Databricks SQL을 사용한 차원 데이터 웨어하우스 구현: 파트 1

점점 더 많은 조직들이 데이터 웨어하우스 작업을 Databricks로 이동하고 있습니다.  이 플랫폼의 탄력적인 특성과 쿼리 실행 엔진에 대한 중요한 개선으로 인해 Databricks는 데이터 웨어하우스 쿼리 성능과 비용 성능 모두에서 세계 기록을 세우게 되었으며, 이로 인해 분석 인프라 통합에 대한 점점 더 매력적인 옵션이 되었습니다.

이러한 노력을 지원하기 위해, 우리는 이전에 Databricks가 다양한 데이터 웨어하우스 설계 접근법을 어떻게 지원하는지에 대해 블로그에 게시했습니다. 이 블로그 시리즈에서는 데이터 웨어하우싱에 가장 인기 있는 접근법 중 하나인 차원 모델링, 즉 스타- 그리고 스노우플레이크 스키마로 특징지어지는 설계 패턴에 대해 좀 더 자세히 살펴보고자 합니다. 이 접근법을 지원하기 위해 널리 채택된 표준화된 추출, 변환 및 로딩 (ETL) 패턴에 대해 깊이 파고들 것입니다. 

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

이를 차원 모델링 커뮤니티에 널리 알리기 위해, 우리는 이 모델링 접근법과 관련된 고전적인 패턴을 철저히 따를 것입니다. 이 정보는 다음 블로그 게시물에 걸쳐 전파될 것입니다:

• 파트 1: (차원) 데이터 객체 정의 (이 포스트)
• Part 2: 차원 ETL 워크플로우 구축 
• Part 3: 사실 ETL 워크플로우 구축 (곧 출시 예정)

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

 

물리적 모델

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

 

차원 테이블

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

 

Identity columns

이 예에서는, 대리 키 열에 대해, CustomerKey, 우리는 행을 삽입할 때마다 순차적인 BIGINT 값을 자동으로 생성하는 identity column 을 사용합니다. identity column에 ALWAYS 또는 BY DEFAULT 옵션을 사용할지 여부는 이 필드에 대해 우리 자신의 값을 삽입할 것인지 금지할 것인지에 따라 달라집니다.

 

누락된 멤버 항목

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

 

식별 필드

최선의 방법으로, 식별 필드에 값을 삽입할 때는 항상 ALTER TABLE 문 을 사용하여 SYNC IDENTITY 옵션을 적용하여 식별 필드의 메타데이터가 업데이트되도록 하는 것이 좋습니다:

 

데이터 유형

비즈니스/자연 키 및 소스 시스템의 데이터에 연결된 다른 필드의 경우, 우리는 소스 시스템 데이터 유형을 Databricks 플랫폼이 지원하는 데이터 유형 과 일치시켜야 합니다 (표 1). 메타데이터 필드에서 비트 값이 사용되는 경우, 0 또는 1과 같은 경우, 리터럴 처리를 좀 더 쉽게 하기 위해 BOOLEAN 또는 TINYINT 데이터 유형 대신에 종종 INT 데이터 유형을 사용하는 것에 유의하십시오.

표 1. Databricks 플랫폼에서 지원하는 데이터 유형

팩트 테이블

사실 테이블 역시 그들의 구조적 관례를 따릅니다. 주로 측정치와 관련 차원에 대한 외래 키 참조로 구성된 사실 테이블은 거래 레코드의 고유 식별자 (또는 사실 레코드와 거의 일대일 관계에 있는 기타 설명적 속성)를 포함할 수도 있으며, 이를 퇴화 차원이라고 합니다. 또한 소스 시스템에서 데이터의 증분 로딩 (aka 델타 추출)을 지원하기 위한 메타데이터 필드를 포함할 수도 있습니다. Databricks 플랫폼 내에서, 우리는 인터넷 판매 사실에 대해 여기에 표시된 것과 유사하게 사실 테이블을 구현할 수 있습니다: CREATE TABLE 문 을 사용하여 구현할 수 있습니다:

 

외래 키 참조

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

참고: 외래 키 제약 조건을 CREATE TABLE 문의 일부로 정의하려는 경우, 단순히 열 정의 목록 바로 뒤에 FOREIGN KEY 절의 쉼표로 구분된 목록 ( FOREIGN KEY (foreign_key) REFERENCES table_name (primary_key)  을 추가하면 됩니다.

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

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

이를 염두에 두고, Databricks에서 객체를 명명하는 데 있어 제한 사항 을 주의해야 합니다. 이에는 다음이 포함됩니다:

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

또한, 객체 이름은 대소문자를 구분하지 않으며 실제로 메타데이터 저장소에 모두 소문자로 저장된다는 점을 주의해야 합니다. 이로 인해 객체의 가독성에 문제가 생길 수 있다면, 일부 객체 이름의 가독성을 향상시키기 위해 스네이크 케이스 규칙을 적용하는 것을 고려해 보실 수 있습니다.

당신의 명명 규칙에 상관없이, 데이터 웨어하우스 내의 모든 객체와 필드에 대해 설명적인 주석을 정의하는 것이 좋습니다. 이는 COMMENT ON 문 을 통해 테이블 객체에 대해 수행되며, 개별 필드의 경우 ALTER TABLE 문 을 사용하여 수행됩니다, 다음과 같이 보여집니다:

이와 다른 메타데이터 (계보 정보 포함)는 Databricks 카탈로그 탐색기 사용자 인터페이스 (그림 3)와 각 카탈로그 내에 내장된 정보 스키마 객체를 통해 접근할 수 있습니다.

마지막으로, 이 블로그는 차원 설계 원칙을 준수하는 관점에서 사실 테이블과 차원 테이블의 생성에 대해 다룹니다. 성능과 유지 보수 최적화를 고려한 테이블 정의에 대한 추가 옵션을 탐색하고 싶다면, 이 블로그 를 확인해 보세요. 별 스키마 성능 최적화에 대한 내용입니다.

 

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

사실 테이블과 차원 테이블 생성에 대한 기본 사항을 다룬 후, 우리는 다음 블로그에서 차원 테이블을 지원하는 ETL 패턴을 구현하는 것에 주목할 것이며, 이는 Python과 SQL을 사용한 Type-1 및 Type-2 점진적 변화 차원 (SCD) 패턴에 특별한 강조를 두고 있습니다.

Databricks SQL에 대해 더 알아보려면 우리의 웹사이트 를 방문하거나 문서를 읽어보세요. 또한 Databricks SQL의 제품 투어를 확인해보세요. 만약 당신이 기존의 창고를 고성능, 서버리스 데이터 창고로 이전하고자 하며, 훌륭한 사용자 경험과 더 낮은 총 비용을 원한다면, Databricks SQL이 해결책입니다 — 무료로 시도해보세요.

 

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