[Databricks] File Arrival Trigger와 Auto Loader 비교: 차이점과 실전 Ingestion 전략

« 2026/10 »
일	월	화	수	목	금	토
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Cloud Storage에 파일이 들어오면 Databricks에서 자동으로 적재하고 싶을 때 File Arrival과 Auto Loader라는 두 기능을 만나게 된다.

이름만 보면 둘 다 “새 파일을 감지하는 기능”처럼 보이기 때문에 다음과 같은 질문이 생긴다.

File Arrival Trigger와 Auto Loader 중 무엇을 사용해야 할까?

결론부터 말하면 둘은 경쟁 기능이 아니다.

File Arrival Trigger는 새로운 파일이 생겼을 때 Lakeflow Job을 시작하는 실행 Trigger다.
Auto Loader는 새로운 파일을 추적하고 읽어서 Delta Table로 적재하는 Ingestion Engine이다.

File Arrival은 “언제 Compute를 실행할 것인가”를 결정하고, Auto Loader는 “어떤 파일을 어디까지 처리했으며 실패 후 어디서 재개할 것인가”를 관리한다.

따라서 불규칙하게 도착하는 파일을 안정적으로 적재하는 대표 전략은 다음과 같다.

File Arrival Trigger로 Job을 시작하고, Job 내부에서 Auto Loader를 AvailableNow로 실행한다.

이 구조는 파일이 없을 때 Compute를 실행하지 않으면서도 Auto Loader의 Checkpoint, Exactly-once, Schema Inference·Evolution과 장애 복구 기능을 그대로 사용할 수 있다.

이 글에서는 두 기능의 정확한 차이, 단독 사용의 위험, File Events와 Directory Listing, 비용 구조, 데이터량과 SLA에 따른 권장 패턴을 정리한다.

이 글은 2026년 8월 Databricks 공식 문서를 기준으로 작성했다. 지원 Runtime, File Events, Unity Catalog, Cloud별 Storage 권한과 기능은 변경될 수 있으므로 실제 적용 전 현재 환경을 확인해야 한다.

1. 한 장으로 이해하는 전체 구조

flowchart LR
          A["Cloud Storage · Managed File Events"] --> B["File Arrival Trigger"]
          B --> C["Lakeflow Job · Auto Loader AvailableNow"]
          C --> D["Checkpoint · Schema · Data Quality"]
          D --> E["Bronze Delta Table"]

각 구성요소의 책임은 다음과 같다.

구성요소	책임
Cloud Storage	원천 파일 보관
File Events	파일 생성·변경 Metadata를 효율적으로 전달·캐시
File Arrival Trigger	새 파일을 감지해 Job Run 생성
Lakeflow Job	Task 순서, 재시도, 알림, Compute 관리
Auto Loader	신규 파일 발견, Checkpoint, Schema, 증분 읽기
Delta Table	적재 결과의 ACID Transaction과 이력 관리

File Arrival Trigger가 Auto Loader의 Checkpoint를 대체하지 않으며, Auto Loader가 Job을 자동으로 생성해 주는 것도 아니다. 두 기능은 서로 다른 계층에서 동작한다.

2. File Arrival Trigger란?

File Arrival Trigger는 Unity Catalog External Location 또는 Volume의 Root나 Subpath를 감시하다가 새 파일이 도착하면 Lakeflow Job을 시작한다.

핵심 특징

File이 불규칙하게 도착할 때 Schedule의 불필요한 실행을 줄인다.
감시 경로의 모든 하위 디렉터리를 재귀적으로 확인한다.
External Location 또는 Volume과 Unity Catalog 권한을 사용한다.
File Events가 활성화된 External Location에서 더 효율적으로 동작한다.
Minimum time between triggers로 실행 빈도를 제한할 수 있다.
Wait after last change로 파일 Batch가 모두 도착할 때까지 기다릴 수 있다.
새 파일이 생겼다는 사실을 근거로 Job을 시작할 뿐, 파일 내용을 읽거나 Delta에 적재하지 않는다.

Databricks는 File Arrival Trigger가 새 파일을 Best-effort 방식으로 매분 확인한다고 설명한다. 실제 반응 시간은 Cloud Storage와 File Events 상태의 영향을 받을 수 있으므로 초 단위 실시간 Trigger로 이해하면 안 된다.

File Arrival Trigger가 하지 않는 일

어떤 파일을 이미 처리했는지 데이터 적재 상태를 관리하지 않는다.
파일 Schema를 추론하거나 변경을 처리하지 않는다.
Checkpoint와 Exactly-once 적재를 제공하지 않는다.
파일 내용을 Parse하지 않는다.
중복 Business Event를 제거하지 않는다.
Delta Table Write의 Transaction을 책임지지 않는다.

즉, Trigger가 두 번 실행되거나 Job이 재시도되어도 안전하려면 실제 처리 Task가 Idempotent해야 한다.

실행 빈도 제어

File Arrival Trigger에는 두 가지 중요한 고급 설정이 있다.

설정	의미	대표 용도
Minimum time between triggers	Run 사이 최소 간격을 보장하는 Cooldown	파일이 계속 들어올 때 실행 폭증 방지
Wait after last change	마지막 파일 이후 일정 시간 대기하는 Debounce	하나의 Batch 파일이 모두 도착한 후 실행

예를 들어 파일 Batch가 5분마다 도착하고 Batch 내부 파일들이 30초에 걸쳐 들어온다면 다음처럼 설정할 수 있다.

Minimum time between triggers: 300초
Wait after last change: 60초

새 파일이 들어올 때마다 60초 Timer가 다시 시작된다. 마지막 파일 이후 60초간 추가 도착이 없으면 Job이 실행되며, Run은 5분보다 자주 만들어지지 않는다.

주요 제약

같은 이름의 기존 파일을 덮어써도 새로운 File Arrival로 Trigger되지 않는다.
감시 Path에 *, ? 같은 Wildcard를 사용할 수 없다.
Path 내부에 External Table이나 Catalog·Schema의 Managed Location이 포함되면 안 된다.
File Events를 사용하지 않는 위치는 Workspace당 Trigger 수와 감시 파일 수에 제약이 있다.
S3와 GCS에서는 존재하지 않거나 삭제된 디렉터리와 빈 디렉터리를 구분하지 못해 Trigger가 오류 없이 계속 평가될 수 있다.
많은 관련 없는 변경이 External Location Root에 발생하면 Subpath Trigger의 Metadata 처리량이 커져 Timeout이 발생할 수 있다.

고변경 환경에서는 적재 대상 Subdirectory만 가리키는 External Volume을 별도로 만들고 Volume Root를 감시하는 편이 안전하다.

3. Auto Loader란?

Auto Loader는 Cloud Object Storage에서 새 파일을 효율적으로 발견하고 증분 처리하는 Structured Streaming Source다. Spark에서는 cloudFiles Format으로 사용한다.

df = (
    spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "json")
        .load("/Volumes/raw/erp/orders/")
)

Auto Loader는 JSON, CSV, XML, Parquet, Avro, ORC, Text, Binary File 등을 지원하며 대규모 Backfill부터 근실시간 적재까지 사용할 수 있다.

핵심 특징

신규 파일 Metadata를 Checkpoint에 저장한다.
실패 후 마지막 처리 상태에서 재개한다.
Delta Sink와 함께 사용할 때 Exactly-once 처리를 제공한다.
수십억 개 파일의 Discovery와 Backfill을 확장성 있게 지원한다.
Schema Inference와 Evolution을 지원한다.
예기치 않은 필드를 _rescued_data 등에 보존할 수 있다.
Directory Listing과 File Notification 두 가지 Discovery Mode를 제공한다.
Continuous, Processing Time, AvailableNow 등 실행 방식과 조합할 수 있다.

Checkpoint가 핵심이다

Auto Loader는 발견한 파일 Metadata를 Checkpoint Location의 RocksDB 기반 상태 저장소에 기록한다.

(
    df.writeStream
      .option(
          "checkpointLocation",
          "/Volumes/platform_state/checkpoints/erp_orders"
      )
      .trigger(availableNow=True)
      .toTable("analytics_bronze.erp_orders")
)

Checkpoint는 단순 Log Directory가 아니다. 어떤 파일을 이미 처리했는지와 Stream 진행 상태를 나타내는 운영 자산이다.

임의로 삭제하지 않는다.
서로 다른 Pipeline이 같은 Checkpoint를 공유하지 않는다.
Source Path나 핵심 Query가 바뀔 때 호환성을 검토한다.
Target Table Directory 하위에 두지 않는다.
Unity Catalog로 관리되는 전용 Storage Location을 사용한다.

새 Checkpoint로 실행하면 기존 파일이 다시 처리될 수 있다. Checkpoint 초기화는 단순 재시작이 아니라 Reprocessing 결정으로 다뤄야 한다.

Exactly-once의 정확한 의미

Auto Loader의 Exactly-once는 동일 Checkpoint 기준으로 발견한 파일을 Delta Sink에 중복 Commit하지 않는다는 의미다.

다음까지 자동 보장하는 것은 아니다.

서로 다른 파일명에 같은 Business Record가 중복된 경우
원천 시스템이 동일 데이터를 여러 파일로 다시 전송한 경우
foreachBatch 내부의 외부 API·DB Write
Business Key 기준의 Upsert와 Delete
Event Time 순서

파일 단위 적재 보장과 업무 레코드 단위 중복 제거는 구분해야 한다. Bronze 이후 Silver에서 Business Key, Event Time, Sequence를 기준으로 Deduplication이나 AUTO CDC를 적용한다.

4. File Arrival과 Auto Loader 직접 비교

비교 항목	File Arrival Trigger	Auto Loader
기능 유형	Job Trigger	File Ingestion Engine
핵심 질문	언제 Job을 실행할까?	어떤 파일을 어떻게 적재할까?
데이터 읽기	하지 않음	수행
상태 관리	Job Trigger 상태	File 처리 상태와 Checkpoint
Exactly-once	제공하지 않음	Delta Sink와 Checkpoint 사용 시 제공
Schema Inference	없음	지원
Schema Evolution	없음	지원
장애 재개	Job 재시도 수준	Checkpoint에서 처리 재개
대규모 File Discovery	실행 신호 감지 목적	수십억 파일 적재에 최적화
기존 파일 Backfill	적재 기능 없음	지원
하위 Directory	재귀 감시	Source Path 아래 파일 처리
순서 보장	없음	없음
File Events	Trigger 감지 최적화	Discovery 최적화
비용 역할	불필요한 Job Run 감소	효율적인 Discovery·증분 처리
단독 사용	Job 내부 처리 로직이 필요	Schedule·Continuous 실행 가능

한 문장으로 줄이면 다음과 같다.

File Arrival은 Compute를 깨우고, Auto Loader는 데이터를 기억하며 옮긴다.

5. File Events, File Arrival, Auto Loader는 같은 것인가?

세 용어도 구분해야 한다.

Cloud File Event: S3·ADLS·GCS가 File 생성·변경 알림을 발생시킨다.
Databricks Managed File Events: Cloud Event를 수집해 최근 File Metadata를 관리형 서비스에 캐시한다.
File Arrival Trigger: File Event 또는 Listing 결과를 이용해 Job을 시작한다.
Auto Loader with File Events: 같은 File Event Cache에서 신규 파일을 효율적으로 발견해 적재한다.

flowchart LR
          A["Cloud Storage Event"] --> B["Managed File Events Cache"]
          B --> C["File Arrival Trigger"]
          B --> D["Auto Loader"]
          C --> E["Job Run"]
          D --> F["File Ingestion"]

Managed File Events를 사용하면 같은 External Location의 여러 Auto Loader Stream과 Trigger가 하나의 관리형 Event Infrastructure를 공유할 수 있다. Stream마다 별도의 Cloud Queue를 만들던 Classic Notification Mode보다 운영이 단순하다.

6. Auto Loader의 File Discovery Mode

Directory Listing Mode

Auto Loader의 기본 모드다. Source Directory를 Listing해 신규 파일을 찾는다.

장점

Storage Read 권한만으로 빠르게 시작할 수 있다.
별도의 Notification Infrastructure가 필요 없다.
소규모·저빈도 적재에 단순하다.

단점

Directory와 File이 커지면 Listing 비용과 지연이 증가한다.
Continuous 실행에서는 반복적인 LIST API 호출이 발생할 수 있다.
대규모 고빈도 환경에서는 File Events보다 비효율적이다.

File Notification Mode with Managed File Events

.option("cloudFiles.useManagedFileEvents", "true")

External Location에 File Events를 활성화하고 Auto Loader가 관리형 File Event Cache를 사용하도록 설정한다.

장점

대부분의 실행에서 전체 Directory Listing을 피한다.
대규모 File Arrival에 확장성이 높다.
여러 Stream이 하나의 관리형 Event Infrastructure를 공유한다.
Databricks가 Notification Resource와 Backfill을 관리한다.

주의점

첫 실행에서는 Cache와 위치를 동기화하기 위해 전체 Listing을 수행한다.
Auto Loader를 7일 이상 실행하지 않으면 Cache Read Position이 만료되어 Full Listing이 다시 발생할 수 있다.
File 발견·처리 순서는 보장하지 않는다.
매우 낮은 Latency에서는 Cache Hop이 추가되는 점을 고려해야 한다.

Databricks는 대부분의 운영 환경에서 Directory Listing보다 Managed File Events 기반 File Notification Mode를 권장한다.

7. 가장 권장되는 조합: File Arrival + Auto Loader AvailableNow

파일이 불규칙하게 들어오고 초 단위 Latency가 필요하지 않다면 가장 균형 잡힌 구조다.

동작 순서

File이 Storage에 도착한다.
Managed File Events가 File Metadata를 수집한다.
File Arrival Trigger가 Lakeflow Job을 시작한다.
Auto Loader가 Checkpoint 이후의 모든 미처리 파일을 찾는다.
AvailableNow가 현재 사용 가능한 파일을 여러 Micro-batch로 처리한다.
처리할 파일이 없어지면 Stream과 Compute가 종료된다.

구현 예시

source_path = "/Volumes/raw/erp/orders/"
schema_path = "/Volumes/platform_state/schemas/erp_orders/"
checkpoint_path = "/Volumes/platform_state/checkpoints/erp_orders/"
target_table = "analytics_bronze.erp_orders"

orders = (
    spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "json")
        .option("cloudFiles.schemaLocation", schema_path)
        .option("cloudFiles.schemaEvolutionMode", "addNewColumns")
        .option("cloudFiles.useManagedFileEvents", "true")
        .option("rescuedDataColumn", "_rescued_data")
        .load(source_path)
)

query = (
    orders.writeStream
        .option("checkpointLocation", checkpoint_path)
        .option("mergeSchema", "true")
        .trigger(availableNow=True)
        .toTable(target_table)
)

query.awaitTermination()

장점

File이 없을 때 Job Compute가 실행되지 않는다.
File Arrival Trigger가 중복 실행되어도 Auto Loader Checkpoint가 이미 처리한 파일을 걸러낸다.
한 번에 많은 파일이 들어와도 AvailableNow가 여러 Micro-batch로 나눠 처리할 수 있다.
Job 재시도와 Checkpoint 복구를 함께 사용할 수 있다.
Schema Evolution과 Rescue를 적용할 수 있다.

주의점

Trigger Path와 Auto Loader Source Path를 동일한 업무 범위로 맞춘다.
Checkpoint와 Schema Location을 Source Directory나 Target Table Directory 아래에 두지 않는다.
Job의 동시 실행 수를 일반적으로 1로 제한한다.
Batch 파일이 순차적으로 도착한다면 Wait after last change를 적용한다.
File Arrival 자체가 누락되더라도 다음 Job Run에서 Auto Loader가 Checkpoint 이후 파일을 발견할 수 있도록 설계한다.

8. 상황별 권장 전략

flowchart LR
          A["File 도착 패턴"] --> B{"지속 유입 · 낮은 Latency?"}
          B -->|예| C["Continuous Auto Loader"]
          B -->|아니오| D{"도착 시각 예측 가능?"}
          D -->|예| E["Schedule + AvailableNow"]
          D -->|아니오| F["File Arrival + AvailableNow"]
          F --> G["Cooldown · Debounce"]

전략 A. File Arrival + Auto Loader AvailableNow

적합한 상황

파일 도착 시간이 불규칙하다.
수분 단위 Latency면 충분하다.
파일이 없을 때 Compute 비용을 내고 싶지 않다.
Exactly-once와 장애 복구가 필요하다.

대표 사례

외부 협력사가 비정기적으로 전달하는 판매 파일
SAP·MES에서 업무 완료 후 생성되는 Batch 파일
하루 몇 번 불규칙하게 생성되는 대용량 Export

전략 B. Scheduled Job + Auto Loader AvailableNow

적합한 상황

업무 마감 시각이 명확하다.
파일 도착 Trigger보다 선행 시스템 완료 시간이 중요하다.
여러 Source가 모두 준비된 뒤 함께 처리해야 한다.
일정 수준의 지연이 허용된다.

대표 사례

매일 08시 전일 SAP 마감 파일
매시간 10분에 확정되는 공장 실적 파일
월 마감 후 한 번 처리하는 대규모 Snapshot

File Arrival보다 실행 횟수는 예측하기 쉽지만, 파일이 없어도 Job이 시작될 수 있다. Auto Loader Checkpoint 덕분에 처리할 파일이 없으면 데이터 중복은 발생하지 않지만 Compute Startup 비용은 발생한다.

전략 C. Continuous Auto Loader

적합한 상황

수초·수분 수준의 낮은 Latency가 중요하다.
파일이 지속적으로 들어온다.
항상 실행되는 Compute 비용을 감당할 수 있다.
Stream Monitoring과 Auto Scaling이 준비되어 있다.

대표 사례

근실시간 IoT File Landing
지속적인 Application Log 적재
높은 빈도의 Micro-file Ingestion

Databricks는 Continuous Trigger의 File Check 간격을 일반적으로 1분 이상으로 설정할 것을 권장한다. Sub-minute Latency가 필요하면 File 기반 Landing 자체가 적절한지도 검토해야 한다.

전략 D. Lakeflow Pipeline + Auto Loader

적합한 상황

Bronze부터 Silver까지 선언형 Pipeline으로 관리한다.
Schema와 Checkpoint 운영을 플랫폼에 맡기고 싶다.
Expectations, Lineage, Pipeline Event Log가 필요하다.

Lakeflow Pipeline에서는 Auto Loader의 Schema와 Checkpoint Location을 시스템이 관리할 수 있어 직접 Structured Streaming을 운영하는 부담이 줄어든다.

전략 E. File Arrival만 사용하고 직접 Batch Read

df = spark.read.json("/Volumes/raw/erp/orders/")

이 방식은 매우 제한적으로만 사용해야 한다.

가능한 경우

매번 새로운 고유 Directory에 완결된 Batch가 생성된다.
Manifest나 Batch ID로 처리 범위를 정확히 식별한다.
Target Write가 Idempotent하다.
재시도와 중복 방지 로직을 직접 구현했다.

일반적인 Landing Directory 전체를 Batch Read하면 Job 재시도 때 기존 파일을 다시 읽고 중복 적재할 수 있다. File Arrival Trigger는 어떤 파일을 처리했는지 알려 주는 Ingestion State가 아니므로, 별도 요구가 없다면 Auto Loader를 함께 사용하는 편이 안전하다.

9. 비용 관점 비교

File Arrival Trigger 비용

Databricks는 Trigger 평가 자체에 별도 비용을 부과하지 않으며, File Events를 사용하지 않는 경우 Cloud Provider의 LIST 요청 비용이 발생할 수 있다. 그러나 실제 총비용의 핵심은 Trigger가 시작한 Job Compute다.

File Arrival 총비용
= Storage Event·LIST API 비용
+ Job Startup 비용
+ Task Compute 비용
+ 너무 잦은 Run의 운영 Overhead

파일 하나가 들어올 때마다 작은 Job을 시작하면 Trigger 비용은 낮아도 Compute Startup이 반복되어 비효율적일 수 있다. Minimum time between triggers와 Wait after last change로 여러 File을 하나의 Run으로 묶는다.

Auto Loader 비용

Auto Loader 총비용
= File Discovery 비용
+ Parsing·Transformation Compute
+ Checkpoint·Schema State Storage
+ Delta Write 비용
+ Continuous Compute 또는 Job Startup 비용

Directory Listing Mode에서는 Storage LIST API 비용이 커질 수 있다. Managed File Events를 사용하면 반복 Listing을 줄일 수 있지만, 첫 실행과 Cache Position 만료 시에는 Full Listing이 발생한다.

패턴별 상대 비용

패턴	유휴 Compute	Startup 빈도	File Discovery	적합한 Arrival
5분 Schedule + AvailableNow	없음	고정·높을 수 있음	실행마다 확인	예측 가능
File Arrival + AvailableNow	없음	실제 도착 시	File Events로 최적화	불규칙
Continuous Auto Loader	발생	낮음	지속적	매우 빈번
File Arrival + 직접 Batch Read	없음	실제 도착 시	처리 로직에 따라 반복 Scan	소규모 완결 Batch

비용 최적화 원칙

불규칙한 Arrival에는 File Arrival Trigger를 사용한다.
잦은 Small File은 Debounce와 Cooldown으로 묶는다.
대부분의 운영 환경에서 Managed File Events를 활성화한다.
AvailableNow에서 maxBytesPerTrigger 등으로 Batch 크기를 통제한다.
7일 이상 적재가 없을 수 있는 Stream은 Full Listing 비용을 고려한다.
Source의 Small File 생성 방식을 개선할 수 있으면 상류에서 묶는다.
Trigger Run 수, 평균 처리 File 수, Startup 대비 실제 처리 시간을 함께 본다.

10. Schema 전략

File Arrival Trigger는 Schema를 전혀 알지 못한다. Schema 문제는 Auto Loader 또는 처리 Task에서 해결해야 한다.

권장 원칙

Bronze에서는 원천을 최대한 보존한다.
Schema Location을 영구적인 관리 경로에 둔다.
신규 Column 추가 정책을 명확히 한다.
예상하지 못한 필드는 Rescue Column에 보존한다.
Type 변경은 자동 Cast보다 별도 검증을 거친다.
Silver에서 업무 타입과 필수값을 강제한다.

Schema Evolution Mode

Mode	동작	사용 상황
`addNewColumns`	신규 Column을 Schema에 추가하고 Stream 재시작 필요	일반적인 유연한 Bronze
`rescue`	새로운·불일치 데이터를 Rescue Column에 저장	원천 변동이 잦음
`failOnNewColumns`	신규 Column 발견 시 실패	엄격한 계약
`none`	Schema Evolution을 수행하지 않음	Schema가 완전히 고정됨

기본 addNewColumns에서는 신규 Column을 발견하면 Schema Location을 갱신한 뒤 Stream이 UnknownFieldException으로 중단될 수 있다. Lakeflow Job의 재시도나 자동 재시작으로 새로운 Schema를 적용해 처리를 이어가는 운영 전략이 필요하다.

11. 순서·중복·파일 완결성 전략

File 처리 순서를 신뢰하지 않는다

Auto Loader는 Directory Listing과 File Notification 어느 방식에서도 File 발견·처리 순서를 보장하지 않는다.

File Name 순서를 Event 순서로 사용하지 않는다.
Record의 Event Time과 Sequence를 보존한다.
Silver Upsert 시 Target의 최신 Timestamp와 비교한다.
Late Arrival 허용 Window를 정의한다.

파일은 Immutable하게 관리한다

동일 Path의 파일을 덮어쓰기보다 새로운 고유 파일명으로 생성한다.

권장:
/orders/load_date=2026-08-25/part-000001-<uuid>.json

비권장:
/orders/latest.json

File Arrival Trigger는 같은 이름의 파일 덮어쓰기를 새 Arrival로 인식하지 않는다. Immutable File은 Trigger, Auto Loader Checkpoint, 감사 추적을 단순하게 만든다.

파일 완결성을 보장한다

대용량 File Upload가 끝나기 전에 처리되는 상황을 막기 위해 다음 중 하나를 사용한다.

Temporary Path에 업로드 후 최종 Path로 이동
완료 Manifest File 생성
_SUCCESS Marker 도착 후 처리
Wait after last change로 Batch Landing 종료를 기다림
Producer가 Atomic Write·Rename을 지원하도록 구성

단순히 첫 번째 File이 보였다는 이유만으로 Batch 전체가 완성됐다고 가정하면 안 된다.

12. 장애와 재처리 전략

flowchart LR
          A["Job Run"] --> B["Checkpoint 확인"]
          B --> C{"미처리 파일?"}
          C -->|없음| D["정상 종료"]
          C -->|있음| E["Micro-batch · Delta Commit"]
          E -->|성공| B
          E -->|실패| F["재시도"]
          F --> B

Trigger는 실행 신호, Checkpoint는 처리 진실이다

File Arrival Trigger가 같은 구간에서 여러 번 Job을 실행하거나 한 번 평가에 실패할 수 있다. 데이터 처리의 최종 기준은 Auto Loader Checkpoint여야 한다.

Trigger 중복 실행 → Checkpoint가 처리 File을 걸러냄
Job 중간 실패     → Checkpoint 이후부터 재개
Trigger 지연      → 다음 Run에서 미처리 File을 발견

Checkpoint를 삭제하기 전에 결정할 것

전체 File을 다시 처리할 것인가?
기존 Target을 비울 것인가, Upsert할 것인가?
기존 Checkpoint를 Backup할 것인가?
별도 Backfill Pipeline과 Checkpoint를 만들 것인가?
동일 Source를 두 Pipeline이 중복 처리하지 않는가?

대규모 Backfill은 운영 Stream의 Checkpoint를 초기화하기보다 별도 Path·Checkpoint·Target으로 실행한 뒤 검증하고 병합하는 방식이 안전하다.

`foreachBatch` 주의

foreachBatch 자체는 At-least-once 의미를 가진다. Batch가 재실행될 수 있으므로 batch_id, Business Key, Transaction을 사용해 외부 Sink Write를 Idempotent하게 만들어야 한다.

13. 모니터링해야 할 지표

File Arrival Trigger

Trigger 평가 실패
Arrival부터 Job 시작까지의 지연
Job Run 수
Run당 처리 File 수
Cooldown·Debounce 대기 시간
빈 Run 비율

Auto Loader

처리 File·Byte 수
numFilesOutstanding, numBytesOutstanding
Input Rows와 Processing Rate
Batch Duration
Checkpoint 최신 시각
Schema Evolution·Rescue 발생 건수
Bad Record와 Quarantine 건수
Arrival Time과 Bronze Ingestion Time 차이

File별 처리 상태는 cloud_files_state Table-valued Function으로 확인할 수 있다.

SELECT *
FROM cloud_files_state(
  '/Volumes/platform_state/checkpoints/erp_orders'
);

운영 Dashboard에서는 “Job이 성공했는가”보다 다음 질문에 답해야 한다.

Storage에 도착했지만 아직 처리되지 않은 File이 있는가?
가장 오래 대기 중인 File은 몇 분 전 File인가?
Schema 변경으로 Stream이 중단됐는가?
같은 Business Key가 여러 번 들어왔는가?
한 Run의 Startup 시간보다 실제 처리 시간이 짧은가?

14. 실무 시나리오별 설계

SAP 일 마감 파일

특성

하루 한 번 여러 File이 순차적으로 생성된다.
마지막 File 이후에만 처리해야 한다.
수분 단위 지연이 허용된다.

권장

File Arrival Trigger
  + Wait after last change
  + Auto Loader AvailableNow
  + Bronze Delta

업무 마감 완료 시각이 더 신뢰할 수 있다면 고정 Schedule이나 선행 Job Dependency가 적합할 수 있다.

MES 시간 단위 생산 실적

특성

여러 공장에서 File이 불규칙하게 도착한다.
공장별 File 수가 다르다.
5~15분 이내 적재가 필요하다.

권장

공장·업무별 Volume 또는 명확한 Path 분리
File Arrival Cooldown 5분
Auto Loader AvailableNow
Silver에서 Barcode·Event Time 기반 Upsert

IoT Micro-file

특성

File이 지속적으로 매우 자주 생성된다.
Startup을 반복하면 비효율적이다.
낮은 Latency가 필요하다.

권장

Continuous Auto Loader 또는 Streaming Ingestion을 사용한다. File Arrival Job을 매 File마다 실행하는 구조는 피한다. 가능하다면 Producer에서 File 크기를 키우거나 Kinesis·Kafka와 같은 Event Stream을 검토한다.

비정기 대용량 Backfill

특성

수개월 데이터가 한 번에 들어온다.
운영 Stream과 섞이면 SLA에 영향을 준다.

권장

별도 Backfill Path와 Checkpoint
Auto Loader AvailableNow
maxBytesPerTrigger로 Micro-batch 제어
검증 후 운영 Target과 Merge

이미지·문서 파일 후처리

특성

내용 자체보다 File URL과 Metadata가 중요하다.
OCR·AI 처리와 외부 API 호출이 필요하다.

권장

Auto Loader binaryFile 또는 FILE Reference
File Arrival Trigger로 Job 시작
foreachBatch의 외부 처리를 Idempotent하게 구현
처리 상태 Table에 File Path·Hash·Status 기록

15. 자주 발생하는 안티패턴

안티패턴 1. File Arrival이 파일을 Exactly-once로 전달한다고 생각한다

File Arrival은 Job 실행 조건일 뿐 처리 상태를 관리하지 않는다.

개선: Auto Loader Checkpoint나 별도 Manifest·Control Table을 사용한다.

안티패턴 2. Trigger마다 전체 Directory를 Batch Read한다

기존 파일이 계속 다시 읽혀 중복과 비용이 증가한다.

개선: Auto Loader로 신규 파일만 처리한다.

안티패턴 3. File 하나마다 Job을 시작한다

Compute Startup 비용과 Job Run 수가 폭증한다.

개선: Cooldown과 Debounce로 File을 묶거나 Continuous Auto Loader를 사용한다.

안티패턴 4. Checkpoint를 Temporary Directory처럼 삭제한다

기존 파일이 다시 처리되거나 상태가 손실된다.

개선: Checkpoint를 영구 운영 자산으로 관리하고 재처리 Runbook을 만든다.

안티패턴 5. 파일명 순서로 최신 데이터를 판단한다

Auto Loader는 처리 순서를 보장하지 않는다.

개선: Event Time과 Sequence를 데이터 안에 포함한다.

안티패턴 6. 동일 File Path를 계속 덮어쓴다

File Arrival이 Trigger되지 않을 수 있고 처리 의미가 불명확해진다.

개선: UUID·Batch ID가 포함된 Immutable File Name을 사용한다.

안티패턴 7. Directory Listing을 대규모 Continuous 환경에 그대로 사용한다

LIST API 비용과 Discovery 시간이 커질 수 있다.

개선: External Location에 Managed File Events를 활성화한다.

안티패턴 8. File Exactly-once를 Record Deduplication으로 이해한다

같은 레코드가 서로 다른 파일에 있으면 두 번 적재된다.

개선: Silver에서 Business Key와 Event Time 기준으로 중복 제거한다.

16. 최종 의사결정표

요구사항	권장 방식
파일 도착이 불규칙, 수분 SLA	File Arrival + Auto Loader AvailableNow
정해진 업무 시각에 처리	Schedule + Auto Loader AvailableNow
파일이 지속 유입, 낮은 Latency	Continuous Auto Loader
대규모 기존 파일 Backfill	Auto Loader AvailableNow
완결된 소규모 Batch와 Manifest	File Arrival + Idempotent Batch 가능
Exactly-once Delta 적재	Auto Loader + Checkpoint
Schema Drift 처리	Auto Loader
단순히 후속 Job만 시작	File Arrival Trigger
File Event 인프라 최적화	Managed File Events
Record-level CDC·Upsert	Auto Loader 이후 `AUTO CDC`·MERGE

17. 결론

File Arrival Trigger와 Auto Loader는 서로 대체하는 기능이 아니다.

File Arrival Trigger는 새 파일이 있을 때만 Job을 실행해 Compute 사용을 효율화한다.
Auto Loader는 Checkpoint를 기반으로 미처리 파일을 추적하고 Schema와 장애 복구를 관리한다.
Managed File Events는 Trigger와 Auto Loader 모두의 File Discovery를 효율화한다.
AvailableNow는 현재 도착한 파일을 모두 처리한 뒤 종료해 Event-driven Batch에 적합하다.

가장 일반적인 운영 권장안은 다음 한 문장으로 정리할 수 있다.

File Arrival로 실행 시점을 결정하고, Auto Loader로 처리 상태와 데이터 적재를 보장한다.

파일이 드물고 불규칙하면 File Arrival + Auto Loader AvailableNow, 파일이 지속적으로 들어오고 낮은 Latency가 필요하면 Continuous Auto Loader를 선택한다. 어떤 방식을 사용하더라도 Immutable File, 영구 Checkpoint, Event Time 기반 처리와 Record-level Deduplication을 함께 설계해야 한다.

[Databricks] Genie Agent로 비정형 데이터를 활용하는 방법: Volume부터 RAG·Multi-Agent까지 (1)	2026.08.25
[Databricks] Unity Catalog로 설계하는 전사 데이터 거버넌스: 본부·보안등급·역할·마스킹 정책 (0)	2026.08.25
[Databricks] Silver Layer에서 dbt Incremental과 Materialized View 비교: 장단점과 비용 전략 (0)	2026.08.25
[Databricks] Data Migration에서 Lakehouse Federation을 활용하는 전략 (0)	2026.08.25
[Databricks] Physical Table vs View vs Materialized View: Silver·Gold Layer 설계 전략 (0)	2026.08.25

남는건 기록뿐