#DPCTAirflowLuigiジョブ管理ツールレポート2019年02月14日しんや(675)118118件のシェア(ちょっぴり話題の記事)この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。昨日(2019年02月13日(水))、下記のイベント(勉強会)に参加してきました。データ分析基盤、また機械学習基盤にとって、要望を満たすデータを整形、準備する『パイプライン』の存在は必要不可欠です。そんな題材をテーマにした勉強会の内容をレポートしたいと思います。さんから資料を下敷きにオープニングトーク。Deck開始時刻近辺になった辺りでビル入館手続き等で会場に到着できていない人が居る状況が発生してしまう事態に。@tetsuroitoさんはこれを『ビルの行列(パイプライン)が待ち状態になっております。"パイプラインの勉強会でパイプラインが詰まる"いう状況になってしまいました』とすかさずネタにして会場の雰囲気を和やかに温めておりました。こちらのイベント40人規模開催のイベントに150人超の募集があったという事でかなりの競争率。「正直こんな勢いで集まるとは思っていなかった」としつつも「皆さんのカジュアルな発言を期待しています」とコメント。ちなみに勉強会のタイトルとなっている"カジュアル(Casual)"の意味はこちらをご参照ください。基本的には登壇者が話したい事を話したい様に話すストロングスタイルな感じです。DevelopersIOイベント開催の経緯としては、下記のスライドページが主旨となっていました。データ分析環境は機械学習環境で用いる「データ」の生成及び品質向上には「パイプライン」は欠かせないものですが、このパイプラインを作り上げていく、運用していく上で色々な課題、作業を行う担当者等が直面する様々な問題とストレス等など。この部分を円滑に進めていくにはどの様なスキルや経験が必要なのか、そういったテーマについてざっくばらんに、「カジュアル」に語り合いたいという思いがあったようです。@m_nishibaさん)」であるエムスリー様の立ち位置やサービスのシェア状況、また会場でしか聞けないちょっとしたお話も聞くことが出来ました。機械学習におけるデータ管理ここから本編となる「カジュアルトーク」です。メモ基本的にはML(機械学習)の文脈で話された内容。パイプライン構築にはLuigiを使っている。Luigiの名前の由来は「世界で2番目に有名な配管工」から取られている。Luigiを拡張したGoKartというフレームワークを開発・運用している。"luigi"17年7月にAIチームを立ち上げたものの、様々な課題が挙がってきており結構キツい状況になっていた。データの使い回しが難しい、モデルの再現性が低い、ログ出力が適切ではない...等これらの諸問題を解決するためにLuigiを活用。LuigiはSpotifyによって開発。タスク(Task)の組み合わせでパイプラインを作れて、インタフェースも決まっているので設計もシンプルにできた。拡張したGoKartでは、タスクとIdだけで状況を再現出来る仕組みを用意。Luigiを活用することでタスクの実装も簡単になり、ログも読みやすくなった。挙動の切り替えも設定ファイルで簡単に実現可能に。モデルの保存に工夫を凝らした。複数ファイルが吐かれる環境のものはまとめてzipするようにして保存して管理を容易に。再実行やSlack通知も出来るように改良。まとめLuigiを入れて良かった。Luigi自身、薄いライブラリなので改造もし易かった。Luigiを入れることで、生産性も向上出来た。ちなみに可視化部分についてはBigQuery→Re:dashの連携で対応。丘サーファーへ水を届けよ!〜みんながデータを使えるようにするまでの日々の挑戦(苦悩)〜2人目のトークはClassi(クラッシー)株式会社より@yuu_kimyさん。タイトルにある「丘サーファー」は、デブサミ2018夏で公開された以下セッションの内容に倣ったもの。メモ皆さん、"容易に"データにアクセス出来ていますか?弊社では多少は活用出来るようになったが、まだまだこれからの状況。実際の経緯を踏まえつつ、過去現在未来の話をしたい。データパイプラインとは何か:データの前処理が時系列に整理されて繋がったもの。(※Wikipediaより引用)何のためにデータパイプラインを?目的は『活用出来るデータのフローを、適切にコントロール出来ること』。使いづらいデータがあるだけでは意味がない。過去編データが使えない、データが無いという状況。Confluence)ようやくサクッと見れる環境が整ってきた!Bigeuqryのデータセットを整備、レイヤーを明確に定義Tableauで扱うカスタムSQLは可能な限り簡素にコンフルのメモは利用ユーザーには刺さる!Tableauの項目の解説とかに役立った。何の用途のためのデータだったのかを書きておくと良い。丘サーファーでは無くなってきたが、もっと便利にしたい。(少し先の)未来編AWSとGCPのハイブリッド環境を実現すべく今頑張っているところ目指すところは『データがウェ~イな状態』。データ基盤の3分類と進化的データモデリング3人目の発表は株式会社リクルートテクノロジーズより@yuzutas0さん。デブサミ2018夏では以下セッションで登壇されています。Deck発表内容メモ6ページ目のAAの元ネタはこちら。「ワイルド・サバンナ」はシンプルな条件で発動する遠隔自動操縦型スタンドなので、スタンドパワーはかなり強いと思われる。2015年9月3日このセッションではデータ基盤の論理設計を切り口にして、物理設計のあるべき姿を考えます。想定対象:PM・テックリード。結論はこちらの図を参照。パイプラインの流れは左から右へ、そして保守については左右両面から挟み込む形で進めていくのがポイント。@yuzutas0さん曰く『進化的データモデリング』。あるべきデータ基盤の定義:この3分類は業務フローに存在するはず。『データが利用者に届いているか』を見る場合、この3分類全てがあるかどうかがポイントとt成る。データレイク:データを加工せずに蓄積。元ネタがあることが大事、ストレージサービスが該当データウェアハウス:意味のある形で残しておく、絶妙だけど大事なニーズ:分散データストアが該当マート:特定用途向けに加工されたもの:ユースケースごとに最適化されていることが大事、redashやtableuなどが該当@yuzutas0さんの考える『データ基盤の定義』は以下。複数のデータソース(Data)と複数の利用者(Ops)をリボンの様に結びつける形が理想。その他トピックについては上記2つの資料をご参照ください。メモ前提:辛い作業を如何にして我々(田中さんサイド)がやらないように出来る、か。今回採り上げるのは『Pairs』のデータ基盤のお話。集中したいのに...)。この部分を標準化・自動化することが肝。?:結論から言うと『最初にかっちり決めて作るのはほぼ不可能』。環境や条件は変わることを前提にして、むしろ『進化させていく』ように作っていくべき。イコール『データ基盤を"育てる"』。Warehousing『腐敗防止層』を設けてパイプラインの拡張や変更に強い環境とするのも有効。Analytics:AWS上に構築。Brain:GCP上に構築。Analyticsのデータを元にモデルを生成。構成どのように活用しているか:定期的なクエリ実行、EMR起動トリガ、Glue起動トリガテスト:ロジックとDAGの管理を分割/DAGの方はあまりきっちり(テスト)出来ていないモニタリング:エラー発生時に実施。アラート通知先はSlackに集約。slackでredashのグラフ表示も行っているAirflow導入で良かったこと:タスクのスケジュールや依存関係が整理出来た実行結果のログの管理が楽になったWorkerがスケール出来るようになったAirflow導入で苦労したこと:バージョンアップが結構面倒ExecutionDateと実際の実行時刻がずれるジョブのスケジュール管理が全て解決した訳ではないまとめと言う訳で、(イベント名)の参加レポートでした。悩みと言うか、課題として捕らえている部分は皆さん共通して直面している要素もあり、また参考になるポイントも得られた実りあるイベントでした。会場ご提供頂いたエムスリー様、また当日発表された皆様、ありがとうございました!(下記はイベント関連ツイートのまとめです。6,750,896まとめ職人→出張ブロガー(初代)→AWSエンジニア→ビッグデータ系エンジニアDevelopers.IO全投稿のうち1,000本を書いています。リモート】クラスメソッドの会社説明会を開催しますクラスメソッドでは、AWS・AI・ビッグデータ・モバイルなどの技術職や営業のメンバーとして一緒にお仕事をする仲間を大募集しています。#cmdevio新型コロナウイルスの感染拡大を受け、本イベントを延期させていただくことになりました(開催時期未定)。お申し込みいただいた皆様には大変申し訳ございませんが、何卒ご理解いただけますようよろしくお願いいたします。AWSについてライトに色んな情報交換をしましょう。カフェ店長のオカノです。今日はオフィスに用があるので、通勤ラッシュを避けて出社しました。この子は新メンバーのさめくんです。在宅勤務が推奨されているのでオフィスが閑散としており、すこしさみしそうです。使いたいときの注意点を書きました。本が出ていたので読んでみたところよかったので紹介させていただきます。