Apache Airflowでエンドユーザーのための機械学習パイプラインを構築する Part1
Part1では、既存の「機械学習パイプライン」がどのような処理を行なっているのかをサーベイします。Part0で述べた通り、現在の機械学習パイプラインはエンジニア向けに作られていることが多いです。しかし、現在はエンジニア向けであるものが一般化する、と考えれば既存のパイプラインを調べることに価値はあるはずです。機械学習パイプラインは機械学習プラットフォームと同義/一部となる場合が多く、調査は双方を対象としています。
サーベイの結果、一般的な「機械学習パイプライン」は以下のような構成となるようです。
ポイントとしては、以下の点があります。
- Dataにはバッチ(Offline)とリアルタイム(Online)の概念がある。バッチの場合HDFSに格納しSpark/Hiveで特徴量計算、リアルタイムの場合Kafkaで収集、Samazaで特徴量計算といった形態が取られることが多い。リアルタイムの計算結果は概ねすぐに予測で使用されるため、アクセス効率が高いKey-Valueストア(Casamdraなど)が適している。
- 学習に使うリソースは、Apache Mesosで管理されていることが多い。機械学習アルゴリズムの実行環境は概ねDockerでまとめられるため、今後はKubernetes単体、あるいはKubernetes on Mesosという形が取られるようになるのではないかと思われる。ジョブ実行結果(学習済みモデル、評価メトリクスなど)はModel Storeに保管され、実行結果を見られるダッシュボードが併設される場合が多い。
- 予測には、モデルの実体以外のファイル(入力/出力フォーマットの修正を行うコードetc)が必要なことが多いため、これらはまとめて(バージョン)管理される。切り替え時のA/Bテスト、またデプロイ後の予測監視などを備える場合もある。
- モデルの効率的な実行(パイプライン処理)と、モデル開発のプロトタイピングは、共有すべきところは共有するが分けて考えた方が良い。
この調査結果を基に、Part2以降実際にAirflowを使った実装を行なって行きたいと思います。
以降は、調査した各機械学習パイプライン/プラットフォームの事例を紹介していきます。機械学習プラットフォームには小洒落た名前をつけるのが通例のようで、各社色々な名前をつけています。
Twitter: Deepbird-v2
Twitterの機械学習プラットフォームは、Deepbirdと呼ばれています。元々はLuaで作っていたようですが、TensorFlowベースに移行した際(Deepbird-v2を構築した際)の経緯が以下の記事に書かれています。こちらには、プラットフォームの内容についても記載があります。上図は、書かれている内容を図に書き起こしたものです。
パイプラインの構成要素ごとにまとめると、以下のようになります。
- データ
LZOで圧縮し、メタデータはApache Thriftのフォーマットで管理。HDFSストレージに保存。 - 特徴量
特に記載はないが、データと同様に保存しているもよう。 - モデルの学習
モデルの構築はTensorFlowを使用。Estimator APIを主に使っているよう。学習にはApache Mesosを用い、ハイパーパラメーターのチューニングも行なっているよう。学習状況はTensorBoardで管理。 - モデルの管理
Model Repoという内部ツールで管理。モデルの保管だけでなく、学習時の性能指標も後から参照/比較できるようにしているよう。 - 予測処理
独自のホスティングサーバーを構築。TensorFlow Servingは既存システム(Mesos/Aurora/Finagle)との連携が弱く諦めたそう。
基本的な機能はCloud ML Engineに近いです。そこから、データストアとモデルのホスティングサーバーを独自に構築したという印象です。
Uber: Michelangelo
Uberの機械学習プラットフォームは、Michelangeloと呼ばれています。その概要については以下の記事で解説されており、上図は書かれている内容を図に書き起こしたものです。
印象としては、完全すぎてちょっと気色悪いです。驚くべき点は、この記事が公開されたのが2017年ということです(TensorFlowが公開されたのが2015年末(ほぼ2016年))。おそらくDNN以前から機械学習を活用しており、「既存の機械学習インフラにDNNを載せた」というのが実体に近いのかなと思います。
Michelangeloでは、モデル構築のために試行錯誤するようなプロセスはあまり考慮されていません。そのため、そちらをサポートするMichelangelo PyMLという仕組みが追加されています(2018年)。
柔軟性の高いPyMLで色々と検証し、固まったらスケーラビリティのあるMichelangeloで実行するという感じです。
Michelangeloを通じて改善に成功した事例も公開されています。
先進的な企業と比べても、さらに2歩・3歩先を行っている印象です。機械学習プラットフォームの構築を検討している場合は、まずUberの事例を見るのが良いのではないかと思います。
- データ
Apache Kafkaで収集を行い、Apache Samzaで集約といった形。データは基本HDFSストレージに保存するが(Offline)、予測処理を行う場合ここから取り出していては間に合わないので、Cassandraに計算済みの特徴量を入れている(Online)。 - 特徴量
特徴量は、Feature Storeで管理される。Feature Storeに保管された特徴量は、Offline(モデルの学習など)、もしくはOnline(予測など)で使用される。 - モデルの学習
モデルの構築には、Spark MLlib、TensorFlow、XGBoostなどが使用されている。学習に際して特徴量のデータフォーマットなどを加工する必要がある場合は、DSLを用いて処理を記述する。
学習/ハイパーパラメーターチューニングはApache Mesos/YARNで実行している。学習結果を参照するダッシュボードも開発されている。
評価指標だけでなく、特徴量の貢献度なども見ることができる。
- モデルの管理
作成したモデルのデプロイは、3種類にわかれている。バッチ予測(Offline)、オンライン予測(Online)、他サービスで使われるAPIの内部処理としての使用(Library)。モデルに関連するファイルは、ZIPでひとまとめにして管理している。モデルを2つ同時にデプロイすると、A/Bテストができるという仕組みもある。 - 予測処理
バッチはSpark job、オンラインはクラスタを組んで実行している。 - モデルの監視
モデルの予測結果と、予測の結果発生した実際のデータを結合し、オンラインで精度計測を実行している。
Facebook: FBLearner Flow
FacebookのFBLearner Flowは、機械学習のプラットフォームというよりパイプライン実行のエンジンになっています。TensorFlowのように、各処理をノード(Operator)として表現し、それをつないでグラフ(Workflow)を構築します。グラフを実行した結果、予測や評価指標が得られるという形になっています。
Workflowにおける各Operatorの実行結果、最終的なOutputについてはGUIで確認ができるようになっています。
Airbnb: Bighead
Airbnbの機械学習プラットフォームは、Bigheadと呼ばれています。こちらは解説のスライドがあり、上図はそのスライドからの抜粋となります。
ポイントごとにまとめると、以下のようになります。
- データ/特徴量
独自に開発した、Ziplineというプラットフォームを使っています。データ種別(Online/Offline)ごとの管理、特徴量の共有、データ品質チェックなどの機能を持っているようです。Uberで言及されている点が多く、その意味でやはりUberは先に行っているなという印象です。 - モデルの学習
Redspotという、Jupyter Hubを拡張した環境でモデルを構築しています。Notebookの環境はDockerで管理され、構築したモデルはDockerコンテナとして保存されるようです。開発をサポートするため、パイプライン処理/可視化機能などを提供するライブラリも開発しています。 - モデルの管理
Bighead Serviceで管理されています。モデルのコードと実行のためのDocker ImageをModel Version、パラメーターの重みをModel Arfifactとして2つをセットにして管理しているようです。 - 予測処理
個々のモデルがDockerベースなので、Kubernetesでクラスタを組んで予測を行なっています。
さらに、よく行うパイプライン処理(データ=>前処理=>学習など)はAirflowで実装を行い、実行を自動化しているようです(ML Automator)。
検証はJupyterベースで行い、うまくいくようならAirflowでパイプライン化して処理を自動化する、という感じなのではないかと推察されます。この点は、Uberでも実行はMichelangelo、検証はPyMLと分けていました。
Netflix: Meson
Mesonは、FBLearner Flowと同様のパイプラインの実行エンジンです。Meson自体はワークフロー(=パイプライン)の定義(ScalaベースのDSL)と実行結果を管理しており、ワークフローの実行にはApache Mesosを使っています。
ワークフローにおける各ステップの実行結果はArtifactsとして出力され、この有無で処理をスキップするなどの制御が可能です。
なお、Netflixではこの他にもJupyter Notebookベースの環境を構築しています。こちらは機械学習エンジニアだけでなく、データ分析を必要とする様々な職種のためのプラットフォームとしているようです。
事例を通じて見ると、やはりプロトタイピング環境と実行環境は分けた方がいいのかなという印象です。端的には、プロトタイピングのプロセスを実行環境に混ぜるべきではないという感じでしょうか。柔軟なプロセスを途中に入れてしまうと、その分実行面でハンデを追うことになります。
