公司要做數據分析，首先要考慮數據的準備，也就是數據平臺的建設，最近接觸了幾個朋友都處於這一環節，而且其中一個在方案選型過程中，也是充滿了糾結，而我也並沒有在開始階段給出合理全面的建議。
所以根據自己的認知整理了這篇文章，一是對自己的整理，二是希望通過分享，給大家一些參考的價值。
一、爲何而搭建數據平臺
業務跑的好好的，各系統穩定運行，爲何還要搭建企業的數據平臺？
這樣的問題，心裏想想就可以了，不要大聲問出來。我來直接回答一下，公司一般在什麼情況下需要搭建數據平臺，對各種數據進行重新架構。
從業務上的視角來看：
1.業務系統過多，彼此的數據沒有打通。這種情況下，涉及到數據分析就麻煩了，可能需要分析人員從多個系統中提取數據，再進行數據整合，之後才能分析。一次兩次可以忍，天天干這個能忍嗎？人爲整合出錯率高怎麼控制？分析不及時效率低要不要處理？
從系統的視角來看：
2.業務系統壓力大，而不巧，數據分析又是一項比較費資源的任務。那麼自然會想到的，通過將數據抽取出來，獨立服務器來處理數據查詢、分析任務，來釋放業務系統的壓力。
3.性能問題，公司可以越做越大，同樣的數據也會越來越大。可能是歷史數據的積累，也可能是新數據內容的加入，當原始數據平臺不能承受更大數據量的處理時，或者是效率已經十分低下時，重新構建一個大數據處理平臺就是必須的了。
上面我列出了三種情況，但他們並非獨立的，往往是其中兩種甚至三種情況同時出現。一個數據平臺的出現，不僅可以承擔數據分析的壓力，同樣可以對業務數據進行整合，也會不同程度的提高數據處理的性能，基於數據平臺實現更豐富的功能需求。
二、數據平臺的建設有哪些方案可以選擇
如果一句話回答的話，那就是：太多了（這是一句廢話，我承認），但確實有非常多的方案可供選擇，我懂的少，肯定是無法一一介紹，所以就分成了下面幾類，相信也一定程度上覆蓋了大部分企業的需求了。
1.常規數據倉庫：它的重點在於數據整合，同時也是對業務邏輯的一個梳理。雖然它也可以打包成ssas那種cube一類的東西來提升數據的讀取性能，但是數據倉庫的作用，更多的是爲了解決公司的業務問題，而不僅僅是性能問題。這一點後面會詳細介紹。
2.敏捷型數據集市：
底層的數據產品與分析層綁定，使得應用層可以直接對底層數據產品中的數據進行拖拽式分析。這一類產品的出現，其初衷是爲了對業務數據進行簡單的、快速的整合，實現敏捷建模，並且大幅提升數據的處理速度。
目前來看，這些產品都達到了以上的目的。但它的優缺點也比較明顯,從我的角度看，它是很難成爲公司的數據中心的。
3.MPP(大規模並行處理)架構的數據產品，以最近開源的greenplum爲例。
傳統的主機計算模式在海量數據面前，顯得弱雞。造價非常昂貴，同時技術上也無法滿足高性能的計算，smp架構難於擴展，在獨立主機的cpu計算和io吞吐上，都沒辦法滿足海量數據計算的需求。分佈式存儲和分佈式計算正是解決這一問題的關鍵，不管是後面的MapReduce計算框架還是MPP計算框架，都是在這一背景下產生的。
greenplum的數據庫引擎是基於postgresql的，並且通過Interconnnect神器實現了對同一個集羣中多個Postgresql實例的高效協同和並行計算。
4.hadoop分佈式系統架構
關於hadoop，已經火的要爆炸了，greenplum的開源跟它也是脫不了關係的。有着高可靠性、高擴展性、高效性、高容錯性的口碑。在互聯網領域有非常廣泛的運用，雅虎、facebook、百度、淘寶等等等等。
hadoop生態體系非常龐大，各公司基於hadoop所實現的也不僅限於數據分析，也包括機器學習、數據挖掘、實時系統等。
當企業數據規模達到一定的量級，我想hadoop是各大企業的首選方案，到達這樣一個層次的時候，我想企業所要解決的也不僅是性能問題，還會包括時效問題、更復雜的分析挖掘功能的實現等。非常典型的實時計算體系也與hadoop這一生態體系有着緊密的聯繫。
近些年來hadoop的易用性也有了很大的提升，sql-on-hadoop技術大量涌現，包括hive、impala、spark-sql等。儘管其處理方式不同，但普遍相比於原始基於文件的Mapreduce，不管是性能還是易用性，都是有所提高的。也因此對mpp產品的市場產生了壓力。
對於企業構建數據平臺來說，hadoop的優勢與劣勢非常明顯：它的大數據的處理能力、高可靠性、高容錯性、開源性以及低成本（爲什麼說低成本，要處理同樣規模的數據，換一個其他方案試試呢）。缺點也就是他的體系的複雜，技術門檻較高（能搞定hadoop的公司規模一般都不小了）。
關於hadoop的優缺點對於公司的數據平臺選型來說，影響已經不大了。需要上hadoop的時候，也沒什麼其它的方案好選擇（要麼太貴，要麼不行），沒到達這個數據量的時候，也沒人願意碰這東西。總之，不要爲了大數據而大數據。
三、方案很多，企業要怎樣選擇呢
環境太複雜，但是我想至少要從下面這幾個方面去考慮吧。
1.目的：什麼樣的目的？就是文中開始部分的三種情況，或者是其中幾個的組合。
做事方法都一樣，哪怕是中午出去吃飯，也是要在心裏有個目的，這頓飯是爲了吃飽，還是吃爽，或者爲了拍別人的馬屁，然後纔好選擇去吃什麼。
當然，要明確數據平臺的建設目的，哪裏是那麼容易的，初衷與討論後確認的目標或許是不一致的。
公司要搭建一個數據平臺的初衷可能很簡單，只是爲了減輕業務系統的壓力，將數據拉出來後再分析，如果目的真的就這麼單純，還真的沒有必要大動干戈了。
如果是獨立系統的話，直接將業務系統的數據庫複製出來一份就好了；如果是多系統，快速建模，直接用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：數據平臺的建設，是一個不小的項目，實施週期過長，會不會途中夭折？這鍋誰都不想背，這樣的項目，怎樣才能迭代起來，逐步實施逐步投放？