By ドイツのオシン、Provectusのシニアソリューションアーキテクト.

による画像 ユルチャンカ・シアヘイ 　 シャッター.

人工知能と機械学習は変曲点に達しています。 2020年に、さまざまな規模のさまざまな業界の組織が、MLプロジェクトを実験から産業規模での生産に進化させ始めました。 そうしている間、彼らは特徴の定義と抽出に多くの時間と労力を浪費していることに気づきました。

特徴ストアは、効率的な特徴エンジニアリングと管理を可能にするため、MLスタックと堅牢なデータインフラストラクチャの基本的なコンポーネントです。 また、機能の簡単な再利用、会社全体での機能の標準化、オフラインモデルとオンラインモデル間の機能の一貫性も可能になります。 一元化されたスケーラブルな機能ストアにより、組織はより迅速にイノベーションを起こし、MLプロセスを大規模に推進できます。

のチーム プロベクタス はいくつかの機能ストアを構築しており、私たちの経験と学んだ教訓を共有したいと思います。 この記事では、機能ストアがどのようにやり直しを排除し、チーム全体でソースからモデルへのデータのトレーサビリティを強化するのに役立つかを探ります。 スケーラブルな機能ストアの構築の詳細を調べ、リアルタイム機能とトレーニング機能の間の一貫性を実現する方法、およびデータのタイムトラベルによる再現性を向上させる方法について説明します。

フィーチャーストアとは何ですか？

Feature Storeは、機械学習機能のデータ管理レイヤーです。 ML機能は、生の単語、ピクセル、センサー値、データストア内のデータの行、CSVファイル内のフィールド、集計（最小、最大、合計、平均）、派生表現（埋め込みまたは集まる）。

ビジネスの観点から、フィーチャーストアにはXNUMXつの大きな利点があります。

1. モデルあたりのコストの削減による機能エンジニアリングからのROIの向上、 機能のコラボレーション、共有、および再利用を容易にします
2. MLエンジニアの生産性の向上により、新しいモデルの市場投入までの時間が短縮されます。 これにより、組織はストレージの実装とAPIを提供する機能をMLエンジニアから切り離し、レイテンシの問題ではなくモデルで作業できるようにして、より効率的なオンラインサービスを実現できます。

一部のユースケースでは、一元化されたスケーラブルな機能ストアは必要ありません。 特徴ストアは、モデルがシステムのステートフルで絶えず変化する表現を必要とするプロジェクトで機能します。 このような使用例には、需要予測、パーソナライズおよびレコメンデーションエンジン、動的価格設定の最適化、サプライチェーンの最適化、ロジスティクスと輸送の最適化、不正検出、予知保全などがあります。

フィーチャーストアの概念

標準化された機能ストアには、それを中心に展開する特定の重要な概念があります。 それらの概念は次のとおりです。

1. オンラインフィーチャーストア。 オンラインアプリケーションは、予測のためにMLモデルに送信される特徴ベクトルを探します。
2. ML固有のメタデータ。 機能の検出と再利用を可能にします。
3. ML固有のAPIとSDK。 トレーニング機能セットとオンラインアクセスを取得するための高レベルの操作。
4. マテリアライズされたバージョン管理されたデータセット。 MLモデルのトレーニングに使用される機能セットのバージョンを維持します。

著者による画像。

すべての概念は上の画像に表されています。 分析データはデータレイクから取得され、機能エンジニアリングパイプラインを介してプッシュされ、出力は機能ストアに保存されます。 そこから、MLエンジニアは機能を発見し、それらを使用して新しいモデルをトレーニングし、機能を再利用してサービスを提供できます。

これらのXNUMXつの概念は、複数の製品でサポートされています。 市場のリーダーは、Feast、Tecton、Hopsworks、および AWSSageMakerフィーチャーストア。 オープンソース製品であるFeastとHopsworksに焦点を当てます。

＃1ごちそう

ごちそう は、チームがデータと機械学習モデルの間のギャップを埋めるのに役立つMLサービスです。 これにより、チームは本番環境の機能を登録、取り込み、提供、および監視できます。

このサービスは活発な開発段階にありますが、GoJek、Farfetch、Postmates、Zulilyですでにバトルテストが行​​われています。 Kubeflowと統合でき、Kubeflowの強力なコミュニティに支えられています。

2020年現在、FeastはGCPのみのサービスです。 インフラストラクチャが少し重く、構成可能性に欠け、データのバージョン管理を提供していません。 同社は2021年のロードマップでこれらの課題に対処する予定であることに注意してください。2020年XNUMX月から、Feastは Tectonのオープンソースバージョン.

著者による画像。

＃2ホップワークス

ホップスワークス は、AIアプリケーションを開発および運用するためのエンタープライズプラットフォームです。 これにより、チームはML機能を迅速かつ効率的に管理できます。 Hopsworksの背後にあるチームは、フィーチャーストアのエバンジェリストであり、多くの優れた教育コンテンツを提供しています。

Hopsworks機能ストアは、取り込みとトレーニングのためにほとんどのPythonライブラリと統合できます。 また、タイムトラベルのあるオフラインストアもサポートしています。 最も重要なことは、AWS、GCP、Azure、およびオンプレミスに対応していることです。

Hopsworksを使用するのが難しいのは、HopsMLインフラストラクチャに大きく依存していることです。 また、Hopsworksオンラインストアはすべての遅延要件を満たしていない場合があります。

著者による画像。

最新のデータプラットフォームの課題

フィーチャーストアの構築の詳細を検討する前に、最新のデータプラットフォームの課題を検討する必要があります。 特徴ストアは、残りのデータおよび MLインフラストラクチャ.

従来、正規のデータレイクアーキテクチャは次のようになります。

著者による画像。

この高レベルのアーキテクチャには、ソーシング、取り込み、処理、永続化、クエリ、およびコンシューマコンポーネント用のコンポーネントがあります。 ほとんどのタスクで正常に機能しますが、理想的ではありません。

データアクセスと発見可能性 問題になる可能性があります。 データは複数のデータソースとサービスに分散しています。 これはかつてはデータの保護に役立ちましたが、現在は複雑さの新しい層を追加し、データサイロを作成するだけです。 このようなアーキテクチャでは、AWS IAMの役割、Amazon S3ポリシー、APIゲートウェイ、データベースのアクセス許可を管理するという面倒なプロセスが必要になります。 これは、マルチアカウント設定ではさらに複雑になります。 その結果、メタデータはデフォルトでは検出できないため、エンジニアはどのデータが存在し、どのデータに実際にアクセスできるかについて混乱します。 これにより、データアクセスの問題により、データと機械学習への投資が削減される環境が生まれます。

モノリシックデータチーム 考慮すべきもうXNUMXつの問題です。 データと機械学習のチームは非常に専門的であるため、多くの場合、コンテキスト外で操作する必要があります。 所有権とドメインコンテキストの欠如は、データプロデューサーとデータコンシューマーの間にサイロを作成し、バックログされたデータチームがビジネスの需要に追いつくことをかなり困難にします。 データとMLエンジニアリングは複雑な依存関係の犠牲になり、操作の同期に失敗します。 このような状況では、高速でエンドツーエンドの実験は不可能です。

機械学習実験インフラストラクチャ 未知の領域です。 従来のアーキテクチャには実験コンポーネントがないため、データの検出とデータアクセスの問題が発生するだけでなく、データセット、MLパイプライン、ML環境、オフライン実験の再現性を維持するのがより複雑になります。 Amazon SageMakerとKubeflowはここである程度の進歩を遂げましたが、再現性には問題があります。 生産実験のフレームワークは未成熟であり、完全に信頼することはできません。 その結果、XNUMXつのエンドツーエンドの実験をデータから本番MLにプッシュするのにXNUMX〜XNUMXか月かかる場合があります。

本番環境でのMLのスケーリング 複雑で、多くの時間と労力を必要とします。 機械学習は主にオフラインアクティビティ（データ収集、処理、モデルトレーニング、結果の評価など）として説明されていますが、実際に重要なのは、モデルがオンラインで使用および提供される方法です。 従来のアーキテクチャでは、モデルの提供中に統一された一貫した方法で機能にアクセスすることはできません。 また、複数のトレーニングパイプラインとMLアプリケーション間で機能を再利用することもできません。 MLアプリケーションの監視と保守もより複雑です。 その結果、本番環境で1モデルから100モデルに拡張するために必要な時間とコストが指数関数的に増加し、組織が希望するペースでイノベーションを行う能力が制限されます。

新たなアーキテクチャの変化

これらの課題に対処するために、いくつかのアーキテクチャの変更が発生しました。

1. データレイクからフディ/デルタ湖へ。 データレイクは、AmazonS3の単なるフォルダーではありません。 これは、データの取り込み、インクリメンタル処理、ACIDトランザクションとポイントインタイムクエリの提供のための機能豊富なフルマネージドレイヤーです。
2. データレイクからデータメッシュへ。 データドメイン、データパイプライン、メタデータ、およびAPIの所有権は、一元化されたチームから製品チームに移行しています。 もうXNUMXつの影響力のある利点は、データを誰も気にしない副作用ではなく、完全な製品として扱い、所有することです。
3. プラットフォームとしてのデータレイクからデータインフラストラクチャへ。 データの所有権が分散化されている場合、プラットフォームコンポーネントを統合し、再利用可能なデータプラットフォームにパッケージ化する必要があります。
4. エンドポイント保護からグローバルデータガバナンスへ。 一元化されたデータプラットフォームへの移行の一環として、組織はEndpointProtectionからGlobalData Governanceに移行しています。これは、利用可能なデータソース全体のセキュリティおよびデータアクセスポリシーを管理するための高レベルの制御計画です。
5. メタデータストアからグローバルデータカタログへ。 Hiveメタストアのようなメタデータストアは、多くのデータソースを集約できません。 業界は、データの発見、系統、およびバージョン管理に関するユーザーエクスペリエンスをサポートするために、グローバルデータカタログを必要としています。
6. フィーチャーストア。 フィーチャーストアは、MLスタックの新しいコンポーネントであり、MLフィーチャー用に個別のデータ管理レイヤーを追加することで、MLの実験と操作のスケーリングを可能にします。

これらの変換はすべて並行して行われているため、全体的に考える必要があります。 フィーチャストアの設計を開始して、フィーチャと他のデータアプリケーション用に別々のデータカタログを作成することはできません。 機能ストアを構築するときは、他の並列プロジェクトの一部になりやすいデータバージョン管理機能に依存する必要があります。

先に進む前に、前述のばらばらのMLジョブからMLOpsへの変換を推進する、XNUMXつの主要なコンポーネントについて簡単に説明し、機能ストアの重要性についてより幅広いコンテキストを提供します。

＃1デルタ/フディ湖

ACIDデータレイクにより、管理された取り込み、MLトレーニング用の効率的なデータセットのバージョン管理、GDPR / CCPAに準拠するための安価な「削除」、データ取り込み用の「アップサート」が可能になります。 また、スキーマを通じてデータ品質を強化しながら、データセットの変更とACIDトランザクションを追跡するための監査ログも提供します。 デルタ湖とフディ湖はビッグデータにストリーム処理をもたらし、従来のバッチ処理よりもはるかに効率的に新鮮なデータを提供します。

＃2グローバルデータガバナンス

AWS IAMロール、Amazon S3ポリシー、APIゲートウェイ、およびデータベース権限をユーザーレベルで管理することはもはや標準ではないため、全社的なデータガバナンス構造を使用して次のことを行う必要があります。

1. すでに持っているデータでプライバシー運用を加速します。 プライバシーワークフローのビジネスプロセス、データマッピング、PIの検出と分類を自動化します。
2. 中央の場所でポリシーを運用します。 プライバシーポリシーを管理して、ポリシーが企業全体で効果的に管理されるようにします。 ワークフロー、トレーサビリティビュー、およびビジネスプロセスレジスタを定義して文書化します。
3. 複数の規制にまたがるコンプライアンスを拡大します。 新しい規制をサポートするために簡単に拡張できる、プライバシーを念頭に置いて設計および構築されたプラットフォームを使用してください。

＃3グローバルデータカタログ

ここには単一のマーケットリーダーはありませんが、マルケス、アムンセン、アパッチアトラス、コリブラ、アレーション、データハブは言及する価値があります。

グローバルデータカタログは、「このデータは存在しますか？」などの質問に答えるのに非常に役立ちます。 それはどこにある？ このデータの信頼できる情報源は何ですか？ アクセスできますか？ 所有者は誰ですか？ このデータのユーザーは誰ですか？ 再利用できる既存の資産はありますか？ このデータを信頼できますか？ 基本的に、それは一種のメタメタデータストアとして機能します。

＃4再現可能なMLパイプライン

最後のコンポーネントは、実験用の再現可能なMLパイプラインです。

著者による画像。

上のグラフは、MLOpsと再現可能な実験パイプラインのアーキテクチャを表しています。 それは、MLモデルコード、MLパイプラインコード、コードとしてのインフラストラクチャ、およびバージョン管理されたデータセットのXNUMXつの入力から始まります。 バージョン管理されたデータセット（機械学習パイプラインへの入力）は、機能ストアから取得する必要があります。

最新のデータインフラストラクチャ

それでは、最新のデータインフラストラクチャを見てみましょう。

著者による画像。

生データのバッチ処理とイベントデータのストリーム処理があります。 処理されたアーティファクトは、ビジネスレポート用のコールドストレージと、API用にほぼリアルタイムで段階的に更新されるホットインデックスに保存されます。 両方のシナリオで同じデータを使用できます。一貫性を保つために、異なるpub /サブシステムを使用します。

これは、データプラットフォームの従来のアーキテクチャです。 その目標は、コールドストレージとホットストレージの間の一貫性を提供し、データカタログからの検出可能性、データ品質、およびその上でのきめ細かい制御によるグローバルセキュリティを可能にすることです。

著者による画像。

機能ストアの設計を見ると、データプラットフォームにあるものとほぼ同じ機能とインフラストラクチャコンポーネントがわかります。 この場合、機能ストアは、さらに別の取り込みシステム、ストレージ、カタログ、および品質ゲートをもたらす別個のサイロではありません。 これは、データプラットフォームとMLツール間の軽量APIとして機能します。 これは、データインフラストラクチャですでに行われているすべてのものとうまく統合できます。 それは、構成可能で軽量であり、独創的なデザインがないものでなければなりません。

著者による画像。

データインフラストラクチャの設計と構築を開始するときは、これまでに学んだ次の「教訓」を考慮してください。

1. フィーチャーストアに投資する前に、一貫性のあるACIDデータレイクを設計することから始めます。
2. 既存のオープンソース製品からの価値は、統合への投資とそれらがもたらす依存関係を正当化するものではありません。
3. フィーチャーストアは、新しいインフラストラクチャおよびデータストレージソリューションではなく、既存のデータインフラストラクチャに統合された軽量のAPIおよびSDKです。
4. データカタログ、データガバナンス、およびデータ品質のコンポーネントは、機能ストアを含むデータインフラストラクチャ全体に対して水平です。
5. グローバルデータカタログとデータ品質の監視のための成熟したオープンソースまたはクラウドソリューションはありません。

リファレンスアーキテクチャ

著者による画像。

このグラフは、お客様に使用しているリファレンスアーキテクチャを示しています。 それは私たちが使用することを選択したサービスを特徴としていますが、あなたは私たちの選択によって制限されるべきではありません。 ここでの考え方は、寒さを選択する必要があるということです & データワークロードとビジネスニーズに基づいたホットストレージ。

ホットストレージの場合は、DynamoDB、Cassandra、Hbase、またはMysql、PostgreSQL、さらにはRedisなどの従来のRDBMSから選択できます。 ホットストレージが構成可能で、プラグイン可能であり、データインフラストラクチャ戦略と整合していることが重要です。

冷蔵には、ApacheHudiとDeltaLakeが私たちのお気に入りです。 それらは、タイムトラベル、インクリメンタル取り込み、マテリアライズドビューなどの機能を提供します。

図には空白がいくつかありますが、すぐに埋めたいと考えています。 たとえば、これまでのところ、データカタログの既成のリーダーは存在しません。 データ品質ツールも初期段階にあります。 今のところ、優れたツールであるGreatExpectationsまたはApacheDeequから選択できますが、完全なソリューションを提供するわけではありません。

著者による画像。

上の画像では、疑問符は、オープンソースコミュニティによって構築されたソリューションから選択したり、独自のソリューションを社内で構築したり、クラウドプロバイダーとコラボレーションしたりできるスペースを占めています（たとえば、AWSの最新の追加— 機械学習用のAmazonSageMakerフィーチャーストア).

フィーチャーストアで前進

機能ストアのゲームはまだ初期段階ですが、実験を行っているだけでなく、機械学習プロジェクトを本番環境に積極的に移行している組織は、機能を保存、更新、取得、共有するための集中型リポジトリが必要であることをすでに認識しています。

この記事では、そのようなリポジトリを設計および構築する方法を示しました。 ここで取り上げるポイントのいくつかは議論の余地があり、コミュニティからのフィードバックを受け入れることができますが、次のことは明らかです。

1. 既存のデータインフラストラクチャは、望ましい結果を達成するために、ストリーミングの取り込み、整合性、データカタログ、バージョン管理など、機能ストアの要件の少なくとも90％をカバーする必要があります。
2. 軽量のFeatureStore APIを構築して、既存のストレージソリューションと社内で統合することは理にかなっています。
3. コミュニティやクラウドベンダーと協力して、標準や最先端の​​エコシステムとの互換性を維持する必要があります。
4. 市場が成熟するにつれて、マネージドサービスまたはオープンソースの代替サービスに移行する準備ができているはずです。

元の。 許可を得て転載。

関連する

• フィーチャーストアとデータウェアハウス
• 機械学習スタックの重要な欠落部分
• 特徴抽出に関するヒッチハイカーのガイド