機械学習パイプライン用にデータをオーケストレーションする方法

この記事のリード画像は、HackerNoon のAI Image Generatorによって「コンピューターを見ているロボット」というプロンプトを介して生成されました。

機械学習(ML) ワークロードには、迅速な結果を生み出すための効率的なインフラストラクチャが必要です。モデルのトレーニングは大規模なデータセットに大きく依存します。このデータをストレージからトレーニング クラスターに集めるのは、ML ワークフローの最初のステップであり、モデル トレーニングの効率に大きな影響を与えます。

データおよび AI プラットフォーム エンジニアは、次のような疑問を念頭に置いてデータの管理に長年取り組んできました。

• データ アクセシビリティ: データが複数のソースにまたがり、データがリモートに保存されている場合に、トレーニング データにアクセスできるようにするにはどうすればよいですか?
• データ パイプライン: トレーニング ワークフローで待機せずにデータを継続的に提供するパイプラインとしてデータを管理するにはどうすればよいですか?
• パフォーマンスと GPU 使用率: GPU をビジー状態に保つために、低いメタデータ レイテンシーと高いデータ スループットの両方を実現するにはどうすればよいでしょうか?

この記事では、上記の質問に対処する、エンドツーエンドの機械学習パイプラインのデータをオーケストレーションするための新しいソリューションについて説明します。一般的な課題と落とし穴について概説し、その後、機械学習用のデータ パイプラインを最適化するための新しい手法であるデータ オーケストレーションを提案します。

モデルトレーニングにおける一般的なデータの課題

エンドツーエンドの機械学習パイプラインは、データの前処理とクレンジングからモデルのトレーニング、推論までの一連のステップです。トレーニングは、ワークフロー全体の中で最も重要でリソースを大量に消費する部分です。

次の図は、典型的な ML パイプラインを示しています。データの収集から始まり、次にデータの準備、そして最後にモデルのトレーニングが続きます。データ収集フェーズでは、通常、データ プラットフォーム エンジニアがデータにアクセスできるようにし、データ サイエンティストがモデルを構築して反復できるようにデータを準備するのにかなりの時間がかかります。

トレーニング フェーズでは、モデルを生成する GPU にデータを継続的に供給するために、前例のない量のデータが処理されます。 ML とその実行可能アーキテクチャの複雑さをサポートするようにデータを管理することが不可欠です。データ パイプラインでは、各ステップで独自の技術的な課題が生じます。

データ収集の課題 – データはどこにでもあります

トレーニングは大規模なデータセットから恩恵を受けるため、関連するすべてのソースからデータを収集することが重要です。データがオンプレミス、クラウド、または複数の地理的場所に分散しているかに関係なく、データ レイク、データ ウェアハウス、オブジェクト ストアに存在する場合、すべてのデータをモノリシック ソースに結合することはもはや現実的ではありません。データ サイロでは、ネットワーク経由のリモート アクセスにより必然的に遅延が発生します。望ましいパフォーマンスを維持しながらデータにアクセスできるようにする方法は、大きな課題です。

データ準備の課題 - シリアル化されたデータの準備

データの準備は、収集フェーズからのデータの取り込みから始まり、モデルをトレーニングするためにデータを配信する前のクレンジング、ETL、変換が含まれます。このフェーズを分離して考えると、データ パイプラインがシリアル化され、トレーニング クラスター用に準備されたデータを待機する間に余分な時間が無駄になります。したがって、プラットフォーム エンジニアは、並列化されたデータ パイプラインを作成し、効率的なデータ共有と中間結果の効率的な保存の両方を可能にする方法を見つけ出す必要があります。

モデルトレーニングの課題 – GPU が十分に活用されておらず、I/O バウンド

モデルのトレーニングには、数百テラバイトのデータ (多くの場合、画像や音声ファイルなどの大量の小さなファイル) の処理が必要です。トレーニングには、エポックを複数回実行する必要がある反復が含まれるため、データに頻繁にアクセスします。 GPU に常にデータを供給して、GPU をビジー状態に保つ必要があります。 I/O を最適化し、GPU に必要なスループットを維持することは簡単ではありません。

従来のアプローチとよくある落とし穴

さまざまなソリューションについて説明する前に、以下の図に示すように、単純化されたシナリオを設定しましょう。ここでは、ML フレームワークとして TensorFlow を実行する複数のノードを持つ GPU クラスターを使用して、クラウドでトレーニングを行っています。前処理されたデータは Amazon S3 に保存されます。一般に、このデータをトレーニング クラスターに取得するには 2 つのアプローチがあります。次にそれらについて説明します。

アプローチ 1: ローカル ストレージにデータを複製する

最初のアプローチでは、以下に示すように、トレーニングのためにデータセット全体がリモート ストレージから各サーバーのローカル ストレージに複製されます。したがって、データの局所性が保証され、トレーニング ジョブはリモート ストレージから入力を取得するのではなく、ローカルから入力を読み取ります。

データ パイプラインと I/O の観点から見ると、このアプローチはすべてのデータがローカルであるため、最高の I/O スループットを提供します。トレーニングでは、データがオブジェクト ストレージからトレーニング クラスターに完全にコピーされるまで待機する必要があるため、GPU は最初を除いてビジー状態に保たれます。

ただし、このアプローチはすべての状況に適しているわけではありません。

まず、データセットが集約ローカル ストレージに収まる必要があります。入力データセットのサイズが大きくなると、データ コピー プロセスが長くなり、エラーが発生しやすくなり、GPU リソースが無駄に消費され、より多くの時間がかかります。

第 2 に、大量のデータを各トレーニング マシンにコピーすると、ストレージ システムとネットワークに大きな負荷がかかります。入力データが頻繁に変更される状況では、データの同期が非常に複雑になる可能性があります。

最後に、クラウド ストレージ上のデータとトレーニング データの同期を維持するのが難しいため、データのコピーを手動で作成すると時間がかかり、エラーが発生しやすくなります。

アプローチ 2: クラウド ストレージに直接アクセスする

もう 1 つの一般的なアプローチは、以下に示すように、トレーニングをリモート ストレージ上のターゲット データセットに直接接続することです。このアプローチでは、前のソリューションと同様に、データセットのサイズは問題になりません。しかし、いくつかの新たな課題に直面しています。

まず、I/O とパイプラインの観点から見ると、データはシリアルに処理されます。すべてのデータ アクセス操作はオブジェクト ストレージとトレーニング クラスター間のネットワークを経由する必要があるため、I/O がボトルネックになります。その結果、I/O スループットがネットワークによって制限されるため、GPU は待機サイクルを費やします。

第 2 に、トレーニングの規模が大きい場合、すべてのトレーニング ノードが同じリモート ストレージから同じデータセットに同時にアクセスし、ストレージ システムに多大な負荷がかかります。同時アクセスが多いためストレージが混雑し、GPU 使用率が低下する可能性があります。

第三に、データセットが大量の小さなファイルで構成されている場合、メタデータ アクセス リクエストがデータ リクエストの大部分を占めることになります。その結果、多数のファイルまたはディレクトリのメタデータをオブジェクト ストアから直接取得すると、メタデータの運用コストが増加するだけでなく、パフォーマンスのボトルネックになります。

推奨されるアプローチ – データを調整する

これらの課題と落とし穴に対処するには、機械学習パイプラインで I/O を処理する際のデータ プラットフォーム アーキテクチャを再考する必要があります。ここでは、エンドツーエンドの ML パイプラインを高速化するための新しいアプローチであるデータ オーケストレーションをお勧めします。データ オーケストレーション テクノロジは、ストレージ システム全体でのデータ アクセスを抽象化し、すべてのデータを仮想化し、標準化された API とグローバル名前空間を介してデータをデータ駆動型アプリケーションに提供します。

抽象化を使用してデータ サイロを統合する

データをコピーしたり移動したりするのではなく、オンプレミスでもクラウドでも、そのままの場所に残しておきます。データ オーケストレーションは、データを抽象化し、統一されたビューを作成するのに役立ちます。これにより、データ収集フェーズの複雑さが大幅に軽減されます。

データ オーケストレーションはすでにストレージ システムと統合できるため、機械学習フレームワークは単一のデータ オーケストレーション プラットフォームと対話するだけで、接続されたストレージからデータにアクセスできます。その結果、あらゆるソースからのすべてのデータに対してトレーニングを実行できるようになり、モデルの品質が向上します。データを中央ソースに手動で移動する必要はありません。 Spark、Presto、PyTorch、 TensorFlowを含むすべての計算フレームワークは、データが存在する場所を気にせずにデータにアクセスできます。

データの局所性のために分散キャッシュを使用する

データセット全体を各単一マシンに複製するのではなく、データをクラスター全体に均等に分散できる分散キャッシュを実装することをお勧めします。分散キャッシュは、トレーニング データセットが単一ノードのストレージ容量よりもはるかに大きい場合に特に有利です。データはローカルにキャッシュされるため、データがリモートにある場合にも役立ちます。データにアクセスする際にネットワーク I/O が発生しないため、ML トレーニングがより高速になり、コスト効率が高くなります。

上の図は、すべてのトレーニング データが保存されるオブジェクト ストアと、データセットを表す 2 つのファイル (/path1/file1 および /path2/file2) を示しています。すべてのファイル ブロックを各トレーニング マシンに保存するのではなく、ブロックは複数のマシンに分散されます。データ損失を防止し、読み取りの同時実行性を向上させるために、各ブロックを複数のサーバーに同時に保存できます。

パイプライン全体でのデータ共有を最適化する

ML トレーニング ジョブによって実行されるデータの読み取りと書き込みには、ジョブ内およびジョブ間の両方で高度な重複があります。データ共有により、すべての計算フレームワークが、次のステップのワークロードの読み取りと書き込みの両方で、以前にキャッシュされたデータにアクセスできるようになります。たとえば、データ準備ステップで ETL に Spark を使用する場合、データ共有により、出力データがキャッシュされ、将来のステージで使用できるようになります。データ共有を通じて、データ パイプライン全体のエンドツーエンドのパフォーマンスが向上します。

データのプリロード、キャッシュ、トレーニングを並列化してデータ パイプラインを調整します。

プリロードとオンデマンド キャッシュを実装することで、データ パイプラインを調整します。下の図は、データ キャッシュを使用したソースからのデータの読み込みが、実際のトレーニング タスクと並行して実行できることを示しています。その結果、トレーニング前に完全なデータをキャッシュするのを待つ必要がなく、データにアクセスするときにトレーニングで高いデータ スループットのメリットが得られます。

最初は I/O 遅延が発生しますが、データはすでにキャッシュにロードされているため、待ち時間は減少します。このアプローチにより、ステップを重複させることができます。オブジェクト ストレージからトレーニング クラスターへのデータのロード、キャッシュ、トレーニングへのオンデマンドのデータ ロード、およびトレーニングはすべて並行して実行できるため、プロセス全体が大幅に高速化されます。

新しい推奨アプローチを 2 つの従来のアプローチと比較してみましょう。機械学習パイプラインのステップ全体でデータを調整することで、データが 1 つのステージから次のステージに流れる際のシリアル実行とそれに伴う非効率を排除します。これにより、高い GPU 使用率が得られます。

ML ワークロードのデータをオーケストレーションする方法

ここではAlluxio を例として使用して、データ オーケストレーションの使用方法を説明します。もう一度、同じ単純化されたシナリオを使用します。 TensorFlow ジョブをスケジュールするには、Kubernetes またはパブリック クラウド サービスを使用できます。

Alluxio を使用して機械学習と深層学習のトレーニングを調整するには、通常、次の 3 つのステップで構成されます。

1. Alluxio をトレーニング クラスターにデプロイします。
2. Alluxio をローカル フォルダーとしてトレーニング ジョブにマウントします。
3. トレーニング スクリプトを使用して、ローカル フォルダー (Alluxio によってサポートされる) からデータを読み込みます。

異なるストレージ システム内のデータは、マウント直後に Alluxio を通じてアクセスでき、TensorFlow を変更せずにベンチマーク スクリプトを通じて透過的にアクセスできます。これにより、アプリケーション開発が大幅に簡素化されます。これがなければ、資格情報の構成だけでなく、特定のストレージ システムそれぞれの統合が必要になります。

こちらのガイドに従って、Alluxio と TensorFlow を使用して画像認識を実行できます。

すべてに対応できる万能のアプローチはないため、次のシナリオではデータ オーケストレーションを使用するのが最適です。

• 分散トレーニングが必要です。
• 大量のトレーニング データ (10 TB 以上) があり、特にトレーニング データに小さなファイルや画像が多数ある場合に顕著です。
• GPU リソースがネットワーク I/O によって十分に占有されていません。
• パイプラインは多くのデータ ソースと複数のトレーニング/コンピューティング フレームワークを使用します。
• 追加のトレーニング リクエストを処理する間、基盤となるストレージは安定している必要があります。
• 同じデータセットが複数のトレーニング ノードまたはタスクで使用されます。

機械学習技術が進化し続け、フレームワークがより複雑なタスクを実行するにつれて、データ パイプラインを管理する方法も改善されます。データ オーケストレーションをデータ パイプラインに拡張することで、エンドツーエンドのトレーニング パイプラインの効率とリソース使用率を向上させることができます。

許可を得て転載しています。 © IDG Communications, Inc.、2022.全著作権所有。 https://www.infoworld.com/article/3651453/orchestrated-data-for-machine-learning-pipelines.html 。