4月25-26日，全球首個 Apache 頂級項目在線盛會 Flink Forward 中文精華版重磅開播，聚焦 Alibaba、 Google、AWS、Uber、Netflix、DellEMC、微博、滴滴等各大網際網路公司實時計算的經典場景和業務故事，由 Flink 核心貢獻者們對 19 個優質 talk 進行中文翻譯及解說，您可免費在線觀看。
為期一天半的 Flink Forward 中文精華版在北京、上海、杭州三地進行聯動直播，吸引了全球近 20000 人次開發者在線觀看。除優質內容外，Flink Forward 精華版還首次開創問題徵集，在線觀看直播的同學可及時對嘉賓分享提出疑問並邀請講師在線解答。
▼Flink Forward 中文精華版 PPT 下載▼
掃描下方「Flink 中文社區」公眾號二維碼，後臺回復關鍵字【0425PPT】即可下載大會全部分享內容～
以下選取了大會部分具有代表性的問題及講師回答，共享給大家。
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 的數據處理組件，也可以在訓練前進行數據清洗。圓桌 | 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]。不僅減小 state 的大小，而且能在數據抵達窗口時就開始計算。
注意下 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 的差異點是什麼？
「A」：
1. hologres 是數據 ingestion 實時生效，而目前開源方案是 mini-batch，類似於flink和 spark streaming 的區別。
2. Hologres 本身是提供服務能力，可以直接給線上應用提供服務，更高的SLA。
3. hologres 能提供高 qps 的查詢能了，可以直接作為 flink 的維表。
演講 | 終於等到你：PyFlink + Zeppelin
分享嘉賓：
「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 才支持。
https://shimo.im/sheets/twgyxGh9hqy6DHYk/MODOC/直播回顧及 Flink 社區學習資料大禮包下載請點擊「閱讀原文」～