> ## 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.

# 데이터 아키텍처: 레이크하우스와 모던 데이터 스택

> 이 문서는 **[선행 지식](/training/00-prerequisites/overview)** 섹션의 일부입니다.

## 데이터 레이크 vs 데이터 웨어하우스

### 데이터 웨어하우스 (Data Warehouse)

데이터 웨어하우스는 분석을 위해 여러 소스의 정형 데이터를 통합 저장하는 시스템입니다. 1990년대부터 기업 분석(Business Intelligence)의 핵심이었습니다.

| 특성         | 내용                                              |
| ---------- | ----------------------------------------------- |
| **스키마**    | Schema-on-Write: 데이터를 저장하기 전에 스키마를 정의           |
| **데이터 형태** | 정형 데이터 (SQL 테이블)                                |
| **처리 방식**  | OLAP (Online Analytical Processing)             |
| **저장 비용**  | 높음 (전용 스토리지 + 컴퓨팅)                              |
| **성능**     | SQL 분석에 최적화, 매우 빠름                              |
| **유연성**    | 낮음 (스키마 변경 어려움)                                 |
| **대표 솔루션** | Teradata, Oracle, Snowflake, BigQuery, Redshift |

**장점**: 높은 쿼리 성능, 강력한 거버넌스, ACID 트랜잭션, BI 도구와 완벽한 통합
**단점**: 비구조화 데이터 처리 불가, 높은 비용, 스키마 변경의 어려움

### 데이터 레이크 (Data Lake)

데이터 레이크는 정형, 반정형, 비정형 데이터를 원본 형태 그대로 저장하는 중앙 저장소입니다. 2010년대 Hadoop의 등장과 함께 대중화되었으며, 이후 클라우드 오브젝트 스토리지(S3, ADLS, GCS)가 그 역할을 대신하게 되었습니다.

| 특성         | 내용                                            |
| ---------- | --------------------------------------------- |
| **스키마**    | Schema-on-Read: 데이터를 읽을 때 스키마를 적용             |
| **데이터 형태** | 정형 + 반정형 + 비정형 모두 가능                          |
| **저장 포맷**  | CSV, JSON, Parquet, Avro, 이미지, 동영상 등          |
| **저장 비용**  | 낮음 (오브젝트 스토리지는 매우 저렴)                         |
| **성능**     | 정형 데이터 쿼리는 웨어하우스보다 느릴 수 있음                    |
| **유연성**    | 높음 (어떤 데이터든 원본 그대로 저장)                        |
| **대표 솔루션** | AWS S3, Azure ADLS, Google GCS + Hadoop/Spark |

**장점**: 유연성, 낮은 저장 비용, ML을 위한 비정형 데이터 지원, 오픈 포맷
**단점**: 데이터 품질 보장 어려움, ACID 없음, "데이터 늪(Data Swamp)" 위험

> 💡 **데이터 늪(Data Swamp)이란?** 레이크에 데이터를 마구 쌓기만 하고 거버넌스와 카탈로그가 부재하면, 어떤 데이터가 어디에 있는지, 신뢰할 수 있는 데이터인지 알 수 없게 됩니다. 많은 기업이 데이터 레이크 구축 후 "데이터는 많은데 쓸 수 있는 데이터는 없다"는 상황에 빠지는 원인입니다.

### 왜 레이크하우스 (Lakehouse)가 등장했는가

데이터 레이크와 데이터 웨어하우스는 각각 상충되는 장단점을 갖고 있습니다. 기업들은 두 가지를 모두 운영하는 경우가 많았는데, 이는 비용 중복, 데이터 복제, 동기화 지연 등의 문제를 야기했습니다.

```
기존 아키텍처의 고려사항:

[소스 시스템] → [데이터 레이크 (S3)] → [ETL] → [데이터 웨어하우스 (Redshift)]
                      ↓ ML팀                              ↓ SQL 분석팀
                  (비정형 데이터)                       (정형 데이터)

문제: 같은 데이터가 레이크와 웨어하우스에 이중으로 존재
     → 비용 2배, 동기화 지연, 데이터 불일치 위험
```

**레이크하우스** 는 데이터 레이크의 저비용·유연성과 데이터 웨어하우스의 ACID 트랜잭션·성능·거버넌스를 단일 플랫폼에서 제공하는 개념입니다. Databricks가 2020년 논문과 함께 공식화했으며, Delta Lake가 핵심 기술입니다.

| 특성        | 데이터 웨어하우스 | 데이터 레이크 | 레이크하우스          |
| --------- | --------- | ------- | --------------- |
| 저장 비용     | 높음        | 낮음      | 낮음              |
| ACID 트랜잭션 | 있음        | 없음      | 있음              |
| 스키마 강제    | 있음        | 없음      | 있음 (선택적)        |
| 비정형 데이터   | 불가        | 가능      | 가능              |
| BI/SQL 성능 | 매우 빠름     | 느림      | 빠름 (Photon/최적화) |
| ML/AI 지원  | 제한적       | 가능      | 가능              |
| 데이터 복제    | 필요        | 원본 저장   | 원본 저장           |

참고: [Databricks: What is a Data Lakehouse?](https://www.databricks.com/glossary/data-lakehouse) | [논문: Lakehouse: A New Generation of Open Platforms](https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf)

***

## 테이블 포맷 전쟁 — Delta Lake vs Iceberg vs Hudi

### 왜 오픈 테이블 포맷이 필요한가

클라우드 오브젝트 스토리지(S3 등)에 데이터를 저장하면 비용이 낮지만, 기본적으로는 단순한 파일 저장소에 불과합니다. Parquet 파일을 S3에 저장하면:

* **ACID 없음**: 두 작업이 동시에 파일을 수정하면 데이터 손상 가능
* **업데이트/삭제 불가**: Parquet은 불변(Immutable) 파일 포맷
* **스키마 변경 어려움**: 컬럼 추가/변경이 복잡
* **타임 트래블 없음**: 과거 데이터 조회 불가

오픈 테이블 포맷은 이런 문제를 해결하기 위해, Parquet 파일 위에 **메타데이터 레이어** 를 추가합니다. 실제 데이터는 Parquet으로 저장하되, 변경 이력, 스키마, 트랜잭션 로그를 별도로 관리합니다.

### 세 포맷 비교

| 특성            | Delta Lake                    | Apache Iceberg                         | Apache Hudi                   |
| ------------- | ----------------------------- | -------------------------------------- | ----------------------------- |
| **개발사**       | Databricks (2019년 오픈소스화)      | Netflix → Apache (2020년)               | Uber → Apache (2020년)         |
| **ACID 트랜잭션** | 있음                            | 있음                                     | 있음                            |
| **스키마 진화**    | 있음                            | 있음 (더 유연함)                             | 있음                            |
| **타임 트래블**    | 있음                            | 있음                                     | 있음                            |
| **파티션 진화**    | 제한적                           | 매우 유연함                                 | 있음                            |
| **엔진 지원**     | Spark 중심, 타 엔진 점진적 지원         | 광범위 (Spark, Flink, Trino, Snowflake 등) | Spark, Flink 중심               |
| **강점**        | Spark 생태계, 성숙도, Databricks 통합 | 엔진 독립성, 파티션 유연성                        | 증분 처리(Incremental Processing) |
| **채택 현황**     | Databricks, Microsoft Fabric  | Snowflake, AWS, Google 지원              | Uber, 증분 처리 워크로드              |

**Delta Lake의 핵심 기능**

```
Delta Lake 디렉토리 구조:
/my-table/
  _delta_log/        ← 트랜잭션 로그 (JSON/Parquet)
    00000.json       ← 1번째 트랜잭션
    00001.json       ← 2번째 트랜잭션
    ...
  part-0000.parquet  ← 실제 데이터
  part-0001.parquet
  ...
```

* **Transaction Log**: 모든 변경 사항을 JSON으로 기록하여 ACID 보장
* **Time Travel**: `VERSION AS OF n` 또는 `TIMESTAMP AS OF 'date'` 구문으로 과거 스냅샷 조회
* **MERGE INTO**: Upsert (Insert + Update) 연산을 단일 명령으로 처리
* **Z-Ordering**: 자주 필터링하는 컬럼 기준으로 데이터를 클러스터링하여 쿼리 성능 향상
* **Auto Optimize / VACUUM**: 소규모 파일 자동 병합, 오래된 파일 정리

**Iceberg의 차별점**

Iceberg는 Netflix가 수만 개의 테이블, PB급 데이터를 관리하면서 필요한 기능을 설계했습니다.

* **Hidden Partitioning**: 파티션 컬럼을 쿼리에 명시하지 않아도 자동으로 최적화
* **Partition Evolution**: 테이블 재작성 없이 파티션 전략 변경 가능
* **엔진 독립**: Spark, Flink, Trino, Hive, Snowflake 등 다양한 엔진이 동일한 Iceberg 테이블을 읽고 쓸 수 있음

### UniForm — 테이블 포맷의 수렴

포맷 전쟁의 최종 결론은 "공존"입니다. Databricks는 **UniForm (Universal Format)** 을 통해 Delta Lake 테이블을 Iceberg 또는 Hudi 형식으로도 읽을 수 있게 지원합니다.

```sql theme={null}
-- UniForm 활성화: Snowflake, Trino 등이 Delta 테이블을 Iceberg로 읽을 수 있음
CREATE TABLE my_table (id INT, name STRING)
TBLPROPERTIES ('delta.universalFormat.enabledFormats' = 'iceberg');
```

이는 플랫폼 의존(Vendor Lock-in) 우려를 줄이고, 멀티 엔진 환경에서 동일한 데이터를 공유할 수 있게 합니다.

참고: [Delta Lake 공식 문서](https://docs.delta.io/latest/index.html) | [Apache Iceberg 공식 문서](https://iceberg.apache.org/docs/latest/) | [Databricks: UniForm](https://docs.databricks.com/en/delta/uniform.html)

***

## 모던 데이터 스택 (Modern Data Stack)

### 개요

**모던 데이터 스택** 은 2010년대 후반 클라우드 네이티브 환경에서 부상한 데이터 파이프라인 아키텍처입니다. 핵심 원칙은 **전문화** 입니다. 하나의 대형 플랫폼 대신, 각 단계에서 최적의 도구를 조합(Best-of-Breed)합니다.

```
모던 데이터 스택의 전형적인 구성:

[소스] → [수집: Fivetran/Airbyte] → [저장: Snowflake/BigQuery/Databricks]
                                              ↓
                               [변환: dbt] → [데이터 마트]
                                              ↓
                              [BI: Tableau/Looker/Power BI]
```

### ELT vs ETL

전통적인 데이터 파이프라인은 **ETL (Extract → Transform → Load)** 방식이었습니다. 소스에서 데이터를 추출하고, 별도의 변환 서버에서 처리한 뒤, 웨어하우스에 저장했습니다.

모던 데이터 스택에서는 **ELT (Extract → Load → Transform)** 가 표준입니다. 클라우드 웨어하우스의 처리 능력이 강력해지면서, 원본 데이터를 먼저 적재하고 웨어하우스 내부에서 SQL로 변환하는 방식이 더 효율적입니다.

| 비교        | ETL                       | ELT                                 |
| --------- | ------------------------- | ----------------------------------- |
| **변환 시점** | 적재 전                      | 적재 후                                |
| **변환 위치** | 별도 서버                     | 웨어하우스 내부                            |
| **도구**    | SSIS, Informatica, Talend | dbt + Snowflake/BigQuery/Databricks |
| **유연성**   | 낮음 (스키마 변경 어려움)           | 높음 (원본 항상 보존)                       |
| **비용**    | 변환 서버 별도                  | 웨어하우스 컴퓨팅 비용                        |

### dbt (data build tool)

**dbt** 는 ELT의 T(Transform) 단계를 담당하는 오픈소스 SQL 변환 프레임워크입니다. 2016년 Fishtown Analytics(현 dbt Labs)에서 만들었습니다.

**핵심 개념**:

* SQL SELECT 문으로 데이터 변환 모델을 정의
* 모델 간 의존성을 자동으로 해결하여 올바른 순서로 실행
* 데이터 테스트(Not Null, Unique, Referential Integrity 등) 내장
* 문서화 자동 생성, 데이터 리니지(Lineage) 시각화

```sql theme={null}
-- dbt 모델 예시: models/marts/orders_summary.sql
{{ config(materialized='table') }}

WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}   -- 다른 dbt 모델 참조
),
customers AS (
    SELECT * FROM {{ ref('stg_customers') }}
)

SELECT
    o.order_id,
    c.customer_name,
    o.amount,
    o.created_at
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.status = 'completed'
```

> 💡 **왜 dbt가 급성장했나?** 기존에 데이터 변환은 Python이나 Spark를 잘 아는 엔지니어가 담당했습니다. dbt는 SQL을 아는 분석가도 직접 데이터 파이프라인을 관리할 수 있게 했고, Git 기반 버전 관리, 테스트, 문서화를 하나의 도구로 제공했습니다. **"분석가의 소프트웨어 엔지니어링"** 이라는 개념이 대중화된 것입니다.

참고: [dbt 공식 문서](https://docs.getdbt.com/) | [dbt + Databricks 통합 가이드](https://docs.databricks.com/en/partners/prep/dbt.html)

### Fivetran / Airbyte — 관리형 수집 도구

**Fivetran** 은 "EL(Extract-Load) as a Service"입니다. 400개 이상의 소스 커넥터를 제공하며, 스키마 변경 자동 감지, CDC(Change Data Capture), 데이터 정규화를 자동으로 처리합니다.

**Airbyte** 는 Fivetran의 오픈소스 대안입니다. 자체 호스팅이 가능하며, 커스텀 커넥터 개발도 지원합니다.

| 비교        | Fivetran   | Airbyte    | Lakeflow Connect |
| --------- | ---------- | ---------- | ---------------- |
| **유형**    | SaaS       | 오픈소스       | Databricks 관리형   |
| **커넥터 수** | 400+       | 300+       | 주요 소스 집중         |
| **설치/운영** | 불필요        | 자체 관리      | 불필요              |
| **비용**    | 행(row) 기준  | 오픈소스 무료    | Databricks에 포함   |
| **최적 용도** | SaaS 소스 수집 | 비용 절감, 커스텀 | Databricks 통합 환경 |

### 오케스트레이션 — Apache Airflow

**Apache Airflow** 는 Airbnb에서 2014년 개발한 오픈소스 워크플로우 오케스트레이션 도구입니다. 데이터 파이프라인을 **DAG (Directed Acyclic Graph)** 으로 정의하고, 스케줄링, 의존성 관리, 재시도, 알림을 처리합니다.

```python theme={null}
# Airflow DAG 예시
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime

with DAG('daily_etl', start_date=datetime(2024, 1, 1), schedule_interval='@daily') as dag:
    extract = PythonOperator(task_id='extract', python_callable=extract_data)
    transform = PythonOperator(task_id='transform', python_callable=transform_data)
    load = PythonOperator(task_id='load', python_callable=load_data)

    extract >> transform >> load  # 의존성 정의
```

현재는 **Prefect**, **Dagster** 같은 더 현대적인 대안도 많습니다. Databricks 환경에서는 **Lakeflow Jobs** 가 Airflow를 대체하거나 함께 사용됩니다.

***