Redshift Spectrumを使ってみた話

(C) Recruit Technologies Co.,Ltd. All rights reserved.
Redshift Spectrumを使ってみた話
2017/05/18
株式会社リクルートテクノロジーズ
河野愛樹

BIG DATA Department本日お話すること
 自己紹介
 我々のサービスとその課題感
 Redshift Spectrumで課題を解決できるか
1

BIG DATA Department自己紹介
 河野愛樹(こうのよしき)
 株式会社リクルートテクノロジーズビッグデータ部
 事業会社へのBIソリューション提供とBI推進
2

我々のサービスとその課題感
3

BIG DATA Department
 事業が本来の業務に専念できるよう、すぐにデータを見れる・分析できる状態を提供
 インフラサービス
 BI製品・分析サーバを環境構築と運用管理をパッケージ化
 Cognos BI
 Tableau Server
 Jupyter Notebook + Python Libraries
 LDAP や OneLoginなどの認証機構
 主なデータソースにRedshift(事業次第)
 データ管理・データ連携支援
 ハコ(インフラ)だけあってもしょうがないので、
必要なデータを持ってきて使える状態にするところも支援
背景：マネージドBIソリューション
Tableau Server
+運用管理
4
Cognos BI
+運用管理
+運用管理
Analysis Server
LDAP

BIG DATA Department課題
 課題①：データ量に上限がある
 データをクラスタ内に持つ故の制約
 溜まり続けるデータに対して打てる手は「データを消す」「ノード数を増やす(上限有)」「クラスタ
を分ける」
 取った選択はノード数を増やす
• ただし、コストとのトレードオフ…
• 長時間に渡るリサイズの辛さ
 課題②：クエリ多重度が低い
 推奨15多重
• 上限もある、Max50多重
• 多くの人がよってたかって使うには不向き
• 実際、BIレポートの実行時間も10多重を超えると2倍以上遅くなっている
 取った選択はクラスタを分ける
• ロールごとに使い方やクエリの特性が違う
• 営業用、MP(企画)用、分析者用、etc
5

BIG DATA Department
 課題③：データ連携が辛くなる
 クラスタを分けたことによる弊害
 連携が増える(= 複雑になる) + 障害点が増える(障害時の影響範囲も広くなる)
 加えて、複数の環境でほぼ同じデータセットうことも
課題
事業DB
Hadoop
6

BIG DATA Department
 同一事業会社なのに部署ごとに環境が生まれる
 営業向け、MP(企画者)向け、データ分析エンジニア向け、経営向け…
 AWS費用が高コストに
 環境差分や運用の個別チューニングもあり、メンテナンスコストも増大
結果、こうなっている
事業DB
Hadoop
Tableau Server
Cognos BI
Jupyter Notebook
営業
MP
データ分析
エンジニア
全部同じ事業
会社だった！
なんてことも。
7

BIG DATA Department
つらい
8

BIG DATA Department
Source: AWS Summit San Francisco 2017: Keynote with Werner Vogels
https://www.youtube.com/watch?v=RpPf38L0HHU 9

Redshift Spectrumで
課題を解決できるか
10

BIG DATA Department
 S3に直接クエリする、ロード不要
 ストレージに容量上限無し
 CSVやParquetを直接扱える
 Athena の Data Catalogを利用
 Data Catalogにテーブル定義情報を登録
 RedshiftからはExternal Schema/Tableとして扱う
Redshift Spectrum
11
Publicスキーマ
Table
Table
Table
S3スキーマ
(External)
Table
S3ファイルパス
テーブル定義
Table
(External)
Data Catalog
External Schema
External
Table

BIG DATA Departmentアーキテクチャ比較：Redshift と Redshift Spectrum
 Redshift Spectrum Layer
(不可視領域)
Data
Catalog
L C
C
C
SQL
Pre-Load
L C
C
C
SQL
S3 Get
S
S
S
S
・
・
・
 Redshift Spectrum
12

BIG DATA Department検証・評価
 AWSの協力のもと、発表前にプロダクト評価を実施
 目的：Spectrumで我々の課題が解決できるか
 課題①：データ量上限
 課題②：クエリ多重度
 課題③：データ連携
 使ったデータセット
 TSV
 約6億行
 約50GB(非圧縮時、gzip圧縮で約25GB)
 既にRedshift内に保有済みデータをSpectrum用にS3出力
13

BIG DATA Department検証前の期待感
 Redshiftに抱いてた課題感を元にすると…
 データ量上限：ストレージの分離！上限なし！
 クエリ多重度：Spectrum Layerが何者か次第…
目的別に分けてたクラスタが統合できるかも？
 データ連携：ロード不要！バッチ作らなくていい！メンテも無くなる！
 その他：
• コスト：ストレージはS3だからRedshiftは処理リソース分の料金だけで済む！
そもそもノード数関係無くなるのか？(減らせれる？)
• 性能：S3へのIOだから圧倒的に遅くなりそう…
14

BIG DATA Department結果①：Small File かつ Multi Nodeは必須
 Big File vs Small File
 Single Node, TSV, Compress(gzip)
15
Big File
(6GB/file * 6files)
Small File
(600MB/file * 40files)
Redshift(参考値)
Full Scan (select *) 111 29 3
単位：秒
Spectrum Redshift(参考値)
1 node 20 nodes 20 nodes
Filter (select 4 columns,
3 filters)
30 18 3
Join (dimension x fact) 81 19 4
 Single Node vs Multi Node
 600MB/file, TSV, Compress(gzip)
単位：秒

BIG DATA Department結果②：多重度による劣化はクエリ特性による
16
Single Query 15 Parallel Query 30 Parallel Query
Spectrum Redshift Spectrum Redshift Spectrum Redshift
Full Scan (select *) 16 0.1 22 2 15 4
3 filters)
15 1 24 17 21 34
Join (dimension x fact) 19 3 65 50 131 109
 1多重 vs 15多重 vs 30多重 (※リリース後に追加検証)
 20 nodes, 600MB/file, TSV, Compress(gzip)
単位：秒(平均)

BIG DATA Department結果②-Full Scan：大きな性能劣化なし
 RedshiftとSpectrumとで平行線
 クラスタローカルディスクとS3との
IO速度の差がそのまま出ていると推察
 高多重度でのクエリ速度の大きな劣
化はない
 IO競合も気にならない程度
17
0
20
40
60
80
100
120
140
1パラ 15パラ 30パラ
クエリ時間(秒) クエリ多重度
Redshift - Full Scan Spectrum - Full Scan
select * from fact
■ Query←Fast

BIG DATA Department結果②-Filter：Spectrumが高多重度に強い
 Spectrumは大きな劣化は見られな
い
 Spectrum Layerの多大なリソース量
が頑張ってる
 Redshiftはリニアに遅くなる
 Compute Nodeの処理性能
18
0
20
40
60
80
100
120
140
Redshift - Fillter Spectrum - Filter
select key from fact
where
mode like 'REG%'
and tax = 1
and lo_discount = 0;
■ Query←Fast

BIG DATA Department結果②-Join：両者大きく性能劣化
 RedshiftとSpectrumとで平行線
 Full Scan同様
 クエリ性能はものすごく劣化
 Leader NodeがJOIN処理を担う
 Leader Nodeが処理のボトルネックに
19
0
20
40
60
80
100
120
140
Redshift - Join Spectrum - Join
select fact.price, fact.priority
from fact inner join dim
on fact.key = dim.key
where
dim.address = ’Tokyo'
■ Query←Fast

BIG DATA Department結果③：ParquetにするとRedshiftに迫る勢い
 TSV vs Parquet
 20 nodes, 600MB/file, Compress(gzip)
20
TSV Parquet Redshift(参考値)
3 filters)
18 6 6
Join (demension x fact) 19 12 9
単位：秒
 確かにParquet形式は早かった！がしかし…！
 既存データの多くはCSV/TSV
 わざわざParquetに変換してまで保持するか？
 AWS Glue(Managed ETL)との組み合わせに期待
• Parquet形式への自動変換

BIG DATA Departmentハマりどころ①
 Redshiftからアンロードした巨大なファイルだと遅い
 データ生成のためにRedshiftからUnload
 Redshiftの仕様として最大約6GBで自動分割
 Spectrumでクエリすると非常に遅かった
 Spectrumのチューニングポイント
 1ファイルを1GB以下にすること
 Redshiftからアンロードする場合はファイルサイズに注意(Unload後に分割すべし)
21
Source: Amazon Redshift Database Developer Guide
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c-spectrum-external-performance.html

BIG DATA DepartmentSpectrumをうまく使うには
 ファイル数は分割しておく
 数百MB単位を目安に
 Multi Node クラスタにする
 クエリ時間とコストのトレードオフ
 コストが許されるなら多いほうが早い
 Spectrum Layerで処理させる
 コンピュートノードでやってたことがオフロードされる
 Spectrumを使ってもLeader Nodeは1つなのでJOINは諦める
 カラムナフォーマット + 必要なカラムのみクエリする
 Parquet形式が推奨
 データの読み出し量の差も性能に効いている
22

BIG DATA Departmentまとめ：我々はSpectrumで幸せになれるか？
 課題①：データ量上限の苦しみ →幸せになれる！
 S3により上限解放
 長時間リサイズからの開放
 ストレージとしてかかってたコストからの開放
 課題②：クエリ多重度の苦しみ →多重度的には変わらないか良くなる(ただしIO性能分は遅
くなる)
 Leader NodeでのJOIN処理によるクエリ速度劣化は健在
 S3のI/Oが想定してたより早く、高多重度でもI/O性能があまり落ちない
 課題③：データ連携地獄の苦しみ →残念ながら未評価
 Redshiftへのロード処理が要らない分バッチ数は減る
 クエリ特性が似てるクラスタだと纏められる(減らせる)クラスタはあるかもしれない
 一方、データの書き込み(Insertなど)ができないのでデータマート作成は減らせれない
 Glueとの連携に期待！
23

Question?
24

Redshift Spectrumを使ってみた話

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Redshift Spectrumを使ってみた話

Similar to Redshift Spectrumを使ってみた話 (20)

Recently uploaded

Recently uploaded (10)

Redshift Spectrumを使ってみた話