ablog

不器用で落着きのない技術者のメモ

Amazon Redshift の redistribute と broadcast

Amazon Redshift の redistribute と broadcast の違いについてのメモ。

  • redistribute と broadcast(A copy of the entire table is broadcast to all the compute nodes) がある。

DS_DIST_OUTER
The outer table is redistributed.

DS_BCAST_INNER
A copy of the entire inner table is broadcast to all the compute nodes.

DS_DIST_ALL_INNER
The entire inner table is redistributed to a single slice because the outer table uses DISTSTYLE ALL.

DS_DIST_BOTH
Both tables are redistributed.

Evaluating the query plan - Amazon Redshift
  • broadcast はテーブル全体または行セットを全ノードに転送すること
  • distribute は行を他ノードに転送すること
Query plan operation Label field value Description
DS_BCAST_INNER BCAST (broadcast) Broadcasts an entire table or some set of rows (such as a filtered set of rows from a table) to all nodes.
DS_DIST_NONE
DS_DIST_ALL_NONE
DS_DIST_INNER
DS_DIST_ALL_INNER
DS_DIST_ALL_BOTH
DIST (distribute) Distributes rows to nodes for parallel joining purposes or other parallel processing.
クエリの概要へのクエリプランのマッピング - Amazon Redshift
  • 大きなファクトテーブルと小さいなディメンションテーブルを結合する際、ファクトテーブルの結合対象の行数分のディメンションテーブルレコードを転送するとファクトテーブルの結合対象行数の回数だけディメンションテーブルの対象行を転送すると効率が悪いため、ディメンションテーブル側の全行を転送する(broadcast)ということか。

ALL distribution replicates the entire table across all nodes. Each node holds a full copy of the table, eliminating data movement during query execution.

Use Case: This style is best suited for small, frequently accessed tables, such as lookup tables. Typical scenarios include:

  • > Small dimension tables joined with large fact tables.
  • > Queries requiring broadcast joins to avoid redistribution costs.
Understanding Amazon Redshift Distribution Styles and Internal Architecture
  • Merge join は結合キーが分散キーかつ結合キーの場合のみのため、distribute や broadcast は発生しないと考えられる。
  • Nested Loop
    • The least optimal join, a nested loop is used mainly for cross-joins (Cartesian products) and some inequality joins.
  • Hash Join and Hash
    • Typically faster than a nested loop join, a hash join and hash are used for inner joins and left and right outer joins. These operators are used when joining tables where the join columns are not both distribution keys and sort keys. The hash operator creates the hash table for the inner table in the join; the hash join operator reads the outer table, hashes the joining column, and finds matches in the inner hash table.
  • Merge Join
    • Typically the fastest join, a merge join is used for inner joins and outer joins. The merge join is not used for full joins. This operator is used when joining tables where the join columns are both distribution keys and sort keys, and when less than 20 percent of the joining tables are unsorted. It reads two sorted tables in order and finds the matching rows. To view the percent of unsorted rows, query the SVV_TABLE_INFO system table.
  • Spatial Join
    • Typically a fast join based on proximity of spatial data, used for GEOMETRY and GEOGRAPHY data types.
Creating and interpreting a query plan - Amazon Redshift

Redistribution of both tables

In my example database, all of the tables are distributed on userid. But what if they weren’t? In particular, what if they had the EVEN distribution style (which is Redshift’s default)? In that case, you’d see a query plan that looks like this:

XN Limit
   ->  XN HashAggregate
       ->  XN Hash Left Join DS_DIST_BOTH
           Outer Dist Key: atc.userid
           Inner Dist Key: cc.userid
           Hash Cond: (("outer".userid)::text = ("inner".userid)::text)
           ->  XN Seq Scan on add_to_cart atc
           ->  XN Hash
               ->  XN Seq Scan on checkout_complete cc

I have seen cases where both tables were redistributed because the query was based on an alternate — but valid — set of join columns. These tend to be extremely rare, but if you find that you’re frequently doing such joins, the best solution is to create a second copy of the tables, distributed on that alternate key.

Redshift の分散スタイルやソートキーの自動最適化履歴を確認する

Redshift の分散スタイルやソートキーの自動最適化履歴は SVL_AUTO_WORKER_ACTION で確認することができる。

select table_id, type, status, eventtime, sequence, previous_state
from SVL_AUTO_WORKER_ACTION;
 table_id |  type   |                        status                        |         eventtime          | sequence | previous_state
----------+---------+------------------------------------------------------+----------------------------+----------+----------------
   118082 | sortkey | Start                                                | 2020-08-22 19:42:20.727049 | 0        |
   118078 | sortkey | Start                                                | 2020-08-22 19:43:54.728819 | 0        |
   118082 | sortkey | Start                                                | 2020-08-22 19:42:52.690264 | 0        |
   118072 | sortkey | Start                                                | 2020-08-22 19:44:14.793572 | 0        |
   118082 | sortkey | Failed                                               | 2020-08-22 19:42:20.728917 | 0        |
   118078 | sortkey | Complete                                             | 2020-08-22 19:43:54.792705 | 0        | SORTKEY: None;
   118086 | sortkey | Complete                                             | 2020-08-22 19:42:00.72635  | 0        | SORTKEY: None;
   118082 | sortkey | Complete                                             | 2020-08-22 19:43:34.728144 | 0        | SORTKEY: None;
   118072 | sortkey | Skipped:Retry exceeds the maximum limit for a table. | 2020-08-22 19:44:46.706155 | 0        |
   118086 | sortkey | Start                                                | 2020-08-22 19:42:00.685255 | 0        |
   118082 | sortkey | Start                                                | 2020-08-22 19:43:34.69531  | 0        |
   118072 | sortkey | Start                                                | 2020-08-22 19:44:46.703331 | 0        |
   118082 | sortkey | Checkpoint: progress 14.755079%                      | 2020-08-22 19:42:52.692828 | 0        |
   118072 | sortkey | Failed                                               | 2020-08-22 19:44:14.796071 | 0        |  
   116723 | sortkey | Abort:This table is not AUTO.                        | 2020-10-28 05:12:58.479233 | 0        |
   110203 | distkey | Abort:This table is not AUTO.                        | 2020-10-28 05:45:54.67259  | 0        | 
SVL_AUTO_WORKER_ACTION - Amazon Redshift

SYS_LOAD_ERROR_DETAIL で他のユーザーが実行したロード処理も参照できるようにする

デフォルトだと一般ユーザーは SYS_LOAD_ERROR_DETAIL を参照すると、自分が実行したロード処理のエントリしか表示できない。
他のユーザーが実行したロード処理のエントリも参照したい場合は SYSLOG ACCESS UNRESTRICTED を付与すればよい。

デフォルトでは、ユーザーが表示可能なテーブルの大部分で、別のユーザーによって生成された行は、通常のユーザーには表示されません。通常のユーザーに SYSLOG ACCESS UNRESTRICTED を付与すると、ユーザーが表示できるテーブルのすべての行 (別のユーザーが生成した行を含む) を表示できます。

システムテーブルとビューのリファレンス - Amazon Redshift

自動VACUUM実行中に手動VACUUMを実行するとどうなるか

自動VACUUM実行中に手動VACUUMを実行すると、自動VACUUMが停止し、手動VACUUMが実行される。

Automatic vacuum operations pause if any of the following conditions are met:

  • A user runs a data definition language (DDL) operation, such as ALTER TABLE, that requires an exclusive lock on a table that automatic vacuum is currently working on.
  • A user triggers VACUUM on any table in the cluster (only one VACUUM can run at a time).
  • A period of high cluster load.
VACUUM - Amazon Redshift

CloudWatch メトリクスのデータポイントの粒度と参照可能期間

CloudWatch メトリクスのデータポイントの粒度と参照可能期間

メトリクスの保持
CloudWatch では、次のようにメトリクスデータを保持します。

  • 期間が 60 秒未満のデータポイントは、3 時間使用できます。これらのデータポイントは高解像度カスタムメトリクスです。
  • 期間が 60 秒 (1 分) のデータポイントは、15 日間使用できます。
  • 期間が 300 秒 (5 分) のデータポイントは、63 日間使用できます。
  • 期間が 3600 秒 (1 時間) のデータポイントは、455 日 (15 か月) 間使用できます。

最初は短い期間で発行されるデータポイントは、長期的なストレージのため一緒に集計されます。たとえば、1 分の期間でデータを収集する場合、データは 1 分の解像度で 15 日にわたり利用可能になります。15 日を過ぎてもこのデータはまだ利用できますが、集計され、5 分の解像度のみで取得可能になります。63 日を過ぎるとこのデータはさらに集計され、1 時間の解像度のみで利用できます。

Amazon CloudWatch の概念 - Amazon CloudWatch

Redshift でクラスターの一時停止・再開とパラメータグループの変更を許可する IAM ポリシー

Redshift でクラスターの一時停止・再開(特定のクラスターのみ)、パラメータグループ設定変更(特定の)を許可する IAM ポリシー

前提
  • マネジメントコンソールから人が操作する想定(AWS CLI など AWS API 経由で実行する場合も同じ)。
  • IAM ポリシー "ReadOnlyAccess"(AWS管理) が付与されている前提。
IAMロール・ポリシー設定
  • IAMロール名: redshift-cluster-reboot-modpg-role … 名前は任意
  • アタッチする IAM ポリシー
    • ReadOnlyAccess(AWS管理)
    • redshift-cluster-reboot-modpg-policy(カスタマー管理) … 名前は任意
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RebootCluster",
            "Effect": "Allow",
            "Action": [
                "redshift:RebootCluster",
                "redshift:PauseCluster",
                "redshift:ResumeCluster"
            ],
            "Resource": [
                "arn:aws:redshift:ap-northeast-1:123456789012:cluster:redshift-cluster-poc"
            ]
        },
        {
            "Sid": "ModifyClusterParameterGroup",
            "Effect": "Allow",
            "Action": [
                "redshift:ModifyClusterParameterGroup"
            ],
            "Resource": [
                "arn:aws:redshift:ap-northeast-1:123456789012:parametergroup:redshift-pg-poc"
            ]
        }
    ]
}

2025/4/17 追記:

  • AWS 管理ポリシー ReadOnlyAccess を付与しない場合は以下の IAM 権限を付与する。
		{
			"Sid": "DescribeClusterParameterGroups",
			"Effect": "Allow",
			"Action": [
				"redshift:DescribeClusterParameterGroups",
				"redshift:DescribeClusterParameters",
				"redshift:DescribeDefaultClusterParameters"
			],
			"Resource": "*"
		}

Redshift でユーザーの接続制限数(CONNECTION LIMIT)以上のコネクションを張ろうすると即時エラーになる

Redshift でユーザーの接続制限数以上のコネクションを張ろうとすると即時エラーになる。

検証結果

  • 3本接続を張った後、4本目の接続を張ろうとすると即時エラーとなる。
$ psql -A -h rs-ra3-4xl-4n.********.us-east-1.redshift.amazonaws.com -p 5439 -d dev -U testuser
Password for user testuser:
psql: error: connection to server at "rs-ra3-4xl-4n.********.us-east-1.redshift.amazonaws.com" (10.0.13.174), port 5439 failed: FATAL:  too many connections for user "testuser"

事前準備

  • Redshift に接続する。
$ psql -A -h rs-ra3-4xl-4n.********.us-east-1.redshift.amazonaws.com -p 5439 -d dev -U awsuser
  • ユーザーを作成する。
CREATE USER testuser password 'abcD1234' CONNECTION LIMIT 3;

参考

構文
CREATE USER name [ WITH ]
PASSWORD { 'password' | 'md5hash' | 'sha256hash' | DISABLE }
[ option [ ... ] ]

where option can be:

CREATEDB | NOCREATEDB
| CREATEUSER | NOCREATEUSER
| SYSLOG ACCESS { RESTRICTED | UNRESTRICTED }
| IN GROUP groupname [, ... ]
| VALID UNTIL 'abstime'
| CONNECTION LIMIT { limit | UNLIMITED }
| SESSION TIMEOUT limit
| EXTERNALID external_id

(中略)

CONNECTION LIMIT { limit | UNLIMITED }

ユーザーが同時に開けるデータベース接続の最大数。この制限はスーパーユーザーには適用されません。同時接続の最大数を許可するには、UNLIMITED キーワードを使用します。データベースごとの接続数の制限が適用される場合もあります。詳細については、「CREATE DATABASE」を参照してください。デフォルトは UNLIMITED です。現在の接続を確認するには、STV_SESSIONSシステムビューに対してクエリを実行します。

https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_CREATE_USER.html:tilte