Delta Live Tables와 Apache Kafka를 이용한 저지연 스트리밍 데이터 파이프라인

Delta Live Tables (DLT)는 안정적인 데이터 파이프라인을 구축하기 위한 간단한 선언적 접근 방식을 사용하고 배치 및 스트리밍 데이터를 위한 기본 인프라를 대규모로 완벽하게 관리하는 최초의 ETL 프레임워크입니다. 많은 사용 사례에서는 거의 실시간 데이터에서 파생된 실행 가능한 인사이트가 필요합니다. Delta Live Tables는 Apache Kafka, AWS Kinesis, Confluent Cloud, Amazon MSK 또는 Azure Event Hubs와 같은 이벤트 버스에서 직접 데이터를 수집하여 낮은 지연 시간으로 이러한 사용 사례를 지원하는 낮은 지연 시간 스트리밍 데이터 파이프라인을 지원합니다.

이 문서는 DLT와 Apache Kafka를 함께 사용하는 방법을 안내하며 스트림을 수집하는 데 필요한 Python 코드를 제공합니다. 권장 시스템 아키텍처가 설명되고 관련 DLT 설정도 함께 살펴봅니다.

스트리밍 플랫폼

이벤트 버스 또는 메시지 버스는 메시지 프로듀서와 컨슈머를 분리합니다. 인기 있는 스트리밍 사용 사례는 웹사이트를 탐색하는 사용자로부터 클릭 데이터를 수집하는 것으로, 모든 사용자 상호 작용은 Apache Kafka에 이벤트로 저장됩니다. Kafka의 이벤트 스트림은 실시간 스트리밍 데이터 분석에 사용됩니다. 여러 메시지 컨슈머가 Kafka에서 동일한 데이터를 읽고 해당 데이터를 사용하여 잠재고객 관심사, 전환율 및 이탈 이유에 대해 알아볼 수 있습니다. 사용자 상호 작용에서 오는 실시간 스트리밍 이벤트 데이터는 종종 청구 데이터베이스에 저장된 실제 구매와 상관 관계를 파악해야 합니다.

Apache Kafka

Apache Kafka는 인기 있는 오픈 소스 이벤트 버스입니다. Kafka는 토픽이라는 개념을 사용하는데, 이는 일정 시간 동안 메시지가 버퍼링되는 이벤트의 추가 전용 분산 로그입니다. Kafka의 메시지는 소비된 후 삭제되지 않지만 영구적으로 저장되지도 않습니다. Kafka의 메시지 보존 기간은 토픽별로 구성할 수 있으며 기본값은 7일입니다. 만료된 메시지는 결국 삭제됩니다.

이 문서는 Apache Kafka를 중심으로 하지만, 논의된 개념은 다른 이벤트 버스 또는 메시징 시스템에도 적용됩니다.

스트리밍 데이터 파이프라인

데이터 흐름 파이프라인에서 Delta Live Tables와 해당 종속성은 표준 SQL Create Table As Select (CTAS) 문과 DLT 키워드 "live"를 사용하여 선언할 수 있습니다.

Python으로 DLT를 개발할 때 @dlt.table 데코레이터를 사용하여 Delta Live Table을 생성합니다. 파이프라인의 데이터 품질을 보장하기 위해 DLT는 Expectations를 사용하는데, 이는 잘못된 레코드에 대한 파이프라인의 동작을 정의하는 간단한 SQL 제약 조건 절입니다.

스트리밍 워크로드는 예측할 수 없는 데이터 볼륨을 동반하는 경우가 많으므로 Databricks는 데이터 흐름 파이프라인에 대해 향상된 자동 확장을 사용하여 전체 엔드투엔드 지연 시간을 최소화하고 불필요한 인프라를 종료하여 비용을 절감합니다.

Delta Live Tables는 각 파이프라인 실행에 대해 올바른 순서로 정확히 한 번씩 완전히 다시 계산됩니다.

대조적으로, 스트리밍 Delta Live Tables는 상태 저장 방식으로, 점진적으로 계산되며 마지막 파이프라인 실행 이후에 추가된 데이터만 처리합니다. 스트리밍 라이브 테이블을 정의하는 쿼리가 변경되면 새 데이터는 새 쿼리를 기반으로 처리되지만 기존 데이터는 다시 계산되지 않습니다. 스트리밍 라이브 테이블은 항상 스트리밍 소스를 사용하며 Kafka, Kinesis 또는 Auto Loader와 같은 추가 전용 스트림에서만 작동합니다. 스트리밍 DLT는 Spark Structured Streaming을 기반으로 합니다.

매우 큰 데이터 볼륨과 낮은 지연 시간 요구 사항이 있는 워크로드와 같이 여러 스트리밍 파이프라인을 연결할 수 있습니다.

스트리밍 엔진에서 직접 수집

Python으로 작성된 Delta Live Tables는 Spark Structured Streaming을 사용하여 Kafka와 같은 이벤트 버스에서 직접 데이터를 수집할 수 있습니다. 규정 준수 문제를 피하고 비용을 절감하기 위해 Kafka 토픽에 대한 짧은 보존 기간을 설정한 다음 Delta가 제공하는 저렴하고 탄력적이며 관리 가능한 스토리지를 활용할 수 있습니다.

파이프라인의 첫 번째 단계로, 복잡한 변환으로 인해 중요한 데이터가 손실될 수 있으므로 데이터를 있는 그대로 원시(bronze) 테이블에 수집하는 것이 좋습니다. 다른 Delta Table과 마찬가지로 bronze 테이블은 기록을 유지하고 GDPR 및 기타 규정 준수 작업을 수행할 수 있도록 합니다.

Python으로 DLT 파이프라인을 작성할 때 @dlt.table 주석을 사용하여 DLT 테이블을 생성합니다. Python에서 스트리밍 DLT를 표시하는 특별한 속성은 없으며, spark.readStream()을 사용하여 스트림에 액세스하면 됩니다. Kafka 토픽에서 데이터를 소비하는 kafka_bronze라는 이름의 DLT 테이블을 생성하는 예제 코드는 다음과 같습니다.

pipelines.reset.allowed

이벤트 버스는 일반적으로 특정 기간 후에 메시지를 만료시키는 반면, Delta는 무한 보존을 위해 설계되었다는 점에 유의하십시오.

이로 인해 DLT 파이프라인의 전체 새로 고침을 실행할 때 Kafka의 원본 데이터가 이미 삭제되었을 수 있습니다. 이 경우 메시징 플랫폼에서 모든 기록 데이터를 백필할 수 없으며 DLT 테이블에 데이터가 누락될 수 있습니다. 데이터 손실을 방지하려면 다음 DLT 테이블 속성을 사용하십시오.

pipelines.reset.allowed=false

pipelines.reset.allowed를 false로 설정하면 테이블 새로 고침은 방지되지만 테이블에 대한 증분 쓰기 또는 테이블로의 새 데이터 흐름은 방지되지 않습니다.

체크포인팅

숙련된 Spark Structured Streaming 개발자라면 위의 코드에서 체크포인팅이 누락된 것을 알 수 있습니다. Spark Structured Streaming에서 체크포인팅은 성공적으로 처리된 데이터에 대한 진행 상황 정보를 유지하는 데 필요하며, 실패 시 이 메타데이터를 사용하여 중단된 쿼리를 정확히 중단된 지점에서 다시 시작합니다.

체크포인트는 Spark Structured Streaming에서 정확히 한 번의 보장으로 실패 복구에 필요하지만, DLT는 수동 구성이나 명시적인 체크포인팅 없이 상태를 자동으로 처리합니다.

SQL과 Python을 DLT 파이프라인에 혼합 사용

DLT 파이프라인은 여러 노트북으로 구성될 수 있지만, 하나의 DLT 노트북은 전체가 SQL 또는 Python으로 작성되어야 합니다(다른 Databricks 노트북과 달리 단일 노트북에 다른 언어의 셀을 포함할 수 있음).

이제 SQL을 선호하는 경우 Python으로 한 노트북에서 Apache Kafka의 데이터 수집을 코딩한 다음 다른 노트북에서 SQL로 데이터 파이프라인의 변환 로직을 구현할 수 있습니다.

스키마 매핑

메시징 플랫폼에서 데이터를 읽을 때 데이터 스트림은 불투명하며 스키마를 제공해야 합니다.

아래 Python 예제는 피트니스 추적기에서 오는 이벤트의 스키마 정의와 Kafka 메시지의 값 부분이 이 스키마에 매핑되는 방법을 보여줍니다.

이점

DLT에서 메시지 브로커에서 직접 스트리밍 데이터를 읽으면 아키텍처 복잡성이 최소화되고 데이터가 메시징 브로커에서 직접 스트리밍되고 중간 단계가 없으므로 엔드투엔드 지연 시간이 단축됩니다.

클라우드 객체 스토어 중개자를 이용한 스트리밍 수집

특정 사용 사례의 경우, Kafka 커넥터를 사용하는 등 Apache Kafka에서 데이터를 오프로드하여 스트리밍 데이터를 클라우드 객체 중개자에 저장할 수 있습니다. Databricks 작업 공간에서는 클라우드 공급업체별 객체 스토어를 Databricks 파일 시스템(DBFS)을 통해 클라우드 독립적인 폴더로 매핑할 수 있습니다. 데이터가 오프로드되면 Databricks Auto Loader를 사용하여 파일을 수집할 수 있습니다.

Auto Loader는 단 한 줄의 SQL 코드로 데이터를 수집할 수 있습니다. DLT 테이블로 JSON 파일을 수집하는 구문은 다음과 같습니다 (가독성을 위해 두 줄로 나뉩니다).

Auto Loader 자체는 스트리밍 데이터 소스이며 새로 도착하는 모든 파일은 정확히 한 번 처리되므로, 해당 테이블로 데이터가 점진적으로 수집됨을 나타내는 raw 테이블의 스트리밍 키워드를 사용합니다.

스트리밍 데이터를 클라우드 객체 스토어로 오프로드하면 시스템 아키텍처에 추가 단계가 도입되므로 종단 간 지연 시간이 증가하고 추가 스토리지 비용이 발생합니다. 클라우드 객체 스토어에 이벤트 데이터를 쓰는 Kafka 커넥터를 관리해야 하므로 운영 복잡성이 증가한다는 점을 명심하십시오.

따라서 Databricks는 모범 사례로 위에서 설명한 대로 Spark Structured Streaming을 사용하여 DLT에서 직접 이벤트 버스 데이터에 액세스하는 것을 권장합니다.

다른 이벤트 버스 또는 메시징 시스템

이 문서는 Apache Kafka를 중심으로 다루지만, 논의된 개념은 다른 이벤트 버스 또는 메시징 시스템에도 적용됩니다. DLT는 Databricks Runtime이 직접 지원하는 모든 데이터 소스를 지원합니다.

Amazon Kinesis

Kinesis에서는 완전히 관리되는 서버리스 스트림에 메시지를 씁니다. Kafka와 마찬가지로 Kinesis는 메시지를 영구적으로 저장하지 않습니다. Kinesis의 기본 메시지 보존 기간은 하루입니다.

Amazon Kinesis를 사용할 때는 위에서 설명한 스트리밍 수집을 위한 Python 코드에서 format("kafka")을 format("kinesis")으로 바꾸고 option()을 사용하여 Amazon Kinesis별 설정을 추가합니다. 자세한 내용은 Spark Structured Streaming 설명서의 Kinesis 통합 섹션을 참조하십시오.

Azure Event Hubs

Azure Event Hubs 설정은 Microsoft의 공식 설명서와 Delta Live Tables 레시피: Azure Event Hubs에서 수집 문서를 참조하십시오.

요약

DLT는 ETL의 "T" 그 이상입니다. DLT를 사용하면 스트리밍 및 배치 소스에서 쉽게 데이터를 수집하고, 모든 클라우드의 Databricks Lakehouse Platform에서 데이터 품질을 보장하며 데이터를 정리하고 변환할 수 있습니다.

Apache Kafka의 데이터는 DLT 노트북에서 Python을 사용하여 Kafka 브로커에 직접 연결함으로써 수집할 수 있습니다. Kafka 스트리밍 계층의 원본 데이터가 만료된 경우에도 전체 파이프라인 새로 고침에 대한 데이터 손실을 방지할 수 있습니다.

시작하기

Databricks 고객인 경우, 시작하기 가이드를 따르십시오. 릴리스 노트를 읽고 이번 GA 릴리스에 포함된 내용에 대해 자세히 알아보십시오. 아직 Databricks 고객이 아닌 경우, 무료 평가판에 가입하시면 자세한 DLT 가격 정보를 여기에서 확인할 수 있습니다.

데이터에 열광하는 동료들이 Data + AI Summit 2022 발표 및 업데이트에 대해 이야기하는 Databricks 커뮤니티에서 대화에 참여하세요. 배우고, 네트워킹하세요.

마지막으로, 서밋의 데이터 엔지니어링 심층 분석 세션을 즐겨보세요. 이 세션에서는 트위터 실시간 스트림, Auto Loader, SQL의 Delta Live Tables 및 Hugging Face 감성 분석을 사용한 또 다른 스트리밍 데이터 예제의 코드를 자세히 설명합니다.

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