《HBase權威指南》一1.1 海量資料的黎明

本節書摘來異步社群《hbase權威指南》一書中的第1章，第1.1節，作者： 【美】lars george 譯者： 代志遠 , 劉佳 , 蔣傑 責編： 楊海玲，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

我們生活在一個網際網路時代，無論是想搜尋最佳的火雞菜單，還是送媽媽什麼樣的生日禮物，都希望能夠通過網際網路迅速地檢索到問題的答案，同時希望查詢到的結果有用，而且非常切合我們的需要。

是以，很多公司開始緻力于提供更有針對性的資訊，例如推薦或線上廣告，這種能力會直接影響公司在商業上的成敗。現在類似hadoop②這樣的系統能夠為公司提供存儲和處理pb級資料的能力，随着新機器學習算法的不斷發展，收集更多資料的需求也在與日俱增。

以前，因為缺乏劃算的方式來存儲所有資訊，很多公司會忽略某些資料源，但是現在這樣的處理方式會讓公司喪失競争力。存儲和分析每一個資料點的需求在不斷增長，這種需求的增長直接導緻各公司電子商務平台産生了更多的資料。

過去，唯一的選擇就是将收集到的資料删減後儲存起來，例如隻保留最近n天的資料。然而，這種方法隻在短期内可行，它無法存儲幾個月或幾年收集到的所有資料，是以建議：建構一種數學模型覆寫整個時間段或者改進一個算法，重跑以前所有的資料，以達到更好的效果。

對于海量資料的重要性，ralph kimball博士指出③：

“資料資産會取代20世紀傳統有形資産的地位，成為資産負債表的重要組成部分。”

還指出：

“資料的價值已經超越了傳統企業廣泛認同的價值邊界。”

google和amazon是認識到資料價值的典範，它們已經開始開發滿足自己業務需求的解決方案。例如，google在一系列的技術出版物中描述了基于商業硬體的可擴充的存儲和處理系統。開源社群利用google的這些思想實作了開源hadoop項目的兩個子產品：hdfs和mapreduce。

hadoop擅長存儲任意的、半結構化的資料，甚至是非結構化的資料，可以幫助使用者在分析資料的時候決定如何解釋這些資料，同樣允許使用者随時更改資料分類的方式：一旦使用者更新了算法，隻需要重新分析資料。

目前hadoop幾乎是所有現有資料庫系統的一種補充，它給使用者提供了資料存儲的無限空間，支援使用者在恰當的時候存儲和擷取資料，并且針對大檔案的存儲、批量通路和流式通路做了優化。這使得使用者對資料的分析變得簡單快捷，但是使用者同樣需要通路分析後的最終資料，這種需求需要的不是批量模式而是随機通路模式，這種模式相對于在資料庫系統來說，相當于一種全表掃描和使用索引。

通常使用者在随機通路結構化資料的時候都會查詢資料庫。rdbms在這方面最為突出，但是也有一些少量的有差異的實作方式，比如面向對象的資料庫。大多數rdbms一直遵守科德十二定律（codd’s 12 rules）④，這個定律對于rdbms來說是剛性标準，并且由于rdbms的底層架構是經過仔細研究的，是以在相當長的一段時間裡這種架構都不會有明顯的改變。近年來出現的各種處理方法，如列式存儲的（column-oriented）資料庫和大規模并行處理（massively parallel processing，mpp）資料庫，表明業界重新思考了技術方案以滿足新的工作負載，但是大多數解決方案仍舊是基于科德十二定律來實作的，并沒有打破傳統的法則。

列式存儲資料庫 列式存儲資料庫以列為機關聚合資料，然後将列值順序地存入磁盤，這種存儲方法不同于行式存儲的傳統資料庫，行式存儲資料庫連續地存儲整行。圖1-1形象地展示了列式存儲和行式存儲的不同實體結構。 列式存儲的出現主要基于這樣一種假設：對于特定的查詢，不是所有的值都是必需的。尤其是在分析型資料庫裡，這種情形很常見，是以需要選擇一種更為合适的存儲模式。 在這種新型的設計中，減少i/o隻是衆多主要因素之一，它還有其他的優點：因為列的資料類型天生是相似的，即便邏輯上每一行之間有輕微的不同，但仍舊比按行存儲的結構聚集在一起的資料更利于壓縮，因為大多數的壓縮算法隻關注有限的壓縮視窗。 像增量壓縮或字首壓縮這類的專業算法，是基于列存儲的類型定制的，因而大幅度提高了壓縮比。更好的壓縮比有利于在傳回結果時降低帶寬的消耗。

值得注意的是，從典型rdbms的角度來看，hbase并不是一個列式存儲的資料庫，但是它利用了磁盤上的列存儲格式，這也是rdbms與hbase最大的相似之處，因為hbase以列式存儲的格式在磁盤上存儲資料。但它與傳統的列式資料庫有很大的不同：傳統的列式資料庫比較适合實時存取資料的場景，hbase比較适合鍵值對的資料存取，或者有序的資料存取。

如今資料的産生速度比幾年以前已經有了迅猛的增長，随着全球化步伐加快，這個增長速度隻會越來越迅猛，由此所産生的資料處理問題也會越來越嚴峻。像google、amazon、ebay和facebook這樣網站的使用者已經覆寫到了地球上的絕大多數人。全球化網絡應用（planet-size web application）的概念已經形成，在這種背景下，企業使用hbase更合适。

舉例來說，facebook每天增量存儲到它們hadoop叢集的資料量超過15 tb⑤，并且随後會對所有這些資料進行處理。這些資料一部分是點選流日志，使用者點選了它們的網站或點選了使用facebook提供的社交插件的網站，每一步點選操作都會被記錄并儲存，這非常适合以批處理的模式，為預測和推薦系統建構機器學習模型。

facebook還有一個實時元件，就是它們的消息系統，其中包括聊天、塗鴉牆和電子郵件，每個月會産生超過1350億條資料⑥，存儲幾個月之後便會産生一個量級龐大的尾部資料，并且這些尾部資料需要被有效地處理。盡管電子郵件中占用存儲量較大的部分（如附件）通常存儲在二級系統中⑦，但這些消息産生的資料量還是令人難以置信的。以facebook的資料産生條目為基礎，假如按twitter中的每條資料占用140位元組來計算，facebook每個月将會産生超過17 tb的資料，在将這些資料導入到hbase之前，現存的系統每個月也要處理超過25 tb的資料。⑧

目前在少數的重點行業中，面向web業務的公司收集的資料量也在不斷增長。

金融

如股票漲跌産生的資料。

生物資訊學

智能電網

銷售

如銷售終端（pos機）産生的資料，或者是股票系統、庫存系統。

基因組學

行動電話服務、軍事、環境工程

也産生了海量的資料。

有效存儲pb級的資料并能高效地檢索和更新并不是一件容易的事情。下面深入探讨一下我們将面臨的挑戰。