데이터 변환
이 문서에서는 Azure Databricks를 사용하여 데이터 변환에 대한 소개 및 개요를 제공합니다. 데이터 변환 또는 데이터 준비는 모든 데이터 엔지니어링, 분석 및 ML 워크로드의 핵심 단계입니다.
이 문서의 예제 패턴 및 권장 사항은 Delta Lake에서 지원되는 Lakehouse 테이블을 사용하는 데 중점을 줍니다. Delta Lake는 Databricks 레이크하우스의 ACID 보장을 제공하기 때문에 다른 형식 또는 데이터 시스템에서 데이터를 사용할 때 다른 동작을 관찰할 수 있습니다.
Databricks는 원시 또는 거의 원시 상태의 레이크하우스로 데이터를 수집한 다음 변환 및 보강을 별도의 처리 단계로 적용하는 것이 좋습니다. 이 패턴을 medallion 아키텍처라고합니다. 메달리온 레이크하우스 아키텍처란?을 참조하세요.
변환해야 하는 데이터가 아직 레이크하우스에 로드되지 않은 경우 Databricks 레이크하우스로 데이터 수집을 참조 하세요. 변환을 작성할 Lakehouse 데이터를 찾으려는 경우 데이터 검색을 참조하세요.
모든 변환은 데이터 원본에 대해 일괄 처리 또는 스트리밍 쿼리를 작성하는 것으로 시작합니다. 데이터 쿼리에 익숙하지 않은 경우 쿼리 데이터를 참조하세요.
변환된 데이터를 델타 테이블에 저장한 후에는 해당 테이블을 ML의 기능 테이블로 사용할 수 있습니다. 기능 엔지니어링 및 서비스를 참조하세요.
참고 항목
여기서는 Azure Databricks의 변환에 대해 설명합니다. Azure Databricks는 여러 일반적인 데이터 준비 플랫폼에 대한 연결도 지원합니다. 파트너 연결을 사용하여 데이터 준비 파트너에 연결을 참조하세요.
Spark 변환 및 레이크하우스 변환
이 문서에서는 ETL 또는 ELT의 T와 관련된 변환을 정의하는 데 중점을 둡니다. Apache Spark 처리 모델도 관련 방식으로 단어 변환 을 사용합니다. 간략하게 설명: Apache Spark에서 모든 작업은 변환 또는 작업으로 정의됩니다.
- 변환: 계획에 일부 처리 논리를 추가합니다. 예를 들어 데이터 읽기, 조인, 집계 및 형식 캐스팅이 있습니다.
- 작업: 결과를 평가하고 출력하는 처리 논리를 트리거합니다. 예를 들어 쓰기, 결과 표시 또는 미리 보기, 수동 캐싱 또는 행 수 가져오기 등이 있습니다.
Apache Spark는 지연 실행 모델을 사용합니다. 즉, 작업이 트리거될 때까지 작업 컬렉션에 정의된 논리가 평가되지 않습니다. 이 모델은 데이터 처리 파이프라인을 정의할 때 중요한 파급 효과를 줍니다. 작업만 사용하여 결과를 대상 테이블에 다시 저장합니다.
작업은 논리 최적화를 위한 처리 병목 상태를 나타내기 때문에 Azure Databricks는 논리의 최적 실행을 보장하기 위해 Apache Spark에 이미 있는 최적화를 기반으로 수많은 최적화를 추가했습니다. 이러한 최적화는 지정된 작업에 의해 트리거되는 모든 변환을 한 번에 고려하고 데이터의 실제 레이아웃에 따라 최적의 계획을 찾습니다. 수동으로 데이터를 캐싱하거나 프로덕션 파이프라인에서 미리 보기 결과를 반환하면 이러한 최적화가 중단되고 비용과 대기 시간이 크게 증가할 수 있습니다.
따라서 레이크하우스 변환을 하나 이상의 레이크하우스 테이블에 적용하여 새 레이크하우스 테이블로 만드는 모든 작업 컬렉션으로 정의할 수 있습니다. 조인 및 집계와 같은 변환은 별도로 설명되지만, 이러한 많은 패턴을 단일 처리 단계에서 결합하고 Azure Databricks의 최적화 프로그램을 신뢰하여 가장 효율적인 계획을 찾을 수 있습니다.
스트리밍 및 일괄 처리의 차이점은 무엇인가요?
스트리밍 및 일괄 처리는 Azure Databricks에서 동일한 구문을 대부분 사용하지만 각각에는 고유한 특정 의미 체계가 있습니다.
일괄 처리를 사용하면 고정된 양의 정적, 변경되지 않는 데이터를 단일 작업으로 처리하는 명시적 지침을 정의할 수 있습니다.
스트림 처리를 사용하면 지속적으로 증가하는 무제한 데이터 세트에 대한 쿼리를 정의한 다음, 작은 증분 일괄 처리로 데이터를 처리할 수 있습니다.
Azure Databricks의 일괄 처리 작업은 Spark SQL 또는 DataFrame을 사용하는 반면 스트림 처리는 구조적 스트리밍을 활용합니다.
다음 표와 같이 읽기 및 쓰기 작업을 확인하여 일괄 처리 Apache Spark 명령을 구조적 스트리밍과 구분할 수 있습니다.
| Apache Spark | 구조적 스트리밍 | |
|---|---|---|
| 읽음 | spark.read.load() |
spark.readStream.load() |
| 쓰기 | spark.write.save() |
spark.writeStream.start() |
구체화된 뷰는 일반적으로 일괄 처리 보장을 준수하지만 델타 라이브 테이블은 가능한 경우 결과를 증분 방식으로 계산하는 데 사용됩니다. 구체화된 뷰에서 반환되는 결과는 항상 논리의 일괄 처리 평가와 동일하지만, Azure Databricks는 가능한 경우 이러한 결과를 증분 방식으로 처리하려고 합니다.
스트리밍 테이블은 항상 결과를 증분 방식으로 계산합니다. 많은 스트리밍 데이터 원본은 시간 또는 며칠 동안만 레코드를 유지하므로 스트리밍 테이블에서 사용하는 처리 모델은 데이터 원본의 각 레코드 일괄 처리가 한 번만 처리된다고 가정합니다.
Azure Databricks는 SQL을 사용하여 다음과 같은 사용 사례에서 스트리밍 쿼리를 작성하도록 지원합니다.
- Databricks SQL을 사용하여 Unity 카탈로그에서 스트리밍 테이블 정의
- Delta Live Tables 파이프라인에 대한 소스 코드 정의
참고 항목
Python 구조적 스트리밍 코드를 사용하여 Delta Live Tables에서 스트리밍 테이블을 선언할 수도 있습니다.
일괄 처리 변환
일괄 처리 변환은 특정 시점에 잘 정의된 데이터 자산 집합에서 작동합니다. 일괄 처리 변환은 일회성 작업일 수 있지만 프로덕션 시스템을 최신 상태로 유지하기 위해 정기적으로 실행되는 예약된 작업 또는 파이프라인의 일부인 경우가 많습니다.
증분 변환
증분 패턴은 일반적으로 데이터 원본이 추가 전용이며 안정적인 스키마를 가지고 있다고 가정합니다. 다음 문서에서는 업데이트, 삭제 또는 스키마 변경이 발생하는 테이블의 증분 변환에 대한 뉘앙스에 대한 세부 정보를 제공합니다.
- 변경 내용 적용 API: Delta Live Tables를 사용하여 변경 데이터 캡처 간소화
- Azure Databricks에서 Delta Lake 변경 데이터 피드 사용
- Delta Lake 테이블 스키마 업데이트
- 델타 테이블 스트리밍 읽기 및 쓰기
실시간 변환
Delta Lake는 Lakehouse를 쿼리하는 모든 사용자 및 애플리케이션에 대해 대량의 데이터에 거의 실시간으로 액세스할 수 있지만 클라우드 개체 스토리지에 파일 및 메타데이터를 쓰는 오버헤드로 인해 Delta Lake 싱크에 쓰는 많은 워크로드에 대해 실제 실시간 대기 시간에 도달할 수 없습니다.
대기 시간이 매우 짧은 스트리밍 애플리케이션의 경우 Databricks는 Kafka와 같은 실시간 워크로드용으로 설계된 원본 및 싱크 시스템을 선택하는 것이 좋습니다. Azure Databricks를 사용하여 집계, 스트림 간 조인, 레이크하우스에 저장된 느린 변경 차원 데이터로 스트리밍 데이터 조인을 비롯한 데이터를 보강할 수 있습니다.