字节跳动数据集成引擎 BitSail 开源架构演进和实践

导读 随着大数据的快速发展，在数据建设的过程中通常需要把数据从 A 系统导入 B 系统，我们称之为数据集成。数据集成是数据建设的基础，主要解决以后数据源间数据传输、加工和处理的问题。本文将介绍字节跳动数据集成引擎 BitSail 开源架构的演进和实践。

今天的介绍会围绕下面几点展开：

1. BitSail 背景介绍

2. BitSail 新功能介绍

3. BitSail CDC 解决方案

4. 未来展望

5. Q&A

分享嘉宾｜李畅 字节跳动 字节跳动大数据工程师 

编辑整理｜李同学

内容校对｜李瑶

出品社区｜DataFun

---

01

BitSail 背景介绍

首先和大家分享下 BitSail 建设的背景。

1. BitSail 数据集成业务场景

BitSail 主要致力于将数据高效地传输到能实现其价值的地方。如，将终端数据、物联网设备数据、数据库数据传输用于支撑广告业务、推荐系统、机器学习、实时分析系统等，从而进一步发掘数据价值。

2. BitSail 的基础能力和业务案例

BitSail 中文名为“比特航行”，是字节跳动开源的分布式、高性能数据集成引擎，支持多种异构数据源间的离线、实时、全量、增量数据同步。目前已经服务于字节内部几乎所有业务线，经过了抖音、头条等海量数据的业务场景和云原生、私有云等部署环境的验证。

3. BitSail 演进历史

2018 年前，字节内部无统一数据集成框架，M*N 的数据源需要各自实现数据同步通道。2019 年基于 Flink 引擎统一架构，完成了批式场景数据集成框架统一。2020 年覆盖流式场景，实现批流架构统一。2021 年支持了数据湖集成，基于 Flink+Hudi 实现数据准实时入湖。2022 年经过海量数据和多业务场景验证，BitSail 拥抱开源，将通用数据集成能力对外输出。

下面将重点分享过去一年 BitSail 的新功能。

02

BitSail 新功能介绍

1. BitSail 数据同步架构

BitSail 整体框架分为三层，包括 Connector 层、框架层、引擎层，整体覆盖离线、实时、全量、增量数据同步场景。

Connector 层又叫数据源层，负责对接包括输入和输出的离线关系型数据库、实时的消息队列、Hive 和 ClickHouse 等大数据存储组件。

框架层提供数据源类型转换、脏数据处理、流控、自动并发度推算、运行监控等丰富的基础支撑能力。

引擎层负责最终的分布式任务调度、数据传输工作。

整体上覆盖了离线、实时和增量数据同步场景。

2. BitSail 代码结构

基于 BitSail 数据同步架构，其代码在结构上也主要分为 Connector、框架和引擎层，各层通过可插拔的模式进行组合。

3. 多引擎架构

BitSail 和 Flink 引擎深度绑定，依赖较重，导致运维成本高，且业务场景受限。Flink 定位为通用计算引擎，其优势在于计算和状态处理能力，而数据集成偏数据读写 IO 场景，存在大量的计算资源浪费。

针对上述问题，解决思路为：

• 引擎基于可插拔设计，支持轻量化的分布式计算引擎；
• Connector 提供引擎无关的读写接口；
• 框架层与引擎解耦。

（1）Source API

数据读取组件（Source API）主要包括 Split Coordinator 和 Source Reader。

Split 是数据处理的最小分片。

Split Coordinator 主要负责创建和管理数据分片（Split），并将数据分片分发给Source Reader。

Source Reader 是真正负责数据读取的组件，它在接收到 Split Coordinator 分发给它的数据分片（Split）后对其进行读取，并将数据传输给下一个算子。

（2）Sink API

数据写入组件（Sink API）主要包括 Writer 和 Writer Committer，其中 Writer Committer 为可选算子。

Writer 主要负责将接收到的数据写到外部存储。

Writer Committer 用于对数据进行提交操作，基于两阶段提交，实现 Exactly –Once 的语义，保障异常场景下数据的准确恢复。

（3）API 接口转换

Connector 虽然提供了与引擎无关的读写接口，但最终需要将 Source 和 Sink 接口转换为引擎能够识别的读写接口。Delegate 基于引擎提供了读写插件实现 Source 和 Sink 接口与引擎接口的转换。

4. 数据处理架构演进

数据处理框架经历了不同的阶段：

• ETL 阶段，数据同步和加工揉在一起。
• ELT 阶段，将数据同步和加工分开，使数据处理的过程分工更清晰。
• EtLT 阶段，数据的实时性要求越来越高，因此需要在数据同步时也能做一些轻量化的处理。

BitSail 支持 EtLT 数据处理架构，在 Source 和 Sink 间引入了 Transform 模块，在流批一体的基础上提供如字段级操作和维表关联之类的轻量级数据处理能力。

5. 自动化测试引擎

一开始 BitSail 的设计是整体打一个 Fat 包，但因其产物包太大且包冲突严重，改为 Connector 独立打包，并支持运行时进行动态加载。

然而，由于动态加载会导致在人物启动过程中加载外部依赖包，因此动态加载时存在潜在的包冲突问题导致报错。

因此我们构建了 Connector 自由组合的自动化测试引擎，并打通 CICD 的流程，在代码合并时即进行所有数据源 M*N 的自动化测试，避免将冲突延迟到任务运行时才暴露。

自动化测试主要分为四步。首先进行单数据源的测试用例构建，其次进行 M*N 的自由组合生成测试任务，然后将任务进行分布式的调度和执行，最后进行测试结果通知。

因为测试用例基于数据源进行构建，所以可以在不同引擎进行复用，并兼容离线和实时场景。

03

BitSail CDC 解决方案

1. CDC 背景介绍

CDC 即通过捕获数据变更日志（Binlog），将如 MySQL、SQL Server、PG 等数据源的数据同步到外部系统。相对批数据同步，CDC 数据同步实时性更高，且对线上数据影响更小。

2. CDC 同步使用场景

CDC 数据同步的使用场景包括：

• 对数据进行离线同步到 Hive 和 ClickHouse 等进行数仓建设，进行离线数据分析。
• 将数据同步到 Doris 和 StarRocks 等 MPP 数据库，支持实时看板等准实时分析。
• 将数据同步到如 ES 数据库进行在线搜索数据分析。

3. 离线整库同步解决方案

离线整库数据同步方案主要分为三步：首先将数据进行批量导入，完成数据的全量初始化；然后流式采集实时增量数据；最后将增量数据与全量数据进行合并得出最新的全量数据。

离线同步的数据合并一般提供 T+1 的数据合并，延时高；需要维护离线同步任务、增量同步任务、数据合并任务、全量表、增量表之间的映射关系，复杂度高；在分库分表场景下，数据需要分别进行入仓和合并；因较长的同步链路和乱序，容易导致数据一致性问题。

4. CDC 整库同步解决方案

通过 CDC 进行整库同步主要分为四个阶段：

• 第一阶段，CDC Batch（离线全量）阶段。该阶段进行全量数据导入，主要完成自动建表、一次性全量导入、全量任务调度。
• 第二阶段，增量实时任务阶段。首先通过 Debezium 采集源端 Binlog 日志，并统一数据格式，然后通过 Kafka 等消息队列提供给下游消费或直接同步到下游。
• 第三阶段，通过 Partition 分流器将单表数据融合。
• 第四阶段，通过 Sink 算子将 Change log 数据同步到下游系统。

5. CDC 整库同步解决的问题

（1）延迟高

CDC 整库同步解决方案可以解决离线整库同步延迟高的问题。CDC 整库同步方案，对全量数据批式导入，增量数据以实时消费 Binlog 写入，可根据需求场景调整数据延迟，因此整体上可以达到近实时。以 Doris 和 StarRocks 为例，可以将延迟控制到秒级。

（2）运维成本高

离线整库数据同步任务需要维护多表和多任务的映射关系和较长的任务链路，运维成本高。而 CDC 整库同步提供了自动建表和自动单次单表的数据同步任务调度，同时支持一个任务写入多张下游表，不需要手工维护复杂的映射关系，因此 CDC 整库同步解决方案运维成本更低。

（3）分库分表

CDC 整库同步解决的第三个问题是分库分表的问题。对于全量任务，单个任务读取多个数据源，写入到单张下游表中；对于增量任务，实时采集多个数据源Binlog，写入到单张下游表中。因此 CDC 整库同步，只需要单表任务即可实现分库分表的任务同步。

（4）一致性问题

离线整库同步链路长且乱序容易导致数据一致性问题。CDC 整库同步可以通过Binlog 位点信息和业务自定义排序字段实现字段的严格有序，保证新数据不被旧数据覆盖。

6. CDC 整库同步运行流程

CDC 整库同步主要包括自动建表、全量任务生成、全量任务调度、全量任务执行、增量任务启动、增量任务执行五个步骤。

7. CDC 整库同步运行页面

CDC 整库同步解决方案针对每一个节点实现单表同步，即通过单个流式任务实现整库同步。

04

未来展望

BitSail 后续规划主要包括：

通过提供更多数据源支持，丰富 Connector 生态建设，并提供更轻量的分布式计算引擎，从而提高整体的数据同步效率。

增强 CDC 同步能力，包括自动 DDL 同步，提供端到端数据一致性检验能力等。

05

Q&A

Q1：自研引擎和基于 Flink 引擎资源节省情况及性能对比表现如何？

A1：自研引擎目前还处于探索阶段并未完全成型，目前经过初步 POC 验证，性能提升还不错。

Q2：Flink 计算引擎做数据同步在资源浪费上表现在哪些方面？

A2：Flink 整体框架及依赖较重，计算和状态处理是其优势，但在数据集成阶段主要消耗 IO，主要用到其分布式调度和数据传输能力。

Q3：流控基于记录条数还是字节数？

A3：都支持，可自定义 QPS 和流量信息。

Q4：基于整库同步任务的线上实践经验资源配置、延时表现、全量初始化耗时如何？

A4：在火山引擎有产品化解决方案实现 CDC 整库同步，可以通过向导式配置源和目标完成数据同步任务创建。全量初始化的耗时主要与数据量有关，上游数据量大需要先进行数据分片再同步，具体可以参考火山引擎的最佳实践。

Q5：实时计算中，类似Flink 数据处理的准确性如何保障？

A5：主要考虑从两个层面解决。代码层面，在数据集成框架中的 Exactl-once 语义和 state 处理保障异常场景下数据准确恢复；业务层面，借助离线数据质量保障规则进行实时数据采样和统计分析。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

李畅

字节跳动

字节跳动大数据工程师

专注大规模数据的分布式计算和传输领域，提供高效、可靠的全域数据集成解决方案；开源社区爱好者，BitSail 开源项目负责人之一。

往期推荐

点个在看你最好看