第2章 データ取り込みとロード / 想定学習時間:30〜40分 / 最終確認:2026年8月

2-4. Lakeflow Connect(標準コネクタ・マネージドコネクタ)

🎯 この節の学習目標

1. Lakeflow Connect とは

Lakeflow Connect は、Databricks が提供するデータ取り込みサービスです。クラウドストレージのファイルから、SaaS アプリケーション、リレーショナルデータベースまで、多様なエンタープライズソースのデータを Unity Catalog 管理下のテーブル(UC-governed tables)へ取り込む入口を一手に引き受けます。Databricks のデータエンジニアリング製品群「Lakeflow」は、Connect(取り込み)宣言型パイプライン(変換)Jobs(旧 Workflows、オーケストレーション)の3層で構成されており、Connect はその最上流に位置します。

2-2・2-3 で学んだ COPY INTO や Auto Loader が「自分でコードを書く取り込み」だとすれば、Lakeflow Connect の特にマネージドコネクタは「設定だけで完結する取り込み」を提供します。

2. 標準コネクタとマネージドコネクタ

Lakeflow Connect のコネクタは大きく2種類に分かれます。この区別が本節の中心です。

観点標準コネクタ(standard connectors)マネージドコネクタ(managed connectors)
対象ソース(種別)クラウドオブジェクトストレージ(S3 / ADLS / GCS)と、メッセージバス(Apache Kafka、Amazon Kinesis などのストリーミングソース)SaaS アプリケーション(CRM・営業支援・人事・分析系など)とデータベース(各種 RDB)
実体Auto Loader や Structured Streaming を土台に、自分でパイプラインを構成する(コードやパイプライン定義を書く)Databricks が接続・抽出・増分管理まで面倒を見るフルマネージドの取り込みパイプライン(UI 中心で設定)
運用負荷パイプラインの構成・監視・障害対応は自分の責任小さい(セットアップのみ。以降の運用は Databricks 管理)
カスタマイズ性高い(オプション・変換を自由に組める)設定項目の範囲内(そのぶん運用負荷が小さい)
ストリーミング要否低遅延のストリーミング取り込みに対応(メッセージバスのソースはこちら)スケジュールに基づく定期的な増分同期が基本形
増分の仕組みチェックポイント等を自分で設計(2-3)コネクタが変更の追跡(CDC 的な増分抽出)を内蔵
宛先どちらも Unity Catalog 管理下のテーブル

標準コネクタの具体像をもう少し補足します。1つ目の対象であるクラウドオブジェクトストレージからのファイル取り込みは、2-3 で学んだ Auto Loader がその中核です。2つ目の対象であるメッセージバスは、Apache Kafka や Amazon Kinesis のようにイベントが継続的に流れ込むストリーミングソースを指します。センサーデータやクリックログのように低遅延で取り込みたいデータは、マネージドコネクタではなく標準コネクタ経由、すなわち Structured Streaming を土台に自分でパイプラインを構成して取り込みます。どちらの標準コネクタも「部品は Databricks が提供し、組み立てと運用は自分が行う」という点で共通しています。

一方のマネージドコネクタは、CRM のような SaaS アプリケーションや各種リレーショナルデータベースを対象に、接続の設定さえ済ませれば抽出・増分管理・失敗時の再試行まで Databricks が運用する「セットアップのみで完結する」取り込みです。ソースが同じ「データベース」でも、マネージドコネクタが未対応の場合は自前の JDBC 実装(2-5)に落ちる、という優先順位も合わせて押さえておきましょう。

📝 試験のポイント

選択肢の見分け方はシンプルです。ソースがファイル(クラウドストレージ)や Kafka・Amazon Kinesis などのメッセージバスなら標準コネクタ(Auto Loader / Structured Streaming 系で自分で構成)、ソースがSaaS アプリケーションやデータベースならマネージドコネクタ。とくに「コードを書かずに」「フルマネージドで」「業務アプリのデータを」という言い回しが出たらマネージドコネクタ、「ストリーミングで」「メッセージバスから」ならば標準コネクタを指しています。

3. マネージドコネクタの設定の流れ

マネージドコネクタのセットアップは、おおむね次の4ステップで完了します。UI(またはAPI)から設定でき、抽出コードは書きません。

① 接続(Connection)の作成ソースへの認証情報を UC のセキュアなオブジェクトとして登録
② ソースの選択取り込むオブジェクト(テーブル・エンティティ)を選ぶ
③ 宛先の指定Unity Catalog のカタログ・スキーマ・テーブルを指定
④ スケジュールの設定同期の周期を決める(内部的に取り込みパイプラインが実行される)
UC 管理テーブルに増分同期変更分がコネクタにより自動反映

図:マネージドコネクタ設定の4ステップ

ここで作る接続(Connection)は Unity Catalog のオブジェクトであり、認証情報の管理や利用権限の制御が UC のガバナンスに統合されます。「誰がこの SaaS への接続を使えるか」までテーブルと同じ権限モデルで管理できるのが特長です。

4. 半構造化・非構造化データへの対応

Lakeflow Connect の取り込み対象は、行と列のきれいな表形式データに限りません。

「構造化・半構造化・非構造化のいずれもレイクハウスに一元化する」というレイクハウスアーキテクチャの思想が、取り込みの入口である Lakeflow Connect にもそのまま反映されています。

5. パートナーコネクタとの関係

Databricks には以前から、外部のデータ統合ベンダーの製品と連携するパートナーコネクタ(Partner Connect)の仕組みがあります。Lakeflow Connect のマネージドコネクタがまだ対応していないソースでも、パートナー製品が対応していれば取り込みを実現できます。

選択肢位置づけ選ぶ場面
Lakeflow Connect マネージドコネクタDatabricks ネイティブのフルマネージド取り込み対応ソースであれば第一候補。UC ガバナンスとの統合が最も深い
パートナーコネクタ外部ベンダー製品による取り込みマネージドコネクタ未対応のソース、既にパートナー製品を全社導入している場合
自前実装(JDBC / REST)ノートブック+Lakeflow Jobs で自作(2-5)どのコネクタも対応していない、特殊な抽出ロジックが必要な場合

6. どんな要件でマネージドコネクタを選ぶか

次の条件がそろうほど、マネージドコネクタが最適解になります。

💡 具体例:営業データの日次同期

ある企業の営業チームが SaaS の営業支援アプリケーションで商談データを管理しており、分析チームは毎朝それをレイクハウスで参照したいとします。マネージドコネクタなら、(1) 営業アプリへの接続を作成、(2) 商談・取引先のオブジェクトを選択、(3) 宛先を main.sales.opportunities などの UC テーブルに指定、(4) 毎朝6時のスケジュールを設定 — の4手順で完了します。以後の増分抽出・スキーマの追随・失敗時の再試行はコネクタが担い、分析チームは着地したテーブルに対して第3章の変換処理を書くだけです。

✅ この節のまとめ

練習問題

問1. あるチームには2つの取り込み要件がある。(1) IoT センサーのイベントが Apache Kafka のトピックに流れ込んでおり、低遅延のストリーミングで取り込みたい。(2) 営業部門の SaaS アプリケーション(CRM)のデータを、コードを書かずに定期同期したい。Lakeflow Connect のコネクタの割り当てとして正しい組み合わせはどれか。

  1. (1) マネージドコネクタ、(2) 標準コネクタ
  2. (1) 標準コネクタ(Structured Streaming を土台に自分で構成)、(2) マネージドコネクタ(フルマネージド同期)
  3. (1) も (2) もマネージドコネクタ(すべてのソースをフルマネージドで取り込める)
  4. (1) も (2) も標準コネクタ(マネージドコネクタはクラウドストレージ専用)
解答と解説を見る

正解:B

Kafka や Amazon Kinesis のようなメッセージバスからのストリーミング取り込みは標準コネクタの守備範囲で、Structured Streaming を土台に自分でパイプラインを構成します。一方、SaaS アプリケーションやデータベースはマネージドコネクタの対象で、セットアップだけでフルマネージドに同期できます。Aは割り当てが逆です。Cは誤りで、メッセージバスはマネージドコネクタの対象ではありません。Dも誤りで、マネージドコネクタの対象はクラウドストレージではなく SaaS・データベースです。

問2. マネージドコネクタでの取り込み設定の流れとして正しい順序はどれか。

  1. スケジュール設定 → 宛先指定 → 接続作成 → ソース選択
  2. 接続の作成 → 取り込むソースオブジェクトの選択 → 宛先 UC テーブルの指定 → スケジュールの設定
  3. 宛先テーブルの作成 → データの手動エクスポート → アップロード UI → スケジュール設定
  4. クラスタ作成 → ノートブック作成 → 抽出コードの記述 → ジョブ登録
解答と解説を見る

正解:B

「接続 → ソース選択 → 宛先 → スケジュール」の4ステップが基本の流れです。まず認証情報を UC の接続オブジェクトとして登録しなければ、ソースの一覧も取得できません(Aのような順序は成立しません)。Cは手動運用でありマネージドの利点を捨てています。Dは自前実装(2-5)の手順であり、マネージドコネクタでは抽出コードを書きません。

問3. 人事部門が使う SaaS アプリケーションの従業員データを、増分同期でレイクハウスに取り込みたい。開発チームは抽出コードの保守を避けたい方針である。対応するマネージドコネクタが存在する場合、最も適切な選択はどれか。

  1. SaaS の REST API に対して requests で抽出コードを書き、Lakeflow Jobs でスケジュールする
  2. SaaS から日次で CSV をエクスポートし、クラウドストレージ経由で COPY INTO する
  3. Lakeflow Connect のマネージドコネクタを設定する
  4. SaaS のデータベースに JDBC で直接接続する
解答と解説を見る

正解:C

対応するマネージドコネクタがあるなら、それが第一候補です。増分同期を内蔵し、抽出コードの保守が不要という要件に完全に一致します。AはAPI仕様変更への追随やエラー処理を自前で保守する必要があり、方針に反します。Bはエクスポートの手動運用または追加の自動化が必要で遠回りです。Dは一般に SaaS の内部データベースへの直接接続は提供されておらず、現実的ではありません。

問4. Lakeflow Connect の標準コネクタとマネージドコネクタの違いとして正しいものはどれか。

  1. 標準コネクタは有料、マネージドコネクタは無料という課金の違いである
  2. 標準コネクタはクラウドストレージ等を対象に自分でパイプラインを構成し、マネージドコネクタは SaaS・データベースを対象に取り込みをフルマネージドで提供する
  3. 標準コネクタの宛先は外部テーブル、マネージドコネクタの宛先は UC 管理テーブルと決まっている
  4. マネージドコネクタはリアルタイム専用で、バッチ同期には使えない
解答と解説を見る

正解:B

両者の違いは「対象ソース」と「誰がパイプラインを管理するか」です。標準コネクタはストレージやメッセージバスを対象に Auto Loader 等で自分で構成し、マネージドコネクタは SaaS・DB を対象に Databricks が管理します。Aのような課金区分の定義ではありません。Cは誤りで、どちらも UC 管理テーブルへ着地させるのが基本です。Dも誤りで、マネージドコネクタはスケジュールに基づく定期同期(バッチ的な増分同期)が基本形です。