本文在綠泡泡“狗哥瑣話”首發於2024.12.15 <-關注不走丟。

上期講Flink Forward Aisa的視頻比較受歡迎，這期加更講Fluss。

為了方便新觀眾瞭解Fluss。簡單介紹一下Fluss，這玩意兒主要是為實時分析而生的流存儲。

所以它會有和Kafka一樣的能力，但是比起Kafka，多一個直接查的能力。

用在數據湖場景，比如配合Paimon，那麼就可以當作一個實時層，整個鏈路的延遲會更低。

總體概覽

接下來看一下它的架構。

從架構圖上看挺清晰的。主要是角色就是Coordinator和TableServer。

Coordinator相當於控制面，管元數據和一些集羣操作（比如數據平衡啊、節點故障的切換啊之類的）。

TableServer負責數據存儲並直接面向用户提供IO服務。主要由兩個部分組成：

• LogStore
• KvStore

因為Fluss支持兩種表的創建，一種是日誌表，相當於是Kafka的場景，支持流讀流寫。這種表用上LogStore組件就行了。

還有一種是主鍵表，對於同個主鍵的操作是upsert的。這裏的話就要用到KvStore了，LogStore在這個時候的作用就是發CDC的，然後做個WAL的存儲。

其他的角色：

• ZK是用來協調Coodinator，還有存儲它們的一些元數據。
• Remote Storage主要是做LogStore的分層，以及KV Store數據的持久化——快照級。LogStore裏是明細級。但這裏並不只是個備份，客户端的讀是會打到上面去的。

經典的數據分佈

經典的OLAP分佈方式Fluss裏面都是有的——分區和分桶。一般來説分區都是按時間來分的，也支持在SQL裏寫出TTL。

分桶支持三種算法，Hash（主鍵表默認），Sticky（日誌表默認），Random。

日誌表默認Sticky是因為它可以實現更大的批次寫入。相當於把一定時間的寫入的數據直接打到硬盤一個地方，那就是純純的順序寫。等這波過去了，負責元數據管理的組件會去看看，要不要換個桶讓你寫，這樣可以讓數據均勻點。

那這種數據分法方式適合對數據順序無要求的情況。有要求還是走主鍵分發的。

配合Flink的LakeHouse

LakeHouse是目前大數據裏比較新的架構。主要是結合湖倉的能力，儘量通過少的技術棧滿足業務需求——即存儲成本、可靠性、分析能力。

在文檔裏呢，我們可以看到Fluss配合Paimon+Flink，可以在原有的LakeHouse能力基礎再加上實時分析的能力。

這種能力在FlinkSQL中是非常靈活的。你可以聲明一張表，但表下面其實由Fluss和Paimon組成。然後你就可以享受到實時分析了。

如果某些情況下，你需要性能更好，但是接受延遲高點。那麼你可以直接用$lake來查Paimon的數據。帶上$lake以後，你就可以把它當普通Paimon表來查了，比如time travel之類的

小結

這麼下來，相信大家對於Fluss有個大致的瞭解了啊。

上期關於Fluss的問題，其實是身邊一個小夥伴提出來的，如果你有相同的疑問，説明你的確有思考啊。ChangeLog無需去重——是指Fluss自己做了upsert的能力，如果沒有這一層，那麼一般是做在下游的Flink作業裏的，就需要物化所有的數據到state裏。

如果這期的內容足夠受歡迎，那麼後面的文章我將會帶大家深挖Fluss裏的一些技術：

• 文檔裏提到的Apache Arrow優化了大批量寫入，是做到的？
• Fluss的LogStore其實很多設計借鑑了Kafka，它和Kafka的區別在哪裏？有沒有什麼trade off在裏面？
• 大幅降低成本，解決雙流join的deltaJoin是怎麼個事兒？
• 完全不用本地盤的Zero Disks是怎麼做的？業界裏有什麼成熟的實踐嗎？