🥇델타 호수 탐험: 시행 및 계획의 진화

헤이 하브르! 나는 기사의 번역을 당신의 관심에 제시합니다 델타 호수 탐험: 스키마 적용 및 진화 Burak Yavuz, Brenner Heintz 및 Denny Lee가 코스 출시를 예상하여 준비한 것입니다. 데이터 엔지니어 오투스에서.

데이터는 우리의 경험과 마찬가지로 끊임없이 축적되고 진화합니다. 이에 발맞추기 위해, 세상에 대한 우리의 정신 모델은 새로운 데이터에 적응해야 하며, 그 중 일부에는 새로운 차원, 즉 이전에는 전혀 몰랐던 사물을 관찰하는 새로운 방식이 포함됩니다. 이러한 정신 모델은 새로운 정보를 분류하고 처리하는 방법을 결정하는 스프레드시트 스키마와 크게 다르지 않습니다.

여기서 우리는 회로 관리 문제에 대해 이야기하게 됩니다. 시간이 지남에 따라 비즈니스 목표와 요구 사항이 바뀌면 데이터 구조도 바뀌게 됩니다. Delta Lake를 사용하면 데이터가 변경됨에 따라 새로운 차원을 쉽게 도입할 수 있습니다. 사용자는 간단한 의미 체계에 접근하여 테이블 스키마를 관리할 수 있습니다. 이러한 도구에는 사용자가 실수로 오류나 불필요한 데이터로 테이블을 어지럽히는 것을 방지하는 스키마 적용과, 적절한 위치에 귀중한 데이터가 포함된 새 열을 자동으로 추가할 수 있는 스키마 진화가 포함됩니다. 이 글에서는 이러한 도구의 사용법을 더 자세히 알아보겠습니다.

테이블 스키마 이해

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

계획 집행이란 무엇인가요?

스키마 적용(Schema Enforcement)은 스키마 검증(Schema Validation)이라고도 하며, 테이블 스키마에 맞지 않는 레코드를 거부하여 데이터 품질을 보장하는 Delta Lake의 보안 메커니즘입니다. 예약만 받는 유명 레스토랑의 프런트 데스크 직원처럼, 그녀는 테이블에 입력된 각 데이터 열이 해당 예상 열 목록에 있는지(즉, 각 열에 "예약"이 있는지) 확인하고 목록에 없는 열이 있는 항목은 모두 거부합니다.

스키마 적용은 어떻게 작동하나요?

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

대상 테이블 스키마에 없는 추가 열을 포함할 수 없습니다. 반대로, 들어오는 데이터에 테이블의 모든 열이 포함되어 있지 않아도 괜찮습니다. 해당 열에는 단순히 null 값이 할당됩니다.
대상 테이블의 열 데이터 유형과 다른 열 데이터 유형을 가질 수 없습니다. 대상 테이블의 열에 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을 쓸 수 없게 하지 않나요?

옛말에 "예방은 치료보다 중요하다"라는 말이 있습니다. 어느 시점에서 스키마를 적용하는 데 주의를 기울이지 않으면 데이터 유형 호환성 문제가 심각한 문제로 나타날 것입니다. 겉보기에 동질적인 원시 데이터 소스에도 예외적인 상황, 손상된 열, 잘못된 매핑 또는 악몽이 현실이 되는 무서운 문제가 포함될 수 있습니다. 가장 좋은 방법은 스키마 적용을 통해 이러한 적을 게이트에서 막고, 나중에 프로덕션 코드의 어두운 깊숙한 곳에 숨어들기 시작할 때 처리하는 것보다는, 먼저 밝은 곳에서 처리하는 것입니다.

스키마를 적용하면 변경 사항을 명시적으로 커밋하지 않는 한 테이블의 스키마가 변경되지 않습니다. 이렇게 하면 새로운 열이 너무 자주 추가되어 이전에는 귀중하고 압축된 테이블이 데이터 홍수로 인해 의미와 유용성을 잃어버리는 데이터 희석을 방지할 수 있습니다. 스키마 강화는 의도적인 태도를 갖고, 높은 기준을 설정하고, 높은 품질을 기대하도록 장려함으로써 본래 의도한 대로 작동합니다. 즉, 성실함을 유지하고 스프레드시트를 깔끔하게 유지하는 데 도움이 됩니다.

더 자세히 고려한 후 실제로 그렇게 하기로 결정했다면 필요한 새로운 열을 추가하세요. 문제없습니다. 아래에 한 줄로 해결할 수 있는 내용이 있습니다. 해결책은 계획을 발전시키는 것입니다!

스키마 진화란 무엇인가?

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

스키마 진화는 어떻게 작동하나요?

이전 섹션의 예를 따라 개발자는 스키마 진화를 사용하여 이전에 스키마 불일치로 인해 거부되었던 새로운 열을 쉽게 추가할 수 있습니다. 이 계획의 진화는 다음을 추가하여 활성화됩니다. .option('mergeSchema', 'true') Spark 팀에게 .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 구성에. 하지만 스키마 적용이 의도치 않은 스키마 불일치에 대해 더 이상 경고하지 않으므로 주의해서 사용해야 합니다.

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

데이터 엔지니어와 과학자는 이 옵션을 사용하여 기존 열을 기반으로 하는 모델을 손상시키지 않고 기존 머신 러닝 프로덕션 테이블에 새로운 열(최근 추적한 지표나 이번 달의 판매 수치 열 등)을 추가할 수 있습니다.

다음 유형의 스키마 변경은 테이블 추가 또는 재작성 중 스키마 진화의 일부로 허용됩니다.

새 열 추가(가장 일반적인 시나리오)
NullType에서 다른 유형으로 데이터 유형을 변경하거나 ByteType에서 ShortType에서 IntegerType으로 승격합니다.

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

열 삭제
기존 열의 데이터 유형을 변경합니다(그대로)
대소문자만 다른 열 이름 바꾸기(예: "Foo" 및 "foo")

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

열 추가
열 주석 변경
트랜잭션 로그가 보관되는 기간을 설정하는 등 테이블의 동작을 결정하는 테이블 속성을 설정합니다.

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

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

결론

스키마 적용은 테이블과 호환되지 않는 새로운 열이나 기타 스키마 변경 사항을 거부합니다. 이러한 높은 기준을 설정하고 유지함으로써 분석가와 엔지니어는 자신의 데이터가 최고 수준의 무결성을 갖추고 있다는 것을 믿을 수 있으며, 이를 명확하고 정확하게 추론하여 더 나은 비즈니스 결정을 내릴 수 있습니다.

반면, 이 제도의 발전은 집행을 단순화함으로써 이를 보완한다. 가정의 자동 스키마 변경. 결국, 열을 추가하는 것은 그렇게 어렵지 않을 것입니다.

계획을 강제로 적용하는 것은 양이며, 계획의 전개는 음입니다. 이러한 기능을 함께 사용하면 소음 억제 및 신호 조정이 그 어느 때보다 쉬워집니다.

또한 이 기사에 기여해 주신 Mukul Murthy와 Pranav Anand에게도 감사드리고 싶습니다.

이 시리즈의 다른 기사:

델타 호수 탐색: 트랜잭션 로그 압축 해제

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