Azure Databricks用に既存の Apache Spark コードを調整する

この記事では、既存の Apache Spark ワークロードを Azure Databricks で実行するように調整するために必要な変更について説明します。 オンプレミス クラスター、カスタム クラウド ベースのインフラストラクチャ、または他のエンタープライズ Apache Spark オファリングからAzure Databricksに移行する場合でも、ほとんどのワークロードで運用環境に移行するために必要な変更はごくわずかです。 Azure Databricksは、カスタム最適化の導入、インフラストラクチャの構成とデプロイ、Databricks Runtime での依存関係の維持により、Apache Spark のパフォーマンスを拡張、簡素化、および向上させます。

重要

Apache Spark のバージョンをアップグレードするときには、構文に重大な変更がある場合があります。 Databricks Runtime リリース ノートのバージョンと互換性Spark 移行ガイド を参照してください。

parquetdelta に変更する

Databricks では、データの書き込み時に Parquet や ORC ではなく Delta Lake を使用することをお勧めしています。 Azure Databricksでは、Delta Lake によってサポートされるテーブルを操作する際の効率を高めるために多くの機能が最適化されており、Parquet から Delta Lake へのデータとコード 形式のアップグレードには、いくつかの手順しか必要とされません。 Parquet データ レイクを Delta Lake に移行するを参照してください。

Delta Lake では ACID トランザクションの保証が提供されるため、ワークロードを簡略化して、Apache Spark 操作で擬似トランザクション性を生み出すことを目的とした回避策をなくすことができる場合があります。 たとえば、次のようになります。

  • ディレクトリ構造またはパーティション分割戦略の構築により、特定の操作からのすべてのファイルをパーティションの一部として同時に検出できるようにします。
  • メタストアを構成または利用して、新しいデータの検出方法に関するトランザクション性を追加します。
  • MSCK repair の利用により、テーブルに書き込まれるファイルをメタストアに登録します。
  • alter table add partition の利用により、テーブルに手動でパーティションを追加します。

Azure Databricksを参照してください。

注意

使用されるデータ形式をアップグレードせずにワークロードを実行できますが、Azure Databricksで最大のパフォーマンス向上の多くは Delta Lake に直接関連付けられています。

Databricks Runtime 互換ライブラリを使用して Apache Spark コードを再コンパイルする

Databricks Runtime の各バージョンには、Apache Spark アプリケーションで必要なライブラリの多くが、事前に構成されて付属しています。 必要に応じて追加のライブラリをコンピューティングにインストールできますが、Databricks では、互換性のテストが行われている、Databricks Runtime にパッケージ化されたライブラリ バージョンを可能な限り使用することをお勧めします。 それぞれの Databricks Runtime リリースに、インストールされるすべてのライブラリの一覧が含まれています。 「Databricks Runtime リリース ノートのバージョンと互換性」を参照してください。

SparkSession 作成コマンドを削除する

従来の Apache Spark ワークロードの多くでは、新しい SparkSession がジョブごとに明示的に宣言されています。 Azure Databricksは、コンピューティング クラスターごとに SparkContext を自動的に作成し、クラスターに対して実行されるノートブックまたはジョブごとに分離された SparkSession を作成します。 SparkSession.builder().getOrCreate()を使用するようにこれらのコマンドをアップグレードすることで、コードをローカルでコンパイルしてテストし、Azure Databricksにデプロイする機能を維持できます。

ターミナル スクリプト コマンドを削除する

Apache Spark では、sys.exit()sc.stop() などのコマンドを使用して、完了したことをプログラムから明示的に宣言する必要があります。 Azure Databricksは、完了に達するとジョブを自動的に終了およびクリーンアップするため、これらのコマンドは不要であり、削除する必要があります。

Azure Databricksは、実行時の終了時に Structured Streaming ワークロードを自動的に終了およびクリーンアップするため、Structured Streaming アプリケーションから awaitTermination() などのコマンドを削除できます。 awaitTermination()を使用するタイミングを参照してください。

Azure Databricksを信頼してクラスターを構成する

Azure Databricksは、回復性とリソース使用量を最大化するために、コンピューティング クラスター内のドライバーと Executor のすべての設定を自動的に構成します。 Executor または JVM に対してカスタム構成を指定すると、パフォーマンスが低下する可能性があります。 Databricks では、ロジックの一貫性が維持されるように型の処理や関数を制御するために必要な Spark 構成のみを設定することをお勧めします。

ワークロードを実行する

Azure Databricksの実行に干渉する可能性があるパターン、コマンド、設定を削除したので、テスト環境でワークロードを実行し、パフォーマンスと結果をレガシ インフラストラクチャと比較できます。 Apache Spark ワークロードのトラブルシューティングとパフォーマンス向上のためにチームが開発したスキルの多くは、Azure Databricksで引き続き活用できますが、Apache Spark、Delta Lake、またはカスタム Azure Databricks 製品の新機能を使用するためのアップグレード手順の方が大きな向上を見ることができます。