Databricks SQL을 사용하여 차원 데이터 웨어하우스 구현하기: 1부

점점 더 많은 조직이 데이터 웨어하우스 워크로드를 Databricks로 이전하고 있습니다. Databricks 플랫폼의 탄력적인 특성과 쿼리 실행 엔진의 상당한 개선으로 인해 Databricks는 데이터 웨어하우스 쿼리 성능과 비용 성능 모두에서 세계 기록을 경신했으며, 분석 인프라 통합을 위한 점점 더 매력적인 옵션이 되고 있습니다.

이러한 노력을 지원하기 위해 Databricks가 다양한 데이터 웨어하우스 설계 접근 방식을 지원하는 방법에 대해 이전에 블로그 게시물을 작성했습니다. 이 블로그 시리즈에서는 데이터 웨어하우징에서 가장 인기 있는 접근 방식 중 하나인 차원 모델링에 대해 자세히 살펴보고자 합니다. 차원 모델링은 스타 스키마와 스노우플레이크 스키마로 특징지어지는 디자인 패턴이며, 이 접근 방식을 지원하기 위해 널리 채택된 표준화된 추출, 변환 및 로드(ETL) 패턴을 자세히 살펴보겠습니다.

차원 모델링 커뮤니티에 널리 제공하기 위해 이 모델링 접근 방식과 관련된 고전적인 패턴을 엄격하게 따를 것입니다. 이 정보는 다음 블로그 게시물에 걸쳐 제공될 것입니다.

• 파트 1: (차원) 데이터 개체 정의 (이 게시물)
• 파트 2: 차원 ETL 워크플로 구축
• 파트 3: 사실 ETL 워크플로 구축 

또한, AdventureWorksDW 데이터베이스에서 더 일반적으로 사용되는 스타 스키마 중 하나(그림 1)를 중심으로 디자인 토론을 진행할 것입니다. 이 데이터베이스는 Microsoft에서 만든 샘플 데이터베이스이며 데이터 웨어하우스 및 비즈니스 인텔리전스 교육 목적으로 널리 사용됩니다.

데이터 웨어하우징에서 차원 모델링이란 무엇인가요?

차원 모델링은 빠른 쿼리 성능을 위해 데이터 저장을 최적화합니다. 데이터를 사실과 차원으로 구성하면 여러 관점에서 데이터를 쉽게 분석할 수 있습니다. 또한 여러 각도에서 동시에 데이터를 탐색할 수 있습니다(다차원 분석).

데이터 웨어하우스의 네 가지 차원은 무엇인가요?

그림 1에서 알 수 있듯이 데이터 웨어하우징의 스타 스키마에는 여러 차원이 포함되지만, 데이터 웨어하우징의 네 가지 주요 차원에는 일반적으로 다음이 포함됩니다.

시간: 이는 추세를 평가하거나 비교를 수행하는 데 필수적인 기록 추적 프레임워크를 제공합니다. 계절별 비즈니스 변화 또는 재고 관리를 최적화하기 위해 데이터를 특정 시간 간격(일, 주, 년)으로 분류할 수 있습니다.

고객: 조직은 누가 제품을 구매하는지에 대한 정확한 통찰력을 필요로 합니다. 이름, 연락처 정보 및 인구 통계와 같은 정보는 유용한 시장 세분화를 제공하고 광고 지출 또는 전반적인 마케팅 전략과 같은 결정을 내리는 데 도움이 될 수 있습니다.

제품: 이 차원은 분석 중인 상품 또는 서비스를 정의하며, 판매량, 판매율 및 향후 성장을 위한 기회를 파악하기 위한 성능 분석을 수행하는 데 유용할 수 있습니다.

위치: 이벤트가 발생한 위치(지리적으로 또는 운영적으로)를 맥락화하면 조직은 고객이 거주할 가능성이 있는 위치를 기반으로 중요한 결정을 내리는 데 도움이 될 수 있습니다.

물리적 모델

Databricks 플랫폼 내에서 사실과 차원은 물리적 테이블로 구현됩니다. 이들은 데이터베이스와 유사한 카탈로그 내에 구성되며, 플랫폼이 지원하는 정보 자산의 폭에 대한 유연성이 더 높습니다. 그런 다음 카탈로그는 스키마로 세분화되어 카탈로그 내 개체 하위 집합에 대한 논리적 및 보안 경계를 생성합니다(그림 2).

차원 테이블

차원 테이블은 비교적 엄격한 구조 패턴 세트를 따릅니다. 순차 식별자인 대체 키는 일반적으로 사실 테이블과 차원 간의 안정적이고 효율적인 연결을 지원하기 위해 정의됩니다. 운영 시스템의 고유 식별자(종종 자연 키 또는 비즈니스 키라고 함)와 관련 비즈니스 속성의 비정규화된 모음이 일반적으로 뒤따릅니다. 식별자 뒤에는 일반적으로 지속적인 ETL 프로세스를 지원하기 위한 일련의 메타데이터 열이 있습니다. Databricks 플랫폼 내에서 고객 차원에 대해 표시된 대로 CREATE TABLE 문을 사용하여 차원 테이블을 구현할 수 있습니다.

Identity columns

이 예시에서는 대리 키 열인 CustomerKey에 대해 행을 삽입할 때 자동으로 순차적인 BIGINT 값을 생성하는 identity column을 사용합니다. identity column과 함께 ALWAYS 또는 BY DEFAULT 옵션을 사용할지 여부는 해당 필드에 대한 자체 값 삽입을 금지할지 허용할지에 따라 달라집니다.

Missing member entry

차원 테이블과 함께 구현되는 일반적인 패턴은 missing member 항목을 만드는 것입니다. 이 항목은 팩트 레코드가 차원에 대한 누락되거나 알 수 없는 연결과 함께 도착하는 시나리오에서 사용되며, BY DEFAULT 옵션이 사용될 때 여기에 표시된 것과 같이 미리 결정된 대리 키 값으로 생성될 수 있습니다.

Identity fields

모범 사례로, identity 필드에 값을 삽입할 때는 항상 ALTER TABLE statement와 SYNC IDENTITY 옵션을 사용하여 identity 필드의 메타데이터를 업데이트하는 것이 가장 좋습니다.

Data types

비즈니스/자연 키 및 소스 시스템의 데이터와 관련된 기타 필드의 경우, 소스 시스템 데이터 유형을 Databricks Platform에서 지원하는 데이터 유형(표 1)과 일치시켜야 합니다. 비트 값을 사용하는 메타데이터 필드의 경우, 0 또는 1과 같은 값에 대해 리터럴 처리를 더 쉽게 하기 위해 BOOLEAN 또는 TINYINT 데이터 유형 대신 INT 데이터 유형을 사용하는 경우가 많다는 점에 유의하세요.

Table 1. Databricks Platform에서 지원하는 데이터 유형

Fact tables

Fact 테이블도 구조적 규칙을 따릅니다. 주로 측정값과 관련 차원에 대한 외래 키 참조로 구성된 fact 테이블에는 트랜잭션 레코드에 대한 고유 식별자(또는 fact 레코드와 거의 일대일 관계에 있는 다른 설명 속성)가 포함될 수 있으며, 이를 degenerate dimensions라고 합니다. 또한 소스 시스템에서 데이터를 증분 로드( aka delta extract)을 지원하기 위한 메타데이터 필드를 포함할 수 있습니다. Databricks Platform 내에서 인터넷 판매 fact에 대해 여기에 표시된 것과 유사한 CREATE TABLE statement를 사용하여 fact 테이블을 구현할 수 있습니다.

외래 키 참조

이전 섹션의 차원 테이블에서 언급했듯이, Databricks 환경의 데이터 유형은 소스 시스템에서 사용되는 데이터 유형에 느슨하게 매핑됩니다. 사실 테이블과 차원 테이블 간의 외래 키 참조는 다음과 같이 ALTER TABLE 문을 사용하여 명시적으로 만들 수도 있습니다.

참고: CREATE TABLE 문을 사용하여 외래 키 제약 조건을 정의하려면, 열 정의 목록 바로 뒤에  FOREIGN KEY (foreign_key) REFERENCES table_name (primary_key)  형식의 쉼표로 구분된 외래 키 절 목록을 추가하기만 하면 됩니다.

메타데이터 및 기타 고려 사항

차원 모델의 매력은 비즈니스 분석가에게 상대적으로 쉽게 접근할 수 있다는 것입니다. 이를 염두에 두고 많은 조직에서는 위 예시의 Fact 및 Dim 접두사와 같이 사실 및 차원에 대한 명명 규칙을 채택하고, 운영 소스 시스템에서 사용되는 이름과 상당히 다른 경우가 많은 테이블 및 필드에 대해 길고 자체 설명적인 이름을 사용하는 것을 권장합니다.

이를 염두에 두고 Databricks의 개체 명명 제한 사항을 인지하는 것이 중요합니다. 여기에는 다음이 포함됩니다.

• 개체 이름은 255자를 초과할 수 없습니다.
• 다음 특수 문자는 허용되지 않습니다.
  • 마침표 (.)
  • 공백 ( )
  • 슬래시 (/)
  • 모든 ASCII 제어 문자(16진수 00-1F)
  • DELETE 문자(16진수 7F)

또한 개체 이름은 대소문자를 구분하지 않으며, 실제로 메타데이터 저장소에 모두 소문자로 저장된다는 점에 유의하는 것이 중요합니다. 이것이 개체 가독성에 문제가 될 수 있다면, 가독성을 높이기 위해 스네이크 케이스 규칙을 사용하는 것을 고려해 볼 수 있습니다.

명명 규칙에 관계없이 데이터 웨어하우스 내의 모든 개체 및 필드에 대한 설명 주석을 정의하는 것이 좋습니다. 이는 테이블 개체에 대한 COMMENT ON 문과 개별 필드에 대한 ALTER TABLE 문을 통해 수행되며, 여기에서 시연됩니다.

이러한 메타데이터와 기타 메타데이터(데이터 계보 정보 포함)는 Databricks Catalog Explorer 사용자 인터페이스(그림 3)와 각 카탈로그 내에 있는 기본 정보 스키마의 개체를 통해 액세스할 수 있습니다.

마지막으로 이 블로그는 차원 설계 원칙을 준수하는 관점에서 사실 및 차원 테이블 생성만을 다룹니다. 성능 및 유지 관리 최적화를 고려한 추가 테이블 정의 옵션을 탐색하고 싶다면, Delta Lake를 사용하여 Databricks에서 스타 스키마를 구현하는 5가지 간단한 단계에 대한 이 블로그를 확인해 보세요.

다음 단계: 차원 테이블 ETL 구현

기본적인 사실 테이블과 차원 테이블 생성 방법을 다룬 후, 다음 블로그에서는 Python과 SQL을 모두 사용하여 Type-1 및 Type-2 점진적 변경 차원(SCD) 패턴에 중점을 두고 차원 테이블을 지원하는 ETL 패턴 구현에 대해 다룰 것입니다. 마지막으로 파트 3에서는 이러한 테이블에 대한 ETL을 구현하는 방법에 대해 설명합니다.

Databricks SQL에 대해 자세히 알아보려면 저희 웹사이트를 방문하거나 설명서를 읽어보세요. Databricks SQL 제품 투어도 확인해 볼 수 있습니다. 기존 웨어하우스를 훌륭한 사용자 경험과 낮은 총 비용을 제공하는 고성능 서버리스 데이터 웨어하우스로 마이그레이션하고 싶다면 Databricks SQL이 해결책입니다. 지금 바로 무료로 사용해 보세요.

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