大資料應用之雙色球算獎平台總體設計曆史資料存儲篇

版權所有，轉載請注明出處

　　曆史期次的雙色球選注資料的存儲，采用什麼樣的格式比較好呢？這需要重點從三個方面考慮，一、檔案通路友善嗎？二、檔案伺服器空間夠用嗎？三、軟硬體故障環境下，如何保障資料的可用性。基于這幾個方面的考慮，到底是采用檔案存儲還是采用資料庫存儲呢？本文，從傳統和前沿技術兩個角度給出了兩種相應的解決方案。

　　問題的存在，不代表沒有解決的方法，一切軟體問題的技術解決方案，其實都是在各種妥協中尋求平衡點而已。當然總有無法平衡的時候，而這時總會有技術方面的突破，有需求才有動力。傳統的方式，針對問題一，可以按照地域或者期次進行檔案夾組織，按照投注站進行檔案命名，不同投注站的單獨期次的檔案存放到同一個檔案中，這樣做的好處是單個檔案的大小變小了，讀取成為可能，缺點是你要去管理大量的小檔案。針對問題二、如果考慮一台主機就能存個三年五載的資料，不妨搞個磁盤陣列，或者多加幾塊t級的存儲硬碟。這麼做的好處是空間問題得到解決了，缺點是仍然面臨io讀取速度的問題。針對問題三、可以采用錄音帶機，或者實體隔離的備援備份，考慮到資料的特點，資料一次寫入，不會發生變更，是以即使是刻盤的方式都是能夠解決問題的，這麼做自然能做到保障資料的可用性，但是同樣的存在問題，那就是即時可用性，無論什麼原因，我必須停下目前的工作，重新進行資料的導入和加載。

　　如果雙色球曆史資料存儲的問題，結合最新的分布式存儲（hdfs），會得到怎麼樣的效果呢？我們不妨仔細的考慮一下。如果采用分布式單檔案存儲，每一期作為一個檔案，可以很好的解決存儲空間和高可用性的問題，但是分段讀取還是一個障礙，除非你一次想使用整個檔案。是以還是要妥協，那就是把檔案按照上一節中提到的方式進行切分。隻是考慮業務分析的需求，粒度可以控制在以地域為機關或者以投注站為機關，粒度過細則會涉及到hdfs檔案分塊的問題（64m）。

　　考慮到雙色球投注資料的特點，每一個選注為一個獨立的資料單元，一條記錄。采用關系型資料庫進行存儲的好處很明顯，就是結構清晰，通路友善。但是由于資料規模的問題，單表存儲2億條記錄，如果采用傳統關系型資料庫，面臨的核心問題就是單表記錄數過大的問題。

　　曆史的因素，關系型資料一緻面臨大資料應用領域的挑戰，當然也衍生出來許多的解決辦法，比如說分區，比如說分表。分區的核心思想在于增加單表的空間，而分表的核心思想則在于分而治之。但是都無法逃避單點通路受限的問題，再怎麼變，也要受控于rdms伺服器的性能。

　　如果采用no-sql技術（hbase）又會是怎麼樣的情形呢？我們以期次為機關組織表結構，每期一個檔案，以投注站編号和流水号為rowkey，以紅球為family1，以籃球為family2。根據hbase的特點，則既可以解決記錄數的問題，也可以解決通路并發通路性能的問題（hbase檔案存儲采用hdfs）。同時hbase基礎之上有很多分布式并行計算的工具可用，可以很好的協調多伺服器的并行計算。

　　前文已述，很喜歡no-sql方式的實作，個人認為是目前最為恰當的方式。引玉抛磚，還是多聽聽各位大牛的意見吧。