データレイク Iceberg
現在人気のオープンソースデータレイク、Iceberg について。
最近ビッグデータのストレージ方式を整理していると、「データレイク」という言葉を避けて通れませんでした。ビジネスデータはもはやリレーショナルデータベースのテーブルだけではありません。トラッキングログ、JSON メッセージ、画像・音声・動画など、さまざまな形態のデータをどこかに格納する必要があります。従来のデータウェアハウス（DWH）はこうしたシナリオでますます苦しくなっており、データレイクを取り巻く一連のオープンソースプロジェクトがちょうどこのギャップを埋めています。この記事では、データレイクと DWH の違い、そしてその中でも代表的な Iceberg について簡単に整理し、自分の学習ノートとして残しておきます。
データレイクとデータウェアハウス
データレイクとは、構造化データと非構造化データを保存するための集中型データリポジトリであり、従来のリレーショナルデータ、半構造化データ、非構造化データなど、あらゆる種類のデータを保存できます。データレイクの主な特徴は高い柔軟性と拡張性を備えていることで、データの保存と処理を手軽に行えます。
データレイクの核心的な考え方のひとつが「先に保存し、後で管理する」（schema-on-read）です。データは生の形式のまま安価な分散ストレージ（HDFS やオブジェクトストレージなど）に書き込まれ、実際に分析する段階になって初めて構造を解析します。これは DWH の「先にモデリングしてから格納する」（schema-on-write）という考え方とは正反対で、あらゆるデータ形態に対応できる理由でもあります。
これに対し、従来のデータウェアハウスは主に構造化データの保存に使われ、通常はリレーショナルデータベースで保存・管理されます。データウェアハウスの主な特徴は高度な正規化と構造化であり、データの正確性と一貫性を保証できます。しかしデータウェアハウスの欠点は、柔軟性に欠けること、非構造化・半構造化データを保存・処理できないこと、そして拡張やアップグレードが難しいことにあります。
データレイクがデータウェアハウスに比べて優れている点は、主に以下のとおりです：
- ストレージに制限がない：データレイクは、従来の構造化データ、半構造化データ、非構造化データなど、あらゆる種類のデータを保存できます。これによりデータレイクはより柔軟になり、さまざまな種類・規模のデータストレージのニーズに適応します。
- 処理速度が速い：データレイクは通常、分散ストレージとコンピューティング技術を採用しており、高速なデータ処理と分析を実現できます。一方、従来のデータウェアハウスは何度もデータ変換と計算を行う必要があり、処理速度が遅くなりがちです。
- コストが低い：データレイクは通常、Hadoop や Spark などのオープンソース技術を採用しており、コストが比較的低く抑えられます。一方、従来のデータウェアハウスは商用データベースソフトウェアを採用する必要があり、コストが高くなります。
- より柔軟：データレイクはより高い柔軟性を持ち、データの保存と処理を手軽に行えます。一方、従来のデータウェアハウスは何度もデータ変換と計算を行う必要があり、データ処理のプロセスが複雑で困難になりがちです。
もちろん、柔軟性には代償があります。素のデータレイクはただのファイルディレクトリの山にすぎず、トランザクションもスキーマ制約も欠けているため、書き込み側と読み取り側が少し油断するとお互いを踏み荒らしてしまい、時間が経つと簡単に「データスワンプ（沼）」に変わってしまいます。テーブルフォーマット（table format）という抽象化レイヤーはまさにこの問題を解決するためのもので、ファイルの上に「テーブル」のセマンティクスを定義します。Iceberg はまさにこの種のプロジェクトです。
Apache Iceberg
Iceberg はオープンソースのデータテーブルフォーマットおよび処理ライブラリで、データレイクにおけるデータテーブルの管理と処理の問題を解決することを目的としています。Iceberg は Netflix によって開発され、現在では Apache ソフトウェア財団のトップレベルプロジェクトのひとつになっています。
Iceberg は、データテーブルのバージョン管理、メタデータ管理、パーティション管理、スナップショット管理など、従来のデータレイクにおけるいくつかの問題を解決しました。Iceberg は Hadoop、Spark、Presto、Flink など、複数のデータストレージ・処理システムをサポートしています。
ここで、その動作メカニズムについて少し掘り下げてみましょう。Iceberg 自体はデータを保存しません。データは相変わらず Parquet や ORC といった列指向ファイルであり、Iceberg が管理するのはデータの上にあるメタデータレイヤーです。メタデータは大きく 3 つのレベルに分かれます：
- スナップショット（snapshot）：ある時点でのテーブルの完全な状態です。書き込みがコミットされるたびに新しいスナップショットが生成され、古いスナップショットも引き続き読み取り可能です。
- マニフェストリストとマニフェストファイル（manifest list / manifest）：スナップショットにどのデータファイルが含まれるか、また各ファイルのパーティション範囲、行数、列レベルの統計などの情報を記録します。
- データファイル：実際の列指向ファイルです。メタデータはこれらを参照するだけで、変更はしません。
書き込み時には新しいメタデータが先にディスクに書き込まれ、最後にテーブルポインタへの 1 回のアトミックな置き換えによってコミットが完了します。これにより、ファイルシステムの上にデータベースに近い ACID セマンティクスがもたらされます。クエリ時にはエンジンがまずメタデータを読み、その中の統計情報を利用して無関係なファイルをスキップします。Hive のようにディレクトリ全体を List する必要はありません。オブジェクトストレージ上では、この点がパフォーマンスに大きく影響します。
Iceberg の主な特徴
Iceberg の主な特徴は以下のとおりです：
- データテーブルのバージョン管理：Iceberg はデータテーブルのバージョン管理をサポートしており、テーブルのバージョンを管理・制御できます。ユーザーは過去のバージョンへ簡単にロールバックしたり、異なるバージョンのデータテーブルをマージしたりできます。
- データテーブルのメタデータ管理：Iceberg はメタデータ管理メカニズムを提供しており、データテーブルの管理とクエリを手軽に行えます。ユーザーはメタデータを通じて、テーブルの構造、パーティション、データ統計などの情報を把握できます。
- データパーティション管理：Iceberg はハッシュパーティション、レンジパーティション、ハッシュ・レンジ混合パーティションなど、複数のパーティション方式をサポートしています。ユーザーは自分のニーズに応じて異なるパーティション方式を選択できます。
- データテーブルのスナップショット管理：Iceberg はデータテーブルのスナップショット管理をサポートしており、データのバックアップとリストアを簡単に行えます。
パーティションについてはもうひとつ細かい点があります。Iceberg のパーティションは「隠しパーティション（hidden partitioning）」です。パーティション値は列の値から変換関数（例えばタイムスタンプの日単位切り捨て）によって自動的に導出され、クエリ時には元の列でフィルタ条件を書くだけで、エンジンが自動的にパーティションプルーニングを活用してくれます。クエリを書く人はテーブルがどうパーティションされているかを知る必要がなく、Hive でパーティション列を手動管理する方式よりずっと親切です。パーティションルール自体も進化させることができ、ルールを変更しても過去のデータを書き直す必要はありません。
スキーマ進化（schema evolution）も同様に得意分野です。列の追加、削除、リネームはメタデータの変更だけで済み、列は名前や位置ではなく一意の ID で追跡されるため、古いテーブルフォーマットにあった「列名を変えただけでデータを読み間違えるかもしれない」という問題を回避しています。
ハマりどころと注意点
- 小さなファイルの問題は依然として存在します。ストリーミング書き込みの頻度が高いと、大量の小さなデータファイルとメタデータファイルが生成されるため、定期的にコンパクション（compaction）を実行する必要があります。さもないとクエリ性能は劣化し続けます。
- スナップショットは自動では掃除されません。コミットのたびにスナップショットが 1 つ残り、過去のスナップショットが参照するファイルは削除されないため、長期間スナップショットの期限切れ処理をしないと、ストレージがどんどん積み上がります。
- Catalog の選定は先にしっかり考えましょう。Iceberg のテーブルポインタは catalog による管理が必要で（Hive Metastore、JDBC などいずれも可）、異なるエンジンから同じテーブルにアクセスするには同じ catalog を共用しなければならず、移行はかなり面倒です。
- 同種のプロジェクトには Delta Lake と Apache Hudi もあります。3 つは位置づけが近いもののエコシステムの重点が異なるため、選定前には自分が主に使うコンピューティングエンジンと合わせて比較検討するのがよく、流行りに流される必要はありません。
まとめ
データレイクが解決するのは「どんなデータでも保存できる」という問題ですが、ストレージだけあって管理がなければ、レイクは簡単にスワンプ（沼）に変わってしまいます。Iceberg のようなテーブルフォーマットは、ファイルの上にトランザクション、バージョン、パーティション、スキーマ管理を補完し、データレイクに DWH に近いテーブルセマンティクスを持たせると同時に、オープンフォーマットと低コストという利点を保持しています。私にとって、これを理解する鍵はあの 3 層のメタデータ構造にありました。スナップショットとマニフェストファイルがどう組織されているかを理解できれば、ロールバック、タイムトラベル、パーティションプルーニングといった機能も自然と腑に落ちます。今後機会があれば、Flink / Spark 上で実際に Iceberg テーブルを読み書きするプロセスを別途記録するつもりです。
COMMENTS