Flink发展

小米从 2019 年开始引入 Flink 并处理实时计算相关的需求，从第一个接入的版本 1.7 到最新的 1.14，累计已升级更新了 6 个大的版本，目前已接入包括数据采集、信息流广告、搜索推荐、用户画像、金融等在内的全集团所有业务线的 3000+ 任务，日均处理 10 万亿 + 的消息，并在国内外搭建了 10+ 集群。

那么，小米在引入 Flink 后遇到了哪些挑战？又是如何解决的？Flink 最终又会走向哪里呢？基于对以上问题的好奇，我们找到了小米大数据部高级开发工程师张蛟，他是 Apache Flink Contributor，主要负责小米基于 Flink 的实时计算框架内核层方面的研发工作。

同时张蛟老师也是已经上线的 QCon+ 案例研习社「Flink 在实时计算应用场景中的落地实践」专题的讲师，因此我们针对 Flink 相关的疑惑和好奇对张蛟老师进行了采访，让我们一起来看看老师的思考吧。

 InfoQ：你最近在负责什么样的工作呢？

张蛟：我目前在小米计算平台部，主要是负责开发和维护小米实时计算平台 Flink 框架内核相关的工作，包括内部新特性的开发、用户使用上的支持、Flink 社区的参与、框架的日常维护等。目前主要面向的是集团内部的用户，为公司的各条业务线的数据开发人员提供数据处理的能力和支撑，更好地赋能业务的发展。

我们在社区开源 Flink 的基础上，根据小米集团使用的特点和个性化需求，进行了比较多的定制化开发，其中有些问题和功能是内部使用场景上会碰到的，因此维护在内部版本上；还有些是各个公司都会遇到和需要的通用场景，我们也会将其反馈给社区。当然也会将我们在开发维护中的经验教训和技术进行分享交流，实现共同进步。

 InfoQ：在你的日常工作中，你有遇到过什么印象深刻的挑战吗？

张蛟：在使用 Flink 的过程中，实际上我觉得有两类问题还是比较突出的：

1. Flink 的运维问题，尤其是版本升级问题

   社区 Flink 版本的升级迭代是比较快的，基本上每三到四个月就会发布一个比较大的版本，而由于内部版本存在着非常多的无法合并到社区的 patch，再加上目前各个版本之间的兼容性并不是很好，包括 checkpoint 在跨版本之间不保证兼容性、API 有时也会发生改变等，导致 Flink 集群升级变成一件非常痛苦的事情，内部甚至不得不同时维护 Flink 的多个版本。

   目前，我们还是做了比较多的事情，包括内部 patch 的梳理整合、升级兼容性的自动检测、checkpoint 的兼容处理开发等等。社区目前也注意到了这方面的情况，除了规范化 Flink 的版本发布周期外，也在新版本中对新旧版本 API 进行了兼容保证。并不能说通过这些手段已经完全解决了这个问题，但至少在一定程度上降低了升级的复杂性和成本。

2. Flink 的消费问题

   其实 Flink 的入门是比较简单的，即使对于 Flink 不那么熟悉的用户，通过阅读文档或是查阅网络上的资料抑或是阅读我们提供的典型场景的使用范例，一般几天就能实现自己的需求，尤其是从 Flink 1.9 开始对 SQL 的支持日趋完善，用户基本上可以完全不写任何代码依靠纯 SQL 就可以完成需求，但跑起来后用户就可能会遇到消息积压的问题，可能的原因有很多，包括 Source 读取速度慢、消息处理逻辑复杂导致消费速度慢、状态读取速度慢影响处理性能、Sink 写入速度慢、消息出现了短时间的流量高峰、消息处理出现异常等等问题。

   解决办法也有很多，比如参数的调整、增大作业并行度、排查上下游的读写瓶颈、优化消息处理逻辑等。当然，优化处理逻辑还是比较困难的，尤其是 Flink SQL 的处理代码都是框架自动生成的，还是比较难进行优化的，一般我们都会将一些比较常见的优化作为参数提供给有需要的用户来手动配置。

 InfoQ：Flink 近些年一直在强调流批一体，它在小米目前有哪些应用场景呢？分享一下你们的实践和探索吧。

张蛟：其实批处理与流处理还是有一定的区别，比如说流处理是事件驱动，也就是说事件来了之后就可以驱动进行处理，但是批处理一般都需要一个调度系统来进行调度，用于控制触发的时间和条件等，目前结合小米内部的蜂鸟调度系统 +Flink+Iceberg 数据湖技术，我们在去年就已经跑通了 Flink 批流处理的整个流程。

在今年，小米正在大力推动流批一体，使用场景既包括新业务新场景直接使用 Flink 批流一体进行开发，也包括老的场景将其批处理场景切换到 Flink 中，实现 Flink 一套框架完成其所有的计算场景。目前，我们主要是在数仓团队进行推广使用，通过 Flink 提供的批流融合能力，加上 Iceberg 的批流读写接口，大大地简化了数据 ETL 链路。

流批一体的优势在于可以使用一套代码完成业务逻辑，并且由于相同框架的批流处理底层使用相同的 API 解决业务口径的问题，这样不仅提升了业务的开发效率，也消除了口径不统一带来的数据质量问题，对于业务来说其可以将更多的精力专注到业务的实现而不是计算引擎的选型、对比数据质量的保证等问题。

 InfoQ：如何看待 Flink 在实时计算方面已趋于成熟这个话题，你认为 Flink 还会有哪些迭代，会如何发展呢？

张蛟：目前来看，经过这些年的发展，Flink 在实时计算方面实际上已经成为了事实上的标准，目前已有功能已经可以基本上解决所有场景的实时计算需求。因此，下一步 Flink 的发力点可能有：

1. 发力离线计算领域

   完全统一计算框架，甚至实现用户可以完全不用区分实时和离线计算的场景，减少用户的学习成本和底层开发人员和公司维护两套框架的运维成本。当然，这并不是一个简单的事情，如果用户和公司在做这件事情上没有显著收益的话，从业务层面看是很难推动的。

   此外，批流分开处理的思想已经深入人心，要想让业务方转变思维也不是一个简单的事情，这一切都依赖于技术的不断进步和时间的证明。

2. 发力 OLAP 数据查询领域

   目前 OLAP 查询引擎还是比较多，处在一个百家争鸣的状态，实时计算的结果需要收集到下游存储系统并基于该数据进行查询，如果能够直接优化和查询 Flink 的计算结果，并同时复用 Flink 的计算能力，那么是不是能够提供更高的查询实时性，而且还能节约存储成本呢？

   当然，这个还会有比较多的工作要做，比如查询的性能优化，能否解决存储、计算和查询相互影响的问题等等，我们可以欣喜地看见 Flink 实际上正不断地在这个方向上进行发力。总的来说，我个人认为 Flink 不会满足于在实时计算领域取得的成就，会有更多更好用的功能持续推出，并促进整个社区的不断发展。

 InfoQ：你如何看待最新提出的流式数仓这个概念？它将来会有哪些应用场景？

张蛟：流式数仓主要是为了解决在数仓开发中的离线和实时一体化问题，目前绝大多数的数仓开发依然还是在使用 Lambda 架构，也就是通过实时链路产生实时数据用于解决实时性需求比较高的在线分析场景，而采用离线链路对历史数据进行修正以保证数据的正确性和完整性，这不仅影响了开发效率，增大了开发成本，同时也带来了数据口径问题。

同时，由于实时链路一般都使用 Kafka 等消息队列作为中间存储，虽然 Kafka 写入效率比较高，但存在着存储时间有限，只支持追加不支持更新，不支持 OLAP 查询等问题。而 Flink 通过引入 Dynamic table（动态表）来存储实时链路产生的分层数据，即可直接存储中间结果并分析，而无需引入第三方存储和 OLAP 引擎，真正实现了中间存储和计算的一体化。

目前来说，Flink+Iceberg 数据湖方案可以看做是一个替代方案，虽然是额外引入了第三方组件 Iceberg，但是通过 Iceberg 支持的事务读写的能力以及行级更新机制，基本上可以解决目前这方面遇到的大部分场景。

 InfoQ：最后，对想要深入了解并应用 Flink 的小伙伴说些什么吧！

张蛟：我个人认为，由浅入深是学习一门新技术的最佳途径，先尝试使用再了解原理，做到知其然再知其所以然，我个人其实不是很推荐直接去看源码，实际上 Flink 框架源码的代码量还是比较大的，如果不能带着问题去看，很大可能是坚持不下去的，即使坚持下去了，效果也可能不太理想，最终很可能是事倍功半的效果。

当然每个人的学习思路和学习习惯可能不尽相同，但就我个人来说，多看 Flink 社区的官方文档和 FLIP 改进提案，多参与社区 issue 的讨论和 code review，都是非常有帮助的。最后，持续学习值得拥有，肯定不会后悔。