公司要做數據分析，首先要考慮數據的準備，也就是數據平台的建設，最近接觸了幾個客戶都處於這一環節，而且其中一個在方案選型過程中，也是充滿了糾結，而我也並沒有在開始階段給出合理全面的建議。 所以根據自己的認知整理了這篇文章，一是對自己的整理，二是希望通過分享，給大家一些參考的價值。

如我前面每篇文章中所說的，文中內容局限於自己的認知和見識，有錯誤或者不足之處，歡迎大家與我交流，對其中的錯誤給予指正。
（ps：文章很長，心情不好的、比較浮躁的，可以走了，改天再看）

一：為何而搭建數據平台?

業務跑的好好的，各系統穩定運行，為何還要搭建企業的數據平台？ 這樣的問題，心裡想想就可以了，不要大聲問出來。我來直接回答一下，公司一般在什麼情況下需要搭建數據平台，對各種數據進行重新架構。

從業務上的視角來看：

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

從系統的視角來看：

2.業務系統壓力大，而不巧，數據分析又是一項比較費資源的任務。那麼自然會想到的，通過將數據抽取出來，獨立伺服器來處理數據查詢、分析任務，來釋放業務系統的壓力。
3.性能問題，公司可以越做越大，同樣的數據也會越來越大。可能是歷史數據的積累，也可能是新數據內容的加入，當原始數據平台不能承受更大數據量的處理時，或者是效率已經十分低下時，重新構建一個大數據分析處理平台就是必須的了。

上面我列出了三種情況，但他們並非獨立的，往往是其中兩種甚至三種情況同時出現。一個數據平台的出現，不僅可以承擔數據分析的壓力，同樣可以對業務數據進行整合，也會不同程度的提高數據處理的性能，基於數據平台實現更豐富的功能需求。

二：數據平台的建設有哪些方案可以選擇

（下文中的優缺點僅從企業選型的角度，並非方案本身的技術角度）

如果一句話回答的話，那就是：太多了（這是一句廢話，我承認），但確實有非常多的方案可供選擇，我懂的少，肯定是無法一一介紹，所以就分成了下面幾類，相信也一定程度上覆蓋了大部分企業的需求了。

1.常規數據倉庫：

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

優點：

• 方案成熟，關於數據倉庫的架構，不管是Inmon架構還是Kimball架構，都有著非常廣泛的應用，而且相信能將這兩種架構落地的人也不少。
• 實施簡單，涉及的技術層面主要是倉庫的建模以及etl的處理，很多軟體公司具備數據倉庫的實施能力，實施難度的大小更多的取決於業務邏輯的複雜程度，而並非技術上的實現。
• 靈活性強，說這句話要有對應場景的，數據倉庫的建設是透明的，如果需要，可以對倉庫的模型、etl邏輯進行修改，來滿足變更的需求（當然，最好設計之初考慮的周全一點）。同時對於上層的分析而言，通過sql或者mdx對倉庫數據的分析處理具備極強的靈活性。

缺點：

• 「實施周期長」，注意，我加了引號，對應下面的敏捷型數據集市，而且這點是相對的，實施周期的長與短要取決於業務邏輯的複雜性，時間是花在了業務邏輯的梳理，並非技術上的瓶頸。關於這點，後面會詳細介紹。
• 數據的處理能力有限，這個有限，也是相對的，海量數據的大數據分析處理它肯定不行，非關係型數據的處理它也不行，但是TB以下級別的數據，還是搞得定的（也取決於所採用的資料庫系統），這個量級的數據，而相當一部分企業的數據，還是很難超過這個級別的。

2.商業敏捷型數據集市：

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

優點：

• 部署簡單，敏捷開發。這也是這類產品最大的優點，和數據倉庫相比，實施周期要短的多。實際上它也沒什麼嚴格的實施的概念，因為這類產品只是針對需要分析的數據，進行局部的關聯，只考慮眼前要解決的問題就夠了，迭代的能力更強些。
• 與上層的分析工具結合較好。上層的分析工具接入這類數據產品後，可直接實現數據的圖形化展示和olap分析。
• 對數據處理性能的提高。這類產品都對數據的分析性能做了處理，雖然方式不盡相同，有內存映射檔案儲存的，也有分布式架構、欄數據儲存的。但無疑都一定程度上提高了數據的處理性能。

缺點：

• 首先，它是要收費的。
• 無法處理複雜的業務邏輯，這只是一個工具，它無法解決業務問題。這類工具中自帶簡單的etl功能，實現簡單的數據處理和整合，而如果考慮到歷史數據，考慮到整體的數據之間的邏輯和關係，它一定是解決不了的。一個簡單的例子，當某個表中，有兩個欄位，一個要保留歷史數據，一個要更新歷史數據，要怎樣實現自動處理。有一個觀念是需要清楚的，不能指望一款工具來解決業務問題。這種數據產品僅僅是對當前的業務數據進行簡單的整合，第一，數據是局部的，第二，時間是當前的（其涵帶的增量更新或者全量更新，是無法應對複雜的邏輯的，相信熟悉etl的人都知道這個過程有多複雜）。當然，對於一些公司來說，可能需求只是對當前業務數據進行整合分析，那麼這類產品就夠了。（說實話，很多公司真的是懶的做更長遠的考慮，有一天沒一天的，誰說的准呢）
• 靈活性低，這個也是沒法避免的，越是操作簡單的工具，他的靈活性肯定受限，因為封裝住了，產品是不透明的，常規的需求用起來非常方便，但是遇到複雜的，發現對他內部不了解，你也沒法修改，只有蛋疼的份。

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

3.MPP(大規模並行處理)架構的數據產品，以最近開源的greenplum為例。

傳統的主機計算模式在海量大數據面前，顯得弱雞。造價非常昂貴，同時技術上也無法滿足高性能的計算，smp架構難於擴展，在獨立主機的cpu計算和io吞吐上，都沒辦法滿足海量數據計算的需求。分布式儲存和分布式計算正是解決這一問題的關鍵，不管是後面的MapReduce計算框架還是MPP計算框架，都是在這一背景下產生的。

greenplum的資料庫引擎是基於postgresql的，並且通過Interconnnect神器實現了對同一個集群中多個Postgresql實例的高效協同和並行計算。
同時，基於greenplum的數據分析平台建設，可以實現兩個層面的處理，顯而易見的一個是對數據處理性能的處理，greenplum的百科中宣稱支援50PB級海量大數據分析處理，考慮它有吹牛的成分，對目前greenplum實際應用情況的了解，100tb級左右的數據，是非常輕鬆的。另一個是數據倉庫可以搭建在greenplum中，這一層面上也是對業務邏輯的梳理，對公司業務數據的整合。

優點：

• 海量數據的支援，大量成熟的大數據應用案例，所以我想這一點是不用懷疑的。
• 擴展性，據說可線性擴展到10000個節點，並且每增加一個節點，查詢、載入性能都成線性增長。
• 易用性，不需要複雜的調優需求，並行處理由系統自動完成。依然是sql作為交語言，簡單、靈活、強大。
• 高級功能，greenplum還研發了很多高級數據分析管理功能，例如人氣很高的外部表，還有Primary/Mirror鏡像保護機制，列／欄混合儲存等。
• 穩定性，greenplum原本作為一個純商業數據產品，具有很長的歷史，其穩定性相比於其他產品以及敏捷性數據集市是更加有保障的。greenplum有非常多的應用案例，納斯達克、紐約證券交易所、平安銀行、建設銀行、華為等都建立了基於greenplum的數據分析平台。其穩定性是可以從側面驗證的，在15年9月份開源後，各大網際網路公司也是一片歡騰，現在也接觸了幾家在使用greenplum的客戶，對其評價都很高。

缺點：

• 本身來說，它的定位在olap領域，不擅長oltp交易系統。當然我們搭建公司的數據中心也不會是用來做交易系統的。
• 成本，兩個方面的考慮，一是硬體成本，greenplum有其推薦的硬體規格，對內存、網卡都有要求。當然，在硬體選型上，需要達到一個平衡，要在性能、容量、成本等多方面考慮，畢竟不能一味的追求性能，把採購部門嚇到吧。另一個是實施成本，這裡主要是人了，基本的是greenplum的安裝配置，再到greenplum中數據倉庫的構建，都需要人和時間。（但是必須要說的是，人家軟體都開源了，也省下了一筆錢啊）
  技術門檻，這裡是相對於上一個敏捷型數據集市的，greenplum的門檻肯定是要高一點了。

4.hadoop分布式系統架構

關於hadoop，已經火的要爆炸了，greenplum的開源跟它也是脫不了關係的。有著高可靠性、高擴展性、高效性、高容錯性的口碑。在網際網路領域有非常廣泛的運用，雅虎、facebook、百度、淘寶等等等等。hadoop生態體系非常龐大，各公司基於hadoop所實現的也不僅限於數據分析，也包括機器學習、數據挖掘、實時系統等。

當企業數據規模達到一定的量級，我想hadoop是各大企業的首選方案，到達這樣一個層次的時候，我想企業所要解決的也不僅是性能問題，還會包括時效問題、更複雜的分析挖掘功能的實現等。非常典型的實時計算體系也與hadoop這一生態體系有著緊密的聯繫。
近些年來hadoop的易用性也有了很大的提升，sql-on-hadoop技術大量湧現，包括hive、impala、spark-sql等。儘管其處理方式不同，但普遍相比於原始基於文件的Mapreduce，不管是性能還是易用性，都是有所提高的。也因此對mpp產品的市場產生了壓力。

對於企業構建數據平台來說，hadoop的優勢與劣勢非常明顯：它的大數據分析處理能力、高可靠性、高容錯性、開源性以及低成本（為什麼說低成本，要處理同樣規模的數據，換一個其他方案試試呢）。缺點也就是他的體系的複雜，技術門檻較高（能搞定hadoop的公司規模一般都不小了）。
關於hadoop的優缺點對於公司的數據平台選型來說，影響已經不大了。需要上hadoop的時候，也沒什麼其它的方案好選擇（要麼太貴，要麼不行），沒到達這個數據量的時候，也沒人願意碰這東西。總之，不要為了大數據而大數據。

三、數據方案很多，企業要怎樣選擇呢？

環境太複雜，但是我想至少要從下面這幾個方面去考慮吧。

1.目的：什麼樣的目的？

就是文中開始部分的三種情況呀（不好意思，自大了，肯定有其它情況，歡迎補充），或者是其中幾個的組合。
做事方法都一樣，哪怕是中午出去吃飯，也是要在心裡有個目的，這頓飯是為了吃飽，還是吃爽，或者為了拍別人的馬屁，然後才好選擇去吃什麼。
當然，要明確數據平台的建設目的，哪裡是那麼容易的，初衷與討論後確認的目標或許是不一致的。

公司要搭建一個數據平台的初衷可能很簡單，只是為了減輕業務系統的壓力，將數據拉出來後再分析，如果目的真的就這麼單純，還真的沒有必要大動干戈了。如果是獨立系統的話，直接將業務系統的資料庫複製出來一份就好了；如果是多系統，選類似finecube那種型敏捷型的商業數據產品也夠了，快速建模，直接用finebi商業智慧或者finereport報表工具接入進去就能實現資料視覺化與olap分析。

但是，既然已經決定要將數據平台獨立出來了，就不再多考慮一點嗎？多個系統的數據，不趁機梳理整合一下？當前只有分析業務數據的需求，以後會不會考慮到歷史數據呢？這種敏捷的方案能夠支撐明年、後年的需求嗎？
任何公司要搭建數據平台，都不是一件小事，多花一兩個月實施你可能覺得累，多花一周兩周的時間，認真的思考一下總可以的吧。雷軍不是說過這樣一句話：不能以戰術上的勤奮，掩蓋戰略上的懶惰。

2.數據量：

根據公司的數據規模選擇合適的方案，這裡說多了都是廢話。

3.成本：

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

關於方案選擇的建議，舉以下3+1個場景

• 場景a：
  要實現對業務數據的快速提取和分析，多個業務系統，沒有達到海量數據，不考慮歷史數據，不需要依照業務邏輯對數據進行系統的梳理，這種情況下，可以考慮敏捷型的bi系統工具自帶的數據底層。
  簡單來講，這種場景僅僅是在技術層面上，完成對數據的整合與提速，並沒有從業務層面上對數據進行建模。他可以滿足一定的數據分析需求，但是不能成為公司的數據中心。
• 場景b：
  要搭建公司級的數據中心，打通各系統之間的數據。非常明顯的，需要搭建一個數據倉庫。這時就需要進一步考慮公司數據的量級了，如果是小數據量，TB級以下，那麼在傳統資料庫中建這樣一個數據倉庫就可以了，如果數據量達到幾十上百TB，或者可見的在未來幾年內數據會達到這樣一個規模，可以將倉庫搭在greenplum中。這種場景應該是適用於大部分公司，對於大部分企業來說，數據量都不會PB級別，更多的是在TB級以下。
• 場景c：
  公司數據爆髮式增長，原有的數據平台無法承擔海量大數據分析處理，那麼就建議考慮hadoop這種大數據平台了。它一定是公司的數據中心，這樣一個角色，倉庫是少不了的，可以將原來的倉庫直接搬到hive中去。這種數據量比較大的情況要怎樣呈現，因為hive的性能較差，它的即席查詢可以接impala，也可以接greenplum，因為impala的並發量不是那麼高，而greenplum正好有它的外部表（也就是greenplum創建一張表，表的特性叫做外部表，讀取的內容是hadoop的hive里的），正好和hadoop完美的融合（當然也可以不用外部表）。
• 場景d：
  這個是後面補充的，當公司原本有一個數據倉庫，但歷史數據了堆積過多，分析性能下降，要怎麼辦？兩個方案可以考慮，比較長遠的，可以將倉庫以及數據遷移到greenplum中，形成一個新的數據平台，一個獨立的數據平台，可以產生更多的可能性；比較快速的，是可以將類似finecube那種敏捷型數據產品接入原來的倉庫，這樣來提升數據的處理性能，滿足分析的要求。

四、關於方案選型時可能會出現的誤區

忽略業務的複雜性，要用工具來解決或者是繞開業務的邏輯。

這個是我最近遇到過的，客戶要做報表平台，有三個業務系統的數據需要整合。但是急於變現，不想搭建傳統的數據倉庫，所以從敏捷型的bi系統工具中選型。工具廠商對自己數據產品的描述，一般著重於他的快速實施、性能的優化、以及自帶的基本etl功能。這樣容易給客戶造成誤區，就是通過這一產品可快速搭建出一個公司級別的數據中心，滿足於頂層對數據的需求。

然而在後期突然意識到，工具所解決的，僅僅是在技術層面上簡化了工具的使用的複雜性，把etl和數據集市封裝在一起，並且提高了數據的性能，但是並沒有從業務層面上實現數據的建模，很多細節問題無法處理。

雖然敏捷開發非常誘人，如果業務系統簡單，或者只需要分析當前狀態的業務數據，不需要公司級的數據中心，那麼確實是一個非常好的方案。然而這些問題還沒有考慮清楚，對敏捷產品有了過高的期望，後面是會遇到些麻煩的。

除此之外，可能還會有為了大數據而大數據的，但是這些我在實際的工作中還沒有遇到。

最後總結一下，企業選擇數據平台的方案，有著不同的原因，要合理的選型，既要充分的考慮搭建數據平台的目的，也要對各種方案有著充分的認識。
僅從個人的角度，對於數據層面來說，還是傾向於一些靈活性很強的方案的，因為數據中心對於公司來說太重要了，我更希望它是透明的，是可以被自己完全掌控的，這樣才有能力實現對數據中心更加充分的利用。因為，我不知道未來需要它去承擔一個什麼樣的角色。

ps：數據平台的建設，是一個不小的專案，實施周期過長，會不會途中夭折？這鍋誰都不想背，這樣的專案，怎樣才能迭代起來，逐步實施逐步投放？我先把問題放在這，呵呵。

作者：帆軟網際網路行業高級顧問王佳東

喜歡這篇文章嗎？歡迎分享按讚，給予我們支持和鼓勵！