728x90
반응형
0️⃣ 목적 정의 (제일 중요)
- [ ] 이 DW/DM으로 누가 무엇을 보나?
- 분석가 / PM / 임원?
- [ ] 주 용도는?
- 대시보드 / 리포트 / ML 피처?
- [ ] 질문 형태가 뭐냐?
- “일별 매출”, “유저 리텐션”, “지역별 추이”
👉 이게 없으면 구조가 흔들림
1️⃣ 데이터 소스 정리 (Ingest)
- [ ] 데이터 출처 목록화
- CSV / API / DB / 로그
- [ ] 주기
- 배치 / 준실시간
- [ ] 스키마 변동 가능성 있음?
👉 소스 단위로 책임 분리
2️⃣ Raw (Bronze) 체크리스트
원본 보존 영역
- [ ] 원본 그대로 저장했는가?
- [ ] 재처리(backfill) 가능?
- [ ] append-only 구조?
- [ ] 포맷
- CSV → Parquet 변환?
- [ ] 저장 위치 명확?
- raw/yyyymmdd/
👉 Raw에서는 비즈니스 로직 ❌
3️⃣ 타입 & 기본 정합성 (Silver 초입)
- [ ] 타입 캐스팅 명확?
- string → int / timestamp
- [ ] 컬럼명 표준화?
- snake_case
- [ ] timezone 정리?
- [ ] primary key 후보 정의?
👉 여기까지가 DW Core의 뼈대
4️⃣ 데이터 품질 (DW 핵심)
- [ ] null 허용 컬럼 vs 필수 컬럼 구분
- [ ] 중복 기준 정의
- [ ] 값 범위 체크 (음수, 이상치)
- [ ] 품질 실패 시 파이프라인 중단?
(도구)
- [ ] dbt test
- [ ] GE (선택)
👉 DW = 신뢰성
5️⃣ DW 모델링 (Silver)
- [ ] 테이블 grain 정의
- “한 row가 뭘 의미하나?”
- [ ] 엔티티 기준 통합
- customer, product, order
- [ ] 조인 키 명확?
- [ ] 정규화/반정규화 기준 합의?
👉 이 단계가 Inmon 감성
6️⃣ DM 설계 (Gold)
여기서부터 Kimball
Fact
- [ ] fact 테이블 grain 명확?
- [ ] 측정값(measure)만 있음?
- [ ] surrogate key 필요?
Dimension
- [ ] dimension 재사용 가능?
- [ ] SCD 타입 정의?
- [ ] 의미가 명확한 컬럼명?
👉 DM = 바로 써먹는 테이블
7️⃣ 성능 & 비용
- [ ] 파티션 기준 적절?
- 날짜?
- [ ] 클러스터링 키?
- [ ] external vs native 구분?
- [ ] incremental 전략?
👉 느리면 안 쓰임
8️⃣ 서빙 & 사용성
- [ ] BI 연결 테스트
- [ ] SQL 안 짜도 이해 가능한가?
- [ ] 컬럼 설명(doc) 있음?
- [ ] deprecated 테이블 표시?
👉 사용자 관점 필수
9️⃣ 운영 관점 (면접에서 점수 오름)
- [ ] 실패 시 알림?
- [ ] 재처리 전략?
- [ ] 스키마 변경 대응?
- [ ] lineage 추적 가능?
🔟 한 문장 요약 (면접용)
“Raw 데이터를 보존하고,
Silver에서 정제·통합된 DW를 구축한 뒤,
Gold에서 분석 목적별 DM을 설계했습니다.
각 레이어는 품질·성능·책임 기준으로 분리했습니다.”
🧠 이 체크리스트의 핵심
👉 DW/DM 구축 =테이블 만드는 게 아니라‘질문에 안정적으로 답하는 구조’를 만드는 것
728x90
반응형
'DataEngineering > Architecture' 카테고리의 다른 글
| 📦 Partition & 🧲 Clustering 정리 (0) | 2026.01.30 |
|---|---|
| Medallion Architecture 정리 (0) | 2026.01.30 |