오픈 테이블 형식과 오픈 카탈로그의 융합: 카탈로그 커밋의 일반 공급

카탈로그 커밋은 Delta를 Iceberg의 카탈로그 중심 모델과 일치시켜 레이크하우스를 통합하는 데 큰 진전을 이룹니다. 카탈로그 커밋을 사용하면 카탈로그는 Delta 테이블의 조정 시스템이 되어 엔진 간의 테이블 검색, 액세스 및 상태를 중개합니다.

오늘, 저희는 UC 관리형 테이블에 대한 카탈로그 커밋의 일반 공급(GA)을 발표하게 되어 기쁩니다. 이는 UC 관리형 테이블의 상호 운용성을 확장하고, UC의 거버넌스 기능을 강화하며, 다중 문장, 다중 테이블 트랜잭션을 포함한 새로운 기능을 지원하는 주요 플랫폼 업그레이드입니다.

이 블로그에서는 다음 내용을 다룰 것입니다…

• Delta와 Unity Catalog가 함께 발전하는 방법
• 카탈로그 커밋이 해결하는 문제점
• 카탈로그 커밋 작동 방식
• Unity Catalog 관리형 테이블에서 카탈로그 커밋을 활성화하는 방법

Delta Lake와 Unity Catalog의 발전

Delta Lake가 생성되었을 때, 레이크하우스는 먼저 개방형 클라우드 스토리지에 대한 안정적인 트랜잭션이 필요했습니다. 당시에는 카탈로그가 최신 데이터 워크로드를 조정하도록 설계되지 않았기 때문에 Delta는 혁신적인 아키텍처 선택을 했습니다. 바로 데이터 레이크 파일 시스템에 ACID 보장을 직접 적용한 것입니다. 이 기반이 레이크하우스를 가능하게 했습니다.

레이크하우스가 더 많은 팀, 엔진 및 AI 워크로드의 기록 시스템이 됨에 따라, 이러한 다양한 자산에 걸친 통합 거버넌스의 필요성이 중요해졌습니다. Unity Catalog는 이러한 누락된 거버넌스 계층을 제공했습니다. 즉, 클라우드, 형식, 엔진 전반에 걸쳐 데이터 및 AI 자산을 검색, 보호, 감사 및 조정할 수 있는 단일 장소입니다.

함께 Delta Lake와 Unity Catalog는 최신 레이크하우스의 기반을 형성했습니다. 그러나 Delta는 스토리지 계층에서 트랜잭션 상태를 관리하고 Unity Catalog는 카탈로그 계층에서 액세스를 관리하는 등 서로 나란히 작동했습니다. 이 아키텍처는 초기에는 충분했지만, 조직이 더 많은 엔진과 워크로드로 확장됨에 따라 이 설계는 새로운 조정 문제를 야기했습니다.

테이블 및 카탈로그 간 조정의 현재 과제

Delta의 원래 파일 시스템 중심 아키텍처는 데이터 레이크에 트랜잭션을 제공하는 데 강력했지만, 카탈로그가 여러 엔진에 걸쳐 테이블 ID, 액세스 및 상태를 일관되게 조정해야 하는 세상에는 설계되지 않았습니다. 조직이 데이터에 대한 요구 사항을 늘림에 따라 카탈로그 조정의 부족은 세 가지 지속적인 과제를 드러냈습니다.

1. "분할 두뇌" 문제: 외부 엔진이 개체 스토리지의 Delta 테이블에 직접 쓰는 경우 스키마와 같은 카탈로그 메타데이터가 실제 테이블 상태와 조용히 달라질 수 있습니다.
2. 다중 엔진, 다중 에이전트 액세스 확산: 각 엔진, 도구 및 에이전트는 테이블에 다르게 액세스할 수 있으며, 이는 테이블 검색의 파편화, 일관성 없는 감사, 시스템 전반의 행 또는 열 수준 제어에 대한 표준화된 적용 부재로 이어집니다.
3. 다중 테이블 트랜잭션 조정: 개방형 레이크하우스 아키텍처는 역사적으로 여러 테이블에 걸친 원자적 쓰기를 지원하지 않았으므로, 조직은 트랜잭션 워크로드를 위해 레거시 데이터 웨어하우스를 유지해야 했습니다.

과제 #1: “분할 두뇌” 문제 – 거버넌스 카탈로그와 테이블 동기화 유지

현재 카탈로그는 Delta 엔진의 읽기 또는 쓰기 경로에 없습니다. 따라서 Apache Flink와 같은 엔진이 스토리지 계층에 직접 쓰는 방식으로 테이블에 스키마 변경을 적용하려는 경우, 카탈로그는 이러한 변경 사항을 알지 못하게 되어 카탈로그 메타데이터와 실제 테이블 상태가 달라지는 “분할 두뇌” 상태가 발생합니다. 이는 조용한 메타데이터 드리프트와 다운스트림 파이프라인 실패를 초래할 수 있습니다.

과제 #2: 다중 엔진, 다중 에이전트 액세스 확산

최신 조직은 데이터를 분석하고, 파이프라인을 구축하고, AI를 지원하기 위해 여러 엔진과 도구를 사용합니다. 역사적으로 이러한 시스템은 정적 경로를 사용하여 개체 스토리지에서 직접 데이터에 액세스했습니다. 이는 워크로드를 물리적 스토리지에 밀접하게 결합시켜 테이블 검색을 어렵게 만듭니다. 또한 각 엔진이 스토리지 계층에서 직접 Delta 테이블을 읽기 때문에, 일반적으로 세분화된 권한만 지원하므로 모든 엔진에 걸쳐 일관된 행/열 수준 거버넌스를 적용하기가 매우 어렵습니다. 마찬가지로, 일관된 액세스 계층이 없어 엔진 전반의 활동을 캡처할 수 없으므로 데이터 액세스 감사가 파편화되어 관리자는 데이터가 실제로 어떻게 사용되는지에 대한 일관되지 않은 보기를 가질 수 있습니다.

조직은 데이터를 검색, 거버넌스 및 감사할 중앙 집중식 장소가 필요합니다. AI 에이전트가 엔터프라이즈 데이터의 주요 소비자로 부상함에 따라 이러한 필요성은 더욱 시급해지고 있습니다.

과제 #3: 여러 테이블 간 트랜잭션 조정

데이터 웨어하우징 워크로드에는 종종 여러 테이블 트랜잭션이 필요합니다. 예를 들어, 다운스트림 판독기가 항상 일관된 보기를 볼 수 있도록 판매 및 재고 테이블을 원자적으로 업데이트하는 것과 같습니다. 그러나 Delta Lake의 기존 파일 시스템 중심 설계는 트랜잭션을 개별 테이블로 제한했습니다. 결과적으로 많은 조직이 레이크하우스 아키텍처로 통합하기를 원하더라도 이러한 워크로드를 위해 레거시 데이터 웨어하우스를 유지해야 했습니다.

카탈로그 커밋은 개방형 레이크하우스의 다음 진화입니다

카탈로그 커밋은 Delta 테이블이 카탈로그와 통합되기 위한 개방형 표준으로, 카탈로그가 테이블 액세스를 조정하고 최신 테이블 상태를 추적하는 책임을 맡도록 합니다. 이제 Delta와 Iceberg 모두 카탈로그 중심이 되었으므로 고객은 테이블이 표준화된 테이블 검색 및 거버넌스 모델을 갖추고 있다고 신뢰할 수 있습니다. 카탈로그 커밋 사양에 대해 자세히 알아보려면 Delta 프로토콜을 읽고 Unity Catalog의 카탈로그 커밋 참조 구현을 확인하세요.

Databricks에서는 UC 관리형 Delta 테이블에서 카탈로그 커밋을 활성화할 수 있습니다. 활성화되면 Unity Catalog는 모든 테이블 액세스를 중개하여 모든 엔진에 대한 일관된 검색 및 권한 부여 모델을 만듭니다. 이를 통해 조직은 자신의 환경에 대한 거버넌스를 진정으로 중앙 집중화할 수 있습니다.

카탈로그 커밋은 오래된 분할 두뇌, 다중 엔진 확산 및 다중 테이블 조정 문제를 해결합니다.

1. 분할 두뇌 문제 제거: 모든 엔진이 동일한 API를 통해 테이블에 액세스하므로 테이블 상태와 카탈로그가 동기화 상태를 유지하며, 조용한 메타데이터 드리프트의 위험을 제거합니다.

Unity Catalog 관리형 Delta 테이블에 쓰는 외부 엔진 활성화

"과거에는 거버넌스 레이크하우스에 스트리밍 데이터를 넣는다는 것은 카탈로그 메타데이터를 별도로 조정하고 아무것도 드리프트되지 않기를 바라는 것을 의미했습니다. 카탈로그 커밋은 그 간극을 완전히 제거합니다. StreamNative의 네이티브 Kafka 서비스(Kafka의 디스크리스, 리더리스 아키텍처를 위한 Ursa 기반)를 사용하면 데이터가 Unity Catalog를 통해 직접 스트리밍되고 커밋되므로 모든 레코드가 거버넌스된 행으로 저장되어 모든 엔진에서 즉시 쿼리할 수 있습니다."— Sijie Guo, 공동 창립자 겸 CEO, StreamNative

2. 다중 엔진 액세스 확산 해결: 모든 엔진과 에이전트가 테이블을 확인하기 위해 표준화된 카탈로그 API를 통과하므로 조직은 더 이상 스토리지 경로를 하드코딩하거나 거친 파일 시스템 수준 권한을 관리할 필요가 없습니다.

모든 엔진에 걸쳐 일관되고 향상된 거버넌스 활성화

3. 레이크하우스에서 기존 데이터 웨어하우징 워크로드 활성화: Databricks 엔진과 Unity Catalog는 여러 테이블에 걸쳐 원자적 쓰기를 조정할 수 있습니다. 이는 레이크하우스에 다중 테이블 ACID 의미론을 가져와 기존 데이터 웨어하우징 워크로드를 활성화합니다.

Databricks에서 다중 테이블 트랜잭션 수행 활성화

“트랜잭션과 SQL 스크립팅, 저장 프로시저와 같은 새로운 SQL 기능들을 통해 가장 중요한 웨어하우징 워크로드를 Databricks로 자신 있게 마이그레이션할 수 있습니다. 이러한 워크로드는 비즈니스 전반의 필수 분석을 지원하며, 레이크하우스에서 강력한 트랜잭션 보장을 제공하는 것은 게임 체인저입니다.” — Gal Doron, 데이터 총괄, AnyClip

또한 UC 관리 테이블에서 카탈로그 커밋을 활성화하면 다음과 같은 기능도 사용할 수 있습니다:

• 전체 감사 가능성: Unity Catalog는 테이블 메타데이터와 액세스 정책을 중앙 집중화하여, 팀이 낮은 수준의 스토리지 로그에만 의존하는 대신 일관된 카탈로그 인터페이스를 통해 권한과 테이블 소유권을 검사할 수 있도록 합니다.
• 자동화된 테이블 최적화: Unity Catalog는 모든 테이블 액세스에 대한 가시성을 활용하여 Liquid Clustering 및 Predictive Optimization을 통해 특정 쿼리 패턴에 맞게 조직의 데이터를 최적으로 구성합니다.
• 더 나은 성능을 위한 기반: Unity Catalog는 엔진이 클라우드 스토리지에서 메타데이터를 가져올 필요 없이 테이블 수준 메타데이터를 엔진에 직접 전달할 수 있어 메타데이터 지연의 주요 원인을 제거합니다.

이러한 기능들을 통해 카탈로그 커밋이 적용된 UC 관리 테이블은 현대적인 레이크하우스의 가장 개방적이고, 관리되며, 성능이 뛰어난 기반이 됩니다.

지금 테이블에서 카탈로그 커밋을 활성화하세요

Databricks의 카탈로그 커밋은 오늘부터 일반적으로 사용할 수 있습니다! Unity Catalog 관리 테이블에서 카탈로그 커밋을 활성화하면 다음과 같은 기능이 잠금 해제됩니다:

1. 향상된 상호 운용성: 외부 엔진에서 UC 관리 Delta 테이블에 쓰기
2. 강력한 거버넌스: 모든 엔진에 대한 일관되고 향상된 거버넌스 잠금 해제
3. 새로운 기능: 여러 문장, 여러 테이블 트랜잭션

데이터 수집부터 최종 소비까지 UC 관리 테이블을 읽거나 쓰는 Databricks 제품은 이제 카탈로그 커밋을 지원합니다. 여기에는 스트리밍 테이블, Delta Sharing, Zerobus, Lakeflow Connect, AI Gateway, MLflow 및 Lakeflow 작업 트리거가 포함됩니다. 마찬가지로, 카탈로그 커밋은 현재 Delta Spark, Delta Flink, Starburst Trino, DuckDB 및 StreamNative를 포함한 에코시스템 전반의 엔진에서 지원됩니다.

또한 프로토콜 수준의 세부 정보를 추상화하는 공유 API 라이브러리인 Delta Kernel과 통합하여 모든 엔진에서 카탈로그 커밋을 쉽게 지원할 수 있습니다. Delta Kernel을 사용하면 커넥터가 간단한 버전 업그레이드로 최신 Delta 기능을 쉽게 지원할 수 있습니다.

카탈로그 커밋이 활성화된 UC 관리 Delta 테이블을 만드는 것은 쉽습니다. Databricks Runtime 16.4 이상을 사용하여 다음을 실행하세요:

카탈로그 커밋을 활성화하기 위해 기존 UC 관리 Delta 테이블을 업그레이드하려면 Databricks Runtime 18.0 이상을 사용하고 다음을 실행하세요:

카탈로그 커밋으로 시작하고 개방형 레이크하우스를 구축하는 당사의 작업에 대해 자세히 알아보려면 데이터 및 AI 서밋에 참여하세요!

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