次の方法で共有

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

  • [アーティクル]

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

重要

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

parquet を delta に変更する

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 では、構造化ストリーミング ワークロードも実行の終了時に自動的に終了され、クリーンアップされるため、構造化ストリーミング アプリケーションから awaitTermination() や類似したコマンドを削除できます。

クラスターの構成を Azure Databricks に任せる

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

ワークロードを実行する

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