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

1.?

背景

數(shù)據(jù)，對于任何一家互聯(lián)網(wǎng)公司來說都是非常重要的資產(chǎn)，公司的大數(shù)據(jù)部門致力于解決如何更好的使用數(shù)據(jù)，挖掘數(shù)據(jù)價值，而數(shù)據(jù)通道服務作為“大數(shù)據(jù)”的前置鏈路，一直以來都在默默的為公司提供及時，完整的數(shù)據(jù)服務，這里我們對滴滴數(shù)據(jù)通道的演進做一個全面的介紹。

2.?

數(shù)據(jù)通道簡介

數(shù)據(jù)通道服務，顧名思義，是數(shù)據(jù)的通路，負責將數(shù)據(jù)從A同步到B的一套解決方案。

異構(gòu)數(shù)據(jù)的同步是公司很多業(yè)務的普遍需求，通道服務也就成為了一項基礎(chǔ)服務。包括但不限于日志，Binlog同步到下游各類存儲和引擎中，如HIVE，ES，HBase等，用于報表，運營等場景。

數(shù)據(jù)通道方案本身涉及的組件很多，鏈路也比較復雜，這里通過一個簡化的有向圖來介紹下通道的核心流程。

有向圖的頂點表示存儲，包括磁盤，消息隊列以及各種存儲服務，邊和方向表示數(shù)據(jù)流量，而數(shù)據(jù)流動的動力則是邊上的各個同步引擎。

僅從圖中的鏈路可以看出，基礎(chǔ)組件包括以下幾種：

組件名稱	組件說明
容器	業(yè)務方運行的容器是數(shù)據(jù)產(chǎn)生的地方，是異構(gòu)數(shù)據(jù)的原始數(shù)據(jù)，包括業(yè)務日志和Binlog等。
Agent	Agent負責數(shù)據(jù)采集，常見的遠端數(shù)據(jù)包括普通日志和Binlog，Agent負責將這類數(shù)據(jù)采集后發(fā)送到消息隊列中，通過讀取文件，并記錄offset的方式，保證至少一次的數(shù)據(jù)采集服務。
Kafka	消息隊列的加入主要用于數(shù)據(jù)復用，削峰填谷以及上下游解耦。采集一份數(shù)據(jù)，多個下游可以根據(jù)需要消費后自行處理，同時借用消息隊列的高吞吐能力，減少上下游的耦合，在流量突增的時候可以起到緩沖的效果。
DSink	DSink組件是公司內(nèi)對數(shù)據(jù)投遞服務的簡稱，主要負責消費MQ數(shù)據(jù)投遞到下游存儲，通過消息隊列的OffSet保證至少一次的數(shù)據(jù)投遞。
ES/HDFS	存儲引擎，異構(gòu)數(shù)據(jù)通過上述投遞服務，完成結(jié)構(gòu)化處理，投遞到下游存儲中，供業(yè)務方使用。
ETL	?寫入HDFS數(shù)據(jù)一般來說都是作為業(yè)務方ETL的輸入，經(jīng)過自定義的處理邏輯后寫入HIVE，供分析和計算使用。
數(shù)據(jù)倉庫	數(shù)據(jù)倉庫中保存結(jié)構(gòu)化的數(shù)據(jù)，方便業(yè)務系統(tǒng)或者下游級聯(lián)使用。
各類業(yè)務系統(tǒng)	業(yè)務系統(tǒng)直接對接ES或者數(shù)據(jù)倉庫，提供線上或者準線上服務。

3.?

數(shù)據(jù)通道服務的演進

數(shù)據(jù)通道致力于解決異構(gòu)數(shù)據(jù)同步的問題，從開始構(gòu)建到現(xiàn)在，經(jīng)歷了組件平臺化，服務化，產(chǎn)品化，引擎升級和智能化幾個階段，每個階段都面臨著各種各樣的問題，而問題的解決都伴隨著系統(tǒng)穩(wěn)定性，可靠性的提升。

▍3.1 組件平臺化

目標：更好地服務業(yè)務

數(shù)據(jù)通道構(gòu)建初期，各個組件各自維護，為業(yè)務方提供數(shù)據(jù)服務，業(yè)務有需求過來的時候各個組件快速啟動一個進程就可以為業(yè)務方提供一個端到端的數(shù)據(jù)通路，業(yè)務拿到數(shù)據(jù)就可以分析計算，完整相關(guān)的業(yè)務指標。

隨著業(yè)務發(fā)展，需求不斷增多，經(jīng)過了一段時間的野蠻增長后，通道的任務數(shù)也水漲船高，大量的任務需要規(guī)范的平臺來管控，因此在通道服務活下來以后第一件需要做的事就是組件平臺化，這么多任務需要有一個統(tǒng)一的管控平臺管理起來，方便根據(jù)用戶的需求，新建修改或者刪除任務。

▍3.2?服務化

目標：承諾SLA

面臨問題：如何保證各個環(huán)節(jié)的At Least Once

數(shù)據(jù)的完整性和及時性是下游服務關(guān)注的重點，完整性是基礎(chǔ)，在這之上盡可能保障及時性。對于下游來說，可以容忍短暫的延遲，但是不能數(shù)據(jù)數(shù)據(jù)不準確的情況，因此，自下而上的，通道服務要為自己同步的數(shù)據(jù)負責。

要為下游提供一致性服務，一方面需要各個組件能夠提供At Least Once的語義保證，另外一方面則需要一個數(shù)據(jù)質(zhì)量中心對外提供數(shù)據(jù)質(zhì)量服務。

介紹一個簡單的場景：DSink在數(shù)據(jù)同步過程中如何實現(xiàn)At Least Once

數(shù)據(jù)投遞服務DSink是消費MQ消息，投遞到下游存儲，MQ以Kakfa為例，DSink在投遞的過程中是異步多線程同時投遞，那怎么保證數(shù)據(jù)投遞完成之后提交準確的offset呢，畢竟一個partition的數(shù)據(jù)會分不到多個線程中同時投遞，投遞的下游可能會因為網(wǎng)絡(luò)或者壓力的原因失敗，還需要重試。

方案一：

一批數(shù)據(jù)都投遞完成后再繼續(xù)消費，也就是全部投遞成功之前阻塞上游消費，這樣可以保證提交的offset是準確的。但是這樣就會有性能問題，在日志場景下會嚴重影響性能。

方案二（DSink采用方案）：

使用TreeMap保存offset，Map的value為一個范圍，A-B的offset范圍，Key則為這個范圍的最小值A(chǔ)，每次有一個partition的offset處理成功后則加入到TreeMap中，具體過程如下：

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

offset經(jīng)過這種處理，可以保證每次提交的offset都是準確的，完成投遞的數(shù)據(jù)，基于此，DSink實現(xiàn)了At Least Once語義。

▍3.3?產(chǎn)品化

目標：提升用戶體驗

數(shù)據(jù)通道服務漸漸完善后，接入的需求也越來越多，遇到的問題也與日俱增，比較直觀的一點就是答疑量上升，一方面用戶需求的接入是通過郵件或者釘釘，開發(fā)同學需要根據(jù)需求手動創(chuàng)建任務；另一方面用戶的不規(guī)范配置會影響任務運行，當數(shù)據(jù)不產(chǎn)出或者產(chǎn)出有問題時需要引擎同學定位解決，答疑的大部分精力都耗在這些問題之上。

數(shù)據(jù)通道服務是隨著公司發(fā)展一起發(fā)展起來的，眾所周知，在發(fā)展初期，缺乏各種規(guī)范，業(yè)務方的日志或者MySql表差異很大，遵循的規(guī)范也是五花八門，或者根本就沒有規(guī)范，為了數(shù)據(jù)通道服務的標準化和自動化，我們通過產(chǎn)品的方式規(guī)范用戶數(shù)據(jù)，符合我們規(guī)范的數(shù)據(jù)可以自動接入，而其他亂七八糟的格式則需要整改后再接入。

為了解決這些問題，數(shù)據(jù)通道孵化了統(tǒng)一的接入平臺——同步中心，在該平臺之上用戶通過點擊配置的方式完成任務創(chuàng)建，同步中心會將用戶需求拆分到各個通道引擎管控平臺，各個管控平臺再根據(jù)配置自行創(chuàng)建任務運行，最后回調(diào)同步中心，整個過程實現(xiàn)自動化。

經(jīng)過這一改造，任務創(chuàng)建時間從原來的平均幾個小時降到5-10分鐘，極大的提升了用戶體驗。

▍3.4?引擎升級——Flink（StreamSQL）

目標：降成本，模板化

DSink組件運行在公司的統(tǒng)一的容器內(nèi)，在申請容器的時候為了減少碎片及便于管理，容器的規(guī)格只有固定的幾種，如4C8G，8C16G，16C32G等，不同的任務都只能在這些規(guī)格中選擇，這樣就會導致資源的浪費，比如一個需要10個VCORE的任務，就只能申請16C的容器，大部分情況CPU會空閑一部分，同時內(nèi)存也只能浪費。

引擎升級，將投遞組件升級到Flink引擎之上主要有以下收益：

Flink是基于yarn來調(diào)度資源，最小的單位是1C1G，通過計算，可以對每一個任務的資源進行精準控制，盡可能的減少資源浪費。

投遞引擎切換到StreamSQL后，所有任務都通過SQL表達，統(tǒng)一了任務模版。

StreamSQL的UDF特性可以支持用戶自定義解析邏輯，基礎(chǔ)SQL可以支持寫入下游ES或者HDFS等存儲，而用戶邏輯增加UDF后即可直接寫入。這一方面減少用戶重復開發(fā)的工作量，另一方面也拓展了數(shù)據(jù)通道的服務范圍。

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

▍3.5?智能化（進行中）

目標：問題診斷與數(shù)據(jù)治理

隨著任務數(shù)的接入越來越多，不可避免的，引擎的各類問題也越來越多，當前主要是用戶問題驅(qū)動或者延遲告警來發(fā)現(xiàn)問題，之后依賴于各個引擎的指標大盤定位問題，再由人工來解決各類引擎問題。實際上當前有相當一部分簡單問題是可以自動化處理的，比如資源不足，如果發(fā)現(xiàn)延遲的原因是資源不足，則可以直接擴資源即可。

鑒于此，我們規(guī)劃了一套問題發(fā)現(xiàn)與自動化處理的智能診斷與解決方案——LogX，期望基于這個方案可以解決引擎?zhèn)?0%的日常問題。

LogX組件的職責如下：

統(tǒng)籌整個鏈路資源，根據(jù)用戶任務，分配各個下游引擎資源

問題診斷和自動化處理——基于各類指標，完成問題智能分析和診斷，對于常見問題可以自動化處理，減少人工干預

全鏈路血緣建設(shè)——根據(jù)血緣關(guān)系識別重點項目，分級保障

全鏈路數(shù)據(jù)治理——基于血緣關(guān)系完成數(shù)據(jù)治理，減少不比要的任務，進一步提升資源利用率

因為涉及到各個引擎的指標與自動化，當前該組件正在持續(xù)推進中，相信不久就可以作為通道的核心服務之一服務于引擎和公司業(yè)務了。

4.?

總結(jié)

數(shù)據(jù)通道服務承載著全公司的數(shù)據(jù)同步，絕大部分離線任務的數(shù)據(jù)源都是通道服務投遞的，可以說當前的通道服務是整個滴滴數(shù)據(jù)的大動脈。經(jīng)過這幾年的發(fā)展，通道服務也逐漸趨于完善，持續(xù)穩(wěn)定的為公司提供數(shù)據(jù)采集和投遞服務。

團隊介紹

?

滴滴云平臺事業(yè)群滴滴大數(shù)據(jù)架構(gòu)部實時數(shù)據(jù)引擎組負責Flink流批一體計算、Kafka消息隊列、日志采集與通道等核心數(shù)據(jù)引擎的研發(fā)與應用，承擔全公司的數(shù)據(jù)采集、投遞以及實時計算任務， 致力于打造穩(wěn)定可靠、高性能、低成本的計算與通道服務。

作者介紹

?

專注于大數(shù)據(jù)實時引擎技術(shù)，致力于數(shù)據(jù)通道全鏈路建設(shè)，基于各類實時引擎，為公司提供穩(wěn)定，可靠，高效，及時的數(shù)據(jù)通道服務。

延伸閱讀

?

內(nèi)容編輯 | Charlotte聯(lián)系我們 | DiDiTech@didiglobal.com

總結(jié)

以上是生活随笔為你收集整理的滴滴数据通道服务演进之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。