Three Principles for Selecting Machine Learning Platforms - The Databricks Blogの翻訳です。
この記事はMLプラットフォーム、オペレーション、ガバナンスに関するシリーズの第二弾となります。最初の記事については、Rafi Kurlansikによるデータを中心とした機械学習プラットフォームに対するニーズをご覧ください。
最近、サイバーセキュリティ会社のデータプラットフォームのシニアディレクターと会話した際に、「そこかしこでツールが変化し続ける中で、どうしたら機械学習プラットフォームを将来にわたって利用できるようにするのか皆目検討がつかないよ」というコメントを聞きました。これは一般的な感情だと思います。機械学習(ML)は、他の技術に比べて遥かに急激に進展しました。研究所からは頻繁に最新のライブラリが公開され、ベンダーたちはツールやプラットフォームを数え切れないほど宣伝しています(Databricksも含まれます)。しかし、これまで議論したように、プラットフォームディレクターは、会社のデータサイエンス(DS)、MLの取り組みを持続性のあるものにするのに完璧なポジションにいると理解するに至りました。彼らの企業は変化し続けるテクノロジーをサポートできるプラットフォームを必要としているのです。
私がDatabricksで過ごした数年間で、長期に渡ってDSとMLチームをサポートするデータプラットフォームを構築した企業を数多く見てきました。これらの企業の多くが最初に直面した課題は、いくつかのエリアにグルーピングされます：データプラットフォームとMLツール間の分断、エンジニアリング、DS、MLチームのコミュニケーション、コラボレーションの欠如、そして、過去のテクノロジーによる変化、成長の阻害です。この記事では、これらの企業が新たなテクノロジーを選択し、DS & MLプラットフォームを改善できるようにガイドした、ハイレベルの提言をご説明します。これらの一般的な失敗、それに対するソリューションは大きく3つの原則にまとめられます。
原則1: 機械学習のためのデータアクセスをシンプルに
DSとMLにおいては容易にデータにアクセスできる必要があります。一般的な障壁には、プロプライエタリなフォーマット、データの帯域の制限、誤ったガバナンスが含まれます。
一緒に働いたお客様のケースが、代表的な例を提供してくれます。この企業は、でータエンジアリングによってメンテナンスされる、きれいなデータを格納するデータウェアハウスを保有していました。また、ビジネスユニットと連携するデータサイエンティストがおり、彼らはXGBoostやTensorFlowといったモダンなツールを活用していましたが、データウェアハウスからDS & MLツールにデータを容易に持っていくることができず、多くのプロジェクトで遅延が発生していました。さらに、プラットフォームのインフラストラクチャチームは、データサイエンティストがデータを彼らのラップトップやワークステーションにコピーすることで、セキュリティリスクを増加させないか心配していました。MLに対するデータウェアハウス中心のアプローチによって引き起こされる軋轢に対応するために、我々は3つのパーツにブレークダウンしました。
PythonとRのためのオープンデータフォーマット
この例において、最初の問題はプロプライエタリなデータを使用していることでした。データウェアハウスはプロプライエタリなフォーマットを使用しており、DSやMLのためにデータを取り出す際には、高価なデータ出力プロセスが必要です。一方で、DS＆MLツールは一般的にSQLではなくPythonやRをベースにしており、ディスク上のParquet、JSON、CSV、メモリー上のPandas、Sparkデータフレームなどを前提としています。画像や音声などの非構造化データにおいては、データウェアハウスに格納できず、処理のための専用のライブラリが必要となり、この問題はさらに悪化します。
データレイクストレージ(Azure ADLS、AWS S3、GCP GCS)を中心としてデータ管理を再設計することで、この企業はデータエンジニアリング、DS&ML両方のデータ管理を統合し、データサイエンティストはこれまで以上に簡単にデータにアクセスできるようになりました。データサイエンティストはPython、Rを使用し、ストレージからデータをデータフレームに直接ロードし、高速なモデル開発と繰り返しが可能となります。また、画像や音声のような特殊なフォーマットを使用できるので、新たなML製品への道を開くことになります。
データの帯域と規模
DS & MLフレンドリーなフォーマットに加えて、この企業はデータの帯域、規模に関する課題に直面していました。小さいデータであれば、データウェアハウスからMLアルゴリズムにデータを投入することはできました。しかし、アプリケーションログ、画像、テキスト、IoTテレメトリーや他のモダンなデータソースは容易にデータウェアハウスのキャパシティを超えてしまい、データ蓄積が高コストとなり、DS & MLアルゴリズムのためのデータ抽出が途方もなく遅くなります。
データレイクストレージをプライマリーのデータレイヤーとすることで、この企業はデータ格納、データ移動に伴うコストを削減しつつも、10倍の規模のデータセットを処理できるようになりました。より多くの履歴データによって、特にレアな例外的イベントを取り扱うケースでモデルの精度を高めました。
統合されたセキュリティ、ガバナンス
従前のデータ管理システムによってこの企業が直面した課題のうち、最も複雑でリスクが高いものは、データセキュリティとガバナンスに関するものです。データアクセスを管理するチームは、テーブルベースのアクセスに慣れ親しんでいるデータベース管理者です。しかし、データサイエンティストはモダンなMLツールにデータを取り込むために、これらの管理されているテーブルからデータセットをエクスポートする必要があります。この分断によるセキュリティ上の懸念と曖昧性は、データサイエンティストが新たなデータソースにアクセスする必要があるときに常に数ヶ月の遅延を引き起こします。
これらのペインポイントによって、データエンジニアとデータベース管理者によって用いられる同じガバナンスモデルの元で、DS & MLツールがデータにアクセスできる統合プラットフォームを選択することになりました。データサイエンティストは、大規模なデータセットをPandas、PySparkのデータフレームに容易に読み込み、データベース管理者はユーザーIDに基づきデータアクセスを管理し、データの漏洩を防ぐことができます。
データアクセスの簡素化に成功すると
このお客様は、DS & MLのデータアクセスをシンプルなものにするために、2つのキーとなる技術上の変更を行いました。(1)プライマリーデータストレージとしてデータレイクストレージを採用。(2)データレイクストレージをベースとして、テーブルとファイルに同じガバナンスモデルを実装。これらの選択によって彼らは、データエンジニアリングには信頼性のあるデータパイプラインを、データサイエンスにはMLに必要なオープンデータフォーマット、管理者にはセキュリティに必要なガバナンスモデルを提供するDelta Lakeを活用したレイクハウスアーキテクチャに移行することになりました。この近代化されたデータアーキテクチャによって、データサイエンティストは半分以下の時間で、新たなユースケースによる価値を提供できるようになりました。
データアクセスをシンプルにしたカスタマーサクセスストーリーには以下のようなものがあります：
- Outreach MLエンジニアはデータにアクセスするためのパイプラインを作ることに時間を浪費していましたが、ETLとMLの両方をサポートするマネージドプラットフォームに移行することで、この問題を低減しました。
- Edmunds データのサイロはデータサイエンティストの生産性を阻害していました。今では、エグゼクティブデイレクターのGreg Rokitaはこう言っています。「Databricksがデータ、データエンジニア、機械学習を民主化してくれたので、今では社内にデータドリブンの原則が浸透しています」
- Shell Databricksがデータアクセスを民主化し、150万以上のお客様に対するレコメンデーションや、全設備、全パーツに対する在庫シミュレーションなど、より大きなデータに対する先進的な分析が可能となりました。
原則2: データエンジアリングとデータサイエンス間のコラボレーションを円滑に
データプラットフォームは、前のセクションで議論したデータアクセスだけではなく、データエンジニアリングとDS & MLチーム間のコラボレーションをシンプルにすべきです。一般的な障壁は、これらの2つのグループが計算、デプロイメント、データ処理、ガバナンスに対して、分断されたプラットフォームを使用していることに起因します。
私が一緒に働いた2番目のお客様においては、成熟したデータサイエンスチームがいましたが、データエンジニアリングのカウンターパートとあまりにも隔離されていると認識されていました。データサイエンスはDS中心のプラットフォーム、ノートブック、オンデマンド(クラウド)ワークステーション、MLライブラリのサポートを有していました。彼らは新たな価値あるモデルを構築できており、データエンジニアは、モデルを、バッチ推論のためのApache Sparkベースのプロダクションシステムへフックするプロセスを持っていました。しかし、このプロセスは苦痛を伴うものでした。データサイエンスチームは、ワークステーションからPythonとRを使用するのには慣れていましたが、データエンジニアリングで用いられるJava環境やクラスターコンピューティングには不慣れでした。これらのギャップは、手際の悪い引き渡しプロセスを引き起こしました：Python、RモデルをJavaに書き直し、同じ振る舞いをするのかを確認し、特徴量生成ロジックを書き直し、スプレッドシートで記録されたモデルファイルを手動で共有します。これらのプラクティスは数ヶ月の遅延、プロダクションにおけるエラーを引き起こし、マネジメントとして見逃せるものではりませんでした。
チーム横断の環境管理
上の例において最初の課題は環境の管理でした。MLモデルは分離されたオブジェクトではありません。これらの振る舞いは、それらの環境に依存し、ライブラリのバージョンによってモデルの予測が変化します。このお客様のチームは、データエンジニアリングのプロダクションシステムにおいて、ML開発環境を再現するために懸命に努力していました。モダンなMLの世界においては、Python(時にはR)を必要とするので、環境を複製するためには、virtualenv、conda、Dockerコンテナーのようなツールが必要となります。
この要件を受けて、彼らはMLflowに目を向けました。MLflowは内部でこれらツールを使用していますが、環境管理の複雑性にデータサイエンティストが直面することはありません。MLflowを用いることで、データサイエンティストは実運用における数ヶ月の遅延を排除し、最新のMLライブラリにアップグレードすることに関して以前ほど心配することはなくなりました。
特徴量生成のためのデータ準備
DS & MLにとっては良いデータが全てであり、(多くのケースでデータエンジニアによる)ETL/ELTと(多くのケースでデータサイエンティストによる)特徴量生成の境界は曖昧です。このお客様においては、データサイエンティストが新たな、あるいは改善された特徴量を運用に乗せる際には、データエンジニアにパイプラインの更新を依頼していました。これを待っている間にビジネスの優先度が変化してしまい、作業が無駄になることもしばしばでした。
彼らは新たなプラットフォームを選択する際、データ処理ロジックを引き渡すことができるツールを探しました。最終的には、彼らはDatabricksのジョブを引き渡しにポイントとして選択しました。データサイエンティストがPythonやRのコードをユニット(ジョブ)にラッピングし、データエンジニアは、既存のオーケストレータ(Apache Airflow)とCI/CDシステム(Jenkins)を用いてそれらをデプロイします。特徴量生成ロジックの更新に対する新たなプロセスはほぼ全てを自動化しました。
機械学習モデルの共有
MLモデルとは、基本的に膨大な量のデータとビジネスゴールを簡潔なビジネスロジックに蒸留したものです。このお客様と働いている過程で、**適切なガバナンスなしに、このような価値のあるアセットが格納、共有されていることに皮肉と恐怖を感じたのです。**オペレーションの観点でガバナンスの欠如は、本格運用に向けて手間がかかる人手でのプロセス（ファイルとスプレッドシート）を必要とし、チームリードやディレクターの見落としを引き起こします。
彼らにとって、単一のモデルレジストリでセキュアなアクセスコントロールの元でMLモデルを共有し、本格運用へと移行できるマネージドなMLflowサービスへの移行はゲームを変えるような出来事でした。ソフトウェアによって、これまでは手動であったプロセスを自動化し、マネジメントはモデルがプロダクションに移行する様子を監視できます。
コラボレーションの円滑化に成功すると
このお客様がコラボレーションを円滑にするために、選択したキーとなるテクノロジーは、共有されたガバナンスとセキュリティモデルを用いて、データエンジニアリングとデータサイエンス両方の要件をサポートする統合プラットフォームに関するものでした。Databricksによって、彼らのユースケースを実現したいくつかの機能には、計算資源、環境の要求に応えるDatabricks Runtimeとクラスター管理、処理単位を定義するジョブ(AWS/Azure/GCP)、オーケストレーションのためのオープンAPI(AWS/Azure/GCP)、CI/CDインテグレーション(AWS/Azure/GCP)、MLOpsとガバナンスのためのマネージドMLflowが含まれます。
データエンジニアリングとデータサイエンスのコラボレーションに関するカスタマーサクセスストーリーには以下が含まれます。
- Condé Nast データパイプラインを管理するチームと先端分析を行っているチームの壁を打ち壊すことで価値を生み出しました。AIインフラストラクチャのプリンシパルエンジニアであるPaul Fryzelは言いました。「我々にとってDatabricksは信じられないほどパワフルなエンドツーエンドのソリューションです。アクション可能なビジネス上の意思決定を行うために、異なるバックグラウンドを持つ様々なチームのメンバーがクイックに利用を開始でき、大量データを取り扱うことができます」
- Iterable データエンジニアリングとデータサイエンスチーム間の断絶が、繰り返しのMLモデルのトレーニング、デプロイメントを妨げていました。MLライフサイクルを整流化するチーム横断のプラットフォームに移行することで、彼らのデータチームはモデルとプロセスの再現性確保をシンプルなものにしました。
- Showtime マネージドMLflowベースのプラットフォームに移行する前は、MLの開発とデプリメントは手動で、エラーが混入しやすいものでした。Databricksは彼らのワークフローのオペレーション上のオーバーヘッドを排除し、新規モデル、新規特徴量の市場投入に至る時間を短縮しました。
原則3: 変化に備える
組織もテクノロジーも変化します。データサイズは成長し、チームのスキルセットとゴールは進化します。そして、テクノロジーも進化し、どんどん置き換えられていきます。明らかかつ一般的な戦略上の誤りは規模の成長に備えないことです。別の一般的かつ目立たない誤りは、データ、ロジック、モデルに対して可搬性に欠けるテクノロジーを選択することです。
最後の原則を説明するために3つ目のお客様のストーリーを共有します。コンテンツの分類を行うためのMLモデルを作ろうとしていたアーリーステージのお客様とともに働きました。彼らはDatabricksを選択しましたが、専門性の欠如から我々のプロフェッショナルサービスに大きく依存していました。一年後、ビジネスに対してある程度の価値を生み出せるようになり、より多くの専門家データサイエンティストを雇用できるようになり、おおよそ50倍以上のデータを収集しました。彼らはスケールする必要があり、分散MLライブラリにスイッチし、他のデータチームとより一層連携する必要がありました。
規模の拡大に備える
このお客様のように、**データ、モデル、企業は時が経つにつれてスケールしていきます。**彼らのデータはもともとはデータウェアハウスに収まっていましたが、データサイズと分析要件が成長するに従って、異なるアーキテクチャーに移行する必要に迫られました。DS & MLチームはもともとはラップトップで作業していましたが、一年後にはより強力なクラスターが必要となりました。事前にレイクハウスアーキテクチャとシングルマシン、分散ML両方をサポートしているプラットフォームで備えることで、この企業は急激な成長に対して円滑に対応することができました。
可搬性および「作るか、買うか」の意思決定
可搬性はより目立たない課題です。**技術的な戦略は、時に「作るか、買うか」の意思決定に単純化し過ぎてしまいます。**これは、「オープンソース技術を用いたインハウスプラットフォームを構築することでカスタマイゼーションを可能としロックインを回避するか、レディメイドのプロプライエタリツールを用いてセットアップを迅速にするか」と言ったものです。この議論は不幸せな選択肢を提示します：カスタムプラットフォームに対する膨大な初期投資か、プロプライエタリテクノロジーによるロックインです。
しかし、これは、**データプラットフォームとインフラストラクチャー、プロジェクトレベルのデータテクノロジーを区別していないので、この議論はミスリーディングです。**データストレージレイヤー、オーケストレーションツール、メタデータサービスはプラットフォームレベルの一般的な技術の選択肢です。データフォーマット、言語、MLライブラリは、プロジェクトレベルの一般的な選択肢です。これらの二つのタイプの選択肢は、変化に備える際には別々に取り扱うべきです。これによって、データプラットフォームとインフラストラクチャを一般的なコンテナとして考え、企業固有のデータ、ロジック、モデルを考える際に役立ちます。
プロジェクトレベルのテクノロジーの変化に備える
**プロジェクトレベルのテクノロジーは容易に切り替えられるようにすべきです。**新たなデータ、MLに基づく製品は、新たなデータソース、MLライブラリ、サービス統合を必要とする異なる要件を持つ場合があります。これらのプロジェクトレベルのテクノロジーの変化に対する柔軟性によって、ビジネスへの適用が可能となり、競合優位性を維持できます。
プラットフォームはこの柔軟性を許容すべきであり、理想的には、チームがデータやモデルに対してプロプライエタリツールやフォーマットを使わないようにすべきです。私のお客様においては、scikit-learnでスタートしましたが、プラットフォームやMLOpsツールを変更することなしに、Spark ML、分散TensorFlowにスイッチすることができました。
プラットフォームの変化に備える
**プラットフォームは可搬性を許容すべきです。**プラットフォームが長期に渡って企業に貢献するためには、プラットフォームはロックインを回避すべきです。プラットフォーム間でのデータ、ロジック、モデル移動はシンプルかつ安価であるべきです。データプラットフォームが企業のコアのミッションでも強みでもない場合には、企業が敏捷で価値のあるアセットを必要に応じて他の場所に移動できる限り、迅速に行動するためにプラットフォームを購入するのは納得のいく話です。
私のお客様においては、scikit-learn、Spark ML、MLflowのようなオープンツール、オープンAPIを利用できるプラットフォームを選択することで、二つの面でメリットが生まれました。最初に、変更を取り消せるという自信を与えることで、プラットフォームの意思決定をシンプルなものにしました。次に、コード、モデルを他のプラットフォームとやり取りすることで、他のデータチームと連携できるようになりました。
| 変化の種類 | プラットフォームへの要件 | プロジェクトレベルの技術の例 |
|---|---|---|
| 規模 | 小規模、大規模データの両方を効率的に処理。 シングルノード、分散コンピューティングの提供 |
Scale pandas → Apache Spark / Koalas Scale scikit-learn → Spark ML Scale Keras → Horovod |
| 新たなデータタイプ、アプリケーションドメイン | 任意のデータ対応、オープンデータフォーマットのサポート バッチとストリーミング両方のサポート 他システムとの連携が容易 |
Delta, Parquet, JSON, CSV, TXT, JPG, DICOM, MPEGなどの使用、結合 ウェブアプリケーションバックエンドからのデータのストリーミング |
| 新たなペルソナ、組織 | データサイエンティスト、データエンジニア、ビジネスアナリストのサポート 大規模なガバナンス、アクセスコントロール |
(a)ノートブックでplotlyによる可視化、(b)プラグイン可能なBIツールのダッシュボードでの可視化 (a)カスタムコード、(b)AutoMLによるMLの実行 |
| プラットフォームの変化 | ユーザーがデータとMLモデルを所有; データ持ち出しの費用が発生しない ユーザーがコードを所有; gitと同期 |
プロジェクトレベルのワークロードがプラットフォームに依存しないように、Keras、Spark MLのようなオープンコードAPIを使用 |
変化への備えに成功すると
変化に適用できるようにするために、このお客様が選択したキーテクノロジーは、シングルマシン、分散ML、MLOpsにおけるライブラリ非依存フレームワークとしてのMLflowをサポートしているプラットフォームであるレイクハウスアーキテクチャです。これらの選択によって、データを50倍にスケールし、より複雑なMLモデルにスイッチし、チームの規模とスキルセットをスケールさせました。
計画とか反省において変化を引き起こしたカスタマーサクセスストーリーは以下の通りとなります：
- Edmunds データチームはデータ処理と、最新のMLフレームワークのようなML要件の両方をサポートするインフラストラクチャを必要としました。彼ら自身のインフラストラクチャの維持には、多大なるDevOpsの労力を必要としました。Databricksのマネージドプラットフォームは、DevOpsのオーバーヘッドをを削減しつつも、柔軟性を提供しました。
- Qubyは、数ペタバイトのデータ、100万以上のモデルの増加に直面しており、レガシーなデータインフラストラクチャではスケールすることも、安定稼働することもできませんでした。Delta LakeとMLflowに移行することで必要とされたスケーラビリティを提供し、データエンジニアリングとデータサイエンスチームが必要とする様々なツールをDatabricksがサポートしていたので、移行をシンプルなものにしました。
- Shellのデータチームのスキルと分析プロジェクト(160以上のAIプロジェクト)は多岐にわたるものでした。DatabricksをShell.aiプラットフォームの基盤コンポーネットとすることで、Shellは現在および未来のデータ要件に必要な柔軟性を手に入れました。
原則を適用する
大袈裟な原則を列挙して、「やれ！」というのは簡単です。しかし、これらの実装には、お使いのテクノロジースタック、組織、ビジネスに対する率直な評価を行った上での計画、実行が必要です。DSとMLをサポートするデータプラットフォームの構築において豊富な経験を持つDatabricksがご支援します。
我々がご一緒した最も成功している企業はいくつかのベストプラクティスに従っています： 彼らはアーキテクチャに対する長期計画と同時に、インパクトと価値をデモンストレーションするための短期計画を実行すべきであることを理解しています。データサイエンスチームとビジネスユニットが連携し、優先度の高いユースケースに取り組むことで、得られた価値が経営層に提供されます。組織横断の連携によって、センターオブエクセレンス(CoE)を結成するプロセスをシンプルなものにし、企業の改善をガイドします。
この記事は、これらのトピックの表層を説明したに過ぎません。他の資料に関しては、こちらをご覧ください。
- Data + AI Summit 2021 keynotes: ここでは、完全なMLライフサイクルに対するデータネイティブかつコラボレーティブなMLソリューションであるDatabricks Machine Learningが発表されています。
- Building Machine Learning Platforms: Matei Zaharia (CTO and co-founder, Databricks), Ben Lorica (Chief Data Scientist, Databricks), and Clemens Mewald (Director, Product Management, Data Science and ML, Databricks)によるウェビナーの録画です。
- MLOps Virtual Event: Operationalizing machine learning at scale: Matei Zaharia (CTO and co-founder, Databricks)および、H&M、J.B. Hunt Transport、Artis Consultingからのスピーカーによるウェビナーの録画です。
- データサイエンス - Databricks、マネージド MLflowのwebページ
次の記事では、MLOps - どのようにデプロイしたモデルをモニタリング、管理するのか、モデルのライフサイクルを完成させるためにどのようにDatabiricksのフル機能を活用するのかにディープダイブします。