編集

次の方法で共有

Spark を使用した Azure での大規模な多数モデルの機械学習 (ML)

Azure Data Factory
Azure Data Lake
Azure Databricks
Azure Machine Learning
Azure Synapse Analytics

この記事では、Azure Databricks または Azure Synapse Analytics のいずれかで Apache Spark を使用する多数モデルのアーキテクチャについて説明します。 Spark は、一部のソリューションで必要とされる、大規模で複雑なデータ変換を行うための強力なツールです。

注意

多数モデルのアプリケーションでは、Spark バージョン 3.0 以降を使用します。 Python と pandas のデータ変換機能とサポートは、以前のバージョンよりも各段に向上しています。

関連記事「Azure Machine Learning を使用した多くのモデルの大規模な機械学習」では、機械学習とコンピューティング クラスターを使用しています。

Architecture

Spark を使用した Azure での大規模な多数モデルの機械学習のアーキテクチャ図。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

  1. データ インジェスト: Azure Data Factory はソース データベースからデータをプルし、Azure Data Lake Storage にコピーします。
  2. モデルトレーニング パイプライン:
    1. データの準備: トレーニング パイプラインは Data Lake Storage からデータをプルし、モデルをトレーニングするため、Spark を使用してデータセットにそれらのデータをグループ化します。
    2. モデルのトレーニング: パイプラインは、データの準備中に作成されたすべてのデータセットのモデルをトレーニングします。 pandas 関数 API を使用して、複数のモデルを並列でトレーニングします。 モデルがトレーニングされた後、パイプラインはテスト メトリックとともにそれを Machine Learning に登録します。
  3. モデル昇格パイプライン:
    1. モデルの評価: 昇格パイプラインは、トレーニング済みのモデルを実稼働環境に移行する前に評価します。 DevOps パイプラインがビジネス ロジックを適用して、モデルがデプロイの条件を満たしているかどうかを判断します。 たとえば、テスト データの精度が 80% を超えているかどうかをチェックする場合があります。
    2. モデルの登録: 昇格パイプラインは、実稼働機械学習ワークスペースに適格なモデルを登録します。
  4. モデルのバッチ スコアリング パイプライン:
    1. データの準備: バッチ スコアリング パイプラインは、Data Lake Storage からデータをプルし、Spark を使用して、スコアリングのためにデータセットにグループ化します。
    2. モデルのスコアリング: パイプラインでは、pandas 関数 API を使用して、複数のデータセットを並列でスコアリングします。 モデル タグを検索することで、Machine Learning の各データセットに適したモデルを見つけます。 次に、モデルをダウンロードし、それを使用してデータセットをスコアリングします。 結果を保持するために、Synapse SQL への Spark コネクタを使用します。
  5. リアルタイム スコアリング: Azure Kubernetes Service (AKS) は、必要に応じてリアルタイム スコアリングを実行できます。 モデルは数が多いので、事前に読み込むのではなく、必要に応じて読み込む必要があります。
  6. 結果:
    1. 予測： バッチ スコアリング パイプラインでは、予測を Synapse SQL に保存します。
    2. メトリック: Power BI がモデルの予測に接続し、表示のために結果を取得して集計します。

コンポーネント

  • Azure Machine Learning は、モデルをより迅速に構築し、デプロイするためのエンタープライズレベルの機械学習サービスです。 このサービスは、ローコード デザイナー、自動 ML (AutoML)、さまざまな IDE をサポートするホストされた Jupyter Notebook 環境などと共に、あらゆるスキル レベルのユーザーに提供されます。
  • Azure Synapse Analytics は、データ統合、エンタープライズ データ ウェアハウジング、ビッグ データ分析を統合した分析サービスです。
  • Synapse SQL は、T-SQL の分散クエリ システムです。データ ウェアハウジングやデータ仮想化のシナリオが可能となるほか、T-SQL を拡張してストリーミングや機械学習のシナリオにも対応することができます。 サーバーレスと専用の両方のリソース モデルが提供されます。
  • Azure Data Lake Storage は、高パフォーマンスの分析ワークロード用の非常にスケーラブルで安全なストレージ サービスです。
  • Azure Kubernetes Service (AKS) は、コンテナー化されたアプリケーションをデプロイおよび管理するためのフル マネージド Kubernetes サービスです。 AKS を使用すると、運用上のオーバーヘッドが Azure にオフロードされるため、Azure でのマネージド ASK クラスターの展開が簡素化されます。
  • Azure DevOps は、アプリケーションとインフラストラクチャの包括的なライフサイクル管理を提供する一連の開発者サービスです。 DevOps には、作業追跡、ソース管理、ビルドと CI/CD、パッケージ管理、およびテスト ソリューションが含まれています。
  • Microsoft Power BI はソフトウェア サービス、アプリ、コネクタのコレクションであり、これらが連携して、関連のないデータ ソースを、一貫性があり視覚的に没入型で対話形式の分析情報に変換します。

代替

  • モデルのトレーニングとスコアリングのために、Azure Databricks で Spark を使用する代わりに、Azure Synapse で Spark を使用できます。
  • ソース データは、任意のデータベースから取得できます。
  • マネージド オンライン エンドポイントまたは AKS を使用して、リアルタイムの推論をデプロイできます。

シナリオの詳細

機械学習の問題の多くは、単一の機械学習モデルで解決するには複雑すぎます。 すべての店舗のすべてのアイテムの売上を予測する場合でも、何百もの油田のメンテナンスをモデル化する場合でも、各インスタンスのモデルを使用すると、多数の機械学習に関する問題の結果が改善される可能性があります。 この 多くのモデルのパターンは、さまざまな業界で非常に共通しており、多くの現実のユース ケースに適用できます。 Azure Machine Learning を使用すると、エンドツーエンドの多くのモデルのパイプラインに、モデル トレーニング、バッチ推論デプロイ、リアルタイム デプロイを含めることができます。

多くのモデル ソリューションでは、トレーニングとスコアリング中にモデルごとに異なるデータセットが必要です。 たとえば、すべての店舗のすべてのアイテムの売上を予測するタスクの場合、それぞれのデータセットはアイテムと店舗の一意の組み合わせに対応します。

考えられるユース ケース

  • 小売り: 食料品店チェーンでは、店舗と商品ごとに個別の収益予測モデルを作成する必要があり、店舗ごとに合計 1,000 個を超えるモデルがあります。
  • サプライ チェーン: 配送会社は、倉庫と製品の組み合わせごとに、在庫を最適化する必要があります。
  • レストラン: 何千ものフランチャイズ店があるチェーンでは、それぞれの需要を予測する必要があります。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

  • データ パーティション：データのパーティション分割は、多くのモデル パターンを実装するための鍵です。 店舗ごとに 1 つのモデルが必要な場合、データセットは 1 つの店舗のすべてのデータで構成され、店舗と同じ数のデータセットがあります。 店舗別に製品をモデル化したい場合は、製品と店舗の組み合わせごとにデータセットがあります。 ソース データ形式によっては、データのパーティション分割が簡単な場合や、広範なデータのシャッフルや変換が必要になる場合があります。 Spark と Synapse SQL は、このようなタスクに対して非常に適切にスケーリングできますが、Python pandas は、1 つのノードとプロセスでのみ実行されるため、適していません。
  • モデル管理: トレーニング パイプラインとスコアリング パイプラインは、各データセットに対して適切なモデルを識別して起動します。 これを行うには、データセットを特徴付けるタグを計算し、タグを使用して一致するモデルを検索します。 タグは、データ パーティション キーとモデル バージョンを識別し、他の情報を提供することもあります。
  • 適切なアーキテクチャの選択:
    • Spark は、トレーニング パイプラインに複雑なデータ変換とグループ化の要件がある場合に適しています。 製品の店舗や場所などの特性の組み合わせによってデータをグループ化する柔軟な分割とグループ化の手法を提供します。 結果は、後続の手順で使用するために Spark DataFrame に配置できます。
    • 機械学習のトレーニングとスコアリングのアルゴリズムが単純な場合は、Scikit-learn などのライブラリを使用してデータをパーティション分割できる場合があります。 このような場合は、Spark を必要としない場合があり、Azure Synapse または Azure Databricks をインストールするときに発生する可能性のある複雑さを回避できます。
    • トレーニング データセットが既に作成されている場合 (たとえば、個別のファイルまたは個別の行や列に含まれている場合)、複雑なデータ変換のために Spark は必要ありません。
    • 機械学習とコンピューティング クラスター ソリューションは、複雑なセットアップが必要な状況に対して大きな多様性を提供します。 たとえば、カスタム Docker コンテナーの使用、ファイルのダウンロード、または事前トレーニング済みのモデルのダウンロードを行うことができます。 コンピューター ビジョンと自然言語処理 (NLP) ディープ ラーニングは、このような多様性を必要とするアプリケーションの例です。
  • Spark のトレーニングとスコアリング: Spark アーキテクチャを使用する場合は、Spark pandas 関数 API を使用して並列のトレーニングとスコアリングを行うことができます。
  • 個別のモデル リポジトリ: デプロイされたモデルを保護するために、トレーニング パイプラインとテスト パイプラインが接続できない専用のリポジトリにモデルを格納することを検討してください。
  • オンライン推論: パイプラインが最初にすべてのモデルを読み込んでキャッシュする場合、モデルのためにコンテナーのメモリが使い果たされる可能性があります。 そのため、待機時間が若干長くなる可能性がある場合でも、run メソッドでモデルをオンデマンドで読み込む必要があります。
  • トレーニングのスケーラビリティ: Spark を使用すると、数十万のモデルを並列でトレーニングできます。 Spark は、クラスター内のすべての VM で複数のトレーニング プロセスをスピンアップします。 各コアは、個別のプロセスを実行できます。 これはリソースが有効に利用されることを意味しますが、特にトレーニング プロセスのコストが高く、実行時間が長い場合は、クラスターのサイズを正確に設定し、適切な SKU を選択することが重要になります。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

Azure でのこのシナリオの実行コストを詳しく知るには、料金計算ツールを使用します。 最初は次の前提で検討することをお勧めします。

  • サービス モデルは、最新の状態を維持するために毎日トレーニングされます。
  • 店舗と製品の組み合わせが 10,000 の 4,000 万行のデータセットの場合、Ls16_v2 インスタンスを使用する 12 の VM がプロビジョニングされたクラスターを使用して Azure Databricks でトレーニングするには、約 30 分かかります。
  • 同じデータのセットを使用したバッチ スコアリングでは、約 20 分かかります。
  • 機械学習を使用してリアルタイムの推論をデプロイすることができます。 要求ボリュームに応じて、適切な VM の種類とクラスター サイズを選択してください。
  • AKS クラスターは必要に応じて自動スケーリングし、その結果平均して 1 か月あたり 2 個のノードがアクティブになります。

自分のユース ケースでは価格がどのように違うかを確認するには、自分の予想されるデータ サイズとサービス負荷の要件に合わせて変数を変更します。 トレーニング データのサイズを拡大または縮小する場合は、Azure Databricks クラスターのサイズを増減させます。 モデルの処理中に同時実行ユーザーを増やすには、AKS クラスターのサイズを増やします。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • James Nguyen | プリンシパル クラウド ソリューション アーキテクト

次のステップ