고급 AUTO CDC 항목

기본 AUTO CDC 및 AUTO CDC FROM SNAPSHOT API 외에도 대상 테이블에서 DML을 실행하고, CDC 대상에서 변경 데이터 피드를 읽고, 처리 메트릭을 모니터링하고, 부분 업데이트를 적용하고, bitemporal Storage를 사용하여 변경 내용을 추적할 수 있습니다. API 소개는 AUTO CDC를 참조하세요.

대상 스트리밍 테이블에서 데이터 추가, 변경 또는 삭제

파이프라인이 Unity 카탈로그에 테이블을 게시하는 경우 문으로 생성된 대상 스트리밍 테이블을 수정하기 위해 삽입, 업데이트, 삭제 및 병합 문을 포함한 AUTO CDC ... INTO (DML) 문을 사용할 수 있습니다.

메모

스트리밍 테이블의 테이블 스키마를 수정하는 DML 문은 지원되지 않습니다. DML 문이 테이블 스키마를 변경하려고 하지 않는지 확인하세요.
스트리밍 테이블을 업데이트하는 DML 문은 Databricks Runtime 13.3 LTS 이상을 사용하여 공유 Unity 카탈로그 클러스터 또는 SQL 웨어하우스에서만 실행할 수 있습니다.
스트리밍에는 추가 전용 데이터 원본이 필요하기 때문에 처리 시 변경 내용이 있는 원본 스트리밍 테이블에서 스트리밍이 필요한 경우(예: DML 문) 원본 스트리밍 테이블을 읽을 때 skipChangeCommits 플래그 를 설정합니다. skipChangeCommits 설정되면 원본 테이블에서 레코드를 삭제하거나 수정하는 트랜잭션은 무시됩니다. 처리에 스트리밍 테이블이 필요하지 않은 경우 구체화된 뷰(추가 전용 제한이 없음)를 대상 테이블로 사용할 수 있습니다.

파이프라인은 지정된 SEQUENCE BY 열을 사용하고 적절한 시퀀싱 값을 __START_AT 대상 테이블의 열( __END_AT SCD 형식 2의 경우)에 전파하므로 DML 문이 이러한 열에 유효한 값을 사용하여 레코드의 적절한 순서를 유지해야 합니다. AUTO CDC 작동 방식을 참조하세요.

스트리밍 테이블과 함께 DML 문을 사용하는 방법에 대한 자세한 내용은 스트리밍 테이블의 데이터 추가, 변경 또는 삭제를 참조하세요.

다음 예제에서는 시작 시퀀스가 5인 활성 레코드를 삽입합니다.

INSERT INTO my_streaming_table (id, name, __START_AT, __END_AT) VALUES (123, 'John Doe', 5, NULL);

팁 (조언)

SCD Type 2 대상 테이블의 __START_AT 열과 __END_AT 이름을 변경해야 하는 경우(예: 다운스트림 스키마 요구 사항과 일치하기 위해) 대상 테이블에 대한 뷰를 만듭니다.

CREATE VIEW my_employees_view AS
SELECT
  *,
  __START_AT AS valid_from,
  __END_AT AS valid_to
FROM my_scd2_target_table;

AUTO CDC 대상 테이블에서 변경 데이터 피드 읽기

Databricks Runtime 15.2 이상에서는 다른 델타 테이블에서 변경 데이터 피드를 읽는 것과 동일한 방식으로 대상 AUTO CDC 인 스트리밍 테이블 또는 AUTO CDC FROM SNAPSHOT 쿼리에서 변경 데이터 피드를 읽을 수 있습니다. 대상 스트리밍 테이블에서 변경 데이터 피드를 읽으려면 다음이 필요합니다.

대상 스트리밍 테이블을 Unity 카탈로그에 게시해야 합니다. 파이프라인에서 Unity 카탈로그 사용을 참조하세요.
대상 스트리밍 테이블에서 변경 데이터 피드를 읽으려면 Databricks Runtime 15.2 이상을 사용해야 합니다. 다른 파이프라인에서 변경 데이터 피드를 읽으려면 Databricks Runtime 15.2 이상을 사용하도록 파이프라인을 구성해야 합니다.

다른 델타 테이블에서 변경 데이터 피드를 읽는 것과 동일한 방식으로 Lakeflow 파이프라인에서 만든 대상 스트리밍 테이블에서 변경 데이터 피드를 읽습니다. Python 및 SQL의 예제를 포함하여 델타 변경 데이터 피드 기능을 사용하는 방법에 대한 자세한 내용은 Azure Databricks 변경 데이터 피드 사용을 참조하세요.

메모

변경 데이터 피드 레코드에는 변경 이벤트 유형을 식별하는 메타데이터 가 포함됩니다. 테이블에서 레코드가 업데이트되면 연결된 변경 레코드에 대한 메타데이터에는 일반적으로 설정된 _change_type 값과 update_preimage 이벤트가 포함됩니다update_postimage.

그러나 _change_type 기본 키 값 변경을 포함하는 대상 스트리밍 테이블에 대한 업데이트가 이루어지면 값이 다릅니다. 기본 키 _change_type에 대한 업데이트가 변경 사항에 포함되면, 메타데이터 필드가 insert 및 delete 이벤트로 설정됩니다. 기본 키에 대한 변경은 키 필드를 UPDATE 또는 MERGE 문을 사용하여 수동으로 업데이트할 때, 또는 SCD 유형 2 테이블의 경우 __start_at 필드가 이전 시작 시퀀스 값을 반영하도록 변경되면서 발생할 수 있습니다.

쿼리는 AUTO CDC SCD 유형 1 및 SCD 형식 2 처리에 대해 다른 기본 키 값을 결정합니다.

SCD 형식	기본 키
SCD 형식 1 및 파이프라인 Python 인터페이스	기본 키는 함수의 `keys` 매개 변수 값입니다 `create_auto_cdc_flow()` . SQL 인터페이스의 경우 기본 키는 `KEYS` 절에서 `AUTO CDC ... INTO` 구문으로 정의된 열입니다.
SCD 형식 2	기본 키는 `keys` 매개 변수 또는 절과 `KEYS` 작업의 반환 값 `coalesce(__START_AT, __END_AT)` 입니다. 여기서 대상 스트리밍 테이블의 해당 열은 다음과 `__START_AT__END_AT` 같습니다. 사용할 수 있으면 `__START_AT`를 사용하고, `__END_AT`가 null인 경우(예: 초기 레코드)에는 `__START_AT`를 사용합니다.

머티리얼라이즈드 뷰에서 변경 데이터 피드 읽기

Important

이 기능은 베타 버전으로 제공됩니다.

Lakeflow 파이프라인이나 Databricks SQL에서 생성된 물질화된 뷰에서 변경 데이터 피드를 읽을 수 있습니다. 이를 사용해 Azure Databricks 외부의 목적지로 물질화된 뷰 변경 사항을 복제하거나, 감사 및 보고를 위한 물질화된 뷰 변경 이력을 유지할 수 있습니다.

Materialized View는 자동 변경 데이터 피드를 사용하기 때문에 변경 데이터 피드 자체를 켤 필요가 없습니다. 대신, 다음 요구 사항을 충족하여 필요한 각 구체화된 뷰에서 변경 데이터 피드를 활성화합니다. 자동 변경 데이터 피드를 참조하세요.

변경 데이터 피드를 읽으려면, 클래식 컴퓨트, 서버리스 컴퓨트, 또는 Databricks SQL에서 Databricks Runtime 18 LTS 이상을 사용해야 합니다.
물질화된 뷰, 그것을 생성하는 파이프라인, 또는 그것을 읽는 파이프라인은 반드시 그 채널을 PREVIEW 사용해야 합니다.
구체화된 뷰는 행 추적이 활성화되어 있어야 합니다. 서버리스 컴퓨트의 Materialized Views는 기본적으로 행 추적이 활성화되어 있습니다. Azure Databricks 행 추적을 참조하세요. 물질화된 뷰에서 행 추적이 활성화되어 있는지 확인하려면 다음을 실행하세요:
```
SHOW TBLPROPERTIES my_mv ('delta.enableRowTracking');
```
물질화된 뷰에서 변경 데이터 피드를 읽으려면, 파이프라인이나 물질화된 뷰에서 외부 메타데이터 플래그를 활성화하세요. 자세한 내용은 ' 데이터 세트 접근 권한 활성화 방법'을 참조하세요.

구체화된 뷰의 변경 데이터 피드는 table_changes() 함수, 스트리밍 읽기 또는 readChangeFeed 옵션을 사용하여 다른 Delta 테이블에서 읽는 것과 동일한 방식으로 읽습니다. SQL과 Python의 문법과 예제는 Azure Databricks에서 Change data 피드 사용하기를 참조하세요.

Databricks SQL 시각화 뷰나 스트리밍 테이블 내에서 물질화된 뷰 변경 데이터 피드를 읽을 수 있습니다:

CREATE OR REFRESH STREAMING TABLE sales
  AS SELECT * FROM STREAM my_mv WITH (readChangeFeed=true)

Limitations

자동 변경 데이터 피드 제한 외에도, Materialized View에서 변경 데이터 피드를 읽을 때 다음과 같은 제한이 적용됩니다:

변경 데이터 피드는 물질화된 뷰가 완전히 재작성되었을 때 변경되지 않은 행을 포함하며, 같은 행에 대한 여러 업데이트를 단일 이벤트로 통합하지 않습니다. 이를 걸러내기 위해 모든 열을 그룹화하여 동일한 행 값을 공유하는 삽입 및 삭제를 찾아 변경 데이터 피드를 집계하세요.
오직 Azure Databricks만이 Materialized View를 위해 변경 데이터 피드를 쿼리할 수 있습니다. 델타 레이크와 아이스버그 외부 고객은 그렇지 않습니다.
Lakeflow 파이프라인 내에서는 다른 파이프라인에서만 물질화된 뷰 변경 데이터 피드를 읽을 수 있으며, 그 파이프라인은 반드시 해당 채널을 PREVIEW 사용해야 합니다. 동일한 파이프라인에서 Materialized View의 변경 데이터 피드를 읽는 것은 지원되지 않습니다.
물질화된 뷰에서 벡터 검색 인덱스를 만들 수는 없습니다.

파이프라인의 CDC 쿼리에서 처리된 레코드에 대한 데이터 가져오기

메모

다음 메트릭은 AUTO CDC 쿼리에 의해서만 캡처되며, AUTO CDC FROM SNAPSHOT 쿼리에는 포함되지 않습니다.

AUTO CDC가 쿼리를 통해 다음과 같은 메트릭을 캡처합니다.

num_upserted_rows: 업데이트 중에 데이터 세트에 삽입된 출력 행의 수입니다.
num_deleted_rows: 업데이트 중에 데이터 세트에서 삭제된 기존 출력 행의 수입니다.

num_output_rows 비CDC 흐름에 대한 출력 메트릭은 AUTO CDC 쿼리에서 캡처되지 않습니다.

부분 업데이트 적용

소스가 변경된 열만 보내는 경우, AUTO CDC는 변경 레코드에 없는 열로서 대상 값을 변경하지 않은 상태로 두어야 하는 경우와, 명시적으로 null로 설정되어 대상 값을 null로 덮어써야 하는 열을 구분해야 합니다. 기본적으로 IGNORE NULL UPDATES 모든 null 항목을 "업데이트 안 함" 표식으로 처리하므로 명시적 null을 적용할 수 없습니다. 이 모호성을 해결하려면 다음 세 가지 방법 중 하나를 선택합니다.

Method	사용 시기	작동 방식
`IGNORE NULL UPDATES ON columnList`	작은 고정 열 집합은 `null` 값을 무시해야 하며, 반면 다른 모든 열은 명시적 `null` 값을 적용해야 합니다.	나열된 열은 들어오는 값이 있는 경우 기존 대상 값을 `null`유지합니다. 다른 모든 열은 명시적 `null` 값을 적용합니다.
`IGNORE NULL UPDATES ON * EXCEPT (exceptColumnList)`	대부분의 열은 `null` 값을 무시해야 하며, 소수의 열만 명시적 `null` 값을 적용해야 합니다.	나열된 열은 명시적 `null` 값을 적용합니다. 들어오는 값이 있는 경우 다른 모든 열은 `null`기존 대상 값을 유지합니다.
`COLUMNS TO UPDATE`	각 변경 레코드는 다른 열 집합을 업데이트하거나 업데이트할 수 있는 열 집합이 시간에 따라 변경됩니다.	원본 열은 각 변경 레코드에 대해 업데이트할 열의 이름을 지정합니다. 나열된 열은 명시적 `null` 값을 포함하여 원본에서 작성됩니다. 나열되지 않은 열은 기존 대상 값을 유지합니다.

COLUMNS TO UPDATE은(는) IGNORE NULL UPDATES과(와) 함께 사용할 수 없으며, 이중 시간 테이블에서는 지원되지 않습니다.

일반적으로 생산자가 각 레코드에서 변경된 열을 알고 여러 생산자가 동일한 원본에 쓰는 경우 또는 업데이트할 수 있는 열 집합이 시간이 지남에 따라 증가하는 경우와 같이 원본 열에 해당 정보를 전달할 수 있는 시기를 선택합니다 COLUMNS TO UPDATE . 파이프라인 소유자가 고정된 변경 가능한 열 집합을 미리 알고 파이프라인 코드에서 제어하는 것을 선호하는 경우를 선택합니다 IGNORE NULL UPDATES ON .

다음 예제에서는 columnsToUpdate라는 이름의 소스 열을 사용하여 명시적으로 null로 설정된 열을 포함해 각 변경 레코드가 업데이트할 열을 제어합니다.

Python

from pyspark import pipelines as dp

dp.create_streaming_table("target")

dp.create_auto_cdc_flow(
  target = "target",
  source = "cdc_source",
  keys = ["id"],
  sequence_by = "sequenceNum",
  stored_as_scd_type = 1,
  columns_to_update = "columnsToUpdate"
)

SQL

CREATE OR REFRESH STREAMING TABLE target;

CREATE FLOW apply_cdc AS AUTO CDC INTO
  target
FROM
  stream(cdc_source)
KEYS
  (id)
SEQUENCE BY
  sequenceNum
STORED AS
  SCD TYPE 1
COLUMNS TO UPDATE
  columnsToUpdate;

전체 매개 변수 참조는 AUTO CDC INTO(파이프라인) 및 create_auto_cdc_flow 참조하세요.

이중 시간 AUTO CDC

Important

Bitemporal AUTO CDC는 베타에 있습니다.

SCD 유형 1 및 형식 2는 단일 시간 차원의 변경 내용을 추적합니다. Bitemporal은 SCD Type 2 기록을 확장하여 두 시간 차원의 변경 내용을 추적하고 두 가지 관점을 구분합니다.

비즈니스 시간: 이벤트가 실제로 발생한 경우.
시스템 시간: 시스템이 이벤트를 기록하거나 수집한 경우입니다.

SCD Type 2와 마찬가지로 바이템포럴은 레코드의 전체 이력을 보존합니다. 두 번째 타임라인을 추가하여 데이터가 보여 준 내용과 시스템이 과거의 어느 시점에서 무엇을 믿었는지를 다시 구성할 수 있습니다.

예를 들어 헤지 펀드는 원본 시스템에서 주식 데이터를 수집합니다. Acme Corp의 주가는 1월 1일에 변경되지만 펀드는 1월 5일까지 해당 업데이트를 수집하지 않습니다. Bitemporal AUTO CDC는 펀드가 두 가지 질문에 대답 할 수 있습니다 : Acme Corp의 실제 주가가 1 월 1 일 (영업 시간)에 무엇이었는지, 그리고 펀드가 1 월 3 일에 거래 결정을 내렸을 때 시스템이 믿는 가격 (시스템 시간). 이러한 타임라인을 구분하는 기능은 감사, 규제 보고 및 재무 의사 결정에 유용합니다.

이중 시간 처리를 사용하려면 STORED AS BITEMPORAL (SQL) 또는 stored_as_scd_type="bitemporal" (Python)을 설정하고, 비즈니스 시간 열에는 SEQUENCE BY를 사용하며 시스템 시간 열에는 SYSTEM SEQUENCE BY를 사용합니다. 대상 테이블은 SCD 유형 2 __SYSTEM_START_AT 및 __SYSTEM_END_AT 열과 함께 __START_AT 및 __END_AT 열을 추가합니다. 구문 세부 정보를 보려면 AUTO CDC INTO (파이프라인) 또는 create_auto_cdc_flow를 참조하세요.

Bitemporal AUTO CDC 예제

다음 예제에서는 소규모 합성 CDC 이벤트 집합에서 이중 시간 대상 테이블을 만듭니다. 열에는 bt 비즈니스 시간이 있고 열에는 st 시스템 시간이 있습니다.

Python

from pyspark import pipelines as dp

# Source: synthetic CDC events
dp.create_streaming_table(name="cdc_source")

@dp.append_flow(target="cdc_source", once=True)
def load_cdc_source():
  return spark.createDataFrame(
    [
      (1, "x10", "y10", 10, 100),
      (1, "x20", "y20", 20, 200)
    ],
    schema="id INT, x STRING, y STRING, bt INT, st INT",
  )

# Target: bitemporal table
dp.create_streaming_table(name="target_bitemporal")

dp.create_auto_cdc_flow(
  target = "target_bitemporal",
  source = "cdc_source",
  keys = ["id"],
  sequence_by = "bt",
  system_sequence_by = "st",
  stored_as_scd_type = "bitemporal"
)

SQL

-- Source: synthetic CDC events
CREATE OR REFRESH STREAMING TABLE cdc_source_sql;

CREATE FLOW cdc_source_sql AS INSERT INTO ONCE
  cdc_source_sql BY NAME
SELECT * FROM VALUES
  (1, 'x10', 'y10', 10, 100),
  (1, 'x20', 'y20', 20, 200)
  AS t(id, x, y, bt, st);

-- Target: bitemporal table
CREATE OR REFRESH STREAMING TABLE target_bitemporal_sql;

CREATE FLOW target_bitemporal_sql AS AUTO CDC INTO
  target_bitemporal_sql
FROM
  stream(cdc_source_sql)
KEYS
  (id)
SEQUENCE BY
  bt
SYSTEM SEQUENCE BY
  st
STORED AS
  BITEMPORAL;

다음 변경 순서는 이중 시간 테이블이 단일 회사에 대해 삽입, 업데이트, 비순차 업데이트 및 삭제를 기록하는 방식을 보여줍니다. 시퀀싱 열은 __START_AT 및 __END_AT 열(비즈니스 시간)을 생성하고, 시스템 시퀀싱 열은 __SYSTEM_START_AT 및 __SYSTEM_END_AT 열(시스템 시간)을 생성합니다:

Column	Description
`__START_AT`	이 행이 유효해진 비즈니스 시간입니다.
`__END_AT`	이 행의 유효성이 종료되는 비즈니스 시간입니다. `null` 무기한으로 유효한 경우.
`__SYSTEM_START_AT`	이 행의 데이터와 비즈니스 시간 구간이 참인 것으로 알려진 시스템 시간입니다.
`__SYSTEM_END_AT`	이 행의 데이터와 비즈니스 시간 간격이 유효하지 않은 것으로 확인된 시스템 시간입니다. `null` 영구적으로 참인 것으로 알려진 경우.

시스템은 두 타임라인에서 순서에 관계없이 도착하는 이벤트를 처리합니다. 이벤트가 이미 처리된 이벤트들보다 더 이른 업무 시간 또는 시스템 시간으로 도착하면, 시스템은 단순히 끝에만 추가하는 대신 영향을 받는 이력을 수정합니다.

변경 1: 삽입

A사는 2025년 7월 18일 10:01:00(업무 시간)에 추가되지만 10:05:00(시스템 시간)까지 수집되지 않습니다.

입력:

회사 ID	데이터 요소	시퀀싱	시스템 시퀀싱	Operation
A	XFv1	7/18/2025 10:01:00	7/18/2025 10:05:00	`INSERT`

Output:

회사 ID	데이터 요소	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NULL	7/18/2025 10:05:00	NULL

XFv1은 알려진 종료 없이 10:01:00부터 유효합니다. 시스템은 알려진 종료 없이 시스템 시간 10:05:00에 이 사실을 알게 되었습니다.

변경 2: 업데이트

A사는 2025년 7월 18일 12:15:43(업무 시간)에 업데이트되고 시스템은 12:20:00(시스템 시간)에 이벤트를 사용합니다. 시스템은 업데이트가 알려지기 전에 믿은 내용과 업데이트가 수집된 후 수정된 비즈니스 기록을 모두 유지합니다.

입력:

회사 ID	데이터 요소	시퀀싱	시스템 시퀀싱	Operation
A	XFv2	7/18/2025 12:15:43	7/18/2025 12:20:00	`UPDATE`

Output:

회사 ID	데이터 요소	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NULL	7/18/2025 10:05:00	7/18/2025 12:20:00
A	XFv1	7/18/2025 10:01:00	7/18/2025 12:15:43	7/18/2025 12:20:00	NULL
A	XFv2	7/18/2025 12:15:43	NULL	7/18/2025 12:20:00	NULL

XFv1은 알려진 끝없이 10:01:00부터 유효한 것으로 생각되었으며, 시스템은 10:05:00부터 12:20:00까지 그 믿음을 유지했습니다. XFv1은 이제 12:15:43까지만 유효한 것으로 확인되었으며, 시스템 시간 12:20:00부터 적용되는 종료 시점이 알려지지 않은 수정된 이력이 있습니다. XFv2는 알려진 종료 없이 12:15:43부터 유효하며 시스템 시간 12:20:00에 학습되었습니다.

변경 3: 순서가 바뀐 업데이트

A사가 실제로 2025년 7월 18일 12:05:00(업무 시간)에 업데이트되었음을 나타내는 주문 외 업데이트가 도착하지만 12:25:00(시스템 시간)까지 수집되지 않습니다. 업데이트가 시스템 시간상 나중에 도착했지만 비즈니스 시간상 더 이른 시점을 반영하는 경우, 시스템은 과거의 비즈니스 시간 이력을 수정하고 순서가 뒤바뀐 업데이트가 도착하기 전에 가지고 있던 내용과 수정된 이력을 모두 보존합니다.

입력:

회사 ID	데이터 요소	시퀀싱	시스템 시퀀싱	Operation
A	XFv3	7/18/2025 12:05:00	7/18/2025 12:25:00	`UPDATE`

Output:

회사 ID	데이터 요소	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NULL	7/18/2025 10:05:00	7/18/2025 12:20:00
A	XFv1	7/18/2025 10:01:00	7/18/2025 12:15:43	7/18/2025 12:20:00	7/18/2025 12:25:00
A	XFv1	7/18/2025 10:01:00	7/18/2025 12:05:00	7/18/2025 12:25:00	NULL
A	XFv3	7/18/2025 12:05:00	7/18/2025 12:15:43	7/18/2025 12:25:00	NULL
A	XFv2	7/18/2025 12:15:43	NULL	7/18/2025 12:20:00	NULL

XFv1은 10:01:00에서 12:15:43까지 유효하다고 생각되었으며, 이제 시스템 시간에서 12:25:00까지 유효합니다. 새 업데이트는 XFv1의 비즈니스 유효성을 시스템 시간 12:25:00부터 적용된 수정된 기록인 12:05:00에 종료하도록 수정합니다. XFv3은 이제 12:05:00부터 12:15:43까지 유효한 것으로 알려져 있으며, 이 판단은 시스템 시간으로 12:25:00부터 시작되어 종료 시점은 알려져 있지 않습니다.

변경 4: 삭제

A사는 2025년 7월 18일 12:30:00에 삭제되고 시스템은 12:30:00에 이벤트를 사용합니다. 삭제 작업은 엔터티의 비즈니스 존재 종료를 나타내므로 시스템에서 대체 행을 생성하지 않습니다. XFv2는 두 행에 표시되며, 회사가 존재하지 않을 때와 시스템이 삭제를 알게 되었을 때의 전체 감사 내역을 유지합니다.

입력:

회사 ID	데이터 요소	시퀀싱	시스템 시퀀싱	Operation
A	XFv2	7/18/2025 12:30:00	7/18/2025 12:30:00	`DELETE`

Output:

회사 ID	데이터 요소	__START_AT	__END_AT	__SYSTEM_START_AT	__SYSTEM_END_AT
A	XFv1	7/18/2025 10:01:00	NULL	7/18/2025 10:05:00	7/18/2025 12:20:00
A	XFv1	7/18/2025 10:01:00	7/18/2025 12:15:43	7/18/2025 12:20:00	7/18/2025 12:25:00
A	XFv1	7/18/2025 10:01:00	7/18/2025 12:05:00	7/18/2025 12:25:00	NULL
A	XFv3	7/18/2025 12:05:00	7/18/2025 12:15:43	7/18/2025 12:25:00	NULL
A	XFv2	7/18/2025 12:15:43	NULL	7/18/2025 12:20:00	7/18/2025 12:30:00
A	XFv2	7/18/2025 12:15:43	7/18/2025 12:30:00	7/18/2025 12:30:00	NULL

XFv2는 알려진 끝 없이 12:15:43부터 유효했으며, 시스템은 12:20:00에서 12:30:00까지 그 믿음을 유지했습니다. 삭제가 반영되면 XFv2는 12:30:00까지만 유효한 것으로 간주되며, 시스템 시간 12:30:00부터는 수정된 이력이 적용됩니다.

파이프라인에서 CDC 처리에 사용되는 데이터 개체는 무엇인가요?

Hive 메타스토어에서 대상 테이블을 선언하면 두 개의 데이터 구조가 만들어집니다.

대상 테이블에 할당된 이름을 사용하는 뷰입니다.
파이프라인에서 CDC 처리를 관리하는 데 사용하는 내부 지원 테이블입니다. 이 테이블의 이름은 대상 테이블 이름 앞에 추가하여 __apply_changes_storage_ 지정됩니다.

예를 들어 이름이 지정된 dp_cdc_target대상 테이블을 선언하면 메타스토어에 명명된 dp_cdc_target 뷰와 테이블이 __apply_changes_storage_dp_cdc_target 표시됩니다. 뷰를 쿼리하여 처리된 데이터에 액세스합니다. 백업 테이블을 직접 수정하지 마세요.

메모

이러한 데이터 구조는 AUTO CDC 처리에만 적용되며, AUTO CDC FROM SNAPSHOT 처리에는 적용되지 않습니다. 또한 Unity 카탈로그가 아닌 Hive 메타스토어에도 적용됩니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-08-24

고급 AUTO CDC 항목

대상 스트리밍 테이블에서 데이터 추가, 변경 또는 삭제

AUTO CDC 대상 테이블에서 변경 데이터 피드 읽기

머티리얼라이즈드 뷰에서 변경 데이터 피드 읽기

Limitations

파이프라인의 CDC 쿼리에서 처리된 레코드에 대한 데이터 가져오기

부분 업데이트 적용

Python

SQL

이중 시간 AUTO CDC

Bitemporal AUTO CDC 예제

Python

SQL

파이프라인에서 CDC 처리에 사용되는 데이터 개체는 무엇인가요?

피드백

추가 리소스