首先简单做个自我介绍，我是李本超，是字节跳动基础架构流式计算方向的工程师，主要负责 Flink SQL 方向。最近非常有幸受邀成为 Apache Flink Committer。

（来自 PMC Member 的邀请邮件）

我参与社区主要是从19年下半年开始的，最开始主要是汇报一些使用过程中遇到的 bug，并且会力所能及的去修复它。与此同时也一直在关注 user 和 dev 邮件列表，一方面了解社区的最新进展和未来发展方向；一方面也在从其他人的提问和回答中学习经验。后来随着了解的深入，也就参与到了帮助解答用户问题，参与设计的讨论、以及感兴趣的 issue 的讨论等。

社区筛选 Committer 的条件是比较均衡的，各种形式的参与贡献社区，都会被记录和认可，比如贡献代码，贡献文档（包括翻译），参与各种形式的讨论，帮忙解答用户的提问等。从我个人的角度来讲，这些方面都做了一定程度的参与，做的最突出的一个点主要是在 user 列表里活跃的比较突出。

本篇文章主要是介绍我自己参与社区的过程和一些心得体会，主要从以下几个方面进行了介绍：

• 初识 Flink 社区
• 如何融入社区
• 在社区的收获
• 对社区的贡献
• 参与社区的建议

初识 Flink 社区

我第一次接触 Flink 的时间其实比较早，2017 年我研究生毕业的时候，我当时的 mentor 给我定的方向就是流式计算，具体来说就是 Flink。当时我对于 Flink 还完全是一个小白，工作上也完全是一个小白，在读了几天 Flink 文档后，就得到了一个非常粗浅的结论，Spark Streaming 应该就可以满足我们的场景了（因为之前在实验室搞过 Spark，而且实习的时候又较为深度的使用过 Spark Streaming）。这一个粗浅的结论让我跟 Flink 深度接触的时间延迟了 2 年。

（2018年 Flink Meetup 北京站大沙老师的现场分享）

第二次接触 Flink 是在 2018 年夏天的一次 Flink Meetup 上，对于当时的情景的印象到现在都还是很深刻的。尤其是大沙老师当时的演讲尤其是对我影响比较大，大沙对于 Flink 深入浅出的讲解，给我的感觉就是 Flink 社区里都是一群大牛，而且 Flink 本身也非常的有意思。

当时就想，如果有幸哪天也能够跟这些人一起在社区参与工作，将会是多么幸福的一件事。值得一提的是，当时光辉老师也分享了 Flink 在字节跳动的落地使用，冥冥中注定吧，我现在也是他团队的一员了。在这之后我们在公司（上家公司）内也做了一些对 Flink 应用落地使用的探索，整体来讲 Flink 还是很好地满足了我们的场景。但是由于公司的数据特点，并没有遇到太多大流量下的挑战，只是在使用层做了一些简单的工作。

（2018年 Flink Meetup 北京站张光辉老师的现场分享）

第三次接触 Flink 就是在 2019 年夏天，我刚刚换工作到字节跳动，也刚好赶上了字节内部准备大力使用和推广 Flink SQL 的时机。最开始我的方向并不是 Flink SQL，而是更多的负责 runtime 方向的事情。但是后来由于 SQL 方向的工作比较多而且时间比较紧张，加上我之前做过 OLAP 方向，对于 SQL 还有点基础，所以就换到了这个方向。我们当时的选型就是阿里刚刚开源并且 merge 到 master 分支的 blink planner。

融入：Blink planner 的第一批用户

我是比较幸运的，正好赶上了我们我们公司使用 Flink SQL 的起步阶段；同时对于社区来讲，也是 blink planner 发布的第一个版本。虽然 blink 有很多非常棒的feature，但是由于社区有非常严格的 feature 引入机制，所以在第一版的 blink planner 里面，有些在阿里云上的 blink 有的 feature，社区的 blink planner 是没有的。（其实我理解这个现象是比较好的，虽然这样会导致一些 feature 的引入速度变慢，甚至于最终都不一定会 merge 到社区里，但是能够保证社区发布的版本是经过严格的设计和讨论的，对于后期的维护和演进比较友好）

我们也是参考了很多 blink 的实现，做了大量的功能的补齐，例如 CREATE TABLE/VIEW、CREATE FUNCTION、计算列、WATERMARK 等等。在我们实现的过程中，就开始在社区里提一些问题，以及 feature request。而且在 1.10 版本里这些功能已经大部分都在社区实现了。

有一个典型的例子就是计算列，这个对于我们来讲是一个比较重要的 feature，我当时是直接借鉴 blink 分支的逻辑实现了一个内部版本。然后这个也给社区提了需求，并且得到了比较快速的响应。在这个交互过程中，我们对这块的实现也算是比较了解，后面也逐步参与了一些相关的工作，比如修复一些计算列相关的 bug 等。

字节跳动是一个非常好的平台，有着非常丰富的场景以及巨大的流量。在我们实践过程中，遇到了很多方面的挑战，既包括功能上的，也包括性能上的。很多问题我们会做积极的探索和解决，如果遇到了一些 bug，就会及时的反馈给社区，并且帮忙进行修复；遇到了解决不了的问题，就会在邮件列表或 JIRA 中进行提问和求助，一般社区的小伙伴都可以非常快速的响应（一般几个小时内吧）。

最开始我们也是以一个用户的身份在社区寻求帮助和经验，遇到解决不了的问题就向社区提出来，一般很快就可以帮我们解决了，通过这种方式我们也让 Flink SQL 在字节内部快速的上线和落地，并且，我们会把一些内部发现并且解决的问题，同步回馈给社区。

逐渐的我们也会发现社区里有些其他公司的小伙伴提到的问题我们都已经遇到且解决过，我们也会积极的去帮助其他的用户答疑解惑。在不知不觉间，我们就从一个使用者的角色转变为了贡献者。

这一年，我的收获

参与社区是需要花很多时间和精力的。但是相对于从社区获得的收获，这些付出就非常值得了。

首先，参与社区最大的好处就是，可以跟社区当前的步调一致，能够看到社区当前的进展，以及未来的规划，不至于在内部进行一些功能设计和 feature 规划的时候，作出一些已经过时的设计，这样能够保证我们始终跟社区以同样的步伐前进 ，并且能够享受到最新的功能。

其次，参与社区的第二个好处是，能够极大地扩展我们的场景和视野。公司内部的场景无论有多么的丰富，毕竟是有限的。但是在社区里，我们可以跟全世界所有 Flink 的用户沟通交流使用 Flink 的经验和心得，也从其他小伙伴那里获取一些思路和灵感。这样子在解决很多内部问题的时候，也能有更开阔的思路以及更快的速度。

然后，参与社区的第三个好处是，我们能够及时发现一些重要的 bug，这样可以在我们内部出现线上问题之前就把问题得到了及时的修复。有一个典型的例子是， Window 内的 COUNT DISTINCT 的状态是有一个小 bug 的，就是它不会被自动清理。这个问题完全是社区的小伙伴提出来的，而且提到了不止一次，我在注意到了这个问题之后，快速的做了一个验证和修复，发现真的竟然存在这样一个问题。当时我就想，幸好是及时发现了，这样就避免了一个潜在的稳定性问题。

最后，还有一个隐性的好处，就是可以扩大公司和个人的影响力。我在参与社区的过程中，也认识了很多热心的小伙伴。甚至于我也从社区的小伙伴那里收到过好几份简历。🤭

对社区的贡献

作为比较早期大规模生产使用社区 blink planner 的团队，我们目前对社区最大的贡献就是修复了很多不易发现的 bug，以及很多 improvement，鉴于我们对于 blink planner 生产环境的大规模使用，我们也在 1.11 中让 blink planner 成为默认 planner 中投出了 +1 票。

其中一些比较有意思的问题包括但不限于：

• FLINK-15430 & FLINK-16589: 代码生成超过 64KB 的问题
• FLINK-15428: CEP 在并发度大于 1 时会有状态问题
• FLINK-16181: CASE WHEN 代码生成 NPE 问题
• FLINK-14546: 支持 JSON 处理 MAP 类型
• FLINK-15494: 解决窗口级联使用时时间列计算错误的问题
• FLINK-17942: WindowOperator 自动清理 COUNT DISTINCT 的状态
• FLINK-16068: 解决计算列在遇到关键字的时候会有问题
• FLINK-17025: 支持新版 AVRO Format

除此之外，我们也在积极规划一些未来的贡献的 feature，例如：

• FLINK-18202: Flink 支持 ProtoBuf Format
• FLINK-18379: Flink 支持异步 UDF/UDTF
• FLINK-17137: Window 支持 mini batch

（我在社区贡献的 issue 分布）

我只是从我们 SQL 方向做了一些简单的总结，其实我们 state/runtime 方向的小伙伴们也都在积极的参与社区，并且做出了很多贡献~

我的一些小建议

Flink 社区对于新的小伙伴的参与还是非常友好的，我自己就有一些这样的体会，在我们参与了一段时间之后，对于有些比较简单的 issue，社区还是期望能分配够给一些刚开始参与社区的小伙伴。所以大家要想参与社区，可以积极的参与起来，社区是非常欢迎大家的~

首先参与社区是一个持续的事情，不是一时兴起，去看看社区的状态，做一些参与。所以参与社区需要一些耐心和耐力，要更及时的了解社区的动态。一开始可能会感觉社区发展的速度太快，每天去看社区的 dev/user 邮件列表会比较耗时间，但是坚持一段时间之后就会发现，其实也花费不了多少时间，而且有时候还比较享受这个过程。

其次参与社区要胆量大一些，不用太畏首畏尾。遇到了能回答的问题，就积极参与回答和讨论。社区本来就是给大家的一个交流分享的平台，并不只是提问和解答的过程。除了 user 列表之外，对于一些比较熟悉的开发和设计，都可以给出自己的看法，每一个真实的想法对社区来讲都是有价值的。可能会有些小伙伴会担心英文的问题，其实个人觉得这个大可不用太担心，社区里的英文交流都是实用为主，只要把意思表达到位了就行，不用多么华丽的辞藻，也并不需要每句话都要字斟句酌考虑各种语态时态的问题（当然也不是鼓励写一些语法有问题的句子）。

然后就是开发相关的，如果你有比较明确的 bug 或者 feature，可以直接去建一个 issue 即可。一般很快就会有小伙伴注意到你的 issue，并且跟你讨论并且确认问题，一旦达成一致，就可以开始写代码并且提 PR 了。当然了，除了自己提 issue 之外，也可以关注其他小伙伴们提的 issue，对于感兴趣的问题要及时点一个 watch，这样就可以及时了解该 issue 后续的讨论和进展。

关于代码，社区对代码的要求还是非常高的。所以大家在社区写代码的时候，需要关注到各种细节，小到一个空格、一个空行，大到代码的设计模式和架构，社区的小伙伴都会精细的 review。这个过程也是非常锻炼人的一个过程。在逐步参与的过程中，你会不知不觉的发现自己的代码水平在不断的提高了~

最后祝愿各位感兴趣的小伙伴在都可以在社区愉快的贡献~