Lakehouse

前回のポストでは merge on read で Apache Iceberg の table を near real time で更新するということを行った。 このポストではそのメンテナンスについて触れて、かつそれを実行してみる。 merge on read の課題 merge on read で table を更新する場合、copy on write の場合と違い table 全体を洗い替えする必要はなく差分のみを追記することになる。 したがって更新にかかる時間は copy on write よりも短くなる。 一方で merge on read の名のとおり読み出し時に積み重なった差分とベースを merge して最新の snapshot とするため、読み出しの速度は copy on write より遅くなる。 長時間更新され差分がたくさん存在しているとなおさら遅い。 なので 更新頻度が低く、参照頻度が高いユースケース -> copy on write 更新頻度が高く、参照頻度が低いユースケース -> merge on write という使い分けがよいとされている。 前回ポストの例では一晩更新を続けた後の merge on read の table に対して簡単な select 文を実行したところ、6分程度かかってしまった。 レコード数はたかだか128件程度であることを考えるとかなり遅いと言える。 このままでは使い物にならない。 ...

Apache Iceberg の table を near real time に、つまり高頻度で更新するということをやってみた。 Apache Iceberg とは Apache Iceberg (以下 Iceberg) は分散ファイルシステムやクラウドストレージ上の table format であり、Apache Hudi や Delta Lake と並んで data lake や lakehouse architecture で用いられる。 特徴的なのは table とデータ実体 (Parquet, Avro など) の間に metadata file, manifest list, manifest file の抽象的なレイヤーがあり、ファイル単位で table の状態を track できること。 これにより強い isolation level、パフォーマンス、schema evolution など様々な機能・性能を実現できるようになっている。 Apache Iceberg Iceberg Table Spec 詳しくは公式ドキュメントを参照のこと。 最近では SmartNews 社が Iceberg で data lake を構築したことを記事にしていた。 Flink-based Iceberg Real-Time Data Lake in SmartNews (Part I) | by SmartNews | SmartNews, Inc | Apr, 2023 | Medium ベンダー提供の DWH 中心ではなく Lakehouse Architecture を目指すのであれば最有力の table format の1つだと言えそう。 ...