Zerobus Ingest(ZeroBus)는 Databricks의 Lakeflow Connect에 포함된 기능으로, 한 문장으로 요약하면 “Kafka 같은 메시지 버스 없이, 데이터 생산자가 이벤트 데이터를 Unity Catalog의 Delta 테이블로 직접(push) 써 넣는 서버리스(fully managed) 인제스트 API/커넥터”입니다. Source
ZeroBus가 바꾸는 아키텍처 한 장 요약
- 출처: Databricks Docs(overview) Source
Databricks는 ZeroBus를 “direct write API”로 소개하며, 중간에 메시지 버스를 두지 않고 데이터 생산자가 Unity Catalog로 이벤트를 직접 푸시하는 접근이라고 설명합니다. Source
1) ZeroBus의 핵심 개념: “Push 기반 + Unity Catalog Delta 테이블 직행”
공식 문서에서 Zerobus Ingest는 다음처럼 정의됩니다.
- Push-based ingestion API: 생산자가 “보내는 쪽(push)”에서 Databricks로 데이터를 밀어 넣음
- Unity Catalog Delta tables에 직접 기록
- Serverless connector: 들어오는 연결을 처리하기 위해 자동 확장되며, 브로커/파티션을 관리할 필요가 없다고 명시 Source
즉, 기존 “Edge/서비스 → Kafka → (커넥터/스트리밍) → Lakehouse” 같은 다단계 구조에서 중간 홉(hop)을 제거해서 단순화하는 철학입니다. Source
2) 왜 ‘ZeroBus’가 필요한가? (Kafka가 있는데도)
Databricks의 설명 포인트는 꽤 명확합니다.
- Kafka는 다중 싱크(여러 목적지)에는 강점이 있지만, 목적지가 레이크하우스 하나뿐인 경우엔
추가 복잡도/비용/중복 데이터/운영 부담이 생기기 쉽다 Source - Zerobus Ingest는 “single-sink(레이크하우스 직행)”에 최적화해
브로커/파티션/컨슈머그룹/업그레이드 같은 운영 요소를 줄이는 방향 Source
3) 성능/스케일: 문서에 나온 수치들(현업 체크포인트)
문서(제약/스펙) 기준 지표
- Time to durability: P95 500ms / P50 200ms
- Time to table(테이블에 물리 반영): P95 30초 / P50 5초 Source
- Throughput 제한(대표)
- 100MB/s per stream (1KB 메시지 기준 벤치)
- 10GB/s per target table
- 15,000 records/s per stream Source
제품/GA 포스트에서 강조하는 메시지
- “수천 동시 연결” 및 “테이블로의 대규모 처리량”, “sub-5-second 경로”를 강조합니다. Source
- 제품 페이지도 “as little as five seconds”, “100MB/s”, “10GB/s”를 반복해 강조합니다. Source
4) 인터페이스/SDK: gRPC vs REST (무엇을 선택할까?)
Zerobus Ingest는 gRPC와 REST를 지원합니다. Source
- gRPC(+SDK): 지속 연결 기반이라 고처리량에 유리하지만, 문서에서 “열어둔 stream이 동시성 쿼터에 영향을 줄 수 있음”을 언급 Source
- REST: 매 요청 핸드셰이크가 있어 “throughput tax”가 있지만, “대규모의 chatty device(자주 말 거는) 환경/제약이 있는 경우”에 맞는 선택지로 설명 Source
지원 SDK(문서에 명시): Python, Rust, Java, Go, TypeScript 및 REST API. Source
ZeroBus 개념 소개 스크린샷/자료
- 출처: Databricks Docs(overview 페이지 캡처 이미지 검색 결과) Source
5) “정확히 한 번(Exactly-once)”인가? 중요한 제약
Zerobus Ingest 커넥터는 at-least-once 보장만 제공한다고 문서에 명시되어 있습니다. 즉, 생산자/클라이언트 측에서 중복 가능성을 고려한 설계(예: event_id 기반 dedup, merge 전략)가 필요할 수 있습니다. Source
또한 스트림(Streams) 관련 핵심 포인트:
- 스트림 1개는 테이블 1개로 ingest
- 이벤트 순서 보장(ordering)은 per-stream 단위
- 스트림을 여러 개로 늘리면 처리량을 올릴 수 있으나, 라운드로빈으로 섞으면 순서 보장이 깨질 수 있음 Source
6) 운영/보안 관점: Unity Catalog가 “입구부터” 걸린다
Zerobus Ingest는 테이블을 자동 생성하지 않으며, 사용자가 테이블을 먼저 만들고, 서비스 프린시플(service principal) 을 만들어 권한을 부여한 뒤 쓰는 흐름을 문서에서 안내합니다. Source
기본 절차(문서 요약):
1) Zerobus endpoint 확인
2) 타깃 테이블 생성/선정
3) 서비스 프린시플 생성 후 catalog/schema/table 권한 부여
4) SDK/REST로 이벤트 전송 Source
7) 대표 제한사항(도입 전에 꼭 체크)
문서에 정리된 제약 중 실무에서 특히 중요한 것들:
- 지원 리전 제한 + 워크스페이스와 테이블이 같은 리전에 있어야 함 Source
- managed Delta tables만 지원(default storage로 쓰기 지원 안 함) Source
- delivery guarantee는 at-least-once Source
- 스키마 자동 진화(auto-evolve) “절대 안 함” Source
- 레코드 최대 10MB Source
- 파티션 테이블에 쓸 때 5초 구간에 1000 파티션 초과 불가 Source
- Catalog-managed commits 미지원 Source
- 컴플라이언스 보안 프로파일 워크스페이스(FedRAMP/HIPAA/PCI-DSS 등) 미지원(문서 명시) Source
8) 언제 ZeroBus를 쓰면 좋나? (추천 시나리오)
Databricks가 직접 언급한 대표 유즈케이스:
정리하면, “메시지 버스 운영이 부담인데 목적지는 Databricks 하나”인 환경에서 특히 매력적입니다. Source
참고 링크 모음
- Zerobus Ingest 개요(공식 문서): https://docs.databricks.com/aws/en/ingestion/zerobus-overview
- 사용 방법(공식 문서): https://docs.databricks.com/aws/en/ingestion/zerobus-ingest
- 제약/한계(공식 문서): https://docs.databricks.com/aws/en/ingestion/zerobus-limits
- Lakeflow Connect + Zerobus 소개(블로그): https://www.databricks.com/blog/whats-new-zerobus-and-other-announcements-improve-data-ingestion-lakeflow-connect
- GA 발표(블로그): https://www.databricks.com/blog/announcing-general-availability-zerobus-ingest-part-lakeflow-connect
- 제품 페이지: https://www.databricks.com/product/data-engineering/lakeflow-connect/zerobus-ingest
