ETL パイプラインを Azure Databricks に移行する

  • [アーティクル]

この記事では、他のデータ システムで実行されている抽出、変換、読み込み (ETL) パイプラインを Azure Databricks に移行するためのオプションの概要について説明します。 Apache Spark コードを移行する場合は、「Azure Databricks 用の出力する Apache Spark コードを調整する」を参照してください。

エンタープライズ データ ウェアハウスからレイクハウスへの移動に関する一般的な情報については、「データ ウェアハウスを Databricks レイクハウスに移行する」を参照してください。 Parquet から Delta Lake への移行の詳細については、「Parquet データ レイクを Delta Lake に移行する」を参照してください。

Azure Databricks では Hive パイプラインを実行できますか。

ほとんどの Hive ワークロードは、Azure Databricks で最小限のリファクタリングを使用して実行できます。 Databricks Runtime でサポートされている Spark SQL のバージョンでは、多くの HiveQL コンストラクトを使用できます。 「Apache Hive の互換性」を参照してください。 Azure Databricks には、既定で Hive メタストアが含まれています。 ほとんどの Hive 移行では、いくつかの主な懸念事項に対処する必要があります。

  • Azure Databricks ネイティブのファイル コーデックを使用するには、Hive SerDe を更新する必要があります (Azure Databricks SerDe を使用するには、DDL を STORED AS から USING に変更します)。
  • Hive UDF は、ライブラリとしてクラスターにインストールするか、ネイティブ Spark にリファクタリングする必要があります。 Hive UDF は既に JVM に存在するため、多くのワークロードに十分なパフォーマンスが提供される可能性があります。 「最も効率的な UDF はどれか」を参照してください。
  • Azure Databricks では Hive と異なる方法でパーティションが使用されるため、テーブルのディレクトリ構造を変更する必要があります。 「Azure Databricks でテーブルをパーティション分割するタイミング」を参照してください。

初期移行中にテーブルを Delta Lake に更新するように選択した場合は、多くの DDL ステートメントと DML ステートメントがサポートされません。 次のようなものが含まれます。

  • ROWFORMAT
  • SERDE
  • OUTPUTFORMAT
  • INPUTFORMAT
  • COMPRESSION
  • STORED AS
  • ANALYZE TABLE PARTITION
  • ALTER TABLE [ADD|DROP] PARTITION
  • ALTER TABLE RECOVER PARTITIONS
  • ALTER TABLE SET SERDEPROPERTIES
  • CREATE TABLE LIKE
  • INSERT OVERWRITE DIRECTORY
  • LOAD DATA
  • TRUNCATE TABLE で PARTITION (part_spec) を使用したターゲット パーティションの指定

Azure Databricks では SQL ETL パイプラインを実行できますか。

通常、ソース コードでシステム固有のプロトコルがどの程度まで使用されたかによっては、SQL ワークロードを他のシステムから Azure Databricks に移行するために、リファクタリングを行う必要はほとんどありません。 Azure Databricks では、Delta Lake が既定のテーブル形式として使用されるため、テーブルは既定でトランザクション保証ありで作成されます。

Spark SQL は主に ANSI に準拠していますが、動作の違いがいくつかある可能性があります。 「Databricks Data Intelligence Platform とエンタープライズ データ ウェアハウスの違い」を参照してください。

データ システムでは外部データへのアクセスが異なる方法で構成される傾向があるため、SQL ETL パイプラインをリファクタリングする多くの作業では、これらのデータ ソースへのアクセスが構成されてから、これらの新しい接続を使用するようにロジックが更新されている可能性があります。 Azure Databricks には、インジェスト対象の多くのデータ ソースに接続するためのオプションが用意されています。

Azure Databricks では dbt ETL パイプラインを実行できますか。

Azure Databricks では、dbt とのネイティブ統合が提供されるため、リファクタリングをほとんど行わずに既存の dbt スクリプトを活用できます。

Delta Live Tables には、パイプラインの作成、テスト、デプロイ用に最適化された Databricks ネイティブの宣言型 SQL 構文が用意されています。 Azure Databricks では dbt を活用できますが、Delta Live Tables へのコードの簡易リファクタリングを行うと、Azure Databricks でパイプラインを操作するための総コストが削減される可能性があります。 「Delta Live Tables とは」を参照してください。

サーバーレス クラウド関数を Azure Databricks に移行できますか。

カスタムのサーバーレス クラウド関数には拡張性と汎用性があるため、一般的な推奨事項を提供することが困難ですが、これらの関数の最も一般的なユース ケースの一例は、ファイルまたはデータが 1 つの場所またはメッセージ キューに表示されるまで待機してから、結果として何らかのアクションを実行することです。 Azure Databricks では、クラウドの状態に基づいてワークロードをトリガーするための複雑なロジックがサポートされていませんが、構造化ストリーミングをワークフローと組み合わせて使用すると、データを段階的に処理できます。

クラウド オブジェクト ストレージから最適化されたデータ インジェストを行うには、自動ローダーを使用します。 構造化ストリーミングでは、ストリーミング ソースからのデータをほぼリアルタイムで処理できます。

Azure Databricks では他のデータ システムから構文を実行できますか。

SQL、Apache Spark、Hive 以外の言語で定義された ETL パイプラインは、Azure Databricks で実行する前に、大量にリファクタリングする必要がある場合があります。 Azure Databricks には、お客様が現在使用しているほとんどのデータ システムから移行するのを支援するエクスペリエンスがあり、移行作業をすぐに開始するために使用できるリソースがある場合もあります。