행 수준 동시성

행 수준 동시성은 행 수준에서 변경 내용을 검색하고 동시 쓰기가 동일한 데이터 파일에서 다른 행을 업데이트하거나 삭제할 때 발생하는 충돌을 자동으로 해결하여 동시 쓰기 작업 간의 충돌을 줄입니다.

행 수준 동시성에 대한 요구 사항

다음 요구 사항을 모두 충족하면 행 수준 동시성이 자동으로 활성화됩니다.

분할된 테이블은 행 수준 동시성을 허용하지 않습니다. 그러나 삭제 벡터가 활성화된 경우에도 분할된 테이블은 OPTIMIZE와 쓰기 작업 간의 충돌을 여전히 방지할 수 있습니다. 행 수준 동시성에 대한 제한 사항을 참조 하세요.

14.3 LTS 이전의 Databricks 런타임 버전은 행 수준 동시성 레거시 동작을 참조하세요.

행 수준 동시성을 사용하는 충돌 행렬

행 단위 동시성이 있는 소스 테이블의 경우, 다음 표는 각 격리 레벨에서 동시 쓰기 연산 쌍이 어떻게 동작하는지 보여줍니다.

동시 메타데이터 변경은 테이블 내 모든 결과에 대한 예외입니다. 테이블 스키마를 업데이트하는 명령이나 쓰기와 같은 ALTER TABLE 메타데이터 변경은 모든 동시 쓰기 작업이 실패할 수 있으며, 여기에는 INSERT. 메타데이터 변경 충돌을 참조하세요.

연산 쌍 WriteSerializable(기본값) 직렬화 가능
INSERT (1) + INSERT 충돌할 수 없음 충돌할 수 없음
INSERT + UPDATE, 삭제, MERGE INTO 충돌할 수 없음 동일한 행을 수정할 때 충돌할 수 있습니다. UPDATE, DELETE, 또는 MERGE 연산이 실패하는 것이 아니INSERT라, .
INSERT + OPTIMIZE 충돌할 수 없음 충돌할 수 없음
UPDATE, 삭제, MERGE INTO + UPDATE, 삭제, MERGE INTO 같은 행을 수정할 때 충돌이 발생할 수 있습니다 같은 행을 수정할 때 충돌이 발생할 수 있습니다
UPDATE, 삭제, MERGE INTO + OPTIMIZE ZORDER BY가 사용될 때 충돌이 발생할 수 있습니다. 그렇지 않으면 충돌할 수 없습니다. ZORDER BY가 사용될 때 충돌이 발생할 수 있습니다. 그렇지 않으면 충돌할 수 없습니다.
OPTIMIZE + OPTIMIZE ZORDER BY가 사용될 때 충돌이 발생할 수 있습니다. 그렇지 않으면 충돌할 수 없습니다. ZORDER BY가 사용될 때 충돌이 발생할 수 있습니다. 그렇지 않으면 충돌할 수 없습니다.

(1) 이 테이블의 모든 INSERT 작업은 동일한 테이블에서 데이터를 읽는 하위 쿼리를 포함하지 않는 추가 작업을 설명합니다. INSERT 동일한 테이블에서 읽는 하위 쿼리를 포함하는 작업은 MERGE와 동일한 수준의 동시성을 지원합니다.

메모

  • 쌍이 충돌할 수 있을 때, 영향을 받은 데이터를 읽는 연산만 실패합니다. INSERT 테이블을 읽지 않고 데이터를 추가하는 연산은 실패하지 않으므로, 재시도 로직은 동시 UPDATE, DELETE, 에 MERGE속해야 합니다.
  • ID 열이 있는 테이블은 동시 트랜잭션을 지원하지 않습니다. ID 열을 참조하세요.
  • REORG 작업에는 데이터 파일을 다시 쓸 때와 동일한 OPTIMIZE 격리 의미 체계가 있습니다. REORG 사용하여 업그레이드를 적용하면 테이블 프로토콜이 변경되어 진행 중인 모든 작업과 충돌합니다.

행 수준 동시성 없이 발생하는 쓰기 충돌

행 수준 동시성이 없는 소스 테이블의 경우, 다음 표는 각 격리 레벨에서 동시 쓰기 연산 쌍이 어떻게 동작하는지 보여줍니다.

동시 메타데이터 변경은 테이블 내 모든 결과에 대한 예외입니다. 테이블 스키마를 업데이트하는 명령이나 쓰기와 같은 ALTER TABLE 메타데이터 변경은 모든 동시 쓰기 작업이 실패할 수 있으며, 여기에는 INSERT. 메타데이터 변경 충돌을 참조하세요.

연산 쌍 WriteSerializable(기본값) 직렬화 가능
INSERT (1) + INSERT 충돌할 수 없음 충돌할 수 없음
INSERT + UPDATE, 삭제, MERGE INTO 충돌할 수 없음 충돌이 있을 수 있습니다. UPDATE, DELETE, 또는 MERGE 연산이 실패하는 것이 아니INSERT라, . 분할을 사용하여 충돌 방지를 참조하세요.
INSERT + OPTIMIZE 충돌할 수 없음 충돌할 수 없음
UPDATE, 삭제, MERGE INTO + UPDATE, 삭제, MERGE INTO 충돌이 있을 수 있습니다. 분할을 사용하여 충돌 방지를 참조하세요. 충돌이 있을 수 있습니다. 분할을 사용하여 충돌 방지를 참조하세요.
UPDATE, 삭제, MERGE INTO + OPTIMIZE 사용되지 않는 한 ZORDER BY 삭제 벡터가 활성화된 테이블에서 충돌할 수 없습니다. 그렇지 않으면 충돌할 수 있습니다. 사용되지 않는 한 ZORDER BY 삭제 벡터가 활성화된 테이블에서 충돌할 수 없습니다. 그렇지 않으면 충돌할 수 있습니다.
OPTIMIZE + OPTIMIZE 사용되지 않는 한 ZORDER BY 삭제 벡터가 활성화된 테이블에서 충돌할 수 없습니다. 그렇지 않으면 충돌할 수 있습니다. 사용되지 않는 한 ZORDER BY 삭제 벡터가 활성화된 테이블에서 충돌할 수 없습니다. 그렇지 않으면 충돌할 수 있습니다.

(1) 이 테이블의 모든 INSERT 작업은 동일한 테이블에서 데이터를 읽는 하위 쿼리를 포함하지 않는 추가 작업을 설명합니다. INSERT 동일한 테이블에서 읽는 하위 쿼리를 포함하는 작업은 MERGE와 동일한 수준의 동시성을 지원합니다.

메모

  • 쌍이 충돌할 수 있을 때, 영향을 받은 데이터를 읽는 연산만 실패합니다. INSERT 테이블을 읽지 않고 데이터를 추가하는 연산은 실패하지 않으므로, 재시도 로직은 동시 UPDATE, DELETE, 에 MERGE속해야 합니다.
  • ID 열이 있는 테이블은 동시 트랜잭션을 지원하지 않습니다. ID 열을 참조하세요.
  • REORG 작업에는 데이터 파일을 다시 쓸 때와 동일한 OPTIMIZE 격리 의미 체계가 있습니다. 업그레이드를 적용하는 데 사용하면 REORG 테이블 프로토콜이 변경되고 진행 중인 모든 작업과 충돌합니다.

행 수준 동시성에 대한 제한 사항

행 수준 동시성에는 제한이 적용됩니다. 다음 작업의 경우 충돌 해결은 쓰기 충돌의 일반적인 동시성을 따릅니다. 행 수준 동시성이 없는 쓰기 충돌을 참조 하세요.

Limitation 설명
복잡한 조건부 절 복잡한 데이터 형식(구조체, 배열, 맵), 비결정적 식, 하위 쿼리 및 상관 하위 쿼리에 대한 조건
MERGE 판별 조건 요구 사항 Databricks Runtime 14.2 MERGE 에서 명령은 대상 테이블에서 명시적 조건자를 사용하여 원본 테이블과 일치하는 행을 필터링해야 합니다.
성능 절충 행 수준 충돌 검색은 총 실행 시간을 늘릴 수 있습니다. 많은 동시 트랜잭션이 있는 경우, 작성자는 충돌 해결보다 대기 시간을 우선시합니다.

삭제 벡터에 대한 모든 제한 사항도 적용됩니다. 제한 사항을 참조하세요.

분할을 사용하여 충돌 방지

충돌 행렬에서 "충돌 가능"으로 표시된 모든 경우 두 작업이 동일한 파일 집합에 영향을 미치는 경우에만 충돌이 발생합니다. 두 파일 집합을 연결 해제하려면 작업 조건에 사용되는 동일한 열로 테이블을 분할합니다.

Example:

테이블이 날짜별로 UPDATE table WHERE date > '2010-01-01' ... 분할되지 않은 경우 명령과 DELETE table WHERE date < '2010-01-01' 충돌합니다. 둘 다 동일한 파일을 수정하려고 시도할 수 있기 때문입니다. 테이블을 분할하여 date 충돌을 방지합니다.

메모

카디널리티가 높은 열을 기준으로 테이블을 분할하면 많은 수의 하위 디렉터리로 인해 성능 문제가 발생할 수 있습니다.

명시적 파티션 필터와의 충돌 방지

이 예외는 종종 동시 DELETEUPDATE또는 MERGE 다른 파티션을 업데이트하는 경우에도 동일한 파티션을 읽을 수 있는 작업 중에 발생합니다. 작업 조건에서 구분을 명시적으로 지정합니다.

// Problem: Condition can scan the entire table
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

// Solution: Add explicit partition filters
deltaTable.as("t").merge(
    source.as("s"),
    "s.user_id = t.user_id AND s.date = t.date AND s.country = t.country AND t.date = '" + date + "' AND t.country = '" + country + "'")
  .whenMatched().updateAll()
  .whenNotMatched().insertAll()
  .execute()

충돌 예외

트랜잭션 충돌이 발생하면 다음 예외 중 하나가 관찰됩니다.

ConcurrentAppendException (동시 추가 예외)

이 예외는 동시 작업이 작업이 읽는 동일한 파티션(또는 분할되지 않은 테이블의 모든 위치)에 파일을 추가할 때 발생합니다. 파일 추가는 INSERT, DELETE, UPDATE 또는 MERGE 작업으로 인해 발생할 수 있습니다.

기본 WriteSerializable 격리 수준에서는 데이터를 전혀 읽지 않고 추가만 하는 INSERT 작업에 의해 추가된 파일이 어떤 작업과도 충돌하지 않습니다. 격리 수준이 직렬화 가능하면 추가가 충돌할 수 있습니다.

중요합니다

WriteSerializable 모드에서도 여러 개의 동시 DELETE, , UPDATEMERGE , 연산이 연산에 INSERT 추가된 값을 참조할 경우 충돌이 발생할 수 있습니다. DELETE, UPDATE, 또는 MERGE 연산이 실패하는 것은 덧붙인 데이터를 읽기 때문입니다. 이를 방지하려면 다음을 수행하세요:

  • 동시 DELETE또는 UPDATEMERGE 작업이 추가된 데이터를 읽지 않는지 확인
  • 추가된 데이터를 읽을 수 있는 작업 중 DELETE, UPDATE, 또는 MERGE 하나만 사용하세요.

ConcurrentDeleteReadException

이 예외는 동시 작업이 작업에서 읽은 파일을 삭제할 때 발생합니다. 일반적인 원인은 DELETE, UPDATE, 또는 MERGE와 같은 파일을 다시 작성하는 작업들입니다.

ConcurrentDeleteDeleteException

이 예외는 동시 작업에서 작업도 삭제하는 파일을 삭제할 때 발생합니다. 이는 동일한 파일을 다시 쓰는 두 개의 동시 압축 작업으로 인해 발생할 수 있습니다.

MetadataChangedException (메타데이터 변경 예외)

이 예외는 동시 트랜잭션이 델타 레이크 테이블의 메타데이터를 업데이트할 때 발생합니다. 일반적인 원인은 ALTER TABLE 테이블 스키마를 업데이트하는 작업 또는 쓰기입니다.

ConcurrentTransactionException (동시 거래 예외)

이 예외는 동일한 체크포인트 위치를 사용하는 스트리밍 쿼리가 여러 번 동시에 시작되고 동시에 델타 레이크 테이블에 쓰려 할 때 발생합니다. 동일한 검사점 위치를 동시에 사용하여 두 개의 스트리밍 쿼리를 실행하지 마세요.

ProtocolChangedException (프로토콜 변경 예외)

이 예외는 다음과 같은 경우에 발생할 수 있습니다.

  • Delta Lake 테이블이 새 프로토콜 버전으로 업그레이드되었습니다(Databricks 런타임을 업그레이드해야 할 수 있습니다).
  • 여러 작성자가 동시에 테이블을 만들거나 대체합니다.
  • 여러 작성자가 빈 파일 경로에 동시에 데이터를 기록하고 있습니다.

Delta Lake 기능 호환성 및 프로토콜을 참조하세요.

행 수준 동시성의 레거시 동작

Databricks Runtime 13.3 LTS에서 행 수준 동시성은 레거시 동작을 사용합니다.

추가 리소스

  • Last updated on