當前BAT基本公開了其大數據平臺架構，從網上也能查詢到一些資料，關于大數據平臺的各類技術介紹也不少，但在那個機制、那個環(huán)境、那個人才、那個薪酬體系下，對于傳統(tǒng)企業(yè)，可借鑒的東西也是有限的。

技術最終為業(yè)務服務，沒必要一定要追求先進性，各個企業(yè)應根據自己的實際情況去選擇自己的技術路徑。

與傳統(tǒng)的更多從技術的角度來看待大數據平臺架構的方式不同，筆者這次，更多的從業(yè)務的視角來談談關于大數據架構的理解，即更多的會問為什么要采用這個架構，到底能給業(yè)務帶來多大價值，實踐的最終結果是什么。

它不一定具有通用性，但從一定程度講，這個架構可能比BAT的架構更適應大多數企業(yè)的情況，畢竟，大多數企業(yè)，數據沒到那個份上，也不可能完全自研，商業(yè)和開源的結合可能更好一點，權當拋磚引玉。

大數據平臺架構的層次劃分沒啥標準，以前筆者曾經做過大數據應用規(guī)劃，也是非常糾結，因為應用的分類也是橫縱交錯，后來還是覺得體現一個“能用”原則，清晰且容易理解，能指導建設，這里將大數據平臺劃分為“五橫一縱”。

具體見下圖示例，這張圖是比較經典的，也是妥協的結果，跟當前網上很多的大數據架構圖都可以作一定的映射。

何謂五橫，基本還是根據數據的流向自底向上劃分五層，跟傳統(tǒng)的數據倉庫其實很類似，數據類的系統(tǒng)，概念上還是相通的，分別為數據采集層、數據處理層、數據分析層、數據訪問層及應用層。

同時，大數據平臺架構跟傳統(tǒng)數據倉庫有一個不同，就是同一層次，為了滿足不同的場景，會采用更多的技術組件，體現百花齊放的特點，這是一個難點。

數據采集層：既包括傳統(tǒng)的ETL離線采集、也有實時采集、互聯網爬蟲解析等等。

數據處理層：根據數據處理場景要求不同，可以劃分為HADOOP、MPP、流處理等等。

數據分析層：主要包含了分析引擎，比如數據挖掘、機器學習、 深度學習等。

數據訪問層：主要是實現讀寫分離，將偏向應用的查詢等能力與計算能力剝離，包括實時查詢、多維查詢、常規(guī)查詢等應用場景。

數據應用層：根據企業(yè)的特點不同劃分不同類別的應用，比如針對運營商，對內有精準營銷、客服投訴、基站分析等，對外有基于位置的客流、基于標簽的廣告應用等等。

數據管理層：這是一縱，主要是實現數據的管理和運維，它橫跨多層，實現統(tǒng)一管理。

1、數據采集層，這是基礎。

離線批量采集，采用的是HADOOP，這個已經成為當前流線采集的主流引擎了，基于這個平臺，需要部署數據采集應用或工具。

諸如BAT都是自己研發(fā)的產品，一般企業(yè)，可以采用商用版本，現在這類選擇很多，比如華為BDI等等，很多企業(yè)技術實力有，但起步的時候往往對于應用場景的理解比較弱，細節(jié)做工很差，導致做出來的產品難以達到要求，比如缺乏統(tǒng)計功能等，跟BAT差距很大，傳統(tǒng)企業(yè)去采購這類產品，要謹慎小心。

一個建議是，當采購產品的時候，除了技術先進性和指標外，更多的應該問問是版本啥時候上線的，是否在哪里成功部署，是否有足夠多的客戶，如果能做個測試就更好，否則，你就是小白鼠哦，這個坑踩了不少。

能做和做成產品是兩個境界的事情，小的互聯網企業(yè)當然也能做出對于自己好用的采集工具，但它很難抽象并打造出一個真正的產品，BAT自研其實形成了巨大的優(yōu)勢。

實時采集現在也成了大數據平臺的標配，估計主流就是FLUME+KAFKA，然后結合流處理+內存數據庫吧，這個技術肯定靠譜，但這類開源的東西好是好，但一旦出現問題往往解決周期往往比較長。

除了用FLUME，針對ORACLE數據庫的表為了實現實時采集，也可以采用OGG/DSG等技術實現實時的日志采集，可以解決傳統(tǒng)數據倉庫抽全量表的負荷問題。

爬蟲當前也逐漸成為很多企業(yè)的采集標配，因為互聯網新增數據主要靠它，可以通過網頁的解析獲取大量的上網信息，什么輿情分析、網站排名啥的，建議每個企業(yè)都應該建立企業(yè)級的爬蟲中心，如果它未在你的大數據平臺規(guī)劃內，可以考慮一下，能拿的數據都不拿，就沒什么好說了。

企業(yè)級的爬蟲中心的建設難度蠻大，因為不僅僅是需要爬蟲，還需要建立網址和應用知識庫，需要基于網頁文本進行中文分詞，倒排序及文本挖掘等，這一套下來，挑戰(zhàn)很大，當前已經有不少開源組件了，比如solr、lucent、Nutch、ES等等，但要用好它，路漫漫其修遠兮。

還有一個就是，如果有可能，筆者建議將數據采集平臺升級為數據交換平臺，因為其實企業(yè)內有大量的數據流動，不僅僅是單向的數據采集，而且有很多數據交換，比如需要從ORACLE倒數據到GBASE，從HBASE倒數據到ASTER等等，對于應用來講，這個價值很大。

既然數據采集和數據交換有很多功能非常類似，為什么不做整合呢?也便于統(tǒng)一管理，感覺企業(yè)的數據交換大量都是應用驅動，接口管理亂七八糟，這也是我的一個建議。

總得來講，建設大數據采集平臺非常不易，從客戶的角度講，至少要達到以下三個要求：

多樣化數據采集能力：支持對表、文件、消息等多種數據的實時增量數據采集(使用flume、消息隊列、OGG等技術)和批量數據分布式采集等能力(SQOOP、FTP VOER HDFS)，比基于傳統(tǒng)ETL性能有量級上的提升，這是根本。

可視化快速配置能力：提供圖形化的開發(fā)和維護界面，支持圖形化拖拽式開發(fā)，免代碼編寫，降低采集難度，每配置一個數據接口耗時很短，以降低人工成本。

統(tǒng)一調度管控能力：實現采集任務的統(tǒng)一調度，可支持Hadoop的多種技術組件(如 MapReduce、Spark 、HIVE)、關系型數據庫存儲過程、 shell腳本等，支持多種調度策略(時間/接口通知/手工)。

2、數據處理層，現在有個詞叫混搭，的確是這樣。

Hadoop的HIVE是傳統(tǒng)數據倉庫的一種分布式替代。應用在傳統(tǒng)ETL中的數據的清洗、過濾、轉化及直接匯總等場景很適合，數據量越大，它的性價比越高。但目前為止看，其支撐的數據分析場景也是有限的， 簡單的離線的海量分析計算是它所擅長的，相對應的，復雜的關聯交叉運算其速度很慢。

一定程度講，比如企業(yè)客戶統(tǒng)一視圖寬表用HIVE做比較低效，因為涉及到多方數據的整合，但不是不可以做，最多慢點嘛，還是要講究個平衡。

hadoop到了X000臺集群的規(guī)模也撐不住了,當前很多企業(yè)的數據量應該會超過這個數量，除了像阿里等自身有研發(fā)能力的企業(yè)(比如ODPS)，是否也要走向按照業(yè)務拆分Hadoop集群的道路?諸如浙江移動已經拆分了固網、移網、創(chuàng)新等多個hadoop集群。

Hadoop的SPARK的很適合機器學習的迭代，但能否大規(guī)模的應用于數據關聯分析，能否一定程度替代MPP，還需要實踐來驗證。

MPP應該來說，是采用分布式架構對于傳統(tǒng)數據倉庫最好的替代，畢竟其實際上是變了種的關系型數據庫，對于SQL提供完整支持，在HIVE做了轉化分析后，數據倉庫的融合建模用它來做性能綽綽有余，其性價比較傳統(tǒng)DB2更好一點，比如經過實用，Gbase30-40臺集群就能超過2臺頂配的IBM 780。

MPP現在產品很多，很難做優(yōu)劣判斷，但一些實踐結果可以說下，GBASE不錯，公司很多系統(tǒng)已經在上面跑了，主要還是國產的，技術服務保障相對靠譜，ASTER還有待觀望，自帶一些算法庫是有其一些優(yōu)勢，GreenPlum、Vertica沒用過，不好說。

現在有個說法是MPP最終也要被Hadoop那套框架替代，畢竟諸如SPARK啥的都在逐步穩(wěn)定和成熟，但在短期內，我覺得還是很靠譜的，如果數據倉庫要采用漸進的演化方式，MPP的確是很好的選擇。

現在諸如中國移動，eBAY等大量公司都在采用這類混搭結構，以適應不同的應用場景，顯然是一種自然的選擇。

大數據平臺的三駕馬車，少不了流處理。

對于很多企業(yè)來講，其顯然是核武器般的存在，大量的應用場景需要它，因此務必要進行建設，比如在IOE時代不可想象的實時、準實時數據倉庫場景，在流處理那里就變得很簡單了，以前統(tǒng)計個實時指標，也是很痛苦的事情，當前比如反欺詐實時系統(tǒng)，一天系統(tǒng)就申請部署好了。

只嘗試過STORM和IBM STREAM，推薦IBM STREAM，雖然是商業(yè)版本，但其處理能力超過STORM不是一點半點，據說STORM也基本不更新了，但其實數據量不大，用啥都可以，從應用的角度講，諸如IBM這種商業(yè)版本，是不錯的選擇，支撐各類實時應用場景綽綽有余。

流處理集群以流處理技術結合內存數據庫，用以實時及準實時數據處理，基于IBM Streams流處理集群承載公司的實時業(yè)務：

3、數據分析層，與時俱進吧。

先談談語言，R和Python是當前數據挖掘開源領域的一對基友，如果要說取舍，筆者真說不出來，感覺Python更偏向工程一點，比如有對分詞啥的直接支撐，R的繪圖能力異常強大。但他們原來都以樣本統(tǒng)計為主，因此大規(guī)模數據的支撐有限。

筆者還是更關注分布式挖掘環(huán)境，SPARK是一種選擇，建議可以采用SPARK+scala，畢竟SPARK是用scala寫的，對很多原生的特性能夠快速支持。

TD的MPP數據庫ASTER也內嵌了很多算法，應該基于并行架構做了很多優(yōu)化，似乎也是一種選擇，以前做過幾度交往圈，速度的確很快，但使用資料屈指可數，還需要老外的支持。

傳統(tǒng)的數據挖掘工具也不甘人后，SPSS現在有IBM SPSS Analytic Server，加強了對于大數據hadoop的支撐，業(yè)務人員使用反饋還是不錯的。

也許未來機器學習也會形成高低搭配，高端用戶用spark，低端用戶用SPSS，也是要適應不同的應用場景。

深度學習現在漸成潮流，TensorFlow是個選擇，公司當前也部署了一套，希望有機會使用，往人工智能方向演進是大勢所趨。

無論如何，工具僅僅是工具，最終靠的還是建模工程師駕馭能力。

4、數據開放層，也處在一個戰(zhàn)國時代。

有些工程師直接將HIVE作為查詢輸出，雖然不合理，也體現出計算和查詢對于技術能力要求完全不同，即使是查詢領域，也需要根據不同的場景，選擇不同的技術。

HBASE很好用，基于列存儲，查詢速度毫秒級，對于一般的百億級的記錄查詢那也是能力杠杠的，具有一定的高可用性，我們生產上的詳單查詢、指標庫查詢都是很好的應用場景。但讀取數據方面只支持通過key或者key范圍讀取，因此要設計好rowkey。

Redis是K-V數據庫，讀寫速度比HBASE更快，大多時候，HBASE能做的，Redis也能做，但Redis是基于內存的，主要用在key-value 的內存緩存，有丟失數據的可能，當前標簽實時查詢會用到它，合作過的互聯網或廣告公司大多采用該技術，但如果數據越來越大，那么，HBASE估計就是唯一的選擇了?

另外已經基于IMPALA提供互聯網日志的實時在線查詢應用，也在嘗試在營銷平臺采用SQLFire和GemFire實現分布式的基于內存的SQL關聯分析，雖然速度可以，但也是BUG多多，引入和改造的代價較大。

Kylin當前算是基于hadoop/SPARK的多維分析的殺手級工具，應用的場景非常多，希望有機會使用。

5、數據應用層，百花齊放吧。

每個企業(yè)應根據自己的實際規(guī)劃自己的應用，其實搞應用藍圖很難，大數據架構越上層越不穩(wěn)定，因為變化太快，以下是運營商對外變現當前階段還算通用的一張應用規(guī)劃圖，供參考：

6、數據管理層，路漫漫其修遠兮

大數據平臺的管理有應用管理和系統(tǒng)管理之分，從應用的角度講，比如我們建立了DACP的可視化管理平臺，其能適配11大搭數據技術組件，可以實現對各類技術組件的透明訪問能力，同時通過該平臺實現從數據設計、開發(fā)到數據銷毀的全生命周期管理，并把標準、質量規(guī)則和安全策略固化在平臺上，實現從事前管理、事中控制和事后稽核、審計的全方位質量管理和安全管理。

其它諸如調度管理、元數據管理、質量管理當然不在話下，因為管住了開發(fā)的源頭，數據管理的復雜度會大幅降低。

從系統(tǒng)管理的角度看，公司將大數據平臺納入統(tǒng)一的云管理平臺管理(私有云)，云管理平臺包括支持一鍵部署、增量部署的可視化運維工具、面向多租戶的計算資源管控體系(多租戶管理、安全管理、資源管理、負載管理、配額管理以及計量管理)和完善的用戶權限管理體系，提供企業(yè)級的大數據平臺運維管理能力支撐，當然這么宏大的目標要實現也非一日之功。

總結下大數據平臺的一些革命性價值。

大數據時代，大多數企業(yè)的架構必然向著分布式、可擴展及多元化發(fā)展，所謂合久必分，不再有一種技術能包打天下了， 這沖擊著傳統(tǒng)企業(yè)集中化的技術外包模式，挑戰(zhàn)是巨大的。

大數據及云計算時代，面多這么多技術組件，要采用一項新的技術，機遇和風險共存：

對于大數據平臺的商業(yè)版本，企業(yè)面對的是合作伙伴的服務跟不上，因為發(fā)展太快，對于開源版本，企業(yè)面臨的是自身運維能力和技術能力的挑戰(zhàn)，對于自主能力實際要求更高。

當前BAT、華為、新型互聯網等企業(yè)在風卷殘云般的席卷人才， 對于諸如運營商等大型企業(yè)的人才挑戰(zhàn)是巨大的，但同時也蘊含著機會， 事實上，對于致力于搞大數據的人來講，來運營商等企業(yè)搞也是不錯的選擇，因為一方面企業(yè)在轉型，另一方面數據量夠大，技術主導的機會更多。