데이터 레이크하우스의 개념

(Data lakehouse in action의 1, 2장을 요약한 글입니다.)

 

Data Lakehouse in Action

-

저자

Pradeep Menon

출판

Packt Publishing

출판일

2022.03.17

 

데이터 레이크하우스

 

1. 데이터 분석 패턴의 진화

엔터프라이즈 데이터 웨어하우스(EDW) 시대

EDW 시대가 시작된 배경은 다음과 같았습니다.

• 분석은 리포팅과 같은 말이었습니다.
• 데이터베이스 구조를 리포팅하는데 최적화하는 것이 최우선 목표였습니다.
• Ralph Kimball, Bill Inmon에 의해 1990, 2000년대에 활성화되었습니다.

 

EDW의 패턴은 다음과 같았습니다.

• Flat Files, Databases -> ETL -> EDW -> Data Marts -> BI

 

EDW는 오랜 시간동안 자리를 유지했는데, 리포트 요구사항에 초점을 맞춘 패턴이어서 많은 회사들의 리포팅 요구사항들을 효율적으로 해결할 수 있었습니다. 그리고 대규모 엔터프라이즈 데이터 모델은 데이터를 논리적 모델과 물리적 모델로 구조화하고 조직화할 수 있었습니다.

 

데이터 웨어하우스는 오랜 시간 자리를 차지했으나 상황이 바뀌기 시작했습니다.

• 급박하게 바뀌는 비즈니스 요구사항을 빠르게 맞추기 힘들었습니다.
• 리포팅 요구사항을 변경하기 위해서는 데이터 모델, ETL 코드 등 변경이 필요했는데 오랜 시간이 필요했습니다.
• JSON을 수용하기 위한 기술이 개발되었습니다.
• AI가 급속도로 발전했으나 DW는 BI에 중점을 두었기 때문에 도움이 되지 않았습니다.

 

 

데이터 레이크 시대

데이터 레이크 시대의 배경에는 5가지 핵심 요소들의 변화가 있었습니다.

• 데이터의 기하급수적인 증가
• 컴퓨터 성능의 증가
• 스토리지 비용 감소
• AI의 성장
• 클라우드 컴퓨팅의 발전

 

2004년에 구글 리서처 Jeffery Dean과 Sanjay Ghemawat이 MapReduce 논문을 냈습니다. 그 방식은 다음과 같았습니다.

• 데이터를 여러 파일로 분산하고 클러스터의 다양한 노드에 분산
• 계산 노드를 사용하여 각 클러스터의 노드에서 로컬로 데이터 처리
• 각 노드와 통신하고 최종 출력을 위해 데이터를 집계하는 오케스트레이터 사용

 

MapReduce는 다음과 같은 이점을 가지고 있었습니다.

• 구조화되거나 구조화되지 않은 데이터를 모두 제공할 수 있었습니다.
• json 형식으로 데이터를 저장하고 처리할 수 있었습니다.
• 이미지도 처리할 수 있었습니다.
• 데이터 레이크 패턴은 데이터의 큰 볼륨을 비교적 더 싼 가격에 제공할 수 있었다.
• 빠르게 바뀌는 요구사항에 빠르게 대처할 수 있었고 AI 기술도 따라갈 수 있었습니다.

 

데이터 레이크는 챌린지를 맞이하게 되었습니다. 데이터 레이크의 철학은 데이터를 먼저 수집한 뒤 무엇을 할지 파악하는 것입니다. 그래서 데이터 늪이 되기 쉬웠고, 관리하기가 어려웠습니다. 또 오픈소스에 의존하게 되었는데 오픈소스는 커뮤니티 중심이고 보안 등 회사에 중요한 기능을 제공하지 않았습니다. 또한 BI에 중점을 두지 않았기 때문에 리포팅이 어려웠습니다.

 

데이터 레이크하우스 시대

데이터 레이크하우스는 데이터 웨어하우스와 데이터 레이크하우스의 장점을 모아두려고 했습니다.

• Data Lake의 장점
  • 구조화되거나 구조화되지 않은 데이터 지원
  • 신속한 실험
  • 유연한 스토리지
  • Scalable Compute
  • AI-Focused
• Data Warehouse의 장점
  • 광범위한 데이터 거버넌스
  • 강력한 보안 구조
  • 검증된 데이터 관리
  • BI-Focused
  • 분석 인사이트 도출

 

2. 데이터 레이크하우스 아키텍처

시스템 컨텍스트

시스템 컨텍스트에서 데이터 레이크하우스는 데이터 제공자와 데이터 소비자 둘로 이루어져 있습니다.

 

 

데이터 제공자의 종류

• Operational System Data
• Text Data
• Streaming Data
• Media Data

 

데이터 소비자의 종류

• Data Scientists
• Analysts
• Management Personnels
• Reporting Systems
• Downstream Application Systems
• API-based systems
• Data Sharing Systems

 

논리 데이터 레이크하우스 아키텍처

레이크하우스 아키텍처는 두 가지에 집중합니다.

• functional requirements (FRs)
  • 특정 비즈니스 동작을 위한 작업/요구사항에 따라 결정됩니다.
• non-functional requirements (NFRs)
  • 특정 컨텍스트에서 도움이 되기 위해 충족해야하는 기준을 지정하는 요구 사항
    • 예: 쿼리 완료 예상 시간, 암호화 요구 사항 등

 

데이터 레이크하우스의 7가지 레이어

수집 레이어

• 배치 데이터 수집 서비스
• 실시간 데이터 수집 서비스

 

데이터 레이크 레이어

4가지의 범주로 나눠집니다.

• Raw Data
• Intermediate Data: 빠른 처리를 위한 중간 데이터 저장소
• Processed Data: 처리된 데이터
• Archived Data: 자주 접근하지 않는 데이터

 

데이터 처리 레이어

• 배치 데이터 처리 서비스
• 스트리밍 데이터 처리 서비스

 

데이터 서빙 레이어

• 데이터 웨어하우스 서비스
• 실시간 데이터 서비스
• API 기반 데이터 서비스
• 데이터 공유 서비스

 

데이터 분석 레이어

• 분석적 샌드박스 서비스(Analytical Sandbox Service)
• AI/ML 서비스
• Business Intelligence Service

 

데이터 거버넌스 레이어

• Data Policy Management
  
  • 기술이 아닌 데이터의 표준, 보안, 무결성, 품질 및 데이터 사용을 제어하는 규칙을 설명하는 설명입니다.
• Data Curation and Cataloging Service
  
  • 데이터에 대한 시각적 정보를 얻을 수 있는 장소입니다.
  • 예를 들면 데이터 리니지가 있습니다.
• Data Quality Service
  
  • 데이터의 안정성과 유용성을 결정하는 데이터 품질 점수가 있어야 합니다.
    
    • 완전성
    • 데이터의 일관성
    • 데이터의 정확성
     

 

데이터 보안 레이어 

• IAM Service
• Data Encryption Service
• Data Masking Service
• Network Security Service

 

아키텍처 원칙

다음 원칙들은 데이터 레이크하우스를 만들게 되면 반드시 지켜야하는 원칙들입니다.

 

1. core는 규율있게, edge는 유연하게

데이터가 저장되는 계층은 구조화되어야 하고, 모호하지 않은 세부적인 거버넌스 정책이 있어야 합니다.

인사이트에 도움이 되는 계층은 유연해야 합니다. 그러나 그냥 방치하는 것이 아니라 데이터 레이크하우스의 정책 내에서 관리는 되어야 합니다.

 

2. De-couple compute and storage

스토리지는 저렴하고 영구적이지만 컴퓨팅은 비용이 많이 듭니다. 컴퓨팅 서비스는 온디멘드로 가동하고 필요할 때 확장할 수 있는 구조여야 합니다.

 

3. 기술보다는 기능에 집중

기술은 계속 변화하기 때문에 기능에 집중해야 합니다.

 

4. moduler architecture

아키텍처의 부품을 다른 곳에 영향을 주지 않고 교체할 수 있도록 만들어야 합니다.

 

5. perform active cataloging
데이터 늪이 되지 않기 위해 카탈로그를 작성해야 하고 수명주기를 관리해야 합니다.