Flink 和 Iceberg 如何解決數據入湖面臨的挑戰

簡介：4.17 上海站 Meetup 胡爭老師分享內容：數據入湖的挑戰有哪些，以及如何用 Flink + Iceberg 解決此類問題。

GitHub 地址
https://github.com/apache/flink
歡迎你們給 Flink 點贊送 star~

1、數據入湖的核心挑戰

數據實時入湖能夠分紅三個部分，分別是數據源、數據管道和數據湖（數倉），本文的內容將圍繞這三部分展開。

1. Case #1：程序 BUG 致使數據傳輸中斷

• 首先，當數據源經過數據管道傳到數據湖（數倉）時，頗有可能會遇到做業有 BUG 的狀況，致使數據傳到一半，對業務形成影響；
• 第二個問題是當遇到這種狀況的時候，如何重起做業，並保證數據不重複也不缺失，完整地同步到數據湖（數倉）中。

2. Case #2：數據變動太痛苦

• 數據變動

  當發生數據變動的狀況時，會給整條鏈路帶來較大的壓力和挑戰。如下圖爲例，原先是一個表定義了兩個字段，分別是 ID 和 NAME。此時，業務方面的同窗表示須要將地址加上，以方便更好地挖掘用戶的價值。

  首先，咱們須要把 Source 表加上一個列 Address，而後再把到 Kafka 中間的鏈路加上鍊，而後修改做業並重啓。接着整條鏈路得一路改過去，添加新列，修改做業並重啓，最後把數據湖（數倉）裏的全部數據所有更新，從而實現新增列。這個過程的操做不只耗時，並且會引入一個問題，就是如何保證數據的隔離性，在變動的過程當中不會對分析做業的讀取形成影響。

• 分區變動

  以下圖所示，數倉裏面的表是以 「月」 爲單位進行分區，如今但願改爲以 「天」 爲單位作分區，這可能就須要將不少系統的數據所有更新一遍，而後再用新的策略進行分區，這個過程十分耗時。

3. Case #3：愈來愈慢的近實時報表？

當業務須要更加近實時的報表時，須要將數據的導入週期，從 「天」 改到 「小時」，甚至 「分鐘」 級別，這可能會帶來一系列問題。

如上圖所示，首先帶來的第一個問題是：文件數以肉眼可見的速度增加，這將對外面的系統形成愈來愈大的壓力。壓力主要體如今兩個方面：

• 第一個壓力是，啓動分析做業愈來愈慢，Hive Metastore 面臨擴展難題，以下圖所示。

  • 隨着小文件愈來愈多，使用中心化的 Metastore 的瓶頸會愈來愈嚴重，這會形成啓動分析做業愈來愈慢，由於啓動做業的時候，會把全部的小文件原數據都掃一遍。
  • 第二是由於 Metastore 是中心化的系統，很容易碰到 Metastore 擴展難題。例如 Hive，可能就要想辦法擴後面的 MySQL，形成較大的維護成本和開銷。

• 第二個壓力是掃描分析做業愈來愈慢。

  隨着小文件增長，在分析做業起來以後，會發現掃描的過程愈來愈慢。本質是由於小文件大量增長，致使掃描做業在不少個 Datanode 之間頻繁切換。

4. Case #4：實時地分析 CDC 數據很困難

你們調研 Hadoop 裏各類各樣的系統，發現整個鏈路須要跑得又快又好又穩定，而且有好的併發，這並不容易。

• 首先從源端來看，好比要將 MySQL 的數據同步到數據湖進行分析，可能會面臨一個問題，就是 MySQL 裏面有存量數據，後面若是不斷產生增量數據，如何完美地同步全量和增量數據到數據湖中，保證數據很少也很多。

• 此外，假設解決了源頭的全量跟增量切換，若是在同步過程當中遇到異常，如上游的 Schema 變動致使做業中斷，如何保證 CDC 數據一行很多地同步到下游。

• 整條鏈路的搭建，須要涉及源頭全量跟同步的切換，包括中間數據流的串通，還有寫入到數據湖（數倉）的流程，搭建整個鏈路須要寫不少代碼，開發門檻較高。

• 最後一個問題，也是關鍵的一個問題，就是咱們發如今開源的生態和系統中，很難找到高效、高併發分析 CDC 這種變動性質的數據。

5. 數據入湖面臨的核心挑戰

• 數據同步任務中斷

  • 沒法有效隔離寫入對分析的影響；
  • 同步任務不保證 exactly-once 語義。

• 端到端數據變動

  • DDL 致使全鏈路更新升級複雜；
  • 修改湖/倉中存量數據困難。

• 愈來愈慢的近實時報表

  • 頻繁寫入產生大量小文件；
  • Metadata 系統壓力大, 啓動做業慢；
  • 大量小文件致使數據掃描慢。

• 沒法近實時分析 CDC 數據

  • 難以完成全量到增量同步的切換；
  • 涉及端到端的代碼開發，門檻高；
  • 開源界缺少高效的存儲系統。

2、Apache Iceberg 介紹

1. Netflix：Hive 上雲痛點總結

Netflix 作 Iceberg 最關鍵的緣由是想解決 Hive 上雲的痛點，痛點主要分爲如下三個方面：

1.1 痛點一：數據變動和回溯困難

1. 不提供 ACID 語義。在發生數據改動時，很難隔離對分析任務的影響。典型操做如：INSERT OVERWRITE；修改數據分區；修改 Schema；
2. 沒法處理多個數據改動，形成衝突問題；
3. 沒法有效回溯歷史版本。

1.2 痛點二：替換 HDFS 爲 S3 困難

1. 數據訪問接口直接依賴 HDFS API；
2. 依賴 RENAME 接口的原子性，這在相似 S3 這樣的對象存儲上很難實現一樣的語義；
3. 大量依賴文件目錄的 list 接口，這在對象存儲系統上很低效。

1.3 痛點三：太多細節問題

1. Schema 變動時，不一樣文件格式行爲不一致。不一樣 FileFormat 甚至連數據類型的支持都不一致；
2. Metastore 僅維護 partition 級別的統計信息，形成不 task plan 開銷； Hive Metastore 難以擴展；
3. 非 partition 字段不能作 partition prune。

2. Apache Iceberg 核心特性

• 通用化標準設計

  • 完美解耦計算引擎
  • Schema 標準化
  • 開放的數據格式
  • 支持 Java 和 Python

• 完善的 Table 語義

  • Schema 定義與變動
  • 靈活的 Partition 策略
  • ACID 語義
  • Snapshot 語義

• 豐富的數據管理

  • 存儲的流批統一
  • 可擴展的 META 設計支持
  • 批更新和 CDC
  • 支持文件加密

• 性價比

  • 計算下推設計
  • 低成本的元數據管理
  • 向量化計算
  • 輕量級索引

3. Apache Iceberg File Layout

上方爲一個標準的 Iceberg 的 TableFormat 結構，核心分爲兩部分，一部分是 Data，一部分是 Metadata，不管哪部分都是維護在 S3 或者是 HDFS 之上的。

4. Apache Iceberg Snapshot View

上圖爲 Iceberg 的寫入跟讀取的大體流程。

能夠看到這裏面分三層：

• 最上面黃色的是快照；
• 中間藍色的是 Manifest；
• 最下面是文件。

每次寫入都會產生一批文件，一個或多個 Manifest，還有快照。

好比第一次造成了快照 Snap-0，第二次造成快照 Snap-1，以此類推。可是在維護原數據的時候，都是增量一步一步作追加維護的。

這樣的話能夠幫助用戶在一個統一的存儲上作批量的數據分析，也能夠基於存儲之上去作快照之間的增量分析，這也是 Iceberg 在流跟批的讀寫上可以作到一些支持的緣由。

5. 選擇 Apache Iceberg 的公司

上圖爲目前在使用 Apache Iceberg 的部分公司，國內的例子你們都較爲熟悉，這裏大體介紹一下國外公司的使用狀況。

• NetFlix 如今是有數百PB的數據規模放到 Apache Iceberg 之上，Flink 天天的數據增量是上百T的數據規模。
• Adobe 天天的數據新增量規模爲數T，數據總規模在幾十PB左右。
• AWS 把 Iceberg 做爲數據湖的底座。
• Cloudera 基於 Iceberg 構建本身整個公有云平臺，像 Hadoop 這種 HDFS 私有化部署的趨勢在減弱，上雲的趨勢逐步上升，Iceberg 在 Cloudera 數據架構上雲的階段中起到關鍵做用。

• 蘋果有兩個團隊在使用：

  • 一是整個 iCloud 數據平臺基於 Iceberg 構建；
  • 二是人工智能語音服務 Siri，也是基於 Flink 跟 Iceberg 來構建整個數據庫的生態。

3、Flink 和 Iceberg 如何解決問題

回到最關鍵的內容，下面闡述 Flink 和 Iceberg 如何解決第一部分所遇到的一系列問題。

1. Case #1：程序 BUG 致使數據傳輸中斷

首先，同步鏈路用 Flink，能夠保證 exactly once 的語義，看成業出現故障時，可以作嚴格的恢復，保證數據的一致性。

第二個是 Iceberg，它提供嚴謹的 ACID 語義，能夠幫用戶輕鬆隔離寫入對分析任務的不利影響。

2. Case #2：數據變動太痛苦

如上所示，當發生數據變動時，用 Flink 和 Iceberg 能夠解決這個問題。

Flink 能夠捕捉到上游 Schema 變動的事件，而後把這個事件同步到下游，同步以後下游的 Flink 直接把數據往下轉發，轉發以後到存儲，Iceberg 能夠瞬間把 Schema 給變動掉。

當作 Schema 這種 DDL 的時候，Iceberg 直接維護了多個版本的 Schema，而後老的數據源徹底不動，新的數據寫新的 Schema，實現一鍵 Schema 隔離。

另一個例子是分區變動的問題，Iceberg 作法如上圖所示。

以前按 「月」 作分區（上方黃色數據塊），若是但願改爲按 「天」 作分區，能夠直接一鍵把 Partition 變動，原來的數據不變，新的數據所有按 「天」 進行分區，語義作到 ACID 隔離。

3. Case #3：愈來愈慢的近實時報表？

第三個問題是小文件對 Metastore 形成的壓力。

首先對於 Metastore 而言，Iceberg 是把原數據統一存到文件系統裏，而後用 metadata 的方式維護。整個過程實際上是去掉了中心化的 Metastore，只依賴文件系統擴展，因此擴展性較好。

另外一個問題是小文件愈來愈多，致使數據掃描會愈來愈慢。在這個問題上，Flink 和 Iceberg 提供了一系列解決方案：

• 第一個方案是在寫入的時候優化小文件的問題，按照 Bucket 來 Shuffle 方式寫入，由於 Shuffle 這個小文件，寫入的文件就天然而然的小。
• 第二個方案是批做業按期合併小文件。
• 第三個方案相對智能，就是自動增量地合併小文件。

4. Case #4：實時地分析CDC數據很困難

• 首先是是全量跟增量數據同步的問題，社區其實已有 Flink CDC Connected 方案，就是說 Connected 可以自動作全量跟增量的無縫銜接。

• 第二個問題是在同步過程當中，如何保證 Binlog 一行很多地同步到湖中， 即便中間碰到異常。

  對於這個問題，Flink 在 Engine 層面可以很好地識別不一樣類型的事件，而後藉助 Flink 的 exactly once 的語義，即便碰到故障，它也能自動作恢復跟處理。

• 第三個問題是搭建整條鏈路須要作很多代碼開發，門檻過高。

  在用了 Flink 和 Data Lake 方案後，只須要寫一個 source 表和 sink 表，而後一條 INSERT INTO，整個鏈路就能夠打通，無需寫任何業務代碼。

• 最後是存儲層面如何支持近實時的 CDC 數據分析。

4、社區 Roadmap

上圖爲 Iceberg 的 Roadmap，能夠看到 Iceberg 在 2019 年只發了一個版本， 卻在 2020 年直接發了三個版本，並在 0.9.0 版本就成爲頂級項目。

上圖爲 Flink 與 Iceberg 的 Roadmap，能夠分爲 4 個階段。

• 第一個階段是 Flink 與 Iceberg 創建鏈接。
• 第二階段是 Iceberg 替換 Hive 場景。在這個場景下，有不少公司已經開始上線，落地本身的場景。
• 第三個階段是經過 Flink 與 Iceberg 解決更復雜的技術問題。
• 第四個階段是把這一套從單純的技術方案，到面向更完善的產品方案角度去作。

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。