Redpanda와 Databricks를 사용한 실시간 오픈 레이크하우스

모든 레이크하우스는 ‘스트림으로 공급’되어야 합니다 

몇 년 전 Databricks가 개척한 ‘오픈 레이크하우스’ 개념은 프레임워크 통합, 도구, 카탈로그 지원, 데이터 상호 운용성에 대한 주요 공급업체의 투자와 오픈 레이크하우스를 위한 공통 기반으로서 Iceberg를 채택하려는 노력 덕분에 최근 Apache Iceberg™의 부상으로 더욱 폭넓게 실현되었습니다. UniForm을 통해 Delta Lake 테이블을 증가하는 Iceberg 생태계에 노출하는 기능, 예측 최적화와 같은 고급 기능을 위한 Unity Catalog의 지원 및 관리형 Iceberg 테이블과 함께하는 Iceberg REST, 그리고 Iceberg V3에서의 Delta/Iceberg 데이터 계층의 최근 통합과 같은 발전은 조직이 이제 성숙한 레이크하우스 제품인 Databricks의 풍부한 기능 세트를 사용하는 것을 저해하지 않고 자신 있게 ‘Iceberg 우선’ 데이터 전략을 채택할 수 있음을 의미합니다. 

Iceberg라는 공용어를 통해 클라우드에 상주하는 데이터에 보편적으로 액세스하는 이러한 이야기에서 빠진 주요 요소 중 하나는 스트림, 즉 Kafka 토픽이었습니다. 오늘날, 저장된 모든 구조화된 데이터는 기본적으로 저장되거나 Iceberg로 ‘장식’될 수 있습니다.  반면에 실시간 앱을 지원하는 스트리밍 플랫폼을 통해 흐르는 고부가가치 데이터는 여전히 포인트-투-포인트, 스트림별 데이터 통합 작업을 통해 대상 레이크하우스로 ‘ETL’하거나 자체 클러스터에서 비용이 많이 드는 커넥터 인프라를 실행해야 합니다. 두 접근 방식 모두 무거운 Kafka Consumer를 사용하므로 실시간 데이터 전달 파이프라인에 부담을 주고, 전문 Kafka 기술로 확장, 관리 및 관찰해야 하는 중간 인프라 구성 요소를 생성합니다. 두 접근 방식 모두 실시간 및 분석 데이터 에스테이트 사이에 매우 비싼 통행료를 부과하는 것과 같으며, 이는 실제로 존재할 필요가 없습니다. 

스트림 백업을 위한 클라우드 객체 스토어 사용이 성숙해지고(Redpanda는 몇 년 전 이러한 흐름을 주도했습니다) 오픈 테이블 형식이 레이크하우스에서 중심이 되면서, 스트림-투-테이블의 이러한 결합은 편리하고 ‘운명적’입니다. Databricks와 Redpanda는 이 접근 방식을 빛나게 하고 주목을 끄는 두 가지 세계적 수준의 데이터 플랫폼을 제공합니다. 함께, 그들은 실시간 의사 결정, 분석 및 AI에 걸쳐 경쟁하기 어려운 데이터 기반을 만듭니다. 실제로 이 접근 방식은 구성 플래그의 용이성으로 스트림과 테이블을 병합합니다. 이는 선택 가능한 스트림을 주문형으로 통합 데이터 레이크로 라우팅하는 다중 챔버 댐처럼 작동하여 최신 인사이트를 제공하고, 레이크하우스 아키텍처가 테이블에 제공했던 새로운 분석 파이프라인 내 데이터의 임의 포함을 가능하게 하며, 이제 Iceberg 생태계가 제공하는 넓어진 조리개를 통해 가능하게 합니다.  

실시간 및 분석 데이터 인프라를 원활하게 융합하여 ‘스트림으로 공급되는 레이크하우스’를 푸시 버튼 방식으로 만드는 것은 엄청난 가치를 발휘할 뿐만 아니라, 일반적인 경우에 제대로 해결하기 위해 신중한 접근 방식이 필요한 어려운 엔지니어링 문제를 해결합니다. 아래에서 설명하듯이, 이 기능을 시장에 출시하기 위해 서두르면서 아무런 타협도 하지 않았습니다. 1년 이상 수십 개의 디자인 파트너(및 Databricks)와 협력하여 고객이 선호하는 배포 옵션(여러 클라우드에서 BYOC 포함)을 유지하고, 완전한 Kafka 호환성(모든 워크로드를 남기지 않음)을 유지하며, 가능한 한 사용자에게 아티팩트 및 단계의 중복을 피하는 방식으로 Redpanda의 단일 코드베이스를 확장했습니다. Redpanda Iceberg Topics 구축을 위한 기본 원칙을 설명하면서 이러한 완전한 비전이 전달되기를 바랍니다. Redpanda Iceberg Topics는 이제 AWS 및 GCP에서 Databricks Unity Catalog와 함께 사용할 수 있습니다!

스트림-투-레이크하우스 플랫폼을 어디서든 실행하세요 

첫 번째 원칙은 선택권을 유지하고 사용자가 있는 곳에서 만나는 것이었습니다. Redpanda는 이미 성숙한 멀티 클라우드 SaaS, BYOC 및 셀프 관리형 제품, BYOVPC와 같은 프라이빗 소버린 네트워킹 옵션을 제공하며, 일반적으로 고객이 클라우드, 네트워크, 객체 스토어, IdP 또는 채택을 제한하거나 플랫폼 소유자가 스트리밍 플랫폼 배포(데이터 및 제어 플레인 모두 포함)를 배치하는 데 가장 적합한 곳에 배치하는 것을 방해하는 것을 강요하지 않습니다. 해당 선택에 관계없이 사용자는 개발자와 관리자 모두에게 플랫폼의 모든 기능과 일관된 UX를 얻습니다. 이 단일 플랫폼 제품 전략을 통해 Databricks용 Iceberg Topics가 오늘날 AWS, GCP 및 Azure 클라우드에서 일반적으로 사용 가능하며, 조직이 클라우드를 전환하거나 새로운 폼 팩터로 변경할 때 동일한 제품, 동일한 기본 엔진, Kafka 호환성, 보안 모델, 성능 특성 및 관리 도구를 배포한다는 것을 알고 자신 있게 배포할 수 있다고 발표할 수 있습니다. 이러한 광범위한 유연성과 일관성은 시장의 다른 옵션과 극명하게 대조됩니다.

Unity Catalog, 가장 통합된 스트리밍 플랫폼을 만나보세요

둘째, 우리는 이것을 단일 시스템으로 구축하는 데 단호했으며, 실제로 그렇게 느껴지는 시스템을 구축했습니다. 완전히 다른 두 가지 소프트웨어 아키텍처를 함께 볼트로 고정하여 두 가지 개념을 잘 융합할 수는 없습니다.  SaaS 베니어로 일부를 덮을 수는 있지만, 부풀려진 아키텍처는 최소한 가격 모델, 성능 및 TCO에서 드러나며, 최악의 경우 사용자 경험으로 이어집니다. 우리는 그것을 피하기 위해 최선을 다했습니다.

개발자에게 단일 시스템이라는 '느낌'은 단일 CRUD 라이프사이클과 테이블로서의 토픽에 대한 일관된 UX, 그리고 이를 작동시키는 데 필요한 것들(즉, 스키마)을 의미합니다.  Iceberg Topics를 사용하면 항목이나 구성을 복사하거나 별도의 UI를 사용하여 두 번 생성할 필요가 없습니다.  데이터와 스키마 모두에 대한 단일 진실 공급원을 하나의 엔티티로 관리하며, 항상 동일한 도구를 사용합니다. 저희에게는 이미 사용 중인 도구를 통해 CRUD 작업을 수행한다는 의미입니다. 즉, 모든 Kafka 생태계 도구, 저희의 rpk CLI, Cloud REST API 또는 저희 K8s CR 또는 Terraform provider와 같은 Redpanda 배포 자동화 도구를 사용합니다. 스키마의 경우, 널리 인정받는 표준 API를 사용하는 내장 Schema Registry를 사용하며, 선호에 따라 Iceberg 테이블 스키마를 암시적으로 또는 명시적으로 정의합니다. 모든 것은 구성 기반이며 DevOps 친화적입니다. 그리고 Unity Catalog의 새로운 관리형 Iceberg 테이블을 사용하면 모든 스트림은 기본적으로 Iceberg 및 Delta Lake 테이블로 Databricks 도구를 통해 검색 가능합니다.

단일 시스템은 플랫폼 운영자에게도 해당됩니다. 운영자는 여러 버킷이나 카탈로그를 관리하거나, Parquet 파일 크기를 조정하거나, 클러스터가 리소스 제약으로 인해 테이블이 스트림보다 뒤처지거나, 노드 장애로 인해 정확히 한 번 전달이 손상되는 것에 대해 걱정할 필요가 없습니다.  Redpanda Iceberg Topics를 사용하면 이 모든 것이 자동화됩니다. 운영자는 데이터 도착 SLA에 맞춰 조정되는 동적 배치 Parquet 쓰기 및 트랜잭션 Iceberg 커밋, 필요 시 Kafka Producer 백프레셔를 생성하는 자동 지연 모니터링, 인프라 장애 후 간격이나 중복을 방지하는 Iceberg 스냅샷 태깅을 통한 정확히 한 번 전달의 이점을 누릴 수 있습니다. 

Redpanda는 단일 버킷/컨테이너에서 모든 데이터를 관리하고, Unity Catalog에서 단일 Iceberg 카탈로그를 사용하며(Redpanda가 정상 복구를 위해 모니터링), Redpanda Cloud UI에 Unity Catalog의 Iceberg REST 엔드포인트를 바로 표시하여 테이블을 쉽게 검색할 수 있도록 합니다. 이제 Unity Catalog 관리형 Iceberg 테이블을 사용하면 컴팩션, 데이터 만료, 예측 최적화와 같은 테이블 유지 관리 작업이 내장되어 Unity Catalog에서 백그라운드에서 자동으로 실행되며, Redpanda는 최소한의 유지 관리 작업(현재 Iceberg 스냅샷 정리 및 테이블 생성/삭제)을 담당합니다. 그러면 Databricks 관리자는 일반적인 Unity Catalog 권한을 사용하여 이러한 테이블을 보호하고 관리할 수 있습니다.  

모든 것을 지배하는 하나의 클러스터

가장 중요하게는, 스레드당 코어 아키텍처를 사용하고 쓰기 캐싱 및 다단계 데이터 및 워크로드 밸런싱과 같은 기능을 포함하는 저희 R1 멀티모달 스트리밍 엔진 덕분에 관리자는 이 고처리량 Iceberg 수집을 동일한 클러스터에서, 그리고 기존 저지연 Kafka 워크로드를 서브-10ms SLA로 지원하는 것과 동일한 토픽으로 실행할 수 있습니다.  Produce/Consume 요청을 처리하는 동일한 CPU 코어에 고정된 비동기 파이프라인 작업을 사용하여 단일 프로세스에서 최대 효율로 두 워크로드를 처리합니다. 가장 중요한 것은 Iceberg Topics가 트랜잭션 커밋된 트랜잭션의 레코드만 수신하는 Iceberg 계층과 함께 Kafka 트랜잭션 및 컴팩트된 토픽을 포함한 전체 Kafka 의미 체계를 활용할 수 있다는 것입니다. 정교한 의미 체계의 어려운 문제를 해결하는 근본적으로 효율적인 아키텍처의 조합은 운영 비용을 절감하는 데 큰 이점을 제공합니다. 왜냐하면, 모든 것을 지배하는 하나의 클러스터이기 때문입니다.  추가 제품 없음. 별도의 클러스터 없음. 파이프라인 관리 불필요. 어디에나 배포 가능.  스트리밍 플랫폼 관리자는 침착하게 계속 진행하세요.

간단하게 만들기

저희의 세 번째 원칙은 기본 동작에 대한 몇 가지 의견을 제시하는 선택을 하여, 대부분의 사용 사례에 맞는 가장 스마트한 자동 구성으로 사용자가 점진적으로 시스템을 학습할 수 있도록 하는 것입니다.  이는 내장된 시간별 테이블 파티셔닝(Kafka 토픽 파티션 체계와 완전히 분리됨), 잘못된 데이터를 캡처하기 위한 테이블로서 항상 켜져 있는 오류 큐, 그리고 스키마 추론을 위한 '최신 버전' 또는 'TopicNameStrategy'와 같은 간단하고 표준적인 규칙은 쉽게 채택할 수 있도록 합니다. 또한 메시지 파티션, 오프셋 및 키와 같은 Kafka 메타데이터를 Iceberg Struct로 가져오므로 개발자는 Iceberg SQL에서 스트리밍 파이프라인의 정확성을 신속하게 검증하는 데 필요한 모든 출처 정보를 얻을 수 있습니다.  

물론 간단한 것은 간단해야 하지만, 복잡한 것도 쉬워야 합니다. 따라서 Iceberg 사용자 지정 파티셔닝의 전체 세트와 함께 계층적 파티션 변환을 정의하거나, 주제 내에서 특정 Protobuf 메시지 유형을 가져와 Iceberg 테이블 스키마로 만드는 것은 다시 말하지만, 선언적인 한 줄 토픽 속성일 뿐입니다.  Redpanda는 인플레이스 테이블 진화를 적용하므로 스키마는 원활하게 진화할 수 있습니다. 그리고 필요한 경우, 온보드 데이터 변환(WebAssembly 기반)을 사용하여 원시 토픽에서 복잡한 메시지를 더 간단한 Iceberg 팩트 테이블로 분산하는 좋아하는 언어의 간단한 SMT를 실행하십시오. 궁극적인 목표는 단일 패스로 분석 준비된 데이터를 저장하는 것입니다.  붐, 브론즈 레이어에 오신 것을 환영합니다.

이 모든 혁신의 배경에는 물론 빠르게 발전하는 Apache Iceberg 프로젝트 및 사양이 있으며, Redpanda는 일반적으로 개방형 표준에 대한 약속을 지키고 있습니다. 그 약속은 Kafka 프로토콜, 스키마 레지스트리 및 HTTP 프록시 API에 대한 초기 지원, 심지어 조직이 Kafka 애플리케이션 전체를 변경 없이 원활하게 마이그레이션할 수 있도록 하는 표준 토픽 구성과 같은 다른 세부 사항으로 시작되었습니다. Iceberg 영역에서 Redpanda는 커뮤니티에서 헌신적인 선구자로서 입지를 다졌으며, 처음부터 완전한 C++ Iceberg 클라이언트를 구현했습니다(오픈 소스로는 제공되지 않음). 이 클라이언트는 전체 Iceberg V2 테이블 사양, 모든 스키마 진화 규칙 및 파티션 변환을 지원합니다.  Iceberg 카탈로그 측면에서 Redpanda는 파일 기반 카탈로그를 제공하고 Unity Catalog와 같은 원격 카탈로그에서 생성, 커밋, 업데이트 및 삭제와 같은 작업을 위해 Iceberg REST를 사용하며, OIDC 인증을 지원하여 클라우드 제공업체의 비밀 관리자에 투명하게 암호화된 비밀로 Unity Catalog 자격 증명을 신중하게 처리합니다. Redpanda는 또한 Databricks 및 기타 Iceberg 리더와 긴밀히 협력하여 Variant 유형을 통해 반구조화된 스트림 데이터를 지원하도록 사양을 확장하는 방법과 두 플랫폼 간에 정책을 동기화하여 테이블 RBAC 관리를 더욱 원활하게 만드는 방법을 모색했습니다. 이 표준화와 항상 사양에 따라 구현하는 것은 최소한의 벤더 종속성을 의미합니다. 조직은 더 나은 옵션을 찾으면 언제든지 시스템의 모든 부분을 교체할 수 있습니다: 스트리밍 플랫폼, Iceberg 카탈로그 또는 테이블을 쿼리/처리하는 레이크하우스. 

지금까지 읽으셨다면, Redpanda의 접근 방식에 담긴 사려 깊은 엄격함이 이 뜨거운 시장 기회에 어떻게 부응하는지 느끼셨기를 진심으로 바랍니다. 이는 강력한 엔지니어링 문화와 견고한 제품 구축에 대한 열정에서 비롯됩니다.  탄탄한 실적을 가진 기술자로서, 특히 BYOC 폼 팩터에 중점을 두어 Redpanda와 Databricks는 하나처럼 작동하고 느껴지는 두 가지 최고의 플랫폼을 제공하기 위해 완벽하게 조정되었으며, 이를 통해 스트림-투-테이블 문제를 잘 해결할 수 있습니다.

지금 Redpanda의 고유한 클라우드 제공업체 자체 구축(Bring-Your-Own-Cloud) 옵션을 사용하여 Unity Catalog에서 Iceberg 토픽을 사용해 보세요.  또는 자체 관리형 버전인 Redpanda Enterprise의 무료 평가판으로 시작하세요!: https://cloud.redpanda.com/try-enterprise.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)