Lakeflow Connect とは
データエンジニアリングの現場では、「外部システムからどうやってデータを取り込むか」が最初の関門になります。Salesforce、業務データベース、各種SaaSアプリケーション。それぞれにAPIの癖があり、自前で取り込みスクリプトを書くと、構築よりも保守のほうが重くのしかかってきます。認証情報の更新、スキーマ変更への追従、増分取り込みの実装、失敗時のリトライ。気づけば本来やりたかった分析より、パイプラインのお守りに時間を取られています。
Lakeflow Connect は、この「取り込み」をマネージドサービスとして引き受けてくれる機能です。主要なSaaSアプリケーションやデータベース向けに組み込みのコネクタが用意されていて、UIまたはコードでインジェストパイプラインを構成できます。できあがったパイプラインは Unity Catalog で統制され、サーバーレスコンピュートで動き、増分取り込みも自動で行われます。
Lakeflow Connect 自体はしばらく前から存在しますが、この1年で状況は大きく変わりました。コネクタは30種類以上に増え、Salesforce・Workday・SQL Server は一般提供 (GA) になり、無料枠も追加されました。一方で、日本語でまとまった解説はまだ多くありません。そこで本記事では、ハンズオンの前に押さえておきたい Lakeflow Connect の全体像を、概念中心に整理します。
公式ドキュメントはこちらです。
Lakeflow Connect の全体像
まず、Lakeflow Connect がデータの流れの中でどこに位置するかを見ておきます。
左側にソースがあります。SaaSアプリケーションや業務データベースです。中央が Lakeflow Connect で、ソースに応じたコネクタがデータを取り込みます。取り込んだデータは右側、Unity Catalog 配下の Delta テーブルとして書き込まれます。そしてその先で、変換や分析、AIといった下流の処理につながっていきます。
ポイントは4つあります。
ひとつめは、マネージドであることです。コネクタは Databricks が提供・保守します。利用者がAPIの仕様変更を追いかける必要はありません。
ふたつめは、サーバーレスで動くことです。インジェストパイプラインはサーバーレスコンピュートで実行されるため、クラスターの管理は不要です。このため、Lakeflow Connect を使うにはワークスペースでサーバーレスコンピュートが有効になっている必要があります (サーバレス コンピュートの要件)。
みっつめは、Unity Catalog による統制です。取り込まれたデータは最初から Unity Catalog 配下のテーブルになり、権限管理やリネージの対象になります。取り込みと統治が分離しません。
よっつめは、増分取り込みです。これは後ほど節を改めて説明します。
2種類のコネクタ、SaaS とデータベース
Lakeflow Connect を理解するうえで最も重要なのが、コネクタには手間の異なる2系統がある、という点です。この違いを知らずに「とりあえず試そう」とすると、見積もりが大きく狂います。
SaaSコネクタ
Salesforce、Workday、Google Ads、Meta Ads、ServiceNow、Jira、Confluence などが対象です。構成はシンプルで、接続先の認証情報を Unity Catalog の接続オブジェクトとして登録し、取り込むオブジェクトを選ぶだけです。多くは OAuth による認証で、ポイントアンドクリックのUIで完結します。
準備の負担が軽いため、Lakeflow Connect を初めて触るならSaaSコネクタが入口として向いています。
データベースコネクタ
SQL Server、PostgreSQL、MySQL などが対象です。こちらはSaaSコネクタより一段構成が複雑です。
データベースコネクタでは、取り込みゲートウェイ (ingestion gateway) というコンポーネントを構成します。取り込みゲートウェイは、専用のジョブの中で連続タスクとして実行され、ソースデータベースから初回スナップショットを抽出し、その後の変更を継続的に取り込みます。
加えて、ソースデータベース側の準備も必要です。たとえば PostgreSQL では論理レプリケーションの有効化やレプリケーションスロットの作成、SQL Server では変更データキャプチャ (CDC) や変更追跡の設定です。ソースと取り込みゲートウェイの間のネットワーク接続も考慮する必要があります。
つまり、データベースコネクタで大変なのは Lakeflow Connect 本体というより、ソース側の準備とネットワークの部分です。これは欠点ではなく、データベースからの確実な増分取り込みに必要な作りなのですが、試す前にこの違いを知っておくと、心の準備ができます。
マネージドコネクタにないソースは
対象のマネージドコネクタが用意されていないソースもあります。これについては、コミュニティが構築・保守するオープンソースのコミュニティコネクタ (Beta) で Lakeflow Connect を拡張する、という選択肢も登場しています。本記事では深入りしませんが、「マネージドコネクタにないから即あきらめ」ではない、という点だけ覚えておくとよいでしょう。
増分取り込みのしくみ
Lakeflow Connect の効率の良さを支えているのが増分取り込みです。
パイプラインの初回実行では、選択したすべてのデータがソースから取り込まれます。これがフルロードです。それと並行して、Lakeflow Connect はソースデータへの変更の追跡を始めます。
2回目以降の実行では、その変更追跡を使い、前回から変更されたデータだけを取り込みます。毎回すべてを取り込み直さないため、効率的で、ソースへの負荷も抑えられます。
変更を追跡する具体的な方法は、ソースによって異なります。SQL Server では変更追跡と変更データキャプチャ (CDC) の両方が使えます。一方 Salesforce コネクタは、設定可能なオプションの中からカーソル列を選んで変更を検出します。利用者がこのしくみを実装する必要はなく、ソースに応じた方式を Lakeflow Connect が選んでくれます。
パイプラインの作り方は3通り
インジェストパイプラインの作成方法は3つあり、目的に応じて選べます。
ひとつめがDatabricks UIです。サイドバーの「データ取り込み」からウィザードを起動し、接続・ソース・宛先・スケジュールを順に指定していく方式です。最初の1本や、手早く動かして挙動を確かめたいときに向いています。
ふたつめが Declarative Automation Bundles (DAB) です。パイプラインの定義をYAMLファイルとして記述し、コードとして管理します。ソース管理やCI/CDに乗せたい、本番運用を見据えたい場合はこちらです。パイプライン定義はおおよそ次のような形になります。
resources:
pipelines:
pipeline_sfdc:
name: salesforce_pipeline
catalog: my_catalog
schema: my_schema
ingestion_definition:
connection_name: <salesforce-connection>
objects:
- table:
source_schema: objects
source_table: Account
destination_catalog: my_catalog
destination_schema: my_schema
みっつめがDatabricksノートブックです。ノートブック上でパイプライン構成を記述して実行します。
入門としてはUIが分かりやすく、運用に乗せる段階でDABへ移行する、という流れが自然です。
Unity Catalog による統制
繰り返しになりますが、Lakeflow Connect で取り込んだデータは、最初から Unity Catalog 配下の Delta テーブルになります。これは地味ですが重要な性質です。
取り込んだ瞬間から、テーブルには Unity Catalog の権限管理が効きます。誰がどのテーブルを参照できるかを一元的に制御でき、データの出所をたどるリネージも自動で記録されます。取り込みツールとガバナンスが別々の製品に分かれていると、「取り込んだはいいが統制が後回し」になりがちですが、Lakeflow Connect ではそこが最初から一体化しています。
なお、Salesforce のように型体系が独自なソースでは、ソースのデータ型が Delta 互換のデータ型に自動変換されます。変換ルールはコネクタごとにドキュメントへ整理されています (例: Salesforce 取り込みコネクタのリファレンス)。
コスト: 無料枠について
Lakeflow Connect には無料枠があります。各ワークスペースは毎日100の無料DBUを受け取り、対象のマネージドコネクタ全体で1日あたり最大1億レコードまで取り込めます。
入門レベルの検証であれば、この無料枠の範囲で十分に試せます。「コストが読めないから手を出しにくい」という入口のハードルが、ひとつ下がったことになります。詳細は日本語ブログ「Lakeflow Connectでビジネスインサイトを加速、無料枠も提供開始」を参照してください。
データエンジニアリングのワークフローの中での位置づけ
最後に、Lakeflow Connect を単体ではなく、ワークフロー全体の中で捉えておきます。
Lakeflow Connect が担うのは「取り込み」です。その先には、取り込んだ生データを変換・加工する工程があり、ここは Lakeflow Spark 宣言型パイプライン (SDP) が担当します。さらにその先に、分析・BI・AIといった活用があります。
取り込み (Connect)、変換 (SDP)、活用。この流れの最初のピースが Lakeflow Connect だと捉えると、製品の位置づけがすっきりします。Connect で取り込んだ Unity Catalog 上のテーブルを、そのまま SDP の入力にできるため、取り込みから変換までが地続きでつながります。
まとめ
Lakeflow Connect の全体像を、概念中心に整理しました。要点は次の通りです。
- Lakeflow Connect は、データ取り込みをマネージド・サーバーレス・Unity Catalog 統制・増分取り込みで引き受ける機能
- コネクタにはSaaS系とデータベース系の2系統があり、後者は取り込みゲートウェイとソース側設定のぶん準備が重い
- 増分取り込みは、初回フルロード後に変更分だけを取り込むしくみで、方式はソースごとに自動で選ばれる
- パイプラインの作成方法はUI・DAB・ノートブックの3通り
- 無料枠ができ、検証の入口のハードルが下がった
実際に手を動かす際は、準備の軽いSaaSコネクタ、たとえば Salesforce から始めるのがおすすめです。具体的な作成手順は、別途ハンズオン記事として書く予定です。