クラウドデータウェアハウスの雄、Redshiftの2023年上半期最新動向をまとめてみました。
普段からRedshiftを触っていても、最新動向のキャッチアップは優先度が低くなりがちだと思いますので、本記事をお役立てください。
これまでの最新動向は以下にまとめておりますので、是非あわせてお読みください。
Redshift最新情報（2023/01/01~2023/06/16）
日本のリージョンに関連する情報を主にピックアップしています。
Redshift、GROUP BY 句でロールアップ、キューブ、グループ化セットの一般提供を発表 - 2023/02/28
- 多次元分析アプリケーションの構築を簡素化するために、GROUP BY 句の拡張であるROLLUP、CUBE、GROUPING SETSなどの新しい SQL 機能をサポートするようになった
- 分析用の複雑な集計ロジックを1つのSQLで書くのに便利
以下のサンプルデータで例を示します。
sql
=> \d orders
テーブル "orders"
列 | 型 | 修飾語
-----------+---------------+--------
id | integer |
product | character(20) |
category | character(20) |
cost | numeric(18,0) |
=> select * from orders;
id | product | category | cost
----+----------------------+----------------------+--------
0 | doraemon | robot | 100000
1 | Memory Bread | gadget | 15000
2 | doraemon | robot | 50000
3 | Memory Bread | gadget | 10000
4 | dorayaki | food | 50
(5 行)
GROUPING SETS
- GROUPING SETS は、単一の GROUP BY 句の集まりで、クエリの結果セットをグループ化できる 0 個以上の列のセット
sql
=> select category, product, sum(cost) as total
-> from orders
-> group by grouping sets(category, product);
category | product | total
----------------------+----------------------+--------
food | | 50
| dorayaki | 50
robot | | 150000
| Memory Bread | 25000
| doraemon | 150000
gadget | | 25000
(6 行)
ROLLUP
- 指定された列でデータをグループ化
- グループ化された行に加え、グループ化列の小計、総計も返す
sql
=> select category, product, sum(cost) as total
-> from orders
-> group by rollup(category, product) order by 1,2;
category | product | total
----------------------+----------------------+--------
food | dorayaki | 50
food | | 50
gadget | Memory Bread | 25000
gadget | | 25000
robot | doraemon | 150000
robot | | 150000
| | 175050
(7 行)
CUBE
- ROLLUPと同じ行を返すが、ROLLUPでは含まないグループ化列の組み合わせごとに小計も返す
sql
=> select category, product, sum(cost) as total
-> from orders
-> group by cube(category, product) order by 1,2;
category | product | total
----------------------+----------------------+--------
food | dorayaki | 50
food | | 50
gadget | Memory Bread | 25000
gadget | | 25000
robot | doraemon | 150000
robot | | 150000
| Memory Bread | 25000
| doraemon | 150000
| dorayaki | 50
| | 175050
(10 行)
参考:
Redshift が 20 万テーブルまでサポートを拡張 - 2023/03/08
- Redshift Serverless と、ノードタイプが ra3.4xlarge、ra3.16xlarge、dc2.8xlarge のデータウェアハウスクラスターについて、最大 20 万テーブルに対応
- 最大で 20 万テーブルを使用するワークロードでも、テーブルを分割したり移動したりせずに Amazon Redshift へ移行できる。
- これまで Redshift が上記のノードタイプでサポートしていたテーブル数は、単一のデータウェアハウスで 10 万だった。
- ユーザー定義のテンポラリテーブルと、Amazon Redshift がクエリ処理中やシステムメンテナンス中に作成したテンポラリテーブルも、この制限数に含まれる。ビューはこの制限数に含まれない。
2023/06/16時点でのテーブル数の上限は下記の通りです。
| ノードタイプ/Serverless | テーブル数上限値 |
|---|---|
large |
9,900 |
xlarge |
9,900 |
xlplus シングルノード |
9,900 |
xlplus マルチノード |
9,900 |
4xlarge |
200,000 |
8xlarge |
200,000 |
16xlarge |
200,000 |
| Serverless | 200,000 |
参考:
Redshift Serverless のデータウェアハウスの基本容量を下げる構成のお知らせ - 2023/03/09
- データウェアハウスの基本キャパシティを 8 RPU (Redshift プロセッシング単位: コンピューティング容量の単位) という低い構成で Redshift Serverless の使用を開始できるようになった
- 以前は、Redshift Serverlessを使用するために必要な最小基本容量は 32 RPU だった。基本容量が最低 8 RPUに引き下げられたことで、価格性能の要件に応じて、複雑さが小さいものから大きいものまで、さまざまなワークロードをより柔軟にサポートできるようになった。
- 新しい低容量構成では、Amazon Redshift Serverless を本番環境、テスト環境、開発環境に、ワークロードに必要なコンピューティング量が少ない場合に最適な価格帯で使用できる
参考記事の試算によると、32 RPUの場合と比較してかなり経済的になるようです。
32RPUの場合: 1422.72USドル/月（1日平均3時間利用）
8RPUの場合: 355.68USドル/月（1日平均3時間利用）
参考:
Redshift が動的データマスキングの一般提供を開始 - 2023/04/20
- 動的データマスキングを使用すると、SQL ベースのマスキングポリシーによって、データへのアクセスを制御可能。このポリシーは、クエリ時に Redshift が機密データをどのようにユーザーに返すかを決定する。
- テーブルにおける特定の列あるいは列のリストに対し、マスキングを適用できる。また、マスキングされたデータの表示方法も柔軟に選択可能（例えば、データに関するすべての情報を完全に隠したり、部分的な実際の値をワイルドカード文字に置き換えたりできる）。
- SQL 式、Python、Lambda のユーザー定義関数を用いて、データのマスキング方法を独自に定義することも可能
- 他の列に基づく条件付きのマスキングを適用すると、異なる列の値に基づいて、テーブルにおける列のデータを選択的に保護できる。
- テーブルにポリシーをアタッチした場合は、そのテーブルにおける 1 つまたは複数の列にマスキング式を適用できる。
-> 既存のセキュリティ機能を拡張し、Redshift データウェアハウス内にある機密データを保護するプロセスを簡略化できる。
マスキングポリシーは以下のように設定できるようです。
（ロールの作成部分など省略）
sql
-- 1 電話番号を全てマスキングするポリシー
CREATE MASKING POLICY Mask_CC_Full
WITH (phone VARCHAR(256))
USING ('XXX-XXX-XXXX');
-- 2 テキストより左から３桁のみを表示させる処理を行う定義関数を作成
CREATE FUNCTION REDACT_PHONE (text)
returns text
immutable
as $$
select left($1,4)||'XXX-XXXX'
$$ language sql;
-- 3 ２の定義関数を実行し、市外局番のみ表示させる部分マスキングを実現するポリシー
CREATE MASKING POLICY Mask_CC_Partial
WITH (phone VARCHAR(256))
USING (REDACT_PHONE(phone));
-- デフォルトのポリシーはフルマスキングポリシーに設定
-- より高い優先順位のマスキング・ポリシーがユーザーまたはそのロールに付加されていない限り、すべてのユーザーにこのマスキング・ポリシーが表示されます
ATTACH MASKING POLICY Mask_CC_Full
ON phone_number(phone)
TO PUBLIC;
-- cust_srvc_roleロールを持つユーザーは、一部の番号（市外局番のみ）を見ることができる
ATTACH MASKING POLICY Mask_CC_Partial
ON phone_number(phone)
TO ROLE cust_srvc_role
PRIORITY 10;
参考:
Redshift が MERGE SQL コマンドの一般提供を開始 - 2023/04/20
- シンプルな SQL コマンドでソースデータの変更を Redshift ウェアハウステーブルに適用できる
- MERGE コマンドを使用すると、一連の DML (データ操作言語) ステートメントを 1 つのステートメントにまとめることができる
- Redshift で他のデータウェアハウスシステムから移行している場合や、頻繁に変化するデータを Redshift ウェアハウスに取り込む必要がある場合、MERGE SQL コマンドで既存および新規のソースデータに基づいてターゲットテーブルから条件付き挿入、更新、削除を簡単に行える
以下が具体的な例です。
主キー列に重複する値がある場合、MERGE は重複する値を削除します。
例ではtarget_table に 101 の ID 値を持つ 2 つの異なる行があるが、名前の値は異なっており、MERGE 実行後、ID が 101 の行が 1 つだけ残ります。
sql
=> CREATE TABLE target (id INT, name CHAR(10), PRIMARY KEY(id));
CREATE TABLE
=> CREATE TABLE source (id INT, name CHAR(10));
CREATE TABLE
=> INSERT INTO target VALUES (101, 'Bob'), (101, 'John'), (102, 'Susan');
INSERT 0 3
=> INSERT INTO source VALUES (101, 'Tony'), (103, 'Alice');
INSERT 0 2
=> MERGE INTO target USING source ON target.id = source.id
WHEN MATCHED THEN UPDATE SET id = source.id, name = source.name
WHEN NOT MATCHED THEN INSERT VALUES (source.id, source.name);
INSERT 0 2
=> SELECT * FROM target;
id | name
-----+------------
101 | Tony
102 | Susan
103 | Alice
(3 rows)
参考:
Redshift が AWS Lake Formation を使用したデータ共有の一元的なアクセスコントロールに対応 - 2023/04/20
- 組織全体で共有されるデータに対するアクセス許可を AWS Lake Formation で一元管理できるようになった。
- Lake Formation マネージドデータ共有を使用すると、セキュリティ管理者は、Redshift データ共有で共有されているテーブルやビューに対してきめ細かなエンタイトルメント (テーブルレベル、列レベル、行レベルアクセスなど) を管理できる
-> Redshift データ共有のガバナンスが簡素化
参考記事の画像を見るとイメージがつきやすいです。
Lake FormationがHubとなり集中的にRedshift間のデータ共有のアクセス制御することで、Redshift 間をHub&Spork構成で実現することができる、ということのようです。
参考:
おわりに
2023年上半期のアップデートは、昨年の暮れにPreviewで公開されたもののGA開始が目立ちました。
総じて、Redshiftの利便性が向上されたものばかりです。
今後のアップデートも楽しみですね。