오늘날 데이터 관리가 완전히 변화하고 있다는 것을 알고 있습니다. 수십 년 동안 기업들은 적절한 방식으로 정보를 저장하는 데이터 웨어하우스에 의존했습니다. 데이터 웨어하우스는 구조화되어 있으며, 관리가 가능하고, 정보를 신속하게 추출할 수 있지만, 비용이 많이 들고 경직된 특성을 가지고 있습니다. 반면, 데이터 레이크는 더 효율적이며 구조에 관계없이 방대한 양의 데이터를 저장할 수 있습니다. 그러나 데이터 레이크하우스 아키텍처의 출현은 데이터 레이크와 데이터 웨어하우스의 장점을 결합합니다. 레이크하우스 모델은 데이터 레이크가 제공하는 유연성을 유지하면서 데이터 웨어하우스의 신뢰성, 관리 및 성능을 통합합니다.
대규모 데이터 분석을 위해 만들어진 가장 주목할 만한 오픈 소스 테이블 형식은 Apache Iceberg입니다. Iceberg는 이 변혁의 최전선에 있으며, 레이크하우스 아키텍처에서 데이터의 가치를 향상시킵니다. 또한 Iceberg는 스키마 진화, ACID 트랜잭션, 데이터 일관성, 쿼리 성능 등 데이터 레이크가 직면한 많은 문제에 대한 해결책을 제공합니다.
이 블로그 게시물은 Apache Iceberg와 현대 데이터 아키텍처에서의 역할을 탐구하는 3부작 시리즈의 첫 번째 글입니다. 이 게시물에서는 다음 주제에 초점을 맞출 것입니다:
- 데이터 웨어하우스에서 데이터 레이크로의 진화
- 전통적인 접근 방식과 관련된 도전 과제
- Apache Iceberg가 이러한 한계를 어떻게 해결하는지
이 시리즈의 다음 게시물에서는 Iceberg의 아키텍처에 대해 더 깊이 파고들고 Iceberg 테이블 내에서 쿼리가 어떻게 작동하는지 탐구할 것입니다.
간단 요약: 데이터 웨어하우스에서 데이터 레이크로의 진화
수년 동안 기업은 분석을 위한 중심 기반이었던 데이터 웨어하우스에 의존해 왔습니다. 데이터 웨어하우스는 다양한 원본으로부터 구조화된 데이터를 캡처하여 보고서와 통찰력을 효율적으로 생성하기 위한 중앙 저장소 역할을 합니다. 요즘에는 데이터 웨어하우스가 빠른 쿼리 성능과 견고한 거버넌스 메커니즘을 통해 신속한 보고와 잘 구조화된 서비스를 가능하게 합니다.
그럼에도 불구하고, 데이터 양이 증가함에 따라 기업은 새로운 문제에 직면했습니다.
- 높은 컴퓨트 및 저장 비용으로 인한 저장 비용 증가
- 유연성이 없는 스키마 강제로 구조화되지 않거나 반구조화된 데이터의 통합이 어려웠습니다
- AI 및 머신러닝 워크로드 지원이 제한적이었습니다
해결책으로 기업은 데이터 레이크를 활용하기 시작했습니다. 이를 통해 기업은 Amazon S3, Azure Data Lake Storage, Google Cloud Storage, Hadoop Distributed File System과 같은 저렴한 저장소 내에서 원시 데이터, 구조화된 데이터, 비구조화된 데이터를 보유할 수 있었습니다.
데이터 레이크의 장점은 다음과 같은 요소를 포함했습니다:
- 특정 클라우드 환경 내 저장 비용 절감
- 비구조화된, 반구조화된, 심지어 구조화된 데이터와 같은 신형 데이터 형식 사용
- AI 및 머신러닝 애플리케이션의 개선된 사용
이러한 이점에도 불구하고, 데이터 레이크는 다음과 같은 새로운 문제를 제시했습니다:
- 거버넌스와 스키마의 부재로 인해 불일치하는 데이터 세트가 발생했습니다.
- 비효율적인 인덱스 활용과 전체 테이블 스캔으로 인해 쿼리 성능이 느려졌습니다.
- ACID 트랜잭션의 부재로 인해 다중 사용자 환경에서 데이터 무결성을 보장하는 것이 어려워졌습니다.
데이터 레이크하우스의 출현
데이터 레이크하우스는 데이터 레이크의 모든 확장성과 경제적 이점을 데이터 웨어하우스의 생산성, 신뢰성 및 트랜잭션 기능과 결합합니다. 이것은 현대적인 설계 패러다임입니다.
데이터 레이크하우스의 주요 이점은 다음과 같습니다:
- 저렴한 가격으로 저장 및 처리 기능 모두 수용
- ACID 트랜잭션을 통한 효율적인 데이터 제어
- 기존 쿼리에 영향을 주지 않고 스키마 수정 – 스키마 진화
- 시간 여행 기능을 통한 테이블의 이전 버전 검색
이러한 기능의 도입은 Delta Lake, Apache Hudi 및 Apache Iceberg와 같은 현대적인 테이블 형식의 개발로 이어졌습니다. 이러한 구조는 데이터 레이크가 데이터 웨어하우스처럼 작동할 수 있도록 하면서도 구조화된 메타데이터 레이어의 도입 덕분에 유연하고 비구조적일 수 있는 자유를 유지했습니다. 이러한 테이블 형식 중에서 Apache Iceberg는 데이터 레이크하우스 아키텍처로 전환하려는 조직을 위해 강력한 솔루션을 제공하며 주요 선택지로 부상했습니다.
Apache Iceberg: 데이터 레이크하우스를 위한 게임 체인저
테이블 형식이란 무엇인가?
표 형식을 사용하면 데이터 레이크에 저장된 대량의 정보를 효과적으로 관리할 수 있습니다. 이는 몇 가지 기능을 포함하며 다음과 같습니다:
- 데이터를 효과적으로 관리하고 쿼리하기 위해 데이터를 표로 구조화합니다.
- 데이터를 효율적으로 제거하고 업데이트하며 스키마를 변경합니다.
- 메타데이터를 변경하여 쿼리 응답 시간을 개선합니다.
하이브와 같은 다른 전통적인 테이블 형식과 마찬가지로, 디렉토리를 기반으로 하는 저장소에 의존하여 데이터를 구성했습니다. 그러나 이 방법은 쿼리 엔진이 쿼리를 실행하기 전에 전체 디렉토리를 거쳐야 했기 때문에 성능 병목 현상을 초래했습니다.
하이브에서 아이스버그로의 진화
하이브 테이블 형식은 초기에 데이터 레이크를 구조화하는 문제를 해결하려고 했습니다. 목적은 사용자가 Apache Hive 및 Presto에서 사용하는 SQL과 유사한 쿼리를 사용하여 데이터 집합을 테이블로 구성할 수 있도록 하는 것이었습니다. 그러나 하이브 형식에는 중요한 단점이 있습니다:
- ACID 트랜잭션의 부족으로 인한 서로 다른 소스에서의 동시 쓰기로 인한 불일치.
- 메타데이터의 비효율적인 관리로 인한 비싼 파일 목록 작업.
- 수동 최적화 파티셔닝 도전으로 인한 느린 쿼리.
아파치 아이스버그가 이러한 문제를 해결하는 방법
아파치 아이스버그는 하이브에서 발생하는 문제를 제거하면서 ACID 트랜잭션, 스키마 진화, 데이터 레이크에서의 빠른 쿼리 성능을 제공하는 현대적인 테이블 형식입니다.
아파치 아이스버그의 중요한 혜택 중 일부는 다음과 같습니다:
- 신뢰할 수 있는 데이터 업데이트와 일관성을 보장하는 ACID 트랜잭션.
- 과거 데이터 스냅샷을 쿼리하고 시간을 거슬러 이동할 수 있는 능력.
- 기존 쿼리를 파괴하지 않고 열을 추가, 이름을 변경하거나 삭제할 수 있는 스키마 진화.
- 파티션이 자동으로 최적의 파티셔닝 전략을 최적화하는 파티션 진화.
- 메타데이터를 효율적으로 관리하여 불필요한 파일 스캔을 줄이고 빠른 쿼리 실행을 가능케 합니다.
최종적으로
아파치 아이스버그의 등장으로 데이터 관리가 크게 변화했습니다. 데이터 레이크하우스 접근 방식으로 전환하는 기업들이 성능을 희생하지 않고 비용 효율적이고 매우 확장 가능한 방식으로 정보를 관리할 수 있습니다. 아파치 아이스버그의 발명으로 분석이 변화되었으며, 그 사용량은 지속적으로 증가하고 있습니다. 이 시리즈의 마지막 게시물을 기대해 주세요. 다음 두 블로그 게시물에서는 다음에 초점을 맞출 예정입니다:
- 파트 2: 데이터, 메타데이터 및 카탈로그 계층을 포함한 아파치 아이스버그의 아키텍처.
- 파트 3: Iceberg에서 쿼리의 메커니즘, 읽기 및 쓰기, 시간 이동, 쿼리 최적화 방법을 다룰 예정입니다.
Source:
https://dzone.com/articles/the-future-of-data-lakehouses-apache-iceberg