Lakehouse 개요

Lakehouse는 Data Lake + Data Warehouse를 합친 개념이다.
ETL 과정이 복잡하고 느리고, 비용도 이중으로 들고 (저장비용 + DW비용) 데이터가 분산돼서 관리가 어려움이 있었다. Data Lake처럼 싸게 저장하고 Data Warehouse처럼 빠르고 정교하게 분석하는 게 목표다.

주요 특징

• 파일 포맷: Parquet, ORC 같은 컬럼 포맷을 기본으로 사용.
• 테이블 포맷: Iceberg, Delta Lake, Hudi 같은 "ACID 지원 테이블 메타데이터 관리" 레이어 추가.
• 쿼리 엔진: Spark, Trino, Presto, Flink 같은 툴이 S3 같은 스토리지에 직접 SQL 쿼리.
• 트랜잭션과 스키마 관리: 파일 단위로도 Insert/Update/Delete 가능.

🏳️‍🌈 [궁금한점]

• Lakehouse 가 무엇인가
• Iceberg와 Trino 조합이 상용 제품과 기능면에서 어떤 차이가 날까

목차

• Kubernetes + Spark 조합과 Lakehouse 차이
• Snowflake 예시
  • Kubernetes/Spark vs Snowflake 기능 비교
  • 주요 특징
  • Snowflake의 한계 및 불편한 점
  • Trino + Iceberg vs Snowflake 비교

Lakehouse 주요 제품

제품	특징
Databricks Delta Lake	거의 최초의 Lakehouse 구현, Spark 기반
Apache Iceberg	오픈소스, Trino/Flink/Spark 모두 연동 잘 됨
Apache Hudi	스트리밍 기반 데이터 업데이트에 강점
AWS Lake Formation	S3 + Glue 기반 Lakehouse

Kubernetes + Spark 조합과 Lakehouse 차이

Lakehouse는 "어떤 인프라로 구동하는가"가 아니라,
"어떻게 데이터 저장/관리/분석할까"에 대한 데이터 아키텍처 모델이다. Kubernetes + Spark는 "그걸 구현하는 수단" 중 하나이다.

구분	내용
Lakehouse	데이터 아키텍처 모델 (데이터 저장, 관리, 분석 방식)
Spark	데이터를 처리하는 엔진 (Lakehouse 데이터를 읽고/쓰는 데 사용)

Lakehouse를 만들기 위해 Spark를 쓸 수 있고, Spark를 Kubernetes에 올려서 운영할 수 있다. 그렇다고 Lakehouse = Kubernetes + Spark는 아니다.

Databricks Lakehouse는 Spark를 내부적으로 쓰지만, Kubernetes를 안 써도 된다 (자체 클러스터 매니저 사용).
Snowflake의 Native Lakehouse의 경우 아예 Spark도, Kubernetes도 직접 안 쓰고 전용 엔진을 사용한다.
AWS Athena + Iceberg 조합으로 Spark 없이 Trino 기반 쿼리하는 경우도 있다.

즉, 꼭 Kubernetes + Spark 조합이 아니어도 Lakehouse는 구현 가능하다.

Snowflake 예시

Snowflake는 "전체 플랫폼 자체" 를 완전히 통합해서 제공한다. 그래서 사용자가 Kubernetes나 Spark를 직접 관리할 필요가 없다.

대체 구조를 보면 이래:

Kubernetes/Spark vs Snowflake 기능 비교

역할	Kubernetes/Spark	Snowflake
컨테이너 오케스트레이션 (Kubernetes 역할)	Kubernetes (Pod 스케줄링, 리소스 관리)	Snowflake 자체 클러스터 매니저 (비공개, 자동 스케일링)
분산 데이터 처리 (Spark 역할)	Spark Executor/Driver	Snowflake MPP 엔진 (Massively Parallel Processing)
데이터 저장소 (HDFS 역할)	HDFS, S3 같은 외부 스토리지	내부 최적화된 Columnar Storage (가끔 외부 스테이지 연결도 가능)

주요 특징

• 자동 스케일 업/다운/아웃 (수평, 수직 모두)
• 워크로드 격리 (다른 유저 쿼리가 영향을 안 줌)
• 스토리지와 컴퓨트 분리 (필요할 때만 컴퓨트 비용)
• 트랜잭션 관리 (ACID) 기본 지원
• SQL로 통합 관리 (Spark처럼 복잡한 설정 없이)

Snowflake의 한계 및 불편한 점

항목	불편한 점
커스터마이징	내부 엔진이 블랙박스라 튜닝 불가. Spark처럼 executor 설정, shuffle 최적화 등을 못 함.
컨트롤 부족	리소스 관리나 스케줄링에 세세하게 개입할 수 없음 (Kubernetes처럼 직접 pod 크기 조정 불가).
비용	사용량이 늘어나면 생각보다 매우 비쌈. 특히 컴퓨트 비용은 요금 폭탄 맞기 쉽다.
특화 작업 어려움	Spark처럼 MLlib, GraphX 같은 ML/Graph 처리 기능이 거의 없음. 주로 SQL/BI 분석용.
벤더 Lock-in	완전한 SaaS라 Snowflake 시스템 안에 갇힘. 데이터 이동이나 마이그레이션 쉽지 않음.
특정 워크로드 부적합	초대형 ETL/ELT 배치 작업은 여전히 Spark가 유리한 경우도 있음.

Trino + Iceberg vs Snowflake 비교

항목	Trino + Iceberg	Snowflake
처리 성능 (쿼리 속도)	클러스터 크기에 따라 다름. 튜닝 잘 하면 Snowflake 못지 않음.	기본적으로 매우 빠름 (최적화된 엔진 + 자동 리소스 할당)
대용량 처리 (TB-PB급)	튜닝/스케일 아웃 잘 하면 가능. 하지만 복잡한 쿼리는 버벅일 수 있음.	매우 강함. 특히 조인/윈도우 함수 같은 복잡 쿼리에 강함.
레이턴시 (응답 시간)	워밍업 필요. 메타데이터 캐시 튜닝 안 하면 초기 쿼리 느림.	첫 쿼리부터 빠름 (자동 최적화 + 웜 스타트)
스케일링 (리소스 확장)	Kubernetes 기반이면 수평 확장 잘 됨. 하지만 수동 튜닝 필요.	완전 자동 스케일링. 사용자가 신경쓸 필요 없음.
비용 최적화	자기 맘대로 조정 가능 (EC2 spot instance, ARM 코어 사용 등)	Snowflake는 요금제 고정이라, 예상보다 많이 나올 수 있음.
ACID 보장	Iceberg 덕분에 Strong ACID 지원 (MERGE/UPDATE/DELETE 다 가능)	기본적으로 완벽한 트랜잭션 지원
복잡 쿼리 (CTE, JOIN, 서브쿼리)	잘 최적화하면 꽤 빠르지만, 리소스 부족하면 Out of Memory 잘 뜸.	복잡 쿼리 최적화 정말 잘 돼 있음. (Adaptive Query Processing 내장)
관리 편의성	설치/모니터링/스케일링 전부 직접 해야 함 (운영 부담 있음).	Snowflake는 그냥 쓰기만 하면 됨 (운영 고민 0)