아마존 레드 시프트 수만 명의 고객이 분석 워크로드를 지원하기 위해 사용하는 빠른 페타바이트 규모의 클라우드 데이터 웨어하우스입니다. 수천 명의 고객이 Amazon Redshift 읽기 데이터 공유를 사용하여 Redshift 프로비저닝된 클러스터와 서버리스 작업 그룹 전반에 걸쳐 즉각적이고 세부적이며 빠른 데이터 액세스를 지원합니다. 이를 통해 데이터를 이동하거나 복사할 필요 없이 읽기 워크로드를 수천 명의 동시 사용자로 확장할 수 있습니다.

이제 Amazon Redshift에서는 공개 미리 보기에서 데이터 공유를 통한 다중 데이터 웨어하우스 쓰기를 발표합니다. 이를 통해 워크로드 요구 사항에 따라 다양한 유형과 크기의 다양한 웨어하우스를 사용하여 ETL(추출, 변환 및 로드) 워크로드에 대해 더 나은 성능을 얻을 수 있습니다. 또한 이를 통해 몇 번의 클릭만으로 ETL 작업을 웨어하우스 간에 분할하고, 각 웨어하우스에 자체 모니터링 및 비용 제어 기능이 있으므로 비용을 모니터링 및 제어하고, 다양한 팀을 지원하여 협업을 촉진할 수 있으므로 ETL 작업을 더욱 예측 가능하게 실행할 수 있습니다. 단 몇 번의 클릭만으로 다른 팀의 데이터베이스에 쓸 수 있습니다.

데이터는 교차 계정 또는 교차 지역에 기록되는 경우에도 커밋되는 즉시 모든 웨어하우스에서 실시간으로 사용 가능합니다. 미리보기의 경우 ra3.4xl 클러스터, ra3.16xl 클러스터 또는 서버리스 작업 그룹의 조합을 사용할 수 있습니다.

이 게시물에서는 동일한 데이터베이스에 쓰기 위해 여러 웨어하우스를 사용해야 하는 경우에 대해 논의하고, 데이터 공유를 통해 다중 웨어하우스 쓰기가 어떻게 작동하는지 설명하고, 여러 웨어하우스를 사용하여 동일한 데이터베이스에 쓰는 방법에 대한 예를 안내합니다.

동일한 데이터베이스에 쓰기 위해 여러 웨어하우스를 사용하는 이유

이 섹션에서는 동일한 데이터베이스에 쓰기 위해 여러 웨어하우스를 사용하는 것을 고려해야 하는 몇 가지 이유에 대해 설명합니다.

혼합 워크로드에 대한 더 나은 성능과 예측 가능성

고객은 초기 워크로드 요구 사항에 맞는 크기의 창고로 시작하는 경우가 많습니다. 예를 들어, 가끔 사용자 쿼리를 지원하고 야간에 천만 행의 구매 데이터를 수집해야 하는 경우 10 RPU 작업 그룹이 귀하의 요구 사항에 완벽하게 적합할 수 있습니다. 그러나 32억 행의 사용자 웹 사이트 및 앱 상호 작용을 시간당 새로 수집하면 새 워크로드가 상당한 리소스를 소비하므로 기존 사용자의 응답 시간이 느려질 수 있습니다. 더 큰 작업 그룹으로 크기를 조정할 수 있으므로 리소스를 놓고 다투지 않고도 읽기 및 쓰기 작업이 빠르게 완료됩니다. 그러나 이는 기존 워크로드에 불필요한 전력과 비용을 제공할 수 있습니다. 또한 워크로드는 컴퓨팅을 공유하므로 한 워크로드가 급증하면 다른 워크로드가 SLA를 충족하는 능력에 영향을 미칠 수 있습니다.

다음 다이어그램은 단일 웨어하우스 아키텍처를 보여줍니다.

데이터 공유를 통해 작성하는 기능을 사용하면 이제 새로운 사용자 웹 사이트 및 앱 상호 작용 ETL을 별도의 대규모 작업 그룹으로 분리하여 기존 워크로드의 비용이나 완료 시간에 영향을 주지 않고 필요한 성능으로 신속하게 완료할 수 있습니다. 다음 다이어그램은 이 다중 웨어하우스 아키텍처를 보여줍니다.

다중 웨어하우스 아키텍처를 사용하면 모든 워크로드를 지원하는 단일 웨어하우스보다 더 적은 양의 컴퓨팅을 사용하여 모든 쓰기 워크로드를 적시에 완료할 수 있으므로 결과적으로 비용이 절감됩니다.

비용 제어 및 모니터링

모든 ETL 작업에 단일 웨어하우스를 사용하는 경우 어떤 워크로드가 비용에 영향을 미치는지 이해하기 어려울 수 있습니다. 예를 들어 ETL 워크로드를 실행하는 한 팀은 CRM 시스템에서 데이터를 수집하고 다른 팀은 내부 운영 시스템에서 데이터를 수집할 수 있습니다. 웨어하우스에서 동일한 컴퓨팅을 사용하여 쿼리가 함께 실행되기 때문에 워크로드 비용을 모니터링하고 제어하기가 어렵습니다. 쓰기 워크로드를 별도의 웨어하우스로 분할하면 리소스 충돌 없이 워크로드가 독립적으로 진행될 수 있도록 하면서 비용을 별도로 모니터링하고 제어할 수 있습니다.

라이브 데이터에서 쉽게 협업하세요

두 팀이 데이터 거버넌스, 컴퓨팅 성능 또는 비용상의 이유로 서로 다른 웨어하우스를 사용하지만 때로는 동일한 공유 데이터에 써야 하는 경우도 있습니다. 예를 들어, 고객이 마케팅, 영업, 고객 서비스 팀과 상호 작용할 때 실시간으로 업데이트해야 하는 일련의 고객 360 테이블이 있을 수 있습니다. 이러한 팀이 서로 다른 웨어하우스를 사용하는 경우 다음과 같은 도구를 사용하여 다중 서비스 ETL 파이프라인을 구축해야 할 수 있으므로 이 데이터를 실시간으로 유지하는 것이 어려울 수 있습니다. 아마존 단순 스토리지 서비스 (아마존 S3), 아마존 단순 알림 서비스 (아마존 SNS), 아마존 단순 대기열 서비스 (아마존 SQS), AWS 람다 각 팀 데이터의 실시간 변경 사항을 추적하고 이를 단일 소스로 수집합니다.

데이터 공유를 통해 쓰기 기능을 사용하면 몇 번의 클릭만으로 여러 웨어하우스를 사용하는 여러 팀에 데이터베이스 개체에 대한 세분화된 권한(예: 한 테이블의 SELECT, 다른 테이블의 SELECT, INSERT, TRUNCATE)을 부여할 수 있습니다. 이를 통해 팀은 자체 웨어하우스를 사용하여 공유 객체에 쓰기를 시작할 수 있습니다. 데이터는 커밋되는 즉시 모든 웨어하우스에 실시간으로 제공되며 웨어하우스가 다른 계정과 지역을 사용하는 경우에도 작동합니다.

다음 섹션에서는 여러 웨어하우스를 사용하여 데이터 공유를 통해 동일한 데이터베이스에 쓰는 방법을 안내합니다.

솔루션 개요

이 솔루션에서는 다음 용어를 사용합니다.

• 네임 스페이스 – 데이터베이스 개체, 사용자 및 역할, 데이터베이스 개체에 대한 권한, 컴퓨팅(서버리스 작업 그룹 및 프로비저닝된 클러스터)에 대한 논리적 컨테이너입니다.
• 데이터 공유 – 데이터 공유를 위한 공유 단위입니다. 데이터 공유에 객체에 대한 권한을 부여합니다.
• 생산자 – 데이터 공유를 생성하고, 데이터 공유에 개체에 대한 권한을 부여하고, 다른 웨어하우스 및 계정에 데이터 공유에 대한 액세스 권한을 부여하는 웨어하우스입니다.
• 소비자 – 데이터 공유에 대한 액세스 권한이 부여된 웨어하우스입니다. 소비자를 데이터 공유 테넌트로 생각할 수 있습니다.

이 사용 사례에는 두 개의 웨어하우스, 즉 대부분의 읽기 및 쓰기 쿼리를 위해 기본 네임스페이스에 연결하는 데 사용되는 기본 웨어하우스와 기본 네임스페이스에 쓰는 데 주로 사용되는 보조 네임스페이스에 연결된 보조 웨어하우스가 있는 고객이 포함됩니다. 우리는 공개적으로 사용 가능한 10GB TPCH 데이터 세트 S3 버킷에서 호스팅되는 AWS Labs에서 제공됩니다. 따라할 많은 명령을 복사하여 붙여넣을 수 있습니다. 데이터 웨어하우스로서는 작지만 이 데이터세트를 사용하면 이 기능을 쉽게 기능적으로 테스트할 수 있습니다.

다음 다이어그램은 솔루션 아키텍처를 보여줍니다.

우리는 창고를 통해 연결하여 기본 네임스페이스를 설정하고 그 안에 마케팅 데이터베이스를 생성합니다. prod 과 staging 스키마에 세 개의 테이블을 생성하고 prod 호출된 스키마 region, nation및 af_customer. 그런 다음 데이터를 region 과 nation 창고를 활용한 테이블. 우리는 데이터를 수집하지 않습니다. af_customer 테이블.

그런 다음 기본 네임스페이스에 데이터 공유를 생성합니다. 우리는 데이터 공유에 객체를 생성할 수 있는 권한을 부여합니다. staging 스키마 및 개체에서 선택, 삽입, 업데이트 및 삭제하는 기능 prod 개요. 그런 다음 계정의 다른 네임스페이스에 스키마 사용 권한을 부여합니다.

이 시점에서 보조 창고에 연결됩니다. 해당 웨어하우스의 데이터 공유와 새 사용자로부터 데이터베이스를 생성합니다. 그런 다음 새 사용자에게 데이터 공유 개체에 대한 권한을 부여합니다. 그런 다음 새 사용자로 보조 창고에 다시 연결합니다.

그런 다음 데이터 공유에 고객 테이블을 만듭니다. staging 스키마를 생성하고 TPCH 10 고객 데이터세트의 데이터를 스테이징 테이블에 복사합니다. 스테이징 고객 테이블 데이터를 공유 테이블에 삽입합니다. af_customer 프로덕션 테이블을 삭제한 다음 테이블을 자릅니다.

이 시점에서 ETL이 완료되고 기본 웨어하우스와 보조 ETL 웨어하우스 모두에서 보조 ETL 웨어하우스에 의해 삽입된 기본 네임스페이스의 데이터를 읽을 수 있습니다.

사전 조건

이 게시물을 따라 하려면 다음 전제 조건이 있어야 합니다.

• 두 개의 창고가 만들어졌습니다. PREVIEW_2023 길. 웨어하우스는 서버리스 작업 그룹, ra3.4xl 클러스터 및 ra3.16xl 클러스터가 혼합되어 있을 수 있습니다.
• 에 액세스 수퍼 유저 두 창고 모두에 있습니다.
• An AWS 자격 증명 및 액세스 관리 (IAM) Amazon Redshift에서 Amazon S3로 데이터를 수집할 수 있는 역할입니다(Amazon Redshift는 클러스터 또는 서버리스 작업 그룹을 생성할 때 기본적으로 생성됩니다).
• 교차 계정의 경우에만 데이터 공유를 승인할 수 있는 IAM 사용자 또는 역할에 액세스해야 합니다. IAM 정책은 다음을 참조하세요. 데이터 공유 공유.

인용하다 AWS 계정 내에서 또는 계정 간에 읽기 및 쓰기 데이터 공유(미리 보기) 최신 정보를 확인하십시오.

기본 네임스페이스(생산자) 설정

이 섹션에서는 데이터를 저장하는 데 사용할 기본(생산자) 네임스페이스를 설정하는 방법을 보여줍니다.

생산자에 연결

생산자에 연결하려면 다음 단계를 완료하세요.

1. Amazon Redshift 콘솔에서 다음을 선택합니다. 쿼리 편집기 v2 탐색 창에서
   

쿼리 편집기 v2에서는 왼쪽 창에서 액세스할 수 있는 모든 창고를 볼 수 있습니다. 확장하여 데이터베이스를 볼 수 있습니다.

2. 수퍼유저를 사용하여 기본 창고에 연결합니다.
3. 다음 명령을 실행하여 생성합니다. marketing 데이터 베이스:

CREATE DATABASE marketing;

공유할 데이터베이스 개체 만들기

공유할 데이터베이스 객체를 생성하려면 다음 단계를 완료하세요.

1. 생성 후 marketing 데이터베이스, 데이터베이스 연결을 다음으로 전환하십시오. marketing 데이터 베이스.

페이지를 보려면 페이지를 새로 고쳐야 할 수도 있습니다.

2. 공유하려는 두 개의 스키마를 생성하려면 다음 명령을 실행하십시오.

CREATE SCHEMA staging;
CREATE SCHEMA prod;

3. 다음 코드로 공유할 테이블을 만듭니다. 이는 테이블 이름이 수정된 AWS Labs DDL 파일에서 나오는 표준 DDL 문입니다.

create table prod.region (
  r_regionkey int4 not null,
  r_name char(25) not null ,
  r_comment varchar(152) not null,
  Primary Key(R_REGIONKEY)
);

create table prod.nation (
  n_nationkey int4 not null,
  n_name char(25) not null ,
  n_regionkey int4 not null,
  n_comment varchar(152) not null,
  Primary Key(N_NATIONKEY)
);

create table prod.af_customer (
  c_custkey int8 not null ,
  c_name varchar(25) not null,
  c_address varchar(40) not null,
  c_nationkey int4 not null,
  c_phone char(15) not null,
  c_acctbal numeric(12,2) not null,
  c_mktsegment char(10) not null,
  c_comment varchar(117) not null,
  Primary Key(C_CUSTKEY)
) distkey(c_custkey) sortkey(c_custkey);

데이터를 region 과 nation 테이블

다음 명령을 실행하여 AWS Labs S3 버킷의 데이터를 region 과 nation 테이블. 기본 생성된 IAM 역할을 유지하면서 클러스터를 생성한 경우 다음 명령을 복사하여 붙여넣어 테이블에 데이터를 로드할 수 있습니다.

copy prod.nation from 's3://redshift-downloads/TPC-H/2.18/10GB/nation.tbl' iam_role default delimiter '|' region 'us-east-1';
copy prod.region from 's3://redshift-downloads/TPC-H/2.18/10GB/region.tbl' iam_role default delimiter '|' region 'us-east-1';

데이터 공유 만들기

다음 명령을 사용하여 데이터 공유를 만듭니다.

create datashare marketing publicaccessible true;

XNUMXD덴탈의 publicaccessible 설정은 공개적으로 액세스 가능한 프로비저닝된 클러스터 및 서버리스 작업 그룹이 있는 소비자가 데이터 공유를 사용할 수 있는지 여부를 지정합니다. 창고에 공개적으로 접근할 수 없는 경우 해당 필드를 무시할 수 있습니다.

데이터 공유에 스키마에 대한 권한 부여

데이터 공유에 권한이 있는 객체를 추가하려면 권한 부여 구문을 사용하여 권한을 부여할 데이터 공유를 지정하세요.

grant usage on schema prod to datashare marketing;
grant usage, create on schema staging to datashare marketing;

이를 통해 데이터 공유 소비자는 prod 스키마에 추가된 객체를 사용하고 생성합니다. staging 개요. 이전 버전과의 호환성을 유지하려면 alter datashare 스키마를 추가하는 명령은 스키마에 대한 사용 권한을 부여하는 것과 동일합니다.

데이터 공유에 테이블에 대한 권한 부여

이제 권한 및 데이터 공유를 지정하는 권한 부여 구문을 사용하여 데이터 공유에 테이블에 대한 액세스 권한을 부여할 수 있습니다. 다음 코드는 다음에 대한 모든 권한을 부여합니다. af_customer 데이터 공유에 대한 테이블:

grant all on table prod.af_customer to datashare marketing;

이전 버전과의 호환성을 유지하기 위해 alter datashare 명령을 사용하여 테이블을 추가하는 것은 테이블에 대한 선택 권한을 부여하는 것과 같습니다.

또한 데이터 공유 내의 모든 현재 및 미래 개체에 동일한 권한을 부여할 수 있는 범위가 지정된 권한을 추가했습니다. 범위가 지정된 선택 권한을 추가합니다. 찌르다 데이터 공유에 대한 스키마 테이블:

grant select for tables in schema prod to datashare marketing;

이 부여 후 고객은 prod 스키마의 모든 현재 및 미래 테이블에 대한 선택 권한을 갖게 됩니다. 이를 통해 해당 사용자는 다음에서 액세스를 선택할 수 있습니다. region 과 nation 테이블.

데이터 공유에 부여된 권한 보기

다음 명령을 실행하면 데이터 공유에 부여된 권한을 볼 수 있습니다.

show access for datashare marketing;

보조 ETL 네임스페이스에 권한 부여

기존 구문을 사용하여 보조 ETL 네임스페이스에 권한을 부여할 수 있습니다. 네임스페이스 ID를 지정하면 됩니다. 보조 ETL 네임스페이스가 서버리스인 경우 네임스페이스 세부 정보 페이지에서, 보조 ETL 네임스페이스가 프로비저닝된 경우 클러스터 세부 정보 페이지에서 네임스페이스 ID의 일부로, 또는 쿼리 편집기 v2에서 보조 ETL 웨어하우스에 연결하여 네임스페이스를 찾을 수 있습니다. 그리고 달리는 중 select current_namespace. 그런 다음 다음 명령을 사용하여 다른 네임스페이스에 대한 액세스 권한을 부여할 수 있습니다(소비자 네임스페이스를 자체 보조 ETL 웨어하우스의 네임스페이스 UID로 변경).

grant usage on datashare marketing to namespace '<consumer_namespace>';

보조 ETL 네임스페이스 설정(소비자)

이제 공유 데이터에 쓰기를 시작하기 위해 보조(소비자) ETL 웨어하우스를 설정할 준비가 되었습니다.

데이터 공유에서 데이터베이스 생성

데이터베이스를 생성하려면 다음 단계를 완료하세요.

1. 쿼리 편집기 v2에서 보조 ETL 웨어하우스로 전환합니다.
2. 명령을 실행하십시오. show datashares 마케팅 데이터 공유와 데이터 공유 생산자의 네임스페이스를 확인합니다.
3. 다음 코드에 표시된 대로 해당 네임스페이스를 사용하여 데이터 공유에서 데이터베이스를 만듭니다.

create database marketing_ds_db with permissions from datashare marketing of namespace '<producer_namespace>';

지정 with permissions 개별 데이터베이스 사용자 및 역할에 세부적인 권한을 부여할 수 있습니다. 이것이 없으면 데이터 공유 데이터베이스에 대한 사용 권한을 부여하면 사용자와 역할은 데이터 공유 데이터베이스 내의 모든 개체에 대한 모든 권한을 얻습니다.

사용자를 생성하고 해당 사용자에게 권한을 부여합니다.

다음을 사용하여 사용자를 생성합니다. CREATE USER 명령:

create user data_engineer password '[choose a secure password]';
grant usage on database marketing_ds_db to data_engineer;
grant all on schema marketing_ds_db.prod to data_engineer;
grant all on schema marketing_ds_db.staging to data_engineer;
grant all on all tables in schema marketing_ds_db.staging to data_engineer;
grant all on all tables in schema marketing_ds_db.prod to data_engineer;

이러한 보조금을 통해 사용자에게 data_engineer 데이터 공유의 모든 개체에 대한 모든 권한. 또한 범위가 지정된 권한으로 스키마에서 사용 가능한 모든 권한을 부여했습니다. data_engineer. 해당 스키마에 추가된 개체에 대한 모든 권한은 자동으로 부여됩니다. data_engineer.

이 시점에서 현재 로그인한 관리자 또는 다음 중 하나를 사용하여 단계를 계속할 수 있습니다. data_engineer.

데이터 공유 데이터베이스에 쓰기 위한 옵션

세 가지 방법으로 데이터 공유 데이터베이스에 데이터를 쓸 수 있습니다.

로컬 데이터베이스에 연결된 동안 세 부분으로 구성된 표기법 사용

읽기 데이터 공유와 마찬가지로 세 부분으로 구성된 표기법을 사용하여 데이터 공유 데이터베이스 개체를 참조할 수 있습니다. 예를 들어, insert into marketing_ds_db.prod.customer. 다중 문 트랜잭션을 사용하여 이와 같이 데이터 공유 데이터베이스의 개체에 쓸 수는 없습니다.

데이터 공유 데이터베이스에 직접 연결

Amazon Redshift Data API(신규) 외에도 Redshift JDBC, ODBC 또는 Python 드라이버를 통해 데이터 공유 데이터베이스에 직접 연결할 수 있습니다. 이렇게 연결하려면 연결 문자열에 데이터 공유 데이터베이스 이름을 지정하세요. 이를 통해 두 부분으로 구성된 표기법을 사용하여 데이터 공유 데이터베이스에 쓸 수 있고 다중 문 트랜잭션을 사용하여 데이터 공유 데이터베이스에 쓸 수 있습니다. 일부 시스템 및 카탈로그 테이블은 이 방법으로 사용할 수 없습니다.

사용 명령을 실행하십시오.

이제 다음 명령을 사용하여 다른 데이터베이스를 사용하도록 지정할 수 있습니다. use <database_name>. 이를 통해 두 부분으로 구성된 표기법을 사용하여 데이터 공유 데이터베이스에 쓸 수 있고 다중 문 트랜잭션을 사용하여 데이터 공유 데이터베이스에 쓸 수 있습니다. 일부 시스템 및 카탈로그 테이블은 이 방법으로 사용할 수 없습니다. 또한 시스템 및 카탈로그 테이블을 쿼리할 때 사용 중인 데이터베이스가 아닌 연결된 데이터베이스의 시스템 및 카탈로그 테이블을 쿼리하게 됩니다.

이 방법을 시도하려면 다음 명령을 실행하십시오.

use marketing_ds_db;

데이터 공유 데이터베이스에 쓰기 시작

이 섹션에서는 논의한 두 번째 및 세 번째 옵션(직접 연결 또는 명령 사용)을 사용하여 데이터 공유 데이터베이스에 쓰는 방법을 보여줍니다. 우리는 AWS 연구소에서 제공한 SQL 데이터 공유 데이터베이스에 쓰려고 합니다.

준비 테이블 만들기

생성 권한이 부여되었으므로 스테이징 스키마 내에 테이블을 생성합니다. 데이터 공유 내에 테이블을 생성합니다. staging 다음 DDL 문을 사용하는 스키마:

create table staging.customer (
  c_custkey int8 not null ,
  c_name varchar(25) not null,
  c_address varchar(40) not null,
  c_nationkey int4 not null,
  c_phone char(15) not null,
  c_acctbal numeric(12,2) not null,
  c_mktsegment char(10) not null,
  c_comment varchar(117) not null,
  Primary Key(C_CUSTKEY)
) distkey(c_nationkey) sortkey(c_nationkey);

USE 명령을 사용했거나 데이터 공유 데이터베이스에 직접 연결했기 때문에 두 부분으로 구성된 표기법을 사용할 수 있습니다. 그렇지 않은 경우 데이터 공유 데이터베이스 이름도 지정해야 합니다.

스테이징 테이블에 데이터 복사

다음 명령을 사용하여 AWS Labs 퍼블릭 S10 버킷의 고객 TPCH 3 데이터를 테이블에 복사합니다.

copy staging.customer from 's3://redshift-downloads/TPC-H/2.18/10GB/customer.tbl' iam_role default delimiter '|' region 'us-east-1';

이전과 마찬가지로 이 웨어하우스를 생성할 때 기본 IAM 역할을 설정해야 합니다.

아프리카 고객 데이터를 테이블에 수집 prod.af_customer

다음 명령을 실행하여 아프리카 고객 데이터만 테이블에 수집합니다. prod.af_customer:

insert into prod.af_customer
select c.* from staging.customer c
  join prod.nation n on c.c_nationkey = n.n_nationkey
  join prod.region r on n.n_regionkey = r.r_regionkey
  where r.r_regionkey = 0; --0 is the region key for Africa

이를 위해서는 선택 권한이 있는 국가 및 지역 테이블에 조인해야 합니다.

준비 테이블 자르기

당신은 잘라낼 수 있습니다 각색 향후 작업에서 다시 생성하지 않고도 테이블에 쓸 수 있도록 합니다. 자르기 작업은 트랜잭션 방식으로 실행되며 데이터 공유 데이터베이스에 직접 연결되어 있거나 use 명령을 사용하는 경우(데이터 공유 데이터베이스를 사용하지 않는 경우에도) 롤백될 수 있습니다. 다음 코드를 사용하세요.

truncate staging.customer;

이제 기본 네임스페이스에 대한 데이터 수집이 완료되었습니다. 다음을 쿼리할 수 있습니다. af_customer 기본 웨어하우스와 보조 ETL 웨어하우스 모두에서 테이블을 가져와 동일한 데이터를 볼 수 있습니다.

결론

이 게시물에서는 여러 웨어하우스를 사용하여 동일한 데이터베이스에 쓰는 방법을 보여주었습니다. 이 솔루션에는 다음과 같은 이점이 있습니다.

• 다양한 크기의 프로비저닝된 클러스터와 서버리스 작업 그룹을 사용하여 동일한 데이터베이스에 쓸 수 있습니다.
• 계정과 지역 전반에 걸쳐 쓸 수 있습니다.
• 데이터는 커밋되는 즉시 모든 웨어하우스에서 실시간으로 사용 가능합니다.
• 생산자 웨어하우스(데이터베이스를 소유한 웨어하우스)가 일시 중지된 경우에도 쓰기가 작동합니다.

이 기능에 대해 자세히 알아보려면 다음을 참조하세요. AWS 계정 내에서 또는 계정 간에 읽기 및 쓰기 데이터 공유(미리 보기). 또한, 의견이 있으시면 다음 주소로 이메일을 보내주세요. dsw-feedback@amazon.com.

저자 소개

라이언 월도프 Amazon Redshift의 수석 제품 관리자입니다. Ryan은 데이터 공유 및 동시성 확장을 포함하여 고객이 컴퓨팅을 정의하고 확장할 수 있는 기능에 중점을 둡니다.

하시다 파텔 Amazon Web Services(AWS)의 분석 전문가 수석 솔루션 설계자입니다.

수딥토 다스 Amazon Web Services(AWS)의 수석 수석 엔지니어입니다. 그는 특히 Amazon Redshift 및 Amazon Aurora에 중점을 두고 AWS에서 여러 데이터베이스 및 분석 서비스의 기술 아키텍처와 전략을 이끌고 있습니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/big-data/improve-your-etl-performance-using-multiple-redshift-warehouses-for-writes/