データアナリストとログ基盤の付き合い方 DataAnalystMeetup#07
- 1. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL データアナリストとログ基盤の付き合い方 Sotaro Tanaka @DataAnalyst Meetup #07
- 2. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL Sotaro Tanaka Data Analyst @ BI Team ● 23歳(今年24歳/大学院中退) ● 新卒データアナリスト ● 現在は、Pairsの新たなログ基盤の設計/構築/ 運用を主に担当 ● 趣味はアニメとゲーム(dbd, Fortnite) 自己紹介
- 3. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL ● データアナリストのログ基盤との関わり方について ● eureka BIチームのログ基盤との関わり方について ● Pairsで新しくログ基盤を作ったときの教訓 今日話すこと
- 4. ところで
- 6. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL ：「基盤周りはインフラとかデータエンジニアに任せとけばいいんじゃね？」 ● そもそも正確なデータがないと、アナリストは価値を発揮できない ● そして、100%「正しい」データを取得し続けることはとても難しい ○ なので、分析に必要なレベルの「正しさ」を見極めることが重要 ○ その「正しさ」を決めるのはアナリスト、データサイエンティスト なぜ、ログ基盤の話？
- 7. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL 確実にデータを残す ?可用性 ?保守性 ?べき等性 ?機密性 etc. ログ基盤にまつわる責任領域 正しいデータを残す ?データの定義 ?ログ設計 ?正しさのレベル設定 ?検証 etc. ログ基盤周りの責任領域をざっくり以下の2つに分けてみる
- 8. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL 確実にデータを残す 可用性 保守性 ログ基盤にまつわる責任領域 正しいデータを残す ?データの定義 ?ログ設計 ?正しさのレベル設定 ?検証 etc. アナリストが責任を持つべき領域
- 9. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL 確実にデータを残す ?可用性 ?保守性 ?べき等性 ?機密性 etc. ログ基盤にまつわる責任領域 正しいデータを残す ?データの定義 ?分析に利用できるレベル の正確さの担保 インフラ、データエンジニアが責任を持つ領域
- 11. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL eurekaのBIチームでは、現在、ログ基盤関連で以下の業務を担当している eureka BIチームのログ基盤との関わり方 ● ログの設計 ● クライアント/サーバーサイドエンジニアへの実装ディレクション ● データやスキーマの管理 ● 生ログから任意の中間データへのETL
- 12. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL アクションまでに複数の経路があるため、経路別の分析が必要になる Pairsのデータの特徴 / 分析の切り口 「注目のお相手」枠経由の いいね！ 「あなたにいいね！を してくれたお相手」枠経由の いいね！
- 13. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL 複雑なデータ構成を上手く取り扱えない設計?管理方法になっていた やりたい分析に対して、データは課題を抱えていた ● アクションまでの経路情報はハードコーディングでカオス ● データに新しいプロパティを追加しにくい（スキーマに縛られる） ● 「てか、このデータ何だ？ 」 ● etc.
- 14. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL ● アクションまでの経路情報はハードコーディングでカオス ? 画面遷移などの情報を記録し、ETLでハードコーディングを代替 ● データに新しいプロパティを追加しにくい（スキーマに縛られる） ? 新しいプロパティが必要になってもテーブルスキーマを変更しない ● 「てか、このデータ何だ？ 」 ? データ定義のドキュメント化 新しいログ基盤を構築して、課題を解決
- 15. 新しくログ基盘を作ってみての教训
- 16. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL Pairsのログ基盤構築では、以下が主なハマりポイントだった ● 変更に強いログ設計?管理方法にしないと、詰む ● クライアントサイドに気を配らないと、意図しないログが入ってくる ● イベント発生の順序とログデータ処理の順序は一致しないので、タイムスタンプの 取り扱いに気をつけないと、順序が死ぬ 新しいログ基盤構築を通じて得た教訓
- 17. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL 変更に強いログの設計?管理をする Bad Good ● 新しいデータを追加するたびに、テーブルのスキーマ変更 ● 肥大化し、把握できなくなったテーブル構成 ● 「このデータ何だっけ …？」状態 ● 画面のUI等が変更されても、スキーマを変えずに新しいプロパティを追加できる設計 ○ 変更しやすいjsonの設計、BQにjson_stringのカラムを用意 ● ログの定義をコードレベル orドキュメントで管理する ○ eurekaではProtocol Buffersを導入予定
- 18. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL (特に)クライアントサイドに気を配る Bad Good ● 「〇〇のログ実装しといてー」という丸投げ ? 特にクライアントサイドは、各プラットフォームの実装やアーキテクチャの違いを踏まえないと、意 図しないログが送り込まれる ? 実装する側だけでは、「何が正しいのか」は分からない ● クライアントサイドのアーキテクチャや実装について、学ぶ ● 共通言語で、コミュニケーションをとる ● ペアプロっぽく一緒に確認しながらテストする
- 19. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL イベントが発生した順序では、ログは届かない Bad Good ● 「ログが発生した時間だけとっておけばええやろ」 ? ETLなどで適切なデータ処理ができない ? デバイス側で異なるタイムゾーンが設定されている場合など、おかしなデータになる ● 発生時間(EventTime) / 到着時間(IngestTime) / 処理時間(ProcessingTime)を記録して、 適切に処理する ○ こちらの方のスライドがとても参考になりました！ /SotaroKimura
- 20. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL とはいえ、必要なレベルに応じて必要なことをやっていけば良いだけ ● 分析に必要なレベルの「正しさ」を見極めることが重要 ● 分析する側の人こそが、そこを見極める役割を担うのが良いのでは ログ周りについて、アーキテクチャや実装レベルの話以外にも、ログ設計や管理、運用 について、もっと情報が世に出てほしい！ ● ぜひ、この後の懇親会などでお話?情報交換しましょう！ ● 良い事例など、ご存知の方いらっしゃいましたら教えてください！ おわりに
- 21. Copyright ? 2018 eureka, Inc. All rights reserved.CONFIDENTIAL ご清聴ありがとうございました！