ベストプラクティス

このトピックでは、Snowflakeで Apache Iceberg™ テーブルを操作するためのベストプラクティスを提供します。

ユースケースに十分な外部ボリュームを作成する

各外部ボリュームは特定の アクティブなストレージの場所 に関連付けられており、1つの外部ボリュームで複数のIcebergテーブルをサポートできます。しかし、必要な外部ボリュームの数は、テーブルデータをどのように保存、整理、保護するかによって異なります。

Snowflake-Icebergテーブルの すべての データとメタデータを同じストレージ場所（たとえば、同じS3バケット）のサブディレクトリに格納したい場合は、単一の外部ボリュームを使用できます。Snowflakeが管理するテーブル用にこれらのディレクトリを設定するには、 データとメタデータのディレクトリ を参照してください。

あるいは、複数の外部ボリュームを作成し、さまざまなストレージ場所を異なる方法で保護することもできます。例えば、以下のような外部ボリュームを作成します。

  • 外部で管理されるIcebergテーブル用の読み取り専用外部ボリューム。

  • Snowflakeで管理されたテーブルの読み取り/書き込みアクセスが設定された外部ボリューム。

外部管理テーブルを頻繁にリフレッシュする

長いリフレッシュ時間を防ぎ、最新のテーブルデータをすばやく取得するには、外部カタログを使用するIcebergテーブルで頻繁にリフレッシュを実行します。

Snowflakeは、操作に時間がかかると予想される場合、テーブルリフレッシュの最適化を試みます。しかし、リフレッシュ時間は、最終的にはテーブルに関連するスナップショットの数と、テーブルに属するデータファイルの数に依存します。

Snowflakeのリフレッシュスケジュールを、スナップショットの期限切れやコンパクションなどのテーブルのメンテナンス操作に合わせることも重要です。メンテナンス作業を行うたびにメタデータをリフレッシュします。

手順については、 テーブルのメタデータをリフレッシュする をご参照ください。

完全な統計を書く

Snowflakeで管理されていないテーブルのクエリランタイムパフォーマンスを最適化するには、Parquetファイルの統計情報が可能な限り完全であることを確認してください。

使用するParquetファイルライター（SparkやTrinoなど）が統計情報を書き込むように設定されていることを確認してください。また、ライターを最新バージョンにアップデートする必要があるかもしれません。

以下のような統計情報の欠落は、クエリのパフォーマンスを低下させます。

  • 最小値と最大値。

  • 個別の値の数（NDV）。個別の値の数は、複雑な結合で結合順序を決定するために使用されます。NDV 統計が欠落していると、結合爆発につながる可能性があります。

  • NULL カウントの数。

ウェアハウスサイズを拡大する

外部カタログを使用するIcebergテーブルを作成すると、Snowflakeはテーブルマニフェストファイルから統計情報を読み取り、高速なパフォーマンスを提供しようとします。

マニフェストファイルに統計情報がない場合や不正確な場合など、状況によっては、Snowflakeはテーブルデータファイルをスキャンして統計情報を取得します。大量のデータファイルをスキャンすると、テーブルの作成が遅くなることがあります。テーブル作成プロセスを高速化するには、テーブルファイルを並行してスキャンできる大規模なウェアハウスを使用します。

注釈

Snowflakeはテーブルの列スキャンを並列化しません。より大きなウェアハウスに切り替えても、クエリのランタイムが速くなるわけではありません。

ユースケースに適したストレージシリアライゼーションポリシーを選択する

ユースケースに応じて適切な STORAGE_SERIALIZATION_POLICY を選択します。Snowflake管理テーブルを作成する（またはSnowflakeをカタログとして使用するようにテーブルを変換する）ときに、そのテーブルのストレージシリアライゼーションポリシーを設定します。シリアライゼーションポリシーは、テーブルデータファイルに対してどのようなエンコーディングと圧縮を行うかをSnowflakeに指示します。

不適切なポリシーは、テーブルを外部エンジンと互換性のないものにしたり、Snowflakeのパフォーマンス低下を引き起こす可能性があります。

詳細については、 CREATE ICEBERG TABLE （IcebergカタログとしてのSnowflake） をご参照ください。

言語: 日本語