Data Platform for Machine Learning

2019-12-10

Knowledge ManagementMachine LearningData Platform

Apple, Data Platform, Machine Learning

参考
メモ

参考

Data Platform for Machine Learning

メモ

Data Platform for Machine Learning を読んでみた。個人的要約メモを以下に記載する。

Abstract

これまでは数学的な試行錯誤（ここでは機械学習も含んでそう表現していると思われる）に適したデータプラットフォーム（データを保持し、サーブする仕組み、と解釈）がなかった。

既存のデータプラットフォームの課題はいくつかある。いずれにせよ、データ管理の負荷はユーザビリティを下げる。また、昨今求められるコンプライアンス機能（例：terms of use、privacy measure、auditなど）をすべて利用できるわけではない。

本論文では、Machine Learning Data Platform（MLdp）に求められるものをまとめ、Appleにおける経験とソリューションを紹介し、将来のアクションを紹介する。

Introduction

MLdp = Machine Learningのためのデータ管理システム

Motivation

前提とするワークフロー：

data collection
annotation
exploration
feature engineering
experimentation
evaluation
finally deployment

（補足）Appleにおけるワークフローのアブストラクションの考え方が分かるので参考として

強い課題感：サイロ化されたデータストア、サイロ化された知見・アクティビティ ★重要

3種類の動機

エンジニアリングチームのサポート
MLライフサイクルのサポート
MLフレームワーク、データのサポート

ロール3種類 + 1

MLエンジニア
ソフトウェアエンジニア
データサイエンティスト
Legal Team

（補足）よく聞くのは、データサイエンティスト、データエンジニアだが、ここでは、 MLエンジニア、ソフトウェアエンジニア、Legal Teamが挙げられているのが特徴的。

MLでは、データはトラックされること、バージョン管理されることが必要 ★重要

MLdpが満たすべき要件 ★重要

以下の2種類のデータに対するコンセプチャルな表現方法
- ほとんど変化しない大量の永続データ
  - 学習データのセットのこと
  - 再現性担保のため学習データ自体はイミュータブルに扱う
- 揮発性のデータ
  - アノテーションやラベルのこと
  - これらの情報は、業務次第で値を変える可能性がある
  - 学習データセット本体と比べて総量が小さい
上記2種類の要件を満たすハイブリッドデータストア
- さらにバージョニング可能な物理レイアウト
- インクリメンタルな更新、デルタトラッキング、ML学習ワークロードへの最適化
継続的なデータ入力に対するシンプルな機構
データ、特徴量エンジニアリングのためのDSL
著名なMLフレームワークへのインターフェース
- 著名なMLフレームワークでは独自のデータ表現をもっているが、一方でMLdpではフレームワークをまたいだ共通的なデータ表現が必要、など
- データ型も多様である
データセンタ、エッジの両方への対応。
- データへの距離を意識しないとならない
説明可能性を担保するためのバージョニング
データリネージのトラック、データソースのトラック
データ探索と発見
- MLdpでは省力化のための中央集権的なアプローチを採用
コンプライアンスãプライバシーの考慮

3Vの話

SYSTEM ARCHITECTURE AND DESIGN

アーキテクチャは、コントロールプレーン、データプレーンによる構成。 ★重要

各コンポーネントの特徴 ★重要

概念データモデル
- ローデータ、ローデータから生成されたデータ（アノテーション、特徴量）の両方とも表現可能とする
バージョン管理の仕組み
- イミュータブルなデータのスナップショットを用いて、実験の再現性を担保する
データアクセスインターフェース
- MLフレームワークや他のデータ処理エンジンとシームレスに連係可能とする
ハイブリッドなデータストア
- 高頻度でのデータ入力とあまり変化しない大量のデータの両方に対応可能とする
ストレージレイアウト
- バージョン間のデルタトラッキング
- 分散学習のためのデータ並列化
- データ探索と発見を可能とするインデックス
- デバイスとデータセンタの両方での学習のためのストリームI/O
- 学習タスクのためのキャッシュ

4種類のデータセット：dataset, annotation, split, and package に分けて考える。 ★重要

dataset:
- データ本体。学習データに用いる、など。量、サイズが大きい。
annotatoin:
- データ本体に付与したラベル、属性、メタデータなど。量、サイズはdatasetと比べて小さい。
split:
- データ本体を分割したもの。
- （補足）実体はdatasetであり、split自体は仮想的な定義と考えられる。
package:
- dataset / split、annotationを組み合わせた仮想的なまとまり。再現性担保のため、学習セットをまとめて管理するために利用。

以下補足。

datasetに対し、annotationやsplitは「weak object」。つまり、それ単体では存在しない。 annotationやsplitをdatasetとは別に管理することメリットは「multifold」である。 annotationもsplitもdatasetを変更せずに変更可能である。 annotationは個別のコンプライアンスポリシーを持つことがある。

バージョンの表現 -> <schema>.<revision>.<patch> ★重要これにより、スキーマ変更あり・なしを明示しながら、バージョン管理を可能とする。

バージョン管理はユーザが明示的に行う。 ★重要

MLプロジェクト間でのデータシェアにおいて以下を実現。 ★重要

他のプロジェクトへの影響を気にせず、そのプロジェクトの都合でデータをシェアし、スキーマを変更できる。
特定のバージョンをピンどめする。再現性確保。
データのモデルバージョンの依存関係をトラック可能とする

MLプロジェクトにおいてはデータはインターフェースである。 ★名言

MLdpではオブジェクトは以下の状態を遷移する。 ★重要

draft
published
archived
purged

publishされたデータはイミュータブルになる。 ★重要これは再現性を担保するため。

（補足）このオブジェクトのライフサイクルは、S3等のパブリッククラウドのオブジェクトストレージの機能と相性が良さそう。

MLdpでは、表形式のデータ表現を採用。 ★重要

カラムナ表現により、圧縮効率やIO効率の改善だけではなく、カラムの追加削除にも対応しやすくなる。

Spark RDD、DataFrame、Apache DataFrame、Pandas、R DataFrameなどと互換性あり。

MLdpではファイルはバイト列として扱う。

またファイルに対して、ストリーム形式でのアクセスも可能とする。 ★重要

データアクセスのインタフェースのうち、ハイレベルAPIはサーバサイドのバッチ処理向き。つまり前処理などに適している。ローレベルAPIは各種フレームワークとの連係向き。

クライアントでのデータ利用のため、MLdpはキャッシュ機能を持つ。 ★重要（補足）このあたり、Appleだからこそ必要であり、一般企業は果たして必要だろうか。

SQLライクなインタフェースを提供。（その他のDSLもあるようだ）

現在、Pythonと連係可能

MLのデータセットは、複数のファイルをまとめ、MLモデルから扱うことがある。

MLdpをマウントして扱うことができる。いまのところクライアントサイドのシンプルなキャッシュ機構を有している。

またエッジでの利用を想定し、REST APIも提供。

セカンダリインデックスも利用可能。

分散学習のためのスプリットを生成することもできる。

ストレージレイヤのデザインのポイントは以下の通り。

頻繁に更新されるデータにも対応しながら、学習時の高スループットでの処理にも対応
スケーラビリティを持ち、バージョン管理可能であり、バージョン間の差分をトラックできる
ダイナミックレンジクエリ、ポイントクエリに対応し、ストリームI/Oアクセスも可能

in-flightのデータ保持にはKVSを使用し、高頻度での並列での書き込みに対応する。 ★重要スナップショットが取られ、クラウドストレージ上に置かれる。 ★重要

おかれたデータは読み取りに最適化されたものになる。

スナップショットに対する変更は、新しいスナップショットとなって書き込まれる（論文ではcurateされた、と表現されていた）。つまり、スナップショットはイミュータブルな扱いとなる。

in-flightのデータとcurateされたデータをつなぐサブシステムを論文ではdata-pipeと呼ぶ。

MLdpでは複数のデータストアを取り扱うが、ユニファイドなアクセス手段を提供する。 ★重要

in-flightのデータストアは頻繁に更新されるため、それをそのまま機械学習の入力データにすることはあまりない。というのも、再現性を担保するのが難しいからだ。

MLdpではデータをパーティション化して保存するが、パーティションキーはユーザが直接指定するわけではない。その代わりソートキーを指定する。ただし、ソートキーが指定されなかった場合は、システムがハッシュをキーに割り当てパーティションを構成するようにする。

パーティションは複数のブロックで構成される。

データの変更が少ないケースでは、バージョン間で多くのブロックを共有できる。 copy-on-writeで変更のあったブロックが生成される。

（感想）多くの分散ファイルシステムで見られる構成。

このブロックで構成することで、MLdpのクライアントは興味のあるブロックにだけアクセスすればよくなる。またブロックに対するストリームI/Oも可能なので、MLフレームワークからストリームI/Oでアクセスできる。

インデックスもある。そのためブロック単位でのスキャンも可能だし、インデックスに基づくピンポイントでの検索も可能。

セカンダリインデックスの仕組みもある。 ★重要

セカンダリインデックスを用いて、各ブロック内のレコードを取りに行くことになる。

MLの計算クラスタにはキャッシュの仕組みが組み込まれており、透過的に利用できるようになっている。データアクセスし、もしキャッシュヒットしたら、キャッシュからデータを返す。キャッシュシステムが停止している場合は、通常のデータアクセスにフォールバックする。

キャッシュシステムの目的は、レイテンシの低減とReadのスケールアウト。

キャッシュはイミュータブルデータを対象とし、読み取り専用。この単純化のおかげで、結果一貫性などに伴う異常を排除。

FUTURE WORK

将来の課題：データ探索性、システム改善、エコシステムインテグレーション。

データ分析者は、適切なデータを探す。 human-in-the-loop。

カタログは知っている情報を探し当てるもの。データ探索は知らない情報を明らかにすること。両者は異なる。データ探索の活動はそれ自体が機械学習タスクであることもある。

この手のデータ探索はドメインスペシフィックではあるが、共通的な？システム要件もある。例えばコンピュータビジョンなど。

ヘテロジーニアスなデータフォーマットをユニファイドな表現に変換できるようにしたい。

システム的な改善に関する2種類の観点：

レイテンシを下げ、スループットを上げる
human-in-the-loopを減らす

インテントベースのキャッシュを開発したい。つまり、明示的にキャッシュ化するのではなく、頻繁に利用されるデータをキャッシュするようにする、など。

プリフェッチの改善、ローカルバッファリングも改善ネタ。しかし学習の際にランダマイズが必要なのが難しいところ。

Spark等との連携も課題。

各フレームワークは独自のデータ保持方式を持っている。 MLdpを利用しやすいようにしたい。できるだけユーザコードを変更せずに利用できるようにしたい。

データ保持方式に大きく分けて2種類：

" MLdpの独自の方式を採用し、都度変換する。 " もうひとつはTFRecordなどのフレームワークネイティブの方式を採用すること

一長一短。

参考

メモ

Abstract

Introduction

Motivation

関連研究

SYSTEM ARCHITECTURE AND DESIGN

FUTURE WORK