1. 直接加到內(nèi)存，起一個線程定時更新維表。

# 優(yōu)點：實現(xiàn)簡單

# 缺點：適用于維表不是太大，維度更新不頻繁場景

# 適用場景：維表小，變更頻率低，對變更及時性要求低

2. 通過Distributed Cache 分發(fā)本地維度文件到task manager后加載到內(nèi)存關(guān)聯(lián)。

* 通過env.registerCachedFile注冊文件。實現(xiàn)RichFunction，在open()中通過RuntimeContext獲取cache文件。

# 優(yōu)點：不需要外部數(shù)據(jù)庫

# 缺點：支持維度數(shù)據(jù)量比較小，更新需要更改文件并重啟作業(yè)

# 適用場景：維度數(shù)據(jù)是以文件形式，數(shù)據(jù)量小，更新頻率低。

比如：靜態(tài)碼表，配置文件。

3. 熱存儲關(guān)聯(lián):利用Flink的RichAsyncFunction讀取外部存儲的數(shù)據(jù)到緩存中，我們在關(guān)聯(lián)維度表時先去查詢緩存，如果緩存中不存在這條數(shù)據(jù)，就利用客戶端去查詢外部存儲，然后插入到緩存中, 可以使用 Guava 庫提供的 CacheBuilder 來創(chuàng)建緩存。

外部存儲可以是HBase,Redis等

* 這里需要特別注意的是，我們用到了異步 IO (RichAsyncFunction)，這個功能的出現(xiàn)就是為了解決與外部系統(tǒng)交互時網(wǎng)絡(luò)延遲成為系統(tǒng)瓶頸的問題。

# 優(yōu)點：維度數(shù)據(jù)不受限于內(nèi)存，支持較多維度數(shù)據(jù)

# 缺點：需要熱存儲資源，維度更新反饋到結(jié)果有延遲（熱存儲導(dǎo)入，cache） # 適用場景：維度數(shù)據(jù)量大，可接受維度更新有一定的延遲。

4. Broadcast 流 1. 將維度數(shù)據(jù)發(fā)送到Kafka作為流S1。事實數(shù)據(jù)是流S2。

2. 定義狀態(tài)描述符MapStateDescriptor，如descriptor。

3. 結(jié)合狀態(tài)描述符，將S1廣播出去，如S1.broadcast(descriptor)，形成廣播流(BroadcastStream) B1。

4. 事實流S2和廣播流B1連接，形成連接后的流BroadcastConnectedStream BC。

5. 基于BC流，在KeyedBroadcastProcessFunction/BroadcastProcessFunction中實現(xiàn)Join的邏輯處理。

# 優(yōu)點： 維度變化實時感知

# 缺點： 需要將維度變化數(shù)據(jù)轉(zhuǎn)換為Kafka流，維度數(shù)據(jù)保存在內(nèi)存中，支持的數(shù)據(jù)量相對較小

# 使用場景： 維度數(shù)據(jù)量小，維度變化敏感

5. Flink SQL 實現(xiàn)維表Join