Apache Iceberg ストレージと Pandas Analytics: パート I

Claude Paugh
5月7日
読了時間: 8分

私は新しいことに挑戦するのが好きで、テクノロジーも例外ではありません。そこで、Apache Iceberg、特にPython実装であるPyIcebergの仕組みについて、さらに詳しく調べてみることにしました。

私は、テクノロジーに関係なく、通常はデータ管理プラクティスの一部となるいくつかの重要な項目を具体的に検討しました。

データ品質管理: 少なくともデータ型で、できれば値の検査でスキーマを検証できますか。
データ整合性: データが複数のデータ構造にリンクされている場合、重複を防ぎ、キーを強制し、ある程度の参照整合性を維持できるか

データアクセス: 行レベルのアクセスでセキュリティを管理できますか。また、アクセス時間は堅牢で、取得と読み込みが合理的です (つまり、ユーザー、サービス、アプリケーションの平均的な期待どおりです)。
メタデータ管理: 複数のバージョンを経て進化し、変更をロールバック/元に戻す機能を提供するスキーマを作成できますか。

PyIcebergを初めてお使いになる方のために説明すると、これはJVMを必要としないApache IcebergのPython実装です。オープンソースなので、PyIcebergのGitHubリポジトリはこちら、コミュニティサポートはこちらでご利用いただけます。このプロジェクトは、当初Apache Sparkの拡張機能として始まり、その後FlinkとHiveへと発展しました。

アパッチアロー財団

データI/Oの仕組みはApache Arrowに基づいています。Apache Arrowは、表形式データとシステム間のデータ交換、特にインメモリ分析の仕様を定義するために開始されたプロジェクトです。Arrowは当初C言語で書かれ、その後、いくつかの他の言語に移植されました（上記のホームページリンクから実装を参照してください）。

ホームページリンクの下部には、 C++ 、 Java 、 Python 、 Rのクックブックへのリンクがあり、これらの言語の実装をすぐに始めることができます。C#、Rust、Ruby、MATLABなどの一般的な言語やツールキットへの移植も可能です。

Apache Parquet または ORC 形式を現在使用している場合、または使用を計画している場合は、クラウドベンダーまたはクエリエンジンのライブラリが、各プロバイダー固有の拡張機能の開始基盤として Arrow ライブラリをソースし、ラップしていることに気付くでしょう。

AI/ML拡張機能

AI/ML コミュニティ向けの CUDA 拡張機能がありますが、高価な GPU リソースでデータ変換や操作を実行しないようにすると、コスト効率と処理効率が向上します。

こうしたデータ中心のタスクにおける関心の分離の欠如は、AI/MLモデルの学習と実行におけるGPUとCPU消費量の少なさに対する需要の原動力の一つだと思います。分離の必要性が認識されていないというよりも、分離を設計し実現するまでに時間がかかる、つまり、分離が実現されていないという問題です。

GPUはCPUのような汎用プロセッサではなく、（少なくとも現時点では）アルゴリズムや視覚化のための計算に適しています。GPUは、三角形上の点を並列に計算し、グラフィック表示を行うために発明されました。NVIDIAは GPUパフォーマンスに関する入門情報を提供しています。オハイオ・スーパーコンピューティング・ラボ（2007年）によるセルベースプロセッサ（GPUもその一形態）の基本的な概要は以下の通りです。

Cellベースプロセッサの具体的なユースケースは、開発の現場では多くのエンジニアが複数のプロセッサではなく単一のプロセッサに特化してキャリアを積んできたため、重要なポイントとなります。特定のコンピューティングリソースにおけるワークロード分離のスキルを開発し、磨く必要があります（インタールードトピックの終わり）。

Apache Iceberg の裏側

メタデータとデータストレージに対する全体的なアプローチは、不変性を確保することであり、これは間違いなくプラスです。なぜでしょうか？簡単に言うと、不変性を実装することで（適切に実装された場合）、データアクセスの同時実行性とパフォーマンスのスケーリングが向上し、スキーマとデータの進化に伴うトレーサビリティも確保されます。RDBMS製品のユーザーであれば、データ（メタデータ）とインデックスの断片化の問題は、常に注意を払い、メンテナンスサイクルを繰り返す必要があるでしょう。これは、分析（ROLAP）やハイブリッド（OLTPと長い履歴）のケースで特に影響が大きいですが、不変性を実装することでこの問題は解消されます。

上記で示唆したように、IcebergはArrow、Parquet、ORC、AVROといったApacheプロジェクトの様々なライブラリをラップして利用しています。これらのライブラリは主に、メモリ内またはファイルベースの永続化におけるI/O操作に重点を置いています。IcebergはPythonでのメタデータ実装にPydanticも積極的に活用しています。

スキーマ構造の「モデル」はPydanticを使用して構築および検証され、メタデータオブジェクトは永続ストアを使用してカタログに保存されます。永続ストアには、REST、SQL DBMS、インメモリストア、Apache Hive、AWS Glue、またはカスタマイズされたものからアクセスできます。https ://iceberg.apache.org/spec/から引用した概要を以下に示します。これは、その構成を視覚的に表すものです。下の図には、メタデータファイルはApache AVROファイルであり、マニフェストリストはJSON形式です。この組み合わせが選択された理由は、スキーマ検証プロパティとPydanticの組み合わせにあると考えられます。

メタデータとデータ品質

メタデータの編成は名前空間レベルから始まり、論理的またはコンテキストに基づいたデータの分離です。必要に応じて、データへのアクセス時に名前空間をまたいだ参照を行うことができます。テーブルオブジェクトは名前空間の「下」に作成され、こちらで確認できるスキーマの実装タイプを提供します。地理空間データを保存する必要がある場合、Icebergはジオメトリタイプと地理タイプをサポートし、メタデータレイヤーでCRS（座標参照系）とエッジ補間をサポートしています。データのパーティション分割と行の系統化も利用可能で、カタログ作成時に詳細な系統化に保持するレコード数を設定できます。

上の図をより分かりやすくするために、パートIIの実装例で作成したIcebergテーブルのコンソールファイル出力を掲載しました。デバイス上に「warehouse」フォルダを作成し、「docs」名前空間からリストを開始しています。「forecast」データとメタデータをドリルダウンしています。

Pydanticの実装、特に「厳密」モード（メタデータとデータ）使用時の実装は、この記事の冒頭で述べた「メタデータ」と「データ品質」の項目を網羅しています。また、メタデータでは列レベルまでスキーマのバージョン管理が可能で、スキーマの進化を支援する優れたメカニズムも備えています。Icebergメタデータは、RDBMSにおける「制約」（リテラルテーブルDDLではありません）に相当するものを使用して実装された、多くのバリエーションを提供しています。型検証、必須フィールドの指定、サイズと精度の検査などの機能がありますが、特定のフィールドにカスタム値リストを適用する機能は備えていません。

私の経験では、RDBMSにおけるリストオブバリューの使用は、OLAP（分析）よりもOLTP設計パターンでより一般的です。Apache Icebergは明らかに分析ユースケース向けに設計されており、トランザクション処理向けではありません。全体として、データ品質とメタデータの面で良いスタートを切っています。「デフォルト」値属性は、代替の「キー」に相当するものを実装したり、「識別子」フィールドIDを使用したりする機能を提供します。

主キーやユニークキーに相当する機能は提供されていません。これらは、関連付けられたインデックスの有無にかかわらず一意性を保証するデータベース制約の一種です。ユーザー管理のインデックスもありませんが、前述のファイル形式のいずれかを既に使用している場合、これは新しいものではなく、また、今後提供されることも想定されていません。一意性の確保は「ユーザー」の責任です。例えば、構造体内で一意性を強制することは可能ですが、それはユーザー自身で実現するものであり、Iceberg が代わりに行うわけではありません。

行レベルのセキュリティ

Apache Icebergにとって課題となるのは、RWA（行レベルアクセスセキュリティ）とデータ整合性です。私が評価しているのは、ライブラリに「組み込まれている」機能であり、追加ツールを使用してこれらの問題を解決するソリューションをどのように構築できるかではありません。

RWAセキュリティはライブラリに組み込まれていません。行とメタデータの機能については、データ品質の問題の診断や経時変化の分析に役立つ優れた系統がいくつか存在します。特に、時系列データのユースケースでは非常に有用です。しかし、RWAセキュリティは企業のセキュリティ要件となることが多いため、将来的にはLDAP統合によってこれに対応できるようになることを期待しています。

データの整合性

Icebergではデータ整合性機能にはあまり重点が置かれていません。これはおそらく、AI/MLデータアクセスのトレンドとして、データテーブルを非正規化し、外部キーが不要になる、つまり1つの大きなテーブルになる傾向があるためでしょう。これは、リレーションシップリンク（物理または仮想）を必要とする複数のテーブルが存在する、より従来型の分析ユースケースで発生するため、そのようなケースでは役立つ追加機能となるでしょう。たとえメタデータで追跡する情報のみであっても、検証の強化に役立ちます。これはIcebergでは見落とされがちな領域です。

データアクセス

前述のApache Arrow形式のいずれかを現在使用しているユーザーは、それぞれの形式がどのようなものかご存知でしょう。大容量データストレージの場合、Parquetは大規模から超大規模データセット、特にクエリ応答時間を適正に保つためにパーティショニングが必要な場合に頻繁に使用されます。私は小規模な実装を行いました。その詳細は、この記事のパートIIで説明します。パートIIでは、単純な応答時間を記録します。しかし、多くの人がご存知のとおり、Parquetは、特に適切にパーティショニングされている場合、クエリリクエストへの応答性が非常に高くなります。列指向形式は、分析ユースケースに適合し、サービス提供するために特に適切に設計されています。

記事の次の部分では、Apache Iceberg と、Python 集計を使用した財務データを使用した簡単な実装について説明します。