Databricksへの移行のナビゲーション：アーキテクチャと戦略的アプローチ
ETLファーストおよびBIファーストの移行戦略の実践的なガイド
によって ジャイミン・シャー, ジョージ・コムニノス, ソーハム・バット 、 カナド・シャルマ による投稿
Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.
- Databricks でのデータ ウェアハウス移行には、ETL-First (バックツー フロント) と BI-First (フロントツーバック) という 2 つの主なアプローチがあります。
- ETL ファーストの移行には、ブロンズ、シルバー、ゴールド レイヤー全体にわたる堅牢なレイクハウス データ モデルの作成が含まれます。これにより、データのガバナンスと品質が確保され、最新化が促進されますが、BI と分析のメリットはパイプライン全体が構築された後にのみ実現されるため、目に見えるビジネス成果が遅れます。
- BI ファースト移行では、まず BI システムを最新化することで、ユーザーは新しいプラットフォームに早期にアクセスできます。「フェデレーションしてから移行」や「レプリケートしてから移行」などのパターンにより、段階的な移行に柔軟性がもたらされ、ビジネス価値が迅速に実現され、進化するニーズに合わせることができます。Lakehouse Federation や LakeFlow Connect などの Databricks 機能は、このアプローチを容易にします。
私たちの前回のブログでは、複雑なデータウェアハウスの移行をDatabricksに実行するための、プロフェッショナルサービスチームが推奨する方法論を探求しました。このようなプロジェクト中に生じる複雑さや課題を強調し、移行戦略と設計フェーズでの重要な決定の重要性を強調しました。これらの選択は、移行の実行と目標データプラットフォームのアーキテクチャの両方に大きな影響を与えます。この投稿では、これらの決定に深く踏み込み、移行プロセス全体で情報に基づいた 効果的な選択を行うための主要なデータポイントを概説します。
移行戦略：まずETLか、それともまずBIか？
あなたが移行戦略を確立し、高レベルの目標データアーキテクチャを設計したら、次に決定することは、どのワークロードを最初に移行するかです。二つの主要なアプローチがあります。
- ETLファーストの移行（バックからフロントへ）
- BIファーストの移行（フロントからバックへ）
ETLファーストの移行：基盤の構築
ETLファースト（バックからフロントへ）で移行する方法は、包括的なレイクハウスデータモデルを作成することから始まり、ブロンズ、シルバー、ゴールドレイヤーへと順番に進みます。このアプローチは、Unity Catalogを用いたデータガバナンスの設定、LakeFlow Connectのようなツールを用いたデータの取り込み、変更データキャプチャ（CDC）のような技術の適用、そしてレガシーETLワークフローとストアドプロシージャをDatabricks ETLに変換することを含みます。厳密なテストの後、BIレポートが再ポイントされ、AI/MLエコシステムがDatabricksプラットフォーム上に構築されます。
この戦略は、データの自然な流れを反映しています。データを生成し、オンボーディングし、それをユースケースの要件を満たすように変換します。これにより、信頼性の高いパイプラインと最適化されたブロンズとシルバー のレイヤーを段階的に展開することが可能になり、不整合を最小限に抑え、BIのデータ品質を向上させます。これは、新しいレイクハウスデータモデルをゼロから設計したり、データメッシュを実装したり、データドメインを再設計する際に特に有用です。
しかし、このアプローチは、通常、これらの取り組みに予算を割り当てるビジネスユーザーにとって、目に見える成果が遅れてしまう場合が多いです。BIを最後に移行するということは、パフォーマンスの向上、洞察力の向上、予測分析とGenAIプロジェクトのサポートの改善が数ヶ月間現れないかもしれません。移行中のビジネス要件の変更は、移動するゴールポストを作り出し、プロジェクトの勢いと組織の賛同に影響を与えることもあります。パイプライン全体が完成し、シルバー層とゴールド層のメイン領域が構築されて初めて、完全なメリットが実現されます。
BIファーストの移行：即時の価値提供
BIファースト、つまりフロントからバックへの移行では、消費層が優先されます。このアプローチにより、ユーザーは新しいデータプラットフォームに早期にアクセスしてその機能を紹介しながら、ユース ケースまたはドメインごとに段階的に消費層に取り込まれるワークフローを移行できます。
BIファーストの移行を可能にする主要な製品機能
Databricksプラットフォームの2つの優れた機能、Lakehouse FederationとLakeFlow Connectは、BIファーストの移行アプローチを非常に実用的で影響力のあるものにします。これらの機能は、BIシステムの近代化プロセスを効率化し、移行努力における機動性、セキ ュリティ、スケーラビリティを確保します。
- レイクハウスフェデレーション：サイロ化されたデータソース全体でのアクセスを統一
レイクハウスフェデレーションは、組織が複数のサイロ化されたエンタープライズデータウェアハウス（EDW）と運用システム全体でデータにシームレスにアクセスし、クエリを実行することを可能にします。Teradata、Oracle、SQL Server、Snowflake、Redshift、BigQueryを含む主要なデータプラットフォームとの統合をサポートします。 - LakeFlow Connect
LakeFlow Connectは、Change Data Capture（CDC）技術を活用してデータの取り込みと同期を革新的に行います。この機能により、リアルタイムで増分的なデータ取り込みがDatabricksに可能となり、プラットフォームが常に最新の情報を反映することを保証します。
BIファーストの移行パターン
Lakehouse FederationとLakeFlow Connectを活用することで、組織はBIファースト移行のための2つの異なるパターンを実装することができます：
- 連携、その後移行：
既存のEDWを迅速に連携し、Unity Catalogを介してそのテーブルを公開し、システム間の分析を可能にします。必要なデータをDelta Lakeに段階的に取り込み、ETLを実行してGold層の集約を構築し、BIレポートをDatabricksに切り替えます。 - レプリケート、その後移行：
CDCパイプラインを使用して、運用データとEDWデータをBronze層にレプリケートします。Delta Lakeでデータを変換し、BIワークフローをモダナイズし、MLとGenAIプロジェクトのためのサイロ化されたデータを解放します。
両方のパターンは、アジ ャイルで段階的なアプローチでユースケースごとに実装することができます。これにより、早期のビジネス価値が確保され、組織の優先事項と一致し、将来のプロジェクトのための設計図が設定されます。レガシーETLは後で移行することができ、データソースを真の起源に移行し、レガシーEDWシステムをリタイアさせることができます。
まとめ
これらの移行戦略は、Databricksを用いてデータプラットフォームを近代化するための明確な道筋を提供します。Unity Catalog、Lakehouse Federation、LakeFlow Connectなどのツールを活用することで、あなたのアーキテクチャと戦略をビジネス目標と一致させ、高度な分析機能を有効にすることができます。ETLファーストまたはBIファーストの移行を優先するかどうかに関わらず、キーとなるのは、変革のジャーニーを通じて価値を段階的に提供し、勢いを維持することです。
最新の投稿を受信トレイで受け取る
ブログを購読して、最新の投稿を受信トレイにお届けします。