基于 Flink 丰富的生态，小米可以非常方便地实现哪些不同场景的数据集成？

1. 离线的数据集成。小米使用 Flink SQL Batch 作业替换了之前的 Data X，借助 Flink 的生态，可以非常方便地实现不同系统数据导入导出的需求，也获得了更丰富的 Source Sink 生态。同时还基于 Flink SQL 可以非常方便地实现字段的映 射，同时 Flink SQL 作为分布式框架，可以很方便提供并发导数的需求。

2. 实时数据集成。 第一部分是实时数据的收集，小米内部主要分为两大类， 分别是日志数据和 DB 的 Binlog 数据。这里主 要介绍 DB 系统的 Binlog 数据收集。最初小米使用自研的 LCS Binlog 服务来进行统一的 Binlog 收集，类似于 Canal 服务，通过该服务将 Binlog 的数据统一收集到消息队列中。 第二部分则是数据的转储， 将使用 Spark Streaming 任务将消息队列中的数据导入其他系统，比如 Kudu 或 HDFS。 现在小米使用 Flink 对 Binlog 的收集和转储链路都进行了改造。使用 Flink CDC 收集 Binlog 数据，并写入消 息队列中。同时通过 Flink 将消息队列的数据转储到其他系统，比如 Kudu、Doris、Iceberg 等等。

3、批流混合集成。在实际的使用中往往需要流批混合的方式，以适用于分库分表、部分链路重做，新增库表等场景。小米选择使用 Flink CDC 任务来收集库级别的 Binlog 数据（按照表级别收集会对 MySQL 服务造成较大的压力）。将数据收集到消息队列后，再针对不同的收集场景，起不同的作业来进行转储。对于单表全量数据需要重做的场景（backfill），小米使用Hybrid Source分别读取 MySQL中的存量数据和消息队列中的增量数据。另一种批流混合的数据集成是在调度层做到批流混合，主要运用于TiDB的Binlog收集场景。在支持 TiDB 的数据收集和转储时无法使用 Hybrid Source，因为 TiDB 的全量数据往往非常大，需要起大量并发能够加速全量数据的转储，而增量数据则只需要较小并发即可，因此使用Hybrid Source难以同时保证业务性能和资源使用效率。解决的方法是在全量数据部分使用 Flink SQL Batch 作业来完成，可以灵活调整并发且相对于实时作业处理效率更高，增量部分则以较小的并发转储即可。

以上内容摘自《Apache Flink 案例集（2022版）》电子书，点击https://developer.aliyun.com/ebook/download/7718 可下载完整版