Parquet、Iceberg、そしてデータレイクハウスを理解する

 (davidgomes.com)
6 ポイント 投稿者 GN⁺ 2023-12-31 | 2件のコメント | WhatsAppで共有

理解する: Parquet、Iceberg、そしてBroadInのデータレイクハウス

  • データの保存方式（ファイルおよびメモリ内）

    • データのアクセスと保存のために、さまざまなファイル形式が存在する
    • 一部のシステムはクローズドなデータ形式を主に使用するが、ほとんどのシステムはオープンなデータ形式をサポートしている
    • 主なオープンソースのファイル形式には、Apache Avro、Parquet、ORC、Arrow、Feather、Protobuf などがある
    • これらの形式は、データを実際のバイナリレイアウト上でどのように配置するかについての仕様を提供する
    • Parquet は圧縮のサポートに優れ、Avro は特定の行ブロックを読み取るのに適している
    • スキーマ進化とファイル分割をサポートし、並列処理に不可欠である
    • さまざまなプログラミング言語やツールから、これらの形式を扱うことができる

  • 大規模データ管理 - Iceberg と Delta Lake

    • さまざまなテーブルを保存し、個別のスキーマを進化させ、効率的にデータをパーティショニングし、外部ツールがスキーマを簡単に読み取れるようにする方法が必要
    • Hive、Iceberg、Delta Lake はいずれもスキーマレジストリまたはメタストアをサポートしている
    • Iceberg と Delta Lake は、個別ファイル形式として Parquet を使用する
    • Iceberg と Delta Lake はクエリエンジンやストレージエンジンではなく、クエリエンジンが処理を実行できるようにするためのオープン仕様である
    • パーティショニング進化、スキーマ進化、データ圧縮、ACID トランザクション、効率的なクエリ最適化、タイムトラベルなどの機能を可能にする

  • データレイクとデータレイクハウスとは何か？

    • データレイクは、企業が OCR、Parquet、CSV ファイルのような生の形式で大量のデータを保存する場所
    • データレイクハウスは、データレイクの上に SQL クエリの実行、バッチジョブの設定、データガバナンスの構成などを可能にする機能を組み合わせたもの
    • データレイクハウスは、オープンなデータウェアハウスの一種と見ることができる
    • Snowflake や BigQuery のようなデータウェアハウスが Iceberg のようなオープンデータ形式をサポートするようになり、データウェアハウスとデータレイクハウスの境界は曖昧になりつつある

GN⁺の意見

  • Iceberg と Delta Lake は、大規模データセットを管理するためのメタデータレイヤーとして重要な役割を果たす。これにより、データの効率的な管理とクエリ最適化が可能になり、データサイエンティストやエンジニアにとって有用である。
  • データレイクハウスは、データレイクとデータウェアハウスの利点を組み合わせ、データ管理と分析のための新しいパラダイムを提示する。これは、データにもとづく意思決定をさらに強化できる機会を提供する。
  • Iceberg のサポートが増えるにつれ、データ管理および分析システムは徐々に標準化され、相互運用可能になっていくと見込まれる。これにより、データプラットフォームの選択と活用において、より大きな柔軟性と効率性がもたらされる。

関連記事

2件のコメント

 
happing94 2024-01-03

IcebergとDelta Lakeを比較していたのですが、こうしてきれいに整理されているのですね。
私が見ていた見解や意見とほぼ同じです。
オンラインで実行されたベンチマークはSparkを使ったもので、ベンチマークは参考にはなるものの大きな意味はないと、TabularのHead of DevRelが書いていました。
オープンソースとして選ぶなら、Icebergが唯一の選択肢に見えます。
要約は良いですが、参考にしたリンクもあるとよいと思います。
 
GN⁺ 2023-12-31
Hacker Newsのコメント

  • Apache Iceberg と Delta Lake はしばしばオープンテーブルフォーマットとして言及されるが、実際には違いがある。

    • Apache Iceberg のテーブルフォーマット仕様は、データベースシステムに慣れている人なら Iceberg テーブルを構築してクエリするのに大きな困難がないほど明確である。
    • 一方で、Delta Lake の仕様は、現在の仕様を完全に実装したり継続的に更新したりするのに必要な労力を把握しにくい。
    • Delta Lake の仕様は、Databricks が Hadoop に失望した Fortune 1000 企業向けにレイクハウスを構築するため、社内で決めた実装方法をリバースエンジニアリングしたもののように見える。
    • Delta Lake が本当にオープンなエコシステムとして価値があるのか確信が持てない。

  • データベースの世界では、Delta、Iceberg、Hudi が S3 のようなストレージにオープンソースのフォーマットでデータを保存することは大きな変化を意味する。

    • これはストレージと処理の多くが標準化され、データベース間の移行が容易になり、ほとんどのツールがトランザクション的に安定した形で同じファイルセットを扱えるようになることを意味する。
    • たとえば、Snowflake がファイルに書き込んでいる間に、データサイエンティストが Jupyter ノートブックでリアルタイムにデータをクエリし、ClickHouse が同じデータに対してユーザー向けの分析を提供できる。
    • 企業が Snowflake から Databricks へ移行することを決めても、大きな問題にはならない。
    • 現時点では、S3 上のこれらのフォーマットをクエリする速度はネイティブな取り込みほど速くはないが、市場圧力によってすべてのデータベースベンダーが性能を最適化するようになるだろう。
    • これはオープンソースとオープン性にとって大きな勝利であり、企業がデータをオープンで移動可能なフォーマットで保有できるようになる。
    • レイクハウスも同様の影響を与える。多くの企業はデータレイクとデータウェアハウスの両方を持っており、2つのシステム間でデータをコピーしなければならない。同じデータセットをクエリし、1つのシステムだけを管理することも同じように重要である。

  • Parquet ファイルを S3 上で何年も扱ってきたが、Iceberg が何なのか正確には理解していなかった。しかし、その記事は Iceberg をうまく説明している。

    • Iceberg は基盤となるデータセットに対するデータベースメタデータのフォーマットであり、スキーマやパーティショニングなどを記述する。
    • 従来の DBMS では、スキーマ、クエリエンジン、ストレージフォーマットが1つのパッケージとして提供される。
    • しかしビッグデータでは、データベースの構成要素を一から構築し、組み合わせて使うことができる。Iceberg をメタデータフォーマットとして、DuckDB をクエリエンジンとして、Parquet をストレージフォーマットとして、S3 をストレージ媒体として使える。

  • Apache Arrow データフレームをディスク上のファイルとして保存する最善の方法は Feather を使うことだが、Apache Parquet フォーマットに変換することも可能である。

    • 独自の非 JVM レイクハウスを構築したいなら、メタデータに Iceberg、データに Parquet を使い、Arrow テーブルを用いて DuckDB でクエリし、Arrow->Pandas または Polars を通じてデータを処理できる。
    • Feather を混ぜると、現状では Python レイクハウススタックは動作しない。

  • データレイクについては聞いたことがあるが、「データレイクハウス」は上流階級のデータが夏にデータボートでデータ釣りに行く場所のように聞こえる。

  • GCP で約 100TB のデータを扱っており、BigQuery をクエリエンジンとして使い、単純な Hive パーティショニングを利用している。すべてのクエリを実行でき、コストも非常に安いことには満足しているが、レイテンシはかなり高い（会社にとって大きな問題ではない）。

    • Iceberg を実装すればこれを改善できるのか気になっている。Iceberg を使った経験がある人はいるだろうか。

  • Iceberg にはとても興奮しているが、最後に調べたときは Spark ライブラリしか実装がなく、Trino の Iceberg コネクタは Hive に強く依存していた。

    • 業界全体が MapReduce、Hive、Spark のようなレガシー技術と決別するのに苦労している。
    • Iceberg について改めて調べるつもりで、この分野が発展することを期待している。今日では、レガシー技術なしでデータを処理できるツールと計算能力があり、すべてのデータがビッグデータというわけではない。
    • その結果、「データエンジニアリング」はますます一般的なバックエンド開発に近づいており、一般的な開発プラクティスが適用されつつある。
    • 純粋な Python の Iceberg ライブラリがごく近いうちに出てほしい。

  • なぜこれらすべてをもっと具体的なアイデアとして説明できる人がいないのか疑問に思う。データの保存方法、接続方法とクエリ方法、そしてクエリ速度（トランザクション速度に対する「分析」速度）を説明すべきである。

  • オンラインで見たすべてのベンチマークでは、Delta Lake フォーマットが Iceberg よりはるかに優れた性能を示している。

    • これが仕様に本質的なものなのか、それとも Iceberg が差を縮める余地があるのかという疑問。

  • このブログ記事が 100% 包括的でもなく、大半の人にとって最良の出発点でもないだろうという点は認めている。

    • 新しいことを学ぶ最善の方法はそれを他人に説明し直すことだという姿勢が気に入っており、自分でもウェブサイトのノートに取り入れ始めている。