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

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組件的職責如下：