주요 컨텐츠로 이동

모던 레이크하우스에서의 데이터 모델링 모범 사례 및 구현

Dimensional Modeling Best practice & Implementation on Modern Lakehouse

발행일: 2022년 10월 20일

솔루션2 min read

많은 고객들이 기존 데이터 웨어하우스를 Databricks Lakehouse로 마이그레이션하고 있습니다. 이는 데이터 웨어하우스를 현대화할 뿐만 아니라 성숙한 스트리밍 및 고급 분석 플랫폼에 즉시 액세스할 수 있기 때문입니다. Lakehouse는 스트리밍, ETL, BI 및 AI 요구 사항을 모두 충족하는 단일 플랫폼이므로 모든 것을 처리할 수 있으며, 비즈니스 팀과 데이터 팀이 단일 플랫폼에서 협업할 수 있도록 지원합니다.

현장에서 고객을 지원하면서 많은 고객들이 Databricks에서 적절한 데이터 모델링 및 물리적 데이터 모델 구현에 대한 모범 사례를 찾고 있다는 것을 알게 되었습니다.

이 글에서는 Databricks Lakehouse 플랫폼에서 차원 모델링의 모범 사례에 대해 더 깊이 알아보고, 테이블 생성 및 DDL 모범 사례를 사용하여 물리적 데이터 모델 구현의 실제 예시를 제공하고자 합니다.

이 블로그에서 다룰 주요 내용은 다음과 같습니다.

  1. 데이터 모델링의 중요성
  2. 일반적인 데이터 모델링 기법
  3. 데이터 웨어하우스 모델링 DDL 구현
  4. Databricks Lakehouse에서의 데이터 모델링 모범 사례 및 권장 사항

데이터 웨어하우스를 위한 데이터 모델링의 중요성

데이터 모델은 데이터 웨어하우스를 구축하는 데 있어 가장 중요한 부분입니다. 일반적으로 프로세스는 의미론적 비즈니스 정보 모델, 논리적 데이터 모델, 그리고 마지막으로 물리적 데이터 모델(PDM)을 방어하는 것으로 시작됩니다. 이 모든 것은 적절한 시스템 분석 및 설계 단계에서 시작되며, 비즈니스 정보 모델과 프로세스 흐름이 먼저 생성되고, 조직 내 비즈니스 프로세스에 따라 주요 비즈니스 엔터티, 속성 및 상호 작용이 캡처됩니다. 그런 다음 논리적 데이터 모델이 엔터티 간의 관계를 보여주도록 생성되며, 이는 기술에 독립적인 모델입니다. 마지막으로, 쓰기 및 읽기가 효율적으로 수행될 수 있도록 기본 기술 플랫폼을 기반으로 PDM이 생성됩니다. 우리 모두 알다시피, 데이터 웨어하우징을 위해 스타 스키마데이터 볼트와 같은 분석 친화적인 모델링 스타일이 매우 인기가 있습니다.

Databricks에서 물리적 데이터 모델 생성 모범 사례

정의된 비즈니스 문제를 기반으로 데이터 모델 설계의 목표는 재사용성, 유연성 및 확장성을 위해 데이터를 쉽게 표현하는 것입니다. 다음은 각 트랜잭션을 저장하는 판매 사실 테이블과 데이터를 슬라이스하고 다이싱하는 고객, 제품, 매장, 날짜 등의 다양한 차원 테이블을 보여주는 일반적인 스타 스키마 데이터 모델입니다. 특정 월에 가장 인기 있는 제품은 무엇인지 또는 분기에 가장 실적이 좋은 매장은 어디인지와 같은 특정 비즈니스 질문에 답하기 위해 차원을 사실 테이블에 조인할 수 있습니다. Databricks에서 이를 구현하는 방법을 살펴보겠습니다.

스타 스키마가 작동하는 방식을 보여주는 다이어그램으로, 팩트와 차원이 레이크하우스에 구축됨
레이크하우스의 차원 모델
가이드

최신 분석을 위한 컴팩트 가이드

Databricks에서의 데이터 웨어하우스 모델링 DDL 구현

다음 섹션에서는 예제를 사용하여 아래 내용을 시연하겠습니다.

  • 3단계 카탈로그, 데이터베이스 및 테이블 생성
  • 기본 키, 외래 키 정의
  • 대리 키를 위한 ID 열
  • 데이터 품질을 위한 열 제약 조건
  • 인덱스, 최적화 및 분석
  • 고급 기법

1. Unity Catalog - 3단계 네임스페이스

Unity Catalog는 Databricks 거버넌스 계층으로, Databricks 관리자와 데이터 관리자가 Databricks 계정의 모든 워크스페이스에서 단일 메타스토어를 사용하여 사용자 및 데이터 액세스를 중앙에서 관리할 수 있도록 합니다. 다른 워크스페이스의 사용자는 Unity Catalog에서 중앙에서 부여된 권한에 따라 동일한 데이터에 대한 액세스를 공유할 수 있습니다. Unity Catalog는 데이터를 구성하는 3단계 네임스페이스(카탈로그.스키마(데이터베이스).테이블)를 가지고 있습니다. Unity Catalog에 대해 자세히 알아보세요.

Unity Catalog - 3단계 네임스페이스

Unity Catalog - 3단계 네임스페이스

섹션의 뒷부분에서 사용할 카탈로그와 스키마를 테이블 생성 전에 설정하는 방법은 다음과 같습니다. 예시에서는 카탈로그 US_Stores와 스키마(데이터베이스) Sales_DW를 생성하고 사용합니다.

카탈로그 및 데이터베이스 설정

다음은 3단계 네임스페이스를 사용하여 fact_sales 테이블을 쿼리하는 예시입니다.

카탈로그.데이터베이스.테이블 이름으로 테이블을 쿼리하는 예시
카탈로그.데이터베이스.테이블 이름으로 테이블을 쿼리하는 예시

2. 기본 키, 외래 키 정의

기본 키와 외래 키 정의는 데이터 모델을 생성할 때 매우 중요합니다. PK/FK 정의를 지원하는 기능은 Databricks에서 데이터 모델을 매우 쉽게 정의할 수 있게 해줍니다. 또한 분석가가 Databricks SQL Warehouse에서 조인 관계를 빠르게 파악하여 효과적으로 쿼리를 작성할 수 있도록 도와줍니다. 대부분의 다른 대규모 병렬 처리(MPP), EDW 및 클라우드 데이터 웨어하우스와 마찬가지로 PK/FK 제약 조건은 정보 제공용입니다. Databricks는 PK/FK 관계를 강제하지는 않지만, 의미론적 데이터 모델 설계를 쉽게 할 수 있도록 정의할 수 있는 기능을 제공합니다.

다음은 store_id를 ID 열로 사용하고 동시에 기본 키로 정의하여 dim_store 테이블을 생성하는 예시입니다.

기본 키 정의로 스토어 차원을 생성하기 위한 DDL 구현

테이블이 생성된 후, 아래 테이블 정의에서 기본 키(store_id)가 제약 조건으로 생성된 것을 볼 수 있습니다.

기본 키 store_id가 테이블 제약 조건으로 표시됨
기본 키 store_id가 테이블 제약 조건으로 표시됨

다음은 transaction_id를 기본 키로 사용하고, 차원 테이블을 참조하는 외래 키를 사용하여 fact_sales 테이블을 생성하는 예시입니다.

외래 키 정의로 판매 사실을 생성하기 위한 DDL 구현

사실 테이블이 생성된 후, 아래 테이블 정의에서 기본 키(transaction_id)와 외래 키가 제약 조건으로 생성된 것을 볼 수 있습니다.

차원을 참조하는 기본 키 및 외래 키가 있는 사실 테이블 정의
차원을 참조하는 기본 키 및 외래 키가 있는 사실 테이블 정의

3. 대리 키를 위한 ID 열

ID 열은 데이터베이스에서 각 새 데이터 행에 고유 ID 번호를 자동으로 생성하는 열입니다. 이는 데이터 웨어하우스에서 대리 키를 생성하는 데 일반적으로 사용됩니다. 대리 키는 시스템에서 생성된 의미 없는 키이므로, 행의 고유성을 식별하기 위해 다양한 자연 기본 키 및 여러 필드의 연결에 의존할 필요가 없습니다. 일반적으로 이러한 대리 키는 데이터 웨어하우스에서 기본 키 및 외래 키로 사용됩니다. ID 열에 대한 자세한 내용은 이 블로그에서 다룹니다. 다음은 1부터 시작하여 1씩 증가하는 값이 자동으로 할당된 ID 열 customer_id를 생성하는 예시입니다.

고객 차원 생성을 위한 DDL 구현 (ID 컬럼 포함)

4. 데이터 품질을 위한 컬럼 제약 조건

기본 키 및 외래 키 정보 제약 조건 외에도 Databricks는 테이블에 추가되는 데이터의 품질과 무결성을 보장하기 위해 시행되는 컬럼 수준의 데이터 품질 검사 제약 조건을 지원합니다. 이러한 제약 조건은 자동으로 검증됩니다. NOT NULL 제약 조건과 컬럼 값 제약 조건이 좋은 예시입니다. 다른 클라우드 데이터 웨어하우스와 달리 Databricks는 컬럼 값 검사 제약 조건을 제공하여 특정 컬럼의 데이터 품질을 보장하는 데 매우 유용합니다. 아래에서 볼 수 있듯이 valid_sales_amount 검사 제약 조건은 테이블에 추가되기 전에 모든 기존 행이 제약 조건을 만족하는지 (즉, sales amount > 0) 확인합니다. 더 자세한 내용은 여기에서 확인할 수 있습니다.

다음은 store_idsales_amount에 유효한 값이 있는지 확인하기 위해 각각 dim_storefact_sales에 제약 조건을 추가하는 예시입니다.

기존 테이블에 컬럼 제약 조건을 추가하여 데이터 품질 보장

5. 인덱싱, 최적화 및 분석

기존 데이터베이스에는 b-tree 및 비트맵 인덱스가 있지만, Databricks는 다차원 Z-order 클러스터링 인덱싱과 같은 훨씬 발전된 형태의 인덱싱을 제공하며 Bloom 필터 인덱싱도 지원합니다. 우선, Delta 파일 형식은 Parquet 파일 형식을 사용하며, 이는 컬럼 압축 파일 형식이므로 컬럼 가지치기(column pruning)에 이미 매우 효율적입니다. 여기에 z-order 인덱싱을 사용하면 페타바이트 규모의 데이터를 초당 처리할 수 있습니다. Z-orderBloom 필터 인덱싱 모두 대규모 Delta 테이블에 대한 매우 선택적인 쿼리에 응답하는 데 필요한 데이터 양을 극적으로 줄여주며, 이는 일반적으로 런타임 성능 향상과 비용 절감으로 이어집니다. 가장 자주 조인에 사용되는 기본 키와 외래 키에 Z-order를 사용하세요. 필요한 경우 추가 Bloom 필터 인덱싱을 사용하세요.

성능 향상을 위해 customer_id 및 product_id별로 fact_sales 최적화

특정 컬럼에 대한 데이터 건너뛰기(data skipping)를 활성화하기 위해 Bloomfilter 인덱스 생성

다른 모든 데이터 웨어하우스와 마찬가지로, 쿼리 최적화 프로그램이 최상의 쿼리 계획을 생성할 수 있도록 통계를 업데이트하기 위해 ANALYZE TABLE을 사용할 수 있습니다.

최상의 쿼리 실행 계획을 위해 모든 컬럼에 대한 통계 수집

6. 고급 기법

Databricks는 테이블 파티셔닝과 같은 고급 기법을 지원하지만, 데이터 양이 수 테라바이트 이상일 때만 제한적으로 사용하세요. 대부분의 경우 OPTIMIZE 및 Z-ORDER 인덱싱만으로도 최상의 파일 및 데이터 가지치기(pruning)가 가능하므로 날짜나 월별로 테이블을 파티셔닝하는 것은 거의 좋지 않은 방법입니다. 하지만 테이블 DDL이 자동 최적화 및 자동 컴팩션으로 설정되어 있는지 확인하는 것이 좋습니다. 이를 통해 작게 생성된 자주 쓰이는 데이터가 Delta의 더 큰 컬럼 압축 형식으로 컴팩트화됩니다.

시각적 데이터 모델링 도구를 활용하고 싶으신가요? 저희 파트너인 Quest의 erwin Data Modeler를 사용하여 몇 번의 클릭만으로 Databricks에서 스타 스키마, 데이터 볼트 및 모든 산업 데이터 모델을 역엔지니어링, 생성 및 구현할 수 있습니다.

Databricks 노트북 예제

Databricks 플랫폼을 사용하면 다양한 데이터 모델을 쉽게 설계하고 구현할 수 있습니다. 위의 모든 예제를 완전한 워크플로우로 보려면 이 예제를 참조하세요.

또한 관련 블로그인 Databricks Delta Lake를 사용하여 스타 스키마를 구현하는 5가지 간단한 단계도 확인해 보세요.

Lakehouse에서 차원 모델 구축 시작하기

Databricks를 14일간 무료로 사용해 보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

게시물을 놓치지 마세요

관심 있는 카테고리를 구독하고 최신 게시물을 받은편지함으로 받아보세요