실시간 분석에는 늘 두 번째 시스템이 있었다
레이크하우스는 분석에 강합니다. 하지만 "밀리초 안에 답해야 하는" 질의에는 약했습니다.
그래서 실시간 대시보드나 사용자 앞에 숫자를 보여 주는 화면이 필요하면, 보통 두 번째 시스템을 붙였습니다. 레이크의 데이터를 빠른 서빙 데이터베이스로 복사하고, CDC로 동기화하는 구조입니다. 시스템이 둘이니 비용도 둘, 권한 관리도 둘이고, 동기화가 어긋나면 숫자도 둘이 됩니다.
Lakehouse//RT는 이 두 번째 시스템을 없애겠다는 발표입니다.
무엇을 발표했나
보도자료는 Lakehouse//RT를 레이크하우스의 실시간 진화라고 소개합니다. 통제되는 Delta Lake와 Apache Iceberg 데이터 위에서 별도의 서빙 시스템 없이 낮은 지연의 분석을 돌립니다.
보도자료가 없어도 된다고 나열한 것이 실무자에게는 가장 와닿습니다.
- 독점 형식
- 데이터 복사본
- 수집 파이프라인
- 동기화·CDC 파이프라인
모든 질의는 Unity Catalog 통제 아래에서 돌아갑니다.
Reyden 엔진
바탕은 새 컴퓨트 엔진 Reyden입니다. 에이전트가 많은 기업의 동시성과 지연 요구에 맞춰 만들었고, 완전 비동기 실행 모델을 씁니다.
비동기 실행이라는 점이 중요해 보입니다. 동시 사용자가 수만 명이면, 질의 하나가 디스크나 네트워크를 기다리는 동안 스레드를 붙잡고 있으면 금방 자원이 바닥납니다. 기다리는 동안 다른 질의를 처리하는 구조여야 그 규모를 감당합니다. 보도자료는 수만 명의 동시 사용자와 에이전트를 지원하도록 설계했다고 밝힙니다.
숫자를 조건과 함께
보도자료의 성능 수치는 셋이고, 조건이 모두 다릅니다.
| 수치 | 조건 |
|---|---|
| 응답 최저 10ms | 작은 데이터셋 |
| 12,000 QPS에서 100ms 미만 | 표준 분석 벤치마크(운영 워크로드 아님) |
| 최대 16배 성능 | 고객이 기존 실시간 서빙 스택과 비교해 보고한 수치 |
10ms는 작은 데이터에서 나온 최저값입니다. 큰 데이터에서의 지연은 보도자료 안에서도 "100ms 미만"과 "100ms"로 표현이 갈립니다. 12,000 QPS는 벤치마크 결과이고, 16배는 통제된 비교가 아니라 고객 보고입니다.
이렇게 나눠 보면 메시지가 더 정확해집니다. "레이크하우스 위에서도 전용 서빙 시스템에 견줄 만한 영역에 들어왔다" 정도입니다.
고객의 목소리
- Cisco: 위협 조회에서 실시간 데이터에 대해 밀리초 성능, 응답 시간 5배 개선
- Magnite: 핵심 대시보드 질의에서 꾸준히 200ms 미만, 데이터는 자사 데이터 레이크에서 통제된 채로
Magnite의 인용에서 중요한 건 숫자보다 뒷부분입니다. 데이터를 자기 레이크에 둔 채로 이 성능을 얻었다는 점입니다. 복사본을 만들지 않았다는 뜻입니다.
왜 지금인가
Ghodsi는 Lakehouse//RT가 에이전트에게 필요한 밀리초 계층을 채워 엔진 스펙트럼을 완성한다고 말했습니다.
사람은 대시보드를 하루 몇 번 엽니다. 에이전트는 질문 하나에 질의를 수십 번 던집니다. 에이전트가 늘어나면 분석 시스템에 오는 질의의 성격이 바뀝니다. 적고 무거운 질의에서, 많고 가벼운 질의로요. Build 2026의 GPU 웨어하우스 발표가 동시 사용자 64명 조건을 강조한 것도 같은 맥락입니다.
함께 읽을 개념 정리
- CDC(변경 데이터 캡처)를 한 장으로: "CDC 파이프라인이 필요 없다"는 말이 무엇을 없앤다는 뜻인지
영상으로 더 보기
Lakehouse//RT 발표가 포함된 첫날 기조연설 전체 영상입니다.
정리하며
발표 당시 Lakehouse//RT는 베타였습니다. 운영 서비스의 화면을 바로 옮기기에는 이릅니다.
시험해 본다면, 지금 서빙 DB로 복사해 쓰는 테이블 중 하나를 골라 같은 질의를 레이크에서 직접 돌려 보는 게 좋겠습니다. 실제 데이터와 실제 동시성에서 지연이 얼마나 나오는지가, 보도자료의 어떤 숫자보다 정확한 답을 줄 겁니다.
