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

この記事は公開されてから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ファイルでロード出来るようにファイルを分割しておくとスループットを最大限発揮出来る。この辺りについては先日書いた以下のレポートでも言及されていました。
  • 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を行う。

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

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

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

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

最近出た機能について

新しい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の管理をより強固なものにしていきたいですね。以上、滞在先のサンフランシスコからのレポートでした。