業務跑的好好的，各系統穩定運行，為何還要搭建企業的數據平臺?
這樣的問題，心裏想想就可以了，不要大聲問出來。我來直接回答壹下，公司壹般在什麽情況下需要搭建數據平臺，對各種數據進行重新架構。
從業務上的視角來看：
1、業務系統過多，彼此的數據沒有打通。這種情況下，涉及到數據分析就麻煩了，可能需要分析人員從多個系統中提取數據，再進行數據整合，之後才能分析。壹次兩次可以忍，天天幹這個能忍嗎?人為整合出錯率高怎麽控制?分析不及時效率低要不要處理?
從系統的視角來看：
2、業務系統壓力大，而不巧，數據分析又是壹項比較費資源的任務。那麽自然會想到的，通過將數據抽取出來，獨立服務器來處理數據查詢、分析任務，來釋放業務系統的壓力。
3、性能問題，公司可以越做越大，同樣的數據也會越來越大。可能是歷史數據的積累，也可能是新數據內容的加入，當原始數據平臺不能承受更大數據量的處理時，或者是效率已經十分低下時，重新構建壹個大數據處理平臺就是必須的了。
上面我列出了三種情況，但他們並非獨立的，往往是其中兩種甚至三種情況同時出現。壹個數據平臺的出現，不僅可以承擔數據分析的壓力，同樣可以對業務數據進行整合，也會不同程度的提高數據處理的性能，基於數據平臺實現更豐富的功能需求。
二、數據平臺的建設有哪些方案可以選擇
下文中的優缺點僅從企業選型的角度，並非方案本身的技術角度。
如果壹句話回答的話，那就是：太多了(這是壹句廢話，我承認)，但確實有非常多的方案可供選擇，我懂的少，肯定是無法壹壹介紹，所以就分成了下面幾類，相信也壹定程度上覆蓋了大部分企業的需求了。
1、 常規數據倉庫：
概念不說了，既然是做數據這壹行的，相信妳比我還要清楚，不清楚的可以百度。它的重點在於數據整合，同時也是對業務邏輯的壹個梳理。雖然它也可以打 包成ssas那種cube壹類的東西來提升數據的讀取性能，但是數據倉庫的作用，更多的是為了解決公司的業務問題，而不僅僅是性能問題。這壹點後面會詳細 介紹。
關於這壹方案的優缺點，直接說重點:
優點：
方案成熟，關於數據倉庫的架構，不管是Inmon架構還是Kimball架構，都有著非常廣泛的應用，而且相信能將這兩種架構落地的人也不少。
實施簡單，涉及的技術層面主要是倉庫的建模以及etl的處理，很多軟件公司具備數據倉庫的實施能力，實施難度的大小更多的取決於業務邏輯的復雜程度，而並非技術上的實現。
靈活性強，說這句話要有對應場景的，數據倉庫的建設是透明的，如果需要，可以對倉庫的模型、etl邏輯進行修改，來滿足變更的需求(當然，最好設計之初考慮的周全壹點)。同時對於上層的分析而言，通過sql或者mdx對倉庫數據的分析處理具備極強的靈活性。
缺點：
“實施周期長”，註意，我加了引號，對應下面的敏捷型數據集市，而且這點是相對的，實施周期的長與短要取決於業務邏輯的復雜性，時間是花在了業務邏輯的梳理，並非技術上的瓶頸。關於這點，後面會詳細介紹。
數據的處理能力有限，這個有限，也是相對的，海量數據的處理它肯定不行，非關系型數據的處理它也不行，但是TB以下級別的數據，還是搞得定的(也取決於所采用的數據庫系統)，這個量級的數據，而相當壹部分企業的數據，還是很難超過這個級別的。
2、 商業敏捷型數據集市：
底層的數據產品與分析層綁定，使得應用層可以直接對底層數據產品中的數據進行拖拽式分析。這壹類產品的出現，其初衷是為了對業務數據進行簡單的、快速的整合，實現敏捷建模，並且大幅提升數據的處理速度。目前來看，這些產品都達到了以上的目的。但它的優缺點也比較明顯。
優點：
部署簡單，敏捷開發，這也是這類產品最大的優點，和數據倉庫相比，實施周期要短的多。實際上它也沒什麽嚴格的實施的概念，因為這類產品只是針對需要分析的數據，進行局部的關聯，只考慮眼前要解決的問題就夠了，叠代的能力更強些。
與上層的分析工具結合較好，上層的分析工具接入這類數據產品後，可直接實現數據的圖形化展示和olap分析。對數據處理性能的提高，這類產品都對 數據的分析性能做了處理，雖然方式不盡相同，有內存映射文件存儲的，也有分布式架構、列數據存儲的。但無疑都壹定程度上提高了數據的處理性能。
缺點：
首先，它是要收費的。
無法處理復雜的業務邏輯，這只是壹個工具，它無法解決業務問題。這類工具中自帶簡單的etl功能，實現簡單的數據處理和整合，而如果考慮到歷史數 據，考慮到整體的數據之間的邏輯和關系，它壹定是解決不了的。壹個簡單的例子，當某個表中，有兩個字段，壹個要保留歷史數據，壹個要更新歷史數據，要怎樣 實現自動處理。有壹個觀念是需要清楚的，不能指望壹款工具來解決業務問題。這種數據產品僅僅是對當前的業務數據進行簡單的整合，第壹，數據是局部的，第 二，時間是當前的(其涵帶的增量更新或者全量更新，是無法應對復雜的邏輯的，相信熟悉etl的人都知道這個過程有多復雜)。當然，對於壹些公司來說，可能 需求只是對當前業務數據進行整合分析，那麽這類產品就夠了。(說實話，很多公司真的是懶得更長遠的考慮，有壹天沒壹天的，誰說的準呢)
l 靈活性低，這個也是沒法避免的，越是操作簡單的工具，他的靈活性肯定受限，因為封裝住了，產品是不透明的，常規的需求用起來非常方便，但是遇到復雜的，發現對他內部不了解，妳也沒法修改，只有蛋疼的份。
從我的角度看，它是很難成為公司的數據中心的。
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、 目的：
什麽樣的目的?就是文中開始部分的三種情況呀(不好意思，自大了，肯定有其它情況，歡迎向“jiago王”補充)，或者是其中幾個的組合。
做事方法都壹樣，哪怕是中午出去吃飯，也是要在心裏有個目的，這頓飯是為了吃飽，還是吃爽，或者為了拍別人的馬屁，然後才好選擇去吃什麽。
當然，要明確數據平臺的建設目的，哪裏是那麽容易的，初衷與討論後確認的目標或許是不壹致的。
公司要搭建壹個數據平臺的初衷可能很簡單，只是為了減輕業務系統的壓力，將數據拉出來後再分析，如果目的真的就這麽單純，還真的沒有必要大動幹戈 了。如果是獨立系統的話，直接將業務系統的數據庫復制出來壹份就好了;如果是多系統，選類似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和數據集市封裝在壹起，並且提高了數據的性能，但是並沒有從業務層面上實現數據的建模，很多細節問題無法處理。
雖然敏捷開發非常誘人，如果業務系統簡單，或者只需要分析當前狀態的業務數據，不需要公司級的數據中心，那麽確實是壹個非常好的方案。然而這些問題還沒有考慮清楚，對敏捷產品有了過高的期望，後面是會遇到些麻煩的。
除此之外，可能還會有為了大數據而大數據的，但是這些我在實際的工作中還沒有遇到。
最後總結壹下，企業選擇數據平臺的方案，有著不同的原因，要合理的選型，既要充分的考慮搭建數據平臺的目的，也要對各種方案有著充分的認識。
僅從個人的角度，對於數據層面來說，還是傾向於壹些靈活性很強的方案的，因為數據中心對於公司來說太重要了，我更希望它是透明的，是可以被自己完全掌控的，這樣才有能力實現對數據中心更加充分的利用。因為，我不知道未來需要它去承擔壹個什麽樣的角色。
希望可以幫助妳，望采納