メインコンテンツまでスキップ

SQL Server インジェスト パイプラインのメンテナンス

備考

プレビュー

Microsoft SQL Server コネクタは、ゲート パブリック プレビュー段階です。プレビューに参加するには、Databricks アカウント チームにお問い合わせください。

この記事では、SQL Server LakeFlow ConnectUI を使用してインジェスト パイプライン 維持するための継続的な操作について説明します。

未使用のステージングファイルを削除する​

2025 年 1 月 6 日より後に作成されたインジェスト パイプラインの場合、ボリューム ステージング データは 25 日後に自動的に削除され、30 日後に物理的に削除されるようにスケジュールされます。 インジェスト パイプラインが 25 日以上正常に完了していないと、宛先テーブルにデータギャップが生じる可能性があります。 ギャップを回避するには、ターゲットテーブルの完全更新をトリガーする必要があります。

2025 年 1 月 6 日より前に作成されたインジェスト パイプラインについては、Databricks サポートに連絡して、ステージング CDC データの自動保持管理を手動で有効にするように依頼してください。

次のデータは自動的にクリーンアップされます。

  • CDC データ・ファイル
  • スナップショット・ファイル
  • ステージング・テーブル・データ

取り込むテーブルを指定する​

パイプライン API には、ingestion_definition の objects フィールドに取り込むテーブルを指定する 2 つの方法が用意されています。

  • テーブル仕様: 指定したソースカタログとスキーマから、指定した宛先カタログとスキーマに個々のテーブルを取り込みます。

    {"table": {

            "source_catalog": ...,

            "source_schema": ...,

            "source_table": ...,

            "destination_catalog": ...,

            "destination_schema": ...

            }}

  • スキーマ仕様: 指定したソースカタログとスキーマのすべてのテーブルを、指定したカタログとスキーマに取り込みます。

    {"schema": {

            "source_catalog": ...,

            "source_schema": ...,

            "destination_catalog": ...,

            "destination_schema": ...

            }}

前の例で source_catalog、 source_schema、および source_table の名前を指定する場合は、大文字と小文字を正確に区別する必要があります。 たとえば、ソース・データベース・カタログが sys.databasesで Marketing として指定されている場合は、marketingなどではなく、同じ大文字と小文字を使用する必要があります。そうしないと、インジェストするテーブルは検出されません。

スキーマ仕様を使用する場合、ソーススキーマ内のすべての新しいテーブルは、自動的に宛先に取り込まれます。 ドロップされたテーブルの無視はサポートされていません。 ソース データベースでテーブルが削除された場合は、インジェスト パイプライン定義から明示的に削除する必要があります。 完全なスキーマレプリケーションの場合は、明示的なテーブルセットに置き換える必要があります。

ソース・データベースの負荷を軽減するために、ゲートウェイは新しいテーブルのみを定期的にチェックします。 新しいテーブルが検出されるまでに最大 6 時間かかる場合があります。 このプロセスを高速化する場合は、ゲートウェイを再起動します。

複数のテーブルまたはスキーマの仕様を ingestion_definitionの objects フィールドに含めることができます。異なるソーススキーマのソーステーブル名が重複することはできません。 これにより、インジェスト パイプラインが失敗します。

ソース DDL キャプチャとスキーマの進化​

SQL Server コネクタは、ソース テーブルのテーブル スキーマに対する変更を追跡できます。 一部のテーブル スキーマの変更は自動的に処理され、対応するターゲット テーブルのスキーマは自動的に進化します。

次のテーブルスキーマの変更は、自動的に処理されます。

ALTER TABLE … ADD COLUMN デフォルト値はありません。

他のすべてのテーブルスキーマの変更は、互換性のないスキーマ変更と見なされます。

ALTER TABLE ...列を追加​

インジェスト パイプラインが自動的に再起動され、新しい列が含まれます。 スキーマ変更前のターゲット Delta テーブルの行には、新しい列の値が NULLに設定されています。

互換性のないスキーマの変更​

互換性のないスキーマの変更により、インジェスト パイプラインは INCOMPATIBLE_SCHEMA_CHANGE エラーで失敗します。 レプリケーションを続行するには、影響を受けるテーブルの完全更新をトリガーします。

注記

Databricks では、互換性のないスキーマ変更のためにインジェスト パイプラインが失敗した時点で、スキーマ変更前のすべての行が取り込まれていることを保証できません。

インジェスト パイプラインのスケジュールを変更する​

  1. Databricks ワークスペースで、[ ジョブの実行] をクリックします。
  2. 「ジョブ」 タブをクリックします。
  3. ジョブをクリックし、[ スケジュールとトリガー ] セクションを変更します。

対象テーブルの完全更新​

DLT の完全な更新機能は、インジェスト パイプラインで使用できます。完全更新では、1 つ以上のターゲットテーブルのスキーマが対応するソーステーブルのスキーマと同期され、すべてのテーブルデータが再コピーされます。 これは、互換性のないスキーマ変更の場合に便利です。

選択したテーブルで完全更新をトリガーするには、インジェストパイプラインの DLT パイプライン UI で [ 更新するテーブルを選択 ] をクリックします。 目的のテーブルを選択し、[ 選択内容の完全更新 ] をクリックします。

インジェスト パイプライン内のすべてのテーブルに対して完全更新を実行するには、[ 開始 ] ボタンの横にあるドロップダウン メニューをクリックし、[ すべて完全更新 ] を選択します。

1 つ以上のテーブルを完全に更新した DLT パイプラインの更新は、パイプラインの起動中に初期化フェーズの後のフェーズで認識できます。

important

インジェスト パイプラインの更新は、 Initializing フェーズまたは Resetting tables フェーズ中に失敗する可能性があります。 DLT はパイプラインを自動的に数回再試行します。 自動再試行が手動で中断された場合、または最終的に致命的に失敗した場合は、前のテーブル更新選択を使用して新しいパイプラインの更新を手動で開始します。 これを行わないと、ターゲットテーブルが部分的なデータと一貫性のない状態のままになる可能性があります。 手動の再試行も失敗する場合は、サポート チケットを作成します。

アラートと通知​

パイプラインの失敗に対するアラートは、すべてのゲートウェイ、マネージド インジェスト パイプライン、およびマネージド インジェスト スケジューリング ジョブに対して自動的に設定されます。 アラートは、 パイプライン APIを使用してカスタマイズできます。 「PUT の通知」を参照してください /api/2.0/パイプライン/{パイプライン} ドキュメンテーション。

に最終更新