数仓分层与维度建模提示词（ODS、DWD、DWS、ADS 各层放什么，事实表与维度表设计，缓慢变化维处理）
要从零搭建数据仓库、或者现有数仓表越建越多、口径混乱、同一个指标在十张表里算法不同时用：描述业务流程和数据源，AI 设计分层架构，确定每个业务过程的事实表粒度与维度表，处理维度的历史变化，并给出表命名规范和建表语句。
通用大模型 对话模型通用
你是一名有多年经验的数据仓库架构师，熟悉维度建模。请帮我设计数据仓库模型。 - 业务领域：[业务领域]（例：电商，包括下单、支付、发货、退款、评价） - 数据源：[数据源]（例：业务库 MySQL 的订单、商品、用户表，App 埋点日志） - 主要的分析需求：[分析需求]（例：每日销售报表、用户复购分析、商品排行） - 计算与存储引擎：[计算引擎]（例：Hive、Spark、云数仓） - 团队规模与现状：[团队现状]（例：2 名数据开发，目前直接从业务库拉数） 请输出： 1. 分层架构：每一层的职责、数据保留策略和命名前缀： - ODS：与源系统保持一致的原始数据，增量或全量同步方式； - DWD：清洗后的明细事实，统一编码、口径和类型； - DIM：公共维度； - DWS：按主题和常用粒度的轻度汇总； - ADS：面向具体报表与应用的结果。 说明在团队规模较小时可以合并或省略哪些层。 2. 业务过程与总线矩阵：列出业务过程（下单、支付等）与维度（日期、用户、商品、地区、渠道）的对应关系表。 3. 事实表设计：每个业务过程的粒度（一行代表什么，必须明确）、度量（可加、半可加、不可加）、退款等「负向」业务如何记录；事务事实表、周期快照、累积快照的选择。 4. 维度表设计：维度属性的选取；维度变化的处理方式（直接覆盖，或保留历史版本并记录生效时间），给出需要保留历史的典型属性（例如用户等级、商品类目）。 5. 规范：表命名、字段命名、分区方式（例如按日期分区）、公共字段（数据日期、更新时间）。 6. 建表语句：给出一张事实表和一张需要保留历史的维度表的完整建表语句，以及维度表每日更新的逻辑。 7. 落地顺序：先建哪些表能最快支持最重要的报表。
高亮处换成你自己的内容：[业务领域]、[数据源]、[分析需求]、[计算引擎]、[团队现状]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[分析需求] 决定先建什么，不要为了「完整」一次性建几十张表。[团队现状] 很重要：两三个人的团队维护完整的五层架构负担很重，可以先合并部分层次。
常见坑：
- 事实表的粒度没有定清楚，一张表里既有订单级数据又有商品明细级数据，汇总时金额被重复计算。
- 用户等级、商品类目这类会变化的属性直接覆盖，回看历史时只能看到现在的等级，历史分析全部失真。
- 每个报表需求都从明细层单独算一遍，同一个指标出现多种口径。常用的指标沉淀到汇总层统一计算。
追问技巧：追问「把现有的这 20 张报表用到的表梳理一遍，找出可以合并或重复计算的地方」，或「给这个模型补充数据质量校验规则」（可配合 1129 号提示词）。
示例输出
示例，仅供参考（事实表设计节选）
| 业务过程 | 事实表 | 粒度 | 主要度量 | 类型 |
|---|---|---|---|---|
| 下单 | dwd_trade_order_item | 每个订单中的每个商品一行 | 购买数量、商品原价、优惠分摊金额 | 事务事实表 |
| 支付 | dwd_trade_payment | 每笔支付流水一行 | 支付金额 | 事务事实表 |
| 订单全流程 | dwd_trade_order_lifecycle | 每个订单一行，记录下单、支付、发货、签收时间 | 各环节耗时 | 累积快照 |
sql
-- 需要保留历史的用户维度表：每个版本一行，记录生效与失效日期
CREATE TABLE dim_user_history (
user_id BIGINT,
user_level STRING,
city STRING,
start_date STRING COMMENT '版本生效日期',
end_date STRING COMMENT '版本失效日期，当前版本为 9999-12-31'
)
PARTITIONED BY (dt STRING);同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～