2019-06-27 Data Pipeline Casual Talk Vol.3 #DPCT
2019/06/27 に開催された Data Pipeline Casual Talk Vol.3 のイベントレポートです。
●イベント概要
2018年は AIや人工知能がハイプサイクルの下降局面に入るなど、テーマとして成熟してきた年となりました。 データドリブンな取り組みを紹介する企業が増えてきたことは非常に好ましいことだと思います。
しかし、一方で、企業で取得されたデータをデータサイエンティストやアナリストに届けるためのデータパイプラインに関する議論がまだまだ十分提供されている状況ではないのではないでしょうか。 いくら民主化が進んでも、きちんと統制されたデータパイプラインが整備されていなければ、また悲しみを繰り返すだけです。
本イベントはそんな中で、日々IT土方作業に勤しまれている方々をお呼びして、カジュアルにデータパイプラインについて語っていただく会です。
■オープニング
@tetsuroito さん
●カジュアルトークとは
・その手の人が好き勝手に話すのでガチな話しか出ません
●参加者の傾向
・パイプライン、データ基盤に関わる人が多い
・アプリのエンジニアもいるが、データよりになってきている
●DPCTのねらい
・パイプラインの技術情報の共有
・ツールの情報
・運用の課題
-> 事前アンケートでの期待とシンクロしてきた
■Cloud Composerを半年運用してきて困ったことをちょっと振り返ってみる
@__sotaron__さん / エウレカ
●Cloud Composerのeurekaでの使い方
・DataLake -> DWHのETL
・DWH -> DataMartのETL
・BigQueryでSQLアクセス
●DataLake -> DWH
・stream のlogデータの集計、指標化
・bulkで入ってきたdump系データの集計、指標化
●DWH -> DataMart
・DWHから必要な指標を抽出
・見たい人に合わせて見せ方を調整する
●DaltaLake -> DWHのタスク
・タスクのグループは処理内容ごとにまとめていた
・新しいワークフローを追加するときは
空テーブル作成 -> ロード -> 作成
・やりたいことは同じでも、タスクごとに作成が必要だった
●なんでこうなってるの？
・BigQueryの仕様
テーブル作成時にしかschema指定ができない
空テーブル作成し直し、appendタスクにしたり
・リトライやりにくい、冪等にしたい
何も考えずにリトライできない
-> 新しいワークフロー追加したいだけなんだけど、、、
●困りごと
・コピペで量産される
・ピタゴラになる
●対策
・データでまとめる
関心の対象毎にDAGを作成
delete -> create -> load -> finish
以前は処理ごとだった
・共通処理をテンプレート化 & code gen
template化してcode gen
yaml -> jinja2 -> builder.py -> 個々のworkflow
・ワークフローの追加 = DAGの追加
●効果
・レビューはtemplateとyamlだけでOK
・作業がconflictしにくくなった
・共通処理を強制
・リトライしやすい！
●タスク失敗やSLA超過
・DataPipelineは運用に乗ると怒られが発生しやすい
失敗した
意図した時間にレポートが届かない
ピタゴラしているからMTTRが長い
・対策
怒られないようなしくみ
怒られる前に気づいて直す
●気づくために
・Airflowのエラー検知、SLA超過アラート
sla_miss_callback
on_failure_callback
・callbackのインタフェースがバラバラ
ソースを読まないと分からない
●Q: custom operatorと比べて、templateはどう？
・Airflowに精通していなくても、コンセプトが理解できる
■Argoによる機械学習ワークフロー管理
田中さん / リブセンス
●リブセンス
・サービス
マッハバイト、転職DRAFTなど
・MLシステムの開発運用は、事業部から独立
●リブセンスのMLシステム
・求人レコメンドエンジン
サービスに合わせて個別につくっている
・応募・採用の効果推定・予測モデル
webアプリも提供
・A/Bテスト・バンディットツール
パターン配信率をバンディットアルゴリズムで自動調整
管理画面からパターンを登録
ランダムに配信
CVログから日に一回重みを切り替え
●課題
・学習・予測大部分がバッチ
・ステップが多い
複数のアルゴリズム
-> filter
-> merge
・共通部分が多い
A/Bテストの部分だけ切り替えなど
・目的に応じて言語・ライブラリが違う
一般的なMLライブラリが適さないことがおおい
モデル・アルゴリズムはJuliaで自前実装
・単一リポジトリでモノリシック
運用が回らなくなってきた
MLのコアとDBIOが密結合
アルゴリズムのコピペ
処理ステップごとに言語が変わる
●対応
・コンポーネントの分割
CLIで単独実行
・コンポーネントのコンテナ化
システムごとの差分は設定ファイルやSQL
・ワークフローをどう実現する？
-> 2017ごろArgo Workflowを見つけた
●Argo Workflow
・k8sからワークフローを実行
高機能なJobなイメージ
・CRD controllerとして実装
各ステップはPodとして動作
・ワークフローの実行に専念、トリガーなどはない
Luigeに近い
●できること
・ワークフローやステップにパラメータも渡せる
・templateのstep
二重のリストで並走を表現
DAGも表現できる
・ステップ間でファイルの受け渡しもできる
・分岐、繰り返し
・成功失敗のハンドリング
・リトライ・タイムアウト
機械学習は不安定なので考慮が必要
・ドキュメントは少ないのでgithubのexampleで把握
●リブセンスでのMLシステムの実行基盤
・GKE中心
・リポジトリ
ワークフロー定義は1つ
コンテナは複数
・docker runで実行できるように実装
・単一ステップのワークフローでスタート
ここから育てていく
●運用Tips
・web UI
kubectl port-forwardでアクセスが必要
ingressで外とつなぐ
Identity-Aware Proxyで認証
・クリーンアップ
Podは成功で残り続ける
削除するCronJob
argo delete --olderで
・workflowがapplyされると即時実行されるだけ
テンプレート化、再利用はしにくい
提案されているWorkflowTemplateに期待
●Q: ArgoEventsはなぜ使わないの？
・CronJobで十分だった
・ArgoEventsは多機能すぎて運用に載せにくそう
■自由と統制のバランス 共通分析基盤のアプローチ
長谷川さん / DeNA
●DeNA
・組織は事業ごとに分かれている
・複数の事業を、共通でサポートする共通分析基盤
・2010年からHadoop運用開始
2.5PB+
230+ Nodes
●project polymorph
・共通分析基盤の刷新を進行中
・DWHをBigQueryに
・周辺もGCPに
●利用者に自由度の高い分析基盤を提供していた
・多くの事業担当者が、すぐに分析できるように
・SQLクエリ、レポート作成
・バッチジョブ作成
●ゆるすぎて混乱が生じることも
・バージョン管理されていないスクリプト
・いつのまにか .bashrc が書き換えられていたり
-> 原因
構成管理が不十分
利用者がエンジニアではない
●まだまだ自由が足りないことも
・ガチにAI/MLに取り組む -> 専用の環境
・スモールスタートしたい -> 共有、でも自由にしたい
●自由度を保ちつつ構成管理を強制
・terraform, GKE でIaC
・githubと連携しなければならないしくみ
スクリプトやタスク定義はdigdagに保存
外部からはdigdag pushさせない
・コンテナで環境を隔離
基盤提供のサービスはコンテナ
digdagのタスクでk8s apiを叩いて、k8s jobを起動
好きなコンテナでどうぞ
・GKEオートスケール
Cluster Autoscaling
初期ノード数は0にしておけば、使った分だけ課金
GPU、メモリ多めなど使いそうなパターンで node poolを定義
Node Auto Provisioning で見繕ってくれるようになりそう
まだベータ版
Workload Identityで鍵管理不要になる？
●Q: 利用者がDockerfileを書いているの？
・やりたいことが様々
・Dockerfileまでは利用者に書いてもらっている
■感想
・トランザクションスクリプトだったワークフローをドメインに分割
・コンテナ単位で処理を閉じて、パイプ&フィルターでワークフローを構成
・利用者とインフラの境界をDockerfileで区切る
など
データパイプラインでも規模が大きくなるとアプリと同じ悩みを抱えるのだな、としみじみ感じました。入力データを加工して出力データをつくるのが機能なので、改めて考えるとあたり前のことでしたが、この認識のずれがつらみを生んでいるのかもしれませんね。
登壇者の皆さん、運営の皆さん、ありがとうございました！
いつも応援していただいている皆さん支えられています。