> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# SDP 파이프라인 & Job 스케줄

## Part D: SDP 파이프라인으로 자동화

### 수동 CTAS → SDP 전환의 의미

| 항목 | 수동 CTAS | SDP (Lakeflow) |
| - | - | - |
| 실행 | 노트북 수동 Run | 파이프라인 자동 스케줄 |
| 증분 처리 | 전체 재처리 | 자동 증분(Streaming Table) |
| 데이터 품질 | 코드에서 직접 필터 | `expect` 선언적 규칙 |
| 의존성 | 실행 순서 수동 | DAG 자동 해석 |
| 에러 복구 | 수동 재실행 | 자동 재시도 + 격리 |

### SDP 파이프라인 생성 프롬프트

> **팁 — 두 노트북 흐름**
>
> * 아래 **1\~4단계**는 `03_CCM_Transform_<본인ID>` 노트북의 CTAS SQL을 바탕으로 **SDP 전환을 설계**하는 대화입니다(아직 새 노트북 안 만듦).
> * **5단계**에서 그 설계를 파이프라인 전용 **새 노트북 `03_CCM_SDP_<본인ID>`** 에 코드로 생성합니다.
> * (SDP는 파이프라인에 연결되는 별도 소스 노트북이 필요합니다.)

**1단계 —** 전환 뼈대 + 타겟 메타.

```
03_CCM_Transform_<본인ID> 노트북의 Silver/Gold 변환 SQL(CTAS)을 참조해서, Bronze → Silver → Gold 변환 로직을 SDP(Spark Declarative Pipeline)로 전환하려고 해. 파이프라인 이름은 ccm_factory_pipeline, 타겟 카탈로그는 ccm_factory, 타겟 스키마는 silver, gold야. 먼저 전환 구조를 제안해줘.
```

**2단계 —** 계층별 테이블 유형.

```
Bronze → Silver는 Streaming Table로(증분 처리), Silver → Gold는 Materialized View로(자동 리프레시) 구성해줘.
```

**3단계 —** Expectations 추가.

> **Expectations란** — SDP에 선언하는 데이터 품질 규칙입니다. 위반 레코드를 자동으로 감지해 제거(`expect_or_drop`)·중단(`expect_or_fail`)·경고(`expect`)하므로, 품질 필터를 코드로 흩뿌리지 않고 한곳에서 규칙으로 관리합니다.

```
Expectations를 추가해줘:
- aa_measurements: expect_or_drop("valid_mtf", "mtf_center_pct BETWEEN 0 AND 100")
- aa_measurements: expect("valid_tilt", "tilt_abs_max <= 8")
- sensor_metrics_5min: expect_or_drop("valid_temp", "max_temperature_c <= 120")
- production_flow: expect_or_drop("valid_dwell", "dwell_time_sec > 0")
- aoi_defects: expect_or_drop("aoi_rule", "NOT (defect_flag = false AND defect_type IS NOT NULL)")
- final_test_clean: expect("valid_result", "test_result IN ('PASS','FAIL')")
```

**4단계 —** 격리 스키마 + 위반 처리 정책.

```
참조 무결성/규칙 위반 레코드는 ccm_factory.quarantine 스키마로 분리하고, 품질 위반 처리는 Silver는 expect_or_drop(위반 시 제거·격리), Gold는 expect_or_fail(위반 시 파이프라인 중단)로 해줘.
```

**5단계 —** SDP 소스 노트북 생성.

```
위 1~4단계 설계를 담아, 파이프라인 전용 새 노트북 03_CCM_SDP_<본인ID>에 SDP 코드를 생성해줘 (Python + SQL 혼합 가능).
```

### SDP 파이프라인 실행

**1단계 —** 파이프라인 생성.

```
방금 만든 03_CCM_SDP_<본인ID> 노트북으로 ccm_factory_pipeline 이름의 파이프라인을 생성해줘. 서버리스 컴퓨트, Continuous 대신 Triggered 모드로.
```

**2단계 —** 실행 + 결과 확인.

```
파이프라인을 실행하고 각 테이블 row count와 Expectations 통과율을 보여줘.
```

### 실행 결과 확인

```
ccm_factory_pipeline의 최근 실행 결과를 보여줘.
각 테이블 row count, Expectations 통과율, 실패한 테이블이 있으면 에러 메시지를 알려줘.
```

> **참고**: SDP는 Databricks UI의 **Pipelines** 메뉴에서 DAG로 테이블 의존성과 품질 상태를 시각적으로 확인할 수 있습니다.

### SDP 파이프라인 설정 · 옵션 조정

파이프라인은 "한 번 만들고 끝"이 아닙니다. 실행 방식(interval)·컴퓨트·모드 같은 **설정을 바꿔 가며** 운영에 맞춥니다. 하나씩 조정해 봅니다.

**1단계 —** 먼저 현재 설정을 확인.

```
ccm_factory_pipeline의 현재 설정(트리거 모드, 컴퓨트, 채널, 타깃 스키마)을 보여줘.
```

**2단계 —** 실행 방식(interval) 변경 — Triggered vs Continuous.

```
이 파이프라인을 Continuous(연속) 모드로 바꾸면 어떤 차이가 있는지 설명해주고,
실습에서는 다시 Triggered로 두되 Continuous로 바꾸는 설정 위치를 알려줘.
```

**3단계 —** 컴퓨트 옵션 조정.

```
파이프라인 컴퓨트를 조정하고 싶어. 서버리스가 기본인데, 클래식 컴퓨트로 바꿀 때의
워커 오토스케일(min/max) 설정과 Photon 사용 여부를 어디서 바꾸는지 알려줘.
서버리스에서는 어떤 옵션이 자동으로 처리되는지도 정리해줘.
```

**4단계 —** 개발/운영 모드 & 채널.

```
Development 모드와 Production 모드의 차이(클러스터 재사용·재시도)를 설명해주고,
지금은 Development로 두자. 릴리스 채널(Current/Preview)도 확인해줘.
```

**5단계 —** 파이프라인 알림 & 전체 새로고침.

```
파이프라인 실행 실패 시 이메일 알림을 추가해줘.
그리고 스키마를 바꿨을 때 쓰는 "전체 새로고침(full refresh)"과 증분 실행의 차이도 알려줘.
```

> 💡 **왜 이걸 배우나**: 초기엔 Triggered + 서버리스가 편하지만, 실시간성이 필요하면 Continuous, 비용/성능을 세밀히 잡아야 하면 클래식 컴퓨트로 갑니다. 모드·채널·알림은 운영 안정성과 직결됩니다.

### 기대 결과: Expectations 통과율 (예시 · 환경별 상이)

> ⚠️ 아래 통과율·위반 건수는 **예시 수치**입니다. 데이터 생성 시드·적재 범위·환경에 따라 달라지므로 절대값이 아니라 "대부분 통과, 소수 격리"라는 경향으로 읽으세요.

| 테이블 | Expectation | 통과율 | 위반 |
| - | - | - | - |
| aa\_measurements | valid\_mtf | \~99.7% | \~750 |
| sensor\_metrics\_5min | valid\_temp | \~99.8% | \~600 |
| production\_flow | valid\_dwell | \~99.5% | \~2,000 |
| aoi\_defects | aoi\_rule | \~99.5% | \~1,500 |

***

## Part E: 파이프라인 Job 스케줄링

> **Job이란** — 노트북·파이프라인을 정해진 스케줄에 자동 실행하는 Databricks의 오케스트레이션 기능입니다. SDP 파이프라인을 매일 새벽 무인으로 리프레시해, 아침에 대시보드·Genie가 항상 최신 데이터를 보게 만드는 것이 목표입니다.

**1단계 —** Job 뼈대.

```
ccm_factory_pipeline을 매일 자동 실행하는 Job을 만들려고 해. Job 이름은 ccm_factory_daily_refresh, 클러스터는 서버리스야.
```

**2단계 —** 스케줄 추가.

```
스케줄은 매일 오전 6시 KST(cron: 0 21 * * * UTC)로 설정해줘.
```

**3단계 —** 재시도·알림·타임아웃 추가.

```
재시도는 최대 2회·간격 10분, 실패 시 이메일 알림, 타임아웃은 2시간으로 추가해줘.
```

**4단계 —** 컴퓨트 옵션 조정.

```
이 Job의 컴퓨트를 서버리스로 두되, 클래식 Job 클러스터로 바꿀 경우의
노드 타입·워커 수·오토스케일 설정을 어디서 지정하는지 알려줘. 서버리스와의 비용/기동시간 차이도 짧게.
```

**5단계 —** 트리거 방식(interval) 옵션.

```
스케줄(cron) 외에 이 Job을 트리거하는 다른 방법(연속 실행, 파일 도착 트리거, 수동 트리거)을
설명해주고, 각각 어떤 상황에 쓰는지 알려줘. 지금은 매일 6시 cron 유지.
```

```
방금 만든 ccm_factory_daily_refresh Job의 설정과 다음 실행 예정 시각을 확인해줘.
지금 한 번 수동 실행(trigger)해서 정상 동작하는지도 확인해줘.
```

***

## 핵심 포인트 정리

| 배운 것 | Databricks 기능 | 비즈니스 가치 |
| - | - | - |
| 데이터 품질 진단·처리 | SQL, Window 함수 | Raw 로그의 신뢰성 확보 |
| 참조 무결성·격리 | Quarantine 스키마 | 오염 데이터가 분석을 왜곡하지 않음 |
| 선언적 파이프라인 | SDP (Lakeflow) | 증분 처리·운영 부담 최소화 |
| 품질 규칙 자동화 | Expectations | 위반 자동 감지·격리·중단 |
| 수율/FPY/OEE/Cpk 집계 | Materialized View | 대시보드·Genie·ML이 바로 소비 |
| 일일 자동 리프레시 | Databricks Jobs | 무인 운영 |

***

## 다음 단계

* **[04. AI/BI 대시보드](04-aibi-dashboard)** — Gold 테이블로 수율·불량·설비 운영 대시보드를 자연어로 생성합니다.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.