아이스버그 카탈로그: 데이터 엔지니어를 위한 안내서

튜토리얼
AWS

Apache Iceberg는 유연성과 확장성을 갖춘 대규모 데이터 세트를 관리하는 인기 있는 선택이 되었습니다. 카탈로그는 Iceberg의 기능에서 중심적인 역할을 하며, 이는 테이블 조직, 일관성 및 메타데이터 관리에 필수적입니다. 이 글에서는 Iceberg 카탈로그가 무엇인지, 다양한 구현, 사용 사례 및 구성에 대해 살펴보며, 다양한 사용 사례에 적합한 카탈로그 솔루션에 대한 이해를 제공합니다.

Iceberg 카탈로그란?

Iceberg에서 카탈로그는 테이블 경로를 관리하고, 테이블 상태를 나타내는 현재 메타데이터 파일을 가리키는 역할을 합니다. 이 아키텍처는 모든 독자와 작성자가 테이블의 동일한 상태에 접근하도록 보장하여 원자성, 일관성 및 효율적인 쿼리를 가능하게 하므로 필수적입니다. 다양한 카탈로그 구현은 이 메타데이터를 파일 시스템에서 전문 메타스토어 서비스에 이르기까지 다양한 방법으로 저장합니다.

Iceberg 카탈로그의 핵심 책임

Iceberg 카탈로그의 기본 책임은 다음과 같습니다:

  1. 테이블 경로 매핑: 테이블 경로(예: “db.table”)를 해당 메타데이터 파일에 연결합니다.
  2. 원자적 작업 지원: 동시 읽기/쓰기 동안 일관된 테이블 상태를 보장합니다.
  3. 메타데이터 관리: 메타데이터를 저장하고 관리하여 접근성과 일관성을 보장합니다.

아이스버그 카탈로그는 다양한 시스템 아키텍처와 저장 요구 사항을 수용하기 위해 여러 가지 구현을 제공합니다. 이러한 구현과 다양한 환경에 대한 적합성을 살펴보겠습니다.


아이이스버그 카탈로그의 유형

1. 하둡 카탈로그

하둡 카탈로그는 일반적으로 설정하기 가장 쉬우며, 파일 시스템만 필요합니다. 이 카탈로그는 파일 타임스탬프를 기반으로 테이블의 디렉토리에서 가장 최근의 메타데이터 파일을 조회하여 메타데이터를 관리합니다. 그러나 파일 수준의 원자적 작업에 의존하기 때문에(일부 저장 시스템인 S3에는 이러한 기능이 부족함) 하둡 카탈로그는 동시 쓰기가 일반적인 프로덕션 환경에는 적합하지 않을 수 있습니다.

구성 예시

하둡 카탈로그를 아파치 스파크와 함께 구성하려면:

SQL

 

스파크 작업 자체에서 카탈로그를 설정하는 다른 방법:

SQL

 

위의 예에서 카탈로그 이름을 “local”로 설정했습니다. 이는 스파크 “spark.sql.catalog.local“에 구성된 대로입니다. 이는 원하는 이름으로 설정할 수 있습니다.

장점:

  • 설정이 간단하며, 외부 메타스토어가 필요하지 않습니다.
  • 개발 및 테스트 환경에 이상적입니다.

단점:

  • 단일 파일 시스템(예: 단일 S3 버킷)으로 제한됩니다.
  • 프로덕션에는 권장되지 않습니다.

2. 하이브 카탈로그

Hive 카탈로그은 메타데이터 위치를 관리하기 위해 Hive 메타스토어를 활용하여 다양한 빅데이터 도구와 호환되도록 합니다. 이 카탈로그는 기존의 Hive 기반 인프라와 다중 쿼리 엔진과의 호환성으로 인해 프로덕션에서 널리 사용됩니다.

구성 예시

Spark에서 Hive 카탈로그를 사용하려면:

SQL

 

장점:

  • 기존의 다양한 빅데이터 도구와 높은 호환성.
  • 온프레미스 및 클라우드 설정에서 클라우드에 중립적이고 유연.

단점:

  • Hive 메타스토어 유지가 필요하여 운영 복잡성이 증가할 수 있습니다.
  • 다중 테이블 트랜잭션 지원이 없어 테이블 간 작업의 원자성이 제한됩니다

3. AWS Glue 카탈로그

AWS Glue 카탈로그은 AWS에서 제공하는 관리형 메타데이터 카탈로그로, AWS 생태계에 많은 투자를 한 조직에 이상적입니다. AWS Glue 내에서 Iceberg 테이블 메타데이터를 테이블 속성으로 처리하여 다른 AWS 서비스와의 원활한 통합을 가능하게 합니다.

구성 예시

Spark에서 Iceberg를 사용하여 AWS Glue를 설정하려면:

SQL

 

장점:

  • 인프라 및 유지보수 오버헤드를 줄이는 관리형 서비스.
  • AWS 서비스와의 강력한 통합.

단점:

  • AWS에 특화되어 있어 다중 클라우드 유연성이 제한됩니다.
  • 다중 테이블 트랜잭션을 지원하지 않습니다

4. Project Nessie Catalog

프로젝트 네시(Project Nessie)는 데이터 버전 관리를 가능하게 하는 “코드로서의 데이터(data as code)” 접근 방식을 제공합니다. Git과 유사한 브랜칭 및 태깅 기능을 통해 사용자는 소스 코드와 유사한 방식으로 데이터 브랜치를 관리할 수 있습니다. 이는 다중 테이블 및 다중 문장 트랜잭션을 위한 강력한 프레임워크를 제공합니다.

설정 예시

네시를 카탈로그로 설정하려면:

SQL

 

장점:

  • 버전 관리 기능을 갖춘 “코드로서의 데이터” 기능을 제공합니다.
  • 다중 테이블 트랜잭션을 지원합니다.

단점:

  • 셀프 호스팅이 필요하여 인프라 복잡성이 추가됩니다.
  • Hive 또는 AWS Glue에 비해 제한된 도구 지원이 있습니다.

5. JDBC 카탈로그

JDBC 카탈로그를 사용하면 PostgreSQL이나 MySQL과 같은 JDBC 호환 데이터베이스에 메타데이터를 저장할 수 있습니다. 이 카탈로그는 클라우드에 구애받지 않으며, 신뢰할 수 있는 RDBMS 시스템을 사용하여 높은 가용성을 보장합니다.

설정 예시

SQL

 

장점:

  • 기존 RDBMS 인프라로 쉽게 설정할 수 있습니다.
  • 높은 가용성과 클라우드 비종속적입니다.

단점:

  • 다중 테이블 트랜잭션을 지원하지 않습니다.
  • 모든 액세스 도구에 대한 JDBC 드라이버에 대한 의존성이 증가합니다.

6. 스노우플레이크 카탈로그

스노우플레이크는 아파치 아이스버그 테이블에 대한 견고한 지원을 제공하여 사용자가 스노우플레이크의 플랫폼을 아이스버그 카탈로그로 활용할 수 있습니다. 이 통합은 스노우플레이크의 성능과 쿼리 의미론을 아이스버그의 오픈 테이블 형식의 유연성과 결합하여 외부 클라우드 저장소에 저장된 대규모 데이터 집합을 효율적으로 관리할 수 있게 합니다. 추가 구성에 대한 자세한 내용은 스노우플레이크 문서를 참조하십시오. 링크

장점:

  • 무결점 통합: 스노우플레이크의 성능과 쿼리 기능을 아이스버그의 오픈 테이블 형식과 결합하여 효율적인 데이터 관리를 용이하게 합니다.
  • 전체 플랫폼 지원: ACID 트랜잭션, 스키마 진화, 타임 트래블과 같은 기능을 포함한 포괄적인 읽기 및 쓰기 액세스를 제공합니다.
  • 간소화된 유지보수: 스노우플레이크는 압축 및 운영 오버헤드 감소와 같은 라이프사이클 작업을 처리합니다.

단점:

  • 클라우드 및 지역 제약: 외부 볼륨은 스노우플레이크 계정과 동일한 클라우드 제공업체 및 지역에 있어야 하며, 크로스 클라우드 또는 크로스 지역 구성을 제한합니다.
  • 데이터 형식 제한: 모든 조직의 데이터 형식 기본 설정과 일치하지 않을 수 있는 아파치 파케이 파일 형식만 지원합니다.
  • 타사 클라이언트 제한: Snowflake에서 관리하는 Iceberg 테이블의 데이터 수정을 방지하여 외부 도구에 의존하는 워크플로에 영향을 줄 수 있는 타사 클라이언트의 작업을 방지합니다.

7. REST 기반 카탈로그

Iceberg는 전통적인 카탈로그 구현과 관련된 여러 문제를 해결하기 위해 REST 기반 카탈로그를 지원합니다.

전통적인 카탈로그의 문제점

  1. 클라이언트 측 복잡성: 전통적인 카탈로그는 종종 각 언어(Java, Python, Rust, Go)에 대해 클라이언트 측 구성 및 종속성을 필요로 하며, 서로 다른 프로그래밍 언어 및 처리 엔진 간에 일관성 부족으로 이어질 수 있습니다. 자세한 내용은 여기를 참조하십시오.
  2. 확장성 제약: 클라이언트 수준에서 메타데이터 및 테이블 작업을 관리하는 것은 병목 현상을 유발할 수 있어 대규모 데이터 환경에서 성능과 확장성에 영향을 줄 수 있습니다.

REST 카탈로그 채택의 장점

  • 간편한 클라이언트 통합: 클라이언트는 표준 HTTP 프로토콜을 사용하여 REST 카탈로그와 상호 작용할 수 있으므로 복잡한 구성이나 종속성이 필요하지 않습니다.
  • 확장성: REST 카탈로그의 서버 측 아키텍처는 성장하는 데이터 세트 및 동시 액세스 패턴을 수용할 수 있는 확장 가능한 메타데이터 관리를 가능하게 합니다.
  • 유연성: 조직은 서버 측에서 사용자 정의 카탈로그 논리를 구현하여 REST 카탈로그를 특정 요구 사항에 맞게 맞춤화할 수 있습니다. 클라이언트 응용 프로그램을 수정하지 않고도.

REST 카탈로그의 여러 구현이 나타났으며, 각각은 특정 조직의 요구 사항을 충족시킵니다:

  • Gravitino: 스파크 및 기타 처리 엔진과 통합을 용이하게 하는 오픈 소스 아이스버그 REST 카탈로그 서비스로, 아이스버그 테이블을 관리하기 위한 간단한 설정을 제공합니다.
  • Tabular: REST 카탈로그 인터페이스를 제공하는 관리형 서비스로, 카탈로그 인프라를 관리하지 않고도 Iceberg의 기능을 활용할 수 있습니다. 더 많은 정보는 Tabular에서 확인할 수 있습니다.
  • Apache Polaris: Apache Iceberg를 위한 완전한 기능을 갖춘 오픈 소스 카탈로그로, REST API를 구현하여 Apache Doris, Apache Flink, Apache Spark, StarRocks, Trino 등의 플랫폼 간의 원활한 다중 엔진 상호 운용성을 보장합니다. 더 많은 정보는 GitHub에서 확인할 수 있습니다.

아이스버그 테이블과 함께 REST 카탈로그를 시도해보는 제가 좋아하는 간단한 방법 중 하나는 일반적인 Java REST 구현을 사용하는 것입니다. GitHub 링크는 여기를 확인해주세요.

결론

적절한 Apache Iceberg 카탈로그를 선택하는 것은 데이터 관리 전략을 최적화하는 데 중요합니다. 여기에는 결정을 안내할 간결한 개요가 있습니다:

  • Hadoop 카탈로그: 간결함으로 인해 개발 및 테스트 환경에 가장 적합합니다. 그러나 병렬 쓰기로 인한 일관성 문제가 발생할 수 있습니다.
  • Hive 메타스토어 카탈로그: 기존 하이브 인프라를 갖춘 조직에 이상적입니다. 다양한 빅데이터 도구와 호환성을 제공하며 복잡한 데이터 작업을 지원합니다. 그러나 하이브 메타스토어 서비스를 유지하는 것은 운영 복잡성을 증가시킬 수 있습니다.
  • AWS Glue 카탈로그: AWS 생태계에 크게 투자한 경우 최적입니다. AWS 서비스와의 원활한 통합을 제공하며 자체 관리형 메타데이터 서비스의 필요성을 줄입니다. 그러나 AWS 전용이므로 다중 클라우드 유연성이 제한될 수 있습니다.
  • JDBC 카탈로그: 메타데이터 저장을 위해 관계형 데이터베이스를 선호하는 환경에 적합하며 모든 JDBC 호환 데이터베이스를 사용할 수 있습니다. 이는 유연성을 제공하고 기존 RDBMS 인프라를 활용하지만 추가 종속성을 도입하고 데이터베이스 연결을 신중하게 관리해야 합니다.
  • REST 카탈로그: 카탈로그 작업을 위한 표준화된 API가 필요한 시나리오에 이상적입니다. 다양한 처리 엔진 및 언어 간의 상호 운용성을 향상시키며 클라이언트에서 카탈로그 구현 세부 정보를 분리합니다. 그러나 카탈로그 작업을 처리하기 위해 REST 서비스를 설정해야 하므로 초기 설정 복잡성이 추가될 수 있습니다.
  • 프로젝트 네시 카탈로그: 이는 Git과 유사한 버전 관리가 필요한 조직에 이상적입니다. 브랜치, 태깅, 멀티 테이블 트랜잭션을 지원합니다. 강력한 데이터 관리 기능을 제공하지만 네시 서비스를 배포하고 관리해야 하므로 운영 오버헤드가 발생할 수 있습니다.

이러한 카탈로그 옵션과 구성을 이해하면 정보에 기반한 선택을 할 수 있으며 귀하의 조직의 특정 요구 사항을 충족하기 위해 데이터 레이크 또는 레이크하우스 설정을 최적화할 수 있습니다.

Source:
https://dzone.com/articles/iceberg-catalogs-a-guide-for-data-engineers