首先简略做个自我介绍，我是李本超，是字节跳动基础架构流式计算方向的工程师，次要负责 Flink SQL 方向。最近十分有幸受邀成为 Apache Flink Committer。
我参加社区次要是从 19 年下半年开始的，最开始次要是汇报一些应用过程中遇到的 bug，并且会力不从心的去修复它。与此同时也始终在关注 user 和 dev 邮件列表，一方面理解社区的最新进展和将来倒退方向；一方面也在从其他人的发问和答复中学习教训。起初随着理解的深刻，也就参加到了帮忙解答用户问题，参加设计的探讨、以及感兴趣的 issue 的探讨等。
社区筛选 Committer 的条件是比拟平衡的，各种模式的参加奉献社区，都会被记录和认可，比方奉献代码，奉献文档（包含翻译），参加各种模式的探讨，帮忙解答用户的发问等。从我集体的角度来讲，这些方面都做了肯定水平的参加，做的最突出的一个点次要是在 user 列表里沉闷的比较突出。
本篇文章次要是介绍我本人参加社区的过程和一些心得体会，次要从以下几个方面进行了介绍：
- 初识 Flink 社区
- 如何融入社区
- 在社区的播种
- 对社区的奉献
- 参加社区的倡议
初识 Flink 社区
我第一次接触 Flink 的工夫其实比拟早，2017 年我研究生毕业的时候，我过后的 mentor 给我定的方向就是流式计算，具体来说就是 Flink。过后我对于 Flink 还齐全是一个小白，工作上也齐全是一个小白，在读了几天 Flink 文档后，就失去了一个十分浅显的论断，Spark Streaming 应该就能够满足咱们的场景了（因为之前在实验室搞过 Spark，而且实习的时候又较为深度的应用过 Spark Streaming）。这一个浅显的论断让我跟 Flink 深度接触的时间延迟了 2 年。
第二次接触 Flink 是在 2018 年夏天的一次 Flink Meetup 上，对于过后的情景的印象到当初都还是很粗浅的。尤其是大沙老师过后的演讲尤其是对我影响比拟大，大沙对于 Flink 深入浅出的解说，给我的感觉就是 Flink 社区里都是一群大牛，而且 Flink 自身也十分的有意思。
过后就想，如果有幸哪天也可能跟这些人一起在社区参加工作，将会是如许幸福的一件事。值得一提的是，过后光芒老师也分享了 Flink 在字节跳动的落地应用，冥冥中注定吧，我当初也是他团队的一员了。在这之后咱们在公司（上家公司）内也做了一些对 Flink 利用落地应用的摸索，整体来讲 Flink 还是很好地满足了咱们的场景。然而因为公司的数据特点，并没有遇到太多大流量下的挑战，只是在应用层做了一些简略的工作。
第三次接触 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
我只是从咱们 SQL 方向做了一些简略的总结，其实咱们 state/runtime 方向的小伙伴们也都在踊跃的参加社区，并且做出了很多奉献~
我的一些小倡议
Flink 社区对于新的小伙伴的参加还是十分敌对的，我本人就有一些这样的领会，在咱们参加了一段时间之后，对于有些比较简单的 issue，社区还是冀望能调配够给一些刚开始参加社区的小伙伴。所以大家要想参加社区，能够踊跃的参加起来，社区是十分欢送大家的~
首先参加社区是一个继续的事件，不是一时衰亡，去看看社区的状态，做一些参加。所以参加社区须要一些急躁和耐力，要更及时的理解社区的动静。一开始可能会感觉社区倒退的速度太快，每天去看社区的 dev/user 邮件列表会比拟耗时间，然而保持一段时间之后就会发现，其实也破费不了多少工夫，而且有时候还比拟享受这个过程。
其次参加社区要胆量大一些，不必太敢作敢为。遇到了能答复的问题，就积极参与答复和探讨。社区原本就是给大家的一个交换分享的平台，并不只是发问和解答的过程。除了 user 列表之外，对于一些比拟相熟的开发和设计，都能够给出本人的认识，每一个实在的想法对社区来讲都是有价值的。可能会有些小伙伴会放心英文的问题，其实集体感觉这个大可不必太放心，社区里的英文交换都是实用为主，只有把意思表白到位了就行，不必如许富丽的辞藻，也并不需要每句话都要惜墨如金思考各种语态时态的问题（当然也不是激励写一些语法有问题的句子）。
而后就是开发相干 的，如果你有比拟明确的 bug 或者 feature，能够间接去建一个 issue 即可。个别很快就会有小伙伴留神到你的 issue，并且跟你探讨并且确认问题，一旦达成统一，就能够开始写代码并且提 PR 了。当然了，除了本人提 issue 之外，也能够关注其余小伙伴们提的 issue，对于感兴趣的问题要及时点一个 watch，这样就能够及时理解该 issue 后续的探讨和停顿。
对于代码，社区对代码的要求还是十分高的。所以大家在社区写代码的时候，须要关注到各种细节，小到一个空格、一个空行，大到代码的设计模式和架构，社区的小伙伴都会精密的 review。这个过程也是十分锤炼人的一个过程。在逐渐参加的过程中，你会人不知; 鬼不觉的发现自己的代码程度在一直的进步了~
最初祝福各位感兴趣的小伙伴在都能够在社区欢快的奉献~