Transactional Data Lake - (1)

✅ 포스팅 요약

이번 포스팅에서는 데이터 엔지니어링 분야에서 비중 있는 역할을 차지하고 있는 데이터 레이크(Data Lake)와 트랜잭셔널 데이터 레이크(Transactional Data Lake)에 대해 다룰 예정입니다. (갑자기 뭔 트랜잭셔널 데이터 레이크라고 물으신다면... 그냥 제가 트랜잭셔널 데이터 레이크에 관심이 생겨서 입니다.)

데이터 엔지니어링 또는 데이터 분석에 관심이 생기신 분들이 기초 개념을 이해하는데 도움이 되었으면 좋겠습니다.

이번 포스팅에서는 데이터 레이크와 트랜잭셔널 데이터 레이크의 개념 설명이 주를 이룰 것이고, 다음 포스팅에서는 실제로 AWS 서비스를 이용하여 각각의 데이터 레이크를 구축하는 방법에 대해 다룰 예정입니다.

여튼 많관부!

🚨 목차
1. 데이터 레이크(Data Lake) 소개
1. 데이터 레이크의 한계점
2. 트랜잭셔널 데이터 레이크(Transactional Data Lake) 소개
3. 트랜잭셔널 데이터 레이크 구축을 위한 핵심 기술 (= Open Table Format)

1️⃣ 데이터 레이크 소개

데이터 레이크의 등장 배경

이전에는 데이터 저장과 분석을 위한 기본 도구로 데이터베이스가 사용되었습니다.
여기서 데이터베이스란 Oracle, MySQL, Microsoft Server SQL 등을 지칭한다고 이해해주시면 될 것 같습니다.
데이터를 데이터베이스에 저장할 때는 몇가지 제약이 있습니다:

• 스키마(Schema)를 정의해야 합니다.
  CREATE TABLE를 할 때 각 Field의 Data Type을 정의하고, Primary Key, Foreign Key, Partition Key 등을 정의합니다.

• 모든 데이터가 스키마에 맞아야 합니다.
  INSERT INTO를 할 때 삽입하려는 데이터가 이미 정의한 스키마에 맞아야 합니다.
  INSERT INTO 이외 다른 트랜잭션을 할 때도 이미 정의한 스키마에 맞아야 합니다.

• 이것 이외에도 지켜야 할 제약 조건이 엄~청 많습니다.

즉, 데이터베이스에는 스키마를 정의할 수 있는 정형 데이터(Structured Data)만 저장할 수 있습니다.

하지만 시대가 변하면서 아래와 같은 다양한 형태의 데이터가 발생하였고, 그런 데이터들을 저장할 필요가 생겼습니다:

• 반정형 데이터(Semi-structured Data):
  반정형 데이터의 대표적인 예시로는 JSON, XML 등이 있습니다.
• 비정형 데이터(Unstructured Data):
  비정형 데이터의 대표적인 예시로는 텍스트 문서, 이미지 파일, 동영상 파일 등이 있습니다.

이런 반정형 데이터와 비정형 데이터는 스키마를 정의하기 어렵거나 불가능하고, 그렇기 때문에 기존의 데이터 레포지토리인 데이터베이스에 저장할 수 없죠.
그래서 이런 다양한 형태의 데이터를 편하게 저장하기 위해 등장한 것이 데이터 레이크입니다.

데이터 레이크의 장점

데이터베이스와 비교했을 때 데이터 레이크가 갖는 장점을 정리해봤습니다.

• 다양한 데이터 수용:
  데이터 레이크는 비정형, 반정형, 정형 데이터를 모두 수용합니다.
  이는 다양한 데이터 소스(Data Source)에서 나오는 데이터를 효과적으로 수집하고 통합할 수 있는 장점을 제공합니다.

• 데이터 분석 및 시각화:
  데이터 레이크에서는 데이터를 원시 형태로 저장하기 때문에 필요한 시기에 적절한 방식으로 가공하고 분석할 수 있습니다.
  이를 통해 데이터 분석가와 과학자는 데이터를 탐색하고 새로운 통찰력을 발견할 수 있습니다.

• 스케일링과 성능:
  데이터 레이크는 가변적인 스케일링을 통해 대량의 데이터 처리를 지원합니다.
  이는 대용량 데이터를 신속하게 처리하고 높은 성능을 유지하는 데 도움이 됩니다.
  데이터베이스는 생성 단계에서 스토리지 용량을 정하면 그 이후에는 스토리지 용량을 바꾸기 어렵습니다.
  즉, 수평 확장(Horizontal Scaling)이 어려운 것인데 그 이유는 데이터베이스에 저장되는 데이터가 스키마를 갖는 정형 데이터이기 때문이죠.
  수평 확장을 한다는 것은 데이터가 분산 저장된다는 것인데, 트랜잭션과 ACID(원자성, 일관성, 고립성, 지속성) 속성을 유지해야 되는 데이터베이스 입장에는 데이터가 분산된다면 골치 아파지는 거죠.
  이것 말고도 각 테이블 별로 관계를 맺고 있기 때문에 데이터를 분산 저장하는 것이 어렵습니다.

• 비용 효율성:
  기존의 데이터 웨어하우스와 비교하여 데이터 레이크는 저장 비용이 상대적으로 저렴합니다.
  또한 필요한 데이터만 가공하여 분석할 수 있어서 불필요한 비용을 절감할 수 있습니다.

2️⃣ 데이터 레이크의 한계점

위에서는 데이터 레이크의 장점을 나열했는데요.
반대로 데이터 레이크가 갖는 한계점도 분명히 존재합니다.
(싼게 비지 떡이라는 말이 괜히 있는게... 읍읍)
데이터베이스 = 컴퓨팅 리소스 + 스토리지 vs. 데이터 레이크 = 스토리지
➡️ 데이터 레이크가 저렴한 이유는 컴퓨팅 리소스가 없기 때문입니다.
그렇기 때문에 데이터 레이크에는 다양한 한계점이 있습니다:

• 스키마의 결여와 데이터 유형의 다양성:
  데이터 레이크는 반정형과 비정형 데이터를 포함하는데, 이러한 데이터들은 스키마가 없거나 유연한 스키마를 가질 수 있습니다.
  이로 인해 데이터 검색과 분석 과정에서 데이터의 의미를 이해하기 어려울 수 있습니다.

• 데이터의 신뢰성과 일관성:
  데이터 레이크에 저장된 데이터는 다양한 소스에서 추출되는데, 이 때 데이터의 품질과 일관성을 유지하기 어려울 수 있습니다.
  데이터의 신뢰성과 일관성을 확보하려면 추가적인 데이터 처리와 검증 작업이 필요합니다.

• 데이터 엑세스와 보안:
  데이터 레이크는 다양한 사용자 및 업무 부서가 데이터에 접근하고 분석을 수행할 수 있어야 합니다.
  이로 인해 데이터 접근과 보안을 관리하는 것이 어려워질 수 있습니다. 민감한 데이터에 대한 접근 제어와 보안 강화가 필요합니다.

• 데이터 무결성과 품질:
  데이터 레이크에는 다양한 형태의 데이터가 쌓이기 때문에 데이터의 무결성과 품질을 유지하는 것이 도전적입니다.
  잘못된 데이터가 분석에 영향을 미칠 수 있으며, 데이터의 정확성을 유지하기 위한 노력이 필요합니다.

• 트랜잭션과 ACID 특성의 부재:
  데이터 레이크는 일반적으로 배치 처리 기반으로 동작하며, 트랜잭션과 ACID(원자성, 일관성, 고립성, 지속성) 특성을 제공하지 않을 수 있습니다.
  따라서 복잡한 트랜잭션 처리가 필요한 시나리오에서는 한계가 있을 수 있습니다.

사실 제가 생각하는 데이터 레이크의 가장 치명적인 한계점은 데이터 소스에서 발생한 변화가 자동으로 데이터 레이크에 반영되지 않기 때문에 발생하는 데이터 소스와 데이터 레이크 사이의 일관성 결여입니다.
솔직히 말해서 저장하려는 데이터가 정형 데이터이고, 기업에 돈만 많으면 데이터 레이크고, 데이터 웨어하우스고 고려할 필요도 없이 그냥 데이터베이스를 쓰면 되는 것 아닌가 싶습니다.

3️⃣ 트랜잭셔널 데이터 레이크 소개

트랜잭셔널 데이터 레이크 정의

위에서 언급한 기존 데이터 레이크의 한계 때문에 등장한 것이 트랜잭셔널 데이터 레이크(Transactional Data Lake)입니다.
트랜잭셔널 데이터 레이크 = 기존 데이터 레이크 + 트랜잭션 지원
저렴한 데이터 레이크를 데이터베이스처럼 사용하기 위해 등장한 개념이라고 생각하면 될 것 같습니다.

트랜잭셔널 데이터 레이크의 장점

• ACID 트랜잭션 지원:
  트랜잭셔널 데이터 레이크는 기존 데이터 레이크에 ACID(Automicity, Consistency, Isolation, Durability) 특성을 추가한 것입니다.
  ACID는 데이터베이스 관련 작업에서 중요한 특성으로, 데이터의 원자성, 독립성, 지속성을 보장하는 것을 의미합니다.
  트랜잭셔널 데이터 레이크는 이러한 ACID 특성을 데이터 레이크에 적용하여 데이터의 변경 관리와 일관성을 강화합니다.
  따라서 트랜잭셔널 데이터 레이크에서는 다양한 데이터 조작 작업이 가능합니다.
  예를 들어, 데이터의 삽입, 갱신, 삭제 등의 작업을 트랜잭션 단위로 수행할 수 있습니다.

• 버전 관리 지원:
  데이터의 버전 관리, 롤백 기능을 제공합니다.
  이 기능을 사용하면 특정 시점에서 데이터의 이전 상태로 돌아갈 수 있으며, 해당 시점에서 데이터의 값을 탐색하거나 분석할 수 있습니다.
  이는 데이터의 변화를 추적하고 데이터의 특정 시점에서의 상태를 확인하는 데 유용합니다.

요약하자면, 트랜잭셔널 데이터 레이크는 대량의 데이터를 처리하고 분석하는 동시에 데이터의 일관성과 신뢰성을 유지하고자 하는 경우에 유용합니다.

4️⃣ 트랜잭셔널 데이터 레이크 구축을 위한 핵심 기술

이런 트랜잭셔널 데이터 레이크를 구축하는데 필요한 것이 있습니다.
바로, 오픈 테이블 포맷(Open table format)입니다.
오픈 테이블 포맷은 오픈 소스로 개발된 테이블 포맷입니다.
테이블 포맷이란 여러 파일로 분산되어 저장된 데이터를 하나의 테이블로 추상화해주는 기술입니다.
데이터 레이크나 데이터 웨어하우스에서는 대용량의 데이터가 여러 파일로 저장되는 경우가 많은데, 이러한 파일들을 효율적으로 관리하고 쿼리할 수 있도록 하기 위해 테이블 포맷을 사용합니다.
현재 트랜잭셔널 데이터 레이크를 위해 사용되는 오픈 테이블 포맷으로는 3가지가 있습니다:

• Apache Hudi
• Apache Iceberg
• Delta Lake

3가지 오픈 테이블 포맷이 개발되었던 초기에는 각자 조금씩 다른 목적을 갖고 개발되었습니다.
Apache Hudi는 Uber에서 증분 처리(Incremental Processing)을 위해 개발하기 시작했습니다.
Apache Iceberg는 넷플릭스에서 대용량 데이터 테이블을 S3와 같은 객체 저장소(Object Stores)에서 효율적으로 관리하고 처리하기 위해 개발하기 시작했습니다.
Delta Lake는 Databricks에서 ACID 트랜잭션 보장하여 일관성 있는 읽기/쓰기를 위해 개발하기 시작했습니다.

그래서 내부적으로 데이터를 저장하고 처리하는 기술은 조금씩 다릅니다.
나중에 기회가 된다면 이에 대한 것도 블로그에서 다루겠습니다.

하지만 각각의 오픈 테이블 포맷의 버전이 업그레이드 될 때마다 사용자 입장에서 느끼기에는 점점 비슷해지고 있는게 사실입니다.
세 가지 오픈 테이블 포맷을 비교/대조한 AWS 테크 블로그가 있으니 관심 있으신 분은 확인해보세요.

다음에는 AWS에서 Glue Data Catalog, Glue Job 그리고 S3를 이용해 실제로 트랜잭셔널 데이터 레이크를 구축하는 방법에 대한 포스팅으로 돌아오겠습니다.