Apache Hudi: The Definitive Guide

6장. Hudi 테이블 유지 관리 및 최적화하기

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

얼리 릴리스 독자를 위한 참고 사항

조판 전자책을 사용하면 저자가 글을 쓸 당시의 편집되지 않은 원시 콘텐츠인 가장 초기 형태의 책을 얻을 수 있으므로 해당 타이틀이 정식 출시되기 훨씬 전에 이러한 기술을 활용할 수 있습니다.

이 책은 마지막 책의 6번째 챕터가 될 것입니다.

이 초안을 검토하고 의견을 제시하는 데 적극적으로 참여하고 싶으시면 편집자에게 이메일( [e-mail])로 연락해 주세요.

집을 최적의 상태로 유지하기 위해 정기적으로 유지보수를 하는 것처럼, 잘 작동하는 데이터 레이크하우스를 위해서는 Apache Hudi 테이블을 유지보수하는 것이 필수적입니다. 집이 넓고 탐색하기 쉬운 상태를 유지하기 위해 정기적으로 분류, 정리, 재구성이 필요한 것처럼, 테이블도 효율성과 접근성을 유지하기 위해 주기적으로 검토하고 정리해야 합니다.

데이터를 작성할 때 사용자는 데이터를 완벽하게 정리하는 것보다 읽기 및 쓰기 지연을 최소화하는 데 더 집중하는 경우가 많은데, 이는 특히 처리량이 많은 테이블의 경우 심각한 문제입니다. 1장 초반에 설명했듯이, Hudi는 이러한 함정을 예상하고 처음부터 이를 방지할 수 있는 데이터 레이크하우스 플랫폼으로 설계되었습니다. 이를 통해 사용자는 나중에 데이터 레이크하우스를 운영할 때 발생하는 비효율과 어려움을 줄일 수 있습니다.

예를 들어, 유지 관리되지 않는 Hudi 테이블은 문제가 될 수 있습니다:

스토리지 비용 증가

작은 파일이 너무 많으면 스토리지 액세스 지연 시간이 길어지고 스토리지의 압축이 비효율적으로 이루어져 레이크하우스의 스토리지 비용이 증가합니다. Cloud 스토리지에 개체가 너무 많으면 스토리지 API 비용도 급증할 수 있습니다.

느린 쿼리 성능

테이블 구성이 최적이 아닌 경우 클러스터링되지 않고 제대로 분할되지 않은 데이터 레이아웃으로 인해 쿼리 실행 시간이 길어질 수 있습니다. 또한 많은 수의 작은 파일은 특히 여러 버전의 테이블을 보관하는 레이크하우스의 경우 메타데이터 부풀리기의 원인이 됩니다.

컴퓨팅 비용 증가

인덱스를 유지 관리하지 않으면, 작성자와 쿼리가 관심 있는 레코드를 찾기 위해 전체 테이블을 스캔하게 되고, 컴퓨팅 리소스를 장시간 보유하게 되어 컴퓨팅 클러스터 요금이 매우 높아질 수 있습니다.

높은 읽기 증폭

로그 파일 증가를 제어하기 위해 자주 압축하지 않으면, MOR(Merge-on-Read) 테이블의 쿼리는 매번 너무 많은 데이터를 읽어야 하기 때문에 문제가 발생할 수 있습니다.

집이 완전히 어질러지기 전에 조치를 취하지 않는 것처럼, 최적의 데이터 접근성과 쿼리 성능을 보장하기 위해서는 사전 예방적인 테이블 유지 관리가 중요합니다.

이때 테이블 서비스가 중요한 역할을 합니다. 이러한 서비스는 데이터 레이크하우스를 깨끗하고 체계적이며 효율적으로 ...