大規模資料傳輸，知易行難 — 資料傳輸與 ETL 平臺的架構演進

本次分享主要分為四部分：

• vivo 大資料平臺架構概覽
• 資料採集的需求與挑戰
• 平臺架構演進過程
• 未來規劃與展望

一、vivo 大資料平臺架構概覽

vivo 大資料平臺是做什麼的？支撐了哪些業務？以及如何支撐這些業務？我們先來看一下 vivo 大資料平臺架構的整體概覽。

從圖中可以看出，vivo 大資料平臺的定位是為公司的各個業務線提供最基礎的資料服務。目前支撐的業務包括網際網路業務、手機業務相關的十幾條大的業務線。支撐的業務主要依賴以下四個平臺：
一是資料生產平臺，主要做資料的採集和資料的清洗，經過採集和清洗入庫到儲存系統，提供給資料開發人員使用。
二是儲存計算平臺，為公司提供統一的儲存計算服務。
三是資料開發平臺，主要給資料開發、分析人員提供資料的查詢和分析的入口。
四是運營維護平臺，是為整個大資料平臺提供物理資源管理、基礎監控等基礎能力的運維服務。

我主要負責資料生產平臺，接下來詳細介紹下 vivo 的資料生產平臺。

如何定義資料生產呢？就我們自己而言，vivo 資料生產平臺是使用者與產品之間通過資料進行互動的一個橋樑。
我們的業務每天產生大量的資料，資料來源主要有公網手機、App 和內部業務。資料很有價值，後續的資料應用可以基於這些資料實時發現可能存在的風險；通過資料還可以形成運營報表以分析產品運營的情況；同時也可以對手機使用者做行為分析，提供畫像給產品，讓產品更好地瞭解使用者和滿足使用者需求。

既然資料這麼重要，如何保證資料能夠快速穩定地觸達到資料分析系統呢？這裡面就有一個很重要的資料生產平臺。資料生產平臺提供了多種資料接入方式，比如提供訊息、埋點、日誌等多種方式收集，然後清洗入庫以供資料開發使用。

那麼，現在我們的資料生產平臺的資料規模如何呢？目前每天採集的資料量大概是 90 TB ，每天接收的資料條是 2500 億，Agent 個數是 1.1 萬 ，服務的業務線有 250+ 。

二、資料採集的需求與挑戰

既然每天的資料這麼大，那在構建資料生產平臺的過程中都遇到了什麼樣的問題呢？接下來分享一下我們在資料採集過程中遇到的需求和挑戰。

很多人會覺得資料採集很容易，前面有采集的 Agent ，後面有訊息中介軟體。在訊息中介軟體之後有兩個路徑：一是通過實時資料消費；二是通過資料分揀離線分析。從這個資料採集的鏈路來看，的確比較簡單。當我們資料較小，業務不復雜時採用這種資料採集鏈路是沒有問題的。當時支援的規模達到 80 萬/S、5000 個 Agent 。

隨著業務的發展，我們發現資料採集的鏈路逐漸不能滿足需求。首先資料生產的環境發生了變化，從單個自建的機房變成多個。我們除了在自建機房上部署，還要在混合雲環境部署。在環境變化的同時，業務要求資料採集除了具備高吞吐還要高可用。這時資料採集就會出現兩個致命的問題：一是資料延時；二是資料丟失。

比如採集鏈路中的網路抖動或者節點故障會導致資料採集延遲，採集延遲又會導致資料採集不及時從而引起丟失的問題。基於這些問題，我們開啟了資料採集平臺的架構演進之路。

三、平臺架構演進過程

1、採集鏈路 0.2 版本

為了解決上述提到的問題，我們的第一個版本在改造時對應於採集鏈路 0.2 版本。這個版本主要做了兩件事：一是 Agent 通道分離，二是 Kafka 資源分離。

之前我們的採集 Agent 是單通道的，後面的 Kafka 節點故障時會阻塞整個通道。同時因為是單通道，我們沒有辦法區分高低優業務。所以，我們將單通道變成多通道。在做多通道的同時，當某個 topic 採集出現異常，我們就直接丟棄，單通道的順序傳送問題也得到解決。

這裡面設定了一個 Kafka 資源分組，用以解決單通道的問題。簡單來講 Kafka 的資源分組按照業務 topic 對 broker 進行劃分。比如將高優的業務劃分到一組，低優業務劃分到另外的組。保持高優的處於低負載狀態，高優的傳送速度比較快，這樣我們的高優通道的傳送速率就相對比較高。這樣既解決了單通道順序傳送問題，資料延遲問題也得到緩解；同時還解決了業務優先順序保障的問題。

這種狀態下，資料採集過程又逐漸暴露出了兩個問題：

一是資料恢復慢。因為當採集鏈路出現問題，我們要恢復某一部分資料該怎麼做？要麼是消費端 Kafka 重置；要麼從 Agent 端重新採集。由於整個鏈路比較長，所以恢復慢。

二是 Kafka 資源緊張。所有的資料都需要經過 Kafka。當 Kafka copy 比較多資料的情況下，就會對磁碟儲存造成壓力，它的磁碟 IO 會成為一個瓶頸。

於是，我們對採集鏈路進行分析，發現採集鏈路上絕大部分在做離線分析，實時資料分析佔其中很少一部分。而離線分析的資料沒有必要經過整個採集路徑。所以，我們對採集路徑做了進一步優化，形成了採集鏈路 0.3 版本。

2、採集鏈路 0.3 版本

採集鏈路 0.3 版本解決了 實時離線分離和資料快速恢復的問題。

過簡單的架構圖，大家可以發現我們的採集鏈路當中增加了一個 logpusher 元件。當我們做離線分析時可以從 Agent 端直接上傳到 HDFS。

logpusher 還可以實現資料快速恢復。我們要恢復 10 分鐘的資料，logpusher 可以去定製，這樣就形成了快速的恢復能力。大部分的離線資料不需要通過實時鏈路來採集，從而減少了 Kafka 的成本壓力，這樣實時採集鏈路資料量變小了，我們整個採集鏈路會更加快速。

隨著公司業務的繼續發展，前面的 Agent 數量越來越多。這時，我們遇到了另外的問題，一是 Kafka 的連線數問題，在 Agent 增多的情況下，Kafka 的連線數呈現一個線性增長；二是出現資料丟失的問題，我們的業務日誌是滾動刪除的，如果採集資料跟不上業務的資料，這部分會被丟棄掉，對後端的資料分析而言是採集資料丟失。為了解決這些問題，採集鏈路演進到了 1.0 版本。

3、採集鏈路 1.0 版本

在 1.0 版本中，我們對採集鏈路做了大改動 ——在 Agent 與 Kafka 之間增加一個緩衝層，這裡我們稱之為 Bus。

Bus 主要做三件事情：一是連線收斂；二是資料緩衝；三是資料路由轉發。

（1）連線收斂

連線收斂，簡單講就是多個連線變成一個連線。為什麼要這樣呢？因為 Kafka 的每一個連線都會消耗 Kafka 的資源。當連線較多的情況下，Kafka 的效能會下降，資料採集速度也會下降。隨著連線增多，故障連線的個數會更大。如果連線故障，就會觸發 Kafka 的 rebalance，rebalance 會進一步影響採集效能。所以我們需要做連線收斂。

（2）資料緩衝

資料緩衝主要是解決資料丟失的問題。如何實現呢？

比如說 Kafka 出現了故障，之前的版本很明顯會導致 Agent 的傳送速度下降。因為 Agent 傳送速度趕不上資料的生產速度，那這部分的資料就滾動刪除，這樣資料就丟失了。

如果我們在 Bus 層做一個資料的緩衝，假如說鏈路出現故障，那 Bus 可以用一些本地磁碟資源，將資料進行旁路儲存，這樣 Agent 可以正常傳送。當 Kafka 穩定之後，Bus 再非同步傳送到 Kafka，這樣也不會影響正常的實時採集鏈路，這就解決了資料丟失的問題。

（3）資料路由轉發

在引入了 Bus 之後，我們同時也做了資料轉發。有的資料不一定到 Kafka ，比如有的資料需要直接到 ES，用於做檢索。我們通過對 Bus 配置修改來決定資料傳送的地方。資料從哪裡來到哪裡去做成可配置的，讓整個採集鏈路變得更加靈活。

（4）部署問題

引入的 Bus 應該部署在哪個地方呢？這裡有兩種部署方案：一種是將 Bus 和 Kafka 部署在一起，將 Agnet 跨機房部署；另一種是將 Bus 與 Agent 部署在一起，與 Kafka 跨機房部署。無論如何選擇，都存在跨機房的問題。思考之後，我們採取的是第二種部署方案。

因為跨機房資料傳輸無疑會導致 RT 增大，資料傳輸的吞吐量下降。為了彌補 RT 的問題，我們通常的做法是增大傳送臨界區 patchSize 或者資料傳送 Task 的數量。我們要麼在 Agent 端增加，要麼在 Bus 端增加。在 Agent 端增加，對業務是有感知的，Agent 是與業務服務部署在一起的，所有我們只能在 Bus 端修改 patchSzie 與傳送的任務數。因此，我們就需要選擇第二種部署方案。

4、小結：從 0.1 到 1.0 版本

簡單回顧下，採集鏈路從 0.1 到1.0版本，我們做了三件事情：
第一是通道分離，解決了資料順序傳送、高低優通道傳送問題。
第二是通過 logpusher 將實時與離線採集鏈路分離，解決了 Kafka 儲存資源浪費的問題和資料快速恢復的問題。
第三是增加 Bus 層，解決了連線數收斂、資料緩衝、資料轉發的問題。

通過以上幾個版本的演進，我們的吞吐量從最初的 80 w/s提升到 360 w/s，採集鏈路也算維持在一個比較穩定的狀態。

5、 採集鏈路 V2.0 架構

我們曾經還遇到過核心交換機故障的問題和機房級掉電故障問題。出現這些問題會導致整個採集鏈路癱瘓，同時也暴露了採集鏈路在機房級容災能力上的不足。基於這兩個問題我們開啟了採集鏈路 2.0。

從採集鏈路 2.0 架構圖中可以看出，我們在採集鏈路的各個元件上都增加了 failover 處理機制。Agent 預設將資料發往本機房的 Bus，當本機房 Bus 異常時 Agent 會將資料傳送到備用的 Bus叢集，後面的 Bus 也是如此。如果 Kafka 故障，Bus 具備將資料發往備用 Kafka 叢集的能力，當然這個依賴於具體的配置。

採集鏈路 2.0 除了鏈路層的修改之外，還增加了一個平臺管控的 manager。這個 manger 主要用於資料接入管理、運營操作管控、指標監控預警及許可權管控。通過 manger 將資料接入、運營操作平臺化，全鏈路指標對賬視覺化。

6、採集鏈路 V3.0

經過採集鏈路 2.0 之後，我們的採集鏈路不管在接入效率還是在鏈路容災能力上都顯著提升。在採集鏈路穩定之後，接下來我們要做的就是如何將採集鏈路的後設資料管控起來。這個就是採集鏈路 3.0 版本的主要工作。

採集鏈路 3.0 主要是做資料運營。所謂資料運營就是讓資料管理員知道資料是誰在生產，誰採集、誰負責、誰授權、誰消費。資料運營就是告知資料管理者資料從哪裡來，到哪裡去。比如這張圖可以看出資料是誰負責，以及資料的上下游；接下來這張圖是一個採集任務檢視，顯示了資料是誰在生產。

到此為止，我們平臺經歷了三個大的版本迭代，資料生產平臺具備了高吞吐的資料採集能力、機房級鏈路容災能力和平臺化的資料管理能力。

那麼接下來我們還有什麼規劃呢?

四、未來規劃與展望

1、ETL 平臺任務配置化和自助測試功能

前面的內容主要介紹資料採集，對於資料生產平臺，還有一個重要的資料清洗 ETL 平臺。ETL 任務負責將 HDFS 資料按照業務需求處理併入庫到 HIVE，以供後面的資料分析與資料統計。

當前的 ETL 任務存在兩個問題，一個是重複性編碼工作，一個是 ETL 邏輯測試驗證困難。

基於以上兩個問題 ，ETL 排程平臺打算提供兩個能力，一個是 ETL 任務配置自動化的能力，第二個是 ETL 任務自助測試的能力。

ETL 任務配置生成，是依賴於程式碼動態注入，這樣可以把重複的邏輯抽取，提高 ETL 任務的開發效率。

ETL 任務測試能力，是讓使用者在上線 ETL 任務之前，可以引入少量的資料來驗證 ETL 任務的邏輯，進而提高線上ETL 任務的質量。

2、大資料平臺內部子系統實現資料共享

除了 ETL 的規劃外，我們還計劃將整個大資料平臺打通。

對於大資料平臺而言主要有兩種角色的使用者，一種是資料分析人員，一種是資料開發人員。

當資料分析人員有一個新的需求時，資料分析人員需要先設計埋點，讓前端開發者按照埋點上報資料；然後資料分析人員告知資料開發人員配置資料採集任務和資料統計任務，資料開發人員配置完整之後再告知資料分析人員可以開始使用資料。

在整個過程中首先是溝通成本比較高，如果資料開發者理解有偏差或者資料分析師表達不到位，都會造成採集的資料和計算的結果不滿足要求；另外整個資料分析的鏈路太長，人為干預太多。

為了解決以上問題，我們想將這幾個平臺打通，讓平臺直接做資料共享，減少人為溝通。

假設有一個新的埋點需求，埋點系統自動推送到採集系統，採集系統自動建立採集任務，同時資料分析人員建立資料分析的任務後，將分析任務推送到資料開發平臺生成資料開發任務。當埋點資料變更時，自動通知下游變更。整個大資料平臺的變更做到自動傳導與傳遞。

通過大資料平臺內部子系統直接的資料共享可以提高新的資料分析接入效率和分析任務變更的效率。

以上，就是本次主題分享實錄。

Q & A

1、我發現 Bus 基本上是通過 Flume 叢集來實現的，那是不是可以直接通過 Flume 開發？
答：我們的 Bus 是基於 Flume 的二次開發。我們知道 Flume 裡面有幾種常用的Channel：File Channel，Kafka Channel，Spillable Memory Channel；但是這幾種都不能滿足我們資料落盤然後非同步傳送的需求，落盤資料傳送不影響正常採集鏈路的需求；另外我們需要自定義配置化的資料分發，所以我們需要對原生 flume 進行改造。

2、資料分析從模型到落地，如何提供比較高效的方式？
答：對於資料分析需要經歷四個過程：資料的埋點、資料採集、資料開發和資料分析。這個過程中，阻礙我們整個資料分析的效率比較低的是溝通。如果資料分析人員不懂工程，而資料開發工程師不懂業務，就會導致兩邊溝通起來有障礙。我們在平臺後設資料做共享，埋點平臺有新的任務時自動通知採集平臺生成採集任務，這會減少人力溝通成本，提高接入效率。

3、關於 Bus 節點，我想了解下你們如何設計 Bus 節點的高可用？
答：這裡的 Bus 是允許當機的，如果你的 Bus 掛掉了幾臺，Agent 自動重連到其他的 Bus 節點。Agent 可以設定在一個時間段內做重連。比如說我們發現後面的 Bus 連線不均衡了，開啟 Agent 重連，當監控連線均衡之後關閉掉重連。
當然 Agent 也不能一直做重連，因為重連會對效能有影響。

更多內容敬請關注 vivo網際網路技術微信公眾號

注：轉載文章請先與微訊號：labs2020 聯絡。