Lakehouse 서빙: Onehouse LakeBase vs Databricks Lakebase Postgres
Source: Dev.to
수년간, 레이크하우스는 스토리지와 분석을 통합했지만, 서빙은 통합하지 못했습니다.
전형적인 아키텍처는 다음과 같았습니다:
- Lakehouse → 분석 및 ETL
- Operational database → 저지연 애플리케이션
- Reverse ETL → 양쪽 사이에 선별된 서브셋 복사
인간이 쿼리를 수행하던 시절에는 이 분리가 잘 작동했습니다. AI 에이전트가 등장하면서 부하 프로파일이 바뀌었습니다. 이들은 반복적인 포인트 조회, 선택적 필터링, 반복 조인, 그리고 긴 추론 루프 안에서 병렬 쿼리를 수행합니다. 이러한 워크로드는 스캔 최적화 엔진과 전통적인 OLTP 시스템에 서로 다른 방식으로 스트레스를 줍니다.
Onehouse LakeBase: 오픈 테이블 위의 데이터베이스 프리미티브
LakeBase는 오픈 레이크하우스 테이블 위에 직접 구축된 저지연 서빙 레이어로 포지셔닝됩니다. 구체적으로는:
- Apache Hudi
- Apache Iceberg
스토리지는 여전히 객체 스토어 기반입니다. LakeBase가 도입하는 기능은 다음과 같습니다:
- 레코드‑레벨 및 보조 인덱싱
- 선택적 워크로드에 대해 비용을 O(K) 로 전환하는 인덱스 조인
- 테이블 커밋에 연결된 트랜잭션‑인식 분산 캐시
- 자동 확장 서빙 엔진 (Quanton‑기반 실행)
- 표준 연결성을 위한 PostgreSQL‑호환 엔드포인트
핵심 가정: 별도의 서빙 티어를 Reverse ETL로 유지하는 대신, 레이크하우스 자체에 데이터베이스‑스타일 메커니즘을 확장한다는 점입니다.
전통적인 분산 엔진(Spark/Trino 계열)은 스캔 및 셔플 패턴 때문에 조인을 O(N + M) 수준의 작업량으로 수행합니다. LakeBase의 인덱스 조인은 필터링된 작업 집합으로 비용을 낮추는 것을 목표로 합니다.
좁고 높은 선택성을 가진 쿼리에 대해 Onehouse가 보고한 바는 다음과 같습니다:
- 1 TB TPC‑DS 선택적 워크로드에서 약 95 % 지연 감소
- Databricks SQL Serverless 대비 약 6배 성능 향상 (좁은 쿼리 테스트)
- 고객 트레이스 재생에서 AWS Athena 대비 5–10배 개선
이는 벤더가 보고한 벤치마크이며 워크로드에 특화된 수치이지만, 설계 의도를 보여줍니다: 데이터를 복제하지 않고도 높은 동시성을 가진 서빙을 레이크하우스에서 가능하게 만든다는 점입니다.
Databricks Lakebase Postgres: 레이크하우스와 통합된 전용 OLTP
Databricks는 다른 접근 방식을 취합니다. Lakebase는 Databricks 플랫폼에 통합된 완전 관리형 PostgreSQL‑호환 OLTP 엔진입니다.
아키텍처적으로:
- 트랜잭션 워크로드는 전용 Postgres 엔진에서 실행
- 강력한 OLTP 의미론 및 격리 보장
- Unity Catalog와 긴밀히 통합
- OLTP와 레이크하우스 분석 간 연합 접근
Databricks는 Delta Lake를 기본으로 최적화되어 있으며, Iceberg와의 상호 운용성도 확대하고 있습니다. Lakebase Postgres는 레이크하우스 스토리지 레이어를 수정하지 않고, 이를 보완합니다.
여기서의 철학은 전문화입니다:
- OLTP 엔진 → 트랜잭션 지연에 최적화
- Lakehouse (Delta / Iceberg) → 분산 분석에 최적화
- 통합 제어 플레인 → 별도 실행 의미론
아키텍처 대비
두 접근 모두 깨지기 쉬운 Reverse ETL 파이프라인을 줄이는 것을 목표로 합니다. 차이는 데이터베이스 동작이 어디에 존재하느냐에 있습니다:
- Onehouse → 인덱싱, 캐싱, 서빙 의미론을 갖춘 오픈 레이크하우스 테이블(Hudi/Iceberg) 확장.
- Databricks → Delta‑네이티브 레이크하우스와 병행되는 전용 PostgreSQL 엔진 도입.
하나는 내부로 수렴하고, 다른 하나는 하나의 플랫폼 아래에서 전문 시스템을 조합합니다.
최종 정리
- 워크로드가 읽기‑중심이고, 선택도가 높으며, 레이크에 집중돼 있다면 인덱스‑우선 모델이 매력적입니다.
- 성숙한 트랜잭션 보장과 명시적인 워크로드 격리가 필요하다면 레이크하우스와 통합된 관리형 PostgreSQL 엔진이 구조적으로 더 깔끔할 수 있습니다.
진정한 변화는 포맷에 관한 것이 아니라, 서빙이 레이크하우스의 본질적인 속성이 되는가, 아니면 레이크하우스와 별개의 전문화된 동반자로 남는가에 관한 것입니다.