goodbyegangsterのブログ

備忘録的な

2019年のRedshift Updateをおさらいする

Redshiftの今を把握しようと調査したので、その備忘録です。下記の2019年のreinvent資料と、2020年2月に開催してくれたBlack Beltの資料を基に確認していきます。

ANT320-R - [REPEAT] What's new with Amazon Redshift, featuring Workday

AWS Black Belt Online Seminar Next Generation Redshift

まとめ

reinventの資料よりUpdateの一覧。

f:id:goodbyegangster:20200307170525p:plain

順々に見ていきます。

RA3 Node Type

コンピュート層とストレージ層が分離可能となったRedshift Cluster。

私たちはRedshiftに、処理能力とストレージをそれぞれ別々に最適化することができる新しいストレージ管理モデルで支えられている、Nitroベースの次世代コンピュートインスタンスをローンチします。このローンチは、ネットワークの広帯域化、Amazon Simple Storage Service (S3)を背後に持つSSDベースのローカルストレージを利用するマネージドストレージ、そしてS3との間で行き来するデータの動きを最適化するための複合的で高度なデータ管理技術といった、アーキテクチャの改良を利用しています。

Amazon Redshift の新機能 – 次世代コンピュートインスタンスと、マネージドで分析に最適化したストレージ

アーキテクチャ

f:id:goodbyegangster:20200307170838p:plain

リーダーノードはそのままで、クラスターノードにあたる部分が、大量SSDキャッシュを持ったコンピュート層と、実体S3であるストレージ層に分離しました。コンピュートノード1つあたり、64TBまでストレージ層を利用できるそうなので、現実的にストレージで困ることはなさそう。

制約

  • 利用可能ノードタイプ
    • RA3タイプでは、現在 ra3.16xlarge というかなり高性能ななモデルしか提供されておらず、オーバースペックになりそう
    • ra3.4xlarge という低スペックモデルがComming Soonらしい
  • コンピュート層のノード数
    • 最小2~最大128
    • ハイスペックモデルしかないのに、最小2からというのもつらい
  • 利用可能
    • 旧ノードタイプで利用していた下記機能も継続して利用可能
      • Concurrency Scaling
      • Redshift Spectrum

AQUA(Advanced Query Accelerator) for Redshift

プレビュー中。コンピュートノード層とストレージ層の間で、ハードウェア・アクセラレーション層を配置できる機能。

f:id:goodbyegangster:20200307170734p:plain

AQUA accelerates Redshift queries by running data intensive tasks such as filtering and aggregation closer to the storage layer. This avoids networking bandwidth limitations by eliminating unnecessary data movement between where data is stored and compute clusters.

フィルタリングや集計処理、暗号化や圧縮処理を実施してくれる。結果として、Redhist Network内で授受すべきデータ量も少なくなり、処理も高速になるよ、とのこと。

概要説明ページ

AZ64

新しい圧縮エンコード。データ圧縮率は同等or良くなっており、圧縮/解凍速度が向上されているらしいです。

今まで通り空テーブルへCOPY処理時に、適当と判断された場合は自動圧縮の仕組みにて AZ64 が自動的に適用されるとのこと。

Materialized View

プレビュー中。Redshiftでもマテリアライズド・ビューを利用できるようになりました。

Redshiftのマテリアライズド・ビュー機能(プレビュー)を試してみる

空間データのサポート

空間データ(地理データ)を扱う GEOMETRY データ型をサポートし、地理関係を分析できる関数を利用可能となった話。

GEOMETRY データ型で扱えるサブタイプ。

Amazon Redshift で空間データをクエリする

2つの距離間を返してくれる ST_DistanceSphere のような、様々な空間関数たち。

空間関数

Concurrency Scaling

リーダーノードをオートスケールする機能。Redshiftでは、同時実行クエリ数は15までが推奨という制限がありますが、本機能を利用することで、その制限を突破できるというもの。

制約

f:id:goodbyegangster:20200307170752p:plain

同時実行スケーリングの候補

設定方法

WLMのパラメーター画面にて設定できます。

f:id:goodbyegangster:20200307170806p:plain

PostgreSQL向けのFederated Query

プレビュー中。RDS PostgreSQLとAurora PostgreSQL向けに、フェデレーションクエリを実行できる機能。外部のポスグレ向けにExternal Schemaを作成することができ、SQLを実行できるというもの。

CREATE EXTERNAL SCHEMA

parquetフォーマットでのエクスポート

RedshiftのUnloadコマンドで、parquetファオーマットでのエクスポートが可能となったもの。

Spectrum Request Accelerator

Spectrum Request Accelerator が何であるのか分からなかったのですが、リリースノートを見ると、自動的に適用されているようです。

Amazon Redshift Spectrum: Spectrum Request Accelerator is automatically and transparently enabled, significantly improving the performance of queries against data in Amazon S3.

Versions 1.0.6145, 1.0.6230, 1.0.6246, 1.0.6431, 1.0.6476, 1.0.6754

おそらく、Spectrumの検索処理にもリザルトキャッシュが働くようなったものを指していると思っていますが。。。

AWS Lake Formation Integration

これは Lake Formation が出たよ、という話ですね。

Auto WLM

WorkLoad Managementの管理を、ある程度Redshift側に委ねられる機能。今まで手動で設定していたWLM内のキュー内の同時実行クエリ数の管理を、Redshift側がその時のクエリ実行状況を考慮して、最適な設定に変更してくれます。

自動 WLM の実装

自動WLMでは クエリ優先度 という概念があり、相対的なクエリの重要度を定義して、Redshift側の自動WLMの動作をコントールできます。一般的な最もオーソドックスな設計としては、以下のようなものでしょうか。

クエリ優先度

  • 毎晩実行されるETL処理は、可能な限りスケジュール通りに実行されるべきなので、クエリ優先度を high とする
    • ETL処理で利用されるDBユーザーグループを、 high としたキューに紐付ける
  • BIツールから参照される処理は、クエリ優先度を normal とする
    • BIツールで利用されるDBユーザーグループを、 normal としたキューに紐付ける

コンフィグ例。

[
  {
    "user_group": [
      "etl_users"
    ],
    "query_group": [],
    "auto_wlm": true,
    "queue_type": "auto",
    "priority": "high"
  },
  {
    "user_group": [
      "bi_readers"
    ],
    "query_group": [],
    "auto_wlm": true,
    "queue_type": "auto",
    "concurrency_scaling": "auto"
  },
  {
    "auto_wlm": true,
    "user_group": [],
    "query_group": []
  },
  {
    "short_query_queue": true
  }
]

Elastic Resize Scheduler

Elastic Resize とは、Redshiftのクラスターノード数の増減を数分で変更するという機能です。Clusterのメタデータを取得した後、バックグラウンドでデータの再分散を実施することで、旧来のノード数変更(Classic Resize)と比較して、圧倒的に早い処理を実行できるというもの。そのElastic Resizeを、Redshiftの標準機能でスケジュール管理できるようなりました。

以下、該当のコンソール画面。

f:id:goodbyegangster:20200307170822p:plain

Auto Vacuum & Auto Analyze & Auto Table Sort

Auto Vacuum(Vacuum Delete)とAuto Analyzeは、従来のPostgreSQLで持っている機能と同じ考え方。

Auto Table Sortは、自動的に Vacuum Sort Only を実行してくれるという機能。何らかの設定変更を必要とせず、sort keyを設定したテーブルに自動的に反映されます。

Amazon Redshift は、データをバックグラウンドで自動的にソートし、テーブルデータをソートキー順に維持します。Amazon Redshift は、スキャンクエリを追跡し、ソートするメリットのあるテーブルのセクションを判断します。

自動テーブルソート

ストアド・プロシージャ

PostgreSQLでサポートされている手続き型言語PL/pgSQL を、Redshiftでも利用可能となった話。

Amazon Redshift でのストアドプロシージャの作成

Distribution & Sort Key Advisor

まず、分散スタイルおよび分散キーを、動的に変更することが可能になりました。 ALTER TABLE 文の中で、変更するための句が用意されています。

マニュアルを確認すると、分散スタイルを変更できるパターンとしては、 ALL へ変更するパターンのみサポートされているようです。以下は公式サンプル。

Alter a table to DISTSTYLE ALL

分散キーを変更するサンプル。

Alter a DISTSTYLE KEY DISTKEY Column

また、ソートキーも動的に変更することが可能になりました。 ALTER TABLE 文の中で ALTER SORTKEY 句が用意されており、テーブルを作成後もソートキーを変更することができます。

ALTER TABLE

Advisorというのは Amazon Redshift Advisor のことで、Advisorが推奨する事項として、分散キーの設定内容やソートキーの設定内容を評価してくれるようなっています。

Amazon Redshift Advisor の推奨事項

分散キーに関しては、Redshiftが最適な分散キーを推奨してくれるようなっています。

Advisor は、クラスターのワークロードを分析して、キー分散スタイルから大きなメリットが得られるテーブルに最適な分散キーを識別します。

テーブルの分散キーを変更する

ソートキーに関しては、単一列でインターリーブソートキーを利用しているテーブルを発見してきます。

単一列インターリーブソートキーの置き換え

Cross-instance Restore

スナップショットからRedshift Clusterをリストアする際、オリジナルClusterとは異なるノードタイプ・サイズを選択できるようなっているそうです。

元のスナップショットから作成された新しいクラスターの場合、ノードタイプやノード数などの構成を選択できます。

スナップショットからのクラスターの復元

Auto Data Distribution

分散スタイルに AUTO を選択できるようになった話ですね。

AUTO 分散では、Amazon Redshift はテーブルデータのサイズに基づいて最適な分散スタイルを割り当てます。たとえば、Amazon Redshift ではまず、ALL 分散を小さなテーブルに割り当て、その後テーブルが大きくなると、EVEN 分散に変更します。テーブルが ALL から EVEN 分散に変更されると、ストレージの使用率がわずかに変わる場合があります。分散の変更は、数秒内にバックグラウンドで発生します。Amazon Redshift が分散スタイルを EVEN から ALL に変更することはありません。テーブルに適用された分散スタイルを表示するには、PG_CLASS_INFO システムカタログビューに対してクエリを実行します。

分散スタイル

メンテナンスの延期

メンテナンスの延期が選択できるようになっています。

クラスターのメンテナンスウィンドウを変更する必要がある場合、メンテナンスを最長 45 日まで遅延できます。たとえば、クラスターのメンテナンスウィンドウが水曜日の 8:30 ~ 9:00 (UTC) に設定されていて、その時間にクラスターにアクセスする必要がある場合、メンテナンスを後の時間に遅らせることができます。ハードウェアをアップデートする必要がある場合を除き、遅延を指定した場合は、クラスターのメンテナンスは一切行われません。

クラスターのメンテナンス