SQL Server 取り込みパイプラインのメンテナンス
プレビュー
LakeFlow Connect はゲート付きパブリック プレビュー段階です。 プレビューに参加するには、Databricks アカウント チームにお問い合わせください。
この記事では、LakeFlow Connect UI を使用して SQL Server 取り込みパイプラインを維持するための継続的な操作について説明します。
取り込むテーブルを指定する
パイプライン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
デフォルト値はありません。
他のすべてのテーブル スキーマの変更は、互換性のないスキーマの変更と見なされます。
取り込みパイプラインのスケジュールを変更する
Databricks ワークスペースで、 [ジョブ実行]をクリックします。
[ジョブ]タブをクリックします。
ジョブをクリックし、スケジュールとトリガーのセクションを変更します。
ターゲットテーブルの完全更新
取り込みパイプラインで Delta Live Tables の完全な更新機能を使用できます。 完全更新では、1 つ以上のターゲット テーブルのスキーマが対応するソース テーブルのスキーマと同期され、すべてのテーブル データが再コピーされます。 これは、互換性のないスキーマ変更の場合に便利です。
選択したテーブルの完全更新をトリガーするには、取り込みパイプラインの DLT パイプライン UI で[更新するテーブルを選択]をクリックします。 目的のテーブルを選択し、 「選択内容を完全に更新」をクリックします。
取り込みパイプライン内のすべてのテーブルに対して完全な更新を実行するには、 [開始]ボタンの横にあるドロップダウン メニューをクリックし、 [すべてを完全に更新]を選択します。
1 つ以上のテーブルを完全にリフレッシュする DLT パイプラインの更新は、パイプラインの起動時の初期化フェーズの後のフェーズで認識できます。
重要
取り込みパイプラインの更新は、 Initializing
またはResetting tables
フェーズ中に失敗する可能性があります。 DLT はパイプラインを自動的に数回再試行します。 自動再試行が手動で中断されたり、最終的に致命的な失敗に終わったりした場合は、以前のテーブル更新選択を使用して、新しいパイプラインの更新を手動で開始します。 これを行わないと、ターゲットテーブルが部分的なデータと一貫性のない状態のままになる可能性があります。 手動の再試行も失敗する場合は、サポート チケットを作成します。
アラートと通知
パイプライン障害のアラートは、すべてのゲートウェイ、管理された取り込みパイプライン、および管理された取り込みスケジュール ジョブに対して自動的に設定されます。 パイプラインAPIを使用してアラートをカスタマイズできます。 PUT /api/2.0/パイプライン/{パイプライン}の通知を参照してください。 ドキュメンテーション。