利用数据库中的 Table(表) 来实现数据仓库,本质上就是用表来组织、存储和管理面向分析的数据,并通过合理的建模、分层和加载机制,把业务系统数据转化为可用于决策分析的数据资产。下面从总体思路、分层设计、表的设计方式、ETL 实现、示例几个方面系统说明。
数据仓库 ≠ 多张表
而是:
以“表”为载体,按主题组织历史数据,支持分析查询
核心原则:
一个典型的数据仓库会使用多组表,按功能分层:
作用:几乎原样保留业务系统数据
表特点:
示例:
ods_order
ods_user
ods_payment
作用:清洗、统一、规范化后的明细数据
表特点:
示例:
dwd_order_detail
dwd_user_info
dwd_payment_record
作用:面向分析主题的轻度汇总
表特点:
示例:
dws_order_by_day
dws_user_order_stat
dws_sales_by_region
作用:直接用于报表、BI、接口
表特点:
示例:
ads_daily_sales_report
ads_user_retention
ads_top_products
用于记录业务过程
特点:
示例:
fact_order
----------------
order_id
user_id
product_id
order_date
amount
quantity
用于描述业务属性
特点:
示例:
dim_user
----------------
user_id
user_name
gender
city
register_date
dim_product
----------------
product_id
product_name
category
brand
dim_user
|
fact_order --+-- dim_product
|
dim_date
维度表再拆分子维度表:
dim_product
└── dim_category
适合对数据一致性要求极高的场景。
全量示例
INSERT INTO ods_order
SELECT * FROM src_order;
增量示例
INSERT INTO dwd_order_detail
SELECT *
FROM ods_order
WHERE update_time > last_load_time;
按时间分区,提高性能
CREATE TABLE dwd_order_detail (
order_id INT,
order_date DATE
)
PARTITION BY RANGE (order_date);
用于记录维度历史状态:
dim_user
----------------
user_id
user_name
city
start_date
end_date
is_current
fact_order
----------------
order_id
user_id
product_id
order_date
payment_amount
dim_user(user_id, gender, city)
dim_product(product_id, category)
dim_date(date, year, month, day)
dws_sales_by_day
----------------
day
total_orders
total_amount
❌ 把表当业务表用
❌ 不做分层,所有数据堆一张表
❌ 事实表里放描述性字段
❌ 没有时间维度
❌ 不做历史数据管理
用 Table 实现数据仓库,就是用分层表 + 事实表 + 维度表 + ETL 规则,把业务数据组织成面向分析的数据模型。
如果你愿意,我可以帮你:
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。