Amazon Redshift는 패치 198부터 새 Python UDF 생성을 더 이상 지원하지 않습니다. 기존 Python UDF는 2026년 6월 30일까지 계속 작동합니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요.
# CREATE TABLE AS
**Topics**
+ [구문](#r_CREATE_TABLE_AS-synopsis)
+ [파라미터](#r_CREATE_TABLE_AS-parameters)
+ [CTAS 사용 시 주의 사항](r_CTAS_usage_notes.md)
+ [CTAS 예](r_CTAS_examples.md)
쿼리를 기반으로 새 테이블을 만듭니다. 이 테이블의 소유자는 명령을 발행하는 사용자입니다.
명령에서 쿼리에 의해 정의된 데이터와 함께 새 테이블이 로드됩니다. 테이블 열의 이름과 데이터 형식은 쿼리의 출력 열과 연결되어 있습니다. CREATE TABLE AS(CTAS) 명령을 실행하면 새 테이블이 생성되고 새 테이블을 로드하는 쿼리가 평가됩니다.
## 구문
```
CREATE [ [ LOCAL ] { TEMPORARY | TEMP } ]
TABLE table_name
[ ( column_name [, ... ] ) ]
[ BACKUP { YES | NO } ]
[ table_attributes ]
AS query
where table_attributes are:
[ DISTSTYLE { AUTO | EVEN | ALL | KEY } ]
[ DISTKEY( distkey_identifier ) ]
[ [ COMPOUND | INTERLEAVED ] SORTKEY( column_name [, ...] ) ]
```
## 파라미터
LOCAL
이 선택적 키워드는 문에서 허용되지만, Amazon Redshift에는 아무런 효과도 없습니다.
TEMPORARY \$1 TEMP
임시 테이블을 만듭니다. 임시 테이블은 자신이 생성된 세션이 끝날 때 자동으로 삭제됩니다.
*table\$1name*
생성할 테이블의 이름입니다.
'\$1'으로 시작하는 테이블 이름을 지정하면 테이블이 임시 테이블로 생성됩니다. 예:
```
create table #newtable (id) as select * from oldtable;
```
최대 테이블 이름 길이는 127바이트이며, 이보다 긴 이름은 127바이트까지 표시되고 나머지는 잘립니다. Amazon Redshift는 노드 유형별로 클러스터당 테이블 수 할당량을 적용합니다. 다음 테이블에서 보듯이, 데이터베이스 및 스키마 이름으로 테이블 이름을 정규화할 수 있습니다.
```
create table tickit.public.test (c1) as select * from oldtable;
```
이 예에서는 `tickit`이 데이터베이스 이름이고, `public`이 스키마 이름입니다. 데이터베이스 또는 스키마가 존재하지 않는 경우 테이블이 생성되지 않으며, 이 명령문은 오류를 반환합니다.
스키마 이름이 주어지는 경우 새 테이블은 그 스키마에서 생성됩니다(생성자가 해당 스키마에 액세스할 수 있다고 가정). 테이블 이름은 그 스키마에 대한 고유한 이름이어야 합니다. 아무런 스키마도 지정되지 않으면 현재 데이터베이스 스키마를 사용하여 테이블이 생성됩니다. 임시 테이블을 생성할 경우, 임시 테이블이 특수한 스키마에 존재하므로 스키마 이름을 지정할 수 없습니다.
같은 이름을 가진 여러 임시 테이블이 각각 별도의 세션에서 생성되는 경우에는 같은 데이터베이스에 동시에 존재하도록 허용됩니다. 이러한 테이블은 서로 다른 스키마에 할당됩니다.
*column\$1name*
새 테이블에 있는 열의 이름입니다. 열 이름을 입력하지 않은 경우에는 쿼리의 출력 열 이름에서 열 이름을 따옵니다. 기본 열 이름은 표현식에 사용됩니다. 유효한 이름에 대한 자세한 내용은 [이름 및 식별자](r_names.md) 섹션을 참조하세요.
BACKUP \$1 YES \$1 NO \$1
자동 및 수동 클러스터 스냅샷에 테이블을 포함해야 할지 여부를 지정하는 절입니다.
중요한 데이터를 포함하지 않는 스테이징 테이블과 같은 테이블의 경우 BACKUP NO를 지정하여 스냅샷을 생성하고 스냅샷으로부터 복원할 때의 처리 시간을 절약하고 Amazon Simple Storage Service의 스토리지 공간을 줄입니다. BACKUP NO 설정은 클러스터 내에 있는 다른 노드로의 데이터 자동 복제에 아무런 영향도 미치지 않으므로, 노드 장애가 발생할 경우 BACKUP NO가 지정된 테이블이 복원됩니다. 기본값은 BACKUP YES입니다.
RA3 프로비저닝된 클러스터 및 Amazon Redshift Serverless 작업 그룹에는 백업 없음 테이블이 지원되지 않습니다. RA3 클러스터 또는 서버리스 작업 그룹에서 백업 없음으로 표시된 테이블은 스냅샷을 생성하는 동안 항상 백업되고 스냅샷에서 복원할 때 항상 복원되는 영구 테이블로 처리됩니다. 백업이 없는 테이블의 스냅샷 비용을 방지하려면 스냅샷을 생성하기 전에 자릅니다.
DISTSTYLE \$1 AUTO \$1 EVEN \$1 KEY \$1 ALL \$1
전체 테이블의 데이터 배포 스타일을 정의하는 키워드입니다. Amazon Redshift는 테이블에 대해 지정된 배포 스타일에 따라 컴퓨팅 노드에 테이블의 행을 배포합니다. 기본값은 DISTSTYLE AUTO입니다.
테이블에 대해 선택하는 분산 스타일이 데이터베이스의 전체 성능에 영향을 미칩니다. 자세한 내용은 [쿼리 최적화를 위한 데이터 배포](t_Distributing_data.md) 섹션을 참조하세요.
+ AUTO: Amazon Redshift에서 테이블 데이터를 기반으로 최적의 배포 스타일을 할당합니다. 테이블에 적용된 분산 스타일을 보려면 PG\$1CLASS 시스템 카탈로그 테이블을 쿼리합니다. 자세한 내용은 [분산 스타일 보기](viewing-distribution-styles.md) 섹션을 참조하세요.
+ EVEN: 테이블의 데이터가 클러스터의 노드들에 걸쳐 라운드 로빈 배포 방식으로 균등하게 분포됩니다. 행 ID는 배포의 결정에 사용되며, 대략적으로 같은 수의 행이 각 노드로 배포됩니다. 이것이 기본 배포 방법입니다.
+ KEY: 데이터가 DISTKEY 열에 있는 값을 기준으로 배포됩니다. 조인 테이블의 조인 열을 배포 키로 설정하면 두 테이블 모두의 조인 행이 컴퓨팅 노드에 배치됩니다. 데이터가 배치되면 최적화 프로그램이 조인을 더 효율적으로 수행할 수 있습니다. DISTSTYLE KEY를 지정하는 경우 DISTKEY 열의 이름을 지정해야 합니다.
+ ALL: 전체 테이블의 복사본이 모든 노드로 배포됩니다. 이 분산 스타일은 임의의 조인에 필요한 모든 행을 모든 노드에서 사용할 수 있도록 보장하지만, 스토리지 요구량이 몇 배로 늘고 테이블의 로드 시간과 유지 관리 시간도 증가합니다. ALL 배포는 KEY 배포가 적절하지 않은 특정 차원 테이블과 함께 사용할 때 실행 시간을 개선할 수 있지만, 성능 개선 정도를 유지 관리 비용과 비교 검토해야 합니다.
DISTKEY (*column*)
배포 키에 대해 열 이름이나 위치 번호를 지정합니다. 테이블에 대한 선택적 열 목록 또는 쿼리의 선택 목록 중 하나에 지정된 이름을 사용합니다. 또는 첫 번째로 선택한 열이 1, 두 번째로 선택한 열이 2 등과 같이 이어지는 경우에는 위치 번호를 사용합니다. 테이블에서는 한 개의 열만 배포 키일 수 있습니다.
+ 어떤 열을 DISTKEY 열로 선언하는 경우 DISTSTYLE이 KEY로 설정되거나 전혀 설정되지 않아야 합니다.
+ 열을 DISTKEY 열로 선언하지 않은 경우 DISTSTYLE을 EVEN으로 설정할 수 있습니다.
+ DISTKEY 또는 DISTSTYLE을 지정하지 않으면 CTAS가 SELECT 절의 쿼리 계획을 기반으로 새 테이블의 분산 스타일을 결정합니다. 자세한 내용은 [열 및 테이블 속성의 상속](r_CTAS_usage_notes.md#r_CTAS_usage_notes-inheritance-of-column-and-table-attributes) 섹션을 참조하세요.
배포 키 및 정렬 키와 동일한 열을 정의할 수 있습니다. 이 접근 방식은 문제가 되는 열이 쿼리에서 조인 열일 때 조인을 가속화하는 경향이 있습니다.
[ COMPOUND \$1 INTERLEAVED ] SORTKEY ( *column\$1name* [, ... ] )
테이블에 대해 하나 이상의 정렬 키를 지정합니다. 데이터가 테이블로 로드될 때 데이터는 정렬 키로 지정되는 열을 기준으로 정렬됩니다.
COMPOUND 또는 INTERLEAVED 정렬 스타일을 선택적으로 지정할 수 있습니다. 기본 키워드는 COMPOUND입니다. 자세한 내용은 [정렬 키](t_Sorting_data.md) 섹션을 참조하세요.
테이블당 최대 400개의 COMPOUND SORTKEY 열 또는 8개의 INTERLEAVED SORTKEY 열을 정의할 수 있습니다.
SORTKEY를 지정하지 않으면 CTAS가 SELECT 절의 쿼리 계획을 기반으로 새 테이블의 정렬 키를 결정합니다. 자세한 내용은 [열 및 테이블 속성의 상속](r_CTAS_usage_notes.md#r_CTAS_usage_notes-inheritance-of-column-and-table-attributes) 섹션을 참조하세요.
COMPOUND
목록에 표시되는 모든 열로 구성된 복합 키를 사용하여 데이터가 나열되는 순서대로 정렬됨을 지정합니다. 복합 정렬 키는 쿼리가 정렬 열의 순서에 따라 행을 스캔할 때 가장 유용합니다. 쿼리가 보조 정렬 열에 의존할 때는 복합 키로 정렬함으로써 얻는 성능상의 이점이 감소합니다. 테이블당 최대 400개의 COMPOUND SORTKEY 열을 정의할 수 있습니다.
INTERLEAVED
데이터가 인터리브 정렬 키를 사용하여 정렬됨을 지정합니다. 인터리브 정렬 키에 대해 최대 8개의 열을 지정할 수 있습니다.
인터리브 정렬에서는 정렬 키에서 각 열이나 열의 하위 집합에 똑같은 가중치를 부여하므로, 쿼리가 정렬 키에 있는 열의 순서에 종속되지 않습니다. 쿼리가 하나 이상의 보조 정렬 열을 사용하는 경우 인터리브 정렬은 쿼리 성능을 크게 높여줍니다. 인터리브 정렬에는 데이터 로드와 vacuum 작업에 약간의 오버헤드 비용이 수반됩니다.
AS *query*
Amazon Redshift가 지원하는 쿼리(SELECT 문)입니다.
# CTAS 사용 시 주의 사항
## 한도
Amazon Redshift는 노드 유형별로 클러스터당 테이블 수 할당량을 적용합니다.
테이블 이름으로 입력할 수 있는 최대 문자 수는 127자입니다.
단일 테이블에서 정의할 수 있는 최대 열 수는 1,600개입니다.
## 열 및 테이블 속성의 상속
CREATE TABLE AS(CTAS) 테이블은 자신이 생성된 테이블로부터 제약 조건, 자격 증명 열, 기본 열 값 또는 기본 키를 상속하지 않습니다.
CTAS 테이블에 대한 열 압축 인코딩을 지정할 수 없습니다. Amazon Redshift가 다음과 같이 압축 인코딩을 자동으로 할당합니다.
+ 정렬 키로 정의된 열은 RAW 압축이 할당됩니다.
+ BOOLEAN, REAL, DOUBLE PRECISION, GEOMETRY 또는 GEOGRAPHY 데이터 유형으로 정의된 열은 RAW 압축이 할당됩니다.
+ SMALLINT, INTEGER, BIGINT, DECIMAL, DATE, TIME, TIMETZ, TIMESTAMP 또는 TIMESTAMPTZ로 정의된 열에는 AZ64 압축이 할당됩니다.
+ CHAR, VARCHAR 또는 VARBYTE로 정의된 열에는 LZO 압축이 할당됩니다.
자세한 내용은 [압축 인코딩](c_Compression_encodings.md) 및 [데이터 타입](c_Supported_data_types.md) 섹션을 참조하세요.
열 인코딩을 명시적으로 할당하려면 [CREATE TABLE](r_CREATE_TABLE_NEW.md)을 사용하세요.
CTAS가 SELECT 절의 쿼리 계획을 기반으로 새 테이블의 분산 스타일과 정렬 키를 결정합니다.
조인, 집계, order by 절 또는 limit 절을 포함하는 쿼리와 같은 복잡한 쿼리인 경우, CTAS는 쿼리 계획을 기반으로 최적의 분산 스타일과 정렬 키를 선택하기 위해 최대한 시도합니다.
**참고**
큰 데이터 집합 또는 복잡한 쿼리로 최상의 성능을 얻으려면 일반적인 데이터 집합을 사용하여 테스트하는 것이 좋습니다.
쿼리 최적화 프로그램이 데이터 정렬과 배포를 위해 선택하는 열이 있을 경우 어떤 열을 선택할지 살펴보는 쿼리 계획을 검사함으로써 CTAS가 선택할 배포 키와 정렬 키를 예측할 수 있는 경우가 종종 있습니다. 쿼리 계획의 최상위 노드가 단일 테이블(XN Seq Scan)의 간단한 순차적 스캔인 경우에는 CTAS가 일반적으로 원본 테이블의 분산 스타일과 정렬 키를 사용합니다. 쿼리 계획의 최상위 노드가 다른 순차적 스캔(예: XN Limit, XN Sort, XN HashAggregate 등)인 경우, CTAS는 쿼리 계획을 기반으로 최적의 분산 스타일과 정렬 키를 선택하기 위해 최대한 시도합니다.
예를 들어, 다음 유형의 SELECT 절을 사용하여 5개의 테이블을 만든다고 가정해봅시다.
+ 간단한 select 문
+ limit 절
+ LISTID를 사용하는 order by 절
+ QTYSOLD를 사용하는 order by 절
+ group by 절을 사용하는 SUM 집계 함수
다음 예에서는 각 CTAS 문에 대한 쿼리 계획을 보여 줍니다.
```
explain create table sales1_simple as select listid, dateid, qtysold from sales;
QUERY PLAN
----------------------------------------------------------------
XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(1 row)
explain create table sales2_limit as select listid, dateid, qtysold from sales limit 100;
QUERY PLAN
----------------------------------------------------------------------
XN Limit (cost=0.00..1.00 rows=100 width=8)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(2 rows)
explain create table sales3_orderbylistid as select listid, dateid, qtysold from sales order by listid;
QUERY PLAN
------------------------------------------------------------------------
XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8)
Sort Key: listid
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(3 rows)
explain create table sales4_orderbyqty as select listid, dateid, qtysold from sales order by qtysold;
QUERY PLAN
------------------------------------------------------------------------
XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8)
Sort Key: qtysold
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(3 rows)
explain create table sales5_groupby as select listid, dateid, sum(qtysold) from sales group by listid, dateid;
QUERY PLAN
----------------------------------------------------------------------
XN HashAggregate (cost=3017.98..3226.75 rows=83509 width=8)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(2 rows)
```
각 테이블에 대한 배포 키와 정렬 키를 보려면 다음에 표시된 것처럼 PG\$1TABLE\$1DEF 시스템 카탈로그 테이블을 쿼리합니다.
```
select * from pg_table_def where tablename like 'sales%';
tablename | column | distkey | sortkey
----------------------+------------+---------+---------
sales | salesid | f | 0
sales | listid | t | 0
sales | sellerid | f | 0
sales | buyerid | f | 0
sales | eventid | f | 0
sales | dateid | f | 1
sales | qtysold | f | 0
sales | pricepaid | f | 0
sales | commission | f | 0
sales | saletime | f | 0
sales1_simple | listid | t | 0
sales1_simple | dateid | f | 1
sales1_simple | qtysold | f | 0
sales2_limit | listid | f | 0
sales2_limit | dateid | f | 0
sales2_limit | qtysold | f | 0
sales3_orderbylistid | listid | t | 1
sales3_orderbylistid | dateid | f | 0
sales3_orderbylistid | qtysold | f | 0
sales4_orderbyqty | listid | t | 0
sales4_orderbyqty | dateid | f | 0
sales4_orderbyqty | qtysold | f | 1
sales5_groupby | listid | f | 0
sales5_groupby | dateid | f | 0
sales5_groupby | sum | f | 0
```
다음 표에 결과가 요약되어 있습니다. 단순성을 기하기 위해 설명 계획에서 비용, 행 및 너비 세부 정보는 생략합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/redshift/latest/dg/r_CTAS_usage_notes.html)
CTAS 문에서 분산 스타일과 정렬 키를 명시적으로 지정할 수 있습니다. 예를 들어, 다음 문은 EVEN 분산을 사용하여 테이블을 생성하고 SALESID를 정렬 키로 지정합니다.
```
create table sales_disteven
diststyle even
sortkey (salesid)
as
select eventid, venueid, dateid, eventname
from event;
```
## 압축 인코딩
ENCODE AUTO는 테이블의 기본값으로 사용됩니다. Amazon Redshift는 테이블의 모든 열에 대한 압축 인코딩을 자동으로 관리하지 않습니다.
## 수신 데이터의 배포
수신 데이터의 해시 배포 구성표가 대상 테이블의 해시 배포 구성표와 일치하는 경우, 데이터 로드 시 데이터를 물리적으로 배포할 필요는 실제로 없습니다. 예를 들어, 새 테이블에 대해 배포 키가 설정되고 같은 키 열에 배포된 다른 테이블에서 데이터가 삽입되고 있는 경우, 같은 노드와 조각을 사용하여 데이터가 적절히 로드됩니다. 하지만 원본 테이블과 대상 테이블이 모두 EVEN 배포로 설정되어 있는 경우 데이터는 대상 테이블로 다시 배포됩니다.
## 자동 ANALYZE 작업
Amazon Redshift는 CTAS 명령으로 생성하는 테이블을 자동으로 분석합니다. 이 테이블들이 처음 생성될 때는 테이블에서 ANALYZE 명령을 실행할 필요가 없습니다. 테이블을 수정하는 경우, 다른 테이블과 같은 방법으로 분석해야 합니다.
# CTAS 예
다음 예에서는 EVENT 테이블에 대해 EVENT\$1BACKUP이라는 테이블을 생성합니다.
```
create table event_backup as select * from event;
```
결과 테이블은 EVENT 테이블에서 배포 키와 정렬 키를 상속합니다.
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'event_backup';
column | type | encoding | distkey | sortkey
----------+-----------------------------+----------+---------+--------
catid | smallint | none | false | 0
dateid | smallint | none | false | 1
eventid | integer | none | true | 0
eventname | character varying(200) | none | false | 0
starttime | timestamp without time zone | none | false | 0
venueid | smallint | none | false | 0
```
다음 명령은 EVENT 테이블에서 4개의 열을 선택하여 EVENTDISTSORT라는 새 테이블을 생성합니다. 새 테이블은 EVENTID를 기준으로 배포되고 EVENTID 및 DATEID를 기준으로 정렬됩니다.
```
create table eventdistsort
distkey (1)
sortkey (1,3)
as
select eventid, venueid, dateid, eventname
from event;
```
결과는 다음과 같습니다.
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'eventdistsort';
column | type | encoding | distkey | sortkey
---------+------------------------+----------+---------+-------
eventid | integer | none | t | 1
venueid | smallint | none | f | 0
dateid | smallint | none | f | 2
eventname | character varying(200)| none | f | 0
```
배포 키 및 정렬 키에 대한 열 이름을 사용하여 같은 테이블을 정확하게 생성할 수 있습니다. 예:
```
create table eventdistsort1
distkey (eventid)
sortkey (eventid, dateid)
as
select eventid, venueid, dateid, eventname
from event;
```
다음 문은 테이블에 균등 배포를 적용하지만 명시적인 정렬 키를 정의하지 않습니다.
```
create table eventdisteven
diststyle even
as
select eventid, venueid, dateid, eventname
from event;
```
새 테이블에 대해 EVEN 배포가 지정되어 있으므로 테이블이 EVENT 테이블(EVENTID)에서 정렬 키를 상속하지 않습니다. 새 테이블에는 정렬 키와 배포 키가 없습니다.
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'eventdisteven';
column | type | encoding | distkey | sortkey
----------+------------------------+----------+---------+---------
eventid | integer | none | f | 0
venueid | smallint | none | f | 0
dateid | smallint | none | f | 0
eventname | character varying(200) | none | f | 0
```
다음 문은 균등 배포를 적용하고 정렬 키를 정의합니다.
```
create table eventdistevensort diststyle even sortkey (venueid)
as select eventid, venueid, dateid, eventname from event;
```
결과 테이블에 정렬 키는 있지만 배포 키는 없습니다.
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'eventdistevensort';
column | type | encoding | distkey | sortkey
----------+------------------------+----------+---------+-------
eventid | integer | none | f | 0
venueid | smallint | none | f | 1
dateid | smallint | none | f | 0
eventname | character varying(200) | none | f | 0
```
다음 문은 EVENTID 열에 정렬되어 있는 수신 데이터에서 다른 키 열에 EVENT 테이블을 다시 배포하고 SORTKEY 열은 정의하지 않으므로, 테이블이 정렬되지 않습니다.
```
create table venuedistevent distkey(venueid)
as select * from event;
```
결과는 다음과 같습니다.
```
select "column", type, encoding, distkey, sortkey
from pg_table_def where tablename = 'venuedistevent';
column | type | encoding | distkey | sortkey
----------+-----------------------------+----------+---------+-------
eventid | integer | none | f | 0
venueid | smallint | none | t | 0
catid | smallint | none | f | 0
dateid | smallint | none | f | 0
eventname | character varying(200) | none | f | 0
starttime | timestamp without time zone | none | f | 0
```