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