bq sushi(bigquery lessons learned)
TRANSCRIPT
落ちて分かるBigQuery の落とし穴
芝尾幸一郎 (Aiming)
/42
このスライドの趣旨• ゲーム会社のデータ集計・分析基盤に BigQueryを導入した。• 幾つかのゲームタイトルを BigQuery に入れて、実際に分析していく中で、どのような落とし穴に落ちてどのようにそれを回避したか、教訓を共有する。
/42
発表者紹介• 芝尾幸一郎• Aiming にてデータ分析基盤作成、データ分析担当• ニコニコ動画のランキングサイト作成• twitter:@shibacow
• 写真とったら送ってね
/42
発表者紹介• bigquery と re:dash を使って、ニコニコ動画データセットの分析を web 経由で行なうシステムを作っている• http://nicodata.info/
/42
ゲーム開発が変わる ! Google Cloud Platform 実践インフラ構築
• GCP に関する本を書きました( 共著 ) 。
• Aiming での BigQuery= データ分析基盤構築について
/42
内容・過去の分析環境からの変遷・ BigQuery による新分析環境・データ分析システムの比較・データ分析環境を作る・実際にログを収集する
・実際に集計、可視化する・収集したデータの活用とKPI
・ BigQuery のコスト・ SQL 実例あれこれ・データ分析環境を作ってみての変化・まとめ
/42
類書にない特徴• ゲーム分析で役立つ実際に近いテーブルスキーマを載せている。• プロデューサーを説得しやすいように、実際に近いコストを載せている ( 注、概算 )
• 実際に近い SQL が載っている (FQ5 とか DAU とか )
落ちて分かるBigQuery の落とし穴
/42
BigQuery 悩み所• テーブル構造やスキーマ構造• 時刻の表現• データロード• データ集計• バッドデータ• コスト
テーブルとスキーマ構造
/42
テーブル分割• アクションで分割
• action <- すべての行動を action とする• login,gacha, 等細かく分ける
• 日にちで分割• テーブルを日付で分割 or 日付で分けない
/42
テーブル増えすぎ問題• 1SQL 1000 テーブルまで• 1 テーブル増えるごとに 50ms 増える• GCP Next 2016 で Table Partitions 発表
/42
Table Partitions v1
/42
JSON vs カラム分割• すべてを JSON で入れる
• JSON_EXTRACT で値を取り出す• すべてをカラムに分ける
• データを挿入時に、予めカラムに分ける
スキーマレス カラム分割実現方法 JSON(STRING 型 ) インサート時分類性能 やや悪い 良いコスト 悪い 良いSQL 冗長 シンプル手軽さ お手軽 設計ありカラム追加 容易 やや不便カラム削除 容易 出来ない
/42
record 型使う？• Table に hash,Array を使うか？
• Aiming では使っていない• カード配列等は、 split(”1,2,3,4,5”,”,”)
/42
そのたハマりポイント• カラム名を、数字で始めると NG
• 1vs1 みたいなカラム名をつけると、テーブル作れない。
時刻
/42
timezone• UTC が基本• UTC として入れて、集計時に JST に直す• where date_add(time,9,’hour’) みたいな
date_add が頻発する
/42
時刻関連関数一々長い• STRFTIME_UTC_USEC とか• STRFTIME_UTC_USEC(UTC_USEC_TO_WEEK(d
ate_add(time,9,’hour’),1),”%Y-%m-%d”) <- 週単位の集計とか、人が書くことをあまり想定していない。• TD_TIME_FORMAT(time,”yyyy-MM-DD”,’JST’)のほうが、親切。
/42
Ruby time.to_s• bigquery の timezone 表現と合わない[INSERT されない ]
"2013-08-04 22:14:30 +0900”
[INSERT される ]
"2013-11-08T16:26:34+09:00"
Time.now.iso8601 を使おう
/42
テーブル区切りは JST• 中のデータは UTC, テーブルの区切りは JST で区切っているので混乱する
データロード
/42
ストリーミングインサート• flunetd -> flunet-bigquery-plugin -> bigquery
• 数万件に一件くらいの割合でレコードが欠ける。• ロードでは起こらない。
• 全部入らないか、全部入るかのどちらか。
/42
Aiming での推奨方法• テーブルは、日ごとに分割• 当日は、ストリーミングインサートを使い、次の日になったら、前日のテーブルは消して、ロード。
Login20160320ストリーミング
Login20160320ロードflunetd Login20160320
/42
この方法の利点• 当日は参考値として扱い、次の日に正確な値にする
• 当日はリアルタイムの値が見たい• サポートに使うのは翌日以降
/42
その他あるある• スキーマミスマッチ
• Hive boolean がある、 BigQuery boolean無い。 -> json で出して、 true が解釈できず、ロード出来ない。
データ集計
/42
SQLぽくない• COUNT(DISTINCT(user_id)) ->
EXACT_COUNT_DISTINCT(user_id)
• STRFTIME_UTC_USEC -> date_format
• UTC_USEC_TO_WEEK -> week
/42
window 関数告知不足• FQ5 とか一発で集計できるが、広報やサンプルが足りず、なかなか認知されない。
10年戦えるデータ分析入門 SQL を武器にデータ活用時代を生き抜く (青木峰郎 )p 188
select exact_count_distinct(user_id) as value,
STRFTIME_UTC_USEC(date,'%Y-%m-%d') as date
FROM (selectuser_id,date,
count(*) OVER (PARTITION BY user_id ORDER BY date RANGE BETWEEN 4 *24 *60 *60 *1000000 PRECEDING AND CURRENT ROW) as cnt
FROM ( select user_id,UTC_USEC_TO_DAY(date_add(time,9,'HOUR')) as date FROM table_date_range(production.login,timestamp('2015-01-01'),date_add(current_timestamp(),9,'HOUR'))GROUP BY user_id,date )) WHERE cnt=5 GROUP BY date;
バッドデータ
/42
バッドデータハンドブック• BigQuery は、テーブルやレコードの修正や削除が難しい。• どんなに対策を練っても実際に運用すれば、おかしなデータが入ってくることは避けられない。
/42
おかしなデータ• カラムの型が異なる (Integer のはずが String が来る )
• カラムの意味が違う。３番めの値と４番目の値を取り違う。
/42
期待値のコントロール• 会計処理の様な厳密なシステムは、別で組む• あくまで傾向値が分かる集計・分析ツールですと宣言。• ゴミデータが入ったら、諦めてもらう様に促す• 再集計しやすいアーキテクチャーにしておく
コスト
/42
cost control がいけてない
何故、問い合わせフォームベースなのか？developer console でも良くない？
https://support.google.com/cloud/contact/bigquery_custom_quota_request_form
/42
過去のコスト履歴が見たい• 今月のコストしか分からない• 前月のコストも分かるようにしてほしい
/42
BigQuery 悩み所まとめ• テーブル構造やスキーマ構造• 時刻の表現• データロード• データ集計• バッドデータ• コスト
/42
素晴らしいプロダクト• データがいくらでも入る• 集計レスポンスが速い• window 関数などが充実• BQ なしでデータ分析基盤を作ることは考えられない。
有難うございました
/42
質疑応答買って !!
来て !!@shibacow