Amazon Redshiftによる リアルタイム分析サービスの構築 クックパッド株式会社 青木峰郎
Amazon Redshiftによる リアルタイム分析サービスの構築
クックパッド株式会社 青木峰郎
ユニークブラウザ数
0万
1,000万
2,000万
3,000万
4,000万
5,000万
2013/4 Q1 Q2 Q3 Q4 2014/4 Q1 Q2 Q3 Q4
PCスマホ(ブラウザ)スマホ(アプリ)フィーチャーフォンその他 4,404万UB
(2014年4月期 決算説明会資料より)
‣ 単語の検索頻度 ‣ 単語の組み合わせ頻度 ‣ 現在盛り上がっている単語
‣ ユーザーの年代や居住地域を軸とした分析
たべみる
Agenda1. たべみるのシステム構成
2. データ連携の詳細
3. SQLによるデータ処理
4. データ更新のパターン
たべみるのシステム構成(web)
app
Redshift ELBEC2
システム構成詳細‣ app: Rails 4 / Ruby 2.1
‣ db: Redshift (dw2.large × 12)
目標応答時間
500ms
応答速度向上の施策1 圧縮2 sortkey3 サマリーテーブル
※10ミリ秒単位でチューニングする場合、分散キー(distkey)はほぼ無関係
サマリーテーブルいつ作る?
安心と伝統の
夜間バッチ
Redshift
MySQL
Treasure Data (Hadoop)
夜間バッチ構成
検索ログ
ユーザーマスター
バッチ サーバー
単語マスター
file
file
file
生データ 中間データ サマリー
table
table
table
table
table
table
table
table
table
table
データ連携
信頼と実績の
TSV渡し
バッチ サーバー
TSV
ソースDB
テーブル
Redshift
テーブル
データ連携方式S3
TSVPUT COPYexport
‣ フォーマット変換 ‣ クレンジング ‣ SQLでできない処理
他の用途では fluentdによる継続ロードも
サマリーテーブル作成
SQLで加工 (ELT)
ELTのお約束1 エクスポート禁止 データ移動は遅い
DB外処理は非並列
2 UPDATE禁止 複数回実行しにくい VACUUMが厄介
3 1行INSERT禁止 COPYかINSERT SELECT
insert select だけ使え!!
SQLでは書けなかった処理1 日本語処理 半角→全角変換
2 可変数カラム タブ区切り文字列の分割
ようするに 文字列処理
SQLでも書ける!こんな処理‣ 単語の組み合わせ生成
‣ 未来の月曜日N週分の生成
‣ テーブルの縦横変換
‣ 移動平均、移動累積和
‣ グループごとのランキングトップN
ジョイン
ジョイン
ジョイン
ウィンドウ関数
ウィンドウ関数
テーブルの縦横変換log_time num word1 word2 word318:00:00 1 おじや18:03:42 2 大根 煮物18:19:01 1 ケーキ18:32:56 3 えび グラタン ▲マカロニ18:49:23 2 おじや たまご
log_time seq word18:00:00 1 おじや18:03:42 1 大根(同上) 2 煮物18:19:01 1 ケーキ18:32:56 1 えび(同上) 2 グラタン(同上) 3 ▲マカロニ18:49:23 1 おじや(同上) 2 たまご
「横持ち」テーブル 「縦持ち」テーブル
テーブルの縦横変換seq123456
transpose_matrix select log.log_time , m.seq , case m.seq when 1 then log.word1 when 2 then log.word2 when 3 then log.word3 when 4 then log.word4 when 5 then log.word5 when 6 then log.word6 end as word from search_log log inner join transpose_matrix m on log.num >= m.seq;
グループごとのランキングuser_category_id keyword search_count rank
20 サラダ 235,097 120 パスタ 190,413 220 もやし 187,999 330 なす 321,977 130 きゅうり 260,460 230 じゃがいも 217,201 340 大根 229,324 140 ささみ 201,876 240 チーズ 179,024 350 大根 139,141 150 いんげん 110,471 2
グループごとのランキングselect user_category_id, keyword, search_count, rank() over ( partition by user_category_id order by search_count desc )from user_category_search_count;
データ更新パターン
テーブル更新パターン1 差分更新 更新データのみ追加2 洗い替え 全行作り直し3 アトミック洗い替え 洗い替えの変種
パターン1:差分更新
ターゲットテーブルソーステーブル
追加されたデータ
差分
insert into TARGET_TABLE select … from SOURCE_TABLE where data_date >= TODAY ;
パターン2:洗い替え作成
drop table TARGET_TABLE; create table TARGET_TABLE (…); insert intoTARGET_TABLE select … from SOURCE_TABLE;
ターゲットテーブルソーステーブル
ターゲット テーブルソーステーブル 新規テーブル
作成 すり替え
create table t_NEW (…); insert into t_NEW select … from SOURCE_TABLE; begin transaction; alter table TARGET_TABLE rename to t_OLD; alter table t_NEW rename to TARGET_TABLE; commit;
パターン3:アトミック洗い替え
応用:アトミックな本番切り替え
targetsource new作成 すり替え
targetsource new
targetsource new
switch_the_world.sql
更新パターンの使い分け
生データ 中間データ サマリーtable
table
table
table
table
table
table
差分更新 洗い替え アトミック 洗い替え
まとめ
なぜRedshiftだったのか
1. COOKPADがAWSにあるから
2. マネージドサービスだから
3. 並列処理性能が高いから
4. ウィンドウ関数など高度な機能が実装されているから
5. あるていどオンライン処理にも耐えられるから