新兴数据仓库设计与实践手册：从分层架构到实际应用（三）-编程知识

新兴数据仓库设计与实践手册：从分层架构到实际应用（三）

news/2024/11/27 15:17:13/文章来源:https://www.cnblogs.com/DolphinScheduler/p/18572366

本手册将分为三部分发布，以帮助读者逐步深入理解数据仓库的设计与实践。

第一部分介绍数据仓库的整体架构概述；
第二部分深入讨论ETL在数仓中的应用理论，ODS层的具体实现与应用；
第三部分将围绕DW数据仓库层、ADS层和数据仓库的整体趋势展开；

通过这样的结构，您可以系统地学习每一层次的内容和设计原则。

前情提要：
《新兴数据仓库设计与实践手册：从分层架构到实际应用（一）》https://mp.weixin.qq.com/s/_iYSM0sT_NOysducbxEJhg

《新兴数据仓库设计与实践手册：从分层架构到实际应用（二）》：http://mp.weixin.qq.com/s?__biz=MzkyODg0MzA1MQ==&mid=2247489134&idx=1&sn=47d09334fecb43ac2ee1beeb111c6abe&chksm=c37528ab9804979fefcb56f45551c409fd97d22453af0ae3b1df36de1026c42a3a61203c5a02#rd

技术方案设计

概念介绍

缓冲层（也称接口层或Stage层）用于存储每天的增量和变更数据。该层暂存从源系统采集的原始数据，以便后续数据处理和ETL流程的使用。

数据仓库

数据生成方式

数据通常通过Kafka直接接入缓冲层，对于包含update、delete和insert操作的业务表，会每日生成变更日志；而仅有insert操作的业务表，则直接将数据进入明细层。

建议方案： 使用Apache SeaTunnel或WhaleTunnel生成的CDC日志直接进入缓冲层。如果业务涉及拉链数据，同样将其存放于缓冲层，以确保数据变更的准确记录。

日志存储方式

缓冲层的日志数据以Impala外部表形式存储，采用Parquet文件格式。这种方式不仅提高了存储效率，还便于MapReduce等处理引擎对数据的快速访问和处理。

日志清理策略

对于日志数据，通常只保留最近几天的数据以节省存储空间。

建议方案：考虑长期存储重要日志数据，以便于历史数据回溯和审计。

表的Schema和分区策略

通常按天分区数据，以partitioned by时间字段进行存储。这样不仅简化了数据管理，还能提升查询效率。表的Schema设计遵循源系统的结构，以确保数据的一致性和完整性。

库和表的命名规范

库名：ods，表示数据的贴源层。
表名：格式建议为ods_日期_业务表名，例如ods_2024_10_sales，便于管理和查询。

Hive表类型

在缓冲层中使用Hive的外部表管理数据，外部表的文件可以存储在非默认的HDFS路径中，这样当删除表定义时，实际存储文件不会被删除，保障数据安全。

业务表使用Hive的内部表，当删除表定义时，关联的HDFS文件也会被删除。此方式适合临时或不重要的数据存储，避免重要数据的误删。

DW数据仓库层

数据仓库层（DW层）是数据仓库设计的核心层，负责对来自贴源层（ODS层）的数据进行主题化建模，以支持高效的业务分析和决策。

DW层根据业务主题划分领域，为各主题构建清晰的数据视图，过滤掉无关决策的数据，专注于支持企业关键分析。

在该层，通常会存储业务系统的所有历史数据，例如保存10年以上的数据，为BI系统提供全面的历史数据支持。

数据分层模型设计

DW层采用维度建模，将维度表和事实表建立外键关联关系，以减少数据冗余、提高数据的组织效率。

维度模型不仅简化了业务分析的复杂性，还提升了DW层的数据易用性。在汇总数据层中，通过宽表设计将不同统计维度关联，建立高度复用的公共指标数据层，从而减少下游数据开发的重复劳动。

数据内容和结构

在DW层中，主要存储三类数据：

明细事实数据：基于ODS层的原始数据加工而成，包含业务过程中的细节信息。
维表数据：描述性数据（如客户信息、产品分类等），同样从ODS层加工生成。
公共指标汇总数据：基于维表和明细数据汇总而成，为业务分析提供标准化的核心指标。

DW层的细分

DW层通常进一步划分为三个子层：维度层（DIM）、明细数据层（DWD）和汇总数据层（DWS），并使用维度建模方法为数据设计结构，以确保高效的数据管理和访问：

维度层（DIM，Dimension）

维度层以业务维度为建模核心，根据每个维度的业务语义，定义维度属性和关联关系，形成标准化的数据分析维表。此层通过为各维度添加属性、定义关联关系等，明确计算逻辑，实现一致性的数据描述。为了避免在维度模型中出现冗余数据，维度表通常采用雪花模型结构，通过拆分属性表来减少数据重复，实现更加规范的维度建模。

明细数据层（DWD，Data Warehouse Detail）

明细数据层以具体的业务过程为核心进行建模，旨在捕捉业务活动的最细粒度信息，构建详细的事实表。这些事实表保留了业务过程的每一个细节，确保数据的完整性和精准性。

在实际设计中，对于一些关键的属性字段，可以适当进行冗余处理，即采用宽表化设计，以提升查询效率，减少多表关联带来的性能开销。这种做法在确保数据精细化的同时，兼顾了系统的易用性和高效性。

汇总数据层（DWS，Data Warehouse Summary）

汇总数据层（DWS）以分析主题为核心进行建模，围绕业务指标需求，构建标准化的汇总表，为上层应用提供一致的公共指标。

这一层基于宽表设计，将统计逻辑物理化，确保数据的命名规范和口径一致，从而支持高效的分析查询。汇总数据层包含多种主题的宽表和明细事实表，为业务提供统一的统计视角。

主题域：以业务过程为视角，将业务活动进行抽象和分类。例如，下单、支付、退款等事件可归类为不同的业务主题域，主要针对公共明细层（DWD）进行主题划分。
数据域：以分析需求为导向，将业务过程和维度进一步抽象，形成数据域。数据域划分在公共汇总层（DWS）中进行，用于满足各类业务分析需求。

层次结构与数据处理

DWD（Data Warehouse Details，数据明细层）：以业务过程为驱动，主要从ODS数据层抽取原始数据并进行清洗和规范化处理，确保数据的完整性和一致性。清洗内容包括去除空值、转换脏数据、枚举值统一、以及异常值过滤等。
DWS（Data Warehouse Base，数据基础层）：该层存储客观数据，主要作为中间层，为DWS层提供基础指标支持。可以视为大量中间指标的存储区，聚焦客观的业务事实。
DWS（Data Warehouse Summary数据服务层）：基于DWB中的基础数据，DWS层整合并汇总成以主题域为中心的宽表数据，用于OLAP分析、业务查询和数据分发。DWS的宽表设计适用于高效查询和聚合分析，满足各种业务部门的统计需求。

数据汇总和轻度聚合

汇总数据层在数据服务和分析场景中发挥关键作用。主要对ODS和DWD层的数据进行轻度聚合和汇总，确保数据粒度适用于业务需求，支持复杂分析和快速响应上层查询需求。

公共维度层（Dimension）

公共维度层（DIM）通过维度建模来构建企业的一致性维度，以确保在数据分析和计算过程中口径统一，避免因算法或指标不一致而引发的偏差。

维度层的主要目的是定义和标准化数据分析的基本属性，例如国家代码、地理位置、产品分类等。通过为所有业务共享的维表建立统一的结构和命名规范，DIM层成为业务数据的标准参照层。

公共维度层的构成

维表：维表是逻辑维度的物理实现，将每个维度及其属性具体化。为了提高查询效率和降低数据冗余，维表通常采用宽表设计原则。

高基数的维表（如用户、商品等）可能包含数百万甚至数亿条记录，而低基数的维表（如枚举配置、日期等）则记录数相对较少。

维度层的设计要点

1）维表设计原则在设计维表时，建议将单表的数据量控制在1000万条以内。对于高基数表，可采用Map Join操作优化查询性能。同时，避免频繁更新维表，针对缓慢变化的维度（如商品分类）可采用拉链表方式记录变更历史。

2）维表命名规范公共维度表命名通常以dim_开头，表示与具体业务无关、可以在各个业务模块中复用的维度。例如，公共区域表命名为dim_pub_area，商品表命名为dim_asale_item。这种命名规范便于识别表用途和主题，提高数据管理的清晰度。

3）粒度定义维度表中的数据粒度是业务过程的最小描述单位。例如，一条订单记录的粒度可能为“每次下单”。粒度可通过维度属性组合来描述，如“国家-城市-区县”组合用于表示地理位置的细节。粒度定义需精细，以满足后续分析需求。

维度建模步骤

选择业务过程选择业务系统中的关键业务过程（如下单、支付、物流等）进行建模。中小企业通常会选取所有业务过程，而大企业则聚焦于分析需求的主要业务线，以减少数据冗余和维护成本。
声明粒度粒度定义明确数据的细化程度。建议选择最小粒度，以支持更细粒度的指标计算。例如，在订单数据中，每个商品项代表一行数据记录，粒度为“每次下单”。保持细粒度可以灵活支持不同的统计需求，避免数据粒度过粗导致的信息丢失。
确定维度维度用来描述业务中的“谁、何处、何时”等信息，帮助分析不同维度的指标变化。例如，为支持订单量按时间、区域或用户的统计分析，需定义时间、地区和用户维度。维度表设计遵循星型模型原则，在必要时进行维度退化。
确定事实事实是业务中的度量数据，如订单金额、购买次数等。事实表中的每条记录反映某一业务活动的度量结果。通过宽表设计适当冗余重要字段，以提高查询效率。DWD层（数据明细层）以业务过程为驱动，而DWS层（汇总层）则是以需求为导向，与维度建模无直接关联。

主题、主题域与维度模型

主题数据仓库中的数据组织围绕不同的主题（如财务、销售、客户）展开。主题定义了数据仓库的主要分析方向，每个主题对应一个业务分析领域。例如，“财务分析”是一个主题，涵盖收入、支出、盈利等指标。
主题域主题域是多个相关主题的集合，便于数据的分层组织和分类管理。主题域的划分应由业务部门与数据仓库设计人员共同决定，考虑业务的关联性和分析需求。例如，销售主题域可包含订单分析、客户行为、广告投放等主题。

主题域划分原则

主题域的划分逻辑可以基于不同的业务需求或部门需求：

按业务过程：如电商平台可设立“广告域”、“客户域”等主题域，进一步分为“库存管理”、“销售分析”等具体主题。
按需求方：如财务部门的主题域可能包含“工资分析”、“投资回报分析”等内容。
按功能或应用：如“朋友圈域”可包含用户动态、广告数据等，适用于社交平台数据的主题划分。
按部门：如运营域、技术域，分别涵盖与各部门工作相关的主题（如运营域中的“活动效果分析”）。

主题域划分不必一次性完成，可采用迭代方式，从确定的主题开始逐步扩展，最终形成符合行业标准的主题模型。

数据明细层（Data Warehouse Detail）

数据明细层（DWD）是数据仓库和业务系统间的隔离层，主要用于提升数据的质量和一致性，确保存储的数据符合分析需求。

DWD层接收并清洗来自ODS层的原始数据，通过去噪、去重、脱敏等处理后，生成干净、准确的明细数据表，以支持业务分析。该层还会适度进行维度退化处理，将一些必要的维度字段直接存储在事实表中，以减少表关联，提高查询性能。

数据清洗与处理

DWD层的数据需要符合严格的数据质量标准，数据在装入前进行多种处理：

1、数据清洗

去除空值、脏数据：例如丢失关键字段（如订单ID为空）的记录、格式错误的数据。
敏感数据脱敏：对手机号、身份证等敏感信息进行加密或脱敏处理。
去除无效数据：如无时间戳的数据（视业务需求）。
会话切割：如针对App日志数据的场景，将用户进入后台再返回前台的操作分割为新的会话，方便后续行为分析。

2、数据映射与转换

地理位置映射：将GPS经纬度转换为省市区地址，采用geohash或IP地址转换库（如ip2region）进行快速定位，也可借助高德、百度地图API。
时间标准化：将时间戳转换为年、月、日、周、季度等信息。
数据规范化：对来自不同来源的数据进行格式统一，例如布尔值（0/1转换为true/false）、空值（统一为null）、日期格式（标准化为YYYY-MM-dd HH:mm:ss）。

3、维度退化

对于一些高基数的维度字段（如订单ID），直接存储在事实表中而不创建单独的维度表。这些退化维度可以简化数据结构，减少关联，提升数据查询的效率。

明细粒度事实表设计

DWD层以业务过程为核心进行建模，根据每个业务过程（如下单、支付、退款等）的特点，构建最细粒度的事实表。这些明细事实表保留了业务过程的全部细节，且一般会将一些常用的维度字段冗余存储，采用宽表设计以提升性能。这些事实表也被称为“逻辑事实表”。

数据质量控制

DWD层的数据粒度与ODS层保持一致，但在此基础上提供更严格的数据质量保证。DWD层还会适度进行维度退化，例如将商品类别的多级维度（如一级、二级、三级类别）或时间、地域等常用维度直接存储在事实表中，简化关联，提高数据的使用效率。

清洗比例：对于大数据量的数据，建议清洗掉低于0.01%的数据，如每万条记录中去除一条不合规数据。
表数量优化：通过合并相似数据，合理控制表数量，将过多的表精简为更易管理的结构。例如，将上万张表优化为三千张或一千张表，以便于后续的维护和扩展。

总结来说，DWD层在保持细粒度的前提下，提供规范化、清洗后的明细数据，为上层的业务应用和分析提供了干净、标准化的数据支撑。

这一层的优化和处理不仅提升了数据仓库的性能，还显著降低了数据冗余，提高了数据的可用性和易用性。

明细粒度事实表设计原则

单维度关联：每个明细粒度事实表只应与一个核心维度关联，保持数据模型简单、清晰。
业务过程相关性：仅包含与业务过程直接相关的事实数据，确保每个事实表准确反映其特定业务过程。
声明粒度：在定义维度和事实之前，必须先明确数据粒度，即一行数据代表的具体业务意义。
一致性和可加性：确保事实的单位一致，且尽量将不可加的事实分解为可加性组件，以支持更广泛的统计需求。
统一粒度：一个事实表中仅能包含单一粒度的事实数据，避免混合不同粒度的事实。
处理Null值：对Null值进行合理处理，以避免数据分析过程中产生意外结果。
退化维度应用：使用退化维度（如订单ID等高频维度）直接冗余存储在事实表中，以简化数据表关联，提升查询效率。

数据处理与存储方案

数据合成：采用全量合成策略，每天合并前天的全量数据和昨天的新增数据，生成一个新的数据表，覆盖旧表。同时，使用历史镜像按周、月或年存储快照。

日志存储方式：使用Impala的外部表和Parquet文件格式存储日志数据。建议在DWD层和下层数据均使用Impala内表，以实现更高效的静态或动态分区管理。

分区设计：默认按天创建分区。如果数据没有时间属性，可根据业务需求选择合适的分区字段。

库与表命名规范：库名为dwd，表名格式建议为dwd_日期_业务表名。对于增量表和全量表，用i表示增量，f表示全量。例如：

dwd_asale_trd_ordcrt_trip_di：表示A电商公司航旅机票订单下单的增量事实表，按日更新。
dwd_asale_itm_item_df：表示A电商公司商品快照的全量事实表，按日刷新。

明细粒度事实表设计示例

以交易商品信息事实表（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;

此表设计为按天分区，数据存储生命周期为400天，用于存储每日更新的商品交易信息。通过ds字段管理数据的时间分区，便于查询和管理。

数据服务层（Data Warehouse Service）

数据服务层（DWS）是基于数据明细层（DWD）构建的汇总层，面向特定业务主题，以宽表形式组织数据，支持分析和业务查询。该层的数据根据不同的主题和分析需求，通过对明细数据进行轻度聚合而成，减少维度数量，以便进行快速、高效的查询。

设计理念与结构

DWS层通过将DWD层的明细数据按主题域（如订单、用户、商品）进行汇总，为分析场景提供预处理的数据支持。数据粒度由细粒度提升至汇总粒度，以更适合多场景的业务查询需求。例如，按交易来源或类型对交易数据进行汇总，可以快速生成每天各主题的行为统计，如商品复购率、用户活跃度等。

特点和用途

面向主题：DWS层按业务主题划分数据，如销售、库存、客户等，生成覆盖多个指标的宽表。每张宽表通常包含较多字段，支持复杂的业务分析与数据分发。
少表宽表设计：DWS层表数量相对较少，每张宽表涵盖多个业务内容，减少表关联，提升OLAP分析和查询性能。
一致性整合：通过整合多个中间层数据（如DWD层），形成一致的企业级汇总事实表（如用户事实表、渠道事实表、终端事实表等），保证数据口径的一致性。

数据聚合与汇总示例

按天轻度汇总：基于DWD数据，对各主题对象（如购买行为）按天进行统计。例如，统计某商品的日复购率或销售额，方便后续的时间序列分析。
主题宽表示例：按照业务主题，生成具有较多字段的宽表，用于业务查询、OLAP分析等。例如，dws_sales_summary宽表可包含销售额、复购率、用户地域分布等字段。
多层次分析：以不同维度进行汇总，如最近一天特定类目（如厨具）商品在各省的销售总额，或者Top 10商品的销售额，支持灵活的多维分析。

场景应用与效率提升

通过汇总层的预聚合，DWS层可以满足80%的常见业务分析需求，减少直接查询ODS层的计算压力。例如，按7天、30天、90天等时间窗口的用户行为分析在DWS层中可以更加高效。

实时分析支持：对DWS层数据进行轻度汇总，有助于实现实时或准实时的用户画像、销售趋势分析等需求。
典型分析场景：如用户在不同时间段登录的IP及购买商品数量、各地区的购买力分布等。这些分析支持业务决策和营销策略调整。

命名和分区规范

表命名规范：建议DWS层表名以dws_主题_宽表描述命名，如dws_sales_summary或dws_user_activity.
分区设计：通常按天或周创建分区，便于时间序列查询；若无时间属性，则根据业务需求自定义分区字段。

通过DWS层的数据汇总与主题划分，企业可以在汇总宽表的基础上，迅速提取核心业务指标，为上层业务查询、报表和OLAP分析提供高效、结构化的数据支持。

数据服务层（DWS）职责与设计原则

DWS层（数据汇总层）基于DWD层的明细数据，按业务主题对数据进行聚合，以宽表形式存储，支持业务查询、OLAP分析和数据分发。

DWS层将多个DWD层表中分散的数据进行汇总，按主题整合到单一宽表中，例如用户、订单、商品、物流等。每张宽表涵盖相关主题的多个维度和指标字段，以满足业务方的多维度分析需求。

DWS层的核心任务

主题汇总将DWD层的明细数据按照业务主题进行聚合，创建单独的宽表。例如，在“用户”主题下，用户注册信息、收货地址和征信数据等内容可以整合到一张宽表中，方便后续的数据查询和分析。
主题建模针对特定业务主题，如流量、订单、用户，构建数据模型，将相关数据从DWD层抽取并聚合。DWS层提供的宽表通常按时间分层，如按天、月汇总的流量会话、每日新增用户、每日活跃用户等。
维度汇总提前将查询需求中的常用维度数据进行聚合处理。例如，将营销渠道、用户来源等维度数据提前整合，简化后续的查询逻辑。

设计规范

宽表设计DWS层通常为每个主题提供1至3张宽表，宽表覆盖多个业务指标，能够满足70%以上的业务需求。典型的宽表包括用户行为宽表、商品宽表、物流宽表和售后宽表等。其中，用户行为宽表是字段最丰富的，可能包含60至200个字段，以支持更全面的用户分析。
命名和分区规范
1. 命名：DWS层表名以dws_开头，后接业务主题和时间周期标识（如_1d代表每日汇总，_1w代表每周汇总）。
2. 分区：通常按天或小时创建分区（如_hh表示小时分区），如无时间维度，则根据业务逻辑选择分区字段。
3. 示例命名：
  1. dws_asale_trd_byr_subpay_1d：按买家粒度的交易分阶段付款每日汇总。
  2. dws_asale_trd_itm_slr_hh：按卖家粒度的商品小时汇总。
数据存储DWS层数据采用Impala内表和Parquet文件格式存储，具备高效的查询性能。一般以覆盖旧表的方式更新数据，定期生成历史快照用于数据存档和溯源分析。

典型的DWS宽表设计示例

用户维度宽表示例

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 '商品类目名称',
  confirm_paid_amt_sum_1d DOUBLE COMMENT '最近一天订单已确认收货的金额总和'
)
COMMENT '商品粒度交易最近一天汇总事实表'
PARTITIONED BY (ds STRING COMMENT '分区字段YYYYMMDD')
LIFECYCLE 36000;

ADS数据应用层

数据应用层（ADS，Application Data Store）用于存储个性化的统计指标和报表数据，为数据产品、业务应用和数据分析提供专门的数据支持。

ADS层的数据是高度汇总或定制化的数据集，覆盖流量、订单、用户等主题，以宽表形式存储，支持多维分析、查询、数据分发等。该层的数据粒度通常较粗，涵盖汇总数据和部分重要的明细数据，满足用户对近期数据的分析需求。

ADS层的核心功能

应用场景定制在DWS层基础上，面向应用场景进一步聚合数据，生成高定制化的宽表（如用户行为、订单趋势）。这些数据可以直接供业务系统调用或导入至应用系统（如MySQL、Redis、Druid）中，用于前端展示、实时查询和分析。
满足部门需求ADS层的数据按业务部门需求进行划分，仅包含与部门分析相关的数据子集。例如，流量数据集市提供流量分析指标，用户数据集市提供活跃度、转化率等用户行为数据，为业务方提供更直观的分析数据。
数据集市和宽表支持数据集市在ADS层按主题划分，如流量、订单、用户等，生成字段丰富的宽表。这些宽表汇总了各类业务指标和维度，支持多种分析需求，广泛用于OLAP分析、KPI展示和业务监控。

数据生成和存储方式

数据生成ADS层的数据源于DWD和DWS层，按业务需求从这些基础层数据中抽取并加工。ADS层表的数据更新频率依赖于业务需求，可以是每日或每小时刷新。
存储与分区使用Impala内表和Parquet格式存储ADS数据，按天或业务字段进行分区，以优化查询效率。对于没有时间属性的表，根据具体业务选择适当的分区字段。
表命名规范库名暂定为ads，表名格式建议为ads_主题_业务表名，按业务需求进行定制。

数据应用层示例

用户行为宽表用于存储用户的互动、消费等行为数据，包含各类用户活动信息，如评论、点赞、收藏、分享、GMV等字段。每张宽表大约包含60-200个字段，满足多维度的用户分析需求。

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 '取消关注商品',
  zhi_cnt BIGINT COMMENT '点赞次数',
  share_cnts BIGINT COMMENT '分享次数',
  bl_cnt BIGINT COMMENT '爆料数',
  gmv_amount BIGINT COMMENT '成交金额',
  gmv_sales BIGINT COMMENT '订单数'
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET;

商品销售汇总表

汇总商品的销售数据，按日或更细粒度进行存储，为分析商品的销售趋势、库存管理等提供支持。

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',
  confirm_paid_amt_sum_1d DOUBLE COMMENT '订单确认收货的金额总和'
)
PARTITIONED BY (ds STRING COMMENT '分区字段YYYYMMDD')
LIFECYCLE 36000;

常用分析指标与应用场景

用户活跃度
1. 日活、周活、月活：统计用户的活跃频率，通过设备ID计算不同时间范围内的活跃用户。
2. 留存率：统计新增用户的留存情况，计算1天、7天等时间范围内的用户留存率。
用户增长与回流
1. 新增用户：基于每日新增用户的统计。
2. 回流用户：分析在一段时间内回归活跃的用户数量。
用户转化与行为分析
1. 转化率：从商品详情到下单、支付的转化率。
2. 复购率：按用户或商品的复购情况统计，支持商品或品类的复购趋势分析。
商品分析
1. 销售额和GMV：按商品或品类计算销售额和GMV，分析热销产品。
2. Top N商品：计算销售排名前N的商品，支持流行度和消费偏好的分析。
用户留存与流失分析
1. 沉默用户：统计登录时间为7天前且登录频率极低的用户。
2. 流失用户：识别近期未登录或活跃度降低的用户，便于后续的用户运营和召回策略。

数据应用层的角色与更新策略

应用层角色ADS层主要面向业务方和数据产品团队，数据经过多层处理和汇总后直接支持报表、KPI、OLAP分析和仪表盘等应用。作为面向最终用户的数据集市，ADS层能够快速响应业务需求。
更新方式旧数据通常采用覆盖更新，按业务需求定期刷新，确保数据时效性。

临时表支持

TMP层数据处理过程中常需临时表以支持复杂计算，ADS层提供独立的TMP层（DW TMP）用于存储这些中间计算结果，避免主数据表的反复更新，提高数据处理的效率和稳定性。

通过ADS层的数据集市和宽表设计，企业能够更灵活地支持多种数据产品和分析需求，为业务增长、用户行为分析、市场洞察等提供强有力的数据支撑。

层次调用规范

在数据仓库分层架构中，必须遵循严格的调用规范，以确保数据流动的单向性，避免复杂的依赖关系和反向调用。

禁止反向调用：下层数据不可调用上层数据，保持数据流向的单向性和清晰性。
调用规范：
- ODS层：仅允许被DWD层调用。
- DWD层：允许被DWS和ADS层调用。
- DWS层：仅允许被ADS层调用。
- ADS层：可调用DWD、DWS及其他ADS表，但建议优先使用汇总度更高的数据，以减少数据冗余和性能消耗。

调用路径概述

数据的标准调用路径包括：

ODS -> DWD -> DWS -> ADS
ODS -> DWD -> ADS

数据仓库技术趋势与小结

数据仓库分层架构为企业构建了高效、稳定的海量数据管理体系，支持数据治理、业务逻辑隔离、数据追踪和复用。通过ODS、DWD、DWS和ADS的分层设计，数据在逐层传递和加工中实现标准化和清洗，确保了一致性和数据可追溯性。

这一架构不仅提高了数据使用的规范性，还降低了系统耦合，提升了数据共享的便捷性。

ODS层：作为原始数据接入层，ODS层负责保留细粒度数据，通过ETL或CDC方式捕获源系统的变更数据，确保数据完整性。
DWD层：标准化数据并进行清洗和脱敏，去除冗余，确保数据一致性，为后续分析和建模提供了基础。
DWS层：将DWD数据聚合为符合业务主题的宽表，构建面向主题的数据服务，优化计算性能并促进数据复用。
ADS层：进一步聚合数据，生成高性能、面向应用的宽表，支持数据产品和业务应用场景，如OLAP分析、KPI监控和仪表盘展示。

随着数据规模和数据源的多样化，数据仓库的架构和技术也在不断演进，当前的主要趋势包括：

实时数据处理与CDC技术传统的批量数据处理已经无法满足现代企业的需求，CDC技术成为数据实时同步和更新的主流方法，确保数据仓库中数据的实时性。
数据湖与数据仓库的融合数据湖（Data Lake）与数据仓库的融合正在成为行业的热门趋势，例如Data Lakehouse架构，将数据湖的灵活性与数据仓库的高效分析能力相结合，为企业提供更强的数据管理能力。
DataOps与自动化数据管理随着企业对数据管理自动化要求的提高，DataOps逐渐成为数据管理的核心工具。例如，白鲸开源的DataOps工具能够实现从数据采集到数据质量控制的全流程自动化管理。

结合新一代数据湖仓（Hudi、Iceberg、GaussDB、Redshift、Greenplum、Doris、Starrocks、偶数、PieDB、MatrixDB等）配合白鲸开源的DataOps工具，可以快速根据本文的设计实践建立起批流一体的数据湖仓。

整体上，无论是湖、仓、实时数仓、都要遵循分层设计架构明确了各层的调用边界，禁止反向调用，确保数据流动顺畅，降低了系统复杂度。

白鲸开源的WhaleStudio以DolphinScheduler和SeaTunnel为基础，增加大量商业版功能，全面支持数据仓库分层的批流数据的集成与数据开发，在中国银行、中信证券、中信建投证券、中国人保、中国人寿、旺旺集团等都有实际DataOps案例，并全面替换Informatica和Talend等传统ETL工具。

为当前业务和未来扩展提供了稳定、高效的数据支持。结构化的数据流转路径为企业的数字化转型和数据驱动决策提供了强有力的支持，推动业务的智能化和数据化发展。