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スキーマ

TableTable

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 GetS

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←

Fa

st


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←

Fa

st


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←

Fa

st


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後に分割すべし)

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

Technology

Transcript of Redshift Spectrumを使ってみた話