數倉分層與維度建模提示詞（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 條評論
還沒有評論，來搶沙發～