18個PPT，29個提問解答，都在這兒啦！

4月25-26日，全球首個 Apache 頂級項目線上盛會 Flink Forward 中文精華版重磅開播，聚焦 Alibaba、 Google、AWS、Uber、Netflix、DellEMC、微網誌、滴滴等各大網際網路公司實時計算的經典場景和業務故事，由 Flink 核心貢獻者們對 19 個優質 talk 進行中文翻譯及解說，您可免費線上觀看。

為期一天半的 Flink Forward 中文精華版在北京、上海、杭州三地進行關聯直播，吸引了全球近 20000 人次開發者線上觀看。除優質内容外，Flink Forward 精華版還首次開創問題征集，線上觀看直播的同學可及時對嘉賓分享提出疑問并邀請講師線上解答。

大會全部提問及解答：

https://shimo.im/sheets/twgyxGh9hqy6DHYk/MODOC/ 直播回顧及 Flink 社群學習資料大禮包下載下傳請點選: Flink Forward 全球線上會議中文精華版0425 Flink Forward 全球線上會議中文精華版0426 以下選取了大會部分具有代表性的問題及講師回答，共享給大家。

Keynote: Introducing Stateful Functions 2.0: Stream Processing meets Serverless Applications

解說嘉賓：李钰（絕頂），Apache Flink Committer，Apache Flink 1.10 Release Manager，阿裡巴巴進階技術專家。

「Q」：PyFlink 支援 Stateful Function 嗎？另外 Stateful Function 的 State 管理是怎麼樣的？

「A」：目前暫不支援。

Stateful Function 的 State 管理和通常 streaming 作業的 State 管理是一樣的，并沒有作特殊處理。actor system 或者說應用這塊，它和 stream processing 有一個很大的差別在于流處理是一個 DAG (有向無環圖)的結構。但是 actor system 是可能有環的。Stateful Function 實際上是增加了一個 feedback loop 支援，但它并沒有去改動 runtime 核心，可以了解為是利用 streaming 自帶的 state 管理來做的。

圓桌 | Lyft: 基于 Flink 的準實時海量資料分析平台

解說嘉賓：王陽（亦祺），阿裡巴巴技術專家。

「Q」：Flink 實時寫 parquet 檔案會不會産生大量小檔案呀？怎麼處理小檔案問題呢？

「A」：用 StreamingFileSink 去寫 Parquet 格式的資料是會産生小檔案的，這樣會導緻 presto/hive client 去分析時性能比較差，Lyft 的做法是通過 SuccessFile Sensor 讓 airflow 自動排程一些 ETL 的任務來進行 compaction 和 deduplication，已經處理完成的會将 rawevent 的分區 swap 出去。這樣處理以後得到更好的資料品質，同時提升互動式查詢的性能。

演講 | 微網誌基于 Flink 的機器學習實踐

分享嘉賓：

• 于茜，微網誌機器學習研發中心進階算法工程師。多年來緻力于使用 Flink 建構實時資料處理和線上機器學習架構，有豐富的社交媒體應用推薦系統的開發經驗。
• 曹富強，微網誌機器學習研發中心系統工程師。現負責微網誌機器學習平台資料計算子產品。主要涉及實時計算 Flink，Storm，Spark Streaming，離線計算 Hive，Spark 等。目前專注于 Flink 在微網誌機器學習場景的應用。
• 于翔，微網誌機器學習研發中心算法架構工程師。

「Q」：Gemini 是怎麼使用的？

「A」：這個問題比較複雜，後期我們會在公衆号釋出詳細的使用說明及對比實驗。

Tips：後期微網誌機器學習研發中心團隊将就“如何使用 Gemini”主題分享一篇技術文章，除詳細的使用說明外還有對比實驗分析，敬請期待！

「Q」：樣本的多流 join 是基于哪種視窗實作的？

「A」：Flink 現有的視窗計算不能滿足我們的業務需求，我們用 union + timer 實作了滑動視窗，資料存儲到 map state 裡，底層采用 rocksdb + ssd 硬碟來存儲，并且自定義了樣本的 trigger 觸發機制。我們對比過 rocksdb，java heap 這兩種 state backend 的政策，在均衡業務場景，處理速度和硬體代價之後，最終選擇rocksdb + ssd 來作為 state 的 backend。

「Q」：多媒體特征計算是怎麼通過 Flink 支援的，能詳細解釋下嗎？這塊的穩定性如何？如何保證的?

「A」：首先我們在 gpu上部署算法模型，并且把模型封裝成 rpc 服務。然後通過 Flink 來調用 rpc 服務，實時的生成圖檔，視訊的各種特征。

穩定性 ：我們通過 Flink metrics，對整個作業的全流程做監控，包括但不限于rpc服務的耗時，成功率等名額。通過 At Least Once 機制來保證每條資料都處理一次。通過對 source （kafka) 端上的監控來監控整體作業的延遲。

另外根據業務場景引入了高可用的保障機制(對賬系統)，來保證資料處理的穩定性，目前重點業務可以達到99.999%的成功率。

「Q」：模型上線後如何使應用自動将原始輸入資料轉變成模型需要的輸入變量？

「A」：模型上線預測時，在線上系統中，我們從特征服務中擷取特征字段，拼接出原始特征資料，然後經過一個特征處理的子產品，将原始樣本轉化為模型需要的輸入資料（可以是libsvm格式或者是适合 DNN 的其他資料格式），然後傳到模型服務子產品，特征處理的輸出的資料格式以及特征處理的代碼，訓練與預測時保持一緻的，唯一的差別在于訓練的資料相對線上預測的資料會多出 label 相關的字段。

演講 | Alink：提升基于 Flink 的機器學習平台易用性

分享嘉賓：楊旭（品數），阿裡巴巴資深技術專家。

「Q」：支援實時機器學習的算法多嗎？如何防止個别奇異值對模型的影響？

「A」：Alink 所有的分類、回歸模型都支援流式資料的預測，線上學習算法方面目前支援 FTRL。在各個模型訓練時，有對特殊資料的處理，另外，使用 Alink 的資料處理元件，也可以在訓練前進行資料清洗。

「Q」：1.10 已經沒有 FlinkML 了吧？FlinkML 和 ALink 之間的關系是？

「A」：FlinkML 為 Flink 自帶的機器學習算法庫，分為舊的版本和新的版本。在做 Alink 前，我們首先認真調研了當時的 FlinkML（即舊版本 FlinkML）的情況，其僅支援 10 餘種算法，支援的資料結構也不夠通用，在算法性能方面做的優化也比較少，而且其代碼也很久沒有更新。是以，我們放棄了基于舊版 FlinkML 進行改進、更新的想法，決定基于 Flink 重新設計研發機器學習算法庫，随後發展為現在的 Alink。

在 Alink 發展的過程中，我們一直與 Flink 社群緊密關聯，在每年的 Flink Forward 大會上彙報我們的進展，共同探讨技術問題，擷取回報和建議。随着 Alink 功能的不斷增強和完善，社群中歡迎 Alink 進行開源的呼聲日益高漲，我們可開始和 Flink 社群更緊密聯系，推動開源 Alink 的代碼進入 FlinkML。

與此同時，社群中更多的人意識到舊版 FlinkML 的問題，決定整個廢棄掉舊版 FlinkML，建設新版 FlinkML。我們積極參加新版 FlinkML API 的設計，分享 Alink API 設計的經驗；Alink 的 Params 等概念被社群采納；之後開始為新版 FlinkML 貢獻算法實作代碼，已送出了 40 餘個 PR，包括算法基礎架構、基礎工具類及若幹算法實作。

Alink 包含了非常多的機器學習算法，在向 FlinkML 貢獻的過程中，需要社群 commiter 的讨論設計與審查代碼，這個過程有助于代碼的精益求精，但由于社群 commiter 的資源有限，代碼完全貢獻到 FlinkML 的過程會持續很長時間。這時，我們不得不考慮是否有其他方式，可以讓使用者先用起來，Alink 單獨開源是個很好的解決方式，它與向 FlinkML 繼續貢獻算法實作，可以同時進行。使用者的使用回報也有助于我們更好的改進算法實作。此想法獲得了社群的支援，獲得了公司内上司和同僚的支援，在 Flink Forword Asia 2019 大會上，宣布了 Alink 開源。

圓桌 | Flink SQL 之 2020：舍我其誰

解說嘉賓：伍翀（雲邪），Apache Flink PMC，阿裡巴巴技術專家。

「Q」：demo 裡的 catalog 裡表的中繼資料是基于記憶體的還是持久化到外部存儲的？

「A」：demo 裡有注冊了兩個 catalog，一個 default catalog（記憶體），一個 hive catalog（持久化），兩種 catalog 都能存批的表和流的表（其實 Flink SQL 不區分流和批的表）

「Q」：本案例跟您上一次(2020年2月份)講的 flink SQL 案例 中用到的特性有什麼不一樣嗎？

「A」：本次 demo 覆寫的 feature 更全，包括 4 種 join，流批一緻性，CEP 等等。

圓桌 | Apache Flink 誤用之痛

解說嘉賓：孫金城（金竹），Apache Member，Apache Flink PMC，阿裡巴巴進階技術專家。

「Q」：Flink 視窗計算，heap 狀态存取消耗很多 cpu，對比 spark 相同邏輯視窗計算多耗很多 cpu，請問有沒有優化方案？

「A」：這個要看具體的場景，需要更細緻的場景說明一下？一般的優化方法如下：

1. 盡量用增量聚合替代全量聚合[1]。不僅減小 state 的大小，而且能在資料抵達視窗時就開始計算。
2. 注意下 Type 是否都能被 Flink 識别，否則序列化反序列化會用預設的 Kryo，導緻序列化反序列化加大 cpu 開銷[2]。可以配上

   env.getConfig().disableGenericTypes();

   來禁用 Kryo，驗證下是否類型都被Flink識别了。

[1]

https://ci.apache.org/projects/flink/flink-docs-master/dev/stream/operators/windows.html#processwindowfunction-with-incremental-aggregation

[2]

https://ci.apache.org/projects/flink/flink-docs-stable/dev/types_serialization.html#data-types-serialization

「Q」：請問多個視窗級聯相同的 keyby 可以使用 datastreamutil 嗎？多個 key 特别長有沒有方法優化

「A」：

1.可以用 DataStreamUtil 來級聯，避免多次 shuffle。

2.業務上如果有辦法優化 key 的長度是最好的，比如減少字段數；或者抽取指定長度或位置的資料作為 key。其次，技術上可以将 key hash 下，比如取 md5，但是這個會帶來多餘的 cpu 損耗，需要和 key 偏長而帶來的網絡或 io 損耗來權衡，看哪個代價更高。

圓桌 | Uber ：使用 Flink CEP 進行地理情形檢測的實踐

解說嘉賓：付典，Apache Flink Committer，阿裡巴巴技術專家。

「Q」：CEP 一般怎麼調優性能？

「A」：Flink CEP 裡，規則的複雜程度對于性能影響很大，是以如果遇到性能問題，可以從是否可以從業務的角度簡化規則的角度來優化

「Q」：那個不同的 key 的視窗錯開是使用自定義視窗 trigger 嗎？

「A」：可以了解為實作了一個自定義的 WindowAssigner，WindowAssigner 針對每個 key 在調用的時候，加入了随機的因素，進而使得不同的 key 得到的視窗範圍不一樣。

演講 | A deep dive into Flink SQL

分享嘉賓：伍翀（雲邪），Apache Flink PMC，阿裡巴巴技術專家。

「Q」：minibatch 減少與 state 互動的方式可以在 datastream 中用嗎？

「A」：minibatch 優化目前隻在 SQL 層的聚合算子中實作了，DataStream 中用不了。

「Q」：Flink SQL 為了支援流批統一，底層用了大量 CodeGen 技術，同樣的 SQL 在底層 codegen 出不同的代碼，這個 codegen 過程消耗時間嗎？對應批，尤其是 OLAP 這種場景，需要快速出結果的場景，codegen 會占整個過程時間的比例？

「A」：目前 codegen 發生在編譯期，是以隻執行一次，是以對于流作業和批作業都還好。不過對于 OLAP 場景确實對于 codegen 以及 代碼編譯都會非常敏感，也是以後的一個優化方向，目前還沒有評測過 codegen 的耗時。

「Q」：stream 模式可能拿不到 statistics 的情況下 join 的優化是怎麼做的？

「A」：目前流計算模式的所有優化都是确定性的優化，沒有考慮 statistics。不過批的優化已經考慮了。在拿不到 stats 的時候，我們會有預設的統計值，比如 rowcount=10^8。

演講 | Flink's application at Didi

分享嘉賓：薛康，現任滴滴技術專家，實時計算負責人。畢業于浙江大學，曾任百度進階研發工程師，對大資料生态建設有豐富經驗。

「Q」：能講一下 streamsql 線上 debug 功能實作原理嗎？

「A」：解析 SQL，替換 source 和 sink 為檔案和标準輸出，然後正常執行 DML，把結果列印到标準輸出，展示在平台上。

「Q」：sql IDE 中寫的 sql ，血緣關系是怎麼實作的？

「A」：每個 connector 會上報連接配接的資料源資訊，比如 kafka 叢集、topic等，作為名額上報到 kafka，然後存入 druid，由平台串聯各個環節，組成完整鍊路。

「Q」：想問下怎麼監控各個 flink 叢集中作業的運作狀态，類似于 flink-web 上的每個作業狀态（運作或失敗）。

「A」：定期通過 yarn api 拿到每個 app 的 JM 位址，通過 JM 的 restful API 拿到正在運作的 job 資訊，判斷每個 job 的啟動時間，如果在兩次判斷之間，說明期間有過重新開機，累積一定次數就可以報警。注意判斷剛送出的情況。

「Q」：kafka table 的中繼資料管理，group.id,start-mode 這種運作時參數怎麼持久化？還是隻儲存靜态的 kafka connection 資訊 / schema 資訊，group.id/start-mode 等作為表參數傳入？

「A」：确實，隻儲存靜态資訊，比較個性化的運作時資訊作為參數，通過 set key=value 的形式作為 job 的一部分一起送出。

演講 | Data Warehouse, Data Lakes, What's Next?

分享嘉賓：金曉軍（仙隐），阿裡巴巴進階技術專家。

「Q」：hologres 能支援高性能的更新操作來實作 Flink RetractSink 嗎?

「A」：可以支援。其實如果用了 hologres,直接存明細就好了，大部分場景不需要做預聚合，需要的時候直接查詢。

「Q」：hologres 大資料量的查詢效率如何？能支援更新删除操作不？

「A」：可以支援，目前線上有萬億級别的表做多元分析，能夠在200ms以内算出結果。hologres 支援更新和删除。

「Q」：hologres 相較于現在社群的資料湖架構 hudi,delta 和 iceberg 的差異點是什麼？

1. hologres 是資料 ingestion 實時生效，而目前開源方案是 mini-batch，類似于flink和 spark streaming 的差別。
2. Hologres 本身是提供服務能力，可以直接給線上應用提供服務，更高的SLA。
3. hologres 能提供高 qps 的查詢能了，可以直接作為 flink 的維表。

演講 | 終于等到你：PyFlink + Zeppelin

• 孫金城（金竹），Apache Member，Apache Flink PMC，阿裡巴巴進階技術專家。
• 章劍鋒（簡鋒），Apache Member，Apache Zeppelin PMC，阿裡巴巴進階技術專家。

「Q」：既然定位在全面整合 Python，那麼加強 Jupyter notebook 就好了吧，Zeppelin vs Jupyter怎麼考慮？

「A」：首先 PyFlink 會在 Zeppelin 和 Jupyter 中都會進行支援，目前是 Zeppelin走在前面。Zeppelin vs Jupyter 來講 Zeppelin更加側重大資料的計算場景， Jupyter 更貼合機器學習的場景，Zeppelin 可以多租戶企業級使用，Jupyter 更适合單使用者場景。

「Q」：flink on zeppelin 的最佳應用場景有哪些？

「A」：批流計算的 ETL 和資料分析，适合用 flink sql，pyflink 和 table api。

「Q」：Zeppelin 對 K8s 的支援目前如何，社群有這塊的規劃嗎？另外 Zeppelin on K8s 為啥選擇使用 Pod 來部署 Zeppelin Server 而不是 statefulset 或者 deployment 呢？

「A」：這塊正在做，依賴于 flink 對 k8s 的支援，預計 zeppelin 0.9 + flink 1.11 可以完美支援 k8s。

Production-Ready Flink and Hive Integration - what story you can tell now?

解說嘉賓：李銳（天離），Apache Hive PMC，阿裡巴巴技術專家。

**「Q」：既然有 hive 了，也有好用的 Hive 用戶端工具，比如 dbvis。如果公司業務是使用 hive 做離線批查詢，值得再通過其他架構這樣整合嗎？我直接使用 dbvis 來做 hive 分析不就好了？

疑問：Hive 是批分析工具，有必要強行和流整合嗎？專工具專用是不是更好些？**

「A」：還是有不少使用者需要對 hive 做實時化改進的，比如實時寫入，或者通過 presto、impala 等做互動式查詢。Flink 與 Hive 整合可以完全是批的模式，擷取比 Hive 原有批處理更好的性能。另一方面我們也觀察到有使用者希望能夠實時的消費寫入 Hive 的資料，這種情況就需要跟流整合了。

「Q」：1.10 中可以在 hivecatalog 上建 kafka 表，是不是已經可以接 kafka 資料寫人 hive 表中了（及批流已經統一了）？

「A」：不是的，1.10 隻是通過 hive catalog 來儲存 kafka 表的中繼資料，但寫入實際資料的時候還是隻支援批式的寫入。流式寫入 hive 表要 1.11 才支援。