キーポイント
- Data scientists spend most of their time building out architecture and preparing data, NOT building models
- Feature stores enable features to be registered, discovered, used, and shared for ML pipelines throughout a company
- A combined OLTP/OLAP RDBMS overcomes the latency and complexity in the traditional online (real-time NoSQL) and offline (batch SQL Data Warehouse) feature store architecture
- By streamlining the process of operationalizing machine learning, ML models become far easier to manage, implement, and operate
機械学習は今やビジネス全盛期に入っています。CIOのほぼ半数が2020年までにAIを実装するとして予測されています。その数は今後5年間で大幅に増加すると予想されています。それにもかかわらず、MITの2019年の調査レポートによると、企業が人工知能に投資した10人のエグゼクティブのうち7人は、その影響が最小限であるか、まったくないと報告しました。なぜでしょうか。機械学習モデルを作成することと、それをエンタープライズ環境で運用するという2つのことは、全く異なるものだからです。AIの使用を検討している企業にとっての最大のチャレンジは、機械学習を運用化することです。これは、2000年代にDevOpsがソフトウェア開発を運用化したのと同じです。必要なアーキテクチャを提供し、フィーチャーストアを使って特徴の提供を自動化することでデータサイエンスのワークフローを簡素化することは、機械学習の簡素化、正確性、高速化を大規模に実現するための最も重要な2つの方法です。
データサイエンスワークフロー
典型的なデータサイエンスサイロでは、新しいプロジェクトはパイプラインに従います。
- データソースから関連データの収集
- データのクリーニングと整理
- データを有用な特徴に変換
- モデルを実行するためのアーキテクチャ構築
- 特徴に関するモデルのトレーニング
- モデルのデプロイ
機械学習モデルのトレーニングとデプロイはこの作業の最も重要な部分と思われるかもしれません。しかし、実際にはデータサイエンティストの時間の20%しかモデルのトレーニングとデプロイに費やされていません。残りの80%はデータの準備に費やされています。
採用するデータサイエンティストがどれほど希少で高価であるかを考えると、この非効率性は理想からはほど遠いものです。幸いなことに、MLアーキテクチャとデータから特徴へのプロセスを合理化するMLOpsへのアプローチは数多くあります。
データサイエンスアーキテクチャ
トレーニングデータがノートPCのスプレッドシートに収めることができるような単純なモデルの時代は終わりました。現在、データは最小で数十テラバイトのサイズであり、多くの場合、ペタバイトの規模です。この規模で特徴パイプラインとモデルトレーニングを実行するために必要な分散コンピューティングインフラストラクチャを構築することは、データサイエンティストにとって大きな頭痛の種です。
コンテナは、これらの機械学習の大規模なデプロイに必要になってきています。ただし、モデルをデプロイするには、データサイエンティストが機械学習エンジニアと協力して各コンテナーを構築し、アプリケーションからモデルを呼び出すことができるように、RESTful APIに手動でラップする必要があります。これは不要なコーディングであり、ストレスが溜まることですが、モデルがスケールするように新しいコンテナを作成する必要があります。Kubernetesアーキテクチャのインテグレーションにより、コンテナオーケストレーションが自動化されます。そのため、データサイエンティストはモデルを自動的にスケーリングでき、業界標準になりました。ただし、Kubernetesインテグレーションを実行するには、データサイエンティストがKubernetesエキスパートになるか、機械学習エンジニアと協力する必要があります。
新しいデータベースのデプロイが、モデルのデプロイと同じように簡単になります。従来、上記のコンテナベースのエンドポイントモデルでは、過度のソフトウェアエンジニアリングが必要でした。データベースデプロイメントでは、モデルをデプロイするのに1行のコードしか必要ありません。データベースデプロイシステムは、モデル実行環境を具現化するテーブルとトリガーを自動的に生成します。もうコンテナをいじる必要はありません。データサイエンティストがしなければならないのは、システムが生成した予測データベーステーブルに特徴のレコードを入力するだけです。それによって、これらの特徴に関して推論が行われます。システムは、新しいレコードでモデルを実行するトリガーを自動的に実行します。これにより、予測テーブルにトレーニングセットに追加する新しい例をすべて保持するため、将来の再トレーニングの時間も節約できます。これにより、手動コードをほとんど使用せずに、あるいはまったく使用せずに、予測を継続して最新の状態に、簡単に保つことができます。
フィーチャーストア
MLパイプラインのもう1つの主要なボトルネックは、データ変換プロセス中に起こります。データを手動で特徴に変換し、それらの特徴をMLモデルに提供することは、時間のかかる単調な作業です。
フィーチャーストアは、機械学習モデルへのデータの入力、追跡、ガバナンスを自動化するために作成された特徴の共有可能なリポジトリです。フィーチャーストアは、特徴を計算して保存します。それによって、会社横断それらの登録、検出、使用、共有ができるようになります。フィーチャーストアは、特徴が常に最新の予測に対するものであることを確認し、各特徴値の履歴を一貫した方法で維持します。そのため、モデルをトレーニング、および再トレーニングできます。
フィーチャーストアアーキテクチャ
図1:フィーチャーストアアーキテクチャ
フィーチャーストアは、生データを特徴に変換するパイプラインからデータの供給を受けます。次に、これらの特徴が定義、宣言され、グループ化される。そして、検索を容易にするためにメタデータが割り当てられます。特徴がストアに配置されると、それらを使用して次のものを作成します。
1.トレーニングビュー これは、ラベルを特徴セットと結合する任意のSQL文です。これによって、データサイエンティストは、特徴とラベルが特定の時点で一貫性があることを確認できます。トレーニングビューを使用して、さまざまなトレーニングセットを作成できます。これらのトレーニングセットは、時間によって異なる場合があります。また、含まれる特徴のサブセットによって異なる場合があります。
トレーニングビューの作成は次のとおりです。
2. トレーニングセット これらは、特定の時間枠で指定された特徴のコレクションです。モデルのトレーニングに使用されるラベル(教師あり学習)と組み合わされる場合があります。これは、フィーチャーストアから事前に決定された特徴値の履歴を含むトレーニングセットを取得するための単純な呼び出しです。
図2:フィーチャーストアでのトレーニングモデル
トレーニングセットからSparkデータフレームを作成する方法は次のようになります。
3. 特徴の提供 特徴は、フィーチャーストアから直接モデルに提供されます。それは、予測のためのモデルへの入力として、エンティティの特徴ベクトルを取得するための簡単な呼び出しです。
図3:フィーチャーストアベースのMLソリューションで提供される特徴
最新の特徴を取得するには、次のようにします。
これらのメカニズムにより、フィーチャーストアで次のことができるようになります。
- 自動化されたデータ変換 フィーチャーストアは、生データを特徴値に変換するデータパイプラインを管理します。これらは、スケジュールパイプライン、あるいはリアルタイムパイプラインとなります。スケジュールパイプラインでは、一度にペタバイトのデータが集約されます(大規模小売業者の各顧客の30日、60日、90日平均の支出額の計算など)。リアルタイムパイプラインでは、イベントによってトリガーされて、即座に特徴値が更新されます(クレジットカードを機械に通すたびに、特定の顧客の今日の支出の合計を更新するようなものです)。
- リアルタイムの特徴提供 フィーチャーストアは、機械学習モデルに提供される最新の特徴値で構成される一次元の特徴ベクトルを提供します。たとえば、アプリケーションが特定の製品をユーザに推奨したい場合、モデルは、ユーザが特定の支出カテゴリで費やした平均金額と、過去48時間に買い物に費やした合計時間の長さを知る必要があります。フィーチャーストアには、これらのメトリックに対して、モデルですぐに利用できる最新の値を持っています。それらを計算し、ミリ秒単位でこれらの特徴を提供できるようにするために、データパイプラインを実行するということはしていません。
- フィーチャーレジストリ フィーチャーレジストリは、組織内の特徴定義をカタログ化するための中央インターフェイスです。フィーチャーレジストリには、組織における単一の情報ソースとして、標準化された特徴定義と関連するメタデータが含まれています。フィーチャーストアを使用すると、使用可能な特徴と特徴定義をシンプルかつ簡単に検索できます。フィーチャーストアは、データサイエンティストにAPIとUIを公開します。それは、本番モデル、あるいは開発中のいずれかで使用されている現在利用可能な特徴、パイプライン、トレーニングデータセットを確認できるようにするためです。データサイエンティストは、ユースケースに必要な特徴を選択して、追加のコードなしでモデルに組み込むことができます。
- モデルのトレーニングと再トレーニング フィーチャーストアは、古い特徴を時系列データベースに編成します。そのため、モデルがトレーニングされると、すべての例において同じタイミングに特徴が揃うことになります。すべての履歴フィーチャ値はタイムスタンプとともに保存されるため、フィーチャーストアはフィーチャのトレーニングデータセット全体を生成し、トレーニング用のラベルと適切に位置合わせできます。これらの機能が更新されると、フィーチャーストアはまったく同じ方法でモデルの再トレーニング用に更新されたトレーニングデータセットを生成できます。
- モデルモニタリング モデルからの過去のすべての予測がその時点でのモデルへの入力とともに保存されている場合、モデルの監視はSQLクエリを実行するのと同じくらい容易です。これにより、ユーザはモデルのパフォーマンスを監視し、特徴のドリフト、モデルの予測のドリフト、モデルの精度(ラベルが利用可能になったとき)を追跡できます。フィーチャーストアはすべての特徴値を最新の状態に保ち、すべての履歴値を時間軸で一貫した方法で保持するため、フィーチャーストアでモデルを簡単に監視できます。
フィーチャーストアの利点
図4:フィーチャーストアアーキテクチャのコンポーネント
- データサイエンスの生産性の向上 フィーチャーストアによって、ありふれた、退屈で時間のかかるデータタスクが問題でなくなります。そのため、データサイエンティストが、データの配管でなくモデルの構築と実験にフォーカスを移すことができるようになります。
- 強化されたモデルの精度 フィーチャーストアによって、データの鮮度と一貫性をまったく新しいレベルに引き上げることで、より正確なモデルを実現することできます。データパイプラインをMLモデルから分離することで、計算に数時間かかる可能性のある大規模な集計ベースの機能を、必要なときにすぐに取得できます。これにより、モデルはリアルタイムに、他の方法では得られない特徴値にアクセスできます。モデルがリアルタイムにデータにアクセスできるため、昨日のデータにとらわれることなく、現実の世界で起こっていることに基づいてより正確に予測できます。さらに、時系列で特徴の履歴を維持することにより、自動的に一貫したトレーニングが保証されます。これは、カスタムメイドのトレーニングセットを使う場合に困難なことがよくあります。
- モデルの透明性 規制当局がMLモデルを利用した企業の慣行を監査するとき、フィーチャーストアは予測の系統に透明性を提供します。モデルにどの特徴が組み込まれたかがわかります。どのデータが、トレーニングセット内のどの特徴に相当するものかがわかります。また、一部のフィーチャーストアでは、モデルがトレーニングされたときにデータベースの状態に戻ることもできます。これをタイムトラベルと呼びます。
図5:フィーチャーストアベースのソリューションのデータフロー
データ型
現在、市場に出回っているすべてのフィーチャーストアは、2つの異なるタイプのデータを別々に提供しています。「オンライン」データには、リアルタイムで更新されるキー・バリューのストリームが含まれます。「オフライン」データには、バッチで処理されることが多い大量の分析データが含まれます。従来のフィーチャーストアでは、これらは別々のデータパイプラインで処理されます。
- リアルタイムのデータパイプラインは、MLモデルを動作させるために必要です。MLモデルは、エンドユーザのインタラクションに対してリアルタイムで直接反応するために使用されます。このような場合、特徴のソースは、ストリーミング、データベースの直接挿入、更新操作のいずれかを通して、フィーチャーストアにリアルタイムに接続される必要があります。これらのトランザクションが処理されると、それらを読み取る後続の推論にちょうど間に合うように、ソースから新しい特徴値が生成されます。この種の操作は通常、一度に数行しか影響しないですが、非常に高い同時実行が起こる可能性があります。この低遅延と高同時実行性の処理は、通常、OLTPデータベースの特徴です。
- バッチデータパイプラインは定期的(通常は1日1回または毎週)に発生します。そこでは、データを抽出、ロード、クレンジング、集約、あるいは、データをキュレートして使用可能な特徴にすることにより、大量のソースデータが処理されます。大量のデータを変換するには、通常、スケール可能な並列処理が必要となります。超並列処理データベースエンジンに見られるこの大量のデータ処理は、通常、OLAPと呼ばれます。
ただし、2種類のデータに対して別々のデータパイプラインを持つことには重大な欠点があります。その最も明白な欠点は、2つの別々のデータエンジンにお金を払って管理する必要があることです。さらに、2つの異なるパイプライン間でデータを移動すると、2つの別々のパイプラインの同期を維持することが難しく、遅延が増加します。
別の方法があります。 OLTP/OLAPを組み合わせたデータベースを使用すると、両方のタイプのデータを同じプラットフォームに保存できます。これにより、次のことが可能になります。
- 2つのパイプライン間の遅延の低減
- 2つのデータエンジンに対する支払いと管理の必要性を排除
- 2つの別々のパイプラインの同期を維持する複雑さを簡素化し、データの高可用性を実現
両方の種類のワークロードをサポートし、水平方向のスケーラビリティも提供するデータベースはほとんどありません。しかし、独立してスケールできるACID準拠のOLTPおよびOLAPエンジンは、リアルタイム推論とバッチ推論の両方を直接フィーチャーストアにシームレスに提供します。
例 - レコメンドエンジン
どのようにしてフィーチャーストアがデータサイエンスワークフローに実際に革命を起こし得るかを概念化するために、eコマースビジネスの例を見てみましょう。このビジネスでは、顧客にパーソナライズ化されたアイテムのレコメンドを提供するMLモデルを構築したいと考えています。
顧客が次に見るべき製品を提案するには、モデルに顧客の購買行動を予測するのに役立つデータを提供する必要があります。これには、顧客がサイトで最後に見たアイテムを含めることができる。これはオンラインの特徴であり、MongoDB、DB2、Oracleなどの運用データベースあるいはトランザクションデータベースから取得できます。モデルへのもう1つの入力を、顧客の平均月額支出とすることができる。これは、事前に計算されたオフラインあるいはバッチの特徴であり、RedshiftやSnowflakeなどのデータウェアハウスから取得できます。
図6:レコメンドエンジンのデータモデル
フィーチャーストアがない場合、データエンジニアは、データをMLモデルに提供するために、カスタムメイドのETLパイプラインを手動で作成する必要があります。彼らは、データをウェアハウスからトレーニングセットに、データベースからJupyterノートブックモデルのデプロイに移動するコードを記述しなければなりません。そして、データを使用可能な特徴に変換する設計を手動で行う必要があります。
図7:MLモデルの従来のETLパイプライン
これをスケールさせるのは簡単ではありません。異なるモデルごと、データソースごとに新しいETLパイプラインを作成する必要があるためです。これは機能しますが、パイプラインが常に一貫して使用されるとは限らず、この方法でML操作をスケールするのは非常に時間がかかります。
フィーチャーストアを使うと、データエンジニアは各データソースからフィーチャーストアへのデータパイプラインを1つ構築するだけで済みます。そして、必要な数の機械学習モデルが中央から特徴を引き出すことができます。これには、2つの機械学習モデルを20のモデルと同じようにアーキテクチャ的に構築することで、モデルパイプラインを非常にスケーラブルにすることを意味します。
図8:フィーチャーストアベースのMLモデルにおけるETLパイプライン
この会社の場合、フィーチャーストアの構築は次のように簡単です。
オンライン/オフラインのフィーチャーストア
上で説明したように、ほとんどのフィーチャーストアには、オンライン機能とオフライン機能用に2つの別々のデータベースがあります。この場合、ユーザはこれら2種類の機能を手動で管理する必要があり、一貫性が失われる可能性があります。2つの異なるデータベースについて、同期を維持するために費やされる時間とエネルギーは膨大です。同期を維持することで、何らかの理由で一方がダウンしたときにすぐに元に戻すことができます。
図9:オンラインとオフラインのフィーチャーストアデータベース
オンラインとオフラインの特徴の両方が1つのシステムに保存されている場合、データパリティの実現はより容易になります。フィーチャーストアをACID準拠のハイブリッドデータベースにリンクすると、2つのストア間に不一致が生じることはありません。何か新しいものが導入された場合、データベーストリガーにより、オンラインライブの特徴値とオフラインの特徴の履歴の一貫性が保証されます。これはより効率的で、必要なコードが少なく、一貫性の問題が発生しにくくなります。
図10:フィーチャーストア向けの単一データベースのオンラインとオフラインのユースケース
市場にあるフィーチャーストア
独自に使用するために独自のフィーチャーストアを構築しているテクノロジー企業が多数あります(Uber、Airbnb、Netflixなど)。一方で、オープンソースのオプションもいくつか市場に出ています。これは、フィーチャーストアを使用したいが、自前では構築したくない企業向けとなります。Feast、Splice Machine、Hopsworksは、主要な3つのオープンソースソリューションです。
Feastは、非常に活発なコミュニティを持つオープンソースのフィーチャーストアです。Feastにはすばらしいドキュメントがあり、Python、コマンドライン、Go、Javaなどの優れたSDKサポートを提供しています。そして、現在Kubeflowとのインテグレーションが追加されようとしています。Feastには最近、よりスケーラブルなソリューションのためにSparkとKubernetesのサポートが追加されました。現在、Feastの唯一のオンラインストアはRedisです。
Feastの主な弱点は、オフラインストアを提供していないことです。しかし、間もなく提供する予定です。オフラインストアを提供していないということは、特徴値の履歴の入力を自動化しないことを意味します。この入力は、フィーチャーストアが行うことの大部分を占めるものです。今すぐFeastを使用する場合は、特徴値の履歴を自身で提供する必要があります。データの完全な系列を確保するのは自身の責任となります。
Logical Clocksが提供するHopsworksは、オープンソースのもう1つの選択肢です。そのフィーチャーストアは、Logical Clocks製品のモジュラーコンポーネントであるため、システム全体を使用する必要はありません。また、エンドツーエンドのMLOpsをカバーする完全に統合されたUIも備えています。Feature Store UIは非常に洗練されており、ユーザは特徴、特徴グループ、トレーニングセットなどを検索できます。パイプラインインテグレーションのためにApache Airflowを使って、特徴とグループを、その特徴とグループを作成したパイプラインにリンクできます。セキュリティもシステムに組み込まれています。
Hopsworksは、パイプライン全体で一貫性を生み出すことに取り組んでいます。現在、ユーザは、モデルをデプロイしてパイプラインを作成するために、作業環境の外部でスクリプトを作成する必要があります。さらに、Hopsworksは、オフラインフィーチャーストアにHiveが必要なため、そのストアのために外部システムに依存しています。
Splice Machine Feature Storeには、他のストアのすべての機能が含まれています。主な違いは、単一エンジンの特徴がオンライン/オフラインデータを同じ場所に保存することです。これによって、ACIDに準拠し、単独で一貫性を保つことができます。Feastがオフラインストアを追加した後でも、それらは別々のエンジンであるため、これら2つのストア間の一貫性を保証することはできません。Splice Machineは、オフラインとオンラインのデータの一貫性を100%保証できる唯一のフィーチャーストアを提供します。これは、同じストアにすべてのデータを保持する唯一のフィーチャーストアだからです。
結論
データサイエンスのサイロの大部分では、データサイエンティストは、自分たちが最も得意とすることに集中することができません。彼らはほとんどの時間とエネルギーをMLアーキテクチャの構築と、モデルのためのデータ準備に費やしています。モデルのデプロイを容易にし、機能プロセスを合理化するために必要なアーキテクチャを提供することによって、OLTP/OLAPを組み合わせたデータベースの上にフィーチャーストアを構築することで、データサイエンスの生産性を100倍以上向上させることができます。
著者について
Monte Zweben氏は、Splice Machineの共同創設者兼CEOである。Splice Machineは、データサイエンスと機械学習を容易にするスケーラブルなSQLデータベースである。テクノロジー業界のベテランであるMonte氏の初期のキャリアでは、 NASA Ames研究センターで人工知能部門の副主任として過ごした。そこでスペースシャトルプログラムでの功績により名誉あるSpace Act Awardを受賞した。その後、Monte氏は起業家の世界に移行し、業界をリードするBlue MartiniとRed Pepper Softwareのスタートアップを設立した。Monte氏は、ハーバードビジネスレビューの記事、さまざまなコンピュータサイエンスジャーナル、および会議議事録を公開している。彼はRocket Fuel Inc.の会長であった。カーネギーメロン大学のコンピュータサイエンス学部の学部長諮問委員会の委員を務めている。