公司要做數(shù)據(jù)分析，首先要考慮數(shù)據(jù)的準備，也就是數(shù)據(jù)平臺的建設，最近接觸了
幾個客戶都處于這一環(huán)節(jié)，而且其中一個
在方案選型過程中，也是充滿了糾結，而
我也并沒有在開始階段給出合理全面的建議。
所以根據(jù)自己的認知整理了這篇文章，一
是對自己的整理，二是希望通過分享，給
大家一些參考的價值。
如我前面每篇文章中所說的，文中內容局限于自己的認知和見識，有錯誤或者不足之處，歡迎大家與“jiago王”交流，對其中的錯誤給予指正。
01
為何而搭建數(shù)據(jù)平臺
業(yè)務跑的好好的，各系統(tǒng)穩(wěn)定運行，為何還要搭建企業(yè)的數(shù)據(jù)平臺？
這樣的問題，心里想想就可以了，不要大聲問出來。我來直接回答一下，公司一般在什么情況下需要搭建數(shù)據(jù)平臺，對各種數(shù)據(jù)進行重新架構。
從業(yè)務上的視角來看：
1.業(yè)務系統(tǒng)過多，彼此的數(shù)據(jù)沒有打通。這種情況下，涉及到數(shù)據(jù)分析就麻煩了，可能需要分析人員從多個系統(tǒng)中提取數(shù)據(jù)，再進行數(shù)據(jù)整合，之后才能分析。一次兩次可以忍，天天干這個能忍嗎？人為整合出錯率高怎么控制？分析不及時效率低要不要處理？
從系統(tǒng)的視角來看：
2.業(yè)務系統(tǒng)壓力大，而不巧，數(shù)據(jù)分析又是一項比較費資源的任務。那么自然會想到的，通過將數(shù)據(jù)抽取出來，獨立服務器來處理數(shù)據(jù)查詢、分析任務，來釋放業(yè)務系統(tǒng)的壓力。
3.性能問題，公司可以越做越大，同樣的數(shù)據(jù)也會越來越大?？赡苁菤v史數(shù)據(jù)的積累，也可能是新數(shù)據(jù)內容的加入，當原始數(shù)據(jù)平臺不能承受更大數(shù)據(jù)量的處理時，或者是效率已經(jīng)十分低下時，重新構建一個大數(shù)據(jù)處理平臺就是必須的了。
上面我列出了三種情況，但他們并非獨立的，往往是其中兩種甚至三種情況同時出現(xiàn)。一個數(shù)據(jù)平臺的出現(xiàn)，不僅可以承擔數(shù)據(jù)分析的壓力，同樣可以對業(yè)務數(shù)據(jù)進行整合，也會不同程度的提高數(shù)據(jù)處理的性能，基于數(shù)據(jù)平臺實現(xiàn)更豐富的功能需求。
02
數(shù)據(jù)平臺的建設有哪些方案可以選擇（下文中的優(yōu)缺點僅從企業(yè)選型的角度，并非方案本身的技術角度）
如果一句話回答的話，那就是：太多了（這是一句廢話，我承認），但確實有非常多的方案可供選擇，我懂的少，肯定是無法一一介紹，所以就分成了下面幾類，相信也一定程度上覆蓋了大部分企業(yè)的需求了。
1.常規(guī)數(shù)據(jù)倉庫：概念不說了，既然是做數(shù)據(jù)這一行的，相信你比我還要清楚，不清楚的可以百度。它的重點在于數(shù)據(jù)整合，同時也是對業(yè)務邏輯的一個梳理。雖然它也可以打包成ssas那種cube一類的東西來提升數(shù)據(jù)的讀取性能，但是數(shù)據(jù)倉庫的作用，更多的是為了解決公司的業(yè)務問題，而不僅僅是性能問題。這一點后面會詳細介紹。
關于這一方案的優(yōu)缺點，不寫沒用的，直接說重點了：
優(yōu)點：
方案成熟，關于數(shù)據(jù)倉庫的架構，不管是Inmon架構還是Kimball架構，都有著非常廣泛的應用，而且相信能將這兩種架構落地的人也不少。
實施簡單，涉及的技術層面主要是倉庫的建模以及etl的處理，很多軟件公司具備數(shù)據(jù)倉庫的實施能力，實施難度的大小更多的取決于業(yè)務邏輯的復雜程度，而并非技術上的實現(xiàn)。
靈活性強，說這句話要有對應場景的，數(shù)據(jù)倉庫的建設是透明的，如果需要，可以對倉庫的模型、etl邏輯進行修改，來滿足變更的需求（當然，最好設計之初考慮的周全一點）。同時對于上層的分析而言，通過sql或者mdx對倉庫數(shù)據(jù)的分析處理具備極強的靈活性。
缺點：
“實施周期長”，注意，我加了引號，對應下面的敏捷型數(shù)據(jù)集市，而且這點是相對的，實施周期的長與短要取決于業(yè)務邏輯的復雜性，時間是花在了業(yè)務邏輯的梳理，并非技術上的瓶頸。關于這點，后面會詳細介紹。
數(shù)據(jù)的處理能力有限，這個有限，也是相對的，海量數(shù)據(jù)的處理它肯定不行，非關系型數(shù)據(jù)的處理它也不行，但是TB以下級別的數(shù)據(jù)，還是搞得定的（也取決于所采用的數(shù)據(jù)庫系統(tǒng)），這個量級的數(shù)據(jù)，而相當一部分企業(yè)的數(shù)據(jù)，還是很難超過這個級別的。
2.商業(yè)敏捷型數(shù)據(jù)集市：
底層的數(shù)據(jù)產品與分析層綁定，使得應用層可以直接對底層數(shù)據(jù)產品中的數(shù)據(jù)進行拖拽式分析。這一類產品的出現(xiàn)，其初衷是為了對業(yè)務數(shù)據(jù)進行簡單的、快速的整合，實現(xiàn)敏捷建模，并且大幅提升數(shù)據(jù)的處理速度。目前來看，這些產品都達到了以上的目的。但它的優(yōu)缺點也比較明顯。
優(yōu)點：
部署簡單，敏捷開發(fā)，這也是這類產品最大的優(yōu)點，和數(shù)據(jù)倉庫相比，實施周期要短的多。
實際上它也沒什么嚴格的實施的概念，因為這類產品只是針對需要分析的數(shù)據(jù)，進行局部的關聯(lián)，只考慮眼前要解決的問題就夠了，迭代的能力更強些。
與上層的分析工具結合較好，上層的分析工具接入這類數(shù)據(jù)產品后，可直接實現(xiàn)數(shù)據(jù)的圖形化展示和olap分析。
對數(shù)據(jù)處理性能的提高，這類產品都對數(shù)據(jù)的分析性能做了處理，雖然方式不盡相同，有內存映射文件存儲的，也有分布式架構、列數(shù)據(jù)存儲的。但無疑都一定程度上提高了數(shù)據(jù)的處理性能。
缺點：
首先，它是要收費的。
無法處理復雜的業(yè)務邏輯，這只是一個工具，它無法解決業(yè)務問題。這類工具中自帶簡單的etl功能，實現(xiàn)簡單的數(shù)據(jù)處理和整合，而如果考慮到歷史數(shù)據(jù)，考慮到整體的數(shù)據(jù)之間的邏輯和關系，它一定是解決不了的。一個簡單的例子，當某個表中，有兩個字段，一個要保留歷史數(shù)據(jù)，一個要更新歷史數(shù)據(jù)，要怎樣實現(xiàn)自動處理。有一個觀念是需要清楚的，不能指望一款工具來解決業(yè)務問題。這種數(shù)據(jù)產品僅僅是對當前的業(yè)務數(shù)據(jù)進行簡單的整合，第一，數(shù)據(jù)是局部的，第二，時間是當前的（其涵帶的增量更新或者全量更新，是無法應對復雜的邏輯的，相信熟悉etl的人都知道這個過程有多復雜）。當然，對于一些公司來說，可能需求只是對當前業(yè)務數(shù)據(jù)進行整合分析，那么這類產品就夠了。（說實話，很多公司真的是懶得更長遠的考慮，有一天沒一天的，誰說的準呢）
靈活性低，這個也是沒法避免的，越是操作簡單的工具，他的靈活性肯定受限，因為封裝住了，產品是不透明的，常規(guī)的需求用起來非常方便，但是遇到復雜的，發(fā)現(xiàn)對他內部不了解，你也沒法修改，只有蛋疼的份。
從我的角度看，它是很難成為公司的數(shù)據(jù)中心的。
3.MPP(大規(guī)模并行處理)架構的數(shù)據(jù)產品，以最近開源的greenplum為例。
傳統(tǒng)的主機計算模式在海量數(shù)據(jù)面前，顯得弱雞。造價非常昂貴，同時技術上也無法滿足高性能的計算，smp架構難于擴展，在獨立主機的cpu計算和io吞吐上，都沒辦法滿足海量數(shù)據(jù)計算的需求。分布式存儲和分布式計算正是解決這一問題的關鍵，不管是后面的MapReduce計算框架還是MPP計算框架，都是在這一背景下產生的。
greenplum的數(shù)據(jù)庫引擎是基于postgresql的，并且通過Interconnnect神器實現(xiàn)了對同一個集群中多個Postgresql實例的高效協(xié)同和并行計算。
同時，基于greenplum的數(shù)據(jù)平臺建設，可以實現(xiàn)兩個層面的處理，顯而易見的一個是對數(shù)據(jù)處理性能的處理，greenplum的百科中宣稱支持50PB級海量數(shù)據(jù)的處理，考慮它有吹牛的成分，對目前greenplum實際應用情況的了解，100tb級左右的數(shù)據(jù)，是非常輕松的。另一個是數(shù)據(jù)倉庫可以搭建在greenplum中，這一層面上也是對業(yè)務邏輯的梳理，對公司業(yè)務數(shù)據(jù)的整合。
優(yōu)點：
海量數(shù)據(jù)的支持，大量成熟的應用案例，所以我想這一點是不用懷疑的。
擴展性，據(jù)說可線性擴展到10000個節(jié)點，并且每增加一個節(jié)點，查詢、加載性能都成線性增長。
易用性，不需要復雜的調優(yōu)需求，并行處理由系統(tǒng)自動完成。依然是sql作為交語言，簡單、靈活、強大。
高級功能，greenplum還研發(fā)了很多高級數(shù)據(jù)分析管理功能，例如人氣很高的外部表，還有Primary/Mirror鏡像保護機制，行／列混合存儲等。
穩(wěn)定性，greenplum原本作為一個純商業(yè)數(shù)據(jù)產品，具有很長的歷史，其穩(wěn)定性相比于其他產品以及敏捷性數(shù)據(jù)集市是更加有保障的。greenplum有非常多的應用案例，納斯達克、紐約證券交易所、平安銀行、建設銀行、華為等都建立了基于greenplum的數(shù)據(jù)分析平臺。其穩(wěn)定性是可以從側面驗證的，在15年9月份開源后，各大互聯(lián)網(wǎng)公司也是一片歡騰，現(xiàn)在也接觸了幾家在使用greenplum的客戶，對其評價都很高。
缺點：
本身來說，它的定位在olap領域，不擅長oltp交易系統(tǒng)。當然我們搭建公司的數(shù)據(jù)中心也不會是用來做交易系統(tǒng)的。
成本，兩個方面的考慮，一是硬件成本，greenplum有其推薦的硬件規(guī)格，對內存、網(wǎng)卡都有要求。當然，在硬件選型上，需要達到一個平衡，要在性能、容量、成本等多方面考慮，畢竟不能一味的追求性能，把采購部門嚇到吧。另一個是實施成本，這里主要是人了，基本的是greenplum的安裝配置，再到greenplum中數(shù)據(jù)倉庫的構建，都需要人和時間。（但是必須要說的是，人家軟件都開源了，也省下了一筆錢?。?br>
技術門檻，這里是相對于上一個敏捷型數(shù)據(jù)集市的，greenplum的門檻肯定是要高一點了。
4.hadoop分布式系統(tǒng)架構
關于hadoop，已經(jīng)火的要爆炸了，greenplum的開源跟它也是脫不了關系的。有著高可靠性、高擴展性、高效性、高容錯性的口碑。在互聯(lián)網(wǎng)領域有非常廣泛的運用，雅虎、facebook、百度、淘寶等等等等。hadoop生態(tài)體系非常龐大，各公司基于hadoop所實現(xiàn)的也不僅限于數(shù)據(jù)分析，也包括機器學習、數(shù)據(jù)挖掘、實時系統(tǒng)等。
當企業(yè)數(shù)據(jù)規(guī)模達到一定的量級，我想hadoop是各大企業(yè)的首選方案，到達這樣一個層次的時候，我想企業(yè)所要解決的也不僅是性能問題，還會包括時效問題、更復雜的分析挖掘功能的實現(xiàn)等。非常典型的實時計算體系也與hadoop這一生態(tài)體系有著緊密的聯(lián)系。
近些年來hadoop的易用性也有了很大的提升，sql-on-hadoop技術大量涌現(xiàn)，包括hive、impala、spark-sql等。盡管其處理方式不同，但普遍相比于原始基于文件的Mapreduce，不管是性能還是易用性，都是有所提高的。也因此對mpp產品的市場產生了壓力。
對于企業(yè)構建數(shù)據(jù)平臺來說，hadoop的優(yōu)勢與劣勢非常明顯：它的大數(shù)據(jù)的處理能力、高可靠性、高容錯性、開源性以及低成本（為什么說低成本，要處理同樣規(guī)模的數(shù)據(jù)，換一個其他方案試試呢）。缺點也就是他的體系的復雜，技術門檻較高（能搞定hadoop的公司規(guī)模一般都不小了）。
關于hadoop的優(yōu)缺點對于公司的數(shù)據(jù)平臺選型來說，影響已經(jīng)不大了。需要上hadoop的時候，也沒什么其它的方案好選擇（要么太貴，要么不行），沒到達這個數(shù)據(jù)量的時候，也沒人愿意碰這東西?？傊?，不要為了大數(shù)據(jù)而大數(shù)據(jù)。
03
方案很多，企業(yè)要怎么選擇呢
環(huán)境太復雜，但是我想至少要從下面這幾個方面去考慮吧。
1.目的：什么樣的目的？就是文中開始部分的三種情況呀（不好意思，自大了，肯定有其它情況，歡迎向“jiago王”補充），或者是其中幾個的組合。
做事方法都一樣，哪怕是中午出去吃飯，也是要在心里有個目的，這頓飯是為了吃飽，還是吃爽，或者為了拍別人的馬屁，然后才好選擇去吃什么。
當然，要明確數(shù)據(jù)平臺的建設目的，哪里是那么容易的，初衷與討論后確認的目標或許是不一致的。
公司要搭建一個數(shù)據(jù)平臺的初衷可能很簡單，只是為了減輕業(yè)務系統(tǒng)的壓力，將數(shù)據(jù)拉出來后再分析，如果目的真的就這么單純，還真的沒有必要大動干戈了。如果是獨立系統(tǒng)的話，直接將業(yè)務系統(tǒng)的數(shù)據(jù)庫復制出來一份就好了；如果是多系統(tǒng)，選類似finecube那種型敏捷型的商業(yè)數(shù)據(jù)產品也夠了，快速建模，直接用finebi或者finereport接入進去就能實現(xiàn)數(shù)據(jù)的可視化與olap分析。
但是，既然已經(jīng)決定要將數(shù)據(jù)平臺獨立出來了，就不再多考慮一點嗎？多個系統(tǒng)的數(shù)據(jù)，不趁機梳理整合一下？當前只有分析業(yè)務數(shù)據(jù)的需求，以后會不會考慮到歷史數(shù)據(jù)呢？這種敏捷的方案能夠支撐明年、后年的需求嗎？
任何公司要搭建數(shù)據(jù)平臺，都不是一件小事，多花一兩個月實施你可能覺得累，多花一周兩周的時間，認真的思考一下總可以的吧。雷軍不是說過這樣一句話：不能以戰(zhàn)術上的勤奮，掩蓋戰(zhàn)略上的懶惰。
2.數(shù)據(jù)量：根據(jù)公司的數(shù)據(jù)規(guī)模選擇合適的方案，這里說多了都是廢話。
3.成本：包括時間成本和金錢，不必多說。但是這里有一個問題想提一下，發(fā)現(xiàn)很多公司，要么不上數(shù)據(jù)平臺，一旦有了這樣的計劃，就恨不得馬上把平臺搭出來用起來，時間成本不肯花，這樣的情況很容易考慮欠缺，也容易被數(shù)據(jù)實施方忽悠。
關于方案選擇的建議，舉以下3+1個場景
場景a：要實現(xiàn)對業(yè)務數(shù)據(jù)的快速提取和分析，多個業(yè)務系統(tǒng)，沒有達到海量數(shù)據(jù)，不考慮歷史數(shù)據(jù)，不需要依照業(yè)務邏輯對數(shù)據(jù)進行系統(tǒng)的梳理，這種情況下，可以考慮敏捷型的bi工具自帶的數(shù)據(jù)底層。
簡單來講，這種場景僅僅是在技術層面上，完成對數(shù)據(jù)的整合與提速，并沒有從業(yè)務層面上對數(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，或者可見的在未來幾年內數(shù)據(jù)會達到這樣一個規(guī)模，可以將倉庫搭在greenplum中。
這種場景應該是適用于大部分公司，對于大部分企業(yè)來說，數(shù)據(jù)量都不會PB級別，更多的是在TB級以下。
場景c：公司數(shù)據(jù)爆發(fā)式增長，原有的數(shù)據(jù)平臺無法承擔海量數(shù)據(jù)的處理，那么就建議考慮hadoop這種大數(shù)據(jù)平臺了。它一定是公司的數(shù)據(jù)中心，這樣一個角色，倉庫是少不了的，可以將原來的倉庫直接搬到hive中去。這種數(shù)據(jù)量比較大的情況要怎樣呈現(xiàn)，因為hive的性能較差，它的即席查詢可以接impala，也可以接greenplum，因為impala的并發(fā)量不是那么高，而greenplum正好有它的外部表（也就是greenplum創(chuàng)建一張表，表的特性叫做外部表，讀取的內容是hadoop的hive里的），正好和hadoop完美的融合（當然也可以不用外部表）。
場景d：這個是后面補充的，當公司原本有一個數(shù)據(jù)倉庫，但歷史數(shù)據(jù)了堆積過多，分析性能下降，要怎么辦？兩個方案可以考慮，比較長遠的，可以將倉庫以及數(shù)據(jù)遷移到greenplum中，形成一個新的數(shù)據(jù)平臺，一個獨立的數(shù)據(jù)平臺，可以產生更多的可能性；比較快速的，是可以將類似finecube那種敏捷型數(shù)據(jù)產品接入原來的倉庫，這樣來提升數(shù)據(jù)的處理性能，滿足分析的要求。
04
關于方案選型時可能會出現(xiàn)的誤區(qū)
忽略業(yè)務的復雜性，要用工具來解決或者是繞開業(yè)務的邏輯。
這個是我最近遇到過的，客戶要做報表平臺，有三個業(yè)務系統(tǒng)的數(shù)據(jù)需要整合。但是急于變現(xiàn)，不想搭建傳統(tǒng)的數(shù)據(jù)倉庫，所以從敏捷型的bi工具中選型。工具廠商對自己數(shù)據(jù)產品的描述，一般著重于他的快速實施、性能的優(yōu)化、以及自帶的基本etl功能。這樣容易給客戶造成誤區(qū)，就是通過這一產品可快速搭建出一個公司級別的數(shù)據(jù)中心，滿足于頂層對數(shù)據(jù)的需求。
然而在后期突然意識到，工具所解決的，僅僅是在技術層面上簡化了工具的使用的復雜性，把etl和數(shù)據(jù)集市封裝在一起，并且提高了數(shù)據(jù)的性能，但是并沒有從業(yè)務層面上實現(xiàn)數(shù)據(jù)的建模，很多細節(jié)問題無法處理。
雖然敏捷開發(fā)非常誘人，如果業(yè)務系統(tǒng)簡單，或者只需要分析當前狀態(tài)的業(yè)務數(shù)據(jù)，不需要公司級的數(shù)據(jù)中心，那么確實是一個非常好的方案。然而這些問題還沒有考慮清楚，對敏捷產品有了過高的期望，后面是會遇到些麻煩的。
除此之外，可能還會有為了大數(shù)據(jù)而大數(shù)據(jù)的，但是這些我在實際的工作中還沒有遇到。
最后總結一下，企業(yè)選擇數(shù)據(jù)平臺的方案，有著不同的原因，要合理的選型，既要充分的考慮搭建數(shù)據(jù)平臺的目的，也要對各種方案有著充分的認識。
僅從個人的角度，對于數(shù)據(jù)層面來說，還是傾向于一些靈活性很強的方案的，因為數(shù)據(jù)中心對于公司來說太重要了，我更希望它是透明的，是可以被自己完全掌控的，這樣才有能力實現(xiàn)對數(shù)據(jù)中心更加充分的利用。因為，我不知道未來需要它去承擔一個什么樣的角色。
End.
作者：jiago （中國統(tǒng)計網(wǎng)特邀認證作者）
聯(lián)系客服
