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を使ってみた話

More Related Content

What's hot (20)

Viewers also liked (9)

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

Redshift Spectrumを使ってみた話