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

グループごとのランキング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

グループごとのランキング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 アトミック洗い替え 洗い替えの変種

パターン１：差分更新

ターゲットテーブルソーステーブル

追加されたデータ

差分

insert into TARGET_TABLE select … from SOURCE_TABLE where data_date >= TODAY ;

パターン２：洗い替え作成

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;

パターン３：アトミック洗い替え

応用：アトミックな本番切り替え

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. あるていどオンライン処理にも耐えられるから