はじめに
Data Platform Meetup 【vol.2】に参加させていただいたときのメモ。
Data Platform Meetupとは
（以下引用）
自社のデータプラットフォームを設計/開発/利用している方（データエンジニア/データアナリスト/データサイエンティスト/機械学習エンジニア等）がノウハウを発表したりカジュアルに情報交換できるイベントです。
以下のような話がされるイベントです
* DWHの設計〜活用（データレイク・データウェアハウス・データマート）
* データ活用にに関わる組織・仕組みの設計（データアナリストとデータエンジニアの役割分担など）
* BIツールの設計・利用方法
* 分析に関する品質担保（ダッシュボードの品質・冪等性の担保など）
* 運用を見据えた管理・統制（権限設定・マスキングなど）
メモ
プロダクト中心のデータ駆動を推進していくために大事なこと
- ピクシブ 長部 和仁さん tohhy
- 「プロダクト開発メンバー主導の民主的なデータ活用を目指すとどの企業でも直面することになるであろういくつかの課題と、それらに対するピクシブ株式会社データ駆動推進室の取り組みをご紹介します。」
- なぜ今データプラットフォーム？
* クラウドDWHと機械学習技術の進歩
* 運用が簡単になったし、活かせるようになった
* -> 可視化、分析も合わせてやっていく - 組織編成のパターン
* 集権化と民主化
* メリデメはある。ピクシブは民主化に踏み切った。コストメリット。ドメインが多いと、集権型では、見切れない。 - 民主化のためにやったこと
* プロダクトチームで自己完結できるようにお膳立て
* データ基盤操作のテンプレート化
* Lookerの導入
* github。レビューがやりやすい。
* 規約はデータ基盤チームが作るが、実装は各チーム
* Slackチャンネル開設
* 分析ワクワクタイム
* データ基盤チームに直接聞ける時間
* 心理的なハードル低く
* チュートリアルを作成 - 課題
* 中間テーブル増え過ぎる
* 監視していく対象も増えている
* 日次でクエリの課金額順に通知とか
データを用意しただけだと使われないので、使ってもらえるようにした努力
- リブセンス Hashimoto Yuki さん
- 「データ分析基盤を管理する立場のエンジニアチームが、ユーザーたる社内の皆様にデータをお使い頂けるよう日々努力している、非エンジニアリング業の話。」
- Redshift, redash
- データだけ置いていても使ってもらえない
- -> そのためにやったこと（ホスピタリティが大事！）
* ドキュメントの整備
* それを使ってできること、を簡潔に
* dmemo（後述）
* 事業部の様子を観察 * 主体的に、事業の方向性をおさえておくようにする
* 事例共有会を催す - ガバナンスを効かせるためにしていること
* データの追加は、データ分析基盤チームがやっている
* 追加依頼は、ドキュメントの記載に従って依頼する
DWHを活用したクックパッドの機械学習プロジェクト
- クックパッド Inuzuka Shintaroさん
- 「大量のユーザーデータをDWHに格納しているクックパッドが，それらのデータをどのように機械学習に活かしてきたか，その際に発生した問題とそれらに対する取り組みについてご紹介します。」
- 学習フェーズ
* Redshiftからpythonで直接接続はよくない（資料参照）
* Queuery経由でHTTP APIリクエスト（unload文でラップ）->実態はS3に格納される - 推論フェーズ
* dmemo
* データベースドキュメント管理システム
* Redshiftに直接アクセスして生成
* 投入も、MySQL（とS3）経由で。ツールを作った。
アプリデータの分析を楽に効果的に！FirebaseAnalyticsとお友達になると良い３つの理由。
- エウレカ Kurimuraさん t_kurimura
- 「アプリ系のサービスでのデータ分析には多くのツラミがあります。アプリエンジニアへ依頼するコミュニケーション、収集するデータの選定、収集したデータの加工。FirebaseAnalyticsを利用することで、より多様なデータをより簡単に利用することができます。アプリエンジニアとしての経験を元に、Pairsでの活用事例を交えて僕のお友達、FirebaseAnalyticsをご紹介します。」
- Firebase Analytics
* -> 実態はGoogle Analytics
* 収集
* Bulk送信
* SDKを入れるだけで、様々なイベント情報が自動で収集される。独自に実装しなくても。
* あくまでRawデータが上がってくるので、ETLは大事。
* 活用
* A/B testing
DWH デザインパターン 〜 テーブル設計編 〜
- Retty Takeno Shunsukeさん takegue
- 「アーキテクチャレベルの大域的な観点はお話はこれまでありましたが、実装のパターンについての説明はあまり触れてこられてきませんでした。 発表では、スノーフレークスキーマに始まり一般的な代表的なスキーマ構成にふれたのち、実践的なテーブル構成について触れたいと思います。 具体的なテーブル構成をどのように整理すると良いのか、の議論の発端となれば幸いです。」
- 分析のための設計
* SQL vs Python
* 誰が使うか
* スキーマ
* スノーフレークスキーマ
* ディメンジョンテーブルとファクトテーブル
* > スノーフレークスキーマとは、ディメンション表の一部または全部が正規化されたスタースキーマである。通常のスタースキーマと同様、OLAPのキューブを構築する際に使われる。
* 横持ち vs 縦持ち - 事例
* SQL、横持ち - 大事なこと
* 誰のためのデザインか考える
