ETL パイプラインを Databricks に移行する
この記事では、他のデータ システムで実行されている抽出、変換、ロード (ETL) パイプラインを Databricksに移行するためのオプションの概要について説明します。 Apache Spark コードを移行する場合は、「 既存の Apache Spark コードを Databricks に適応させる」を参照してください。
エンタープライズ データウェアハウスからレイクハウスへの移行に関する一般的な情報については、「Databricks レイクハウスへのデータウェアハウスの移行」を参照してください。Parquet から Delta Lakeへの移行に関する情報については、「Parquet データレイクを Delta Lakeに移行する」を参照してください。
Hiveで パイプラインを実行できますか?Databricks
ほとんどの Hive ワークロードは、最小限のリファクタリングで Databricks 上で実行できます。 Databricks Runtime でサポートされている Spark SQL のバージョンでは、多くの HiveQL コンストラクトを使用できます。 「Apache Hive の互換性」を参照してください。Databricks には、デフォルトによる Hive metastore が含まれています。 ほとんどの Hive 移行では、いくつかの主要な懸念事項に対処する必要があります。
- Hive SerDe は、Databricks ネイティブのファイル コーデックを使用するように更新する必要があります。 (Databricks SerDe を使用するには、DDL を
STORED AS
からUSING
に変更します。 - Hive UDF は、 ライブラリとしてクラスター にインストールするか、ネイティブ Sparkにリファクタリングする必要があります。 Hive UDF はすでに 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)
in を使用したターゲットパーティションの指定TRUNCATE TABLE
Databricks で SQL ETL パイプラインを実行できますか?
他のシステムから Databricks に SQL ワークロードを移行する場合、通常、ソースコードでシステム固有のプロトコルがどの程度使用されたかにもよりますが、リファクタリングはほとんど必要ありません。 Databricks では Delta Lake をデフォルトのテーブル形式として使用するため、テーブルはデフォルトによる トランザクション保証 付きで作成されます。
Spark SQL は主に ANSI に準拠していますが、動作にいくつかの違いがある場合があります。 「Databricks Data Intelligence Platform とエンタープライズ データウェアハウスの違いは何ですか?」を参照してください。
データ システムは外部データへのアクセスを異なる方法で構成する傾向があるため、パイプライン SQL ETL リファクタリング作業の多くは、これらのデータソースへのアクセスを構成し、これらの新しい接続を使用するようにロジックを更新することである可能性があります。 Databricks 、 インジェストのために多くのデータソースに接続するためのオプションが用意されています。
Databricks で dbt ETL パイプラインを実行できますか?
Databricks は dbt とのネイティブ統合を提供し、リファクタリングをほとんど行わずに既存の dbt スクリプトを活用できます。
DLT は、パイプラインの作成、テスト、デプロイに最適化された Databricks ネイティブの宣言型 SQL 構文を提供します。Databricks で dbt を活用できますが、コードを DLT に軽くリファクタリングすると、Databricks でパイプラインを運用するための総コストを削減できる可能性があります。DLTとはを参照してください。
サーバレスのクラウド機能を Databricksに移行できますか?
カスタムサーバレスクラウド関数の拡張性と汎用性により、一般的な推奨事項を提供することは困難ですが、これらの関数の最も一般的なユースケースの1つは、ファイルまたはデータが場所またはメッセージキューに表示されるのを待ってから、その結果として何らかのアクションを実行することです。 Databricks は、クラウドの状況に基づいてワークロードをトリガーする複雑なロジックをサポートしていませんが、構造化ストリーミングを ジョブ と組み合わせて使用することで、データを段階的に処理することができます。
Auto Loaderを使用して、クラウドオブジェクトストレージからのデータ取り込みを最適化します。構造化ストリーミングは、 ストリーミング ソースから のデータをほぼリアルタイムで処理できます。
Databricks 上の他のデータ システムから構文を実行できますか?
SQL、Apache Spark、Hive 以外の言語で定義された ETL パイプラインは、Databricks で実行する前に大幅にリファクタリングする必要がある場合があります。 Databricks は、現在使用されているほとんどのデータ システムからの移行を支援した経験があり、移行作業をすぐに開始するためのリソースを用意している可能性があります。