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の一覧。
順々に見ていきます。
RA3 Node Type
コンピュート層とストレージ層が分離可能となったRedshift Cluster。
私たちはRedshiftに、処理能力とストレージをそれぞれ別々に最適化することができる新しいストレージ管理モデルで支えられている、Nitroベースの次世代コンピュートインスタンスをローンチします。このローンチは、ネットワークの広帯域化、Amazon Simple Storage Service (S3)を背後に持つSSDベースのローカルストレージを利用するマネージドストレージ、そしてS3との間で行き来するデータの動きを最適化するための複合的で高度なデータ管理技術といった、アーキテクチャの改良を利用しています。
Amazon Redshift の新機能 – 次世代コンピュートインスタンスと、マネージドで分析に最適化したストレージ
アーキテクチャ
リーダーノードはそのままで、クラスターノードにあたる部分が、大量SSDキャッシュを持ったコンピュート層と、実体S3であるストレージ層に分離しました。コンピュートノード1つあたり、64TBまでストレージ層を利用できるそうなので、現実的にストレージで困ることはなさそう。
制約
- 利用可能ノードタイプ
- RA3タイプでは、現在
ra3.16xlargeというかなり高性能ななモデルしか提供されておらず、オーバースペックになりそう ra3.4xlargeという低スペックモデルがComming Soonらしい
- RA3タイプでは、現在
- コンピュート層のノード数
- 最小2～最大128
- ハイスペックモデルしかないのに、最小2からというのもつらい
- 利用可能
- 旧ノードタイプで利用していた下記機能も継続して利用可能
- Concurrency Scaling
- Redshift Spectrum
- 旧ノードタイプで利用していた下記機能も継続して利用可能
AQUA(Advanced Query Accelerator) for Redshift
プレビュー中。コンピュートノード層とストレージ層の間で、ハードウェア・アクセラレーション層を配置できる機能。
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 データ型で扱えるサブタイプ。
2つの距離間を返してくれる ST_DistanceSphere のような、様々な空間関数たち。
Concurrency Scaling
リーダーノードをオートスケールする機能。Redshiftでは、同時実行クエリ数は15までが推奨という制限がありますが、本機能を利用することで、その制限を突破できるというもの。
制約
設定方法
WLMのパラメーター画面にて設定できます。
PostgreSQL向けのFederated Query
プレビュー中。RDS PostgreSQLとAurora PostgreSQL向けに、フェデレーションクエリを実行できる機能。外部のポスグレ向けにExternal Schemaを作成することができ、SQLを実行できるというもの。
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では クエリ優先度 という概念があり、相対的なクエリの重要度を定義して、Redshift側の自動WLMの動作をコントールできます。一般的な最もオーソドックスな設計としては、以下のようなものでしょうか。
- 毎晩実行されるETL処理は、可能な限りスケジュール通りに実行されるべきなので、クエリ優先度を
highとする- ETL処理で利用されるDBユーザーグループを、
highとしたキューに紐付ける
- ETL処理で利用されるDBユーザーグループを、
- BIツールから参照される処理は、クエリ優先度を
normalとする- BIツールで利用されるDBユーザーグループを、
normalとしたキューに紐付ける
- BIツールで利用されるDBユーザーグループを、
コンフィグ例。
[ { "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の標準機能でスケジュール管理できるようなりました。
以下、該当のコンソール画面。
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 句が用意されており、テーブルを作成後もソートキーを変更することができます。
Advisorというのは Amazon Redshift Advisor のことで、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) に設定されていて、その時間にクラスターにアクセスする必要がある場合、メンテナンスを後の時間に遅らせることができます。ハードウェアをアップデートする必要がある場合を除き、遅延を指定した場合は、クラスターのメンテナンスは一切行われません。
