既存の Apache Spark コードを Databricks に適応させる

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

重要

Apache Spark のバージョンをアップグレードすると、構文に破壊的変更が生じる可能性があります。Databricks Runtime リリース ノートのバージョンと互換性に関するページと、Spark 移行ガイドを参照してください。

parquet を deltaに変更する

Databricks では、データを書き込むときに、Parquet または ORC の代わりに Delta Lake を使用することをお勧めします。Databricks は、Delta Lake によってサポートされるテーブルとやりとりする際の効率を向上させるため、多くの機能を最適化しています。Parquet から Delta Lake へのデータおよびコードのアップグレードは、数ステップで済みます。「 Parquet データレイクを Delta Lakeに移行する」を参照してください。

Delta Lake は ACIDトランザクション保証を提供しているため、Apache Spark のオペレーションで擬似トランザクションを作成することを目的としたワークアラウンドを除去し、ワークロードをシンプル化できる場合があります。例は次のとおりです。

  • 特定の操作のすべてのファイルをパーティションの一部として同時に検出できるようにするディレクトリ構造またはパーティション分割戦略を構築する。

  • メタストアを構成して、新しいデータの検出方法に関するトランザクション性を追加する。

  • MSCK repair を使用して、メタストアのテーブルに書き込まれたファイルを登録する。

  • alter table add partition を使用してテーブルにパーティションを手動で追加する。

Databricks でテーブルをパーティション分割する場合を参照してください。

注

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

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

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

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

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

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

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

また、Databricks は、実行の終了時に構造化ストリーミング ワークロードを自動的に終了してクリーンアップするため、構造化ストリーミング アプリケーションから awaitTermination() コマンドや同様のコマンドを削除できます。

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

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

ワークロードを実行する

上記変更で Databricks の実行を妨げる可能性のあるパターン、コマンド、設定を削除したので、テスト環境でワークロードを実行し、パフォーマンスと結果をレガシ インフラストラクチャと比較できます。Apache Spark ワークロードのトラブルシューティングとパフォーマンスの向上のためにチームが開発したスキルの多くは、Databricks でも活用できますが、多くの場合、Apache Spark、Delta Lake、またはカスタム Databricks 製品の新機能を使用するようにステップをアップグレードすることで、より大きなメリットが得られます。