Delta Lake 장단점과 운영 가이드 정리

Azure 환경에서 SAP, MSSQL 같은 원천 데이터를 적재하고 모델링해서 분석계를 구축할 때, Delta Lake는 데이터 레이크의 유연성과 데이터 웨어하우스의 안정성을 함께 잡는 핵심 레이어입니다.

 

이 글에서는 델타레이크의 장단점, 파일 구조, 사용 사례, 특이점, 그리고 실사용 코드까지 알기 쉽게 정리했습니다.

 

Delta Lake 장단점과 운영 가이드 정리

반응형

---

Delta Lake란 무엇인가?

Delta Lake는 Apache Spark 기반의 빅데이터 워크로드에 ACID 트랜잭션을 제공하는 오픈 소스 저장 계층입니다.

• 데이터 자체는 Parquet 파일로 저장
• 트랜잭션 기록은 _delta_log 폴더에 JSON 파일 + 체크포인트 파일로 기록
• UPDATE, DELETE, MERGE 같은 변경 작업과 버전 관리가 가능

왜 Delta Lake가 필요한가?

기존 데이터 레이크는 단순 파일 저장만 가능해서 다음과 같은 문제가 있었습니다.

문제점	기존 데이터 레이크	Delta Lake
ACID 트랜잭션	지원하지 않음	지원
UPDATE/DELETE	불가능	가능
롤백/감사	어려움	Time Travel
스키마 제어	약함	Schema Enforcement
배치+스트리밍	분리 필요	통합 지원

---

Delta Lake 파일 구조 (핵심)

Delta Lake의 핵심은 데이터 파일과 로그 파일을 분리해서 관리한다는 점입니다.

delta_table/
├── data/                    # 실제 데이터 (Parquet)
│   ├── part-00000-abc.snappy.parquet
│   ├── part-00001-def.snappy.parquet
│   └── ...
└── _delta_log/              # 트랜잭션 로그
    ├── 00000000000000000000.json    # 버전 0 로그
    ├── 00000000000000000001.json    # 버전 1 로그
    ├── 00000000000000000010.checkpoint.parquet  # 체크포인트
    └── ...

로그 파일에 기록되는 주요 내용

{
  "add": {
    "path": "part-00000-abc.snappy.parquet",
    "size": 12345,
    "modificationTime": 1700000000000,
    "dataChange": true,
    "partitionValues": {}
  },
  "commitInfo": {
    "operation": "WRITE",
    "operationParameters": {"mode": "Append"},
    "timestamp": 1700000000500
  }
}

• add: 새 Parquet 파일이 테이블에 포함됨
• remove: 파일이 논리적으로 제거됨 (물리 삭제는 안 됨)
• 체크포인트: 여러 JSON 로그를 묶어 읽기 성능 개선

---

Delta Lake 장단점 정리

✅ 장점 5가지

장점	설명
ACID 트랜잭션	동시 작업에서도 데이터 무결성 보장
Time Travel	이전 버전 즉시 조회, 감사/롤백/재현 분석 용이
스키마 제어	컬럼 추가/변형 규칙적으로 관리
배치+스트리밍 통합	하나의 테이블로 배치/실시간 처리 모두
Spark 호환성	기존 파이프라인 전환 없이 점진 도입

⚠️ 단점 3가지

단점	설명
운영 복잡도 상향	로그, 체크포인트, 보존 정책까지 관리 필요
학습 곡선	OPTIMIZE, VACUUM, schema evolution 등 개념 학습 필요
거버넌스 필요	단순 파일 저장보다 설계 역량 더 요구

---

실무에서 중요한 5가지 운영 포인트

1. 작은 파일 문제 해결 (OPTIMIZE)

-- 작은 파일 병합
OPTIMIZE delta_table_name;

-- 파티션별 병합
OPTIMIZE delta_table_name WHERE date = '2025-01-01';

2. Z-Order로 필터 성능 개선

-- Z-Order 정렬 (multi-column 필터 가속)
OPTIMIZE delta_table_name ZORDER BY (customer_id, transaction_date);

3. 오래된 버전 정리 (VACUUM)

-- 7일 이전 버전 제거 (기본 7일 보존)
VACUUM delta_table_name RETAIN 168 HOURS;

-- DRY RUN: 삭제 전 확인
VACUUM delta_table_name DRY RUN;

4. Time Travel로 이전 버전 조회

-- 버전 번호로 조회
SELECT * FROM delta_table_name VERSION AS OF 5;

-- 타임스탬프로 조회
SELECT * FROM delta_table_name TIMESTAMP AS OF '2025-01-15 10:00:00';

5. 스키마 진화 (Schema Evolution)

-- 새 컬럼 자동 추가 (schema evolution 활성화)
INSERT INTO delta_table_name (customer_id, new_column)
SELECT customer_id, 'value' FROM source_table;

-- 또는 스키마 강제 업데이트
ALTER TABLE delta_table_name ADD COLUMNS (new_column STRING);

---

사용 사례: 메달리온 아키텍처 패턴

Azure Databricks와 Synapse 환경에서 메달리온 구조와 함께 쓰면 가장 강점이 큽니다.

브론즈 (Bronze) ──> 실버 (Silver) ──> 골드 (Gold)
   ↓                    ↓                    ↓
원천 적재           정제/표준화        BI/ML 소비
(SAP, MSSQL)        (Dedup, Clean)    (Power BI)

브론즈 레이어: 원천 데이터 적재

CREATE TABLE bronze.sales_order (
  order_id BIGINT,
  customer_id BIGINT,
  order_date DATE,
  amount DECIMAL(18,2)
) USING DELTA;

-- 스트리밍 적재
INSERT INTO bronze.sales_order
SELECT * FROM source.sap_sales_order;

실버 레이어: 정제 및 표준화

CREATE TABLE silver.sales_order (
  order_id BIGINT,
  customer_id BIGINT,
  order_date DATE,
  amount DECIMAL(18,2),
  processed_at TIMESTAMP
) USING DELTA;

-- 중복 제거 + 표준화
INSERT INTO silver.sales_order
SELECT 
  order_id,
  customer_id,
  order_date,
  amount,
  CURRENT_TIMESTAMP() AS processed_at
FROM bronze.sales_order
QUALIFY ROW_NUMBER() OVER (PARTITION BY order_id ORDER BY order_date DESC) = 1;

골드 레이어: BI 소비용

CREATE TABLE gold.sales_order_summary (
  customer_id BIGINT,
  total_amount DECIMAL(18,2),
  order_count INT,
  last_order_date DATE
) USING DELTA;

-- 집계
INSERT INTO gold.sales_order_summary
SELECT 
  customer_id,
  SUM(amount) AS total_amount,
  COUNT(*) AS order_count,
  MAX(order_date) AS last_order_date
FROM silver.sales_order
GROUP BY customer_id;

---

Delta Lake vs Parquet 비교

비교 항목	Parquet	Delta Lake
저장 포맷	Parquet	Parquet + _delta_log
ACID	지원하지 않음	지원
UPDATE/DELETE	불가능	가능
타임 트래블	불가능	지원
스키마 제어	기본	강화
스트리밍 지원	제한적	완전 지원
오버헤드	낮음	중간 (로그 관리)

 

Parquet는 효율적이고 압축률이 좋지만, Delta Lake는 트랜잭션과 버전 관리 기능이 추가된 형태입니다.

---

실무 판단 기준: Delta Lake가 적합한 상황

✅ Delta Lake를 쓰는 경우

• 데이터가 자주 변하고 이력 관리가 필요할 때
• 배치 + 스트리밍이 섞여 있을 때
• 여러 팀이 같은 데이터를 공유할 때
• 감사/롤백이 중요한 금융, 공공, 제조, 유통 분석계일 때
• Azure Databricks/Synapse 레이크하우스 환경일 때

❌ Delta Lake가 과한 경우

• 단순 조회만 하는 정적 데이터일 때
• 파일 수명 관리가 거의 필요 없는 아주 단순 저장소일 때
• 학습 비용 대비 이득이 작을 때

---

Delta Lake가 왜 핵심인가

Delta Lake는 "파일 기반 데이터 레이크의 유연함"과 "웨어하우스 수준의 신뢰성" 사이를 메우는 기술입니다.

• Azure 환경에서 SAP, MSSQL, 로그, IoT 데이터를 브론즈 → 실버 → 골드로 흐르게 만들 때 핵심 레이어
• Power BI 보고서 소비까지 연결하는 데이터 엔지니어링 + BI 흐름에서 강력
• Time Travel, ACID, 스키마 제어 덕분에 운영 대응과 감사 추적 모두 편해짐

데이터 엔지니어링과 BI를 같이 보는 환경에서는 원천 적재부터 보고서 소비까지 연결하는 핵심 레이어로 쓰기 좋습니다.