為何而搭建資料平臺
業務跑的好好的， 各系統穩定運行， 為何還要搭建企業的資料平臺?這樣的問題， 心裡想想就可以了， 不要大聲問出來。 我來直接回答一下， 公司一般在什麼情況下需要搭建資料平臺， 對各種資料進行重新架構。
從業務上的視角來看：
1.業務系統過多， 彼此的資料沒有打通。 這種情況下， 涉及到資料分析就麻煩了， 可能需要分析人員從多個系統中提取資料， 再進行資料整合， 之後才能分析。 一次兩次可以忍， 天天干這個能忍嗎?人為整合出錯率高怎麼控制?分析不及時效率低要不要處理?
從系統的視角來看：
2.業務系統壓力大， 而不巧， 資料分析又是一項比較費資源的任務。 那麼自然會想到的， 通過將資料抽取出來， 獨立伺服器來處理資料查詢、分析任務， 來釋放業務系統的壓力。
3.性能問題， 公司可以越做越大， 同樣的資料也會越來越大。
上面我列出了三種情況， 但他們並非獨立的， 往往是其中兩種甚至三種情況同時出現。 一個資料平臺的出現， 不僅可以承擔資料分析的壓力， 同樣可以對業務資料進行整合， 也會不同程度的提高資料處理的性能， 基於資料平臺實現更豐富的功能需求。
2、資料平臺的建設有哪些方案可以選擇
(下文中的優缺點僅從企業選型的角度， 並非方案本身的技術角度)
如果一句話回答的話， 有非常多的方案可供選擇， 所以就分成了下面幾類，
常規資料倉庫
概念不說了， 既然是做資料這一行的， 相信你比我還要清楚， 不清楚的可以百度。 它的重點在於資料整合， 同時也是對業務邏輯的一個梳理。 雖然它也可以打包成saas那種cube一類的東西來提升資料的讀取性能， 但是資料倉庫的作用， 更多的是為了解決公司的業務問題， 而不僅僅是性能問題。 這一點後面會詳細介紹。 關於這一方案的優缺點， 不寫沒用的， 直接說重點了：
優點
方案成熟， 關於資料倉庫的架構， 不管是Inmon架構還是Kimball架構， 都有著非常廣泛的應用， 而且相信能將這兩種架構落地的人也不少。
實施簡單， 涉及的技術層面主要是倉庫的建模以及etl的處理，
靈活性強， 說這句話要有對應場景的， 資料倉庫的建設是透明的， 如果需要， 可以對倉庫的模型、etl邏輯進行修改， 來滿足變更的需求(當然， 最好設計之初考慮的周全一點)。 同時對於上層的分析而言， 通過sql或者mdx對倉庫資料的分析處理具備極強的靈活性。
缺點
“實施週期長”， 注意， 我加了引號， 對應下面的敏捷型資料集市， 而且這點是相對的， 實施週期的長與短要取決於業務邏輯的複雜性， 時間是花在了業務邏輯的梳理， 並非技術上的瓶頸。 關於這點， 後面會詳細介紹。
資料的處理能力有限， 這個有限， 也是相對的，
商業敏捷型資料集市
底層的資料產品與分析層綁定， 使得應用層可以直接對底層資料產品中的資料進行拖拽式分析。 這一類產品的出現， 其初衷是為了對業務資料進行簡單的、快速的整合， 實現敏捷建模， 並且大幅提升資料的處理速度。 目前來看， 這些產品都達到了以上的目的。 但它的優缺點也比較明顯。
優點
部署簡單， 敏捷開發， 這也是這類產品最大的優點， 和資料倉庫相比， 實施週期要短的多。 實際上它也沒什麼嚴格的實施的概念， 因為這類產品只是針對需要分析的資料，進行局部的關聯，只考慮眼前要解決的問題就夠了，反覆運算的能力更強些。與上層的分析工具結合較好，上層的分析工具接入這類資料產品後，可直接實現資料的圖形化展示和olap分析。
對資料處理性能的提高，這類產品都對資料的分析性能做了處理，雖然方式不盡相同，有記憶體映射檔存儲的，也有分散式架構、列資料存儲的。但無疑都一定程度上提高了資料的處理性能。
缺點
首先，它是要收費的。無法處理複雜的業務邏輯，這只是一個工具，它無法解決業務問題。這類工具中自帶簡單的etl功能，實現簡單的資料處理和整合，而如果考慮到歷史資料，考慮到整體的資料之間的邏輯和關係，它一定是解決不了的。一個簡單的例子，當某個表中，有兩個欄位，一個要保留歷史資料，一個要更新歷史資料，要怎樣實現自動處理。有一個觀念是需要清楚的，不能指望一款工具來解決業務問題。這種資料產品僅僅是對當前的業務資料進行簡單的整合，第一，資料是局部的，第二，時間是當前的(其涵帶的增量更新或者全量更新，是無法應對複雜的邏輯的，相信熟悉etl的人都知道這個過程有多複雜)。當然，對於一些公司來說，可能需求只是對當前業務資料進行整合分析，那麼這類產品就夠了。
靈活性低，這個也是沒法避免的，越是操作簡單的工具，他的靈活性肯定受限，因為封裝住了，產品是不透明的，常規的需求用起來非常方便，但是遇到複雜的，發現對他內部不瞭解，你也沒法修改，只有蛋疼的份。
從我的角度看，它是很難成為公司的資料中心的。
(大規模並行處理)架構的資料產品
傳統的主機計算模式在海量資料面前，顯得弱勢力但造價非常昂貴，同時技術上也無法滿足高性能的計算，smp架構難於擴展，在獨立主機的cpu計算和io吞吐上，都沒辦法滿足海量資料計算的需求。分散式存儲和分散式運算正是解決這一問題的關鍵，不管是後面的MapReduce計算框架還是並行處理計算框架，都是在這一背景下產生的。
優點
海量資料的支援，大量成熟的應用案例，所以我想這一點是不用懷疑的。擴展性，據說可線性擴展到10000個節點，並且每增加一個節點，查詢、載入性能都成線性增長。易用性，不需要複雜的調優需求，並行處理由系統自動完成。依然是sql作為交語言，簡單、靈活、強大。
缺點
本身來說，它的定位在olap領域，不擅長oltp交易系統。當然我們搭建公司的資料中心也不會是用來做交易系統的。
成本，兩個方面的考慮，一是硬體成本，對記憶體、網卡都有要求。當然，在硬體選型上，需要達到一個平衡，要在性能、容量、成本等多方面考慮，畢竟不能一味的追求性能，把採購部門嚇到吧。另一個是實施成本，這裡主要是人了，安裝配置，再到資料倉庫的構建，都需要人和時間。(但是必須要說的是，人家軟體都開源了，也省下了一筆錢啊)
技術門檻，這裡是相對於上一個敏捷型資料集市的，greenplum的門檻肯定是要高一點了。
hadoop分散式系統架構
關於hadoop，greenplum的開源跟它也是脫不了關係的。有著高可靠性、高擴展性、高效性、高容錯性的口碑。在互聯網領域有非常廣泛的運用，雅虎、facebook、百度、淘寶等等等等。hadoop生態體系非常龐大，各公司基於hadoop所實現的也不僅限於資料分析，也包括機器學習、資料採擷、即時系統等。當企業資料規模達到一定的量級，我想hadoop是各大企業的首選方案，到達這樣一個層次的時候，我想企業所要解決的也不僅是性能問題，還會包括時效問題、更複雜的分析挖掘功能的實現等。非常典型的即時計算體系也與hadoop這一生態體系有著緊密的聯繫。
近些年來hadoop的易用性也有了很大的提升，sql-on-hadoop技術大量湧現，包括hive、impala、spark-sql等。儘管其處理方式不同，但普遍相比於原始基於檔的Mapreduce，不管是性能還是易用性，都是有所提高的。也因此對第三類產品的市場產生了壓力。
對於企業構建資料平臺來說，hadoop的優勢與劣勢非常明顯：它的大資料的處理能力、高可靠性、高容錯性、開源性以及低成本(為什麼說低成本，要處理同樣規模的資料，換一個其他方案試試呢)。缺點也就是他的體系的複雜，技術門檻較高(能搞定hadoop的公司規模一般都不小了)。
關於hadoop的優缺點對於公司的資料平臺選型來說，影響已經不大了。需要上hadoop的時候，也沒什麼其它的方案好選擇(要麼太貴，要麼不行)，沒到達這個資料量的時候，也沒人願意碰這東西。總之，不要為了大資料而大資料。
3、方案很多，企業要怎樣選擇呢
環境太複雜，但是我想至少要從下面這幾個方面去考慮吧。
目的
就是文中開始部分的三種情況，或者是其中幾個的組合。做事方法都一樣，哪怕是中午出去吃飯，也是要在心裡有個目的，這頓飯是為了吃飽，還是吃爽，或者為了拍別人的馬屁，然後才好選擇去吃什麼。當然，要明確資料平臺的建設目的，哪裡是那麼容易的，初衷與討論後確認的目標或許是不一致的。公司要搭建一個資料平臺的初衷可能很簡單，只是為了減輕業務系統的壓力，將資料拉出來後再分析，如果目的真的就這麼單純，還真的沒有必要大動干戈了。如果是獨立系統的話，直接將業務系統的資料庫複製出來一份就好了;如果是多系統，選類似finecube那種型敏捷型的商業資料產品也夠了，快速建模，直接用finebi或者finereport接入進去就能實現資料的視覺化與olap分析。
但是，既然已經決定要將資料平臺獨立出來了，就不再多考慮一點嗎?多個系統的資料，不趁機梳理整合一下?當前只有分析業務資料的需求，以後會不會考慮到歷史資料呢?這種敏捷的方案能夠支撐明年、後年的需求嗎?
任何公司要搭建資料平臺，都不是一件小事，多花一兩個月實施你可能覺得累，多花一周兩周的時間，認真的思考一下總可以的吧。雷軍不是說過這樣一句話：不能以戰術上的勤奮，掩蓋戰略上的懶惰。
資料量
根據公司的資料規模選擇合適的方案，這裡說多了都是廢話。
成本
包括時間成本和金錢，不必多說。但是這裡有一個問題想提一下，發現很多公司，要麼不上資料平臺，一旦有了這樣的計畫，就恨不得馬上把平臺搭出來用起來，時間成本不肯花，這樣的情況很容易考慮欠缺，也容易被資料實施方忽悠。
關於方案選擇的建議，舉以下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那種敏捷型資料產品接入原來的倉庫，這樣來提升資料的處理性能，滿足分析的要求。
4、關於方案選型時可能會出現的誤區
忽略業務的複雜性，要用工具來解決或者是繞開業務的邏輯。這個是我最近遇到過的，客戶要做報表平臺，有三個業務系統的資料需要整合。但是急於變現，不想搭建傳統的資料倉庫，所以從敏捷型的bi工具中選型。工具廠商對自己資料產品的描述，一般著重於他的快速實施、性能的優化、以及自帶的基本etl功能。這樣容易給客戶造成誤區，就是通過這一產品可快速搭建出一個公司級別的資料中心，滿足於頂層對資料的需求。然而在後期突然意識到，工具所解決的，僅僅是在技術層面上簡化了工具的使用的複雜性，把etl和資料集市封裝在一起，並且提高了資料的性能，但是並沒有從業務層面上實現資料的建模，很多細節問題無法處理。
雖然敏捷開發非常誘人，如果業務系統簡單，或者只需要分析當前狀態的業務資料，不需要公司級的資料中心，那麼確實是一個非常好的方案。然而這些問題還沒有考慮清楚，對敏捷產品有了過高的期望，後面是會遇到些麻煩的。除此之外，可能還會有為了大資料而大資料的，但是這些我在實際的工作中還沒有遇到。
最後總結一下，企業選擇資料平臺的方案，有著不同的原因，要合理的選型，既要充分的考慮搭建資料平臺的目的，也要對各種方案有著充分的認識。
因為這類產品只是針對需要分析的資料，進行局部的關聯，只考慮眼前要解決的問題就夠了，反覆運算的能力更強些。與上層的分析工具結合較好，上層的分析工具接入這類資料產品後，可直接實現資料的圖形化展示和olap分析。對資料處理性能的提高，這類產品都對資料的分析性能做了處理，雖然方式不盡相同，有記憶體映射檔存儲的，也有分散式架構、列資料存儲的。但無疑都一定程度上提高了資料的處理性能。
缺點
首先，它是要收費的。無法處理複雜的業務邏輯，這只是一個工具，它無法解決業務問題。這類工具中自帶簡單的etl功能，實現簡單的資料處理和整合，而如果考慮到歷史資料，考慮到整體的資料之間的邏輯和關係，它一定是解決不了的。一個簡單的例子，當某個表中，有兩個欄位，一個要保留歷史資料，一個要更新歷史資料，要怎樣實現自動處理。有一個觀念是需要清楚的，不能指望一款工具來解決業務問題。這種資料產品僅僅是對當前的業務資料進行簡單的整合，第一，資料是局部的，第二，時間是當前的(其涵帶的增量更新或者全量更新，是無法應對複雜的邏輯的，相信熟悉etl的人都知道這個過程有多複雜)。當然，對於一些公司來說，可能需求只是對當前業務資料進行整合分析，那麼這類產品就夠了。
靈活性低，這個也是沒法避免的，越是操作簡單的工具，他的靈活性肯定受限，因為封裝住了，產品是不透明的，常規的需求用起來非常方便，但是遇到複雜的，發現對他內部不瞭解，你也沒法修改，只有蛋疼的份。
從我的角度看，它是很難成為公司的資料中心的。
(大規模並行處理)架構的資料產品
傳統的主機計算模式在海量資料面前，顯得弱勢力但造價非常昂貴，同時技術上也無法滿足高性能的計算，smp架構難於擴展，在獨立主機的cpu計算和io吞吐上，都沒辦法滿足海量資料計算的需求。分散式存儲和分散式運算正是解決這一問題的關鍵，不管是後面的MapReduce計算框架還是並行處理計算框架，都是在這一背景下產生的。
優點
海量資料的支援，大量成熟的應用案例，所以我想這一點是不用懷疑的。擴展性，據說可線性擴展到10000個節點，並且每增加一個節點，查詢、載入性能都成線性增長。易用性，不需要複雜的調優需求，並行處理由系統自動完成。依然是sql作為交語言，簡單、靈活、強大。
缺點
本身來說，它的定位在olap領域，不擅長oltp交易系統。當然我們搭建公司的資料中心也不會是用來做交易系統的。
成本，兩個方面的考慮，一是硬體成本，對記憶體、網卡都有要求。當然，在硬體選型上，需要達到一個平衡，要在性能、容量、成本等多方面考慮，畢竟不能一味的追求性能，把採購部門嚇到吧。另一個是實施成本，這裡主要是人了，安裝配置，再到資料倉庫的構建，都需要人和時間。(但是必須要說的是，人家軟體都開源了，也省下了一筆錢啊)
技術門檻，這裡是相對於上一個敏捷型資料集市的，greenplum的門檻肯定是要高一點了。
hadoop分散式系統架構
關於hadoop，greenplum的開源跟它也是脫不了關係的。有著高可靠性、高擴展性、高效性、高容錯性的口碑。在互聯網領域有非常廣泛的運用，雅虎、facebook、百度、淘寶等等等等。hadoop生態體系非常龐大，各公司基於hadoop所實現的也不僅限於資料分析，也包括機器學習、資料採擷、即時系統等。當企業資料規模達到一定的量級，我想hadoop是各大企業的首選方案，到達這樣一個層次的時候，我想企業所要解決的也不僅是性能問題，還會包括時效問題、更複雜的分析挖掘功能的實現等。非常典型的即時計算體系也與hadoop這一生態體系有著緊密的聯繫。
近些年來hadoop的易用性也有了很大的提升，sql-on-hadoop技術大量湧現，包括hive、impala、spark-sql等。儘管其處理方式不同，但普遍相比於原始基於檔的Mapreduce，不管是性能還是易用性，都是有所提高的。也因此對第三類產品的市場產生了壓力。
對於企業構建資料平臺來說，hadoop的優勢與劣勢非常明顯：它的大資料的處理能力、高可靠性、高容錯性、開源性以及低成本(為什麼說低成本，要處理同樣規模的資料，換一個其他方案試試呢)。缺點也就是他的體系的複雜，技術門檻較高(能搞定hadoop的公司規模一般都不小了)。
關於hadoop的優缺點對於公司的資料平臺選型來說，影響已經不大了。需要上hadoop的時候，也沒什麼其它的方案好選擇(要麼太貴，要麼不行)，沒到達這個資料量的時候，也沒人願意碰這東西。總之，不要為了大資料而大資料。
3、方案很多，企業要怎樣選擇呢
環境太複雜，但是我想至少要從下面這幾個方面去考慮吧。
目的
就是文中開始部分的三種情況，或者是其中幾個的組合。做事方法都一樣，哪怕是中午出去吃飯，也是要在心裡有個目的，這頓飯是為了吃飽，還是吃爽，或者為了拍別人的馬屁，然後才好選擇去吃什麼。當然，要明確資料平臺的建設目的，哪裡是那麼容易的，初衷與討論後確認的目標或許是不一致的。公司要搭建一個資料平臺的初衷可能很簡單，只是為了減輕業務系統的壓力，將資料拉出來後再分析，如果目的真的就這麼單純，還真的沒有必要大動干戈了。如果是獨立系統的話，直接將業務系統的資料庫複製出來一份就好了;如果是多系統，選類似finecube那種型敏捷型的商業資料產品也夠了，快速建模，直接用finebi或者finereport接入進去就能實現資料的視覺化與olap分析。
但是，既然已經決定要將資料平臺獨立出來了，就不再多考慮一點嗎?多個系統的資料，不趁機梳理整合一下?當前只有分析業務資料的需求，以後會不會考慮到歷史資料呢?這種敏捷的方案能夠支撐明年、後年的需求嗎?
任何公司要搭建資料平臺，都不是一件小事，多花一兩個月實施你可能覺得累，多花一周兩周的時間，認真的思考一下總可以的吧。雷軍不是說過這樣一句話：不能以戰術上的勤奮，掩蓋戰略上的懶惰。
資料量
根據公司的資料規模選擇合適的方案，這裡說多了都是廢話。
成本
包括時間成本和金錢，不必多說。但是這裡有一個問題想提一下，發現很多公司，要麼不上資料平臺，一旦有了這樣的計畫，就恨不得馬上把平臺搭出來用起來，時間成本不肯花，這樣的情況很容易考慮欠缺，也容易被資料實施方忽悠。
關於方案選擇的建議，舉以下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那種敏捷型資料產品接入原來的倉庫，這樣來提升資料的處理性能，滿足分析的要求。
4、關於方案選型時可能會出現的誤區
忽略業務的複雜性，要用工具來解決或者是繞開業務的邏輯。這個是我最近遇到過的，客戶要做報表平臺，有三個業務系統的資料需要整合。但是急於變現，不想搭建傳統的資料倉庫，所以從敏捷型的bi工具中選型。工具廠商對自己資料產品的描述，一般著重於他的快速實施、性能的優化、以及自帶的基本etl功能。這樣容易給客戶造成誤區，就是通過這一產品可快速搭建出一個公司級別的資料中心，滿足於頂層對資料的需求。然而在後期突然意識到，工具所解決的，僅僅是在技術層面上簡化了工具的使用的複雜性，把etl和資料集市封裝在一起，並且提高了資料的性能，但是並沒有從業務層面上實現資料的建模，很多細節問題無法處理。
雖然敏捷開發非常誘人，如果業務系統簡單，或者只需要分析當前狀態的業務資料，不需要公司級的資料中心，那麼確實是一個非常好的方案。然而這些問題還沒有考慮清楚，對敏捷產品有了過高的期望，後面是會遇到些麻煩的。除此之外，可能還會有為了大資料而大資料的，但是這些我在實際的工作中還沒有遇到。
最後總結一下，企業選擇資料平臺的方案，有著不同的原因，要合理的選型，既要充分的考慮搭建資料平臺的目的，也要對各種方案有著充分的認識。