データパイプラインに関する知見をカジュアルに語る！ Data Pipeline Casual Talkに参加してきた #DPCT

ジョブ管理ツール

#ビッグデータ

#イベントレポート

#機械学習

#勉強会

#Luigi

しんや

2019.02.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

昨日(2019年02月13日(水))、下記のイベント(勉強会)に参加してきました。データ分析基盤、また機械学習基盤にとって、要望を満たすデータを整形、準備する『パイプライン』の存在は必要不可欠です。そんな題材をテーマにした勉強会の内容をレポートしたいと思います。

Data Pipeline Casual Talk - connpass

参加レポート

開会の挨拶＆会場説明

Data Pipeline Talkの趣旨説明

開催前の挨拶として、主催者である @tetsuroito さんから資料を下敷きにオープニングトーク。

Data Pipeline Casual Talk for Ready - Speaker Deck

開始時刻近辺になった辺りでビル入館手続き等で会場に到着できていない人が居る状況が発生してしまう事態に。@tetsuroitoさんはこれを『ビルの行列(パイプライン)が待ち状態になっております。"パイプラインの勉強会でパイプラインが詰まる"いう状況になってしまいました』とすかさずネタにして会場の雰囲気を和やかに温めておりました。

こちらのイベント40人規模開催のイベントに150人超の募集があったという事でかなりの競争率。「正直こんな勢いで集まるとは思っていなかった」としつつも「皆さんのカジュアルな発言を期待しています」とコメント。

ちなみに勉強会のタイトルとなっている"カジュアル(Casual)"の意味はこちらをご参照ください。基本的には登壇者が話したい事を話したい様に話すストロングスタイルな感じです。

AWS Casual Talks#1 で説明したカジュアルとはを再掲 http://t.co/CdlqWIlDES #awscasual

— con_mame (@con_mame) 2014年4月18日

AWS Casual Talks #2 に参加してきた #awscasual ｜ DevelopersIO

イベント開催の経緯としては、下記のスライドページが主旨となっていました。データ分析環境は機械学習環境で用いる「データ」の生成及び品質向上には「パイプライン」は欠かせないものですが、このパイプラインを作り上げていく、運用していく上で色々な課題、作業を行う担当者等が直面する様々な問題とストレス等など。また、この部分を円滑に進めていくにはどの様なスキルや経験が必要なのか、そういったテーマについてざっくばらんに、「カジュアル」に語り合いたいという思いがあったようです。

会場の説明＆スポンサートーク

次いで、会場をご提供頂いたエムスリー株式会社様から @m_nishibaさんによる会社紹介及び会場の諸説明。「医療関係のIT屋さん(by @m_nishibaさん)」であるエムスリー様の立ち位置やサービスのシェア状況、また会場でしか聞けないちょっとしたお話も聞くことが出来ました。

Talk1: 機械学習におけるデータ管理

ここから本編となる「カジュアルトーク」です。1人目のセッションは会場説明から引き続きのエムスリー株式会社@m_nishiba さん。

発表資料

発表内容メモ

基本的にはML(機械学習)の文脈で話された内容。
パイプライン構築にはLuigiを使っている。Luigiの名前の由来は「世界で2番目に有名な配管工」から取られている。
Luigiを拡張したGoKartというフレームワークを開発・運用している。
GitHub - m3dev/gokart: A wrapper of the data pipeline library "luigi"
17年7月にAIチームを立ち上げたものの、様々な課題が挙がってきており結構キツい状況になっていた。
データの使い回しが難しい、モデルの再現性が低い、ログ出力が適切ではない...等
これらの諸問題を解決するためにLuigiを活用。LuigiはSpotifyによって開発。

タスク(Task)の組み合わせでパイプラインを作れて、インタフェースも決まっているので設計もシンプルにできた。
拡張したGoKartでは、タスクとIdだけで状況を再現出来る仕組みを用意。
Luigiを活用することでタスクの実装も簡単になり、ログも読みやすくなった。
挙動の切り替えも設定ファイルで簡単に実現可能に。
また、モデルの保存に工夫を凝らした。複数ファイルが吐かれる環境のものはまとめてzipするようにして保存して管理を容易に。
再実行やSlack通知も出来るように改良。
まとめ
Luigiを入れて良かった。Luigi自身、薄いライブラリなので改造もし易かった。
Luigiを入れることで、生産性も向上出来た。
ちなみに可視化部分についてはBigQuery→Re:dashの連携で対応。

Talk2: 丘サーファーへ水を届けよ！〜みんながデータを使えるようにするまでの日々の挑戦(苦悩)〜

2人目のトークはClassi（クラッシー)株式会社より@yuu_kimyさん。

タイトルにある「丘サーファー」は、デブサミ2018夏で公開された以下セッションの内容に倣ったもの。@yuu_kimyさんはことわりを入れつつ、当セッションで言及する"丘サーファー"を『データにアクセスできない人全員』と定義付けた上でトークを進めました。

発表資料

発表内容メモ

皆さん、"容易に"データにアクセス出来ていますか？
弊社では多少は活用出来るようになったが、まだまだこれからの状況。実際の経緯を踏まえつつ、過去現在未来の話をしたい。
データパイプラインとは何か:データの前処理が時系列に整理されて繋がったもの。(※Wikipediaより引用)
何のためにデータパイプラインを？目的は『活用出来るデータのフローを、適切にコントロール出来ること』。使いづらいデータがあるだけでは意味がない。データが使いやすい形で提供出来ることが大事
過去編
データが使えない、データが無いという状況。
サクッとビジネス担当者が見れる環境が無く、レポート担当者の負荷が大きい状況だった
採ったアプローチ方法
使うためのデータに優先順位を付けて整備に着手(BigQuery/Tableau/JIRA Confluence)
ようやくサクッと見れる環境が整ってきた！
Bigeuqryのデータセットを整備、レイヤーを明確に定義
Tableauで扱うカスタムSQLは可能な限り簡素に
コンフルのメモは利用ユーザーには刺さる！Tableauの項目の解説とかに役立った。何の用途のためのデータだったのかを書きておくと良い。
丘サーファーでは無くなってきたが、もっと便利にしたい。
(少し先の)未来編
AWSとGCPのハイブリッド環境を実現すべく今頑張っているところ
目指すところは『データがウェ～イな状態』。

Talk3: データ基盤の3分類と進化的データモデリング

3人目の発表は株式会社リクルートテクノロジーズより@yuzutas0さん。デブサミ2018夏では以下セッションで登壇されています。

発表資料

データ基盤の3分類と進化的データモデリング #DPCT / 20190213 - Speaker Deck

発表内容メモ

6ページ目のAAの元ネタはこちら。

「テスト書いてないとかお前それ @t_wada の前でも同じ事言えんの？」「書いてないお！ (ｷﾘｯ」

— Takuto Wada (@t_wada) 2018年1月27日

「ワイルド・サバンナ」はシンプルな条件で発動する遠隔自動操縦型スタンドなので、スタンドパワーはかなり強いと思われる。

— Takuto Wada (@t_wada) 2015年9月3日

このセッションではデータ基盤の論理設計を切り口にして、物理設計のあるべき姿を考えます。
想定対象：PM・テックリード。
結論はこちらの図を参照。パイプラインの流れは左から右へ、そして保守については左右両面から挟み込む形で進めていくのがポイント。@yuzutas0さん曰く『進化的データモデリング』。

あるべきデータ基盤の定義：この3分類は業務フローに存在するはず。『データが利用者に届いているか』を見る場合、この3分類全てがあるかどうかがポイントとt成る。
データレイク：データを加工せずに蓄積。元ネタがあることが大事、ストレージサービスが該当
データウェアハウス：意味のある形で残しておく、絶妙だけど大事なニーズ：分散データストアが該当
マート：特定用途向けに加工されたもの：ユースケースごとに最適化されていることが大事、redashやtableuなどが該当

@yuzutas0さんの考える『データ基盤の定義』は以下。複数のデータソース(Data)と複数の利用者(Ops)をリボンの様に結びつける形が理想。

その他トピックについては上記2つの資料をご参照ください。(とても15分でカバーし切れるボリューム感では無かった...w)

Talk4: データ基盤を「育てる」という考え方とそれを支える技術

4人目の発表は株式会社エウレカより田中聡太郎さん。

発表資料

発表内容メモ

前提：辛い作業を如何にして我々(田中さんサイド)がやらないように出来る、か。
今回採り上げるのは『Pairs』のデータ基盤のお話。
Pairs(ペアーズ) - 恋愛・婚活マッチングアプリ
データ基盤とは何？
言葉がわかりにくい？
ポジションや職種によってイメージするものが結構違う
利用者からの期待と実際に作っているものの乖離がある？
どの作業を基盤で置き換えてみるか？という観点で考える
Pairsのデータ基盤：作業依頼がデータ加工の人に集中、『SQL書く書くおじさん』が大量発生し、負荷が掛かる状況に(本当はこの先の可視化・考察・提案に集中したいのに...)。この部分を標準化・自動化することが肝。
がしかし、そもそも標準化・自動化出来るのか？：結論から言うと『最初にかっちり決めて作るのはほぼ不可能』。環境や条件は変わることを前提にして、むしろ『進化させていく』ように作っていくべき。イコール『データ基盤を"育てる"』。
参考文献1：『進化的アーキテクチャ』
O'Reilly Japan - 進化的アーキテクチャ
【書評】「進化的アーキテクチャ」を読みました｜ DevelopersIO
参考文献2：『Agile Data Warehouse Design』
Amazon | Agile Data Warehouse Design: Collaborative Dimensional Modeling, from Whiteboard to Star Schema | Lawrence Corr, Jim Stagnitto | Data Warehousing

『腐敗防止層』を設けてパイプラインの拡張や変更に強い環境とするのも有効。

Talk5: リブセンスのデータ分析基盤を支えるAirflow

最後5人目はリブセンスより吉武正史さん。

発表資料

発表内容メモ

リブセンスのデータ分析基盤について
データ分析基盤/Livesense Analytics:AWS上に構築。ログデータ等をRedshiftに収集、社員は誰でもSQLを叩いて分析出来る
機械学習基盤/Livesence Brain:GCP上に構築。Analyticsのデータを元にモデルを生成。レコメンドやABテスト、多額バンディット等メディア共通で利用出来る機械学習システム
メンバー構成：データエンジニア／機械学習エンジニア／データアナリスト
上記2システムを用い、実装／分析／運用に垣根を作らないシームレスな活用を実現
アーキテクチャ
Apache Airflowの解説
Apache Airflow導入の経緯
元々Rubyのrakeを使っていた
スケジュール管理はcron
処理量やスケジュール等が増加・煩雑になったため導入を決意
リブセンスでのAirflow活用方法
構成
どのように活用しているか：定期的なクエリ実行、EMR起動トリガ、Glue起動トリガ
テスト：ロジックとDAGの管理を分割／DAGの方はあまりきっちり(テスト)出来ていない
モニタリング：エラー発生時に実施。アラート通知先はSlackに集約。slackでredashのグラフ表示も行っている
Airflow導入で良かったこと：
タスクのスケジュールや依存関係が整理出来た
実行結果のログの管理が楽になった
Workerがスケール出来るようになった
Airflow導入で苦労したこと：
バージョンアップが結構面倒
ExecutionDateと実際の実行時刻がずれる
ジョブのスケジュール管理が全て解決した訳ではない

まとめ

と言う訳で、(イベント名)の参加レポートでした。悩みと言うか、課題として捕らえている部分は皆さん共通して直面している要素もあり、また参考になるポイントも得られた実りあるイベントでした。会場ご提供頂いたエムスリー様、また当日発表された皆様、ありがとうございました！(下記はイベント関連ツイートのまとめです。合わせてご参照頂けますと幸いです)