데이터 관리 관행이 발전함에 따라 데이터 웨어하우스와 데이터 레이크를 하나의 아키텍처로 결합하는 모델인 데이터 레이크하우스가 등장했습니다. 아파치아이스버그(Apache Iceberg)를 통해 이런 데이터 레이크하우스를 구현할 수가 있습니다. 이러한 내용을 자세히 설명한 내용이 있어 공유합니다.
🍎 왜 데이터 레이크하우스인가?
- 데이터 레이크하우스가 등장하기 전에는 많은 기업들이 조직의 구조화된 관계형 데이터를 분석과 보고를 위한 단일 리포지토리로 모으는 데이터 웨어하우스에 집중했습니다.
- 데이터, 특히 비정형 데이터가 기하급수적으로 증가하면서 데이터 레이크는 방대한 양의 원시 비정형 및 반정형 데이터를 저렴한 스토리지에 저장하는 방법으로 부상했습니다. 이를 통해 데이터 팀은 데이터를 확보하는 즉시 데이터를 노출할 수 있었습니다.
- 데이터 분석가와 데이터 과학자는 고급 분석을 실행하거나 머신 러닝 모델을 학습하기 위해 데이터를 읽기 시작하면서 스키마를 정의할 수 있었습니다(스키마 온-읽기).
🍎 2계층 아키텍처의 등장: 데이터 웨어하우스와 데이터 레이크
- 데이터 분석가들이 선호하는 SQL 언어를 사용해 데이터를 고성능으로 구조화하고 분석하는 동시에 데이터 변경에 대한 트랜잭션 일관성을 유지하고 데이터 거버넌스 및 보안을 간소화하는 데이터 웨어하우스가 여전히 필요했습니다.
- 또한 데이터의 이전 스냅샷을 쉽게 쿼리하거나 데이터를 복사하지 않고 테이블을 복제하는 등의 고유한 기능에 대한 필요성도 있었습니다.
- 이로 인해 많은 기업들이 데이터를 저장하고 처리하기 위해 데이터 레이크와 데이터 웨어하우스로 구성된 데이터 레이크 하우스 아키텍처를 채택하게 되었습니다.
🍏 데이터 레이크의 장점
- 저비용 객체 스토리지
- 비구조화 데이터, 데이터 과학 및 기계 학습을 포함한 고급 분석 지원
- 읽기 시 스키마로 인한 더 쉽고 빠른 데이터 온보딩 및 AI/ML 기능 활성화
🍏 데이터 웨어하우스의 장점
- 사용 편의성
- 향상된 거버넌스
- 더 나은 검색
- SQL 성능 강화
- ACID(원자성, 일관성, 격리 및 내구성)
- 제로 카피 복제
- 시간 여행(타임트래블)
🍏 이중 아키텍처 데이터 관리의 문제점
- 높은 총 소유 비용: 두 개의 별도 시스템을 유지하는 것은 더 큰 복잡성과 인력과 관련된 높은 비용 의미
- 데이터 노후화: 데이터 레이크와 데이터 웨어하우스 간의 데이터 업데이트 지연 가능성
- 신뢰성: 데이터를 수집하는 여러 프로세스는 추가적인 ETL 단계를 도입하여 실패 지점을 증가 가능성
- 드리프트: 한 시스템의 데이터 변경이 다른 시스템에 반영되지 않아 불일치 발생
- 벤더 종속: 데이터 웨어하우스는 종종 독점 스토리지 형식만 지원하며, 플랫폼 간 마이그레이션은 조직에 높은 비용 소요
🍎 데이터 레이크하우스의 장점
- 데이터 레이크하우스 = 데이터 레이크 + 데이터 웨어하우스
- 기업은 데이터 웨어하우스 기능(구조화된 데이터 및 트랜잭션 관리 기능을 사용하면서) 대규모 원시 데이터 저장소에서 데이터 레이크 스토리지로 데이터를 수집 가능
- 모든 데이터 사용자가 데이터 레이크하우스를 사용할 수 있도록 하는 핵심은 각 데이터 파일 위에 메타데이터 계층을 사용하는 오픈 테이블 형식으로, 사용자가 데이터 레이크에서 정형, 반정형, 비정형 데이터에 관계없이 직접 데이터를 쿼리 가능
- 이 계층을 통해 사용자는 미리 정의된 스키마, 캐싱, 인덱싱을 구현하고 데이터 웨어하우스와 유사하게 카탈로그에서 데이터를 테이블로 검색할 수 있도록 만들어 더 빠르게 쿼리 지원
- 메타데이터 계층은 데이터 레이크의 개방형 파일 형식(Apache Parquet) 위에 있는 개방형 메타데이터 테이블 형식(Delta Lake 및 Apache Iceberg)을 통해 관리
🍏 모든 소비를 단일 장소로 지정: SQL on Lake
- 모든 데이터 사용자, 즉 데이터 과학자와 엔지니어부터 SQL을 사용하는 제품 소유자 및 비즈니스 분석가까지 동일한 테이블 형식을 통해 노출된 동일한 데이터를 쿼리
- 데이터 레이크하우스를 사용하면 중복 데이터가 문제 감소하고, 기업이 더 이상 두 개의 시스템을 관리하지 않고 새로운 소스에서 데이터 통합이 자동화되고 개방구조이기 때문에 총소유 비용 저렴해짐
- 오픈 표준 형식을 활용하는 중앙 집중식 스토리지로 인해 선택한 특수 컴퓨팅 엔진을 도입할 수 있는 다양한 기회가 열리고 벤더 종속을 최소화
🍎 Apache Iceberg란?
- 오픈 테이블 형식은 데이터 웨어하우스의 기능을 데이터 레이크하우스 아키텍처에 도입하는 데 중요한 역할
- Apache Iceberg는 데이터 레이크에서 SQL 지원을 통해 대규모 데이터를 효율적으로 쿼리하기 위해 사용하는 오픈 테이블 형식으로 테이블 형식은 데이터 파일이 테이블 내에서 어떻게 구성되고 접근되는지를 지정
🍏 Apache Iceberg의 주요 특징
- Apache Iceberg는 데이터 관리 및 데이터 구조화와 같은 전통적으로 데이터 웨어하우스에서 제공되던 기능을 데이터 레이크와 빅데이터로 가져오는 데 큰 역할
- 데이터 조직화를 위한 스키마 정의, SQL 쿼리, 테이블 복제 및 시간 여행(time travel)이 포함
- 오픈소스 프로젝트로서의 유연성과 상호운용성을 제공하며, 데이터를 저장하기 위해 Parquet와 같은 오픈 데이터 형식을 통합하고, 다양한 벤더와 플랫폼의 도구가 데이터를 접근할 수 있도록 지원
- 메타데이터 파일, 매니페스트 목록 및 메타데이터 파일 형태로 테이블 메타데이터를 캡처
- 메타데이터 레이어는 특정 스냅샷(메타데이터 파일이라고 함)의 파일 목록을 추적하기 위해 Apache Iceberg가 생성한 매니페스트 파일로 구성. 데이터의 다른 스냅샷이 생성될 때마다 이전 스냅샷에 대한 참조가 포함되며, 이를 통해 시간 여행과 같은 데이터 웨어하우스의 기능 제공
🍏 아이스버그 테이블을 사용한 레이크하우스 아키텍처 구현
- 레이크하우스 아키텍처의 이점을 활용하고자 하는 기업은 이를 위해 아이스버그 테이블을 사용
- 아이스버그 테이블은 기업이 데이터 레이크와 같은 자체 외부 스토리지에서 데이터를 읽고 쓸 수 있는 방법을 제공하면서 쿼리 기능과 기본 테이블의 기능 지원
- 기업은 데이터를 레이크하우스 아키텍처에 저장하고 사용을 그곳으로 지정할 수 있어 데이터를 별도로 로드하고 저장하는 비용 최소화
- 아이스버그 테이블은 테이블 형식으로 Apache Iceberg를 사용하고, 데이터 파일 형식으로 Apache Parquet를 사용하여 데이터 레이크의 대규모 데이터셋을 저장하고 처리하는 아키텍처 사용
🍏 Iceberg Tables 성능 최적화
데이터 웨어하우스에서 레이크로 워크로드를 옮길 때 가장 큰 우려는 쿼리 성능 저하이며, 이는 비용 증가로 이어질 수 있어 성능 최적화가 중요함. 데이터 수집 및 쿼리 프로세스를 최적화함으로써, Iceberg Tables는 네이티브 테이블 성능에 가까운 결과를 제공 가능
- 데이터 레이아웃 최적화: 데이터가 쓰여질 때 스토리지 엔진이 데이터를 배치하는 방식이 성능에 중요.파일 크기, 행 그룹 크기, 파티션 수, 압축 방법 등
- 인덱스와 통계: 데이터 작성 시 메타데이터에 수집된 인덱스와 통계를 활용하면, 데이터를 찾기 위해 열거나 스캔해야 하는 파일 수를 줄여 쿼리를 더 빠르게 실행
- 스토리지 유지 관리: 오래된 스냅샷을 정리하고 파일을 최적 크기로 압축하여 데이터 저장소를 유지 관리 필요
- 캐싱: 가상 웨어하우스 수준과 결과 수준에서 캐싱 지원. 데이터 수집 중 스토리지 레이아웃을 미리 계산하는 방식으로 레이크 스토리지 레이어 내에서 성능 최적화 구현
- 행 수준 업데이트 최적화: Iceberg 스펙은 copy-on-write와 merge-on-read라는 두 가지 행 수준 업데이트 패턴 지원. 업데이트와 삭제 작업이 많은 워크로드의 경우 merge-on-read 패턴을 선택하면 성능을 향상 가능
🍏 레이크하우스 아키텍처로 데이터의 가치를 극대화하기
- Iceberg를 활용한 데이터 레이크하우스 아키텍처로 데이터 소비를 전환함으로써, 다양한 처리 엔진을 통합할 유연성이 개선되고 총 소유 비용 절감
- 오픈 형식과 Iceberg의 광범위한 생태계는 데이터를 컴퓨팅 락인 없이 쉽게 처리할 수 있도록 보장하여 데이터 투자 수명을 연장
- 아키텍처 변경을 통해 중복 저장 비용을 제거하고, 데이터 레이크의 SQL 성능 개선
>> 스노우플레이크 관점의 상세 내용은 원문을 참고하시기 바랍니다.