共计 6957 个字符，预计需要花费 18 分钟才能阅读完成。
导读
BitSail 是字节跳动开源数据集成引擎，反对多种异构数据源间的数据同步，并提供离线、实时、全量、增量场景下全域数据集成解决方案，目前撑持了字节外部和火山引擎多个客户的数据集成需要。通过字节跳动各大业务线海量数据的考验，在性能、稳定性上失去较好验证。
10 月 26 日，字节跳动发表 BitSail 我的项目正式在 GitHub 开源，为更多的企业和开发者带来便当，升高数据建设的老本，让数据高效地发明价值。
本篇内容将围绕 BitSail 演讲历程及重点能力解析开展，次要包含以下四个局部：
- 字节跳动外部数据集成背景
- BitSail 技术演进历程
- BitSail 能力解析
-
将来瞻望
字节跳动外部数据集成背景
始终以来，字节跳动都非常重视并贯彻“数据驱动”这一理念，作为数据驱动的一环，数据中台能力的建设至关重要，而这其中，数据集成作为数据中台建设的根底，次要解决了异构数据源的数据传输、加工和解决的问题。
BitSail 源自字节跳动数据平台团队自研的数据集成引擎 DTS（全称 Data Transmission Service，即数据传输服务），最后基于 Apache Flink 实现，至今曾经服务于字节外部业务靠近五年，现已具备批式集成、流式集成和增量集成三类同步模式，并反对分布式程度扩大和流批一体架构，在各种数据量和各种场景下，一个框架即可解决数据集成需要。此外，BitSail 采纳插件式架构，反对运行时解耦，从而具备极强的灵活性，企业能够很不便地接入新的数据源。BitSail 演进历程
1. 全域数据集成引擎演进三阶段
字节跳动数据集成引擎 BitSail 演进的历程能够分为三个阶段：
① 初始期：2018 年以前公司没有对立的数据集成框架，对每个通道都是各自实现，因而依赖的大数据引擎也比拟零散，如 MapReduce、Spark，数据源之间的连贯也是网状连贯，整体的开发和运维老本都比拟高。
② 成长期：能够分为三个小阶段。 - 2018-2019：随着 Flink 生态不断完善，越来越多的公司将 Flink 作为大数据计算引擎的首选，字节跳动也不例外，并在 Flink 上继续摸索，并于 2019 年提出基于 Flink 的异构数据源间传输，实现批式场景的对立。
- 2020-2021：随着 Flink 批流一体的欠缺，字节跳动对原有架构进行较大降级，并笼罩了流式场景，实现批流场景的对立。
-
2021-2022：接入了 Hudi 数据湖引擎，解决 CDC 数据实时同步问题，并提供湖仓一体解决方案。
③ 成熟期：2022 年开始全域数据集成引擎的整体架构曾经稳固，并通过字节跳动外部各业务线生产环境的考验，在性能和稳定性上也失去充沛的保障，于是团队心愿可能将能力对外输入，为更多的企业和开发者带来便当，升高数据建设的老本，让数据高效地发明价值。2. BitSail 数据集成引擎技术架构演进
① 基于 Flink 的异构数据源传输架构
基于 Flink 1.5 DataSet API 实现的异构数据源传输架构，只反对批式场景。框架核心思想是，对原始输出层数据抽象为 BaseInput，次要用于拉取源端的数据；对输入层形象为 BaseOutput，负责将数据写到内部零碎。同时，框架层提供了根底服务，包含类型零碎（Type System）、主动并发度（Auto Parallelism）、流控（Flow Control）、脏数据检测（Dirty Data）等等，并对所有的数据源通道失效。
以下介绍一个批次场景上比拟有意思的性能，也是理论业务中面临的一些痛点。
上图左上局部是原始的 Flink 运行日志，从这个日志里看不到工作进度数据和预测数据，如当前任务运行的百分比、运行实现所需工夫。左下局部则是 Flink UI 界面提供的工作运行的元信息，能够看到读写条数都是 0，从 Flink 引擎角度，因为所有算子作为一个整体是没有输出和输入的，这是正当的，但从用户角度就无奈看到工作整体进度信息和以后解决记录条数，从而导致用户狐疑这个工作是否曾经卡住。
图中左边是革新之后的成果，日志中明确输入以后解决了多少条数、实时进度展现、耗费工夫等等，该性能在字节外部上线后，失去了很多业务的好评。上面介绍一下具体的实现。
首先回顾 Flink Task 的执行过程，与传统的 MapReduce、Spark 的驱动模型不一样，Flink 是以工作驱动，JM 创立好 Split 之后，Task 是常驻运行，一直向 JM 申请新的 Split，只有所有的 Split 解决完之后，Task 才会退出。此时，如果用总的实现的 Task 个数除以总的 Task 个数，进度将呈现肯定水平的失真。
最开始，所有的 Task 都在运行，一直地去拉取 Split，咱们看到的进度会是 0，等到 JM 的 Split 解决完之后，所有的 Task 会集中退出，能够看到进度会忽然跳动到 100%，两头是短少进度信息的。为了解决这个问题，咱们还是要回到数据驱动自身，以 Split 的维度来掂量整个 Job 的运行过程。
图中左边所展现的是，通过 Flink UI 提供的 API，能够拿到整个工作的拓扑信息，将其分为两层算子并进行革新，别离是 Source 层和 Operator 层。 - Source 层
咱们批改了原生的 Source API，具体的话包含两个局部，第一个是创立 Split 之后，咱们会去拿到 Total Split 的个数，将它上载到 Metric 里；其次是 Source 里的每个 Task 每解决完一个 Split 之后，咱们会上报一个 CompletedSplit。最终咱们通过 Flink UI 是能够拿到以后曾经实现的 Split 个数以及总共的 Split 个数，并用实现的 Split 个数来除以总共的 Split 个数来掂量 Source 节点的进度。 -
Operator 层
首先咱们会看以后 Operator 上游节点的输入多少条，以及以后节点它读取了多少条，并用以后节点读取的条数除以它的上游节点的输入条数作为以后 Operator 的进度。同时，这里咱们做了一个梯度限度，就是以后节点的进度只能小于等于它的上游节点进度。② 基于 Flink 批流一体的架构
以下是批流一体的架构，绝对于原有架构，字节跳动数据平台团队实现如下降级：
- 将 Flink 版本从 1.5 降级到 1.9，同时咱们剖析了 DataSet API，对立降级到 DataStream API，以反对批流一体架构。
- 对数据源反对进行裁减，除了原有的离线数据源之外，减少了实时数据源，如音讯队列。
- 对框架层实现拓展，反对 Exactly Once、反对 Event Time 写入、Auto DDL 等性能。
- 对引擎层进行改良，减少揣测执行、Region Failover 等性能。
- 在 Runtime 层也做了进一步的裁减，反对云原生架构。咱们剖析一个实时场景中比拟典型的链路，MQ 到 Hive 这个链路。
左图（Shuffle）是目前社区的实现形式，很多数据湖的写入，比方 Hudi、Iceberg 基本上也是这个构造。这套构造分为两层算子，第一层是咱们的数据处理层，负责数据的读取和写入；第二层算子是一个单节点的提交层，它是一个单并发，次要负责元信息的提交，比方去生成 Hive 的分区或者做一些其余的元信息动作。这个架构的劣势是其整体拓扑（数据处理流程）比拟清晰，算子功能定位也比较清楚，然而它有一个显著的缺点，退出一个单并发节点后，导致整个工作变成 Shuffle 连贯。而 Shuffle 连贯人造的弱势是，当遇到 Task Failover 的时候，它会间接进行全局重启。右图（Pipelined）是革新之后的数据处理流程，数据写入局部没有变动，变动的是前面的提交局部，这样的设计思考是是放弃原有 Pipeline 架构，以实现 Task 容错时不会进行全局重启。废除了原有的单并发提交节点，把所有元信息的提交拿到 JM 端解决，同时 Task 和 JM 的通信是通过 Aggregate Manager 来实现。改为这套架构之后，在大数据量场景下，其稳定性失去了显著的晋升。
③ 基于 Flink 湖仓一体的架构引入湖仓一体架构的目标是解决 CDC 数据的近实时同步。右图是原有架构，解决流程包含三个模块：拉取批次工作：用来拉取 CDC 全量的数据，写到 Hive 里作为一个根底的镜像。
- 实时工作：拉取 CDC 的 Changelog，并实时写入 HDFS，作为一个增量数据。
- 离线调度工作：周期性地进行 Merge，将全量数据和增量数据进行合并，造成新的全量数据。
上述架构比较复杂，并依赖 Flink、Spark 等多种计算引擎，在实时性方面，只能做到 T+1，最快也只能做到小时级提早，无奈无效撑持近实时剖析场景。从效率来说，存储开销比拟大，每个分区都是一个全量镜像，而且计算成本较高，每次 Merge 都须要进行全局 Shuffle。右图是降级后的架构，次要的降级点包含：
- 将 Flink 1.9 降级到 Flink 1.11，接入了 Hudi 数据湖引擎，以反对 CDC 数据近实时同步。这是因为 Hudi 引擎有齐备的索引机制以及高效的 Upsert 性能。
-
对 Hudi 引擎也进行了多项根底改良，以进步整体的写入效率和稳定性。
最终施行的成果，近实时写入，整体的提早在 10 分钟以内，综合性能比原有架构晋升 70% 以上。至此，实现了全域数据集成架构对立，实现一套零碎笼罩所有同步场景。3. 架构演进过程实践经验分享
上面介绍理论演进过程中的一些思考、问题和改良计划。
- 表类型抉择
数据湖是反对多种表格局的，比方 CopyOnWrite（简称 COW）表、MergeOnRead（简称 MOR）表。COW 表的劣势在于读性能比拟好，然而会导致写放大，MOR 表正好相同，写的性能比拟好的，会导致读放大。具体抉择哪种表格局，更多要依据大家的业务场景来决定。
咱们的业务场景是为了解决 CDC 数据的近实时同步，CDC 数据有个显著的特点，是存在大量的随机更新。这个场景下抉择 COW，会导致写放大的问题比较严重，所以咱们抉择了 MOR 表。上图就是一个 MOR 表查问和写入的流程。第一个是列存储的根底镜像文件，咱们称之为 Base 文件，第二个是行存储的增量日志，咱们称之为 Log 文件。
每次查问时，须要将 Log 文件和 Base 文件合并，为了解决 MOR 表读放大的问题，通常咱们会建一个 Compaction 的服务，通过周期性的调度，将 Log 文件和 Base 文件合并，生成一个新的 Base 文件。 -
Hudi 实时写入痛点
如图所示，这是原生的 Hudi 实时写入的流程图。
首先，咱们接入 Hudi 数据，会进入 Flink State，它的作用是索引。Hudi 提供了很多索引机制，比方 BloomIndex。然而 BloomIndex 有个缺点，它会呈现假阳性，降级去遍历整个文件，在效率上有肯定的影响。Flink State 的劣势是反对增量更新，同时它读取的性能会比拟高。通过 Flink State 之后，咱们就能够确认这条记录是 Upsert，还是 Insert 记录，同时会调配一个 File Id。
紧接着，咱们通过这个 File Id 会做一层 KeyBy，将雷同 File 的数据调配到同一个 Task。Task 会为每一个 File Id 在本地做一次缓存，当缓存达到下限后，会将这批数据 Flush 进来到 hoodie client 端。Hoodie client 次要是负责以块的形式来写增量的 Log 数据，以 Mini Batch 的形式将数据刷新到 HDFS。
再之后，咱们会接一个单并发的提交节点，最新的版本是基于 Coordinator 来做的，当所有的算子 Checkpoint 实现之后，会提交元信息做一次 Commit，认为这次写入胜利。同时 Checkpoint 时，咱们会刷新 Task 的缓存和 hoodie client 的缓存，同时写到 HDFS。通常，咱们还会接一个 Compaction 的算子，次要用来解决 MOR 表读放大的问题。
这个架构在理论的生产环境会遇到如下问题：
（1）当数据量比拟大的时候，Flink State 的收缩会比拟厉害，相应地会影响 Task 的速度以及 Checkpoint 的成功率。
（2）对于 Compaction 算子，Flink 的流式工作资源是常驻的，Compaction 自身是一个周期性的调度，如果并发度设置比拟高，往往就意味着资源的节约比拟多。
（3）Flink 提供了很多资源优化的策略，比方 Slot Sharing，来进步整体的资源利用率，这就会导致资源抢占的问题，Compaction 会和真正的数据读写算子来进行资源的抢占。Compaction 自身也是一个重 I/O、CPU 密集型操作，须要一直地读取增量日志、全量日志，同时再输入一个全量数据。
针对上述问题，咱们优化了 Hudi 的写入流程。首先咱们会采集 CDC 的 Change Log，并发送到音讯队列，而后生产音讯队列中的 Change Log，而后咱们进行如下三个优化：（1）废除了原先的 Flink State，替换为 Hash Index。Hash Index 的劣势是不依赖内部存储。来了一个 HoodieRecord 之后，只须要一个简略的哈希解决，就晓得它对应的 Bucket。（2）将 Compaction 服务独立成一个离线的工作，并且是周期性的调度，用来解决资源节约和资源抢占的问题。（3）将 Task 缓存和 Hudi 缓存做了合并，因为每次 Checkpoint 都须要刷新 Task 缓存，Hudi 缓存须要写入 HDFS，如果缓存的数据量比拟多，会导致整个 Checkpoint 工夫比拟长。优化之后，稳定性方面，能够反对百万级的 QPS；端到端的 Checkpoint 延时管制在 1 分钟以内，Checkpoint 成功率能够做到 99%。
BitSail 能力解析
目前技术架构比拟成熟，并通过字节跳动各业务线的验证，在数据的稳定性和效率上都能失去肯定的保障。因而，咱们心愿能把本人积淀的教训对外输入，给更多企业和开发者带来便当，升高大家数据建设的老本，让数据发明高效的价值。
为了达到这个指标，咱们要解决两个能力的构建。1. 低成本共建能力
数据集成有一个显著的网络效应，每个用户所面临的数据集成的场景也是不一样的，因而须要大家的独特参加，欠缺数据集成的性能和生态，这就须要解决共建老本的问题，让大家都能低成本地参加整个我的项目的共建和迭代。在 BitSail 中，咱们通过两个思路推动这个能力建设。
① 模块拆分
所有的模块糅合在一个大的 jar 包中，包含引擎层、数据源层、根底框架层，模块耦合比较严重，数据处理流程也不清晰。针对这个问题，咱们依照功能模块进行划分，将根底框架和数据源从引擎中独立进去，同时咱们的技术组件采取可插拔的设计，以应答不同的用户环境，比方脏数据检测、Schema 同步、监控等等，在不同的环境中会有不同的实现形式。
② 接口形象
框架对 Flink API 是深度绑定，用户须要深刻到 Flink 引擎外部，这会导致整体 Connector 接入老本比拟高。为了解决这个问题，咱们形象了新的读写接口，该接口与引擎无关，用户只有开发新的接口即可。同时在外部会做一层新的形象接口与引擎接口的转换，这个转换对用户是屏蔽的，用户不须要理解底层引擎细节。
2. 架构的兼容能力
不同公司依赖的大数据组件和数据源的版本不一样，同时还会遇到版本前后不兼容问题，因而须要欠缺架构的兼容能力，以解决不同环境下的疾速装置、部署和验证。咱们同样有两个思路来建设这个能力。
① 多引擎架构
以后架构和 Flink 引擎深度绑定，在应用场景方面受到肯定的限度，比方有些客户用了 Spark 引擎或者其余引擎。Flink 引擎依赖比拟重的状况下，对于简略场景和小数据量场景，整体的资源节约比较严重。为解决此问题，咱们在引擎层预留了多引擎入口，在曾经预留的 Flink 引擎根底之上，接下来会扩大到 Spark 引擎或者 Local Engine。具体实现方面，咱们对执行的环境进行了一层形象，不同的引擎会去实现咱们的抽象类。同时，咱们摸索 Local 执行形式，对小数据量在本地通过线程的形式来解决，不必去启动 Flink Job 或相似的解决，进步整体资源的应用效率。
② 依赖隔离
目前零碎存在一些外部环境中没有的外部依赖，大数据底座也是绑定的公司外部版本，咱们进行了三个方面的优化：
剔除公司外部依赖，采取开源的通用解决方案，以应答不同的业务场景。
大数据底座方面，采纳 Provided 依赖，不绑定固定底座，运行时由内部指定，针对不兼容的场景，通过 Maven Profile 和 Maven Shade 隔离。
针对数据源多版本和版本不兼容的问题，采取动静加载的策略，将数据源做成独立的组件，每次只会加载须要的数据源，以达到隔离的指标。将来瞻望
BitSail 心愿数据畅通无阻地航行到有价值的中央，期待和大家独特单干，欠缺数据集成的性能和生态。同时将来咱们将在三个方面持续深入：
① 多引擎架构：摸索 Local Engine 落地，反对本地执行，对简略场景和小数据量场景进步资源利用率；实现引擎智能抉择策略，针对简略场景应用 Local Engine；针对简单场景复用大数据引擎的能力。
② 通用能力建设：推广新接口，对用户屏蔽引擎细节，升高 Connector 开发成本摸索 Connector 多语言计划。
③ 流式数据湖：对立 CDC 数据入湖解决方案，在性能上稳固撑持千万级 QPS 在数据湖平台能力构建方面，全面笼罩批式、流式、增量应用场景。
进入 BitSail 代码仓库：https://github.com/bytedance/…