首先簡單做個自我介紹，我是李本超，是字節跳動基礎架構流式計算方向的工程師，主要負責 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。這個過程也是非常鍛鍊人的一個過程。在逐步參與的過程中，你會不知不覺的發現自己的代碼水平在不斷的提高了~
最後祝願各位感興趣的小夥伴在都可以在社區愉快的貢獻~
關注 Flink 中文社區，獲取更多技術乾貨
你在看」嗎？
