Kafka 토픽 데이터를 낮은 지연으로 Iceberg 테이블로 변환하고 지속적으로 컴팩션하는 문제를 짚고, Spark 파이프라인과 ‘제로 카피’ Kafka 접근의 한계를 설명한 뒤, 전용(네이티브) Iceberg 데이터베이스 방식과 WarpStream Tableflow라는 대안을 제시합니다.
Richard Artoul
공동 창업자
2025년 9월 17일
the-case-for-an-iceberg-native-database-why-spark-jobs-and-zero-copy-kafka-wont-cut-it
HN 공개: WarpStream은 오브젝트 스토리지 위에 직접 구축된 Apache Kafka 대체품을 판매합니다.
우리는 새로운 제품인 WarpStream Tableflow를 출시했습니다. 이는 Kafka 토픽 데이터를 낮은 지연으로 Iceberg 테이블로 변환하고, 테이블을 계속 컴팩션 상태로 유지하는 가장 쉽고, 가장 저렴하며, 가장 유연한 방법입니다. 이미 Kafka 토픽을 Iceberg 테이블로 변환하는 난관에 익숙하시다면, “마법 상자가 있다면?” 섹션에서 우리의 해법으로 건너뛰셔도 됩니다.
Apache Iceberg와 Delta Lake는 오브젝트 스토리지 위에서 전통적인 데이터베이스 테이블의 환상을 제공하는 테이블 포맷으로, 스키마 진화, 동시성 제어, 그리고 사용자에게 투명한 파티셔닝을 포함합니다. 이러한 테이블 포맷은 많은 오픈소스 및 상용 쿼리 엔진과 데이터 웨어하우스 시스템이 동일한 기반 데이터 위에서 동작하도록 해 벤더 종속을 방지하고, 데이터를 추가 복제하지 않고도(비용과 거버넌스 문제를 줄이며) 워크로드별 최적의 도구를 사용할 수 있게 해줍니다.
테이블 포맷은 정말 훌륭하지만, 어디까지나 ‘포맷’일 뿐입니다. 실제로 이를 만들고 유지하는 주체가 필요합니다. 그 결과 지금 데이터 인프라 분야에서 가장 논쟁적인 화두 중 하나는 Kafka에 저장된 실시간 데이터를 바탕으로 Iceberg/Delta Lake 테이블을 어떻게 구축할 것인가입니다.
.png)
이 문제의 정석적 해법은 Spark 배치 잡을 사용하는 것입니다.
.png)
역사적으로 이런 식으로 해왔고, 아주 나쁜 해법은 아니지만 다음과 같은 문제가 있습니다.
문제 1과 3은 Spark로 해결할 수 없지만, 문제 2(테이블 업데이트 지연)은 Spark Streaming과 마이크로배칭으로 일부 완화할 수 있을지도 모릅니다.
.png)
그렇지만 완전히 그렇지는 않습니다. Spark Streaming으로 더 작은 마이크로배치 잡을 자주 돌리면 Iceberg 테이블 업데이트 빈도는 크게 늘어납니다. 하지만 이제 기존 문제에 더해 새로운 문제가 두 개 생깁니다.
.png)
데이터 레이크를 만들어 본 사람이라면 누구나 스몰 파일 문제에 익숙합니다. 쓰기 빈도가 높을수록 파일이 빠르게 불어나고, 쿼리는 점점 느려지고 비싸져 결국은 아예 동작하지 않게 됩니다.
그래도 괜찮습니다. 잘 알려진 해법이 있으니까요: 더 많은 Spark!
스파크 스트리밍 잡이 만들어낸 작은 파일들을 주기적으로 합쳐 더 큰 파일로 만드는 컴팩션을 수행하는 새로운 Spark 배치 잡을 만들 수 있습니다.
.png)
컴팩션 잡은 스몰 파일 문제를 해결하지만 새로운 문제를 만듭니다. Iceberg 테이블은 이른바 ‘단일 라이터 문제(single writer problem)’에 시달리는데, 이는 동시에 하나의 프로세스만 테이블을 변경할 수 있다는 뜻입니다. 두 프로세스가 동시에 테이블을 변경하려고 하면 하나는 실패하여 많은 작업을 다시 해야 합니다[1].
즉, 인제스트 프로세스와 컴팩션 프로세스가 서로 경합하게 되며, 둘 중 하나가 상대적으로 너무 자주 실행되면 충돌률이 치솟고 전체 처리량은 곤두박질칩니다.
물론 이 문제의 해법도 있습니다. 컴팩션을 드물게(예: 하루 한 번), 그리고 거친 단위로 실행하는 것입니다. 동작은 하지만 두 가지 새로운 문제가 생깁니다.
아직 지치지 않으셨나요? 끝이 아닙니다. Iceberg 테이블의 모든 변경은 새로운 스냅샷을 만듭니다. 시간이 지나면 스냅샷이 쌓여 비용이 늘고, 메타데이터 JSON 파일이 너무 커져 테이블이 더는 쿼리 불가능해질 수 있습니다. 따라서 컴팩션과 별개로 오래된 스냅샷을 정리하는 백그라운드 잡이 또 필요합니다.
또한 인제스트나 컴팩션 잡이 실패할 때가 있고, 그 경우 어떤 스냅샷에도 속하지 않는 고아(오펀) Parquet 파일이 오브젝트 스토리지 버킷에 남게 됩니다. 그러면 버킷을 스캔해 고아 파일을 삭제하는 또 다른 주기적 백그라운드 잡이 필요합니다.
두더지 잡기 게임 같지 않나요? 하나를 해결할 때마다 두 개가 새로 생깁니다. 그럴 만도 한 것이, Iceberg와 Delta Lake는 ‘명세’일 뿐 ‘구현’이 아니기 때문입니다.
제가 PostgreSQL의 B-트리를 디스크에 배치하는 방식에 대한 명세와, 그 B-트리를 조작할 수 있는 라이브러리를 건넸다고 상상해 보세요. 여러분은 회사의 핵심 애플리케이션을 구동할 PostgreSQL 호환 데이터베이스를 자신 있게 만들고 배포할 수 있을까요? 아마 아닐 겁니다. 동시성 제어, 커넥션 풀 관리, 트랜잭션, 격리 수준, 잠금, MVCC, 스키마 변경, 그리고 현대 트랜잭션 DB가 디스크에 비트만 배열하는 것 외에 수행하는 수많은 기능을 여전히 구현해야 하니까요.
데이터 레이크에도 똑같은 비유가 적용됩니다. Spark는 Parquet과 Iceberg 매니페스트 파일을 조작하는 작은 공구상자일 뿐입니다. 하지만 사용자가 실제로 원하는 것은 현대적 데이터 웨어하우스 기능의 50%쯤입니다. Spark가 기본 제공하는 것과 사용자가 성공에 필요로 하는 것의 격차는 메울 수 없을 정도로 큽니다.
이 관점에서 보면, 왜 이렇게 어려운지 놀랍지 않습니다. “우리는 Spark로 회사의 최신 데이터 레이크를 만들겠다”라는 말은 사실상 “회사 내 모든 데이터 파이프라인마다 주문제작형 데이터베이스를 하나씩 만들겠다”라고 선언하는 것과 다름없습니다. 그게 쉽기를 기대하는 사람은 없죠. 데이터베이스는 어렵습니다.
대부분의 사람들은 이런 인프라를 관리하고 싶지 않습니다. 그저 한 애플리케이션에서 이벤트를 내보내면, 합리적인 시간 안에 Iceberg 테이블에서 그 이벤트를 볼 수 있기를 원할 뿐입니다. 끝.
문제 정의는 단순하지만, 만족스러운 수준으로 해결하려면 현대 데이터베이스 기능의 절반을 구축하고 운영해야 하는 게 현실입니다.
작은 일이 아닙니다! 저도 압니다. 공동 창업자와 저는(그리고 WarpStream의 동료들과 함께) 이 모든 걸 예전에 한 번 해봤습니다.
요약: “Iceberg 토픽”, “제로 카피 Iceberg”, “디스크 없는 Kafka” 같은 버즈워드에 관심 없으시다면 이 섹션은 건너뛰고 바로 “마법 상자가 있다면?”로 넘어가세요.
이제 많은 이들이 더 나은 해법을 찾으려는 이유가 보이실 겁니다. 여러 접근이 시도되었고, 최근 부상한 것 중 하나는 Kafka 자체(및 다양한 프로토콜 호환 구현)가 Iceberg 테이블을 만들어 주도록 하자는 것입니다.
논리는 이렇습니다. Kafka(및 다수의 호환 구현)는 이미 과거 토픽 데이터를 위한 티어드 스토리지를 갖추고 있습니다. 레코드/로그 세그먼트가 충분히 오래되면 Kafka가 이를 오브젝트 스토리지로 내보내, 드물게 소비되는 데이터의 디스크 사용량과 비용을 줄일 수 있습니다.
그렇다면 티어링되는 로그 세그먼트를 Parquet 파일로 바꾸고, 그 위에 약간의 메타데이터 마법을 얹어주면 어떨까요? 그러면 이제 “제로 카피” 스트리밍 데이터 레이크가 생깁니다. Kafka 컨슈머와 Iceberg 쿼리를 모두 같은 데이터 사본 하나로 서빙하고, Spark도 몰라도 됩니다!
%20(1).png)
문제 해결! 이 기능을 지원하는 Kafka 구현으로 갈아타고, 몇 가지 토픽 설정만 바꾸면, 동료들이 원하는 쿼리 엔진으로 실시간 Iceberg 테이블에서 인사이트를 뽑을 수 있겠죠.
물론 실제로는 그렇지 않습니다. 여기는 WarpStream 블로그니까요. 열혈 독자라면 방금 네 단락이 제가 하고 싶은 진짜 말을 위한 도끼 갈기였다는 걸 아실 겁니다. 바로 이것입니다: 이건 작동하지 않으며, 앞으로도 작동하지 않을 겁니다.
이렇게 생각하실 수도 있겠죠. “리치, 넌 맨날 안 된다 그러잖아. Kafka의 티어드 스토리지는 안 된다고 10페이지짜리 성토문도 쓰지 않았어?” 맞습니다, 썼습니다.
솔직히, 저는 Kafka의 티어드 스토리지에 매우 비판적입니다. 겉보기엔 좋아 보여도, 실제 구현 대부분은 처참합니다. 어쩌면 제가 좀 냉소적일 수도 있습니다. WarpStream으로의 마이그레이션 중 적지 않은 비율이, 고객이 실제로 Kafka 클러스터의 과거 데이터를 WarpStream으로 복사하려 할 때, 티어드 스토리지에서 과거 데이터를 로드하느라 Kafka 클러스터가 망가져 잠시 멈칫하곤 하거든요.
하지만 그게 제 요지입니다. 저는 ‘현실 세계’에서 티어드 스토리지가 과거 조회를 잘 서빙하지 못하는 모습을 수없이 봤습니다.
이 글에서는 OSS Kafka와 대부분의 벤더 구현에서 티어드 스토리지의 (수많은) 문제를 반복하지 않겠습니다. 다만 지적하고 싶은 건, 티어드 스토리지의 포맷을 바꾸는 것은 그 어떤 문제도 해결하지 못하고, 일부는 오히려 악화시키며, Iceberg 경험도 나빠진다는 점입니다.
이미 성능이 나쁜 기존 티어드 스토리지 구현이 Iceberg 포맷 때문에 더 나빠지는 이유부터 시작하죠. 우선 Parquet 파일 생성은 ‘비쌉니다’. 정말로 비쌉니다. 로컬 디스크에서 오브젝트 스토리지로 로그 세그먼트를 복사하는 것에 비해, CPU 사이클을 최소 한 자릿수 이상 더 쓰고, 메모리도 많이 씁니다.
이 작업이 아무 데나 있는 상태 없는(stateless) 컴퓨트 노드에서 돌아간다면 괜찮겠지만, 그렇지 않습니다. 여러분 클러스터에서 일부 토픽-파티션의 리더를 맡고 있는 아주 중요한 Kafka 브로커에서 돌아갑니다. 이런 계산 집약적 작업(Parquet 생성)을 하기에 ‘최악의 장소’입니다.
설상가상으로, 오브젝트 스토리지에 있는 티어드 데이터를 읽어 과거 Kafka 컨슈머를 서빙하는 일(티어드 스토리지의 주된 성능 문제)은 운영도, 비용도 ‘더더욱’ 어려워집니다. 이제 Parquet 파일을 디코드해 Kafka 레코드 배치 포맷으로 되돌려야 하는데, 이 역시 한 번 더, 여러분의 실시간 워크로드를 담당하는 Kafka 브로커에서 수행됩니다. 계산 집약적 작업을 하기에 ‘최악의 장소’에서 말이죠.
이 접근은 프로토타입이나 데모에서는 동작합니다. 하지만 의미 있는 규모로 프로덕션에 들고 가는 순간 운영과 성능의 악몽이 됩니다. 아니면 Kafka 클러스터를 엄청 과다 프로비저닝해야 하는데, 이는 사실상 돈을 엄청 뿌리고 잘되길 비는 격입니다.
티어드 스토리지의 성능 문제를 믿지 않으셔도 괜찮습니다. 어차피 핵심은 그게 아닙니다. Kafka의 티어드 스토리지 포맷으로 Iceberg를 쓰는 목적은 ‘어떤 용도’로든 쓸 수 있는 실시간 Iceberg 테이블을 만드는 것입니다. 불행히도 티어드 스토리지로는 ‘유용한’ Iceberg 테이블이 나오지 않습니다.
Kafka의 티어드 스토리지 시스템이 Iceberg 테이블을 생성한다면, Iceberg 테이블의 파티셔닝은 Kafka 토픽의 파티셔닝과 ‘반드시’ 일치해야 합니다. 이는 자명한 이유들로 매우 성가십니다. Kafka 파티셔닝 전략은 ‘운영’ 용도를 위해 선택되지만, Iceberg 파티셔닝 전략은 ‘분석’ 용도를 위해 선택되어야 합니다.
양자 간에는 본질적 임피던스 불일치가 있어 늘 발목을 잡습니다. 최적의 쿼리 성능은 Iceberg 측에서 파일 프루닝이 최대화되도록 데이터를 파티셔닝하고 정렬하는 데서 나오지만, 같은 파일 집합이 Kafka 컨슈머를 위한 티어드 스토리지 역할도 해야 한다면 이는 ‘불가능’합니다.
이 문제의 자명한 해법이 하나 있습니다. 티어드 데이터를 두 사본으로 저장하는 것입니다. 하나는 Kafka 컨슈머 서빙용, 다른 하나는 Iceberg 쿼리에 최적화된 형태로요. 훌륭한 생각이고, 운영/분석 워크로드를 모두 규모 있게 서빙하는 현대 시스템은 대개 이렇게 설계됩니다.
하지만 데이터를 두 사본으로 저장할 거라면, 두 용도를 굳이 뒤섞을 이유가 전혀 없습니다. 얻는 건 겉보기 편의성뿐이고, 대가로 끝없는 운영/성능 문제를 치르게 됩니다.
요컨대 프로덕션 Kafka 클러스터 안에서 “제로 카피” Iceberg를 구현하겠다는 생각은 공상에 가깝습니다. Kafka는 Kafka로, Iceberg는 Iceberg로 두는 편이 훨씬 낫습니다.
Spark 섹션에서 본 스몰 파일 문제, 기억하시죠? 불행히도 Parquet 생성을 Kafka 브로커에 욱여넣는다고 스몰 파일 문제가 사라지지 않습니다. 여전히 테이블 유지보수와 파일 컴팩션을 수행해 쿼리 가능 상태를 유지해야 합니다.
이건 Spark에서도 어려운 문제인데, 그 유지보수/컴팩션을 Kafka 클러스터 노드에서 해야 한다면 더더욱 어렵습니다. 이유는 간단합니다. Spark는 상태 없는 컴퓨트 레이어라 필요할 때 올렸다 내렸다 할 수 있기 때문입니다.
Iceberg 테이블에 대해 매일 대규모 컴팩션을 돌려야 할 때, 여러분은 그 순간 멀티 테넌트 쿠버네티스 클러스터 어딘가에 굴러다니는 잡다한 VM들을 긁어모아 즉석 Spark 클러스터를 만들 수 있습니다. 스팟 인스턴스를 써도 됩니다. 전부 상태 없으니까요. 상관없습니다!
.png)
여러분의 Spark 클러스터를 떠받치는 VM들. 아마도요.
컴팩션을 얼마나 많이, 얼마나 무겁게, 얼마나 오래 돌리든, 그게 실시간 Kafka 워크로드의 성능이나 가용성에 악영향을 줄 일은 절대 없습니다.
이에 반해 여러분의 ‘말끔한’ Kafka 클러스터는 ‘신중히 프로비저닝’되어 ‘고급’ VM에서, 잔여 ‘RAM이 넉넉’하고 ‘비싼 SSD/EBS 볼륨’을 달고 돌아갑니다. 클러스터 리사이징에는 ‘수 시간’, 어쩌면 ‘수일’이 걸립니다. 클러스터가 멈추면 비즈니스에 즉시 데이터 손실이 발생합니다. ‘바로 그곳’에서 Parquet 파일을 쿵쿵 두들겨 맞추는 데 귀중한 CPU와 RAM을 쓰겠다고요!?
말이 안 됩니다.
WarpStream 같은 ‘디스크리스’ Kafka 구현은 저장과 컴퓨트를 분리해 컴퓨트를 더 유연하게 만들기 때문에, Iceberg 기능을 Kafka 브로커에 바로 넣는 면에서 약간은 유리합니다.
그럼에도 저는 이게 나쁜 생각이라고 봅니다. 가장 큰 이유는 Iceberg 파일 생성과 컴팩션이, Kafka가 평소에 하는 바이트 셔플 작업과 비교하면 엄청나게 비싼 연산이기 때문입니다. 게다가 Iceberg 테이블 구축/유지에 필요한 비용과 메모리는 스키마에 따라 크게 변합니다. Iceberg 테이블에 컬럼 몇 개만 추가하는 사소한 스키마 변경으로도 Kafka 클러스터 부하가 10배 이상 늘 수 있습니다. 그 Kafka 클러스터가(디스크리스든 아니든) 핵심 프로덕션 트래픽을 서빙하고 있다면 재앙입니다.
마지막으로, 이 기능을 지원하는 기존 Kafka 구현들은 결국 Iceberg 테이블의 파티셔닝을 Kafka 토픽의 파티셔닝과 엮어버리곤 합니다. 그 결과 앞서 설명한 대로 슬픈 Iceberg 테이블이 됩니다. 아니면 아예 테이블 유지보수와 컴팩션 문제를 빼먹습니다.
알겠습니다. 합리적인 지연으로 Iceberg 테이블을 만드는 일은 정말 어렵고 성가십니다. 티어드 스토리지와 WarpStream, Freight 같은 디스크리스 아키텍처가 요즘 Kafka 생태계에서 유행입니다. 어차피 Kafka가 데이터를 오브젝트 스토리지에 저장하는 방향으로 가고 있다면, 다 같이 잘 지내 보죠. 로그 세그먼트를 어떻게든(손을 휙휙) Parquet으로 주물러서, 모두가 오래오래 행복하게 살면 안 될까요?
그 마음 압니다. 아이디어가 너무나 ‘명백’하고 ‘매혹적’이죠. 우리 모두 시스템의 단순함을 갈망합니다. 그래서 이 아이디어가 커뮤니티에 빠르게 뿌리내렸고, 많은 벤더들이 다듬어지지 않은 구현을 서둘러 내놓았습니다. 하지만 앞서 설명했듯, 이건 나쁜 생각이고 훨씬 더 나은 방법이 있습니다.
만약, 이 모든 티어드 스토리지 광기를 제쳐두고, 잠깐만요, ‘마법 상자’가 있다면 어떨까요.
%201%20(1).png)
보라, 소박한 마법 상자를.
마법 상자 속을 들여다보지 말고, 먼저 이 상자가 ‘무엇을 하는지’를 이야기해 봅시다. 마법 상자는 오직 ‘한 가지’ 기능만 압니다. Kafka에서 읽고, Iceberg 테이블을 만들고, 그것을 컴팩션 상태로 유지합니다. 좋습니다, 세 가지네요. 그래도 한 문장에 넣었으니 셈은 한 가지로 할게요.
이 상자는 그것만 하고, 그걸 잘하려고만 합니다. 이런 마법 상자가 있다면, 우리는 다음처럼 하면 됩니다.
.png)
그리고 삶은 아름다울 것입니다.
또 이렇게 생각하시겠죠. “스파크지? 상자에 스파크 넣었지!?”
%20(1).png)
상자 안에 뭐가 들었죠?!
그렇게도 할 수 있습니다. 스키마 레지스트리 연동, 스키마 마이그레이션 신중 처리, 유효하지 않은 레코드 DLQ, 업서트 처리, 동시 라이터 문제 해결, 점진적 컴팩션의 우아한 스케줄링, 자동 스케일링까지 서로 얽히는 정교한 Spark 프로그램 묶음을 짤 수 있습니다.
그리고 작동할 겁니다.
하지만 그건 ‘마법 상자’가 아닙니다.
그건 ‘상자 속의 Spark’이고, Spark의 날카로운 모서리는 언젠가 우리 상자에 구멍을 낼 겁니다.
%20(1).png)
여러분은 이 상자 속을 보면 실망하실 겁니다.
그게 SaaS로, 상자를 만든 전문가들이 관리하는 청정 환경에서만 돌릴 상자라면 문제가 덜합니다. 하지만 여러분이 직접 배포하고 운영하고 싶은 상자는 아닙니다.
Spark는 도구로 가득한 차고 같은 존재입니다. 차고의 도구들을 정교하게 배치해, 충분하고 빈번한 사람의 개입이 있을 때 어쩌다 품질이 들쭉날쭉한 위젯을 토해내는 루브 골드버그 머신을 만들 수는 있습니다.
하지만 우리가 필요한 건 그런 게 아닙니다. 우리에게 필요한 것은 Iceberg 조립 라인입니다. 오로지 Iceberg만, 하루가 멀다 하고, 잔혹할 만큼 효율적으로, 사람의 감독이나 개입 없이 만들어내는 일관되고 특수 제작된 윤활 잘 된 기계. Kafka가 들어가고, Iceberg가 나옵니다.
‘그게’ 여러분이 자체 환경에 배포해 직접 운영하고 싶은 마법 상자일 것입니다.
결국은 패키징의 문제입니다.
여기는 WarpStream 블로그입니다. 그러니 우리가 마법 상자를 만들었다고 말할 차례죠. 이름은 Tableflow입니다. 새 아이디어가 아닙니다. 사실 Confluent Cloud 사용자들은 6개월 넘게 완전관리형 서비스로서 Tableflow를 써왔고, 아주 좋아합니다. 비용 효율적이고, 효율적이며, Flink를 포함해 Confluent Cloud 생태계 전반과 긴밀히 통합되어 있습니다.
하지만 Confluent Cloud Tableflow에는 문제가 하나 있습니다. Confluent Cloud에서 완전관리형으로 돌아가기 때문에 WarpStream의 BYOC(Bring Your Own Cloud) 배포 모델과는 맞지 않습니다. 우리는 Tableflow의 BYOC 버전이 필요하다는 걸 깨달았습니다. 그래야 Confluent의 WarpStream 사용자들도 동일한 Tableflow의 이점을, 자신의 클라우드 계정 내 BYOC 모델로 누릴 수 있으니까요.
그래서 그렇게 만들었습니다!
WarpStream Tableflow(이 글에서는 그냥 Tableflow라고 부릅니다)는 Iceberg 생성 Spark 파이프라인에 대해 WarpStream이 Apache Kafka에 하는 것과 같은 일을 합니다.
여러분의 환경에서 실행되고, 자동 스케일링되며, 완전히 상태 없고, 단일 바이너리로 된 ‘마법 같은’ 데이터베이스입니다. 이 데이터베이스는 여러분의 Kafka 클러스터(Apache Kafka, WarpStream, AWS MSK, Confluent Platform, 기타 Kafka 호환 구현 모두)와 연결되고, 선언적 YAML 구성으로 여러분이 요구하는 정확한 사양의 Iceberg 테이블을 생산합니다.
source_clusters:
- name: "benchmark"
credentials:
sasl_username_env: "YOUR_SASL_USERNAME"
sasl_password_env: "YOUR_SASL_PASSWORD"
bootstrap_brokers:
- hostname: "your-kafka-brokers.example.com"
port: 9092
tables:
- source_cluster_name: "benchmark"
source_topic: "example_json_logs_topic"
source_format: "json"
schema_mode: "inline"
schema:
fields:
- { name: environment, type: string, id: 1}
- { name: service, type: string, id: 2}
- { name: status, type: string, id: 3}
- { name: message, type: string, id: 4}
- source_cluster_name: "benchmark"
source_topic: "example_avro_events_topic"
source_format: "avro"
schema_mode: "inline"
schema:
fields:
- { name: event_id, id: 1, type: string }
- { name: user_id, id: 2, type: long }
- { name: session_id, id: 3, type: string }
- name: profile
id: 4
type: struct
fields:
- { name: country, id: 5, type: string }
- { name: language, id: 6, type: string }
Tableflow는 Iceberg 테이블 생성/유지의 ‘모든’ 성가신 부분을 자동화합니다.
물론 Tableflow가 아직 ‘전부’를 하지는 못합니다. 하지만 많은 것을 이미 해내고 있고, 빈틈은 곧 메워질 것입니다.
어떻게 동작하냐고요? 그건 다음 블로그 포스트의 주제입니다. 요약하자면, 우리는 스트리밍 데이터 레이크의 효율적 생성과 유지만을 목적으로 하는, BYOC 네이티브이자 클라우드 네이티브인 커스텀 데이터베이스를 만들었습니다.
기술적 세부는 다음 글에서 더 다루겠습니다. 관심 있으시다면 문서를 확인하고, 조기 액세스 프로그램 참여를 위해 문의해 주세요. 또한 이 시리즈의 다음 글(잔혹한 기술 세부 사항 포함)이 게시될 때 알림을 받으려면 뉴스레터 구독을 해주세요.
오늘 바로 WarpStream을 시작하고, 만료되지 않는 400달러 크레딧을 받아 보세요. 시작에 신용카드는 필요하지 않습니다.