ODS부터 ADS까지, 데이터 웨어하우스 계층화에 대한 자세한 설명!

1. 데이터 웨어하우스를 계층화해야 하는 이유

데이터 모델이 데이터를 질서있게 구성하고 저장해야만 빅데이터를 고성능, 저비용, 고효율, 고품질로 사용할 수 있습니다.

01 레이어링의 의미

1) 명확한 데이터 구조: 각 데이터 레이어에는 범위가 있으므로 테이블을 사용할 때 더 쉽게 찾고 이해할 수 있습니다.

데이터 관계의 구성: 소스 시스템 간에는 복잡한 데이터 관계가 있습니다. 예를 들어 고객 정보는 핵심 시스템, 신용 시스템, 재무 관리 시스템 및 자본 시스템에 동시에 존재합니다. 데이터를 검색할 때 결정을 내리나요? 데이터 웨어하우스는 동일한 주제에 대한 데이터의 통합 모델링을 수행하고 복잡한 데이터 관계를 명확한 데이터 모델로 분류하므로 사용 시 위의 문제를 피할 수 있습니다.

2) 데이터 계보 추적: 간단히 말하면 이렇게 이해될 수 있습니다. 우리가 궁극적으로 비즈니스 무결성을 제공하는 것은 직접 사용할 수 있는 비즈니스 테이블이지만 여러 소스에서 비롯됩니다. 출처가 있습니다. 시계에 문제가 있습니다. 우리는 문제의 위치를 ​​빠르고 정확하게 파악하고 피해 범위를 이해할 수 있기를 원합니다.

3) 반복 개발을 줄이기 위한 데이터 재사용: 데이터 계층화를 표준화하고 일부 공통 중간 계층 데이터를 개발하여 엄청난 반복 계산을 줄일 수 있습니다. 데이터의 계층별 처리 원리에 따라 하위 계층에는 상위 계층 데이터 처리에 필요한 모든 데이터가 포함됩니다. 이 처리 방법은 각 데이터 개발자가 처리를 위해 소스 시스템에서 데이터를 다시 추출하는 것을 방지합니다. 요약 레이어의 도입을 통해 다운스트림 사용자 로직의 반복 계산을 방지하여 사용자의 개발 시간과 에너지를 절약하고 계산 및 저장 공간도 절약합니다. 불필요한 데이터 중복을 크게 줄이고, 계산 결과를 재사용할 수 있으며, 저장 및 컴퓨팅 비용을 크게 절감합니다.

4) 복잡한 문제를 단순화하세요. 복잡한 작업을 여러 단계로 분해하여 완료하세요. 각 레이어는 단일 단계만 처리하므로 비교적 간단하고 이해하기 쉽습니다. 데이터의 정확성을 유지하는 것도 쉽습니다. 데이터에 문제가 있는 경우 모든 데이터를 복구할 필요는 없습니다. 문제가 있는 단계부터 복구를 시작하면 됩니다.

5) 원본 데이터의 (영향)을 보호하고 비즈니스에 미치는 영향을 보호합니다. 비즈니스나 시스템이 변경되면 비즈니스를 한 번 변경하고 데이터를 다시 연결할 필요가 없습니다. 데이터 안정성과 연속성을 향상시킵니다.

소스 비즈니스 시스템의 복잡성을 보호합니다. 소스 시스템은 매우 복잡할 수 있으며 테이블 이름 지정, 필드 이름 지정, 필드 의미 등이 다양할 수 있습니다. DW 계층은 이러한 모든 것을 표준화하고 보호하는 데 사용됩니다. 다운스트림 데이터 사용자의 사용을 보장하기 위한 복잡성 및 데이터 표준화. 소스 시스템 비즈니스가 변경되면 관련 변경 사항은 DW 레이어에 의해 처리되며, 이는 다운스트림 사용자의 코드 및 로직을 변경하지 않고도 다운스트림 사용자에게 투명하게 적용됩니다.

데이터 웨어하우스의 유지 관리: 계층화된 설계를 통해 다음 계층의 코드와 논리를 변경하지 않고 특정 계층의 문제를 해당 계층에서만 해결할 수 있습니다.

빅 데이터 시스템에는 성능, 비용, 효율성 및 품질 간의 최상의 균형을 달성하기 위해 데이터를 더 잘 구성하고 저장하는 데 도움이 되는 데이터 모델 방법이 필요합니다!

02 데이터 웨어하우스(ETL)의 4가지 작업

ETL(추출 변환 로딩)은 흩어져 있고 이기종 데이터 소스에서 임시 중간 계층으로 데이터를 추출하여 정리, 변환, 통합 및 최종 로딩을 담당합니다. . 데이터 웨어하우스나 데이터 마트에. ETL은 데이터 웨어하우스 구현의 핵심이자 영혼입니다. ETL 규칙의 설계 및 구현은 전체 데이터 웨어하우스 구축 워크로드의 약 60%~80%를 차지합니다.

1) 데이터 추출에는 초기 데이터 로드 및 데이터 새로 고침이 포함됩니다. 초기 데이터 로드는 주로 차원 테이블 및 팩트 테이블을 설정하고 해당 데이터를 이러한 데이터 테이블에 넣는 방법에 중점을 두고 있으며 데이터 새로 고침은 원본 데이터가 변경되면 데이터 웨어하우스에 해당 데이터를 추가하고 업데이트합니다(예: 예약된 작업을 생성하거나 트리거 형태로 정기적으로 데이터를 새로 고칠 수 있음).

2) 데이터 클리닝 은 주로 원본 데이터베이스에 나타나는 모호성, 중복, 불완전성, 비즈니스 또는 논리 규칙 위반 등의 문제가 있는 데이터의 통합 처리를 수행하는 것입니다. 즉, 비즈니스에 부합하지 않거나 쓸모 없는 데이터를 정리하는 것입니다. 예를 들어 길이가 현장 요구 사항을 충족하지 않는 데이터를 정리하려면 hive 또는 MR을 작성하세요.

3) 데이터 변환(transformation)은 주로 정리된 데이터를 데이터 웨어하우스에서 요구하는 데이터로 변환하는 것입니다: 데이터 사전 또는 다른 소스 시스템의 동일한 데이터 필드의 데이터 형식일 수 있습니다. (예를 들어 테이블 A에서는 id라고 하고 테이블 B에서는 id라고 합니다.) 데이터 웨어하우스에서는 데이터 내용을 정규화하기 위해 통일된 데이터 사전과 형식을 제공해야 합니다. 웨어하우스 요구 사항 일부 필드의 내용은 소스 시스템에서 사용할 수 없지만 소스 시스템의 여러 필드 내용을 기반으로 결정되어야 합니다.

4) 데이터 로딩 은 마지막 처리된 데이터를 해당 저장 공간(hbase, mysql 등)으로 가져와 시각화를 위한 데이터 마트에 제공을 용이하게 하는 것입니다.

일반적으로 대기업은 데이터 보안 및 운영 편의성을 위해 자체 캡슐화된 데이터 플랫폼과 작업 스케줄링 플랫폼을 보유하고 있습니다. 하위 계층에는 hadoop 클러스터, 스파크 클러스터, sqoop, hive, Zookeeper, hbase, 등. 웹 인터페이스를 제공하고 직원마다 다른 권한을 부여한 다음 클러스터에서 다양한 작업과 호출을 수행합니다. 데이터 웨어하우스를 예로 들면, 데이터 웨어하우스는 여러 논리적 수준으로 나뉩니다. 이러한 방식으로 다양한 수준의 데이터 작업에 대해 다양한 수준의 작업 흐름에서 다양한 수준의 작업을 생성하고 실행할 수 있습니다(대규모 회사의 클러스터에는 일반적으로 실행 대기 중인 수천 또는 수만 개의 예약된 작업이 있습니다) 매일 다르기 때문에 계층적 작업 흐름, 서로 다른 수준의 작업이 해당 작업 흐름에서 실행되므로 관리 및 유지 관리가 더 편리해집니다.

03 레이어링에 대한 오해

데이터 웨어하우스 레이어의 내부 구분은 레이어링을 위한 레이어링이 아닙니다. 레이어링은 ETL 작업 및 워크플로의 구성, 데이터 흐름 및 제어를 해결하는 것입니다. 다양한 요구 사항 충족과 같은 다양한 문제를 읽고 쓸 수 있습니다.

업계의 일반적인 관행은 전체 데이터 웨어하우스 계층을 DWD, DWT, DWS, DIM, DM 등과 같은 여러 계층으로 나누는 것입니다. 그러나 우리는 이러한 계층 간의 명확한 경계가 무엇인지 알 수 없거나 계층 간의 경계를 명확하게 설명할 수 없습니다. 그러나 복잡한 비즈니스 시나리오로 인해 실제로 이를 구현하는 것은 불가능합니다.

일반적으로 데이터 계층화에 있어서는 세 가지 계층이 가장 기본입니다. DW 계층을 분할하는 방법은 특정 비즈니스 요구 사항과 회사 시나리오를 기반으로 사용자가 정의합니다.

2. 데이터 웨어하우스의 기술 아키텍처

데이터 센터에는 많은 콘텐츠가 포함되어 있습니다. 특정 작업에 해당하는 경우 다음 콘텐츠가 포함될 수 있습니다.

• 시스템 아키텍처: Hadoop, Spark 및 기타 구성요소를 중심으로 한 아키텍처 시스템
• 데이터 아키텍처: 최상위 설계, 주제 도메인 분할, 계층적 설계, ODS-DW-ADS
• 데이터 모델링: 차원 모델링, 비즈니스 프로세스 - 세분성 결정 - 차원 - 팩트 테이블
• 데이터 관리: 자산 관리, 메타데이터 관리, 품질 관리, 마스터 데이터 관리, 데이터 표준, 데이터 보안 관리
• 보조 시스템: 스케줄링 시스템, ETL 시스템, 모니터링 시스템
• 데이터 서비스: 데이터 포털, 머신러닝 데이터 마이닝, 데이터 쿼리, 분석, 보고 시스템, 시각화 시스템 , 데이터 교환 공유 및 다운로드

3. 데이터 웨어하우스 계층 아키텍처

데이터 웨어하우스는 기본적으로 4개 계층으로 나눌 수 있습니다. 그러나 이 구분과 이름은 고유하지 않습니다. 일반적으로 데이터 웨어하우스는 4개의 레벨로 구성되어 있지만 회사마다 이름이 다를 수 있습니다. 그러나 핵심 개념은 모두 4계층 데이터 모델에서 나옵니다.

01 게시 소스 레이어(ODS, Operational Data Store)

데이터 소개 레이어(ODS, Operational Data Store, 데이터베이스 레이어라고도 함) ) : 원본 데이터는 거의 처리 없이 데이터 웨어하우스 시스템에 저장되며, 구조는 기본적으로 소스 시스템과 일치합니다. 데이터 웨어하우스의 데이터 준비 영역입니다. 이 계층의 주요 역할은 기본 데이터를 동기화하고 저장하는 것입니다.

일반적으로 ODS 계층의 데이터와 소스 시스템의 데이터는 동형이며 주요 목적은 후속 데이터 처리를 단순화하는 것입니다. 데이터 세분성 측면에서 ODS 계층의 데이터 세분성은 괜찮습니다. ODS 계층의 테이블에는 일반적으로 두 가지 유형이 포함됩니다. 하나는 로드해야 하는 현재 데이터를 저장하는 데 사용되는 유형이고 다른 하나는 처리 후 기록 데이터를 저장하는 데 사용되는 유형입니다. 과거 데이터는 일반적으로 3~6개월 동안 저장되며 공간 절약을 위해 삭제해야 합니다. 그러나 서로 다른 프로젝트는 다르게 처리되어야 합니다. 소스 시스템의 데이터 양이 크지 않으면 장기간 보관하거나 전체를 저장할 수도 있습니다.

참고: 이 레이어에서는 단순한 데이터 액세스가 아니라 비정상적인 필드 처리, 필드 이름 표준화, 시간 필드 통일 등 특정 데이터 정리가 고려되어야 합니다. 일반적으로, 이는 간과되기 쉽지만 매우 중요합니다. 특히 나중에 다양한 기능을 자동 생성할 때 매우 유용할 것입니다.

참고: 일부 회사의 ODS 레이어는 많은 데이터 필터링을 수행하지 않으며 처리를 위해 DWD 레이어에 배치됩니다. 일부 회사에서는 처음부터 ODS 계층에서 상대적으로 정제된 데이터 필터링을 수행합니다. 이는 명확하게 정의되어 있지 않으며 각 회사의 아이디어와 기술 사양에 따라 다릅니다.

일반 기업 개발에서는 원본 데이터가 ODS에 저장될 때 몇 가지 기본 처리를 수행합니다.

데이터 소스 차별화

데이터는 일반적으로 날짜별로 시간 분할에 따라 저장되며 일부 회사에서는 연, 월, 일의 3단계 파티션을 사용하여 저장합니다.

형식 오류 삭제, 누락된 키 정보 필터링 등 가장 기본적인 데이터 처리를 수행합니다.

데이터 실시간 오프라인

• 오프라인 측면: 일일 예약 작업: 일괄 작업 실행, 일반적인 일일 컴퓨팅 작업과 같은 비즈니스 라이브러리 실행. Sqoop은 추출에 자주 사용됩니다. 예를 들어 하루에 한 번 정기적으로 추출합니다. 매일 이른 아침에 전날의 데이터를 계산하고, 아침에 보고서를 읽어보세요. 이러한 종류의 작업은 Hive 및 Spark를 사용하여 계산되는 경우가 많으며 최종 결과는 Hive, Hbase, Mysql, Es 또는 Redis에 기록됩니다.
• 실시간 데이터: 로그 데이터 또는 비즈니스 라이브러리. 이 부분은 주로 실시간 추천, 실시간 사용자 초상화 등 다양한 실시간 시스템에서 사용됩니다. 그리고 Flink를 사용하여 계산하면 결국 Es, Hbase 또는 Redis에 속하게 됩니다. 데이터 소스는 비즈니스 데이터베이스입니다. Canal을 사용하여 Mysql의 Binlog를 모니터링하고 실시간으로 액세스한 다음 메시지 큐에 수집하고 최종적으로 Camus에 의해 HDFS로 가져오는 것을 고려할 수 있습니다.

1) 주요 데이터 소스:

• 데이터 소스는 회사의 모든 시스템에서 생성된 데이터
• 에 의해 보고되고 수집됩니다. 사용자 행동 로그 및 일부 백엔드 로그에 대한 로그 유형 데이터 소스에서. 묻힌 행동 로그의 경우 일반적으로 다음과 같은 과정을 거친다. 먼저 Nginx에 데이터가 보고된 후 Flume에 의해 수집된 다음 Kafka와 같은 메시지 큐에 저장되고 일부 실시간으로 가져옵니다. 또는 오프라인 가져오기 작업. 오프라인 데이터 창고 HDFS
• 외부 데이터(협동 데이터 및 크롤러에서 얻은 데이터 포함)를 가져오고 수집된 데이터를 함께 요약합니다

2) 데이터 저장 전략(증분) , 전액)

실제 적용시에는 증분식, 전체량 보관, 지퍼 보관 중 선택하여 사용하실 수 있습니다.

• 증분 저장

기록 데이터 분석 요구 사항을 충족하기 위해 ODS 레이어 테이블에 시간 차원을 파티션 필드로 추가할 수 있습니다. 비즈니스 날짜를 파티션으로 사용하는 일 단위의 증분 스토리지이며 각 파티션은 일일 증분 비즈니스 데이터를 저장합니다.

예:

1월 1일에 사용자 A가 A사의 전자상거래 매장 B를 방문했고, A사의 전자상거래 로그에서 1월 2일에 사용자 A가 다시 방문했다는 기록이 생성되었습니다. A사의 전자상거래 상점 C에 진입한 후 A사의 전자상거래 로그는 t2라는 레코드를 생성합니다.

증분 저장 방식을 사용하면 1월 1일에 t1이 파티션에 저장되고, 1월 2일에 t2가 파티션에 저장됩니다.

1월 1일에 사용자 A가 A사의 전자상거래 웹사이트에서 B 제품을 구매했으며 거래 로그에 t1이라는 기록이 생성됩니다. 1월 2일에 사용자 A가 B 제품을 다시 반품했으며 거래 로그는 다음과 같습니다. t1 레코드가 업데이트되었습니다.

증분 저장 방식을 사용하여 최초 구매한 t1 기록은 1월 1일에 파티션에 저장되고, 업데이트된 t1은 1월 2일에 파티션에 저장됩니다.

트랜잭션, 로그 등 트랜잭션 성격이 강한 ODS 테이블은 증분 스토리지에 적합합니다. 이러한 유형의 테이블은 데이터 양이 많고, 전체 스토리지를 사용하는 데 따른 스토리지 비용이 높습니다. 또한 이러한 테이블의 다운스트림 애플리케이션은 전체 기록 데이터 액세스에 대한 수요가 적습니다(이러한 수요는 데이터 웨어하우스의 후속 집계를 통해 얻을 수 있음). 예를 들어, 로그 ODS 테이블에는 데이터 업데이트 비즈니스 프로세스가 없으므로 모든 증분 파티션을 UNION하여 전체 데이터 세트를 형성합니다.

• 전체 저장 공간

일 단위의 전체 저장 공간, 영업일을 파티션으로 하고 각 파티션은 영업일까지의 전체 비즈니스 데이터를 저장합니다.

예를 들어, 판매자 A는 1월 1일에 회사 A의 전자상거래 웹사이트에 B와 C라는 두 개의 제품을 출시했습니다. 프런트엔드 제품 테이블은 1월 2일에 두 개의 레코드 t1과 t2를 생성합니다. A는 제품 B가 선반에서 제거되고 제품 D가 동시에 출시됩니다. 프런트엔드 제품 테이블은 레코드 t1을 업데이트하고 새 레코드 t3을 생성합니다. 전체 저장 방식을 사용하면 1월 1일에 t1, t2의 두 레코드가 파티션에 저장되고, 업데이트된 t1, t2, t3 레코드가 1월 2일에 파티션에 저장됩니다.

제품 카테고리 등 소량의 데이터로 천천히 변화하는 차원 데이터의 경우 풀 스토리지를 직접 사용할 수 있습니다.

• Zip Storage

Zip Storage는 두 개의 새로운 타임스탬프 필드(start_dt 및 end_dt)를 추가하여 모든 변경 데이터를 매일 세부적으로 기록합니다. 일반적으로 파티션 필드도 이와 같습니다. 두 개의 타임스탬프 필드입니다.

솔루션

개념 : 인터페이스 레이어(스테이지)라고도 하며, 일일 증분 데이터를 저장하고 데이터를 변경하는 데 사용됩니다.

데이터 생성 방법: kafka에서 직접 소스를 수신합니다. 데이터의 경우, 비즈니스 테이블은 매일 데이터를 업데이트, 삭제, 삽입해야 하며, 삽입 데이터를 위한 비즈니스 테이블만 생성되며 해당 데이터는 세부 레이어에 직접 입력됩니다.

토론 계획: 운하 통나무만 버퍼 레이어에 직접 넣습니다. 지퍼 데이터가 있는 다른 업체도 있으면 버퍼 레이어에 넣습니다.

로그 저장 방법: MR 처리가 필요한 데이터를 쉽게 읽을 수 있도록 임팔라 모양과 Parquet 파일 형식을 사용합니다.

로그 삭제 방법 : 장기 보관, 최근 며칠 동안의 데이터만 보관 가능합니다. 논의 계획: 직접 장기 보관.

테이블 스키마: 파티션은 일반적으로 매일 생성되며, 파티셔닝된 파티션은 일반적으로 매일 저장됩니다.

라이브러리 및 테이블 이름 지정. 라이브러리 이름: ods, 테이블 이름: 초기 고려 형식은 ods 날짜 비즈니스 테이블 이름이며 결정됩니다.

hive의 외부 테이블은 비즈니스 테이블에 해당합니다.

Hive 외부 테이블의 경우 데이터가 저장되는 파일이 Hive의 hdfs 기본 위치에 없을 수 있으며, Hive 해당 테이블을 삭제해도 해당 데이터 파일은 삭제되지 않습니다. 이는 기업 개발에 적합합니다. 테이블 삭제 작업으로 인해 하이브 비즈니스 테이블에서 중요한 데이터가 삭제되는 것을 방지하기 위해 데이터 파일은 하이브에 해당하는 기본 위치에 저장됩니다. 삭제되었습니다.

02 데이터 웨어하우스(DW)

데이터 웨어하우스(DW) 레이어: 데이터 웨어하우스 레이어는 데이터 웨어하우스를 만들 때 핵심 설계 레이어입니다. 이 레이어는 ODS에서 얻은 데이터입니다. 레이어는 주제에 따라 다양한 데이터 모델을 구축합니다. 각 주제는 거시적 분석 영역에 해당합니다. 데이터 웨어하우스 레이어는 의사 결정에 불필요한 데이터를 제외하고 특정 주제에 대한 간결한 보기를 제공합니다. BI 시스템의 모든 이력 데이터(예: 10년치 데이터)는 DW 레이어에 저장됩니다.

DW는 상세한 사실 데이터, 차원 테이블 데이터 및 공개 지표 요약 데이터를 저장합니다. 그 중 세부 팩트 데이터와 차원 테이블 데이터는 일반적으로 ODS 레이어 데이터 처리를 기반으로 생성됩니다. 공개 지표 요약 데이터는 일반적으로 차원 테이블 데이터와 세부 팩트 데이터를 기반으로 생성됩니다.

DW 레이어는 차원 레이어(DIM), 상세 데이터 레이어(DWD), 요약 데이터 레이어(DWS)로 세분화됩니다. 차원 모델과 팩트 모델의 외래 키 관계를 정의할 수 있으므로 데이터 중복이 줄어들고 세부 데이터 테이블의 유용성이 향상됩니다. 요약 데이터 레이어에서는 재사용된 통계 세분성의 차원도 연관될 수 있으며, 더 넓은 테이블 방법을 사용하여 공개 지표 데이터 레이어를 구축하여 공개 지표의 재사용성을 개선하고 반복 처리를 줄일 수 있습니다.

차원 레이어(DIM, Dimension): 차원을 모델링 동인으로 사용하여 각 차원의 비즈니스 의미를 기반으로 차원 속성, 관련 차원 등을 추가하여 계산 로직을 정의하여 속성 정의를 완성합니다. 일관된 데이터 분석 차원 테이블을 처리하고 구축합니다. 차원 모델에서 차원 특성이 중복적으로 연관되는 것을 방지하기 위해 차원 테이블은 눈송이 모델을 기반으로 작성됩니다.

상세 데이터 계층(DWD, Data Warehouse Detail): 비즈니스 프로세스를 모델링 동인으로 삼아 각 특정 비즈니스 프로세스의 특성을 기반으로 가장 세분화된 세부 팩트 테이블을 구축합니다. 일부 중요한 속성 필드는 적절하게 중복되도록 만들 수 있습니다(즉, 와이드 테이블 처리).

데이터 웨어하우스 요약(DWS): 분석된 주제 개체를 모델링 드라이버로 사용하여 상위 계층 애플리케이션 및 제품의 표시기 요구 사항을 기반으로 공개 세부 요약 표시기 테이블을 구축합니다. 와이드 테이블 방법을 사용하여 모델을 물리적화하고, 명명 표준과 일관된 구경으로 통계 지표를 구축하고, 상위 계층에 공개 지표를 제공하고, 요약 와이드 테이블과 세부 팩트 테이블을 설정합니다.

테마 도메인: 비즈니스 프로세스 중심, 주문, 결제, 환불 등 비즈니스 활동 이벤트를 추상적으로 수집하는 것이 모두 비즈니스 프로세스입니다. 공통 세부 수준(DWD)을 위한 테마 분할.

데이터 도메인: 비즈니스 분석의 경우 비즈니스 프로세스 또는 차원의 추상 모음입니다. DWS(공통 요약 계층)를 위한 데이터 도메인 분할.

DWD 계층은 비즈니스 프로세스에 의해 구동됩니다.

DWS 레이어, DWT 레이어 및 ADS 레이어는 모두 수요 중심입니다.

DWD: 데이터 웨어하우스 세부 데이터 세부 레이어. 주로 ODS 데이터 계층에서 일부 데이터 정리 및 표준화 작업을 수행합니다.

데이터 정리: null 값, 더티 데이터, 열거형 값 변환 및 제한 범위를 초과하는 데이터를 제거합니다.

DWB: 객관적인 데이터를 저장하는 데이터 웨어하우스 기반 데이터베이스 계층. 일반적으로 중간 계층으로 사용되며 다수의 지표에 대한 데이터 계층으로 간주될 수 있습니다.

DWS: 데이터 웨어하우스 서비스 데이터 서비스 레이어는 DWB의 기본 데이터를 기반으로 특정 주제 영역(일반적으로 넓은 테이블)을 분석하기 위해 서비스 데이터 레이어로 통합 및 요약됩니다. 후속 비즈니스 쿼리, OLAP 분석, 데이터 배포 등을 제공하는 데 사용됩니다.

사용자 행동, 가벼운 집계

주로 ODS/DWD 레이어 데이터에 대한 간단한 요약을 수행합니다.

1) 공용 차원 레이어(DIM, Dimension)

DIM: 이 레이어는 국가 코드, 국가 이름, 지리적 위치 등을 예를 들어 비교적 간단하게 이해할 수 있습니다. 중국 이름, 국기, 사진 및 기타 정보는 DIM 레이어에 저장됩니다.

차원 모델링 개념을 바탕으로 전사적으로 일관된 차원을 설정합니다. 일관되지 않은 데이터 계산 수준 및 알고리즘의 위험을 줄입니다.

공개 차원 요약 레이어(DIM)는 주로 차원 테이블(차원 테이블)로 구성됩니다. 디멘션은 비즈니스를 측정하고 관찰하는 논리적 개념이자 관점입니다. 차원 테이블(Dimension Table)은 데이터 플랫폼에 구축된 테이블을 차원과 그 속성을 기반으로 물리적화하고, 와이드 테이블 디자인의 원리를 적용한 테이블이다. 따라서 공통 차원 요약 레이어(DIM)를 구축하려면 먼저 차원을 정의해야 합니다.

고카디널리티 차원 데이터: 일반적으로 사용자 데이터 테이블 및 제품 데이터 테이블과 유사한 데이터 테이블입니다. 데이터의 양은 수천만 개가 될 수도 있고 수억 개가 될 수도 있습니다.

낮은 카디널리티 차원 데이터: 일반적으로 열거 값에 해당하는 중국어 의미 또는 날짜 차원 테이블과 같은 구성 테이블입니다. 데이터의 양은 한 자릿수일 수도 있고 수만 개일 수도 있습니다.

설계 치수 테이블:

치수 정의를 완료한 후 치수를 보완하여 치수 테이블을 생성할 수 있습니다. 치수 테이블 디자인에는 주의가 필요합니다.

치수 양식 테이블 정보는 1천만 개를 초과하지 않는 것이 좋습니다.

차원 테이블을 다른 테이블과 조인할 때 차원 테이블의 데이터가 너무 자주 업데이트되지 않도록 Map Join

을 사용하는 것이 좋습니다. 천천히 변화하는 차원: 지퍼 테이블

공용 차원 요약 계층(DIM) 차원 테이블 사양

공용 차원 요약 계층(DIM) 차원 테이블 명명 사양: 희미한_{비즈니스 세그먼트 이름/pub} _{차원 정의}[_{Customized naming tag}], 소위 pub은 시간 차원과 같이 특정 비즈니스 분야와 관련이 없거나 모든 비즈니스 분야에 공통되는 차원입니다.

예: 공공 영역 차원 테이블 희미한_pub_area 제품 차원 테이블 희미한 asale_itm

팩트 테이블의 레코드로 표현되는 비즈니스 세부 정보의 정도를 세분성이라고 합니다. 일반적으로 세분성은 두 가지 방식으로 표현될 수 있습니다. 하나는 차원 속성의 조합으로 표시되는 세부 수준이고, 다른 하나는 표시되는 특정 비즈니스 의미입니다. 투명한! 데이터 웨어하우스 분야의 일반적인 모델링 방법과 실제 사례입니다.

모델링 방법 및 원리

보통 별형 모델을 사용하여 차원 모델을 구축해야 하며, 제시된 상태는 일반적으로 별자리 모델(여러 팩트 테이블로 구성, 차원 테이블) 공개되며 여러 팩트 테이블에서 공유할 수 있음)

데이터 재실행을 지원하기 위해 추가 데이터 비즈니스 날짜 필드를 추가할 수 있고 테이블을 날짜별로 나눌 수 있으며 증분 ODS 레이어 데이터 그리고 전날의 DWD 관련 테이블을 병합 처리에 사용할 수 있나요?

세분성은 한 줄의 정보가 주문과 같은 하나의 행동을 나타낸다는 것입니다.

차원 모델링 단계

업무 프로세스 선택 : 업무 시스템에서 주문 업무, 결제 업무, 환불 업무, 물류 업무, 사업 분야 등 관심 업무 분야를 선택하는 것에 해당합니다. 팩트 테이블. 중소기업이라면 모든 업무 프로세스를 선택해 보세요. DWD가 대기업(테이블 1,000개 이상)인 경우 요구 사항과 관련된 비즈니스 라인을 선택합니다.

선언 세분성: 데이터 세분성은 데이터 웨어하우스에 저장된 데이터의 정제 수준이나 포괄성을 나타냅니다. 세분성을 선언한다는 것은 팩트 테이블의 데이터 행이 나타내는 내용을 정확하게 정의하는 것을 의미하며 다양한 요구 사항을 충족하기 위해 가능한 가장 작은 세분성을 선택해야 합니다. 일반적인 세분성 설명은 다음과 같습니다. 주문의 각 항목은 주문 사실 테이블의 행으로 처리되며 세분성은 매번입니다. 주당 주문 수는 행으로 제공되며 단위는 주 단위입니다. 월별 주문 수는 행으로 표시되며 단위는 월 단위입니다. DWD 레이어의 세분성이 주별 또는 월별인 경우 나중에 세부적인 지표를 계산할 방법이 없습니다. 따라서 가장 작은 세분성을 사용하는 것이 좋습니다.

차원 결정: 차원의 주요 역할은 주로 "누가, 어디서, 언제"와 같은 정보를 나타내는 비즈니스 사실을 설명하는 것입니다. 차원을 결정하는 원칙은 관련 차원의 지표를 후속 요구사항에서 분석해야 하는지 여부입니다. 예를 들어, 언제 더 많은 주문이 이루어졌는지, 어느 지역이 더 많은 주문을 했는지, 어느 사용자가 더 많은 주문을 했는지 확인하려면 통계가 필요합니다. 결정해야 하는 차원에는 시간 차원, 지역 차원 및 사용자 차원이 포함됩니다. 차원 테이블: 차원 모델링의 스타 스키마 원리에 따라 차원 저하를 수행해야 합니다.

사실 확인: 여기서 "사실"이라는 단어는 주문 금액, 주문수량 등 DWD 레이어에서는 비즈니스 프로세스가 모델링 드라이버로 사용되며, 각 특정 비즈니스 프로세스의 특성을 기반으로 가장 세분화된 세부 레이어 팩트 테이블이 구축됩니다. 팩트 테이블은 적절하게 확장될 수 있습니다.

참고: DWD 계층은 비즈니스 프로세스에 의해 구동됩니다. DWS 계층, DWT 계층 및 ADS 계층은 모두 수요 중심이며 차원 모델링과 관련이 없습니다. DWS와 DWT는 모두 넓은 테이블을 구축하고 테마에 따라 테이블을 구축합니다. 주제는 문제를 보는 관점과 동일합니다. 차원 테이블에 해당합니다.

테마 정보:

데이터 웨어하우스의 데이터는 테마별로 구성됩니다. 테마는 기업 정보 시스템의 데이터를 더 높은 수준에서 종합, 분류 및 분석하는 방법입니다. 개념, 각 주제는 기본적으로 거시 분석 분야에 해당합니다. 예를 들어 재무 분석은 분석 분야이므로 이 데이터 웨어하우스 애플리케이션의 주제는 "재무 분석"입니다.

주제 도메인 정보:

주제 도메인은 일반적으로 밀접하게 관련된 데이터 주제의 모음입니다. 이러한 데이터 주제는 비즈니스 관심사(즉, 주제 분석 후 결정된 주제의 경계)에 따라 다양한 주제 영역으로 나눌 수 있습니다

주제 영역 구분에 대해:

주제 도메인의 결정은 최종 사용자(비즈니스)와 데이터 웨어하우스 설계자가 공동으로 완료해야 합니다. 주제 도메인을 분할할 때 모든 사람의 진입점이 다르기 때문에 논쟁, 리팩토링 등이 발생할 수 있습니다.

• 비즈니스 또는 비즈니스 프로세스에 따라 구분: 예를 들어 광고 위치 판매에 의존하는 포털 웹사이트에는 광고 도메인, 고객 도메인 등이 있을 수 있으며 광고 도메인에는 광고 인벤토리, 매출 분석, 내부 납품 분석 및 기타 주제가 있을 것입니다.
• 수요 측면에 따라 구분: 예를 들어 수요 측면이 재무 부서인 경우 해당 금융 주제 영역은 다음과 같습니다. 설정되며 재무 주제 영역에는 직원 급여 분석, 투자 수익률 분석 등이 포함될 수 있습니다.
• 기능이나 응용 프로그램에 따라 구분됩니다. 예: 친구 데이터 필드, WeChat의 그룹 채팅 데이터 필드 등 및 친구 서클 데이터 필드에는 동적 정보 테마, 광고 테마 등이 있을 수 있습니다.
• 부서별로 구분: 예를 들어 운영 도메인이 있을 수 있습니다. 기술 영역 등 운영 영역에서는 급여 지출 분석, 이벤트 홍보 효과 분석 등의 주제가 있을 수 있습니다.

간단히 말하면 출발점 논리가 다르면 다를 수 있습니다. 분할 논리. 모든 주제의 추상화를 한 번에 완료하는 데 집중하는 대신, 명확하게 정의된 주제부터 시작한 다음 이를 점차적으로 자신의 산업에 맞는 표준 모델로 요약하는 것이 구축 프로세스 중에 반복적 접근 방식을 채택할 수 있습니다.

주제: 당사자, 마케팅, 금융, 계약 계약, 조직, 주소, 채널, 제품,

금융 비즈니스 주제는 무엇입니까: 네 가지 주제로 나눌 수 있습니다:

• 사용자 테마(사용자 연령, 성별, 배송지 주소, 전화번호, 지방 등)
• 거래 테마(주문 데이터, 청구서 데이터 등)
• 위험 관리 테마(사용자의 위험 통제 수준, 제3자 신용 데이터)
• 마케팅 주제(마케팅 활동 목록, 활동 구성 정보 등)

2) DWD(데이터 웨어하우스 세부 정보) 데이터 세부 레이어, 세분화 사실 레이어

DWD는 비즈니스 레이어와 데이터 웨어하우스 사이의 격리 레이어입니다. 이 레이어는 주로 일부 데이터 품질 문제와 데이터 무결성 문제를 해결합니다.

상세 테이블은 ODS 레이어의 원본 테이블에서 변환된 상세 데이터를 저장하는 데 사용됩니다. DWD 레이어의 데이터는 일관되고 정확하며 깨끗한 데이터, 즉 소스 시스템 데이터인 ODS여야 합니다. 계층 데이터를 정리해야 합니다(빈 값, 더티 데이터, 제한 범위를 초과하는 데이터 제거, 행 저장소를 열 저장소로 변경, 압축 형식 변경), 정규화, 차원 저하, 감도 줄이기 및 기타 작업을 수행해야 합니다. 예를 들어, 사용자 데이터 정보는 다양한 테이블에서 나오므로 데이터 손실 지연과 같은 문제가 자주 발생합니다. 각 사용자가 데이터를 더 잘 사용할 수 있도록 이 계층에 보호막을 만들 수 있습니다. 이 레이어에는 통합된 차원 데이터도 포함되어 있습니다.

Detailed-grained Fact Layer(DWD): 비즈니스 프로세스를 모델링 동인으로 삼아 각 특정 비즈니스 프로세스의 특성을 기반으로 가장 세분화된 세부 레이어 팩트 테이블이 구성됩니다. 기업의 데이터 사용 특성을 결합하여 세부 팩트 테이블의 일부 중요한 차원 속성 필드를 적절하게 중복되도록 만들 수 있습니다. 즉, 와이드 테이블 처리입니다. 세분화된 팩트 수준의 테이블은 종종 논리적 팩트 테이블이라고도 합니다.

DWD 레이어를 기반으로 가볍게 요약하고 공통 차원(시간, 위치, 조직 수준, 사용자, 제품 등)과 결합하여 가장 세분화된 데이터를 담당합니다.

이 계층은 일반적으로 ODS 계층과 동일한 데이터 세분성을 유지하며 일정한 데이터 품질을 보장합니다. ODS 기반으로 데이터를 처리하여 보다 깨끗한 데이터를 제공합니다. 동시에, 데이터 세부 계층의 유용성을 향상시키기 위해 이 계층은 일부 차원 저하 기술을 채택합니다. 차원에 데이터 웨어하우스에 필요한 데이터가 없으면 차원이 저하될 수 있으며 차원이 저하될 수 있습니다. 팩트 테이블로 성능이 저하되어 팩트 테이블 및 차원 테이블 연결 수가 줄어듭니다.

예:

주문 ID는 차원이 너무 커서 이를 저장하기 위해 차원 테이블을 사용할 필요가 없으며 일반적으로 데이터 분석을 수행할 때 주문 ID가 매우 중요하므로 우리는 주문 ID가 팩트 테이블에서 중복됩니다. 이 차원은 퇴화된 차원입니다.

이 수준의 데이터는 일반적으로 데이터베이스의 세 번째 정규형 또는 차원 모델링을 따르며 데이터 세분성은 일반적으로 ODS와 동일합니다. BI 시스템의 모든 기록 데이터(예: 10년치 데이터)는 PDW 계층에 저장됩니다.

데이터가 이 레이어에 로드되기 전에 노이즈 제거, 중복 제거, 먼지 제거, 비즈니스 추출, 단위 통합, 필드 절단 및 비즈니스 식별과 같은 작업을 수행해야 합니다.

삭제된 데이터 유형:

• 불완전한 데이터
• 오류 데이터
• 데이터 중복

데이터 정리의 임무는 필터입니다 요구 사항에 맞지 않는 데이터를 처리하고, 필터링된 결과를 사업부서에 제출하여 추출 전 사업부에서 필터링 또는 수정되었는지 확인합니다.

DWD 레이어의 기능은 무엇인가요?

1데이터 정리 및 필터링

버려진 필드 제거, 잘못된 형식의 정보 제거

키 필드가 손실된 정보 제거

필터 코어 필드는 의미 없는 데이터이며, 예를 들어, 주문 테이블의 주문 ID가 null이고 결제 테이블의 결제 ID가 비어 있습니다.

휴대폰 번호, ID 번호 등 민감한 데이터를 민감하게 처리하지 마세요.

해당하는 데이터를 제거하세요. 시간 정보를 포함하지 않음(이는 회사의 특정 비즈니스에 따라 다르지만 일반적으로 시간 차원에서 후속 처리, 정보 분석, 처리 및 추출을 용이하게 하기 위해 데이터에 타임스탬프가 표시됩니다.)

일부 회사에서는 인쇄할 수도 있습니다. 이 레이어의 데이터는 평면적이지만 비즈니스 요구 사항에 따라 다릅니다. 이는 kylin이 평면화된 데이터 처리에는 적합하지만 중첩 테이블 데이터 정보 처리에는 적합하지 않기 때문입니다.

일부 회사에서는 데이터 세션도 잘라냅니다. 이것은 일반적으로 앱입니다. 로그 데이터는 다른 비즈니스 시나리오에 적합하지 않을 수 있습니다. 이는 앱이 백그라운드 모드로 전환되기 때문입니다. 예를 들어 사용자가 아침에 10분 동안 앱을 연 다음 앱이 백그라운드로 들어가서 열립니다. 이때 세션은 아직 1개이고 실제로는 끊어야 합니다. (앱이 백그라운드로 들어갔다가 다시 프런트에 들어가는 기록을 기록하는 회사도 있습니다. 세션 자르기)

②데이터 매핑 및 변환

GPS 경도와 위도를 시/도 상세 주소로 변환합니다. 업계에서 흔히 사용하는 GPS 빠른 쿼리는 일반적으로 지오해시를 이용해 지리적 위치 지식베이스를 매핑한 후, GPS를 지오해시로 변환한 후 지식베이스의 지오해시를 비교하여 지리적 위치정보를 알아내는 방법도 있다. Amap과 같은 오픈 API를 사용하는 기업에서는 바이두맵의 API가 GPS와 지리적 위치정보를 지도로 표시하지만 일정 횟수에 도달하려면 비용이 들기 때문에 IP 주소도 지방 및 상세 주소로 변환된다는 사실은 누구나 알고 있습니다. 도시. 빠른 검색 라이브러리가 많이 있지만 IP 주소를 긴 정수로 변환할 수 있기 때문에 기본 원칙은 이진 검색입니다. 전형적인 예는 시간을 연도, 월, 일 또는 시간으로 변환하는 ip2region 라이브러리

입니다. 심지어 주, 분기 차원 정보

데이터 표준화, 빅데이터로 처리되는 데이터는 자원 회사의 다른 부서, 다른 프로젝트, 다른 클라이언트에서 나올 수 있기 때문에 이때 동일한 비즈니스 데이터 필드, 데이터. 유형, null 값 등이 다를 수 있습니다. 이때 DWD 레이어를 평활화해야 합니다. 그렇지 않으면 후속 처리 시 많은 문제가 발생합니다. 예를 들어 부울은 0 1로 표시됩니다. 예를 들어 문자열은 비어 있습니다. 값은 "" 또는 null을 사용할 수 있습니다.

날짜 형식 등은 좀 더 다르며 실제 비즈니스 데이터를 기반으로 결정해야 하지만 일반적으로 YYYY-MM-dd HH:mm:ss

차원과 같은 표준 형식으로 형식이 지정됩니다. 저하: 비즈니스 데이터에서 전송된 테이블에 대해 차원 저하 및 차원 축소를 수행합니다. (제품 1급, 2급, 3급, 도, 시, 군, 년, 월, 일) 팩트 테이블에서 주문 ID가 중복됩니다

정리하는 것이 합리적인 데이터 양: 데이터 1개 10,000개 중에서 청소됩니다.

합리적인 테이블 수: 10,000개의 테이블이 3,000개의 테이블이 되고, 3,000개의 테이블이 1,000개의 테이블이 됩니다.

상세한 세분화된 팩트 테이블 설계 원칙:

• 세분화된 팩트 테이블 하나의 차원에만 연결됩니다.
• 비즈니스 프로세스와 관련된 사실을 최대한 많이 포함하세요.
• 비즈니스 프로세스와 관련된 사실만 선택하세요.
• 비부가적 사실을 부가적 구성요소로 분해합니다.
• 차원과 팩트를 선택하기 전에 세분성을 선언해야 합니다.
• 동일한 팩트 테이블에 서로 다른 세분성의 여러 팩트를 포함할 수 없습니다.
• 사실의 단위는 일관성이 있어야 합니다. 세분성
• Null 값을 주의해서 처리하세요.
• 축소 차원을 사용하여 팩트 테이블의 유용성을 향상시킵니다.

계획

논의 계획: 데이터 합성 방법:

전량: 매일, 전날의 전량 데이터와 어제의 새로운 데이터 세부 레이어에서 새 데이터 테이블로 합성됩니다. 이전 테이블을 덮어씁니다. 동시에 기록 미러링을 사용하여 주/월/연도별로 새 테이블에 기록 미러를 저장합니다.

로그 저장 방법: 직접 데이터는 임팔라 모양과 Parquet 파일 형식을 사용합니다. 다음 레이어는 모두 임팔라에서 생성된 데이터입니다. + 정적/동적 파티셔닝을 사용하는 것이 좋습니다. .

테이블 스키마: 일반적으로 요일별로 파티션을 생성하고, 시간 개념 없이 특정 업무에 맞게 파티션 필드를 선택합니다. 파티셔닝은 일반적으로 날짜별로 저장됩니다.

라이브러리 및 테이블 이름 지정. 라이브러리 이름: dwd, 테이블 이름: 초기 고려 형식은 dwd 날짜 비즈니스 테이블 이름이며 결정됩니다.

이전 데이터 업데이트 방법: 직접 적용

Detailed Granularity Fact Layer(DWD) 사양

네이밍 사양은 다음과 같습니다: dwd_{비즈니스 섹션/pub}_{데이터 도메인 약어 } _{비즈니스 프로세스 약어}[_{Custom table naming label abbreviation}] _{단일 파티션 증분 전체 식별}, pub는 데이터에 여러 비즈니스 부문의 데이터가 포함되어 있음을 의미합니다. 단일 파티션의 증분 전체 양 식별자는 일반적으로 i는 증분을 의미하고 f는 전체 양을 의미합니다.

예: dwd_asale_trd_ordcrt_trip_di(전자상거래 회사의 항공권 주문 주문 팩트 테이블, 일일 새로 고침 증분) dwd_asale_itm_item_df(전자상거래 제품 스냅샷 팩트 테이블, 일일 새로 고침 전체 금액).

이 튜토리얼에서 DWD 레이어는 주로 3개의 테이블로 구성됩니다:

• 거래 상품 정보 팩트 테이블: dwd_asale_trd_itm_di.
• 거래 회원 정보 팩트 테이블: ods_asale_trd_mbr_di.
• 거래 주문 정보 팩트 테이블: dwd_asale_trd_ord_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;

3) DWS(데이터 웨어하우스 서비스) 데이터 서비스 레이어, 요약 레이어 와이드 테이블

DWD 상세 데이터 레이어를 기반으로 일부 분석 시나리오, 분석 개체, 등. 일부 하위 주제 요약 데이터 레이어 DWS로 구성됩니다.

세부 세분성 ==> 요약 세분성

DWS 레이어(데이터 요약 레이어) 와이드 테이블, 주제 중심 요약, 상대적으로 적은 차원, DWS는 DWD 레이어의 기본 데이터를 기반으로 합니다. 차원 ID는 트랜잭션 소스 및 트랜잭션 유형별 집계와 같은 대략적인 요약 집계를 수행합니다. 특정 주제 영역의 분석을 위해 서비스 데이터를 일반적으로 넓은 테이블로 통합하고 요약합니다.

DWD 기준, 요일별 간략한 요약입니다. 각 대상객체의 당일 행동에 대한 통계(예: 구매행동, 상품 재구매율 통계)

이 레이어에는 상대적으로 적은 수의 데이터 테이블이 있으며 대부분은 넓은 테이블입니다. 하나의 테이블이 더 많은 비즈니스 콘텐츠를 처리하고 테이블에 더 많은 필드가 있습니다. 주문, 사용자 등의 주제에 따라 다양한 필드로 구성된 넓은 테이블을 생성하여 후속 비즈니스 쿼리, OLAP 분석, 데이터 배포 등을 제공합니다.

사용자 팩트 테이블, 채널 팩트 테이블, 터미널 팩트 테이블, 자산 팩트 테이블 등과 같은 주제를 기반으로 여러 중간 계층 데이터를 통합하고 팩트 테이블을 형성합니다. 팩트 테이블은 일반적으로 넓은 테이블이며 이에 대해 구현됩니다. 레이어 전사적 데이터 일관성.

먼저 비즈니스 주제를 판매 도메인, 재고 도메인, 고객 도메인, 구매 도메인 등으로 나누고 각 주제 도메인의 팩트 테이블과 차원 테이블을 결정합니다. 일반적으로 비즈니스 요구사항을 기반으로 트래픽, 주문, 사용자 등으로 구분되며, 후속 비즈니스 쿼리, OLAP 분석, 데이터 배포 등을 제공하기 위해 많은 필드로 구성된 넓은 테이블이 생성됩니다.

지역별 특정 카테고리(예: 주방용품)의 마지막 날 판매량 총계, 해당 카테고리 상위 10개 판매 제품명, 지역별 사용자 구매력 분포. 따라서 상품, 카테고리, 구매자 등의 최종 성공적인 거래를 기반으로 마지막 날의 데이터를 요약할 수 있습니다.

예를 들어, 각 기간별로 서로 다른 로그인 IP로 사용자가 구매한 상품 수 등 여기에 간단한 요약을 하면 계산이 더 효율적이게 됩니다. 이를 토대로 7일, 30일, 90일의 행동만 계산하면 훨씬 더 빨라질 것입니다. 우리는 비즈니스의 80%가 ODS 대신 DWS 레이어를 통해 계산될 수 있기를 바랍니다.

DWS 레이어의 기능은 무엇인가요?

dws는 ​​dwd 레이어의 데이터를 주제별로 요약하여 주제에 따라 테이블에 넣습니다.

예를 들어 사용자 주제 아래에는 사용자 등록 정보, 사용자 배송 주소, 사용자의 신용 보고서는 동일한 테이블에 저장되며 이는 dwd 레이어의 여러 테이블에 해당합니다. 트래픽, 주문, 사용자 등 사업 부문에 따라 더 많은 필드가 있는 넓은 테이블입니다. 생성된

테마 모델링 비즈니스 주제에 대한 데이터 모델링을 수행하고 관련 데이터를 추출합니다.

예:

• 일별 및 월별 트래픽 세션 집계
• 일일 신규 사용자 추가 Aggregation
• 일일 활성 사용자 집계
• 차원 모델링은 실제로 유사하지만 비즈니스 요구 사항에 따라 후속 데이터 쿼리 처리에 필요한 차원 데이터를 추출하여 처리합니다.
• 예를 들어 운영 차원 데이터가 집계되면
• 채널 풀인 새 차원 데이터가 집계됩니다.

① DWS 레이어 주제당 넓은 테이블 1~3개(100개 처리 - 200개 지표 수요의 70% 이상)

특정 와이드 테이블 이름: 사용자 행동 와이드 테이블, 사용자 구매 상품 세부 행동 와이드 테이블, 제품 와이드 테이블, 물류 와이드 테이블, 애프터 세일 등

②폭이 가장 넓은 테이블은 무엇인가요? 대략 몇 개의 필드가 있나요?

가장 넓은 것은 사용자 행동 와이드 테이블입니다. 약 60~200개 필드가 있습니다

3특정 사용자 행동 넓은 테이블 필드 이름

댓글, 보상, 컬렉션, 제품 팔로우, 사람 팔로우, 좋아요, 공유, 좋은 가격 속보, 기사 퍼블리싱, 활동, 로그인, 재사인카드, 럭키하우스, 선물, 금화, 전자상거래 클릭, gmv

4분석지표

일간활동, 월간활동, 주간활동, 유지율, 유지율, 신규추가(일,주,년), 전환율, 이탈, 재방문, 3일 연속 로그인(좋아요, 모음, 댓글, 구매, 추가 구매, 주문, 활동) 7일 이내, 3일 연속 주간(월간) 로그인, GMV(거래금액, 주문), 재구매율, 재구매율 순위, 좋아요, 댓글, 수집, 할인받는 사람 수, 할인 사용, 침묵, 구매 가치가 있는지, 환불 횟수, 환불 인기상품 순위

• Active

일일 활성: 100만명, 월간 활성: 일일 활성 300만명의 2~3배

총 등록 사용자 수는 몇 명입니까? 천만~3천만

• GMV, 어떤 제품이 가장 잘 팔리나요? 하루에 몇 건의 주문이 접수되나요?

GMV: 하루 주문 100,000건(50-100위안) 500만-1000만

100만 일일 활동, 매일 약 100,000명이 구매, 평균 소비량은 100위안 인,일 GMV는 천만

1000,000-200만

• 재구매율

일용품 재구매; 페이셜 마스크, 치약 ) 10%-20%

컴퓨터, 모니터, 시계 1%

• 전환율

제품 세부 정보=》장바구니에 담기=》주문=》결제

5%-10% 60-70% 90%-95%

• 유지율

1/2/3, 주간 리텐션, 월간 리텐션

활동: 10-20%

계획:

개념: 데이터 마트 또는 와이드 테이블이라고도 합니다. 트래픽, 주문, 사용자 등 사업 부문에 따라 다양한 필드로 구성된 넓은 테이블을 생성하여 후속 비즈니스 쿼리, OLAP 분석, 데이터 배포 등을 제공합니다.

데이터 생성 방법: 조명 요약 레이어와 세부 레이어 데이터 계산을 통해 생성됩니다.

로그 저장 방법: 임팔라 내부 테이블, 쪽모이 세공 파일 형식 사용.

테이블 스키마: 일반적으로 요일별로 파티션을 생성하고, 시간 개념 없이 특정 업무에 맞게 파티션 필드를 선택합니다.

라이브러리 및 테이블 이름 지정. 라이브러리 이름: dws, 테이블 이름: 초기 고려 형식은 dws 날짜 비즈니스 테이블 이름이며 결정됩니다.

이전 데이터 업데이트 방법: 직접 재정의

공개 요약 팩트 테이블 사양

公共汇总事实表命名规范：dws_{业务板块缩写/pub}_{数据域缩写}_{数据粒度缩写}[_{自定义表命名标签缩写}]_{统计时间周期范围缩写}。关于统计实际周期范围缩写，缺省情况下，离线计算应该包括最近一天（_1d），最近N天（_nd）和历史截至当天（_td）三个表。如果出现_nd的表字段过多需要拆分时，只允许以一个统计周期单元作为原子拆分。即一个统计周期拆分一个表，例如最近7天（_1w）拆分一个表。不允许拆分出来的一个表存储多个统计周期。

对于小时表（无论是天刷新还是小时刷新），都用_hh来表示。对于分钟表（无论是天刷新还是小时刷新），都用_mm来表示。

举例如下：

dws_asale_trd_byr_subpay_1d（买家粒度交易分阶段付款一日汇总事实表）

dws_asale_trd_byr_subpay_td（买家粒度分阶段付款截至当日汇总表）

dws_asale_trd_byr_cod_nd（买家粒度货到付款交易汇总事实表）

dws_asale_itm_slr_td（卖家粒度商品截至当日存量汇总表）

dws_asale_itm_slr_hh（卖家粒度商品小时汇总表）---维度为小时

dws_asale_itm_slr_mm（卖家粒度商品分钟汇总表）---维度为分钟

• 用户维度：用户主题

drop table
if exists dws_sale_detail_daycount;
create external table dws_sale_detail_daycount(
user_id string comment '用户 id',
--用户信息
user_gender string comment '用户性别',
user_age string comment '用户年龄',
user_level string comment '用户等级',
buyer_nick string comment '买家昵称',
mord_prov string comment '地址',
--下单数、 商品数量， 金额汇总
login_count bigint comment '当日登录次数',
cart_count bigint comment '加入购物车次数',
order_count bigint comment '当日下单次数',
order_amount decimal(16,2) comment '当日下单金额',
payment_count bigint comment '当日支付次数',
payment_amount decimal(16,2) comment '当日支付金额',
confirm_paid_amt_sum_1d double comment '最近一天订单已经确认收货的金额总和'
order_detail_stats array<struct<sku_id:string,sku_num:bigint,order_count:bigint,order_amount:decimal(20,2)>> comment '下单明细统计'




) comment '每日购买行为'
partitioned by(`dt`
string)
stored as parquet
location '/warehouse/gmall/dws/dws_sale_detail_daycount/'
tblproperties("parquet.compression" = "lzo");

• 商品维度：商品主题

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;

问：数据集市层是不是没地方放了，各个业务的数据集市表是应该在 dws 还是在 app?

答：这个问题不太好回答，我感觉主要就是明确一下数据集市层是干什么的，如果你的数据集市层放的就是一些可以供业务方使用的宽表，放在 app 层就行。如果你说的数据集市层是一个比较泛一点的概念，那么其实 dws、dwd、app 这些合起来都算是数据集市的内容。

03 应用层（ADS）applicationData Service应用数据服务

数据应用层（ADS，Application Data Store）：存放数据产品个性化的统计指标数据，报表数据。主要是提供给数据产品和数据分析使用的数据，通常根据业务需求，划分成流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。从数据粒度来说，这层的数据是汇总级的数据，也包括部分明细数据。从数据的时间跨度来说，通常是DW层的一部分，主要的目的是为了满足用户分析的需求，而从分析的角度来说，用户通常只需要分析近几年的即可。从数据的广度来说，仍然覆盖了所有业务数据。

在 DWS 之上，我们会面向应用场景去做一些更贴近应用的 APP 应用数据层，这些数据应该是高度汇总的，并且能够直接导入到我们的应用服务去使用。

应用层(ADS)：应用层主要是各个业务方或者部门基于DWD和DWS建立的数据集市(Data Market, DM)，一般来说应用层的数据来源于DW层，而且相对于DW层，应用层只包含部门或者业务方面自己关心的明细层和汇总层的数据。

该层主要是提供数据产品和数据分析使用的数据。一般就直接对接OLAP分析,或者业务层数据调用接口了

数据应用层APP：面向业务定制的应用数据主要提供给数据铲平和数据分析使用的数据，一般会放在ES，MYSQL，Oracle，Redis等系统供线上系统使用，也可以放在Hive 或者 Druid 中供数据分析和数据挖掘使用。

APP 层：为应用层，这层数据是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。如我们经常说的报表数据，或者说那种大宽表，一般就放在这里。包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析，面向最终结果用户；

概念：应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用。

数据生成方式：由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。

日志存储方式：使用impala内表，parquet文件格式。

表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。

库与表命名。库名：暂定ads，另外根据业务不同，不限定一定要一个库。

旧数据更新方式：直接覆盖。

ADS 层复购率统计

CREATE TABLE app_usr_interact( user_id string COMMENT '用户id',
nickname string COMMENT '用户昵称',
register_date string COMMENT '注册日期',
register_from string COMMENT '注册来源',
remark string COMMENT '细分渠道',
province string COMMENT '注册省份',
pl_cnt bigint COMMENT '评论次数',
ds_cnt bigint COMMENT '打赏次数',
sc_add bigint COMMENT '添加收藏',
sc_cancel bigint COMMENT '取消收藏',
gzg_add bigint COMMENT '关注商品',
gzg_cancel bigint COMMENT '取消关注商品',
gzp_add bigint COMMENT '关注人',
gzp_cancel bigint COMMENT '取消关注人',
buzhi_cnt bigint COMMENT '点不值次数',
zhi_cnt bigint COMMENT '点值次数',
zan_cnt bigint COMMENT '点赞次数',
share_cnts bigint COMMENT '分享次数',
bl_cnt bigint COMMENT '爆料数',
fb_cnt bigint COMMENT '好价发布数',
online_cnt bigint COMMENT '活跃次数',
checkin_cnt bigint COMMENT '签到次数',
fix_checkin bigint COMMENT '补签次数',
house_point bigint COMMENT '幸运屋金币抽奖次数',
house_gold bigint COMMENT '幸运屋积分抽奖次数',
pack_cnt bigint COMMENT '礼品兑换次数',
gold_add bigint COMMENT '获取金币',
gold_cancel bigint COMMENT '支出金币',
surplus_gold bigint COMMENT '剩余金币',
event bigint COMMENT '电商点击次数',
gmv_amount bigint COMMENT 'gmv',
gmv_sales bigint COMMENT '订单数'
)
PARTITIONED BY( dt string)
--stat_dt
date COMMENT '互动日期',

①如何分析用户活跃？

在启动日志中统计不同设备 id 出现次数。

②如何分析用户新增?

用活跃用户表 left join 用户新增表，用户新增表中 mid 为空的即为用户新增。

③如何分析用户 1 天留存？

留存用户=前一天新增 join 今天活跃

用户留存率=留存用户/前一天新增

④如何分析沉默用户？

(登录时间为 7 天前,且只出现过一次)

按照设备 id 对日活表分组，登录次数为 1，且是在一周前登录。

⑤如何分析本周回流用户？

本周活跃 left join 本周新增 left join 上周活跃，且本周新增 id 和上周活跃 id 都为 null。

⑥如何分析流失用户？

(登录时间为 7 天前)

按照设备 id 对日活表分组，且七天内没有登录过。

⑦如何分析最近连续 3 周活跃用户数？

按照设备 id 对周活进行分组，统计次数大于 3 次。

8지난 7일 동안 3일 연속 활성 사용자 수를 분석하는 방법은 무엇인가요?

• 최근 7일 동안의 활성 사용자를 쿼리하고 사용자의 활성 날짜 순위를 매깁니다.
• 사용자의 활성 날짜와 순위의 차이를 계산합니다.
• 동일한 사용자와 그룹을 계산합니다. 차이를 계산하고 차이 개수를 계산합니다
• 동일한 개수가 3 이상인 데이터를 꺼내고 중복된 항목을 제거합니다. 즉, 3일 연속으로 활동한 사용자 또는 더보기

7 연속 즐겨찾기, 좋아요, 구매, 추가 구매, 결제, 검색, 상품 클릭, 반품 매일

7일 연속 1개월

2주 연속

TMP: 모든 각 계산 수준에는 많은 임시 테이블이 있으며 DW TMP 레이어는 데이터 웨어하우스의 임시 테이블을 저장하도록 특별히 설계되었습니다.

04 계층적 호출 사양

• 역방향 호출은 금지됩니다
• ODS는 DWD에서만 호출할 수 있습니다.
• DWD는 DWS 및 ADS로 호출할 수 있습니다.
• DWS는 ADS로만 호출할 수 있습니다.
• 데이터 애플리케이션은 DWD, DWS, ADS를 호출할 수 있지만 집계 수준이 높은 데이터에 우선순위를 부여하는 것이 좋습니다.
• ODS->DWD->DWS>ADS
• ODS->DWD->ADS

위 내용은 ODS부터 ADS까지, 데이터 웨어하우스 계층화에 대한 자세한 설명!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!