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

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

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

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

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

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

數據采集層：既包括傳統的ETL離線采集、也有實時采集、互聯網爬蟲解析等等。 數據處理層：根據數據處理場景要求不同，可以劃分為HADOOP、MPP、流處理等等。 數據分析層：主要包含了分析引擎，比如數據挖掘、機器學習、 深度學習等。 數據訪問層：主要是實現讀寫分離，將偏向應用的查詢等能力與計算能力剝離，包括實時查詢、多維查詢、常規查詢等應用場景。 數據應用層：根據企業的特點不同劃分不同類別的應用，比如針對運營商，對內有精準營銷、客服投訴、基站分析等，對外有基于位置的客流、基于標簽的廣告應用等等。 數據管理層：這是一縱，主要是實現數據的管理和運維，它橫跨多層，實現統一管理。 1、數據采集層，這是基礎。

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

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

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

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

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

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

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

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

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

多樣化數據采集能力：支持對表、文件、消息等多種數據的實時增量數據采集(使用flume、消息隊列、OGG等技術)和批量數據分布式采集等能力(SQOOP、FTP VOER HDFS)，比基于傳統ETL性能有量級上的提升，這是根本。 可視化快速配置能力：提供圖形化的開發和維護界面，支持圖形化拖拽式開發，免代碼編寫，降低采集難度，每配置一個數據接口耗時很短，以降低人工成本。 統一調度管控能力：實現采集任務的統一調度，可支持Hadoop的多種技術組件(如 MapReduce、Spark 、HIVE)、關系型數據庫存儲過程、 shell腳本等，支持多種調度策略(時間/接口通知/手工)。 2、數據處理層，現在有個詞叫混搭，的確是這樣。