[논문] Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics

https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

 

 

본 문서는 기존의 데이터 웨어하우스와 데이터 레이크의 한계를 극복하고자 레이크하우스(Lakehouse)라는 새로운 데이터 아키텍처를 제안합니다. 데이터 웨어하우스가 데이터 사일로, 높은 비용, 제한된 확장성 등의 문제를 겪는 반면, 데이터 레이크는 데이터 품질 및 거버넌스 부족, 분석 성능 저하와 같은 단점을 가진다고 지적합니다. 레이크하우스는 오픈 데이터 형식을 기반으로 하여 기계 학습 및 데이터 과학 워크로드를 지원하며, 데이터 웨어하우스의 성능 및 관리 기능을 통합하여 이러한 문제를 해결하며 복잡성을 줄이고, 데이터의 신뢰성, 최신성, 그리고 고급 분석 지원을 향상시키는 것을 목표로 합니다.

 

 

1. Introduction

레이크하우스는 다음과 같은 특징을 가집니다:
(i) Apache Parquet 및 ORC와 같은 개방형 직접 액세스 데이터 형식을 기반으로 합니다
(ii) 머신러닝 및 데이터 과학 워크로드에 대한 최고 수준의 지원을 제공합니다

데이터 웨어하우징의 역사는 운영 데이터베이스에서 데이터를 중앙 집중식 웨어하우스로 수집하여 비즈니스 리더가 분석적 통찰력을 얻고, 의사 결정 및 비즈니스 인텔리전스(BI)에 활용으로 시작되었다.
이러한 웨어하우스의 데이터는 스키마-온-라이트(schema-on-write) 방식으로 작성되어, 데이터 모델이 다운스트림 BI 소비에 최적화되도록 보장했습니다. 우리는 이를 1세대 데이터 분석 플랫폼이라고 부릅니다 (figure 1 참조)

약 10년 전, 1세대 시스템은 여러 가지 문제에 직면하기 시작했습니다
일반적으로 스토리지를 온프레미스 어플라이언스에 결합하며, 사용자 부하의 최대치와 데이터 미관리(data undermanagement)에 맞춰 자원을 프로비저닝하고 비용을 지불해야 했으며, 데이터셋이 증가함에 따라 매우 비용이 많이 들었습니다. 데이터셋이 빠르게 증가했을 뿐만 아니라, 비디오, 오디오, 텍스트 문서와 같이 완전히 비정형화된 데이터셋이 점점 더 많아졌는데, 데이터 웨어하우스는 이러한 데이터를 전혀 저장하고 쿼리할 수 없었습니다

이러한 문제들을 해결하기 위해 2세대 데이터 분석 플랫폼은 모든 원시 데이터를 데이터 레이크로 오프로드하기 시작했습니다
데이터 레이크는 Apache Parquet 및 ORC와 같은 일반적이고 주로 개방형 파일 형식으로 데이터를 저장하는 파일 API를 갖춘 저비용 스토리지 시스템입니다. 이러한 접근 방식은 Apache Hadoop 움직임과 함께 시작되었으며, 저렴한 스토리지를 위해 Hadoop 파일 시스템(HDFS)을 사용했습니다. 데이터 레이크는 모든 데이터를 저렴한 비용으로 저장할 수 있는 민첩성을 제공하는 스키마-온-리드(schema-on-read) 아키텍처였지만, 반면에 데이터 품질 및 거버넌스 문제를 다운스트림으로 미루는 결과를 낳았습니다. 이 아키텍처에서는 레이크에 있는 데이터의 작은 하위 집합이 나중에 가장 중요한 의사 결정 지원 및 BI 애플리케이션을 위해 (Teradata와 같은) 다운스트림 데이터 웨어하우스로 ETL되었습니다. 또한 개방형 형식의 사용은 데이터 레이크 데이터를 머신러닝 시스템과 같은 광범위한 다른 분석 엔진에서 직접 액세스할 수 있도록 했습니다

 

 

 

2. Motivation: Data Warehousing Challenges

 

데이터 웨어하우스는 많은 비즈니스 프로세스에 필수적이지만, **여전히 부정확한 데이터, 데이터의 최신성 부족(staleness), 그리고 높은 비용으로 인해 사용자들을 좌절시키고 있습니다**
이러한 각 과제의 적어도 일부가 기업 데이터 플랫폼의 설계 방식에서 비롯된 "우발적 복잡성(accidental complexity)"이며, 이는 **레이크하우스(Lakehouse)를 통해 제거될 수 있다**고 주장합니다
.
첫째, 오늘날 기업 데이터 사용자들이 가장 많이 보고하는 문제는 대개 **데이터 품질 및 신뢰성**입니다
. 정확한 데이터 파이프라인을 구현하는 것은 본질적으로 어렵지만, 별도의 레이크와 웨어하우스를 사용하는 오늘날의 투-티어(two-tier) 데이터 아키텍처는 이 문제를 악화시키는 추가적인 복잡성을 더합니다. 예를 들어, 데이터 레이크와 웨어하우스 시스템은 지원하는 데이터 타입, SQL 방언 등에서 다른 의미론(semantics)을 가질 수 있습니다. 또한 데이터는 레이크와 웨어하우스에 다른 스키마로 저장될 수 있으며(예: 한쪽은 비정규화), 여러 시스템에 걸쳐 있는 ETL/ELT 작업의 증가는 오류 및 버그 발생 가능성을 높입니다
.
둘째, 점점 더 많은 비즈니스 애플리케이션이 **최신 데이터**를 요구하지만, 오늘날의 아키텍처는 웨어하우스로 들어오기 전에 데이터를 위한 별도의 스테이징 영역을 두고 주기적인 ETL/ELT 작업을 사용하여 로드함으로써 **데이터의 최신성 부족(staleness)을 증가시킵니다**
. 이론적으로는 데이터 웨어하우스를 더 빠르게 업데이트하기 위해 더 많은 스트리밍 파이프라인을 구현할 수 있지만, 이는 여전히 배치(batch) 작업보다 운영하기가 어렵습니다. 대조적으로, 1세대 플랫폼에서는 웨어하우스 사용자들이 파생된 데이터셋과 동일한 환경에서 운영 시스템으로부터 로드된 원시 데이터에 즉시 접근할 수 있었습니다. 고객 지원 시스템 및 추천 엔진과 같은 비즈니스 애플리케이션은 오래된 데이터로는 단순히 효과적이지 않으며, 웨어하우스를 쿼리하는 인간 분석가들조차 오래된 데이터를 주요 문제로 보고합니다
.
셋째, 많은 산업에서 **대부분의 데이터가 이제 비정형 데이터**입니다
. 조직들은 이미지, 센서 데이터, 문서 등을 수집하고 있으며, 이 데이터를 관리하기 위한 사용하기 쉬운 시스템을 필요로 합니다. 그러나 SQL 데이터 웨어하우스와 그 API는 이러한 데이터를 쉽게 지원하지 않습니다
.
마지막으로, 대부분의 조직은 이제 머신러닝 및 데이터 과학 애플리케이션을 배포하고 있지만, 이러한 애플리케이션은 데이터 웨어하우스나 데이터 레이크에서 제대로 지원되지 않습니다
. 앞서 논의했듯이, 이러한 애플리케이션은 SQL이 아닌 코드로 대량의 데이터를 처리해야 하므로, ODBC/JDBC를 통해 효율적으로 실행될 수 없습니다. 고급 분석 시스템이 계속 발전함에 따라, **개방형 형식의 데이터에 직접 접근할 수 있도록 하는 것이 이들을 지원하는 가장 효과적인 방법**이 될 것이라고 생각합니다. 또한, ML 및 데이터 과학 애플리케이션은 데이터 품질, 일관성, 격리 등 기존 애플리케이션이 겪는 동일한 데이터 관리 문제에 직면하므로, DBMS 기능을 데이터에 가져오는 것은 엄청난 가치가 있습니다
.
**레이크하우스를 향한 현재의 단계:** 현재의 여러 산업 동향은 고객들이 투-티어 레이크 + 웨어하우스 모델에 불만을 가지고 있다는 추가적인 증거를 제공합니다
.
* 첫째, 최근 몇 년 동안 **거의 모든 주요 데이터 웨어하우스가 Parquet 및 ORC 형식의 외부 테이블에 대한 지원을 추가했습니다**
. 이는 웨어하우스 사용자가 동일한 SQL 엔진에서 데이터 레이크를 쿼리할 수 있도록 하지만, 데이터 레이크 테이블 관리를 더 쉽게 만들거나 웨어하우스 데이터에 대한 ETL 복잡성, 최신성 부족 및 고급 분석 과제를 제거하지는 않습니다. 실제로, 이러한 커넥터는 SQL 엔진이 주로 자체 내부 데이터 형식에 최적화되어 있기 때문에 성능이 좋지 않은 경우가 많습니다
.
* 둘째, Spark SQL, Presto, Hive, AWS Athena
와 같이 **데이터 레이크 스토리지에 직접 실행되는 SQL 엔진에 대한 광범위한 투자**가 있습니다. 그러나 이러한 엔진만으로는 데이터 레이크의 모든 문제를 해결하고 웨어하우스를 대체할 수 없습니다. 데이터 레이크는 여전히 ACID 트랜잭션과 같은 기본 관리 기능과 데이터 웨어하우스 성능에 필적하는 인덱스와 같은 효율적인 접근 방식이 부족합니다.

 

 

 

 

 

 

 

3. The Lakehouse Architecture