深度解析字节跳动开源数据集成引擎 BitSail

admin888

1. 导读
BitSail 是字节跳动开源数据集成引擎，反对多种异构数据源间的数据同步，并提供离线、实时、全量、增量场景下全域数据集成解决计划，目前撑持了字节外部和火山引擎多个客户的数据集成需要。通过字节跳动各大业务线海量数据的考验，在机能、不乱性上失掉较好验证。
10 月 26 日，字节跳动宣告 BitSail 名目正式在 GitHub 开源，为更多的企业和开发者带来方便，升高数据建立的本钱，让数据高效地发明价值。本篇内容将环抱 BitSail 演讲历程及重点才能解析展开，次要包罗下列四个部份：
字节跳动外部数据集成配景BitSail 技术演进历程BitSail 才能解析将来瞻望2. 字节跳动外部数据集成配景


始终以来，字节跳动都十分注重并贯彻“数据驱动”这一理念，作为数据驱动的一环，数据中台才能的建立相当首要，而这其中，数据集成作为数据中台建立的根底，次要解决了异构数据源的数据传输、加工和处置的问题。
BitSail 源自字节跳动数据平台团队自研的数据集成引擎 DTS（全称 Data Transmission Service，即数据传输办事），最后基于 Apache Flink 完成，至今曾经办事于字节外部业务接近五年，现已具备批式集成、流式集成和增量集成三类同步模式，并反对散布式程度扩展和流批一体架构，在各种数据量和各种场景下，一个框架便可解决数据集成需要。另外，BitSail 采取插件式架构，反对运转时解耦，从而具备极强的灵敏性，企业能够很便利地接入新的数据源。
3. BitSail 演进历程
3.1 全域数据集成引擎演进三阶段


字节跳动数据集成引擎 BitSail 演进的历程能够分为三个阶段：
① 初始期：2018 年之前公司没有一致的数据集成框架，对每个通道都是各自完成，因此依赖的大数据引擎也对比零散，如 MapReduce 、Spark ，数据源之间的衔接也是网状衔接，总体的开发和运维本钱都对比高。
② 生长期：能够分为三个小阶段。
2018 - 2019 ：跟着 Flink 生态不停完美，愈来愈多的公司将 Flink 作为大数据计算引擎的首选，字节跳动也不例外，并在 Flink 上继续探究，并于 2019 年提出基于 Flink 的异构数据源间传输，实现批式场景的一致。2020 - 2021 ：跟着 Flink 批流一体的完美，字节跳动对原有架构进行较大降级，并掩盖了流式场景，实现批流场景的一致。2021 - 2022 ：接入了 Hudi 数据湖引擎，解决 CDC 数据实时同步问题，并提供湖仓一体解决计划。③ 成熟期：2022 年开始全域数据集成引擎的总体架构曾经不乱，并通过字节跳动外部各业务线出产环境的考验，在机能和不乱性上也失掉充沛的保障，因而团队但愿可以将才能对外输入，为更多的企业和开发者带来方便，升高数据建立的本钱，让数据高效地发明价值。
3.2 BitSail 数据集成引擎技术架构演进
3.2.1 基于 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 的进度。同时，这里咱们做了一个梯度限度，就是以后节点的进度只能小于等于它的下游节点进度。
3.2.2 基于 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 来完成。改成这套架构之后，在大数据量场景下，其不乱性失掉了明显的晋升。
3.2.3 基于 Flink 湖仓一体的架构
引入湖仓一体架构的目的是解决 CDC 数据的近实时同步。


右图是原有架构，处置流程包罗三个模块：
拉取批次工作：用来拉取 CDC 全量的数据，写到 Hive 里作为一个根底的镜像。实时工作：拉取 CDC 的 Changelog，并实时写入 HDFS，作为一个增量数据。离线调度工作：周期性地进行 Merge，将全量数据和增量数据进行合并，造成新的全量数据。上述架构对比繁杂，并依赖 Flink、Spark 等多种计算引擎，在实时性方面，只能做到 T+1，最快也只能做到小时级提早，无奈无效撑持近实时候析场景。从效力来讲，存储开消对比大，每个分区都是一个全量镜像，并且计算本钱较高，每次 Merge 都需求进行全局 Shuffle。


右图是降级后的架构，次要的降级点包罗：
将 Flink 1.9 降级到 Flink 1.十一，接入了 Hudi 数据湖引擎，以反对 CDC 数据近实时同步。这是由于 Hudi 引擎有齐备的索引机制以及高效的 Upsert 机能。对 Hudi 引擎也进行了多项根底改进，以进步总体的写入效力和不乱性。终究实行的成果，近实时写入，总体的提早在 10 分钟之内，综合机能比原有架构晋升 70% 以上。至此，实现了全域数据集成架构一致，完成一套零碎掩盖一切同步场景。
3.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 实现之后，会提交元信息做一次 Co妹妹it，以为这次写入胜利。同时 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 的劣势是不依赖内部存储。来了一个 Hoodie Record 之后，只需求一个简略的哈希处置，就知道它对应的 Bucket。
（2）将 Compaction 办事独立成一个离线的工作，而且是周期性的调度，用来解决资源挥霍和资源抢占的问题。
（3）将 Task 缓存和 Hudi 缓存做了合并，由于每次 Checkpoint 都需求刷新 Task 缓存，Hudi 缓存需求写入 HDFS，假如缓存的数据量对比多，会致使全部 Checkpoint 时间对比长。
优化之后，不乱性方面，能够反对百万级的 QPS；端到真个 Checkpoint 延时管制在 1 分钟之内，Checkpoint 胜利率能够做到 99%。


4. BitSail 才能解析
目前技术架构对比成熟，并通过字节跳动各业务线的验证，在数据的不乱性和效力上都能失掉一定的保障。因此，咱们但愿能把本人积淀的教训对外输入，给更多企业和开发者带来方便，升高大家数据建立的本钱，让数据发明高效的价值。为了达到这个指标，咱们要解决两个才能的构建。
4.1 低本钱共建才能
数据集成有一个显著的网络效应，每个用户所面临的数据集成的场景也是纷歧样的，因此需求大家的独特参预，完美数据集成的功用和生态，这就需求解决共建本钱的问题，让大家都能低本钱地参预全部名目的共建和迭代。
在 BitSail 中，咱们经过两个思绪推动这个才能建立。
4.1.1 模块拆分


一切的模块糅合在一个大的 jar 包中，包罗引擎层、数据源层、根底框架层，模块耦合对比重大，数据处置流程也不明晰。针对这个问题，咱们根据功用模块进行划分，将根底框架和数据源从引擎中独立出来，同时咱们的技术组件采用可插拔的设计，以应答不同的用户环境，好比脏数据检测、Schema 同步、监控等等，在不同的环境中会有不同的完成形式。
4.1.2 接口笼统


框架对 Flink API 是深度绑定，用户需求深化到 Flink 引擎外部，这会致使总体 Connector 接入本钱对比高。为理解决这个问题，咱们笼统了新的读写接口，该接口与引擎有关，用户只有开发新的接口便可。同时在外部会做一层新的笼统接口与引擎接口的转换，这个转换对用户是屏蔽的，用户不需求理解底层引擎细节。
4.2 架构的兼容才能
不同公司依赖的大数据组件和数据源的版本纷歧样，同时还会遇到版本先后不兼容问题，因此需求完美架构的兼容才能，以解决不同环境下的疾速装置、部署和验证。咱们一样有两个思绪来建立这个才能。
4.2.1 多引擎架构


以后架构和 Flink 引擎深度绑定，在使用场景方面遭到一定的限度，好比有些客户用了 Spark 引擎或者其余引擎。Flink 引擎依赖对比重的状况下，关于简略场景和小数据量场景，总体的资源挥霍对比重大。
为解决此问题，咱们在引擎层预留了多引擎入口，在曾经预留的 Flink 引擎根底之上，接上去会扩展到 Spark 引擎或者 Local Engine。详细完成方面，咱们对履行的环境进行了一层笼统，不同的引擎会去完成咱们的笼统类。同时，咱们探究 Local 履行形式，对小数据量在当地经过线程的形式来解决，不必去启动 Flink Job 或相似的处置，进步总体资源的使用效力。
4.2.2 依赖隔离


目前零碎存在一些内部环境中没有的外部依赖，大数据底座也是绑定的公司外部版本，咱们进行了三个方面的优化：
剔除公司外部依赖，采用开源的通用解决计划，以应答不同的业务场景。大数据底座方面，采取 Provided 依赖，不绑定固定底座，运转时由内部指定，针对不兼容的场景，经过 Maven Profile 和 Maven Shade 隔离。针对数据源多版本和版本不兼容的问题，采用静态加载的战略，将数据源做成独立的组件，每次只会加载需求的数据源，以达到隔离的指标。5. 将来瞻望BitSail 但愿数据疏通无阻地飞行到有价值之处，期待和大家独特协作，完美数据集成的功用和生态。同时将来咱们将在三个方面持续深入：
① 多引擎架构：探究 Local Engine 落地，反对当地履行，对简略场景和小数据量场景进步资源利用率；完成引擎智能选择战略，针对简略场景使用 Local Engine；针对繁杂场景复用大数据引擎的才能。
② 通用才能建立：推行新接口，对用户屏蔽引擎细节，升高 Connector 开发本钱
探究 Connector 多言语计划。
③ 流式数据湖：一致 CDC 数据入湖解决计划，在机能上不乱撑持千万级 QPS
在数据湖平台才能构建方面，片面掩盖批式、流式、增量使用场景。
??本文感激 DataFun 意愿者钟晓华整顿
6. 流动预报
十一 月 9 日 19:30，字节跳动数据平台举行 BitSail 首期直播流动，约请数据集成畛域专家，深化解读字节跳动数据集成技术理论与运用、开源名目布局和门路，更有工程师手把手教你如何疾速上手。
当即扫码进群，预定直播，赢取精美礼品！