Fabric에서 Lakehouse와 Warehouse 중 어느 것을 선택할까?
발행: (2026년 2월 22일 오전 02:03 GMT+9)
14 분 소요
원문: Dev.to
I’m happy to translate the article for you, but I need the full text of the post. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the article text, I’ll translate it into Korean while preserving the original formatting, markdown, and technical terms.
핵심 개념
데이터 웨어하우스
다중 소스에서 정제되고, 통합된, 구조화된 데이터를 schema‑on‑write 방식으로 저장하고, SQL 분석 및 BI에 최적화된 중앙 집중식 저장소.
- 강력한 데이터 품질, 일관된 차원, 이력 추적 및 엄격한 거버넌스를 강조합니다.
- 일반적으로 ETL 또는 ELT 파이프라인을 사용하여 데이터를 로드하기 전에 변환합니다.
데이터 레이크하우스
데이터 레이크(객체 스토리지를 기반으로) 위에 웨어하우스와 유사한 기능—ACID 트랜잭션, 스키마 강제, 인덱싱, SQL 쿼리 성능—을 Delta, Iceberg, 또는 Hudi와 같은 오픈 테이블 포맷 위에 추가하는 아키텍처입니다.
- 하나의 플랫폼에서 구조화된, 반구조화된, 비구조화된 데이터를 지원합니다.
- 별도의 레이크 + 웨어하우스 스택 없이 BI와 AI/ML 워크로드를 모두 사용할 수 있게 합니다.
Architectural Differences
Storage & Schema
| Warehouse | Lakehouse | |
|---|---|---|
| Storage model | 관계형 구조(테이블, 컬럼, 인덱스)와 schema‑on‑write 방식. 데이터를 저장하기 전에 고정 스키마에 맞추어 변환합니다. | 객체 스토리지에 저장되는 오픈 포맷(예: Parquet + Delta/Iceberg/Hudi). schema‑on‑write와 schema‑on‑read 모두 지원합니다. |
| Ingestion | 일반적으로 이미 정제된 구조화 데이터를 로드합니다. | 원시 파일(CSV, JSON, 이미지, 로그 등)을 그대로 ingest하고 나중에 스키마/테이블 정의를 레이어링할 수 있습니다. |
Compute & Query Engine
| Warehouse | Lakehouse | |
|---|---|---|
| Engine | 분석 워크로드에 최적화된 tightly integrated SQL 엔진(컬럼형 스토리지, 벡터화 실행, 비용 기반 옵티마이저). | 동일한 데이터를 여러 엔진이 사용할 수 있음: Spark, 전용 SQL 엔진, ML 프레임워크, 스트리밍 엔진 등. |
| Access pattern | 단일 “데이터 웨어하우스 엔진” 진입점(클라우드에서 컴퓨트/스토리지가 논리적으로 분리돼 있더라도). | 동일한 Delta/Iceberg 테이블을 BI 도구 및 ML·스트리밍 파이프라인에서 직접 사용할 수 있습니다. |
Data Types & Workloads
| Warehouse | Lakehouse | |
|---|---|---|
| Primary data | OLTP 시스템, ERP/CRM 등에서 나오는 구조화된 관계형 데이터. | 구조화 데이터, 반구조화 데이터(JSON, 로그) 및 비구조화 데이터(이미지, 오디오, 문서). |
| Typical workloads | BI, 대시보드, 규제·재무 보고, ad‑hoc SQL 분석. | 혼합 워크로드: BI, 데이터 사이언스, ML 피처 엔지니어링, 실시간·스트리밍, 고급 분석. |
Governance & Reliability
| Warehouse | Lakehouse | |
|---|---|---|
| Governance | RBAC, 고정 스키마, 데이터 품질 규칙, 라인지를 플랫폼에 내장한 강력하고 중앙집중식 거버넌스. | 트랜잭션 테이블 포맷(예: Delta)을 사용해 ACID 보장 및 타임 트래블을 레이크 데이터에 적용. 거버넌스는 원시 레이크보다 풍부하지만 전통적인 웨어하우스보다 복잡합니다. |
| Reliability | ACID 트랜잭션과 엄격한 제약 조건이 표준—재무·규제 보고에 이상적. | 테이블 포맷을 통한 ACID 보장; 신뢰성은 카탈로그, 메타데이터 서비스, 거버넌스 툴의 적절한 구성에 따라 달라집니다. |
Performance & Cost
| Warehouse | Lakehouse | |
|---|---|---|
| Performance | 스타/스노우플레이크 스키마, 집계, 조인에 최적화돼 있어 BI에 매우 예측 가능함. | 저렴한 객체 스토리지와 분리된 컴퓨트를 활용. 쿼리 성능이 뛰어날 수 있지만 파티셔닝, Z‑ordering, 캐싱 등 세심한 튜닝이 필요할 수 있음. |
| Cost model | 구조화된 스토리지와 사전 ETL/ELT 때문에 TB당 비용이 더 높음하지만 순수 BI 워크로드에서는 총 비용이 낮을 수 있음. | 스토리지는 저렴하고 페타바이트 규모에서도 비용 효율적; 컴퓨트는 별도로 필요에 따라 확장 가능. 운영 비용은 최적화를 위한 엔지니어링 노력으로 이동함. |
Comparison Table
| Aspect | Warehouse | Lakehouse |
|---|---|---|
| Primary data types | 구조화된 | 구조화된 + 반구조화된 + 비구조화된 |
| Schema strategy | 쓰기 시 스키마 | 쓰기 시 스키마와 읽기 시 스키마 혼합 |
| Storage | 관계형 DW 엔진 | 객체 스토리지의 오픈 포맷 (Delta/Iceberg/Hudi) |
| Workloads | BI, 보고, SQL 분석 | BI + ML/AI + 스트리밍 + 탐색 |
| Governance | 강력하고 중앙집중적이며 경직된 | 강력하지만 더 복잡함; 신중한 설계 필요 |
| Performance | SQL/스타 스키마에 매우 강함 | 강력하지만 더 많은 튜닝 필요; 멀티 엔진 |
| Cost model | TB당 비용이 높음; ETL 비용 | 스토리지는 저렴하고; 유연한 ELT; 운영 비용 전환 |
| Team focus | BI 개발자, SQL, 데이터 모델링 | 데이터 엔지니어, ML, 혼합 SQL + Spark/ML 스킬 |
실무에서의 장단점
데이터 웨어하우스 – 강점과 약점
강점
- 특히 정규화된 차원과 일관된 메트릭을 갖춘 엔터프라이즈 BI 및 보고에 매우 강력한 지원.
- 예측 가능한 쿼리 성능 및 SLA 제공, 경영진 및 운영 대시보드에 이상적.
- 거버넌스, 라인리지, 보안, 그리고 변경 관리에 대한 성숙한 도구 제공.
약점
- 대용량 원시/반구조화 데이터(예: IoT 로그, 클릭스트림 등)에는 적합하지 않음.
- ETL/ELT 파이프라인이 사전 모델링을 많이 수행해야 하므로 새로운 소스 온보딩이 느려짐.
- 무거운 ML/AI 워크플로에 자연스럽게 맞지 않으며, 데이터를 다른 시스템으로 내보내야 하는 경우가 많음.
데이터 레이크하우스 – 강점과 약점
강점
- 단일 플랫폼에서 모든 데이터 유형 및 워크로드를 처리하여 레이크(데이터 사이언스용)와 웨어하우스(BI용) 사이의 중복을 감소.
- AI/ML 파이프라인 및 피처 엔지니어링을 BI에 사용되는 동일한 데이터에서 직접 지원.
- 원시 데이터와 정제된 데이터가 모두 저렴한 클라우드 객체 스토리지에 저장되므로 규모에 따라 비용 효율적.
약점
- 운영 복잡성: Spark, SQL 엔진, 카탈로그, 거버넌스 서비스 등 구성 요소가 많음.
- 전통적인 스타 스키마 BI에 대한 쿼리 성능은 특화된 웨어하우스보다 더 많은 튜닝이 필요할 수 있음.
- 특히 테이블 포맷, 파티셔닝, 거버넌스와 관련된 데이터 엔지니어링 및 플랫폼 역량이 더 요구됨.
언제 어떤 것을 선택할지
데이터 웨어하우스를 선호하는 경우
- 주요 워크로드가 구조화된 데이터에 대한 고전적인 BI 및 보고(ERP/CRM, 재무 시스템)인 경우.
- 규제 보고를 위해 예측 가능한 성능, 엄격한 SLA, 강력한 거버넌스가 필요할 때.
- 팀이 무거운 데이터 엔지니어링 파이프라인보다 SQL, 데이터 모델링, 대시보드 개발에 집중하고 있을 때.
레이크하우스를 선호하는 경우
- 단일 플랫폼에서 구조화된, 반구조화된, 비구조화된 데이터를 처리해야 할 때.
- 조직이 혼합 워크로드(BI, 데이터 사이언스, ML, 스트리밍)를 운영하며 공유 스토리지의 이점을 얻을 때.
- 페타바이트 규모의 비용 효율적인 스토리지와 유연한 ELT 파이프라인이 우선일 때.
- 테이블 포맷, 파티셔닝, 다중 엔진 거버넌스를 관리할 데이터 엔지니어링 전문성이 있거나 구축할 계획이 있을 때.
데이터 웨어하우스를 선호해야 할 때
- 안정적이고 잘 정의된 스키마(예: 재무, 인사, 회원 관리)와 예측 가능한 구조.
- 규제 또는 재무 통제로, 신뢰성이 높은, 신중하게 관리되고 천천히 변하는 스키마가 필요함.
- 팀이 주로 SQL / BI 중심이며, 실험적 유연성보다 안정적인 대시보드를 빠르게 제공하는 것이 더 중요함.
레이크하우스를 선호해야 할 때
- 다양한 데이터 유형(로그, 이벤트, 문서, 반구조화된 API 페이로드)을 관계형 데이터와 함께 관리해야 합니다.
- 데이터 과학, ML, 스트리밍 분석에 강력히 집중하고 있으며, BI도 포함됩니다.
- 플랫폼은 저장 비용을 낮게 유지하면서도 (멀티‑TB/PB) 매우 대용량으로 확장할 수 있어야 합니다.
하이브리드 / 통합 아키텍처
대부분의 최신 패턴은 하이브리드 접근법을 권장합니다:
- 레이크하우스(또는 레이크 + 레이크하우스)를 원시 및 정제 레이어와 ML/실험에 사용합니다.
- “단일 진실 원본” BI 및 규제 보고를 위해 정제된 웨어하우스(또는 웨어하우스와 유사한 골드 레이어)를 제공합니다.
레이크하우스는 종종 웨어하우스와 레이크 다음의 **“3세대”**로 묘사되며, 많은 장점을 결합하면서도 일부 시나리오에서는 특화된 웨어하우스를 위한 여지를 남깁니다.
Microsoft Fabric에서는 이 패턴이 레이크 중심 웨어하우스 모델로 나타납니다: 통합 Delta 스토리지, 원시/엔지니어링용 레이크하우스, BI‑준비 모델용 웨어하우스가 모두 하나의 플랫폼에 포함됩니다.