PostgreSQL용 Openflow 커넥터 소개
PostgreSQL용 Openflow 커넥터 소개
이 문서에서는 PostgreSQL용 Openflow 커넥터의 기본 개념, 워크플로, 제한 사항을 설명합니다. 이 커넥터는 PostgreSQL 데이터베이스 인스턴스를 Snowflake에 연결하고 선택한 테이블의 데이터를 거의 실시간 또는 일정에 따라 복제합니다.
출처: Snowflake 문서
본문
PostgreSQL용 Openflow 커넥터 소개
PostgreSQL용 Openflow 커넥터는 PostgreSQL 데이터베이스 인스턴스를 Snowflake에 연결하고 선택한 테이블의 데이터를 거의 실시간 또는 일정에 따라 복제합니다. 커넥터는 또한 모든 데이터 변경의 로그를 만들며, 이 로그는 복제된 테이블의 현재 상태와 함께 제공됩니다.
사용 사례
다음과 같은 목적을 위해 이 커넥터를 사용하세요.
- 포괄적이고 중앙 집중적인 보고를 위해 PostgreSQL 데이터를 Snowflake로 CDC 복제
지원되는 PostgreSQL 버전
다음은 지원되는 PostgreSQL 버전입니다.
| 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | |
|---|---|---|---|---|---|---|---|---|
| Standard | 예 | 예 | 예 | 예 | 예 | 예 | 예 | 예 |
| AWS RDS | 예 | 예 | 예 | 예 | 예 | 예 | 예 | 예 |
| Amazon Aurora | 예 | 예 | 예 | 예 | 예 | 예 | 예 | 예 |
| GCP Cloud SQL | 예 | 예 | 예 | 예 | 예 | 예 | 예 | 예 |
| Azure Database | 예 | 예 | 예 | 예 | 예 | 예 | 예 | 예 |
Openflow 요구 사항
- 지속적인 복제 워크로드에 따라 런타임 크기를 선택하세요. 크기 조정 지침과 한 런타임에서 여러 커넥터를 실행하는 방법은 Runtime sizing을 참조하세요.
- 커넥터는 다중 노드 Openflow 런타임을 지원하지 않습니다. 이 커넥터의 런타임은 Min nodes와 Max nodes를 1로 설정해 구성하세요.
제한 사항
- 커넥터는 PostgreSQL 버전 11 이상을 지원합니다.
- 커넥터는 PostgreSQL에 대한 사용자 이름·비밀번호 인증만 지원합니다.
- 커넥터는 Snowflake의 유형 제한을 초과하는 데이터가 있는 테이블을 복제하지 않습니다. 이 규칙의 예외는 범위를 벗어난 값이 포함된 날짜·시간 데이터 유형 열입니다. 자세한 내용은 'Out of range value support'를 참조하세요.
- 커넥터는 복제된 모든 테이블이 지원되는 신원 키(identity key) 구성을 가지도록 요구합니다. REPLICA IDENTITY DEFAULT가 있는 기본 키, REPLICA IDENTITY USING INDEX가 있는 고유 인덱스(기본 키가 없는 테이블의 'Configure replica identity' 참조), 또는 REPLICA IDENTITY FULL이 있는 사용자가 선언한 논리 키 중 하나입니다. 지원되는 신원 키 구성이 없는 테이블은 INSERT 작업만 복제할 수 있습니다. UPDATE와 DELETE에는 신원 키가 필요합니다. 자세한 내용은 'Specify a logical key for a table'을 참조하세요.
- 커넥터는 복제 중 열 추가, 삭제, 이름 변경 같은 일반적인 소스 테이블 스키마 변경을 지원합니다. 전체 목록과 지원되지 않는 변경 유형 몇 가지는 Schema changes를 참조하세요.
- 스냅샷 없는 증분 복제를 사용할 때 증분 복제가 시작되기 전에 삽입된 행이 있다면, 그 행에 대한 이후 업데이트는 VARCHAR, VARIANT, BINARY, ARRAY 열에 값이 누락된 목적지 행을 만들 수 있습니다.
- 커넥터는 테이블 잘라내기(truncate) 연산을 지원하지 않습니다. 소스의 TRUNCATE 문은 무시되며 해당 행 삭제는 목적지 테이블에 적용되지 않습니다.
참고: 특정 테이블 열에 영향을 주는 제한 사항은 해당 열을 복제에서 제외해 우회할 수 있습니다.
워크플로
- 데이터베이스 관리자가 PostgreSQL 복제 설정을 구성하고, publication과 커넥터용 자격 증명을 만듭니다. 선택 사항으로 SSL 인증서를 제공합니다.
- Openflow 관리자가 커넥터용 웨어하우스와 복제할 목적지 데이터베이스를 만듭니다.
- Openflow 관리자 또는 데이터 엔지니어가 다음 작업을 수행합니다.
- 커넥터를 설치합니다.
- 플로우 템플릿에 필수 파라미터를 지정합니다.
- 플로우를 실행합니다. Openflow에서 실행할 때 커넥터는 다음 작업을 수행합니다.
- 저널 테이블용 스키마를 만듭니다.
- 복제 대상으로 구성된 소스 테이블과 일치하는 스키마와 목적지 테이블을 만듭니다.
- 테이블 복제 수명 주기에 따라 복제를 시작합니다.
커넥터 동작 방식
다음 섹션에서는 복제, 스키마 변경, 데이터 보존을 포함해 다양한 시나리오에서 커넥터가 어떻게 동작하는지 설명합니다.
데이터 복제
목적지 스키마 이름은 Destination Schema Pattern 파라미터로 결정됩니다. 자세한 내용은 'PostgreSQL Destination Parameters'를 참조하세요. 기본적으로 목적지 스키마 이름은 소스 스키마 이름과 일치하므로 목적지 테이블의 정규화된 이름은 다음과 같습니다.
<destination_database>.<source_schema_name>.<source_table_name>
테이블 복제 방식
테이블은 다음 단계로 복제됩니다.
- 스키마 introspection: 커넥터가 소스 테이블의 열, 이름, 유형을 발견한 뒤 Snowflake와 커넥터의 제한 사항에 대해 검증합니다. 검증 실패는 이 단계를 실패하게 하고 주기가 완료됩니다. 스키마 Introspection이 성공적으로 완료되면 커넥터는 빈 목적지 테이블을 만듭니다.
- 스냅샷 로드: 커넥터가 소스 테이블에서 사용 가능한 모든 데이터를 목적지 테이블로 복사합니다. 이 단계의 실패는 주기를 끝내며 더 이상 데이터가 복제되지 않습니다. 성공적으로 완료되면 소스 테이블의 전체 데이터 집합이 목적지 테이블에서 사용 가능해집니다.
- 증분 로드: 커넥터가 소스 테이블의 변경을 계속 추적해 목적지 테이블로 복사합니다. 이것은 테이블이 복제에서 제거될 때까지 계속됩니다. 이 단계에서의 실패는 문제가 해결될 때까지 소스 테이블 복제를 영구적으로 중지합니다.
참고: 이 커넥터는 새로 추가된 테이블에 대해 스냅샷 로드 단계를 건너뛰고 증분 변경 복제를 즉시 시작하도록 구성할 수 있습니다. 이 옵션은 이전에 복제된 데이터가 존재하는 계정에 커넥터를 재설치하면서 테이블을 다시 스냅샷하지 않고 복제를 계속하고 싶을 때 유용합니다. 스냅샷 로드를 건너뛰고 증분 로드 과정을 사용하는 방법은 'Incremental replication'을 참조하세요.
중요: 연결 오류 같은 일시적 실패는 테이블 복제를 막지 않습니다. 지원되지 않는 데이터 유형 같은 영구 실패는 테이블 복제를 막습니다. 영구 실패가 테이블 복제를 막으면 테이블을 복제 테이블 목록에서 제거하세요. 실패 원인을 해결한 뒤 테이블을 복제 테이블 목록에 다시 추가할 수 있습니다.
스키마 변경
증분 복제 중 커넥터는 소스 테이블 스키마 변경을 감지하고 목적지 테이블을 자동으로 업데이트할 수 있습니다. 지원되지 않는 변경은 영향을 받는 테이블의 복제를 다시 시작할 때까지 중지합니다.
지원되는 변경
커넥터는 다음 스키마 변경을 지원합니다.
- 열 추가. 커넥터가 열을 목적지 테이블에 추가하고 새 행과 업데이트된 행의 값을 복제합니다. 기존 행은 역채움되지 않으며, 변경 전에 존재했던 행에서는 새 열이 NULL입니다.
- 열 삭제. 커넥터가 목적지 열의 이름을
__SNOWFLAKE_DELETED접미사를 붙여 변경해 과거 값을 보존합니다. 자세한 내용은 'Dropped columns'을 참조하세요. - 열 이름 변경. 커넥터는 이름 변경을 원래 열 삭제와 새 열 추가로 취급합니다. 커넥터는 원래 열을 접미사가 붙은 이름으로 유지합니다. 예: A라는 열은 A__SNOWFLAKE_DELETED가 됩니다. 쿼리 패턴은 'Renamed columns'를 참조하세요.
- 호환 가능한 유형 변경. 열을 같은 Snowflake 데이터 유형으로 매핑되는 소스 유형으로 바꾸면 커넥터는 목적지 열 유형을 변경하지 않고 복제를 계속 유지합니다(예: INT→BIGINT, 둘 다 NUMBER로 매핑).
- 이전에 삭제된 열 재추가. 커넥터가 기존의 소프트 삭제된 열 옆에 새 목적지 열로 열을 추가합니다(예: A와 A__SNOWFLAKE_DELETED).
- 기본 키 정의 변경. 커넥터는 변경 후에도 테이블에 유효한 복제 키가 남는 한, 기본 키 열 추가·제거 또는 기본 키를 구성하는 열 변경을 지원합니다. 기본 키를 삭제했는데 다른 유효한 복제 키(자격이 되는 고유 인덱스 또는 구성된 논리 키 등)가 남지 않으면 해당 테이블의 복제가 실패하고 테이블이 FAILED로 표시됩니다.
이전에 삭제되어 소프트 삭제된 열을 다시 삭제하면 소프트 삭제된 열 이름이 이미 사용 중이므로 해당 테이블의 복제가 실패합니다.
지원되지 않는 변경
커넥터는 다음 스키마 변경을 지원하지 않습니다. 이러한 변경이 발생하면 영향을 받는 테이블의 복제가 중지됩니다.
- 호환되지 않는 유형 변경. 새 소스 유형이 다른 Snowflake 데이터 유형으로 매핑될 때(예: INT→VARCHAR, 각각 NUMBER와 TEXT로 매핑).
- 숫자 정밀도 또는 배율 변경. 예: NUMERIC(7,2)을 NUMERIC(6,3)으로 변경.
- 문자 열 길이 변경. 예: VARCHAR(50)을 VARCHAR(100)으로 변경.
복구하려면 영향을 받는 테이블의 복제를 다시 시작하세요. 'Restart table replication' 참조.
테이블의 Column Filter JSON을 변경할 때도 동일한 소프트 삭제 메커니즘이 적용됩니다. 자세한 내용은 'Replicate a subset of columns in a table'을 참조하세요.
PostgreSQL 복제본 서버에서 테이블 복제
커넥터는 논리적 복제를 사용해 기본(primary) 서버, 핫 스탠바이 복제본(hot standby replica), 또는 구독자(subscriber) 서버에서 데이터를 수집할 수 있습니다. PostgreSQL 복제본에 연결하도록 커넥터를 구성하기 전에 기본 노드와 복제본 노드 간 복제가 올바르게 동작하는지 확인하세요. 커넥터에서 데이터 누락 문제를 조사할 때는 먼저 누락된 행이 커넥터가 사용하는 복제본 서버에 있는지 확인하세요.
스탠바이 복제본에 연결할 때 추가 고려 사항:
- 서버의 PostgreSQL 버전이 >= 16이어야 합니다. Amazon Aurora는 읽기 복제본에서 논리적 디코딩을 제공하지 않으므로 지원되지 않습니다.
- 핫 스탠바이 복제본에만 연결이 지원됩니다. 웜 스탠바이(warm standby) 복제본은 기본 인스턴스로 승격되기 전까지 클라이언트 연결을 수락할 수 없습니다.
- 커넥터에 필요한 publication은 스탠바이 서버가 아니라 기본 서버에 만들어야 합니다. 스탠바이 서버는 읽기 전용이라 publication을 만들 수 없습니다.
핫 스탠바이 인스턴스에 연결했는데 Openflow 게시판에 'Trying to create the replication slot '
SELECT pg_log_standby_snapshot();
이 오류는 기본 서버에 데이터 변경이 없을 때 발생합니다. 그 결과 커넥터가 복제본 서버에서 복제 슬롯을 만드는 동안 멈출 수 있습니다. 이는 복제본 서버가 복제 슬롯을 만들기 위해 기본 서버의 실행 중인 트랜잭션 정보가 필요하기 때문입니다. 기본 서버는 유휴 상태일 때 이 정보를 보내지 않습니다. pg_log_standby_snapshot() 함수는 기본 서버가 실행 중인 트랜잭션 정보를 복제본 서버로 보내도록 강제합니다.
PostgreSQL 17 이상에서 복제 슬롯이 기본 장애 조치를 견디게 하려면 커넥터가 스탠바이가 아니라 기본에 연결해야 합니다. 'PostgreSQL 17+ failover slot support'를 참조하세요.
테이블의 데이터 변경 추적
커넥터는 소스 테이블의 데이터 현재 상태뿐만 아니라 모든 변경 세트의 모든 행 상태도 복제합니다. 이 데이터는 목적지 테이블과 같은 스키마에 만든 저널(journal) 테이블에 저장됩니다.
저널 테이블 이름은 <source_table_name>_JOURNAL_<timestamp>_<schema_generation> 형식으로 지정되며, 여기서 <timestamp>는 소스 테이블이 복제에 추가된 시점의 epoch 초 값이고, <schema_generation>은 소스 테이블의 스키마 변경 때마다 증가하는 정수입니다. 그 결과 스키마 변경을 겪는 소스 테이블은 여러 개의 저널 테이블을 갖게 됩니다.
테이블이 복제에서 제거된 뒤 다시 추가되면 <timestamp> 값이 바뀌고 <schema_generation>은 다시 1부터 시작합니다.
중요: Snowflake는 저널 테이블 구조를 어떤 식으로든 변경하지 말 것을 권장합니다. 저널 테이블은 복제 과정의 일부로 목적지 테이블을 업데이트할 때 커넥터가 사용합니다.
커넥터의 복제 키 선택 방식
커넥터는 각 소스 테이블에서 하나의 열 또는 열 집합을 복제 키로 사용합니다. 복제 키는 행을 고유하게 식별하며 CDC 변경을 목적지에 적용하는 MERGE 작업을 구동합니다.
각 테이블에 대해 커넥터는 다음 순서로 복제 키를 결정합니다.
- 사용자가 선언한 논리 키. 커넥터가 테이블을 나열하는 Table Key Configuration Service로 구성된 경우 커넥터는 해당 열을 복제 키로 사용하며, 테이블의 기본 키나 고유 인덱스를 덮어씁니다. 자세한 내용은 'Specify a logical key for a table'을 참조하세요.
- 기본 키. REPLICA IDENTITY가 DEFAULT일 때(기본 키가 있는 테이블의 PostgreSQL 기본값) 테이블의 기본 키 제약 조건의 열.
- 고유 인덱스. 테이블에 기본 키가 없으면 커넥터는 REPLICA IDENTITY USING INDEX로 지정된 고유 인덱스를 사용합니다. 설정 지침과 인덱스 요구 사항은 기본 키가 없는 테이블의 'Configure replica identity'를 참조하세요.
- 없음. 자격이 되는 키가 없으면 커넥터는 INSERT 작업만 복제할 수 있습니다. UPDATE와 DELETE에는 신원 키가 필요합니다. 테이블에 대한 전체 CDC를 활성화하려면 기본 키를 추가하거나, 자격이 되는 고유 인덱스에 REPLICA IDENTITY USING INDEX를 구성하거나, 논리 키를 선언하세요.
다음 예시는 각 복제 키 시나리오를 보여줍니다.
기본 키가 있는 테이블(특별한 설정 불필요):
CREATE TABLE orders (
order_id BIGINT PRIMARY KEY,
customer_id INT,
total NUMERIC(10, 2)
);
커넥터는 order_id를 복제 키로 사용합니다.
기본 키가 없고 고유 인덱스로 복제되는 테이블:
CREATE TABLE sessions (
session_token VARCHAR(64) NOT NULL,
user_id INT,
created_at TIMESTAMPTZ
);
CREATE UNIQUE INDEX idx_sessions_token ON sessions (session_token);
ALTER TABLE sessions REPLICA IDENTITY USING INDEX idx_sessions_token;
커넥터는 session_token을 복제 키로 사용합니다.
기본 키도 자격이 되는 인덱스도 없고 논리 키로 복제되는 테이블:
CREATE TABLE audit_events (
event_id UUID NOT NULL,
event_type TEXT,
payload JSONB
);
ALTER TABLE audit_events REPLICA IDENTITY FULL;
Table Key Configuration JSON에서 event_id에 논리 키를 구성하세요. 설정 지침은 'Specify a logical key for a table'을 참조하세요.
복제 키 값 변경
소스 업데이트가 기존 행의 복제 키 값을 변경하면 커넥터는 행의 신원이 바뀌므로 목적지 행을 제자리에서 업데이트할 수 없습니다. 대신 소스 업데이트를 목적지 테이블의 두 연산으로 나눕니다.
- 이전 값으로 키가 지정된 목적지 행이 소프트 삭제됩니다. 해당
_SNOWFLAKE_DELETED메타데이터 열이 TRUE로 설정됩니다. - 새 값으로 키가 지정된 새 목적지 행이 삽입되며, 업데이트된 페이로드와
_SNOWFLAKE_DELETED = FALSE가 설정됩니다.
따라서 변경 후 목적지 테이블에는 원래 행(소프트 삭제됨)과 새 키 값 아래의 새 행, 두 행이 포함됩니다. 현재 행만 쿼리하려면 _SNOWFLAKE_DELETED = FALSE로 필터링하세요.
이 동작은 복제 키가 기본 키, 자동 감지된 고유 인덱스, 또는 사용자가 선언한 논리 키일 때 적용됩니다.
초과 크기 값
기본적으로 커넥터는 최대 16 MB까지의 개별 값을 복제합니다. 커넥터가 더 큰 값을 만나면 관련 테이블을 영구 실패로 표시하고 복제를 중지합니다. 초과 크기 값 처리 방식을 변경하려면(예: NULL로 바꾸기) Oversized Value Strategy 목적지 파라미터를 수정하세요.
Snowflake 계정에 ENABLE_OPENFLOW_CDC_POSTGRES_SSV2 파라미터가 true로 설정되어 있으면 값당 한도를 16 MB에서 128 MB로 높일 수 있습니다.
128 MB 값당 한도 활성화에 대한 자세한 내용과 지침은 'Increase the oversized value limit'을 참조하세요.
잘못된 행에 대한 오류 처리
잘못된 행은 수집 중 Snowflake가 거부하는 행으로, 목적지 테이블에 쓸 수 없습니다(예: 목적지 열 유형으로 변환할 수 없는 값, 필수 열 누락). Error Handling Strategy 파라미터는 커넥터가 잘못된 행을 만났을 때 하는 동작을 제어합니다.
- Fail Table(기본): 첫 번째 잘못된 행에서 커넥터가 테이블을 영구 실패로 표시하고 복제를 중지하며, 엄격한 전부 아니면 전무 복제를 유지합니다. 소스 데이터를 고친 뒤 'Restart table replication'에 설명된 대로 복제를 재개하세요.
- Log Errors and Continue: 커넥터는 유효한 행은 계속 복제하고, 거부된 각 행을 원래 페이로드와 오류 세부 정보와 함께 테이블의 오류 테이블에 기록합니다. 테이블은 실패로 표시되지 않습니다.
전략을 바꾸려면 Error Handling Strategy 파라미터를 설정하세요. 자세한 내용은 'PostgreSQL Destination Parameters'를 참조하세요.
거부된 행 캡처 방식
커넥터는 Snowpipe Streaming으로 데이터를 로드하므로 오류 로깅은 'Error logging in Snowpipe Streaming'에 설명된 그대로 동작합니다. Log Errors and Continue를 선택하면 커넥터는 ERROR_LOGGING 속성이 TRUE로 설정된 새 목적지·저널 테이블을 만들므로, 거부된 행은 로드를 중단하는 대신 전용 오류 테이블에 캡처됩니다. 오류 테이블은 어떤 변환 전에 Snowflake로 전송된 원래 페이로드와 함께 오류 세부 정보를 저장합니다.
ERROR_TABLE 테이블 함수로 테이블의 오류 테이블을 쿼리하세요.
SELECT * FROM ERROR_TABLE(<destination_database>.<schema>.<table>) ORDER BY timestamp;
거부된 행이 어디에 들어가는지는 복제 단계에 따라 다릅니다.
- 스냅샷 로드: 거부된 행이 목적지 테이블의 오류 테이블에 기록됩니다.
- 증분(CDC) 로드: CDC 변경이 먼저 저널 테이블에 기록되므로 거부된 행이 저널 테이블의 오류 테이블에 기록됩니다. 저널 테이블에 대한 자세한 내용은 '테이블의 데이터 변경 추적'을 참조하세요.
커넥터는 Log Errors and Continue를 선택한 뒤 만들어진 테이블에서만 오류 로깅을 활성화합니다. 이미 복제 중이던 테이블의 거부된 행을 캡처하려면 'Enable error logging on an existing schema'의 저장 프로시저로 기존 목적지·저널 테이블에 오류 로깅을 활성화하세요.
참고: 커넥터가 잘못된 행을 만나면 거부된 행 수를 포함하는
WARN로그 항목을 내보냅니다. 이 항목들로 거부된 행 활동을 모니터링하세요.
거부된 행 소비
거부된 행을 프로그래밍 방식으로 처리하려면 오류 테이블에 스트림을 만들고 다른 Snowflake 스트림처럼 소비하세요. 자세한 내용은 'Streams on error tables'를 참조하세요.
TOAST 값 지원
커넥터는 array, bytea, json, jsonb, text, varchar, xml 유형의 열에 TOAST 값이 있는 테이블 복제를 지원합니다.
커넥터가 CDC 스트림에서 TOAST 값을 만나면 주어진 열 유형에 맞게 형식화된 기본 플레이스홀더 __previous_value_unchanged로 대체해 저널 테이블에 저장합니다. 그런 다음 MERGE 쿼리가 플레이스홀더 값을 고려해, 목적지 테이블이 항상 마지막 비-TOAST 값을 포함하도록 합니다.
범위를 벗어난 값 지원
커넥터는 date, timestamp, timestamptz 유형의 열에 범위를 벗어난 값이 있는 테이블 복제를 지원합니다. 커넥터가 CDC 스트림에서 범위를 벗어난 값을 만나면 열 유형에 따라 기본 플레이스홀더로 대체합니다.
범위를 벗어난 값의 플레이스홀더 값:
| 열 유형 | 플레이스홀더 값 |
|---|---|
| date | -9999-01-01부터 9999-12-31 |
| timestamp | 0001-01-01 00:00:00부터 9999-12-31 23:59:59.999999999 |
| timestamptz | 0001-01-01 00:00:00+00부터 9999-12-31 23:59:59.999999999+00 |
참고:
-Infinity와Infinity값도 세 유형 모두 해당 플레이스홀더로 대체됩니다.
데이터 보존 이해
커넥터는 고객 데이터가 자동으로 삭제되지 않는 데이터 보존 철학을 따릅니다. 복제된 데이터에 대한 완전한 소유권과 통제권을 유지하며, 커넥터는 과거 정보를 영구히 제거하지 않고 보존합니다.
이 접근 방식의 의미는 다음과 같습니다.
- 소스 테이블에서 삭제된 행은 물리적으로 제거되지 않고 목적지 테이블에서 소프트 삭제됩니다.
- 소스 테이블에서 제거된 열은 삭제되지 않고 목적지 테이블에서 이름이 변경됩니다.
- 저널 테이블은 무기한 보존되며 자동으로 정리되지 않습니다.
목적지 테이블 메타데이터 열
각 목적지 테이블에는 복제 정보를 추적하는 다음 메타데이터 열이 포함됩니다.
| 열 이름 | 유형 | 설명 |
|---|---|---|
| _SNOWFLAKE_INSERTED_AT | TIMESTAMP_NTZ | 행이 원래 목적지 테이블에 삽입된 시각 |
| _SNOWFLAKE_UPDATED_AT | TIMESTAMP_NTZ | 행이 목적지 테이블에서 마지막으로 업데이트된 시각 |
| _SNOWFLAKE_DELETED | BOOLEAN | 행이 소스 테이블에서 삭제되었는지 여부. true이면 행이 소프트 삭제되어 더 이상 소스에 존재하지 않음 |
소프트 삭제된 행
행이 소스 테이블에서 삭제되면 커넥터는 이를 목적지 테이블에서 물리적으로 제거하지 않습니다. 대신 _SNOWFLAKE_DELETED 메타데이터 열을 true로 설정해 삭제로 표시합니다.
이 접근 방식으로 다음을 할 수 있습니다.
- 감사 또는 규정 준수 목적으로 과거 데이터 보존
- 필요할 때 삭제된 레코드 쿼리
- 요구 사항에 따라 데이터를 영구히 제거할 시기와 방법 결정
활성(비삭제) 행만 쿼리하려면 _SNOWFLAKE_DELETED 열로 필터링하세요.
SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;
삭제된 행을 쿼리하려면:
SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;
삭제된 열
열이 소스 테이블에서 삭제되면 커넥터는 목적지 테이블에서 해당 열을 삭제하지 않습니다. 대신 과거 값을 보존하기 위해 __SNOWFLAKE_DELETED 접미사를 붙여 이름을 변경합니다.
예를 들어 EMAIL이라는 열이 소스 테이블에서 삭제되면 목적지 테이블에서 EMAIL__SNOWFLAKE_DELETED로 이름이 바뀝니다. 열이 삭제되기 전에 존재했던 행은 원래 값을 유지하고, 삭제 후 추가된 행은 이 열에서 NULL을 가집니다.
이름이 바뀐 열에서도 과거 값을 계속 쿼리할 수 있습니다.
SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;
이름이 바뀐 열
CDC 메커니즘의 제한 때문에 커넥터는 열 이름 변경과 열 삭제 후 새 열 추가를 구분할 수 없습니다. 그 결과 소스 테이블에서 열 이름을 바꾸면 커넥터는 이를 두 개의 별도 연산(원래 열 삭제와 새 이름으로 새 열 추가)으로 취급합니다.
예를 들어 소스 테이블에서 열 이름을 A에서 B로 바꾸면 목적지 테이블에는 다음이 포함됩니다.
- A__SNOWFLAKE_DELETED: 이름 변경 전의 값을 포함. 이름 변경 후 추가된 행은 이 열에서 NULL.
- B: 이름 변경 후의 값을 포함. 이름 변경 전에 존재했던 행은 이 열에서 NULL.
이름이 바뀐 열 쿼리
원래 열과 이름이 바뀐 열의 데이터를 단일 통합 열로 가져오려면 COALESCE 또는 CASE 표현식을 사용하세요.
SELECT
COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;
또는 CASE 표현식을 사용:
SELECT
CASE
WHEN B IS NOT NULL THEN B
ELSE A__SNOWFLAKE_DELETED
END AS A_RENAMED_TO_B
FROM my_table;
이름이 바뀐 열용 뷰 만들기
목적지 테이블을 수동으로 수정하는 대신 이름이 바뀐 열을 단일 통합 열로 제시하는 뷰를 만들 수 있습니다. 이 접근 방식은 원래 데이터를 보존하고 진행 중인 복제로 인한 잠재적 문제를 피하므로 권장됩니다.
CREATE VIEW my_table_unified AS
SELECT
*,
COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;
중요: 목적지 테이블 구조를 수동으로 수정하는 것(열 삭제 또는 이름 변경 등)은 진행 중인 복제를 방해하고 데이터 불일치를 유발할 수 있으므로 권장되지 않습니다.
저널 테이블
증분 복제 중 소스 데이터베이스의 변경은 목적지 테이블에 병합되기 전에 먼저 저널 테이블에 기록됩니다. 커넥터는 저널 테이블에서 데이터를 자동으로 제거하지 않습니다. 이 데이터는 감사, 디버깅, 재처리 목적으로 유용할 수 있기 때문입니다.
저널 테이블은 해당 목적지 테이블과 같은 스키마에 만들어지며 다음 명명 규칙을 따릅니다.
<TABLE_NAME>_JOURNAL_<timestamp>_<number>
여기서:
- <TABLE_NAME>은 목적지 테이블 이름.
는 Unix epoch 형식(1970년 1월 1일 이후 초)의 생성 타임스탬프로 고유성을 보장. 는 1에서 시작해 소스 테이블의 스키마 변경이나 열 필터 수정으로 인해 목적지 테이블 스키마가 바뀔 때마다 증가.
예를 들어 목적지 테이블이 SALES.ORDERS라면 저널 테이블 이름은 SALES.ORDERS_JOURNAL_1705320000_1일 수 있습니다.
중요: 복제가 진행 중일 때 저널 테이블을 삭제하지 마세요. 활성 저널 테이블 제거는 데이터 손실이나 복제 실패를 유발할 수 있습니다. 해당 소스 테이블이 복제에서 완전히 제거된 후에만 저널 테이블을 삭제하세요.
저널 테이블 스토리지 관리
오래된 저널 데이터를 제거해 스토리지 비용을 관리해야 한다면, 더 이상 복제되지 않는 테이블의 저널 테이블을 주기적으로 정리하는 Snowflake 태스크를 만들 수 있습니다.
저널 정리를 구현하기 전에 다음을 확인하세요.
- 해당 소스 테이블이 복제에서 완전히 제거되었는지.
- 감사나 처리 목적으로 저널 데이터가 더 이상 필요 없는지.
자동 정리용 태스크 생성·관리에 대한 정보는 'Introduction to tasks'를 참조하세요.
다음 단계
- 커넥터가 데이터 유형을 Snowflake 데이터 유형으로 매핑하는 방법을 이해하려면 'Openflow Connector for PostgreSQL: Data mapping'을 검토하세요.
- 커넥터 설정은 'Set up the Openflow Connector for PostgreSQL'을 검토하세요.