滴滴數據通道服務演進之路

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

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引擎之上主要有如下收益：

1. Flink是基於yarn來調度資源，最小的單位是1C1G，經過計算，能夠對每個任務的資源進行精準控制，儘量的減小資源浪費。
2. 投遞引擎切換到StreamSQL後，全部任務都經過SQL表達，統一了任務模版。
   StreamSQL的UDF特性能夠支持用戶自定義解析邏輯，基礎SQL能夠支持寫入下游ES或者HDFS等存儲，而用戶邏輯增長UDF後便可直接寫入。這一方面減小用戶重複開發的工做量，另外一方面也拓展了數據通道的服務範圍。
   
   

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

▍ 3.5  智能化（進行中）

目標：問題診斷與數據治理

隨着任務數的接入愈來愈多，不可避免的，引擎的各種問題也愈來愈多，當前主要是用戶問題驅動或者延遲告警來發現問題，以後依賴於各個引擎的指標大盤定位問題，再由人工來解決各種引擎問題。實際上當前有至關一部分簡單問題是能夠自動化處理的，好比資源不足，若是發現延遲的緣由是資源不足，則能夠直接擴資源便可。

鑑於此，咱們規劃了一套問題發現與自動化處理的智能診斷與解決方案——LogX，指望基於這個方案能夠解決引擎側80%的平常問題。

LogX組件的職責以下：

1. 統籌整個鏈路資源，根據用戶任務，分配各個下游引擎資源
2. 問題診斷和自動化處理——基於各種指標，完成問題智能分析和診斷，對於常見問題能夠自動化處理，減小人工干預
3. 全鏈路血緣建設——根據血緣關係識別重點項目，分級保障
4. 全鏈路數據治理——基於血緣關係完成數據治理，減小不比要的任務，進一步提高資源利用率

由於涉及到各個引擎的指標與自動化，當前該組件正在持續推動中，相信不久就能夠做爲通道的核心服務之一服務於引擎和公司業務了。

4. 

總結

數據通道服務承載着全公司的數據同步，絕大部分離線任務的數據源都是通道服務投遞的，能夠說當前的通道服務是整個滴滴數據的大動脈。通過這幾年的發展，通道服務也逐漸趨於完善，持續穩定的爲公司提供數據採集和投遞服務。

團隊介紹

▬

滴滴雲平臺事業羣 滴滴大數據架構部實時數據引擎組負責Flink流批一體計算、Kafka消息隊列、日誌採集與通道等核心數據引擎的研發與應用，承擔全公司的數據採集、投遞以及實時計算任務， 致力於打造穩定可靠、高性能、低成本的計算與通道服務。

做者介紹

▬

專一於大數據實時引擎技術，致力於數據通道全鏈路建設，基於各種實時引擎，爲公司提供穩定，可靠，高效，及時的數據通道服務。

延伸閱讀

▬

             
 
 
              
 
               
 
              
 
 
              
 
               內容編輯 | Charlotte 
              
 
 
              
 
               聯繫咱們 | DiDiTech@didiglobal.com 
              
 
 
              
 
               
 
              
 
 
              
 
               
 

             

本文分享自微信公衆號 - 滴滴技術（didi_tech）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。