桔妹導讀：滴滴數據通道引擎承載着全公司的數據同步，為下游實時和離線場景提供了必不可少的源數據。隨着任務量的不斷增加，數據通道的整體架構也隨之發生改變。本文介紹了滴滴數據通道的發展歷程，遇到的問題以及今后的規划。
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組件的職責如下：
- 統籌整個鏈路資源，根據用戶任務，分配各個下游引擎資源
- 問題診斷和自動化處理——基於各類指標，完成問題智能分析和診斷，對於常見問題可以自動化處理，減少人工干預
- 全鏈路血緣建設——根據血緣關系識別重點項目，分級保障
- 全鏈路數據治理——基於血緣關系完成數據治理，減少不比要的任務，進一步提升資源利用率
因為涉及到各個引擎的指標與自動化，當前該組件正在持續推進中，相信不久就可以作為通道的核心服務之一服務於引擎和公司業務了。
4. 總結
數據通道服務承載着全公司的數據同步，絕大部分離線任務的數據源都是通道服務投遞的，可以說當前的通道服務是整個滴滴數據的大動脈。經過這幾年的發展，通道服務也逐漸趨於完善，持續穩定的為公司提供數據采集和投遞服務。
團隊介紹
滴滴雲平台事業群滴滴大數據架構部實時數據引擎組負責Flink流批一體計算、Kafka消息隊列、日志采集與通道等核心數據引擎的研發與應用，承擔全公司的數據采集、投遞以及實時計算任務， 致力於打造穩定可靠、高性能、低成本的計算與通道服務。
作者介紹
**
專注於大數據實時引擎技術，致力於數據通道全鏈路建設，基於各類實時引擎，為公司提供穩定，可靠，高效，及時的數據通道服務。
延伸閱讀
內容編輯 | Charlotte
聯系我們 | DiDiTech@didiglobal.com
本文由博客群發一文多發等運營工具平台 OpenWrite 發布