AWS 기술 블로그
AWS에서의 Transactional Data Lake를 위한 오픈 테이블 형식(Open table format) 선택 가이드
이 글은 AWS Big Data Blog의 Choosing an open table format for your transactional data lake on AWS by Shana Schipers, Ian Meyers, and Carlos Rodrigues의 한국어 번역 및 편집본입니다.
2023년 8월: 이 게시물은 Amazon Redshift의 Apache Iceberg 지원을 포함하도록 업데이트되었습니다.
참고사항 – 오픈 테이블 형식(Open table format) 에 대한 AWS 서비스 지원의 급속한 발전으로 인해 최근 개발 내용이 아직 본 포스팅에 반영되지 않을 수 있습니다. 오픈 테이블 형식에 대한 AWS 서비스 지원에 대한 최신 정보는 공식 AWS 서비스 문서를 참조하십시오.
이제 기업은 최신 데이터 아키텍처 하에 자동화된 파이프라인을 사용하여 거의 모든 유형의 데이터를 데이터 레이크(data lake)에 수집할 수 있습니다. 데이터 레이크는 페타바이트 또는 엑사바이트 규모의 내구성이 뛰어나고 비용 효율적인 오브젝트 스토리지를 제공합니다. 이후 해당 데이터는 직접 액세스, 실시간 및 배치 워크플로를 통해 데이터 웨어하우스, 검색 시스템, 스트림 프로세서, 쿼리 편집기, 노트북 및 기계 학습 (ML) 모델과 같은 분석 서비스에 활용됩니다.
이렇듯 고객 데이터 레이크에 수집된 데이터는 다양한 사례에 활용됩니다(예: 금융 서비스 기업의 실시간 사기 거래 탐지, 소매업체의 재고관리 및 실시간 마케팅 캠페인, 관광/숙박 산업의 항공편 및 호텔 객실 가용성 확인 등). 모든 활용 분야에서 데이터 권한, 데이터 거버넌스 및 데이터 보호는 매우 중요한 요소이며 서비스를 사용하는 고객 역시 높은 수준의 데이터 보안, 암호화 및 수명 주기 관리를 중시합니다.
본 포스팅에서는 오픈 소스 트랜잭션 테이블 형식(또는 오픈 테이블 형식)을 사용하여 데이터 레이크의 성능, 비용, 거버넌스 및 개인 정보 보호와 관련된 복잡한(고급) 사례를 해결하는 방법을 보여드리고자 합니다. 이에 더불어 다양한 사례에서 실제 사용할 수 있는 가장 일반적인 오픈 테이블 형식의 특징과 기능에 대한 정보도 소개하고 있습니다.
특히, 데이터 레이크 워크로드에 적합한 오픈 테이블 형식을 선택할 때 본 포스팅을 가이드라인으로 참고함으로써 의사 결정 프로세스를 가속화하고 적용할 수 있는 범위를 좁힐 수 있습니다. 이 게시물의 내용은 작성 당시 검토된 형식인 Apache Hudi v0.13.0, Apache Iceberg 1.2.0, Delta Lake 2.3.0의 최신 오픈 소스 릴리스를 기반으로 합니다.
목차
최신 데이터 레이크의 고급 사용 사례
데이터 레이크는 비용, 확장성 및 유연성 측면에서 데이터를 저장하기 위한 최고의 선택지 중 하나입니다. 저렴한 비용으로 대용량의 정형 및 비정형 데이터를 보존하고 비즈니스 보고서, 빅데이터 처리, 실시간 분석 및 ML에 이르기까지 다양한 유형의 분석 워크로드에 데이터를 활용함으로써 더 나은 의사결정을 내릴 수 있습니다.
이러한 기능에도 불구하고 데이터 레이크는 ‘데이터베이스’가 아니며 오브젝트 스토리지는 ACID 처리 시맨틱(ACID processing semantics)을 지원하지 않습니다. ACID 처리 시맨틱은 다양한 기술을 사용하는 수백 또는 수천 명의 사용자에 대한 대규모 데이터를 효과적으로 최적화 및 관리하는 데 유용한 역할을 할 수 있습니다. 그 예는 다음과 같습니다.
- 비즈니스의 데이터 변경에 따라 효율적인 레코드 수준의 업데이트 및 삭제 수행
- 테이블이 수백만 개의 파일과 수십만 개의 파티션으로 확장됨에 따라 쿼리 성능 관리
- 여러 동시 라이터(Writer) 및 리더(Reader) 간의 데이터 일관성 보장
- 쓰기 작업의 중간 실패로 인한 데이터 손상 방지
- 데이터 세트를 (부분적으로) 다시 작성하지 않고도 시간이 지남에 따라 테이블 스키마 진화
이러한 문제는 관계형 데이터베이스 소스의 CDC (변경 데이터 캡처), 데이터 삭제를 요구하는 개인 정보 보호 규정, 대량의 저용량 파일이 생성될 수 있는 스트리밍 데이터 수집과 같은 사용 사례에서 더욱 두드러집니다. CSV, JSON, Parquet 또는 ORC와 같은 일반적인 데이터 레이크 파일 형식은 전체 파일의 쓰기만 허용하므로 앞서 언급한 요구 사항을 구현하기가 어렵고 시간과 비용이 많이 소요됩니다.
이러한 문제를 극복하기 위해 오픈 테이블 형식은 데이터 레이크의 최적화 및 관리 오버헤드를 간소화하는 데이터베이스와 유사한 추가 기능을 제공하는 동시에 Amazon Simple Storage Service (Amazon S3)와 같은 비용 효율적인 시스템에서의 스토리지를 지원합니다. 해당 기능은 다음과 같습니다.
- ACID 트랜잭션(ACID transactions) — 쓰기가 완전히 성공하거나 롤백(roll-back) 되도록 허용합니다.
- 레코드 수준 작업(Record-level operations) — 단일 행을 삽입, 업데이트 또는 삭제할 수 있습니다.
- 인덱스(Indexes) — 파티셔닝과 같은 데이터 레이크 기술 외에도 성능이 향상됩니다.
- 동시 제어(Concurrency control) — 여러 프로세스가 동일한 데이터를 동시에 읽고 쓸 수 있습니다.
- 스키마 진화(Schema evolution) — 테이블의 수명 동안 테이블의 컬럼을 추가하거나 수정할 수 있습니다.
- 시간 이동(Time travel) — 과거 특정 시점의 데이터를 쿼리할 수 있습니다.
일반적으로 오픈 테이블 형식은 단일 레코드의 다양한 버전을 여러 내부 파일에 저장하여 위와 같은 기능을 구현하고, 분석 엔진이 액세스 중인 레코드의 올바른 버전을 확인하고 수정할 수 있도록 추적 및 인덱싱 메커니즘을 사용합니다. 레코드가 업데이트되거나 삭제되면 변경된 정보가 새로운 파일에 저장됩니다. 읽기와 같은 작업이 요청되면 특정 레코드에 대한 파일을 검색하고, 오픈 테이블 형식 소프트웨어에 의해 조정됩니다.
이는 많은 트랜잭션 시스템에서 사용되는 강력한 아키텍처이지만 데이터 레이크에서는 성능 및 규정 준수 요구 사항을 준수하기 위해 해결해야 하는 몇 가지 사안이 있을 수 있습니다. 예를 들어, 오픈 테이블 형식에서 데이터를 삭제하면 삭제 마커(delete marker)만 저장되고 compaction [1]및 vacuum [2]작업을 수행하여 하드 삭제를 수행할 때까지만 원본 데이터가 보존되는 경우도 있습니다. 업데이트의 경우, 유사한 프로세스가 실행될 때까지 이전 버전의 레코드 값이 유지될 수 있습니다.
삭제해야 하는 데이터가 삭제되지 않거나 의도한 것보다 훨씬 많은 수의 파일을 저장하게 되어 스토리지 비용이 증가하고 읽기 성능이 저하될 수 있습니다. compaction 및 vacuum 작업은 오픈 테이블 형식의 작동 방식의 일부로, 또는 별도의 유지관리 절차로서 든 간에 정기적으로 수행되어야 합니다.
본 포스팅을 활용할 수 있는 방법
본 포스트는 사용 사례별 적합한 단일 테이블 형식을 추천해 드리지 않습니다. 기능 평가를 통해 각각의 사용 사례별 테이블 형식에 대한 주요 특징 및 주의 사항을 설명함으로써 의사 결정 프로세스의 속도를 높이는 것을 골자로 합니다. 특히, 사용자는 테스트를 수행하여 테이블 형식이 특정 사용 사례의 요구 사항을 충족하는지 확인하는 것이 중요합니다.
이 게시물은 AWS 기술 가이드와 오픈 소스 커뮤니티의 벤치마크에서 각각 제공되는 상세한 기술 지침 (예: 모범 사례) 이나 특정 파일 형식 각각에 대한 벤치마킹을 제공하기 위한 것이 아닙니다.
오픈 테이블 형식 선택
데이터 레이크의 오픈 테이블 형식을 선택할 때는 다음과 같은 두 가지 사항을 고려하는 것이 중요하다고 사료됩니다.
- 기능적 적합성(Functional fit) — 테이블 형식이 여러분의 사례를 효율적으로, 필요한 성능으로 구현하기 위한 주요 기능을 제공하고 있나요? 테이블 형식은 모두 공통된 기능도 제공하지만, 각 테이블 형식은 기반 기술 설계가 다르며 고유한 기능을 지원할 수 있습니다. 각 형식은 다양한 사용 사례를 처리할 수 있지만 각기 다른 장단점이 있으며 설계상 이유로 특정 상황(시나리오)에 효율적일 수 있습니다.
- 지원되는 통합(Supported integrations) — 테이블 형식이 여러분의 데이터 환경과 원활하게 통합되나요? 테이블 형식을 평가할 때는 조직의 읽기/쓰기 지원, 데이터 카탈로그 통합, 지원되는 액세스 제어 도구 등과 같은 차원에서 지원되는 엔진 통합을 고려하는 것이 중요합니다. 이는 AWS 서비스와의 통합 및 타사 도구와의 통합 모두에 적용됩니다.
일반 기능 및 고려 사항
다음 표에는 사용 사례와 관계없이 고려해야 할 각 파일 형식에 대한 일반적인 기능과 고려 사항이 요약되어 있습니다. 이 외에도 테이블 형식의 복잡성 및 사내 기술과 같은 다른 측면도 고려하는 것이 중요합니다.
| Apache Hudi | Apache Iceberg | Delta Lake | ||
| 기본 API∇ |
|
|
|
|
| 쓰기(Write) 모드 |
|
|
|
|
| 지원되는 데이터 파일 형식 |
|
|
|
|
| 파일 레이아웃 관리 |
|
|
|
|
| 쿼리 최적화 |
|
|
|
|
| S3 최적화 |
|
|
|
|
| 테이블 유지 관리 |
|
|
|
|
| 시간 이동(Time Travel) |
|
|
||
| 스키마 진화(Schema evolution) |
|
|
||
| 작업(operation) |
|
|
|
|
| 모니터링 |
|
|
|
|
| 데이터 암호화 |
|
|
|
|
| 환경 설정 옵션 |
읽기/쓰기 동작 (예: 인덱스 유형 또는 병합 로직)을 커스텀하고 자동으로 유지 관리 및 최적화 (예: 파일 크기 조정, compaction 및 정리)를 수행하기 위한 광범위한 설정 옵션 |
기본 읽기/쓰기 동작을 위한 설정 옵션 (Merge On Read 또는 Copy On Write 작업 모드) |
테이블 속성에 대한 제한된 설정 옵션 (예: 인덱싱된 컬럼) |
|
| 기타 |
|
|
|
|
| AWS 분석 서비스 지원* | ||||
| Amazon EMR | 읽기 및 쓰기 | 읽기 및 쓰기 | 읽기 및 쓰기 | |
| AWS Glue | 읽기 및 쓰기 | 읽기 및 쓰기 | 읽기 및 쓰기 | |
| Amazon Athena (SQL) | 읽기 | 읽기 및 쓰기 | 읽기 | |
| Amazon Redshift (Spectrum) | 읽기 | 현재 지원되지 않음 | 읽기 † | |
| AWS Glue Data Catalog‡ | 예 | 예 | 예 | |
∇테이블 형식에 대한 가장 광범위한 기능을 지원하는 Spark API
* 타사 도구의 테이블 형식 지원에 대해서는 해당 도구의 공식 문서를 참조하십시오.
† Amazon Redshift는 Delta Symlink 테이블만 지원합니다(자세한 내용은 Delta Lake에서 관리되는 데이터를 위한 외부 테이블 생성 참조하십시오).
‡ 다른 AWS 서비스와 함께 Lake Formation을 사용할 때의 테이블 형식 지원에 대한 내용은 Lake Formation 설명서의 “다른 AWS 서비스와 함께 사용하는 방법”을 참조하십시오.
일반적인 사용 사례별 적합한 기능
자, 이제 각각의 오픈 테이블 형식별 기능을 보다 깊이 이해하기 위해 사용 사례를 상세히 살펴보겠습니다.
데이터 레이크로 데이터 가져오기
이 섹션에서는 스트리밍 수집, 배치 적재(Batch load), 변경 데이터 캡처(CDC) 사용 사례에 대한 각 오픈 테이블 형식의 기능에 관해 설명합니다.
스트리밍 수집 (Streaming ingestion)
스트리밍 수집을 사용하면 큐(Queue), 토픽(Topic) 또는 스트림의 변경 사항을 데이터 레이크에 작성(write)할 수 있습니다. 구체적인 요구 사항은 사용 사례 유형에 따라 상이할 수 있으나, 일반적으로 스트리밍 데이터 수집에는 다음과 같은 기능이 필요합니다.
- 저지연 쓰기(low-latency writes) — 레코드 수준의 삽입, 업데이트 및 삭제를 지원합니다(예: 늦게 도착하는 데이터 지원).
- 파일 크기 관리 — (스트리밍 배치 당 하나 이상의 파일을 생성하여 수백만 개의 작은 파일이 생성되는 대신) 최적의 읽기 성능에 맞는 크기의 파일 생성이 가능합니다.
- 동시 리더(reader) 및 라이터(writer) 지원 — 스키마 변경 및 테이블 유지 관리를 포함합니다.
- 자동 테이블 관리 서비스 — 일관된 읽기 성능 유지가 가능합니다.
이 섹션에서는 변경 사항에 따라 이전 레코드를 업데이트하거나 삭제하지 않고 레코드가 파일에 삽입되기만 하는 스트리밍 수집에 관해 설명합니다. 일반적인 예로 시계열 데이터(예: 센서 판독 값)가 있는데, 여기서 각 이벤트는 데이터세트에 새 레코드로 추가됩니다. 다음 표에는 기능이 요약되어 있습니다.
| Apache Hudi | Apache Iceberg | Delta Lake | |
| 기능적 적합성 |
|
|
|
| 고려 사항 |
|
|
|
| 지원되는 AWS 통합 |
|
|
|
| 결론 | 추가 전용(append-only) 워크로드에 대한 환경 설정이 허용되는 경우 모든 추가 전용 스트리밍에 적합 | 더 큰 마이크로 배치 윈도우를 사용하는 추가 전용 스트리밍에 적합하며 테이블 관리 운영 오버헤드가 허용되는 경우에 적합 | 더 큰 마이크로 배치 윈도우를 사용하는 추가 전용 스트리밍에 적합하며 테이블 관리 운영 오버헤드가 허용되는 경우에 적합 |
데이터 레이크로 업데이트와 삭제가 포함된 데이터를 스트리밍할 때 가장 중요한 것은 업데이트의 영향을 받는 파일을 효율적으로 식별하여 빠른 upsert 및 delete를 가능하게 하는 것입니다.
| Apache Hudi | Apache Iceberg | Delta Lake | |
| 기능적 적합성 |
|
|
|
| 고려 사항 |
|
|
|
| 지원되는 AWS 통합 |
|
|
|
| 결론 | 스트리밍 upsert, upsert를 위한 인덱스, 자동 파일 크기 조정, compaction을 기본적으로 지원하므로 업데이트 및 삭제가 포함된 저지연 스트리밍에 적합 | 운영 오버헤드가 허용되는 경우 큰 마이크로 배치(micro-batch) 윈도우 스트리밍에 적합 | 지연 시간이 중요하지 않은 경우 업데이트/삭제를 스트리밍 데이터 수집에 사용할 수 있는데, 이는 Copy On Write 전략이 저지연 스트리밍 사례에 필요한 쓰기 성능을 제공하지 못할 수 있기 때문 |
변경 데이터 캡처
변경 데이터 캡처 (Change data capture, CDC)는 데이터베이스의 데이터 변경 사항을 식별하고 캡처한 다음 해당 변경 사항을 다운스트림 프로세스 또는 시스템에 실시간으로 전달하는 프로세스를 의미합니다. 본 사례는 데이터베이스에서 Amazon S3로 CDC 데이터를 전달하는 프로세스를 말합니다.
앞서 언급한 일반적인 스트리밍 요건 외에도 효율적인 CDC 처리를 위한 주요 요건은 다음과 같습니다.
- 효율적인 레코드 수준의 업데이트 및 삭제 — 수정할 파일을 효율적으로 식별할 수 있습니다 (이는 늦게 도착하는 데이터를 지원하는 데 중요함).
- CDC 기본 지원 — 다음 옵션 포함:
- 테이블 형식에서의 CDC 레코드 지원 — 테이블 형식은 CDC에서 생성한 레코드를 처리하는 방법을 이해하며, CDC 레코드를 테이블에 기록하기 위한 커스텀 사전 처리가 필요하지 않습니다.
- 테이블 형식을 기본적으로 지원하는 CDC 도구 — CDC 도구는 CDC에서 생성한 레코드를 처리하고 대상 테이블에 적용하는 방법을 이해합니다. 이 경우 CDC 엔진은 중간에 다른 엔진 없이 대상 테이블에 데이터를 씁니다.
두 가지 CDC 옵션을 지원하지 않는 경우, CDC 기록을 올바르게 처리한 후 대상 테이블에 적용하기 위해서는 커스텀 코드가 필요합니다. CDC 엔진을 사용하면 도구마다 고유한 CDC 레코드 형식 (또는 페이로드) 이 있을 수 있습니다. 예를 들어 Debezium과 AWS Database Migration Service (AWS DMS)는 각각 고유한 레코드 형식을 가지고 있으므로 서로 다른 방식으로 변환해야 합니다. 특히, 여러 테이블에서 대규모로 CDC를 운영할 때는 이 점을 중요하게 고려해야 합니다.
세 가지 테이블 형식 모두 원본 데이터베이스의 CDC를 대상 테이블로 구현할 수 있습니다. 각 형식에 따른 CDC의 차이점은 주로 CDC 파이프라인과 지원되는 통합의 구현이 용이한가에 있습니다.
| Apache Hudi | Apache Iceberg | Delta Lake | ||
| 기능적 적합성 |
|
|
||
| 고려 사항 |
|
|
|
|
| 기본적으로 지원되는 CDC 형식 |
|
|
|
|
| CDC 도구와의 통합 |
|
|
|
|
| 결론 | 세 가지 형식 모두 CDC 워크로드를 구현할 수 있습니다. Apache Hudi는 CDC 워크로드에 대한 전반적인 기술 적합성이 가장 뛰어날 뿐만 아니라 효율적인 CDC 파이프라인 설계를 위한 대부분의 옵션을 제공합니다. 이는 DeltaStreamer를 통한no-code/low-code, 네이티브 Hudi 통합을 제공하는 서드파티 CDC 도구, Hudi에서 제공되는 CDC 레코드 페이로드를 사용하는 Spark/Flink 엔진 등이 해당합니다. | |||
배치 적재
만약 쓰기(write)는 주기적으로만 발생하고 읽기(read)의 빈도수가 높을 경우, 배치 적재를 사용하고 읽기 성능을 최적화하는 것이 적합할 수도 있습니다.
업데이트와 삭제가 있는 데이터 배치 적재는 세 가지 테이블 형식으로 구현할 수 있는 가장 간단한 사용 사례일 것입니다. 배치 적재는 일반적으로 지연 시간이 짧을 필요가 없으므로 Copy On Write 전략의 운영 단순성을 활용할 수 있습니다. Copy On Write를 사용하면 데이터 파일을 다시 쓰면서 업데이트를 적용하고 새 레코드를 추가할 수 있으므로, 테이블에서 compaction 또는 최적화 테이블 서비스를 실행해야 하는 복잡성이 최소화됩니다.
| Apache Hudi | Apache Iceberg | Delta Lake | |
| 기능적 적합성 |
|
|
|
| 고려 사항 |
|
|
|
| 지원되는 AWS 통합 |
|
|
|
| 결론 | 세 가지 형식 모두 배치 적재에 적합합니다. Apache Hudi는 대부분의 환경 설정 옵션을 지원하므로 시작하기에는 수고로울 수 있지만, 자동 테이블 관리로 인해 운영 부담이 줄어듭니다. 반면 Iceberg와 Delta는 시작하기가 더 간단하지만, 테이블 유지 관리에 약간의 운영 오버헤드가 필요합니다. | ||
오픈 테이블 형식으로 작업하기
이 섹션에서는 가장 흔한 사용 사례(예: 읽기 성능 최적화, 증분 데이터 처리, 개인 정보 보호 규정 준수를 위한 삭제 처리 등)별 오픈 테이블 형식의 기능에 관해 설명합니다.
읽기 성능 최적화
이전 섹션에서는 주로 특정 사례별 쓰기 성능에 관해 이야기했습니다. 이제는 각 오픈 테이블 형식이 어떻게 최적의 읽기 성능을 지원할 수 있는지 살펴보겠습니다. 데이터가 순전히 쓰기에만 최적화되는 경우도 있지만, 일반적으로 읽기 성능은 오픈 테이블 형식을 평가하는 데 있어 매우 중요한 요소입니다.
쿼리 성능을 향상시키는 오픈 테이블 형식 기능은 다음과 같습니다.
- 인덱스, (컬럼) 통계, 기타 메타데이터 — 쿼리 플랜과 파일 프루닝(Pruning)를 개선하여 스캔하는 데이터를 줄입니다.
- 파일 레이아웃 최적화 — 쿼리 성능을 향상시킵니다.
- 파일 크기 관리 — 적절한 크기의 파일은 더 나은 쿼리 성능을 제공합니다.
- 쿼리 패턴에 따른 데이터 코로케이션 (클러스터링 사용) — 쿼리로 스캔하는 데이터의 양을 줄입니다.
| Apache Hudi | Apache Iceberg | Delta Lake | |
| 기능적 적합성 |
|
|
|
| 고려 사항 |
|
|
|
| 최적화 및 유지 관리 프로세스 |
|
|
|
| 결론 | 읽기 성능을 높이려면 쿼리 엔진이 테이블 형식에서 제공하는 최적화 기능을 지원하는 것이 중요합니다. Spark를 사용할 때 세 가지 형식 모두 올바르게 구성되면 우수한 읽기 성능을 제공합니다. Trino(Athena 역시)를 사용하면 Hudi 및 Delta의 데이터 건너뛰기 기능이 지원되지 않기 때문에 Iceberg가 더 나은 쿼리 성능을 제공할 수 있습니다. 쿼리 엔진이 지원하는 기능을 충분히 고려하시기를 바랍니다. | ||
데이터 레이크의 증분 데이터 처리
개략적으로 보면 증분 데이터 처리란 새로운 데이터를 소스에서 대상으로 이동시키는 것을 말합니다. 증분 ETL(Extract, Transform and Load) 워크로드를 효율적으로 구현하려면 특정 시점 이후 변경되거나 추가된 데이터 레코드만 (증분 방식으로) 가져올 수 있어야 하므로 불필요한 데이터(예: 전체 파티션)를 재처리할 필요가 없습니다. 데이터 원본이 오픈 테이블 형식 테이블인 경우 증분 쿼리를 활용하여 이러한 테이블 형식을 더욱 효율적으로 읽을 수 있습니다.
| Apache Hudi | Apache Iceberg | Delta Lake | |
| 기능적 적합성 |
|
|
|
| 고려 사항 |
|
|
|
| 지원되는 AWS 통합 | 증분 쿼리는 다음에서 지원
|
증분 쿼리는 다음에서 지원
CDC 뷰는 다음에서 지원
|
CDF는 다음에서 지원
|
| 결론 | 스토리지 오버헤드 없이 다양한 엔진을 사용하는 증분 ETL 파이프라인에 가장 적합한 기능입니다. | 뷰를 만드는 데 필요한 오버헤드가 허용된다면, Spark를 사용하여 증분 파이프라인을 구현하는 데 적합합니다. | 추가 스토리지 오버헤드가 허용된다면, Spark를 사용하여 증분 파이프라인을 구현하는 데 적합합니다. |
개인정보 보호 규정을 준수하기 위한 삭제 처리
일반 데이터 보호 규정(GDPR) 및 캘리포니아 소비자 개인 정보 보호법(CCPA)과 같은 개인 정보 보호 규정으로 인해, 다양한 업계의 기업들은 사용자의 “잊혀질 권리”를 보장하고 데이터 레이크에 레코드 수준의 삭제를 수행하거나 고객 데이터 사용 방법에 대한 동의를 얻기 위해 변경 사항을 올바르게 저장해야 합니다.
이번 사례에서는 데이터세트 전체(또는 상당 부분)를 다시 작성하지 않고, 레코드 수준의 삭제를 수행할 수 있는 기능이 가장 필수적인 요건으로 작용합니다. 개인 정보 관련 규정을 준수하기 위해 하드 삭제(Hard deletes: 테이블에서 레코드 삭제 및 Amazon S3에서 물리적으로 제거)를 수행하는 것이 중요합니다.
| Apache Hudi | Apache Iceberg | Delta Lake | |
| 기능적 적합성 | 하드 삭제는 Hudi의 자동 클리너 서비스로 수행 | 하드 삭제는 별도의 프로세스로 구현할 수 있음 | 하드 삭제는 별도의 프로세스로 구현할 수 있음 |
| 고려 사항 |
|
|
|
| 결론 | 이 사용 사례는 세 가지 형식을 모두 사용하여 구현할 수 있으며, 각각의 경우에 설정 또는 백그라운드 파이프라인에서 데이터 보존 요구 사항을 충족하는 데 필요한 정리 절차를 구현하는지 확인해야 합니다. | ||
결론
오늘날 모든 사용 사례에 알맞은 최적의 단일 테이블 형식은 없으며, 형식마다 특정 요구 사항에 맞는 고유한 장점이 있습니다. 주요 요건 및 사용 사례를 결정한 후, 이러한 요건에 가장 적합한 테이블 형식을 선택하는 것이 중요합니다.
사용자의 워크로드에 가장 적합한 테이블 형식을 결정할 때, 빠른 결정을 위해 다음 작업을 수행하는 것을 권장합니다.
- 이 게시물에 제공된 개략적인 지침을 사용하여 워크로드에 적합한 테이블 형식을 파악하세요.
- 이전 단계에서 식별한 테이블 형식에 대해 개념 증명(PoC)을 수행하여 해당 형식이 특정 워크로드 및 요건에 적합한지 검증합니다.
이러한 오픈 테이블 형식은 오픈 소스이며, 새로운 기능 출시 및 통합 가능성 등 빠른 속도로 발전하므로 워크로드에 맞는 형식을 결정할 때 제품 로드맵도 함께 고려해야 한다는 점을 유념하시기 바랍니다.
[1] 일반적으로 작은 파일들을 큰 파일로 합치면서 데이터를 최신화합니다. 오픈 테이블 형식마다 조금씩 정의가 다르므로, 공식사이트의 설명을 참조합시오.
[2] 더이상 참조하지 않는 파일을 삭제하는 작업을 의미합니다.