[DATA-009][중급] 데이터 창고·호수·레이크하우스 구분하기
페이지 정보
본문
[이번 수업]
데이터가 늘면 파일을 모으는 것만으로는 품질과 권한을 관리하기 어렵습니다. 데이터 웨어하우스, 데이터 레이크, 레이크하우스가 무엇을 저장하고 어떻게 관리하는지 비교합니다. 세 구조는 목적과 운영 조건에 맞춰 선택합니다.
[선수지식]
DATA-002의 파일 형식과 스키마, DATA-004의 SQL, DATA-008의 ETL·ELT 흐름을 먼저 익히면 좋습니다. Python 3도 사용합니다.
[학습목표]
1. 세 구조의 데이터 상태와 읽는 방식을 비교합니다.
2. 파일 형식과 테이블 형식의 역할을 구분합니다.
3. 원시 데이터와 분석용 데이터를 분리합니다.
[핵심개념]
데이터 웨어하우스는 여러 원천의 데이터를 정리하고 열 이름과 자료형을 맞춘 분석용 테이블로 저장합니다. 보통 쓰기 전에 스키마를 적용하는 스키마 온 라이트 방식을 쓰며, 반복되는 SQL 보고서와 지표 계산에 알맞습니다.
데이터 레이크는 CSV, JSON, 이미지, 로그처럼 모양이 다른 원시 데이터와 중간 결과를 파일 중심으로 보관합니다. 읽을 때 스키마를 적용하는 스키마 온 리드가 가능해 유연합니다. 그러나 소유자, 버전, 품질, 보관 기간이 없으면 믿을 파일을 찾기 어렵습니다.
레이크하우스는 레이크의 파일 저장 위에 테이블 메타데이터와 관리 기능을 더합니다. 열 지향 파일 형식은 필요한 열을 골라 읽고 압축하기 좋습니다. 테이블 형식은 파일 목록, 스키마, 파티션, 스냅샷을 관리합니다. 원자적 커밋, 동시 쓰기, 스키마 변경의 보장 범위는 구현마다 다르므로 실제 명세를 확인해야 합니다.
선택할 때는 데이터 종류, 쿼리 속도, 갱신 방식, 권한, 복구 목표와 운영 인력을 봅니다. 원시·정제 영역을 나누고 지표가 만들어진 경로인 데이터 계보를 남기는 원칙은 어느 구조에서도 중요합니다.
[따라하기]
아래를 storage_layers.py로 저장합니다. 원시 주문은 CSV에, 분석용 주문은 내장 데이터베이스 테이블에 넣습니다. 다시 실행해도 같은 주문 ID는 갱신됩니다.
```python
from pathlib import Path
import sqlite3
rows = [
{"id": "A-1", "amount": 12000},
{"id": "A-2", "amount": 18000},
]
raw = Path("data_lake/raw/orders.csv")
raw.parent.mkdir(parents=True, exist_ok=True)
raw.write_text(
"id,amount\nA-1,12000\nA-2,18000\n", encoding="utf-8"
)
db = sqlite3.connect("warehouse.db")
with db:
db.execute(
"CREATE TABLE IF NOT EXISTS orders "
"(id TEXT PRIMARY KEY, amount INTEGER)"
)
db.executemany(
"INSERT OR REPLACE INTO orders VALUES(:id, :amount)", rows
)
count, total = db.execute(
"SELECT COUNT(*), SUM(amount) FROM orders"
).fetchone()
db.close()
print("원시 파일:", raw.as_posix())
print("분석 행 수:", count)
print("매출 합계:", total)
```
macOS와 Linux에서는 `python3 storage_layers.py`, Windows PowerShell에서는 `py storage_layers.py`를 실행합니다. 예상 결과입니다.
```text
원시 파일: data_lake/raw/orders.csv
분석 행 수: 2
매출 합계: 30000
```
CSV 폴더는 레이크의 원시 영역, 데이터베이스 테이블은 웨어하우스의 정제 영역을 작게 흉내 냅니다. 테이블 형식과 트랜잭션 메타데이터가 없으므로 레이크하우스는 아닙니다.
[흔한 실수]
레이크를 규칙 없는 파일 투기장으로 만들거나 원시 파일을 덮어써 재처리 근거를 잃기 쉽습니다. 복사본 중 기준 테이블을 정하지 않는 문제도 있습니다. 작은 파일이 너무 많으면 읽기 비용이 커지므로 파일 크기와 파티션을 실제 쿼리로 점검합니다.
[보안 주의]
원시 파일은 신뢰하지 말고 허용된 열, 자료형, 크기를 검사합니다. 원시·정제·보고 영역의 권한을 분리하고 최소 권한을 적용합니다. 개인정보는 필요한 항목만 수집하며 암호화, 마스킹, 보관 기간, 삭제와 접근 기록을 관리합니다. 실습에는 실제 개인정보를 넣지 않습니다.
[직접 해볼 과제]
금액이 `unknown`인 주문을 추가하세요. 잘못된 행은 격리하고 정상 행만 테이블에 넣은 뒤 거부 건수를 출력합니다.
[확인문제]
1. 웨어하우스와 레이크는 스키마를 적용하는 시점이 어떻게 다른가요?
2. 파일 형식과 테이블 형식은 각각 어떤 문제를 해결하나요?
3. 레이크하우스라는 이름만으로 동시 쓰기 안전성을 판단하면 안 되는 이유는 무엇인가요?
[다음 학습]
SWE-009에서는 성능 최적화를 배웁니다. 다음 DATA 수업은 배치·스트리밍·이벤트 처리입니다.
[공식 참고 자료]
- NIST 빅데이터 참조 아키텍처: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1500-6r2.pdf
- NIST 빅데이터 보안·개인정보 지침: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1500-4r2.pdf
- 레이크하우스 원 논문: https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf
- 열 지향 파일 형식 공식 문서: https://parquet.apache.org/docs/overview/motivation/
- 열린 테이블 형식 공식 명세: https://iceberg.apache.org/spec/
- Python sqlite3 공식 문서: https://docs.python.org/3/library/sqlite3.html
데이터가 늘면 파일을 모으는 것만으로는 품질과 권한을 관리하기 어렵습니다. 데이터 웨어하우스, 데이터 레이크, 레이크하우스가 무엇을 저장하고 어떻게 관리하는지 비교합니다. 세 구조는 목적과 운영 조건에 맞춰 선택합니다.
[선수지식]
DATA-002의 파일 형식과 스키마, DATA-004의 SQL, DATA-008의 ETL·ELT 흐름을 먼저 익히면 좋습니다. Python 3도 사용합니다.
[학습목표]
1. 세 구조의 데이터 상태와 읽는 방식을 비교합니다.
2. 파일 형식과 테이블 형식의 역할을 구분합니다.
3. 원시 데이터와 분석용 데이터를 분리합니다.
[핵심개념]
데이터 웨어하우스는 여러 원천의 데이터를 정리하고 열 이름과 자료형을 맞춘 분석용 테이블로 저장합니다. 보통 쓰기 전에 스키마를 적용하는 스키마 온 라이트 방식을 쓰며, 반복되는 SQL 보고서와 지표 계산에 알맞습니다.
데이터 레이크는 CSV, JSON, 이미지, 로그처럼 모양이 다른 원시 데이터와 중간 결과를 파일 중심으로 보관합니다. 읽을 때 스키마를 적용하는 스키마 온 리드가 가능해 유연합니다. 그러나 소유자, 버전, 품질, 보관 기간이 없으면 믿을 파일을 찾기 어렵습니다.
레이크하우스는 레이크의 파일 저장 위에 테이블 메타데이터와 관리 기능을 더합니다. 열 지향 파일 형식은 필요한 열을 골라 읽고 압축하기 좋습니다. 테이블 형식은 파일 목록, 스키마, 파티션, 스냅샷을 관리합니다. 원자적 커밋, 동시 쓰기, 스키마 변경의 보장 범위는 구현마다 다르므로 실제 명세를 확인해야 합니다.
선택할 때는 데이터 종류, 쿼리 속도, 갱신 방식, 권한, 복구 목표와 운영 인력을 봅니다. 원시·정제 영역을 나누고 지표가 만들어진 경로인 데이터 계보를 남기는 원칙은 어느 구조에서도 중요합니다.
[따라하기]
아래를 storage_layers.py로 저장합니다. 원시 주문은 CSV에, 분석용 주문은 내장 데이터베이스 테이블에 넣습니다. 다시 실행해도 같은 주문 ID는 갱신됩니다.
```python
from pathlib import Path
import sqlite3
rows = [
{"id": "A-1", "amount": 12000},
{"id": "A-2", "amount": 18000},
]
raw = Path("data_lake/raw/orders.csv")
raw.parent.mkdir(parents=True, exist_ok=True)
raw.write_text(
"id,amount\nA-1,12000\nA-2,18000\n", encoding="utf-8"
)
db = sqlite3.connect("warehouse.db")
with db:
db.execute(
"CREATE TABLE IF NOT EXISTS orders "
"(id TEXT PRIMARY KEY, amount INTEGER)"
)
db.executemany(
"INSERT OR REPLACE INTO orders VALUES(:id, :amount)", rows
)
count, total = db.execute(
"SELECT COUNT(*), SUM(amount) FROM orders"
).fetchone()
db.close()
print("원시 파일:", raw.as_posix())
print("분석 행 수:", count)
print("매출 합계:", total)
```
macOS와 Linux에서는 `python3 storage_layers.py`, Windows PowerShell에서는 `py storage_layers.py`를 실행합니다. 예상 결과입니다.
```text
원시 파일: data_lake/raw/orders.csv
분석 행 수: 2
매출 합계: 30000
```
CSV 폴더는 레이크의 원시 영역, 데이터베이스 테이블은 웨어하우스의 정제 영역을 작게 흉내 냅니다. 테이블 형식과 트랜잭션 메타데이터가 없으므로 레이크하우스는 아닙니다.
[흔한 실수]
레이크를 규칙 없는 파일 투기장으로 만들거나 원시 파일을 덮어써 재처리 근거를 잃기 쉽습니다. 복사본 중 기준 테이블을 정하지 않는 문제도 있습니다. 작은 파일이 너무 많으면 읽기 비용이 커지므로 파일 크기와 파티션을 실제 쿼리로 점검합니다.
[보안 주의]
원시 파일은 신뢰하지 말고 허용된 열, 자료형, 크기를 검사합니다. 원시·정제·보고 영역의 권한을 분리하고 최소 권한을 적용합니다. 개인정보는 필요한 항목만 수집하며 암호화, 마스킹, 보관 기간, 삭제와 접근 기록을 관리합니다. 실습에는 실제 개인정보를 넣지 않습니다.
[직접 해볼 과제]
금액이 `unknown`인 주문을 추가하세요. 잘못된 행은 격리하고 정상 행만 테이블에 넣은 뒤 거부 건수를 출력합니다.
[확인문제]
1. 웨어하우스와 레이크는 스키마를 적용하는 시점이 어떻게 다른가요?
2. 파일 형식과 테이블 형식은 각각 어떤 문제를 해결하나요?
3. 레이크하우스라는 이름만으로 동시 쓰기 안전성을 판단하면 안 되는 이유는 무엇인가요?
[다음 학습]
SWE-009에서는 성능 최적화를 배웁니다. 다음 DATA 수업은 배치·스트리밍·이벤트 처리입니다.
[공식 참고 자료]
- NIST 빅데이터 참조 아키텍처: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1500-6r2.pdf
- NIST 빅데이터 보안·개인정보 지침: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1500-4r2.pdf
- 레이크하우스 원 논문: https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf
- 열 지향 파일 형식 공식 문서: https://parquet.apache.org/docs/overview/motivation/
- 열린 테이블 형식 공식 명세: https://iceberg.apache.org/spec/
- Python sqlite3 공식 문서: https://docs.python.org/3/library/sqlite3.html
- 이전글[SWE-009][중급] 느린 코드를 측정하고 빠르게 고치기 26.09.04
- 다음글[AI-009][중급] 문서를 찾아 근거 있는 답변 만들기 26.09.04
댓글목록
등록된 댓글이 없습니다.