夏軍：小米大資料整合架構演化之路

【IT168 專稿】本文根據夏軍老師在2018年10月18日【第十屆中國系統架構師大會】現場演講內容整理而成。

講師簡介：

夏軍，小米資料流平臺負責人，曾就職於騰訊和百度，主要負責訊息佇列、大資料整合方案，離線計算和實時計算等方面的工作。

摘要：

小米有眾多的智慧終端和裝置，資料規模非常大，對於資料採集和大資料整合提出了非常高的要求。此次演講主要介紹小米大資料整合解決方案，主要包括小米資料流平臺的架構演化，整個鏈路的資料質量監控，資料流生態的構建思路，最後會介紹典型的應用場景、未來的規劃和思考。

分享大綱：

1、問題與挑戰

2、資料流整體框架

3、核心功能

4、應用場景解析

正文：

1、問題與挑戰

首先，我介紹一下小米大資料整合架構面臨的問題和挑戰：一是大資料場景下系統眾多，包括各種儲存系統和計算系統，這其中很關鍵的一個問題是如何高效整合所有系統以讓資料發揮最大價值;二是做資料整合時，我們希望可以有更低延遲;三是當資料在不同系統中流動時，我們如何及時發現並解決問題;四是量化資料在整個鏈路傳輸過程中存在的問題，比如資料延遲、資料丟失等。

2、資料流整體框架

上圖為小米資料流整體架構，大致可分為三部分：中間層叫Talos，這是小米自研的一套訊息佇列，其主要應用場景有兩個：一是作為資料中介軟體(資料中轉中心)，二是服務於後續的流式計算。雖然現在Kafka非常火，但是我們確實發現了Kafka的一些問題，比如Reblance、擴容、縮容等問題，因此我們選擇使用自研Talos。下層是基於流式訊息佇列做的source和sink擴充套件，目標是希望以Talos為資料匯流排把大資料應用場景下的不同平臺連線起來。上層依賴於底層的source和sink體系，解決Metric監控、報警和資料收集等問題，也會做OLAP分析和線上APP日誌收集等。我們希望在這個架構下，業務方可以根據不同需求適配該系統以得到完美的解決方案。

3、核心功能

上圖為該平臺的主要核心模組，最底層是訊息佇列，中間層是資料接入層，該層包含一些SDK，因為它本身作為訊息佇列也存在很多應用場景，比如推送場景等。我們在訊息佇列上做了Streaming Plunigs以適配各種Streaming系統，其後的Source和Sink其實是對資料的擴充套件。最上層主要是基於這套框架做的整體feature，比如全域性web端控制和產品化方案。我們也做了全鏈路資料監控和資料追蹤。我們有一個自己的流式計算管理平臺，用來幫助管理使用者流式作業。因為小米有自己的海外業務，所以我們有全域性資料中心的資料replication機制，需要在海外部署自己的資料中心，因為資料是全球分散化的，必然就存在資料彙總問題，這些構成了我們的整體解決方案。

接下來，我將逐步介紹核心功能。首先，我介紹一般資料解決方案(如上圖)，這是一些常見系統，我們要解決的問題是在不同的系統間做資料整合。

這之中存在一些問題：一是系統的互動複雜度較高;二是當涉及的系統較多時，如果每個業務都做自己的事情，不僅前期研發成本會非常高，而且後續功能新增、系統運維、系統重構和交接成本會更高;三是當各業務方按照自身需求進行開發時，由於彼此獨立導致無法複用重複邏輯;四是如果讓業務方完成某件事情，業務方往往會忽略監控和資料質量，一般缺失或者很難做到很完備，因此無法保證資料互動質量;五是一般由業務獨立部署，基本無法抽象化和服務化，進而很難積累經驗和傳承知識。

我們的做法是基於Talos訊息佇列作為訊息匯流排，和不同的系統進行互動，我們在外圍做一些產品化工作，接管一些比較繁瑣的配置。基於此，我們做了Multi Source和Multi Sink的抽象。

我們認為抽象首先是希望資料在系統間進行流動，這之中包含兩層含義：一是連線不同的系統;二是構建低延遲場景。我們做產品化封裝其實就是避免業務團隊的重複投入與研發。我們希望以Talos為訊息資料匯流排對所有資料使用流式計算以儘可能降低資料結構產生的延遲。要想在所有系統之間作中轉，我們就需要考慮整合複雜度，透過Source和Sink組合的模式，系統整合複雜度降為O(N)。最後，我們期望按照這種模式接入更多系統，這樣我們就可以形成規模效應，依賴目前的資料流平臺給使用者產生價值，建立資料流生態系統。

接下來，我們介紹一下系統監控。對於整套流程，我認為系統監控大概分為以下幾方面：資料丟失監控，資料延遲增加監控，服務程式異常監控，流量異常監控。

一般情況下，我們會在每臺機器上部署一個agent，收集不同模組的Metric資料。其次，我們會把資料彙總到訊息佇列，對資料進行各種整理並中轉到Druid平臺，由於監控資料有很多維度，因此我們用Druid的目的就是降維，按照不同維度進行資料合併。然後，我們將資料中轉到Falcon，這是一套小米開源的監控系統，我們會對監控資料提供Web化展示，讓使用者實時看到監控內容，我們也會週期性生成報表來告訴使用者一些資料情況。

說到底，資料流端到端審計其實就是量化整個鏈路的資料情況，其展現形式就是Web介面，能夠實時查詢最新資料，也能查詢歷史資料。在報表部分，我們引入了兩個概念：Event Time和 Processing Time，Event Time指訊息真正產生的系統時間。Processing Time指訊息到達具體某個模組，因為我們是一個流動的系統，裡面有很多模組，我們會把 Event Time和 Processing Time依賴於類似Metric的模組進行資料打點並收集。我們會把Event Time看作訊息的唯一標籤來進行資料校驗。Processing Time用來統計訊息從產生到達某一模組的系統延遲情況。

上圖為資料流端到端審計的簡單處理流程，我們會在每一個節點做埋點資料，埋點資料主要包括每條訊息的Event Time和 Processing Time，以及其歸屬的流等類似資訊。為了保證監控資料的高可用，我們會把監控資料先持久化到本地磁碟。然後，我們透過一套自己的流程收集資料。

整個過程存在幾個問題，一是監控資料量非常大，如果要監控整個鏈路，我們需要給每條流經系統的資料做埋點，這會導致系統負載增加;二是訊息有可能重複，在最終結果彙總時，我們要做相應的去重處理;三是期望資料以一種準實時的形式展示給使用者。

在這之中，我們引入了Spark Streaming對資料進行處理，雖然訊息有重複，雖然Spark Streaming作業會因為各種原因掛掉，但我們需要保證訊息正確統計。我們在Agent端進行分鐘級別的資料合併，也就是在每臺機器上進行預聚合，這樣能夠把原始監控訊息的資料量大大降低。我們會在Spark Streaming裡做一些基於記憶體的去重邏輯，依賴外部KV系統做資料校驗。

上圖為我們的監控成果，小米會有很多線上資料，這些資料在進行埋點後寫入訊息佇列，最後會轉到Kudu和HDFS中，HDFS後期會做一些基於離線的Hive分析過渡，或者是OLAP分析。上圖展示了我們到達這個環節的資料量，對於一個時間視窗，也就是一分鐘的時間內，視窗所到達的資料量。

上圖顯示出現了一些資料丟失。目前來看，整個過程應該是資料從線上灌入Hive和HDFS，上圖所示資料為測試樣例，展示了從訊息佇列到後端部分系統做轉儲的過程。

4、應用場景解析

因為篇幅有限，我就介紹了小米對Source和Sink理念的理解，以及我們如何做監控和資料審計。我認為，對大資料整合系統而言，這三點對對業務來說是至關重要的。接下來，我將解析部分應用場景。

首先介紹小米內部資料整合的典型方案——埋點資料收集。對網際網路公司而言，埋點資料收集是非常重要的應用場景。上圖大概分為幾部分，一是對各種web服務設定埋點資料，透過擴充套件appender來實現業務，方便的把資料透過每臺機器部署的agent進行中轉;其次，我們也做了web接入層，將大量的離散點透過這種模式收集起來，進而對其做資料分析。

第二個應用場景是實時日誌分析，對於線上日誌檔案，我們會透過agent進行監控，將資料實時傳入Talos，透過ES或者Kibana進行實時查詢。簡單來說，我們依賴整個系統把分散式檔案透過準實時的方式匯入ES，再透過Kibana進行查詢和視覺化日誌分析。

第三個場景是泛OLAP場景。我們透過Druid做多維度分析，使用Kudu進行即即席詢，利用Kudu的列儲存以較低延遲展示資料， 利用Kylin做T+1查詢。

整體流程如上圖所示，小米目前還存在大量MySQL叢集和報表資料，MySQL可以滿足OTLP的需求，但是對於很多的OLAP查詢，延遲會比較大，無法滿足需求。基於此場景，我們的解決方案是把MySQL資料以準實時方式匯出，在Kudu裡做一個實時映象，透過Spark SQL做查詢。或者，將HDFS的資料灌入kudu，再接入Superset之類做展示。

最後一個場景是流式計算。我們之前提到系統中有很多Source和Sink，我們期望能夠從Talos也就是訊息佇列裡將資料傳入Spark Streaming做實時計算，綜上，這就是小米在資料流系統構建方面的經驗。