Delta Lake 자세히 알아보기: 스키마 적용 및 진화

헤이 하브르! 나는 기사의 번역을 당신의 관심에 제시합니다 "Delta Lake로 다이빙: 스키마 적용 및 진화" 과정 시작을 예상하여 준비한 저자 Burak Yavuz, Brenner Heintz 및 Denny Lee 데이터 엔지니어 오투스에서.

우리의 경험과 마찬가지로 데이터는 지속적으로 축적되고 진화하고 있습니다. 따라잡기 위해 세계에 대한 우리의 정신 모델은 새로운 데이터에 적응해야 하며, 그 중 일부는 새로운 차원, 즉 우리가 이전에 전혀 몰랐던 것을 관찰하는 새로운 방법을 포함하고 있습니다. 이러한 정신 모델은 우리가 새로운 정보를 분류하고 처리하는 방법을 정의하는 테이블 스키마와 크게 다르지 않습니다.

이로 인해 스키마 관리 문제가 발생합니다. 시간이 지남에 따라 비즈니스 목표와 요구 사항이 변경됨에 따라 데이터 구조도 변경됩니다. Delta Lake를 사용하면 데이터가 변경될 때 새로운 측정을 쉽게 구현할 수 있습니다. 사용자는 간단한 의미 체계에 액세스하여 테이블 스키마를 관리할 수 있습니다. 이러한 도구에는 사용자가 실수로 오류나 불필요한 데이터로 테이블을 오염시키는 것을 방지하는 Schema Enforcement와 중요한 데이터의 새 열을 적절한 위치에 자동으로 추가할 수 있는 Schema Evolution이 포함됩니다. 이 기사에서는 이러한 도구의 사용에 대해 자세히 설명합니다.

테이블 스키마 이해

Apache Spark의 각 DataFrame에는 데이터 유형, 열 및 메타데이터와 같은 데이터의 형태를 정의하는 스키마가 포함되어 있습니다. Delta Lake를 사용하면 테이블 스키마가 트랜잭션 로그 내에 JSON 형식으로 저장됩니다.

스키마 적용이란 무엇입니까?

스키마 유효성 검사라고도 하는 스키마 적용은 테이블 스키마와 일치하지 않는 레코드를 거부하여 데이터 품질을 보장하는 Delta Lake의 보호 메커니즘입니다. 예약만 받는 인기 레스토랑의 여주인처럼 그는 테이블에 입력된 데이터의 각 열이 해당 예상 열 목록에 있는지 확인합니다(즉, "예약"이 있는 경우). 각각), 목록에 없는 열이 있는 항목은 모두 거부합니다.

스키마 적용은 어떻게 작동합니까?

Delta Lake는 쓰기 시 스키마 유효성 검사를 사용합니다. 즉, 테이블에 대한 모든 새 쓰기는 쓰기 시간에 대상 테이블의 스키마와의 호환성을 확인합니다. 스키마가 일치하지 않으면 Delta Lake는 트랜잭션을 완전히 되돌리고(데이터가 기록되지 않음) 예외를 발생시켜 사용자에게 불일치를 알립니다.
Delta Lake는 다음 규칙을 사용하여 레코드가 테이블과 호환되는지 확인합니다. 작성된 DataFrame:

• 대상 테이블의 스키마에 없는 추가 열을 포함할 수 없습니다. 반대로 들어오는 데이터에 테이블의 모든 열이 포함되어 있지 않으면 모든 것이 정상입니다. 이러한 열에는 단순히 XNUMX 값이 할당됩니다.
• 대상 테이블의 열 데이터 유형과 다른 열 데이터 유형을 가질 수 없습니다. 대상 테이블의 열에 StringType 데이터가 포함되어 있지만 DataFrame의 해당 열에 IntegerType 데이터가 포함된 경우 스키마 시행에서 예외가 발생하고 쓰기 작업이 수행되지 않습니다.
• 대소문자만 다른 열 이름을 포함할 수 없습니다. 이는 동일한 테이블에 정의된 'Foo' 및 'foo'라는 열을 가질 수 없음을 의미합니다. Spark는 대/소문자를 구분하거나 구분하지 않는(기본값) 모드에서 사용할 수 있지만 Delta Lake는 대/소문자를 유지하지만 스키마 저장소 내에서는 구분하지 않습니다. Parquet는 열 정보를 저장하고 반환할 때 대소문자를 구분합니다. 가능한 오류, 데이터 손상 또는 데이터 손실(Databricks에서 개인적으로 경험한)을 방지하기 위해 이 제한을 추가하기로 결정했습니다.

이를 설명하기 위해 새로 생성된 열을 허용하도록 아직 구성되지 않은 Delta Lake 테이블에 추가하려고 할 때 아래 코드에서 어떤 일이 발생하는지 살펴보겠습니다.

# Сгенерируем DataFrame ссуд, который мы добавим в нашу таблицу Delta Lake
loans = sql("""
            SELECT addr_state, CAST(rand(10)*count as bigint) AS count,
            CAST(rand(10) * 10000 * count AS double) AS amount
            FROM loan_by_state_delta
            """)

# Вывести исходную схему DataFrame
original_loans.printSchema()

root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
 
# Вывести новую схему DataFrame
loans.printSchema()
 
root
  |-- addr_state: string (nullable = true)
  |-- count: integer (nullable = true)
  |-- amount: double (nullable = true) # new column
 
# Попытка добавить новый DataFrame (с новым столбцом) в существующую таблицу
loans.write.format("delta") 
           .mode("append") 
           .save(DELTALAKE_PATH)

Returns:

A schema mismatch detected when writing to the Delta table.
 
To enable schema migration, please set:
'.option("mergeSchema", "true")'
 
Table schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
 
Data schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
-- amount: double (nullable = true)
 
If Table ACLs are enabled, these options will be ignored. Please use the ALTER TABLE command for changing the schema.

새 열을 자동으로 추가하는 대신 Delta Lake는 스키마를 적용하고 기록을 중지합니다. 불일치를 일으키는 열(또는 열 집합)을 확인하는 데 도움이 되도록 Spark는 비교를 위해 추적 스택에서 두 스키마를 팝합니다.

스키마 적용의 이점은 무엇입니까?

스키마 적용은 상당히 엄격한 검사이므로 생산 또는 소비할 준비가 된 깨끗하고 완전히 변환된 데이터 세트의 게이트키퍼로 사용할 수 있는 훌륭한 도구입니다. 일반적으로 데이터를 직접 공급하는 테이블에 적용됩니다.

• 기계 학습 알고리즘
• BI 대시보드
• 데이터 분석 및 시각화 도구
• 고도로 구조화되고 강력한 유형의 시맨틱 스키마가 필요한 프로덕션 시스템.

이 최종 장애물에 대한 데이터를 준비하기 위해 많은 사용자는 테이블에 점진적으로 구조를 도입하는 간단한 "멀티 홉" 아키텍처를 사용합니다. 이에 대해 자세히 알아보려면 기사를 읽을 수 있습니다. Delta Lake를 사용한 생산 등급 머신 러닝.

물론 스키마 적용은 파이프라인의 어느 곳에서나 사용할 수 있지만 이 경우 테이블에 대한 스트리밍 쓰기가 좌절될 수 있다는 점을 명심하십시오. 예를 들어 수신 데이터에 다른 열을 추가한 것을 잊어버렸기 때문입니다.

데이터 희석 방지

이 시점에서 왜 과대 광고인지 궁금할 것입니다. 결국 때때로 예상치 못한 "스키마 불일치" 오류로 인해 특히 Delta Lake를 처음 사용하는 경우 워크플로에서 문제가 발생할 수 있습니다. 무슨 일이 있어도 DataFrame을 작성할 수 있도록 필요에 따라 스키마를 변경하는 것이 어떻습니까?

옛 속담에 "XNUMX 온스의 예방은 XNUMX 파운드의 치료 가치가 있습니다." 어느 시점에서 스키마를 적용하는 데 주의를 기울이지 않으면 데이터 유형 호환성 문제가 추악한 머리를 드러낼 것입니다. 겉보기에 동질적인 원시 데이터 소스에는 엣지 케이스, 깨진 열, 잘못된 형식의 매핑 또는 꿈꾸는 다른 두려운 것들이 포함될 수 있습니다. .악몽 속에서. 가장 좋은 접근 방식은 스키마 적용을 통해 게이트에서 이러한 적들을 막고 나중에 프로덕션 코드의 어두운 깊이를 배회하기 시작하는 시점이 아니라 빛 속에서 처리하는 것입니다.

스키마 적용은 사용자가 직접 변경을 확인하지 않는 한 테이블의 스키마가 변경되지 않는다는 확신을 줍니다. 이렇게 하면 새 열이 너무 자주 추가되어 이전에 중요하고 압축된 테이블이 데이터 범람으로 인해 가치와 유용성을 잃을 때 발생할 수 있는 데이터 희석을 방지할 수 있습니다. 의도적으로 높은 표준을 설정하고 높은 품질을 기대하도록 장려함으로써 스키마 적용은 설계된 대로 정확하게 작동하여 성실함을 유지하고 스프레드시트를 깨끗하게 유지할 수 있도록 도와줍니다.

더 고려한 후에 귀하가 정말로 필요한 새 열 추가 - 문제 없습니다. 아래는 한 줄 수정입니다. 해결책은 회로 진화입니다!

스키마 진화란 무엇입니까?

스키마 진화는 사용자가 시간이 지남에 따라 변경되는 데이터와 일치하도록 테이블의 현재 스키마를 쉽게 변경할 수 있는 기능입니다. 하나 이상의 새 열을 포함하도록 스키마를 자동으로 조정하기 위해 추가 또는 덮어쓰기 작업을 수행할 때 가장 일반적으로 사용됩니다.

스키마 진화는 어떻게 작동합니까?

이전 섹션의 예에 따라 개발자는 스키마 진화를 쉽게 사용하여 스키마 불일치로 인해 이전에 거부된 새 열을 추가할 수 있습니다. 추가하여 회로 진화가 활성화됩니다. .option('mergeSchema', 'true') 스파크 팀에게 .write или .writeStream.

# Добавьте параметр mergeSchema
loans.write.format("delta") 
           .option("mergeSchema", "true") 
           .mode("append") 
           .save(DELTALAKE_SILVER_PATH)

그래프를 보려면 다음 Spark SQL 쿼리를 실행합니다.

# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10

또는 다음을 추가하여 전체 Spark 세션에 대해 이 옵션을 설정할 수 있습니다. spark.databricks.delta.schema.autoMerge = True Spark 구성에. 그러나 스키마 적용은 더 이상 의도하지 않은 스키마 불일치에 대해 경고하지 않으므로 주의해서 사용하십시오.

요청에 매개변수 포함 mergeSchema, DataFrame에는 있지만 대상 테이블에는 없는 모든 열이 쓰기 트랜잭션의 일부로 스키마 끝에 자동으로 추가됩니다. 중첩 필드도 추가할 수 있으며 해당 구조 열의 끝에 추가됩니다.

날짜 엔지니어와 데이터 과학자는 이 옵션을 사용하여 이전 열을 기반으로 기존 모델을 중단하지 않고 기존 기계 학습 생산 테이블에 새 열(아마도 최근 추적된 메트릭 또는 이번 달 판매 수치 열)을 추가할 수 있습니다.

다음 유형의 스키마 변경은 테이블을 추가하거나 덮어쓰는 동안 스키마 진화의 일부로 허용됩니다.

• 새 열 추가(가장 일반적인 시나리오)
• NullType -> 다른 유형에서 데이터 유형 변경 또는 ByteType -> ShortType -> IntegerType에서 승격

스키마 진화의 일부로 허용되지 않는 기타 변경 사항은 다음을 추가하여 스키마와 데이터를 덮어써야 합니다. .option("overwriteSchema", "true"). 예를 들어 "Foo" 열이 원래 정수이고 새 스키마가 문자열 데이터 유형인 경우 모든 Parquet(data) 파일을 덮어써야 합니다. 이러한 변경 사항은 다음과 같습니다.

• 열 삭제
• 기존 열의 데이터 유형 변경(제자리에서)
• 대소문자만 다른 열 이름 바꾸기(예: "Foo" 및 "foo")

마지막으로 Spark 3.0의 다음 릴리스에서는 명시적 DDL(ALTER TABLE 사용)이 완전히 지원되어 사용자가 테이블 스키마에서 다음 작업을 수행할 수 있습니다.

• 열 추가
• 열 주석 변경
• 트랜잭션 로그 보관 기간 설정과 같이 테이블 동작 방식을 결정하는 테이블 속성 설정

스키마 진화의 이점은 무엇입니까?

도식적 진화는 언제든지 사용할 수 있습니다. 의도하다 테이블의 스키마를 변경합니다(실수로 DataFrame에 있으면 안 되는 열을 추가한 경우와 반대) 이는 명시적으로 선언하지 않고도 올바른 열 이름과 데이터 유형을 자동으로 추가하므로 스키마를 마이그레이션하는 가장 쉬운 방법입니다.

결론

스키마 적용은 테이블과 호환되지 않는 새 열 또는 기타 스키마 변경을 거부합니다. 이러한 높은 표준을 설정하고 유지함으로써 분석가와 엔지니어는 데이터에 의존하여 최고 수준의 무결성을 확보하고 데이터에 대해 명확하고 간결하게 추론하여 더 나은 비즈니스 결정을 내릴 수 있습니다.

반면에 스키마 진화는 단순화를 통해 시행을 보완합니다. 가정의 자동 스키마 변경. 결국 열을 추가하는 것이 어렵지 않아야 합니다.

스키마 적용은 양이고 스키마 진화는 음입니다. 이러한 기능을 함께 사용하면 노이즈 감소 및 신호 튜닝이 그 어느 때보다 쉬워집니다.

또한 이 기사에 기여한 Mukul Murthy와 Pranav Anand에게도 감사드립니다.

이 시리즈의 다른 기사:

Delta Lake 살펴보기: 트랜잭션 로그 풀기

관련 기사

Delta Lake를 사용한 생산 등급 머신 러닝

데이터 레이크란 무엇입니까?

과정에 대해 자세히 알아보기

출처 : habr.com