データウェアハウスをDatabricksレイクハウスに移行する

この記事では、エンタープライズデータウェアハウスをDatabricks Lakehouseに置き換える際に考慮すべき点や注意点について説明します。エンタープライズデータウェアハウスで定義されたほとんどのワークロード、クエリ、ダッシュボードは、管理者が最初のデータ移行とガバナンス構成を完了すると、最小限のコードリファクタリングで実行できます。データウェアハウスのワークロードをDatabricksに移行することは、データウェアハウスをなくすことではなく、むしろデータエコシステムを統一することです。Databricksでのデータウェアハウジングの詳細については、Databricksでのデータウェアハウジングとはを参照してください。

多くの Apache Spark ワークロードは、ソースシステムからデータウェアハウスにデータを抽出、変換、読み込み (ETL) して、ダウンストリームのアナリティクスを強化します。エンタープライズデータウェアハウスをレイクハウスに置き換えることで、アナリスト、データサイエンティスト、データエンジニアは、同じプラットフォーム内の同じテーブルに対して作業できるようになり、全体的な複雑さ、メンテナンス要件、総所有コストが削減されます。「データレイクハウスとは」を参照してください。Databricks 上のデータウェアハウジングの詳細については、「 Databricks 上のデータウェアハウジングとは」を参照してください。

データをレイクハウスに読み込む

Databricksは、データをレイクハウスに簡単に移行し、多様なデータソースからデータをロードするETLジョブを構成するための多くのツールと機能を提供します。次の記事では、これらのツールとオプションについて説明します。

Databricksデータインテリジェンスプラットフォームは、エンタープライズデータウェアハウスとどう違うのですか?

Databricksデータインテリジェンスプラットフォームは、Apache Spark、Unity Catalog、Delta Lake 上に構築されており、アナリティクス、ML、データエンジニアリングのビッグデータワークロードをネイティブにサポートします。すべてのエンタープライズ・データ・システムには、トランザクション保証、インデックス作成と最適化のパターン、およびSQL構文がわずかに異なります。最も大きな違いには、次のようなものがあります。

すべてのトランザクションはテーブルレベルです。データベースレベルのトランザクション、ロック、または保証はありません。
BEGINおよびENDの構文はなく、各ステートメントやクエリーは別々のトランザクションとして実行されます。
3層の名前空間ではcatalog.schema.tableパターンが使用されます。用語databaseとschemaは、従来のApache Spark構文のため同義です。
主キー制約と外部キー制約は情報提供のみを目的としています。制約は、テーブルレベルでのみ適用できます。Databricksの制約を参照してください。
DatabricksとDelta Lakeでサポートされるネイティブデータ型は、ソースシステムとは若干異なる場合があります。数値型に必要な精度は、ターゲットの型を選択する前に明確に示す必要があります。

次の記事では、重要な考慮事項に関する追加のコンテキストを提供します。