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

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

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

DatabricksでHiveパイプラインを実行できますか?

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

  • Hive SerDe は、Databricks ネイティブのファイル コーデックを使用するように更新する必要があります。 (Databricks SerDe を使用するには、DDL を STORED AS から USING に変更します)。

  • Hive UDFs は、 ライブラリとしてクラスター にインストールするか、ネイティブ Spark にリファクタリングする必要があります。 Hive UDFs はすでに JVM にあるため、多くのワークロードに対して十分なパフォーマンスを提供できる可能性があります。 パフォーマンスに関する考慮事項を参照してください。

  • Databricks は Hive とは異なる方法でパーティションを使用するため、テーブルのディレクトリ構造を変更する必要があります。 「 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

  • PARTITION (part_spec) を使用したターゲット区画の指定 TRUNCATE TABLE

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

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

Spark SQL はほぼ ANSI に準拠していますが、動作にいくつかの違いがある場合があります。 「 Databricksデータインテリジェンスプラットフォームとエンタープライズ データウェアハウスの違い」を参照してください。

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

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

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

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

サーバレス クラウド機能を Databricks に移行できますか?

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

Auto Loader を使用して、クラウド オブジェクト ストレージからのデータ取り込みを最適化します。構造化ストリーミングは、 ストリーミング ソースから のデータをほぼリアルタイムで処理できます。

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

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