Data Platform Meetup Vol.2に参加したので、その参加レポートを書きます。
実は既に @ikedaosushi さんが記事を書いているのでそちらを読んでください。よくまとまった記事なので「私は書く必要ないんじゃないか」とも思ってしまったのですが、私が感じたこと + 質疑応答の内容を追記していきます。
個人的に三行でまとめると↓のような感想でした。
- 社内コミュニティやドキュメントなどの啓蒙活動でスキルやナレッジの伝達を各社努力している
- Redshiftはマジで大変そう(自分はBig Queryにかなり救われている)
- 縦持ち、横持ちはコンテキストによって必要性が変わるので使い分ける(snowflake schema)
私も似た感想でした。
啓蒙活動について
特にpixivの長部さんの発表でよく触れられていました。「分析・データ加工の代行を期待されてしまう」というのは自分たちの会社でも起こっていて、「（悪く言うと）便利屋からどう脱却して専門性を発揮していくか」という話はデータ組織に普遍的なテーマなのかもしれません。
そのためにナレッジ共有の場や教材作成を作ったそうなのですが、個人的にはそこのモチベーションや目標の置き方をどうやっているのか気になりました。実際そういう質問もあり、それには「元々問題意識を持った人の寄り合いが部署になった経緯があるのでメンバーのモチベーションが高く、問題になってない」というような趣旨の回答されていました。
RedShift VS BigQueryについて
CookpadのInuzukaさんの発表。RedShiftの同時接続数などの制約をどう回避して便利に使うかという発表もありました。技術的な話としては面白かったのですが、自分たちのチームでGCPのBigQueryを利用しているところではあまり問題になったことがない箇所（課金額の見積もりちゃんとしてないと困る程度）ではありました（一応同時実行数などの制限もあるのですが、自分たちのユースケースだと全然余裕です）。
ただ自分たちのチームでは、DWHがBigQueryで、（機械学習も含めた）システムの開発や運用をAWSで行っているので、データやモデルをどうやり取りするかといった別の問題はあるように思います。実際にはそこまで考えて技術選定する必要があると思います。
各発表のQ & A
できるだけメモを取ったつもりですが、抜け漏れや要旨が間違っている点があればご指摘ください🙏
プロダクト中心のデータ駆動を推進していくために大事なこと
Q. 学習教材はエンジニア向け以外にもあるか？
A. ビジネス職向けのSQLのチュートリアルもある。もちろんエンジニア向けも用意している。
Q. BigQueryは従量課金なので、自由に使わせるのは課金額の点で怖くないか？
A. 裁量にまかせているものの、監視はしている。特に前日のクエリの課金額順の通知はしていて、問題のあるクエリを書いた人に指摘はしている。
Q. 教材のモチベーション維持ってどうやってる？直接ビジネスに影響しない箇所なので、KPIの設定など苦戦するのでは？
A. 元々、組織の発端が問題意識を持った人の寄り合い状態から始まっていて、メンバーのモチベーションも高いので大きな問題になってない。
Q. 民主化のためにLOOKERを利用しているとのことだが、LOOKMLは誰が定義してる？
A. リポジトリは統一していて、そこに各部署のエンジニアがコミットしてる。また規約の定義やコードレビューはデータ駆動推進室が行っている。
データを用意しただけだと使われないので、使ってもらえるようにした努力
Q. 事業部制を取っている会社でデータを集約してるのすごい。ガバナンスを効かせるのって工夫したのでは？
A.\ データの追加はこちら側がやってる。プロダクトのDBのコピーと、個人情報のマスキングして入れるのが大変だった。ただ要望を定型フォーマットで出してくれるように工夫してる。
Q. （クックパッドのコミッタの方から）dmemoの要望ってありますか？
A. Redshiftに直接繋いでいて、ActiveRecordのinteger型がRedshiftと互換性がないので独自に潰す必要があった点が大変だった。
Q. 具体的に「こういうことをしたら喜ばれた」って話はありますか？
A. データの使い方といってもいろいろあって、分析・機械学習などの応用がいくらの価値を創出したか出しづらいんですけど…。ただ、インプレッションログの表示順位を工夫した（受注確率が高い顧客を上にもってくるなど）。
DWHを活用したクックパッドの機械学習プロジェクト
時間が取れなかったため質疑応答の時間なし。他の発表も短い時間だったので、もう少し一つ一つの発表をじっくり聞きたかった気がします…。
アプリデータの分析を楽に効果的に！FirebaseAnalyticsとお友達になると良い３つの理由
Q. クライアントサイドの時刻ってイベント発生時刻と送信時刻のどちらか？クライアント側で時刻が狂ってる場合はどう扱ってる？
A. 時刻は基本的にイベント発生時刻で、タイムゾーンはすべてUTC。イベント発生時にオフラインだった場合のデータが後でバルク送信された場合に過去のデータが変わることはあるので、3日さかのぼってデータマートを作ってる。
DWH デザインパターン 〜 テーブル設計編 〜
Q. テーブルの設計で、ディメンションとファクトを分けるのが習慣としてある人とない人がいて、「なぜこう持たないの？」って衝突があるはず。そこは乗り越えた？
A. レビューや「規約に乗るとこういうメリットがある」と説明することで乗り越えている。また規約に則って作ると便利になるように補助するツールを実装している。
Q. 「指標」部分はどうしてるのか？（ここの質問の意図がメモできませんでした…）
A. 具体的な指標の話は（業務の話になるので）外で話しづらいが、再利用しやすい形にはしてる。指標のカタログを作っているイメージ。
