Parquet、Icebergとデータレイクハウスを理解する
(davidgomes.com)- データ保存技術はひとまとまりではなく、ファイルフォーマット、メモリフォーマット、テーブルメタデータ層、レイクハウスアーキテクチャのように異なるレイヤーに分かれている
- Avro・Parquet・ORC・Arrowはデータのバイナリレイアウトを定めるフォーマットであり、Parquetはカラム指向の圧縮と分析処理に強く、Avroは行単位の処理により適している
- IcebergとDelta Lakeはファイルフォーマットではなく、Parquetのようなファイルの上で大規模テーブル管理を可能にする上位のメタデータ層である
- データレイクハウスは、S3のようなストレージ上の生ファイルの上に、SQLクエリ、バッチ処理、ガバナンスといったウェアハウス機能を載せる方式である
- SnowflakeやBigQueryのようなウェアハウスもIcebergのようなオープンフォーマットをサポートし始めており、データウェアハウスとレイクハウスの境界は次第に曖昧になっている
ファイルフォーマットとメモリフォーマットの違い
- データ保存・アクセスを効率化するオープンソースフォーマットは、保存方式と使われる場所がそれぞれ異なる
- Apache Avro: バイナリ、行指向ストレージ(rowstore)、ファイル
- Apache Parquet: バイナリ、カラム指向ストレージ(columnstore)、ファイル
- Apache ORC: バイナリ、カラム指向ストレージ、ファイル
- Apache Arrow: バイナリ、カラム指向ストレージ、メモリ
- Protocol Buffers: 言語中立なデータ構造定義言語であり、実装によって行指向ストレージにもカラム指向ストレージにもなりうる
- CSV: テキストベースで、構造が非常に単純
- Apache Arrowのデータフレームをディスクファイルとして保存する際には主にFeatherが使われ、Parquetなど別のフォーマットに変換することもできる
- Snowflake、Redshift、Athena、Hiveのようなシステムはオープンフォーマットとクローズドな保存フォーマットの読み書きをサポートしているが、オープンフォーマットへの対応範囲は製品ごとに異なることがある
フォーマットが実際に定めるもの
- ファイルフォーマットは、データが実際のバイナリ配置でどのように並ぶかを定める仕様である
- Parquetは圧縮に強く、Avroは行指向ストレージ方式のため特定の行ブロックを読むのにより適している
- ParquetとAvroはいずれもスキーマ進化をサポートしており、既存データをすべて書き直さなくても新しいデータのスキーマを変更できる
- 両フォーマットともファイル分割をサポートしており、これはデータの並列処理に重要である
- Apache Parquetリポジトリには、実際のファイルフォーマット仕様とJavaの参照実装が含まれている
- Parquetは複数の言語やツールで読み書きでき、PandasでもDataFrameを
to_parquetでローカルのParquetファイルに保存できる - Presto/Trino、Spark、DuckDB、Hive、Dremio、Impala、AWS Athena、Apache Drillは、Parquetファイルを扱えるエンジンの例である
ファイルフォーマットだけでは不十分な大規模データ管理
- 個別のファイルフォーマットは1つのファイルレイアウトしか定義しないため、変化し続ける大規模データセットを管理するには不十分である
- 多数のテーブル保存、個々のテーブルのスキーマ進化、時点参照、効率的なパーティショニング、外部ツールによるスキーマ読み取り、コストベースのクエリ最適化のための統計保存には上位レイヤーが必要である
- このレイヤーには、テーブルフォーマットとスキーマレジストリまたはメタストアが含まれる
- Confluent Schema RegistryはAvroとProtobufをサポートしており、行指向になりがちなストリーミングデータにより適している
Hive、Iceberg、Delta Lakeの位置づけ
- Facebookは2009年に独自のテーブルメタデータフォーマットとともにHiveを公開し、その後Hiveは複数のフォーマットをサポートするようになった
- NetflixはHiveの性能とスケーラビリティの限界を超えるためにIcebergを開発した
- DatabricksはIcebergの代替としてDelta Lakeを開発し、その後オープンソース化した
- IcebergとDelta Lakeはいずれも個別のファイルフォーマットとしてParquetを使用する
- Hive、Delta Lake、Icebergはいずれもスキーマレジストリまたはメタストアに相当する概念をサポートしている
- HiveのHMS(Hive MetaStore)は、実際にはほぼ任意のRDBMSを利用できる
- IcebergにはIceberg Catalogsがある
- DatabricksにはUnity Catalogがある
- こうしたカタログやメタストアは、どのチームやユーザーがどのテーブルにアクセスできるかを管理するデータガバナンスにも利用できる
IcebergとDelta Lakeが担う機能
- Delta LakeとIcebergはクエリエンジンやストレージエンジンそのものではなく、クエリエンジンが動作できるようにするオープン仕様である
- 両者は同じ問題を異なる方法で解決しており、Delta LakeはIcebergよりもコントリビューターの多様性が低い点から、オープン性をめぐる議論がある
- Redshift、BigQuery、Snowflake、Athena、Dremioなど、多くのデータウェアハウスやレイクハウスでIceberg対応が急速に広がっている
- IcebergとDelta Lakeは、大規模テーブル運用に必要な機能を提供する
- パーティショニング
- スキーマ進化
- データ圧縮
- スキーマ変更に対するACIDトランザクション
- カラムプルーニング、条件プッシュダウン、統計収集による効率的なクエリ最適化
- 時点参照のためのタイムトラベル
- Icebergはパーティション進化をサポートしており、既存データをすべて書き直さなくてもテーブルのパーティショニング方式やシャードキーを変更できる
- Netflixではパーティショニング変更が大きな悩みであり、Icebergを作った理由の1つでもあった
クローズドフォーマットとIceberg対応への圧力
- Iceberg仕様は、複数のシステムがサポートするフォーマットとして急速に人気を集めている
- クローズドフォーマットを使う製品は、自社フォーマットで可能な限り高い性能を出しつつも、IcebergまたはDelta Lakeを何らかの形でサポートしなければならない圧力を受けている
- Icebergは、すべてのデータベースシステムがいずれ対応すべきチェックボックス機能になる可能性がある
- 性能上の理由から、Icebergがクローズドなデータフォーマットを完全に置き換えるのは難しいかもしれない
- 単一のクエリエンジン専用にデータフォーマットを開発すれば、データベース開発者は最大限の効率を引き出し、より速く革新できる
データレイクとデータレイクハウス
- データレイクは、企業が大量のデータをParquetやCSVのような生ファイルの形で保存する場所である
- データウェアハウスは、データをスキーマを持つSQLテーブルやデータベーススキーマのような、より構造化された方法で保存する
- データレイクハウスは、データレイクにSQLクエリ実行、バッチ処理、データガバナンス構成といった機能を組み合わせた形態である
- Icebergとクエリエンジン、その他の追加コンポーネントを組み合わせれば、データレイク上にデータレイクハウスを構築できる
- 以前は、こうした機能のためにデータウェアハウスやより伝統的なDBMSを導入する必要があった
- データレイクハウスは、HDFSやS3のようなクラウドBlob Storeをすべてのデータの保存場所として利用し、そのストレージ上で高速に動作するようクエリエンジンを最適化する
- DatabricksとDremioはデータレイクハウス製品の例である
- SnowflakeやBigQueryのようなウェアハウスがIcebergのようなオープンデータフォーマットを追加することで、データウェアハウスとデータレイクハウスの区別はさらに曖昧になっている
2件のコメント
IcebergとDelta Lakeを比較していたのですが、こうしてきれいに整理されているのですね。
私が見ていた見解や意見とほぼ同じです。
オンラインで実行されたベンチマークはSparkを使ったもので、ベンチマークは参考にはなるものの大きな意味はないと、TabularのHead of DevRelが書いていました。
オープンソースとして選ぶなら、Icebergが唯一の選択肢に見えます。
要約は良いですが、参考にしたリンクもあるとよいと思います。
Hacker Newsの意見
Apache IcebergとDelta Lakeはどちらもオープンテーブル形式（Open Table Format）としてよく一括りにされるが、実際にはかなり違って見える
Icebergの仕様はhttps://iceberg.apache.org/spec/にあり、データベースシステムを知っている人なら、これを見てIcebergテーブルを作成しクエリする実装を大きな苦労なく作れそうに見える
一方Delta Lakeのほうはhttps://github.com/delta-io/delta/blob/master/PROTOCOL.mdだが、現行仕様を完全に実装するのに必要な作業量すら見積もりにくく、変わり続けるこの巨大な仕様についていくのはさらに途方に暮れる
正直なところ、Delta Lakeの仕様は、Hadoopで痛い目を見たFortune 1000企業向けにDatabricksがレイクハウスを急いで構築する中で生まれた実装上の妥協を、リバースエンジニアリングして文書化したもののように読める
Delta Lakeを採用することが本当にオープンなエコシステムに入ることなのか、まだ納得できていない。この点について安心できる根拠があるとよいのだが
付け加えると、GitHubの履歴も安心材料にはならない: https://github.com/delta-io/delta/commits/master/PROTOCOL.md
任意の機能や修正がDatabricksのエンジニアによるPRとして上がり、Databricksのシニアエンジニアがすぐ承認する流れのように見える
しかしその一方で、コミュニティ主導のオープンな形式だと主張することはできない。『動物農場』式に「ある側はより平等だ」というバージョンなら別だが
計算列やチェック制約のような機能を使うにはSpark SQL式もサポートする必要があるが、そちらのドキュメントはさらに貧弱だ
名目上だけのオープンソースに近く、信用すべきではないと思う
Delta Lakeも使ってみたが、実際の利用ではもどかしい制限や厄介な角が多かった。結局そのプロジェクトは完全にやめ、当時Icebergも調査した
IcebergとHudiは機能構成がより一貫して設計されているほうだったが、サポートはまだ少ない状態で、今後この点が改善することを期待している
この6か月間は、IcebergがJVMエコシステム外のユーザー向けツール提供に苦戦している一方で、Deltaが先行している印象を受けた。その面ではDeltaのほうがずっと取り付きやすい
比較すると、SQL Serverでははるかにうまく実装されている。列指向ストレージテーブル（columnstore indexes、エンジン内部のParquet/ORCに相当）は不変で、デルタは圧縮性・アクセス性・速度のためにB-Treeに保存される
ある時点で列ストアを部分的または全体的にデフラグ・マージ・再構築し、B-Treeは削除された後、新しい変更が蓄積されて再び始まる
これをJSONでやるというのは、控えめに言っても悪い時代の兆候だ
Delta Lakeよりは何でもましに思えるし、特にIcebergのほうが良さそうだ
良い記事だ。S3上のParquetファイルは何年も扱ってきたが、Icebergが正確に何なのかはよく知らなかった。この文章はうまく説明している
Icebergは、基盤となるデータセットのスキーマとパーティショニングなどを記述するデータベースメタデータ形式だ
多くは
/key3=000/key2=002/のようなHiveパーティショニングの慣例を使うが、Icebergはクエリエンジンにより多くの構造を公開する点で優れているPostgresのような従来のDBMSでは、スキーマ、クエリエンジン、ストレージ形式が1つのパッケージとして提供される
しかしビッグデータでは、データベースの構成要素を最初から組み立て、相互に組み合わせて使うことができる。Icebergをメタデータ形式として、DuckDBをクエリエンジンとして、Parquetをストレージ形式として、S3を保存媒体として使える
データベースの世界では大きな変化です。Delta、Iceberg、Hudiのおかげで、データの多くがS3上のオープンソース形式で保存されるようになるためです。
ストレージと処理のかなりの部分が標準化されれば、データベース間の移動が容易になり、ほぼすべてのツールが最終的には同じファイル集合をトランザクション的に安全に扱えるようになります。
たとえばSnowflakeがファイルに書き込んでいる間に、データサイエンティストはJupyter notebookでリアルタイムにクエリでき、ClickHouseは同じデータに対して整合性保証を維持しながらユーザー向け分析を提供できます。
その後、会社がSnowflakeからDatabricksへ切り替えることにしても、それほど大ごとではなくなります。
現時点では、こうした形式をS3上でクエリする速度はネイティブ取り込みほど速くありませんが、市場圧力によってすべてのデータベースベンダーが性能最適化を迫られ、最終的にはネイティブ取り込みデータの性能に近づくはずです。
オープン性とオープンソース、そして企業がデータを開かれた移植可能な形式で保有できるという点で、大きな勝利です。
レイクハウスにも同じ含意があります。多くの企業はデータレイクとデータウェアハウスの両方を持ち、その間でデータをコピーすることになります。
同じデータ集合をクエリし管理するシステムを1つだけにすることにも、同様に大きな効果があります。
データエンジニアリング分野にいる者として、非常に興味深い時期です。
今後は、クエリ実行時にクラウド全体の複数のエンジンだけでなく、ローカルマシンにも実行計画を送れる未来が見えます。
Snowflakeなら、むしろ事業を畳んで投資家に数十億ドルを返したほうがましかもしれません。データを自社エコシステムに囲い込むことこそが、彼らのビジネスモデル全体だからです。
オープン標準が企業に独自技術を手放させた良い例があるのか気になります。
「Apache Arrowデータフレームをディスクファイルとして保存する最良の方法はFeatherであり、Apache Parquetなどにも変換できる」という話には強く同意しません。
JVMではないレイクハウスを自前で作るなら、Icebergをメタデータ、Parquetをデータ、DuckDBをクエリエンジンとして使い、Arrowテーブルとしてクエリする構成が最適です。
ParquetをArrowへ直接読み込むコストは非常に低く、その後Arrow→PandasやPolarsへ渡せばよいです。直接渡してもよいですし、Arrow Flightベースのサービス経由でも構いません。
ここにFeatherを入れると、現在のPythonレイクハウススタック全体がうまく機能しません。
今は変わっているかもしれませんが、それでもParquetが最も将来に備えた選択肢だと感じます。
データレイクは聞いたことがありますが、「データレイクハウス」は上流階級のデータが夏にデータボートに乗ってデータ釣りに行く場所のように聞こえます。
多くの企業はデータレイクにデータを保存し、TableauやPowerBIのようなツールにBIを提供するためにウェアハウスを使います。その結果、両者の間でデータをコピーすることになります。
レイクを直接クエリしつつ、トランザクションとガバナンスを1つのデータ集合に適用するデータレイクハウスは、スタックを大幅に単純化し、コストも削減できます。
聞くたび、読むたびに、頭の中でかなりぎこちなく感じます。
Icebergには特に期待しています。オープンソースだからです。
ただ、最後に見たとき実装はSparkライブラリだけで、Trino（旧Presto、SQLエンジン）のIcebergコネクタはHiveに強く依存していました。
業界全体がMapReduce、Hive、そしてあえて言えばSparkの遺産から離婚するのに苦労しているように見えました。
それ以来Icebergを見直してはいませんが、近いうちに見るつもりですし、この分野の発展を本当に期待しています。
今ではレガシー技術なしでもデータを扱うツールと計算能力があり、すべてのデータがビッグデータというわけでもありません。
そのため幸いにも、データエンジニアリングは徐々に一般的なバックエンド開発に似てきており、普通の開発プラクティスも根付きつつあります。
ごく近い将来、純粋なPython Icebergライブラリが登場することを期待しています。
その依存関係を取り除くために、途方もない労力が費やされました。
Databendは1時間で立ち上げられましたし、Rust実装が出ればJava/Hiveに比べて移植性が高くなり、今後きちんと使いやすくなるだろうと感じました。
なぜこのすべてをもっと具体的に説明できないのか分かりません。
データをどう保存し、どう接続してクエリし、クエリがどれくらい速いのか、といった形で語ってほしいです。たとえばトランザクション速度と分析クエリ速度の違いのように。
現在 GCP で約 100TB のデータを扱っており、BigQuery をクエリエンジンとして使い、
/key3=000/key2=002/のような単純な Hive パーティショニングを使用している。必要なクエリはすべて実行でき、コストも非常に安いので満足している。
ただしレイテンシがかなり高くなってきているが、私たちにとって極めて重要というわけではない。それでも Iceberg を導入すればこの点が改善されるのか気になっている。
こうした経験のある人がいるのか知りたいし、全体としてこのようなアーキテクチャは本当に素晴らしい。
こうした技術の主目的は大規模データ管理だが、Parquet のような素のストレージ形式が提供する機能も拡張する。なので役に立つ可能性はあるが、本当に必要かは見極める必要がある。
BigQuery は使ったことがないが、similar features があるかもしれない。
まず、ここでいう「レイテンシ」が何を指すのか、「かなり高い」がどの程度なのかを定義する必要がある。
分析用データストアは効率的なバッチ処理のために設計されており、単一レコードを探すことはこのアーキテクチャの主目的ではない。高速な検索にはキャッシュやインデックスが必要だ。
場合によっては、単一レコード検索に
limit 1を追加するだけで解決することもある。Parquet のような効率的なデータ保存形式を使っているか確認し、ファイルサイズを点検して "small file problem" がないか見るべきだ。
そのうえで、関連する BigQuery の機能を使っているかも確認する必要がある。こうした点検の前後でクエリに
explainを実行してみるとよい。パーティションキーやインデックス列を使っていないなら、どんなビッグデータシステムでも検索結果が即座に返ることはない。BigQuery テーブルを高スループット計算の入力として使っているのでなければ、BI ツールの最適化や、エンドユーザーの遅延を防ぐ分析用テーブルの作成に集中すると思う。
たとえば最近、ファクト/ディメンションテーブルの結合と
COALESCE演算をマテリアライズして、分析専用の大きなテーブルを作った。概念的には通常のデータウェアハウス構成の「外」にあるが、dbt の中に存在するため、データ品質とリネージは維持できた。
そのおかげで Tableau の固定計算をなくし、エンドユーザーのロード/グループ化時間を約 95% 削減できた。
GCS/S3 に対するフェデレーテッドクエリなら速くなる可能性がある。
「この記事は 100% 網羅的でもなければ、多くの人にとって最高の出発点でもないだろう。自分のために書いているからだ。新しいことを学ぶ最良の方法は、それを他人に説明し直すよう自分に強いることだと感じている」という姿勢が本当に気に入った。
私も紙のノートや自分の Web サイト上のメモで、こうしたやり方を取り入れ始めた。
より管理された Parquet ストレージの Iceberg 時代を深掘りすることに大きく期待していた。
しかし、まだ高速 GPU I/O（GPUDirect/cuFile）対応は数年遅れている。
そのため AI ワークロード向けに顧客へ持っていこうとするたびに、その壁にぶつかる。
いずれ実現しそうではあり、「可能か」よりも「いつか」の問題に近い。二兎を追って両方を得られるようになれば、本当に素晴らしいと思う。
テキストの保存には、今日では Parquet で十分だ。
PyTorch Data Loader と TF Data は、並列に先読みし、メモリバッファを満たしたうえで GPU とやり取りするマルチスレッドクライアントを提供している。
S3 がここでボトルネックになり得るという点には同意する。そこで私たちは S3 の上に、グローバル分散の一貫性を持つ NVMe キャッシュとして HopsFS を置いている。
Anyscale も S3 用のローカル NVMe キャッシュで似たことをしてきた。
もう一つ興味深いファイル形式に Lance があり、Parquet に似ているが画像データ向けだ。ファイル内で画像を見つけるための高速なランダム I/O インデックスが追加されている。