김신건의 로그 - 위키 / data-engineering

Apache Parquet

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Apache Parquet 은 분석 쿼리에 최적화된 오픈소스 컬럼형 이진 파일 포맷. 2013년 Twitter + Cloudera 가 Google Dremel 논문 (2010) 을 참고해 발표. 현재 [[data-warehouse|데이터 웨어하우스]] / data lake 의 사실상 표준 저장 포맷.

같은 데이터를 CSV/JSON 대비 10-100배 작게, 분석 쿼리를 10-100배 빠르게 실행.

왜 컬럼형인가

Row-based (CSV, JSON, Avro):
  Row 1: [id=1, name="A", age=30, ..., col50]
  Row 2: [id=2, name="B", age=25, ..., col50]

  SELECT AVG(age) → 모든 컬럼을 읽고 age 만 뽑음.

Column-based (Parquet, ORC):
  id:   [1, 2, 3, ...]
  name: [A, B, C, ...]
  age:  [30, 25, 40, ...]  ← 이 컬럼만 스캔
  ...

  SELECT AVG(age) → age 컬럼만 I/O. 나머지 스킵.

컬럼형의 세 가지 이점:

I/O 절감 - 필요한 컬럼만 읽음 (컬럼 프로젝션)
압축률 - 같은 타입/유사값이 연속 -> 사전, RLE, delta 압축이 잘 먹힘 (5-10배)
CPU 효율 - 같은 타입이 연속 -> SIMD 벡터 명령, late materialization

파일 구조

flowchart TB
    File["Parquet File"]
    Header["Magic 'PAR1'"]
    RG1["Row Group 1<br/>(128 MB - 1 GB)"]
    RG2["Row Group 2"]
    RGN["Row Group N"]
    Footer["Footer<br/>(schema + metadata + statistics)"]
    Trailer["Magic 'PAR1'"]

    File --> Header
    File --> RG1
    File --> RG2
    File --> RGN
    File --> Footer
    File --> Trailer

    RG1 --> CC1["Column Chunk 1<br/>(컬럼 A 데이터)"]
    RG1 --> CC2["Column Chunk 2<br/>(컬럼 B 데이터)"]
    RG1 --> CCN["Column Chunk N"]

    CC1 --> Page1["Data Page 1<br/>(1-10 MB)"]
    CC1 --> Page2["Data Page 2"]
    CC1 --> Dict["Dictionary Page (optional)"]

계층	크기 (권장)	역할
File	임의	하나의 물리 파일 (`.parquet`)
Row Group	128 MB - 1 GB	수평 파티션, 병렬 read/write 단위
Column Chunk	Row group / N	한 컬럼의 데이터가 연속으로
Data Page	1 - 10 MB	압축/인코딩 단위
Dictionary Page	Column chunk 당 1개 (선택)	값 -> 정수 매핑
Footer	파일 끝	schema + row group 위치 + 통계

Footer 가 파일 끝에 있는 이유: streaming write 를 지원하려면 파일을 다 쓴 뒤에야 전체 통계/위치를 알 수 있음. 대신 read 시 seek 두 번 (끝으로 -> footer 읽기 -> 필요한 row group 위치로).

인코딩 (Encoding)

압축 전 값을 정수/오프셋으로 표현하는 단계. 컬럼 특성에 따라 자동 선택.

Encoding	적용 타입	최적 케이스	압축비
PLAIN	모든 타입	fallback, 무압축	1x
RLE_DICTIONARY	모든 타입 (일반적)	낮은 카디널리티 (성별, 국가)	10-100x
DELTA_BINARY_PACKED	INT32/INT64	정렬/순차 정수 (id, timestamp)	5-20x
DELTA_LENGTH_BYTE_ARRAY	BYTE_ARRAY	문자열 길이 varying	3-10x
DELTA_BYTE_ARRAY	BYTE_ARRAY	정렬된 문자열	5-15x
BYTE_STREAM_SPLIT	FLOAT/DOUBLE	부동소수점 (뒤 codec 과 조합 개선)	압축 개선

Dictionary encoding 이 기본. 카디널리티가 임계값을 넘으면 PLAIN 으로 fallback.

압축 (Compression Codec)

인코딩된 페이지를 물리적으로 압축. 인코딩 위에 codec 을 한 번 더 적용.

Codec	압축비	압축 속도	해제 속도	권장
SNAPPY	2-4x	매우 빠름	매우 빠름	옛 기본값, 균형형
ZSTD	3-6x	빠름	빠름	현대 기본값 권장
GZIP	4-8x	느림	느림	최대 압축 필요 시
LZ4	2-3x	최고	최고	실시간 스트리밍
BROTLI	5-10x	매우 느림	중간	아카이빙 (드묾)
LZO	2-4x	빠름	빠름	Legacy (사실상 대체됨)
UNCOMPRESSED	1x	-	-	디버깅만

[!IMPORTANT] ZSTD 가 현대 기본값. SNAPPY 보다 압축비가 좋고 GZIP 보다 빠름. 새 파일은 ZSTD 로 시작.

통계 (Statistics) & Predicate Pushdown

각 row group / column chunk / page 는 min, max, null_count 통계를 저장. Reader 는 이 통계만 보고 데이터를 읽지 않고 스킵 가능.

Query: SELECT * FROM t WHERE order_date >= '2026-01-01'

Row Group 1: min=2025-01-01, max=2025-12-31  →  skip (max < filter)
Row Group 2: min=2026-01-01, max=2026-06-30  →  read
Row Group 3: min=2026-07-01, max=2026-12-31  →  read

Bloom Filter (선택): 컬럼 값의 hash 집합. WHERE user_id = 12345 처럼 등호 조건에서 row group 을 확률적으로 스킵. 크기 ~1-2% 오버헤드.

Page Index (Parquet 2.5+): row group 안의 페이지 수준 min/max 를 별도로 저장. 페이지 단위 스킵.

스키마 진화 (Schema Evolution)

Parquet 은 다음을 지원:

컬럼 추가: 새 컬럼 (기본값 or NULL)
컬럼 제거: reader 무시
컬럼 이름 변경: 메타 수정
타입 승격: INT32 -> INT64, FLOAT -> DOUBLE
중첩 구조 변경: struct 필드 추가

주의: 타입 강등 (INT64 -> INT32) 은 안전하지 않음. 오래된 파일과 새 스키마가 섞이면 reader 마다 처리 다름.

트랜잭션 스키마 진화가 필요하면 Iceberg / Delta Lake / Hudi 같은 table format 층을 위에 얹음.

논리 타입 (Logical Types, Parquet 2.x)

물리 타입 (INT32, INT64, BYTE_ARRAY 등) 위에 의미를 부여:

Logical Type	물리 타입	의미
`STRING`	BYTE_ARRAY	UTF-8 문자열
`DATE`	INT32	epoch 이후 일수
`TIMESTAMP`	INT64	밀리/마이크로/나노초
`DECIMAL(p,s)`	INT32/64/FIXED/BYTE_ARRAY	고정소수점
`UUID`	FIXED_LEN_BYTE_ARRAY(16)	128비트 UUID
`JSON`	BYTE_ARRAY	JSON 문자열
`VARIANT`	(nested)	반정형 데이터 (Parquet 2.11+)
`GEOMETRY/GEOGRAPHY`	BYTE_ARRAY	WKT/WKB (Parquet 2.11+)

중첩 구조 (Nested Schema)

Dremel 의 핵심 기여: 임의 깊이의 중첩 구조를 컬럼형으로 저장. Struct, List, Map 을 각 leaf 컬럼별 (definition level, repetition level) 로 인코딩.

schema: {
  user: {
    id: int64,
    tags: list<string>,
    addresses: list<{city: string, zip: string}>
  }
}

물리 저장:
  user.id                    (INT64)
  user.tags.list.element     (STRING) + rep/def levels
  user.addresses.list.city   (STRING) + rep/def levels
  user.addresses.list.zip    (STRING) + rep/def levels

Reader 는 rep/def level 로 원래 nested 구조를 복원. JSON 을 flatten 하지 않고도 컬럼 프로젝션이 됨.

Row Group / Page 크기 결정

파라미터	권장	범위	트레이드오프
Row Group	256-512 MB	128 MB - 1 GB	크면 압축 좋음/random access 느림
Page	1-10 MB	512 KB - 64 MB	작으면 필터링 세밀/오버헤드 증가
Rows per Row Group	1M-10M	컬럼 폭에 따라	메모리 vs 압축

일반 권장: 256 MB row group + SNAPPY/ZSTD + Dictionary encoding.

Parquet vs 다른 포맷

포맷	저장	압축	쿼리 속도	스키마 진화	중첩	주요 사용처
Parquet	Column	3-6x	빠름	우수	우수	데이터 레이크, 분석
ORC	Column	4-8x	빠름	우수	우수	Hive/Spark
Avro	Row	2-4x	느림	최고	우수	스트리밍 (Kafka)
CSV	Row	1-2x	매우 느림	없음	없음	Legacy, 사람 읽기
JSON	Row	1-3x	느림	우수	우수	API, 반정형
JSONL/NDJSON	Row	1-3x	느림	우수	우수	로그, 스트리밍

대략: Parquet 은 CSV 대비 크기 10-100배 감소, 분석 쿼리 10-100배 빠름.

라이브러리

언어/도구	라이브러리	특징
Python	`pyarrow`	C++ Arrow 백엔드, 권장
Python	`pandas` (v2.0+)	내부적으로 pyarrow 사용
Python/Rust	`polars`	매우 빠름, 최근 표준화
SQL (in-process)	`duckdb`	Parquet 을 SQL 로 바로
JVM	`parquet-mr`, Spark	Hadoop 생태계
Go	`parquet-go`	Segment/InfluxData 활용
Rust	`arrow-rs`, `parquet`	zero-copy, 매우 빠름

실전 예제

Python (pyarrow)

import pyarrow as pa
import pyarrow.parquet as pq

# 쓰기
table = pa.table({
    'id': [1, 2, 3],
    'name': ['a', 'b', 'c'],
    'ts': pa.array([1706000000, 1706000001, 1706000002], type=pa.timestamp('ms'))
})

pq.write_table(
    table,
    'out.parquet',
    compression='zstd',
    row_group_size=1_000_000,
    use_dictionary=True,
    write_statistics=True,
)

# 읽기 (필요한 컬럼만 + 필터)
table = pq.read_table(
    'out.parquet',
    columns=['id', 'ts'],
    filters=[('id', '>=', 2)],   # predicate pushdown
)

DuckDB (SQL 로 바로)

-- Parquet 을 테이블처럼 쿼리
SELECT COUNT(*) FROM 's3://bucket/data/**/*.parquet'
WHERE ts >= '2026-01-01';

-- Parquet 으로 저장
COPY (SELECT * FROM orders WHERE year = 2026)
TO 'orders_2026.parquet' (FORMAT PARQUET, COMPRESSION ZSTD);

Spark / [[aws-glue|Glue]]

# read
df = spark.read.parquet("s3://bucket/data/")
df.filter("year = 2026").select("id", "amount").show()

# write with partitioning
df.write \
  .mode("overwrite") \
  .partitionBy("year", "month") \
  .option("compression", "zstd") \
  .parquet("s3://bucket/out/")

데이터 레이크에서의 파티셔닝 관용

디렉토리 구조로 파티션 표현 (Hive 스타일):

s3://bucket/events/
├── year=2026/
│   ├── month=01/
│   │   ├── day=01/
│   │   │   └── part-00000.parquet
│   │   └── day=02/
│   └── month=02/

[[aws-athena|Athena]] / [[aws-redshift-spectrum|Spectrum]] / Spark 는 WHERE year=2026 AND month=01 을 만나면 그 폴더의 파일만 스캔. 파티션 프루닝 = 비용/시간 절감의 핵심.

Small Files Problem

파티션이 세분화되거나 스트리밍 flush 가 잦으면 파일이 작아짐 (KB ~ MB). 결과:

Row group 이 너무 작아 압축비 하락
파일 open/close 오버헤드 폭증
메타데이터 오버헤드 (파일당 footer)
[[aws-s3|S3]] LIST/GET 요청 비용 증가
쿼리 엔진의 파일 스캔 병렬화 손해

해결:

Compaction job: 작은 파일을 주기적으로 256 MB+ 로 합침
파티션 세분화 완화: day 대신 month
Iceberg / Delta Lake / Hudi: 자동 compaction, snapshot
[[aws-s3|S3]] Tables (2024+): 관리형 compaction

함정

[!WARNING] INT96 timestamp = Legacy (Impala 호환). 새 파일은 INT64 + timestamp logical type 사용. INT96 은 나노초까지만 표현 못함 + 표준 X.

[!CAUTION] row group 이 너무 큼 = OOM 위험, 스트리밍 flush 시 지연. 너무 작음 = 위 small files 문제. 256 MB 근처가 sweet spot.

[!WARNING] Dictionary encoding 이 fallback 하면 조용히 압축비 붕괴. Column cardinality 를 확인. 필요하면 dictionary_page_size_limit 조정.

[!IMPORTANT] 파일 rename/append 없다. Parquet 은 immutable. 수정하려면 새 파일로 write + 옛 파일 삭제. Iceberg/Delta 가 이 위에 트랜잭션 semantics 를 얹음.

[!CAUTION] Schema 변경 후 옛 파일과 섞임 = reader 따라 결과 다름. 스키마 이력 관리 (Iceberg schema ID) 또는 partitioned by schema version.

[!WARNING] UTF-8 아닌 문자열 을 STRING 으로 저장 = reader 별 처리 다름. BINARY (bytes) 로 저장하고 앱 레벨에서 처리.

[!IMPORTANT] 압축 codec 미지정 = SNAPPY 기본 (라이브러리별). 새 파이프라인은 ZSTD 로 명시. GZIP 은 CPU 부담 크니 아카이빙에만.

Athena 다중 포맷 쿼리: JSON, CSV, Parquet, Iceberg

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

[[aws-athena|Amazon Athena]] 는 하나의 SQL 인터페이스에서 [[aws-s3|S3]] 에 저장된 여러 포맷의 데이터를 그대로 조회 할 수 있음. 각 포맷은 SerDe (Serializer/Deserializer) 로 해석되며, 파일 종류별로 다른 문법과 성능 트레이드오프가 있음. 이 페이지는 실전에서 가장 자주 만나는 JSON, CSV, [[apache-parquet|Parquet]], Iceberg 를 다중 포맷 관점에서 정리.

지원 파일 포맷 & SerDe 매핑

포맷	SerDe (기본)	특징	스캔 비용 (상대)
CSV / TSV	`LazySimpleSerDe`, `OpenCSVSerDe`	사람이 읽기 편함, 대용량 부적합	100 (기준)
JSON	`Hive JsonSerDe`, `OpenX JsonSerDe`	반정형, 유연	~80
[[apache-parquet\|Parquet]]	네이티브 (Trino)	컬럼형 + 압축	~1-10
ORC	네이티브	컬럼형 + 인덱스	~1-10
Avro	`AvroSerDe`	로우형 + 스키마	~40
Ion	네이티브	Amazon Ion	~40
RegexSerDe	`RegexSerDe`	로그 파싱 (ALB, CloudFront, Apache)	~100
Grok	`GrokSerDe`	로그 패턴 매칭	~100
Apache Iceberg	네이티브 (Parquet 기반)	ACID + Time travel	~1-10
Delta Lake	네이티브 (2024+)	ACID	~1-10
Apache Hudi	네이티브	Incremental	~1-10

[!IMPORTANT] 스캔 비용 상대 지표는 CSV 대비 대략. 실제로 Parquet + 컬럼 프로젝션 + 파티션 프루닝 조합은 CSV 대비 100-400배 저렴 하기도.

CSV / TSV 쿼리

기본 (LazySimpleSerDe)

CREATE EXTERNAL TABLE raw.access_log_csv (
  timestamp STRING,
  ip STRING,
  method STRING,
  path STRING,
  status_code INT,
  bytes BIGINT
)
ROW FORMAT DELIMITED
  FIELDS TERMINATED BY ','
  LINES TERMINATED BY '\n'
STORED AS TEXTFILE
LOCATION 's3://logs/access/'
TBLPROPERTIES ('skip.header.line.count'='1');   -- 헤더 skip

인용부호 있는 CSV (OpenCSVSerDe)

CREATE EXTERNAL TABLE raw.customers_csv (
  id INT,
  name STRING,
  address STRING   -- 콤마 포함 가능
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES (
  'separatorChar' = ',',
  'quoteChar' = '"',
  'escapeChar' = '\\'
)
LOCATION 's3://raw/customers/';

[!WARNING] OpenCSVSerde 는 모든 컬럼을 STRING 으로 읽음. 숫자 컬럼은 쿼리 시 CAST() 필요. LazySimpleSerDe 는 스키마 대로 타입 캐스팅.

JSON 쿼리

JSON 데이터 예 (line-delimited JSON, NDJSON)

{"user_id": 42, "event": "click", "ts": "2026-07-30T15:00:00Z", "props": {"page": "/home", "duration_ms": 320}}
{"user_id": 43, "event": "view",  "ts": "2026-07-30T15:00:01Z", "props": {"page": "/products/1", "duration_ms": 5120}}

기본 (Hive JsonSerDe)

CREATE EXTERNAL TABLE raw.events_json (
  user_id BIGINT,
  event   STRING,
  ts      STRING,
  props   STRUCT<page: STRING, duration_ms: INT>
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://raw/events/';

OpenX JsonSerDe (더 유연)

CREATE EXTERNAL TABLE raw.events_openx (
  user_id BIGINT,
  event   STRING,
  ts      STRING,
  props   MAP<STRING, STRING>
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES (
  'ignore.malformed.json' = 'true',              -- 파싱 실패 row skip
  'dots.in.keys' = 'true',                       -- "user.id" 같은 키 허용
  'case.insensitive' = 'true',                   -- 대소문자 무시
  'mapping.userid' = 'user_id'                   -- 원본 -> 컬럼명 매핑
)
LOCATION 's3://raw/events/';

중첩 필드 접근

SELECT user_id,
       event,
       props.page AS page,
       props.duration_ms AS duration
FROM raw.events_json
WHERE props.duration_ms > 1000;

JSON_EXTRACT (SerDe 없이 raw string)

컬럼을 STRING 으로 두고 필요할 때만 파싱:

CREATE EXTERNAL TABLE raw.events_raw (
  payload STRING
)
LOCATION 's3://raw/events/';

SELECT JSON_EXTRACT_SCALAR(payload, '$.user_id') AS user_id,
       JSON_EXTRACT_SCALAR(payload, '$.props.page') AS page,
       CAST(JSON_EXTRACT_SCALAR(payload, '$.props.duration_ms') AS INT) AS duration
FROM raw.events_raw;

장점: 스키마 진화 자유. 단점: 매번 파싱 (느림, 비쌈).

Array UNNEST

{"user_id": 42, "tags": ["premium", "kr", "beta"]}

CREATE EXTERNAL TABLE raw.users_json (
  user_id BIGINT,
  tags    ARRAY<STRING>
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://raw/users/';

-- ARRAY 를 row 로 풀기
SELECT u.user_id, tag
FROM raw.users_json u, UNNEST(u.tags) AS t(tag);

중첩 ARRAY OF STRUCT

{"order_id": 1, "items": [{"sku": "A", "qty": 2}, {"sku": "B", "qty": 1}]}

CREATE EXTERNAL TABLE raw.orders_json (
  order_id BIGINT,
  items    ARRAY<STRUCT<sku: STRING, qty: INT>>
)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
LOCATION 's3://raw/orders/';

-- UNNEST + STRUCT 필드 접근
SELECT o.order_id, item.sku, item.qty
FROM raw.orders_json o, UNNEST(o.items) AS t(item);

[[apache-parquet|Parquet]] 쿼리

기본

CREATE EXTERNAL TABLE curated.orders (
  order_id BIGINT,
  user_id BIGINT,
  amount DECIMAL(10, 2),
  order_ts TIMESTAMP
)
PARTITIONED BY (year INT, month INT)
STORED AS PARQUET
LOCATION 's3://curated/orders/'
TBLPROPERTIES ('parquet.compression' = 'ZSTD');

ALTER TABLE curated.orders ADD
  PARTITION (year=2026, month=7)
    LOCATION 's3://curated/orders/year=2026/month=7/';

컬럼 프로젝션 + 파티션 프루닝

-- 스캔 = 필요한 컬럼 × 필요한 파티션
SELECT SUM(amount)
FROM curated.orders
WHERE year = 2026 AND month = 7;

-- 전체 스캔 (파티션 프루닝 실패)
SELECT SUM(amount) FROM curated.orders WHERE order_ts >= '2026-07-01';

[!IMPORTANT] 파티션 컬럼은 원본 그대로 (year = 2026), 함수/캐스팅 wrap 금지. 자세히: [[aws-athena|Athena]] 함정 섹션.

Parquet 중첩 필드

Parquet 은 중첩 struct/list 를 컬럼형으로 저장. SQL 은 JSON 과 동일:

SELECT o.order_id, item.sku, item.qty
FROM curated.orders_nested o, UNNEST(o.items) AS t(item);

Apache Iceberg 쿼리

CREATE TABLE lakehouse.orders (
  order_id BIGINT,
  user_id BIGINT,
  amount DECIMAL(10, 2),
  order_date DATE
)
PARTITIONED BY (order_date)
LOCATION 's3://lakehouse/orders/'
TBLPROPERTIES (
  'table_type' = 'ICEBERG',
  'format' = 'parquet',
  'write_compression' = 'zstd'
);

-- ACID
INSERT INTO lakehouse.orders VALUES (1, 42, 100.00, DATE '2026-07-30');
UPDATE lakehouse.orders SET amount = 200.00 WHERE order_id = 1;
DELETE FROM lakehouse.orders WHERE order_id = 1;
MERGE INTO lakehouse.orders AS t USING staging AS s
  ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET amount = s.amount
  WHEN NOT MATCHED THEN INSERT VALUES (s.order_id, s.user_id, s.amount, s.order_date);

-- Time travel
SELECT * FROM lakehouse.orders FOR TIMESTAMP AS OF TIMESTAMP '2026-07-01 00:00:00';
SELECT * FROM lakehouse.orders FOR VERSION AS OF 12345;

자세히: [[aws-athena|Athena]] Iceberg 섹션.

다중 포맷 조인 (같은 쿼리)

Athena 는 서로 다른 포맷의 테이블을 자유롭게 조인.

SELECT
  d.customer_name,          -- Parquet dimension
  SUM(f.amount) AS revenue  -- Parquet fact
FROM curated.customers d    -- Parquet
JOIN raw.orders_json f      -- JSON raw
  ON d.customer_id = f.user_id
WHERE f.event = 'purchase'
  AND d.country = 'KR'
GROUP BY d.customer_name;

Athena 내부 (Trino) 가 각 SerDe 로 읽고 컬럼형으로 변환해 조인.

CTAS: 포맷 변환

원본 CSV/JSON 을 [[apache-parquet|Parquet]] 로 승격.

CREATE TABLE curated.events_parquet
WITH (
  format = 'PARQUET',
  parquet_compression = 'ZSTD',
  external_location = 's3://curated/events/',
  partitioned_by = ARRAY['year', 'month', 'day']
)
AS
SELECT
  user_id,
  event,
  CAST(from_iso8601_timestamp(ts) AS TIMESTAMP) AS event_ts,
  props.page,
  props.duration_ms,
  YEAR(from_iso8601_timestamp(ts)) AS year,
  MONTH(from_iso8601_timestamp(ts)) AS month,
  DAY(from_iso8601_timestamp(ts)) AS day
FROM raw.events_json
WHERE from_iso8601_timestamp(ts) >= TIMESTAMP '2026-07-01';

결과:

원본 JSON 대비 5-10 배 압축
컬럼 프루닝 가능
파티션 프루닝 가능
이후 쿼리 요금 대폭 절감

주의: CTAS 는 한 번에 최대 100 파티션. 대량이면 INSERT INTO ... SELECT 로 청크 분할.

INSERT INTO (증분 적재)

INSERT INTO curated.events_parquet
SELECT ...
FROM raw.events_json
WHERE from_iso8601_timestamp(ts) >= DATE '2026-07-30'
  AND from_iso8601_timestamp(ts) < DATE '2026-07-31';

Iceberg 이면 트랜잭션 with duplicate protection 도 가능 (MERGE).

로그 파싱 (RegexSerDe)

ALB/CloudFront/S3 access log 처럼 정해진 텍스트 로그:

CREATE EXTERNAL TABLE raw.alb_logs (
  type STRING,
  time STRING,
  elb STRING,
  client_ip STRING,
  target STRING,
  request_processing_time DOUBLE,
  target_processing_time DOUBLE,
  response_processing_time DOUBLE,
  elb_status_code STRING,
  target_status_code STRING,
  received_bytes BIGINT,
  sent_bytes BIGINT,
  request STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = '1',
  'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) (.*)\" ...'
)
LOCATION 's3://alb-logs/AWSLogs/123/elasticloadbalancing/us-east-1/2026/07/';

Athena 콘솔 안에 ALB / CloudFront / VPC Flow Logs 등 정형 CREATE TABLE snippet 이 있음.

파일 포맷 선택 가이드

시나리오	포맷
원본 이벤트 스트림 raw 저장	JSON (스키마 진화 유연)
로그 원본 (외부 제공)	그대로 (Parquet 변환 검토)
정제 후 분석	[[apache-parquet\|Parquet]] + ZSTD + partition
ACID 트랜잭션 필요	Iceberg / Delta
사람이 읽기 필요	CSV (임시), 아니면 Parquet + BI
사이즈 최적화	Parquet + ZSTD (또는 GZIP)
ML 학습 tensor	Parquet

스캔 비용 실제 (동일 데이터, 다른 포맷)

원본 4 TB 로그 (uncompressed CSV, 100 컬럼) 를 컬럼 하나만 쿼리:

포맷	스캔량	비용 (Athena $5/TB)
CSV (uncompressed)	4 TB	$20
CSV + GZIP	~1.3 TB	$6.50
JSON (unc.)	~3.2 TB	$16
Parquet (SNAPPY, 100 컬럼 -> 1 컬럼 프로젝션)	~10 GB	$0.05
Parquet (ZSTD, 프로젝션 + 파티션 프루닝 90%)	~1 GB	$0.005

즉 Parquet + partition + projection 조합은 CSV 대비 4000 배 저렴.

스키마 진화 다루기

JSON:

OpenX SerDe + ignore.malformed.json=true 로 새 필드 자동 무시
새 컬럼 추가 시 ALTER TABLE ADD COLUMNS

Parquet:

새 컬럼 추가 -> 옛 파일은 NULL 반환
컬럼 타입 변경은 안전하지 않음 (Iceberg 로 승격 검토)

Iceberg:

Schema evolution 이 first-class. 컬럼 추가/제거/이름 변경/타입 승격 모두 트랜잭션.

함정

[!WARNING] SELECT * 로 JSON/CSV = 전체 컬럼 파싱, 비용 폭탄. 필요 컬럼만 SELECT.

[!CAUTION] OpenCSVSerDe 는 모두 STRING. 숫자/날짜 컬럼은 쿼리마다 CAST -> 느림. LazySimpleSerDe 로 스키마 지정 또는 [[apache-parquet|Parquet]] 로 승격.

[!WARNING] 파티션 컬럼에 함수 적용 = 파티션 프루닝 실패. WHERE year = 2026 그대로.

[!IMPORTANT] JSON 중첩 필드 SerDe 매핑. Hive JsonSerDe 는 대소문자 민감, OpenX 는 옵션. 소스 케이스 맞춰 SerDe 선택.

[!CAUTION] 작은 파일 수천 개 = 성능/비용 폭탄. CTAS 로 정기 compaction.

[!WARNING] JSON_EXTRACT 남용 = 매 쿼리 파싱. 자주 쓰는 필드는 SerDe 로 매핑 또는 Parquet 로 승격.

[!IMPORTANT] Iceberg 를 Lake Formation 으로 등록 = DDL 제한. Athena 에서 UPDATE/DELETE 안 되는 경우.

[!CAUTION] CTAS 한 번에 100 파티션 초과 = 오류. INSERT INTO ... SELECT 로 나눠서.

ETL / ELT

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

ETL = Extract (추출) + Transform (변환) + Load (적재). 여러 소스에서 데이터를 뽑아 정제한 뒤 [[data-warehouse|데이터 웨어하우스]] 에 저장하는 파이프라인.

ELT 는 순서를 바꿔서 원본 그대로 warehouse 에 먼저 적재하고, warehouse SQL 로 변환. 현대 클라우드 DW ([[aws-redshift|Redshift]], BigQuery, Snowflake) 의 컴퓨트가 강력해지면서 사실상 표준이 됨.

3단계

1. Extract (추출)

소스 시스템에서 데이터 읽기.

소스 유형	예시	추출 방식
관계형 DB	[[postgresql\|Postgres]], MySQL, [[aws-rds\|RDS]]	JDBC full/incremental, CDC (WAL/binlog)
NoSQL	[[dynamodb\|DynamoDB]], [[mongodb\|MongoDB]]	Streams, snapshot
SaaS API	Salesforce, Stripe, Zendesk	REST API + pagination
파일	CSV, JSON, [[apache-parquet\|Parquet]] on [[aws-s3\|S3]]	Object listing + read
이벤트 스트림	Kafka, Kinesis	Consumer group
로그	Application logs	Fluent Bit, CloudWatch subscription

추출 방식:

Full: 매번 전체 (작은 테이블)
Incremental (updated_at): WHERE updated_at > last_run
CDC (Change Data Capture): WAL/binlog 스트림 -> 거의 실시간
Snapshot + delta: 주기적 full + 그 사이 CDC

2. Transform (변환)

원본을 사용 가능한 형태로 정제.

Cleaning: null 처리, 이상치 제거, dedup
Type casting: 문자열 -> DATE/NUMERIC 등
Standardization: timezone UTC, currency, unit
Enrichment: 다른 소스 join, geolocation lookup
Aggregation: hourly/daily rollup
Denormalization: [[data-warehouse|DW]] star schema 형태로 flatten
Anonymization: PII 마스킹, hashing

3. Load (적재)

Target 시스템 (DW, 데이터 마트, 검색 인덱스, 특징 저장소) 에 씀.

Bulk COPY: [[aws-redshift|Redshift]] COPY, Snowflake COPY INTO, BigQuery LOAD DATA
Upsert (MERGE): SCD 관리
Append-only: 이벤트 로그, immutable fact
Overwrite partition: 하루치 재처리 시 파티션 단위 삭제 후 재적재

ETL vs ELT

flowchart LR
    subgraph ETL_flow[전통 ETL]
        S1[Source] --> E1[Extract]
        E1 --> T1["Transform<br/>(별도 ETL 서버)"]
        T1 --> L1["Load into DW<br/>(정제된 형태)"]
    end

    subgraph ELT_flow[현대 ELT]
        S2[Source] --> E2[Extract]
        E2 --> L2["Load raw into DW<br/>(원본 그대로)"]
        L2 --> T2["Transform<br/>(DW SQL 로)"]
    end

축	ETL	ELT
변환 위치	별도 ETL 서버/엔진	DW 내부 SQL
DW 저장 데이터	정제된 최종본	Raw + staging + 최종본
재처리	파이프라인 다시 실행 (느림)	SQL 로 rebuild (빠름)
스키마 유연성	사전 스키마 필요	Schema-on-read 가능
DW 비용	저장 적음	저장 많음 (raw 유지)
컴퓨트 비용	ETL 서버 (별도)	DW 컴퓨트 사용
툴	Informatica, Talend, SSIS, [[aws-glue\|Glue]]	dbt, Dataform, [[aws-redshift\|Redshift]] SQL, Snowflake
적합	소스 데이터가 크고 DW 컴퓨트가 비쌀 때	클라우드 DW (탄력적 컴퓨트)
디버깅	여러 시스템 걸침, 어려움	DW 안에서 SQL, 쉬움

현대 표준: 클라우드 DW + dbt + Airflow/Dagster/Prefect. ELT 방향으로 옮겨감.

언제 ETL 이 여전히 맞나

PII 를 DW 에 저장하면 안 될 때 -> 로드 전 마스킹
소스 볼륨이 DW 저장/컴퓨트 대비 압도적으로 클 때 -> 미리 aggregate
DW 가 legacy on-prem 이고 확장이 어려울 때

아키텍처 패턴

배치 파이프라인

가장 흔함. 시간/일 단위.

flowchart LR
    Src[Source DB] -->|"nightly dump"| Raw["S3 raw/"]
    Raw -->|"[[aws-glue|Glue]] job"| Staged["S3 staged/<br/>[[apache-parquet|Parquet]]"]
    Staged -->|"COPY"| DW["[[aws-redshift|Redshift]]"]
    DW -->|"dbt run"| Marts["Marts"]
    Airflow[Airflow scheduler] -.orchestrate.-> Raw
    Airflow -.orchestrate.-> Staged
    Airflow -.orchestrate.-> DW

오케스트레이터: Airflow, Dagster, Prefect, [[aws-step-functions|Step Functions]], Argo Workflows
실행 엔진: Spark ([[aws-glue|Glue]]), Python, dbt
저장: [[aws-s3|S3]] raw -> [[apache-parquet|Parquet]] staged -> [[aws-redshift|Redshift]] marts

스트리밍 파이프라인

거의 실시간 (초/분 단위).

flowchart LR
    App[App 이벤트] --> Kafka[Kafka / Kinesis]
    Kafka --> Flink["Flink / Kafka Streams<br/>(변환/집계)"]
    Flink --> DW["[[aws-redshift|Redshift]] Streaming Ingestion"]
    Flink --> S3["S3 (이벤트 원본 보관)"]
    S3 --> Batch["배치 재처리"]

엔진: Apache Flink, Spark Structured Streaming, Kafka Streams, ksqlDB
딜리버리: exactly-once (Flink checkpoints, Kafka transactions)
이슈: late-arriving events, watermark, event time vs processing time

Lambda / Kappa

Lambda: 실시간 (speed) + 배치 (batch) 이중 파이프라인. 배치가 최종 진실.
Kappa: 스트리밍 only. 재처리도 스트림 재실행.

현대는 Kappa 지향 (하나의 파이프라인).

CDC 파이프라인

[Source DB WAL/binlog] -> Debezium -> Kafka -> Sink (DW / lake / cache)

소스 스키마 변경 -> 자동 propagation (설정에 따라)
Sub-second 지연
[[aws-redshift|Redshift]] Zero-ETL, DMS, Fivetran 등 매니지드 옵션

Medallion Architecture (Bronze / Silver / Gold)

Databricks 가 대중화한 [[data-warehouse|Lakehouse]] 계층:

Bronze: raw ingestion, 소스 형식 유지
Silver: cleaned, deduped, enriched, join 가능한 상태
Gold: business-level aggregates, BI 소비

Kimball 의 staging / core / mart 와 사실상 같은 개념.

오케스트레이션 도구

도구	특징
Apache Airflow	Python DAG, 사실상 표준, 규모 크면 세팅 복잡
Dagster	자산 (asset) 중심, 강한 타입, dbt 통합 우수
Prefect	Pythonic, 동적 워크플로우, 서버리스 옵션
[[aws-step-functions\|AWS Step Functions]]	서버리스, AWS 네이티브, 상태 머신
[[aws-glue\|AWS Glue]] Workflows	Glue 내장, 단순
Argo Workflows	Kubernetes 네이티브
Kestra	YAML 선언형, 최근 성장
cron + Bash	초기 프로토타입만

변환 도구

dbt (data build tool)

ELT 의 T. SQL SELECT 문 + Jinja 로 변환 로직을 버전 관리.

-- models/marts/fact_orders.sql
{{ config(materialized='incremental', unique_key='order_id') }}

SELECT
  o.order_id,
  o.customer_id,
  o.amount,
  o.created_at
FROM {{ ref('stg_orders') }} o
{% if is_incremental() %}
  WHERE o.updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

테스트 (unique, not null, accepted values) 코드로
Lineage 자동 문서화 (dbt docs)
사실상 표준

Spark ([[aws-glue|Glue]], Databricks, EMR)

큰 변환, semi-structured, ML 특징 엔지니어링.

Pandas / [[pandas|pandas]] / Polars / DuckDB

작은 배치, 노트북, 프로토타입.

데이터 계약 (Data Contracts)

소스 -> 파이프라인 사이 스키마/의미 합의. 소스 팀이 스키마를 몰래 바꿔서 파이프라인이 조용히 깨지는 사고를 방지.

# 예: user_signup 이벤트 계약
event: user_signup
owner: growth-team
schema:
  user_id: uuid
  email: string, PII
  signup_at: timestamp, utc
  source: enum[web, ios, android]
sla:
  freshness: 5min
  completeness: 99.9%

Protobuf/Avro/JSON Schema 로 코드화
CI 에서 소스 릴리즈 시 계약 검증
위반 시 배포 차단

Idempotency & Reprocessing

파이프라인은 같은 입력 -> 같은 출력 이어야 안전한 재실행이 가능.

핵심 기법:

파티션 재작성 (INSERT OVERWRITE 하루치)
자연 키 기반 upsert (MERGE)
Watermark (스트리밍 late-arriving)
DAG 실행 ID 로 stale write 방지

Anti-pattern: INSERT ... SELECT 를 재실행 -> 중복 축적.

데이터 품질 (Data Quality)

파이프라인의 실질적 신뢰도.

검증 종류	예시
Schema	컬럼 타입/개수
Not null	필수 컬럼
Unique	기본 키
Referential	fact -> dim FK
Range	나이 0-150, 금액 >= 0
Freshness	마지막 update 가 SLA 내
Completeness	row 수 이전 배치 대비 -50% 이면 alert
Distribution drift	값 분포가 급변하면 alert

도구: dbt tests, Great Expectations, Soda, Monte Carlo, Bigeye.

관측성 (Data Observability)

파이프라인의 5가지 축:

Freshness - 마지막 갱신 시점
Volume - row 수
Schema - 스키마 변경
Distribution - 값 분포
Lineage - upstream/downstream 영향 범위

AWS 에서의 ETL 구성

컴포넌트	선택지
Extract	[[aws-glue\|Glue]] Crawler, DMS (CDC), Kinesis Firehose
Store	[[aws-s3\|S3]] (data lake), [[apache-parquet\|Parquet]] 권장
Transform	[[aws-glue\|Glue]] Spark job, [[aws-athena\|Athena]] CTAS, [[aws-lambda\|Lambda]] (소규모), dbt on Redshift
Load / Query	[[aws-redshift\|Redshift]] COPY, [[aws-athena\|Athena]] on S3, [[aws-redshift-spectrum\|Spectrum]]
Orchestrate	[[aws-step-functions\|Step Functions]], MWAA (managed Airflow), EventBridge Scheduler
Catalog	[[aws-glue\|Glue]] Data Catalog
Quality	[[aws-glue\|Glue]] Data Quality (DQDL), Deequ

함정

[!WARNING] 한 파이프라인에 모든 로직 몰아넣기 = 재사용 불가. Extract, Transform, Load 를 태스크 단위로 분리하고 재시도/재실행이 각각 가능해야 함.

[!CAUTION] 파이프라인 실패를 조용히 넘김 = 다운스트림이 stale 데이터로 오판. Freshness alert + SLA 필수.

[!WARNING] 소스 스키마 변경 감지 안 함 = 컬럼 추가/제거/타입 변경 시 파이프라인이 오늘부터 다른 데이터를 만듬. 데이터 계약 + schema evolution 정책 필수.

[!IMPORTANT] 재실행 불가능한 파이프라인 = 프로덕션 사고. INSERT ... SELECT 대신 INSERT OVERWRITE PARTITION 또는 MERGE 로 idempotent 하게 설계.

[!CAUTION] 작은 파일 수천 개 생성 = [[apache-parquet|Parquet]] 성능 붕괴 + [[aws-athena|Athena]] / [[aws-redshift-spectrum|Spectrum]] 비용 폭탄. Compact job 필수 (128 MB - 1 GB 파일 크기 target).

[!WARNING] PII 를 raw 로 DW 에 로드 = 규제 위반. 로드 전 masking / tokenization, 또는 정책 기반 컬럼 접근 제어.

[!WARNING] Airflow 의 execution_date 혼동 = “실행 시각” 이 아니라 “이 실행이 처리하는 논리 시각” (interval start). 미리 알아두지 않으면 하루 어긋난 데이터가 나옴.

Hadoop / Spark

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

Hadoop 은 2006 야후에서 시작된 분산 저장 + 분산 처리 오픈소스 플랫폼. Google 이 2003-2004 년에 발표한 GFS (분산 파일시스템) 와 MapReduce (분산 처리 모델) 논문을 오픈소스로 구현한 것이 출발점.

Spark 는 2009 UC Berkeley AMPLab 에서 시작된 인메모리 분산 처리 엔진. MapReduce 의 디스크 I/O 병목을 해결하기 위해 RDD (Resilient Distributed Dataset) 개념을 도입해 반복 계산에서 10-100 배 빠른 성능 을 제공.

두 시스템 모두 단일 서버로 처리 불가능한 규모의 데이터 를 여러 서버로 나눠 처리하는 것이 목적. 오늘날 [[data-lake|데이터 레이크]] / [[data-warehouse|데이터 웨어하우스]] 위의 대규모 처리 엔진은 대부분 이 두 계보를 잇는다.

Hadoop 의 두 축

Hadoop 은 원래 저장 (HDFS) + 처리 (MapReduce) 두 컴포넌트로 시작. 이후 YARN (자원 관리) 이 분리되어 3 요소가 됨.

flowchart TB
    subgraph Hadoop
        subgraph Storage["저장"]
            HDFS["HDFS<br/>(분산 파일시스템)"]
        end
        subgraph Resource["자원 관리"]
            YARN["YARN<br/>(스케줄러)"]
        end
        subgraph Compute["처리"]
            MR["MapReduce"]
            OtherEngines["Spark, Hive, Flink, Tez..."]
        end
    end

    Compute --> YARN
    Compute --> HDFS
    YARN --> Storage

HDFS (Hadoop Distributed File System)

파일을 고정 크기 블록 (기본 128 MB) 으로 나눠 여러 노드에 분산 저장 + 복제.

flowchart TB
    NN["NameNode<br/>(메타데이터: 파일→블록→노드 매핑)"]
    DN1["DataNode 1"]
    DN2["DataNode 2"]
    DN3["DataNode 3"]
    DN4["DataNode 4"]

    NN -.->|heartbeat| DN1
    NN -.->|heartbeat| DN2
    NN -.->|heartbeat| DN3
    NN -.->|heartbeat| DN4

    File["file.parquet 1 GB"] --> B1["Block 1 (128MB)"]
    File --> B2["Block 2"]
    File --> B3["Block 3"]
    File --> B8["... Block 8"]

    B1 -.->|"replica 3"| DN1
    B1 -.-> DN2
    B1 -.-> DN3
    B2 -.-> DN2
    B2 -.-> DN3
    B2 -.-> DN4

핵심 특성:

큰 블록 (128 MB 기본): 파일당 블록 수 감소 -> NameNode 부담 감소, sequential I/O 최적
복제 계수 3 (기본): 노드/랙/데이터센터 장애에 대비
Write-Once-Read-Many: append 만 가능, 임의 수정 불가 (log-structured 사고)
Rack awareness: 복제본을 다른 랙에 분산 (물리 장애 격리)

한계:

NameNode 는 단일 지점 병목 (HA 로 완화)
작은 파일 다수 는 부적합 (파일당 블록 오버헤드)
저지연 요구 (< 100 ms) 부적합 (배치 지향)

클라우드 시대에는 [[aws-s3|S3]] 같은 객체 저장소가 사실상 HDFS 를 대체 ([[aws-emr|EMR]] 은 EMRFS 로 S3 를 HDFS 처럼 접근).

MapReduce

큰 데이터를 작은 조각으로 나눠 병렬 처리 -> 결과를 합치는 프로그래밍 모델. Google 이 2004 년에 발표.

flowchart LR
    Input[("입력 데이터<br/>여러 블록")]

    subgraph Map["Map 단계 (병렬)"]
        M1["Mapper 1<br/>(k,v) 방출"]
        M2["Mapper 2"]
        M3["Mapper N"]
    end

    subgraph Shuffle["Shuffle 단계<br/>(네트워크 재분배)"]
        S["같은 key 는 같은 reducer 로"]
    end

    subgraph Reduce["Reduce 단계 (병렬)"]
        R1["Reducer 1<br/>집계"]
        R2["Reducer 2"]
    end

    Output[("결과")]

    Input --> M1
    Input --> M2
    Input --> M3

    M1 --> S
    M2 --> S
    M3 --> S

    S --> R1
    S --> R2

    R1 --> Output
    R2 --> Output

예: WordCount

Map:    "hello world" → [("hello", 1), ("world", 1)]
Shuffle: 같은 word 를 같은 reducer 로 보냄
Reduce: [("hello", 1), ("hello", 1), ...] → ("hello", 42)

MapReduce 의 한계 (Spark 등장의 이유):

단계마다 디스크 write (Map 결과 -> disk -> Shuffle -> disk -> Reduce)
반복 알고리즘 (ML 학습, PageRank) 이 매우 느림 (매 iteration 마다 디스크 왕복)
표현력 제한 (map + reduce 로 표현 어려운 알고리즘 다수)

YARN (Yet Another Resource Negotiator)

컴퓨트 자원 (CPU, 메모리) 을 여러 애플리케이션에 분배 하는 스케줄러. Hadoop 2.x 부터 MapReduce 로부터 분리.

구성:

ResourceManager (마스터): 전체 자원 스케줄링
NodeManager (워커): 각 노드의 컨테이너 관리
ApplicationMaster (앱별): 애플리케이션의 태스크 조율

YARN 위에서 MapReduce, Spark, Flink, Hive 등이 함께 실행 가능 -> Hadoop 이 단일 처리 엔진이 아닌 플랫폼 이 됨.

Spark 의 등장

“디스크 I/O 를 줄이자” 가 핵심 통찰.

RDD (Resilient Distributed Dataset)

Spark 의 원류 추상. 메모리에 분산 저장된 불변 컬렉션.

“Resilient” 의 의미: 데이터 자체를 복제해서 저장하지 않고, 데이터를 만드는 계보 (lineage) 만 저장. 노드 장애 시 lineage 를 다시 실행해 복구.

raw = sc.textFile("s3://.../logs")           # RDD 1
words = raw.flatMap(lambda l: l.split())      # RDD 2 (lineage: raw → flatMap)
counts = words.map(lambda w: (w, 1))          # RDD 3
result = counts.reduceByKey(lambda a, b: a+b) # RDD 4
result.saveAsTextFile("s3://.../out")         # Action

Transformation (map, filter, join): 지연 실행 (lazy), lineage 만 기록
Action (count, collect, save): 실제 실행 트리거

DAG 스케줄러

Transformation 을 DAG (Directed Acyclic Graph) 로 표현 -> stage (shuffle 경계) 로 나눔 -> task 로 분해 -> executor 에서 병렬 실행.

flowchart LR
    subgraph Stage1["Stage 1 (narrow deps)"]
        T1[Read] --> T2[Filter] --> T3[Map]
    end

    subgraph Boundary["Shuffle 경계"]
        S["ShuffleWrite/Read"]
    end

    subgraph Stage2["Stage 2 (narrow deps)"]
        T4[Combine] --> T5[Output]
    end

    Stage1 --> S --> Stage2

Narrow dependency (map, filter): 파티션 1 → 파티션 1 (shuffle X)
Wide dependency (groupBy, join): 파티션 다수 → 파티션 재분배 (shuffle O)

Shuffle 이 성능 병목이므로 shuffle 을 최소화 하는 게 Spark 튜닝의 핵심.

DataFrame / Dataset (2015+)

RDD 는 저수준. Catalyst Optimizer 가 최적화할 수 있도록 스키마와 SQL 문법 을 얹은 것이 DataFrame / Dataset.

# RDD (저수준, 최적화 여지 없음)
raw.filter(lambda r: r[2] > 100).map(lambda r: (r[0], r[3]))

# DataFrame (Catalyst 가 파티션 프루닝, 컬럼 프루닝, predicate pushdown 자동)
df.select("id", "amount").filter("amount > 100")

# SQL (같은 최적화 자동)
spark.sql("SELECT id, amount FROM t WHERE amount > 100")

Catalyst 가 자동으로:

Predicate pushdown ([[apache-parquet|Parquet]] statistics 활용)
Column pruning
Constant folding
Join reordering
Whole-stage code generation (Java bytecode 생성)

현대에는 DataFrame API + SQL 이 사실상 표준. RDD 는 직접 사용 드묾.

아키텍처

flowchart TB
    subgraph Driver["Driver 프로세스"]
        Main["사용자 코드 main()"]
        DAG["DAG Scheduler"]
        Task["Task Scheduler"]
    end

    subgraph CM["Cluster Manager<br/>(YARN / K8s / Standalone)"]
        RM["자원 할당"]
    end

    subgraph Workers["Executor JVM 들"]
        E1["Executor 1<br/>(N task slot)"]
        E2["Executor 2"]
        E3["Executor N"]
    end

    Main --> DAG
    DAG --> Task
    Task -->|"task 제출"| CM
    CM --> E1
    CM --> E2
    CM --> E3

    E1 -.->|"결과 반환"| Driver

Driver: 사용자 코드 실행, DAG 생성, 태스크 분배
Executor: 실제 데이터 처리 (여러 task 동시 실행 = slot)
Cluster Manager: 자원 할당 (YARN / [[aws-emr|EMR]] / K8s / Standalone)

Spark 컴포넌트

Spark 는 하나의 엔진 위에 여러 상위 라이브러리 제공.

컴포넌트	용도
Spark Core	RDD, DAG, 실행 엔진
Spark SQL	DataFrame + SQL 쿼리 (Catalyst 최적화)
Structured Streaming	DataFrame API 로 스트리밍 (micro-batch or continuous)
MLlib	분산 머신러닝 (일부 알고리즘)
GraphX	그래프 분석 (거의 사용 안 됨, GraphFrames 로 대체)

MapReduce vs Spark

축	MapReduce	Spark
저장	단계마다 디스크	메모리 우선 (부족 시 디스크 spill)
모델	Map + Reduce 2 단계	임의 DAG (map, filter, join, groupBy, …)
속도	기준	10-100 배 (반복 알고리즘)
API	Java 위주	Scala, Python, R, SQL, Java
상호작용	배치 only	REPL / 노트북 (Zeppelin, Jupyter)
스트리밍	X (Storm 별도)	Structured Streaming
ML	Mahout 별도	MLlib 내장
표현력	낮음	높음 (SQL, DataFrame, MLlib)
디버깅	어려움	Spark UI

결론: 새 프로젝트는 사실상 Spark. MapReduce 는 레거시 유지만.

관리형 Spark / Hadoop

서비스	특징
[[aws-emr\|Amazon EMR]]	Hadoop 생태계 완전 관리형, EC2/Serverless/EKS
[[aws-glue\|AWS Glue]]	서버리스 Spark ETL
Databricks	Spark 창시자들의 상용, Delta Lake
Google Dataproc	GCP 관리형
Azure HDInsight / Synapse	Azure
자체 호스팅	Cloudera, Hortonworks (인수 통합)

언제 Spark 를 쓰나

적합:

수 GB ~ PB 규모 배치 처리
ETL 파이프라인 (raw -> 정제)
ML 특징 엔지니어링 + 학습
대규모 join / aggregation
반복 알고리즘 (K-means, GraphX, PageRank)
로그/이벤트 스트림 분석 (Structured Streaming)

부적합 (더 나은 대안):

초저지연 (< 100 ms) 처리 -> [[aws-kinesis-data-analytics|Flink]] / Kafka Streams
트랜잭션 처리 -> [[postgresql|Postgres]] / OLTP DB
작은 데이터 (< 10 GB) -> pandas / DuckDB / Polars
단순 SQL 애드혹 -> [[aws-athena|Athena]] / [[aws-redshift|Redshift]]

Spark 성능 튜닝의 큰 축

파일 포맷: [[apache-parquet|Parquet]] + ZSTD (CSV/JSON 대비 10-100 배)
파티셔닝: partition 컬럼으로 프루닝
Shuffle 최소화: repartition 남용 X, broadcast join 활용
Broadcast join: 작은 테이블 (~ 100 MB) 을 executor 에 복제
AQE (Adaptive Query Execution): 런타임 통계로 자동 최적화 (Spark 3.x 기본 on)
Executor 크기: 너무 크면 GC 문제, 너무 작으면 오버헤드 (경험적 4-8 core, 16-32 GB)
Cache / Persist: 반복 참조 데이터만
Skew 처리: Salting, AQE skew join

함정

[!WARNING] collect() 를 큰 데이터에 = Driver OOM. Driver 는 단일 JVM. 큰 결과는 write / foreachPartition 로.

[!CAUTION] Shuffle 남용. groupBy, join, distinct, repartition 는 shuffle. Wide dependency 를 반복하면 성능 급락.

[!WARNING] 작은 파일 (Small files) 수천 개 = task 수 폭증 + 스케줄링 오버헤드. Compaction 후 read.

[!IMPORTANT] UDF 는 Catalyst 최적화 우회. 가능하면 built-in 함수 사용. Python UDF 는 특히 느림 (직렬화 오버헤드).

[!CAUTION] Skewed key = 특정 task 만 오래 걸림 (전체가 그 task 에 blocked). AQE skew join 또는 salting.

[!WARNING] HDFS 는 클라우드에서 임시. [[aws-emr|EMR]] 등에서 클러스터 종료 시 데이터 손실. 결과는 [[aws-s3|S3]] 에.

[!IMPORTANT] RDD 직접 사용 지양. DataFrame / SQL 이 Catalyst 최적화 받아 훨씬 빠름. 특수한 경우만 RDD.

MPP (대량 병렬 처리)

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

MPP (Massively Parallel Processing, 대량 병렬 처리) 는 하나의 대규모 쿼리를 수십 - 수백 노드에 나눠 동시에 실행하는 아키텍처. 각 노드가 자기 데이터 조각만 처리한 뒤 결과를 통합. [[data-warehouse|데이터 웨어하우스]] 의 표준 아키텍처.

대표 시스템: [[aws-redshift|Amazon Redshift]], Snowflake, Google BigQuery, Teradata, Greenplum, Vertica, IBM Netezza, ClickHouse.

왜 MPP 인가

단일 서버 DB ([[postgresql|Postgres]], MySQL) 는 CPU / 메모리 / 디스크 자원이 한계. 100 억 행 aggregation 은 시간 단위로 느려짐.

MPP 의 답: 데이터를 여러 노드에 나눠 저장하고, 쿼리를 각 노드에서 병렬 실행. 노드 100 개면 이론상 100 배 빠름 (실제로는 shuffle 오버헤드 등으로 낮음).

세 가지 분산 아키텍처

MPP 를 이해하려면 분산 시스템의 세 축 을 알아야 함.

flowchart TB
    subgraph SM["Shared-Memory<br/>(단일 서버)"]
        CPU1[CPU] --> Mem[공유 메모리]
        CPU2[CPU] --> Mem
        Mem --> Disk[디스크]
    end

    subgraph SD["Shared-Disk<br/>(Oracle RAC)"]
        N1[Node 1] --> SDisk[공유 스토리지]
        N2[Node 2] --> SDisk
        N3[Node 3] --> SDisk
    end

    subgraph SN["Shared-Nothing<br/>(MPP)"]
        NN1[Node 1] --> D1[로컬 디스크 1]
        NN2[Node 2] --> D2[로컬 디스크 2]
        NN3[Node 3] --> D3[로컬 디스크 3]
        NN1 <-.->|"네트워크"| NN2
        NN2 <-.->|"네트워크"| NN3
    end

축	Shared-Memory	Shared-Disk	Shared-Nothing (MPP)
자원	CPU/메모리 공유	디스크 공유	각자 소유
확장	Scale-up (단일 서버 강화)	Scale-out (제한적)	Scale-out (선형 확장)
동시성	락 경합	락 경합 (분산 락)	없음 (독립)
장애 격리	서버 전체 다운	디스크 SPOF	노드 하나만
네트워크 부담	없음	중간	큼 (shuffle)
대표	단일 [[postgresql\|Postgres]]	Oracle RAC	Redshift, Snowflake

MPP 는 shared-nothing = 각 노드가 자기 자원을 완전 소유. 네트워크로만 통신. 노드 수를 늘리면 (거의) 선형으로 성능 증가.

MPP 클러스터 구조

전형적인 MPP 는 leader + compute 로 구성.

flowchart TB
    Client["BI / JDBC / ODBC 클라이언트"]

    Client --> Leader

    subgraph Cluster["MPP 클러스터"]
        Leader["Leader Node<br/>(쿼리 파싱/최적화/조율)"]

        subgraph Compute["Compute Nodes (실제 데이터 처리)"]
            CN1["Compute 1<br/>slice 1, slice 2"]
            CN2["Compute 2<br/>slice 3, slice 4"]
            CN3["Compute N<br/>slice N-1, slice N"]
        end

        Leader -->|"실행 계획 배포"| CN1
        Leader -->|"실행 계획 배포"| CN2
        Leader -->|"실행 계획 배포"| CN3

        CN1 <-.->|"redistribution"| CN2
        CN2 <-.->|"redistribution"| CN3
        CN1 <-.-> CN3
    end

Leader Node

클라이언트 연결 종단
SQL 파싱, 검증
쿼리 최적화 (통계 기반)
실행 계획을 compute node 에 배포
각 compute 의 부분 결과를 통합해 클라이언트에 반환
데이터를 직접 처리하지 않음 (조율만)

Compute Node

실제 데이터 저장 + 처리
여러 slice (병렬 실행 단위) 로 분할 (노드당 코어 수 만큼)
Leader 로부터 받은 실행 계획을 자기 slice 에서 실행
필요 시 다른 노드로 데이터 재분배 (shuffle / redistribution)

데이터 분산 전략 (Distribution)

MPP 의 성능은 데이터를 어떻게 노드에 나눠놓았는가 에 좌우.

1. Hash Distribution (Key)

특정 컬럼 값을 hash 해서 slice 결정.

customer_id 1  → hash → slice 3 (Node 2)
customer_id 42 → hash → slice 7 (Node 4)

장점: 같은 key 를 조인 시 co-located join (네트워크 이동 없음).

-- customers.customer_id 로 hash 분산
-- orders.customer_id 로 hash 분산
-- 같은 key -> 같은 slice -> 로컬 join
SELECT ... FROM customers JOIN orders ON customers.customer_id = orders.customer_id;

단점: skew (특정 key 에 몰림) 시 그 slice 만 과부하.

2. Round-Robin / EVEN

행을 순서대로 다음 slice 에 배정. 균등 분산.

장점: skew 없음, 완전 균등. 단점: 조인 시 항상 redistribute 필요.

적합: 조인 안 하는 fact table, 로그.

3. Replicated / ALL

모든 노드에 같은 복사본. 작은 dimension table 에.

장점: 어떤 fact table 과도 조인 시 redistribute 불필요. 단점: 저장 공간 N 배 (N = 노드 수).

적합: 수백만 행 이하 dimension (date_dim, product_dim).

4. Automatic

시스템이 데이터 크기 / 접근 패턴 기반으로 자동 선택. Redshift AUTO, Snowflake 자동 등.

쿼리 실행 흐름

sequenceDiagram
    participant C as Client
    participant L as Leader
    participant N1 as Compute 1
    participant N2 as Compute 2
    participant N3 as Compute 3

    C->>L: SQL 쿼리
    L->>L: 파싱, 최적화, 계획 수립

    par 각 노드에서 병렬 스캔
        L->>N1: 스캔 + 필터 (자기 slice 데이터만)
        L->>N2: 스캔 + 필터
        L->>N3: 스캔 + 필터
    end

    N1-->>N1: 부분 aggregate
    N2-->>N2: 부분 aggregate
    N3-->>N3: 부분 aggregate

    Note over N1,N3: 필요 시 redistribution<br/>(GROUP BY 등)

    N1-->>L: 부분 결과
    N2-->>L: 부분 결과
    N3-->>L: 부분 결과

    L->>L: 최종 통합
    L-->>C: 결과

핵심 통찰: 가능한 한 각 노드에서 부분 aggregate 를 먼저 하고 (예: 각 노드에서 COUNT), 마지막에 leader 가 합침 (SUM of COUNTs). 이걸 못하면 모든 원본 데이터를 leader 로 모아야 함.

Redistribution (Shuffle)

같은 join key 가 다른 노드에 있으면, 조인 전에 네트워크로 재분배 필요.

Case 1: co-located join (좋음)
  customer.customer_id = order.customer_id
  둘 다 customer_id 로 hash 분산 -> 같은 slice -> 로컬 join

Case 2: redistribute (나쁨)
  customer.customer_id = order.city
  order 를 customer_id 로 redistribute -> 네트워크 이동 -> 느림

Case 3: broadcast (dimension 작을 때)
  small dim × huge fact
  small dim 을 모든 노드에 복사 -> 각 노드에서 로컬 join

Redistribution 이 성능 병목. 실행 계획 (EXPLAIN) 에서 DS_DIST_INNER, DS_BCAST_INNER 등을 확인.

MPP 의 강점

선형 확장성: 노드 2 배 -> 처리량 (거의) 2 배
컬럼형 저장 최적: 컬럼 단위로 압축 + 필요 컬럼만 스캔
대규모 aggregation: SUM, COUNT, GROUP BY 가 병렬로 나뉨
분석 쿼리 특화: OLAP 워크로드에 이상적

MPP 의 한계

작은 트랜잭션 부적합: INSERT 한 행씩은 매우 느림 (bulk COPY 필요)
JOIN 이 잘못 설계되면 성능 급락 (redistribution 폭탄)
데이터 skew 에 취약 (한 slice 만 과부하)
동시 사용자 한계 (leader 병목)
비싼 노드: 스토리지 + 컴퓨트가 결합 -> 확장 유연성 낮음

현대 MPP: Compute-Storage 분리

전통 MPP (Netezza, Teradata) 는 노드 안에 로컬 SSD/HDD 저장. Compute 를 늘리려면 스토리지도 함께.

현대 (Snowflake 2015+, Redshift RA3, BigQuery) 는 compute 와 storage 를 분리.

flowchart TB
    subgraph Old["전통 MPP (~2010)"]
        N1[Node = compute + storage] --> D1[로컬 SSD]
        N2[Node = compute + storage] --> D2[로컬 SSD]
    end

    subgraph New["현대 MPP (Snowflake, Redshift RA3)"]
        subgraph CT["Compute 티어"]
            C1[Compute]
            C2[Compute]
        end
        subgraph ST["Storage 티어"]
            S3["공유 스토리지<br/>(S3 / 자체)"]
        end
        C1 <--> S3
        C2 <--> S3
    end

이점:

Compute 만 늘리기 / 줄이기 가능 (탄력적)
여러 워크로드가 같은 데이터 공유 (data sharing)
스토리지는 사실상 무한 (S3)
유휴 시 compute 만 종료 (비용 절감)

대표 사례:

[[aws-redshift-serverless|Redshift Serverless]]: compute 완전 자동 스케일
Snowflake: multi-cluster virtual warehouse
BigQuery: 서버리스, slot 예약

MPP vs Spark (분산 처리의 두 계보)

같은 “분산 대규모 처리” 지만 철학이 다름.

축	MPP	[[hadoop-spark\|Spark]]
주 목적	분석 SQL 쿼리	임의 데이터 처리 (ETL, ML, 스트리밍)
저장	자체 (컬럼형, 최적화)	외부 ([[aws-s3\|S3]], HDFS)
인터페이스	SQL 중심	DataFrame, RDD, SQL
자원 모델	클러스터 고정 or 자동	Executor 온디맨드
실행 모델	Push-based (leader → compute)	DAG based, lazy
최적화	Cost-based optimizer (통계)	Catalyst (스키마 기반)
적합	BI, 대시보드, 반복 SQL	ETL, ML, 임시 대량 처리
대표	Redshift, Snowflake	Databricks, [[aws-emr\|EMR]], [[aws-glue\|Glue]]

현대는 융합: [[aws-redshift-spectrum|Redshift Spectrum]] 은 S3 (data lake) 쿼리, Databricks 는 Delta Lake + Photon (MPP 스타일 벡터화) -> Lakehouse 방향.

대표 MPP 시스템

시스템	특징
[[aws-redshift\|Amazon Redshift]]	PostgreSQL 기반 MPP, RA3 (compute-storage 분리), Serverless
Snowflake	Multi-cloud, virtual warehouse, 데이터 공유 우수
Google BigQuery	서버리스, Dremel 기반, slot 모델
Databricks SQL	Delta Lake + Photon (벡터화 엔진)
Teradata	원조 MPP (1979-), 온프렘 대세
Greenplum	오픈소스 (PostgreSQL 기반, VMware Tanzu)
Vertica	컬럼형 MPP, 광고/통신 산업
ClickHouse	오픈소스, 실시간 분석 특화, 매우 빠름
IBM Netezza	하드웨어 어플라이언스 원조
Firebolt	신생, 성능 강조

함정

[!WARNING] 행 단위 INSERT/UPDATE = MPP 의 최악의 워크로드. bulk load (COPY, [[apache-parquet|Parquet]] batch) 만.

[!CAUTION] 분산 키 설계 실수 = redistribution 폭탄. 자주 조인하는 컬럼을 distribution key 로.

[!WARNING] 데이터 skew (특정 key 에 몰림) = 한 slice 만 과부하, 전체 쿼리가 그 slice 에 blocked. Cardinality 확인.

[!IMPORTANT] 작은 dimension 을 hash 분산 하면 조인마다 redistribute. ALL / replicated 로.

[!CAUTION] SELECT * = 컬럼형의 이점 상실. 필요 컬럼만.

[!WARNING] 동시 사용자 많음 = leader node 병목. Concurrency scaling / Serverless 로 완화.

[!IMPORTANT] MPP 는 OLTP 대체 X. 트랜잭션 워크로드는 [[postgresql|Postgres]] 같은 OLTP DB. MPP 는 OLAP 전용.

데이터 레이크

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

데이터 레이크 (Data Lake) 는 구조 여부와 무관하게 모든 종류의 데이터를 원본 형식 그대로 저장하는 중앙 저장소. 스키마를 미리 강제하지 않고 (schema-on-read), 필요할 때 쿼리 엔진 / 프레임워크가 스키마를 해석. [[aws-s3|S3]] / GCS / Azure Data Lake Storage 가 사실상 표준 백엔드.

핵심 대비: [[data-warehouse|데이터 웨어하우스]] 는 schema-on-write (미리 정제된 데이터), 데이터 레이크는 schema-on-read (원본 저장 후 해석).

왜 데이터 레이크인가

전통 [[data-warehouse|DW]] 만으로는 부족한 이유:

비정형 / 반정형 데이터 (로그, JSON, 이미지, 오디오, 비디오) 를 DW 에 넣기 어려움
DW 저장은 비쌈, 원본 raw 를 모두 DW 에 두면 비용 폭발
ML 학습은 종종 원본 그대로 가 필요 (변환된 것이 아닌)
데이터 소스가 폭증 -> 스키마 강제가 병목

데이터 레이크의 답:

[[aws-s3|S3]] 같은 저비용 객체 스토리지에 원본 그대로 저장
소비 시점에 필요한 엔진이 스키마 해석 ([[aws-athena|Athena]] SQL, [[aws-emr|EMR]] Spark, ML 학습)
여러 워크로드가 같은 데이터 한 벌 을 공유

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

축	Data Lake	[[data-warehouse\|Data Warehouse]]
주 저장	원본 파일 ([[apache-parquet\|Parquet]], JSON, CSV, 이미지, …)	정제된 컬럼형 테이블
스키마	Schema-on-read	Schema-on-write
엔진	다양 ([[aws-athena\|Athena]], [[aws-emr\|EMR]], Spark, Presto)	자체 SQL ([[aws-redshift\|Redshift]], BigQuery)
데이터 종류	구조 + 반구조 + 비구조 (전부)	구조 (테이블)
저장 비용	매우 저렴 ([[aws-s3\|S3]] $0.023/GB)	비쌈 (Redshift RMS 등)
컴퓨트 비용	쿼리별 과금 (스캔량)	클러스터 시간
워크로드	ML, batch, 로그, 애드혹	BI, 대시보드, SQL 분석
트랜잭션	없음 (원시), Iceberg/Delta 로 가능	ACID
거버넌스	어려움 ([[aws-lake-formation\|Lake Formation]])	성숙
거버넌스 안 잡히면	data swamp	사일로
대표 스택	[[aws-s3\|S3]] + [[aws-glue\|Glue]] + [[aws-athena\|Athena]]	[[aws-redshift\|Redshift]] / Snowflake / BigQuery

현대적 결론: 둘 중 하나 가 아님. Lakehouse 로 통합하는 방향 (아래).

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

flowchart TB
    subgraph DW["Data Warehouse (전통)"]
        DW_S["정제된 컬럼형 저장"]
        DW_E["자체 SQL 엔진"]
        DW_A["ACID 트랜잭션"]
    end

    subgraph DL["Data Lake (2010s)"]
        DL_S["원본 파일 저장<br/>Parquet/JSON/Image"]
        DL_E["여러 엔진 (Athena, Spark, ...)"]
        DL_N["트랜잭션 없음"]
    end

    subgraph LH["Data Lakehouse (현재)"]
        LH_S["원본 파일 저장 + 트랜잭션 메타"]
        LH_F["Iceberg / Delta / Hudi"]
        LH_A["ACID + Time travel + Schema evolution"]
    end

    DW -.-> LH
    DL -.-> LH

Lakehouse = 데이터 레이크의 유연성 + DW 의 트랜잭션/거버넌스. Apache Iceberg, Delta Lake, Apache Hudi 같은 오픈 테이블 포맷이 핵심.

데이터 조직화: 계층 (Zones)

원본 그대로 다 섞이면 data swamp 가 됨. 계층을 나누는 것이 표준.

Medallion (Databricks 대중화)

계층	별칭	내용
Bronze	Raw	소스에서 온 그대로. 재처리 가능하도록 immutable
Silver	Cleaned	타입 정리, dedup, join 가능한 상태
Gold	Curated	비즈니스 도메인별 aggregate. BI 소비

Kimball 스타일 (전통 DW 관용)

계층	내용
Landing / Staging	원본 착륙
Core / Integrated	정규화된 통합 저장
Marts	비즈니스별 fact/dim

둘은 사실상 같은 개념. 이름과 표기가 다를 뿐.

표준 아키텍처 (AWS 위)

flowchart LR
    subgraph Sources
        DB[("RDS/Aurora")]
        Kafka[Kinesis/MSK]
        Logs[Application Logs]
        SaaS["SaaS API"]
        Files["파일 업로드"]
    end

    Sources -->|"Extract"| Bronze["S3 Bronze/<br/>(raw)"]
    Bronze -->|"Glue Spark"| Silver["S3 Silver/<br/>(Parquet, cleaned)"]
    Silver -->|"CTAS / Spark"| Gold["S3 Gold/<br/>(aggregates)"]

    Catalog[("Glue Data Catalog")] -.->|"schema"| Bronze
    Catalog -.-> Silver
    Catalog -.-> Gold

    Gold --> Athena["Athena SQL"]
    Gold --> Spectrum["Redshift Spectrum"]
    Gold --> EMR["EMR Spark"]
    Gold --> SM["SageMaker ML"]
    Athena --> BI[QuickSight]

    LF["Lake Formation<br/>(권한/거버넌스)"] -.-> Catalog

[[aws-s3|S3]]: 저장의 뿌리 (모든 계층)
[[aws-glue|Glue]]: 카탈로그 + Spark 변환
[[aws-lake-formation|Lake Formation]]: 세분화된 접근 제어
[[aws-athena|Athena]] / [[aws-redshift-spectrum|Spectrum]] / [[aws-emr|EMR]]: 소비 엔진
파일 포맷: [[apache-parquet|Parquet]] + ZSTD 압축이 사실상 표준

오픈 테이블 포맷 (Lakehouse 의 핵심)

포맷	특징	지원 엔진
Apache Iceberg	AWS/Netflix 표준화, hidden partitioning, schema evolution, snapshot	[[aws-athena\|Athena]], [[aws-emr\|EMR]], Spark, Trino, Flink
Delta Lake	Databricks 원류, transaction log, time travel	Spark, EMR, Databricks
Apache Hudi	Uber 원류, upsert 최적화, streaming ingest	Spark, Flink, [[aws-emr\|EMR]]

공통 기능:

ACID 트랜잭션 (concurrent read/write)
Time travel (스냅샷 이력)
Schema evolution (컬럼 추가/제거)
Hidden partitioning (사용자가 파티션 계산 안 해도 됨)
Compaction / vacuum (small files 자동 관리)

2024 이후 방향: [[aws-s3|S3]] Tables (관리형 Iceberg), Snowflake Iceberg 지원, Redshift + Iceberg, Databricks + UniForm.

S3 데이터 레이크 파일 구조 관용

s3://company-data-lake/
├── bronze/                              # raw
│   ├── source=rds_orders/
│   │   └── year=2026/month=07/day=30/
│   │       └── part-00000.parquet
│   ├── source=kinesis_events/
│   │   └── year=2026/month=07/day=30/hour=15/
├── silver/                              # cleaned
│   ├── db=analytics/table=orders/
│   │   └── year=2026/month=07/
│   │       └── part-00000.parquet
├── gold/                                # marts
│   ├── db=marts/table=daily_sales/
├── _catalog/                            # Iceberg/Delta metadata
├── _archive/                            # 오래된 raw (Glacier lifecycle)
└── _tmp/                                # 임시 (life 3d)

파티션 관용:

시계열: year=YYYY/month=MM/day=DD
다중 소스: source=xxx/year=.../...
테이블 단위: db=xxx/table=yyy/

데이터 레이크 성숙도 단계

Raw dump: 소스에서 그대로. 카탈로그 없음. -> data swamp 위험.
Cataloged: [[aws-glue|Glue Catalog]] 로 스키마 등록. [[aws-athena|Athena]] 로 쿼리 가능.
Zoned: Bronze/Silver/Gold 계층. 정제/승격 프로세스.
Governed: [[aws-lake-formation|Lake Formation]] 로 세분화 권한, PII 관리, lineage.
Lakehouse: Iceberg/Delta 로 트랜잭션, time travel, BI/ML 통합.

흔한 실패 패턴: Data Swamp

정제/카탈로그/권한 없이 데이터만 쌓임 -> 아무도 못 씀.

증상:

팀마다 다른 파일을 “orders” 로 부름
파일이 수백만 개 (small files)
CSV 파일이 컬럼 순서/개수 다름
PII 가 사방에 흩어짐
누가 언제 만든 파일인지 모름

예방:

데이터 계약 (contract): 소스와 파이프라인 간 스키마/의미 합의
[[aws-glue|Glue Catalog]] 등록 필수
Compaction job: 작은 파일 -> 256 MB+
Lifecycle 정책: 오래된 raw 는 [[aws-s3-glacier|Glacier]] 로
PII 스캔: Macie 등으로 자동 탐지
소유자 (owner) 태그: 모든 폴더/테이블에

파일 포맷 선택

데이터 종류	포맷	이유
이벤트 스트림 원본	JSON / [[apache-parquet\|Parquet]]	JSON = 유연, Parquet = 쿼리 빠름
분석용 정제 데이터	[[apache-parquet\|Parquet]] + ZSTD	압축 + 컬럼 프루닝
트랜잭션 필요	Iceberg / Delta (Parquet 위)	ACID + time travel
임시 / debug	CSV / JSON	사람이 읽기 편함
이미지 / 오디오	원본 (binary)	압축 이미 되어 있음
ML 학습 tensor	Parquet / TFRecord / WebDataset	병렬 read

성능 & 비용의 3 축

파일 포맷 - Parquet vs CSV 는 [[aws-athena|Athena]] 스캔비에서 10-100배 차이
파티션 프루닝 - 시계열 파티션으로 스캔 대상 축소
파일 크기 - 256 MB - 1 GB 범위 (small files 회피)

자세히: [[apache-parquet|Apache Parquet]], [[aws-athena|Athena]] 함정 섹션.

스토리지 계층화 (Lifecycle)

Raw 를 영구 보관하되 비용을 줄이는 관용:

Bronze/ (30일)     : S3 Standard
Bronze/ (90일)     : S3 Standard-IA
Bronze/ (1년+)     : S3 Glacier Flexible Retrieval
Bronze/ (7년+)     : S3 Glacier Deep Archive
Silver/            : Standard (자주 read)
Gold/              : Standard

자세히: [[aws-s3-glacier|S3 Glacier]], [[aws-s3|S3]] Lifecycle.

데이터 레이크 서비스 (AWS)

컴포넌트	서비스
저장	[[aws-s3\|S3]], [[aws-s3-glacier\|S3 Glacier]]
카탈로그	[[aws-glue\|AWS Glue Data Catalog]]
ETL	[[aws-glue\|Glue]] Spark, EMR, Databricks
거버넌스	[[aws-lake-formation\|Lake Formation]]
쿼리 (SQL)	[[aws-athena\|Athena]], [[aws-redshift-spectrum\|Redshift Spectrum]]
쿼리 (Spark)	[[aws-emr\|EMR]], Glue Spark
인제스션	Kinesis, [[aws-glue\|Glue]] CDC, DMS
BI	QuickSight
ML	SageMaker
PII 감지	Macie
관리형 Iceberg	S3 Tables (2024+)

함정

[!WARNING] 원본만 쌓고 계층/카탈로그 없음 = data swamp. 처음부터 zone (Bronze/Silver/Gold) + [[aws-glue|Glue Catalog]] 등록을 강제하는 파이프라인 규약 필요.

[!CAUTION] CSV / JSON 을 그대로 유지 = 다운스트림 ([[aws-athena|Athena]], [[aws-redshift-spectrum|Spectrum]]) 이 매번 10-100배 스캔량. Silver 계층으로 승격할 때 반드시 [[apache-parquet|Parquet]] 로.

[!WARNING] PII 무분별 저장 = 규제 위반 (GDPR, KISA). 로드 전 masking / tokenization, Macie 로 지속 탐지, Lake Formation 로 컬럼 접근 제어.

[!IMPORTANT] Small files 문제 를 무시 = 파티션 세분화 + 스트리밍 flush 로 수백만 파일 = 성능/비용 폭탄. Compaction job 필수, 또는 Iceberg auto-compact.

[!CAUTION] 트랜잭션 없이 UPDATE/DELETE 필요 = 원본 파일을 다시 쓰다가 partial write / 동시성 문제. Iceberg / Delta 로 승격.

[!WARNING] 접근 제어를 IAM/버킷 정책만으로 = 컬럼/row 단위 제어 불가. [[aws-lake-formation|Lake Formation]] 로 세분화.

[!IMPORTANT] “Data Lake vs Warehouse” 이분법 오류. 현대는 lakehouse 로 병합. [[data-warehouse|DW]] 는 Gold 계층의 특수 형태로 볼 수 있음.

[!CAUTION] lineage 없음 = 컬럼 값이 어디서 왔는지 추적 불가 -> 사고 시 원인 파악 불가. [[aws-glue|Glue Catalog]] + dbt docs / OpenLineage / Marquez.

데이터 웨어하우스

koa (김신건) — Thu, 30 Jul 2026 00:00:00 GMT

정의

데이터 웨어하우스 (Data Warehouse, DW) 는 여러 운영 시스템에서 흘러 들어온 이력 데이터를 통합해, 대규모 분석 쿼리를 빠르게 실행하도록 최적화된 중앙 저장소. 트랜잭션 처리 (OLTP) 가 아니라 의사결정 지원 (OLAP, BI, 리포팅, ML 특징 엔지니어링) 이 목적.

Bill Inmon (1990) 정의: 주제 지향 (subject-oriented), 통합 (integrated), 시변 (time-variant), 비휘발성 (non-volatile) 데이터 컬렉션.

왜 필요한가

운영 DB ([[postgresql|PostgreSQL]], [[aws-rds|RDS]], MySQL) 를 그대로 분석에 쓰면 문제가 쌓임:

OLTP 최적화: row-based 저장, 인덱스는 point-lookup 위주 -> SELECT SUM(x) FROM huge_table GROUP BY y 가 초 단위 -> 시간 단위로 느려짐
자원 경합: 분석 쿼리가 트랜잭션을 락, latency spike
스키마 분산: 서비스별 DB 가 나뉘어 있어 join 이 불가능
이력 부족: 운영 DB 는 최신 상태만, 과거 시점 재구성이 안 됨

DW 는 분석 전용 이라 다음을 뒤집음:

컬럼형 저장 (필요한 컬럼만 스캔)
압축 (컬럼 값이 비슷 -> 5-10배 압축)
병렬 실행 (MPP) (수십/수백 노드로 분산 스캔)
append/bulk load 위주 (row-level update 는 거의 없음)
스키마 통합 + 시계열 보존 (fact + dimension 모델)

OLTP vs OLAP

축	OLTP	OLAP (DW)
목적	트랜잭션 처리	분석 / BI / ML
저장 형식	Row-based	Column-based
쿼리 형태	소량 row 조회/갱신	대량 aggregation
동시성	수천 사용자 point 쿼리	수십 분석가 heavy 쿼리
정규화	3NF (중복 최소화)	Denormalized (join 최소화)
인덱스	B-tree point-lookup	Zone map, min-max, columnar
데이터 신선도	실시간	분/시간/일 단위 (배치)
변경 빈도	Row 단위 UPDATE 자주	Bulk INSERT/APPEND 위주
트랜잭션	ACID 필수	배치 로드 후 read-only 가까움
대표 예	[[postgresql	Postgres]], MySQL, [[dynamodb\|DynamoDB]]

아키텍처 계층

flowchart LR
    subgraph Sources["소스 (OLTP, 이벤트)"]
        RDS[("RDS/Aurora")]
        Kafka[Kafka/Kinesis]
        SaaS["SaaS API<br/>(Stripe, Salesforce)"]
        Logs[Application Logs]
    end

    Sources -->|"Extract + Load"| Raw

    subgraph Warehouse["Data Warehouse"]
        Raw["Raw / Landing<br/>(원본 그대로)"]
        Staging["Staging<br/>(타입 정리)"]
        Marts["Data Marts<br/>(dim + fact)"]
        Raw --> Staging
        Staging --> Marts
    end

    Marts -->|"SQL / BI"| BI[BI / 대시보드]
    Marts -->|"Feature Store"| ML[ML 학습]
    Marts -->|"Reverse ETL"| Ops["운영 시스템<br/>(활성화)"]

Raw / Landing: 소스 그대로. 재처리 가능하도록 원본 보존
Staging: 타입 캐스팅, dedup, timestamp 표준화
Marts / Curated: 비즈니스 도메인별 dimension + fact 테이블. 소비자가 직접 쿼리

데이터 모델링 방법론

Kimball (Dimensional / Star Schema)

업무 프로세스 중심 으로 fact 테이블 + 주변 dimension 테이블. Bottom-up.

       dim_date            dim_product
          │                     │
          └─────► fact_sales ◄──┘
                     │
                     ▼
                dim_customer
                     │
                     ▼
                 dim_store

Fact table: 이벤트/측정 (수량, 금액). 좁고 길다 (많은 row).
Dimension table: 컨텍스트 (누가, 무엇을, 언제, 어디서). 넓고 짧다.
Grain: fact 한 행이 무엇을 의미하는지 (한 주문 line, 한 클릭 등) 명확히 정의.
SCD (Slowly Changing Dimension): Type 1 (overwrite), Type 2 (버전), Type 3 (이전 값 컬럼) 등.

쉬운 SQL, BI 도구 친화 -> 사실상 산업 표준.

Inmon (Corporate Information Factory)

전사 통합 3NF 모델 (EDW) 을 먼저 만들고, 그 위에 부서별 mart 를 파생. Top-down.

엄격한 통합: 회사 전체 개념 하나의 스키마
느린 구축: 몇 년 걸림
일관성 최우선: 규제 산업 (금융/보험) 에 어울림

Data Vault 2.0

Hub (business key) + Link (관계) + Satellite (속성 변경 이력) 3 컴포넌트.

소스 시스템 변화에 강함
감사/이력 추적이 first-class
쿼리는 복잡 -> 소비 계층에서 star schema 로 pivot

현대 실무: raw/staging 은 Data Vault 스타일, 소비 계층은 Kimball star schema 조합이 많음.

DW vs Data Lake vs Data Lakehouse

축	Data Warehouse	Data Lake	Data Lakehouse
저장	구조화 (컬럼형)	원본 파일 ([[apache-parquet]], JSON, CSV)	원본 파일 + 트랜잭션 메타
스키마	Schema-on-write	Schema-on-read	둘 다
엔진	자체 SQL (Redshift, BigQuery)	다양 (Athena, Spark)	Delta Lake, Iceberg, Hudi
워크로드	BI, SQL 분석	ML, batch, 로그 원본	BI + ML 통합
비용	저장 비쌈, 쿼리 저렴	저장 매우 저렴 ([[aws-s3\|S3]]), 쿼리 유료	중간
트랜잭션	ACID	없음	ACID (Iceberg/Delta/Hudi)
거버넌스	성숙	어려움 (“data swamp”)	개선됨
대표	[[aws-redshift\|Redshift]], Snowflake, BigQuery	S3 + [[aws-athena\|Athena]] + [[aws-glue\|Glue]]	Databricks, Iceberg on S3

Lakehouse 는 lake 의 저비용 + warehouse 의 트랜잭션/거버넌스를 결합하려는 시도. 2020 이후 표준 방향.

주요 관리형 데이터 웨어하우스

제품	특징	강점	약점
[[aws-redshift\|Amazon Redshift]]	PostgreSQL 기반 MPP, RA3 + Serverless	AWS 통합, [[aws-redshift-spectrum\|Spectrum]], [[aws-glue\|Glue]] 연계	AWS 락인
Google BigQuery	Serverless, Dremel 기반	인프라 걱정 없음, 스토리지/쿼리 분리 과금	GCP 락인
Snowflake	Multi-cloud, virtual warehouse	UX 우수, 데이터 공유	벤더 비용
Azure Synapse	Azure 통합	Power BI 연계	성숙도
Databricks SQL	Delta Lake + Photon	Lakehouse, ML 통합	세팅 필요
ClickHouse	오픈소스 컬럼 DB	초고속, 셀프 호스팅	관리 부담
DuckDB	임베디드 OLAP	로컬/노트북 분석	단일 노드

컬럼형 저장이 빠른 이유

Row-based:
  [row1: col1, col2, col3, col4, ..., col50]
  [row2: col1, col2, col3, col4, ..., col50]
  → SELECT AVG(col3) 도 전체 row 를 읽어야 함

Column-based:
  [col1: v1, v2, v3, ..., vN]
  [col2: v1, v2, v3, ..., vN]
  [col3: v1, v2, v3, ..., vN]    ← 이 컬럼만 스캔
  → I/O 가 필요한 컬럼만

추가 이득:

압축: 같은 컬럼 값의 카디널리티가 낮음 -> RLE, Dictionary, Delta 등으로 5-10배 압축
SIMD: 같은 타입이 연속 -> CPU 벡터 명령
Zone map / min-max: 블록 skip
Late materialization: 필터 통과한 row 만 실제 조합

자세히: [[apache-parquet]] (파일 포맷), [[aws-redshift|Redshift]] (엔진 사례).

로딩 패턴

배치 [[etl]] / [[etl|ELT]]

가장 흔함. 시간/일 단위 배치.

[Source DB] ──dump──> [S3 raw] ──[aws-glue|Glue] transform──> [DW]

CDC (Change Data Capture)

소스 DB 의 WAL/binlog 을 스트림으로 수신, 거의 실시간 반영.

Debezium, AWS DMS, [[aws-redshift|Redshift]] Zero-ETL
지연: 초 단위
부하: 소스 DB 에 로그 리더 프로세스

스트리밍 인제스션

Kafka, Kinesis 에서 직접 DW 로 append.

[[aws-redshift|Redshift]] Streaming Ingestion, Snowpipe Streaming, BigQuery Storage Write API
Materialized view 로 auto-aggregate

Reverse ETL

DW 에서 계산된 지표를 다시 SaaS/운영 시스템으로 push (Hightouch, Census).

성능 최적화의 축

파티셔닝 / 정렬 키: filter predicate 컬럼으로 물리 분리 -> 블록 skip
분산 키 (MPP): join 키가 같은 노드에 -> shuffle 제거
파일 포맷: [[apache-parquet]] / ORC (컬럼형, 통계, 압축)
파일 크기: 128 MB ~ 1 GB 권장. 작은 파일 수천 개 = small files problem
압축 encoding: 컬럼별 특성에 맞는 코덱
Materialized view / pre-aggregation: 반복 쿼리를 미리 계산
Result cache: 같은 쿼리 결과 재사용
Concurrency scaling: 읽기 부하 시 클러스터 자동 확장

데이터 품질 & 거버넌스

DW 는 “회사의 단일 진실 (Single Source of Truth)” 목표. 품질/거버넌스 없으면 data swamp.

Data contracts: 소스와 target 간 스키마/의미 합의
Lineage: 컬럼 값이 어디서 왔는지 추적 ([[aws-glue|Glue]] Data Catalog, dbt docs)
Testing: dbt test, Great Expectations, Soda 로 not null / unique / accepted values 검증
Access control: 컬럼/row 단위 접근 (Redshift RLS, BigQuery column-level security)
PII 관리: KMS 암호화, 마스킹, tokenization
Cost governance: 사용자별 쿼리 한도, workgroup 예산 알림

함정

[!WARNING] DW 를 운영 DB 로 쓰면 재앙. Row-level UPDATE/DELETE 가 느리고 비쌈. 트랜잭션 워크로드는 [[postgresql|Postgres]] 같은 OLTP 로.

[!CAUTION] INSERT 한 행씩 = MPP 의 최악의 워크로드. 항상 bulk load (COPY, [[apache-parquet|Parquet]] batch).

[!WARNING] 정규화 그대로 이식 = star schema 없이 3NF 를 DW 에 넣으면 join 지옥. Kimball 스타일로 denormalize.

[!IMPORTANT] schema-on-read 만 믿지 말 것. Data lake 에 원본만 넣고 스키마 안 잡으면 시간 지날수록 아무도 못 씀. Contract + validation 필수.

[!CAUTION] 비용 폭탄 3대 원인: SELECT *, 파티션 없는 스캔, 작은 파일 수천 개. [[aws-athena|Athena]] / [[aws-redshift-spectrum|Spectrum]] 은 스캔량 과금이라 특히.

[!WARNING] DW 는 단일 진실이 아니라 “합의된 진실” 이다. 소스 시스템의 semantics 를 명시적으로 문서화하지 않으면 지표가 팀마다 달라짐.

김신건의 로그 - 위키 / data-engineering

Apache Parquet

정의

왜 컬럼형인가

파일 구조

인코딩 (Encoding)

압축 (Compression Codec)

통계 (Statistics) & Predicate Pushdown

스키마 진화 (Schema Evolution)

논리 타입 (Logical Types, Parquet 2.x)

중첩 구조 (Nested Schema)

Row Group / Page 크기 결정

Parquet vs 다른 포맷

라이브러리

실전 예제

Python (pyarrow)

DuckDB (SQL 로 바로)

Spark / [[aws-glue|Glue]]

데이터 레이크에서의 파티셔닝 관용

Small Files Problem

함정

관련 위키

Athena 다중 포맷 쿼리: JSON, CSV, Parquet, Iceberg

정의

지원 파일 포맷 & SerDe 매핑

CSV / TSV 쿼리

기본 (LazySimpleSerDe)

인용부호 있는 CSV (OpenCSVSerDe)

JSON 쿼리

JSON 데이터 예 (line-delimited JSON, NDJSON)

기본 (Hive JsonSerDe)

OpenX JsonSerDe (더 유연)

중첩 필드 접근

JSON_EXTRACT (SerDe 없이 raw string)

Array UNNEST

중첩 ARRAY OF STRUCT

[[apache-parquet|Parquet]] 쿼리

기본

컬럼 프로젝션 + 파티션 프루닝

Parquet 중첩 필드

Apache Iceberg 쿼리

다중 포맷 조인 (같은 쿼리)

CTAS: 포맷 변환

INSERT INTO (증분 적재)

로그 파싱 (RegexSerDe)

파일 포맷 선택 가이드

스캔 비용 실제 (동일 데이터, 다른 포맷)

스키마 진화 다루기

함정

관련 위키

ETL / ELT

정의

3단계

1. Extract (추출)

2. Transform (변환)

3. Load (적재)

ETL vs ELT

언제 ETL 이 여전히 맞나

아키텍처 패턴

배치 파이프라인

스트리밍 파이프라인

Lambda / Kappa

CDC 파이프라인

Medallion Architecture (Bronze / Silver / Gold)

오케스트레이션 도구

변환 도구

dbt (data build tool)

Spark ([[aws-glue|Glue]], Databricks, EMR)

Pandas / [[pandas|pandas]] / Polars / DuckDB

데이터 계약 (Data Contracts)

Idempotency & Reprocessing

데이터 품질 (Data Quality)

관측성 (Data Observability)

AWS 에서의 ETL 구성

함정

관련 위키

Hadoop / Spark

정의

Hadoop 의 두 축

HDFS (Hadoop Distributed File System)