Databricks のロゴ

Databricks / リリースノート / 2026/05/01 / 通常

Databricks 2026年5月1日のリリースノート解説: Lakeflow Connect の Community connectors Beta

dataworkflow

公式リリースノート

Databricks は 2026年5月のリリースノートで、Lakeflow Connect の Community connectors を Beta として案内しました。Databricks が管理する connector だけでは対応しきれないデータソースに対し、オープンソースの connector を使う、または自社で custom connector を作る道筋が整理された更新です。

要点

  • Lakeflow Connect に Community connectors が Beta として追加された
  • Databricks managed connector がないデータソースでも、registered connector や custom connector を使って取り込みを構成しやすくなる
  • connector は LakeflowConnect interface と Spark Python Data Source API を前提に、認証、schema discovery、incremental read を実装する
  • Community connector は Databricks が保守する managed connector ではないため、SLA、互換性、コード管理、credential 管理を確認したい

今回のリリースノートで語られていること

2026年5月の Databricks release notes では、Community connectors が Lakeflow Connect を拡張する仕組みとして紹介されています。Databricks の公式ドキュメントでは、Community connectors はコミュニティが構築・保守する open-source connector と説明されており、Databricks がまだ managed connector を提供していないソースからデータを取り込むための選択肢になります。

使い方は大きく2つです。1つ目は、すでに登録されている community connector を使って、対象ソースから Databricks workspace へデータを取り込む方法です。2つ目は、自社やチームが必要とする source API に合わせて custom connector を作る方法です。custom connector では、LakeflowConnect interface に沿って、認証、テーブル一覧、schema、metadata、incremental read、必要に応じた delete 読み取りなどを実装します。これにより、単なる一回限りのスクリプトではなく、Lakeflow Spark Declarative Pipelines の取り込みパイプラインとして動かせる形に近づきます。

実務上の価値は、未対応ソースの取り込みを待つだけでなく、自社の優先度に合わせて connector を前倒しで用意できる点にあります。SaaS、社内API、業界固有システムなど、標準 connector が揃うまで時間がかかるソースでも、認証・schema discovery・incremental read の責務を connector にまとめることで、取り込み運用を標準化しやすくなります。

一方で、Beta であり community-maintained である点は重要です。Databricks managed connector と同じ保守前提ではないため、connector のコード品質、依存関係、credential の扱い、エラー処理、rate limit、schema evolution、削除データの扱いを自チームで確認する必要があります。とくに本番データパイプラインで使う場合は、検証環境でのテスト、monitoring、fallback、connector のバージョン固定を決めてから採用したい更新です。

対象になりそうなユーザー・チーム

  • Lakeflow Connect を使ってSaaSや業務システムからデータを取り込んでいるデータエンジニア
  • managed connector がないデータソースの取り込みを急ぎたい分析基盤チーム
  • Unity Catalog と Lakeflow を前提にデータ取り込み標準を整備しているプラットフォーム担当
  • connector の保守、認証、schema evolution、運用監視を管理するチーム

実務で確認したいポイント

まず、自社で取り込みたい source が registered community connector として存在するかを確認します。存在する場合でも、その connector がどの認証方式、どのテーブル、どの incremental read 方式、どの deletion handling をサポートするかを見ます。

custom connector を作る場合は、LakeflowConnect interface の実装が運用境界になります。API pagination、rate limit、retry、schema drift、primary key、cursor field、CDC / append-only / snapshot の扱いを曖昧にしたまま本番投入すると、後から差分取り込みや再実行で困りやすくなります。

また、workspace admins が Preview / Beta 機能へのアクセスをどう制御するかも確認が必要です。Community connectors は便利ですが、外部コードを workspace に取り込んで実行する性質があるため、コードレビュー、GitHub repository の信頼性、依存パッケージ、credential の保管場所を governance に含めたいところです。

今すぐ対応が必要か

managed connector がないソースの取り込みを抱えているチームは、早めに検証する価値があります。すでに安定した取り込み基盤がある場合は急ぐ必要はありませんが、Lakeflow Connect へ取り込み標準を寄せたい組織では、Community connectors をPoC候補として評価しておくとよさそうです。

結局、この更新をどう見るべきか

Community connectors Beta は、Databricks のデータ取り込み範囲を managed connector の外側へ広げる更新です。便利さの反面、保守責任と運用設計は利用側に寄るため、未対応ソースを早く取り込みたいチームほど、connector の品質とガバナンスをセットで評価するべきです。