大數據平台架構

前面提到各種大數據技術的原理與架構，大數據計算通過將可執行的代碼分發到大規模的伺服器集群上進行分散式計算，以處理大規模的數據，即所謂的移動計算比移動數據更划算。但是這樣的計算方式必然不會很快，即使一個規模不太大的數據集上的一次簡單計算，MapReduce也可能需要幾分鐘，Spark快一點，也至少需要數秒的時間。

而網站處理用戶請求，需要毫秒級的響應，也就是說，要在1秒內完成計算，大數據計算必然不能實現這樣的響應要求。但是網站應用又需要使用大數據實現統計分析、數據挖掘、關聯推薦、用戶畫像等一系列功能。

所以網站需要構建一個大數據平台，去整合網站應用和大數據系統之間的差異，將應用程序產生的數據導入到大數據系統，經過處理計算後再導出給應用程序使用。一個典型的網站大數據平台架構如下圖：

大數據平台可分為三個部分

數據採集

將應用程序產生的數據和日誌等同步到大數據系統中，由於數據源不同，這裡的數據同步系統實際上是多個相關係統的組合。資料庫同步通常用Sqoop，日誌同步可以選擇Flume，打點採集的數據經過格式化轉換後通過Kafka傳遞。

不同的數據源產生的數據質量可能差別很大，資料庫中的數據也許可以直接導入大數據系統就可以，而日誌和爬蟲產生的數據就需要進行大量的清洗、轉化處理才能有效使用。所以數據同步系統實際上承擔著傳統數據倉庫ETL的工作。

數據處理

這裡是大數據存儲與計算的核心，數據同步系統導入的數據存儲在HDFS。MapReduce、Hive、Spark等計算任務讀取HDFS上的數據進行計算，再將計算結果寫入HDFS。

MapReduce、Hive、Spark等進行的計算處理被稱作是離線計算，HDFS存儲的數據被稱為離線數據。相對的，用戶實時請求需要計算的數據稱為在線數據，這些數據由用戶實時產生，進行實時在線計算，並把結果數據實時返回用戶，這個計算過程中涉及的數據主要是用戶自己一次請求產生和需要的數據，數據規模非常小，內存中一個線程上下文就可以處理。

在線數據完成和用戶的交互後，被數據同步系統導入到大數據系統，這些數據就是離線數據，其上進行的計算通常針對（某一方面的）全體數據，比如針對所有訂單進行商品的關聯性挖掘，這時候數據規模非常大，需要較長的運行時間，這類計算就是離線計算。

除了離線計算，還有一些場景，數據規模也比較大，要求的處理時間也比較短。比如淘寶要統計每秒產生的訂單數，以便進行監控和宣傳。這種場景被稱為大數據流式計算，通常用Storm、Spark Steaming等流式大數據引擎來完成，可以在秒級甚至毫秒級時間內完成計算。

數據輸出與展示

大數據計算產生的數據還是寫入到HDFS中，應用程序不可能到HDFS中讀取數據，所以必須要將HDFS中的數據導出到資料庫中。數據同步導出相對比較容易，計算產生的數據都比較規範，稍作處理就可以用Sqoop之類的系統導出到資料庫。

這時，應用程序就可以直接訪問資料庫中的數據，實時展示給用戶，比如展示給用戶的關聯推薦的商品。淘寶賣家的量子魔方之類的產品，其數據都來自大數據計算產生。

除了給用戶訪問提供數據，大數據還需要給運營和決策層提供各種統計報告，這些數據也寫入資料庫，被相應的後台系統訪問。很多運營和管理人員，每天一上班，就是登錄後台數據系統，查看前一天的數據報表，看業務是否正常。如果數據正常甚至上升，就可以稍微輕鬆一點，如果數據下跌，焦躁而忙碌的一天也馬上就開始了。

將上面三個部分整合起來的是任務調度管理系統，不同的數據何時開始同步，各種MapReduce、Spark任務如何合理調度才能使資源利用最合理、等待的時間又不至於太久，臨時的重要任務能夠儘快執行，這些都需要任務調度管理系統完成。有時候對分析師和工程師開放的作業提交、進度跟蹤，數據查看等功能也集成在這個系統中。

對於每個公司的大數據團隊，最核心開發維護的也就是這個系統，大數據平台上的其他系統一般都有成熟的開源軟體可以選擇，作業調度管理會涉及很多個性化的需求，通常需要團隊自己開發。