Databricks Lakehouse//RT: Reyden 엔진이 전용 실시간 DB를 대체하는 방법
요약
Databricks는 2026년 6월 16일 DAIS(Data + AI Summit 2026)에서 Lakehouse//RT를 발표했다. 기존 OLAP 쿼리 엔진(Photon)이 아닌 Reyden이라는 이름의 엔진으로 구동되며, Delta Lake·Apache Iceberg 테이블을 데이터 이동 없이 읽어 12,000 QPS에서 100ms 미만 응답을 제공한다. 측정 기준으로 기존 실시간 서빙 스택(StarRocks, ClickHouse, Druid, Redis 기반 솔루션) 대비 16배 높은 성능이다. 실시간 대시보드나 AI 에이전트 쿼리를 위해 별도의 OLTP 데이터베이스나 인메모리 캐시 레이어를 운영하던 아키텍처를 단일 Lakehouse로 통합하는 것이 목표다.
배경: Lakehouse의 실시간 서빙 공백
OLAP Lakehouse의 한계
Lakehouse 아키텍처는 Delta Lake나 Iceberg 같은 오픈 테이블 포맷 위에 ACID 트랜잭션과 분석 쿼리를 통합해 데이터 웨어하우스와 데이터 레이크의 장점을 결합했다. 그러나 지연 시간이 문제였다. Databricks의 Photon 엔진이나 Apache Spark 기반 실행 경로는 배치 처리와 수십 초 단위 쿼리에 최적화되어 있어, 10~100ms 수준의 응답이 필요한 워크로드에는 적합하지 않았다.
결과적으로 대부분의 조직은 Lakehouse 옆에 실시간 서빙 레이어를 따로 운영했다. Delta Lake가 원본 데이터를 보관하되, 이를 StarRocks나 ClickHouse로 동기화하거나 Redis로 집계 결과를 캐시하는 식이다. 이 구조는 데이터 복사 비용, 동기화 지연, 별도 클러스터 관리 부담을 낳는다.
실시간 서빙 레이어 운영의 실제 비용
별도 실시간 스택 운영에는 데이터 이동 파이프라인 관리 외에도 스키마 변경 전파, 중복 데이터 저장 비용, 백필 처리 복잡도가 포함된다. AI 에이전트와 BI 대시보드가 동시에 같은 테이블을 다른 지연 시간 요구사항으로 조회하는 상황에서는 두 시스템을 항상 동기 상태로 유지하는 것 자체가 운영 부담이 된다.
Databricks Lakehouse//RT 소개
Reyden 엔진
Lakehouse//RT의 핵심은 Reyden이라는 새 실행 엔진이다. Photon의 개선판이 아니라 실시간 저지연 쿼리를 목표로 처음부터 설계한 엔진으로, Databricks 공동창업자 Reynold Xin의 이름을 딴 "Reynold's Dream Engine"의 줄임말이다. Reynold Xin은 Apache Spark의 공동 제작자이기도 하다.
Reyden의 설계 원칙은 세 가지다.
- 오픈 포맷 네이티브: Delta Lake Parquet 파일과 Iceberg 데이터 파일을 클라우드 오브젝트 스토리지에서 직접 읽는다. 데이터를 별도 스토리지로 이동하거나 변환하지 않는다.
- 쿼리 경로 최적화: 칼럼 통계·파일 스킵·벡터화 실행을 포인트 쿼리와 소범위 스캔에 맞게 최적화했다. Photon이 대규모 배치를 기준으로 설계된 것과 대조적이다.
- Unity Catalog 통합: 모든 테이블 접근이 Unity Catalog를 통해 이루어지므로 거버넌스와 접근 제어를 별도로 구성할 필요가 없다.
쿼리 지연 시간의 구조
Lakehouse//RT가 낮은 지연 시간을 달성하는 이유는 쿼리 경로를 짧게 유지하는 데 있다. Delta Lake의 트랜잭션 로그(Delta Log)를 메모리에 캐시해 파일 탐색 비용을 제거하고, 칼럼별 통계를 활용해 불필요한 Parquet 파일 읽기를 건너뛴다. 네트워크 왕복이 많은 분산 셔플 단계를 포인트 쿼리에서 제거함으로써 소규모 데이터셋에서는 10ms 수준까지 낮출 수 있다.
아키텍처 다이어그램
기존 실시간 스택과의 성능 비교
Databricks가 공개한 벤치마크는 동일 Delta Lake 데이터를 각 실시간 스택에 적재한 뒤 QPS와 P99 지연 시간을 측정한 것이다.
| 스택 | 12,000 QPS P99 | 비고 |
|---|---|---|
| Lakehouse//RT (Reyden) | < 100ms | Delta/Iceberg 직접 읽기 |
| StarRocks | ~1,600ms | 별도 OLAP 스토리지 필요 |
| ClickHouse | ~1,400ms | 데이터 복사 필요 |
| Apache Druid | ~1,800ms | Segment 사전 변환 필요 |
| Redis 기반 집계 | ~80ms | 사전 계산된 결과만, SQL 불가 |
Redis 기반 솔루션은 지연 시간은 낮지만 SQL을 지원하지 않아 임의 쿼리(ad-hoc query)를 처리할 수 없다. Lakehouse//RT는 완전한 ANSI SQL로 10~100ms 응답을 제공한다는 점에서 Redis와 ClickHouse/StarRocks 사이의 공백을 채운다.
단, Lakehouse//RT의 벤치마크는 읽기 전용 워크로드를 기준으로 한다. 쓰기(INSERT/UPDATE/DELETE)는 Lakehouse//RT 서비스 범위 밖이며, 데이터는 기존 Databricks 파이프라인이나 DLT(Delta Live Tables)로 Delta Lake에 기록한다.
Unity Catalog 통합
Lakehouse//RT는 Unity Catalog 없이 사용할 수 없다. 모든 테이블 접근이 Unity Catalog를 통해 라우팅되므로 거버넌스 정책, 열 수준 마스킹, 행 필터가 실시간 쿼리 경로에도 자동으로 적용된다.
기존 Databricks 워크스페이스에서 Unity Catalog를 활성화한 상태라면 별도 데이터 마이그레이션 없이 Lakehouse//RT를 활성화할 수 있다. Unity Catalog가 없는 Hive 메타스토어 기반 워크스페이스는 우선 Unity Catalog로 마이그레이션해야 한다.
거버넌스 측면에서 이 통합의 의미는 크다. 기존에는 Delta Lake 원본과 ClickHouse 같은 실시간 사본 사이에 동일한 접근 제어 정책을 별도로 구성해야 했다. Lakehouse//RT를 쓰면 원본 Delta Lake 테이블의 Unity Catalog 정책이 실시간 쿼리에도 그대로 적용된다.
제약사항과 Beta 현황
2026년 7월 15일부터 Beta가 시작됐다. 현재 공개된 제약사항은 다음과 같다.
- 읽기 전용: ANSI SQL SELECT만 지원. DML(INSERT/UPDATE/DELETE)은 지원하지 않는다.
- Unity Catalog 필수: Hive 메타스토어 테이블 직접 접근 불가.
- Beta 기간 중 SLA 미보장: GA 전까지 응답 시간 보장치 없음.
- 지원 테이블 포맷: Delta Lake, Apache Iceberg. Hudi는 Beta 시점 기준 미지원.
- JOIN 복잡도 제한: 대형 조인이나 집계 쿼리는 Reyden의 단기 쿼리 최적화 경로 외부로 빠져 지연 시간이 늘어날 수 있음.
단기 포인트 쿼리와 소범위 스캔이 주요 워크로드일 때 성능이 가장 잘 나온다. 수십억 행을 전체 스캔하는 리포트 쿼리는 Lakehouse//RT보다 기존 Photon 엔진이 더 적합하다.
운영 체크리스트
Lakehouse//RT 도입을 검토할 때 확인해야 할 항목이다.
사전 조건
- Unity Catalog 활성화 여부 확인
- 대상 테이블이 Delta Lake 또는 Iceberg 포맷인지 확인
- 기존 Photon 워크로드와의 리소스 충돌 검토
데이터 신선도
- Lakehouse//RT는 Delta Log를 메모리 캐시하므로 쓰기 커밋 후 수초 내 신선한 데이터를 반영한다. 그러나 정확한 캐시 무효화 주기는 Beta 문서에서 확인할 것.
비용 구조
- Lakehouse//RT는 별도 DBU(Databricks Unit) 과금 모델. 기존 Photon 클러스터와 별개로 Lakehouse//RT 엔드포인트를 프로비저닝해야 한다.
실시간 서빙 레이어 제거 시퀀스
- Lakehouse//RT를 병렬로 활성화하고 기존 스택과 결과 비교
- 지연 시간·QPS 요건 충족 확인
- 애플리케이션 쿼리 엔드포인트를 Lakehouse//RT로 전환
- 기존 실시간 스택 데이터 파이프라인 중단
- 기존 스택 폐기
요점 정리
- Reyden은 Photon과 독립된 엔진으로, 저지연 포인트 쿼리·소범위 스캔에 특화됐다.
- Delta Lake와 Iceberg를 클라우드 스토리지에서 직접 읽어 데이터 복사 비용이 없다.
- 12,000 QPS에서 P99 100ms 미만, 기존 실시간 스택 대비 16배 성능.
- Unity Catalog 필수이므로 거버넌스 정책이 실시간 쿼리에도 자동 적용된다.
- 2026년 7월 Beta, 읽기 전용이며 GA 전 SLA 미보장.
- 대형 전체 스캔 쿼리는 여전히 Photon이 더 적합하다.
References
- https://www.databricks.com/blog/announcing-databricks-lakehourst-beta
- https://www.databricks.com/dataaisummit/2026
- https://delta.io/
- https://iceberg.apache.org/
- https://docs.databricks.com/aws/en/delta/index.html
- https://docs.databricks.com/aws/en/data-governance/unity-catalog/index.html