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

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

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

当セッションについては既にスライド資料が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スライスでアップロードを行うため最大限のスループットが期待出来る。イメージは下記スライド資料の図を参照。

Data Hygiene (データの衛生)

• 定期的なテーブルのANALYZE
• テーブルを分析する - Amazon Redshift
• ANALYZE - Amazon Redshift
• よく使うカラムについてはロード処理毎に／全てのカラムは毎週実施。
• 古くなった統計情報を見る場合：SVV_TABLE_INFO
• 不足している統計情報を見る場合：STL_ALERT_EVENT_LOG

• 定期的にVACUUM処理を実施

• VACUUM - Amazon Redshift
• 毎週行う程度がちょうどいい
• トリガーは『未ソートのブロックの数』
• 未ソート、空の情報を確認する場合：SVV_TABLE_INFO - Amazon Redshift
• ディープコピー(DEEP COPY)は未ソートな状態が高い場合に効果的。(20%の未ソート状態であれば、DeepCopyした方が速い)

自動圧縮について

• 自動圧縮しておく事は良いこと(大抵の場合)
• より良いパフォーマンス、低コスト
• 空テーブルへの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関数

• Amazon RedhiftのSQL関数、直近で25個程増えている模様。
• SQL 関数リファレンス - Amazon Redshift
• Amazon RedshiftのLISTAGGを使って集計内容をリスト化する ｜ Developers.IO

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

• Amazon Web Services ブログ: 【AWS発表】Amazon RedshiftにUDF(ユーザ定義関数)が追加されました
• Amazon Redshift: UDF(User-Defined Functions:ユーザー独自の定義関数)の作成方法 ｜ Developers.IO
• Amazon Redshift Scalar User-Defined Functions: A How-To
• Redshift User Defined Functions in Python

Interleaved Sortkey

• Amazon Web Services ブログ: 【AWS発表】Interleaved Sorting機能でAmazon Redshiftの効果的な検索フィルタリングが可能に
• 【新機能】Amazon Redshift の Interleaved Sorting機能を試してみた ｜ Developers.IO

Compound Sort Keyの場合

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

Interleaved Sort Keyの場合

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

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

• レガシーなデータウェアハウスの典型的なETL/ELT
• 1テーブル1ファイル
• 多くの更新が必要
• 多くのジョブがデータを削除→ロード
• 二重ロード防止のタメにPKの件数をカウント
• ジョブストリームをコントロールするための(小さい)テーブルを設けている
• 2つの"問い掛け"
• なぜあなたはそれをやるのか？：多くの場合、彼らは(それを行なう理由を)知らない。
• 顧客は何を必要としているのか？：多くの場合、現在のプラクティスにマッチしていないことがある。また、他のAWSサービスを使う事で代替出来る、効果を得られるかも。
• Amazon Redshiftでのワークロード管理
• Update は行のDELETE＋INSERT：DELETE作業は列に削除情報をマークするだけにしておく
• ブロックはImmutable(不変)：最小限のスペースが列毎、スライス毎に1つのブロックとして使われる
• コミットは高コスト
• クエリの同時実行はスループットを向上させるため、あまり行わない方が良い
• ダッシュボード用にキャッシュ(層)を活用するのはオススメな対応方法
• WLMはクエリに用いるRAMを制御・管理する。より良い活用を行なうためには複数のキューを用いる事。

• オススメのOpenSourceTool：awslabs/amazon-redshift-utils · GitHub

• Admin Srcipts
• Admin Views
• Column Encoding Utility
• Analyze and Vacuum Utility
• Unload and Copy Utility
• 関連エントリ
• Amazon Redshift便利ツール『amazon-redshift-utils』の便利SQLスクリプト紹介(AdminViews編) ｜ Developers.IO
• Amazon Redshift便利ツール『amazon-redshift-utils』の便利SQLスクリプト紹介(AdminScripts編) ｜ Developers.IO
• Amazon Redshift: テーブル列圧縮定義の診断・テーブル間データ移行ツール『Amazon Redshift Column Encoding Utility』 ｜ Developers.IO

TripAdviser社のAmazon Redshift事例共有

• TripAdvisor: Read Reviews, Compare Prices & Book

問題・課題

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

インフラ自動化

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

監視

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

キューの管理

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

まとめ

• Amazon RedshiftはTripAdviser社に於ける分析を変えてきた。
• 1日数千クエリ、数百人の利用者
• Amazon Redshiftの状況をTableauダッシュボードで可視化
• リアルタイム探索を素早く何百回と繰り返し
• 従業員のアクセスはOpenLDAPを使用
• これらのソリューションはオープンソース化する予定とのこと。
• 2016年の2月を予定
• 詳細はこちらを参照：TripAdvisor Engineering Blog | All the tech it takes to allow you to plan and book your perfect tripTripAdvisor Engineering Blog

さいごに

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