​桔妹导读： 滴滴数据通道引擎承载着全公司的数据同步，为上游实时和离线场景提供了必不可少的源数据。随着任务量的一直减少，数据通道的整体架构也随之产生扭转。本文介绍了滴滴数据通道的倒退历程，遇到的问题以及今后的布局。

1. 背景

数据，对于任何一家互联网公司来说都是十分重要的资产，公司的大数据部门致力于解决如何更好的应用数据，开掘数据价值，而数据通道服务作为“大数据”的前置链路，始终以来都在默默的为公司提供及时，残缺的数据服务，这里咱们对滴滴数据通道的演进做一个全面的介绍。

2. 数据通道简介

数据通道服务，顾名思义，是数据的通路，负责将数据从 A 同步到 B 的一套解决方案。

异构数据的同步是公司很多业务的广泛需要，通道服务也就成为了一项根底服务。包含但不限于日志，Binlog 同步到上游各类存储和引擎中，如 HIVE，ES，HBase 等，用于报表，经营等场景。

数据通道计划自身波及的组件很多，链路也比较复杂，这里通过一个简化的有向图来介绍下通道的外围流程。

有向图的顶点示意存储，包含磁盘，音讯队列以及各种存储服务，边和方向示意数据流量，而数据流动的能源则是边上的各个同步引擎。仅从图中的链路能够看出，根底组件包含以下几种：

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

滴滴技术 出品