データアナリストとログ基盤の付き合い方 DataAnalystMeetup#07

Copyright © 2018 eureka, Inc. All rights reserved.CONFIDENTIAL
データアナリストとログ基盤の付き合い方
Sotaro Tanaka
@DataAnalyst Meetup #07

Sotaro Tanaka
Data Analyst @ BI Team
● 23歳(今年24歳/大学院中退)
● 新卒データアナリスト
● 現在は、Pairsの新たなログ基盤の設計/構築/
運用を主に担当
● 趣味はアニメとゲーム(dbd, Fortnite)
自己紹介

● データアナリストのログ基盤との関わり方について
● eureka BIチームのログ基盤との関わり方について
● Pairsで新しくログ基盤を作ったときの教訓
今日話すこと

なぜ
「DataAnalystMeetup」で
ログ基盤の話？

：「基盤周りはインフラとかデータエンジニアに任せとけばいいんじゃね？」
● そもそも正確なデータがないと、アナリストは価値を発揮できない
● そして、100%「正しい」データを取得し続けることはとても難しい
○ なので、分析に必要なレベルの「正しさ」を見極めることが重要
○ その「正しさ」を決めるのはアナリスト、データサイエンティスト
なぜ、ログ基盤の話？

確実にデータを残す
　　・可用性
　　・保守性
　　・べき等性
　　・機密性
　　etc.
ログ基盤にまつわる責任領域
正しいデータを残す
・データの定義
・ログ設計
・正しさのレベル設定
・検証
etc.
ログ基盤周りの責任領域をざっくり以下の2つに分けてみる

可用性
保守性
・ログ設計
・正しさのレベル設定
・検証
etc.
アナリストが責任を持つべき領域

　　・可用性
　　・保守性
　　・べき等性
　　・機密性
　　etc.
・分析に利用できるレベル
の正確さの担保
インフラ、データエンジニアが責任を持つ領域

eurekaのBIはどうやってるのか？

eurekaのBIチームでは、現在、ログ基盤関連で以下の業務を担当している
eureka BIチームのログ基盤との関わり方
● ログの設計
● クライアント/サーバーサイドエンジニアへの実装ディレクション
● データやスキーマの管理
● 生ログから任意の中間データへのETL

アクションまでに複数の経路があるため、経路別の分析が必要になる
Pairsのデータの特徴 / 分析の切り口
「注目のお相手」枠経由の
いいね！
「あなたにいいね！を
してくれたお相手」枠経由の
いいね！

複雑なデータ構成を上手く取り扱えない設計・管理方法になっていた
やりたい分析に対して、データは課題を抱えていた
● アクションまでの経路情報はハードコーディングでカオス
● データに新しいプロパティを追加しにくい（スキーマに縛られる）
● 「てか、このデータ何だ？」
● etc.

● アクションまでの経路情報はハードコーディングでカオス
⇨ 画面遷移などの情報を記録し、ETLでハードコーディングを代替
● データに新しいプロパティを追加しにくい（スキーマに縛られる）
⇨ 新しいプロパティが必要になってもテーブルスキーマを変更しない
● 「てか、このデータ何だ？」
⇨ データ定義のドキュメント化
新しいログ基盤を構築して、課題を解決

新しくログ基盤を作ってみての教訓

Pairsのログ基盤構築では、以下が主なハマりポイントだった
● 変更に強いログ設計・管理方法にしないと、詰む
● クライアントサイドに気を配らないと、意図しないログが入ってくる
● イベント発生の順序とログデータ処理の順序は一致しないので、タイムスタンプの
取り扱いに気をつけないと、順序が死ぬ
新しいログ基盤構築を通じて得た教訓

変更に強いログの設計・管理をする
Bad
Good
● 新しいデータを追加するたびに、テーブルのスキーマ変更
● 肥大化し、把握できなくなったテーブル構成
● 「このデータ何だっけ …？」状態
● 画面のUI等が変更されても、スキーマを変えずに新しいプロパティを追加できる設計
○ 変更しやすいjsonの設計、BQにjson_stringのカラムを用意
● ログの定義をコードレベル orドキュメントで管理する
○ eurekaではProtocol Buffersを導入予定

(特に)クライアントサイドに気を配る
Bad
Good
● 「〇〇のログ実装しといてー」という丸投げ
⇨ 特にクライアントサイドは、各プラットフォームの実装やアーキテクチャの違いを踏まえないと、意
図しないログが送り込まれる
⇨ 実装する側だけでは、「何が正しいのか」は分からない
● クライアントサイドのアーキテクチャや実装について、学ぶ
● 共通言語で、コミュニケーションをとる
● ペアプロっぽく一緒に確認しながらテストする

イベントが発生した順序では、ログは届かない
Bad
Good
● 　　「ログが発生した時間だけとっておけばええやろ」
⇨ ETLなどで適切なデータ処理ができない
⇨ デバイス側で異なるタイムゾーンが設定されている場合など、おかしなデータになる
● 発生時間(EventTime) / 到着時間(IngestTime) / 処理時間(ProcessingTime)を記録して、
適切に処理する
○ こちらの方のスライドがとても参考になりました！
https://www.slideshare.net/SotaroKimura

とはいえ、必要なレベルに応じて必要なことをやっていけば良いだけ
● 分析に必要なレベルの「正しさ」を見極めることが重要
● 分析する側の人こそが、そこを見極める役割を担うのが良いのでは
ログ周りについて、アーキテクチャや実装レベルの話以外にも、ログ設計や管理、運用
について、もっと情報が世に出てほしい！
● ぜひ、この後の懇親会などでお話・情報交換しましょう！
● 良い事例など、ご存知の方いらっしゃいましたら教えてください！
おわりに

ご清聴ありがとうございました！

データアナリストとログ基盤の付き合い方 DataAnalystMeetup#07

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to データアナリストとログ基盤の付き合い方 DataAnalystMeetup#07

Similar to データアナリストとログ基盤の付き合い方 DataAnalystMeetup#07 (20)

データアナリストとログ基盤の付き合い方 DataAnalystMeetup#07