為何而搭建數(shù)據(jù)平臺

業(yè)務(wù)跑的好好的，各系統(tǒng)穩(wěn)定運行，為何還要搭建企業(yè)的數(shù)據(jù)平臺?這樣的問題，心里想想就可以了，不要大聲問出來。我來直接回答一下，公司一般在什么情況下需要搭建數(shù)據(jù)平臺，對各種數(shù)據(jù)進行重新架構(gòu)。

[[227449]]

從業(yè)務(wù)上的視角來看：

1.業(yè)務(wù)系統(tǒng)過多，彼此的數(shù)據(jù)沒有打通。這種情況下，涉及到數(shù)據(jù)分析就麻煩了，可能需要分析人員從多個系統(tǒng)中提取數(shù)據(jù)，再進行數(shù)據(jù)整合，之后才能分析。一次兩次可以忍，天天干這個能忍嗎?人為整合出錯率高怎么控制?分析不及時效率低要不要處理?

從系統(tǒng)的視角來看：

2.業(yè)務(wù)系統(tǒng)壓力大，而不巧，數(shù)據(jù)分析又是一項比較費資源的任務(wù)。那么自然會想到的，通過將數(shù)據(jù)抽取出來，獨立服務(wù)器來處理數(shù)據(jù)查詢、分析任務(wù)，來釋放業(yè)務(wù)系統(tǒng)的壓力。

3.性能問題，公司可以越做越大，同樣的數(shù)據(jù)也會越來越大。可能是歷史數(shù)據(jù)的積累，也可能是新數(shù)據(jù)內(nèi)容的加入，當(dāng)原始數(shù)據(jù)平臺不能承受更大數(shù)據(jù)量的處理時，或者是效率已經(jīng)十分低下時，重新構(gòu)建一個大數(shù)據(jù)處理平臺就是必須的了。

上面我列出了三種情況，但他們并非獨立的，往往是其中兩種甚至三種情況同時出現(xiàn)。一個數(shù)據(jù)平臺的出現(xiàn)，不僅可以承擔(dān)數(shù)據(jù)分析的壓力，同樣可以對業(yè)務(wù)數(shù)據(jù)進行整合，也會不同程度的提高數(shù)據(jù)處理的性能，基于數(shù)據(jù)平臺實現(xiàn)更豐富的功能需求。

2、數(shù)據(jù)平臺的建設(shè)有哪些方案可以選擇

(下文中的優(yōu)缺點僅從企業(yè)選型的角度，并非方案本身的技術(shù)角度)

如果一句話回答的話，有非常多的方案可供選擇，所以就分成了下面幾類，相信也一定程度上覆蓋了大部分企業(yè)的需求了。

常規(guī)數(shù)據(jù)倉庫

概念不說了，既然是做數(shù)據(jù)這一行的，相信你比我還要清楚，不清楚的可以百度。它的重點在于數(shù)據(jù)整合，同時也是對業(yè)務(wù)邏輯的一個梳理。雖然它也可以打包成saas那種cube一類的東西來提升數(shù)據(jù)的讀取性能，但是數(shù)據(jù)倉庫的作用，更多的是為了解決公司的業(yè)務(wù)問題，而不僅僅是性能問題。這一點后面會詳細介紹。關(guān)于這一方案的優(yōu)缺點，不寫沒用的，直接說重點了：

優(yōu)點

方案成熟，關(guān)于數(shù)據(jù)倉庫的架構(gòu)，不管是Inmon架構(gòu)還是Kimball架構(gòu)，都有著非常廣泛的應(yīng)用，而且相信能將這兩種架構(gòu)落地的人也不少。

實施簡單，涉及的技術(shù)層面主要是倉庫的建模以及etl的處理，很多軟件公司具備數(shù)據(jù)倉庫的實施能力，實施難度的大小更多的取決于業(yè)務(wù)邏輯的復(fù)雜程度，而并非技術(shù)上的實現(xiàn)。

靈活性強，說這句話要有對應(yīng)場景的，數(shù)據(jù)倉庫的建設(shè)是透明的，如果需要，可以對倉庫的模型、etl邏輯進行修改，來滿足變更的需求(當(dāng)然，最好設(shè)計之初考慮的周全一點)。同時對于上層的分析而言，通過sql或者mdx對倉庫數(shù)據(jù)的分析處理具備極強的靈活性。

缺點

“實施周期長”，注意，我加了引號，對應(yīng)下面的敏捷型數(shù)據(jù)集市，而且這點是相對的，實施周期的長與短要取決于業(yè)務(wù)邏輯的復(fù)雜性，時間是花在了業(yè)務(wù)邏輯的梳理，并非技術(shù)上的瓶頸。關(guān)于這點，后面會詳細介紹。

數(shù)據(jù)的處理能力有限，這個有限，也是相對的，海量數(shù)據(jù)的處理它肯定不行，非關(guān)系型數(shù)據(jù)的處理它也不行，但是TB以下級別的數(shù)據(jù)，還是搞得定的(也取決于所采用的數(shù)據(jù)庫系統(tǒng))，這個量級的數(shù)據(jù)，而相當(dāng)一部分企業(yè)的數(shù)據(jù)，還是很難超過這個級別的。

商業(yè)敏捷型數(shù)據(jù)集市

底層的數(shù)據(jù)產(chǎn)品與分析層綁定，使得應(yīng)用層可以直接對底層數(shù)據(jù)產(chǎn)品中的數(shù)據(jù)進行拖拽式分析。這一類產(chǎn)品的出現(xiàn)，其初衷是為了對業(yè)務(wù)數(shù)據(jù)進行簡單的、快速的整合，實現(xiàn)敏捷建模，并且大幅提升數(shù)據(jù)的處理速度。目前來看，這些產(chǎn)品都達到了以上的目的。但它的優(yōu)缺點也比較明顯。

優(yōu)點

部署簡單，敏捷開發(fā)，這也是這類產(chǎn)品最大的優(yōu)點，和數(shù)據(jù)倉庫相比，實施周期要短的多。實際上它也沒什么嚴格的實施的概念，因為這類產(chǎn)品只是針對需要分析的數(shù)據(jù)，進行局部的關(guān)聯(lián)，只考慮眼前要解決的問題就夠了，迭代的能力更強些。與上層的分析工具結(jié)合較好，上層的分析工具接入這類數(shù)據(jù)產(chǎn)品后，可直接實現(xiàn)數(shù)據(jù)的圖形化展示和olap分析。

對數(shù)據(jù)處理性能的提高，這類產(chǎn)品都對數(shù)據(jù)的分析性能做了處理，雖然方式不盡相同，有內(nèi)存映射文件存儲的，也有分布式架構(gòu)、列數(shù)據(jù)存儲的。但無疑都一定程度上提高了數(shù)據(jù)的處理性能。

缺點

首先，它是要收費的。無法處理復(fù)雜的業(yè)務(wù)邏輯，這只是一個工具，它無法解決業(yè)務(wù)問題。這類工具中自帶簡單的etl功能，實現(xiàn)簡單的數(shù)據(jù)處理和整合，而如果考慮到歷史數(shù)據(jù)，考慮到整體的數(shù)據(jù)之間的邏輯和關(guān)系，它一定是解決不了的。一個簡單的例子，當(dāng)某個表中，有兩個字段，一個要保留歷史數(shù)據(jù)，一個要更新歷史數(shù)據(jù)，要怎樣實現(xiàn)自動處理。有一個觀念是需要清楚的，不能指望一款工具來解決業(yè)務(wù)問題。這種數(shù)據(jù)產(chǎn)品僅僅是對當(dāng)前的業(yè)務(wù)數(shù)據(jù)進行簡單的整合，第一，數(shù)據(jù)是局部的，第二，時間是當(dāng)前的(其涵帶的增量更新或者全量更新，是無法應(yīng)對復(fù)雜的邏輯的，相信熟悉etl的人都知道這個過程有多復(fù)雜)。當(dāng)然，對于一些公司來說，可能需求只是對當(dāng)前業(yè)務(wù)數(shù)據(jù)進行整合分析，那么這類產(chǎn)品就夠了。

靈活性低，這個也是沒法避免的，越是操作簡單的工具，他的靈活性肯定受限，因為封裝住了，產(chǎn)品是不透明的，常規(guī)的需求用起來非常方便，但是遇到復(fù)雜的，發(fā)現(xiàn)對他內(nèi)部不了解，你也沒法修改，只有蛋疼的份。

從我的角度看，它是很難成為公司的數(shù)據(jù)中心的。

(大規(guī)模并行處理)架構(gòu)的數(shù)據(jù)產(chǎn)品

傳統(tǒng)的主機計算模式在海量數(shù)據(jù)面前，顯得弱勢力但造價非常昂貴，同時技術(shù)上也無法滿足高性能的計算，smp架構(gòu)難于擴展，在獨立主機的cpu計算和io吞吐上，都沒辦法滿足海量數(shù)據(jù)計算的需求。分布式存儲和分布式計算正是解決這一問題的關(guān)鍵，不管是后面的MapReduce計算框架還是并行處理計算框架，都是在這一背景下產(chǎn)生的。

優(yōu)點

海量數(shù)據(jù)的支持，大量成熟的應(yīng)用案例，所以我想這一點是不用懷疑的。擴展性，據(jù)說可線性擴展到10000個節(jié)點，并且每增加一個節(jié)點，查詢、加載性能都成線性增長。易用性，不需要復(fù)雜的調(diào)優(yōu)需求，并行處理由系統(tǒng)自動完成。依然是sql作為交語言，簡單、靈活、強大。

缺點

本身來說，它的定位在olap領(lǐng)域，不擅長oltp交易系統(tǒng)。當(dāng)然我們搭建公司的數(shù)據(jù)中心也不會是用來做交易系統(tǒng)的。

成本，兩個方面的考慮，一是硬件成本，對內(nèi)存、網(wǎng)卡都有要求。當(dāng)然，在硬件選型上，需要達到一個平衡，要在性能、容量、成本等多方面考慮，畢竟不能一味的追求性能，把采購部門嚇到吧。另一個是實施成本，這里主要是人了，安裝配置，再到數(shù)據(jù)倉庫的構(gòu)建，都需要人和時間。(但是必須要說的是，人家軟件都開源了，也省下了一筆錢啊)

技術(shù)門檻，這里是相對于上一個敏捷型數(shù)據(jù)集市的，greenplum的門檻肯定是要高一點了。

hadoop分布式系統(tǒng)架構(gòu)

關(guān)于hadoop，greenplum的開源跟它也是脫不了關(guān)系的。有著高可靠性、高擴展性、高效性、高容錯性的口碑。在互聯(lián)網(wǎng)領(lǐng)域有非常廣泛的運用，雅虎、facebook、百度、淘寶等等等等。hadoop生態(tài)體系非常龐大，各公司基于hadoop所實現(xiàn)的也不僅限于數(shù)據(jù)分析，也包括機器學(xué)習(xí)、數(shù)據(jù)挖掘、實時系統(tǒng)等。當(dāng)企業(yè)數(shù)據(jù)規(guī)模達到一定的量級，我想hadoop是各大企業(yè)的首選方案，到達這樣一個層次的時候，我想企業(yè)所要解決的也不僅是性能問題，還會包括時效問題、更復(fù)雜的分析挖掘功能的實現(xiàn)等。非常典型的實時計算體系也與hadoop這一生態(tài)體系有著緊密的聯(lián)系。

近些年來hadoop的易用性也有了很大的提升，sql-on-hadoop技術(shù)大量涌現(xiàn)，包括hive、impala、spark-sql等。盡管其處理方式不同，但普遍相比于原始基于文件的Mapreduce，不管是性能還是易用性，都是有所提高的。也因此對第三類產(chǎn)品的市場產(chǎn)生了壓力。

對于企業(yè)構(gòu)建數(shù)據(jù)平臺來說，hadoop的優(yōu)勢與劣勢非常明顯：它的大數(shù)據(jù)的處理能力、高可靠性、高容錯性、開源性以及低成本(為什么說低成本，要處理同樣規(guī)模的數(shù)據(jù)，換一個其他方案試試呢)。缺點也就是他的體系的復(fù)雜，技術(shù)門檻較高(能搞定hadoop的公司規(guī)模一般都不小了)。

關(guān)于hadoop的優(yōu)缺點對于公司的數(shù)據(jù)平臺選型來說，影響已經(jīng)不大了。需要上hadoop的時候，也沒什么其它的方案好選擇(要么太貴，要么不行)，沒到達這個數(shù)據(jù)量的時候，也沒人愿意碰這東西?？傊灰獮榱舜髷?shù)據(jù)而大數(shù)據(jù)。

3、方案很多，企業(yè)要怎樣選擇呢

環(huán)境太復(fù)雜，但是我想至少要從下面這幾個方面去考慮吧。

目的

就是文中開始部分的三種情況，或者是其中幾個的組合。做事方法都一樣，哪怕是中午出去吃飯，也是要在心里有個目的，這頓飯是為了吃飽，還是吃爽，或者為了拍別人的馬屁，然后才好選擇去吃什么。當(dāng)然，要明確數(shù)據(jù)平臺的建設(shè)目的，哪里是那么容易的，初衷與討論后確認的目標或許是不一致的。公司要搭建一個數(shù)據(jù)平臺的初衷可能很簡單，只是為了減輕業(yè)務(wù)系統(tǒng)的壓力，將數(shù)據(jù)拉出來后再分析，如果目的真的就這么單純，還真的沒有必要大動干戈了。如果是獨立系統(tǒng)的話，直接將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫復(fù)制出來一份就好了;如果是多系統(tǒng)，選類似finecube那種型敏捷型的商業(yè)數(shù)據(jù)產(chǎn)品也夠了，快速建模，直接用finebi或者finereport接入進去就能實現(xiàn)數(shù)據(jù)的可視化與olap分析。

但是，既然已經(jīng)決定要將數(shù)據(jù)平臺獨立出來了，就不再多考慮一點嗎?多個系統(tǒng)的數(shù)據(jù)，不趁機梳理整合一下?當(dāng)前只有分析業(yè)務(wù)數(shù)據(jù)的需求，以后會不會考慮到歷史數(shù)據(jù)呢?這種敏捷的方案能夠支撐明年、后年的需求嗎?

任何公司要搭建數(shù)據(jù)平臺，都不是一件小事，多花一兩個月實施你可能覺得累，多花一周兩周的時間，認真的思考一下總可以的吧。雷軍不是說過這樣一句話：不能以戰(zhàn)術(shù)上的勤奮，掩蓋戰(zhàn)略上的懶惰。

數(shù)據(jù)量

根據(jù)公司的數(shù)據(jù)規(guī)模選擇合適的方案，這里說多了都是廢話。

成本

包括時間成本和金錢，不必多說。但是這里有一個問題想提一下，發(fā)現(xiàn)很多公司，要么不上數(shù)據(jù)平臺，一旦有了這樣的計劃，就恨不得馬上把平臺搭出來用起來，時間成本不肯花，這樣的情況很容易考慮欠缺，也容易被數(shù)據(jù)實施方忽悠。

關(guān)于方案選擇的建議，舉以下3+1個場景

場景a：要實現(xiàn)對業(yè)務(wù)數(shù)據(jù)的快速提取和分析，多個業(yè)務(wù)系統(tǒng)，沒有達到海量數(shù)據(jù)，不考慮歷史數(shù)據(jù)，不需要依照業(yè)務(wù)邏輯對數(shù)據(jù)進行系統(tǒng)的梳理，這種情況下，可以考慮敏捷型的bi工具自帶的數(shù)據(jù)底層。

簡單來講，這種場景僅僅是在技術(shù)層面上，完成對數(shù)據(jù)的整合與提速，并沒有從業(yè)務(wù)層面上對數(shù)據(jù)進行建模。他可以滿足一定的分析需求，但是不能成為公司的數(shù)據(jù)中心。

場景b：要搭建公司級的數(shù)據(jù)中心，打通各系統(tǒng)之間的數(shù)據(jù)。非常明顯的，需要搭建一個數(shù)據(jù)倉庫。這時就需要進一步考慮公司數(shù)據(jù)的量級了，如果是小數(shù)據(jù)量，TB級以下，那么在傳統(tǒng)數(shù)據(jù)庫中建這樣一個數(shù)據(jù)倉庫就可以了，如果數(shù)據(jù)量達到幾十上百TB，或者可見的在未來幾年內(nèi)數(shù)據(jù)會達到這樣一個規(guī)模，可以將倉庫搭在greenplum中。

這種場景應(yīng)該是適用于大部分公司，對于大部分企業(yè)來說，數(shù)據(jù)量都不會PB級別，更多的是在TB級以下。

場景c：公司數(shù)據(jù)爆發(fā)式增長，原有的數(shù)據(jù)平臺無法承擔(dān)海量數(shù)據(jù)的處理，那么就建議考慮hadoop這種大數(shù)據(jù)平臺了。它一定是公司的數(shù)據(jù)中心，這樣一個角色，倉庫是少不了的，可以將原來的倉庫直接搬到hive中去。這種數(shù)據(jù)量比較大的情況要怎樣呈現(xiàn)，因為hive的性能較差，它的即席查詢可以接impala，也可以接greenplum，因為impala的并發(fā)量不是那么高，而greenplum正好有它的外部表(也就是greenplum創(chuàng)建一張表，表的特性叫做外部表，讀取的內(nèi)容是hadoop的hive里的)，正好和hadoop完美的融合(當(dāng)然也可以不用外部表)。

場景d：這個是后面補充的，當(dāng)公司原本有一個數(shù)據(jù)倉庫，但歷史數(shù)據(jù)了堆積過多，分析性能下降，要怎么辦?兩個方案可以考慮，比較長遠的，可以將倉庫以及數(shù)據(jù)遷移到greenplum中，形成一個新的數(shù)據(jù)平臺，一個獨立的數(shù)據(jù)平臺，可以產(chǎn)生更多的可能性;比較快速的，是可以將類似finecube那種敏捷型數(shù)據(jù)產(chǎn)品接入原來的倉庫，這樣來提升數(shù)據(jù)的處理性能，滿足分析的要求。

4、關(guān)于方案選型時可能會出現(xiàn)的誤區(qū)

忽略業(yè)務(wù)的復(fù)雜性，要用工具來解決或者是繞開業(yè)務(wù)的邏輯。這個是我最近遇到過的，客戶要做報表平臺，有三個業(yè)務(wù)系統(tǒng)的數(shù)據(jù)需要整合。但是急于變現(xiàn)，不想搭建傳統(tǒng)的數(shù)據(jù)倉庫，所以從敏捷型的bi工具中選型。工具廠商對自己數(shù)據(jù)產(chǎn)品的描述，一般著重于他的快速實施、性能的優(yōu)化、以及自帶的基本etl功能。這樣容易給客戶造成誤區(qū)，就是通過這一產(chǎn)品可快速搭建出一個公司級別的數(shù)據(jù)中心，滿足于頂層對數(shù)據(jù)的需求。然而在后期突然意識到，工具所解決的，僅僅是在技術(shù)層面上簡化了工具的使用的復(fù)雜性，把etl和數(shù)據(jù)集市封裝在一起，并且提高了數(shù)據(jù)的性能，但是并沒有從業(yè)務(wù)層面上實現(xiàn)數(shù)據(jù)的建模，很多細節(jié)問題無法處理。

雖然敏捷開發(fā)非常誘人，如果業(yè)務(wù)系統(tǒng)簡單，或者只需要分析當(dāng)前狀態(tài)的業(yè)務(wù)數(shù)據(jù)，不需要公司級的數(shù)據(jù)中心，那么確實是一個非常好的方案。然而這些問題還沒有考慮清楚，對敏捷產(chǎn)品有了過高的期望，后面是會遇到些麻煩的。除此之外，可能還會有為了大數(shù)據(jù)而大數(shù)據(jù)的，但是這些我在實際的工作中還沒有遇到。

最后總結(jié)一下，企業(yè)選擇數(shù)據(jù)平臺的方案，有著不同的原因，要合理的選型，既要充分的考慮搭建數(shù)據(jù)平臺的目的，也要對各種方案有著充分的認識。