テクノロジー

Spark+AI Summit 2019へ行ってみた 〜参加レポート〜

こんにちは、BE部データソリューションチーム所属の棚谷です。
今回は、2019年4月23日から25日までにサンフランシスコ モスコーニ・センター・ウエストで開催されたSpark+AI Summit 2019に参加してきたので、
その様子をレポートします。

Spark+AI Summitとは

Spark+AI Summitとは分散処理フレームワークの一つである Apache Spark に関するテクノロジーカンファレンスであり、最新機能の紹介やsparkを活用した事例紹介などの講演がなされます。今回は全体で約5000名、アジア地域から約150名、日本から約20名を超える人々が参加しているそうです。D2Cでも分析業務でsparkを活用しています。
企業展示会場の様子

セッションについて

セッションは大きく15分野に分かれており,初歩的なsparkの使い方から機械学習技術の活用事例・spark自体のアーキテクチャに関する研究発表まで幅広いユーザ層を対象にしています。
私は今回機械学習システムのアーキテクチャや運用に関する Productionizing ML、データエンジニアリングに関する Data Engineeringのセッションをメインに聞きました。本記事では紹介されたサービスや他社事例を抜粋して紹介いたします。なお講演の動画とスライドはyoutubeのdatabricksのアカウントspark summitのHPにアップロードされています。

databricks

Spark 3.0(2019 lateリリース予定)
  • Project Hydrogen
  • Accelerator-aware scheduling : SparkでGPUクラスタをサポート(spark-24615)
  • Standardize Optimized Data Exchange between Spark and DL/AI frameworks : 機械学習フレームワークの入出力形式へのデータ変換(SPARK-24579)
  • Koalas
  • Pandas API on Apache Spark
  • デモを見る限り、単純にpandas->koalasへの置き換えで動くらしい
  • Delta Lake
    Spark上で動くデータのACIDを担保するフレームワークのオープンソース版(元々databricksのサービス)
  • ストリーミングとバッチで生成されるデータを統合
  • データのメタデータ(json)を保持
    • 排他制御とデータのチェックポイント作成が可能
    • sparkで特定バージョンデータのアクセスが可能
  • mlflow 1.0 https://www.youtube.com/watch?v=QJW_kkRWAUs
    databricksが開発した特定のライブラリやインフラに依存しないオープンソース機械学習プラットフォームMLflowの紹介
  • mlflowは3つのコンポーネントからなる
    • MLflow Tracking : 機械学習パイプラインにおけるログ(パラメータ,コードのバージョン、出力ファイルなど)をトラッキングするAPIおよびUI
    • MLflow Project : 機械学習実行コード、データおよび実行環境をパッケージングしたファイルフォーマット,yamlファイル形式
    • MLflow Models : 機械学習モデルの実行環境をパッケージングしたファイルフォーマット,yamlファイル形式
  • 次のintegrationをサポート
  • mlflowの開発コミュニティは現在86contributors(>40companies)
    • spark を上回る速度でコミュニティが拡大している
  • mlflow 1.0(May,2019)から新たに2つのコンポーネントが追加
    • MLflow Model Registry : MLflow server上でMLflow Modelのバージョン管理やデプロイを行う
    • MLflow workflow : 多段階の機械学習パイプラインのスケジュール管理機能

Netflix

講演タイトル:How Netflix Data Science Powers Global Entertainment

Netflixのビジネスでどう機械学習が活用されているかの事例紹介
  • レコメンドシステム
  • 使用されているアルゴリズム
  • ユーザの好みをクラスタリング(taste cluster)
    • トピックモデルを使用しているっぽい
    • 各地域ごとのtaste clusterのトレンドに応じてtopページのコンテンツ表示をチューニング
  • コンテンツに対して投資可否決定支援
  • コンテンツに対する人力タグ付け
  • 製作段階におけるコンテンツの人気度予測
    • レコメンドシステムのアルゴリズムを応用
    • 黄色破線が実際の人気度
    • 実線が予測された人気度
    • 学習データとして脚本・出演者・制作スタッフを使用
    • 予測データを参考に投資可否や投資額を決定

Microsoft

Azure新機能の説明
  • AzureでDelta LakeとMLflow(機械学習のライフサイクルを管理するオープンソースプラットフォーム)が対応
  • Sparkを使用したSeeing AIの紙幣認識モデルデプロイのデモ
  • Seeing AIの紹介

RISC-V

講演タイトル:New Golden Age for Computer Architectures

オープンソースのInstruction Set ArchitectureであるRISC-Vが紹介されました。
  • 現在の汎用マイクロプロセッサは微細化プロセスの物理的限界等の問題で性能向上に限界がきている
  • 汎用マイクロプロセッサの代わりに近年Domain specific accelerator (google TPU, FPGA)が注目されてきている。
  • Instruction Set Architecture (ISA)
    • プログラムがハードウェア上で動作させるための各種命令を構築した体系のこと
    • 例えばIntelチップはx86と呼ばれるISAが採用されている
  • RISC
    • x86に比べてよりシンプルなISAであり、5倍実行速度が速い
  • RISC-V
    • オープンソースのISA
    • 開発コミュニティも安定的に成長している
  • RISC-Vを使用して開発されたOpen domain specific accelerator

Uber

講演タイトル:Using Spark Mllib Models in a Production Training and Serving Platform: Experiences and Extensions

Uber内製の機械学習プラットフォーム Michelangeloの紹介とSpark MLlib改良について発表されました。
  • MichelangeloではSpark MllibのPipelineを使用して機械学習モデルのトレーニングとデプロイを行なっている。
    • これによってデータの変換から特徴量エンジニアリング、学習、学習結果の後処理のパッケージングが可能
    • PipelinemModelによって予測モデルのデプロイが学習時のデータ前処理も含めて一貫性が保たれる。
    • MichelangeloはUberアプリのカスタマーサポート機能(COTA)に応用されている
  • モデルのOnline servingのために高速化が必要
    • 既存の機械学習モデルフォーマット(PMML,PFA,MLeap)ではモデルの一貫性・相互運用性・パフォーマンスに問題が存在
    • Spark PipelinemModelのI/OとServing APIsに改良を施す
  • Spark PipelinemModel I/Oの改良点
    • モデルメタデータreadにsc.textfileからjava I/Oに変更
    • モデルparquet file readに sparkSession.read から ParquetUtil.readに変更
    • アンサンブル木モデルのparquet fileを直接読み込む。
    • 上記改良によってPipelinemModelのI/Oパフォーマンスが1/3〜1/15に短縮された。
  • Serving APIsの改良
    • PipelineのtransformersクラスにOnlineTransformer traitを追加
    • オンライン予測時のAPIをシンプルにした。
  • TensorFlowモデルをMichelangeloにデプロイ
    • horovodを使用して分散学習したモデルをTFTransformerを使用してPipelinemModelに変換

Tencent

講演タイトル:Apache Spark on K8S Best Practice and Performance in the Cloud

TencentのエンジニアがKubernetes上にsparkクラスタ(spark on k8s)を構築し、通常のsparkクラスタ(spark on yarn)とのパフォーマンスを比較していました。
  • spark 2.x でkubernetesをnativeサポート
    • 今回は Spark 2.4.1 を使用
  • spark on kubernetesのモチベーション
    • serverless
      • システム間の関係がより疎結合になる
    • On-premises
      • 将来クラウド環境移行
  • sparkling(cloud data warehousing solution) on kubernetes
    • sparkling のサーバーをkubernetesへ移行
      • Cloud API server -> Kubernetes API server
      • Cloud VM resource -> container resource
      • Cloud load balancer -> Kubernetes load balancer
      • Cloud DNS -> Kubernetes ingress/coredns
      • Cloud VM image -> docker image
  • spark on Kubernetesのアークテクチャと開発状況
  • spark on Kubernetes と spark on yarnのベンチマーク環境
  • ベンチマーク:Terasort
    • spark on Kubernetes with tmpfsではyarnの場合よりパフォーマンスがよかった。
    • spark on Kubernetes with tmpfsの改善
      • spark.kubernetes.local.dirs.tmpfs=trueに変更しspark.local.dirをメモリ上にマウント
      • kubelet workspaceの容量を増やす
      • 上記修正によってspark.local.dirのディスク容量逼迫によるパフォーマンス低下を軽減できる
  • ベンチマーク:Spark-sql-perf
    • 左図:spark on kubernetesにおける最適化前後のパフォーマンス比較
      • パフォーマンスが遅い原因
        • kubelet work direcoryは一つしかディスク領域をマウントできないので、単一のspark.local.dirディスクioがボトルネックになる
      • 改善点
      • spark.local.dirとして複数のディレクトリを使用できるようにsparkのコードを変更 SPARK-27499
    • 右図:最適化後spark on kubernetesとspark on yarnのパフォーマンス比較
      • 最適化しても大抵の場合はkubernetesの方が遅い

Dataxu

講演タイトル:SparkML: Easy ML Productization for Real-Time Biddin

オーバー・ザ・トップ(over-the-top=OTT)上でDSPを開発しているDataxuのRTBにおけるMLシステムの事例が紹介されました。
  • dataxuでのデータスケール
    • 1日あたりのデータ処理時間:2PB
    • 1秒あたりの入札回数:300万
    • 5大陸で7日✖︎24時間稼働
    • 1日あたりに学習する機械学習モデル数:数千(1キャンペーン1学習モデル)
  • dataxuの機械学習システムの要件
上記要件を満たすためにSparkを採用
  • sparkを採用したシステムでの課題1:学習データのパーティショニング
    • キャンペーンごとにモデルを用意するため、学習データをキャンペーンごとに区切る
    • その際各パーティションのデータサイズがまちまちなため、サイズに応じたリソース配分が必要
    • 最初に入ってきたデータをサンプルとして大まかなキャンペーンごとのデータ量の分布を見積もる
  • sparkを採用したシステムでの課題2:Sparkのモデルがlow latency(< 1ms)の予測に対応していない(Uberの講演と関連)
    • 既存のSparkのモデルでは、bidding の入力データ(RowModel)に最適化されていない
    • RowModelに対応するためにsparkの各クラス(Estimator, Transformer, Pipeline)をwrapするクラス(RowTRansformer, RowEstimator)を作成
  • sparkを採用したシステムでの課題3:sparkのone-hot encodingライブラリが遅い
    • カテゴリ変数とそれに対応するインデックス辞書を作成することに時間がかかる
    • 最初に入ってきたデータをサンプルとして、高頻度K個のカテゴリのみを採用して変換を行う
  • sparkを採用したシステムでの課題4:モデル学習コストが高い
    • 1モデルの学習に数時間から数秒かかる
    • 各学習ジョブの特性をみて効率よくバッチジョブを設計する。
    • MaxResourceAllocationは使わない。
    • 60%の費用削減
  • sparkを採用したシステムでの課題5 :プロダクション環境へのデプロイ
    • step1: ステージング環境でモデルのA/Bテスト(Attribution through rateがKPI)を行い,KPIが改善したら次のステップに進む
    • step2: プロダクション環境の1つのBidding machineのシステムを新しいものにリプレイスを行い、その後latecyの改善等チューニングを行う
    • step3: チューニング後全てのBidding machine のシステムをリプレイスする
      • システムリプレイスロジックにblackboad patternを採用
      • これによりシステムのリプレイスやロールバックが容易となった
  • モデルのtransparency
    • モデルの透明性確保のためA/Bテストの結果の図を作成
  • 新しいロジックの追加
    • 上記のblackboad patternを導入したことによって、2日程度でプロダクション環境に適用可能

Lyft

講演タイトル:Scaling Apache Spark on Kubernetes at Lyft

LyftはUberと同じライドシェアサービスを提供している米企業で、後発だがUberよりもピーク時の乗車料金が安くドライバーにとっては料金の取り分が多くチップも多くもらえるので急速に普及しているとのことです。
トークではKubernetes上にSparkクラスタを構築することで、複数のsparkジョブのスケジューリング・スケーリング・外部ライブラリ依存関係をマネージするユースケースが紹介されました。
  • Lyftにおけるbatch computingに関する課題
    • Lyftはbatch computingのプロセスにおいて複数或いは異なるバージョンの言語、外部ライブラリが混在
    • 上記課題によるリソース管理
  • 課題をspark + kubernetes で解決
    • spark: 複数の計算環境、言語やAPI、データソース、外部アプリケーションに対応
      • 異なるジョブで必要なライブラリやそのバージョンの管理が必要(spark自身のバージョン含む)
      • 共有クラスタで実行しなければならない
    • kubernetes: 各ジョブで必要な依存ライブラリやそのバージョンをコンテナイメージで簡単に管理実行できる。
  • Lyftにおけるbatch jobsのスケール
    • データサイズ: 数10PB
    • 日次実行ジョブ数:100k以上
    • 複数クラスタで起動されるEC2ノードの数:数1000
  • クラスタアークテクチャ(k8s導入前)
  • クラスタアークテクチャ(k8s導入後)
  • 工夫
    • 計算用k8sクラスタを複数構築し、ラベルを付与して管理する。
    • 単一のジョブ内で複数のNamespaceを導入する。
      • AWS IAM Roleと関連づけることができリソースのアクセス制御が可能
    • 依存関係にあるジョブを同一Pod内で実行する。

Kount

講演タイトル:A “Real-Time” Architecture for Machine Learning Execution with MLeap

Kount社はインターネット上での詐欺の検出や防止のためのソフトウェアやサービスを提供しているアメリカの企業で、約6500の顧客を抱えているそうです。
講演では、社内で運用しているMLeapとSparkを利用したリアルタイム機械学習基盤の紹介が行われました。MLeapは機械学習パイプラインのための共通の実行APIやフォーマットを提供するオープンソースのソフトウェアで、spark, scikit-learn, TensorFlowをサポートしているそうです。Kountではオンラインの決済トランザクションをリアルタイム(<10ms)で処理するためにsparkとMleapを採用しています。
  • Kountにおける機械学習基盤の課題
    • 2017年11月、単一仮想マシン上のscikit-learn
      • 移植性
      • スケーリング
      • 複数の機械学習プラットフォームへの対応
      • モデル管理
    • 2018年1月、オンプレのsparkクラスタ
      • sparkContextに依存したモデルで、リアルタイム処理に向かない
  • 上記課題を解決するためにmleapを活用
    • モデル管理が一元化(mleap pipline)
    • 特徴量抽出と予測が分離(QA:両方同時のバージョンアップデートするような運用は行わない)
      • 本番版環境とは別にテスト環境を同じデータで動かすリアルタイム性要求しない
      • 運用コストは小さくする
    • アーキテクチャ図
  • モデルのデプロイ
  • MLeapを使用した処理速度の改善

iguazio

講演タイトル:Real-Time Analytics and Actions Across Large Data Sets with Apache Spark

iguazio社は機械学習プラットフォームを提供するイスラエル企業で、講演では当社が開発しているサーバーレスのオープンソースプラットフォームNuclioとsparkを利用したリアルタイムのデータアナリティクスアプリのデモが行われました。
  • Nuclio
    • Kubernetes サポート
    • GPU サポート
    • イベントトリガー:kafka, kinesis,http等
    • 1秒間に400Kイベントを処理可能
  • デモ:フェニックス地区のタクシーのリアルタイム分布やビジュアライズ
    • スーパーマンみたいな絵がNuclioのロゴ
    • タクシーの位置データや売り上げの集計にsparkを使用
    • Dialogflowを使用して音声認識
  • ユースケース紹介:リアルタイム株価分析
  • ユースケース紹介:リアルタイムネットワーク障害予測
  • ユースケース紹介:スケジュール変更時のリアルタイム空港オペレーション最適化
  • QA
    • オンライン学習はしていない

Eventbrite

講演タイトル:Near Real-Time Analytics with Apache Spark: Ingestion, ETL, and Interactive Queries

  • Near real-time analyticsには様々な要求処理時間スケールが存在
  • EventbriteにおけるNear real-time analyticsの要件
  • 比較するデータIngestionの方法
    • Full overwrite
      • データソースからHiveテーブルにすべて上書き
      • [Good] 実装がシンプル
      • [Good] ETLクエリの実装がシンプルさらに高速に動作
      • [Bad] high latency
      • [Bad] read/writeデータIOが重い
    • Batch incremental merge
      • データソースから追加/更新されたデータのみ取得しHiveテーブルにマージ上書き
      • [Good] ETLクエリの実装がシンプルさらに高速に動作
      • [Good] readデータIOが軽い
      • [Bad] relatively high latency
      • [Bad] writeデータIOが重い
      • [Bad] 追加/更新されたデータの信頼性担保
    • Append only
      • データソースから追加/更新されたデータのみ取得し新たなpart fileとしてHiveテーブルに追加
      • ファイル圧縮は1時間ごとあるいは日時で実行
      • [Good] minutes latency
      • [Good] 実装が簡単
      • [Good] データレイクの構造がシンプル
      • [Bad] データ統合処理が必要
      • [Bad] データ取得クエリに追加処理が必要
    • Key/value store
      • データソースから追加/更新されたデータのみ取得し、Key/value storeにupsertする。
      • [Good] 実装が簡単
      • [Good] 同じ操作を何度繰り返しても、同じ結果が得られる(冪等性)
      • [Good] データレイクとweb serviceとの接続がしやすい
      • [Bad] Key/value storeへのデータ書き込み速度がHDFSより遅い
      • [Bad] 大規模なデータスキャンに最適化されていない
    • Hybrid batch/stream view
      • apache kafkaでのDBトランザクションログよりバッチ処理でデータを取得し、hiveテーブルにマージ。同時にkafkaのトランザクションID保持する
      • ETLクエリによるデータ取得時には、最新のトランザクションデータとhiveテーブルのデータをマージする
      • [Good] latencyが秒スケールで抑えられる
      • [Good] バッチ処理の実装がシンプル
      • [Good] Sparkがbatchとstreaming両方の処理に対応
      • [Bad] streamingデータのマージ処理が複雑
      • [Bad] データ読み込みのみ
      • オープンソース化されたDelta Lakeによってstreamingデータのマージ処理の実装がよりシンプルに実現可能
  • 上記5つのデータIngestion手法のwrite/read latencyの比較
  • どのデータIngestion手法を使用するか次の項目に依存
    • ユースケース
    • 許容されるLatency
    • データサイズ
    • 重複除去
    • ストレージ

Comcast

講演タイトル:How to Utilize MLflow and Kubernetes to Build an Enterprise ML Platform

Comcast社はケーブルテレビサービス等を提供するアメリカ企業で、講演ではMLFlowやkubernetesを利用した自社の機械学習プラットフォームが紹介されました。
  • MLFlowやkubernetes導入前のMLシステム
    • 機械学習モデルの管理する仕組みやモデルデプロイの標準化されたプロセスが無かった
    • モデルデプロイのためにコードの書き換えを行わなければならず、数日から数週間の期間を要した
    • モデル複雑度と予測処理速度のトレードオフ
  • MLシステムの要件
    • モデルデプロイのためにコードの書き換えを廃止
    • モデルの実験と結果追跡が簡単に実行可能
    • データサイエンティストが自分でプロダクションモデルをデプロイできるようにする
    • プロダクション環境でモデルのA/Bテストが迅速に行える
    • ワークフローの各ステップでカスタマイズできるようにする
  • MLシステムで使用した既存のフレームワーク
    • Modeling
      • databricks
      • Apache Spark
      • MLFlow
    • container
      • docker
    • Model Serving
      • Kubernetes
      • Argo : Kubernetes 上で動作するコンテナネイティブなワークフローエンジン
      • Kubeflow : Kubernetes上で簡単に機械学習環境を構築するためのOSS
      • Seldon Core : Kubernetes上に機械学習モデルをデプロイするためのOSS, kubeflowで使用されている。
        • inference時にinference graphと呼ばれる計算グラフを定義することで以下のことが可能
          • A/B テスト
          • アンサンブル
          • 多腕バンディット
          • その他
      • Ambassador:Kubernetes上で動作するAPI Gateway
        • プロダクション環境でPod間のリクエストをスケールしやすくするために使用
  • Comcast の機械学習パイプライン
  • ワークフロー各ステップで使用されるkubernetes pods
  • モデルのパッケージングとトラッキング
    • MLflowを使用
  • モデル構築
    • モデルのバージョンおよびプロダクション環境か開発環境かはgithubのタグで管理される。
    • databricksとgithubのリポジトリ間で機械学習コードの同期が行われる

GridGain

講演タイトル:Distributed ML/DL with Ignite ML Module Using Apache Spark as Database

GridGain社はインメモリコンピューティングライブラリを開発しているアメリカ企業で、講演ではApache igniteの機械学習ライブラリであるignite MLが紹介されました。
  • Apache ignite(cf:https://techblog.yahoo.co.jp/oss/ignite_spark/)
    • Sparkと同様にインメモリ技術を活用した高耐障害性分散データ処理プラットフォーム
    • Sparkは非トランザクション的な分析によく使われるプラットフォーム
    • Igniteはリアルタイム処理に優れ、大量データに対して非トランザクションとACIDトランザクション的な処理を両方サポート
  • igniteとsparkのインテグレーション(cf:https://techblog.yahoo.co.jp/oss/ignite_spark/)
    • shared RDD
      • spark cluster上のデータをデータソースとして使用可能
      • RDDにより並列処理を可能とするデータの分割や分散を隠蔽
      • Sparkのバックエンドとして使うことが可能(igniteクラスタでsparkが動くらしい)
      • IgniteRDDは複数のSparkタスクに共有され、ファイルシステムにRDD内容を書き出すことなくステートシェアリングが可能
    • DataFrameサポート
      • DataFrameを拡張し、RDDと同じくSparkワーカーに跨ったステートシェアリングが可能
  • Spark MLの問題点
    • モデルのアンサンブル、スタッキング、ブースティング、バギングをサポートしていない
    • 全てのアルゴリズムでオンライン学習をサポートしていない
    • データソースからアルゴリズムに対応するデータに変換する際、多くの変換ステップやオーバーヘッドが存在する。
    • TensorFlowなどと統合することが難しい
    • 一部のアルゴリズムが疎行列を使用している。
      • 疎行列は分散処理に向いていない
    • モデルのservingのために様々アプローチ(プラットフォーム、Mleapやmlflowなど)が存在し、デファクトスタンダードが決まっていない
    • Auto ML がサポートされていない
    • 内部的にRDDを使用したmllibが使われている
  • ignite MLがサポートしているアルゴリズム
    • 分類
      • logostic regression
      • SVM
      • kNN
      • ANN
      • Decision trees
      • random forest
    • 回帰
      • kNN regression
      • linear regression
      • decision tree regression
      • random forest regression
      • GDBT
    • multi-layer perceptron
    • 前処理
      • standardization
      • one-hot encoding
      • NLPに関するものは実装中
    • Evaluation
      • K-fold CV
  • pipline
    • spark piplineと同様に定義可能
  • モデルアンサンブルのサポート
    • 単純平均
    • 重み付き平均
    • 多数決
  • スタッキング可能
  • オンライン学習
    • kafkaデータソースをサポート
  • tensorflow をサポート
    • IGFS(IGnite File System <- In-Memory File System) plugin
    • Distributed training
  • Model inference
    • サポートしているモデルフォーマット
      • PMML
      • XGBoost Model
      • Spark Model
      • Mleap
  • Roadmap for ignite 3.0
    • NLP support
    • Spark pipline inference support
    • DL4j integration
    • Approximate ML algorithm to speed up training

所感

  • koalasが発表されたことで環境さえ整えられれば、pandas使える人なら分析作業の効率化とデータの大規模化ができそう。
  • kubernetesクラスタ上でsparkを動かしてパフォーマンスが出るようになるにはまだまだ時間がかかりそう
  • 機械学習プラットフォームのOSSは個人的にはmlflowが使いやすそう
  • リアルタイム予測が各社に力を入れている
  • Apache igniteとsparkの連携に注目したい

その他(空き時間)

IT企業のオフィス巡り

会場近くの徒歩圏内にあるIT企業のオフィスを巡ってみました。

ビアバー巡り

サンフランシスコにはクラフトビールの醸造所が複数あるのですが、醸造所併設のバーに行ってきました。当然ながらビールの鮮度は最高なので日本で飲めるビールであっても全く味や香りが違う場合もあったりします。
上の写真はビールのお試しセットで一般的に Beer flights と呼ばれたりします。


関連タグ