이 블로그는 최초로 blog.adipolak.com에 발표되었다.
이전 섹션에서는 ACID transactions가 무엇인지 이해했습니다.
이 섹션에서는 DeltaLog이라는 Delta 트랜잭션 로그가 ACID를 어떻게 구현하는지 살펴봅니다.

트랜잭션 로그

트랜잭션 로그는 TaDa가 수행한 작업의 기록입니다.💡) 데이터베이스 관리 시스템, 목표는 ACID properties이 붕괴될 때 정상적으로 운행하는 것이다.

DeltaLake 트랜잭션 로그 - DetlaLog

DeltaLog은 Delta Lake 테이블에서 제출한 각 트랜잭션의 질서정연한 기록을 저장하는 트랜잭션 로그 디렉토리입니다.
델타로그의 목표는 같은 표를 동시에 읽는 독자에게 유일한 진실의 출처를 제공하는 것이다.평행 카드 리더기가 읽는 데이터가 완전히 같다는 것이다.
이것은 DeltaLog에서 읽기, 삭제, 업데이트 등 사용자가 한 모든 변경 사항을 추적하는 것을 통해 이루어진다.
DeltaLog에는 데이터의 통계 정보도 포함될 수 있습니다.데이터/필드/열의 유형에 따라 열마다 최소값/최대값이 있을 수 있습니다.이러한 추가 메타데이터를 가지고 있으면 조회 속도를 가속화하는 데 도움이 된다.DeltaTable 읽기 메커니즘은 단순화push down predict를 사용합니다.
Databricks 웹 사이트의 파일 시스템에서 DeltaLog의 간소화는 다음과 같습니다.

DeltaLog 자체는 여러 JSON 파일로 구성된 폴더입니다.10개의 파일에 도달하면 DeltaTable에서 체크포인트와 압축 작업을 수행합니다(다음 장에서 자세히 살펴보겠습니다).
다음은 코드 소스 테스트 리소스의 DeltaLog JSON 파일의 예입니다. 파일의 각 항목은 JSON에 있습니다.

{"remove":{"path":"part-00001-f1cb1cf9-7a73-439c-b0ea-dcba5c2280a6-c000.snappy.parquet","dataChange":true}}
{"remove":{"path":"part-00000-f4aeebd0-a689-4e1b-bc7a-bbb0ec59dce5-c000.snappy.parquet","dataChange":true}}

이 파일에는 제출된 내용이 총 두 번 캡처되었습니다.
삭제 - 전체 열을 삭제하거나 특정 값만 삭제할 수 있습니다.이 작업에서 메타데이터 필드 데이터체인은true로 설정됩니다.
다음은 파일의 각 항목이 JSON에 있는 보다 복잡한 JSON 파일 예입니다.

{"metaData":{"id":"2edf2c02-bb63-44e9-a84c-517fad0db296","format":{"provider":"parquet","options":{}},"schemaString":"{\"type\":\"struct\",\"fields\":[{\"name\":\"id\",\"type\":\"integer\",\"nullable\":true,\"metadata\":{}},{\"name\":\"value\",\"type\":\"string\",\"nullable\":true,\"metadata\":{}}]}","partitionColumns":["id"],"configuration":{}}}
{"remove":{"path":"part-00001-6d252218-2632-416e-9e46-f32316ec314a-c000.snappy.parquet","dataChange":true}}
{"remove":{"path":"part-00000-348d7f43-38f6-4778-88c7-45f379471c49-c000.snappy.parquet","dataChange":true}}
{"add":{"path":"id=5/part-00000-f1e0b560-ca00-409e-a274-f1ab264bc412.c000.snappy.parquet","partitionValues":{"id":"5"},"size":362,"modificationTime":1501109076000,"dataChange":true}}
{"add":{"path":"id=6/part-00000-adb59f54-6b8f-4bfd-9915-ae26bd0f0e2c.c000.snappy.parquet","partitionValues":{"id":"6"},"size":362,"modificationTime":1501109076000,"dataChange":true}}
{"add":{"path":"id=4/part-00001-36c738bf-7836-479b-9cc1-7a4934207856.c000.snappy.parquet","partitionValues":{"id":"4"},"size":362,"modificationTime":1501109076000,"dataChange":true}}

이 예에는 메타데이터 대상 항목이 있습니다. 이것은 표열의 변경 사항을 표시하거나, 표 구조에 대한 업데이트를 표시하거나, 새 표를 만들었습니다.
나중에 우리는 두 개의 삭제 조작을 보았고, 그 다음에 세 개의 추가 조작을 보았다.이러한 조작 대상은stat 필드를 가지고 통계 정보를 포함할 수 있는데, 예를 들어 기록수, 최소값, 최대값 등이다.
이 JSON 파일에는 '흐름 업데이트', '수첩' 등 필드가 있는 조작 대상도 포함될 수 있으며, 만약 작업이 수첩, isolation Level 등에서 진행된다면.
이러한 정보는 관리 테이블과 스토리지에 대한 중복된 전체 검색을 방지하는 데 매우 가치가 있습니다.
DeltaTable와 DeltaLog 간의 연결을 간소화하기 위해 DeltaTable를 DeltaLog 심사의 한 그룹의 작업의 직접적인 결과로 간주하기 쉽다.

DeltaLog 및 원자성

part one에서 원자성은 발생하든 안 하든 하나의 일을 의미한다는 것을 알고 있습니다.DeltaLog 자체는 원자 작업으로 구성됩니다.일지의 모든 줄(위에서 보듯이)은 하나의 동작을 대표하는데 이것은 원자 단위이다.이것들을 제출이라고 부른다.
데이터에서 발생하는 트랜잭션은 각각 DeltaLog의 커밋을 나타내는 여러 구성 요소로 분해할 수 있습니다.이런 복잡한 조작을 작은 일로 분해하는 방법은 원자성을 확보하는 데 도움이 된다.

DeltaLog 및 격리

업데이트, 삭제, 추가 등 조작은 격리에 해를 끼칠 수 있다.따라서 DeltaTable와의 격리를 원하기 때문에 카드 리더는 표 스냅샷에만 접근할 수 있습니다.이것은 모든 병렬 카드 리더기가 정확한 데이터를 읽을 수 있도록 보장한다.삭제 작업을 처리할 때 Delta는 파일에 대한 실제 삭제 작업을 연기합니다.그것은 먼저 파일을 삭제된 것으로 표시한 다음에 안전하다고 판단될 때 삭제한다. (Cassandra와 유사하고 묘비가 있는 ElasticSearch 삭제 작업과 같다.)
DeltaLake 0.8.1 소스 코드에는 삭제 보존 기간을 최소 2주 이상으로 설정하거나 작업의 지속 기간을 초과하는 것이 좋다는 설명이 있습니다.
주의: 이것은 흐름 작업 부하에도 영향을 줄 수 있습니다. 왜냐하면 어느 때 실제 파일을 삭제해야 하기 때문에 흐름이 막힐 수 있습니다.

DeltaLog 및 정합성

Delta Lake는 긍정적인 병렬 알고리즘을 사용하여 충돌을 해결함으로써 일관성 문제를 해결합니다.
이 알고리즘을 담당하는 클래스는 OptimisticTransaction 클래스입니다.DeltaLog 인스턴스 제어Java 8 ReentrantLock를 사용하여 구현됩니다.
다음은 코드 세그먼트입니다.

DeltaTable 실례는 doCommitRetryIteratively 함수에서 OptimisticTransaction의ReentrantLock을 적극적으로 사용합니다.
낙관적인 방법을 선택한 것은 빅데이터 세계에서 기존 기록을 갱신하는 것보다 더 많은 데이터를 추가했기 때문이다.
특정 기록을 찾아 업데이트하는 것은 매우 어렵다. 보통 필요한 데이터가 손상되었을 때 진행된다.
다음은 낙관 알고리즘의 코드 세그먼트입니다.

572 줄에서 프로그램이 시도한 버전은 commitVersion 실례로 기록되고, 그 유형은 var 이다.var Scala에서 가변 객체 인스턴스를 나타냅니다. 이것은 값이 변경되기를 기대해야 한다는 것을 의미합니다.
575 줄에서 알고리즘을 시작합니다.
그것은 while(true) 순환을 시작하고 유지보수attemptNumber 계수기를 작동한다.==0인 경우 제출을 시도합니다.만약 여기에 실패한다면, 이것은 이 commitVersion 를 가진 파일이 테이블에 기록되었거나 제출되었다는 것을 의미하며, 이상을 던질 것입니다.이 이상은 592+593 줄에서 포착되었다.여기서부터 매번 실패할 때마다 알고리즘은 시도 횟수를 1씩 증가시킨다.
첫 번째 실패 후 프로그램은 577줄의 첫 번째if문장에 들어가지 않습니다.그것은 579선상에 직행할 것이다. else if프로그램이 attemptNumber 허용/설정의 최대 값보다 큰 상태에 이르면 DeltaErrors.maxCommitRetriesExceededException 이상을 던집니다.
MaxCommitRetriesExceedexception 예외는 버전 제출, 첫 번째 버전 제출 시도, 제출 시도 횟수 및 제출을 시도한 총 시간(ms)에 대한 정보를 제공합니다.
그렇지 않으면 588행에서 checkForConflict 기능을 사용하여 업데이트를 기록합니다.
여러 가지 상황이 우리를 이런 상태에 빠뜨릴 것이다.
고급 위조 코드:

while(tryCommit)
    if first attempt:
        do commit
    else if: attempt number > max retries
            throw an exception - exit loop
        else:
            record retry operation
            try fixing logical conflicts - return valid commit version or throw an exception
            do commit
    retry on exceptions and attempt version +1
    if no exception - end loop
end     

DeltaLake는 사용자를 지원하기 위해 데이터 및 충돌에 대한 추가 정보를 제공하는 충돌 예외 집합을 도입했습니다.

충돌 장면을 좀 봅시다.

두 작성자:

이것은 두 컴파일러가 같은 테이블에 데이터를 동시에 추가하고 어떤 내용도 읽지 않는 경우이다.이 경우, 하나의 컴파일러가 제출되고, 두 번째 컴파일러는 자신의 업데이트를 추가하기 전에 첫 번째 컴파일러의 업데이트를 읽습니다.만약 그것이 단지 하나의 추가 조작일 뿐이라고 가정한다면, 예를 들어 계수기, 둘 다 점차적으로 증가하고 있다.이 경우 모든 계산을 다시 할 필요가 없고 자동으로 제출됩니다.만약 그렇지 않다면, writer one이 제공하는 새로운 정보를 감안하여, writer No.2는 다시 계산해야 할 것이다.

삭제 및 읽기:

이런 더욱 복잡한 장면에는 자동화 해결 방안이 없다.동시 삭제 읽기에 대한 전용 ConcurentDeleteReadException 이 있습니다.
이것은 파일을 삭제하는 요청이 동시에 읽기에 사용되면 프로그램에서 이상을 던진다는 것을 의미한다.

삭제 및 삭제:

두 작업이 같은 파일을 삭제할 때, 압축 메커니즘이나 다른 작업 때문일 수도 있고, 여기서도 이상이 발생할 수 있다.

DeltaLog 및 내구성

DeltaTable에서 진행되는 모든 업무는 디스크/파일 시스템에 직접 저장되기 때문에 지속성은 주어진 매개 변수입니다.모든 커밋이 디스크로 영구화됩니다.시스템에 장애가 발생하면 디스크에서 복구할 수 있습니다.
(화재와 같은 진정한 재난이 발생하거나 정보를 저장하는 실제 디스크가 손상되지 않는 한)
델타를 탐색하고 배우기 위해 저는 코드 소스 코드 자체를 깊이 연구했습니다.만약 당신이 나에게 가입할 흥미가 있다면, 나는 동영상을 통해 그것을 포착할 것입니다. 만약 이것이 당신에게 유용하다면 저에게 알려 주십시오.

다음은요?

다음은 Delta Lake의 더 많은 예시, 장면과 용례를 볼 수 있습니다!우리는 압축 메커니즘, 패턴 집행, 그리고 그것이 어떻게 조작을 집행하는지 배울 것이다.
여느 때와 마찬가지로, 나는 너희들의 나에 대한 건의와 피드백을 매우 받고 싶다🐦.
매달 업데이트를 받고 싶다면 고려해 보세요subscribing.