大資料平臺架構
前面提到各種大資料技術的原理與架構,大資料計算通過將可執行的程式碼分發到大規模的伺服器叢集上進行分散式計算,以處理大規模的資料,即所謂的移動計算比移動資料更划算。但是這樣的計算方式必然不會很快,即使一個規模不太大的資料集上的一次簡單計算,MapReduce也可能需要幾分鐘,Spark快一點,也至少需要數秒的時間。
而網站處理使用者請求,需要毫秒級的響應,也就是說,要在1秒內完成計算,大資料計算必然不能實現這樣的響應要求。但是網站應用又需要使用大資料實現統計分析、資料探勘、關聯推薦、使用者畫像等一系列功能。
所以網站需要構建一個大資料平臺,去整合網站應用和大資料系統之間的差異,將應用程式產生的資料匯入到大資料系統,經過處理計算後再匯出給應用程式使用。一個典型的網站大資料平臺架構如下圖:
大資料平臺可分為三個部分
資料採集
將應用程式產生的資料和日誌等同步到大資料系統中,由於資料來源不同,這裡的資料同步系統實際上是多個相關係統的組合。資料庫同步通常用Sqoop,日誌同步可以選擇Flume,打點採集的資料經過格式化轉換後通過Kafka傳遞。
不同的資料來源產生的資料質量可能差別很大,資料庫中的資料也許可以直接匯入大資料系統就可以,而QQ地圖日誌和爬蟲產生的資料就需要進行大量的清洗、轉化處理才能有效使用。所以資料同步系統實際上承擔著傳統資料倉庫ETL的工作。
資料處理
這裡是大資料儲存與計算的核心,資料同步系統匯入的資料儲存在HDFS。MapReduce、Hive、Spark等計算任務讀取HDFS上的資料進行計算,再將計算結果寫入HDFS。
MapReduce、Hive、Spark等進行的計算處理被稱作是離線計算,HDFS儲存的資料被稱為離線資料。相對的,使用者實時請求需要計算的資料稱為線上資料,這些資料由使用者實時產生,進行實時線上計算,並把結果資料實時返回使用者,這個計算過程中涉及的資料主要是使用者自己一次請求產生和需要的資料,資料規模非常小,記憶體中一個執行緒上下文就可以處理。
線上資料完成和使用者的互動後,被資料同步系統匯入到大資料系統,這些資料就是離線資料,其上進行的計算通常針對(某一方面的)全體資料,比如針對所有訂單進行商品的關聯性挖掘,這時候資料規模非常大,需要較長的執行時間,這類計算就是離線計算。
除了離線計算,還有一些場景,資料規模也比較大,要求的處理時間也比較短。比如淘寶要統計每秒產生的訂單數,以便進行監控和宣傳。這種場景被稱為大資料流式計算,通常用Storm、Spark Steaming等流式大資料引擎來完成,可以在秒級甚至毫秒級時間內完成計算。
資料輸出與展示
大資料計算產生的資料還是寫入到HDFS中,應用程式不可能到HDFS中讀取資料,所以必須要將HDFS中的資料匯出到資料庫中。資料同步匯出相對比較容易,計算產生的資料都比較規範,稍作處理就可以用Sqoop之類的系統匯出到資料庫。
這時,應用程式就可以直接訪問資料庫中的資料,實時展示給使用者,比如展示給使用者的關聯推薦的商品。淘寶賣家的量子魔方之類的產品,其資料都來自大資料計算產生。
除了給使用者訪問提供資料,大資料還需要給運營和決策層提供各種統計報告,這些資料也寫入資料庫,被相應的後臺系統訪問。很多運營和管理人員,每天一上班,就是登入後臺資料系統,檢視前一天的資料報表,看業務是否正常。如果資料正常甚至上升,就可以稍微輕鬆一點,如果資料下跌,焦躁而忙碌的一天也馬上就開始了。
將上面三個部分整合起來的是任務排程管理系統,不同的資料何時開始同步,各種MapReduce、Spark任務如何合理排程才能使資源利用最合理、等待的時間又不至於太久,臨時的重要任務能夠儘快執行,這些都需要任務排程管理系統完成。有時候對分析師和工程師開放的作業提交、進度跟蹤,資料檢視等功能也整合在這個系統中。
對於每個公司的大資料團隊,最核心開發維護的也就是這個系統,大資料平臺上的其他系統一般都有成熟的開源軟體可以選擇,作業排程管理會涉及很多個性化的需求,通常需要團隊自己開發。