タダです.
前回「Data Engineering Study #1 」に続き「Data Engineering Study #2 」が開催されたので参加してきました.今回の記事では発表を聞いて感じたことやメモをとった内容をまとめていきます.
イベント概要
第1回勉強会では「DWHとBIツール」の選び方について学びました。
これらはデータを扱うためのツールですので、当然「データ」そのものを集めないといけません。実は大容量データの取り扱いには専門的な知識が要求されます。
今回の勉強会では、データを集めるための基盤の話と、集めたデータをビジネス活用しやすい状態に整備する方法の、2つのテーマについて学びます。
基調講演には「前向きデータ整備人」勉強会主催者のしんゆう氏をお招きし、今回のテーマの概論をお話し頂いた後、実際にデータ収集・整備を行われている2社の事例から学んでいきます。
本編動画
当日のツイートまとめ togetter.com
基調講演「事業に貢献するデータ基盤を作ろう・考え方編」
「データアーキテクト（データ整備人）を”前向きに”考える会」で知っていたしんゆうさんの発表でした.しんゆうさんといえば,note でも情報発信されています
発表を聞いての所感
発表を聞いて,データ基盤がなぜ必要で「データ整備」の工程でどんなことをしていてこの工程がないとどう苦労するのかを調理でたとえてくださったのですがわかりやすかったです.前回の勉強会でもありましたが,基盤を作ったが使われない事態を回避するためにも「データ整備」の工程が必要なんだと感じました.
発表メモ
- なぜデータ基盤を作るのか
- データ基盤の意義をプロセスから考えるとデータ収集はデータから知りたいことのために必要なデータを集める仕組みづくり(=データ基盤)
- データ基盤はデータ分析プロセスの中の収集フェーズを速やかかつ正確に行うための仕組みのこと
- データ基盤の意義をプロセスから考えるとデータ収集はデータから知りたいことのために必要なデータを集める仕組みづくり(=データ基盤)
- 価値のないデータ基盤を作らないためにはどうするか
- 使われない時に問うべきは利用者のニーズを満たせてなかったのではないかを問う
- 利用者のニーズはデータで何が知りたいのかをつかむことから始める
- 基盤と利用のバランスをとる
- 作ることが目的になったら利用まで繋がらない
- 基盤構築と基盤の利用との間に必要なプロセスがある
- 作ることが目的になったら利用まで繋がらない
- 基盤と利用の間の役割
- 基盤と利用の間の役割として必要なデータを集めて,必要なデータを整理してデータの不備がないかを基盤作る人と相談
- 基盤と利用までの間のアクションを「データ整備」とする
- 基盤と利用の間の役割として必要なデータを集めて,必要なデータを整理してデータの不備がないかを基盤作る人と相談
- データを整備しないとどうなるか
- データを整備する人がいないとデータを使ってやりたいことをするために必要な情報が整ってないから都度処理することになり大変
質疑応答
- 初期フェーズのスタートアップの分析基盤を考える時どんな構成にするか
- データで何を知りたいかを把握する
- 基盤を作ることにコストをかけずミニマムな構成で作った方が良い
- データで何を知りたいかを把握する
- 初学者の勉強方法はあるか
- 基盤の整備はここ数年くらいのトピックなので知っている人について学ぶのがいい
- しんゆうさんはどう学んできたか
- 周りの人を見ながら自分が何をやるべきかを選定する
- イベントの登壇者に声かけていくのがいいと思う
- データ整備後の保守運用について
- いかにエラーチェック体制をとれるか
- テーブルチェックしてエラーが出たらアラートチェックする等
- いかにエラーチェック体制をとれるか
発表資料
事例紹介1「データ収集の基本とJapanTaxiにおける実践例」
JapanTaxi 社の渡部さんの発表です.個人的に渡部さん著の「ビッグデータ化分析のシステムと開発がこれ一冊でしっかりわかる教科書」を読んだのですが,インフラからデータエンジニアへのキャリアを形成していきたいと思っているので関連トピックをさらえて勉強になりました.そんな渡部さんの発表は第2回のイベントが発表された時から気になっていました.
発表を聞いての所感
当日の Twitter の反応でもそうでしたがデータ収集における教科書のような内容で,収集するデータの種類,ファイルの形式,収集方法,実践例,注意点が詳細に整理されており僕もデータ収集フェーズを担当するようになったら何度もお世話になるだろうと思いました.注意点も含蓄ある内容で多くのご経験からお話しされていてウンウンととても勉強になりました!
発表メモ
- データ収集はシステム内で赤枠の範囲で考える
- データソースの種類と収集方法については下記のページで頻度,データソース,収集例,収集方式がまとまっておりわかりやすい
- データの収集方法は次の通り
- Japan Taxi でのデータ収集実践例
- 図解化されているが,データ収集の節で説明した様々な方法を組み合わせ実現している
- データ収集の注意点
- ETL 製品はたくさんあるためどのように付き合うか
- データソースの変更対応
- データ収集の優先度を考える
* データ収集チームが作られた要注意- 目的がわからない取り組みはやめ,事業インパクトを理解してデータ収集に優先順位をつける
質疑応答
- 押し付けあいになりやすいデータ整備する泥臭いタスクを組織的に前向きになれるようにどう取り組んでいるか
- 可能なら利用チームに入って分析する
- データ分析の目標値を決めていく
- データマネジメント/ガバナンスについてインフラエンジニアとしてシステムとプロセスの点で留意している点はあるか
- メタデータをかけてシェアする場所を用意する
- 情報を一元化して管理がしやすくなる
- データの持ち主と説明がわかってればデータ管理上わからなくなるぽくないことは少なくなる
- クエリログをとるのが重要
- 使われてないテーブルがわかって影響の有無がわかる
- メタデータをかけてシェアする場所を用意する
- こういうデータ取りたいけど,結構めんどくさいケースはあるか
- 利用の事業部が離れていて知り合いがいなかったり,データ利用するのが別会社だったりして誰に話していいかわからない
- 上記の場合は調整できる人をいれたりして対応する
- 利用の事業部が離れていて知り合いがいなかったり,データ利用するのが別会社だったりして誰に話していいかわからない
発表資料
関連書籍
図解即戦力 ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書
- 作者:渡部 徹太郎
- 発売日: 2019/11/07
- メディア: 単行本（ソフトカバー）
事例紹介2「メルカリJPにおける分析環境の整備」
事例2つ目はメルカリ社の永井さんの発表です.この発表ではデータ収集後,①データの整備で改善になぜ取り組み,改善のサイクルを回して理想と現実を埋める理由と②レガシーデータセットを廃棄する取り組みをお話しされました.
発表を聞いての所感
メルカリ社はデータ基盤の運用上の2つの課題の話でした.データ基盤を作って終わりではなくなんとなく回っているから良いのではなく改善を行なって社員の生産性の向上や自分たちの時間を生み出すことに努めているのだなと思いました.改善を回すのも現状の課題や利用状況を可視化して把握,利用者がどんな利用形態を求めているのかを確認して対応されていたのは参考になりました.
発表メモ
- なぜ改善を回すか
- 基盤は BigQuery と LOOKER
- なぜ改善に取り組むのか -> たくさんのデータ分析の業務があるため,分析環境の改善が生産性の改善につながる
- 理想形:改善を回し続けられるようにしたい
- 避けたいことは改善に取り組まない -> 現状維持でじわじわ大変 -> 改善に使える時間が減少
- やりたいことは改善に取り組む -> 現状維持が楽になり改善に使える時間が増えて十分な余裕を作って攻めの改善もできる
- 取り組み:レガシーなデータセットを廃止する
- 2つのデータパイプライン問題
- 本番の元テーブルから BigQuery の分析用テーブル(新とレガシー)が2つある
- メンテナンスコストがかさむしテーブル間の数字のズレがあった
- レガシーなテーブルがなぜ必要かの業務理解とKPIの要件を調べていくことでレガシーシステムの廃止に向けて取り組んだ
- GMV(流通取引総額)の見方としてどう集計したいかを確認したところ新しいデータパイプラインで賄えそうだとわかった
- 2つのデータパイプライン問題
- 取り組みのポイント
- データ基盤はどう集計したいかの要件(指標や業務の内容)によって依存するので基盤だけで問題を考えない
- 取り組みの範囲を絞り込む
- テーブル別で参照ユーザー数を見て使っている人の人数によって改善箇所をきめていくとよい(人気のテーブルとそうでないテーブルで利用者数に100倍の差がある
質疑応答
- データ整備におけるスピードと品質の両立についてどう取り組んでいるか
- スピードと品質のトレードオフがあると思っていて品質を重視する
- データは目に見えない依存関係(会議や意思決定など)があると思っていて変更や廃止は容易でなかったりするので品質ばっちりなものを出すと運用負荷が低くなる
- データ分析基盤のリファクタリングについてタイミングや進め方のコツ
- レガシーシステムの廃止の過程でニーズを把握して新しいシステムに取り組んだ
- データ分析基盤づくりの時の運用や変更のしやすさをユーザとエンジニア間で調整が大変でどのように変更予想や調整しているか
- なるべく変更を発生しないようにする工夫として不可逆的な変更はなるべく後回しにする
発表資料
まとめ
「Data Engineering Study #2 」で聞いた発表ごとに所感と発表メモ,質疑応答の内容をまとめていきました.次回のイベントも公開されており,次は分析基盤の組織にどう浸透させていくかにフォーカスした内容のようです.基盤を使っても使われなかったりすると意味ないのでどう普及させるかを聞けるのかと思うと次回も楽しみですね!
関連記事
前回の参加レポート sadayoshi-tada.hatenablog.com
