증분 스트림을 처리하는 이유는 무엇인가요?
오늘날의 데이터 기반 비즈니스는 지속적으로 데이터를 생성하므로 이 데이터를 지속적으로 수집하고 변환하는 엔지니어링 데이터 파이프라인이 필요합니다. 이러한 파이프라인은 데이터를 정확히 한 번 처리하고 배달하고, 대기 시간이 200밀리초 미만인 결과를 생성하고, 항상 비용을 최소화할 수 있어야 합니다.
이 문서에서는 데이터 파이프라인 엔지니어링을 위한 일괄 처리 및 증분 스트림 처리 방법, 증분 스트림 처리가 더 나은 옵션인 이유, Databricks 증분 스트림 처리 제품 시작, Azure Databricks 스트리밍
반복되는 일괄 처리 작업의 문제
데이터 파이프라인을 설정할 때 처음에는 반복된 일괄 처리 작업을 작성하여 데이터를 수집할 수 있습니다. 예를 들어 매시간 원본에서 읽고 Delta Lake와 같은 싱크에 데이터를 쓰는 Spark 작업을 실행할 수 있습니다. 이 접근 방식의 문제점은 매시간 실행되는 Spark 작업이 이전 작업이 끝난 지점에서 시작해야 하기 때문에 원본을 점진적으로 처리하는 것입니다. 처리한 데이터의 최신 타임스탬프를 기록한 다음 타임스탬프가 해당 타임스탬프보다 더 최근인 모든 행을 선택할 수 있지만 다음과 같은 문제가 있습니다.
연속 데이터 파이프라인을 실행하려면 원본에서 증분 방식으로 읽고, 변환을 수행하고, 결과를 Delta Lake와 같은 싱크에 쓰는 시간별 일괄 처리 작업을 예약하려고 할 수 있습니다. 이 방법에는 다음과 같은 문제가 있을 수 있습니다.
- 타임스탬프 후 모든 새 데이터를 쿼리하는 Spark 작업에서 지연 데이터가 누락됩니다.
- 실패하는 Spark 작업은 신중하게 처리되지 않은 경우 정확히 한 번 보장을 위반할 수 있습니다.
- 새 파일을 찾기 위해 클라우드 스토리지 위치의 콘텐츠를 나열하는 Spark 작업은 비용이 많이 듭니다.
그런 다음 이 데이터를 반복적으로 변환해야 합니다. 반복된 일괄 처리 작업을 작성한 다음 데이터를 집계하거나 다른 작업을 적용하여 파이프라인의 효율성을 더욱 복잡하게 만들고 줄일 수 있습니다.
일괄 처리 예제
파이프라인에 대한 일괄 처리 수집 및 변환의 문제를 완전히 이해하려면 다음 예제를 고려하세요.
누락된 데이터
고객에게 청구할 요금을 결정하는 사용량 데이터가 포함된 Kafka 토픽과 파이프라인이 일괄 처리로 수집되는 경우 이벤트 시퀀스는 다음과 같습니다.
- 첫 번째 일괄 처리에는 오전 8시와 오전 8시 30분에 두 개의 레코드가 있습니다.
- 최신 타임스탬프를 오전 8시 30분으로 업데이트합니다.
- 당신은 오전 8시 15분에 또 다른 기록을 얻습니다.
- 두 번째 일괄 처리는 오전 8시 30분 이후의 모든 항목에 대해 쿼리하므로 오전 8시 15분에 레코드를 놓치게 됩니다.
또한 사용자를 과충전하거나 과충전하지 않으려는 경우 모든 레코드를 정확히 한 번 수집해야 합니다.
중복 처리
다음으로, 데이터에 사용자 구매 행이 포함되어 있으며 스토어에서 가장 인기 있는 시간을 알 수 있도록 시간당 매출을 집계한다고 가정합니다. 같은 시간에 대한 구매가 서로 다른 일괄 처리로 도착하는 경우 동일한 시간 동안 출력을 생성하는 여러 일괄 처리가 있습니다.
오전 8시~오전 9시 창에는 두 개의 항목(배치 1의 결과물), 하나의 항목(배치 2의 결과물), 또는 세 개의 항목(어떤 배치에서도 나오지 않은 결과물)이 있나요? 지정된 시간 창을 생성하는 데 필요한 데이터는 여러 변환 일괄 처리에 걸쳐 표시됩니다. 이 문제를 해결하려면 데이터를 매일 분할하고 결과를 계산해야 할 때 전체 파티션을 다시 처리할 수 있습니다. 그런 다음 싱크에서 결과를 덮어쓸 수 있습니다.
그러나 두 번째 일괄 처리는 이미 처리되었을 수 있는 데이터를 처리하는 불필요한 작업을 수행해야 하기 때문에 대기 시간 및 비용이 발생합니다.
증분 스트림 처리에 문제가 없음
증분 스트림 처리를 사용하면 반복된 일괄 처리 작업의 모든 문제를 방지하여 데이터를 수집하고 변환할 수 있습니다. Databricks 구조적 스트리밍 및 Delta Live Tables는 스트리밍의 구현 복잡성을 관리하여 귀하가 비즈니스 논리에만 집중할 수 있게 합니다. 연결할 원본, 데이터에 대해 수행해야 하는 변환 및 결과를 작성할 위치를 지정하기만 하면 됩니다.
증분 수집
Databricks의 증분 수집은 Apache Spark 구조적 스트리밍을 통해 구동되며, 증분 방식으로 데이터 원본을 사용하고 싱크에 쓸 수 있습니다. 구조적 스트리밍 엔진은 데이터를 정확히 한 번 사용할 수 있으며 엔진은 순서가 다른 데이터를 처리할 수 있습니다. 엔진은 Notebook에서 실행하거나 Delta Live Tables의 스트리밍 테이블을 사용하여 실행할 수 있습니다.
Databricks의 구조적 스트리밍 엔진은 비용 효율적인 방법으로 클라우드 파일을 증분 처리할 수 있는 AutoLoader와 같은 독점 스트리밍 원본을 제공합니다. Databricks는 Apache Kafka, Amazon Kinesis, Apache Pulsar 및 Google Pub/Sub와 같은 다른 인기 있는 메시지 버스용 커넥터도 제공합니다.
증분 변환
구조적 스트리밍을 사용하는 Databricks의 증분 변환을 사용하면 일괄 처리 쿼리와 동일한 API를 사용하여 DataFrames에 대한 변환을 지정할 수 있지만, 시간이 지남에 따라 일괄 처리 및 집계된 값 간에 데이터를 추적하므로 필요하지 않습니다. 데이터를 다시 처리할 필요가 없으므로 반복되는 일괄 처리 작업보다 더 빠르고 비용 효율적입니다. 구조적 스트리밍은 Delta Lake, Kafka 또는 지원되는 다른 커넥터와 같이 싱크에 추가할 수 있는 데이터 스트림을 생성합니다.
델타 라이브 테이블에서 구체화된 뷰는 엔자임 엔진으로 운영됩니다. Enzyme는 여전히 소스를 점진적으로 처리하지만, 스트림을 생성하는 대신 물질화된 뷰를 생성합니다. 이는 사용자가 제공한 쿼리의 결과를 저장하는 미리 계산된 테이블입니다. 엔자임은 새로운 데이터가 쿼리 결과에 미치는 영향을 효율적으로 파악하고, 사전 계산된 테이블 up-to를 유지합니다.
구체화된 뷰는 집계 데이터를 기반으로 항상 효율적으로 업데이트되는 뷰를 만듭니다. 예를 들어 위에서 설명한 시나리오에서 오전 8시부터 오전 9시까지의 시간 범위에는 세 가지 요소가 있다는 것을 알 수 있습니다.
구조화된 스트리밍 또는 델타 라이브 테이블
구조적 스트리밍과 델타 라이브 테이블 간의 중요한 차이점은 스트리밍 쿼리를 운영하는 방식입니다. 구조적 스트리밍에서는 여러 구성을 수동으로 지정하고 쿼리를 수동으로 연결해야 합니다. 쿼리를 명시적으로 시작하고, 쿼리가 종료될 때까지 기다렸다가 실패 시 취소하고, 기타 작업을 수행해야 합니다. Delta Live Tables에서는 파이프라인을 실행하도록 선언적으로 지정하면, 계속해서 파이프라인이 실행되도록 유지합니다.
Delta Live 테이블에는 구체화된 뷰같은 기능도 있어 데이터의 변환을 효율적이고 증분적으로 미리 계산합니다.
이러한 기능에 대한 자세한 내용은
다음 단계
Delta Live Tables를 사용하여 첫 번째 파이프라인을 만듭니다. 자습서: 첫 번째 Delta Live Tables 파이프라인실행합니다.
Databricks에서 첫 번째 구조적 스트리밍 쿼리를 실행합니다. 첫 번째 구조적 스트리밍 워크로드 실행을 참조하세요.
구체화된 뷰를 사용합니다. 에서 Databricks SQL에서 구체화된 뷰 사용을 참조하세요.