Lakebridge：Databricksへのデータ移行を支援するツール

 

---

---

1. はじめに

背景

近年、多くの企業では、PostgreSQL、SQL Server、Oracle、Teradataなどの従来型データベースやEDW（Enterprise Data Warehouse） から、Databricks Lakehouseへの移行が進められています。その目的は、大規模データ分析やAI/MLの活用を単一の統合プラットフォーム上で実現することにあります。

しかし、データマイグレーションは単にデータをコピーするだけではありません。実際には、以下のような複数の工程を含む複雑なプロセスです。

• スキーマのマッピングとデータ型の標準化
• 増分ロード（Incremental Load）の設計
• データ品質の検証
• Unity Catalogへの登録
• アクセス権限の設定
• Job／Workflowを利用した定期実行の自動化

これらの作業を手動で実施する場合、ソースシステムごとに異なる移行方法を検討する必要があり、標準化が難しく、導入・運用・引き継ぎにかかるコストも増大します。

Databricks Lakebridgeは、こうした課題を解決するために設計されたツールです。レガシーデータプラットフォームと Databricks Lakehouseをつなぐ「ブリッジ」として機能し、マイグレーションプロセスの標準化と自動化を支援することで、移行リスクとTCO（Total Cost of Ownership：総保有コスト） の削減に貢献します。

目的

本記事では、実践のデモを通じてDatabricks Lakebridgeの役割と、Databricks へのマイグレーションにおける活用方法を紹介します。

Lakebridge全体のアーキテクチャと主要機能を理解し、実際のマイグレーションプロジェクトへ活用するための基礎知識を習得することを目的としています。

目標

本記事を通じて、読者は以下の内容を理解できるようになります。

• データマイグレーションにおけるDatabricks Lakebridgeの役割
• Lakebridgeを利用するための前提条件と環境要件
• Assessment、Transpile、Reconcileの各機能とサポート範囲
• SQLサーバーからDatabricks SQLへのマイグレーションを例に、Lakebridgeの基本的な利用方法を習得する
• 実際のマイグレーションプロジェクトでLakebridgeを利用する際の注意点と制約事項

2. 前提条件

本手順を実施する前に、以下の条件を満たしていることを確認してください。

• Unity Catalogが有効化されたAzure Databricksワークスペース が利用可能であること
• Databricks CLIがインストールされており、対象のワークスペースへの認証が完了していること
• Python3.10 ～ 3.14がインストールされていること
• Java 21以降がインストールされていること
• GitHub、Maven Central、およびPyPIにアクセス可能なネットワーク環境であること
  ※プロキシ環境を利用している場合は、各エンドポイントに対して適切なプロキシ設定が必要です。
• 読み取り権限を持つ移行元SQLサーバーの接続情報を準備していること

※ネットワーク要件について

Lakebridge のインストールおよび各種コンポーネントのダウンロードには、GitHub、Maven Central（Java ライブラリ）、および PyPI（Python パッケージ）へのアクセスが必要です。

企業ネットワークでプロキシやファイアウォールによりこれらのサイトへのアクセスが制限されている場合は、事前にプロキシ設定またはミラーリポジトリの構成を行ってください。

3. Databricks Lakebridgeとは

Databricks Lakebridgeは、Databricks Labsが2025年6月に公開した、無料のオープンソース マイグレーションツールです。レガシーシステムからDatabricksへのSQLマイグレーションをエンドツーエンドで管理・自動化することを目的として設計されています。

Databricksが公開している主な指標は以下のとおりです。

• マイグレーション作業の最大80%自動化
• マイグレーションの実施速度を最大2倍に向上
• 1,000社を超える顧客およびパートナーの利用中

Lakebridgeの最大の特徴は、マイグレーションプロセスを次の3つのフェーズに体系化している点です。

• Assessment（事前評価フェーズ）：移行元システムを分析し、SQLコードの複雑さやデータ量を評価して、マイグレーションの実施計画を立てます。
• Code Conversion（コード変換フェーズ）：レガシーSQLやETLコードを、Databricksで実行可能な形式へ自動的に変換します。
• Validation（データ照合フェーズ）：マイグレーション後のDatabricks 上のデータと移行元システムのデータを比較し、両者が一致していることを検証します。

これら3つのフェーズは、それぞれ独立して実行できます。
例えば、事前評価が完了している場合はTranspileのみを実行し、コード変換を手作業で実施済みの場合はReconcileのみを利用してデータ整合性を確認することも可能です。

Lakebridgeを導入することで、企業は次のようなメリットを得られます。

• マイグレーションプロセスを標準化し、チーム間の引き継ぎコストを削減できる
• コード変換を自動化することで、手作業による開発工数を削減し、マイグレーションのリスクを低減できる
• Reconcileによる定量的な検証を通じて、マイグレーション後のデータ品質を保証できる
• 複数の移行元プラットフォームに対して、統一されたアプローチでマイグレーションを実施できる

4. Lakebridgeの主な機能

4.1 Assessment :マイグレーション前の評価

Assessmentフェーズでは、マイグレーションを実施する前に、移行元環境のSQLコードやデータを調査・分析します。

このフェーズの目的は、マイグレーションの規模やリスクを正確に把握し、適切な移行計画を立てることです。

Assessmentフェーズは、Profiler、AnalyzerおよびSQL Splitterの3つのツールで構成されています。

4.1.1 Profiler

Profiler は現在試験提供(Experimental)段階のツールであり、移行元システムへ直接接続して、データベースのメタデータ、クエリの実行性能、およびシステムのワークロード構成に関する情報を収集します。

目的:

移行元データベースのスキーマ、クエリパターン、およびデータ量を包括的に把握し、Databricksへ移行した場合のコスト削減効果を見積もることを目的としています。
特に、マイグレーションのスコープ評価（Scoping）を行い、経営層やアーキテクチャチームへ移行計画を提案する際に適しています。

対応プラットフォーム

Profilerは、以下の7つの主要なデータプラットフォーム向けに組み込みコネクタを提供しています。
・Azure Synapse

・Snowflake

・Microsoft SQL Server

・Legacy Synapse (Dedicated SQL Pool)

・Oracle

・Google BigQuery

・Amazon Redshift

出力結果

収集した情報は、タイムスタンプ付きのスナップショットファイルとして保存されます。
また、visualize-profiler-results コマンドを実行することで、分析結果をDatabricksワークスペース内のLakeviewダッシュボード として可視化することもできます。

※ 注意事項
Profilerは7種類の移行元プラットフォームから情報を収集できますが、Lakeviewダッシュボードの自動生成が正式にサポートされているのは、現時点ではAzure Synapseのみです。
Microsoft SQL ServerやSnowflakeなどのその他のデータソースについては、収集結果はスナップショットとして正常に出力されますが、分析を行うには、ユーザー自身でUnity Catalogにデータを取り込み、Lakeview上でダッシュボードを作成する必要があります。

4.1.2 Analyzer

Analyzerは、レガシーETLパイプラインやSQLアセットのメタデータを解析し、マイグレーションコストの見積もり、依存関係の分析、および複雑度レポートの作成を行うツールです。

目的:

Analyzerの目的は、マイグレーション対象となるワークロードの規模とリスクを定量的に評価し、必要な工数やライセンスコストを見積もるための基礎情報を提供することです。
Profilerが主に「データ量」や「クエリパターン」を分析するのに対し、Analyzerは「コードの複雑さ」や「コンポーネント間の依存関係」を詳細に分析することに重点を置いています。

主な機能

• レガシーシステムに含まれるマッピング、変換ロジック、関数、変数 などのコンポーネントを網羅的にインベントリ化する。
• ジョブ間およびシステム間の依存関係を可視化し、安全なカットオーバー計画の立案を支援する。
• 各アセットを4段階（低・中・高・非常に高） の複雑度で評価し、マイグレーションの優先順位や手動レビューの必要性を判断するための指標を提供する。
• 複数のワークシートを含むExcelレポート を自動生成する（※必要に応じてJSON形式での出力にも対応）

事前準備:

Analyzerを実行する前に、移行元システムからSQLスクリプトをエクスポートする、またはETLリポジトリをXMLまたはJSON形式でローカルディレクトリへ展開しておく必要があります。
エクスポート方法は利用するプラットフォームによって異なります。例えば、

• Microsoft SQL Server：SQL Server Management Studio（SSMS） の「Generate Scripts」ウィザードを使用する
• IBM DataStage：ETLリポジトリをXML形式でエクスポートする

Analyzer は、各アセットの複雑度を以下の 4 段階 に分類します。

複雑度	特徴	推奨されるコード変換エンジン
低 (Low)	シンプルな構造であり、ルールベースの変換エンジンによって高い精度で自動変換できます。	Morpheus / BladeBridge
中 (Medium)	一般的な構造であり、ルールベースの変換エンジンで対応可能ですが、軽微なレビューを推奨します。	Morpheus / BladeBridge
高 (High)	複雑な手続き型ロジックを含んでおり、少なくとも2回の手動レビューを推奨します。	Switch (LLM)
非常に高 (Very High)	自動変換の適用範囲を超える複雑な処理を含み、多くの箇所で手動対応が必要です。	Switch (LLM) + 手動処理

判断基準:

マイグレーション対象のアセットの50%以上 が 「高」 または 「非常に高」 と評価された場合は、プロジェクト計画において少なくとも2回の手動レビュー を実施することを推奨します。

4.1.3 SQL Splitter

SQL Splitterは、複数のデータベースオブジェクト定義が混在した大規模なSQLスクリプト（モノリシックなSQLスクリプト）を解析し、データベースオブジェクトごとに個別のファイルへ分割するとともに、オブジェクトの種類に応じて適切なディレクトリへ自動的に分類するユーティリティです。

目的:

SQLコードをより小さな単位へ分割することで、後続のTranspileおよびAnalyzerフェーズにおける解析・変換精度を向上させることを目的としています。

大規模な SQL スクリプトをそのまま解析・変換すると、変換精度の低下やエラーの増加につながる可能性があるため、事前に SQL Splitter を実行することが推奨されています。

主な機能: 

• 複数のSQLスクリプトに含まれるTABLE、VIEW、PROCEDURE、FUNCTION、SEQUENCEなどのデータベースオブジェクトを抽出し、オブジェクトごとに独立したファイルへ分割する。
  Oracle Packageを解析し、複雑なパッケージを個別のFUNCTIONやPROCEDUREファイルへ自動的に分割する（※必要に応じてグローバル変数を保持することも可能）
• Windows、Linux、macOS向けの実行バイナリが提供されており、コマンドライン引数を指定してターミナルから直接実行できる。

※ 注意事項:このコマンドラインツールを実行する前に、出力先として指定するディレクトリをあらかじめ作成しておく必要があります。

4.2 Transpile：SQLコードの変換

Transpileフェーズでは、レガシーSQL、ETLパイプライン、およびオーケストレーションワークフローを、Databricksで実行可能なコードへ変換します。

Lakebridgeでは、用途や移行元システムに応じて、次の 3 種類のトランスパイラー（Transpiler）が提供されています。

• Morpheus：AST（Abstract Syntax Tree）ベースの変換エンジンで、高い変換精度を実現する
• BladeBridge：パターンベースの変換エンジンで、多様なSQLおよびETLプラットフォームに対応する
• Switch：LLMを活用した変換エンジンで、複雑なビジネスロジックやコンテキストを考慮した変換を実現する

移行元プラットフォームやプロジェクト要件に応じて、適切なトランスパイラーを選択できます。

変換エンジンを実行する前に、入力・出力ディレクトリや ソースSQLダイアレクト（例：Microsoft SQL Server、Oracle、Snowflake）などの各種パラメーターを設定する必要があります。

また、Lakebridgeでは、変換後のSQLを移行先DatabricksのCatalogおよびSchema上で検証するSQLバリデーション 機能も提供されています。

ただし、このバリデーション機能は デフォルトでは無効 となっています。利用する場合は、「skip-validation=false」を設定するとともに、Databricksへの接続情報など、必要な設定を追加で構成する必要があります。

4.2.1 Morpheus

Morpheusは、AST（Abstract Syntax Tree：抽象構文木） を利用したSQLトランスパイラーです。

変換処理は、以下の3段階のパイプラインで実行されます。

①ソースコードをASTに解析する

②変換ルールを適用する

③Databricks SQLを生成する

対応するソースSQLダイアレクト

• Microsoft SQL Server
• Snowflake
• Azure Synapse

変換先：Databricks SQL

Morpheusの最大の特徴は、変換後のファイルにエラーや警告が含まれていない場合、Databricks上でも移行元と同等の処理結果が得られることが保証される点です。これは、MorpheusがSQLを構文レベルで厳密に解析したうえで変換を行うために実現できる品質保証です。

エラー処理

• 変換できなかった構文が存在する場合は、その箇所の行番号および列番号を含む説明コメントが、出力ファイルの先頭に自動的に追加されます。
• 変換後のロジックが移行元と完全に等価であることを確認できない場合は、警告（Warning） が付与され、移行元データと比較しながら手動で確認する必要があることが示されます。

ライセンス：無料（※ローカル環境で実行可能）

4.2.2 BladeBridge

BladeBridgeは、設定駆動型（Configuration-driven） の変換エンジンです。

変換ルールはJSON設定ファイル によって管理されており、幅広い SQL ダイアレクトに加え、複雑なレガシー ETL プラットフォームにも対応しています。

対応する移行元プラットフォーム:

• SQLプラットフォーム：Oracle、Teradata
• ETLプラットフォーム：IBM DataStage、SQL Server Integration Services（SSIS）

出力形式:

• SQLファイル: 移行元のSQLファイルごとに、1:1 の対応関係でDatabricks互換のSQLファイルを生成します。Stored ProcedureはDatabricks SQL Scripting形式へ変換されます。
• ETLジョブ（DataStage、SSIS など）:Transformation Logicは、モジュール化されたDatabricks Notebookとして生成されます。OrchestrationやWorkflow 定義は、Databricks WorkflowのJSON定義へ変換されます。
• 高度なカスタマイズ: BladeBridgeの設定は、CLIパラメーター とJSONオーバーライドファイルの2層構成 となっています。この仕組みにより、標準のマイグレーションロジックを変更することなく、JSON設定ファイルを利用して安全にカスタマイズできます。また、複雑なフロー制御が必要な場合は、外部Perlコールバックルーチン に処理を委譲することも可能です。

ライセンス：無料（※ローカル環境で実行可能）

※SSIS利用時の注意事項

• Script Task内で実装された「C#」または「VB.NET」のカスタムコードは自動変換の対象外であり、Pythonで手動実装する必要があります。
• FTP TaskやSend Mail Taskは直接変換されませんが、Pythonのftplib、dbutils.fs、smtplib、またはDatabricks Job Notificationsなどを利用して同等の処理を実装できます。
• SQL Server Analysis Services（SSAS）のAnalysis Services Processing TaskはSQL Server固有の機能であり、Databricksに直接対応する機能が存在しないため、個別に評価したうえで再設計または手動変換が必要です。
• SSISでは「target-tech=SPARKSQL」のみサポートされており、PySparkはサポートされていません

4.2.3 Switch（試験提供機能）

Switchは、LLM（Large Language Model） を活用した試験提供中のトランスパイラーです。

Databricks Mosaic AI Model Servingを利用してコードの文脈や意図を理解し、構文ルールだけに依存するのではなく、コードの意味（セマンティクス） に基づいて変換を行います。

実行環境: 変換処理はDatabricksワークスペース上のJobとして実行され、Serverless ComputeおよびUnity Catalogのストレージを利用します。

対応フォーマット: 標準で9種類の主要なSQLダイアレクト（Microsoft SQL Server、Snowflake、Oracle など）に対応しているほか、Airflow DAG や PySpark Pipeline などの SQL 以外のアセット に対しても、あらかじめ用意されたプロンプトを利用できます。

主な特徴:

• MorpheusやBladeBridgeでは対応が難しい複雑な手続き型ロジックや、特殊なエッジケースにも対応できます。
• 標準では対応していないソース形式や特殊なマイグレーション要件に対しては、YAML形式のカスタムプロンプトを作成することで対応できます。
• 構文エラー自動修正 機能を備えており、構文エラーを検出すると、修正対象のコードをLLMに再送信し、自動的に修正を繰り返します。
• ClaudeのExtended Thinking Modeを有効にすることで、コード変換の精度をさらに向上させることができます。
• 1ファイルあたりのデフォルトの上限は20,000トークン です。この上限を超えるファイルは自動的にスキップされます。
• 変換処理は 非同期（Asynchronous） で実行されます。ジョブ開始後すぐに Job URL が返され、進行状況は Databricks Jobs UI から確認できます。
• 変換後の Notebook サイズが 10 MB を超えた場合は、ワークスペースへ保存できません。

費用: Databricks Mosaic AI Model Servingの利用に伴い、APIトークン使用量に応じた料金が発生します。

4.3 Reconcile：データの参照

Reconcileフェーズでは、マイグレーション後のDatabricks上のデータが、移行元システムのデータと正しく一致しているかを検証します。

このフェーズの目的は、データマイグレーションの品質を定量的に評価するとともに、データの不整合を早期に検出することです。

Reconcileでは、以下の4種類の検証レポート を実行できます。

• Schema Validation (schema)：移行先テーブルのスキーマが移行元と一致していることを検証します。主に、カラム名、データ型 などを比較します。
• Row Hash Validation (row)：行単位の ハッシュ値 を比較し、データの一致性を高速に検証します。
• Column-by-Column Validation (data)：各カラムの値を詳細に比較し、不一致となるデータを特定します。
• All (all)：Schema Validation、Row Hash Validation、およびColumn-by-Column Validationをまとめて実行します。

5. 実践デモンストレーション実施：SQL ServerからDatabricksへのマイグレーション

以下では、SQL Server環境からDatabricks SQLへのマイグレーションを例に、Lakebridgeの基本的な利用フローを紹介します。

本デモは、Lakebridgeの公式Quick Start Guideをもとに構成しており、Assessment → Transpile → Reconcile の一連のマイグレーションフローを体験できる内容となっています。

SQL ServerからDatabricks SQLへのマイグレーションフロー概要（Lakebridge)

5.1 環境の準備

まず、Lakebridgeおよび関連する変換コンポーネントをインストールします。

① Lakebridgeのインストール

以下のコマンドを実行し、Databricks CLIを使用して Lakebridgeのコアツールをインストールしま

このコマンドを実行すると、現在認証済みのDatabricksワークスペースへ、Databricks Labsの仕組みを利用してLakebridgeがデプロイされます。

インストール完了後は、以下のコマンドを実行して、利用可能なLakebridgeコマンドを確認できます。

Databricks CLI経由でLakebridgeのインストール完了画面

実行すると、次のようなLakebridgeのコマンド一覧が表示されます。

• analyze
• transpile
• reconcile
• llm-transpile
• install-transpile

これらのコマンドが表示されれば、Lakebridgeの実行環境が正しく構築され、コード解析およびマイグレーションを実行する準備が整っていることを確認できます。

② Transpilerのインストール

コード変換機能（Transpiler）は、Lakebridgeのコアツールとは別のコマンドでインストールします。

コマンドを実行すると、Lakebridge は対話形式で Transpiler の設定を行います。設定する主な項目は以下のとおりです。

• Source Dialect：移行元データベースの SQL ダイアレクトを選択します。
  例：Microsoft SQL Server、Oracle、Snowflake など
• Transpiler Engine：使用する変換エンジンを選択します。本デモでは Morpheus を使用します。
• Input SQL Path：変換対象となるSQLファイルが格納されたディレクトリを指定します。
• Output Folder：Databricks SQLへ変換した結果を出力するディレクトリを指定します。
• Error File Path：変換中に発生したエラーや警告を記録するログファイルの保存先を指定します。
• Validation Option：変換後のSQLに対して構文や妥当性の検証を実施するかどうかを指定します。デフォルトでは、この機能は無効になっています。

※LLMを利用したSwitchエンジンを使用する場合は、インストール時に専用のオプションフラグを指定する必要があります。

5.2 Lakebridgeを使用したSQL変換の例

インストールが完了したら、SQL Serverのソースコードを対象に、実際のマイグレーションを実行します。

① Analyzerを実行してSQLオブジェクトの分析

Analyzerを実行し、各SQLオブジェクトの複雑度を評価するとともに、マイグレーション計画の基礎資料となるExcelレポートを生成します。

各オプションの意味は以下のとおりです。

• –source-tech：移行元プラットフォームを指定します。
  ※本例では mssqlを指定します。
• –source-directory：分析対象となるSQLファイルを格納したディレクトリを指定します。
• –report-file：出力するExcelレポート（.xlsx）の保存先を指定します。ディレクトリではなく、ファイルパスを指定する必要があります。
• 実行結果
  Analyzerの実行後、複数のワークシートを含むExcelレポート が生成されます。各SQLオブジェクトには 「低」「中」「高」「非常に高」 の複雑度が割り当てられ、手動レビューが必要なファイル も明確に識別されます。

確認ポイント:

生成されたExcelレポート を確認し、「高」 または 「非常に高」 と評価されたオブジェクトの割合を把握します。

これらのオブジェクトは、自動変換後に手動レビューの対象としてマイグレーション計画へ組み込むことを推奨します。

Analyzerが生成した複雑度評価レポート（Excel形式）

② Morpheus TranspilerによるSQL変換
複雑度の評価が完了したら、Morpheusを使用してSQL ServerのSQLコードをDatabricks SQLへ変換します。

Morpheus は、SQL ServerからDatabricksへのマイグレーションにおいて、高い変換精度と品質保証を提供するため、推奨されるトランスパイラーです。

各オプションの意味は以下のとおりです。

• ––source-dialect mssql：移行元のSQLダイアレクトとしてSQL Serverを指定します。変換エンジン（Morpheus）は install-transpile 実行時に選択済みのため、ここで再度指定する必要はありません。
• ––input-source：変換対象となるSQLファイルが格納されたディレクトリを指定します。事前に準備したSQLファイルが格納されているディレクトリを指定します。
• ––output-folder：変換後のDatabricks SQLファイルを保存するディレクトリを指定します。
• —–catalog-name /––schema-name：SQLバリデーション時に使用するDatabricksのCatalogおよびSchemaを指定します。バリデーション機能はデフォルトでは無効になっているため、利用する場合は「–skip-validation=false」などの追加オプションを指定して有効化する必要があります。

Transpilerの実行結果

5.3 変換結果の検証

SQLコードの変換が完了したら、最後にReconcileを実行し、Databricks上のデータがSQL Serverの移行元データと一致していることを検証します。
① Reconcile環境のセットアップ

データ照合機能を利用する前に、以下のコマンドを実行して、ローカルストレージおよび実行環境を設定します。

セットアップ中に、以下の項目を設定します。

• Data Source：移行元のデータベース管理システムを選択します。
  ※本例ではSQL Serverを指定します。
• Report Type：実行する照合レポートの種類を選択します。
  ※schema、row、data、または all を指定できます。
• Unity Catalog Connection：Databricks上で作成済みのUnity Catalog Connectionを指定します。この接続を利用して移行元データベースへアクセスします。
• Source Catalog/Schema：照合対象となる移行元データベースのCatalogおよびSchemaを指定します。
• Target Catalog/Schema：マイグレーション後のデータが格納されているDatabricks側のCatalogおよびSchemaを指定します。

※実行前の準備：
Reconcileを実行する前に、Databricksワークスペースで以下の設定を完了しておく必要があります。

• Unity Catalog Connectionの作成：SQL Serverへ接続するためのUnity Catalog ConnectionをDatabricksワークスペース上で作成します。
• 「remote_query」プレビュー機能の有効化
  プレビュ で 「Enables remote query table-valued function (remote_query)」 を オン にします。

続いて、LakebridgeはReconcileで使用するメタデータの保存先をDatabricks上で設定します。

デフォルトでは、以下の設定が使用されます。

• Catalog metadata：Reconcileに必要なすべてのオブジェクトを格納するCatalogです。
  デフォルト値：remorph
• Schema metadata：照合結果や管理情報を保持するテーブルを格納するSchemaです。
  デフォルト値：reconcile
• Volume metadata：Reconcileの実行時に使用する設定ファイルや中間データを保存するVolumeです。
  デフォルト値：reconcile_volume

※指定したCatalog、Schema、またはVolumeがすでに存在する場合は、Lakebridgeが自動的に検出し、それらを再利用します。

これらのオブジェクトには、Reconcileの設定情報、実行状態、および移行元システムとDatabricks間のデータ照合結果が保存されます。

通常は、Lakebridgeが自動的に設定するデフォルト値をそのまま利用できます。

Reconcile環境の設定が完了すると、LakebridgeはSQL Serverの移行元とDatabricksの移行先にある照合対象テーブルを自動的に検出できます。

この機能により、比較対象となるテーブルの対応付けや照合ルールを手動で設定する手間を大幅に削減できます。

• Auto-discover source/target tables：移行元および移行先の Schema を自動的にスキャンし、照合可能な対応テーブルを検出します。
• Discover tables now：テーブル検出を直ちに実行し、移行元テーブルと移行先テーブルのマッピング情報を Reconcile の設定ファイルに生成します。
• Auto-configure：照合に必要な設定を自動生成します。比較に使用するJoin Key、カラムマッピング、および基本的な変換ルールが自動的に設定されます。

② Reconcile設定ファイルの作成

Reconcileを実行する前に、照合対象テーブルおよび照合方法を定義したJSON設定ファイル を作成します。

設定ファイル名は、以下の命名規則に従う必要があります（）。

recon_config_<data_source>_<UC_connection_name>_<report_type>.json
※大文字・小文字も含めて完全に一致している必要があります。

例: recon_config_mssql_my_sqlserver_connection_all.json

Reconcile設定ファイル (JSON形式)の例

設定ファイルの基本構成は以下のとおりです。

• report_type：実行する照合タイプを指定します。
  schema、row、data、all のいずれかを指定します。
  この項目は各テーブル単位ではなく、設定ファイルのトップレベルで指定します。
• source.uc_connection_name：事前準備で作成したUnity Catalog Connectionの名前を指定します。
• source_name / target_name：照合対象となる移行元テーブル名および移行先テーブル名を指定します。
• join_columns：Column-by-Column Validation（data / all） を実行する際に、各行を一意に識別するためのJoin Keyを指定します。

作成した設定ファイルは、Databricks Workspaceの以下のディレクトリへアップロードします。
/Workspace/Users/<user_name>/.lakebridge/

③ Reconcileの実行

設定ファイルの準備が完了したら、以下のコマンドを実行して Reconcile を開始します。

実行結果：照合結果は、Databricks Workspaceの以下のディレクトリに ダッシュボードとして生成されます。 /Workspace/Users/<user_name>/.lakebridge/dashboards.

確認できる主な項目：ダッシュボードでは、移行元システムとDatabricksのデータ照合結果をテーブルごとに確認できます。

• Mismatched Records：値が一致しなかったレコード数を表示します。
• Threshold Mismatches： あらかじめ設定した許容しきい値を超えた不一致を表示します。
• Missing in Databricks：移行元システムには存在するものの、Databricks には存在しないレコードを表示します。
• Missing in Source：Databricks には存在するものの、移行元システムには存在しないレコードを表示します。

6. ツールの選択方法

プロジェクトで適切なツールを選択することは、マイグレーションのリスク低減と作業効率の向上に大きく影響します。

以下の比較表を参考に、移行元プラットフォームやプロジェクトの要件に応じて、最適なAssessmentツールおよびTranspilerを選択してください。

なお、AssessmentツールであるProfilerとAnalyzerは、それぞれ目的が異なるため、役割の違いを理解したうえで使い分けることが重要です。

比較項目	Profiler	Analyzer
主な用途	データ量やクエリパターンを把握し、マイグレーション規模を評価（※マネジメント向け）	コードの複雑度や依存関係を詳細に分析（※エンジニア向け）
接続方式	移行元環境へ直接接続（Live接続）	あらかじめエクスポートしたローカルファイルを解析する
出力形式	タイムスタンプ付きSnapshot、Lakeview ダッシュボード	Excelレポート（複雑度評価、依存関係マップなど）
提供状況	試験提供 (Experimental)	安定版

 

プロジェクトの要件や移行元プラットフォームに応じて、以下の比較表を参考に最適なTranspilerを選択してください。

比較項目	Morpheus	BladeBridge	Switch
変換方式	AST ベース（構文解析）	Configuration-driven（ルールベース）	LLM ベース（意味解析）
対応ソース	SQL Server、Snowflake、Azure Synapse	Oracle、Teradata、DataStage、SSISなど	9種類のSQLダイアレクト、Airflow DAG, PySparkなど
変換精度	エラー・警告なしで変換が完了した場合、論理的な等価性を保証する	ルールベースで変換（設定内容に依存）	コンテキストの理解に依存するため、論理的な等価性は保証されない
複雑なロジックへの対応	変換できない箇所には FIXME コメントを付与し、手動対応を促す	Perl Callbackによる拡張が可能	複雑な手続き型ロジックにも対応可能
実行環境	ローカル	ローカル	Databricks Workspace (Job)
コスト	無料	無料	Mosaic AI Model ServingのAPI 利用料金が発生する
推奨ユースケース	SQL Server、Snowflake、Azure Synapse からの移行。変換精度を最優先する場合	Oracle、Teradata、DataStage、SSIS からの移行。ETL の変換も含めて実施する場合	「高」または「非常に高」と評価されたアセットや、Morpheus／BladeBridge では対応が難しいエッジケース
提供状況	安定版	安定版	試験提供 (Experimental)

7. まとめ

本記事では、SQL ServerからDatabricks SQLへのマイグレーションを例に、Databricks Lakebridgeの役割と主要な機能について紹介しました。

Lakebridgeが提供する3つのフェーズで構成されたマイグレーションパイプライン を振り返ると、以下のような特徴があります。

• Assessmentフェーズ
  SQL Splitter、Profiler、Analyzer を活用することで、マイグレーション前にシステムを多角的に分析し、オブジェクトの複雑度に応じた適切な移行戦略を立てることができます。
• Transpileフェーズ
  移行元プラットフォームやコードの複雑度に応じて、Morpheus（AST ベースの高精度変換）、BladeBridge（幅広い ETL に対応したルールベース変換）、Switch（LLM を活用した複雑なロジックの変換）を使い分けることで、コード変換にかかる工数を大幅に削減できます。
• Reconcileフェーズ
  4種類の検証モードと柔軟な設定ファイルを利用することで、マイグレーション後のデータ品質を定量的に検証し、残存する差異やリスクを可視化できます。

Lakebridgeの大きな特徴は、マイグレーションプロセスを標準化できることです。

移行元システムが異なる場合でも、共通のツールセットと統一されたワークフローで対応できるため、ナレッジの共有やチーム間の引き継ぎを効率化できます。

一方で、導入にあたっては次の点にも注意が必要です。

• LakebridgeはDatabricks Labsのプロジェクトであり、Databricksの正式な製品ではありません。 そのため、SLAは提供されておらず、本番環境への適用前には十分な評価を行うことが推奨されます。
• ProfilerおよびSwitchは現在も 試験提供（Experimental） の機能であるため、本番環境で利用する際には十分な検証が必要です。
• Morpheusによる変換後もerrorやwarningコメントが残るファイルについては、手動レビューに必要な工数を事前に見積もっておく必要があります。
• Switchを利用する場合は、Mosaic AI Model ServingのAPI利用料金が発生するため、あらかじめコストを見積もることが重要です。
• Reconcileの設定ファイルの命名規則や、TeradataにおけるUDFの追加設定など、移行元プラットフォームごとの注意事項についても事前に確認しておく必要があります。

Databricks Lakebridgeは、レガシーなデータプラットフォームからDatabricks Lakehouseへのマイグレーションを体系的に進めるための強力なツールです。

本記事が、今後のマイグレーションプロジェクトを計画・実施する際の参考資料となれば幸いです。

この記事を書いた人

trinm

この投稿者の最新の記事

この投稿者の記事一覧

• 2026年7月14日ブログLakebridge：Databricksへのデータ移行を支援するツール
• 2026年6月9日ブログ【Azure Databricks】Databricks Genieとは？ データ活用企業が統合プラットフォームを選ぶ理由
• 2026年5月15日ブログ【Azure Databricks】外部ロケーションを使用して Azure Data Lake Storageに接続する