摘要：1 月 8 日，Flink Forward Asia 2021 邀請到了幾位國內外頂尖科技公司實時計算方向的負責人，舉辦了兩場圓桌分享。本文為大家帶來北京場題為《行業先鋒暢聊 Flink 未來》的圓桌分享的精彩內容。本場圓桌主要討論了三個話題：
- 如何看待 Flink 與實時計算的未來？
- 如何看待 Flink 與其他開源專案的關係？
- 如何看待企業與開源社群之間的關係？
一、如何看待 Flink 與實時計算的未來
是否可以認為 Flink 在實時計算方面已經趨於成熟？各位嘉賓眼中實時計算的未來是什麼樣的？距離實現這樣的未來，Flink 還需要探索哪些領域、解決哪些問題？
王加勝：功能趨於成熟，應用領域有待擴充套件
我個人認為，成熟有兩個比較重要的標誌：功能趨於完善、在核心場景下得到大規模的應用。我認為 Flink 現在在功能層面已經趨於成熟，包括對實時計算和流批一體的支援。但在應用方面，Flink 還需要推廣更多的業務。期待 Flink 在更多的領域發揮更大的作用。
董亭亭：流式計算趨於成熟，流批一體仍有較大探索空間
流式計算領域，Flink 已經是業界事實標準，是各公司流式計算選型的首選，在穩定性和易用性方面也越來越成熟。作為流批一體引擎，Flink 在批處理方面仍有較大探索空間，例如動態資源排程、推測執行等能力，以及湖倉一體、OLAP 等應用場景。在這方面，社群和各公司也在積極推動、探索，還不能說是成熟的。
鞠大升：Flink 是一種趨勢，未來前景會更光明
從資料處理領域來看，Flink 現階段已經達成了一種趨勢，但還不是成熟。衡量是否成熟要看兩個方面：從在業務應用場景的實際使用情況來看，目前 Flink 在流式處理的趨勢已經達成，批式處理仍以 Spark 為主，資料湖、增量生產才剛剛起步，所以從應用角度來說，Flink 的使命任重而道遠；從技術能力來說，Flink 在批處理、大狀態作業執行、容災恢復等方面還有進步空間。期望 Flink 在資料處理領域發揮更大的作用、增長出更多的能力和場景。
張光輝：流式計算場景相對成熟，技術層面進一步提升
Flink 在流式計算的場景已經相對成熟，在實時數倉、實時 ETL、實時機器學習都已經有大規模落地，隨著 Hybrid Source、CDC connector、實時入湖入倉等技術的開源，對業務場景的覆蓋面已經比較廣了。但在技術層面上，還有一些需要未來進一步探索的地方，比如狀態和計算的存算分離、彈性計算應對突發流量的能力、更優秀的容錯能力等。
王峰：流計算要走向極致，實時計算不只是流計算
大資料的整體趨勢是向實時化演進，Flink 在其中充當了先鋒的作用。Flink 在流處理技術方面已經走向成熟，但還沒有達到極致。比如，Flink 在雲原生的挑戰下如何動態的適配彈性擴縮容，如何實現徹底的存算分離架構，如何提升容錯能力做到 zero downtime。我覺得在流計算方面，Flink 接下來應該朝著極致方向去演進。
實時計算這個大的概念並不等於流計算。當資料發生變化時，第一時間感知變化、按預定邏輯進行處理，這是流計算所做的事情；同時，實時計算還有其他的形態，比如要對一批資料進行毫秒級、秒級的分析，這依然是實時計算的範疇。Flink 在對存量資料進行高時效分析方面還有很大發展空間，依賴其流批一體的能力、高效的計算引擎可以實現更大場景資料的實時化。
二、如何看待 Flink 與其他開源專案的關係
目前行業內有很多 Flink 與其他生態專案相結合的成功案例，同時 Flink 在許多方面也面臨著與其他開源專案的競爭。各位嘉賓如何看待 Flink 與這些生態專案之間的關係？Flink 在整個開源大資料生態中應該如何定位、如何保持差異化？
王峰：保持開放，創新發展、良性競爭
Flink 需要保持開放性，這是開源系統的基本理念。我們需要和其他的開源專案很好地協同，形成生態系統。Flink 目前已經和上下游系統有了很好的對接，通過 connector 可以連線不同的資料庫、資料倉儲，部署方面也相容了 Hadoop、Kubernetes 的生態。未來我們需要繼續堅持。
Flink 和一些生態專案之間可能會有一些 overlap，這種競爭在我看來是偏良性的。使用者需要的其實是完整、方便的體驗，可能很難分清楚各個引擎元件的邊界。目前看到的趨勢，各個生態專案都在擴充套件自己的邊界，基於自己的核心優勢向前邁一步，讓使用者使用更方便，這是一種良性競爭。Flink 也是一樣，基於純流式執行引擎的核心優勢，可以構建流批一體的分析能力，相容離線的一些場景；基於 Flink SQL，可以做短查詢、OLAP 分析，做有限資料集的分析、查詢加速；Flink 接下來在流批一體的儲存資料格式上也會有自己的創新，實現流批一體計算和流批一體儲存的結合，實現流式數倉理念，實現一站式大資料分析體驗。
所以，我覺得各大生態之間既要保持開放性、能夠相互整合和對接，又要有各自的創新發展，給使用者更好的體驗。
張光輝：合作實現一加一大於等於二
從現狀來看，Flink 和其他生態專案之間更多的是合作關係。比如構建實時數倉，上游需要 Kafka，中間使用 Flink，把計算結果匯入 Doris 去做實時分析。我認為 Flink 和其他生態專案的合作，能夠實現一加一大於等於二的狀態。
鞠大升：正確看待競合關係，發揮優勢創造價值
合作與競爭是開源社群經常會遇到的話題。我們應該正確看待合作與競爭的關係，分析自己的優勢和劣勢，更好地發揮自己的優勢，為使用者提供更多的能力，這是非常重要的。具體到這個問題，我認為目前在業界有三塊：一是 MQ 上的輕量化事件處理能力；二是類似 Kafka、Hudi 資料湖等。這些我認為是偏合作的關係，通過實時更新能力，讓數倉更多地達到增量生產的能力，而不單單是批式或者流式處理的數倉；第三是 OLAP 場景，在這方面我認為確實是競合關係。所謂競爭，是在生產和應用這兩個專案時，當其中一個的能力很強時，一定會侵佔另一個的市場，這是不可避免的。而這二者無論哪個做的越來越好，都一定會給使用者提供更多的價值，這是從合作的角度。比如我們提出實時數倉，採用 Flink + Doris，他們之間是合作的關係，但在某種程度上也是競爭的關係。
關於如何保持差異化的競爭，我覺得 Flink 可以看到自己弱勢的地方並加以改進。比如 Flink 的狀態對使用者是偏透明的，終端使用者無法觸達狀態資料，無法分析，在這一點上可以做的更好。
董亭亭：保持生態融合，提升自身競爭力
關於合作，Flink 是流批一體的計算引擎。如果要實現全鏈路的流批一體，除了計算引擎的流批一體，還要依賴儲存引擎的流批一體。所以，Flink 可以和 Prevaga、Hudi 等儲存引擎保持很好的合作關係，和整個生態更加融合，讓使用者有更多的選擇，也能夠很好地與其他引擎配合，從而實現真正的全鏈路流批一體、湖倉一體建設。
關於競爭，在計算引擎領域，各社群確實存在一些競爭關係。Flink 需要提升自己的競爭力，比如在 Batch 引擎能力方面是否能和 Spark 拉齊、是否能夠具有可替代性等。
王加勝：專注計算，與儲存系統保持合作關係
大資料領域技術發展，儲存計算分離更加符合未來的趨勢。一方面，儲存層和計算層各自迭代，速率更快，更有優勢；另一方面，無論儲存層還是計算層，單一引擎長時間內都很難支援所有場景，依然需要通過多個引擎來覆蓋業務場景，分離的狀態可以更多地滿足各種場景的需求。因此，Flink 應該專注計算層面，需要和儲存層面的相關專案有很好的合作關係，一起為業務提供比較好的使用體驗。
Clickhouse、Doris 等專案也在做流式計算的探索，這些專案最大優勢在於查詢效率等方面，他們做流式計算的探索的優勢是降低了使用者使用的複雜性。這些專案相對於 Flink 偏弱的是，Flink 在實時計算方面領先比較多，對於實時計算領域的支援更加好。如果 Flink 在使用體驗、接入門檻等方面進一步改進的話，加上其強大的功能，依然可以保持非常強的競爭力，能夠覆蓋更多的應用場景、連線更多系統、支援更多業務場景，在儲存計算分離的生態中，在計算層面佔據重要地位並保持優勢長期發展下去。
三、如何看待企業與開源社群之間的關係
使用和貢獻開源專案有哪些優勢，過程中遇到過哪些挑戰？如何看待企業內部實踐創新與開源社群之間的關係？各位嘉賓所在團隊都在做哪些有關 Flink 的探索，接下來有哪些規劃，有哪些打算貢獻社群的創新技術？
王加勝：積極擁抱開源，探索湖倉一體、流批一體
小米對於開源的態度是非常開明的，我們積極擁抱開源，認為開源有很大的優勢。一方面，藉助開源的力量，我們能通過較少的人力投入，支撐非常複雜的業務場景，滿足各種業務的複雜需求；另一方面，通過參與開源，我們能夠和業界非常優秀的工程師，共同進行技術交流，提高自己的技術能力。
我們目前在 Flink 方面的探索：一是結合 Flink + Iceberg 做湖倉一體的嘗試，希望為業務提供近實時數倉的開發和使用體驗；二是流批一體方面的嘗試，通過 Flink 把公司內部實時整合和離線整合的技術棧做了統一。後續也會在其他方面進一步探索。我們遇到的挑戰，主要來自專案的使用門檻和開發運維體驗。開源專案賦予了我們強大的核心能力，在實際業務應用過程中，還是要解決複雜性問題、降低使用者使用門檻，這是一個挑戰。
關於內部實踐與開源社群的關係，我認為每家公司根據自己的特殊場景和需求，基於開源的版本做一些內部特性的適配，是很有必要的。針對這些特性，整體原則是儘量不要侵蝕核心程式碼，避免和社群割裂導致運維困難。其他一些功能迭代開發方面，我們堅持先到社群參與討論，吸收業界優秀工程師建議，保證我們的設計是合理的正確的，並爭取合併到社群。
董亭亭：開源有很多優勢，版本跟進是挑戰
開源專案的優勢有很多，比如我們可以跟社群做一些交流，遇到問題時可以吸收到很好的想法思路和設計建議，減少試錯成本；我們還能夠享受到社群程式碼帶來的一些紅利，借鑑社群成熟的解決方案，避免重複造輪子。
過去一段時間，快手在 Flink SQL 方面也和社群進行了一些合作，包括跟進、參與社群的一些功能、issue 的開發，也貢獻了我們內部自研的像漸進式視窗這樣的功能。在引擎方面，我們做了熱更新模型、限流策略等在我們內部業務使用場景上反饋比較好的功能，也在和社群討論準備把這些功能貢獻給社群。
我們在跟進社群最新版本的過程中是有一些挑戰的。比如一些內部自研功能，不是很通用，適配我們公司內部的一些場景需求。社群新發版本，我們需要把這些功能 Cherrypick 到社群的版本上，在 Cherrypick 程式碼、推進業務升級等方面會有額外的人力成本。所以我們基本上每隔一年跟進一次社群的最新版本，把內部功能合併到一起。
鞠大升：開源專案加速技術領域的發展應用
我認為開源專案能夠很好地加速一個技術或者領域的發展和應用過程。具體來說，一家公司藉助開源專案能夠很快啟動在這個領域的探索。另外，開源專案能夠把相關領域的問題集中起來，讓大家共同參與解決相關領域的問題，促進相關領域的問題快速迭代、快速解決，促進相關領域的發展。這些方面的優勢是非常明顯的。
美團在 Flink 方面的規劃基本分為三個方面：實時數倉方面，期望通過 Flink + Doris 鏈路，構建實時數倉開發的場景；增量數倉方面，通過 Flink + Hudi，達到近實時資料產出效果；離線場景下，期望將引擎統一到 Flink。我們期望讓業務方根據成本、時效性選擇不同場景，保持語言和底層引擎的一致，給業務方提供這樣的便利。
使用開源專案的過程中遇到的挑戰有兩個方面：一是我們發現開源專案普遍不太關注可運維性。可運維性更多需要結合公司內部的生態技術去做，開源社群不知道公司內部運維環境，在這方面關注比較少。這也是大部分公司在使用開源專案時第一個需要解決的困難。二是在開源專案上做的比較深入的時候，如果社群發展比較慢，公司可能是等不及的，需要做很多 Feature 甚至大版本的迭代。這是對公司的一個挑戰，反過來也是對社群發展速度的一個挑戰。
接下來，我們可能會在 Flink 實時更新的方面做流批一體的嘗試，希望這些嘗試的方案和想法能夠跟社群分享。
張光輝：企業與社群相輔相成、相互促進
位元組內部針對 Flink 做了非常多的技術探索。在 SQL 方面更多的是功能方面的探索，比如延遲 join、增加聚合指標、能從 checkpoint 恢復、以及內部的各種 connector。在 state checkpoint 方面我們更多的是效能方面的探索，比如小檔案聚合、state 使用者可查、通過 cache 減少 RocksDB State Backend 序列化、反序列化的效能損耗。在 runtime 側，我們更多的是提升穩定性，比如黑名單機制、單點故障恢復能力等。
我認為使用開源專案的優勢是，我們能以更少的人力投入、更短的時間，把一套更優秀的技術在內部的業務場景落地。我們遇到的最大挑戰是版本升級。社群版本的升級迭代還是比較快的，我們內部積累了非常多的 feature 來不及貢獻社群，每次版本升級、業務遷移的成本是非常大的。
我認為內部實踐和開源社群，整體上是一個相輔相成、互相促進的關係。具體來說，位元組有一些上萬併發的超大作業，每次重啟需要花費十分鐘左右，這是我們業務無法容忍的。我們跟社群溝通了這些問題，社群同學也跟我們積極對接，很快就達成了一系列的解決方案，在後續版本中解決了這些問題，將作業的重啟速度提升了 2-3 倍。
未來規劃：在實時計算場景，我們會在提升彈性計算的能力、狀態的儲存計算分離、提高容錯性這些方面做一些探索。在流批一體方面，我們會推更多的業務，把 Flink 的優勢釋放出來，解放和提升業務的生產力。另外我們在短查詢方面有一些探索和落地，後續會把這方面做的一些排程效能、SQL 效能的優化回饋到社群。
王峰：推崇開源技術體系與企業業務及人才培養相結合的模式
“開源” 是一個非常有熱度的話題。國家規劃已經提出，中國在基礎的核心技術上要自主可控、開源開放，希望國內各企業能夠通過開源形成協同力量、提升國家的軟體基礎設施。阿里巴巴這些年對開源的擁抱是越來越積極的，也成立了開源委員會。Apache Flink 這個專案也是一個典型代表，相信業界的公司都能感受到阿里巴巴在 Flink 開源專案上的支援和投入。我現在所在的團隊，有幾十位工程師、核心技術人員是全職投入到 Flink 開源專案。
剛剛董亭亭、張光輝也提到了，快手和位元組所在的流媒體行業實施業務量非常大，遇到了很多技術挑戰，也希望把在這種極致挑戰中解決的問題貢獻給社群，可能受限於社群版本釋出太快，無法更好的融合。在這一點上我們的經驗和建議是，希望國內頭部的網際網路公司可以更多地投入到開源社群的建設，讓公司的工程師有更多的時間投入到開源社群建設裡。有越多的人投入，就有越多的機會產生 Committer、PMC Member，在社群就有更多機會發言、有更多機會把自己的東西推入社群，對社群的影響力也就越大，形成良性迴圈。也希望 Apache Flink 社群能夠吸納到更多公司的 Contributor 參與併成為 Committer，這樣剛才很多問題都可以自然地在開源社群中解決。
企業內部技術實踐和開源社群是非常密切的關係。我們相信開源社群的貢獻者、核心開發者，都在一家技術驅動的公司工作。開源社群中很多的想法和需求，其實是來自於各家企業、各個行業。因此，內部業務的技術實踐是開源社群的源泉。此外，開源社群釋出的版本，需要到各個企業、行業去實踐，這也是開源專案很大的一個優勢。開源專案是免費的，大家都願意去使用，用非常低的成本去擴充市場。這麼多使用者、行業、公司、場景使用後，會給社群提供豐富的反饋。開源社群基於這些反饋可以快速地迭代，然後再到各個公司去實踐。這是開源專案能夠快速發展並得到大家認可的一個很好的機制。這裡面也包括了技術創新，開源社群是一個紐帶，在這裡大家能夠看到各個公司是怎麼使用這個專案的、各個公司的問題是什麼，你的創新想法也可以被別的公司使用，形成一個很好的孕育技術創新的環境。企業參與到開源社群裡，基於開源開放的技術體系，與自己的業務、人才培養結合起來，我覺得這是一個非常好的模式。
更多 Flink 相關技術問題，可掃碼加入社群釘釘交流群
第一時間獲取最新技術文章和社群動態，請關注公眾號～
