[Apache Iceberg] 등장 배경 (1) : OLAP와 Data Warehouse

🧊 Apache Iceberg: The Definitive Guide 책을 바탕으로 작성되었습니다.

 

💡 들어가며 

Apache Iceberg는 최근 대규모 데이터를 저장하고 관리할 때 널리 활용되고 있는 오픈 테이블 포맷입니다.
오픈 테이블 포맷이란 어떤 개념일까요? 그리고 Apache Iceberg를 많은 곳에서 사용하는 이유는 무엇일까요?
이를 알기 위해서는 Apache Iceberg가 탄생하게 된 배경을 이해하고 있어야 합니다.
이번 글에서는 그 첫 번째로 OLAP와 Data Warehouse에 대해 살펴보도록 하겠습니다.

 

 

📍 Chapter 1. Introduction to Apache Iceberg 글 모아보기 : 

► 2편 : [Apache Iceberg] 등장 배경 (2) : Data Lake와 Data Lakehouse
► 3편 : [Apache Iceberg] Iceberg 이전의 Table Format, Hive 
► 4편 : [Apache Iceberg] Iceberg 설계 아키텍처 및 주요 특징

 

---

1️⃣ 분석을 위한 대용량 데이터 처리 방식, OLAP

일반적으로 우리가 어떤 데이터를 저장하고 사용하기 위해서 가장 먼저 떠올릴 수 있는 방법은

MySQL 같이 행과 열로 이루어진 테이블 형태로 저장하는 RDBMS(Relational DataBase Management System)일 것입니다.

 

이러한 RDBMS는 OLTP(OnLine Transaction Processing) 종류의 처리에 특화되어 있습니다.

OLTP는 적은 수의 행을 빠르게 변경(insert, update, delete)하는 처리 방식을 의미합니다.

일반적으로 은행 거래, 쇼핑몰 주문과 같은 서비스를 다룰 때 OLTP가 필요하게 됩니다.

 

그러나 시간이 지나면서 분석이나 머신러닝(ML)과 같은 대용량 데이터를 대상으로 하는 작업이 등장했습니다. 

이러한 종류의 작업에서는 일반적으로 모든 행에 대해서 특정 열을 집계하여 조회(sum, avg, count)합니다.

 

이렇게 대용량의 데이터에 대해 분석 및 집계하는 처리 방식을 OLAP(OnLine Analytical Processing)라 합니다.

 

분석과 머신러닝과 같은 OLAP 작업에, OLTP에 최적화된 RDMBS를 사용하게 되면 데이터가 커질수록 처리 성능이 좋지 않았고

따라서 OLAP에 최적화된 새로운 저장 방법이 필요해졌습니다.

 

---

(1) OLAP 구성 요소

'OLAP에 최적화된 새로운 저장 방법'은 'OTLP에 최적화된 RDMBS'와 어떤 부분이 다르기 때문에 
대용량 데이터에 대해 열을 기준으로 조회 및 집계하는 작업을 더 잘 수행할 수 있는 걸까요?

 

그 차이를 이해하기 위해서는 두 시스템을 구성하는 요소들이 어떤 역할을 담당하는지 알고 있어야 합니다.

비슷한 종류의 구성 요소를 가지고 있지만, 각 요소의 구조와 세부 구현 방식이 다르기 때문입니다.

 

그렇다면 사용자가 데이터에 접근하고 처리하는 데 있어서
추상화 수준이 낮은 개념부터 높은 순서로(= 물리적 → 논리적) 살펴보도록 하겠습니다.

그림 1-1. 분석 workload를 지원하기 위한 기술적 구성요소(technical component)

 

 

► Storage

• 데이터를 물리적으로 저장하는 공간
• e.g - 로컬 파일 시스템(DAS), 분산 파일 시스템(HDFS), 객체 스토리지(S3)

► File Format

• 데이터를 파일로 어떻게 저장할지에 대한 정의(구조, 인코딩, 압축 방식 등)
• e.g - 정형(CSV), 반정형(JSON), 비정형(Text file)
• e.g - 행 지향(CSV, Apache Avro), 열지향(Apache Parquet, Apache ORC)

► Table Format

• 파일이 Storage에 어떻게 배치되어야 하는지에 대한 정의
• 즉, 파일(physical)을 테이블(logical)로 어떻게 구성할지(추상화)
• e.g - Apache Iceberg, Delta lake, Apache Hudi

► Storage Engine

• File Format과 Table Format이 정의한 방식에 따라 Storage에 데이터를 읽고 쓰는 작업 수행
• 데이터 파일과 내부 구조(인덱스, 압축)를 관리하면서 최적화된 성능으로 CRUD를 제공

► Compute Engine

• 쿼리를 해석하여 최적화된 실행 계획을 세우고, 읽어온 데이터를 처리하는 작업 수행
• e.g - Apache Spark, Presto/Trino, Snowflake

► Catalog

• 필요한 데이터를 빠르게 식별할 수 있도록 메타데이터를 저장하고 제공
• 메타데이터 : 테이블 이름, 스키마, 물리적 위치, 통계 정보(레코드 수, 테이블 크기, 컬럼별 최소/최대 값⋯)
• e.g - Apache Hive Metastore, AWS Glue Data Catalog

 

[🔎 Storage Engine vs. Compute Engine ]
개인적으로 가장 헷갈렸던 두 개념에 대해 다시 한 번 이해하기 쉽게 비교를 해보겠습니다.
두 개 모두 Engine으로서 데이터와 관련된 상호작용을 한다는 공통점이 있지만, 그 수행하는 동작에 있어서 차이가 있습니다 : 

Storage Engine - 어떻게 데이터를 저장하고 관리할지 - Storage와 상호작용하며 데이터를 읽고 쓴다.

Compute Engine - 어떻게 데이터를 처리하고 계산할지 - 사용자로부터 쿼리를 받아 해석하고, 읽어온 데이터에 대해 계산을 수행한다.

 

 

그럼 "도서관"을 예시로 각 구성 요소를 이해하기 쉽게 정리해보도록 하겠습니다. 

Storage부터 Compute Engine까지 각 개념이 어떻게 이어지는지 연결 지어 생각해 보면 OLAP 시스템의 흐름을 이해할 수 있습니다.

OLAP 구성 요소	도서관에 비유하면	설명
Storage	도서관 건물, 선반	책을 물리적으로 저장하는 모든 공간
File Format	한국어 책 / 영어 원서, 종이책 / 전자책, 글자책 / 그림책	책 한 권이 어떤 모습으로 만들어졌는지에 대한 '설계도' 이 설계도를 알아야 책을 제대로 읽을 수 있다 모든 책이 하나의 같은 설계도를 따를 필요는 없다. - 파일 : csv는 쉼표로 구분된 텍스트, json은 중괄호와 쉼표의 키-값 쌍, Parquet는 열 단위 압축 - 책    : 언어(한국어/영어), 형태(종이/전자), 구성(글/그림)
Table Format	책을 분류하고 정리하는 규칙	모든 책이 따르는, 책을 도서관에 어떻게 배치할지에 대한 규칙 이것이 잘 만들어져있다면 전체 도서관 시스템을 효율적으로 운영할 수 있다. - 예 : 모든 종이책은 1층에 위치하고, 저자 이름 가나다 순서대로 정렬한다
Storage Engine	사서	이용자가 "김해진 작가의 한국어 종이책 좀 찾아주세요!" 하고 요청하면, 사서는 '종이책은 1층에 저자별 가나다순'이라는 규칙(Table Format)을 알고, 그 책이 '한국어 종이책'이라는 설계도(File Format)로 만들어졌으니 읽을 수 있다는 걸 안다. (한국어를 알고 책을 서가에서 꺼내 읽을 수 있어서) 그래서 그 책을 서가에서 빠르고 정확히 찾아와 이용자에게 전달한다(데이터 읽기). 새로운 책이 들어왔을 때(데이터 쓰기)도 알고 있는 규칙을 바탕으로 책을 꺼내거나 꽂는 작업을 수행한다.
Catalog	도서 목록 or 도서 검색 시스템	"어떤 책(테이블)이 몇 번 서가(Storage 경로)에 있고, 그 책은 어떤 장르(스키마/컬럼 타입)이며, 몇 페이지(데이터 크기)인지" 등 책 자체의 내용이 아닌 책에 대한 정보를 기록하고 관리한다. 사서나 이용자가 책을 찾을 때 이 목록을 먼저 확인한다.
Compute Engine	도서관 이용자	도서관에서 책을 읽는 이용자. 이들은 사서(Storage Engine)를 통해 책을 가져와서(데이터 읽기), 자신들의 지식과 도구를 활용해 책에서 필요한 정보를 빠르고 효율적으로 찾아내고 계산하여 새로운 결과물(분석 결과)을 만들어냅니다.

 

OLAP 구성 요소의 대표적인 예시가 포함된 그림을 마지막으로 Data Warehouse 등장 이전의 이야기를 마무리하도록 하겠습니다.

이미지 출처 (https://hudi.apache.org/blog/2024/07/11/what-is-a-data-lakehouse/)

---

 

2️⃣ Data Warehouse 

Data Warehouse(=OLAP Database)는 하나의 시스템 안에 OLAP 구성 요소들을 갖고 있는 중앙 집중식 저장소입니다.

아래 그림에서 보다시피 Data Warehouse가 독점적으로 모든 데이터를 저장하고 관리하게 됩니다.

저장된 데이터에 접근할 때도 Data Warehouse의 Compute engine을 통해서만 접근할 수 있습니다.

데이터 웨어하우스의 구성 요소

 

---

(1) Data Warehouse의 변화

이러한 구조는 2015년까지 대부분 on-premise 환경에서 Storage와 Compute 구성 요소가 동일한 노드(장치)에서 밀접하게 결합되어 있었기 때문에 설계되었습니다. 하지만, 이는 작업에 따라 Storage나 Compute를 독립적으로 확장할 수 없다는 문제가 있었습니다. 즉, Storage를 확장하기 위해서는 불필요한 Compute에 대한 확장 비용도 추가로 필요하였습니다.

 

이후 클라우드 네이티브 컴퓨팅이 등장하면서, Storage와 Compute 구성 요소를 분리하고 독립적으로 리소스를 확장할 수 있게 되었습니다. Compute 자원을 필요할 때만 사용할 수 있게 되면서 동시에 Storage 상태와 완전히 독립적으로 운영할 수 있게 되었습니다.

---

(2) Data Warehouse의 장단점

 

	🟢 장점	🔴 단점
1	SSOT(Single Source Of Truth) 보장	데이터가 특정 시스템에 종속(Locked in)
2	많은 양의 데이터를 빠르게 쿼리	Storage, Compute 비용
3	데이터 거버넌스(가용성, 활용성, 안전) 보장	정형(structured) 데이터 지원
4	쿼리하는데 최적화된 데이터 레이아웃 구성	ML 종류의 분석 작업 실행 어려움
5	데이터가 정의된 스키마를 따르도록 보장

 

🟢 장점

1. 다양한 Source에서 오는 모든 데이터를 한 곳에서 쉽고 빠르게 접근할 수 있다.
2. OLAP를 위해 설계되어 많은 데이터를 빠르게 조회할 수 있다.

 

🔴 단점

1. 각 구성 요소가 강하게 결합(coupled)되어 있기 때문에, 해당 Data Warehouse를 통해서만 데이터에 접근할 수 있다.
   (→ Redshift에 저장되어 있는 데이터를 BigQuery 컴퓨팅 엔진을 사용해서 조회할 수 없다)
2. 재정 비용 + 운영 비용(파이프라인 구성 및 유지관리) 증가
3. ML 작업에 사용되는 JSON, 이미지, 텍스트 같은 유형의 데이터를 다루기 어렵다.
4. ML 작업을 위해 설계되지 않았기 때문에, 이를 위해서는 다른 곳으로 데이터를 옮겨야 한다.

 

 

---

 

다음 글에서는 Data Warehouse의 단점을 극복하기 위해 등장한 Data Lake와 Data Lakehouse에 대해 알아보도록 하겠습니다.