株式会社primeNumberPublicationへの投稿
🏂

Snowflake Summit 2025 Day4 レポート:Apache Polaris on Snowflake

Takaki Ihara
に公開
Snowflake
iceberg
Snowflake Summit
Polaris Catalog
idea

はじめに

お世話になっております。primeNumberの庵原です！
この記事ではSnowflake Summit 2025のDay4でのセッション"STREAMLINING CROSS-ENGINE GOVERNANCE FOR APACHE ICEBERG TABLES"で発表された内容や様子について現地で見たもの聞いたものを速報形式でまとめてお送りいたします！

セッション概要

  • 名前: STREAMLINING CROSS-ENGINE GOVERNANCE FOR APACHE ICEBERG TABLES（Streamingの直接的な話がなかった...）
  • 概要説明: As data lakes grow, seamless access and strong governance are crucial. However, governance for Apache Iceberg to-date has often ended up fragmented, forming inconsistencies and complex integrations. Apache Polaris simplifies governance for multi-engine architectures with a unified access control layer that integrates with Apache Spark, Trino, Snowflake and more. Join this session to learn more about how Polaris makes this possible along with demos, updates and ways to join the community.（データレイクが拡大するにつれ、シームレスなアクセスと強力なガバナンスが不可欠です。しかし、Apache Icebergのガバナンスはこれまで断片化され、不一致や複雑な統合を引き起こすことが多くありました。Apache Polarisは、Apache Spark、Trino、Snowflakeなどとの統合を可能にする統一されたアクセス制御レイヤーにより、マルチエンジンアーキテクチャのガバナンスを簡素化します。このセッションに参加し、Polarisがこれを実現する仕組み、デモ、最新情報、コミュニティへの参加方法について学びましょう。）(デモもなかった...)

課題点

ここのセッションで議題に上がっていた課題点として、まず複数のQuery Engine, Catalog&Metadata, Storageを複数運用する際のガバナンス、特にアクセス制御がエンジンやツールごとに断片化されサイロ化している点が挙げられていました。

  • ガバナンスの重複: 標準がないため、ユーザーはエンジンごとにアクセスコントロールリスト（ACL）を個別に設定・管理する必要があり、ガバナンスの取り組みが重複してしまいます。
  • 限定的な制御: 特に各カタログごとでのきめ細かい（Fine-grained）アクセス制御の実装が限られており、十分なセキュリティレベルを担保することが難しい場合がある。
  • 一貫性のない読み書きサポート: 各コンポーネントの組み合わせによって、読み書きのサポート状況が異なり、期待通りに連携できないケースが多く存在してしまっている。
  • 手動スクリプトへの依存: データの圧縮（Compaction）や不要ファイルの削除といったメンテナンス作業が、手動のスクリプトやその場しのぎのガバナンスに依存している状態になってしまっている。
  • 一貫性のないポリシー: チームやエンジンごとにデータやメタデータの保持ポリシーが異なると、意図しないデータの肥大化やパフォーマンスの低下、あるいは必要なデータが消えてしまうといった問題を引き起こす可能性がある。
  • 統一された標準の欠如: 複数のエンジン間で、アクセス制御がどのように機能すべきかという業界標準が通常の場合は存在し得ない。これにより、エンジンごとにセマンティクス（意味や解釈）が異なり、一貫した制御が困難になって行く可能性がある。

Apache Polarisについて

これに対する解決策として、SnowflakeがOSSコミュニティに対しても大きな貢献をしているApache Polarisが紹介されています。
これは機能豊富なカタログで、IcebergなどのREST APIを実装しており、Apache SparkやSnowflakeを含む多様なプラットフォーム間でシームレスなマルチエンジン相互運用性を実現します。

特徴として挙げられていた点として、以下があります。

  • 複数のエンジンで読み書きが可能
    • Snowflake、Spark、Trinoなどなど
  • ロールベースのアクセス制御が複数のエンジンと互換性あり
    • 要は異なるクエリエンジンからアクセスされてもアクセス制御が統一的に設定できるということ
  • 複数のフォーマットに対応したカタログ: Iceberg、Delta
  • 複数のカタログとの統合

今日のPolarisのRBACモデルについて

Polaris Catalogはカタログに特化したOSSですが、エンタープライズ利用を念頭に独自のRBACモデルを最初から設計に組み込んでいます。SnowflakeのRBAC設計思想を踏襲しつつ、OSSカタログとしては珍しく「カタログそのものが認可の中心」になるよう作られているのが特徴です。

そんなPolaris CatalogのRBACモデルは以下のように紹介されていました。

Polarisが現在提供しているRBACモデルは、カタログ (Catalog) > 名前空間 (Namespace) > テーブル (Table) という階層的なオブジェクトに対して、ロール（役割）ベースで権限を管理する仕組みです。

スライドにある通り、「Catalog Admin」「Data Admin」「Catalog Reader」といったロールが示されており、これらのロールにデータの読み書きやオブジェクトの一覧表示などの権限が割り当てられます。これにより、ユーザーやサービスは、特定のカタログ内のロールに割り当てられ、そのロールが持つ権限の範囲で操作を行うことができます。

権限を付与される対象は、人間のユーザー（例: Alice）だけでなく、ETL/ストリーミングエンジンのようなサービスや、AI/MLアプリケーションなども含まれます。

また一時的な認証情報の発行の機能があり、テーブルレベルでスコープ（範囲）を限定した、一時的な認証情報を発行する機能を持っています。これにより、クライアントは永続的なストレージ認証情報を持つ必要がなくなり、セキュリティ向上が期待できます。

新しい拡張ポリシーストアについて

Polaris CatalogではPolicyという単位でのルール定義を作成し、保存しておくことができます。このルールは特定のリソースに対して特定の条件下で誰が特定のアクションを実行できるかを定義したものです。

例えば、スライドにある事前定義されているポリシー（Predefined Policies）は以下のようなものがあります。

  • データ圧縮 (Data Compaction): 小さなファイルをマージして、クエリパフォーマンスを向上させる。
  • メタデータ圧縮 (Metadata Compaction): Icebergのメタデータファイル（Manifestファイルなど）を圧縮する。
  • 孤立ファイル（Orphan File）の削除: どのスナップショットからも参照されなくなった不要なデータファイルを削除する。
  • スナップショットの有効期限切れ (Snapshot Expiration): 古いテーブルのスナップショットを自動的に削除し、メタデータが肥大化するのを防ぐ。

また実はこの機能自体も新しく、セッション内では「NEW: Table Maintenance Service (TMS) Policies」という部分で紹介されていました。

また、後から作成可能なカスタムポリシーを設定することも可能です。

  • データマスキング (Data Masking): custom.<org_name>.data_maskingのように、特定のデータをマスキング（*****などで隠す）するための組織独自のポリシーを作成できる。
  • 監査ポリシー (Audit Policy): custom.<user_id>.audit_policy のように、特定の操作を監査・記録するためのポリシーを作成できる。

その上で新機能として以下の2つの機能が紹介されました。



このうち左のPluggable Policy Typesは先ほど説明した事前定義やカスタムのポリシーの組み合わせを柔軟に行える機能です。

Versioned Definitionsについては以下のスライドがわかりやすいです。

ポリシーの「構造（スキーマ）」そのものを、既存のシステムを壊すことなく安全に変更・更新していくための仕組みです。

例えば、当初 system.compaction ポリシーのルールが「有効/無効」の2つだけだったとします。後からコミュニティで「圧縮するファイルの閾値」という新しいルールを追加したくなった場合、この仕組みがあれば、古いルールを使っている既存のユーザーに影響を与えずに、新しいバージョンのルールを導入できます。

これにより以下のメリットを享受できます。

  • 後方互換性の確保: ポリシーの定義（スキーマ）が変更されても、古いバージョンのスキーマに依存している既存のシステムやポリシーが機能しなくなるのを防げる。
  • 安全な更新とロールバック: 新しいバージョンのスキーマを管理された方法で導入でき、問題があればロールバック（切り戻し）も可能になる。

ポリシーの具体的な設定方法について

ポリシーの設定方法については現在2つの方法が取れるようです。

REST API

以下はポリシーの作成と付与の例です。

# Command 1: Create Policy
curl -X POST -H "Authorization: Bearer myToken" \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json' \
http://POLARIS_HOST:8181/polaris/v1/catalogl/namespaces/ns1/policies \
    -d '(
        "name": "policyl",
        "type": "system.data-compaction"
    )'

# Command 2: Attach Policy
curl -X PUT -H "Authorization: Bearer myToken" \
    -H 'Accept: application/json' \
    -H 'Content-Type: application/json'
    http://POLARIS_HOST:8181/polaris/vl/catalogl/name
    -d'(
        "target": (
            "type":"table-like",
            "path": [
                "NS1" ,
                "test_table_1"
            ]
        )
    )'

Python CLI

以下も同様にポリシーの作成と付与の例です。

# Command 1: Create Policy
polaris policies create cl.ns policyl --type system.data_compaction --content ' ("enable": true}'
# Command 2: Attach Policy
polaris policies attach --policy cl.nsl.policyl --table cl.ns2.t1
# Command 3: Detach Policy
polaris policies detach --policy cl.nsl.policyl --table cl.ns2.t1

まとめ

いかがでしたでしょうか？

Apache Polarisの挑戦は、これまでの性善説的な考え方に基づいたデータアクセスから、厳格なルールに基づいた「ゼロトラスト」的なデータガバナンスへの移行を、オープンな世界で実現しようとするものだと感じました。特に、RBACとPolicy Storeの明確な役割分担は、多くの企業のデータガバナンス設計において素晴らしい参考になるはずです。今後も動向を注目しつつ、実際に導入して触れる日が来ると良いなと感じます。

株式会社primeNumber
株式会社primeNumberPublication

「あらゆるデータを、ビジネスの力に変える」データテクノロジーカンパニー。クラウドETL「TROCCO」やクラウド データカタログ「COMETA」、データテクノロジー領域の課題解決を実現するプロフェッショナルサービスを提供しています。

Discussion