既存の 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 に直接関連付けられています。

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

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

スパークセッション作成コマンドを削除する

多くの従来の 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 製品の新機能を使用するように ステップ をアップグレードすることで、より大きなメリットが得られます。