Lakeflow Spark 선언적 파이프라인에 대한 모범 사례

이 페이지에서는 Lakeflow Spark 선언적 파이프라인을 사용하여 파이프라인을 디자인, 빌드 및 운영하기 위한 권장 패턴을 설명합니다. 새 파이프라인을 시작하거나 기존 파이프라인을 개선할 때 이러한 지침을 적용합니다.

올바른 데이터 세트 형식 선택

Lakeflow Spark 선언적 파이프라인은 스트리밍 테이블, 구체화된 뷰 및 임시 뷰의 세 가지 데이터 세트 형식을 제공합니다. 파이프라인의 각 계층에 적합한 형식을 선택하면 불필요한 컴퓨팅 비용이 방지되고 코드를 쉽게 추론할 수 있습니다.

스트리밍 테이블 은 데이터 수집 및 짧은 대기 시간 스트리밍 변환에 적합한 선택입니다. 각 입력 행은 한 번만 읽고 처리하므로 클라우드 스토리지 또는 메시지 버스의 추가 전용 워크로드, 대용량 데이터 및 이벤트 기반 처리에 적합합니다.

구체화된 뷰 는 복잡한 변환 및 분석 쿼리에 적합한 선택입니다. 결과는 미리 계산되고 증분 새로 고침을 사용하여 최신 상태로 유지되므로 이에 대한 쿼리는 빠릅니다. 구체화된 뷰에서는 데이터를 직접 수정할 수 없습니다. 쿼리 정의가 출력을 제어합니다.

임시 뷰 는 스토리지에 데이터를 구체화하지 않고 변환 논리를 구성하는 파이프라인 범위 뷰입니다. 자체 테이블이 필요하지 않은 중간 단계에 사용합니다.

다음 표에서는 각 형식을 사용하는 시기를 요약합니다.

사용 사례	권장 형식	Reason
클라우드 스토리지 또는 메시지 버스에서 수집	스트리밍 테이블	각 레코드를 한 번 처리합니다. 는 대용량 및 추가 전용 워크로드를 처리합니다.
CDC 스트림(삽입, 업데이트, 삭제)	스트리밍 테이블	정렬되고 중복 제거된 CDC 수집의 대상 `APPLY CHANGES INTO`으로 사용됩니다.
복잡한 집계 및 조인	구체화된 뷰	점진적으로 새로고침; 각 업데이트에서 전체 재계산을 피합니다.
대시보드 질의 처리 속도 향상	구체화된 뷰	미리 계산된 결과는 원시 테이블보다 쿼리를 더 빠르게 만듭니다.
중간 변환(다운스트림 판독기 없음)	임시 보기	스토리지 비용을 발생시키지 않고 파이프라인 논리를 구성합니다.

자세한 내용은 스트리밍 테이블, 구체화된 뷰 및 Lakeflow Spark 선언적 파이프라인 개념을 참조하세요.

명령적 MERGE 대신 선언적 CDC 사용

명령적 SQL MERGE 문을 사용하여 CDC(변경 데이터 캡처)를 구현하려면 이벤트 순서 지정, 중복 제거, 부분 업데이트 및 스키마 진화를 올바르게 처리하기 위한 중요한 사용자 지정 코드가 필요합니다. 이러한 각 문제는 독립적으로 해결해야 하며, 결과 코드는 유지 관리 및 테스트하기 어렵습니다.

Lakeflow Spark 선언적 파이프라인은 순서 지정, 중복 제거, 순서가 다른 이벤트 및 스키마 진화를 선언적으로 처리하는 문(SQL) 및 APPLY CHANGES INTO 함수(Python)를 제공합니다apply_changes(). 변경 피드의 모양과 대상 테이블에 대해 설명합니다. 파이프라인은 나머지를 처리합니다. APPLY CHANGES INTO 는 SCD 유형 1(덮어쓰기) 및 SCD 형식 2(기록 보존)를 모두 지원합니다.

자세한 내용은 변경 데이터 캡처 및 스냅샷 및 AUTO CDC API: 파이프라인을 사용하여 변경 데이터 캡처 간소화를 참조하세요.

기대에 따라 데이터 품질 적용

예상은 데이터 세트를 통과하는 모든 행에 적용되는 true/false SQL 식입니다. 행이 조건에 실패하면 파이프라인은 구성한 위반 정책에 따라 응답합니다. 예상은 정책에 관계없이 파이프라인 이벤트 로그에 메트릭을 내보내므로 시간이 지남에 따라 데이터 품질 추세를 추적할 수 있습니다.

위반 정책 선택

세 가지 위반 정책을 사용할 수 있습니다. 잘못된 데이터에 대한 허용 오차와 일치하는 항목을 선택합니다.

경고 (기본값): 유효하지 않은 레코드는 대상 테이블에 기록되고 메트릭에 플래그가 지정됩니다. 모든 데이터를 캡처해야 하지만 품질 문제에 대한 가시성을 원하는 경우 이 정책을 사용합니다.
drop: 유효하지 않은 레코드는 쓰기 전에 삭제됩니다. 잘못된 행이 예상되고 다운스트림으로 전파되어서는 안 되는 경우 이를 사용합니다.
fail: 파이프라인 업데이트가 첫 번째 잘못된 레코드에서 중지됩니다. 잘못된 레코드가 심각한 업스트림 문제를 나타내는 중요한 데이터에 사용합니다.

다음 예제에서는 스트리밍 테이블에 적용된 각 정책을 보여 줍니다.

SQL

-- Warn: write invalid records but track them in metrics
CREATE OR REFRESH STREAMING TABLE orders_raw (
  CONSTRAINT valid_order_id EXPECT (order_id IS NOT NULL)
) AS SELECT * FROM STREAM read_files("/volumes/raw/orders", format => "json");

-- Drop: discard invalid records before writing
CREATE OR REFRESH STREAMING TABLE orders_clean (
  CONSTRAINT non_negative_amount EXPECT (amount >= 0) ON VIOLATION DROP ROW
) AS SELECT * FROM STREAM(orders_raw);

-- Fail: stop the pipeline on any invalid record
CREATE OR REFRESH STREAMING TABLE orders_critical (
  CONSTRAINT required_customer_id EXPECT (customer_id IS NOT NULL) ON VIOLATION FAIL UPDATE
) AS SELECT * FROM STREAM(orders_clean);

파이썬

from pyspark import pipelines as dp

# Warn: write invalid records but track them in metrics
@dp.table
@dp.expect("valid_order_id", "order_id IS NOT NULL")
def orders_raw():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "json") \
        .load("/volumes/raw/orders")

# Drop: discard invalid records before writing
@dp.table
@dp.expect_or_drop("non_negative_amount", "amount >= 0")
def orders_clean():
    return spark.readStream.table("orders_raw")

# Fail: stop the pipeline on any invalid record
@dp.table
@dp.expect_or_fail("required_customer_id", "customer_id IS NOT NULL")
def orders_critical():
    return spark.readStream.table("orders_clean")

잘못된 레코드 격리 관리

레코드를 조용히 삭제하는 대신 조사를 위해 삭제된 레코드를 유지하려면 격리 패턴을 사용합니다. 두 개의 흐름을 사용하여 별도의 스트리밍 테이블로 유효성 검사에 실패한 행을 라우팅합니다. 하나는 주 테이블에서 잘못된 행을 삭제하고 다른 하나는 잘못된 행만 격리 테이블에 쓰는 것입니다. 이렇게 하면 클린 데이터 세트를 오염하지 않고 잘못된 데이터를 조사, 수정 및 다시 처리할 수 있습니다.

격리 패턴에 대한 자세한 예제는 Expectation 권장 사항 및 고급 패턴을 참조하세요.

기대에 대한 자세한 내용은 파이프라인 기대치를 사용하여 데이터 품질 관리를 참조하세요.

파이프라인 매개 변수화

파이프라인에는 기본 카탈로그 및 스키마 설정이 있으므로 동일한 카탈로그 및 스키마 내에서 읽고 쓰는 코드는 매개 변수 없이 환경에서 작동합니다. 그러나 파이프라인이 두 번째 카탈로그 또는 스키마(예: 개발과 프로덕션 간에 다른 공유 소스 카탈로그에서 읽기)를 참조해야 하는 경우 소스 코드에서 직접 해당 이름을 하드 코딩하지 마세요. 대신 파이프라인 구성 매개 변수(파이프라인 설정에 설정된 키-값 쌍)로 정의하고 코드에서 참조합니다. 이렇게 하면 매개 변수 값을 교환하여 단일 코드베이스를 환경 간에 올바르게 실행할 수 있습니다.

SQL

CREATE OR REFRESH MATERIALIZED VIEW transaction_summary AS
SELECT account_id, COUNT(txn_id) AS txn_count, SUM(amount) AS total_amount
FROM ${source_catalog}.sales.transactions
GROUP BY account_id;

파이썬

from pyspark import pipelines as dp
from pyspark.sql.functions import count, sum

@dp.materialized_view
def transaction_summary():
    source_catalog = spark.conf.get("source_catalog")
    return spark.read.table(f"{source_catalog}.sales.transactions") \
        .groupBy("account_id") \
        .agg(
            count("txn_id").alias("txn_count"),
            sum("amount").alias("total_amount")
        )

자세한 내용은 파이프라인에서 매개 변수 사용을 참조하세요.

각 환경에 적합한 파이프라인 모드 선택

개발 및 프로덕션 업데이트 모드

파이프라인은 개발 또는 프로덕션 업데이트 모드에서 실행됩니다. 목표와 일치하는 모드를 선택합니다.

개발 모드에서 파이프라인은 업데이트 간에 장기 실행 클러스터를 다시 사용하고 오류에 대해 다시 시도하지 않습니다. 이렇게 하면 클러스터 다시 시작을 기다리지 않고 오류 세부 정보를 즉시 얻을 수 있으므로 파이프라인 코드를 작성하고 테스트할 때 반복 주기가 단축됩니다.

프로덕션 모드에서는 각 업데이트가 완료된 후 클러스터가 즉시 종료되어 컴퓨팅 비용이 절감됩니다. 또한 파이프라인은 클러스터 다시 시작을 포함하여 에스컬레이션 재시도를 적용하여 일시적인 인프라 오류를 자동으로 처리합니다. 예약된 모든 파이프라인 실행에 프로덕션 모드를 사용합니다.

트리거된 파이프라인 모드와 연속 파이프라인 모드 비교

트리거된 모드는 사용 가능한 모든 데이터를 처리한 다음 중지합니다. 대부분의 파이프라인에 적합한 선택입니다. 즉, 일정(매시간, 매일 또는 주문형)으로 실행되며 분 미만의 데이터 새로 고침이 필요하지 않습니다.

연속 모드 는 클러스터가 계속 실행되고 새 데이터가 도착하면 처리합니다. 사용 사례에 초~분 범위의 대기 시간이 필요한 경우에만 적합합니다. 연속 모드에는 Always-On 클러스터가 필요하므로 트리거된 모드보다 훨씬 더 비쌉니다.

자세한 내용은 트리거된 파이프라인 모드와 연속 파이프라인 모드 및 파이프라인 구성을 참조하세요.

데이터 레이아웃에 액체 클러스터링 사용

Liquid 클러스터링이 정적 분할을 대체하고 ZORDER 델타 테이블에서 데이터 레이아웃을 최적화합니다. 파티션 열을 미리 선택해야 하고 값이 고르지 않게 분산될 경우 데이터 편향이 발생할 수 있는 분할과 달리, 액체 클러스터링은 자체적으로 조정되며 데이터 편향을 방지하고 점진적입니다. 각 실행마다 재구성이 필요한 데이터만 다시 작성됩니다.

쿼리 패턴이 진화함에 따라 전체 테이블을 다시 작성하지 않고 언제든지 클러스터링 열을 변경합니다.

스트리밍 테이블 정의에서 클러스터링 열을 정의합니다.

SQL

CREATE OR REFRESH STREAMING TABLE events
CLUSTER BY (event_date, region)
AS SELECT * FROM STREAM read_files("/volumes/raw/events", format => "parquet");

파이썬

from pyspark import pipelines as dp

@dp.table(cluster_by=["event_date", "region"])
def events():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "parquet") \
        .load("/volumes/raw/events")

열을 클러스터링하는 방법을 잘 모르는 경우, Databricks가 쿼리 워크로드에 따라 최적의 클러스터링 열을 자동으로 선택할 수 있도록 CLUSTER BY AUTO를 사용하세요.

자세한 내용은 스트리밍 테이블을 참조하고 테이블에 액체 클러스터링을 사용합니다.

CI/CD 및 Databricks 자산 번들을 사용하여 파이프라인 관리

파이프라인 소스 코드를 버전 제어하고 Databricks 자산 번들을 사용하여 환경 전반의 배포를 관리합니다.

자세한 내용은 원본 제어 파이프라인 만들기, 파이프라인을 Databricks 자산 번들 프로젝트로 변환 및 파이프라인과 함께 매개 변수 사용을 참조하세요.

버전 제어에 파이프라인 코드 저장

모든 파이프라인 원본 파일(Python 및 SQL)을 Git 리포지토리에 번들 구성과 함께 저장합니다. 전체 프로젝트를 버전 제어하면 변경 내용의 전체 기록을 제공하고, 공동 작업을 더 쉽게 수행할 수 있으며, 프로덕션 환경으로 승격하기 전에 개발 환경에서 변경 내용의 유효성을 검사할 수 있습니다.

Databricks는 이 워크플로를 관리하기 위해 Databricks 자산 번들을 권장합니다 . 번들은 소스 코드와 함께 YAML에서 파이프라인 구성을 정의하고 databricks bundle CLI를 사용하면 터미널 또는 CI/CD 시스템에서 파이프라인의 유효성을 검사, 배포 및 실행할 수 있습니다.

환경 격리에 번들 대상 사용

번들은 여러 대상(예: dev, staging, prod)을 지원하며, 각 대상은 카탈로그 이름, 클러스터 정책, 알림 주소 및 기타 설정에 대해 자체 재정의 집합을 포함합니다. 번들 대상을 파이프라인 매개 변수와 결합하여 배포 시 올바른 환경별 값을 삽입하여 소스 코드에 환경 상수가 없는 상태로 유지합니다.

일반적인 워크플로는 다음과 같습니다.

개발자는 기능 분기에서 작업하여 개발 카탈로그의 개인 개발 파이프라인에 배포합니다.
주 분기에 병합할 때 CI 시스템은 databricks bundle validate 및 databricks bundle deploy --target staging을 실행하여 파이프라인을 유효성 검사하고 스테이징 환경에 배포합니다.
테스트가 통과하면 CI 시스템이 프로덕션 databricks bundle deploy --target prod에 배포됩니다.

스트리밍 모범 사례

이러한 패턴을 사용하여 상태를 관리하고, 지연 데이터를 제어하고, 스트리밍 파이프라인을 안정적으로 유지합니다.

자세한 내용은 워터마크를 사용하여 유지 처리 최적화, 스트리밍 검사점(CP) 오류로부터 파이프라인 복구 및 파이프라인을 사용하여 기록 데이터를 백필을 참조하세요.

상태 저장 작업에 워터마크를 사용하세요

워터마크는 창이 있는 집계 및 중복 제거와 같은 상태 저장 스트리밍 작업 중에 파이프라인이 메모리에 유지하는 상태를 바인딩합니다. 워터마크가 없으면 파이프라인이 가능한 모든 키에 대한 데이터를 누적하여 결국 장기 실행 파이프라인에서 메모리 부족 오류가 발생함에 따라 상태가 무제한으로 증가합니다.

워터마크는 타임스탬프 열과 지연 데이터에 대한 허용 오차 임계값을 지정합니다. 임계값을 통과한 후 도착하는 레코드는 삭제됩니다. 대기 데이터에 대한 허용 오차와 해당 상태를 열어 두는 메모리 비용의 균형을 맞추는 임계값을 선택합니다.

다음 예제에서는 1분 텀블링 창 집계를 3분 워터마크와 함께 계산합니다.

SQL

CREATE OR REFRESH STREAMING TABLE event_counts AS
SELECT window(event_time, '1 minute') AS time_window, region, COUNT(*) AS cnt
FROM STREAM(events_raw)
  WATERMARK event_time DELAY OF INTERVAL 3 MINUTES
GROUP BY time_window, region;

파이썬

from pyspark import pipelines as dp
from pyspark.sql.functions import window

@dp.table
def event_counts():
    return (
        spark.readStream.table("events_raw")
            .withWatermark("event_time", "3 minutes")
            .groupBy(window("event_time", "1 minute"), "region")
            .count()
    )

메모

각 업데이트에서 완전히 다시 계산되지 않고 집계가 증분 방식으로 처리되도록 하려면 워터마크를 정의해야 합니다.

스트리밍 상태 및 전체 새로 고침 이해

스트리밍 상태는 증분입니다. 파이프라인은 매번 처음부터 다시 계산하지 않고 업데이트 간에 상태를 빌드하고 유지 관리합니다. 이는 상태 저장 스트리밍을 효율적으로 만드는 것이지만 상태 저장 쿼리의 논리를 변경하는 경우(예: 워터마크 임계값 수정 또는 집계 열 변경) 기존 상태가 더 이상 새 논리와 호환되지 않는다는 것을 의미합니다. 이 경우 모든 기록 데이터를 새 논리로 다시 처리하고 상태를 처음부터 다시 빌드하려면 전체 새로 고침을 수행해야 합니다.

전체 새로 고침은 원본이 기록 데이터를 유지하지 않는 경우 데이터 손실로 이어질 수도 있습니다. 예를 들어 보존 기간이 짧은 Kafka 원본은 새로 고침 시 사용 가능한 데이터의 마지막 몇 분만 가질 수 있으므로 이전보다 훨씬 적은 데이터가 포함된 테이블이 생성됩니다. 특히 전체 새로 고침 비용이 많이 들거나 원본에 데이터 보존이 제한된 대용량 스트림의 경우 상태 저장 쿼리 논리 변경을 신중하게 계획합니다. medallion 아키텍처를 사용하면 최소한의 변환으로 브론즈 테이블을 생성하는 데 도움이 되며, 실버 또는 골드 테이블이 브론즈 테이블의 전체 기록으로부터 다시 계산할 수 있습니다.

스트림-스트림 조인

스트림 스트림 조인에는 조인의 양쪽 에 워터마크 및 시간 제한 조인 조건이 필요합니다. 조인 조건의 시간 간격은 더 이상 일치할 수 없는 경우 스트리밍 엔진에 알려 더 이상 일치시킬 수 없는 상태를 제거할 수 있도록 합니다. 워터마크 또는 시간 제한 조건을 생략하면 상태는 바인딩되지 않고 증가합니다.

다음 예제에서는 광고 노출 이벤트를 클릭 이벤트와 조인하여 클릭이 노출 후 3분 이내에 발생하도록 합니다.

SQL

CREATE OR REFRESH STREAMING TABLE impression_clicks AS
SELECT imp.ad_id, imp.impression_time, clk.click_time
FROM STREAM(ad_impressions)
    WATERMARK impression_time DELAY OF INTERVAL 3 MINUTES AS imp
JOIN STREAM(user_clicks)
    WATERMARK click_time DELAY OF INTERVAL 3 MINUTES AS clk
ON imp.ad_id = clk.ad_id
  AND clk.click_time BETWEEN imp.impression_time
    AND imp.impression_time + INTERVAL 3 MINUTES;

파이썬

from pyspark import pipelines as dp
from pyspark.sql.functions import expr

dp.create_streaming_table("impression_clicks")

@dp.append_flow(target="impression_clicks")
def join_impressions_and_clicks():
    impressions = spark.readStream.table("ad_impressions") \
        .withWatermark("impression_time", "3 minutes")
    clicks = spark.readStream.table("user_clicks") \
        .withWatermark("click_time", "3 minutes")
    return impressions.alias("imp").join(
        clicks.alias("clk"),
        expr("""
            imp.ad_id = clk.ad_id AND
            clk.click_time BETWEEN imp.impression_time AND imp.impression_time + INTERVAL 3 MINUTES
        """),
        "leftOuter"
    )

정적 테이블(스냅샷 조인)에 대해 스트림을 조인하면 각 마이크로배치가 시작될 때 정적 테이블 스냅샷이 새로 고쳐집니다. 따라서, 지연 도착 차원 레코드는 이미 처리된 팩트에 소급 적용되지 않습니다. 소급 애플리케이션이 필요한 경우 구체화된 뷰를 사용하거나 파이프라인을 재구성합니다.

파이프라인 성능 최적화

이러한 기술을 적용하여 컴퓨팅 비용을 절감하고 파이프라인 업데이트 속도를 향상시킵니다.

자세한 내용은 구체화된 뷰 를 참조하고 워터마크를 사용하여 상태 저장 처리 최적화를 참조하세요.

작은 파일 방지

볼륨이 낮은 원본에서 파이프라인을 너무 자주 트리거하면 많은 수의 작은 파일이 클라우드 스토리지에 기록됩니다. 작은 파일은 각 파일에 별도의 메타데이터 조회 및 I/O 왕복이 필요하고 클라우드 스토리지 API는 대규모로 나열 작업을 제한하기 때문에 읽기 성능이 저하됩니다. 이를 방지하려면 데이터 볼륨과 일치하는 트리거 간격을 선택합니다. 연속적으로가 아니라 업데이트 간에 의미 있는 양의 데이터가 누적될 수 있도록 일정에 따라 트리거된 파이프라인을 실행합니다.

데이터 스큐 처리

조인 또는 groupBy 키의 값이 파티션 간에 고르지 않게 분산되어 적은 수의 작업이 대부분의 데이터를 처리하는 경우 데이터 오차가 발생합니다. 이렇게 하면 엔드 투 엔드 업데이트 시간을 늘리는 핫스폿이 만들어집니다. 액체 클러스터링을 사용하여 저장된 테이블의 기울이기를 해결합니다. 진행 중인 계산에서 발생하는 데이터 편향의 경우, 두 단계로 그룹화 및 집계하기 전에 임의의 버킷 접미사를 추가하여 고도로 편향된 키에 솔트를 추가합니다.

자세한 내용은 데이터 레이아웃에 액체 클러스터링 사용을 참조하세요.

구체화된 뷰에 증분 새로 고침 사용

큰 집계를 위해 실현된 뷰를 사용할 때, Lakeflow Spark 선언적 파이프라인은 전체 결과 집합을 다시 계산하는 대신 마지막 업데이트 이후의 상위 변경 사항만 처리하여 점진적으로 갱신하려고 시도합니다. 증분 새로 고침은 각 파이프라인 트리거에서 쿼리를 처음부터 다시 실행하는 것보다 훨씬 저렴합니다. 구체화된 뷰를 증분 방식으로 새로 고칠 가능성을 최대화하려면 간단하고 결정적인 집계 쿼리를 작성하고 비결정적 함수와 같이 증분 처리를 방지하는 구문을 방지합니다.

증분 새로 고침 에 대한 구체화된 뷰을 참조하세요.

조인 최적화

한쪽이 작은 차원 테이블인 조인의 경우 순서 섞기 조인을 수행하는 대신 Spark에 작은 테이블을 모든 실행기에 브로드캐스트하도록 지시하는 브로드캐스트 힌트를 추가합니다.

SQL

CREATE OR REFRESH MATERIALIZED VIEW enriched_orders AS
SELECT o.*, /*+ BROADCAST(p) */ p.product_name, p.category
FROM orders o
JOIN products p ON o.product_id = p.product_id;

파이썬

from pyspark import pipelines as dp
from pyspark.sql.functions import broadcast

@dp.materialized_view
def enriched_orders():
    orders = spark.read.table("orders")
    products = spark.read.table("products")
    return orders.join(broadcast(products), "product_id")

시계열 근접 조인(예: 시간 범위 내에서 가장 가까운 이벤트 찾기)의 경우 범위 조인 조건을 사용하고 스트림을 조인하는 경우 양쪽에 워터마크가 있는지 확인하거나 조인하기 전에 이벤트를 시간 버킷으로 미리 범주화하는 것이 좋습니다.

파이프라인 모니터링

파이프라인 이벤트 로그는 Lakeflow Spark 선언적 파이프라인의 기본 관찰 가능성 기본 형식입니다. 모든 파이프라인 실행은 실행 진행률, 데이터 품질 예상 결과, 데이터 계보 및 오류 세부 정보를 포함하는 구조적 레코드를 이벤트 로그에 씁니다. 이벤트 로그는 직접 쿼리할 수 있는 델타 테이블입니다.

기본 스토리지 경로를 모르고 이벤트 로그를 쿼리하려면 공유 클러스터 또는 SQL 웨어하우스에서 테이블 반환 함수를 사용합니다 event_log() .

SELECT * FROM event_log('<pipeline-id>')
WHERE event_type = 'flow_progress'
ORDER BY timestamp DESC
LIMIT 100;

예상 메트릭에 대한 이벤트 로그를 쿼리하여 데이터 품질 대시보드를 빌드합니다. 이 열에는 details 시간 경과에 따른 품질 추세를 추적하고 회귀에 대한 경고를 하는 데 사용할 수 있는 각 제약 조건에 대한 통과/실패 횟수가 포함된 중첩된 JSON 구조가 포함되어 있습니다.

이벤트 기반 경고의 경우 이벤트 후크를 사용하여 파이프라인이 실패하거나 데이터 품질 임계값을 위반할 때 사용자 지정 웹후크 또는 알림 서비스(예: Slack 또는 PagerDuty)를 트리거합니다. 이벤트 후크는 파이프라인 이벤트에 대한 응답으로 실행되는 Python 함수입니다.

자세한 내용은 파이프라인 모니터링, 파이프라인 이벤트 로그 및 이벤트 후크를 사용하여 파이프라인의 사용자 지정 모니터링 정의를 참조하세요.

서버리스 컴퓨팅 사용

Databricks는 새 파이프라인에 대해 서버리스 컴퓨팅을 권장합니다. 서버리스에서는 수동 클러스터 구성이 없습니다. Databricks는 인프라를 자동으로 관리합니다. 서버리스 파이프라인은 워크로드 요구에 대응하여 수평(더 많은 실행기) 및 수직(더 큰 실행기 크기)을 모두 확장할 수 있는 향상된 자동 크기 조정을 사용합니다. 서버리스 파이프라인은 항상 Unity 카탈로그를 사용하므로 거버넌스 및 계보 추적이 기본적으로 기본 제공됩니다.

자세한 내용은 서버리스 파이프라인 구성을 참조하세요.

medallion 아키텍처를 사용하여 파이프라인 구성

medallion 아키텍처는 각각 고유한 목적을 가진 세 개의 논리 계층(청동, 은, 금)으로 데이터를 구성합니다. Lakeflow Spark 선언적 파이프라인 데이터 세트 형식을 올바른 계층에 매핑하면 각 계층의 책임이 명확해지고 파이프라인을 더 쉽게 유지 관리할 수 있습니다.

Bronze: 스트리밍 테이블을 사용하여 클라우드 스토리지, 메시지 버스 또는 CDC 원본에서 원시 데이터를 수집합니다. Bronze 테이블은 최소한의 변환으로 원시 원본 데이터를 유지하므로 요구 사항이 변경되면 실버 또는 골드 레이어가 브론즈 계층의 원본에서 다시 처리할 수 있습니다.
실버: 증분 행 수준 변환(필터링, 정리 및 구문 분석)에 스트리밍 테이블을 사용합니다. 증분 새로 고침의 이점을 활용하는 차원 테이블 또는 복잡한 집계에 대한 보강 조인을 포함하는 실버 계층 논리의 경우 구체화된 뷰를 사용합니다.
골드: 구체화된 뷰를 사용하여 대시보드, 보고 도구 및 다운스트림 소비자에게 제공되는 집계, 메트릭 및 요약을 미리 계산합니다.

가능한 경우 수집(브론즈)과 변환(실버 및 골드)을 고유한 파이프라인 DAG로 구분합니다. 레이어를 분리하면 각 계층을 독립적으로 예약, 모니터링 및 문제를 해결할 수 있으며 변환 파이프라인의 오류로 새 데이터가 브론즈에 착륙하는 것을 차단하지는 않습니다.

자세한 내용은 스트리밍 테이블 및 구체화된 뷰를 참조하세요.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-03-15