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