有什么需求需要Paimon來解決？

在它剛剛誕生的時(shí)候，被叫做Built-In Dynamic Table Storage，動(dòng)態(tài)表是Flink實(shí)時(shí)處理的一個(gè)概念，簡(jiǎn)單的說就是不同時(shí)間點(diǎn)的表的內(nèi)容是不一樣的，也就是說這個(gè)表一直在變，并且你可以回放到過去任意時(shí)間的一個(gè)點(diǎn)，變化的內(nèi)容也能作為changeLog輸出給外部算子。

所以Paimon的定位是：流批統(tǒng)一的存儲(chǔ)。簡(jiǎn)單的說就是既可以作為Hive一樣支持批量查詢、插入，也能像從Kafka接入Change Log一樣接入實(shí)時(shí)數(shù)據(jù)的這么一個(gè)存儲(chǔ)引擎。

具體可以看Flink提案：https://cwiki.apache.org/confluence/display/FLINK/FLIP-188%3A+Introduce+Built-in+Dynamic+Table+Storage

稍微理解記錄一下
就是說這里的Kakfa既作為Source，還用作存儲(chǔ)中間結(jié)果。正常我們是只關(guān)心圖里最右面的聚合結(jié)果而不是中間結(jié)果的，這時(shí)候是沒有問題的。但是一旦我們有需求需要查（ad hoc）一下中間結(jié)果，發(fā)現(xiàn)查Kafka太不方便了。

Kakfa既作為Source，還用作存儲(chǔ)中間結(jié)果

所以有些同學(xué)就想了個(gè)辦法，就是中間結(jié)果同時(shí)存儲(chǔ)在Kafka和Hudi、ClickHouse，這樣想查（ad hoc）的話就去Olap引擎里面去查。但是這樣也有個(gè)問題，就是存儲(chǔ)大量數(shù)據(jù)的成本是很高的，所以就得對(duì)數(shù)據(jù)設(shè)置TTL把過期的數(shù)據(jù)刪掉或者把過期數(shù)據(jù)存儲(chǔ)到類似iceberg這種不那么費(fèi)資源的存儲(chǔ)中。

中間數(shù)據(jù)存兩份

主要使用的技術(shù)架構(gòu)。

為啥是LSM樹而不是別的數(shù)據(jù)結(jié)構(gòu)。

對(duì)于數(shù)據(jù)的性能方面，我們比較關(guān)注的主要是寫入和查詢。
存：磁盤和固態(tài)硬盤的順序存儲(chǔ)性能都大大強(qiáng)于隨機(jī)存儲(chǔ)，那么如果有一種架構(gòu)能夠盡可能利用順序存儲(chǔ)的性能，那豈不是可以實(shí)現(xiàn)高吞吐的數(shù)據(jù)寫入了么。
查：它內(nèi)部有很多文件，文件內(nèi)部的數(shù)據(jù)內(nèi)容是排序了的，所以每個(gè)文件都有一個(gè)邊界，文件和文件之間也根據(jù)每個(gè)文件的邊界再排序，而且每個(gè)文件之間都是不重合的，這樣的話，根據(jù)排序規(guī)則來查找一個(gè)或一堆連續(xù)的數(shù)據(jù)也會(huì)非常的快。
LSM樹就是這種數(shù)據(jù)結(jié)構(gòu)。

LSM Tree

LSM Tree的在大數(shù)據(jù)集的存儲(chǔ)引擎中使用還是非常廣泛的，比如HBase、LevelDB、RocksDB都使用到了這塊的技術(shù)。

總的來說，數(shù)據(jù)分別存儲(chǔ)在內(nèi)存和磁盤中，詳細(xì)分的話一共有三個(gè)地方用來存儲(chǔ)數(shù)據(jù)。
1、磁盤文件（File Store）。用于真正的持久化文件。我們先不用管里面具體的數(shù)據(jù)結(jié)構(gòu)，先了解一下這個(gè)文件的主要思想，就是“盡可能的利用磁盤的順序?qū)懶阅埽ㄖ徊宀桓騽h了重插），好找文件里面的內(nèi)容（文件內(nèi)容排序）”。雖然現(xiàn)實(shí)業(yè)務(wù)中的數(shù)據(jù)內(nèi)容經(jīng)常需要更新，但是我們先假設(shè)所有要寫入的數(shù)據(jù)都是源源不斷的、且一旦寫入之后也不需要更新、變更的，那么我們就可以不斷的向磁盤寫入文件，盡可能的利用到磁盤的順序?qū)懶阅軆?yōu)勢(shì)了。
2、內(nèi)存（MemTable）。我們都知道數(shù)據(jù)都是先存在內(nèi)存中，然后再寫入到磁盤的。在寫入的過程中先在內(nèi)存中緩存起來，當(dāng)內(nèi)存中積攢到一定數(shù)量的數(shù)據(jù)之后，再一股腦的寫到文件中去。為了方便數(shù)據(jù)的組織和查找，數(shù)據(jù)在寫入內(nèi)存之后是要按一定規(guī)則去排序的。這內(nèi)存的數(shù)據(jù)結(jié)構(gòu)就是memTable。
3、預(yù)寫日志（WAL）。上面的兩個(gè)文件存儲(chǔ)的位置仿佛已經(jīng)滿足了實(shí)際的需求，但是我們知道存儲(chǔ)在內(nèi)存中的文件是不穩(wěn)定的，一旦服務(wù)器宕機(jī)，內(nèi)存中的數(shù)據(jù)就丟失了。為了解決這個(gè)問題，引入了預(yù)寫日志（Write Ahead Log），就是當(dāng)數(shù)據(jù)寫入前，先將寫入的數(shù)據(jù)信息寫入到日志文件中去，這樣宕機(jī)后重啟也可以從這個(gè)日志中恢復(fù)內(nèi)存中內(nèi)容。另外，預(yù)寫日志在Paimon里面還被稱為L(zhǎng)og Store，當(dāng)批讀的時(shí)候，可以直接讀FileStore，而流讀的時(shí)候，就可以先讀FileStore來獲取已經(jīng)落盤好的數(shù)據(jù)，然后再從LogStore讀取增量的Change Log。
LSM Tree總體的思路大概就是這樣，當(dāng)然上面的描述都是沒有考慮數(shù)據(jù)更新和其他實(shí)際上很重要的場(chǎng)景，暫時(shí)先不介紹數(shù)據(jù)文件的合并（compact）了。

那如果有數(shù)據(jù)更新怎么辦。

這部分就是LSM Tree（Log Structured Merge Tree）中merge的內(nèi)容。LSM把上面數(shù)據(jù)存儲(chǔ)的位置分了很多層，具體多少層不定，Paimon默認(rèn)是4層。第一層就是內(nèi)存中的MemTable，而后的層都是File Store，里面存儲(chǔ)的文件格式是SstFile文件。當(dāng)MemTable中的數(shù)據(jù)達(dá)到一定量級(jí)時(shí)，會(huì)觸發(fā)Flush動(dòng)作寫入文件。這時(shí)候就可能會(huì)觸發(fā)compact，這塊后面再介紹。

快速問答：

Q：與時(shí)下流行的ClickHouse、Hudi對(duì)比，有什么優(yōu)勢(shì)。
Flink Table Store 與 Hudi、Lceberg 的差別在哪里？
A：本質(zhì)差別在于數(shù)據(jù)定位。Flink Table Store使用 LSM 結(jié)構(gòu)來更新和接受查詢，相當(dāng)于在寫過程中不斷地 Spill、 Compaction，其優(yōu)點(diǎn)在于編寫進(jìn)來的數(shù)據(jù)已經(jīng)排序好。并且通過 Append Spill 來更新，更新性能高。另外，LSM 結(jié)構(gòu)可以在存儲(chǔ)上有更大的擴(kuò)展性，比如類似 Clickhouse 那樣可以有各種場(chǎng)景的 MergeTree，加速查詢。

Q：怎么實(shí)現(xiàn)分布式存儲(chǔ)
A：LSM樹是存在于某個(gè)機(jī)器中的數(shù)據(jù)結(jié)構(gòu)，那么如果想實(shí)現(xiàn)分布式存儲(chǔ)，那么就通過引入桶來解決。