LTの発表資料です https://data-platform-meetup.connpass.com/event/155073/
つかわれるデータプラットフォーム〜デザイン編〜 फ़ี%BUB1MBUGPSN.FFUVQ
View Slide
͜ΕΛ͓͢͠Δਓ फ़ีʢ!UBLFHVF%BUB1MBUGPSN.FFUVQ3FUUZιϑτΣΞΤϯδχΞ$PSF7BMVF σʔλΞʔΩςΫςΟϯάσʔλͷՁΛ࠷େԽ͢ΔΈઃܭͷ࣮ݱࣥච׆ಈʮ༏ઌֶशʹΑΔਪનจ͔Βͷݟग़͠நग़ʯ03ֶձʮͬͯΈΑ͏ʂ ػցֶशʢ4PUXBSF%FTJHOʣʯʮࢼֶͯ͠Ϳ ػցֶशೖʯʮσʔλج൫ͻͱΓ"EWFOU$BMFOEBSʯ /FXଞʜ
分析上で発生する悲しみ%BUB1MBUGPSN.FFUVQ
分厚いjoin (わからない)
依存関係を壊したくなくて乱立するオレオレview
整合性が保てるか不安なダッシュボード群
%BUB1MBUGPSN.FFUVQこれらは設計(デザイン)の失敗が原因
分析のためのデザイン%BUB1MBUGPSN.FFUVQ注意を払うべきデザインの3つの観点をさっくり紹介
42- 1ZUIPO 3分析のためのデザイン: 42-WT1ZUIPOʁ利用者を想定した言語(インタフェース)選びも選定基準のひとつ● データアクセスのため目的特化● 汎用的なプログラムが書きづらい● エンジンごとに命令セット変わる● コードの保守・運用しづらい● 汎用的なプログラム描きやすい● ライブラリも充実...● 機械学習等への接続も比較的容易● コードの保守・運用はしやすい
データをディメンションテーブルとファクトテーブルに分けて整理分析のためのデザイン: εϊʔϑϨʔΫεΩʔϚ %BUB1MBUGPSN.FFUVQディメンジョンテーブル:テーブルは非正規化状態で保持ファクトテーブル:ディメンションに対して集計
ԣ࣋ͪ ॎ࣋ͪ分析のためのデザイン: ԣ࣋ͪ WTॎ࣋ͪ*% ଐੑ ଐੑ1 John Hoge2 Ben Fuga*% ଐੑ 1 属性1 John1 属性2 Ben2 属性1 Ben2 属性2 Ben● 型制約をつけやすい● 補完がききやすい● 記述が冗長になりやすい● ピボットテーブル向き● 制約の保持が厳しい
BigQuery上での実践: Rettyでの事例%BUB1MBUGPSN.FFUVQ
データフロー依存の方向性データ置き場
データフロー依存の方向性データ置き場ディメンションファクト原則 横持ち各 Projectは指標から選ぶビューで依存関係の明示単方向の依存だいたいSQL
イベント層%BUB1MBUGPSN.FFUVQ- イベントログ系のレコードテーブルを整形、構造化する。- クロスプラットフォームである程度共通に使えるような構造化(自前のログ基盤, Firebase, GoogleAnalytics ...)- 不要なカラムや前処理等も行う
エンティティ層%BUB1MBUGPSN.FFUVQドメインにおける主要なエンティティについてまとめる- プライマリテーブル(core);- joinの手間を減らし、使いやすい形式に構造化- ユニーク制約等を実現- as-was分析のために各entittyでhistoryを構築- ディメンジョンテーブル(dim__xxx): 分析カスタム定義のディメンジョン
指標層%BUB1MBUGPSN.FFUVQ- ファクトテーブルの構築する- 特定の指標の最小粒度(grain)の構築- 同じデータセット内では、必ず同じ指標を持つ指標に着目したグルーピング- 指標のバージョニングの実現(自動生成)
%BUB1MBUGPSN.FFUVQQ. 誰のためのデザイン?
%BUB1MBUGPSN.FFUVQ分析者ステークホルダ意思決定者データ基盤開発者アプリケーション開発者Q. 誰のためのデザイン?
%BUB1MBUGPSN.FFUVQ分析者ステークホルダ意思決定者データ基盤開発者アプリケーション開発者転送基盤 分析基盤レポーティング基盤ログ基盤ヒトとヒトのつなぎめに価値を作る: デザインの問題Q. 誰のためのデザイン?
☺%BUB1MBUGPSN.FFUVQつかいやすい基盤でみんなを幸せになろう!
%BUB1MBUGPSN.FFUVQ