剖析大數據平臺的數據存儲
數據作為一種資產，若少了存儲，就成了無根之木，失去了后續(xù)挖掘的價值。在小數據時代，受存儲容量與CPU處理能力限制，在現在看來相當小的數據，在當時其實也可以認為是“大數據”了。正如在蒸汽機時代，創(chuàng)造了時速126英里(203公里)紀錄的Mallard蒸汽火車就可以被視為極速火車了。那么，為何在當時沒人提出Big Data概念，得到業(yè)界關注并催生出一波數據浪潮呢?
Big Data概念是1998年由SGI***科學家John Masey在USENIX大會上提出的。他當時發(fā)表了一篇名為Big Data and the Next Wave of Infrastress的論文，使用了Big Data來描述數據爆炸的現象。但大數據真正得到業(yè)界關注，則是其后多年的事情了。其中大數據最重要的發(fā)酵素則是2003-2006年Google發(fā)布的GFS、MapReduce和BigTable三篇論文。
在我看來，小數據時代的數據量雖然在逐年增加，但是當時突破存儲容量的解決辦法依舊是垂直伸縮，即通過尋求更大容量的存儲介質來解決這個問題。由于互聯網業(yè)務不夠流行，Web 2.0還未開始(更談不上移動應用與物聯網)，當時IT系統要處理的數據結構相當單一，都是相對規(guī)整的關系型數據(結構數據)。因而在小數據時代，存儲世界是關系數據庫一統天下的時代。
當存儲技術的發(fā)展變得步履蹣跚，趕不上數據發(fā)展的速度時，分布式存儲成為了必然選擇，非結構型數據也對存儲格式提出了新的要求。層出不窮的數據源也使得數據量產生了井噴似的迅猛增長。
此時，分布式存儲與NoSQL的誕生回應了這樣的需求，解決了大數據存儲的根本難題。
數據存儲工具如百花盛開，一時仿佛來到了數據存儲的盛世。然而，亂花漸欲迷人眼，我們反而不知道該怎么選擇合適的數據存儲技術了。正如設計需要結合業(yè)務場景，對數據存儲的技術決策同樣需要結合具體的場景。決定的因素包括：
- 數據源的類型與數據的采集方式
- 采集后數據的格式與規(guī)模
- 分析數據的應用場景
如果數據的采集是針對業(yè)務歷史數據的同步與備份，那么HDFS可能就是***的存儲選擇;如果數據的格式為文檔型結構，那么諸如MongoDB之類的文檔型數據庫就可能是我們首要考慮的目標;如果存儲的數據是要應對全文本搜索的應用場景，那么ElasticSearch可能才是我們的心頭所愛。
倘若存在某種業(yè)務場景，使得這幾種決定因素互相沖突，例如既需要分布式的文檔數據庫，又需要支持高性能的統計分析，該怎么應對呢?這就引出了大數據平臺數據存儲的一個重要特征：
- 相同的業(yè)務數據會以多種不同的表現形式，存儲在不同類型的數據庫中，形成polyglot-db這種產生數據冗余的生態(tài)環(huán)境。
沒有哪一款存儲工具擅長應對所有的數據處理場景。
在對數據存儲進行技術決策時，我們需要充分了解各種存儲工具的優(yōu)缺點，然后結合業(yè)務場景對其進行選擇。就像足球教練那樣，要對各個球員的技術特點了如指掌，才能將他們安排在合適的位置上。
在大數據存儲領域，HDFS或許就是我們最放心的守門員，全量的歷史數據都可以交給他。你幾乎不用害怕他會“丟球”，而他守門的技巧是可以橫向擴展的，再多再猛烈的射門他都能擋得住。
PostgreSQL是保守型的后場選手，他技術全面，在保持數據一致性方面他能做到近乎***的萬無一失。性格穩(wěn)重，以符合大多數教練對后防需求的思維方式來踢球。
HBase屬于后腰型選手，既能在防守上給PostgreSQL以協助，又不時通過列式存儲的技術特點傳出讓人拍案叫絕的好球。
Redis是中場提速器，他不僅能夠加快球隊的傳球效率為球隊提速，而且還以極高的傳球***率著稱，偶爾傳出的致命一擊更能幫助球隊攻城拔寨。Redis還是***的團隊成員，可以與各種類型的球員打出漂亮配合，他還不搶風頭，只在自己最擅長的領域默默地展現自己的才華。
ElasticSearch或許可以稱得上是“中場大師”，因為他能為各種類型的前鋒提供傳球支持，并能保證球權處理的高效性。他的各種盤球技法(支持各式各樣的查詢)讓人眼花繚亂。興之所至時，他的盤帶與傳球真如水銀瀉地一般，No look pass的傳球總是出人意料的精彩。
諸如Parquet、Neo4j、Pilosa之類的數據庫都可以稱得上是劍走偏鋒的前鋒球員.他們不善于應對陣地戰(zhàn)靠著穩(wěn)扎穩(wěn)打通過硬實力硬吃對手，而是像刺客一般伺機而動，對手稍有不慎，迎接他的就是一劍封喉的絕殺。
對于polyglot-db這種解決方案，我們還需要細心處理好數據一致性問題，即當數據源的數據發(fā)生變化時，我們如何將這些數據變化反應到各種存儲工具中。如果數據是以immutable形式存儲，滿足數據的一致就變得容易多了。因此在polyglot-db的場景下，我們傾向于數據保持不變。如果業(yè)務場景確實不支持，同步就會變得更復雜。在前面講解數據采集時，我已經給出了不夠***的解決方案，庶幾能解決數據同步問題。
數據存儲就是數據平臺工程師手中的工具百寶箱，你需要熟悉各種工具的利弊，他們擅長處理的場景，然后再將好鋼用在刀刃上，以求***性的發(fā)揮工具的潛力。記住，在大數據平臺中，不是數據驅動而是業(yè)務場景驅動你對數據存儲的技術決策。
【本文為51CTO專欄作者“張逸”原創(chuàng)稿件，轉載請聯系原作者】
