見出し画像

人と組織の状態可視化サービスのデータサイエンティストを支える技術を初公開

こんにちは。株式会社アトラエの小倉です。人と組織の状態可視化サービスである wevox というサービスのインフラエンジニアとして日々活動しています。

wevox には、データの観点から事業の課題解決を遂行するDS(データサイエンス)チームがあります。どのようなツールやサービスを使っているか質問を頂くことが多かったのでブログにまとめました。

また ML/DL 畑で働く学生さんに見て頂ければ、弊社含め事業会社で働くことの解像度が上がると思うので是非ご覧ください!

▼ 対象読者
• wevox のデータサイエンティストの作業環境が知りたい人
• 事業会社のデータサイエンティストの働く環境が知りたい人

全体像 

画像13

データサイエンスの技術スタックと、それを支えるインフラの技術スタックはざっくりと上記のとおりです(※ 2020/07時点)。

wevox DS チームは Google Cloud Platform(GCP) をメインで使うので紹介するツールは GCP のものが多めです。

これらのツールについて、私の考えとともに説明していきます。

二種類の基盤

データサイエンティストの業務環境はざっくり分けて「データ分析基盤」「ML/DL 基盤」の2つがあります。それぞれの基盤において、目的と手段のセットが異なるため区別させてもらいました。

データ分析基盤構築の目的は、データサイエンティストが意思決定のためのデータ分析を速く、正確に、納得感をもって行えるようにすることです。そのためにはデータに不自由なくアクセスできることや計算資源があること、その操作性が優れていることが要件として求められるでしょう。またデータ分析といっても作業レベルでいうと色々あるので、それぞれに合わせたツールがあるといいと思います。


もう一方の環境は ML/DL 基盤です。ML/DL 基盤は、データサイエンティストがプロダクトに乗せる ML/DL 機能を作れるようにすること、またそれを継続して改善し続けることが構築の目的になります。モデルを単に作れることだけではなくそれを機能にすることも求められます。またデータの質・量が変化すればアウトプットも変わるため、それに対応し続けることも必要となります。いわゆるMLOpsというやつです。

それぞれ使うツール群もだいぶ異なるので分けて説明していきます。

データ分析基盤

Tableau、Jupyter、BigQuery、Data Portal をメインに使う事が多いです。それぞれ簡単にツールの説明をします。

👉 Tableau

画像1

膨大なデータの中からヒントや仮説をスピーディに得るために Tableau(タブロー)を使うことが多いです。操作性もグラフィックも他ツールより優れている印象です。

画像2

上記は、弊社のデータサイエンティストが趣味で(?)社内CO2濃度を分析したものです。社員増加に伴うCO2濃度の高まりという社内の課題解決のためにデータの観点から立ち上がりました(?)。IoT機器で取得したデータは項目が多いですが、Tableauを使うと可視化が楽にできます。

👉 AI Platform Notebooks

画像3

AI Platform Notebooks は GCP のマネージド Jupyter です。GCP からアクセスして利用しますが、使用感は Jupyter と全く同じです。マネージドであるためサーバーの悩みの多くは GCP が全部持ってくれるので、我々はコードを書くことに専念出来ます。

wevox DS チームは各人がそれぞれ重い処理を行うことが多いため、自己判断でメモリ、CPU/GPU のスペックを調整できるようにしたほうが機動力があがると考えています。そのためクラウドの計算資源を各人の判断で使えるようにしています(もちろん適切に監視や権限管理してます)。

データサイエンティストは GCP の計算資源を使うことで計算資源の縛りなしに Jupyter を使うことができます。クラウド万歳!

👉 BigQuery

画像4

SQL ライクな処理を超高速で行いたい時に使います。BigQuery は RDB とは違いカラム指向なので、(ジョブ次第ですが)テラバイト級のデータ処理もかなり早く終わります。

どんどん掘り下げるような調査をする時、重い計算を処理する時など、何でも使える万能選手です。超安価、非同期処理ということもあり作業の一部を BigQuery にアウトソースすることも多いです。

弊社のバーチャルデータサイエンティストが BigQuery で黒魔術をしていたので、その時のブログのリンクを載せておきます。 Python による計算処理を BigQuery に置き換えて 4,000倍高速にしたというにわかに信じられない内容です。

また BigQuery ML というのもあり、これによってSQL ライクに機械学習が出来ます。(後述します)

👉 Google Data Portal

画像5

定期的に確認したい内容は Data Portal を使います。所謂ダッシュボードですが、対応入力データの種類が豊富なのが魅力です。AWS や Salesforce などとも連携できます。

画像6

例えば上記は wevox の累計データ数を時系列で可視化したものです(意図的にぼかしてます)。クエリを叩けば手に入りますが、毎度叩くのも面倒なので Data Portal で常に可視化しています。このようにしておけば、いつでも誰でも、現在の状況をダッシュボードとして見ることが出来ます

データサイエンティストがData Portalで可視化しておいて、ビジネスサイドや他事業部のメンバーが眺めに来ることが多いです。


ML/DL基盤

ここからは ML/DL 機能を wevox のアプリケーションに乗せるための環境、ML/DL 基盤について説明します。事業会社であるため、ML/DL モデルもお客様のためになってナンボだと思ってます。そのためモデルの精度を上げることと同じくらいスピード感を持ってリリースすることも重要だと考えます。

画像7

現在 wevox DS チームでは、Kubeflow (キューブフロー)をメインに使っています。正確には、 Kubeflow Pipelines というパイプラインツールをメインで使っています。


Kubeflow は機械学習の一連の作業を、Kubernetes 上にデプロイするためのOSS のツールキットです。Kubeflow が包含するツール郡を組み合わると以下のようなことが達成可能です。

• データ取得 →モデルの構築 → web API化 が既存作業の延長で可能に
• メモリ、CPU / GPU に応じたインスタンススケーリング(in/out, up/down)の自動化
• パイプラインの構築、管理、定期実行
• メタデータ管理
• ポータビリティ
• GCP 各サービス(BigQuery, Dataflow など)とのシームレスな連携
• ポータビリティ
• etc

そして上記を、基本的にはデータサイエンティストの作業の範囲内で完結させることを目的にします。データサイエンティストのメインツールは Jupyter だと思いますが、データサイエンティストは Jupyter 内で Python を書くことで EDA からプロダクトリリース・MLOpsを行うことが出来ます

それによりデータサイエンティストがエンジニアに依存することなく機能提供に踏み込めたり、プロダクトレベルで仮説検証(モデルの A/B テスト等)が行えるようにできるようになり、ビジネスのスピードが超加速します

データサイエンティストとエンジニアとでは業務の責任範囲が異なります。スペックの高い計算資源を使いたい時は担当のエンジニアに依頼する必要がありますし、モデルの継続的な学習の仕組みの構築や推論器のデプロイはデータサイエンティストの作業では完結しません。

wevox DSチームではこの垣根を技術で乗り越えようと考え、結果としてKubeflow を含めた技術の採用をしました。

データサイエンティストが実際に利用するツールや機能をご紹介します。

👉 Kubeflow Pipelines

画像8

データ取得 → 前処理 → 学習 などの汎用化・共通化できるパイプラインを構築・管理するツールです。wevox では Kubeflow Pipelines を GKE(Google Kubernetes Engine)にデプロイして管理しています。

Kubeflow Pipelines はバックエンドで Kubernetes と Argo Workflow が動いています。実は Kubernetes と ML/DLの相性はかなりいいのですが、愚直に Kubernetes で管理しようとすると YAML を大量に書く必要があります。上の画像でも千行規模の YAML になります😨

Kubeflow Pipelines のいいところは退屈な YAML を書かずに、Python SDK である kfp を習得すれば Kubernetes 上にパイプラインを構築できる点です。以前 kfp の記事を書いたので使い方はこちらを参照ください。また上の画像はDSの土屋が作ったものです。ワークフローのルール自体は kpf に従っているだけなので Python の延長上で作れています。

画像9

Kubeflow Pipelines は実験管理も兼ねています。データの基礎統計量、TFDV、テーブルデータのスキーマはプリセットツールで見ることが出来ます。

データリネージ(データがどこから来てどこに向かうか)などのメタデータ管理も容易にやってくれます。

そしてここまでの処理を、基本的には慣れ親しんだ Jupyter(ここではAI Platform Notebooks)で行うことになります。

画像10

上記の図のように各処理を GCP の各リソースにアウトソースできることも魅力の1つです。

例えばゴリッとコードを書くことが必要なデータの処理を BigQuery や Dataflow に投げたり、中間結果の出力先として GCS を使ったりすることも出来ます。学習は AI Platform Training を、推論 API の作成はAI Platform Prediction というそれぞれの GCP マネージドサービスを利用できます。

そのためデータサイエンティストは GCP の Jupyter でコードを書くだけですが、GCP リソースと Kubernetes の仕組みでインフラ部分を極力意識せずにデプロイと MLOps に専念できます。

👉 Cluster Auto Scaler と Node Auto Provisioning

GKE(Google Kubernetes Engine)では計算資源の要求や使用量に応じて、自動的にインスタンスが増減する仕組みがあります。

機械学習における処理は一般的なwebアプリの処理と比較して計算資源(メモリ、CPU/GCPU)をより消費すると思います。あるあるな経験としてはこんなものがあるでしょう。

• タスクによって稼働するインスタンスの種類を切り替えるのが面倒
• インフラ担当者にインスタンスの稼働や権限付与の依頼をするのが面倒
• インスタンスを切り忘れて悲惨な金額請求が… 😱

Cluster Auto Scaler と Node Auto Provisioning はそれらを解消してくれるGKE の機能です。端的にいうと、タスクが実行されると必要最低限なスペックのインスタンスが立ち上がりスケールアウトもしてくれて、タスクが終了するとスケールインしつつ自動的にインスタンスが0台になる、という機能です。

そしてのこの機能はデータサイエンティスト側で設定・操作することはほぼなく、インフラ側の設定で完了します。そのためデータサイエンティストが パイプラインの各ステップで実行されるジョブについて宣言的にリソースの量を記述しておけば、それを GKE が読み取って適切なインスタンスの立ち上げ・スケジューリング・削除をしてくれる、というわけです。素晴らしい世界!!

オートスケーリング機能は非常に便利でいつもお世話になっております(?)。

他にも色々とありますが、ピックアップするとこんなものでしょうか。もちろんGitHub、GCR、Cloud Build を組み合わせて開発環境と本番環境を運用しますが、基本的にメインになる活動場所は AI Platform Notebooks と  Kubeflow Pipelinesです。

実際に運用していますが、Kubeflow Pipelines すげー!便利ー!となってます。

今は Python SDK を書くことで YAML 記述を回避してますが、SDK すらもハードルだと感じ始めたら Kale を使うことも検討します。Kale を使うことで Jupyter のコードセルにメタデータを付与することで、そのままパイプラインにコンパイルしてくれます。

👉 Auto ML と BigQuery ML

これらはガンガン利活用しているわけではないですが、かつてテスト的に利用したことがあり今後本番環境での利用も可能性があると考えているため紹介することにしました。

最近ノーコードのサービスが流行っていますが、それと似た潮流が DS にもあると感じています。まさに Googleも「AIの民主化」を目指しており、この2つのサービスはそれを体現するようなものです。

画像11

まず Auto ML からですが、これはデータを投入してポチポチとボタンを押し進めるとデータ可視化・前処理・モデル構築・評価・API化 までを全自動でかつ、高精度にやってくれるサービスです。本当に全自動です。はじめて触った時は衝撃を受けました。

これだけ聞くと精度が高くなさそうな感じもしますが、2019年の Kaggle のコンペでは Auto ML で生成したモデルが2位になっています

書きすぎると何のブログか分からなくなるので控えますがw、少なくともものによっては人間の手を加えずにプロダクトレディなモデルの生成が期待できます。


次に BigQuery ML ですが、これは SQL ライクな操作で ML/DL のあれこれができてしまうというサービスです。例えば、以下のような クエリを書くだけでロジスティック回帰のモデルの完成です。簡単ですね。

CREATE MODEL `bqml_tutorial.sample_model`
OPTIONS(model_type='logistic_reg') AS
SELECT
 IF(totals.transactions IS NULL, 0, 1) AS label,
 IFNULL(device.operatingSystem, "") AS os,
 device.isMobile AS is_mobile,
 IFNULL(geoNetwork.country, "") AS country,
 IFNULL(totals.pageviews, 0) AS pageviews
FROM
 `bigquery-public-data.google_analytics_sample.ga_sessions_*`
WHERE
 _TABLE_SUFFIX BETWEEN '20160801' AND '20170630'

Auto ML は内部で最適なモデルの探索を大規模に起こっているため、学習の時間に数時間掛かることがほとんどです。一方の BigQuery ML は既にあるモデルの中から選択して学習させるので学習時間は高速です。上記のクエリで言うと  model_type='logistic_reg' ですね。

参考までに2つのサービスと、Python でゴリっと書いたものを比較してみます。

画像12

(藤原 秀平 他『GoogleCloudPlatform 実践 機械学習基礎開発MachineLearning/データ分析』p24の図を一部改変)

同じノーコード系ではありますが、Auto ML と BigQuery ML では前提と強みや弱みが異なります。そのためそれぞれのビジネス環境に応じて適切な手段をとるのがいいかと思います。

余談にはなりますが、学生さんとお話をするとこの2つ含め類似したサービス(DataRobot等)をご存知無い方が多くいらっしゃるようです。むしろ知らない方の方が多い印象を受けます。私個人とDSチームの感覚としてはこれらのツールと自分たちのスキルをどのように共存させるかが企業と個人の生存戦略につながってくると思っています。時間を札束で買うことが、選択肢の1つに大いになりうると思っています。

もっと書きたいことはありますが、質問などあれば Twitter 等 SNS で聞いてください。

よくある質問

環境の説明とは別によく頂く質問をまとめました。

🍣 wevox DSチームでどんな成果がありますか?

wevox DS チームが関わった機能としては以下のリリースがあります。

• バランス分析機能
• 影響度分析機能
• 変動検知機能
• etc

分析結果の記事もいくつか出しています。各企業様と弊社のDSチームとで分析を行ったものとして以下があります。

• 【wevox】生産性を高める一手を学術的に証明(1)
• 【wevox】生産性を高める一手を学術的に証明(2)
• 【wevox】テレワークによるエンゲージメントの低下とその対処法
• 【wevox】新入社員のエンゲージメント低下パターンを分析

🍣 技術選定ってどうしてますか?

基本的には問題を解決したいと思うメンバーが提案・導入します。観点としては課題解決をどの程度達成するか、コストはどうか、中長期で考えた時にどうか、などです。

ちなみにメインの ML フレームワークは Tensorflow です。これは利用するクラウドが GCP であり、Tensorflow との相性が極めていいためです。ただメインなだけで PyTorch、scikit-learn、XGBoostも使います。

🍣 どんなデータサイエンティストが在籍してますか?

こんな人達です。彼らが書いたブログをここに貼っておきます(何かの因果なのか、両方のサムネイルに右アングルの私の頭が写り込んでいます)。


🍣 求人はありますか?

あります!気になったらこちら是非ご覧ください!

✌️ 新卒の応募はこちら

画像14

✌️ 中途の応募はこちら

最後に

wevox DSチームは現在4名体制です。データサイエンティスト3名と、インフラエンジニアの私1名です。

正直な話をすると人数規模に対して ML/DL 環境はかなりオーバースペックなインフラだと感じています。Kubeflow Pipelines は便利ではありますが、Kubernetes (GCP GKE) 上で動いており、クラスタの運用が必須になります。しかもアプリケーションは AWS EKS で動いているため、実質 GKE を利用するのは我々4名です。

傍から見ても「オーバースペックでは?」と思われるかもしれませんが、wevox の今後の命運を左右するデータサイエンティストの生産性を考えた時妥当であると私は考えてこの環境を選びました。

また今後優秀なデータサイエンティストにもジョインして欲しい、ジョインするだろうとも考えたのも理由の1つです。

この記事を書き始めた時は社内のメンバー向けに共有することを考えていましたが、どうせならオープンにして学生さんや転職を検討されている方に見てもらおうと考え今に至ります。

この記事を見てアトラエ、wevox やそもそも事業会社のデータサイエンティストとして働くことを想像してもらえたなら嬉しいです!

この記事が気に入ったらサポートをしてみませんか?