「データプラットフォームから機械学習プラットフォームへ」

「美容ファッションの世界：データプラットフォームから機械学習プラットフォームへの転換」

データ/ MLプラットフォームの進化と複雑なMLOpsの実践のサポート方法

データ/ MLは、私たちのテックランドスケープで最も人気のあるトピックです。データ/ MLプラットフォームの理解と、それらのプラットフォームが基本から複雑に進化する方法について共有したいと思います。最後に、MLプロジェクトを管理するための原則であるMLOpsについてもカバーします。

私の紹介については、こちらのLinkedInをご覧ください。

旅の始まり：オンラインサービス+OLTP+OLAP

最初の段階では、データインフラストラクチャはかなりシンプルになる可能性があります。分析クエリは、オンラインOLTPデータベースの読み取りレプリカに送信されるか、データウェアハウスとしてのOLAPデータベースが設定されます。

以下は、インフラストラクチャの例です：

• エントロピー正則化強化学習の説明
• 「2023年に使用するためのトップ9のデータ管理ツール」
• 「5分でイメージ検索」

これらのシステムに問題はありません。ビジネス要件を満たすシステムはすべて良いシステムです。シンプルな場合はなお良いです。

この段階では、データ分析を行うための複数の方法があります：

1. 単にOLTPデータベースのレプリカノードにクエリを送信する（推奨されない方法）。
2. OLTPデータベースのCDC（変更データキャプチャ）を有効にし、そのデータをOLAPデータベースに取り込む。CDCログのインジェスチョンサービスのオプションは、選択したOLAPデータベースに基づいて選択できます。例えば、CDCコネクタを使用したFlinkデータストリーミングは、これを処理する方法の一つです。多くのエンタープライズサービスは、独自の推奨ソリューションを提供しています。例えば、Snowflakeの場合はSnowpipeを使用することが推奨されます。データをマスターノードのCPU/IO帯域幅を保持するためにレプリカノードからロードすることも推奨されます。

この段階では、MLのワークロードはローカル環境で実行されるかもしれません。ローカルでJupyterノートブックを設定し、OLAPデータベースから構造化データを読み込んでMLモデルをローカルでトレーニングすることができます。

このアーキテクチャの潜在的な課題は、次のようなものです：

• OLAPデータベースでは、非構造化または半構造化のデータを管理するのは難しいです。
• 大量のデータ処理に対して性能の低下が起きる可能性があります（単一のETLタスクにTBのデータが必要な場合）。
• さまざまなコンピュートエンジン（SparkやPrestoなど）へのサポートが不足しています。ほとんどのコンピュートエンジンは、JDBCエンドポイントを介してOLAPに接続することはできますが、並列処理はJDBCエンドポイント自体のIOボトルネックによって制限されます。
• OLAPデータベースに大量のデータを保存するコストが高いです。

おそらく、これを解決する方法を既に知っているかもしれません。データレイクを構築しましょう！データレイクを導入することは、完全にOLAPデータベースを廃止する必要があるわけではありません。異なるユースケースに対応するため、2つのシステムが並行して存在することも一般的です。

データレイク：ストレージ-コンピュートの分離+書き込み時のスキーマ

データレイクは、非構造化および半構造化データを永続化し、書き込み時にスキーマを行います。専用のストレージソリューションを使用して大量のデータを格納し、需要に応じてコンピュートクラスタを起動することでコストを削減することができます。また、コンピュートクラスタをスケールアップすることで、TB / PBのデータセットを簡単に管理することができます。

以下は、インフラストラクチャの例です：

これは、実際のデータレイクの実装ははるかに複雑な場合もある、非常に単純化されたグラフです。

クラウドプロバイダの多くは、AWS S3やAzure ADLSなどのデータレイクのためのソリューションを提供しています。しかし、これらのストレージソリューションの上にはまだ多くのタスクが残っています。たとえば、テーブルのメタデータを管理するためのHiveメタストアや、データの可視化を提供するDatahubが必要です。また、データレイクでの細かいアクセス制御やデータのラインナップ解析（例：spline）など、課題もあります。

データレイクの価値と効率を最大限に活用するためには、各レイヤーのファイル形式と平均ファイルサイズを注意深く選択する必要があります。

一般的なポイントは次のとおりです：

• 小さいファイルを避けること：小さいファイルはデータレイクの高いストレージコストとパフォーマンスの低下の主な原因の1つです。
• 遅延、圧縮率、パフォーマンスのバランスを取ること：低遅延のHudiのようなファイル形式を使用したデータレイクテーブルは、最適な圧縮率を提供しないかもしれません。一方、高い圧縮率を持つ大きなORCファイルはパフォーマンスの悪夢を引き起こすかもしれません。ファイル形式は、テーブルの使用パターン、遅延要件、テーブルサイズに基づいて賢く選択する必要があります。

データブリックスなどの確立されたSaaS/PaaSプロバイダ（Databricks）は、まともなデータレイク（またはLakeHouse）ソリューションを提供しています。また、ByteHouseを利用してビッグデータ分析の統一的なエクスペリエンスを試すこともできます。

MLの面では、チームはリモート環境でTensenflowやPytorchなど、確立されたMLフレームワークを探求し始めるかもしれません。さらに、トレーニングされたMLモデルはオンラインのモデル推論のために本番環境に展開される可能性があります。TensorFlowとPytorchの両方には、TensorFlow ServingやPytorch Servingなどのサービングソリューションが付属しています。

しかし、私たちの旅はここで終わりません。私たちは現在、次の課題に直面しているかもしれません：

• オンラインのMLモデルサービングにとって重要なリアルタイムのメトリックとフィーチャー管理の不足。
• モデルのパフォーマンスモニタリングの不足。

さらに進んでいきましょう。

リアルタイムデータ/MLインフラ：データリバー+データストリーミング+フィーチャーストア+メトリックサーバー

リアルタイムデータインフラの構築には、通常、複数の部門の協力が必要です。データリバーを構築する最初の理由は、データ/MLシステムではなく、マイクロサービスが同期呼び出しを解除してさらにスケーリングできるようにすることです。代わりに、マイクロサービスはKafkaのようなメッセージブローカーと通信することで効率を上げます（一貫性レベルの低下の代償として）。

全体的なアーキテクチャは次のようになります。

データリバー（Kafkaなど）で利用可能なデータを使用して、リアルタイムデータ処理のためのデータストリーミングパイプラインを構築できます。これらのデータはオンラインフィーチャーストアで直接使用されるか、Pinotのようなメトリックサーバーに同期されます。メトリックサーバーは、これらのメトリックポイントをより有用なモデルパフォーマンスメトリックやビジネスメトリックに変換/集計することができます。また、ストリーミングデータベース（RisingWaveなど）を採用することで、SQL構文でストリーミングデータを結合/集計することも可能です。

データストリーミングの構築には、Flinkが非常に人気です。また、Flink with CDC connectorを使用してOLTPデータベースからデータを抽出し、メッセージブローカーやデータレイクにデータをシンクすることもできます。

オンラインフィーチャーストアは、ScyllaDBやAWS Dynamo DBのようなキーバリューデータベースによってバックアップされるべきです。オンラインフィーチャーストアは、特定の参照ID（ユーザーID、製品UUID）に関連するフィーチャーベクトルを使用してモデルサービングサービスに送信されるリクエストを豊かにするのに役立ちます。これにより、マイクロサービスを構築するバックエンドサービスチームとMLモデルを構築するMLエンジニアチームの依存関係が大幅に解消されます。新しいML機能と新しいMLモデルを独立して展開できるため、MLエンジニアはフィーチャーベクトルを更新してもマイクロサービスに公開されるモデルサービスのAPIシグネチャは変わりません。

『デザイニングマシンラーニングシステム』という本では、モデルスタッキングについて共有されています（Jen Wadkin’sのVoAGI投稿でのモデルスタッキングについての共有）。モデルサービングでもモデルスタッキングを使用するのは非常に一般的です。異種モデル（例：PyTorchモデルとTensorFlowモデル）を一緒にスタックしたい場合、オーケストレータが必要です。リクエストを異なるモデルにルーティングする際に、モデルのパフォーマンスに基づいて動的な重み付けを行うこともできます。

ところで、私たちは複雑なシステムを持っています。それはかなりクールに見えますが、新しい課題が発生します：

• システムの負債が未管理のままであると、高く上昇するでしょう。
• MLエンジニアにとっての高い認知負荷。

それがMLOpsがどのように役立つかを考える必要がある時かもしれません。

MLOps：抽象化、可観測性、スケーラビリティ

MLOpsは特定の解決策ではありません。それはむしろMLシステムを管理するための一連の原則のようなものです。通常のソフトウェアプロジェクトとは異なり、MLシステムはデータの変化に大きく影響を受け、データ依存管理は容易な課題ではありません。論文Hidden Technical Debt in Machine Learning Systemsは、これらの課題を詳細に説明しています。したがって、MLOps駆動のMLプラットフォームは次の機能を持つ必要があります：

• データ変更の監視とデータ品質の監視。
• オフラインおよびオンラインの環境を横断するMLフィーチャーの管理。
• 実験的－運用的な対称性を満たす再現可能なMLパイプライン。
• インフラの詳細を抽象化できる簡潔なMLパイプラインの設定。

この記事、MLOps：機械学習における継続的なデリバリーと自動化パイプラインでは、実験的－運用的な対称性の重要性が強調されています。それはまた、レベル0、レベル1、最終的にはレベル2までのMLOpsの自動化レベルについて説明しています。このドキュメントからのグラフがとても気に入っていて、単にレベル1のMLOpsがどのようなものか説明するために借用させていただきます。

このようなMLOpsの実践を組織全体に拡大するためには、MLエンジニアにとってインフラストラクチャの実装詳細を抽象化した簡潔なMLパイプラインの設定を提供する必要があります。これにより、プラットフォームエンジニアもプラットフォームユーザーにあまり影響を与えることなくMLプラットフォームをアップグレードする柔軟性を持つことができます。MLパイプラインコントローラーによって実際の作業負荷に変換されるMLパイプラインを記述するために、yamlなどの設定ファイルを使用することを検討してください。

リアルタイムデータ/MLインフラを再編成しましょう。以下のグラフを使用して、MLOpsが私たちのプラットフォームを形作る方法を強調します。

MLパイプラインがどのようになるかをより具体的に理解するために、各ステージの可能な抽象化の例を示します。以下のグラフは実際の実装を表していませんが、構成のイメージをさらに理解するのに役立ちます。すべての必要な側面を網羅しているわけではありません。

KubernetesはMLワークロード（または現在のすべてのワークロード）をオーケストレーションする人気のある解決策です。CRDを使用して、ユーザーとプラットフォームの間の簡潔なインタフェースを提供できます。記事「Kubebuilderの考え方」では、kubebuilderでCRDを構築する際の私の考えを共有しました。

もちろん、以下のような重要なサブトピックを網羅していませんが、これらに限定されません：

• ハイパーパラメータの最適化
• 分散トレーニングアーキテクチャ

次は何か

MLOpsは既知のミッションに適切な名前を与えるだけです。それはまだ終わっていない仕事です。私が共有したのは、ML Opsプラットフォームを実装するための主観のある戦略です。それでも、高品質のML製品を作成するためのハードルは依然として高く、データの収集、処理、マイニングの取り組みは依然として大変です。

これらの課題に加えて、私が観察したMLのトレンドも共有したいと思います。この領域がどれだけ速く進化しているかを考えると、これは完全なリストではないことは確かです。

• サーバーレス：MLの価値をあまりにも後回しにしてきたため、MLプラットフォームの基盤は通常、データプラットフォームです。それは、ユーザーに社会メディアプラットフォームで参加するためのコンピュータを購入させるのと同じです。多くのサービスプロバイダーが、採用のハードルを下げるために独自のサーバーレスソリューションを開発しています。例えば、Databricks、Snowflake、Bytehouseなどです。企業はデータウェアハウス、データレイク、またはレイクハウスを立ち上げた後、ML製品の構築を開始することができます。
• AIによる特徴エンジニアリング：AIはすべてを行うことができますね。
• MaaSのトレンド：より強力なモデルサービスが登場します。企業は独自のMLサービスを構築せずに、ビジネスに大きな恩恵をもたらすために直接MLのパワーを利用できます。

皆さんもご存知の通り、MLの領域は非常に速いペースで進化しています。この瞬間、私がこれを入力しているときには、この記事はすでに期限切れかもしれません。新しいアイデアがすでに出てきて、現実に変えられているかもしれません。ML Opsについてのご意見や私が学習を進めるべき場所など、どのように思われるかご意見をお聞かせください。一緒にペースを維持しましょう！

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!