호수 거래/분석 처리(LTAP)는 호수 내 통합 데이터 저장 계층에서 하나의 거버넌스 모델 하에 트랜잭션(OLTP)과 분석(OLAP) 작업을 모두 제공하는 데이터 아키텍처로, 별도의 트랜잭션 시스템과 분석 시스템을 동기화할 필요가 없습니다. 이 시스템은 전통적으로 팀이 운영 데이터를 별도의 분석 시스템으로 복사하기 위해 유지하던 변경 데이터 캡처(CDC), 복제, 변환 파이프라인을 제거합니다. Azure Databricks는 Lakebase 스토리지 아키텍처 위에 LTAP를 구축합니다. 공지 사항은 Databricks, 최초의 Lake Transactional/Analytical Processing 아키텍처인 LTAP 출시를 참조하세요.
LTAP는 단일 기능이 아니라 아키텍처입니다. Azure Databricks는 현재 개발 및 확장 중인 Lakebase 기능 세트를 통해 이를 제공합니다. 사용 가능한 기능은 클라우드에 따라 다릅니다. 이 페이지는 아키텍처를 설명합니다. 오늘날 클라우드에서 사용할 수 있는 기능에 대해서는 LTAP를 구현하는 능력(Capabilities who implement LTAP)을 참조하세요.
Important
이 페이지를 읽기 전에 Lakebase 아키텍처와 그 구성 요소들인 상태 없는 Postgres 컴퓨트, 세이프키퍼, 페이지서버, 클라우드 객체 저장소를 이해하기 위해 Lakebase 아키텍처 를 읽어보세요. LTAP는 Lakebase가 컴퓨트와 스토리지를 분리하는 방식을 직접 기반으로 하며, 이 페이지의 나머지 부분은 그 기반을 전제로 합니다.
두 스택을 동기화하는 데 드는 비용
애플리케이션은 데이터 작업을 두 가지 종류의 작업으로 나눕니다. 트랜잭션(OLTP) 워크로드는 한 번에 몇 개의 행에 대응하며, 결제 처리나 API 결과 반환 등 해당 행의 전체 내용을 빠르게 처리해야 합니다. 분석(OLAP) 워크로드는 대규모 데이터셋에서 인사이트를 찾으며, 종종 여러 행을 집계하고 연결하는 작업을 수행합니다. 예를 들어 매출 예측이나 사기 탐지 등이 있습니다. 이 패턴들은 반대 방향으로 작용합니다: OLTP는 개별 행에 대해 지속적인 저지연 읽기와 쓰기를 필요로 하는 반면, OLAP는 대량의 데이터를 스캔하고 집계해야 합니다. 수십 년 동안 답은 두 개의 별도 시스템이었습니다: 애플리케이션용 트랜잭션 데이터베이스와 분석을 위한 데이터 웨어하우스 또는 레이크하우스.
이 두 스택을 연결하는 것이 비용이 많이 듭니다. 동기화를 유지하려면 변경 데이터 캡처(CDC), 스트리밍 파이프라인, 그리고 한 시스템에서 다른 시스템으로 데이터를 복사하는 데만 역할을 하는 리드 복제본을 실행해야 합니다. 그 인프라는 취약하고, 데이터가 작성된 시점과 분석이 가능한 시점 사이에 지연이 발생하며, 주요 트랜잭션 데이터베이스와 자원 경쟁을 벌입니다. 애플리케이션과 AI 에이전트가 최신 거래 데이터에 대한 분석을 점점 더 필요로 함에 따라, 이 격차는 팀의 진행을 지연시킵니다. 두 시스템 간 데이터 복사는 거버넌스 위험도 초래합니다: 데이터가 이동하면서 혈통이 끊길 수 있어 GDPR 삭제 요청과 같은 의무 이행이 더 어려워집니다.
LTAP가 스토리지 계층에서 데이터를 통합하는 방법
두 스택 간에 더 나은 파이프라인을 구축하는 대신, LTAP는 파이프라인의 필요성을 완전히 없애줍니다. 저장 계층부터 데이터베이스를 근본적으로 재구성함으로써 이를 실현합니다.
Lakebase는 이미 상태 없는 Postgres 컴퓨팅을 내구성 있는 저장 계층인 세이프키퍼, 페이지서버, 클라우드 객체 저장소와 분리하고 있습니다. 트랜잭션은 세이프키퍼 정족수가 작성 기록을 지속 가능하게 기록하면 커밋되며, 페이지서버는 그 변경 사항을 비동기적으로 클라우드 객체 저장소로 구현하여 데이터가 더 이상 단일 데이터베이스 엔진에 갇혀 있지 않게 됩니다.
참고
Lakebase가 컴퓨팅과 스토리지를 어떻게 분리하는지에 대해서는 Lakebase 아키텍처를 참조하세요.
LTAP는 그 저장 계층에 한 단계를 추가합니다. Lakebase 저장소가 데이터를 객체 저장소로 물질화할 때, 행 지향의 Postgres 데이터를 호수에 도착할 때 Parquet의 열형 레이아웃으로 트랜스코딩하며, Delta나 Iceberg와 같은 오픈 테이블 형식으로 읽을 수 있습니다. 이 트랜스코딩 덕분에 단일 데이터 복사본이 OLTP와 OLAP 작업 부하를 모두 처리할 수 있습니다. Postgres 원본을 충실하고 효율적으로 표현하는 열 지향 복사본이 되도록 설계되었습니다:
- 의미는 보존됩니다. Lakebase 저장소는 모든 값을 열형 형태로 트랜스코딩하되 원본 Postgres 표현을 유지하여, Postgres 호환 엔진이 정보를 잃지 않고 데이터를 재해석할 수 있습니다. Parquet에 깔끔하게 매핑되지 않는 타입(예:
NaN, 오버NUMERIC플로우)이나 벡터, 배열, 지오그래피, JSON 같은 확장 타입은 정형적인 Postgres 표현을 포함하는 오버플로우 필드에 보존됩니다. - 행 버전은 보존됩니다. 트랜스코딩은 중간 행 버전을 유지하므로, 열형 복사본은 행 데이터와 동일한 버전 정보를 담고 있습니다.
- 컬럼형 데이터는 잘 압축됩니다. 열형 레이아웃은 매우 압축되어 저장 공간 사용량과 객체 저장소로 이동하는 데이터 양을 줄입니다.
트랜스코딩은 전적으로 스토리지 계층에서 실행되며, 기본 Postgres 인스턴스와는 격리되어 있어 트랜잭션 서빙 작업에 영향을 주지 않습니다. 이는 Lakebase가 이미 하고 있는 것을 기반으로 합니다: 커밋된 데이터를 클라우드 객체 저장소로 플러시하는 기능입니다. LTAP는 단순히 같은 플러시에 컬럼 포맷을 추가하는 것입니다. 파이프라인을 구축할 필요도 없고, 외부 프로세스가 데이터베이스를 폴링하는 것도 없습니다.
모든 것이 트랜스코딩된 것은 아닙니다. Postgres 인덱스는 열로 변환되지 않고 내구성 저장 계층에서 원래 표현된 상태로 유지되므로, 트랜잭션 포인트 읽기와 조회가 빠르게 진행되고, 열형 복사본은 분석을 담당합니다.
데이터가 외부화된 버전 관리 저장소에 저장되기 때문에, 분기를 생성하거나 특정 시점으로 복원하는 것은 물리적 복사본이 아니라 메타데이터 작업입니다. 대규모 생산 데이터베이스를 몇 초 만에 분기하고, 실험이나 위험한 마이그레이션을 실행한 뒤 폐기할 수 있으며, 기본 데이터를 중복하지 않고도 가능합니다.
참고
Lakebase 브랜치는 데이터베이스 저장소의 쓰기 시 복사 복제 방식으로, 부모 데이터베이스의 기존 데이터를 공유하고 변경된 부분만 저장하여 처음부터 데이터가 중복되지 않습니다. 시점 복원은 동일한 버전화된 저장소를 사용하여 복원 창 내 이전 시점으로 데이터베이스를 반환합니다. 자세한 내용은 데이터베이스 브랜치 및 시점 복원을 참조하세요.
이러한 스토리지 수준 접근법이 LTAP을 변경 데이터 캡처(CDC)와 차별화하는 요소입니다. CDC는 외부 프로세스를 통해 OLTP 저장소에서 데이터를 별도의 분석 계층으로 복제하며, 이 프로세스는 주 데이터베이스를 지속적으로 폴링하고, 행 변경 사항을 열식 데이터로 변환하는 파이프라인을 사용합니다. 이 파이프라인은 주 트랜잭션 데이터베이스의 자원을 소모하고, 스키마 변경과 엣지 케이스를 직접 처리해야 하며, 데이터 신선성과 파이프라인 비용을 대가로 치르게 하고, 그 과정에서 실패 지점도 추가됩니다. LTAP는 대신 스토리지 수준 접근법을 취합니다: 레이크베이스 스토리지는 정상적인 스토리지 운영의 일부로 데이터를 트랜스코딩하며, 외부 프로세스가 귀하의 업무량과 경쟁하지 않고, 구축하거나 유지할 파이프라인도 없습니다.
LTAP의 세 가지 기둥
스토리지 계층에서 데이터를 통합하면 LTAP가 세 가지 정의적인 특성을 갖게 됩니다.
- 보편적 거버넌스. Unity Catalog는 두 워크로드 모두에서 하나의 논리적 복사본에 대한 분석적 접근을 관리합니다.
- 목적에 맞게 제작된 엔진들. Postgres는 거래를 담당하고, Lakehouse는 분석을 담당하며, 어느 쪽도 서로를 타협하지 않습니다.
- 오픈 스토리지에 있는 단일 논리 복사본. 두 엔진 모두 복제본이나 파이프라인을 동기화할 필요가 없는 오픈 포맷의 데이터 한 복사본만 읽습니다.
보편적 통치
Unity Catalog는 두 워크로드 모두에서 데이터에 대한 분석적 접근을 관리합니다. Lakebase 데이터베이스를 등록한 후, Unity Catalog는 이를 읽는 외부 컴퓨트에 권한, 계보, 감사를 적용합니다.
참고
Unity 카탈로그 거버넌스는 현재 분석용 액세스, 즉 등록된 Lakebase 데이터를 읽는 Lakehouse//RT 및 Change Data Feed와 같은 외부 컴퓨트에 적용됩니다. 아직 개별 Postgres 테이블을 직접 관리하지는 않습니다.
트랜잭션 경로, 즉 Postgres에 접속하는 애플리케이션과 클라이언트의 접근은 여전히 Unity 카탈로그가 아닌 표준 Postgres 권한(GRANT그리고 REVOKE)에 의해 제어됩니다. 실제로 Unity Catalog는 분석 및 호숫가 접근을 관리하고, Postgres 역할과 권한은 거래 접근을 담당합니다.
목적에 맞게 제작된 엔진
Postgres는 거래 업무를 담당하고, Lakehouse는 분석 업무를 제공하며, 각각 고유한 강점을 가지고 있습니다. 흔한 오해 중 하나는 이 둘을 통합하면 운영 데이터가 Iceberg에 저장된 콜드 데이터가 된다는 것입니다. 하지만 그렇지 않습니다. Lakebase는 여전히 표준 Postgres입니다. 인덱싱, 분기, 시점 복구, 확장, 저지연 포인트 읽기 및 쓰기 기능은 현재와 똑같이 계속 작동합니다.
분석적 리드는 주 Postgres 인스턴스와 분리되어 있기 때문에 트랜잭션 작업과 경쟁하지 않습니다. Lakehouse//RT와 같은 분석 엔진이 실시간 Lakebase 데이터를 쿼리할 때, 데이터를 복사하지 않고 신선하고 트랜잭션적으로 일관된 결과를 반환합니다:
- 엔진은 Postgres가 아니라 객체 저장소의 열형 복사본에서 대부분의 데이터를 읽습니다.
- 트랜잭션 일관성을 얻기 위해, Postgres는 현재 로그 시퀀스 번호(LSN)만 요청하는데, 이는 앞서 쓰기 로그에서 위치를 표시하는 단일 값입니다. 이건 저렴한 메타데이터 조회입니다.
- 아직 호수에 반영되지 않은 최근의 변경 사항 중 일부는 페이지서버에서 읽어 상단에 병합합니다.
Postgres는 분석 읽기 트래픽을 단일 LSN을 반환하는 것 외에는 아무런 처리를 하지 않으며, 트랜스코딩은 저장소 계층에서 실행되지, 애플리케이션을 지원하는 Postgres 인스턴스에서는 실행되지 않습니다. 운영 업무량은 예상대로 계속 진행됩니다.
오픈 스토리지에 있는 단일 논리 복사본입니다
데이터가 Delta나 Iceberg와 같은 오픈 테이블 형식으로 읽을 수 있는 기둥형 파켓 형태로 호수 내에 존재하기 때문에, Lakebase(OLTP)와 Lakehouse(OLAP)는 동일한 저장 기반을 공유합니다. 트랜잭션 데이터베이스와 별도의 분석 복사본을 대조하는 대신, 두 워크로드 모두에서 하나의 논리적 데이터 복사본을 유지할 수 있습니다.
각 엔진은 성능을 위해 데이터를 캐시하거나 서로 다른 물리적 형식으로 표현할 수 있습니다. Lakebase는 빠른 OLTP 포인트 조회를 위해 Postgres 페이지를 사용하며, 분석 엔진은 컬럼형 Parquet을 읽습니다. 여전히 별도의 트랜잭션용 복사본과 분석용 복사본을 유지하고 이를 동기화하는 대신, 단일 논리적 데이터 세트로 작업합니다.
각 테이블에는 레이크베이스나 레이크하우스 중 한 명의 작가가 있습니다. 두 엔진 모두 그 하나의 논리 복사본을 읽기 때문에, 동일한 데이터가 두 번째 사본 없이도 애플리케이션과 분석에 제공될 수 있습니다.
Lakebase 사용 방식을 바꿔야 하나요?
No. LTAP 기능을 도입하는 데 데이터 이전이나 애플리케이션이 Lakebase에 연결하는 방식을 변경하는 것은 필요하지 않습니다. Lakebase는 여전히 표준 Postgres로 남아 있습니다: 기존 확장 프로그램, 인덱스, 쿼리, 애플리케이션 코드는 변경된 적 없이 계속 작동합니다. 각 LTAP 기능은 독립적이기 때문에, 작업 부하가 필요할 때마다 어느 것이든 채택할 수 있습니다.
LTAP를 구현하는 기능
LTAP 아키텍처를 Lakebase 기능들을 통해 실천에 적용합니다. 각 프로젝트는 위에서 설명한 공유 스토리지 기반 위에 구축되며, 함께 LTAP를 통해 데이터가 이동하는 경로를 포함합니다:
- 거버넌스 및 등록: Lakebase 데이터를 Unity 카탈로그 아래에 포함시키세요.
- Lakebase에서 레이크하우스 데이터를 서비스: LTAP Direct Writes로 가속된 동기화된 테이블.
- 실시간 Lakebase 데이터를 조회하세요: 분석은 Lakehouse//RT, 변경 스트림은 Lakebase Change Data Feed입니다.
다음 다이어그램은 Unity 카탈로그에 의해 관리되는 한 복사본에 이 기능들이 어떻게 쓰고 읽는지 보여줍니다.
Lakehouse//RT와 Lakebase Change Data Feed는 동일한 기본 데이터를 읽지만 다르게 표현합니다. Lakehouse//RT는 실시간 Postgres 데이터의 현재 상태를 분석용으로 읽습니다. 변경 데이터 피드는 하위 파이프라인과 감사를 위한 행 단위 변경 스트림을 제공합니다. LTAP가 제거하는 외부 CDC도 마찬가지입니다: 두 경우 모두 단일 데이터 복사본에서 작동합니다.
다음 표는 모든 LTAP 기능과 그 기능이 무엇인지, 그리고 클라우드에서의 릴리스 상태를 나열합니다. 가용성은 클라우드마다 다르기 때문에, 클라우드에 제공되지 않은 기능은 사용 불가로 표시됩니다.
| Capability | 상태 | 설명 |
|---|---|---|
| Unity 카탈로그에서 Lakebase를 등록하세요 | GA | Lakebase 데이터에 대한 분석 접근을 통제하고 lakehouse에서 교차 소스 쿼리를 실행합니다. |
| 동기화된 테이블을 사용하여 데이터 제공 | GA | Lakebase에서 Unity Catalog 테이블 데이터를 저지연 OLTP 읽기 위해 제공하세요. LTAP Direct Writes(베타)는 모든 동기화 모드에서 초기 로드를 가속화하며, 완전한 갱정도 지원합니다. |
| Lakehouse//RT 가 Lakebase에 쿼리 중입니다 | 베타 | 실시간 Postgres 데이터에 대해 Lakebase OLTP 성능에 영향을 주지 않는 트랜잭션 일관된 OLAP 쿼리를 실행할 수 있습니다. |
| Lakebase 변경 데이터 피드 | Public Preview | Lakebase Postgres 테이블의 행 단위 변경 사항을 Unity 카탈로그 Delta 테이블로 저장하여 하위 파이프라인과 감사용으로 활용합니다. |
구현 접근법
이제 기능을 알게 되었으니, 문제는 당신의 업무량이 어떤 기능을 필요로 하느냐입니다. LTAP는 데이터가 아키텍처를 통해 흐르는 방식에 맞는 기능을 결합하여 구현합니다.
핵심 결정은 방향입니다: 각 데이터셋에 대해 어떤 시스템이 쓰기를 소유하는가? 각 테이블에는 단일 라이터가 있고, 그것이 어떤 기능을 사용하는지를 결정합니다.
- 레이크베이스가 쓰기 권한을 가집니다. 애플리케이션은 Postgres에 쓰기 역할을 하며, 그 운영 데이터를 복사하지 않고 분석에 활용하고 싶습니다. 예를 들어, 영업 애플리케이션은 주문과 결제가 발생하는 즉시 Lakebase에 작성합니다. Lakehouse//RT를 사용해 해당 주문에 대한 실시간 수익 대시보드를 실행하거나, Lakebase 변경 데이터 피드를 사용해 각 주문 변경을 다운스트림 파이프라인이나 감사 로그로 스트리밍하세요.
- 레이크하우스가 쓰기 작업을 소유합니다. 데이터는 레이크하우스에서 생성되거나 유지되며, 애플리케이션에서 저지연 OLTP 읽기를 원할 것입니다. 예를 들어, 야간 호숫가 작업은 제품 추천이나 가격 표를 계산합니다. 동기화된 테이블을 사용해 해당 데이터를 Lakebase에 전달해 애플리케이션이 낮은 지연 시간으로 데이터를 읽을 수 있게 하고, LTAP Direct Writes를 활성화해 대형 테이블의 초기 부하를 가속화하세요.
각 데이터셋을 다음 방향 중 하나에 매핑하고, Unity 카탈로그에 데이터베이스를 등록 하여 거버넌스를 한 뒤, 각 경로를 구현하기 위해 기능 문서를 따라가세요. 단일 애플리케이션은 종종 두 방향을 모두 사용합니다: 레이크하우스에서 Postgres로 참조 데이터를 제공하는 동시에 자체 트랜잭션 쓰기를 분석에 노출하는 방식입니다. 가용성은 클라우드마다 다르므로, 위 기능 표를 확인하여 클라우드에서 제공하는 내용을 확인하세요.
다음 단계
- Lakebase 아키텍처: Lakebase가 상태 없는 컴퓨팅과 내구성 저장소를 어떻게 구분하는지 이해하세요. Lakebase 아키텍처를 참조하세요.
- Unity Catalog에 데이터베이스를 등록: Lakebase 데이터를 관리하고 레이크하우스에서 쿼리하세요. Unity 카탈로그에서 Lakebase 데이터베이스 등록을 참조하세요.
- 동기화된 테이블로 데이터를 제공하기: Unity 카탈로그 테이블 데이터를 Lakebase에 동기화하여 저지연 읽기를 수행하고, LTAP 직접 쓰기로 대규모 부하를 가속화하세요. 동기화된 테이블로 레이크하우스 데이터를 제공하는 것을 참조하세요.
- Lakebase Change Data Feed: 파이프라인과 감사를 위해 행 단위 변경 사항을 레이크하우스로 스트리밍합니다. Lakebase 변경 데이터 피드를 참조하세요.