Delta Lake 심층 분석: 스키마 적용 및 진화

Databricks에서 이 Notebook 시리즈를 사용해 보세요.

데이터는 우리의 경험처럼 항상 진화하고 축적됩니다. 이에 발맞춰 세상에 대한 우리의 멘탈 모델은 새로운 데이터에 적응해야 하며, 그중 일부는 새로운 차원, 즉 이전에는 상상도 못 했던 방식으로 사물을 보는 새로운 방식을 포함합니다. 이러한 멘탈 모델은 테이블의 스키마와 다르지 않으며, 새로운 정보를 분류하고 처리하는 방법을 정의합니다.

이것이 스키마 관리로 이어집니다. 비즈니스 문제와 요구 사항이 시간이 지남에 따라 진화함에 따라 데이터 구조도 진화합니다. Delta Lake를 사용하면 데이터가 변경될 때 새로운 차원을 쉽게 통합할 수 있습니다. 사용자는 테이블의 스키마를 제어하기 위한 간단한 의미 체계에 액세스할 수 있습니다. 이러한 도구에는 사용자가 실수나 불량 데이터로 테이블을 실수로 오염시키는 것을 방지하는 스키마 적용과 풍부한 데이터의 새 열이 해당 열에 속할 때 자동으로 추가할 수 있도록 하는 스키마 진화가 포함됩니다. 이 블로그에서는 이러한 도구의 사용법을 자세히 살펴보겠습니다.

테이블 스키마 이해

Apache Spark™의 모든 DataFrame에는 데이터 형식 및 열과 같은 데이터 모양과 메타데이터를 정의하는 청사진인 스키마가 포함되어 있습니다. Delta Lake를 사용하면 테이블의 스키마가 트랜잭션 로그 내부에 JSON 형식으로 저장됩니다.

스키마 적용이란 무엇인가요?

스키마 유효성 검사라고도 하는 스키마 적용은 테이블의 스키마와 일치하지 않는 테이블에 대한 쓰기를 거부하여 데이터 품질을 보장하는 Delta Lake의 안전 장치입니다. 예약만 받는 붐비는 식당의 프런트 데스크 관리자처럼 테이블에 삽입된 데이터의 각 열이 예상 열 목록에 있는지(즉, 각 열에 "예약"이 있는지) 확인하고 목록에 없는 열이 있는 쓰기를 거부합니다.

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

Delta Lake는 쓰기 시 스키마 유효성 검사를 사용합니다. 즉, 테이블에 대한 모든 새 쓰기는 쓰기 시 대상 테이블의 스키마와의 호환성이 검사됩니다. 스키마가 호환되지 않으면 Delta Lake는 트랜잭션을 완전히 취소하고(데이터가 쓰여지지 않음) 예외를 발생시켜 사용자에게 불일치를 알립니다.

테이블에 대한 쓰기가 호환되는지 확인하기 위해 Delta Lake는 다음 규칙을 사용합니다. 쓸 DataFrame:

• 대상 테이블의 스키마에 없는 추가 열을 포함할 수 없습니다. 반대로 들어오는 데이터에 테이블의 모든 열이 포함되어 있지 않아도 괜찮습니다. 해당 열에는 null 값이 할당됩니다.
• 열 데이터 형식이 대상 테이블의 열 데이터 형식과 다를 수 없습니다. 대상 테이블의 열에 StringType 데이터가 포함되어 있지만 DataFrame의 해당 열에 IntegerType 데이터가 포함되어 있는 경우 스키마 적용은 예외를 발생시키고 쓰기 작업이 수행되지 않도록 합니다.
• 대/소문자만 다른 열 이름을 포함할 수 없습니다. 즉, 동일한 테이블에 'Foo' 및 'foo'와 같은 열을 정의할 수 없습니다. Spark는 대/소문자를 구분하거나 구분하지 않는(기본값) 모드에서 사용할 수 있지만 Delta Lake는 스키마를 저장할 때 대/소문자를 유지하지만 구분하지 않습니다. Parquet는 열 정보를 저장하고 반환할 때 대/소문자를 구분합니다. 잠재적인 실수, 데이터 손상 또는 손실 문제(Databricks에서 직접 경험한 문제)를 방지하기 위해 이 제한 사항을 추가하기로 결정했습니다.

예를 들어 아직 수락하도록 설정되지 않은 Delta Lake 테이블에 새로 계산된 일부 열을 추가하려고 할 때 아래 코드에서 발생하는 상황을 살펴보세요.

Delta Lake는 새 열을 자동으로 추가하는 대신 스키마를 적용하고 쓰기를 중지합니다. 어떤 열이 불일치를 일으켰는지 식별하는 데 도움이 되도록 Spark는 비교를 위해 스택 추적에서 두 스키마를 모두 출력합니다.

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

스키마 적용은 매우 엄격한 검사이기 때문에 프로덕션 또는 소비 준비가 된 깨끗하고 완전히 변환된 데이터 세트의 게이트키퍼로 사용하기에 훌륭한 도구입니다. 일반적으로 다음을 직접 공급하는 테이블에 적용됩니다.

• Machine Learning 알고리즘
• BI 대시보드
• 데이터 분석 및 시각화 도구
• 고도로 구조화되고 강력한 형식의 의미 체계 스키마가 필요한 모든 프로덕션 시스템

이 최종 허들을 위해 데이터를 준비하기 위해 많은 사용자가 테이블에 점진적으로 구조를 추가하는 간단한 "멀티 홉" 아키텍처를 사용합니다. 자세한 내용은 Delta Lake를 사용한 Machine Learning 프로덕션화라는 게시물을 참조하세요.

물론 스키마 적용은 파이프라인의 어느 곳에서나 사용할 수 있지만 예를 들어 들어오는 데이터에 단일 열을 추가했다는 사실을 잊었기 때문에 테이블에 대한 스트리밍 쓰기가 실패하는 것은 약간 실망스러울 수 있습니다.

데이터 희석 방지

이 시점에서 모든 소란이 무엇인지 자문할 수 있습니다. 결국 예기치 않은 "스키마 불일치" 오류가 워크플로에서 걸려 넘어질 수 있으며, 특히 Delta Lake를 처음 사용하는 경우 더욱 그렇습니다. 내 DataFrame을 무엇이든 쓸 수 있도록 스키마를 필요한 대로 변경하도록 하는 것은 어떨까요?

옛말에 "예방은 치료보다 낫다"라는 말이 있습니다. 어느 시점에서 스키마를 적용하지 않으면 데이터 형식 호환성 문제가 불거질 것입니다. 겉으로는 동질적인 원시 데이터 소스에 엣지 케이스, 손상된 열, 잘못된 매핑 또는 밤에 부딪히는 다른 무서운 것들이 포함될 수 있습니다. 훨씬 더 나은 접근 방식은 스키마 적용을 사용하여 이러한 적을 문에서 막고 나중에 프로덕션 코드의 어두운 구석에 숨어 있을 때가 아니라 낮에 처리하는 것입니다.

스키마 적용은 테이블의 스키마를 변경하겠다는 긍정적인 선택을 하지 않는 한 변경되지 않는다는 안심감을 제공합니다. 새로운 열이 너무 자주 추가되어 이전에는 풍부하고 간결했던 테이블이 데이터 홍수로 인해 의미와 유용성을 잃을 수 있는 데이터 "희석"을 방지합니다. 의도적으로 높은 기준을 설정하고 높은 품질을 기대하도록 장려함으로써 스키마 적용은 설계된 대로 정확하게 수행하고 있습니다. 즉, 정직하고 테이블을 깨끗하게 유지합니다.

추가 검토 후 해당 새 열을 정말로 추가하려던 것이라고 결정한 경우 아래에서 설명한 대로 한 줄로 쉽게 수정할 수 있습니다. 해결책은 스키마 진화입니다!

스키마 진화란 무엇인가요?

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

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

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

플롯을 보려면 다음 Spark SQL 문을 실행합니다.

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

쿼리에 mergeSchema 옵션을 포함하면 DataFrame에 있지만 대상 테이블에 없는 열이 쓰기 트랜잭션의 일부로 스키마 끝에 자동으로 추가됩니다. 중첩된 필드도 추가할 수 있으며 이러한 필드는 해당 struct 열의 끝에도 추가됩니다.

데이터 엔지니어와 과학자는 이 옵션을 사용하여 기존 열에 의존하는 기존 모델을 손상시키지 않고도 새로운 열(아마도 새로 추적된 메트릭 또는 이번 달 판매 수치 열)을 기존 Machine Learning 프로덕션 테이블에 추가할 수 있습니다.

다음 유형의 스키마 변경은 테이블 추가 또는 덮어쓰기 중에 스키마 진화에 적합합니다.

• 새 열 추가(가장 일반적인 시나리오)
• NullType -> 다른 유형으로의 데이터 형식 변경 또는 ByteType -> ShortType -> IntegerType에서의 업캐스트

스키마 진화에 적합하지 않은 다른 변경 사항은 .option("overwriteSchema", "true")를 추가하여 스키마 및 데이터를 덮어써야 합니다. 예를 들어 열 "Foo"가 원래 integer 데이터 형식이었고 새 스키마가 문자열 데이터 형식인 경우 모든 Parquet(데이터) 파일을 다시 작성해야 합니다. 이러한 변경 사항에는 다음이 포함됩니다.

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

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

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

스키마 진화는 어떻게 유용하나요?

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

요약

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

반대로 스키마 진화는 의도된 스키마 변경이 자동으로 수행되도록 하여 적용을 보완합니다. 결국 열을 추가하는 것은 어렵지 않아야 합니다.

스키마 적용은 스키마 진화의 음입니다. 함께 사용하면 이러한 기능을 통해 노이즈를 차단하고 신호에 맞추기가 그 어느 때보다 쉬워집니다.

이 블로그에 기여해 주신 Mukul Murthy와 Pranav Anand에게도 감사드립니다.

관련 항목

이 시리즈의 기사:
Delta Lake 살펴보기 #1: 트랜잭션 로그 압축 풀기
Delta Lake 살펴보기 #2: 스키마 적용 및 진화
Delta Lake 살펴보기 #3: DML 내부(업데이트, 삭제, 병합)

Delta Lake를 사용한 Machine Learning 프로덕션화
데이터 레이크란 무엇인가요?

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)