業務運行良好，系統運行穩定。為什麽要為企業搭建數據平臺？
這樣的問題就在腦子裏想想，不要大聲問出來。我直接回答，公司壹般在什麽情況下需要搭建壹個數據平臺來重構各種數據。
從業務角度來看:
1，業務系統太多，彼此的數據沒有打通。在這種情況下，涉及到數據分析就比較麻煩，分析師可能需要從多個系統中提取數據，然後將數據整合後再進行分析。壹兩次我還能忍。我能忍受每天這樣做嗎？如何控制人工積分的高錯誤率？分析不及時，效率低。妳想處理嗎？
從系統的角度來看:
2.業務系統壓力很大，但遺憾的是，數據分析是壹項耗費資源的工作。那麽自然會想到，通過提取數據，由壹個獨立的服務器來處理數據查詢和分析任務，來釋放業務系統的壓力。
3，業績問題，公司可以越做越大，同樣的數據也會越做越大。可能是歷史數據的積累，也可能是新數據內容的加入。當原有的數據平臺無法處理更多的數據，或者效率已經很低的時候，就需要重新構建壹個大數據處理平臺。
以上我列舉了三種情況，但都不是獨立的，往往是兩種甚至三種同時出現。壹個數據平臺的出現，既可以承擔數據分析的壓力，又可以整合業務數據，還可以不同程度地提升數據處理的性能，從而基於數據平臺實現更豐富的功能需求。
二、數據平臺建設有哪些方案？
下面的優劣只是從企業選擇的角度，而不是方案本身的技術角度。
如果用壹個字來回答，那就是:太多了(這是廢話，我承認)，但是確實有很多選項可以選擇，而我所知甚少，所以不能壹壹介紹，所以我分為以下幾類，相信壹定程度上涵蓋了大部分企業的需求。
1，常規數據倉庫:
忘了這個概念。既然妳是做數據生意的，相信妳比我更清楚。如果不清楚，可以去百度。它的重點是數據集成，也是業務邏輯的梳理。雖然也可以像ssas壹樣封裝成立方體來提高數據的讀取性能，但是數據倉庫的作用更多的是解決公司的業務問題而不僅僅是性能問題。這壹點後面會詳細介紹。
關於這個方案的優缺點，直接了當地說:
優勢:
方案比較成熟，數據倉庫的架構，無論是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還開發了很多高級的數據分析和管理功能，比如流行的外部表、主/鏡像保護機制、行/列混合存儲等等。
穩定性，greenplum作為純商業數據產品，歷史悠久，穩定性比其他產品和敏捷數據集市更有保障。Greenplum有很多應用案例，納斯達克、紐交所、平安銀行、建設銀行、華為都建立了基於greenplum的數據分析平臺。從側面可以驗證它的穩定性。65438+2005年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的性能差，它的ad hoc查詢可以用impala或者greenplum連接，因為impala的並發沒有那麽高，greenplum只是有它的外部表(就是greenplum創建壹個表，表的特性叫做外部表，讀取的內容在hadoop的hive裏)，這就和hadoop完美的集成了(當然不壹定要用外部表)。
場景d:
這是後面加上的。公司本來有數據倉庫，但是歷史數據積累過多，分析性能下降，怎麽辦？可以考慮兩種方案。從長遠來看，可以將倉庫和數據遷移到greenplum，形成新的數據平臺和獨立的數據平臺，可以產生更多的可能性。像finecube這樣更快、更敏捷的數據產品可以連接到原有的倉庫，從而提高數據處理性能，滿足分析需求。
四、關於方案選擇中可能出現的誤區。
忽略業務的復雜性，用工具解決或者繞過業務邏輯。)
這是我最近遇到的。客戶想做報表平臺，需要整合三個業務系統的數據。但是急於變現，不想建立傳統的數據倉庫，所以選擇敏捷bi工具。對工具廠商數據產品的描述壹般側重於其快速實現、性能優化和基本etl功能。這很容易給客戶造成誤解，即通過該產品可以快速搭建公司級數據中心，滿足頂層數據需求。
但是到了後期，我突然意識到，工具所解決的只是在技術層面上簡化了使用工具的復雜性，把etl和數據集市封裝在壹起，提高了數據的性能，而並沒有實現業務層面的數據建模，很多細節無法處理。
敏捷開發雖然很吸引人，但是如果業務系統比較簡單，或者只需要分析當前的業務數據而沒有公司級的數據中心，確實是非常好的解決方案。但是這些問題沒有考慮清楚，妳對敏捷產品期望過高，以後會遇到壹些麻煩。
另外，可能會有為了大數據而大數據，但我在實際工作中沒有遇到過這些。
最後，綜上所述，企業選擇數據平臺的方案有不同的原因。要做出合理的選擇，必須充分考慮建設數據平臺的目的，充分了解各種方案。
從個人角度來說，至於數據層面，我還是傾向於壹些靈活的解決方案，因為數據中心對於公司來說太重要了，我希望它是透明的，可以完全由自己掌控，這樣我就可以充分利用數據中心。因為，我不知道它未來需要扮演什麽樣的角色。
希望能幫到妳，希望采納。