Data Platform Meetup に行ってきた
Data Platform Meetup @ Retty 株式会社 行ってきた
というのも現職でまさしくデータ基盤の今後、みたいな話をしていて、なにかヒントが得られたらとの思いで参加
twitter はこちら #DPM
(9/12 追記: 後半 2 つのスライドへのリンクを追加しました)
カルチャーとエンジニアリングをつなぐ データプラットフォーム
@takegueさん
安易な役割分担はサイロ化を起こす
それ自分がやるんですかマンが増えちゃってよくないですよね。これは分析基盤かどうかあんまり関係なくて、チームがひとつのプロダクトに向かえるかどうか、な感じですね。
データレイク構築後の四方山話 #DPM / 20190905
yuzutas0さん
めちゃくちゃ早口でスライドも飛ばしながらだったので、ゆっくり見直す必要がありますね。(見直したとは言っていない)
- 中間テーブルで必要最低限のカラムにする(= キーを落とす)
- あとからキー欲しくなる
- 中間テーブル使ってもらえない件
この辺はあるあるすぎました。
中間テーブルで 利用者数 * クエリ数 がパレートの法則が効くっていうのも言われてみればたしかに、という感じ。まずは使われているところからアプローチしてみます
DataPlatform 構築プロジェクト推進の事例と学び
鉄本 環さん
BigQuery のハマりポイントは同じ轍を踏みそうなので、ありがたかった。 というのも現職で Amazon Redshift を使っていて、結構つらみがあるので代替手段を検討したいんですよね。どこかで移行するってなったら参考になりそうでした
DataMart 層で非正規化しても困ったことはなかった、みたいな実際の運用の結果を聞くと今の自分の仕事の状況も大丈夫そうなんだなーって安心できますね
大規模サービス開発における分析用データの必要要件
@shoeiさん
生データ全部 BQ に置いとくからよろしく → よいですねー
ただそうなると大事なのがログのクオリティで、そこはちゃんとルール作ってレビューしてるってのはすごい。結構プロダクト作ってるとログ後回しになりがちなので、ちゃんとしてますね、さすがの一言でした
中間テーブルの仕組みづくり → オンボーディング まできっちり作って運用するのもすげーってなりますね。やっぱり中間テーブルは 仕組み含めて使ってもらってなんぼ = なかなか使ってもらいづらい なので、ここをどうやるかという話は出てくるんだなあ
まとめ
話を聞いていて一番思ったのは、自社の状況はまた違うな、でした。 登壇していた人たちはみんな、プロダクトがあってそのデータをいかに分析するか という形だったのに対して、現職はデータ自体に希少性があって(語弊はあるけど)データ自体がプロダクト なので、扱いや考え方が異なるなあと。とはいえ援用できる部分がたくさんあったので、さっそく持ち帰って使えそうです
また逆に、現職みたいなデータがプロダクトな会社の場合の考え方、みたいな形でアウトプットをできると良さそうでした
あとは Retty にいる元同僚と会えたりしてよかったです