本文整理自 Dell 科技集團(tuán)高級(jí)軟件研發(fā)經(jīng)理孫偉在 4 月 17 日 上海站 Flink Meetup 分享的《Iceberg 和對(duì)象存儲(chǔ)構(gòu)建數(shù)據(jù)湖方案》，文章內(nèi)容為：

1.數(shù)據(jù)湖和 Iceberg 簡(jiǎn)介

2.對(duì)象存儲(chǔ)支撐 Iceberg 數(shù)據(jù)湖

3.演示方案

4.存儲(chǔ)優(yōu)化的一些思考

一、數(shù)據(jù)湖和 Iceberg 簡(jiǎn)介

1. 數(shù)據(jù)湖生態(tài)

如上圖所示，對(duì)于一個(gè)成熟的數(shù)據(jù)湖生態(tài)而言：

首先我們認(rèn)為它底下應(yīng)具備海量存儲(chǔ)的能力，常見(jiàn)的有對(duì)象存儲(chǔ)，公有云存儲(chǔ)以及 HDFS；
在這之上，也需要支持豐富的數(shù)據(jù)類型，包括非結(jié)構(gòu)化的圖像視頻，半結(jié)構(gòu)化的 CSV、XML、Log，以及結(jié)構(gòu)化的數(shù)據(jù)庫(kù)表；
除此之外，需要高效統(tǒng)一的元數(shù)據(jù)管理，使得計(jì)算引擎可以方便地索引到各種類型數(shù)據(jù)來(lái)做分析。
最后，我們需要支持豐富的計(jì)算引擎，包括 Flink、Spark、Hive、Presto 等，從而方便對(duì)接企業(yè)中已有的一些應(yīng)用架構(gòu)。

2. 結(jié)構(gòu)化數(shù)據(jù)在數(shù)據(jù)湖上的應(yīng)用場(chǎng)景

上圖為一個(gè)典型的數(shù)據(jù)湖上的應(yīng)用場(chǎng)景。

數(shù)據(jù)源上可能會(huì)有各種數(shù)據(jù)，不同的數(shù)據(jù)源和不同格式。比如說(shuō)事物數(shù)據(jù)，日志，埋點(diǎn)信息，IOT 等。這些數(shù)據(jù)經(jīng)過(guò)一些流然后進(jìn)入計(jì)算平臺(tái)，這個(gè)時(shí)候它需要一個(gè)結(jié)構(gòu)化的方案，把數(shù)據(jù)組織放到一個(gè)存儲(chǔ)平臺(tái)上，然后供后端的數(shù)據(jù)應(yīng)用進(jìn)行實(shí)時(shí)或者定時(shí)的查詢。

這樣的數(shù)據(jù)庫(kù)方案它需要具備哪些特征呢？

首先，可以看到數(shù)據(jù)源的類型很多，因此需要支持比較豐富的數(shù)據(jù) Schema 的組織；
其次，它在注入的過(guò)程中要支撐實(shí)時(shí)的數(shù)據(jù)查詢，所以需要 ACID 的保證，確保不會(huì)讀到一些還沒(méi)寫完的中間狀態(tài)的臟數(shù)據(jù)；
最后，例如日志這些有可能臨時(shí)需要改個(gè)格式，或者加一列。類似這種情況，需要避免像傳統(tǒng)的數(shù)倉(cāng)一樣，可能要把所有的數(shù)據(jù)重新提出來(lái)寫一遍，重新注入到存儲(chǔ)；而是需要一個(gè)輕量級(jí)的解決方案來(lái)達(dá)成需求。
Iceberg 數(shù)據(jù)庫(kù)的定位就在于實(shí)現(xiàn)這樣的功能，于上對(duì)接計(jì)算平臺(tái)，于下對(duì)接存儲(chǔ)平臺(tái)。

3. 結(jié)構(gòu)化數(shù)據(jù)在數(shù)據(jù)湖上的典型解決方案

對(duì)于數(shù)據(jù)結(jié)構(gòu)化組織，典型的解決方式是用數(shù)據(jù)庫(kù)傳統(tǒng)的組織方式。

如上圖所示，上方有命名空間，數(shù)據(jù)庫(kù)表的隔離；中間有多個(gè)表，可以提供多種數(shù)據(jù) Schema 的保存；底下會(huì)放數(shù)據(jù)，表格需要提供 ACID 的特性，也支持局部 Schema 的演進(jìn)。

4. Iceberg 表數(shù)據(jù)組織架構(gòu)

快照 Metadata：表格 Schema、Partition、Partition spec、Manifest List 路徑、當(dāng)前快照等。
Manifest List：Manifest File 路徑及其 Partition，數(shù)據(jù)文件統(tǒng)計(jì)信息。
Manifest File：Data File 路徑及其每列數(shù)據(jù)上下邊界。
Data File：實(shí)際表內(nèi)容數(shù)據(jù)，以 Parque，ORC，Avro 等格式組織。
接下來(lái)具體看一下 Iceberg 是如何將數(shù)據(jù)組織起來(lái)的。如上圖所示：

可以看到右邊從數(shù)據(jù)文件開(kāi)始，數(shù)據(jù)文件存放表內(nèi)容數(shù)據(jù)，一般支持 Parquet、ORC、Avro 等格式；
往上是 Manifest File，它會(huì)記錄底下數(shù)據(jù)文件的路徑以及每列數(shù)據(jù)的上下邊界，方便過(guò)濾查詢文件；
再往上是 Manifest List，它來(lái)鏈接底下多個(gè) Manifest File，同時(shí)記錄 Manifest File 對(duì)應(yīng)的分區(qū)范圍信息，也是為了方便后續(xù)做過(guò)濾查詢；Manifest List 其實(shí)已經(jīng)表示了快照的信息，它包含當(dāng)下數(shù)據(jù)庫(kù)表所有的數(shù)據(jù)鏈接，也是 Iceberg 能夠支持 ACID 特性的關(guān)鍵保障。有了快照，讀數(shù)據(jù)的時(shí)候只能讀到快照所能引用到的數(shù)據(jù)，還在寫的數(shù)據(jù)不會(huì)被快照引用到，也就不會(huì)讀到臟數(shù)據(jù)。多個(gè)快照會(huì)共享以前的數(shù)據(jù)文件，通過(guò)共享這些 Manifest File 來(lái)共享之前的數(shù)據(jù)。
再往上是快照元數(shù)據(jù)，記錄了當(dāng)前或者歷史上表格 Scheme 的變化、分區(qū)的配置、所有快照 Manifest File 路徑、以及當(dāng)前快照是哪一個(gè)。
同時(shí)，Iceberg 提供命名空間以及表格的抽象，做完整的數(shù)據(jù)組織管理。

5. Iceberg 寫入流程

上方為 Iceberg 數(shù)據(jù)寫入的流程圖，這里用計(jì)算引擎 Flink 為例。

首先，Data Workers 會(huì)從元數(shù)據(jù)上讀出數(shù)據(jù)進(jìn)行解析，然后把一條記錄交給 Iceberg 存儲(chǔ)；
與常見(jiàn)的數(shù)據(jù)庫(kù)一樣，Iceberg 也會(huì)有預(yù)定義的分區(qū)，那些記錄會(huì)寫入到各個(gè)不同的分區(qū)，形成一些新的文件；
Flink 有個(gè) CheckPoint 機(jī)制，文件到達(dá)以后，F(xiàn)link 就會(huì)完成這一批文件的寫入，然后生成這一批文件的清單，接著交給 Commit Worker；
Commit Worker 會(huì)讀出當(dāng)前快照的信息，然后與這一次生成的文件列表進(jìn)行合并，生成一個(gè)新的 Manifest List 以及后續(xù)元數(shù)據(jù)的表文件的信息，之后進(jìn)行提交，成功以后就形成一個(gè)新的快照。

6. Iceberg 查詢流程

上方為 Iceberg 數(shù)據(jù)查詢流程。

首先是 Flink Table scan worker 做一個(gè) scan，scan 的時(shí)候可以像樹(shù)一樣，從根開(kāi)始，找到當(dāng)前的快照或者用戶指定的一個(gè)歷史快照，然后從快照中拿出當(dāng)前快照的 Manifest List 文件，根據(jù)當(dāng)時(shí)保存的一些信息，就可以過(guò)濾出滿足這次查詢條件的 Manifest File；
再往下經(jīng)過(guò) Manifest File 里記錄的信息，過(guò)濾出底下需要的 Data Files。這個(gè)文件拿出來(lái)以后，再交給 Recorder reader workers，它從文件中讀出滿足條件的 Recode，然后返回給上層調(diào)用。
這里可以看到一個(gè)特點(diǎn)，就是在整個(gè)數(shù)據(jù)的查詢過(guò)程中沒(méi)有用到任何 List，這是因?yàn)?Iceberg 完整地把它記錄好了，整個(gè)文件的樹(shù)形結(jié)構(gòu)不需要 List，都是直接單路徑指向的，因此查詢性能上沒(méi)有耗時(shí) List 操作，這點(diǎn)對(duì)于對(duì)象存儲(chǔ)比較友好，因?yàn)閷?duì)象存儲(chǔ)在 List 上面是一個(gè)比較耗資源的操作。

7. Iceberg Catalog 功能一覽

Iceberg 提供 Catalog 用良好的抽象來(lái)對(duì)接數(shù)據(jù)存儲(chǔ)和元數(shù)據(jù)管理。任何一個(gè)存儲(chǔ)，只要實(shí)現(xiàn) Iceberg 的 Catalog 抽象，就有機(jī)會(huì)跟 Iceberg 對(duì)接，用來(lái)組織接入上面的數(shù)據(jù)湖方案。

如上圖所示，Catalog 主要提供幾方面的抽象。

它可以對(duì) Iceberg 定義一系列角色文件；
它的 File IO 都是可以定制，包括讀寫和刪除；
它的命名空間和表的操作 (也可稱為元數(shù)據(jù)操作)，也可以定制；
包括表的讀取 / 掃描，表的提交，都可以用 Catalog 來(lái)定制。
這樣可以提供靈活的操作空間，方便對(duì)接各種底下的存儲(chǔ)。

二、對(duì)象存儲(chǔ)支撐 Iceberg 數(shù)據(jù)湖

1. 當(dāng)前 Iceberg Catalog 實(shí)現(xiàn)

目前社區(qū)里面已經(jīng)有的 Iceberg Catalog 實(shí)現(xiàn)可分為兩個(gè)部分，一是數(shù)據(jù) IO 部分，二是元數(shù)據(jù)管理部分。

如上圖所示，其實(shí)缺少面向私有對(duì)象存儲(chǔ)的 Catalog 實(shí)現(xiàn)，S3A 理論上可以接對(duì)象存儲(chǔ)，但它用的是文件系統(tǒng)語(yǔ)義，不是天然的對(duì)象存儲(chǔ)語(yǔ)義，模擬這些文件操作會(huì)有額外的開(kāi)銷，而我們想實(shí)現(xiàn)的是把數(shù)據(jù)和元數(shù)據(jù)管理全部都交給一個(gè)對(duì)象存儲(chǔ)，而不是分離的設(shè)計(jì)。

2. 對(duì)象存儲(chǔ)和 HDFS 的比較

這里存在一個(gè)問(wèn)題，在有 HDFS 的情況下，為什么還要用對(duì)象存儲(chǔ)？

如下所示，我們從各個(gè)角度將對(duì)象存儲(chǔ)和 HDFS 進(jìn)行對(duì)比。

總結(jié)下來(lái)，我們認(rèn)為：

對(duì)象存儲(chǔ)在集群擴(kuò)展性，小文件友好，多站點(diǎn)部署和低存儲(chǔ)開(kāi)銷上更加有優(yōu)勢(shì)；
HDFS 的好處就是提供追加上傳和原子性 rename，這兩個(gè)優(yōu)勢(shì)正是 Iceberg 需要的。
下面對(duì)兩個(gè)存儲(chǔ)各自的優(yōu)勢(shì)進(jìn)行簡(jiǎn)單闡述。

1）比較之：集群擴(kuò)展性

HDFS 架構(gòu)是用單個(gè) Name Node 保存所有元數(shù)據(jù)，這就決定了它單節(jié)點(diǎn)的能力有限，所以在元數(shù)據(jù)方面沒(méi)有橫向擴(kuò)展能力。
對(duì)象存儲(chǔ)一般采用哈希方式，把元數(shù)據(jù)分隔成各個(gè)塊，把這個(gè)塊交給不同 Node 上面的服務(wù)來(lái)進(jìn)行管理，天然地它元數(shù)據(jù)的上限會(huì)更高，甚至在極端情況下可以進(jìn)行 rehash，把這個(gè)塊切得更細(xì)，交給更多的 Node 來(lái)管理元數(shù)據(jù)，達(dá)到擴(kuò)展能力。
2）比較之：小文件友好

如今在大數(shù)據(jù)應(yīng)用中，小文件越來(lái)越常見(jiàn)，并逐漸成為一個(gè)痛點(diǎn)。

HDFS 基于架構(gòu)的限制，小文件存儲(chǔ)受限于 Name Node 內(nèi)存等資源，雖然 HDFS 提供了 Archive 的方法來(lái)合并小文件，減少對(duì) Name Node 的壓力，但這需要額外增加復(fù)雜度，不是原生的。
同樣，小文件的 TPS 也是受限于 Name Node 的處理能力，因?yàn)樗挥袉蝹€(gè) Name Node。對(duì)象存儲(chǔ)的元數(shù)據(jù)是分布式存儲(chǔ)和管理，流量可以很好地分布到各個(gè) Node 上，這樣單節(jié)點(diǎn)就可以存儲(chǔ)海量的小文件。
目前，很多對(duì)象存儲(chǔ)提供多介質(zhì)，分層加速，可以提升小文件的性能。

3）比較之：多站點(diǎn)部署

對(duì)象存儲(chǔ)支持多站點(diǎn)部署全局命名空間支持豐富的規(guī)則配置
對(duì)象存儲(chǔ)的多站點(diǎn)部署能力適用于兩地三中心多活的架構(gòu)，而 HDFS 沒(méi)有原生的多站點(diǎn)部署能力。雖然目前看到一些商業(yè)版本給 HDFS 增加了多站點(diǎn)負(fù)責(zé)數(shù)據(jù)的能力，但由于它的兩個(gè)系統(tǒng)可能是獨(dú)立的，因此并不能支撐真正的全局命名空間下多活的能力。

4）比較之：低存儲(chǔ)開(kāi)銷

對(duì)于存儲(chǔ)系統(tǒng)來(lái)說(shuō)，為了適應(yīng)隨機(jī)的硬件故障，它一般會(huì)有副本機(jī)制來(lái)保護(hù)數(shù)據(jù)。常見(jiàn)的如三副本，把數(shù)據(jù)存三份，然后分開(kāi)保存到三個(gè) Node 上面，存儲(chǔ)開(kāi)銷是三倍，但是它可以同時(shí)容忍兩個(gè)副本遇到故障，保證數(shù)據(jù)不會(huì)丟失。另一種是 Erasure Coding，通常稱為 EC。以 10+2 舉例，它把數(shù)據(jù)切成 10 個(gè)數(shù)據(jù)塊，然后用算法算出兩個(gè)代碼塊，一共 12 個(gè)塊。接著分布到四個(gè)節(jié)點(diǎn)上，存儲(chǔ)開(kāi)銷是 1.2 倍。它同樣可以容忍同時(shí)出現(xiàn)兩個(gè)塊故障，這種情況可以用剩余的 10 個(gè)塊算出所有的數(shù)據(jù)，這樣減少存儲(chǔ)開(kāi)銷，同時(shí)達(dá)到故障容忍程度。
HDFS 默認(rèn)使用三副本機(jī)制，新的 HDFS 版本上已經(jīng)支持 EC 的能力。經(jīng)過(guò)研究，它是基于文件做 EC，所以它對(duì)小文件有天然的劣勢(shì)。因?yàn)槿绻∥募拇笮⌒∮诜謮K要求的大小時(shí)，它的開(kāi)銷就會(huì)比原定的開(kāi)銷更大，因?yàn)閮蓚€(gè)代碼塊這邊是不能省的。在極端情況下，如果它的大小等同于單個(gè)代碼塊的大小，它就已經(jīng)等同于三副本了。
同時(shí)，HDFS 一旦 EC，就不能再支持 append、hflush、hsync 等操作，這會(huì)極大地影響 EC 能夠使用的場(chǎng)景。對(duì)象存儲(chǔ)原生支持 EC，對(duì)于小文件的話，它內(nèi)部會(huì)把小文件合并成一個(gè)大的塊來(lái)做 EC，這樣確保數(shù)據(jù)開(kāi)銷方面始終是恒定的，基于預(yù)先配置的策略。

3. 對(duì)象存儲(chǔ)的挑戰(zhàn)：數(shù)據(jù)的追加上傳

在 S3 協(xié)議中，對(duì)象在上傳時(shí)需要提供大小。

以 S3 標(biāo)準(zhǔn)為例，對(duì)象存儲(chǔ)跟 Iceberg 對(duì)接時(shí)，S3 標(biāo)準(zhǔn)對(duì)象存儲(chǔ)不支持?jǐn)?shù)據(jù)追加上傳的接口，協(xié)議要求上傳文件時(shí)提供文件大小。所以在這種情況下，對(duì)于這種流式的 File IO 傳入，其實(shí)不太友好。

1）解決方案一：S3 Catalog 數(shù)據(jù)追加上傳 - 小文件緩存本地/內(nèi)存

對(duì)于一些小文件，流式傳入的時(shí)候就寫入到本地緩存 / 內(nèi)存，等它完全寫完后，再把它上傳到對(duì)象存儲(chǔ)里。

2）解決方法二：S3 Catalog 數(shù)據(jù)追加上傳 - MPU 分段上傳大文件

對(duì)于大文件，會(huì)用到 S3 標(biāo)準(zhǔn)定義的 MPU 分段上傳。

它一般分為幾個(gè)步驟：

第一步先創(chuàng)建初始化的 MPU，拿到一個(gè) Upload ID，然后給每一個(gè)分段賦予一個(gè) Upload ID 以及一個(gè)編號(hào)，這些分塊就可以并行上傳；
在上傳完成以后，還需要一步 Complete 操作，這樣相當(dāng)于通知系統(tǒng)，它會(huì)把基于同一個(gè) Upload ID 以及所有的編號(hào)，從小到大排起來(lái)，組成一個(gè)大文件；
把機(jī)制運(yùn)用到數(shù)據(jù)追加上傳場(chǎng)景，常規(guī)實(shí)現(xiàn)就是寫入一個(gè)文件，把文件緩存到本地，當(dāng)達(dá)到分塊要求大小時(shí)，就可以把它進(jìn)行初始化 MPU，把它的一個(gè)分塊開(kāi)始上傳。后面每一個(gè)分塊也是一樣的操作，直到最后一個(gè)分塊上傳完，最后再調(diào)用一個(gè)完成操作來(lái)完成上傳。
MPU 有優(yōu)點(diǎn)也有缺點(diǎn)：

缺點(diǎn)是 MPU 的分片數(shù)量有上限，S3 標(biāo)準(zhǔn)里可能只有 1 萬(wàn)個(gè)分片。想支持大文件的話，這個(gè)分塊就不能太小，所以對(duì)于小于分塊的文件，依然是要利用前面一種方法進(jìn)行緩存上傳；
MPU 的優(yōu)點(diǎn)在于并行上傳的能力。假設(shè)做一個(gè)異步的上傳，文件在緩存達(dá)到以后，不用等上一個(gè)分塊上傳成功，就可以繼續(xù)緩存下一個(gè)，之后開(kāi)始上傳。當(dāng)前面注入的速度足夠快時(shí)，后端的異步提交就變成了并行操作。利用這個(gè)機(jī)制，它可以提供比單條流上傳速度更快的上傳能力。

4. 對(duì)象存儲(chǔ)的挑戰(zhàn)：原子提交

下一個(gè)問(wèn)題是對(duì)象存儲(chǔ)的原子提交問(wèn)題。

前面提到在數(shù)據(jù)注入的過(guò)程中，最后的提交其實(shí)分為幾步，是一個(gè)線性事務(wù)。首先它要讀到當(dāng)前的快照版本，然后把這一次的文件清單合并，接著提交自己新的版本。這個(gè)操作類似于我們編程里常見(jiàn)的 “i=i+1”，它不是一個(gè)原子操作，對(duì)象存儲(chǔ)的標(biāo)準(zhǔn)里也沒(méi)有提供這個(gè)能力。

上圖是并發(fā)提交元信息的場(chǎng)景。

這里 Commit Worker 1 拿到了 v006 版本，然后合并自己的文件，提交 v007 成功。
此時(shí)還有另一個(gè) Commit Worker 2，它也拿到了 v006，然后合并出來(lái)，且也要提供 v007。此時(shí)我們需要一個(gè)機(jī)制告訴它 v007 已經(jīng)沖突，不能上傳，然后讓它自己去 Retry。Retry 以后取出新的 v007 合并，然后提交給 v008。
這是一個(gè)典型的沖突場(chǎng)景，這里需要一套機(jī)制，因?yàn)槿绻荒軝z測(cè)到自己是一個(gè)沖突的情況的話，再提交 v007 會(huì)把上面 v007 覆蓋，會(huì)導(dǎo)致上一次提交的所有數(shù)據(jù)都丟失。

如上圖所示，我們可以使用一個(gè)分布式鎖的機(jī)制來(lái)解決上述問(wèn)題。

首先，Commit Worker 1 拿到 v006，然后合并文件，在提交之前先要獲取這一把鎖，拿到鎖以后判斷當(dāng)前快照版本。如果是 v006，則 v007 能提交成功，提交成功以后再解鎖。
同樣，Commit Worker 2 拿到 v006 合并以后，它一開(kāi)始拿不到鎖，要等 Commit Worker 1 釋放掉這個(gè)鎖以后才能拿到。等拿到鎖再去檢查的時(shí)候，會(huì)發(fā)現(xiàn)當(dāng)前版本已經(jīng)是 v007，與自己的 v007 有沖突，因此這個(gè)操作一定會(huì)失敗，然后它就會(huì)進(jìn)行 Retry。
這是通過(guò)鎖來(lái)解決并發(fā)提交的問(wèn)題。

5. Dell EMC ECS 的數(shù)據(jù)追加上傳

基于 S3 標(biāo)準(zhǔn)的對(duì)象存儲(chǔ)和 Iceberg 問(wèn)題的解決方案存在一些問(wèn)題，例如性能損失，或者需要額外部署鎖服務(wù)等。

Dell EMC ECS 也是個(gè)對(duì)象存儲(chǔ)，基于這個(gè)問(wèn)題有不一樣的解答，它基于 S3 的標(biāo)準(zhǔn)協(xié)議有一些擴(kuò)展，可以支持?jǐn)?shù)據(jù)的追加上傳。

它的追加上傳與 MPU 不同的地方在于，它沒(méi)有分塊大小的限制。分塊可以設(shè)置得比較小一點(diǎn)，上傳后內(nèi)部就會(huì)串聯(lián)起來(lái)，依然是一個(gè)有效的文件。

追加上傳和 MPU 這兩者可以在一定程度上適應(yīng)不同的場(chǎng)景。

MPU 有加速上傳能力，追加上傳在速度在不是很快的情況下，性能也是足夠用，而且它沒(méi)有 MPU 的初始化和合并的操作，所以兩者在性能上能夠適應(yīng)不同場(chǎng)景進(jìn)行使用。

6. Dell EMC ECS 在并發(fā)提交下的解決方案

ECS 對(duì)象存儲(chǔ)還提供了一個(gè) If-Match 的語(yǔ)義，在微軟的云存儲(chǔ)以及谷歌的云存儲(chǔ)上都有這樣一個(gè)接口能力。

If-Match 就是說(shuō)在 Commit Worker 1 提交拿到 v006 的時(shí)候，同時(shí)拿到了文件的 eTag。提交的時(shí)候會(huì)帶上 eTag，系統(tǒng)需要判斷要覆蓋文件的 eTag 跟當(dāng)前這個(gè)文件真實(shí) eTag 是否相同，如果相同就允許這次覆蓋操作，那么 v007 就能提交成功；
另一種情況，是 Commit Worker 2 也拿到了 v006 的 eTag，然后上傳的時(shí)候發(fā)現(xiàn)拿到 eTag 跟當(dāng)前系統(tǒng)里文件不同，則會(huì)返回失敗，然后觸發(fā) Retry。
這個(gè)實(shí)現(xiàn)是和鎖機(jī)制一樣的效果，不需要外部再重新部署鎖服務(wù)來(lái)保證原子提交的問(wèn)題。

7. S3 Catalog - 統(tǒng)一存儲(chǔ)的數(shù)據(jù)

回顧一下，上方我們解決了文件 IO 中上傳數(shù)據(jù) IO 的問(wèn)題，和解決了元數(shù)據(jù)表格的原子提交問(wèn)題。

解決這些問(wèn)題以后，就可以把數(shù)據(jù)以及元數(shù)據(jù)的管理全部都交到對(duì)象存儲(chǔ)，不再需要額外部署元數(shù)據(jù)服務(wù)，做到真正統(tǒng)一數(shù)據(jù)存儲(chǔ)的概念。

三、演示方案

如上所示，演示方案用到了 Pravega，可以簡(jiǎn)單理解為 Kafka 的一個(gè)替代，但是對(duì)它進(jìn)行了性能優(yōu)化。

在這個(gè)例子中，我們會(huì)把數(shù)據(jù)注入 Pravega 的流里，然后 Flink 會(huì)從 Pravega 中讀出數(shù)據(jù)進(jìn)行解析，然后存入 Iceberg 組織。Iceberg 利用 ECS Catalog，直接對(duì)接對(duì)象存儲(chǔ)，這里面沒(méi)有任何其他部署，最后用 Flink 讀出這個(gè)數(shù)據(jù)。

四、存儲(chǔ)優(yōu)化的一些思考

上圖為當(dāng)前 Iceberg 支持的數(shù)據(jù)組織結(jié)構(gòu)，可以看到它直接 Parquet 文件存在存儲(chǔ)里面。

我們的想法是如果這個(gè)湖跟元數(shù)據(jù)的湖其實(shí)是一個(gè)湖，有沒(méi)有可能生成的 Parquet 文件跟源文件存在很大的數(shù)據(jù)冗余度，是否可以減少冗余信息的存儲(chǔ)。

比如最極端的情況，源文件的一個(gè)信息記錄在 Iceberg 中，就不存這個(gè) Parquet 數(shù)據(jù)文件。當(dāng)要查詢的時(shí)候，通過(guò)定制 File IO，讓它根據(jù)原文件在內(nèi)存中實(shí)時(shí)生成一個(gè)類似于 Parquet 的格式，提交給上層應(yīng)用查詢，就可以達(dá)到一樣的效果。

但是這種方式，局限于對(duì)存儲(chǔ)的成本有很高的要求，但是對(duì)查詢的性能要求卻不高的情況。能夠?qū)崿F(xiàn)這個(gè)也要基于 Iceberg 好的抽象，因?yàn)樗奈募獢?shù)據(jù)和 File IO 都是抽象出來(lái)的，可以把源文件拆進(jìn)去，讓它以為這是一個(gè) Parquet 文件。

進(jìn)一步思考，能否優(yōu)化查詢性能，同時(shí)節(jié)省存儲(chǔ)空間。

比如預(yù)計(jì)算一下，把源文件某些常用的列拿出來(lái)，然后統(tǒng)計(jì)信息到 Iceberg 中，在讀的時(shí)候利用源文件和云計(jì)算的文件，可以很快查詢到信息，同時(shí)又節(jié)省了不常用的數(shù)據(jù)列存儲(chǔ)空間。

這是比較初步的想法，如果能夠?qū)崿F(xiàn)，則用 Iceberg 不僅可以索引結(jié)構(gòu)化的 Parquet 文件格式，甚至可以索引一些半結(jié)構(gòu)化、結(jié)構(gòu)化的數(shù)據(jù)，通過(guò)臨時(shí)的計(jì)算來(lái)解決上層的查詢?nèi)蝿?wù)，變成一個(gè)更完整的 Data Catalog。

原文鏈接：http://click.aliyun.com/m/1000283887/