首先簡單做個自我介紹，我是李本超，是位元組跳動基礎架構流式計算方向的工程師，主要負責 Flink SQL 方向。最近非常有幸受邀成為 Apache Flink Committer。
（來自 PMC Member 的邀請郵件）
我參與社群主要是從19年下半年開始的，最開始主要是彙報一些使用過程中遇到的 bug，并且會力所能及的去修複它。與此同時也一直在關注 user 和 dev 郵件清單，一方面了解社群的最新進展和未來發展方向；一方面也在從其他人的提問和回答中學習經驗。後來随着了解的深入，也就參與到了幫助解答使用者問題，參與設計的讨論、以及感興趣的 issue 的讨論等。
社群篩選 Committer 的條件是比較均衡的，各種形式的參與貢獻社群，都會被記錄和認可，比如貢獻代碼，貢獻文檔（包括翻譯），參與各種形式的讨論，幫忙解答使用者的提問等。從我個人的角度來講，這些方面都做了一定程度的參與，做的最突出的一個點主要是在 user 清單裡活躍的比較突出。
本篇文章主要是介紹我自己參與社群的過程和一些心得體會，主要從以下幾個方面進行了介紹：
- 初識 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。這個過程也是非常鍛煉人的一個過程。在逐漸參與的過程中，你會不知不覺的發現自己的代碼水準在不斷的提高了~
最後祝願各位感興趣的小夥伴在都可以在社群愉快的貢獻~