1、如何消除流查詢的不確定性影響
set 'table.optimizer.non-deterministic-update.strategy' = 'TRY_RESOLVE';
流查詢中的不確定更新(NDU)問題通常不是直觀的，可能較複雜的查詢中一個微小條件的改動就可能產生 NDU 問題風險，從 1.16 版本開始，Flink SQL (FLINK-27849)引入了實驗性的 NDU 問題處理機制 ’table.optimizer.non-deterministic-update.strategy’， 當開啓 TRY_RESOLVE 模式時，會檢查流查詢中是否存在 NDU 問題，並嘗試消除由 Lookup Join 產生的不確定更新問題（內部會增加物化處理），如果還存在上述第 1 或 第 3 點因素無法自動消除，Flink SQL 會給出儘量詳細的錯誤信息提示用戶調整 SQL 來避免引入不確定性（考慮到物化帶來的高成本和算子複雜性，目前還沒有支持對應的自動解決機制
2、從 Flink 1.17 版本開始支持 PLAN_ADVICE
指定 PLAN_ADVICE 將使得優化器（optimizer）分析優化後的物理執行計劃並提供潛在的數據風險預警或性能調優建議。 此時輸出標題將會從 “Optimized Physical Plan” 變爲 “Optimized Physical Plan with Advice” 作爲提示。
EXPLAIN PLAN_ADVICE
SELECT * FROM MyTable WHERE b > 100;
3、使用kafka連接器需要保證join的字段不能重複消費，否則會發散出很多條
使用upsert-kafka連接器join操作可以保證同一主鍵有重複數據時不重複join，
若是一個up-kafka source 一個kafka source join則還是會發散，join字段確定有重複數據，或者在源數據不是主鍵，則消費kafka join儘量使用upsert-kafka， flink state會把source讀取的數據都存在內存中，source有定義主鍵時，changelog 流join時有重複數據會找到狀態中該主鍵最後一次變更拿出來關聯，當不是changelog join時，即source沒有定義主鍵，如果重複join同一主鍵數據，則是狀態中存儲的該主鍵數據的笛卡爾積
4、使用kafka連接器join，如果有重複數據的話不能保證最終結果是確定的，即正確的。在join的字段有重複數據的情況下儘量使用upsert-kafka
5、upsert-kafka和kafka maxwell-json的join跟upsert-kafka和upsert-kafka的join效果一樣
ts timestamp(0) METADATA FROM 'value.ingestion-timestamp' VIRTUAL,
earliest_consume_dt as PROCTIME(),
binlog_dt timestamp(0),
earliest_consume_dt timestamp(0),
6、作業優化了以下幾項
1、使用rocksdb存儲大狀態、調整task內存和flink manger內存的比例爲8:2
-Dstate.backend.type=rocksdb
-Dstate.backend.rocksdb.memory.managed=true
-Dtaskmanager.memory.managed.fraction=0.2
2、調整了resourceManager的堆大小爲8g, nodeManager的堆大小爲4g，yarn集羣響應速度加快
3、使用兩階段本地聚合
set 'table.optimizer.agg-phase-strategy' = 'TWO_PHASE';
4、只設置taskmanager.memory.process.size內存參數，配合manager.fraction參數有效壓縮flink作業空閒的分配內存
5、flink on yarn防止容器內存超用被kill， 使用以下參數，slot使用3~4個，taskmanager.memory.flink.size設置16G，比設置4G，slot 10多個要好
-Dstate.backend.type=rocksdb
-Dstate.backend.rocksdb.memory.managed=true
-Dtaskmanager.memory.managed.fraction=0.2
-Dcontainerized.taskmanager.env.MALLOC_ARENA_MAX=1