Iceberg 實(shí)踐 | Flink + Iceberg + 對(duì)象存儲(chǔ)，構(gòu)建數(shù)據(jù)湖方案

摘要：本文整理自 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. 未來(lái)規(guī)劃
   

3. 演示方案

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

   
   

Tips：點(diǎn)擊文末「閱讀原文」即可查看更多技術(shù)干貨～

 GitHub 地址 

歡迎大家給 Flink 點(diǎn)贊送 star~

一、數(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ù)文件開始，數(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í)候可以像樹一樣，從根開始，找到當(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è)文件的樹形結(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ì)有額外的開銷，而我們想實(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ǔ)開銷上更加有優(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ǔ)開銷

• 對(duì)于存儲(chǔ)系統(tǒng)來(lái)說(shuō)，為了適應(yīng)隨機(jī)的硬件故障，它一般會(huì)有副本機(jī)制來(lái)保護(hù)數(shù)據(jù)。




• 常見(jiàn)的如三副本，把數(shù)據(jù)存三份，然后分開保存到三個(gè) Node 上面，存儲(chǔ)開銷是三倍，但是它可以同時(shí)容忍兩個(gè)副本遇到故障，保證數(shù)據(jù)不會(huì)丟失。
• 另一種是 Erasure Coding，通常稱為 EC。以 10+2 舉例，它把數(shù)據(jù)切成 10 個(gè)數(shù)據(jù)塊，然后用算法算出兩個(gè)代碼塊，一共 12 個(gè)塊。接著分布到四個(gè)節(jié)點(diǎn)上，存儲(chǔ)開銷是 1.2 倍。它同樣可以容忍同時(shí)出現(xiàn)兩個(gè)塊故障，這種情況可以用剩余的 10 個(gè)塊算出所有的數(shù)據(jù)，這樣減少存儲(chǔ)開銷，同時(shí)達(dá)到故障容忍程度。

  
  

• HDFS 默認(rèn)使用三副本機(jī)制，新的 HDFS 版本上已經(jīng)支持 EC 的能力。經(jīng)過(guò)研究，它是基于文件做 EC，所以它對(duì)小文件有天然的劣勢(shì)。因?yàn)槿绻∥募拇笮⌒∮诜謮K要求的大小時(shí)，它的開銷就會(huì)比原定的開銷更大，因?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ù)開銷方面始終是恒定的，基于預(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è)分塊開始上傳。后面每一個(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è)，之后開始上傳。當(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 合并以后，它一開始拿不到鎖，要等 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。

---

另外～《Apache Flink-實(shí)時(shí)計(jì)算正當(dāng)時(shí)》電子書重磅發(fā)布，本書將助您輕松 Get Apache Flink 1.13 版本最新特征，同時(shí)還包含知名廠商多場(chǎng)景 Flink 實(shí)戰(zhàn)經(jīng)驗(yàn)，學(xué)用一體，干貨多多！快掃描下方二維碼獲取吧～

（本次為搶鮮版，正式版將于 7 月初上線）

更多 Flink 相關(guān)技術(shù)交流，可掃碼加入社區(qū)釘釘大群～

▼ 關(guān)注「Flink 中文社區(qū)」，獲取更多技術(shù)干貨 ▼

---

  戳我，立即報(bào)名！