《企業級一站式大數據開發平臺理論及實踐》
《ApacheSpark在海致大數據平臺中優化實踐》
《快手大數據平臺服務化實踐》
常規的大數據平臺架構方案是基於大數據平臺Lamda架構設計的。事實上，業界也基本是按照這種架構模型搭建自己的大數據平臺。
下面我們來看一下淘寶、美團和滴滴的大數據平臺，一方面進一步學習大廠大數據平臺的架構，另一方面也學習大廠的工程師如何畫架構圖。通過大廠的這些架構圖，就會發現，不但這些知名大廠的大數據平臺設計方案大同小異，架構圖的畫法也有套路。
淘寶可能是中國互聯網業界較早搭建了自己大數據平臺的公司，圖1是淘寶早期的Hadoop大數據平臺，比較典型。
淘寶的大數據平臺基本分成三部分，上面是數據源與數據同步模塊；中間是雲梯1，即淘寶的Hadoop大數據集羣；下面是大數據的應用，即使用大數據集羣的計算結果。
數據源主要來自Oracle和MySQL的備庫，以及日誌系統和爬蟲系統，這些數據通過數據同步網關服務器導入Hadoop集羣。其中，DataExchange非實時全量同步數據庫數據，DBSync實時同步數據庫增量數據，TimeTunnel實時同步日誌和爬蟲數據。數據全部寫入HDFS。
在Hadoop中的計算任務會通過天網調度系統，根據集羣資源和作業優先級，調度作業的提交和執行。計算結果寫入HDFS，再經過DataExchange同步到MySQL和Oracle數據庫。處於平臺下方的數據魔方、推薦系統等從數據庫中讀取數據，就可以實時響應用戶的操作請求。
淘寶大數據平臺的核心是位於架構圖左側的天網調度系統，提交到Hadoop集羣上的任務需要按序、按優先級調度執行，Hadoop集羣上已經定義好的任務也需要調度執行，何時從數據庫、日誌、爬蟲系統導入數據也需要調度執行，何時將Hadoop執行結果導出到應用系統的數據庫，仍然需要調度執行。可以說，整個大數據平臺都是在天網調度系統的統一規劃和安排下運作的，如圖2所示。
DBSync、TimeTunnel、DataExchange這些數據同步組件也是淘寶內部開發的，可以針對不同的數據源和同步需求導入、導出數據。這些組件淘寶大多已經開源，我們可以參考使用。
美團大數據平臺的數據源來自MySQL數據庫和日誌，數據庫通過Canal獲得MySQL的binlog，輸出給消息隊列Kafka，日誌通過Flume輸出到Kafka，如圖3所示。
Kafka的數據會被流式計算和批處理計算兩個引擎分別消費。流處理使用Storm進行計算，結果輸出到HBase或者數據庫。批處理計算使用Hive進行分析計算，結果輸出到查詢系統和BI（商業智能）平臺。
數據分析師可以通過BI產品平臺進行交互式的數據查詢訪問，也可以通過可視化的報表工具查看已經處理好的常用分析指標；公司高管也可以通過平臺上的天機系統查看公司主要業務指標和報表。
美團大數據平臺的整個過程管理通過調度平臺進行管理。公司內部開發者使用數據開發平臺訪問大數據平臺，進行ETL（數據提取、轉換、裝載）開發，提交任務作業並進行數據管理。
滴滴大數據平臺分爲實時計算平臺（流式計算平臺）和離線計算平臺（批處理計算平臺）兩個部分。
實時計算平臺架構如圖4所示。數據採集以後輸出到Kafka消息隊列，消費通道有兩個，一個是數據ETL，使用Spark Streaming或者Flink將數據進行清洗、轉換、處理後記錄到HDFS中，供後續批處理計算；另一個通道是Druid，計算實時監控指標，將結果輸出到報警系統和實時圖表系統DashBoard，如圖4所示。
離線計算平臺架構如圖5所示。滴滴的離線大數據平臺是基於Hadoop 2（HDFS、Yarn、MapReduce）和Spark以及Hive構建的，並在此基礎上開發了自己的調度系統和開發系統。調度系統和前面其他系統一樣，調度大數據作業的優先級和執行順序。開發平臺是一個可視化的SQL編輯器，可以方便地查詢表結構、開發SQL，併發布到大數據集羣上。
此外，滴滴還重度使用HBase，並對相關產品（HBase、Phoenix）做了一些自定義的開發，維護着一個和實時、離線兩個大數據平臺同級別的HBase平臺，它的架構圖參見圖6。
來自實時計算平臺和離線計算平臺的計算結果被保存到HBase中，然後應用程序通過Phoenix訪問HBase。而Phoenix是一個構建在HBase上的SQL引擎，可以通過SQL方式訪問HBase上的數據。
可以看到，這些知名大廠的大數據平臺真的是大同小異，雖然由於各自場景和技術棧的不同，在大數據產品選型和架構細節上略有差異，但整體思路基本上都是一樣的。
不過也正是這種大同小異，讓我們能從各個角度瞭解大數據平臺架構，對大數據平臺架構有更深刻的認知。
我在阿里巴巴工作期間，有一陣子不斷參加各種基礎技術產品的架構評審會。有一次，另一個和我一樣經常參加這類會議的架構師說：“我感覺這些產品的架構怎麼都一樣”。經他一提醒，大家紛紛點頭稱是，好像確實如此。
同一類問題的解決方案通常是相似的。一個解決方案可以解決重複出現的同類問題，這種解決方案就稱爲模式。模式幾乎無處不在，一旦一個解決方案被證明是行之有效的，就會被重複使用解決同類的問題。
所以我們看到，很多大數據產品的架構也都差不多，比如Hadoop 1、Yarn、Spark、Flink、Storm，這些產品的架構部署真的是太像了。
對於有志於成爲架構師的工程師來說，一方面當然要提高自己的編程水平，另一方面也可以多看看各種架構設計文檔，多參加一些架構師技術大會。
在我看來，編程需要天分；而架構設計，真的是熟能生巧。
關於作者：
李智慧，同程旅行交通首席架構師。曾任阿里巴巴、Intel架構師，長期從事分佈式系統與大數據開發，Apache Spark 代碼貢獻者，騰訊雲 TVP，著有暢銷書《大型網站技術架構：核心原理與案例分析》。
本文節選自《大數據技術架構：核心原理與應用實踐》，想了解更多大數據技術架構的內容，推薦閱讀此書。
更多精彩內容請閱讀《大數據技術架構：核心原理與應用實踐》！
未來的生活一定是數字化的生活，掌握一些大數據技術總是好事。但本質上它也只是一個工具，人生的旅程，既要緊跟時代，也要謹防隨波逐流。相信各位讀者能以《大數據技術架構：核心原理與應用實踐》一書的內容爲起點而非終點，繼續探索，走出自己的光明大道。
本文分享自微信公衆號 - 大數據技術與架構（import_bigdata）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
