데이터 엔지니어의 일 절반
데이터 엔지니어가 만드는 파이프라인의 상당수는 같은 일을 합니다. 운영 DB의 데이터를 분석 시스템으로 옮기는 일입니다.
주문이 Postgres에 쌓이면, CDC로 변경을 잡아 레이크로 보내고, 변환해서 웨어하우스에 올립니다. 이 과정에서 지연이 생기고, 스키마가 바뀌면 파이프라인이 깨지고, 두 시스템의 숫자가 미묘하게 어긋납니다.
LTAP 발표는 이 일을 없애겠다는 주장입니다.
LTAP이 말하는 것
보도자료는 LTAP을 레이크의 하나의 데이터 사본 위에서 OLAP와 OLTP를 합치는 새로운 데이터 처리 구조라고 정의합니다. 트랜잭션, 분석, 스트리밍, 운영 데이터를 스토리지 계층에서 하나로 묶는다는 설명입니다.
핵심 문장은 이것입니다. 모든 운영 데이터는 파이프라인 없이 즉시 레이크에서 분석할 수 있다.
데이터브릭스는 이를 "세계 최초의 LTAP 플랫폼"이라고 부릅니다.
바탕은 Lakebase
LTAP의 바탕은 Lakebase입니다. 작년에 나온 서버리스 Postgres로, 오브젝트 스토리지 위에서 돌며 컴퓨트와 스토리지가 분리돼 있습니다.
중요한 점은 저장 방식입니다. Lakebase는 데이터를 Unity Catalog에 레이크하우스와 같은 개방 형식으로 저장합니다. Delta와 Iceberg입니다.
그래서 이런 그림이 됩니다.
- 트랜잭션은 표준 Postgres에서 ACID 보장과 함께 처리
- 분석은 레이크하우스 엔진에서 처리
- 둘이 같은 데이터 사본을 보고, 각자 따로 확장
- 하나의 통제 모델 아래에서 모든 엔진이 같은 사본을 읽음
HTAP와는 무엇이 다른가
트랜잭션과 분석을 한 시스템에서 처리하는 아이디어는 새롭지 않습니다. HTAP(Hybrid Transactional/Analytical Processing)라는 이름으로 오래전부터 있었습니다. 대부분 하나의 데이터베이스 안에 행 저장과 열 저장을 같이 두는 방식이었습니다.
LTAP의 차이는 장소입니다. 데이터베이스 안이 아니라 레이크에서 합칩니다. 저장 형식이 개방 형식이니, 데이터브릭스 엔진이 아닌 다른 엔진도 같은 사본을 읽을 수 있습니다. 이름에 Lake가 붙은 이유입니다.
따져 볼 지점
보도자료만으로는 답할 수 없는 질문이 몇 가지 있습니다.
쓰기 성능. 오브젝트 스토리지는 작은 쓰기를 자주 하기에 좋은 저장소가 아닙니다. 초당 수천 건의 주문을 받는 운영 DB가 개방 형식으로 바로 기록하면서도 낮은 지연을 유지하는 방법은 보도자료에 나오지 않습니다. 아마 그 사이에 버퍼나 로그 계층이 있을 겁니다.
분석의 신선도. "즉시 분석 가능"이 정확히 몇 초 뒤를 뜻하는지도 나오지 않습니다.
상태. 발표 당시 LTAP은 "곧 Lakebase의 일부로 나온다"였습니다. 정식 출시가 아닙니다.
이 질문들은 출시 후 문서와 실제 측정으로 확인해야 합니다.
Lakebase 자체의 소식
LTAP과 함께 Lakebase에 새 기능이 붙었습니다.
- 클라우드·리전을 넘는 재해 복구
- git 방식의 브랜치와 스냅샷
- 자율 데이터베이스 운영
브랜치 기능이 실무에서 쓸모가 커 보입니다. 운영 DB를 브랜치로 떠서 마이그레이션을 시험하거나, 에이전트가 만든 변경을 격리된 사본에서 먼저 돌려 볼 수 있습니다.
규모에 대한 숫자도 있습니다. Lakebase는 수천 곳의 고객을 받고 있고, 하루 1,200만 번의 데이터베이스 실행을 처리합니다. 실행 횟수가 이렇게 많은 건 에이전트나 개발 도구가 짧게 쓰고 버리는 데이터베이스를 많이 만들기 때문으로 보입니다. 데이터브릭스는 AI 덕분에 개발자가 예전보다 약 50배 많은 애플리케이션을 만든다고 주장합니다.
사례
Block, Ensemble, Superhuman, Zillow가 Lakebase 고객으로 소개됐습니다. Ensemble은 2PB가 넘는 수익 주기 데이터를 이 플랫폼에 두고 있고, CTO Grant Veazey는 LTAP이 운영 워크로드와 분석 워크로드를 하나의 계층에서 합친다고 말했습니다.
정리하며
Ghodsi는 지난 시대를 떠받친 인프라가 이제는 아무도 감당할 수 없는 병목이 됐다고 말했습니다. 운영 DB와 분석 시스템 사이의 파이프라인이 그 병목 중 하나라는 건 데이터 엔지니어라면 누구나 동의할 겁니다.
LTAP이 약속대로 동작한다면, 새 서비스를 만들 때 "이 데이터를 나중에 분석으로 어떻게 옮기지"라는 질문이 사라집니다. 아직은 약속 단계이니, 당장은 Lakebase의 브랜치처럼 이미 나온 기능부터 시험해 보는 게 현실적입니다.
함께 읽을 개념 정리
- CDC(변경 데이터 캡처)를 한 장으로: "CDC 파이프라인이 필요 없다"는 말이 무엇을 없앤다는 뜻인지
- Apache Iceberg를 한 장으로: 여러 엔진이 같은 테이블을 읽고 쓰는 원리
