Iceberg + AIStorが現代のマルチエンジンデータレイクハウスを発電する方法

最初はNetflixでライアン・ブルー(Ryan Blue)によってインキュベートされた。 現在、DataBricksの名声で知られていますが、最終的に現在住んでいるApache Software Foundationに送信されました。その核心は、アットスケールデータセットのためのオープンテーブル形式です(数百TBから数百PBまで考えてください)。AIがモデル作成、調節、リアルタイムの推論のために膨大な量のデータを埋め込んでいたことで、このテクノロジーの必要性は最初の開発以来だけ増加しました。 Apache Icebergについて テーブル Apache Icebergについて テーブル Iceberg は複数のエンジンに対応したフォーマットで、Spark、Trino、Flinks、Presto、Snowflake、Dremio はすべて、同じデータセット上で独立して同時に動作することができることを意味します。Iceberg は、データ分析の普遍的な言語である SQL をサポートし、原子トランザクション、スケジュールの進化、パーティションの進化、タイムトラベル、ロールバック、ゼロコピー分割などの高度な機能を提供しています。 関連する: Data Lakehouse Solutions by ミニオ Data Lakehouse Solutions by ミニオ 現代のオープンテーブル形式の目標 レイクハウスの約束は、データレイクと倉庫の最善を統一する能力にある。オブジェクトストレージに保存されるデータレイクは、大量の原料データをそのネイティブ形式で保存するように設計され、スケーラビリティ、使いやすさ、コスト効率性を提供しました。しかし、データレイクは、データ管理などの問題と、それらに保存されているデータを効率的にクエリする能力と闘っていました。 Iceberg や Apache Hudi や Delta Lake などの他のオープンテーブル形式は、前進の飛躍を意味します。これらの形式により、データ湖は倉庫のように振る舞い、オブジェクトストレージの初期の柔軟性とスケーラビリティを維持します。オープンテーブル形式とオープンストレージのこの新しいバックパックは、AI、機械学習、高度な分析、リアルタイムのビジュアル化などの多様なワークロードをサポートすることができます。 ここでは、このインフラストラクチャがどのように機能するかを見ていきます。クエリエンジンは、あなたのバック内のオブジェクトストレージの上に直接座り、移行することなくその内部のデータをクエリすることができます。dデータベースのストレージにデータを移行する古いパラダイムは、もはや重要ではありません。代わりに、どこからでもIcebergテーブルをクエリすることができます。 Analytics ツールと Visualizations は、Iceberg テーブルが格納されているストレージに直接接続できますが、より一般的にクエリ エンジンと接続してより簡素なユーザー エクスペリエンスを提供します。 最後に、AI/ML はクエリ エンジンと同じ設計原理を持っています これらの AI/ML ツールは、移行なしでオブジェクトストレージに直接 Iceberg テーブルを使用します。 特に、モデルやデータセットの複数のバージョンを困難なく維持する能力のために。 MLワークロード MLワークロード Icebergの何が特別なのか Apache Icebergは、Apache HudiやDelta Lakeなどの代替品と区別する機能と設計原則の組み合わせによって独特です。 Iceberg は、既存のデータの完全な書き換えを必要とせずに、スケジュールの進化に包括的なサポートを提供し、ユーザーが列を追加、ダウンロード、更新、または名前を変更することを可能にします。 Schema Evolution Iceberg はパーティションの進化をサポートし、データの書き換えを必要とせずに時間とともにパーティションスケジュールの変更を可能にします。 Partition Evolution Iceberg は、明示ファイル、明示リスト、およびメタデータファイルを含む等級的なメタデータ構造を使用しています。この設計は、データファイルに関する詳細な情報を提供することで、クエリの計画と最適化を強化し、効率的なデータアクセスと管理を容易にします。 Metadata Management Iceberg は、オープン性を念頭に置いて設計され、Apache Spark、Flink、Trino、Presto などのさまざまな処理エンジンと互換性があります。 価格を下げ、これらの製品におけるイノベーションを促進する。 Multi-Engine Compatibility 商品検索エンジン 商品検索エンジン すべてのオープンテーブル形式と同様に、Icebergは多様でアクティブなコミュニティから恩恵を受け、その強力さと継続的な改善に貢献します。 Open Source Community Object Storage and Iceberg(オブジェクトストレージとアイスベルグ) オブジェクトストレージは、多くの環境で膨大なデータセットを管理するために必要なスケーラビリティ、耐久性、およびコスト効率を提供する現代のレイクハウスアーキテクチャの基礎となっています。 たとえば、モデルトレーニングなどの高流量ワークロードの場合、AIStor の S3 に対する RDMA サポートは、データへの低遅延アクセスを確保します。この機能により、両テクノロジーの組み合わせは、特に大規模なAI および分析パイプラインのための非常に効果的なソリューションになります。 アイスター アイスター 自分で試してみて:前提条件 Docker と Docker Compose をインストールする必要があります。両方が必要な場合、インストールがしばしば簡単になります。 . Docker Desktop を公式の Docker ウェブサイトからダウンロードしてインストールします。 オペレーティング システムのインストーラーで提供されたインストールの指示に従って Docker Desktop を起動します。 デスクトップ Docker デスクトップ Docker あなたが好むなら、あなたはまた、端末を開いて実行することで、DockerとDocker Composeのインストールを確認することができます: docker --version docker-compose --version Iceberg チュートリアル このセクションでは、IcebergとAIStorを統合する方法を示しています。 初期環境を構築するには: 「Apache Iceberg Spark Quickstart」 Apache Iceberg Spark Quickstart Step 1: Setup with Docker Compose ステップ1:Docker Composeで設定する フォロー THE Spark と Iceberg でコンテナ化された環境を起動するには、ガイドの最初のステップは、以下の情報をファイルにコピーして docker-compose.yml というファイルとして保存することです。 Apache Iceberg Spark Quickstart ガイド Apache Iceberg Spark Quickstart ガイド version: "3" services: spark-iceberg: image: tabulario/spark-iceberg container_name: spark-iceberg build: spark/ networks: iceberg_net: depends_on: - rest - minio volumes: - ./warehouse:/home/iceberg/warehouse - ./notebooks:/home/iceberg/notebooks/notebooks environment: - AWS_ACCESS_KEY_ID=admin - AWS_SECRET_ACCESS_KEY=password - AWS_REGION=us-east-1 ports: - 8888:8888 - 8080:8080 - 10000:10000 - 10001:10001 rest: image: apache/iceberg-rest-fixture container_name: iceberg-rest networks: iceberg_net: ports: - 8181:8181 environment: - AWS_ACCESS_KEY_ID=admin - AWS_SECRET_ACCESS_KEY=password - AWS_REGION=us-east-1 - CATALOG_WAREHOUSE=s3://warehouse/ - CATALOG_IO__IMPL=org.apache.iceberg.aws.s3.S3FileIO - CATALOG_S3_ENDPOINT=http://minio:9000 minio: image: minio/minio container_name: minio environment: - MINIO_ROOT_USER=admin - MINIO_ROOT_PASSWORD=password - MINIO_DOMAIN=minio networks: iceberg_net: aliases: - warehouse.minio ports: - 9001:9001 - 9000:9000 command: ["server", "/data", "--console-address", ":9001"] mc: depends_on: - minio image: minio/mc container_name: mc networks: iceberg_net: environment: - AWS_ACCESS_KEY_ID=admin - AWS_SECRET_ACCESS_KEY=password - AWS_REGION=us-east-1 entrypoint: > /bin/sh -c " until (/usr/bin/mc config host add minio http://minio:9000 admin password) do echo '...waiting...' && sleep 1; done; /usr/bin/mc rm -r --force minio/warehouse; /usr/bin/mc mb minio/warehouse; /usr/bin/mc policy set public minio/warehouse; tail -f /dev/null " networks: iceberg_net: 次に、端末ウィンドウで .yml ファイルを保存した場所に移動し、このコマンドでドッカーコンテナを起動します。 docker-compose up 次に、次のコマンドを実行して、Spark-SQL セッションを開始できます。 ドッカー exec -it spark-iceberg spark-sql Step 2: Create a Table ステップ2:テーブルを作成 Spark shell を開いてテーブルを作成します。 CREATE TABLE my_catalog.my_table ( id BIGINT, data STRING, category STRING ) USING iceberg PARTITIONED BY (category); あなたの MinIO Console をチェックして、Navigate to AWS_ACCESS_KEY_ID=admin、AWS_SECRET_ACCESS_KEY=password http://127.0.0.1:9001 http://127.0.0.1:9001 ここでは、テーブルのために作成された iceberg/my_table/metadata パスを観察します. Initially, no data files exist—only metadata that defines the schema and partitions. Step 3: Insert Data ステップ3:データを入力 いくつかのMockデータを入力する: INSERT INTO my_catalog.my_table VALUES (1, 'a', 'music'), (2, 'b', 'music'), (3, 'c', 'video'); この操作は、適切なパーティション(my_table/data/category=...)でデータファイルを作成し、メタデータを更新します。 Step 4: Query the Data ステップ4: Query the Data 検証するための基本的なクエリを実行する: SELECT COUNT(1) AS count, data FROM my_catalog.my_table GROUP BY data; あなたの出力は次のようになるはずです。 spark-sql ()> SELECT COUNT(1) AS count, data > FROM my_catalog.my_table > GROUP BY data; 1 c 1 b 1 a Time taken: 0.575 seconds, Fetched 3 row(s) Key Iceberg Featuresの検索結果 Iceberg をユニークにする機能: Schema Evolution および Partition Evolution をご覧ください。 Schema Evolution 進化計画 Schema evolution は、Apache Iceberg の最も強力で定義的な機能の 1 つであり、従来の倉庫システムにおける大きな痛みを解決します. それは、高価で時間がかかるデータの書き換えを必要とせずにテーブルのスケジュールを変更することを可能にし、特に大規模なデータセットに有益です. この機能は、組織が継続的なクエリや操作を妨げることなく、ビジネスニーズが進化するにつれてデータモデルを調整することができます. Iceberg では、スケジュールの変更は純粋にメタデータレベルで処理されます。テーブルの各列にはユニークな ID が割り当てられ、スケジュールの変更がデータファイルに影響を与えないようにします。例えば、新しい列が追加された場合、Iceberg は既存のデータを再解釈または書き換えることなく新しい ID を割り当てます。 次に、スケジュールの進化が実践的にどのように機能するかを示す例を参照してください. Suppose you need to add a new column, buyer, to store additional information about transactions. You can execute the following SQL command: ALTER TABLE my_catalog.my_table ADD COLUMN buyer STRING; この操作はテーブルのメタデータを更新し、新しいデータファイルが購入者列を含めるようにします。 古いデータファイルは影響を受けず、クエリは新しいデータと古いデータの両方をシームレスに処理するように書くことができます。 同様に、列が必要なくなった場合は、保存されたデータに影響を及ぼさずに削除できます。 ALTER TABLE my_catalog.my_table DROP COLUMN buyer; このアクションでは、カテゴリ列を除外するためにスケジュールを更新します. Iceberg は、関連するメタデータがクリアされ、古いデータバージョンを参照する可能性のある歴史的なクエリの完全性を維持します。 Iceberg's Schema Evolution では、コラムの名前変更、コラムのタイプの変更、およびコラムの順序の再編成もサポートしていますが、すべては効率的なメタデータだけの操作を通じて行われます。 このアプローチは、AI/ML実験、ダイナミックなビジネス論理、または進化する規制要件によって推進されるような頻繁なスケジュール変更の環境において特に有利です。 Partition Evolution Partitionの進化 Iceberg は、テーブル内の行のためのパーティション値を生成するという退屈でエラーに敏感なタスクに対処できるパーティション進化をサポートしています. Users focus on adding filters to the queries that solve business problems and do not worry about how the table is partitioned. Iceberg automatically avoids reads from unnecessary partitions. Iceberg は、パーティションを定義するか、Iceberg がそれを管理するようにすることができます。 Iceberg は、イベントの時間などのタイムスタンプでパーティションを処理するのが好きです。 パーティションは、マニフェストのスナップショットによって追跡されます。 クエリは、テーブルの物理的なレイアウトに依存しなくなります。 物理的および論理的なテーブルのこの分離のために、Iceberg テーブルは、より多くのデータが追加されるにつれて、時間とともにパーティションを進化させることができます。 ALTER TABLE my_catalog.my_table ADD COLUMN month int AFTER buyer; ALTER TABLE my_catalog.my_table ADD PARTITION FIELD month; 私たちは今、同じテーブルのための2つのパーティション スケジュールを持っています。これから、クエリ プランは分割され、古いパーティション スケジュールを使用して古いデータをクエリし、新しいパーティション スケジュールを使用して新しいデータをクエリします。Iceberg は、テーブルをクエリする人々は、データが2つのパーティション スケジュールを使用して保存されていることを知る必要はありません。Iceberg は、バック・ザ・シーン WHERE 条項とパーティション フィルターの組み合わせを通じて、データ ファイルを一致せずに割り出します。 Time Travel and Rollback タイムトラベル&ロールバック Iceberg テーブルに書き込むたびに新しいスナップショットが生成されます。スナップショットはバージョンと同じで、AIStor のバージョンアップ機能と同様にタイムトラベルやロールバックに使用できます。スナップショットを管理する方法は、システムがよく維持されているようにスナップショットを有効に設定することです。タイムトラベルは、同じテーブルのスナップショットを使用する再生可能なクエリを可能にします、またはユーザーが変更を容易に検討することができます。バージョンロールバックは、ユーザーがテーブルを良い状態に戻すことで問題を迅速に修正することができます。 テーブルが変更されるにつれて、Iceberg はそれぞれのバージョンをスナップショットとして追跡し、テーブルをクエリするときにどのスナップショットにもタイムトラベルする機能を提供します。これは、過去のクエリを実行するか、特にレポートのために以前のクエリの結果を再現したい場合に非常に役に立ちます。タイムトラベルは、既知の結果のクエリで新しいコードをテストできるので、新しいコードの変更をテストするときに役に立つこともできます。 テーブルに保存されたスナップショットを表示するには、次のクエリを実行します。 SELECT * FROM my_catalog.my_table.snapshots; あなたの出力はこんな感じでなければなりません: 2025-01-10 00:35:03.35 4613228935063023150 NULL append s3://warehouse/my_catalog/my_table/metadata/snap-4613228935063023150-1-083e4483-566f-4f5c-ab47-6717577948cb.avro {"added-data-files":"2","added-files-size":"1796","added-records":"3","changed-partition-count":"2","spark.app.id":"local-1736469268719","total-data-files":"2","total-delete-files":"0","total-equality-deletes":"0","total-files-size":"1796","total-position-deletes":"0","total-records":"3"} Time taken: 0.109 seconds, Fetched 1 row(s) いくつかの例: -- time travel to October 26, 1986 at 01:21:00 SELECT * FROM my_catalog.my_table TIMESTAMP AS OF '1986-10-26 01:21:00'; -- time travel to snapshot with id 10963874102873 SELECT * FROM prod.db.table VERSION AS OF 10963874102873; スナップショットを使用して増加的な読み込みを行うことができますが、Spark ではなく Spark-SQL を使用する必要があります。 scala> spark.read() .format(“iceberg”) .option(“start-snapshot-id”, “10963874102873”) .option(“end-snapshot-id”, “10963874102994”) .load(“s3://iceberg/my_table”) また、テーブルを特定の時点または特定のスナップショットに戻すこともできます。 CALL my_catalog.system.rollback_to_timestamp(‘my_table’, TIMESTAMP ‘2022-07-25 12:15:00.000’); CALL my_catalog.system.rollback_to_snapshot(‘my_table’, 527713811620162549); エクスプレス SQL Iceberg は、行レベルの削除、合併、アップデートなどのすべての表現的な SQL コマンドをサポートしており、最も注目すべきことは、Iceberg は Eager と Lazy 戦略の両方をサポートしていることです。私たちは、削除する必要があるすべてのものを暗号化することができます (例えば、GDPR または CCPA) ですが、すべてのデータファイルを直ちに書き換えることはできません、私たちは必要に応じて怠惰にゴミを収集し、Iceberg がサポートする巨大なテーブルの効率化に役立ちます。 たとえば、特定のプレディカートに一致するテーブル内のすべてのレコードを削除できます。 DELETE FROM my_catalog.my_table WHERE category = 'video'; 代わりに、CREATE TABLE AS SELECT または REPLACE TABLE AS SELECT を使用して、次のことを行うことができます。 CREATE TABLE my_catalog.my_table_music AS SELECT * FROM my_catalog.my_table WHERE category = 'music'; 2つのテーブルを簡単に組み合わせることができます。 MERGE INTO my_catalog.my_data pt USING (SELECT * FROM my_catalog.my_data_new) st ON pt.id = st.id WHEN NOT MATCHED THEN INSERT *; データエンジニア Iceberg はオープンな分析テーブルの基盤であり、SQL 行動を使用し、データストアの基礎を適用して問題を解決する前に、私たちはそれを知っていることを知っています。 宣言データエンジニアリングでは、テーブルを構成し、データのニーズに合わせて各エンジンを変更することを心配しないでください。 これは自動的な最適化と推奨を解除します。 安全なコミットで、データサービスは可能であり、これは人間がデータのワークロードを避けるのに役立ちます。 テーブルの履歴、スナップショット、およびその他のメタデータを確認するには、Iceberg はクエリメタデータをサポートします。 テーブルのデータファイルを表示するには: SELECT * FROM my_catalog.my_table.files; Manifestoを表示する: SELECT * FROM my_catalog.my_table.manifests; テーブルの歴史を表示する SELECT * FROM my_catalog.my_table.history; スナップショットを表示 SELECT * FROM my_catalog.my_table.snapshots; また、スナップショットやテーブル履歴に加わって、それぞれのスナップショットを書いたアプリケーションを見ることができます。 select h.made_current_at, s.operation, h.snapshot_id, h.is_current_ancestor, s.summary['spark.app.id'] from my_catalog.my_table.history h join my_catalog.my_table.snapshots s on h.snapshot_id = s.snapshot_id order by made_current_at; あなたが基本を学んだ後、あなたのデータの一部をIcebergにアップロードし、それからより多くのことを学びましょう。 . Icebergドキュメンタリー 統合 さまざまなクエリおよび実行エンジンがIcebergコネクタを導入し、Icebergテーブルの作成と管理を容易にします。 で、 で、 で、 で、 で、 そして、リストは増えています。 スパーク 素晴らしい 早速 トリノ ドリーム 雪だるま この幅広い統合環境により、組織は単一の処理エンジンに制限されずにApache Icebergを採用できるようになり、柔軟性と あなたのデータインフラに 相互運用性 相互運用性 カタログ Iceberg カタログはテーブルメタデータを管理し、データセットとクエリエンジン間の接続を容易にするために中心的なものです。これらのカタログは、テーブルスケジュール、スナップショット、およびパーティションレイアウトなどの重要な情報を保持し、Icebergのタイムトラベル、スケジュールの進化、および原子の更新などの高度な機能を可能にします。いくつかのカタログの実装は、さまざまなオペレーティングニーズを満たすために利用可能です。例えば、Polarisは、現代のデータインフラストラクチャに適したスケーラブルでクラウドネイティブなカタログソリューションを提供し、Dremio NessieはGitのようなセマンティク IcebergとAIStorでデータ湖を構築するのがカッコいい。 Apache Icebergは、データ湖のテーブル形式として多くの注目を集めています。拡大するオープンソースコミュニティと、複数のクラウドプロバイダーやアプリケーションフレームワークからの統合の増加により、Icebergを真剣に考え、実験し、学習し、既存のデータ湖アーキテクチャに統合する計画を始めました。 Iceberg および AIStor を始めるときは、ご自身の経験を共有したり、質問したりして下さい。 . Slackチャンネル