Azure Synapse Analytics で Apache Spark 用のライブラリを管理する
ライブラリには、Azure Synapse Analytics (Azure Synapse Spark) の Apache Spark 用プログラムまたはプロジェクトに含める再利用可能なコードが用意されています。
さまざまな理由から、サーバーレス Apache Spark プール環境を更新する必要がある場合があります。 たとえば、次のようなことが考えられます。
- コア依存関係の 1 つで新しいバージョンがリリースされた。
- 機械学習モデルのトレーニングやデータの準備のために追加のパッケージが必要になった。
- より優れたパッケージが利用可能になり、古いパッケージは不要になります。
- Apache Spark プールで使用可能にする必要のあるカスタム パッケージがチームによって構築された。
サードパーティまたはローカル環境でビルドされたコードをアプリケーションで使用できるようにするには、いずれかのサーバーレス Apache Spark プールまたはノートブック セッションにライブラリをインストールします。
パッケージ レベルの概要
Azure Synapse Analytics には、次の 3 つのレベルのパッケージがインストールされています。
既定: 既定のパッケージには、完全な Anaconda インストールと、一般的に使用される追加のライブラリが含まれます。 ライブラリの完全なリストについては、「Apache Spark バージョンのサポート」を参照してください。
これらのライブラリは、Spark インスタンスが起動されるときに自動的に組み込まれます。 別のレベルでさらにパッケージを追加できます。
Spark プール: 実行中のすべての成果物は、パッケージを Spark プール レベルで使用できます。 たとえば、ノートブックと Spark ジョブの定義を対応する Spark プールにアタッチできます。
Azure Synapse Analytics ワークスペースで使用するスタム ライブラリとオープンソース ライブラリの特定のバージョンをアップロードできます。 ワークスペース パッケージは、Spark プールにインストールできます。
セッション: セッション レベルのインストールにより、特定のノートブック セッション用の環境が作成されます。 セッション レベルのライブラリの変更は、セッション間では維持されません。
注意
- プール レベルのライブラリ管理には、パッケージのサイズと必要な依存関係の複雑さに応じて、時間がかかることがあります。更新の最長時間は 50 分に設定されています。 プール レベルのライブラリ管理ジョブが上限の 50 分を超えると、自動的にジョブが取り消されます。 セッション レベルのインストールは、試験的な短期反復のシナリオにお勧めします。
- プール レベルのライブラリ管理により、Notebooks と Spark のジョブ定義を実行するための安定した依存関係が生成されます。 パイプライン実行の場合は、Spark プールにライブラリをインストールすることを強くお勧めします。
- セッション レベルのライブラリ管理は、ライブラリの高速反復や頻繁な変更への対応に役立ちます。 しかし、セッション レベルではインストールの安定性は確約されません。 また、パイプライン実行で %pip や %conda などのインライン コマンドが無効になります。 開発フェーズでは、Notebook セッションでのライブラリ管理をお勧めします。
ワークスペース パッケージを管理する
チームがカスタムのアプリケーションまたはモデルを開発する場合、コードをパッケージ化するために、.whl、.jar、.tar.gz ファイルなどのさまざまなコード成果物を開発する場合があります。
重要
- tar.gz は R 言語でのみサポートされています。 .whl を Python カスタム パッケージとして使用してください。
Azure Synapse では、ワークスペース パッケージをカスタムまたはプライベートの .whl ファイルまたは .jar ファイルにできます。 これらのパッケージをワークスペースにアップロードし、後で特定のサーバーレス Apache Spark プールに割り当てることができます。 それらのワークスペース パッケージを割り当てると、すべての Spark プール セッションにパッケージが自動的にインストールされます。
ワークスペース ライブラリの管理方法の詳細については、ワークスペース パッケージの管理に関する記事を参照してください。
プール パッケージの管理
場合によっては、特定の Apache Spark プールで使用されるパッケージを標準化する必要があります。 この標準化は、チームの複数のメンバーが通常的に同じパッケージをインストールする場合に便利です。
Azure Synapse Analytics のプール管理機能を使用すると、サーバーレス Apache Spark プールにインストールするライブラリの既定のセットを構成できます。 これらのライブラリは、基本ランタイムの上にインストールされます。
Python ライブラリの場合、Azure Synapse Spark プールは Python パッケージの依存関係のインストールと管理に Conda を使用します。 プール レベルの Python ライブラリを指定するには、requirements.txt または environment.yml ファイルを提供できます。 この環境構成ファイルは、その Spark プールから Spark インスタンスが作成されるたびに使用されます。 ワークスペース パッケージをプールにアタッチすることもできます。
これらの機能の詳細については、「Spark プール パッケージを管理する」をご覧ください。
重要
- インストールするパッケージが大きい場合やインストールに時間がかかる場合は、これが Spark インスタンスの起動時間に影響することがあります。
- PySpark、Python、Scala/Java、.NET、または Spark のバージョンの変更はサポートされていません。
DEP 対応 Azure Synapse Spark プールの依存関係の管理
注意
DEP が有効なワークスペースでは、パブリック リポジトリからのパッケージのインストールはサポートされません。 その代わりに、すべての依存関係をワークスペース ライブラリとしてアップロードし、Spark プールにインストールします。
必要な依存関係の特定が困難な場合は、次の手順を実行します。
次のスクリプトを実行して、Azure Synapse Spark 環境と同じローカルの Python 環境を設定します。 このスクリプトには、Azure Synapse Spark の既定の Python 環境に含まれるすべてのライブラリの一覧を含む YAML ファイルが必要です。 この YAML ファイルは、「Apache Spark 3.2 (サポート終了のお知らせ)」や「Apache Spark 3.3 (GA)」など、特定のランタイム バージョンのドキュメント内にあります。
# One-time Azure Synapse Python setup wget Synapse-Python38-CPU.yml sudo bash Miniforge3-Linux-x86_64.sh -b -p /usr/lib/miniforge3 export PATH="/usr/lib/miniforge3/bin:$PATH" sudo apt-get -yq install gcc g++ conda env create -n synapse-env -f Synapse-Python38-CPU.yml source activate synapse-env次のスクリプトを実行して、必要な依存関係を特定します。 このスクリプトは、Spark 3.1 または Spark 3.2 プールにインストールするすべてのパッケージとバージョンが含まれている requirements.txt ファイルを渡すために使用できます。 これにより、入力ライブラリの要件に応じた、新しいホイール ファイル/依存関係の名前が出力されます。
# Command to list wheels needed for your input libraries. # This command will list only new dependencies that are # not already part of the built-in Azure Synapse environment. pip install -r <input-user-req.txt> > pip_output.txt cat pip_output.txt | grep "Using cached *"注意
既定では、このスクリプトは Spark プールにまだ存在していない依存関係のみをリスト表示します。
セッション スコープのパッケージを管理する
データ分析や機械学習を対話的に実行しているときに、新しいパッケージを試してみることや、Apache Spark プールで現在使用できないパッケージが必要になることがあります。 プールの構成を更新する代わりに、セッション スコープのパッケージを使用してセッションの依存関係を追加、管理、更新できます。
セッション スコープのパッケージでは、ユーザーがセッションの開始時にパッケージの依存関係を定義できます。 セッション スコープのパッケージをインストールすると、指定されたパッケージにアクセスできるのは現在のセッションのみとなります。 その結果として、該当するセッション スコープのパッケージは、同じ Apache Spark プールを使用する別のセッションやジョブに影響することがなくなります。 また、これらのライブラリは、基本ランタイムおよびプール レベルのパッケージの上部にインストールされます。
セッション スコープのパッケージを管理する方法の詳細については、次の記事をご覧ください。
Python セッション パッケージ: セッション開始時に Conda environment.yml ファイルを使用して、一般的なリポジトリから追加の Python パッケージをインストールします。 または、
%pipと%condaコマンドを使用して、Notebook コード セルでライブラリを管理することもできます。重要
pip または conda でライブラリを試してインストールするために
%%shを使用しないでください。 その動作は、%pip または %conda と同じではありません。Scala/Java セッション パッケージ: セッションの開始時に、
%%configureを使用して、インストールする .jar ファイルのリストを指定します。R セッション パッケージ: セッション内で
install.packagesまたはdevtoolsを使用することで、Spark プール内のすべてのノードにパッケージをインストールできます。
Azure PowerShell コマンドレットと REST API を使用してライブラリ管理プロセスを自動化する
チームがパッケージ管理 UI にアクセスすることなくライブラリを管理する場合は、Azure Synapse Analytics 用の Azure PowerShell コマンドレットまたは REST API を使用して、ワークスペース パッケージとプール レベル パッケージの更新を管理するオプションがあります。
詳細については、次の記事を参照してください。