LakeFlow Connect のマネージド コネクタ
プレビュー
LakeFlow Connect のマネージド コネクタは、さまざまなリリース状態にあります。
この記事では、SaaSアプリケーションやデータベースからデータを取り込むための Databricks LakeFlow Connect のマネージド コネクタの概要について説明します。結果として得られる取り込みパイプラインは Unity Catalog によって制御され、サーバレス コンピュートと LakeFlow 宣言型パイプラインによって駆動されます。 マネージド コネクタは、効率的な増分読み取りと書き込みを活用して、データ取り込みを高速化、スケーラブル、コスト効率を高めながら、データを最新の状態に保ち、ダウンストリームで消費できるようにします。
SaaS コネクタ コンポーネント
SaaS コネクタには、次のコンポーネントがあります。
コンポーネント | 説明 |
---|---|
接続 | アプリケーションの認証の詳細を格納する Unity Catalog のセキュリティ保護可能なオブジェクト。 |
取り込みパイプライン | アプリケーションから送信先テーブルにデータをコピーするパイプライン。この取り込みパイプラインはサーバレスコンピュートで実行されます。 |
宛先テーブル | 取り込み パイプラインがデータを書き込むテーブル。これらは ストリーミングテーブルであり、増分データ処理の追加サポートを備えた Delta テーブルです。 |
データベースコネクタコンポーネント
データベースコネクタには、次のコンポーネントがあります。
コンポーネント | 説明 |
---|---|
接続 | データベースの認証の詳細を格納する Unity Catalog のセキュリティ保護可能なオブジェクト。 |
取り込みゲートウェイ | ソース データベースからスナップショット、変更ログ、メタデータを抽出するパイプライン。ゲートウェイは従来のコンピュートで実行され、ソースで変更ログを切り捨てる前に変更をキャプチャするために継続的に実行されます。 |
ステージング・ストレージ | 抽出されたデータを宛先テーブルに適用する前に一時的に保存する Unity Catalog ボリューム。これにより、ゲートウェイが継続的に変更をキャプチャしている場合でも、任意のスケジュールで取り込み パイプラインを実行できます。また、障害の回復にも役立ちます。ゲートウェイをデプロイするときにステージングストレージボリュームを自動的に作成し、その保存場所のカタログとスキーマをカスタマイズできます。データは 30 日後にステージングから自動的に消去されます。 |
取り込みパイプライン | ステージングストレージから宛先テーブルにデータを移動するパイプライン。この取り込みパイプラインはサーバレスコンピュートで実行されます。 |
宛先テーブル | 取り込み パイプラインがデータを書き込むテーブル。これらは ストリーミングテーブルであり、増分データ処理の追加サポートを備えた Delta テーブルです。 |
オーケストレーション
取り込み パイプラインは、1 つ以上のカスタム スケジュールで実行できます。パイプラインに追加するスケジュールごとに、 LakeFlow Connect によってその ジョブ が自動的に作成されます。 取り込み パイプラインは、ジョブ内のタスクです。オプションで、ジョブにタスクを追加できます。
データベース コネクタの場合、取り込み ゲートウェイは、連続タスクとして独自のジョブで実行されます。
増分取り込み
LakeFlow Connect では、増分取り込みを使用してパイプラインの効率を向上させます。 パイプラインの最初の実行時に、選択したすべてのデータがソースから取り込まれます。並行して、ソース データへの変更を追跡します。パイプラインの後続の各実行では、その変更追跡を使用して、可能な限り、前回の実行から変更されたデータのみを取り込みます。
正確なアプローチは、データソースで利用可能なものによって異なります。 たとえば、変更の追跡とチェンジデータキャプチャ (CDC) の両方を SQL Serverで使用できます。 これに対し、Salesforce コネクタは、設定されたオプションのリストからカーソル列を選択します。
一部のソースまたは特定のテーブルでは、現時点では増分取り込みはサポートされていません。Databricks は、増分サポートの対象範囲を拡大する予定です。
ネットワーキング
SaaS アプリケーションまたはデータベースに接続するには、いくつかのオプションがあります。
- SaaSアプリケーション用のコネクタは、ソースのAPIに手を差し伸べます。また、サーバレスのエグレスコントロールとも自動的に互換性があります。
- クラウド データベース用のコネクタは、Private Link 経由でソースに接続できます。または、データベースをホストしている VNet または VPC とピアリングされた仮想ネットワーク (VNet) または仮想プライベート クラウド (VPC) がワークスペースにある場合は、その内部に取り込み ゲートウェイをデプロイできます。
- オンプレミス データベース用のコネクタは、AWS Direct Connect や Azure ExpressRoute などのサービスを使用して接続できます。
配備
Databricks Asset Bundle を使用してインジェストパイプラインをデプロイし、ソース管理、コードレビュー、テスト、継続的インテグレーションと継続的デリバリー (CI/CD) などのベストプラクティスを実現できます。バンドルは Databricks CLI を使用して管理され、開発、ステージング、本番運用など、異なるターゲット ワークスペースで実行できます。
障害復旧
フルマネージドサービスとして、 LakeFlow Connect は可能な限り問題から自動的に回復することを目指しています。 たとえば、コネクタに障害が発生すると、エクスポネンシャル バックオフで自動的に再試行されます。
ただし、エラーによって介入が必要になる可能性があります (たとえば、資格情報の有効期限が切れた場合など)。このような場合、コネクタはカーソルの最後の位置を格納することで、データの欠落を回避しようとします。その後、可能な場合は、パイプラインの次の実行でその位置から再開できます。
モニタリング
LakeFlow Connect は、パイプラインの保守に役立つ堅牢なアラートと監視を提供します。 これには、イベント ログ、クラスター ログ、パイプライン ヘルス メトリクス、データ品質メトリクスが含まれます。
履歴追跡
履歴追跡設定は、 slowly changing dimensions (SCD) 設定とも呼ばれ、時間の経過に伴うデータの変化を処理する方法を決定します。 履歴追跡をオフ (SCD タイプ 1) にすると、ソースで更新および削除される古いレコードが上書きされます。履歴追跡をオンにする (SCD タイプ 2) とすると、これらの変更の履歴が維持されます。ソースのテーブルまたはカラムを削除しても、SCD タイプ 1 が選択されている場合でも、そのデータはコピー先から削除されません。
たとえば、次のテーブルを取り込むとします。
また、アリスの好きな色が1月2日に紫に変わるとしましょう。
履歴追跡がオフ (SCD タイプ 1) の場合、取り込み パイプラインの次回の実行では、宛先テーブルのその行が更新されます。
履歴追跡がオン (SCD タイプ 2) の場合、取り込み パイプラインは古い行を保持し、更新を新しい行として追加します。古い行を非アクティブとしてマークして、どの行が最新の状態であるかを把握できます。
すべてのコネクタが履歴追跡 (SCD タイプ 2) をサポートしているわけではありません。
機能の互換性
次の表は、コネクタごとの機能の可用性をまとめたものです。その他の機能と制限については、特定のコネクタのドキュメントを参照してください。
機能 | Googleアナリティクス | Salesforce | Workday | SQL Server | ServiceNow | SharePoint |
---|---|---|---|---|---|---|
ステータス | パブリックプレビュー | パブリックプレビュー | パブリックプレビュー | ゲーティッドパブリックプレビュー 詳細については、アカウントチームにお問い合わせください。 | ゲーティッドパブリックプレビュー 詳細については、アカウントチームにお問い合わせください。 | ベータ版 |
UI ベースのパイプラインオーサリング | ||||||
API ベースのパイプラインオーサリング | ||||||
Databricksアセットバンドル | ||||||
増分取り込み | 数式フィールドの一時的な例外 | ただし、テーブルにカーソルフィールドがない場合の例外 | ||||
Unity Catalog のガバナンス | ||||||
Databricks Workflowsを使用したオーケストレーション | ||||||
SCDタイプ2 | ||||||
API ベースの列の選択と選択解除 | ||||||
自動化されたスキーマ進化: 新しい列と削除された列 | ||||||
自動スキーマ進化: データ型の変更 | ||||||
自動化されたスキーマ進化: 列の名前変更 | 新しい列 (新しい名前) と削除された列 (古い名前) として扱われます。 | 新しい列 (新しい名前) と削除された列 (古い名前) として扱われます。 | 新しい列 (新しい名前) と削除された列 (古い名前) として扱われます。 | DDL オブジェクトが有効になっている場合、コネクタは列の名前を変更できます。DDL オブジェクトが有効になっていない場合、コネクタはこれを新しい列 (新しい名前) および削除された列 (古い名前) として扱います。いずれの場合も、完全な更新が必要です。 | 新しい列 (新しい名前) と削除された列 (古い名前) として扱われます。 | 新しい列 (新しい名前) と削除された列 (古い名前) として扱われます。 |
自動スキーマ進化: 新しいテーブル | スキーマ全体を取り込む場合。パイプラインあたりのテーブル数の制限を参照してください。 | スキーマ全体を取り込む場合。パイプラインあたりのテーブル数の制限を参照してください。 | N/A | スキーマ全体を取り込む場合。パイプラインあたりのテーブル数の制限を参照してください。 | スキーマ全体を取り込む場合。パイプラインあたりのテーブル数の制限を参照してください。 | スキーマ全体を取り込む場合。パイプラインあたりのテーブル数の制限を参照してください。 |
パイプラインあたりのテーブルの最大数 | 250 | 250 | 250 | 250 | 250 | 250 |
外部サービスへの依存
DatabricksのSaaS、データベース、およびその他のフルマネージド コネクタは、接続先のアプリケーション、データベース、または外部サービスのアクセシビリティ、互換性、安定性に依存します。Databricks はこれらの外部サービスを制御していないため、変更、更新、およびメンテナンスに対する影響力は (あったとしても) 制限されています。
外部サービスに関連する変更、中断、または状況により、コネクタの運用が妨げられたり、非現実的になったりした場合、Databricks はそのコネクタの保守を中止または中止することができます。Databricksは、該当するドキュメントの更新を含む、メンテナンスの中止または中止を顧客に通知するために合理的な努力を払います。