Tableau Conference 2016 at Austin [レポート]AWS RedshiftとTableauのベスト・プラクティス #data16

DI部の川崎です。オースティンから帰国して参りました。オースティン滞在時に、接戦の末に大統領が決まるというタイミングを経験し、思い出深い旅になりました。カンファレンスでは非常にたくさんのものを得ることができましたが、このセッションもその成果の一つです。

早速ですが、Tableau Conference 2016@Austinのセッション参加レポート：1本目はAWS RedshiftとTableauの組み合わせのベスト・プラクティスの紹介をしていきます。

セッションの紹介文は下記の通りです。

• Best Practices for Using AWS Redshift and Tableau - Learn | Tableau Conference 2016

アジェンダ

• パフォーマンスの基本
• ベスト・プラクティス
• ケーススタディ：ベスト・プラクティスを適用する
• その他のストラテジー
• Redshiftをモニターする

Jediレベルということで、特にケーススタディの項目は、進行が早すぎて理解が追いついておりませんので、後日詳細をお伝えできればと考えております。

資料

本セッションで使用したPPTスライド、Tableauワークブックは、下記サイトで公開されています。

https://github.com/russch/redshift-performance-info/releases

セッションビデオ

本セッションの録画版は、下記のサイトで公開されています。（※登録必要ですが無料で利用・アクセス可能）

http://tclive.tableau.com/Library/Video?vCode=BRK53638

パフォーマンスの基本

ソートキー

• ソートキーの順序に従い、データはディスク上に保持される
  • 結果を返す際に、不要な領域は、データブロック単位でスキップされる
  • ソートキーのタイプ：コンパウンド、インターリーブド
  • 直近の日付のデータを参照するクエリが多い場合、タイムスタンプ列をコンパウンドソートキーの第一カラムに指定する
• フィルタリング
  • WHERE句で条件に指定されるカラムは、ソートキーの候補である
  • Date型、Timestamp型のカラムも同様に候補である。特に、レンジ(範囲)条件の場合。
• JOIN
  • 頻繁にJOINで使われるカラムをソートキーに指定すると、JOINのパフォーマンスを上げることができる。
• AnalyzeとVacuum
  • よいパフォーマンスのために重要。忘れると痛い目に合う

分散スタイル／キー

• データは分散スタイル／キーに従い、各ノードに配置される
  • MPP（）で言うところのパラレル処理
  • Even/All/DIST KEYの3つ
• ファクト表
  • ノード間の等分配置をするために、カーディナリティの高いカラムを選択する。「スキュー」を避ける
  • JOINで使われている列は候補になる
• ディメンション表
  • データ分散の仕組み上、同じキーであれば、ファクト表でもディメンション表でも結果として同じノードに配置される
  • 「ALL」は小さめのディメンション表では好ましい
  • (JOINする)両方のテーブルが同一のソートキー、分散キーを持っている場合、マージジョインが選択され速い
• 分散キーは1つだけしか指定できない
  • 悲観することはない

インデックス

• (Redshiftにインデックスは、)ない

圧縮

• 圧縮を使おう
  • ストレージ領域をConserve
  • ストレージからの読み込みの際、IOを削減する
• COPY
  • Redshiftはインポートの際に、対象データを分析して、最適なエンコードタイプを適用する
• ANALYZE COMPRESSION
  • レコードが増加したテーブルに対して使用する
  • サイズやテーブルの性質が変わった後に使用する
• 例外
  • コンパウンドソートキーの第一カラムや、単一のソートキーでは不必要なデータブロックのスキャンを招くことがある

まとめ：これらをやる

• ソートキー
  • コンパウンドかインターリーブド
  • フィルターやJOINをカバーするカラムを選択する
• 分散キー
  • EVEN/ALL/DIST KEY
  • Skew(偏り)は悪、分散キーを賢く使う
  • JOINで使用されるカラムは、分散キーの候補
• 圧縮
  • まず使う
  • ソートキーを圧縮するのは避ける

ベスト・プラクティス

究極的には、

ベスト・プラクティスは、高い体感速度を実現させる

Tableuの体感速度に影響がある要因

• Redshiftのノードタイプ、ノード数(カネ)
• Redshiftのデータベースデザイン＆設定(専門知識、時間)
• Tableauダッシュボード・デザイン(専門知識、時間)
• 同時実行数(どれを選択するか)

ノードタイプ

• Dense Storage
  • サイズが大きいが、遅いディスク
  • 2TB(ds2.xlarge) or 16TB(ds2.8xlarge) - HDD
• Dense Compute
  • サイズが小さいが、速いディスク
  • 160GB(dc1.large) or 2.56TB(dc1.8xlarge) - SSD
• Dense Computeの方が価格が高い
  • でも、それがベスト(アマゾン)
  • 「DC1ノードタイプは、すべてのノートタイプの中でベストのパフォーマンスを提供する」

ノードサイズ、ノード数

• 小さめのノードで数を増やした構成からスタートし、スケールアウトする
  • ターゲットとするECU、vCPU、RAM、ストレージに対して、
  • 「多数の小さなノード」構成のインスタンスか、それとも「少数の大きなノード」構成か、選択する
• アーキテクチャ上の「スモール」と「ビッグ」の差異は、多くのケースで「スモール」に軍配が上がる
• 多数の「スモール」構成で、ストレージのデータサイズが足らなくなったとき、より大きなノードにスケールアップする

Redshiftチューニング

• WLMキュー
  • ワークロードに特化したクエリを並列で実行するキューを作成する
  • キューは、ユーザグループごとか、もしくはクエリグループごとに作成する
  • クエリの同時実行数は、キュー毎に設定する
  • それぞれのキューにRedshiftのメモリ割合を割り当てる
  • ベスト・プラクティス：キューを多く作り過ぎないこと
• Tableauのクエリをキューに割り当てる
  • データソース毎に割り当てる（クエリ毎、シート毎、ダッシュボード毎には割当できない）
  • ユーザグループ：Redshiftのクレデンシャル(認証情報)を活用する
• 余談: RAMの心配をする訳は？
  • • ディスクへあふれ出る＝IO増加＝（だいたい）パフォーマンスが悪化する
    • svl_query_summary を使って、下記のクエリをチェックする

  SELECT query,
  	    cast (workmem as decimal) / 1000000000 as "RAM, GB" , 
  	    rows,
  	    labels,
  	    is_diskbased
  	FROM
  	  svl_query_summary
  	WHERE query = 1665
  	ORDER BY
  	  workmem DESC

データベース・デザイン

• ソートキー追加、分散スタイル選択
  • さもなくば、pass go しない
  • Analyze / Vacuum
• 複雑なスキーマをフラットにする
  • 小さめのディメンション表をファクト表にマージする
  • 不要なJOINを避ける
  • 規模が大きくなった時には、集計表を検討する
• JOINするカラムでは、すべて値を入れ、NULLにならないようにする
  • さもなくばTableauが生成するクエリは、より複雑になる
• カラムを小さめに保つ
  • クエリを実行する際に、Redshiftは実際の値のサイズではなく、列の定義からメモリを割り当てる
  • 必要よりも大きなサイズの列は、RAMを無駄遣いし、メモリに読み込むことができる行数を少なくしてしまう
  • 結果：ディスクベースのクエリが増えてしまう
• クエリプランの読み方
  • クエリプランは、何にフォーカスすべきかの参考になる
  • 「EXPLAIN」コマンドを使うかマネージメントコンソールから参照する

クエリプラン

• Plan vs. Actual execution
• ボトムアップの方向から読む
  • 各レベルはオペレータと3つのメトリックスが表示されている
• オペレータ
  • Sequential Scan
  • Join (Nested Loop、Hash join/Hash 、Merge Join)
  • Aggregate (Aggregate, HashAggregate, GroupAggregate)
• メトリックス
  • Cost、Rows、Width
• Costは相対的な数値
  • 同時に、レベル毎に加算的
  • executionより上(つまり後)には、子要素のコストを含む

クエリプラン

SELECT
  cd_credit_rating,
  cd_education_status,
  SUM(ss_net_paid) 
FROM
    store_sales 
INNER JOIN 
    customer_demographics
        ON store_sales.ss_.cdemo_sk = customer_demographics.cd_demo_sk 
WHERE
 cd_marital_status = 'M'
 OR cd_marital_status = 'D' 
GROUP BY
 cd_credit_rating,
 cd_education_status

クエリプラン

• ソートキーを追加
• 同じプラン、でも速くなった

Actual Results

クエリプラン

• 分散キーを追加

まとめ：これらをやる

• Redshift
  • WLMキューを賢く使う
• データベース・デザイン
  • スキーマをフラットにする
  • 除去できるJOINを探す
  • 必要に応じて、集計する
• クエリプラン
  • (マネージメントコンソールの)Actual ResultのUIを探索的に使う
  • ボトムアップに見ていき、チューニング可能な点を探す
  • パフォーマンスのアラートと、skey(偏り)のヒントに注意する

Tableau チューニング

• ホワイトペーパー「Designing Effecient Workbooks」
  • Less is more (日付、ヴィジュアライゼーションの数、etc.)
  • フィルターをアグレッシブに使う
• 必要に応じて、集計を行う
  • 複数のデータソースに対して、それぞれのレベルで集計する
  • アクションフィルター、クロスデータベースフィルター、ナビゲーションを駆動する
• Tableau Serverのキャッシュ
  • 使う
  • refresh=yesのパラメータはキャッシュを無視するので、使わないように

Tableau チューニング

• （一時的に）カーソルを不使用にする
  • UseDeclareFetch=0
• １つのダッシュボード、複数のデータソース
  • 各データソースに別のクエリキューを指定
    • スモール / 速い クエリは同時実行数を大きめにし、メモリを少なめに設定する
    • ビッグ / 遅い クエリは同時実行数を小さめにし、メモリを多めに設定する
• LOD計算
  • LODは、INNER or CROSS JOINを使ったサブクエリによって実装されている
  • JOINで使われるカラムを最適化するために、ソートキー and/or 分散スタイルを利用する

Tableau チューニング

• 接続が遅い？
  • TableauがRedshiftに接続する際に、TEMPテーブルが作成される
  • RedshiftのCOMMITキューはシングルスレッド
  • 負荷が高い状況で、TEMPテーブル作成が遅くなることがあり、Tableauをブロックする
  • 一時テーブル作成の設定をカスタマイズすることを検討

CAP_CREATE_TEMP_TABLES, no

CAP_SELECT_INTO, no

同時接続数

• 分割できる数は限られている
  • Redshiftでは、同時実行クエリ数は、全体で最大50
  • AWSは、Redshiftクラスタ全体で、15以下を推奨
  • 初期キューのデフォルト値は5
• (Tableauの)パラレルクエリ：v9 vs. V10
  • v10にアップグレードして、劇的にパフォーマンスが改善してない？
  • v9では最高2、v10では最高8

ケーススタディ：ベスト・プラクティスを適用する

テストの実行には「TabJolt」を使用している、とのことです。また、検証にあたりTableau Server側のキャッシュはすべて無効にしている、キャッシュを有効にすれば、その分パフォーマンスは向上する、とのことでした。

その他のストラテジー

ご紹介したベスト・プラクティスの工程は、正直手間のかかるものになります。そんな時は「抽出」を使いましょう！

「抽出」に関するRedshift側の問題点

• カーソル
  • データの結果セット全体は、リーダーノードでマテリアライズされる（遅い）
  • 結果セットのクラスタ当たりのサイズ制限は、16GB‐14,000GB（ノード数、ノードタイプによる）
  • 最大カーソル数を越えてしまうと、他のカーソルもエラーになる
• カーソルなし
  • 全結果セットがTableauにストリーム転送される
  • Tableau側に大量のメモリが必要になる

「抽出」に関するTableau側の問題点

• やっていいこと
  • 「抽出」を集計する
  • 不要なフィールドを隠す
  • 「抽出」を時間でRollup（集約）する
• やってはいけないこと
  • アグリゲーション（集合）なしで、大量のローおよびカラムを返そうと試すこと

巨大な結果セットを抽出する別の方法

Redshiftをモニターする

Redshiftモニター in Tableau

• 抵抗を縮小する
  • キーメトリクスをひと目で見ることができる
• スポット・トレンド
  • ベースラインメトリクス、参考メトリクスを長期間
  • 全般の健全性、あるいはキュー毎のメトリクス
• オープンソース
  • Like it? Make it better!
  • Don't like it? Fork it!

https://github.com/russch/redshift-monitor/

最後に

以上、AWS RedshiftとTableauの組み合わせのベスト・プラクティスのセッションでした。ベンチマークの結果については、内容を鵜呑みにせず、自分たちの環境で検証していく必要がありますが、非常に参考になる内容だったと思います。冒頭にも書きましたが、Jediレベルということで、セッションの進行が早く、理解が追いついていない箇所がありますので、時間ができたらセッションビデオを見て、また復習をしてみたいと思っております。

われわれ日本人も、Redshift ＆ Tableau をガンガン使い倒していきましょう！