하나의 쓰기 경로, 다중 진입: Rippling이 Unity Catalog로 관리되는 Apache Iceberg™를 사용하는 방법

이 글은 Rippling의 데이터 플랫폼 부문 스태프 엔지니어인 Tae Lee의 기고문입니다.

Rippling에서는 테이블을 쓰는 엔진과 읽는 엔진이 항상 같지는 않습니다. Databricks 작업이 테이블을 생성할 수 있지만, 다운스트림 소비자는 Rippling Data Cloud의 Trino 기반 쿼리 레이어, Snowflake 또는 다른 레이크하우스 리더일 수 있습니다. 이 때문에 카탈로그 결정은 단순한 메타데이터 세부 정보 이상의 의미를 갖습니다. 즉, 누가 테이블을 쓸 수 있고, 누가 이를 유지 관리하며, 다른 엔진이 이를 어떻게 읽는지를 결정합니다.

즉, 목표는 모든 워크로드를 하나의 엔진이나 하나의 카탈로그로 강제하는 것이 아닙니다. 목표는 각 프로듀서가 가장 잘 실행되는 플랫폼을 사용하도록 하면서도, 다운스트림 시스템이 중복 없이 사용할 수 있는 거버넌스가 적용된 테이블을 게시하는 것입니다.

Unity Catalog 관리형 Iceberg 테이블은 이 아키텍처에서 Databricks가 생성하는 영역에 적용하는 패턴입니다.

카탈로그 소유권은 라이터를 따릅니다

저희의 카탈로그 전략은 간단한 규칙에서 시작합니다. 카탈로그는 라이터를 따라야 한다는 것입니다.

AWS 네이티브 컴퓨팅의 경우, AWS Glue Data Catalog를 사용합니다. 이는 Glue, Athena, EMR 또는 관련 인프라와 같은 AWS 엔진이 작성하는 워크로드에 자연스럽게 부합합니다.

Databricks에서 생성된 워크로드의 경우, Unity Catalog를 사용합니다. 이는 특히 Apache Iceberg™에 중요합니다. Databricks는 페더레이션을 통해 외부 Iceberg 테이블을 읽을 수 있지만, 이러한 테이블은 Unity Catalog 관리형 Iceberg 테이블과 다릅니다. Databricks가 테이블을 써야 하거나 워크로드가 Databricks의 성능 및 거버넌스에 크게 의존하는 경우, 해당 테이블은 UC 관리형이어야 합니다.

플랫폼 간에 공유해야 하는 Snowflake 생성 데이터의 경우, Snowflake 관리형 Iceberg 테이블과 함께 Snowflake Horizon Catalog를 사용합니다. 이는 프로듀서인 Snowflake에 의해 구동되는 별도의 카탈로그 결정입니다.

여기서 중요한 차이점이 있습니다. Iceberg는 오픈 테이블 포맷을 제공하지만, 메타데이터 커밋, 권한 및 테이블 수명 주기는 여전히 카탈로그가 소유한다는 점입니다. 포맷 이식성과 카탈로그 소유권은 서로 관련이 있지만 동일한 것은 아닙니다.

Databricks 워크로드에 관리형 Iceberg를 사용하는 이유

이 패턴을 도입하기 전에는 다른 곳에서 사용해야 하는 Databricks 생성 출력을 처리하기 위해 보통 추가적인 핸드오프가 필요했습니다. 즉, Databricks가 쓴 후 두 번째 복사본을 내보내거나, 소비 시스템에 직접 쓰고 Databricks가 다시 필요할 때 커넥터나 페더레이션 경로를 통해 다시 읽어오는 방식이었습니다. 두 접근 방식 모두 작동하지만, 중복 구체화(materialization), 추가 컴퓨팅 비용, 커넥터 고유의 제한 사항이 추가됩니다. 

Unity Catalog 관리형 Iceberg는 우리에게 더 명확한 경계를 제공합니다.

Databricks는 테이블을 네이티브하게 씁니다. Unity Catalog는 테이블 메타데이터, 액세스 모델 및 수명 주기를 소유합니다. 테이블 데이터와 Iceberg 메타데이터는 Rippling 소유의 S3 스토리지에 저장됩니다. 

외부 엔진은 Iceberg REST Catalog API 또는 카탈로그 페더레이션을 통해 연결됩니다. 자격 증명 벤딩(Credential vending)은 이러한 엔진에 기본 스토리지에 대한 범위가 지정된 액세스 권한을 부여합니다. 그런 다음 엔진은 자체 컴퓨팅을 사용하여 S3에서 직접 Parquet 파일을 읽습니다. 

이것이 저희에게 가장 중요한 특징입니다. Databricks 작업은 테이블을 한 번만 생성하면 되며, Trino, Snowflake, Spark, Athena, EMR과 같은 다운스트림 엔진은 표준 Iceberg 액세스 패턴을 통해 동일한 테이블을 사용할 수 있습니다. 소비자는 모든 쿼리를 다른 엔진의 SQL 언어나 실행 레이어를 통해 프록시 처리할 필요가 없으므로, 엔진 간 변환, 푸시다운(pushdown) 동작, 스로틀링, 다운스트림 읽기를 위한 프로듀서 측 컴퓨팅에 대한 의존도가 줄어듭니다. 

이것은 Databricks 내보내기가 아닙니다. Databricks 네이티브 프로듀서가 있는 오픈 Iceberg 테이블입니다.

ML 출력에서 Data Cloud까지

Rippling에서 ML 및 AI 워크로드는 여전히 사용 사례에 맞는 대상을 선택합니다. Delta 테이블, 벡터 데이터베이스, OpenSearch 또는 기타 목적별로 구축된 대상 등이 이에 해당합니다. 관리형 Iceberg는 선택된 게시 패턴일 뿐, 모든 ML 출력의 기본 대상은 아닙니다.

관리형 Iceberg가 중요한 역할을 하는 부분은 바로 핸드오프입니다. 선택된 출력의 경우, Databricks 작업은 Unity Catalog 관리형 Iceberg 테이블을 한 번만 게시하면 됩니다. 그러면 Rippling Data Cloud는 Trino 기반 액세스 패턴을 포함한 쿼리 레이어를 통해 동일한 테이블을 사용하고, 이를 다운스트림 변환, 대시보드 및 AI 기반 제품 기능에 활용할 수 있습니다.

아키텍처는 다음과 같습니다.

이를 통해 하나의 거버넌스가 적용된 테이블과 하나의 쓰기 경로를 확보할 수 있습니다. 다운스트림 소비자는 중복된 물리적 복사본이 필요하지 않으며, Lakeflow Jobs는 각 소비 시스템에 별도로 쓸 필요가 없습니다.

개방성만큼 중요한 운영

오픈 테이블 포맷은 이야기의 일부일 뿐입니다. Iceberg 테이블은 파일 압축(compaction), 스냅샷 만료, 고립된 파일(orphan) 정리, 통계 수집 등 여전히 유지 관리가 필요합니다.

Glue 카탈로그에 등록된 Iceberg 테이블의 경우, 해당 유지 관리는 AWS 네이티브 플랫폼 경로의 몫입니다. Glue에는 테이블 최적화 기능이 있지만, 이는 여전히 별도의 운영 모델입니다. 즉, 이러한 기능을 어디서 활성화할지, 어떻게 모니터링할지, Glue를 사용하는 워크로드의 동작을 어떻게 검증할지 결정해야 합니다.

Unity Catalog 관리형 Iceberg의 경우, Databricks는 관리형 테이블을 위한 자동 테이블 유지 관리, 파일 최적화 및 압축, 통계 수집, 데이터 레이아웃 최적화를 포함하여 Predictive Optimization을 통해 이러한 수명 주기를 더 많이 처리합니다. 테이블을 쓰는 동일한 플랫폼이 성능을 유지하는 데 필요한 대부분의 위생 관리(hygiene)도 처리하므로 매우 유용합니다.

이것이 저희가 UC 관리형 Iceberg를 단순한 상호 운용성 기능으로만 보지 않는 이유 중 하나입니다. 이는 운영 모델이기도 합니다. Databricks에서 생성된 테이블의 경우, 유지 관리 경로는 읽기 경로만큼이나 중요합니다.

종속성(Lock-In)에 대한 명확한 이해

이 아키텍처는 데이터 종속성을 줄여주지만, 모든 의존성을 제거하지는 않습니다.

데이터 종속성은 낮습니다. 테이블은 Rippling 소유의 S3 스토리지에 있는 Parquet 기반 Iceberg입니다.

다운스트림 엔진은 오픈 Iceberg 패턴을 통해 데이터를 직접 읽을 수 있습니다.

카탈로그 및 거버넌스 의존성은 실재합니다. Unity Catalog는 메타데이터, 권한, 리니지(lineage) 및 관리형 테이블 동작을 위한 컨트롤 플레인으로 유지됩니다. Databricks를 사용하지 않게 되더라도 데이터는 이식 가능하지만, 카탈로그 및 유지 관리 시스템을 교체해야 합니다.

이러한 부류의 테이블에 대해서는 이는 감수할 만한 절충안(trade-off)입니다. Databricks가 프로듀서이고 테이블이 거버넌스 하에 유지 관리되어야 하며 다른 엔진에서 읽을 수 있어야 할 때 UC는 제 역할을 톡톡히 해냅니다.

실질적인 결과

Unity Catalog 관리형 Iceberg의 가치는 모든 테이블에 대해 하나의 카탈로그를 제공한다는 점에 있지 않습니다. 실제로 그렇지도 않으며, 그것이 저희의 목표도 아닙니다.

그 가치는 개방형 다운스트림 소비가 필요한 Databricks 생성 테이블에 대해 단일 쓰기 경로를 제공한다는 점에 있습니다. Databricks는 네이티브 쓰기 및 최적화 경로를 확보하고, 다운스트림 시스템은 S3의 오픈 데이터에 직접 액세스할 수 있습니다. 

REST 카탈로그를 통해 테이블에 액세스하는 엔진은 원시 스토리지 경로를 통해 거버넌스를 우회하는 대신 동일한 메타데이터 및 액세스 레이어를 거칩니다.

이것이 바로 실질적인 결과입니다.

"Unity Catalog와 관리형 Iceberg는 우리에게 두 가지 장점을 모두 제공합니다. 즉, AI 및 ML 파이프라인을 위한 네이티브 성능과 모든 다운스트림 소비자를 위한 개방형 상호 운용성을 동시에 제공합니다. 하나의 쓰기 경로, 중복 제로, 그리고 Rippling의 Data Cloud를 위해 구축 중인 AI 기반 제품을 포함하여 모든 엔진이 준수하는 거버넌스 레이어를 제공합니다."

Rippling에게 상호 운용성이란 모든 엔진을 서로 대체 가능하게 만드는 것이 아닙니다. 각 엔진이 자신 있는 작업을 수행하도록 하면서도, 게시된 테이블을 이식 가능하고 거버넌스가 적용된 상태로 유지하여 이를 필요로 하는 시스템에서 사용할 수 있도록 하는 것입니다.

Unity Catalog 및 Iceberg 지원에 대해 자세히 알아보려면 Unity Catalog 제품 페이지를 방문해 보세요. 

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