SynapseからDatabricksへの移行の進め方

Azure Synapseは、大規模なSQL分析のための信頼できる基盤として機能しており、それを採用したチームにとって当時は賢明な選択でした。しかし、主にデータウェアハウスを中心に設計されたプラットフォームは、現在のデータチームに求められる多様な要件すべてに対応できるようには作られていません。これらのギャップを埋めるには、通常、さらなるサービスや統合、運用オーバーヘッドの追加が必要になり、これらは時間の経過とともに蓄積されていきます。

Databricksへの移行は、この課題を解決する1つの方法です。このブログでは、Synapseからの移行へのアプローチ方法と、実行時に留意すべき点について説明します。

Synapse移行によって実現すること

お客様とのSynapse移行の取り組みを通じて、一貫して3つのビジネスドライバーが見られます。

1. 統合されたデータ資産。データプラットフォームが拡大するにつれて、関与するサービスの数も増加します。例えば、Synapse Analyticsプールが特定のワークロードを処理し、Sparkプールが別のワークロードを処理し、サーバーレスSQLがアドホックなアクセスを提供します。多くの場合、これらと並行してAzure Data Factoryがすべてをオーケストレーションします。また、多くの組織には、引き続きサポートが必要なレガシーなSSISワークロードもあります。これらのコンポーネントは、単体では問題ありません。しかし、追加のサービスが導入されると、ガバナンス、監視、権限管理、運用のオーバーヘッドがさらに重なり、課題が生じます。
   Databricksは、データエンジニアリング、分析、機械学習、ガバナンスを単一のプラットフォームに統合することで、この課題を解決します。異なる運用モデルを持つサービス間を行き来する代わりに、チームは同じ基盤となるアーキテクチャとガバナンスフレームワークに沿って作業できます。その結果、複雑さが軽減され、統合ポイントが減少し、大規模な運用が容易なプラットフォームが実現します。
2. 将来への備え。現代のデータチームの焦点は、機械学習モデル、リアルタイムデータパイプライン、AI搭載アプリケーションのサポートへとシフトしています。これらのワークロードはすべて、同じ基盤となるデータに依存しています。課題は、従来のデータウェアハウス中心のアーキテクチャが、このレベルの融合を想定して設計されておらず、主にBIニーズをターゲットにしていたことです。要件が拡大するにつれて、組織は機能のギャップを埋めるために、さらに多くのサービスや専門ツールを追加せざるを得なくなることがよくあります。
   Databricksはこの融合のために構築されており、データ、分析、AIを単一のプラットフォームに統合します。Unity Catalogがデータ、ノートブック、AI/ML資産全体に一貫したガバナンスを提供し、Unity AI Gatewayがそれらの制御をモデル、エージェント、AIアプリケーションに拡張することで、組織は新たなガバナンスのサイロを作ることなく、新しいAIワークロードを採用できます。
3. 運用効率の向上。ほとんどの移行ビジネスケースはライセンスコストから始まりますが、最大の削減効果がそこから得られることはほとんどありません。より大きなインパクトは、チームが運用・サポートする必要のあるシステムの数を減らすことから得られる場合が多いです。サービスが減るということは、統合が減り、ツール間の引き継ぎが減り、潜在的な問題が減ることを意味します。

すでに移行を完了した組織は、具体的な成果を上げています。例えば、全米第3位のコンビニエンスストアチェーンであるCasey'sは、分析環境をSynapseからDatabricks Lakehouse（旧Databricks SQL）に移行し、運用のデータ配信時間を8時間から4時間に短縮しました。別の例として、ItalgasはSynapseとAzure Analysis Servicesの両方を廃止することでアーキテクチャを簡素化しました。同社は、Power BIとAI駆動の分析の両方をDatabricksから直接提供しながら、ワークロードコストを73%削減したと報告しています。

詳細は組織によって異なりますが、パターンは一貫しています。それは、アーキテクチャの簡素化、データ配信の高速化、そして現代のデータチームに課される要求により適合したプラットフォームの実現です。

実際に何を移行するのかを理解する

Synapse移行の初期段階でチームが不意を突かれがちなことの1つは、移行対象のスコープです。Azure Synapseは単一のプラットフォームと見なされがちですが、実際には1つのブランドの下で動作するさまざまな個別のサービスで構成されており、それぞれに異なる移行戦略が必要で、複雑さのレベルも異なります。

ほとんどの移行では、長年にわたってビジネスロジック、ストアドプロシージャ、分散戦略、インデックス作成の決定、パフォーマンス最適化が蓄積されてきた専用SQLプールに労力の大部分が費やされます。しかし、複雑さはSQLだけにとどまりません。同じ移行において、通常はオーケストレーション（Azure Data FactoryおよびSynapse Pipelines）、権限とガバナンス（SQL権限に加えてMicrosoft Purview。リネージは手動でつなぎ合わされることが多い）、そしてBIやサードパーティとの接続性（セマンティックモデル、レポート、およびSynapseエンドポイントに直接接続されたダウンストリームツール）も考慮する必要があります。これこそが、最も再設計、テスト、検証を必要とする部分であり、最も過小評価されやすい部分です。

サーバーレスSQLプールは、主にデータレイク内のファイルに対するクエリレイヤーを提供するため、一般的にシンプルです。ここでの移行は、複雑なワークロードを再設計するのではなく、主にビュー、外部テーブル、アクセスパターンの再構築が中心となります。Sparkプールは最も移行が簡単なコンポーネントです。Synapse SparkとDatabricksはどちらもApache Sparkをベースにしており、ノートブックは比較的少ない変更で移行できることが多いためです。

重要な点は、これらのコンポーネントが異なるスピードで動き、異なる関係者が関与し、異なるリスクをもたらすということです。移行を単一のタイムラインを持つ単一のワークストリームとして進める組織は、労力と複雑さの両方を過小評価しがちです。その結果、スケジュールが遅れ始め、移行プログラムが当初の範囲を超えて拡大し始めます。移行を成功させるには、チームは移行のプロセスを体系化する必要があります。

移行をどのように体系化するか

SynapseからDatabricksへの移行は、単一のワークストリームではありません。3つの異なるコンピューティングモデルを移行し、ガバナンスを統合し、オーケストレーションを近代化し、長年蓄積されたT-SQLロジックを再構築することになります。これをうまく処理するチームは、段階的なアプローチを採用し、単なる技術的なプロジェクトではなく、構造化されたプログラムとして扱います。

検出。すべての移行は、実際に何が実行されているかを理解することから始まります。Lakebridge Profilerは、Synapse環境をスキャンし、構成、リソース使用状況、クエリパターン、パフォーマンス基準に関するメタデータを収集します。出力は、TCOケースの構築に使用されます。

評価。インベントリが整ったら、次のステップは複雑さを理解することです。Lakebridge Analyzerは、T-SQLコードベースを評価し、すべてのオブジェクトを複雑さによって分類し、サポートされていない構造にフラグを立て、依存関係をマッピングします。出力は、移行スケジュールと関連する労力の評価、および資産移行の優先順位の定義に使用できます。まずは「手近な成果」として、難易度の低いワークロードや中程度のワークロードから開始し、その後、最も重要なユースケースに向けて労力を計画します。

設計。環境の可視化が完了したら、関心はアーキテクチャと設計に移ります。最初の決定事項はアプローチです。リフト＆シフト、近代化、またはハイブリッドのいずれかです。ほとんどのSynapse移行において、ハイブリッドが正解です。自動化ツールがコード変換の大部分を処理してスケジュール通りにSynapseから移行し、ワークロードがDatabricksで稼働し始めた後に段階的に近代化を進めます。

2つ目の決定事項は順序です。BIファーストのアプローチは、ETLから開始するよりも早く勢いを生み出す傾向があります。Lakehouse Federationを使用すると、基盤となるパイプラインが移行する前に、Unity Catalogを介してSynapseデータを公開できます。現実的な開始方法としては、まずビジネス向けの拡張データ（データマート）をDatabricksに配置し、Genieを使用して自然言語分析を実行できるようにビジネスユーザーに直接提供することです。ビジネス関係者は早い段階で進捗と価値を実感でき、その間にエンジニアリングチームは水面下でより複雑なETLを近代化できます。お客様に最適な移行アプローチを決定するために、こちらのブログ投稿をお読みください。

パイロット。規模を拡大する前に、移行戦略を実際のワークロードに対してエンドツーエンドで検証する必要があります。1つの先導的なユースケースを選択し、データの取り込みから消費まで移行して、本番環境に切り替えます。パイロット運用によって、アーキテクチャ、ガバナンスモデル、テスト手順、ツールが現実の条件下で検証され、その後のフェーズで再利用可能な資産が作成されます。

ウェーブごとの移行。拡大フェーズでは、ウェーブごとの移行が推奨されます。各ウェーブは、目に見えるビジネス上の成果をもたらすように設計されており、エンドユーザーとのフィードバックループを確立します。

実行は通常、4つの並行するワークストリームとして進められます。インジェクション（ADFおよびSynapse PipelineのワークロードをLakeflow Connectに移行）、変換（T-SQLプロシージャとビジネスロジックをDatabricksに移行）、オーケストレーション（スケジュールと依存関係をDatabricks Workflowsに移行）、および消費（BIツールとセマンティックモデルの接続先をDatabricks SQL Warehousesに変更）です。これらを並行して実行することで、チームは早期に価値を提供し、予測可能なスケジュールでSynapseを廃止できます。

Databricksは、さまざまな角度からSynapseの移行をサポートします。当社のForward Deployed Engineeringチームによるアドバイザリーとデリバリー、認定されたBrickbuilderパートナー、そして面倒な作業を自動化するLakebridgeのようなアクセラレータを提供しています。ゴールは単に移行を完了することではなく、プロジェクト終了後もチームがプラットフォームを維持するために必要なスキルを身に付け、運用モデルを構築することです。

データの取り込み

SQLコードを変換する前に、まずデータをレイクハウスに取り込む必要があります。Databricksは、ソースシステムや運用要件に応じていくつかのオプションを提供しています。

多くの一般的なエンタープライズソースに対して、Lakeflow Connectは、組み込みコネクタと自動化されたパイプライン管理による、管理されたインジェスチョン体験を提供します。同時に、Databricksはオープンなストレージフォーマットをベースに構築されているため、組織は幅広いサードパーティ製の取り込みツールを使用できます。Fivetran、Airbyte、その他のETL/ELTプラットフォームなどのソリューションは、データをDelta Lakeに直接取り込むことができるため、お客様は単一のインジェスチョンフレームワークに縛られることなく、既存のデータ統合エコシステムと連携できます。

実践的なコード変換

レイクハウスでデータが利用可能になると、移行作業はコード変換へと移ります。これは通常、移行において最も複雑なフェーズです。自動化ツールが変換の大部分（通常は80〜90%程度）を処理しますが、残りの作業は手続き型ロジックの微調整や、自動変換できないパターンの解決に費やされます。

以下に、SynapseとDatabricksの構文で注意すべきいくつかの違いを示します。

物理ディレクティブの削除

最も一般的な変換パターンは、物理的な最適化ディレクティブの削除です。専用SQLプールは、HASH分散、ROUND_ROBIN分散、REPLICATE分散、クラスター化カラムストアインデックスなどの構造に大きく依存しています。これらはSynapseのパフォーマンスチューニングにおいて不可欠ですが、Databricksには直接対応するものがないため、通常は移行時に省略されます。

代わりに、Databricksはクエリパフォーマンスを向上させるために、ストレージの最適化とLiquid Clusteringに依存しています。前者は、Deltaテーブルのファイルコンパクション、統計情報の収集、VACUUMなどのメンテナンス操作を継続的に実行するPredictive Optimizationを通じて自動的に処理されます。後者は、クエリパフォーマンスを向上させるために1つ以上のクラスタリング列を使用してDeltaテーブル内のデータを整理するLiquid Clusteringによって提供されます。しかし、最適なクラスタリング列の選択は、データがどのようにクエリされるかを理解することに依存しており、これは実際には困難であることが多く、ワークロードの進化に伴って頻繁に変化します。この運用上の負担を軽減するため、Databricksは、観察されたクエリアクセスパターンに基づいてクラスタリング列を自動的に特定し、継続的に微調整するCLUSTER BY AUTOを導入しました。これらの機能により、専用SQLプールと比較して、手動での物理チューニングに必要な作業量が大幅に削減されます。

Synapseで多大なエンジニアリング工数を費やしていた物理設計の決定は、単に不要になります。以前は手動で行っていた作業を、プラットフォームが処理します。

関数の再マッピング

最も一般的に使用されるT-SQL関数の多くには、直接対応するDatabricksの関数があり、Lakebridgeがマッピングの大部分を自動的に処理します。

問題のより一般的な原因は、関数自体のマッピングではなく、結果に微妙な影響を与える動作の違いです。文字列比較が良い例です。Synapseの専用SQLプールは通常、大文字と小文字を区別しない照合順序で動作しますが、Databricks SQLはデフォルトで大文字と小文字を区別します。大文字と小文字を区別しない一致に暗黙的に依存しているロジックは、移行後に異なる結果を返す可能性があります。必要に応じて、両側でLOWER()またはUPPER()を使用して、比較を明示的に行う必要があります。構文の変換は通常簡単ですが、セマンティクス（意味合い）の違いにはより注意が必要です。

ストアドプロシージャ：まず移行し、次に最適化する

Databricksはストアドプロシージャをネイティブにサポートしているため、ほとんどのSynapseプロシージャは全体の構造を維持したまま移行できます。パラメータ、変数、条件分岐ロジック、DML操作はすべてサポートされています。

プロシージャ自体が問題になることはほとんどありません。複雑さはその内部にあります。カーソル、行ごとの処理、動的SQL、Synapse固有のパフォーマンス最適化などです。これらのパターンには、単なる変換だけでなく、適切な判断が必要です。

SCDタイプ2：Delta Lakeによる履歴の保存

緩やかに変化する次元（SCD：Slowly Changing Dimensions）は、Synapseの実装が最も多様な領域の1つです。多くの組織が、長年にわたってカスタムのストアドプロシージャやマージロジックを蓄積してきました。移行の目標は、その実装を正確に再現することではなく、「現在の状態をクエリ可能に保ちながら、ディメンションレコードの履歴バージョンを維持する」というビジネス要件を守ることにあります。

一般的なDatabricksのアプローチでは、2つのステップを使用します。まず、変更されたレコードを期限切れにします。次に、新しいバージョンを挿入します。

Delta LakeのACIDトランザクションにより、複数の操作が関係する場合でも、このパターンを安全に実行できます。

エラー処理

多くのSynapseストアドプロシージャは、エラーのキャッチや監査レコードの書き込みをTRY...CATCHブロックに依存しています。Databricks SQLはコンディションハンドラーを通じてネイティブに同等の機能を提供するため、既存のパターンのほとんどをSQLベースのまま維持できます。

監査ログの記録や制御されたエラー処理のようなシンプルなシナリオは、通常そのまま移行できます。より複雑なワークフローでは、特にDatabricks Workflowsを介したダウンストリームの連携が関係する場合、追加の設計が必要になることがあります。

現場の経験から学べること

組織の規模や資産の複雑さに関係なく、Synapseの移行において一貫して得られるいくつかの教訓があります。

変換ではなく、まずアセスメントから始めましょう。 変換コードを1行も書く前に、Lakebridge Profiler and Analyzerを実行してください。実際の使用状況、スコープ、複雑さ、依存関係を明確にし、そのデータを利用して可能な限りスコープを削減します。

積極的に自動化しましょう。 Lakebridgeはコード変換の80〜90%を処理します。カーソル、動的SQL、複雑なエラー処理など、人間の判断が必要な10〜20%にエンジニアリングの時間を集中させましょう。

検証を過小評価してはいけません。 実際、検証には移行そのものよりも多くの労力がかかることがよくあります。最も効果的なアプローチは、移行のウェーブごとに照合（レコンシリエーション）を実行し、行数、集計、ハッシュベースのレコード比較、および完全な一致が適切でない値に対する許容値ベースのチェックを比較することです。Lakebridge Reconcileは、これらすべての次元にわたってこれをサポートします。ビジネスに不可欠なワークロードの場合、最終的な切り替えの前に両方の環境を並行して実行することで、ユーザーが使い慣れたレポートで作業を続けながら、チームは出力を並べて比較できます。

Synapse型の考え方から脱却しましょう。 良い例がテーブル設計です。チームは頻繁に、SynapseのHASH分散キーをDelta Lakeのパーティション列に直接マッピングしようとします。ほとんどの場合、これは不要な複雑さをもたらし、パフォーマンスを低下させる原因になります。顧客IDや注文IDなどの高カーディナリティ値がパーティションキーに適することはめったになく、リキッドクラスタリングや、予測メンテナンスのようなDatabricksの自動最適化機能を使用して処理する方が適していることがよくあります。

プラットフォームが処理できるようになったものを再作成しないでください。 移行は、アーキテクチャを正確に再現するのではなく、シンプルにする絶好の機会です。Delta Lake、自動最適化、およびモダンなレイクハウスパターンにより、従来のウェアハウス環境で必要だった手動チューニング手法の多くが不要になります。過去のすべての最適化の決定をDatabricksに持ち込むと、多くの場合、それらの制約が存在した理由を残さずに、古い制約だけを維持することになってしまいます。

運用の準備を整えましょう。 Deltaテーブルは、時間の経過とともに追加のワークロードが実行されるにつれて、自然と小さなファイルが蓄積されます。コンパクションやメンテナンスプロセスを行わないと、パフォーマンスが徐々に低下する可能性があります。従来のデータウェアハウスプラットフォームから移行するチームは、ストレージの最適化が継続的な運用モデルの一部になることに驚くことがよくあります。管理は難しくありませんが、最初から計画しておく必要があります。

チェンジマネジメントを計画しましょう。 ほとんどのSynapseチームはDatabricksを初めて使用するため、イネーブルメントへの投資不足は、プロジェクトが導入目標を達成できない最も一般的な原因の1つです。技術的な計画と同じくらい真剣にイネーブルメント計画に取り組みましょう。

Synapseの早期廃止は避けましょう。 移行に成功した事例の多くでは、本番ワークロードが移行した後もしばらくの間、レガシー環境を利用可能な状態に維持しています。予期しない問題が発生した場合に備えてロールバックオプションを確保しつつ、コストを最小限に抑えるためにコンピュートを一時停止できます。さらに重要なのは、そのセーフティネットを維持することで、新しいプラットフォームが実際の運用環境で実力を証明する間、ビジネス関係者に安心感を与えられる点です。

SynapseからDatabricksへの移行は、単なるテクノロジープロジェクトにとどまりません。その本質は、時間の経過とともに複雑化してきたプラットフォームをシンプルにすると同時に、次世代のアナリティクス、AI、データ製品をサポートできる基盤を構築することにあります。技術的な作業も重要ですが、これらの移行から最大の利益を得る組織は、この機会を利用してアーキテクチャを簡素化し、不要な複雑さを排除し、同時に運用方法を近代化する組織です。より大きなメリットは、運用がよりシンプルで、拡張が容易で、組織の将来の方向性により合致したデータプラットフォームを手に入れられることです。

次のステップ

Synapse移行の開始段階にいる場合：

• ご使用の環境でLakebridge Profiler and Analyzerを実行してください。作業範囲を決定する前にデータを取得しましょう。
• Migration Strategy: Lessons LearnedブログとTransforming Legacy Data Warehouses eBookをお読みください。
• 実践的なサポートが必要な場合は、Databricks FDE Teamや認定移行パートナーがSynapseの移行をエンドツーエンドで提供します。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事