DagsterとMetaxyによるMLパイプラインのサンプルレベルバージョン管理

Metaxyを使用して、Dagster上でサンプルレベルの粒度を持つマルチモーダルデータパイプラインを構築する方法を学びましょう 私はダニエル・ガフニと申します。Anam社のMLOpsエンジニアです。 Anamでは、リアルタイムでインタラクティブなアバターを構築するためのプラットフォームを開発しています。当社製品を支える重要なコンポーネントの一つが、自社開発のビデオ生成モデルです。 私たちは、ビデオやオーディオデータのあらゆる種類の前処理を必要とするカスタムトレーニングデータセットでこのモデルを訓練します。MLモデルで埋め込みを抽出したり、アノテーションやデータ合成のために外部APIを利用したりします。もちろん、これらのステップをデータアセットとしてオーケストレーションするためにDagsterを使用しています。 このブログ記事では、これらのパイプラインにおけるサンプルレベルバージョニングを解決するために、私たちが新しいオープンソースフレームワークであるMetaxyとDagsterをどのように組み合わせて使用したかを共有します。 Metaxyは、通常テーブル（またはアセット）レベルで動作するDagsterのようなオーケストレーターと、Rayのような低レベルの処理エンジンを接続し、各ステップで処理すべきサンプルを正確に処理し、余分なサンプルを処理しないようにすることを可能にします。 小さな変更 数ヶ月前、私たちはデータ準備パイプラインに小さな変更を加えることに決めました。当時、私たちは各サンプルのバージョンを追跡するカスタムデータバージョニングシステムを使用していました。このシステムは、手動で指定されたステップの`code_version`と上流ステップ（聞き覚えがありますか？）に基づいて、各ステップのフィンガープリントを計算することができました。Dagsterのデータバージョニングとの唯一の違いは粒度レベルでした：私たちはデータセットの各行に対して計算していましたが、Dagsterはアセットレベルのバージョニングしかサポートしていません。 私たちが導入したかった変更は非常に単純なものでした：ビデオを新しい解像度でクロップしたいと考えていました。これはクロップステージの`code_version`を変更することを意味し、下流のステップは自動的に再計算されるはずでした。しかし、私たちは不快な結果にも気づきました。クロップステップの直後、私たちのパイプラインは2つの領域に分岐していました： 下流ステップの半分は、クロップされたビデオフレームを全く使用していませんでした。それらはオーディオ部分のみを操作していました。しかし、私たちのデータバージョニングシステムはこの詳細を認識しておらず、とにかくそれらを再計算してしまうのです。これは、カスタムオーディオMLモデルをトレーニングデータセット全体で実行することを意味します：非常に高価で、絶対に不要な処理です。 この瞬間、私はデータバージョニングに対する私たちの素朴なアプローチに何か問題があることに気づきました。このブログ記事で議論するプロジェクト、Metaxyのアイデアはここで生まれました。 マルチモーダルデータへの一瞥 ソフトウェアの世界がAIに侵食されるにつれ、より多くのチームや組織がマルチモーダルデータパイプラインと関わり始めています。従来のデータエンジニアリングワークフローとは異なり、これらのパイプラインはテーブルだけでなく、テキスト、画像、オーディオ、ビデオ、ベクトル埋め込み、医療データなども扱います。 マルチモーダルデータパイプラインは非常にユニークであり、要件と複雑さはユースケースによって大きく異なります。HTTP経由でAI APIを呼び出す場合でも、ローカルでML推論を実行する場合でも、単にffmpegを呼び出す場合でも、共通点があります：計算とI/Oは非常に速く高価になります。 従来の（表形式）データパイプラインが再実行されるとき、通常はそれほどコストがかかりません。確かに、ビッグデータは存在し、Sparkジョブはペタバイト級の表形式データをクエリできますが、実際にはこれらの問題に直面するチームはほとんどありません。それがSmall Dataムーブメントが成功した大きな理由です：Snowflakeのスキャンの中央値は100MB未満のデータを読み取り、組織の80％は10TB未満のデータしか持っていません！したがって、表形式パイプラインを再実行することは通常問題ありません。また、増分処理を実装するよりもはるかに簡単です。 マルチモーダルパイプラインは全く別の獣です。それらは数桁多い計算とデータ移動を必要とします。データセット全体でWhisper音声文字起こしステップを誤って再実行してしまいましたか？おめでとうございます：1万ドルが無駄になりました！ そのため、マルチモーダルパイプラインでは、増分アプローチの実装は選択肢ではなく必要条件となります。そして、それは非常に複雑であることがわかります。 Metaxyの紹介 Metaxyは、データセット（またはそのパーティション）しか認識しないDagsterの世界と、個々のサンプルを扱わなければならない計算の世界をつなぐ、欠けていたピースです。 Metaxyには、それをユニークにする2つの特徴があります： 部分的なデータ更新を追跡することができます。 インフラストラクチャに依存せず、Pythonで書かれた任意のデータパイプラインに接続できます。 Dagsterがデータバージョンを計算するために採用しているのと同じアプローチを実装していますが、それを拡張しています： 一度に数百万行を処理するために、バッチで動作するように リモートデータベースまたはローカルで実行できるように データフレームエンジンやDBに依存しないように データフィールドを認識するように：Metaxyの各データバージョンは文字列ではなく、実際には辞書です。 Metaxyの主な目標の一つは、粒度の細かい部分的なデータバージョニングを可能にし、部分的な更新が正しく認識されるようにすることです。Metaxyでは、通常のメタデータ列に加えて、ユーザーはデータフィールドを定義し、バージョン管理することもできます： データフィールドは任意であり、ユーザーが適切と考えるように設計できます。重要なポイントは、データフィールドが表形式のメタデータではなく、データ（例：mp4ファイル）を記述することです。 その後、数行のPythonコードを実行できます： ```python with store: increment = store.resolve_update("video/face_crop") ``` これは裏側で多くの作業を行います： 上流ステップの状態テーブルを結合する 各行の期待されるデータバージョンを計算する - これが最も複雑なステップです。各バージョンが辞書であり、辞書の各フィールドが独自の上流フィールドのサブセットに依存する可能性があるため、複雑です 解決対象のステップの状態テーブルをロードし、バージョンを期待されるものと比較する 新規、陳腐化、孤立したサンプルをユーザーに返す ユーザーがincrementオブジェクトを取得すると（ちなみに、これは遅延評価可能です！）、各カテゴリのサンプルをどうするかを決定できます：通常、新規と陳腐化は再処理され、孤立したものは削除される可能性があります。 Metaxyは、部分的なデータ依存関係を認識することで、「小さな変更」問題を解決します。 3つのMetaxyフィーチャー（Metaxyが各ステップで生成されるデータを呼ぶ方法）を考えてみましょう：ビデオファイル（`video/full`）、Whisper文字起こし（`transcript/whisper`）、顔の周りでクロップされたビデオファイル（`video/face_crop`）： オーディオとフレームの別々の情報パスは色分けされています。フィーチャー間に明確なフィールドレベル、または部分的なデータ依存関係があることに注目してください。各フィールドバージョンは、それが依存するフィールドのバージョンから計算されます。同じフィーチャーからのフィールドバージョンは、その後結合されてフィーチャーバージョンを生成します。 `transcript/whisper`フィーチャーの`text`フィールドが`video/full`フィーチャーの`audio`フィールドにのみ依存していることは明らかです。もし`video/full`のサイズを変更することに決めたとしても、`transcript/whisper`は再計算する必要はありません。 Metaxyはこの種の「無関係な」更新を検出し、上流の変更の影響を受けないフィールドを持つ下流フィーチャーの再計算をスキップします。これは、各フィーチャーの各サンプルの各フィールドに対して個別のデータバージョンを記録することで実現されます： ``` metaxy_provenance_by_field {"audio": "a7f3c2d8", "frames": "b9e1f4a2"} {"audio": "d4b8e9c1", "frames": "f2a6d7b3"} {"audio": "c9f2a8e4", "frames": "e7d3b1c5"} {"audio": "b1e4f9a7", "frames": "a8c2e6d9"} ``` 構成可能性の課題 先に述べたように、増分パイプラインは多様です：それらはしばしばユニークな環境で実行され、特定のインフラストラクチャ、異なるクラウドプロバイダー（Neocloudsを含む）、またはRayやModalのようなスケーリングエンジンを必要とします。 Metaxyの目標の一つは、Dagsterと同じくらい汎用的で依存性がなく、この多様なユースケースをサポートすることでした。Metaxyは、異なるユーザーや組織が使用できるようにするために、プラグ可能でなければなりませんでした。 そして、これは可能であることがわかりました！Metaxyによって行われるメタデータ管理作業の95％は、データベースに依存しない方法で実装されており、PolarsやDuckDBでローカルでも実行できます！ これは、IbisとNarwhalsプロジェクトに投入された信じられないほどの作業量によってのみ可能になりました。Ibisは同じPythonインターフェース（典型的なDataFrame APIではありません）を実装しています...

DagsterとMetaxyによるMLパイプラインのサンプルレベルバージョン管理

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト