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 的差別點是什麼？
「A」：

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 才支持。