データパイプラインのマルチロケーションレジリエンス

データパイプラインのマルチロケーションレジリエンスにより、地域全体のクラウドプロバイダーが停止するリスクからデータパイプラインを保護できます。この機能により、セカンダリの場所にフェールオーバーすると、データパイプライン（特にSnowpipeとCOPYINTO）は、中断したり、インジェスションを重複して実行したりすることなく、新しいデータのロードを再開します。

この機能はクロスクラウドで動作し、プライマリおよびバックアップのストレージの場所をまったく異なるクラウドプロバイダー（たとえばAWSからAzureへのフェールオーバーなど）や、同じクラウド内のクロスリージョンに配置できます。

この機能は、共有責任モデルに依存しています。

  • **Snowflakeの役割：**Snowflakeは、ターゲットテーブルとロード履歴（インジェスションの状態）をセカンダリアカウントにネイティブで複製します。フェールオーバー中、Snowflakeはこの状態を使用して重複を防ぎ、プライマリの場所で処理されなかったファイルのみをインジェストします。

  • **ユーザーの役割：**障害が発生した場合（またはデュアル書き込みクラウド構成の一部として）、新しい受信ファイルをセカンダリクラウドストレージの場所にルーティングする必要があります。Snowflakeは、外部クラウドストレージファイルを複製しません。

パイプラインのレジリエンスは、最大2つのキーリソースを構成することで実現されます。

  • **マルチロケーションストレージ統合（MLSI）：**リージョンまたはクラウド全体で、Snowflakeを複数の外部クラウドストレージの場所に安全に接続します。MLSIは、外部ステージのみからのCOPYINTOまたはSnowpipeパイプラインでレジリエンスが欲しい場合に必要です。

  • **マルチキュー通知統合（MQNI）：**Snowflakeを複数のサードパーティのクラウドメッセージキューに接続し、新しいファイル通知を継続的に受信できるようにします。MQNIは、Snowpipeパイプラインにレジリエンスが欲しい場合（つまり継続的なデータのロードが生じる場合）にのみ必要です。

データパイプラインの複数の場所におけるレジリエンスアーキテクチャ

要件と考慮事項

この機能を構成する前に、以下の前提条件と考慮事項を精査してください。

要件

  • **エディション：**Snowflake Business Critical Edition（またはそれ以上）。

  • **サポートされているインジェスションのメソッド：**この機能は、Snowpipe（自動インジェスト）およびCOPYINTO<table>を介したファイルベースのデータのロードのみをサポートします。OpenflowまたはSnowpipe Streamingはサポートされていません。

  • **同一パス構造：**パイプラインがフェールオーバー後に新しいファイルを見つけられるようにするには、プライマリロケーションとまったく同じ階層、フォルダー構造、相対パスを使用して、セカンダリのストレージの場所でファイルを書き込む必要があります。

考慮事項

  • **請求：**この機能では、ターゲットアカウントに請求される標準の複製料金（データ転送およびコンピューティングリソース）が発生します。

  • **ステージ変更のダウンタイム：**既存のステージのRELATIVE_URLプロパティを変更すると、依存オブジェクトが無効化され、インジェスションが停止します。ダウンタイムを避けるため、セットアップ中に新しいステージを作成することをお勧めします。

  • **マルチキュー通知統合（MQNI）：**ソースアカウントとターゲットアカウントの両方で同じアクティブキューを使用することはサポートされていません。通知が失われる可能性があります。Snowflakeでは、アカウント間で同じキューが使用されているかどうかは確認されません。

  • **ディレクトリテーブル：**MLSIを使用してステージ上にディレクトリテーブルを作成する操作は現在サポートされていません。

複製動作

  • **非同期複製：**Snowflakeは、テーブルとパイプラインのロード履歴をまったく同じスナップショットで複製します。同期されているため、停止してもデータが重複することはありません。セカンダリデータベースが4時間遅れている場合、テーブルデータも4時間遅れになります。キューに入っている4時間分の通知を処理するシンプルな操作により、テーブルが最新の状態になります。

  • **デュアル書き込みのデータ損失回避：**復旧ポイントの目標（RPO）は、複製更新間隔によって決定されます。フェールオーバー時のデータ損失を防ぐには、セカンダリクラウドメッセージキューのメッセージ保持期間を複製間隔より長くする必要があります。スケジュールされた複製のキャッチアップより前に、キューによりメッセージがドロップされる場合、それらのファイルはフェールオーバー時にインジェストされません。

  • **単一書き込みのデータ損失リスク：**単一書き込みルーティングを使用すると、前回複製が成功した後にプライマリの場所で処理されるファイルは、セカンダリの場所から完全に認識できない状態になります。フェールオーバー時に、このデータはターゲットアカウントで一時的に欠落します。

警告

**単一書き込みフェールバックに関する重要な警告：**更新を実行して元のプライマリアカウントにフェールバックすると、プライマリデータベースはセカンダリデータベースによって上書きされます。同期する前に、これらの孤立したファイルを手動でセカンダリデータベースに統合しないと、ファイルはプライマリデータベースから完全に削除されます。

適切なアーキテクチャの選択

Snowflakeでは、ターゲットテーブルとパイプラインのロード履歴が同じスナップショットで非同期的に複製されるため、データの重複や部分的なロードからパイプラインを保護できます。インジェスションの途中で障害が発生した場合、トランザクションは完全にロールバックされ、部分的にロードされたファイルは残りません。

ただし、停止中に「同時進行」のファイルを回復する方法は、外部クラウドストレージルーティングがデュアル書き込みまたは単一書き込みルーティングで構成されているかどうかに完全に依存します。

2.単一書き込みルーティング

プロデューサーは、プライマリクラウドストレージにのみ書き込みます。障害が発生する場合は、プロデューサーを再ルーティングし、セカンダリクラウドストレージに対し新しいファイルの書き込みを開始します。

  • **フェールオーバーの動作：**セカンダリアカウントは、セカンダリバケットにルーティングされた新しいファイルの処理をすぐに開始します。ただし、影響を受けたプライマリの場所に残された同時進行中のファイルは、一時的にそのままになります。

  • **フェールバックの動作：**プライマリの場所が回復し、プライマリSnowflakeアカウントへのフェールバックが実行されると、Snowpipeは障害前の段階でキューに正常に到達しているファイル通知を自動的に処理します。

  • **結果：**重複なし。ただし、障害のためにクラウド通知の生成が完全に失敗した場合（または障害によりキューのメッセージ保持ポリシーが中断された場合）は、手動での介入が必要です。

  • **必要なアクション：**フェールバック後、プライマリストレージバケットとSnowflakeのCOPY_HISTORYビューを比較して、欠落しているファイルを特定します。ALTERPIPE ... REFRESH、または手動でCOPYINTOコマンドを実行して、これら特定の孤立したファイルをロードします。

パート1:1回限りの構成（セットアップ）

回復力のあるデータパイプラインを構成するために、次のステップが1回実行されます。セットアップ時に両方のアカウントのアクティブな場所を構成したため、実際の停止時のフェールオーバーはほぼ瞬時に行われます。

ステップ1：マルチロケーションストレージ統合（MLSI）

マルチロケーションストレージ統合を構成するには、ストレージ統合を構成するための標準的なステップに従います。その際の注意点については、このセクションに記載されています。

ソースアカウントで、STORAGE_LOCATIONSリスト内の各場所に値を指定してMLSIを作成します。クラウド間のセットアップのために、クラウドプロバイダーを組み合わせることができます。

CREATE STORAGE INTEGRATION my_mlsi
  TYPE = EXTERNAL_STAGE
  STORAGE_LOCATIONS =
  (
    (
      NAME = 'my-s3-us-west-1'
      STORAGE_PROVIDER = 'S3'
      STORAGE_BASE_URL = 's3://myBucketWest'
      STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::12345:role/myrole'
      STORAGE_AWS_EXTERNAL_ID = 'mlsi-external-id'
      ENCRYPTION = ( TYPE = 'AWS_SSE_S3' )
    ),
    (
      NAME = 'my-s3-us-east-1'
      STORAGE_PROVIDER = 'S3'
      STORAGE_BASE_URL = 's3://myBucketEast'
      STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::67890:role/myrole'
      STORAGE_AWS_EXTERNAL_ID = 'mlsi-external-id'
      ENCRYPTION = ( TYPE = 'AWS_SSE_S3' )
    )
  )
  ENABLED = TRUE
  STORAGE_ALLOWED_LOCATIONS = ('*')
  ACTIVE = 'my-s3-us-west-1';

条件:

  • **STORAGE_LOCATIONS：**ストレージ統合のために1つまたは複数のストレージの場所（S3バケット、GCSバケット、またはAzureコンテナー）のリストを指定します。各クラウドプロバイダーのパラメーターを表示する方法については、:doc:`/sql-reference/sql/create-storage-integration`リファレンスページの:ref:`クラウドプロバイダーのパラメーター（cloudProviderParams）<label-create_integration_storage_cloudProviderParams>`を参照してください。

  • **NAME：**ストレージの場所の識別子（名前）を指定する文字列。

  • **ENCRYPTION：**ストレージの場所の暗号化を指定します。ストレージの場所の暗号化は、ステージレベルではなく、ストレージ統合レベルで指定する必要があります。暗号化されたファイルからロードする場合にのみ必要です。ストレージの場所とファイルが暗号化されていない場合は不要です。各クラウドプロバイダーの暗号化オプションを確認するには、:doc:`/sql-reference/sql/create-stage`リファレンスページの:ref:`ENCRYPTION<label-create_stage_encryption_parameters>`を参照してください。

  • **ACTIVE：**現在のアカウントにおけるストレージ統合のアクティブな場所として設定する、ストレージの場所の名前を指定します。

    ソースアカウントのアクティブなストレージの場所については、アクセス制御を設定し、ストレージにアクセスするためのSnowflake権限を付与する必要があります。次のトピックの指示を使用します。

ステップ2：MLSIを外部ステージに関連付ける

既存のステージを変更するのではなく、新しいステージを作成することを強くお勧めします。

警告

WARNING：RELATIVE_URLの変更はダウンタイムの原因となります

ALTERSTAGEを使用して、既存のステージのRELATIVE_URLを変更する場合、依存するディレクトリテーブルが再作成され、このステージを使用する外部テーブルまたはパイプは無効としてマークされます。また、インジェスションが停止されます。既存のステージを変更する場合は、ダウンタイムが発生することを想定してください。

CREATESTAGEコマンドを使用して、作成したマルチロケーションストレージ統合を1つまたは複数の外部ステージに関連付けます。

CREATE STAGE my_ext_stage
  RELATIVE_URL = '/my_folder/my_sub_folder/'
  STORAGE_INTEGRATION = 'my_mlsi';

条件:

  • **RELATIVE_URL：**ストレージ統合で定義されたストレージの場所から、外部ステージの場所への相対パス。フェールオーバー後にパイプラインが新しいファイルを見つけられるようにするには、プライマリの場所と同じ階層、フォルダー構造、相対パスを使用して、セカンダリのストレージの場所にファイルを書き込む必要があります。

注釈

この値はリテラルパスにする必要があります。パターンやワイルドカードによる指定はサポートされていません。ストレージ統合のSTORAGE_BASE_URLの下にあるすべての場所へのアクセスを指定するには、空の文字列（RELATIVE_URL=''）を使用します。

  • **STORAGE_INTEGRATION：**マルチロケーションストレージ統合の名前。

注釈

または、RELATIVE_URLパラメーターとMLSIを指定して、既存の外部ステージを変更することもできます。ALTERSTAGEコマンドは、外部ステージがマルチロケーションストレージ統合を使用しないように、この変更のロールバックもサポートします。

例:

ALTER STAGE my_ext_stage SET
  RELATIVE_URL = '/my_folder/my_sub_folder/'
  STORAGE_INTEGRATION = 'my_mlsi';

ステップ3：マルチキュー通知統合の構成（MQNI）

クラウドメッセージングによる自動データロードを使用し、外部ステージにマルチロケーションストレージ統合を構成している場合は、Snowpipeパイプラインのシームレスなフェールオーバーにマルチキュー通知統合も使用する必要があります。

通知統合用に定義するキューごとに、以下のトピックのステップを使ってメッセージサービスを準備する必要があります。

注釈

SnowpipeでAmazon SNSを使用したくない場合、MQNIの作成を回避できますが、フェールオーバー時に追加のステップを実行する必要があります。このオプションを選択した場合は、パイプを上記で作成したステージおよびMLSIに関連付けてから、ステップ4に進みます。

シナリオA：新しいマルチキュー通知統合（MQNI）の作成

マルチキュー通知統合を作成するには、通知統合を作成するための標準的な手順に従います。ただし、このセクションに記載されているように、いくつかの違いがあります。

ソースアカウントで、QUEUESリスト内の各キューに値を指定して、マルチキュー通知統合を作成します。

CREATE NOTIFICATION INTEGRATION my_mqni
  ENABLED = TRUE
  TYPE = MULTI_QUEUE
  DIRECTION = INBOUND
  QUEUES = (
    (
      NAME = 'my-us-west-1'
      NOTIFICATION_PROVIDER = AWS_SNS
      AWS_SNS_TOPIC_ARN = 'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-west'
    ),
    (
      NAME = 'my-us-east-1'
      NOTIFICATION_PROVIDER = AWS_SNS
      AWS_SNS_TOPIC_ARN = 'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-east'
    )
  )
  ACTIVE = 'my-us-west-1';

条件:

  • **TYPE = MULTI_QUEUE：**Snowflakeとサードパーティのクラウドメッセージキューイングサービスとの間のマルチキュー統合であることを指定します。

  • **DIRECTION = INBOUND：**Snowflakeがクラウドメッセージングサービスから送信された通知を受信することを指定します。

  • **QUEUES：**通知統合の1つまたは複数のキューが記載されているリストを指定します。

  • **NAME：**キューの識別子（名前）を指定する文字列。

各クラウドプロバイダーの特定のキューパラメーターを表示するには、以下を参照してください。

  • AWS:

    • **NOTIFICATION_PROVIDER = AWS_SNS：**サードパーティのクラウドメッセージキューイングサービスとしてAmazon Simple Notification Service（SNS）を指定します。

    • **AWS_SNS_TOPIC_ARN：**通知がプッシュされるAmazon SNSトピックのAmazon Resource Name（ARN）。

  • Google Cloud：CREATE NOTIFICATION INTEGRATION（Google Pub/Subトピックからのインバウンド）

  • Azure：CREATE NOTIFICATION INTEGRATION（Azure Event Gridトピックからのインバウンド）

  • **ACTIVE：**現在のアカウントにおける通知統合のアクティブなキューとして設定するキューの名前を指定します。

    ソースアカウントのアクティブなキューに対して、Snowflakeにメッセージングサービスへのアクセス権限を付与する必要があります。ご利用のクラウドプロバイダーの指示に従ってください。

    • AWSの場合は、:ref:`label-create_sns_topic_subscription`の下にある、「SnowflakeのSQSキューをSNSトピックに登録する」を参照してください。

    • Google Cloudの場合は、:ref:`label-gcp_pubsub_snowpipe`の下にある「Pub/SubサブスクリプションにSnowflakeアクセスを付与する」を参照してください。

    • Azureの場合は、:ref:`label-azure_configuring_automation`の下にある「Snowflakeにストレージキューへのアクセスを付与する」を参照してください。

MQNIを作成した後、それを使用してCREATEPIPEコマンドで新しいパイプを作成できます。次の例では、マルチロケーションストレージ統合に依存する外部ステージ（my_ext_stage）を使用して、Amazon S3からテーブルにデータをロードするパイプを作成します。

CREATE PIPE my_pipe
  AUTO_INGEST = TRUE
  INTEGRATION = my_mqni
  AS COPY INTO my_table FROM @my_ext_stage/my_pipe/;

シナリオB：既存の通知統合のMQNIへの移行

最初から新しいものを作成するのではなく、MQNIに変換したい既存の通知統合がすでにある場合は、SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE関数を使用します。

この関数は、指定した名前を使用して新しいマルチキュー通知統合を作成し、ソースアカウントのアクティブなキューを元のキューに設定し、ソースアカウント内のすべてのパイプを自動的に移行して新しいMQNIを使用するようにします。

構文：

SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  '<new_mqni_name>',
  '<original_sns_topic_arn_or_int_name>',
  '<new_sns_topic_arn_or_int_name>'
)

条件:

  • **new_mqni_name：**関数が作成する新しいマルチキュー通知統合に割り当てる識別子（名前）を指定する文字列。

  • original_sns_topic_arn_or_int_name:

    • AWSの場合、1つまたは複数のパイプに関連付けられた元のSNSトピックのAmazon Resource Name（ARN）。

    • Google CloudまたはAzureの場合、1つまたは複数のパイプに関連付けられた元の単一キュー通知統合の識別子を指定する文字列。

  • new_sns_topic_arn_or_int_name:

    • AWSの場合、キューとしてMQNIに追加する新しいSNSトピックのAmazon Resource Name（ARN）。

    • Google CloudまたはAzureの場合、元の通知統合と組み合わせる新しい単一キュー通知統合の識別子を指定する文字列。

例1：新しいSNSトピックキューの追加

SELECT SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  'my_mqni',
  'arn:aws:sns:us-west-1:12345:my-snowpipe-mlsi-west',
  'arn:aws:sns:us-east-1:67890:my-snowpipe-mlsi-east'
);

これにより、次のキューを含むmy_mqniという名前のMQNIが生成されます。

  • MY_MQNI-queue1（元のアクティブなSNSトピック用）

  • MY_MQNI-queue2（新しいSNSトピック用）

例2：2つの通知統合のMQNIへの統合

SELECT SYSTEM$CONVERT_PIPES_TO_MULTI_QUEUE(
  'my_azure_mqni',
  'my_azure_ni_1',
  'my_azure_ni_2'
);

これにより、次のキューを含むmy_azure_mqniという名前のMQNIが生成されます。

  • my_azure_ni_1（元のアクティブなキュー用）

  • my_azure_ni_2（新しいキュー用）

注釈

ソースアカウントのアクティブなキューを変更する場合は、ALTER INTEGRATION ... SET ACTIVE = '<my_queue>'ステートメントを使用できます。アクティブなキューを更新する前に、通知統合を使用するパイプを一時停止する必要があります。

ステップ4：ターゲットアカウントへのMLSIおよびMQNIの複製

注釈

リフレッシュ操作では、オブジェクトにグローバルIDsがある場合を除き、複製ではないターゲットアカウント内のストレージ統合または通知統合がドロップされます。

詳細については、 ターゲットアカウントでの複製とオブジェクト をご参照ください。

1.マルチロケーションストレージ統合およびマルチキュー通知統合を複製するには、既存の複製またはフェールオーバーグループを変更して、ALLOWED_INTEGRATION_TYPESリストにSTORAGE INTEGRATIONSおよびNOTIFICATION INTEGRATIONSを含めます。

たとえば、ALTER FAILOVER GROUPコマンドを使用します。

ALTER FAILOVER GROUP my_fg SET
  OBJECT_TYPES = DATABASES, ROLES, INTEGRATIONS
  ALLOWED_INTEGRATION_TYPES = API INTEGRATIONS, STORAGE INTEGRATIONS,
    NOTIFICATION INTEGRATIONS;

  1. 次に、ターゲットアカウントでリフレッシュ操作を実行します。

ALTER FAILOVER GROUP my_fg REFRESH;

ステップ5：ターゲットアカウントでのアクティブな状態の構成

リフレッシュ操作を実行した後、実際の障害時にシームレスなフェールオーバーが確実に実行されるようにするため、ターゲットアカウントでアクティブなストレージの場所とキュー（通知統合を使用する場合）を構成します。

ターゲットアカウントでの操作

  1. ターゲットアカウントでアクティブな場所として設定するストレージの場所については、次のトピックの指示を使用して、Snowflakeにストレージへのアクセス権限を付与します。

  2. セカンダリストレージのアクティブ化ターゲットアカウントでセカンダリバックアップストレージの場所を使用するようにMLSIを設定します。

    ALTER STORAGE INTEGRATION my_mlsi SET ACTIVE = 'my-s3-us-east-1';

  3. マルチキュー通知統合を使用している場合は、ターゲットアカウントでアクティブに設定するキューに対し、Snowflakeがメッセージングサービスにアクセスするための権限を付与します。ご利用のクラウドプロバイダーの指示に従ってください。

    • AWSの場合は、:ref:`label-create_sns_topic_subscription`の下にある、「SnowflakeのSQSキューをSNSトピックに登録する」を参照してください。

    • Google Cloudの場合は、:ref:`label-gcp_pubsub_snowpipe`の下にある「Pub/SubサブスクリプションにSnowflakeアクセスを付与する」を参照してください。

    • Azureの場合は、:ref:`label-azure_configuring_automation`の下にある「Snowflakeにストレージキューへのアクセスを付与する」を参照してください。

  4. セカンダリキューのアクティブ化（MQNIを使用している場合）ターゲットアカウントのセカンダリの場所にアクティブキューを設定します。

    ALTER INTEGRATION my_mqni
  SET ACTIVE = 'MY_MQNI-queue2';

パート2:フェールオーバーのステップ

停止時にこれらのステップを実行して、データインジェスチョンをセカンダリの場所にリダイレクトします。アクティブなキューとストレージはセットアップで事前に構成されているため、このプロセスに必要なコマンドは最小限になります。

  1. ターゲットアカウントの昇格：ターゲットアカウントにログインし、新しいプライマリアカウントとして機能するように昇格させます。セカンダリクラウドインフラストラクチャのデータのロードが自動的に再開されます。

    ALTER FAILOVER GROUP my_fg PRIMARY;

  2. SnowpipeでAmazon SNSを使用していない場合SnowpipeでSNSを使用しておらず、SQSのみに依存している場合は、MQNIを作成する必要はありません。代わりに、次のシステム関数を呼び出して、フェールオーバー時にパイプを再バインドします。

    SELECT SYSTEM$INGEST_REBIND_PIPE('my_db.my_schema.my_pipe');

パート3：フェールバックのステップ

障害が解決し、プライマリの場所が正常になったら、これらのステップを実行してパイプラインをプライマリロケーションに戻します。

  1. データを同期して元に戻す：元のアカウントを昇格させる前に、障害時に発生したすべてのデータと状態の変更を元のアカウントにプルバックする必要があります。元のプライマリアカウント（現在はセカンダリアカウントとして機能）にログインし、手動での更新を開始します。

    ALTER FAILOVER GROUP my_fg REFRESH;

    重要

    次のステップに進む前に、このリフレッシュ操作が完全に完了するのを待ちます。同期が完了する前にフェールオーバーすると、データが失われる可能性があります。

    警告

    **単一書き込みフェールバックに関する重大な警告：**単一書き込みルーティングを使用すると、前回複製が成功した後にプライマリの場所で処理されるファイルは、セカンダリの場所から認識できない状態になります。フェールオーバー時、このデータはターゲットアカウントで一時的に欠落します。更新を実行して元のプライマリアカウントにフェールバックすると、プライマリデータベースはセカンダリデータベースによって上書きされます。同期する前に、これらの孤立したファイルを手動でセカンダリデータベースに統合しないと、ファイルはプライマリデータベースから完全に削除されます。

  2. 元のアカウントの昇格：更新が完了したら、元のソースアカウントをプライマリに昇格させます。

    ALTER FAILOVER GROUP my_fg PRIMARY;

  3. SnowpipeでAmazon SNSを使用していない場合システム関数を呼び出して、パイプを元のソースの場所に再バインドします。

    SELECT SYSTEM$INGEST_REBIND_PIPE('my_db.my_schema.my_pipe');

パート4：モニタリングと検証

フェールオーバーまたはフェールバックを開始した後、次のコマンドを使用して、データパイプラインが正常にリダイレクトされ、インジェスションが再開されたことを確認します。

1.アクティブな統合状態の確認

プロパティをチェックして、統合で正しいストレージとキューが指定されていることを確認します。出力でACTIVEプロパティを探します。

-- Check the active storage location
DESCRIBE STORAGE INTEGRATION my_mlsi;

-- Check the active message queue
DESCRIBE INTEGRATION my_mqni;

2.パイプステータスの確認（Snowpipeのみ）

SYSTEM$PIPE_STATUS関数を使用して、パイプが実行されていることを確認し、セカンダリの場所から新しいファイルがアクティブにキューされているかどうかを確認します。

SELECT SYSTEM$PIPE_STATUS('my_pipe');

"executionState":"RUNNING"を探し、"pendingFileCount"をチェックして、セカンダリバケットにドロップされた新しいファイルがアクティブに認識されていることを確認します。

3.インジェスション成功の検証（ロード履歴）

データがエラーや重複なしでロードされていることを確認するには、COPY_HISTORYビューのクエリを実行します。これにより、インジェストされたファイル、ソースパス、およびロードされたタイミングが正確に示されます。

SELECT file_name, status, row_count, last_load_time
FROM TABLE(information_schema.copy_history(
  table_name => 'my_table',
  start_time => DATEADD(hours, -1, CURRENT_TIMESTAMP())
));

file_nameパスがアクティブなストレージの場所を反映し、ステータスにLOADEDと表示されていることを確認します。