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

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

與傳統(tǒng)的更多從技術(shù)的角度來看待大數(shù)據(jù)平臺(tái)架構(gòu)的方式不同，筆者這次，更多的從業(yè)務(wù)的視角來談?wù)勱P(guān)于大數(shù)據(jù)架構(gòu)的理解，即更多的會(huì)問為什么要采用這個(gè)架構(gòu)，到底能給業(yè)務(wù)帶來多大價(jià)值，實(shí)踐的最終結(jié)果是什么。

它不一定具有通用性，但從一定程度講，這個(gè)架構(gòu)可能比BAT的架構(gòu)更適應(yīng)大多數(shù)企業(yè)的情況，畢竟，大多數(shù)企業(yè)，數(shù)據(jù)沒到那個(gè)份上，也不可能完全自研，商業(yè)和開源的結(jié)合可能更好一點(diǎn)，權(quán)當(dāng)拋磚引玉。

大數(shù)據(jù)平臺(tái)架構(gòu)的層次劃分沒啥標(biāo)準(zhǔn)，以前筆者曾經(jīng)做過大數(shù)據(jù)應(yīng)用規(guī)劃，也是非常糾結(jié)，因?yàn)閼?yīng)用的分類也是橫縱交錯(cuò)，后來還是覺得體現(xiàn)一個(gè)“能用”原則，清晰且容易理解，能指導(dǎo)建設(shè)，這里將大數(shù)據(jù)平臺(tái)劃分為“五橫一縱”。

具體見下圖示例，這張圖是比較經(jīng)典的，也是妥協(xié)的結(jié)果，跟當(dāng)前網(wǎng)上很多的大數(shù)據(jù)架構(gòu)圖都可以作一定的映射。

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

同時(shí)，大數(shù)據(jù)平臺(tái)架構(gòu)跟傳統(tǒng)數(shù)據(jù)倉庫有一個(gè)不同，就是同一層次，為了滿足不同的場景，會(huì)采用更多的技術(shù)組件，體現(xiàn)百花齊放的特點(diǎn)，這是一個(gè)難點(diǎn)。

數(shù)據(jù)采集層：既包括傳統(tǒng)的ETL離線采集、也有實(shí)時(shí)采集、互聯(lián)網(wǎng)爬蟲解析等等。

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

數(shù)據(jù)分析層：主要包含了分析引擎，比如數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)、 深度學(xué)習(xí)等。

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

數(shù)據(jù)應(yīng)用層：根據(jù)企業(yè)的特點(diǎn)不同劃分不同類別的應(yīng)用，比如針對(duì)運(yùn)營商，對(duì)內(nèi)有精準(zhǔn)營銷、客服投訴、基站分析等，對(duì)外有基于位置的客流、基于標(biāo)簽的廣告應(yīng)用等等。

數(shù)據(jù)管理層：這是一縱，主要是實(shí)現(xiàn)數(shù)據(jù)的管理和運(yùn)維，它橫跨多層，實(shí)現(xiàn)統(tǒng)一管理。

1、數(shù)據(jù)采集層，這是基礎(chǔ)。

離線批量采集，采用的是HADOOP，這個(gè)已經(jīng)成為當(dāng)前流線采集的主流引擎了，基于這個(gè)平臺(tái)，需要部署數(shù)據(jù)采集應(yīng)用或工具。

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

一個(gè)建議是，當(dāng)采購產(chǎn)品的時(shí)候，除了技術(shù)先進(jìn)性和指標(biāo)外，更多的應(yīng)該問問是版本啥時(shí)候上線的，是否在哪里成功部署，是否有足夠多的客戶，如果能做個(gè)測試就更好，否則，你就是小白鼠哦，這個(gè)坑踩了不少。

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

實(shí)時(shí)采集現(xiàn)在也成了大數(shù)據(jù)平臺(tái)的標(biāo)配，估計(jì)主流就是FLUME+KAFKA，然后結(jié)合流處理+內(nèi)存數(shù)據(jù)庫吧，這個(gè)技術(shù)肯定靠譜，但這類開源的東西好是好，但一旦出現(xiàn)問題往往解決周期往往比較長。

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

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

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

還有一個(gè)就是，如果有可能，筆者建議將數(shù)據(jù)采集平臺(tái)升級(jí)為數(shù)據(jù)交換平臺(tái)，因?yàn)槠鋵?shí)企業(yè)內(nèi)有大量的數(shù)據(jù)流動(dòng)，不僅僅是單向的數(shù)據(jù)采集，而且有很多數(shù)據(jù)交換，比如需要從ORACLE倒數(shù)據(jù)到GBASE，從HBASE倒數(shù)據(jù)到ASTER等等，對(duì)于應(yīng)用來講，這個(gè)價(jià)值很大。

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

總得來講，建設(shè)大數(shù)據(jù)采集平臺(tái)非常不易，從客戶的角度講，至少要達(dá)到以下三個(gè)要求：

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

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

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

2、數(shù)據(jù)處理層，現(xiàn)在有個(gè)詞叫混搭，的確是這樣。

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

一定程度講，比如企業(yè)客戶統(tǒng)一視圖寬表用HIVE做比較低效，因?yàn)樯婕暗蕉喾綌?shù)據(jù)的整合，但不是不可以做，最多慢點(diǎn)嘛，還是要講究個(gè)平衡。

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

Hadoop的SPARK的很適合機(jī)器學(xué)習(xí)的迭代，但能否大規(guī)模的應(yīng)用于數(shù)據(jù)關(guān)聯(lián)分析，能否一定程度替代MPP，還需要實(shí)踐來驗(yàn)證。

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

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

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

現(xiàn)在諸如中國移動(dòng)，eBAY等大量公司都在采用這類混搭結(jié)構(gòu)，以適應(yīng)不同的應(yīng)用場景，顯然是一種自然的選擇。

大數(shù)據(jù)平臺(tái)的三駕馬車，少不了流處理。

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

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

流處理集群以流處理技術(shù)結(jié)合內(nèi)存數(shù)據(jù)庫，用以實(shí)時(shí)及準(zhǔn)實(shí)時(shí)數(shù)據(jù)處理，基于IBM Streams流處理集群承載公司的實(shí)時(shí)業(yè)務(wù)：

3、數(shù)據(jù)分析層，與時(shí)俱進(jìn)吧。

先談?wù)務(wù)Z言，R和Python是當(dāng)前數(shù)據(jù)挖掘開源領(lǐng)域的一對(duì)基友，如果要說取舍，筆者真說不出來，感覺Python更偏向工程一點(diǎn)，比如有對(duì)分詞啥的直接支撐，R的繪圖能力異常強(qiáng)大。但他們?cè)瓉矶家詷颖窘y(tǒng)計(jì)為主，因此大規(guī)模數(shù)據(jù)的支撐有限。

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

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

傳統(tǒng)的數(shù)據(jù)挖掘工具也不甘人后，SPSS現(xiàn)在有IBM SPSS Analytic Server，加強(qiáng)了對(duì)于大數(shù)據(jù)hadoop的支撐，業(yè)務(wù)人員使用反饋還是不錯(cuò)的。

也許未來機(jī)器學(xué)習(xí)也會(huì)形成高低搭配，高端用戶用spark，低端用戶用SPSS，也是要適應(yīng)不同的應(yīng)用場景。

深度學(xué)習(xí)現(xiàn)在漸成潮流，TensorFlow是個(gè)選擇，公司當(dāng)前也部署了一套，希望有機(jī)會(huì)使用，往人工智能方向演進(jìn)是大勢所趨。

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

4、數(shù)據(jù)開放層，也處在一個(gè)戰(zhàn)國時(shí)代。

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

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

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

另外已經(jīng)基于IMPALA提供互聯(lián)網(wǎng)日志的實(shí)時(shí)在線查詢應(yīng)用，也在嘗試在營銷平臺(tái)采用SQLFire和GemFire實(shí)現(xiàn)分布式的基于內(nèi)存的SQL關(guān)聯(lián)分析，雖然速度可以，但也是BUG多多，引入和改造的代價(jià)較大。

Kylin當(dāng)前算是基于hadoop/SPARK的多維分析的殺手級(jí)工具，應(yīng)用的場景非常多，希望有機(jī)會(huì)使用。

5、數(shù)據(jù)應(yīng)用層，百花齊放吧。

每個(gè)企業(yè)應(yīng)根據(jù)自己的實(shí)際規(guī)劃自己的應(yīng)用，其實(shí)搞應(yīng)用藍(lán)圖很難，大數(shù)據(jù)架構(gòu)越上層越不穩(wěn)定，因?yàn)樽兓?，以下是運(yùn)營商對(duì)外變現(xiàn)當(dāng)前階段還算通用的一張應(yīng)用規(guī)劃圖，供參考：

6、數(shù)據(jù)管理層，路漫漫其修遠(yuǎn)兮

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

其它諸如調(diào)度管理、元數(shù)據(jù)管理、質(zhì)量管理當(dāng)然不在話下，因?yàn)楣茏×碎_發(fā)的源頭，數(shù)據(jù)管理的復(fù)雜度會(huì)大幅降低。

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

總結(jié)下大數(shù)據(jù)平臺(tái)的一些革命性價(jià)值。

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

大數(shù)據(jù)及云計(jì)算時(shí)代，面多這么多技術(shù)組件，要采用一項(xiàng)新的技術(shù)，機(jī)遇和風(fēng)險(xiǎn)共存：

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

當(dāng)前BAT、華為、新型互聯(lián)網(wǎng)等企業(yè)在風(fēng)卷殘?jiān)瓢愕南砣瞬牛?對(duì)于諸如運(yùn)營商等大型企業(yè)的人才挑戰(zhàn)是巨大的，但同時(shí)也蘊(yùn)含著機(jī)會(huì)， 事實(shí)上，對(duì)于致力于搞大數(shù)據(jù)的人來講，來運(yùn)營商等企業(yè)搞也是不錯(cuò)的選擇，因?yàn)橐环矫嫫髽I(yè)在轉(zhuǎn)型，另一方面數(shù)據(jù)量夠大，技術(shù)主導(dǎo)的機(jī)會(huì)更多。