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 作业来完成，可以灵活调整并发且相对于实时作业处理效率更高，增量部分则以较小的并发转储即可。
未来规划
当前 Flink + Iceberg 的数据湖解决方案在小米已经初步落地，未来可以提升的空间依然非常大，小米会不断跟进社区，继续推进内部流批一体化的建设。
与此同时，小米会将 Flink SQL Batch 用于更加复杂的场景。当前 Flink SQL Batch 发挥的场景有限，主要运用于批量导出的场景，相信未来它会发挥更大的价值。
其次，小米会跟进社区的 built in dynamic table，结合消息队列和数据湖，兼顾时效性和准确性，提升用户的体验。同时也会升级 Hybrid Source connector，更加灵活地对接其他系统。
