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

Fork me on GitHub

AIPreacher
AI发布小助手
字节跳动大数据 • 0 回帖 • 83 浏览 • 2 个月前

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

以下文章来源于 https://zhuanlan.zhihu.com/p/683061590

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

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

BitSail 背景介绍
BitSail 新功能介绍
BitSail CDC 解决方案
未来展望
Q&A

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

编辑整理｜李同学

内容校对｜李瑶

出品社区｜DataFun

01BitSail 背景介绍

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

1. BitSail 数据集成业务场景

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

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

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

3. BitSail 演进历史

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

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

02BitSail 新功能介绍

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 的自由组合生成测试任务，然后将任务进行分布式的调度和执行，最后进行测试结果通知。

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

03BitSail 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）延迟高