|
|
@@ -2,8 +2,7 @@
|
|
|
|
|
|
> `poyee-data-warehouse` 数据仓库工程的模块划分、执行时序与配置管理。
|
|
|
|
|
|
-**项目状态**：目前采用**原地渐进式重构**模式。项目根目录当前物理路径为 `tendata-warehouse-release/`（老项目名），将在重构过程中逐步改造为 `poyee-data-warehouse/`。下方目录结构是**目标态**（重构完成后应当长成的样子），不是当前态。当前态请直接查看项目根目录。
|
|
|
-
|
|
|
+**项目状态**：重构中，目前采用**原地渐进式重构**模式。
|
|
|
## 1. 目录结构（目标态）
|
|
|
|
|
|
```
|
|
|
@@ -476,35 +475,28 @@ python3 bin/datax-gc-generator.py --from hdfs --to elasticsearch \
|
|
|
数仓分层与 `jobs/` 目录一一对应：
|
|
|
|
|
|
```
|
|
|
- ┌─────────────┐
|
|
|
-┌─────────────────────────────────────────┐ │ │
|
|
|
-│ ADS (Application Data Service) ads/ │ │ │
|
|
|
-│ 应用层：面向产品的宽表 + 导出到服务层 │ │ │
|
|
|
-├─────────────────────────────────────────┤ │ │
|
|
|
-│ TDM (Theme Data Model) tdm/ │ │ DIM │
|
|
|
-│ 标签层：长表明细+宽表服务+人群包圈选 │ │ │
|
|
|
-├─────────────────────────────────────────┤ │ jobs/dim/ │
|
|
|
-│ DWS (Data Warehouse Service) dws/ │◄─┤ │
|
|
|
-│ 汇总层：聚合统计 │ │ 公共维度 │
|
|
|
-├─────────────────────────────────────────┤ │ 贯穿 │
|
|
|
-│ DWD (Data Warehouse Detail) dwd/ │◄─┤ dwd/dws/ │
|
|
|
-│ 明细层：清洗加工 + 维度退化 │ │ tdm/ads │
|
|
|
-├─────────────────────────────────────────┤ │ │
|
|
|
-│ ODS (Operational Data Store) ods/ │ │ │
|
|
|
-│ 贴源层：类型转换、空值处理、脏数据识别 │ │ │
|
|
|
-├─────────────────────────────────────────┤ │ │
|
|
|
-│ RAW (Raw Data) raw/ │ │ │
|
|
|
-│ 原始数据采集：全字段 STRING，原样落盘 │ │ │
|
|
|
-└─────────────────────────────────────────┘ └─────────────┘
|
|
|
+ ┌────────────┐
|
|
|
+┌───────────────────────────────────────────┐ │ │
|
|
|
+│ ADS 应用层：业务指标、服务端导出宽表 │ │ │
|
|
|
+├───────────────────────────────────────────┤ │ │
|
|
|
+│ TDM 标签层：长表明细 + 宽表 + 人群包 │◄──┤ DIM │
|
|
|
+├───────────────────────────────────────────┤ │ │
|
|
|
+│ DWS 汇总层：主题聚合、提供公共指标 │◄──┤ 公共维度 │
|
|
|
+├───────────────────────────────────────────┤ │ │
|
|
|
+│ DWD 明细层：清洗加工 + 维度退化 │◄──┤ │
|
|
|
+├───────────────────────────────────────────┤ │ │
|
|
|
+│ ODS 贴源层：类型转换、脏数据识别 │ │ │
|
|
|
+├───────────────────────────────────────────┤ └────────────┘
|
|
|
+│ RAW 采集层：全字段 STRING，原样落盘 │
|
|
|
+└───────────────────────────────────────────┘
|
|
|
|
|
|
数据流向：
|
|
|
- MongoDB/MySQL/ClickHouse ──DataX(raw)──> RAW(Hive)
|
|
|
- RAW ──SparkSQL(ods)──> ODS ──SparkSQL(dwd)──> DWD
|
|
|
- DWD ──SparkSQL(dws)──> DWS ──SparkSQL(tdm)──> TDM ──SparkSQL(ads)──> ADS
|
|
|
- ADS ──DataX/BrokerLoad──> Doris/ClickHouse/ES/MongoDB（服务层）
|
|
|
+ PG / ES ──DataX(raw)──▶ RAW ──SparkSQL(ods)──▶ ODS ──SparkSQL(dwd)──▶ DWD
|
|
|
+ DWD ──SparkSQL(dws)──▶ DWS ──SparkSQL(tdm)──▶ TDM ──SparkSQL(ads)──▶ ADS
|
|
|
+ ADS ──DataX / BrokerLoad──▶ 服务层（Doris / ClickHouse / ES / MongoDB）
|
|
|
```
|
|
|
|
|
|
-**jobs/ 目录内部组织建议：**
|
|
|
+**jobs/ 目录内部组织：**
|
|
|
|
|
|
每个分层目录内部按**业务域代码**（见 `21-命名规范.md` §3.2，`trd`/`usr`/`prd`/`shp`/`pub`/`dim`）建子目录，每个业务域下放置具体的 ini 或 SQL 文件。样板见 `00-项目架构.md` §9。
|
|
|
|
|
|
@@ -532,11 +524,6 @@ jobs/
|
|
|
|
|
|
**原则**：同一业务（如订单）的数据在不同分层之间纵向流转，`trd/` 这一业务域在 raw/ods/dwd/dws/tdm/ads 各层都会出现。
|
|
|
|
|
|
-**关于 dim**：dim 与其他分层并列，作为顶层独立目录 `jobs/dim/`，**不**塞在 `jobs/ods/dim/` 下。原因：
|
|
|
-- 维度的生命周期独立于 ods（典型场景：日历表手工 init 一次，年度增量；汇率每日刷一次）
|
|
|
-- 下游 dwd/dws/tdm/ads 都直接 JOIN dim，是平级被引用关系，不是包含关系
|
|
|
-- dim 自己也分业务域（pub/usr/prd/shp），与其他层的二维结构一致
|
|
|
-
|
|
|
## 6. 配置管理体系
|
|
|
|
|
|
### 6.1 配置分类
|
|
|
@@ -718,24 +705,17 @@ bin/datax-multiple-hive-job-starter.sh -gcd jobs/raw/trd -start-date 20260415 -e
|
|
|
|
|
|
**核心原则：DDL 与计算 SQL 物理分离，DDL 全部在 `manual/ddl/` 下单一来源。**
|
|
|
|
|
|
-- `manual/ddl/` 存放**所有 DDL**（首次建表 + 后续 ALTER），采用 **migration 模式**：每次 DDL 操作是一个不可变文件，**绝不回头改老文件**
|
|
|
+- `manual/ddl/` 存放**所有 DDL**（首次建表 + 后续 ALTER），采用 **migration 模式**：每次 DDL 操作是一个不可变文件，**禁止回头改老文件**
|
|
|
- `jobs/` 存放每日调度执行的采集 / 计算任务，只做 `INSERT OVERWRITE` 或数据同步，不写 CREATE TABLE
|
|
|
-- 不存在第二个 ddl 目录，避免"两套 DDL 同步维护"的负担
|
|
|
+
|
|
|
|
|
|
一张表的完整生命周期涉及：
|
|
|
-- `manual/ddl/{表名}.sql` —— 首次建表，永久保留
|
|
|
-- 若干 `manual/ddl/{yyyymmdd}_{表名}_{change}.sql` —— 之后每次 ALTER，独立文件
|
|
|
+- `manual/ddl/{表名}_create.sql` —— 首次建表，永久保留
|
|
|
+- 若干 `manual/ddl/{表名}_{yyyymmdd}_{描述}_change.sql` —— 之后每次 ALTER，独立文件
|
|
|
- `jobs/{layer}/{domain}/{表名}.sql` —— 每日调度的计算 SQL（不含建表）
|
|
|
|
|
|
### 9.1 `manual/ddl/` —— DDL 唯一来源
|
|
|
|
|
|
-**两类文件**：
|
|
|
-
|
|
|
-| 文件类型 | 命名 | 生命周期 | 幂等 |
|
|
|
-|---|---|---|---|
|
|
|
-| 首次建表 | `{表名}.sql`（无日期前缀） | 永久保留，不归档 | `CREATE TABLE IF NOT EXISTS`（幂等） |
|
|
|
-| 后续 ALTER | `{yyyymmdd}_{表名}_{change}.sql`（带日期前缀） | 执行后保留 3-6 月，归档到 `manual/ddl/archive/` | `ALTER TABLE`（非幂等） |
|
|
|
-
|
|
|
**目录组织**：扁平存放，不再按 `{layer}/{domain}/` 分子目录 —— 因为每张表只在 `manual/ddl/` 出现一次（外加若干 ALTER 文件），扁平就够用。`grep dwd_trd_ manual/ddl/` 一行命令就能列出某表的所有 DDL 历史。
|
|
|
|
|
|
```
|
|
|
@@ -758,7 +738,7 @@ manual/ddl/
|
|
|
-- 业务含义：交易域-订单支付明细-增量-日
|
|
|
-- 分层：DWD
|
|
|
-- 更新周期：日 / 增量
|
|
|
--- 负责人：zhu_tianyu
|
|
|
+-- 负责人：tianyu.chu
|
|
|
-- 创建日期：2026-xx-xx
|
|
|
-- 工单：TPAD-1001
|
|
|
-- 状态：已执行 2026-xx-xx
|
|
|
@@ -773,8 +753,7 @@ CREATE TABLE IF NOT EXISTS dwd.dwd_trd_order_pay_inc_d (
|
|
|
etl_time TIMESTAMP COMMENT 'ETL写入时间'
|
|
|
) COMMENT '交易域-订单支付明细-增量-日'
|
|
|
PARTITIONED BY (dt STRING COMMENT '日期分区 yyyyMMdd')
|
|
|
-STORED AS ORC
|
|
|
-TBLPROPERTIES ('orc.compress'='NONE');
|
|
|
+STORED AS ORC;
|
|
|
```
|
|
|
|
|
|
**ALTER 文件模板**（`manual/ddl/20260520_dwd_trd_order_pay_add_refund.sql`）：
|
|
|
@@ -782,7 +761,7 @@ TBLPROPERTIES ('orc.compress'='NONE');
|
|
|
```sql
|
|
|
-- ============================================================
|
|
|
-- 表名：dwd.dwd_trd_order_pay_inc_d
|
|
|
--- 作者：zhu_tianyu
|
|
|
+-- 作者：tianyu.chu
|
|
|
-- 日期：2026-05-20
|
|
|
-- 工单：TPAD-1234
|
|
|
-- 目的：加 refund_amt_cny 字段（业务上线退款流程）
|
|
|
@@ -797,7 +776,7 @@ ADD COLUMNS (
|
|
|
);
|
|
|
```
|
|
|
|
|
|
-**存储格式约定**：所有分层一律 `STORED AS ORC` + `orc.compress=NONE`（不压缩，放弃一部分磁盘换 CPU、查询速度与 debug 友好度）。
|
|
|
+**存储格式约定**：所有分层一律 `STORED AS ORC` （不压缩，放弃一部分磁盘换 CPU、查询速度与 debug 友好度 ,后期做冷热数据再考虑压缩）。
|
|
|
|
|
|
### 9.2 `jobs/` 层 —— 每日调度的计算 SQL
|
|
|
|
|
|
@@ -821,7 +800,7 @@ jobs/dwd/trd/
|
|
|
-- - ods.ods_trd_order_pay_inc_d
|
|
|
-- - dim.dim_prd_product_ful_d
|
|
|
-- 下游使用：dws_trd_order_agg_inc_d、ads_trd_gmv_d
|
|
|
--- 负责人：zhu_tianyu
|
|
|
+-- 负责人：tianyu.chu
|
|
|
-- 创建日期：2026-xx-xx
|
|
|
-- ============================================================
|
|
|
|
|
|
@@ -873,7 +852,7 @@ raw 层的 `jobs/` 有两类主要任务，根据源数据形态选择：
|
|
|
-- 编码 UTF-8 / 带表头 / 逗号分隔 / 双引号 quote / 字段内允许换行
|
|
|
-- 执行器：bin/csv-to-hdfs-starter.py
|
|
|
-- 暂存路径：/tmp/csv_staging/raw_trd_legacy_order_his_o/
|
|
|
--- 负责人：zhu_tianyu
|
|
|
+-- 负责人：tianyu.chu
|
|
|
-- 创建日期：2026-xx-xx
|
|
|
-- 状态：[待执行]
|
|
|
-- 备注：CTAS 语法一次性建表 + 写入，无需在 manual/ddl/ 单独写 CREATE TABLE
|
|
|
@@ -1002,12 +981,8 @@ jobs/ads/trd/
|
|
|
|
|
|
当要给某张表加列 / 改字段时，**只写新文件，不改老文件**：
|
|
|
|
|
|
-1. 在 `manual/ddl/{yyyymmdd}_{表名}_{change}.sql` 写 ALTER 语句（带工单号、目的、回滚方案）
|
|
|
-2. 如果字段参与了 `jobs/` 里的计算 SQL，一并更新 `jobs/{layer}/{domain}/{表名}.sql` 的 `SELECT` 列表
|
|
|
-3. 执行完毕后，把这个 ALTER 文件移到 `manual/ddl/archive/`
|
|
|
+在 `manual/ddl/{yyyymmdd}_{表名}_{change}.sql` 写 ALTER 语句（带工单号、目的、回滚方案）
|
|
|
|
|
|
-**为什么不去改原始的 `manual/ddl/{表名}.sql`**：
|
|
|
-- 强行同步两份会让"DDL 唯一来源"形同虚设，增加双写出错概率
|
|
|
- ALTER 文件按时间前缀线性堆叠，`grep dwd_trd_order_pay manual/ddl/` 即可看到该表的全部 DDL 历史，按文件名时间序回放就是表结构的完整演化
|
|
|
-- 真要在新环境重建这张表，按时间顺序把 `manual/ddl/{表名}.sql` + 所有相关 ALTER 文件依次执行即可，结果和生产一致。**注意**：目前没有自动化重放工具，需要人手按文件名时间序执行；未来视需要可以写一个 `bin/replay-ddl.sh`（当前未实现，**不要假设它存在**）
|
|
|
+- 真要在新环境重建这张表，按时间顺序把 `manual/ddl/{表名}.sql` + 所有相关 ALTER 文件依次执行即可，结果和生产一致。**注意**：目前没有自动化重放工具，需要人手按文件名时间序执行；未来视需要可以写一个 `bin/replay-ddl.sh`（当前未实现）
|
|
|
- 这是数据库 migration 工具（Flyway / Alembic / Liquibase）的标准做法，已被工业界验证
|
