이 기사는 Alibaba DataWorks의 데이터 웨어하우스 아키텍처 및 모델 설계 방법을 소개하기 위해 다음 네 부분으로 나누어집니다.
-
기술 아키텍처 선택
-
데이터 웨어하우스 계층
-
데이터 모델
-
계층적 호출 사양
01 기술 아키텍처 선정
튜토리얼 자체는 Alibaba Cloud MaxCompute를 예로 사용하며 실제로 프로세스와 방법론이 일반적입니다.
데이터 모델을 설계하기 전에 먼저 기술 아키텍처 선택을 완료해야 합니다. 이 튜토리얼에서는 Alibaba Cloud 빅데이터 제품인 MaxCompute를 DataWorks와 함께 사용하여 전체 数据建模和研发流程.
전체 기술 아키텍처 다이어그램은 아래 그림에 나와 있습니다.
그 중 DataWorks의 데이터 통합은 데이터 수집 및 기본 ETL을 완료하는 역할을 담당합니다[데이터 수집 및 ETL을 위한 기본 플랫폼은 오픈 소스 관련 기술 구성 요소를 기반으로 구축 가능]. MaxCompute는 빅 데이터 개발 프로세스 전반에 걸쳐 오프라인 컴퓨팅 엔진 역할을 합니다 . DataWorks에는 데이터 개발, 데이터 품질, 데이터 보안 및 데이터 관리를 포함한 일련의 기능이 포함되어 있습니다.
02 데이터 웨어하우스 계층화
Alibaba의 데이터 시스템에서 우리는 데이터 웨어하우스를 아래에서 위로 , 数据引入层（ODS，Operation Data Store）및数据公共层（CDM，Common Data Model） 의 세 계층으로 나눌 것을 제안합니다 数据应用层（ADS，Application Data Service）.
데이터 웨어하우스의 계층화와 각 계층의 용도는 다음 그림에 나와 있습니다.
-
데이터 도입 계층 ODS(Operation Data Store) : 데이터 웨어하우스 시스템에 처리되지 않은 원시 데이터를 저장하고 구조가 소스 시스템과 일치합니다. 예
数据仓库的数据准备区. 주로 기본 데이터를 MaxCompute로 가져오는 임무를 완료하고 기본 데이터의 과거 변경 사항을 기록합니다. -
데이터 공용 계층 CDM(Common Data Model, 공통 데이터 모델 계층이라고도 함)은 ODS
DIM维度表、DWD和DWS계층의 데이터에서 처리됩니다. 주로 데이터 처리 및 통합을 완료하고 일관된 차원을 설정하며 분석 및 통계를 위해 재사용 가능한 세부 팩트 테이블을 구축하고 공개 세분화 지표를 요약합니다.
-
DIM(Common Dimension Layer) : 차원 모델링 개념을 기반으로 기업 전체에 일관된 차원을 설정합니다. 일관되지 않은 데이터 계산 구경 및 알고리즘의 위험을 줄입니다. 공통 차원 레이어의 테이블은 일반적으로 논리적 차원 테이블이라고도 하며 차원과 차원 논리적 테이블은 일반적으로 일대일 대응입니다.
-
Public Summary Granularity Fact Layer (DWS) : 분석 대상 객체를 모델링 드라이버로 사용하여 상위 레벨 애플리케이션 및 제품 인덱스 요구 사항을 기반으로 공개 Granularity 요약 지표 팩트 테이블을 구축하고 광범위한 방법으로 모델을 물리적화합니다. 테이블. 명명 규칙과 일관된 구경으로 통계 지표를 구성하고, 상위 계층에 대한 공개 지표를 제공하고, 요약 와이드 테이블과 세부 팩트 테이블을 설정합니다.
공개 요약 세분성 팩트 계층의 테이블은 일반적으로 요약 논리 테이블이라고도 하며 파생 지표 데이터를 저장하는 데 사용됩니다. -
DWD(Detail-grained fact layer) : 비즈니스 프로세스를 모델링 드라이버로 사용하여 각 특정 비즈니스 프로세스의 특성을 기반으로 가장 세분화된 세부 수준의 팩트 테이블을 구축합니다. 상세 팩트 테이블의 일부 중요한 차원 특성 필드는 엔터프라이즈의 데이터 사용 특성, 즉 와이드 테이블 처리와 결합하여 적절하게 중복될 수 있습니다. 세분화된 팩트 레이어의 테이블은 일반적으로 논리적 팩트 테이블이라고도 합니다.
-
데이터 응용 계층 ADS(Application Data Service) : 데이터 상품의 개인화된 통계 지표 데이터를 저장합니다. CDM 및 ODS 계층 처리에 따라 생성됩니다.
데이터 분류 아키텍처는 ODS 계층에서 세 부분으로 나뉩니다 . 전체 데이터 분류 구조는 다음 그림과 같습니다.数据准备区、离线数据和准实时数据区
交易数据系统的数据이 자습서 에서는 DataWorks数据集成, 同步到数据仓库的ODS层. 데이터 개발 후 광범위한 팩트가 형성되고 상품 및 지역과 같은 차원으로 공개 요약이 수행됩니다.
전체 데이터 흐름은 아래 그림과 같습니다.
그 중 ODS 레이어에서 DIM 레이어로의 ETL(Extract, Transform, Load) 처리는 MaxCompute에서 이루어지며, 처리가 완료된 후 모든 스토리지 시스템에 동기화됩니다. ODS 레이어와 DWD 레이어는 다운스트림 구독을 위해 데이터 미들웨어에 배치됩니다. DWS 계층과 ADS 계층의 데이터는 일반적으로 온라인 스토리지 시스템 에 저장되며 다운스트림은 인터페이스 호출 형태로 사용됩니다 .
03 데이터 모델
1. 데이터 도입 계층(ODS)
ODS 레이어에 저장되며 从业务系统获取的最原始的数据다른 상위 레이어 데이터의 소스 데이터입니다. 비즈니스 데이터 시스템의 데이터는 일반적으로 매우 상세한 데이터이며 오랜 기간 동안 축적되고 자주 액세스됩니다 面向应用的数据.
데이터 가져오기 레이어 테이블 디자인
이 튜토리얼에서 주로 ODS 레이어에 포함되는 데이터는 트랜잭션 시스템 주문 내역, 사용자 정보 내역, 제품 내역 등입니다. 이러한 데이터는 처리되지 않은 가장 원시 데이터입니다. 논리적으로 이러한 데이터는 二维表. 엄밀히 말하면 ODS 계층은 데이터 웨어하우스 모델링 범주에 속하지 않지만 ODS 계층을 합리적으로 계획하고 데이터 동기화를 잘 수행하는 것도 매우 중요 합니다 .
이 자습서에서는 6개의 ODS 테이블이 사용됩니다.
경매에 대한 상품 정보 기록: s_auction.
정상적인 판매를 위한 상품 정보 기록: s_sale.
사용자 세부 정보 기록: s_users_extra.
새로 추가된 상품 거래 주문 정보: s_biz_order_delta를 기록합니다.
새로 추가된 물류 주문 정보(s_logistics_order_delta)를 기록합니다.
새로 추가된 결제 주문 정보(s_pay_order_delta)를 기록합니다.
설명: 테이블을 증분 테이블로 식별하기
위해 전달합니다 . 테이블의 일부 필드 이름은 접미사를 추가하여 해결할 수 있는 키워드와 동일합니다 ._delta_col1
테이블 생성 예시(s_auction)
CREATE TABLE IF NOT EXISTS s_auction
(
id STRING COMMENT '商品ID',
title STRING COMMENT '商品名',
gmt_modified STRING COMMENT '商品最后修改日期',
price DOUBLE COMMENT '商品成交价格，单位元',
starts STRING COMMENT '商品上架时间',
minimum_bid DOUBLE COMMENT '拍卖商品起拍价，单位元',
duration STRING COMMENT '有效期，销售周期，单位天',
incrementnum DOUBLE COMMENT '拍卖价格的增价幅度',
city STRING COMMENT '商品所在城市',
prov STRING COMMENT '商品所在省份',
ends STRING COMMENT '销售结束时间',
quantity BIGINT COMMENT '数量',
stuff_status BIGINT COMMENT '商品新旧程度 0 全新 1 闲置 2 二手',
auction_status BIGINT COMMENT '商品状态 0 正常 1 用户删除 2 下架 3 从未上架',
cate_id BIGINT COMMENT '商品类目ID',
cate_name STRING COMMENT '商品类目名称',
commodity_id BIGINT COMMENT '品类ID',
commodity_name STRING COMMENT '品类名称',
umid STRING COMMENT '买家umid'
)
COMMENT '商品拍卖ODS'
PARTITIONED BY (ds STRING COMMENT '格式：YYYYMMDD')
LIFECYCLE 400;데이터 가져오기 레이어 스토리지
요구 사항을 충족하기 위해 历史数据分析需求시간 차원을 파티션 필드로 ODS 계층 테이블에 추가할 수 있습니다. 增量실제 응용 프로그램에서는 채택 ,全量 저장 또는 저장을 선택할 수 있습니다 拉链.
-
증분 스토리지 비즈니스
날짜가 파티션인 일 단위의 증분 스토리지와 각 파티션은 일일 증분 비즈니스 데이터를 저장합니다. 예를 들어,
1월 1일에 사용자 A가 A사의 B사 쇼핑몰을 방문하여 A사의 전자상거래 로그에 t1이라는 기록이 생성되었고, 1월 2일에 A사가 A사의 C사 쇼핑몰을 방문하여 회사가 A의 전자 상거래 상점 로그는 레코드 t2를 생성합니다. 증분 저장 방법을 사용하면 t1은 1월 1일에 파티션에 저장되고 t2는 1월 2일에 파티션에 저장됩니다.
1월 1일 사용자 A가 A사의 전자상거래 사이트에서 B상품을 구매하여 거래내역에 t1의 기록이 생성되고, 1월 2일에 사용자 A가 다시 B상품을 구매하여 거래내역이 갱신됨 t1退货. 증분 저장 방법을 사용하면 처음 구매한 t1 레코드는 1월 1일 파티션에 저장되고 업데이트 된 t1 레코드는 1월 2일 파티션에 저장됩니다 .
트랜잭션, 로그 事务性较强的ODS表适合增量存储등 이러한 유형의 테이블에는 많은 양의 데이터가 있으며 전체 저장 방법을 사용하는 저장 비용이 높습니다 . 또한 이 유형의 테이블의 다운스트림 애플리케이션은 기록 전체 데이터 액세스에 대한 요구가 적습니다(이러한 요구는 데이터 웨어하우스의 후속 요약을 통해 얻을 수 있음). 예를 들어, 로그 유형 ODS 테이블에는 데이터 업데이트 비즈니스 프로세스가 없으므로 모든 증분 파티션이 함께 UNION되어 전체 데이터 양을 형성합니다.
-
전체 저장소
비즈니스 날짜를 파티션으로 사용하고 각 파티션은 비즈니스 날짜까지 데이터를 저장하는 전체 스토리지(일)입니다全量业务数据.
예를 들어, 1월 1일 판매자 A가 A사의 전자상거래 사이트에서 두 개의 상품 B와 C를 출시했고, 프런트엔드 상품 테이블은 두 개의 레코드 t1과 t2를 생성할 것입니다.1월 2일 판매자 A는 상품 B를 출시했고, 동시에下架제품 D가 출시된 후 프런트 엔드 제품 테이블은 레코드 t1을 업데이트하고 새 레코드 t3을 생성합니다. 전체 저장 방법을 사용하여 두 개의 레코드 t1 및 t2가 1월 1일 파티션에 저장되고 업데이트된 t1, t2 및 t3 레코드가 1월 2일 파티션에 저장됩니다 .
상품 카테고리와 같이 소량의 데이터로 천천히 변화하는 차원 데이터의 경우 전체 스토리지를 직접 사용할 수 있습니다.
-
지퍼 스토리지는 지퍼 스토리지를 사용하여
新增两个时间戳字段（start_dt和end_dt）날짜 단위로 모든 변경 데이터를 기록하며 일반적으로 파티션 필드도 이 두 타임스탬프 필드입니다.
지퍼 수납의 예는 다음과 같습니다.
이러한 방식으로 다운스트림 애플리케이션은 타임스탬프 필드를 제한하여 기록 데이터를 얻을 수 있습니다. 예를 들어 사용자가 1월 1일에 데이터에 액세스하는 경우 start_dt<=20160101 및 end_dt>20160101만 제한하면 됩니다.
천천히 변화하는 치수
MaxCompute는 대리 키 사용을 권장하지 않으며 자연 키를 차원 기본 키로 사용하도록 권장합니다.두 가지 주요 이유가 있습니다.
-
MaxCompute는 분산 컴퓨팅 엔진이며 전역적으로 고유한 대리 키를 생성하는 워크로드가 매우 큽니다. 많은 양의 데이터를 접할 때 이 작업은 더 복잡하고 불필요합니다.
-
서로게이트 키를 사용하면 ETL의 복잡성이 증가하므로 ETL 작업의 개발 및 유지 관리 비용이 증가합니다.
대리키를 사용하지 않는 경우에는 방법으로 처리 缓慢变化维度할 수 있다 .快照
스냅샷 모드의 데이터 계산 주기는 일반적으로 하루에 한 번입니다 . 이 기간을 기준으로 차원 변경을 처리하는 방법은 일별 전체 스냅샷입니다.
예를 들어 제품 차원에서 전체 제품 스냅샷 데이터는 매일 보관됩니다. 어떤 날의 팩트 테이블은 날짜를 제한하고 자연키를 연관시켜 그날의 상품 정보나 최신 상품 정보를 얻을 수 있다 . 이 방법의 장점은 주로 다음 두 가지 사항을 포함합니다.
-
천천히 변화하는 치수를 다루는 방법은 간단하고 효과적이며 개발 및 유지 보수 비용이 낮습니다.
-
사용하기 쉽고 이해하기 쉽습니다. 데이터 사용자는 해당 날짜의 스냅샷 데이터를 얻기 위해 날짜를 제한하기만 하면 됩니다. 임의 날짜의 사실 스냅샷은 차원의 자연 키를 통해 임의 날짜의 차원 스냅샷과 연관될 수 있습니다.
该方法的弊端主要是存储空间的极大浪费. 예를 들어, 특정 차원의 일일 변화량은 전체 데이터량에서 차지하는 비중이 매우 적고, 극단적인 경우 매일 변화가 없는 경우 스토리지 낭비가 심각하다. 이 방법은 주로 스토리지를 희생하여 ETL 효율성을 얻는 최적화 및 논리적 단순화를 실현합니다. 이 방법의 남용을 피하고 대응책이 있어야 합니다 .数据生命周期制度，清除无用的历史数据
데이터 동기화 로딩 및 처리
ODS 데이터는 추가 데이터 개발에 사용되기 전에 각 데이터 소스 시스템에서 MaxCompute로 동기화되어야 합니다. 이 자습서에서는 DataWorks데이터 통합 기능을 사용하여 데이터 동기화를 완료할 것을 권장합니다. 데이터 통합을 사용하는 과정에서 다음 사양을 따르는 것이 좋습니다.
-
시스템의 소스 테이블은 테이블 구조의 일관성을 유지하기 위해 MaxCompute와 한 번만 동기화할 수 있습니다.
-
데이터 통합은 오프라인 전체 데이터 동기화에만 사용됩니다.실시간 증분 데이터 동기화는 데이터 전송 서비스 DTS를 사용하여 구현해야 합니다.자세한 내용은 데이터 전송 서비스 DTS를 참조하십시오.
-
데이터 통합 완전히 동기화된 데이터는 전체 규모 테이블의 현재 날짜 파티션에 직접 입력됩니다.
-
ODS 계층의 테이블은 데이터 저장 비용 관리 및 정책 제어에 편리한 통계 날짜 및 시간 파티션 테이블 형식으로 저장하는 것이 좋습니다 .
-
데이터 통합은 소스 시스템 필드의 변경 사항을 적응적으로 처리할 수 있습니다.
-
소스 시스템 필드의 대상 테이블이 MaxCompute에 존재하지 않는 경우 데이터 통합은 존재하지 않는 테이블 필드를 자동으로 추가할 수 있습니다.
-
대상 테이블의 필드가 소스 시스템에 없으면 데이터 통합이 NULL로 채웁니다.
2. 공통 차원 요약 계층(DIM)
공용 차원 요약 계층(DIM)은 전체 엔터프라이즈에 대해 일관된 차원을 설정하기 위한 차원 모델링의 개념을 기반으로 합니다.
공개 차원 요약 계층(DIM)은 주로 차원 테이블(차원 테이블)로 구성됩니다. 차원은 논리적인 개념이며 비즈니스를 측정하고 관찰하기 위한 관점입니다. 차원 테이블은 데이터 플랫폼에 구축된 테이블을 차원과 그 속성에 따라 물리적으로 구현한 테이블로, 와이드 테이블 설계 원칙을 채택하고 있습니다. 따라서 构建公共维度汇总层（DIM）首先需要定义维度.
치수 정의
数据域나누고 건축 할 때 总线矩阵합칠 필요가 있습니다 对业务过程的分析定义维度. 이 튜토리얼을 A电商公司的营销业务板块예로 들어 트랜잭션 데이터 도메인 에서는 영수증을 확인하는 비즈니스 프로세스(성공적인 트랜잭션)에 중점을 둡니다.
입고를 확인하는 비즈니스 프로세스에는 주로 상품과 수령 위치의 두 가지 차원에 의존하는 비즈니스 관점이 있습니다(이 튜토리얼에서는 수령과 구매가 동일한 위치라고 가정함).
제품의 관점에서 정의할 수 있는 차원은 다음과 같습니다.
제품 ID,
제품 이름,
제품 가격,
제품 신품: 0-new, 1-idle, 2-used,
제품 카테고리 ID, 제품 카테고리 이름,
카테고리
ID ,
카테고리 이름 ,
구매자 ID,
상품 상태: 0- 정상, 1-사용자에 의해 삭제됨, 2-선반에서 벗어남, 3-선반에 놓지 않음
상품이 위치한 도시
상품이 위치한 지방
지리적 관점에서 다음 차원을 정의할 수 있습니다.
구매자 ID
도시 코드
도시 이름
지방 코드
지방 이름
차원 모델링의 핵심으로 엔터프라이즈 데이터 웨어하우스에서 차원의 고유성이 보장되어야 합니다. 회사 A의 상품 차원을 예로 들어 보겠습니다 有且只允许有一种维度定义. 예를 들어, 지방 코드의 차원은 모든 비즈니스 프로세스에서 전달되는 정보와 일치합니다.
디자인 차원 테이블
차원 정의가 완료된 후 차원을 보완하여 차원 테이블을 생성할 수 있습니다.
차원 테이블의 디자인은 다음 사항에 주의를 기울여야 합니다.
-
单表信息차원 테이블의 항목 수는 1,000만 개를 넘지 않는 것이 좋습니다 . -
차원 테이블이 다른 테이블과 조인될 때 권장됩니다
使用Map Join. -
避免过于频繁的更新차원 테이블의 데이터입니다.
차원 테이블을 설계할 때 다음 측면을 고려해야 합니다.
-
차원 테이블의 데이터 안정성. 예를 들어, A사의 전자상거래 회원은 보통 죽지 않지만, 회원 데이터는 수시로 갱신될 수 있는데, 이때 전체 데이터를 저장하기 위해 단일 파티션을 생성하는 것을 고려해야 합니다. 업데이트되지 않는 레코드가 있는 경우 필요할 수 있습니다
分别创建历史表与日常表. 일일 테이블은 현재 유효한 기록을 저장하는 데 사용되므로 테이블의 데이터 볼륨이 확장되지 않으며, 기록 테이블은 사망 시간에 따라 해당 파티션에 삽입되고 단일 파티션은 사망 기록을 저장하는 데 사용됩니다. 파티션의 해당 시간. -
세로 분할 여부입니다. 차원 테이블에서 많은 수의 특성이 사용되지 않거나 너무 많은 특성 필드를 포함하여 쿼리 속도가 느려지는 경우 필드를 분할하고 여러 차원 테이블을 만드는 것을 고려해야 합니다.
-
가로 분할 여부입니다. 레코드 간에 명확한 경계가 있는 경우 여러 테이블로 분할하거나 다단계 파티션을 설계하는 것이 좋습니다.
-
코어 차원 테이블의 출력 시간에는 일반적으로 엄격한 요구 사항이 있습니다.
차원 테이블을 설계하는 주요 단계는 다음과 같습니다.
-
차원의 예비 정의를 완료하고 차원의 일관성을 보장합니다.
-
기본 차원 테이블(이 자습서에서 사용되는 중앙 팩트 테이블
星型模型)을 식별합니다. 여기서 기본 차원 테이블은 일반적으로 비즈니스 시스템과 직접 동기화되는 데이터 도입 계층(ODS) 테이블입니다. 예를 들어 s_auction은 프런트 엔드 상품 센터 시스템과 동기화된 상품 테이블이며 이 테이블이 기본 차원 테이블입니다. -
관련 치수 테이블을 결정합니다. 데이터 웨어하우스는 비즈니스 소스 시스템의 데이터 통합이며 서로 다른 비즈니스 시스템 또는 동일한 비즈니스 시스템의 테이블 간에 상관 관계가 있습니다. 업무 분류에 따라 기본 차원 테이블과 연결된 테이블을 결정하고 그 중 일부를 선택하여 차원 특성을 생성합니다. 상품 차원을 예로 들면, 비즈니스 논리의 결합에 따라 상품과 범주, 판매자, 상점 및 기타 차원 간에 상관 관계가 있음을 알 수 있습니다.
-
차원 특성 결정에는 주로 두 단계가 포함됩니다. 첫 번째 단계는 마스터 차원 테이블에서 차원 속성을 선택하거나 새 차원 속성을 생성하는 것이고, 두 번째 단계는 관련 차원 테이블에서 차원 속성을 선택하거나 새 차원 속성을 생성하는 것입니다. 상품 차원을 예로 들어 기본 차원 테이블(s_auction) 및 관련 차원 테이블(예: 범주, 판매자 및 상점)에서 차원 속성을 선택하거나 새 차원 속성을 생성합니다.
가능한 한 많은 차원 특성을 생성합니다.
가능한 한 많은 의미 있는 텍스트 설명을 제공합니다.
숫자 속성과 사실을 구별하십시오.
일반 치수 속성을 가능한 많이 침전시키십시오.
DIM(Common Dimension Summary Layer) 차원 테이블 사양 DIM
(Public Dimension Summary Layer) 차원 테이블 명명 사양:dim_{业务板块名称/pub}_{维度定义}[_{自定义命名标签}]소위 pub은 특정 비즈니스 세그먼트와 관련이 없거나 모든 비즈니스 세그먼트에 공통되는 차원입니다. 시간 차원으로.
예는 다음과 같습니다.
공개 영역의 차원 테이블dim_pub_area A 회사의 전자 상거래 부문 전체 제품 목록dim_asale_itm
테이블 구축의 예
CREATE TABLE IF NOT EXISTS dim_asale_itm
(
item_id BIGINT COMMENT '商品ID',
item_title STRING COMMENT '商品名称',
item_price DOUBLE COMMENT '商品成交价格_元',
item_stuff_status BIGINT COMMENT '商品新旧程度_0全新1闲置2二手',
cate_id BIGINT COMMENT '商品类目ID',
cate_name STRING COMMENT '商品类目名称',
commodity_id BIGINT COMMENT '品类ID',
commodity_name STRING COMMENT '品类名称',
umid STRING COMMENT '买家ID',
item_status BIGINT COMMENT '商品状态_0正常1用户删除2下架3未上架',
city STRING COMMENT '商品所在城市',
prov STRING COMMENT '商品所在省份'
)
COMMENT '商品全量表'
PARTITIONED BY (ds STRING COMMENT '日期,yyyymmdd');
CREATE TABLE IF NOT EXISTS dim_pub_area
(
buyer_id STRING COMMENT '买家ID',
city_code STRING COMMENT '城市code',
city_name STRING COMMENT '城市名称',
prov_code STRING COMMENT '省份code',
prov_name STRING COMMENT '省份名称'
)
COMMENT '公共区域维表'
PARTITIONED BY (ds STRING COMMENT '日期分区，格式yyyymmdd')
LIFECYCLE 3600;3. DWD(Detail-grained 팩트 레이어)
세분화된 팩트 레이어는 비즈니스 프로세스 드라이브로 모델링되며 , 각 특정 비즈니스 프로세스의 특성을 기반으로 세부 레이어의 가장 세분화된 팩트 테이블이 구성됩니다. 상세 팩트 테이블의 일부 중요한 차원 속성 필드는 엔터프라이즈의 데이터 사용 특성과 결합하여 적절하게 중복될 수 있습니다 宽表化处理.
데이터 웨어하우스 차원 모델링의 핵심으로서 공개 요약 입도 팩트 레이어(DWS) 및 세부 입도 팩트 레이어(DWD)의 팩트 테이블은 비즈니스 프로세스를 중심으로 설계되어야 합니다 . 참조된 차원 및 비즈니스 프로세스와 관련된 측정값을 포함하여 비즈니스 프로세스를 설명하는 측정값을 확보하여 비즈니스 프로세스를 설명합니다. 度量通常为数值型数据, 사실 논리 테이블의 기초로. 팩트 논리 테이블의 설명 정보는 팩트 속성이며 팩트 속성의 외래 키 필드는 해당 차원을 통해 연결됩니다.
팩트 테이블의 레코드로 표현되는 비즈니스 세부 정보의 정도를 세분성이라고 합니다 . 일반적으로 세분성은 두 가지 방식으로 표현될 수 있습니다. 하나는 차원 특성의 조합으로 표현되는 세부 수준이고 다른 하나는 표현되는 특정 비즈니스 의미입니다.
비즈니스 프로세스를 측정하기 위한 사실로서 일반적으로 정수 또는 부동 소수점 십진수 값이며 가산성, 반가산성 및 비가산성의 세 가지 유형이 있습니다.
-
추가 팩트는 팩트 테이블과 연결된 모든 차원을 따라 집계될 수 있는 팩트입니다.
-
반가산적 팩트는 모든 차원이 아니라 특정 차원을 따라서만 집계할 수 있습니다. 예를 들어, 재고는 위치별, 제품별로 요약할 수 있지만 시간 차원으로 1년의 월별 재고를 누적하는 것은 의미가 없습니다.
-
비율 팩트와 같은 완전한 비가산성. 비가산적 팩트의 경우 추가 구성 요소로 분해하여 집계를 수행할 수 있습니다.
차원 테이블과 비교할 때 팩트 테이블은 일반적으로 더 가늘고 행 증가율이 더 빠릅니다 . 차원 속성은 팩트 테이블(예: 存储到事实表中的维度列称为维度退化，可加快查询速度. 차원 테이블에 저장된 다른 차원과 마찬가지로 차원 퇴화를 사용하여 팩트 테이블을 필터링 및 쿼리하고 집계 작업을 구현하는 등의 작업을 수행할 수 있습니다 .
DWD(Detailed Fact Layer)는 일반적으로 , 및 의 세 가지 유형으로 나뉩니다. 事务事实表자세한周期快照事实表 내용 累积快照事实表은 데이터 웨어하우스 구축 가이드를 참조하십시오.
-
트랜잭션 팩트 테이블은 비즈니스 프로세스를 설명하고 공간 또는 시간의 특정 지점에서 측정 이벤트를 추적하며 원자 팩트 테이블 이라고도 하는 가장 원자적인 데이터를 저장하는 데 사용됩니다 .
-
주기적인 스냅샷 팩트 테이블은 규칙적이고 예측 가능한 간격으로 팩트를 기록합니다.
-
누적 스냅샷 팩트 테이블은 프로세스의 전체 수명 주기를 포함하는 프로세스 시작과 종료 사이의 주요 단계 이벤트를 표현하는 데 사용되며 일반적으로 주요 시점을 기록하는 여러 날짜 필드가 있습니다. 누적 스냅샷 팩트 테이블이 수명 동안 지속적으로 변경되는 동안 프로세스 변경에 따라 레코드도 수정됩니다.
디테일 그레인 팩트 테이블의 설계 원칙
세분화된 팩트 테이블의 설계 원칙은 다음과 같습니다.
-
일반적으로 세부 수준의 팩트 테이블은 하나의 차원에만 연결됩니다.
-
가능한 한 비즈니스 프로세스에 대한 모든 관련 사실을 포함하십시오.
-
비즈니스 프로세스와 관련된 사실만 선택하십시오.
-
비가산적 사실을 부가적 구성 요소로 분해합니다.
-
차원과 팩트를 선택하기 전에 세분성을 선언해야 합니다.
-
동일한 팩트 테이블에 세분성이 다른 팩트가 여러 개 있을 수 없습니다.
-
팩트 단위는 일관성이 있어야 합니다.
-
Null 값을 주의해서 처리하십시오.
-
축퇴 차원을 사용하여 팩트 테이블의 유용성을 개선하십시오.
-
세분화된 팩트 테이블의 전체 설계 프로세스는 아래 그림과 같습니다.
트랜잭션 비즈니스 프로세스와 그 측정은 일관성 측정에서 정의되었습니다. 상세 팩트 테이블은 비즈니스 프로세스에 대한 모델 설계에 주의를 기울입니다 . 세부 팩트 테이블의 설계는 네 단계로 나눌 수 있습니다.
选择业务过程, 确定粒度, 选择维度,确定事实（度量） . 세분성은 주로 차원 확장 없이 비즈니스 활동의 의미론적 설명을 기록하는 것입니다. 상세 팩트 테이블을 구축할 때 기존 테이블을 기반으로 상세 레이어 데이터를 개발할 것인지 선택하고, 구축된 테이블의 레코드에 어떤 세분성 데이터가 저장되어 있는지 알아야 한다.
DWD(Detail-grained 팩트 레이어) 사양
일반적으로 따라야 하는 명명 규칙은 다음과 같습니다. dwd_{业务板块/pub}_{数据域缩写}_{业务过程缩写}[_{自定义表命名标签缩写}] _{单分区增量全量标识}, pub는 데이터에 여러 비즈니스 부문의 데이터가 포함되어 있음을 나타냅니다. 단일 파티션의 증분 전체 금액은 일반적으로 다음과 같이 식별됩니다. i는 증분을 의미하고 f는 전체 금액을 의미합니다. 예: dwd_asale_trd_ordcrt_trip_di(전자상거래 회사의 항공권 주문 주문 팩트 테이블, 일일 새로고침 증분) 및 dwd_asale_itm_item_df(전자상거래 제품 스냅샷 팩트 테이블, 일일 새로고침 전체 금액).
이 튜토리얼에서 DWD 레이어는 주로
트랜잭션 상품 정보 팩트 테이블: dwd_asale_trd_itm_di의 세 테이블로 구성됩니다.
트랜잭션 구성원 정보 팩트 테이블: ods_asale_trd_mbr_di.
거래 주문 정보 팩트 테이블: dwd_asale_trd_ord_di.
테이블 생성 예시(dwd_asale_trd_itm_di)
CREATE TABLE IF NOT EXISTS dwd_asale_trd_itm_di
(
item_id BIGINT COMMENT '商品ID',
item_title STRING COMMENT '商品名称',
item_price DOUBLE COMMENT '商品价格',
item_stuff_status BIGINT COMMENT '商品新旧程度_0全新1闲置2二手',
item_prov STRING COMMENT '商品省份',
item_city STRING COMMENT '商品城市',
cate_id BIGINT COMMENT '商品类目ID',
cate_name STRING COMMENT '商品类目名称',
commodity_id BIGINT COMMENT '品类ID',
commodity_name STRING COMMENT '品类名称',
buyer_id BIGINT COMMENT '买家ID',
)
COMMENT '交易商品信息事实表'
PARTITIONED BY (ds STRING COMMENT '日期')
LIFECYCLE 400;4. 공개 요약 세분성 팩트 레이어(DWS)
明细粒度 ==> 汇总粒度
공개 요약 세분성 팩트 계층은 以分析的主题对象作为建模驱动상위 계층 애플리케이션 및 제품 지표 요구 사항을 기반으로 공개 세분화 요약 지표 팩트 테이블을 작성합니다. 공통 집계 계층의 테이블은 일반적으로 파생 메트릭에 해당합니다 .
일반적인 요약 팩트 테이블 디자인 원칙
집계는 요약을 의미합니다 原始明细粒度的数据. DWS 공개 요약 계층은 분석 개체에 대한 주제 집계 모델링입니다. 이 튜토리얼에서 최종 분석 목표는 지난 날 각 지방의 특정 카테고리(예: 주방용품)의 총 판매액 , 이 카테고리의 상위 10개 판매 상품명 및 사용자 구매력 분포 입니다. 각 지방 . 따라서 最终交易成功상품, 카테고리, 구매자 등의 관점에서 최신 날짜의 데이터를 요약 할 수 있습니다.
-
집계는 사실에 걸쳐 있지 않습니다. 집계는 원래 스타 스키마에 대해 만들어진 요약입니다. 원래 모델과 일치하는 결과를 얻고 쿼리하려면 집계된 차원 및 측정값이 원래 모델과 일치해야 하므로 집계가 팩트에 걸쳐 있지 않습니다.
-
집계는 쿼리 성능을 향상시키지만 집계는 ETL 유지 관리의 어려움도 증가시킵니다. 하위 범주에 해당하는 1차 범주가 변경되면 집계 테이블로 요약된 기존 데이터를 다시 조정해야 합니다.
또한 DWS 레이어를 설계할 때 다음 원칙을 따라야 합니다.
-
데이터 커먼즈: 집계 집계를 제3자에게 제공할 수 있는지 여부를 고려하십시오. 데이터 분석에서 특정 차원을 기반으로 한 집계가 자주 사용되는지 여부를 판단할 수 있습니다. 대답이 예인 경우 자세한 데이터를 집계 테이블에 집계해야 합니다.
-
데이터 도메인을 교차하지 않음: 데이터 도메인은 상위 수준에서 데이터를 분류하고 집계하는 추상화입니다. 데이터 도메인은 일반적으로 비즈니스 프로세스에 따라 분류되는데, 예를 들어 트랜잭션은 트랜잭션 도메인 아래에 통합되고 상품의 새로운 추가 및 수정은 상품 도메인 아래에 배치됩니다.
-
통계 기간 구분: 데이터의 통계 기간은 테이블 이름으로 설명해야 합니다(예: ,
_1d, , ) .最近1天td表示截至当天nd表示最近N天
공개 요약 팩트 테이블 사양
공개 요약 팩트 테이블 명명 규칙: dws_{业务板块缩写/pub}_{数据域缩写}_{数据粒度缩写}[_{自定义表命名标签缩写}]_{统计时间周期范围缩写}. 통계적 실제 기간 범위 약어와 관련하여 기본적으로 오프라인 계산에는 最近一天（_1d）,最近N天（_nd） 및 3개의 테이블이 포함되어야 합니다 历史截至当天（_td）. 분할해야 하는 _nd의 테이블 필드가 너무 많은 경우 원자 분할로 하나의 통계 기간 단위만 허용됩니다. 즉, 테이블은 통계 주기로 분할됩니다. 예를 들어 테이블은 지난 7일(_1w) 동안 분할됩니다. 분할 테이블은 여러 통계 기간을 저장할 수 없습니다.
for 小时表(day refresh인지 hour refresh인지)를 나타내는 _hh데 사용 . for 分钟表(day refresh인지 hour refresh인지)를 나타내는 _mm데 사용 .
예를 들면 다음과 같습니다. dws_asale_trd_byr_subpay_1d(A 전자상거래 업체별 구매자 세부거래 결제 1일 요약표)
dws_asale_trd_byr_subpay_td (당일 기준 구매자 A 전자상거래 업체 단계별 세부결제 요약표)
dws_asale_trd_byr_cod_nd ( A 전자상거래 업체의 구매자 세부 대금 상환 거래 요약표)
dws_asale_itm_slr_td (A 전자상거래 업체의 당일 판매자 주식 요약표)
dws_asale_itm_slr_hh (A 전자상거래 업체의 시간별 판매자 요약표) 세분화된 상품) --- 차원이 시간
dws_asale_itm_slr_mm (A 전자상거래 회사 세분화된 상품 판매자의 분 요약 테이블)--- 차원이 분인 테이블
작성 예
비즈니스 요구 사항을 충족하는 DWS 레이어 테이블 생성 구문은 다음과 같습니다.
CREATE TABLE IF NOT EXISTS dws_asale_trd_byr_ord_1d
(
buyer_id BIGINT COMMENT '买家ID',
buyer_nick STRING COMMENT '买家昵称',
mord_prov STRING COMMENT '收货人省份',
cate_id BIGINT COMMENT '商品类目ID',
cate_name STRING COMMENT '商品类目名称',
confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天订单已经确认收货的金额总和'
)
COMMENT '买家粒度所有交易最近一天汇总事实表'
PARTITIONED BY (ds STRING COMMENT '分区字段YYYYMMDD')
LIFECYCLE 36000;
CREATE TABLE IF NOT EXISTS dws_asale_trd_itm_ord_1d
(
item_id BIGINT COMMENT '商品ID',
item_title STRING COMMENT '商品名称',
cate_id BIGINT COMMENT '商品类目ID',
cate_name STRING COMMENT '商品类目名称',
mord_prov STRING COMMENT '收货人省份',
confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天订单已经确认收货的金额总和'
)
COMMENT '商品粒度交易最近一天汇总事实表'
PARTITIONED BY (ds STRING COMMENT '分区字段YYYYMMDD')
LIFECYCLE 36000;04 계층적 호출 명세
데이터 웨어하우스의 계층화가 완료되면 각 계층의 데이터 간의 호출 관계에 대한 합의가 필요합니다.
ADS 응용 프로그램 계층은 데이터 웨어하우스의 공용 계층 데이터를 호출하는 데 우선순위를 둡니다 . 如果已经存在CDM层数据，不允许ADS应用层跨过CDM中间层从ODS层重复加工数据. CDM 미들 레이어는 애플리케이션 레이어의 데이터 구성 요구 사항을 적극적으로 이해하고 공용 데이터를 공용 레이어에 보관하고 다른 데이터 레이어에 데이터 서비스를 제공해야 합니다. 동시에 ADS 애플리케이션 레이어는 CDM 중간 레이어와 적극적으로 협력하여 데이터 공공 건설의 지속적인 변환을 수행해야 합니다. 과도한 ODS 레이어 참조, 불합리한 데이터 중복 및 하위 컬렉션 중복을 피하십시오. 계층적 호출의 일반적인 원칙은 다음과 같습니다.
-
ODS 계층 데이터는 애플리케이션 계층 작업에서 직접 참조할 수 없습니다. 중간 계층에 침전된 ODS 계층 데이터가 없으면 CDM 계층의 관점을 통해 접근할 수 있다. CDM 레이어 보기는 보기의 유지 관리 용이성을 유지하기 위해 스케줄러로 캡슐화되어야 합니다 .
-
CDM 레이어 작업의 깊이는 너무 크지 않아야 합니다(10 레이어를 초과하지 않는 것이 좋습니다).
-
특별한 경우를 제외하고 계산 새로 고침 작업에는 하나의 출력 테이블만 허용됩니다.
-
여러 작업이 테이블을 새로 고치고 출력하는 경우(다른 작업이 다른 파티션에 삽입됨) 여러 작업의 새로 고침 및 출력에 의존하려면 DataWorks에서 가상 작업을 생성해야 합니다. 일반적으로 다운스트림은 이 더미 작업에 의존해야 합니다.
-
CDM 요약 레이어는 지표 계산을 누적할 수 있는 CDM 상세 레이어를 우선적으로 호출합니다. CDM 요약 레이어는 대량의 상세 데이터 레이어에서 직접 계산되는 많은 양의 요약 레이어 데이터를 피하기 위해 생성된 거친 요약 레이어를 호출하는 데 우선 순위를 부여하려고 합니다.
-
CDM 상세 레이어의 누적 스냅샷 팩트 테이블은 데이터 일관성과 출력을 유지하기 위해 CDM 트랜잭션 팩트 테이블 호출에 우선순위를 둡니다.
-
응용 프로그램 계층의 CDM 계층에서 세부 데이터에 대한 과도한 참조 및 의존을 피하기 위해 대상 방식으로 CDM 공개 요약 계층을 구축합니다.