次の方法で共有

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

  • [アーティクル]

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

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

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

Azure Databricks には、データを簡単にレイクハウスに移行し、多様なデータ ソースからデータを読み込む ETL ジョブを構成するためのさまざまなツールと機能が用意されています。 次の記事では、これらのツールとオプションについて説明します。

Databricks Data Intelligence Platform とエンタープライズ データ ウェアハウスの違い

Databricks Data Intelligence Platform は、Apache Spark、Unity Catalog、Delta Lake を基にして構築され、分析、ML、Data Engineering のためのビッグ データ ワークロードに対するネイティブ サポートを提供します。 すべてのエンタープライズ データ システムでは、トランザクション保証、インデックス作成と最適化のパターン、SQL 構文が若干異なります。 確認できる最大の違いには、次のようなものがあります。

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

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