(レポート) BDT401: Amazon Redshift Deep Dive – チューニングとベストプラクティス #reinvent

特集

しんや

2015.10.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS re:Invent 2015は全日程が終了し、日本からの参加者も帰国の途に着き、今頃は3連休の最終日、ゆっくり体を休めている頃でしょうか。私はと言うと、この後10/19〜23とTableau Conference 2015(こちらも開催地はラスベガス！)に参加するため、弊社代表兼AWSコミュニティヒーローのBOSSと米国サンフランシスコに滞在しております。(※この辺りの詳細についてはまたいずれ...)

さて、当レポートではAmazon Redshift Deep Diveのセッションをレポートして行きたいと思います。Amazon Redshiftも新機能が色々と追加されており、"最新版のベストプラクティス"も情報をアップデートして行かなければなりません。これまでの情報整理も兼ねてその内容についてレポートして行きたいと思います。

IMG_0482

当セッションについては既にスライド資料がSlideshareで公開されていたので共有します。

アーキテクチャレビュー

データの取り込み

  • COPYコマンドを使い、1スライス1ファイルでロード出来るようにファイルを分割しておくとスループットを最大限発揮出来る。この辺りについては先日書いた以下のレポートでも言及されていました。
  • (レポート) ISM303: エンタープライズデータウェアハウスのAmazon Redshiftへの移行 #reinvent ｜ Developers.IO
  • 100MBのファイル1個を8ノード(=16スライス)でアップロード→ファイルが1個であれば1つのスライスのみでアップロードを実施、100MB/sの回線を使っていたとした場合[100MB/s]÷[16スライス]=6.25MB/sしか出ない。
  • 指定のファイルを16個に分割しておく事で、8ノード16スライスでアップロードを行うため最大限のスループットが期待出来る。イメージは下記スライド資料の図を参照。

IMG_0492

Data Hygiene (データの衛生)

自動圧縮について

  • 自動圧縮しておく事は良いこと(大抵の場合)
  • より良いパフォーマンス、低コスト
  • 空テーブルへのCOPYを行う際はデータを自動的にサンプリングしている
  • 10万行以上の場合この挙動となり、最適なエンコーディングを探す
  • 一時テーブルまたはステージングテーブルを使うETLプロセスの場合、自動圧縮をOFFにしておく
  • 適切なエンコーディングを決めるために、ANALYZE COMPRESSIONを行う。
  • ANALYZE COMPRESSION - Amazon Redshift
  • 上記作業で得られたエンコーディング情報をDMLに反映。

ソートキーを圧縮する時は注意

  • ゾーンマップはブロック毎に最小値(min)/最大値(max)を格納する。
  • どのブロックがレンジを持っているかを確認後、スキャンする行のオフセットを把握。
  • 高圧縮されたソートキー＝ブロックあたりの行が多い、という事を意味する。このため、必要以上のデータブロックをスキャンする事になるでしょう。
  • もしソートキーがデータ列を大幅に圧縮する事になる場合、あなたはソートキー列の圧縮をスキップしたいと思うようになるでしょう。
  • この辺りの情報の詳細を確認する場合は下記テーブルのskew_sortkey1を参照。
  • SVV_TABLE_INFO - Amazon Redshift

可能な限りカラムの桁数は少なくしよう

  • 宣言したカラム桁数に基いてバッファが割り当てられる。
  • 必要なカラム数より大きい値を取るという事は、よりメモリが消費されるという事を意味する。
  • メモリに収まる行数：クエリが大きくなるとディスクに溢れる可能性(？)
  • この情報を確認する場合は、下記テーブルのmax_varcharを確認。
  • SVV_TABLE_INFO - Amazon Redshift

最近出た機能について

新しいSQL関数

ユーザー定義のスカラー関数(UDF)

Interleaved Sortkey

Compound Sort Keyの場合

  • Amazon Redshiftのレコードはブロックに格納されている。このイラストでは、4つのレコードがブロックを埋めていると仮定しよう。
  • cust_idを持つレコードは1つのブロックの中に同じ値のものが揃ってますが、
  • prod_idの部分についてはブロックを跨る形で配備されてしまっています。

redshift_compound_sortkey

Interleaved Sort Keyの場合

  • cust_idを持つレコードは2つのブロックの間に配備されています。
  • prod_idを持つレコードもまた、2つのブロックの間に配備されており、
  • データは双方のキーで等しくソートされます。

redshift_interleaved_sortkey

既存ワークロードの移行作業

TripAdviser社のAmazon Redshift事例共有

redshift-deep-dive_11

問題・課題

  • TripAdviser社のリソース共有の課題
  • 月間3億7500万のユニークユーザー
  • クラスタ：ds2.8xlarge 8ノード
  • 最も大きいテーブルは12TB(※1ヶ月のデータ)
  • 460人のエンジニア、データサイエンティスト、アナリスト、プロジェクトマネージャー、
  • テーブル数：2500以上
  • もしこれらを構築していなければ...
  • 会社のモットーは"Speed Wins"：解析に時間を掛けてはいられない
  • 2億9300万行のテーブルがINSERT文でインポートされる

インフラ自動化

  • Azkaban - バッチワークフロー＋UI(LinkedIn社)
  • Azkabanがデータ変換インフラ、SQL等を呼び出す。
  • 非エンジニア用のカスタムUI：選択・クリックするだけ。

監視

  • 監視(テーブル/パフォーマンス/使用率)
  • 時間の掛かっているクエリに対するアラート
  • 日次レポート：ピーク利用率／切り口はユーザー、アクティビティタイプ
  • 日次レポート：テーブルサイズ、テーブルスペース
  • psqlの互換性のおかげで、初期監視コストは最小減で済む。
  • 可視化にはTableauを使っている。

IMG_0566

キューの管理

  • シンプルに保ち、メモリを確保
  • ミッションクリティカル
  • DBA
  • Quick
  • デフォルトタイムアウトも含む
  • グループが許可するあなたに、直接キューをスイッチする事を
  • Tableauを活用

まとめ

さいごに

様々な切り口でのTipsが紹介されましたが、どれも非常にためになるものばかりでした。当セッションの内容を熟読しマスターしてAmazon Redshiftの管理をより強固なものにしていきたいですね。以上、滞在先のサンフランシスコからのレポートでした。

AWS

関連記事

AWS入門ブログリレー2024〜AWS CloudFormation編〜

平木佳介

2024.04.19

Amazon IVSリアルタイムストリーミング機能｜視聴までの処理を見てみよう！

坂齊史奈子

2024.04.19

Amplify Gen2のDataのモデル定義が分かりやすい

中村佳央

2024.04.19

VPCフローログの各種フィールドの意味をまとめてみた

和田響

2024.04.19