omuronの備忘録

個人的な備忘録

「Data Engineering Study #2 データ収集基盤とデータ整備のこれまでとこれから」 #DataEngineeringStudy 受講メモ

お盆休みでサボってたので久しぶりの勉強会視聴です。

forkwell.connpass.com ハッシュタグ :#DataEngineeringStudy

登録者千人超えてますね。すごい。

基調講演「事業に貢献するデータ基盤を作ろう・考え方編」

speakerdeck.com

データ基盤は意思決定に使えない/使われないと意味がない。
作ることが目的になってないか注意する。

データ整備は技術よりも段取りとコミュニケーションの比重が高い。
他と違う役割があるので担当者(データアーキテクト)を置くほうがいい。

基盤と整備と利用のバランスを考える。

おすすめ本

QA

初期フェーズのスタートアップの分析基盤を考える時どんな構成にしますか? (コストの制約が厳しい中、今後の拡張性も踏まえて構成を検討する必要があると思ってます。)

基盤よりミニマムで最低限なことをやるほうがいい。

初学者の勉強方法は?

最近の話なので無い。知ってる人から学ぶ。

データ整備後の保守運用について。きちんと整備された状態を維持するにはどうすればいいか。

整備後はなくて常に保守が必要。エラーのチェック体制を作っておくかが大事。

事例紹介1「データ収集の基本と 「JapanTaxi」アプリにおける実践例」

www.slideshare.net

事業システムから生まれたデータを分析システムにいれる。

ファイルフォーマット種類

  • CSV,TSV
  • JSON
  • AVRO : バイナリ
  • Parquent,OCR : 列方向で圧縮している

事業 DB に select * などして直接負荷をかけない。
リードレプリカを活用するなど。

事業システムは売上を上げてて偉い。
分析システムはそうじゃないので注意する。

QA

押し付けあいになりやすいデータ整備する泥臭いタスクを組織的に前向きになれるようにどう取り組んでいますか?

利用している人のチームに入って分析しながらデータを取るのが最適。
難しいなら上司と目標を決めて取り組む組織にしないと難しい。

データマネジメント/データガバナンスについて、インフラエンジニアとしてシステムとプロセスの点で留意している点

メタデータを書けて共有できる場所を準備する。
データに対するノウハウを貯める場所を作るのがインフラ側の仕事。
クエリログを日々貯めるのは重要。使われてないテーブルがわかる。

こういうデータ取りたいんだけど、結構めんどくさいケースなど聞いてみたいです。

事業部が遠いケース。知り合いがいない場合など。
事業が遠いほどめんどくさい。
技術的じゃない課題。調整力が重要。

縦も横も際限なく増えるデータに対して、スケーラビリティ・レスポンス性能をどう設計するか。

クラウド使う。オンプレ使わない。従量課金でスケールできるものでやる。

事例紹介2「メルカリにおける分析環境整備の取り組み」

speakerdeck.com

現状:なぜ改善に取り組むのか?

基盤: BigQuery + Locker
クエリ実行ユーザー 700人/月 (社員数1,800人)
テーブル数 100以上/月

ありたい姿:改善のサイクルを回し続ける

負のサイクルはさけたい。
改善のサイクルを回すことで現状維持が楽になりさらに改善させ、攻めの改善もできる。

取り組み:レガシーなデータセットを廃止する

古いもののメンテナンスコストは削減したい。
レガシーテーブルを削除したいが古いテーブルで計算している KPI を利用しているチームがある。
レガシーな pipeline へ依存した業務があるのが問題。
キャンセル処理の取り扱いが新旧で違っていた。
業務要件を元に KPI の定義を見直してレガシーなテーブルへの依存をなくす。

基盤と指標と業務はセットで考える!

QA

データ整備におけるスピードと品質の両立について、どう取り組まれていますか?

品質を重視する。
データは目に見えない依存関係が発生する。
システム上現れないけど沢山の人が依存したテーブルが発生するので、品質をあげて運用コストをあげないようにする。

データ分析基盤のリファクタリングについて、タイミングや進め方のコツ等あればお聞きしたいです。

リファクタリングというかリプレイスの話ですが、レガシーなシステムを廃止する過程でニーズが見えてくる。
取引に関してキャンセルを除かずにデータを見たいというニーズがレガシーテーブルを廃止するときにわかったりなど。

データ分析基盤づくりの際に、運用のしやすさ、変更のしやすさをユーザとエンジニア間で調整するのが大変です。皆さんどのように変更予想や調整をしているのでしょうか?

データを処理するときに不可逆的な変換はできるだけ後にする。
明細に近い状態でデータを加工しておく。

所感

エンジニアの自己満足でシステムを作るのではなく、使うユーザーとコミュニケーションをとって改善を続けることが大事なのは、データ収集基盤に限った話ではないですね。
どうしても作るのが目的になったり、目標を達成するために無理やり形にしたりとか、作る立場としてはありがちなので気をつけないと。
作ったけど使われないシステムは悲しいですしね。