vlambda博客
学习文章列表

Apache Flink 功能强大，支持开发和运行多种不同种类的应用程序，是业界公认的性能优异的大数据实时计算引擎之一。事实证明，Flink 已经可以扩展到数千核心，其状态可以达到 TB 级别，且仍能保持高吞吐、低延迟的特性。在全球范围内，越来越多的公司开始使用 Flink，在国内比较知名的互联网公司如阿里巴巴、字节跳动、京东、美团等，都在大规模使用 Flink 作为企业的分布式大数据处理引擎。

业界原先对于 Flink 的定位更多是一个流处理器或流计算引擎，在大数据实时化转型大趋势之下，作为从业者，我们不禁会思考 Flink 还能做哪些事情？如何能充分地发挥出 Flink 的优势，实现一个覆盖更大范围实时化问题的解决方案？在具体的业务场景中，我们又会面临怎样的挑战，以及有哪些解决方案？

基于上述提到的问题，我们邀请了汽车之家智能数据中心的数据工程师王刚老师，来为大家分享 Apache Flink 在汽车之家的核心实践内容。同时王刚老师将在 QCon+ 案例研习社【Flink 在实时计算应用场景中的落地实践】专题中为大家带来「基于 Flink 的实时计算平台与实时数据入湖实践」的分享，希望能够给大家带来启发。

以下是对王刚老师的专访：

大家好，我叫王刚，目前负责汽车之家实时计算平台、实时接入平台及数据湖相关的设计开发及维护工作。在实际生产过程中经过不断地打磨，平台的易用性及任务的稳定性都得到了不小的提升，已经服务于全公司的业务线，日计算量也达到了万亿的规模。

我从 2018 年底开始做实时计算平台，过程中确实小困难不断。但是仔细想想，在汽车之家数据的数量级下，我们应用 Flink 遇到的绝大部分问题都是在使用的过程中，或是资源应用不当导致的小麻烦，这得益于 Flink 优秀的设计和其背后强大的社区。在定制化的需求上，得益于 Flink 计算引擎优秀的封装，通过一些简单的改动便能够支持；在计算引擎中遇到的一些较棘手的问题，我们也能在社区的帮助下得以解决；还有一类环境问题也会给我们带来不少困扰，比如 glibc 的问题导致 JVM 的 native 内存泄漏。当时我们刚刚接触 Flink，一度怀疑是 Flink 引擎自身的问题，走了很多弯路，后来发现进程中很多连续的 64MB 的内存段的数量随着时间的变化不断增加，这才定位到了问题所在。

还有一部分问题来自做平台相关的工作，比如随着用户数量的增多，on call 压力很大，这时就得不断地去反思：

1. 什么事情是目前用户做不了的，必须我们帮他做？是否可以通过平台赋能给用户？

2. 在 on call 中经常碰到的使用问题，平台是否能够自动帮助用户去诊断并给出解决建议？

3. 重保的任务如何做好灾备？

在这方面我们主要有两个方向上的探索：

1. 我们平台上的用户在使用 Flink SQL 开发流计算任务的时候，可以将之前批处理任务的 SQL 稍做些改动就能够应用到流计算的开发中，这样不仅使用户的学习与开发成本大幅降低，而且也统一了计算口径；

2. 我们在存储层引入了 Iceberg 作为统一的 Table Format，做到了存储层的流批一体，这样就可以通过全量或者增量的方式读取数据，进行批 / 流任务处理。

对于之后的规划，我们也会尝试使用 Flink SQL 作为批计算引擎，充分发挥 Flink 流批一体的优势，来进一步赋能用户，减少用户的开发成本。

最近我比较关注的是新版本 Flink 的任务资源细粒度管理特性。在 Flink1.14 版本之前是一种粗粒度的资源管理方式，我们可以通过 Slot Sharing 的方式充分利用资源，但是在个别场景里还是会造成不必要的资源浪费。我觉得为 SlotSharingGroup 细粒度分配资源，是解决资源浪费的一个很好的思路。

另一方面，我比较关注的是 Flink CDC (Change Data Capture) 项目。在 Flink CDC 发布之前，我们在 Flink 上实现了同步 MySQL，SQLServer，TiDB 等业务库数据的实时接入分发平台。今年的 FFA（Flink Forward Asia）大会上，云邪老师分享的 Flink CDC 主题给了我很大的启发，我认为 Flink CDC 需要做的那些易用性提升（Schema 变更，库级数据入湖）都是我们公司的数仓及业务线用户亟需我们去解决的问题。

我们有遇到以下两个比较明显的问题：

1. Flink 版本迭代较快，且版本之间的兼容性较低，这样会导致平台很难集成新版本的 Flink；

2. Flink SQL 可以让用户通过 SQL 来完成实时计算的开发，但是 SQL 的表达能力有限，有时候用户需要写很多 SQL 来完成一个实时大屏的数据开发，这样数据会被重复计算，造成资源浪费。这类问题其实更像实时 OLAP 的场景，我们目前是使用了 StarRocks 去支持这种场景，不过更加期望 Flink 可以有一站式的解决方案，进一步降低我们的维护成本。

我觉得在软件开发上接触任何新的技术栈的方法都是通用的，建议找些场景先用起来，再带着问题去深入了解，最后再想想如果是自己去实现会怎么做。另外，在工作时我们也要养成多总结、多反思的习惯。很多刚刚接触软件开发的同学认为问题解决了就完事了，其实每次出现的问题无论大小，都是一次绝佳的思考机会。问题解决之后，我们可以回头再想一想下一次如何才能更好地帮助用户快速定位问题或者避免出现这类问题。比如反思一下：问题这么难定位是不是因为程序设计得过于复杂，链路过长呢？