Azure Databricks에서 ACID 보장이란?
Azure Databricks는 오픈 소스 Delta Lake 프로토콜에서 제공하는 ACID 보증에 따라 모든 읽기 및 쓰기 및 빌드에 기본적으로 Delta Lake를 사용합니다. ACID는 원자성, 일관성, 격리 및 영속성을 나타냅니다.
- 원자성은 모든 트랜잭션이 성공하거나 완전히 실패함을 의미합니다.
- 일관성은 데이터의 지정된 상태가 동시 작업에 의해 관찰되는 방식과 관련이 있습니다.
- 격리는 동시 작업이 잠재적으로 서로 충돌하는 방식을 나타냅니다.
- 영속성은 커밋된 변경 내용이 영구적임을 의미합니다.
많은 데이터 처리 및 웨어하우징 기술이 ACID 트랜잭션을 보유히고 있다고 설명하지만 구체적인 보장은 시스템에 따라 다르며 Azure Databricks의 트랜잭션은 작업해 본 다른 시스템과 다를 수 있습니다.
참고 항목
이 페이지에서는 Delta Lake에서 백업된 테이블에 대한 보장을 설명합니다. 다른 데이터 형식 및 통합 시스템은 읽기 및 쓰기에 대한 트랜잭션 보장을 제공하지 않을 수 있습니다.
클라우드 개체 스토리지에 대한 모든 Azure Databricks 쓰기는 트랜잭션 커밋을 사용하며, _started_<id> 및 _committed_<id>로 시작하는 메타데이터 파일과 함께 데이터 파일을 만듭니다. Azure Databricks는 부실 커밋 메타데이터 파일을 정기적으로 정리하므로 이러한 파일과 상호 작용할 필요가 없습니다.
Azure Databricks에서 트랜잭션 범위는 어떻게 지정합니까?
Azure Databricks는 테이블 수준에서 트랜잭션을 관리합니다. 트랜잭션은 항상 한 번에 하나의 테이블에 적용됩니다. Azure Databricks는 동시 트랜잭션을 관리하기 위해 낙관적 동시성 제어를 사용합니다. 즉, 테이블에 대한 읽기 또는 쓰기에 대한 잠금이 없으며 교착 상태는 가능하지 않습니다.
기본적으로 Azure Databricks는 읽기에 대한 스냅샷 격리 및 쓰기에 대한 쓰기 직렬화 가능 격리를 제공합니다. 쓰기 직렬화 가능 격리는 스냅샷 격리보다 더 강력한 보장을 제공하지만 쓰기에 대해서만 더 강력한 격리를 적용합니다.
여러 테이블을 참조하는 읽기 작업은 액세스 시 각 테이블의 현재 버전을 반환하지만 참조된 테이블을 수정할 수 있는 동시 트랜잭션을 중단하지는 않습니다.
Azure Databricks에는 여러 작업을 단일 트랜잭션으로 그룹화할 수 있는 BEGIN/END 구문이 없습니다. 여러 테이블을 수정하는 애플리케이션은 직렬 방식으로 각 테이블에 트랜잭션을 커밋합니다. MERGE INTO를 사용하여 테이블에 대한 삽입, 업데이트 및 삭제를 단일 쓰기 트랜잭션으로 결합할 수 있습니다.
Azure Databricks는 원자성을 어떻게 구현하나요?
트랜잭션 로그가 커밋 원자성을 제어합니다. 트랜잭션 중에 데이터 파일은 테이블을 지원하는 파일 디렉터리에 기록됩니다. 트랜잭션이 완료되면 트랜잭션 중에 작성된 모든 파일의 경로를 포함하는 트랜잭션 로그에 새 항목이 커밋됩니다. 각 커밋은 테이블 버전을 증가시키고 새 데이터 파일을 읽기 작업에 표시합니다. 테이블의 현재 상태는 트랜잭션 로그에서 유효한 것으로 표시된 모든 데이터 파일로 구성됩니다.
트랜잭션 로그가 새 버전을 기록하지 않는 한 데이터 파일은 추적되지 않습니다. 테이블에 데이터 파일을 쓴 후 트랜잭션이 실패하면 이러한 데이터 파일은 테이블 상태를 손상시키지 않지만 파일은 테이블의 일부가 되지 않습니다. 이 VACUUM 작업은 실패한 트랜잭션에서 커밋되지 않은 나머지 파일을 포함하여 테이블 디렉터리의 추적되지 않은 모든 데이터 파일을 삭제합니다.
Azure Databricks는 내구성을 어떻게 구현하나요?
Azure Databricks는 클라우드 개체 스토리지를 사용하여 모든 데이터 파일 및 트랜잭션 로그를 저장합니다. 클라우드 개체 스토리지에는 고가용성 및 높은 내구성이 포함됩니다. 트랜잭션이 완전히 성공하거나 실패하고 트랜잭션 로그가 클라우드 개체 스토리지의 데이터 파일과 함께 사용되므로 Azure Databricks의 테이블은 저장되는 클라우드 개체 스토리지의 내구성 보장을 상속합니다.
Azure Databricks는 일관성을 어떻게 구현하나요?
Delta Lake는 낙관적 동시성 제어를 사용하여 쓰기 간의 트랜잭션 보장을 제공합니다. 이 메커니즘에서 쓰기는 세 단계로 작동합니다.
- 읽기: 수정(즉, 다시 작성)해야 하는 파일을 식별하기 위해 사용 가능한 최신 버전의 테이블을 읽습니다(필요한 경우).
- 추가 전용인 쓰기는 쓰기 전에 현재 테이블 상태를 읽지 않습니다. 스키마 유효성 검사는 트랜잭션 로그의 메타데이터를 활용합니다.
- 쓰기: 테이블을 정의하는 데 사용되는 디렉터리에 데이터 파일을 씁니다.
- 유효성 검사 및 커밋:
- 제안된 변경 내용이 읽은 스냅샷 이후에 동시에 커밋되었을 수 있는 다른 변경 내용과 충돌하는지 검사합니다.
- 충돌이 없으면 모든 단계적 변경 내용이 새 버전의 스냅샷으로 커밋되고 쓰기 작업이 성공합니다.
- 충돌이 있는 경우 동시 수정 예외로 인해 쓰기 작업이 실패합니다. 이 오류는 데이터 손상을 방지합니다.
낙관적 동시성은 데이터에서 대부분의 동시 트랜잭션이 서로 충돌할 수 없다고 가정하지만 충돌은 발생할 수 있습니다. Azure Databricks의 격리 수준 및 쓰기 충돌을 참조하세요.
Azure Databricks는 격리를 어떻게 구현하나요?
Azure Databricks는 모든 테이블 쓰기 및 업데이트에 대해 기본값으로 직렬화 가능한 쓰기 격리를 사용합니다. 스냅샷 격리는 모든 테이블 읽기에 사용됩니다.
쓰기 직렬화 가능성 및 낙관적 동시성 제어는 함께 작동하여 쓰기에 대한 높은 처리량을 제공합니다. 테이블의 현재 유효한 상태는 항상 사용할 수 있으며 쓰기는 테이블에 대해 언제든지 시작될 수 있습니다. 동시 읽기는 메타스토어 및 클라우드 리소스의 처리량에 의해서만 제한됩니다.
Azure Databricks의 격리 수준 및 쓰기 충돌을 참조하세요.
Delta Lake는 다중 테이블 트랜잭션을 지원하나요?
Delta Lake는 다중 테이블 트랜잭션을 지원하지 않습니다. Delta Lake는 테이블 수준에서 트랜잭션을 지원합니다.
Azure Databricks에서 기본 키 및 외래 키 관계는 정보용이며 적용되지는 않습니다. 기본 키 및 외래 키 관계 선언을 참조하세요.
Delta Lake에서 다중 클러스터 쓰기를 지원한다는 것은 무엇을 의미하나요?
Delta Lake는 여러 클러스터가 동일한 테이블에 동시에 쓸 때 데이터 손상을 방지합니다. 일부 쓰기 작업은 동시 실행 중에 충돌할 수 있지만 테이블을 손상시키지 않습니다. Azure Databricks의 격리 수준 및 쓰기 충돌을 참조하세요.
다른 작업 영역에서 Delta 테이블을 수정할 수 있나요?
예, 다른 작업 영역에서 동일한 델타 테이블을 동시에 수정할 수 있습니다. 또한 한 프로세스가 작업 영역에서 쓰는 경우 다른 작업 영역의 판독기는 일관된 보기를 볼 수 있습니다.