滴滴資料通道服務演進之路

滴滴技術發表於2020-08-28

桔妹導讀：滴滴資料通道引擎承載著全公司的資料同步，為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加，資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程，遇到的問題以及今後的規劃。

1. 背景

資料，對於任何一家網際網路公司來說都是非常重要的資產，公司的大資料部門致力於解決如何更好的使用資料，挖掘資料價值，而資料通道服務作為“大資料”的前置鏈路，一直以來都在默默的為公司提供及時，完整的資料服務，這裡我們對滴滴資料通道的演進做一個全面的介紹。

2. 資料通道簡介

資料通道服務，顧名思義，是資料的通路，負責將資料從A同步到B的一套解決方案。

異構資料的同步是公司很多業務的普遍需求，通道服務也就成為了一項基礎服務。包括但不限於日誌，Binlog同步到下游各類儲存和引擎中，如HIVE，ES，HBase等，用於報表，運營等場景。

資料通道方案本身涉及的元件很多，鏈路也比較複雜，這裡通過一個簡化的有向圖來介紹下通道的核心流程。

有向圖的頂點表示儲存，包括磁碟，訊息佇列以及各種儲存服務，邊和方向表示資料流量，而資料流動的動力則是邊上的各個同步引擎。僅從圖中的鏈路可以看出，基礎元件包括以下幾種：

元件名稱	元件說明
容器	業務方執行的容器是資料產生的地方，是異構資料的原始資料，包括業務日誌和Binlog等。
Agent	Agent負責資料採集，常見的遠端資料包括普通日誌和Binlog，Agent負責將這類資料採集後傳送到訊息佇列中，通過讀取檔案，並記錄offset的方式，保證至少一次的資料採集服務。
Kafka	訊息佇列的加入主要用於資料複用，削峰填谷以及上下游解耦。採集一份資料，多個下游可以根據需要消費後自行處理，同時借用訊息佇列的高吞吐能力，減少上下游的耦合，在流量突增的時候可以起到緩衝的效果。
DSink	DSink元件是公司內對資料投遞服務的簡稱，主要負責消費MQ資料投遞到下游儲存，通過訊息佇列的OffSet保證至少一次的資料投遞。
ES/HDFS	儲存引擎，異構資料通過上述投遞服務，完成結構化處理，投遞到下游儲存中，供業務方使用。
ETL	寫入HDFS資料一般來說都是作為業務方ETL的輸入，經過自定義的處理邏輯後寫入HIVE，供分析和計算使用。
資料倉儲	資料倉儲中儲存結構化的資料，方便業務系統或者下游級聯使用。
各類業務系統	業務系統直接對接ES或者資料倉儲，提供線上或者準線上服務。

3. 資料通道服務的演進

資料通道致力於解決異構資料同步的問題，從開始構建到現在，經歷了元件平臺化，服務化，產品化，引擎升級和智慧化幾個階段，每個階段都面臨著各種各樣的問題，而問題的解決都伴隨著系統穩定性，可靠性的提升。

3.1 元件平臺化

目標：更好地服務業務

資料通道構建初期，各個元件各自維護，為業務方提供資料服務，業務有需求過來的時候各個元件快速啟動一個程式就可以為業務方提供一個端到端的資料通路，業務拿到資料就可以分析計算，完整相關的業務指標。隨著業務發展，需求不斷增多，經過了一段時間的野蠻增長後，通道的任務數也水漲船高，大量的任務需要規範的平臺來管控，因此在通道服務活下來以後第一件需要做的事就是元件平臺化，這麼多工需要有一個統一的管控平臺管理起來，方便根據使用者的需求，新建修改或者刪除任務。

3.2 服務化

目標：承諾SLA

面臨問題：如何保證各個環節的At Least Once資料的完整性和及時性是下游服務關注的重點，完整性是基礎，在這之上儘可能保障及時性。對於下游來說，可以容忍短暫的延遲，但是不能資料資料不準確的情況，因此，自下而上的，通道服務要為自己同步的資料負責。要為下游提供一致性服務，一方面需要各個元件能夠提供At Least Once的語義保證，另外一方面則需要一個資料質量中心對外提供資料質量服務。

介紹一個簡單的場景：DSink在資料同步過程中如何實現At Least Once資料投遞服務DSink是消費MQ訊息，投遞到下游儲存，MQ以Kakfa為例，DSink在投遞的過程中是非同步多執行緒同時投遞，那怎麼保證資料投遞完成之後提交準確的offset呢，畢竟一個partition的資料會分不到多個執行緒中同時投遞，投遞的下游可能會因為網路或者壓力的原因失敗，還需要重試。方案一：一批資料都投遞完成後再繼續消費，也就是全部投遞成功之前阻塞上游消費，這樣可以保證提交的offset是準確的。但是這樣就會有效能問題，在日誌場景下會嚴重影響效能。方案二（DSink採用方案）：使用TreeMap儲存offset，Map的value為一個範圍，A-B的offset範圍，Key則為這個範圍的最小值A，每次有一個partition的offset處理成功後則加入到TreeMap中，具體過程如下：

定時提交offset時只需要獲取Map中第一個Entry value的結束offset進行提交即可。

offset經過這種處理，可以保證每次提交的offset都是準確的，完成投遞的資料，基於此，DSink實現了At Least Once語義。

3.3 產品化

目標：提升使用者體驗

資料通道服務漸漸完善後，接入的需求也越來越多，遇到的問題也與日俱增，比較直觀的一點就是答疑量上升，一方面使用者需求的接入是通過郵件或者釘釘，開發同學需要根據需求手動建立任務；另一方面使用者的不規範配置會影響任務執行，當資料不產出或者產出有問題時需要引擎同學定位解決，答疑的大部分精力都耗在這些問題之上。資料通道服務是隨著公司發展一起發展起來的，眾所周知，在發展初期，缺乏各種規範，業務方的日誌或者MySql表差異很大，遵循的規範也是五花八門，或者根本就沒有規範，為了資料通道服務的標準化和自動化，我們通過產品的方式規範使用者資料，符合我們規範的資料可以自動接入，而其他亂七八糟的格式則需要整改後再接入。為了解決這些問題，資料通道孵化了統一的接入平臺——同步中心，在該平臺之上使用者通過點選配置的方式完成任務建立，同步中心會將使用者需求拆分到各個通道引擎管控平臺，各個管控平臺再根據配置自行建立任務執行，最後回撥同步中心，整個過程實現自動化。經過這一改造，任務建立時間從原來的平均幾個小時降到5-10分鐘，極大的提升了使用者體驗。

3.4 引擎升級——Flink（StreamSQL）

目標：降成本，模板化

DSink元件執行在公司的統一的容器內，在申請容器的時候為了減少碎片及便於管理，容器的規格只有固定的幾種，如4C8G，8C16G，16C32G等，不同的任務都只能在這些規格中選擇，這樣就會導致資源的浪費，比如一個需要10個VCORE的任務，就只能申請16C的容器，大部分情況CPU會空閒一部分，同時記憶體也只能浪費。引擎升級，將投遞元件升級到Flink引擎之上主要有以下收益：

Flink是基於yarn來排程資源，最小的單位是1C1G，通過計算，可以對每一個任務的資源進行精準控制，儘可能的減少資源浪費。
投遞引擎切換到StreamSQL後，所有任務都通過SQL表達，統一了任務模版。StreamSQL的UDF特性可以支援使用者自定義解析邏輯，基礎SQL可以支援寫入下游ES或者HDFS等儲存，而使用者邏輯增加UDF後即可直接寫入。這一方面減少使用者重複開發的工作量，另一方面也擴充了資料通道的服務範圍。

通過這一次引擎升級，通道任務從原來的400臺物理機，切換到StreamSQL，只需要約250臺物理機。CPU的峰值利用率也從不到30%提升到60%+。

3.5 智慧化（進行中）

目標：問題診斷與資料治理

隨著任務數的接入越來越多，不可避免的，引擎的各類問題也越來越多，當前主要是使用者問題驅動或者延遲告警來發現問題，之後依賴於各個引擎的指標大盤定位問題，再由人工來解決各類引擎問題。實際上當前有相當一部分簡單問題是可以自動化處理的，比如資源不足，如果發現延遲的原因是資源不足，則可以直接擴資源即可。鑑於此，我們規劃了一套問題發現與自動化處理的智慧診斷與解決方案——LogX，期望基於這個方案可以解決引擎側80%的日常問題。LogX元件的職責如下：