外部テーブルの概要¶

*外部テーブル*は、外部ステージに格納されているデータを、あたかもSnowflakeのテーブル内にあるかのようにクエリするために使用できるSnowflakeの機能です。外部ステージはSnowflakeの一部ではないため、Snowflakeがステージを格納したり、管理したりすることはありません。セキュリティ体制を強化するには、プライベート接続を使用して外部テーブルにアクセスするために、外部ステージを:doc:` アウトバウンドプライベート接続 </user-guide/private-connectivity-outbound>` 用に構成します。

外部テーブルを使用すると、ファイル名、バージョン識別子、および関連プロパティを含む特定のファイルレベルのメタデータを（Snowflake内に）格納できます。外部テーブルは、COPY INTO <テーブル> コマンドがサポートする、XML 以外の形式で格納されたデータにアクセスできます。

外部テーブルは読み取り専用です。外部テーブルに対してデータ操作言語（DML）の操作は実行できません。ただし、クエリや結合操作に外部テーブルを使用することはできます。また、外部テーブルに対するビューも作成できます。

外部テーブルのデータをクエリすると、Snowflake内のテーブルにネイティブで格納したデータをクエリするよりも遅くなる場合があります。クエリのパフォーマンスを向上させるために、外部テーブルを基にしたマテリアライズドビューを使用することができます。Parquetファイルを使用する場合、クエリのパフォーマンスを最適化するには、代わりに Apache Iceberg™ テーブルの使用を検討してください。

注釈

クエリ操作中にクラウドストレージ内のファイルをスキャンしているときにSnowflakeでエラーが発生した場合、ファイルはスキップされ、スキャンは次のファイルで続行されます。クエリはファイルを部分的にスキャンし、エラーが発生する前にスキャンされた行を返すことができます。

このトピックの内容:

外部テーブルのスキーマの計画¶

次のセクションでは、外部テーブルを計画するために使用できるオプションについて説明します。

読み取り時のスキーマ¶

すべての外部テーブルには次の列が含まれます。

VALUE:: 外部ファイルの単一の行を表す VARIANT 型の列。
METADATA$FILENAME:: 外部テーブルに含まれるステージングされた各データファイルの名前を識別する疑似列。ステージ内のパスも含まれます。
METADATA$FILE_ROW_NUMBER:: ステージングされたデータファイルの各記録の行番号を表示する疑似列。

外部テーブルを作成するには、ソースデータファイルのファイル形式とレコード形式に関する知識が必要です。データファイルのスキーマを知る必要はありません。

注釈

SELECT * は常にVALUE列を返します。この列では、すべての通常または半構造化データがバリアント行にキャストされます。

仮想列¶

ソースデータファイルのスキーマに精通している場合は、VALUE 列と METADATA$FILENAME または METADATA$FILE_ROW_NUMBER 疑似列を使用して、式として追加の仮想列を作成できます。外部データをスキャンする場合、データファイル内の指定されたフィールドまたは半構造化データ要素のデータ型は、外部テーブル内のこれらの追加列のデータ型と一致する必要があります。この要件により、外部データに対する強力な型チェックとスキーマ検証が可能になります。

一般的なファイルサイズの推奨事項¶

外部テーブルをクエリするときの並列スキャン操作の数を最適化するには、フォーマットごとに次のファイルまたは行グループのサイズをお勧めします。

形式	推奨サイズ範囲	注意
Parquetファイル	256 - 512 MB
Parquet列グループ	16 - 256 MB	Parquetファイルに複数の行グループが含まれている場合、Snowflakeは異なるサーバーの各行グループで動作できます。クエリのパフォーマンスを向上させるために、Parquetファイルのサイズを推奨範囲内にすることをお勧めします。または、大きなファイルサイズが必要な場合には、各ファイルに複数の行グループを含めます。
サポートされている他のすべてのファイル形式	16 - 256 MB

大きなデータファイルをクエリするときに最適なパフォーマンスを得るには、外部テーブルに対してマテリアライズドビューを作成してクエリします。

パーティション化された外部テーブル¶

外部テーブルをパーティション化することを強くお勧めします。これには、パスに日付、時刻、国、または同様のディメンションを含む論理パスを使用して基礎データを編成する必要があります。パーティション化は、パーティション列を使用して外部テーブルデータを複数の部分に分割します。

外部テーブルの定義には、外部データに多次元構造を課す複数のパーティション列を含めることができます。パーティションは外部テーブルのメタデータに保存されます。

パーティション化によりクエリのパフォーマンスが改善します。外部データは個別のスライスまたはパーツに分割されるため、データセット全体をスキャンする代わりにデータのごく一部を処理する場合、クエリの応答時間が速くなります。

個々の使用ケースに応じて、以下のいずれかを行うことができます。

各パーティション列の式を定義する外部テーブルを更新することにより、新しいパーティションを自動的に追加します。
新しいパーティションを手動で追加します。

パーティション列は、 CREATE EXTERNAL TABLE ... PARTITION BY 構文を使用して、外部テーブルが作成されるときに定義されます。外部テーブルの作成後は、パーティションの追加メソッドを変更することはできません。

次のセクションでは、パーティションを追加するためのさまざまなオプションについて詳しく説明します。例については、 CREATE EXTERNAL TABLE をご参照ください。

自動的に追加されたパーティション¶

外部テーブル作成者は、新しい外部テーブルのパーティション列を、METADATA$FILENAME 疑似列に保存されているパスまたはファイル名情報を解析する式として定義します。パーティションは、パーティション列の式のパスまたはファイル名に一致するすべてのデータファイルで構成されます。

次の CREATEEXTERNALTABLE 構文は、式に基づいてパーティションを自動的に追加します。

CREATE EXTERNAL TABLE
  <table_name>
     ( <part_col_name> <col_type> AS <part_expr> )
     [ , ... ]
  [ PARTITION BY ( <part_col_name> [, <part_col_name> ... ] ) ]
  ..

Copy

Snowflakeは、外部テーブルのメタデータが更新されるときに、定義されたパーティション列の式に基づいてパーティションを計算して追加します。デフォルトでは、メタデータはオブジェクトの作成時に自動的に更新されます。さらに、オブジェクトの所有者は、新しいデータファイルまたは更新されたデータファイルが外部ステージで利用可能になったときに、自動的に更新されるようにメタデータを構成できます。または、所有者は ALTER EXTERNAL TABLE ... REFRESH コマンドを実行して、メタデータを手動で更新できます。

手動で追加されたパーティション¶

外部テーブル作成者は、新しい外部テーブルのパーティション型を ユーザー定義 として決定し、パーティション列のデータ型のみを指定します。式に一致する外部ストレージの場所にあるすべての新しいファイルのパーティションを自動的に追加するのではなく、パーティションを選択的に追加および削除する場合は、このオプションを使用します。

通常、このオプションは、外部テーブルを他のメタストア（AWS Glueや Apache Hive など）と同期する場合に選択します。

次 CREATEEXTERNALTABLE 構文は、パーティションを手動で追加します。

CREATE EXTERNAL TABLE
  <table_name>
     ( <part_col_name> <col_type> AS <part_expr> )
     [ , ... ]
  [ PARTITION BY ( <part_col_name> [, <part_col_name> ... ] ) ]
  PARTITION_TYPE = USER_SPECIFIED
  ..

Copy

必要な PARTITION_TYPE = USER_SPECIFIED パラメーターを含めます。

パーティション列の定義は、内部（非表示） METADATA$EXTERNAL_TABLE_PARTITION 列の列メタデータを解析する式です。

オブジェクトの所有者は、ALTER EXTERNAL TABLE ... ADD PARTITION コマンドを実行して、外部テーブルのメタデータにパーティションを手動で追加します。

ALTER EXTERNAL TABLE <name> ADD PARTITION ( <part_col_name> = '<string>' [ , <part_col_name> = '<string>' ] ) LOCATION '<path>'

Copy

ユーザー定義のパーティションを使用して外部テーブルを自動的に更新することはサポートされていません。この型の外部テーブルを手動で更新しようとすると、ユーザーエラーが発生します。

Delta Lakeサポート¶

注釈

この機能はまだサポートされていますが、将来のリリースでは非推奨となります。

代わりに Apache Iceberg™テーブルの使用をご検討ください。Icebergテーブルは、外部ボリュームを使用して、クラウドストレージ内のデルタテーブルファイルに接続します。

詳細については、 Icebergテーブルと CREATE ICEBERG TABLE （オブジェクトストレージ内のDeltaファイル）を参照してください。また、デルタ外部テーブルを Apache Iceberg™ に移行するも可能です。

Delta Lake は、データレイク上のテーブル形式であり、他の機能の中でも ACID （アトミック性、一貫性、分離性、耐久性）トランザクションをサポートします。Delta Lakeのすべてのデータは、Apache Parquet形式で保存されます。Delta Lakeで拡張されたクラウドストレージの場所を参照する外部テーブルを作成できます。

Delta Lakeを参照する外部テーブルを作成するには、 CREATE EXTERNAL TABLE ステートメントで TABLE_FORMAT = DELTA パラメーターを設定します。

このパラメーターを設定すると、外部テーブルは、[ WITH ] LOCATION の場所にあるDelta Lakeトランザクションログファイルをスキャンします。Deltaログファイルの名前は _delta_log/00000000000000000000.json や _delta_log/00000000000000000010.checkpoint.parquet などです。外部テーブルのメタデータが更新されると、SnowflakeはDelta Lakeトランザクションログを解析し、現在のParquetファイルを判別します。バックグラウンドで、更新はファイルの追加と削除の操作を実行して、外部テーブルのメタデータの同期を維持します。

例などの詳細については、 CREATE EXTERNAL TABLE をご参照ください。

注釈

Delta Lakeファイルを参照する外部テーブルは、削除ベクターをサポートしていません。
クラウドストレージでのデータ定義言語（DDL）操作によってトリガーされるイベント通知の順序は保証されていないため、この機能では自動リフレッシュはサポートされていません。追加または削除されたファイルを登録するには、定期的に ALTER EXTERNAL TABLE ... REFRESH ステートメントを実行します。

デルタ外部テーブルを Apache Iceberg™ に移行する¶

Delta Lakeを参照する1つ以上の外部テーブルを Apache Iceberg™ テーブルに移行するには、以下の手順を実行します。

SHOW EXTERNAL TABLES コマンドを使用して、外部テーブルの location （外部ステージとフォルダーパス）を取得します。

例えば、次のコマンドは外部テーブルの情報を返し、 my_delta_ext_table のような名前でフィルタリングします。
```
SHOW EXTERNAL TABLES LIKE 'my_delta_ext_table';
```
Copy
外部ボリュームを作成します。前の手順で取得した場所を STORAGE_BASE_URL に指定します。

複数のデルタテーブル用の単一の外部ボリュームを同じストレージ場所に作成するには、外部ボリュームのアクティブ場所（STORAGE_BASE_URL）を共通のルートディレクトリに設定します。

例えば、同じストレージ場所から分岐する3つのデルタテーブルの次の場所を考えてみましょう。
- s3://my-bucket/delta-ext-table-1/
- s3://my-bucket/delta-ext-table-2/
- s3://my-bucket/delta-ext-table-3/
次の例に示すように、外部ボリュームを作成する際に STORAGE_BASE_URL としてバケットを指定します。後で、Icebergテーブルを作成するときに、テーブルファイルへの相対パス（例: delta-ext-table-1/）を BASE_LOCATION に指定できます。
```
CREATE OR REPLACE EXTERNAL VOLUME delta_migration_ext_vol
STORAGE_LOCATIONS = (
  (
    NAME = storage_location_1
    STORAGE_PROVIDER = 'S3'
    STORAGE_BASE_URL = 's3://my-bucket/'
    STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789123:role/my-storage-role' )
);
```
Copy
デルタテーブルのカタログ統合を作成します。
CREATE ICEBERG TABLE （オブジェクトストレージ内のDeltaファイル）コマンドを使用してIcebergテーブルを作成します。外部ボリュームの BASE_LOCATION は、既存の外部テーブルの場所を指していなければなりません。

次の例では、s3://my-bucket/delta-ext-table-1/ にある外部テーブルファイルに基づいてIcebergテーブルを作成し、以前に作成した外部ボリュームを参照します。テーブルの完全なストレージ場所を決定するために、Snowflakeは外部ボリュームの STORAGE_BASE_URL に BASE_LOCATION を追加します。
```
CREATE ICEBERG TABLE my_delta_table_1
  BASE_LOCATION = 'delta-ext-table-1'
  EXTERNAL_VOLUME = 'delta_migration_ext_vol'
  CATALOG = 'delta_catalog_integration';
```
Copy

外部テーブルを削除:

DROP EXTERNAL TABLE my_delta_ext_table_1;

Copy

列を追加または削除します¶

既存の外部テーブルを変更して列を追加または削除するには、次の ALTER TABLE 構文を使用します。

列の追加： ALTER TABLE ... ADD COLUMN
列の削除： ALTER TABLE ... DROP COLUMN

注釈

デフォルトの VALUE 列と METADATA$FILENAME および METADATA$FILE_ROW_NUMBER 疑似列は削除できません。

詳細については、ALTER TABLE の例をご参照ください。

外部テーブルの保護¶

マスキングポリシーと行アクセスポリシーを使用して外部テーブルを保護できます。詳細については、次のトピックをご参照ください。

外部テーブルのマテリアライズドビュー¶

多くの場合、外部テーブルに対するマテリアライズドビューは、基礎となる外部テーブルに対する同等のクエリよりも高速なパフォーマンスを提供できます。クエリを頻繁に実行する場合、またはクエリが非常に複雑な場合は、マテリアライズドビュの方が大幅に高速になる可能性があります。

クエリされた外部テーブルのファイルレベルのメタデータを更新して、マテリアライズドビューに参照先のクラウドストレージの場所にある現在のファイルのセットが反映されるようにします。

外部テーブルのメタデータは、クラウドストレージサービスのイベント通知サービスを使用して自動で、または ALTER EXTERNAL TABLE ... REFRESH を使用して手動で更新できます。

外部テーブルのメタデータの自動更新¶

クラウドストレージサービスのイベント通知サービスを使用すると、外部テーブルのメタデータを自動的に更新できます。

リフレッシュ操作は、メタデータを外部ステージとパスにある関連ファイルの最新セットと同期させます。

パス内の新しいファイルがテーブルメタデータに追加されます。

パス内のファイルへの変更は、テーブルメタデータで更新されます。

パス内になくなったファイルは、テーブルのメタデータから削除されます。

詳細については、外部テーブルを自動的に更新するをご参照ください。

外部テーブルの請求¶

Snowflakeでは、外部テーブルメタデータの自動更新に関するイベント通知を管理するためのオーバーヘッドは料金に含まれています。このオーバーヘッドは、外部テーブルに指定された外部ステージとパスのクラウドストレージに追加されるファイルの数に関連して増加します。Snowpipeは外部テーブルの自動更新のイベント通知に使用されるため、このオーバーヘッド料金は請求明細書にSnowpipe料金として表示されます。この料金は、 PIPE_USAGE_HISTORY 関数をクエリするか、Account Usage PIPE_USAGE_HISTORY ビューを調べると見積もることができます。

さらに、Snowflakeでは、外部テーブルのメタデータを手動で更新する場合（ALTER EXTERNAL TABLE ... REFRESH を使用）、少額のメンテナンスオーバーヘッド料金が発生します。このオーバーヘッドは、Snowflakeにおける他の類似のアクティビティすべてと同様に、標準のクラウドサービス課金モデルに従って課金されます。標準の外部テーブルの手動更新は、クラウドサービスの操作のみです。ただし、Delta Lakeで拡張された外部テーブルの手動更新は、ユーザー管理のコンピューティングリソース（つまり、仮想ウェアハウス）に依存しています。

ACCOUNTADMIN ロールを持つユーザー、または MONITOR USAGE グローバル権限を持つロールは、AUTO_REFRESH_REGISTRATION_HISTORY テーブル関数にクエリを実行して、指定されたオブジェクトのメタデータに登録されているデータファイルの履歴と、これらの操作に対して請求されるクレジットを取得できます。

セットアップとロードのワークフローの概要¶

注釈

外部テーブルはストレージのバージョン管理（S3のバージョン管理、Google Cloud Storageのオブジェクトバージョン管理、Azure Storageのバージョン管理）をサポートしていません。

Amazon S3ワークフロー¶

次の手順では、Amazon S3ステージを参照する外部テーブルのセットアップおよびロードワークフローの概要を説明します。完全な手順については、Amazon S3の外部テーブルを自動的に更新するをご参照ください。

データファイルがステージングされる外部の場所（つまり、S3バケット）を参照する、名前付きステージオブジェクトを（CREATE STAGE を使用して）作成します。
名前付きステージを参照する外部テーブルを作成します（CREATE EXTERNAL TABLE を使用）。
ALTER EXTERNAL TABLE ... REFRESH を使用して、外部テーブルのメタデータを手動で更新し、メタデータをステージパス内のファイルの現在のリストと同期します。このステップでは、外部テーブル定義の設定も確認します。
S3バケットのイベント通知を構成します。Snowflakeは、イベント通知に依存して外部テーブルメタデータを継続的に更新し、ステージングされたファイルとの一貫性を維持します。
ALTER EXTERNAL TABLE ... REFRESH を使用して、外部テーブルメタデータを手動でもう一度更新し、ステップ3以降に発生した変更とメタデータを同期します。その後、S3イベント通知はメタデータの更新を自動的にトリガーします。
追加のロールにSnowflakeアクセス制御権限を設定して、外部テーブルへのクエリアクセスを付与します。

Google Cloud Storageワークフロー¶

次の手順では、Google Cloud Storage（GCS）ステージを参照する外部テーブルのセットアップおよびロードワークフローの概要を説明します。

GCS イベントのGooglePub/Subサブスクリプションを構成します。
Snowflakeで通知統合を作成します。通知統合は、SnowflakeとPub/Subなどサードパーティのクラウドメッセージキューサービス間におけるインターフェイスを提供する、Snowflakeオブジェクトです。
データファイルがステージングされる外部の場所（つまり、GCS バケット）を参照する、名前付きステージオブジェクトを（CREATE STAGE を使用して）作成します。
名前付きステージと統合を参照する外部テーブルを作成します（CREATE EXTERNAL TABLE を使用）。
ALTER EXTERNAL TABLE ... REFRESH を使用して、外部テーブルメタデータを手動でもう一度更新し、ステップ4以降に発生した変更とメタデータを同期します。その後、Pub/Sub通知により、メタデータの更新が自動的にトリガーされます。
追加のロールにSnowflakeアクセス制御権限を設定して、外部テーブルへのクエリアクセスを付与します。

Microsoft Azureワークフロー¶

次の手順では、Azureステージを参照する外部テーブルのセットアップおよびロードワークフローの概要を説明します。完全な手順については、Azure Blob Storageの外部テーブルを自動的に更新するをご参照ください。

Azure StorageイベントのEvent Gridサブスクリプションを構成します。
Snowflakeで通知統合を作成します。通知統合は、Snowflakeと、Microsoft Event Gridといった、サードパーティのクラウドメッセージキューサービス間のインターフェイスを提供するSnowflakeオブジェクトです。
データファイルがステージングされる外部の場所（つまり、Azureコンテナー）を参照する、名前付きステージオブジェクトを（CREATE STAGE を使用して）作成します。
名前付きステージと統合を参照する外部テーブルを作成します（CREATE EXTERNAL TABLE を使用）。
ALTER EXTERNAL TABLE ... REFRESH を使用して、外部テーブルメタデータを手動でもう一度更新し、ステップ4以降に発生した変更とメタデータを同期します。その後、Event Grid通知はメタデータの更新を自動的にトリガーします。
追加のロールにSnowflakeアクセス制御権限を設定して、外部テーブルへのクエリアクセスを付与します。

外部テーブルのクエリ¶

標準テーブルと同じように、外部テーブルをクエリします。

Snowflakeは、無効な UTF-8データを含む記録のクエリ結果を省略します。無効なデータに遭遇しても、Snowflakeはエラーメッセージを返さずにファイルのスキャンを続行します。

無効な UTF-8データに起因するクエリ結果の記録欠落を回避するには、ファイル形式に REPLACE_INVALID_CHARACTERS = TRUE を指定してください。そうすることで、テーブルへのクエリの際に、無効な UTF-8文字がUnicode置換文字（�）に置き換えられます。

Parquetファイルの場合、 BINARY_AS_TEXT = FALSE をファイル形式に設定することで、論理データ型が定義されていない列を、Snowflakeが UTF-8テキストではなくバイナリデータとして解釈するようにすることもできます。

Parquetファイルの記録のフィルタリング¶

行グループの統計を利用してParquetファイルのデータを整理するには、WHERE 句にパーティション列、通常の列、またはその両方を含めることができます。次の制限が適用されます。

この句には VARIANT 列を含めることはできません。
句には、次の比較演算子の1つ以上のみを含めることができます。
- =
- >
- <
この句には、1つ以上の論理/ブール演算子、また STARTSWITH SQL 関数のみを含めることができます。

さらに、"value:<path>::<data type>"`（または同等の :doc:/sql-reference/functions/get`/ GET_PATH、 : 関数）形式のクエリは、ベクトル化されたスキャナーを利用します。形式 "value" または単に "value:<path>" のクエリは、ベクトル化されていないスキャナーを使用して処理されます。ベクトル化されたスキャナーを使用するクエリでは、CONVERT_TIMEZONE 関数を使用してすべてのタイムゾーンデータを標準タイムゾーンに変換します。

クエリフィルターに含まれるキーでファイルを並べ替える場合、およびファイルに複数の行グループがある場合は、より適切なプルーニング結果が得られる可能性があります。

次のテーブルは、このセクションの動作を示す同様のクエリ構造を示しています。ここで、et は外部テーブルであり、 c1、 c2、および c3 は仮想列です。

最適化されている	最適化されていない
`SELECT c1, c2, c3 FROM et;`	`SELECT value:c1, c2, c3 FROM et;`
`SELECT c1, c2, c3 FROM et WHERE c1 = 'foo';` `SELECT c1, c2, c3 FROM et WHERE value:c1::string = 'foo';`	`SELECT c1, c2, c3 FROM et WHERE value:c1 = 'foo';`

最適化されている

最適化されていない

SELECT c1, c2, c3 FROM et;

SELECT value:c1, c2, c3 FROM et;

SELECT c1, c2, c3 FROM et WHERE c1 = 'foo';

SELECT c1, c2, c3 FROM et WHERE value:c1::string = 'foo';

SELECT c1, c2, c3 FROM et WHERE value:c1 = 'foo';

永続的なクエリ結果¶

テーブルと同様に、外部テーブルのクエリ結果は、24時間保存されます。この24時間の期間中、次の操作は外部テーブルのクエリ結果キャッシュを無効にしてパージします。

外部テーブル定義を変更する DDL 操作。これには、外部テーブル定義の明示的な変更（ALTER EXTERNAL TABLE を使用）や外部テーブルの再作成（CREATE OR REPLACE EXTERNAL TABLE を使用）が含まれます。
外部テーブルのメタデータに登録されている、クラウドストレージ内のファイルセットの変更。保存場所のイベント通知サービスを使用した自動更新操作、または手動更新操作（ALTER EXTERNAL TABLE ... REFRESH を使用）のいずれかにより、結果キャッシュが無効になります。

注釈

クラウドストレージ内の参照ファイルを変更しても、次の状況ではクエリ結果キャッシュが無効にならず、クエリ結果が古くなります。

自動更新操作がオフになっている（つまり、AUTO_REFRESH = FALSE）か、正しく構成されていません。
外部テーブルのメタデータが手動で更新されていません。

例: 外部テーブルメタデータから古いステージング済みファイルを削除する¶

次の手順は、ALTER EXTERNAL TABLE ... REMOVE FILES ステートメントを使用して、外部テーブルのメタデータから古いステージングされたファイルを削除する方法の例を示しています。ストアドプロシージャは、ステージで最後に変更された日付に基づいてメタデータからファイルを削除します。

CREATE PROCEDURE ステートメントを使用してストアドプロシージャを作成します。

CREATE or replace PROCEDURE remove_old_files(external_table_name varchar, num_days float)
  RETURNS varchar
  LANGUAGE javascript
  EXECUTE AS CALLER
  AS
  $$
  // 1. Get the relative path of the external table
  // 2. Find all files registered before the specified time period
  // 3. Remove the files


  var resultSet1 = snowflake.execute({ sqlText:
    `call exttable_bucket_relative_path('` + EXTERNAL_TABLE_NAME + `');`
  });
  resultSet1.next();
  var relPath = resultSet1.getColumnValue(1);


  var resultSet2 = snowflake.execute({ sqlText:
    `select file_name
     from table(information_schema.EXTERNAL_TABLE_FILES (
         TABLE_NAME => '` + EXTERNAL_TABLE_NAME +`'))
     where last_modified < dateadd(day, -` + NUM_DAYS + `, current_timestamp());`
  });

  var fileNames = [];
  while (resultSet2.next())
  {
    fileNames.push(resultSet2.getColumnValue(1).substring(relPath.length));
  }

  if (fileNames.length == 0)
  {
    return 'nothing to do';
  }


  var alterCommand = `ALTER EXTERNAL TABLE ` + EXTERNAL_TABLE_NAME + ` REMOVE FILES ('` + fileNames.join(`', '`) + `');`;

  var resultSet3 = snowflake.execute({ sqlText: alterCommand });

  var results = [];
  while (resultSet3.next())
  {
    results.push(resultSet3.getColumnValue(1) + ' -> ' + resultSet3.getColumnValue(2));
  }

  return results.length + ' files: \n' + results.join('\n');

  $$;

  CREATE or replace PROCEDURE exttable_bucket_relative_path(external_table_name varchar)
  RETURNS varchar
  LANGUAGE javascript
  EXECUTE AS CALLER
  AS
  $$
  var resultSet = snowflake.execute({ sqlText:
    `show external tables like '` + EXTERNAL_TABLE_NAME + `';`
  });

  resultSet.next();
  var location = resultSet.getColumnValue(10);

  var relPath = location.split('/').slice(3).join('/');
  return relPath.endsWith("/") ? relPath : relPath + "/";

  $$;

Copy

ストアドプロシージャを呼び出します。
```
-- Remove all files from the exttable external table metadata:
call remove_old_files('exttable', 0);

-- Remove files staged longer than 90 days ago from the exttable external table metadata:
call remove_old_files('exttable', 90);
```
Copy
または、CREATE TASK を使用してタスクを作成し、ストアドプロシージャを定期的に呼び出して、外部テーブルのメタデータから古いファイルを削除することもできます。

Apache Hiveメタストアの統合¶

Snowflakeは、外部テーブルを使用して Apache Hive メタストアとSnowflakeの統合をサポートしています。Hiveコネクタは、メタストアイベントを検出し、それらのイベントをSnowflakeに送信して、外部テーブルとHiveメタストアの同期を維持します。この機能により、ユーザーはHiveでデータを管理しながら、Snowflakeからそのデータをクエリすることができます。

手順については、 Apache HiveメタストアとSnowflakeの統合をご参照ください。

外部テーブル DDL¶

外部テーブルの作成と管理をサポートするために、Snowflakeは次の一連の特別な DDL コマンドを提供します：

必要なアクセス権限¶

外部テーブルを作成および管理するには、少なくとも次のロール権限を持つロールが必要です。

オブジェクト	権限
データベース	USAGE
スキーマ	USAGE、 CREATE STAGE （新しいステージを作成する場合）、 CREATE EXTERNAL TABLE
ステージ（既存のステージを使用する場合）	USAGE

Information Schema¶

Snowflake Information Schema には、外部テーブルとそのステージングされたデータファイルの情報を取得するためにクエリできるビューとテーブル関数が含まれています。

ビュー¶

EXTERNAL_TABLES ビュー: 指定された（または現在の）データベース内の外部テーブルの情報を表示します。

テーブル関数¶

AUTO_REFRESH_REGISTRATION_HISTORY: 指定されたオブジェクトのメタデータに登録されているデータファイルの履歴と、これらの操作に対して請求されるクレジットを取得します。
EXTERNAL_TABLE_FILES: 指定された外部テーブルのメタデータに含まれるステージングされたデータファイルに関する情報を取得します。
EXTERNAL_TABLE_FILE_REGISTRATION_HISTORY: メタデータの更新時に見つかったエラーを含む、外部テーブルのメタデータ履歴に関する情報を取得します。