Pārlūkot izejas kodu

docs(kb/27+28): 品类字段 sport→category(lv2,lv1 main_category 留 2 期)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tianyu.chu 19 stundas atpakaļ
vecāks
revīzija
3ac6368ab5
3 mainītis faili ar 12 papildinājumiem un 9 dzēšanām
  1. 3 3
      kb/27-dwd建模.md
  2. 8 6
      kb/28-dim建模.md
  3. 1 0
      kb/92-重构进度.md

+ 3 - 3
kb/27-dwd建模.md

@@ -51,10 +51,10 @@ WHERE order_type = 'group'
 
 | 字段来源 | 退化字段 |
 |---|---|
-| `dim_trd_card_group_ful_d`(拼团 → 品类)| `sport` / `manufacturer` / `sets` / `year` / `list_id` / `panini_list_id` / `group_name` |
+| `dim_trd_card_group_ful_d`(拼团 → 品类)| `category` / `manufacturer` / `sets` / `year` / `list_id` / `panini_list_id` / `group_name` |
 | `card_group_order_info` 自有 | 其他业务字段直存 |
 
-DWD 不二次清洗 sport(`dim_trd_card_group_ful_d` 已归一脏数据)。**不带大类 `first_sport`**(业务侧定:拼团大类即 `sport` 叶子,大类聚合按需在上层做)。
+DWD 不二次清洗 category(`dim_trd_card_group_ful_d` 已归一脏数据)。**不带大类 `main_category`**(业务侧定:拼团大类 lv1 业务库原名 `first_sport`,1 期不引,2 期再讨论)。
 
 ### 2.5 accounts_payable_cny 派生规则
 
@@ -83,7 +83,7 @@ END AS accounts_payable_cny
 | 拼团维度退化 | group_name | STRING | dim_trd_card_group | 拼团名称 |
 | 拼团维度退化 | list_id | BIGINT | dim_trd_card_group | 商家上线 checklist id(业务库快照冗余)|
 | 拼团维度退化 | panini_list_id | BIGINT | dim_trd_card_group | 帕尼尼 list id(业务库快照冗余)|
-| 拼团维度退化 | sport | STRING | dim_trd_card_group | 运动品类(DIM 已清洗,权威源)|
+| 拼团维度退化 | category | STRING | dim_trd_card_group | 品类(lv2,DIM 已清洗,权威源)|
 | 拼团维度退化 | manufacturer | STRING | dim_trd_card_group | 厂商 |
 | 拼团维度退化 | sets | STRING | dim_trd_card_group | 系列 |
 | 拼团维度退化 | year | STRING | dim_trd_card_group | 年份(赛季)|

+ 8 - 6
kb/28-dim建模.md

@@ -106,17 +106,19 @@ ODS 跨 dt 不去重 → 同 pk 多分区并存 → DIM 取每个 pk 的最新
 
 `card_group_info`(拼团信息),承载"商家上架的拼团活动"实体。订单 → 品类的归属通过本表 `sport` 字段取得。
 
-### 3.2 sport 脏数据清洗
+### 3.2 category 字段(命名 + 脏数据清洗)
 
-**业务依据**:拼团可上单个产品,也可组合多个产品(可能跨类);以商家设置的拼团大类(`cgi.sport`)为准聚合最贴近业务侧分析口径,因此 `sport` 取自拼团表本身,不通过底层产品表(panini / checklist)反查
+**字段命名**:业务库原字段 `card_group_info.sport` → 数仓字段名 `category`(lv2 叶子品类)。按 `kb/21 §1` 一词一义原则,业务库 sport 实际已多义(16 个值里含"影视收藏 / 综合收藏 / 综合体育"等非 sport 语义),数仓字段改用中性的 `category`。lv1 大类(业务库 `first_sport`,1 期不引)未来引入时命名为 `main_category`
 
-**清洗规则**(DIM 内置,下游直引):
+**业务依据**(取自拼团粒度而非产品粒度):拼团可上单个产品,也可组合多个产品(可能跨类);以商家设置的拼团大类(`cgi.sport`)为准聚合最贴近业务侧分析口径,因此 `category` 取自拼团表本身,不通过底层产品表(panini / checklist)反查。
 
-| 原值 | 清洗后 |
+**清洗规则**(DIM 内置,下游直引 `category`):
+
+| 原值(cgi.sport)| 清洗后(category)|
 |---|---|
 | `mlb` | `MLB` |
 | `Boxing` | `UFC` |
-| `other` | NULL(聚合时 `WHERE sport IS NOT NULL` 过滤)|
+| `other` | NULL(聚合时 `WHERE category IS NOT NULL` 过滤)|
 | 其他 | 原值保留 |
 
 ### 3.3 字段表
@@ -134,7 +136,7 @@ ODS 跨 dt 不去重 → 同 pk 多分区并存 → DIM 取每个 pk 的最新
 | 商品关联 | list_id | BIGINT | | 商家上线 checklist id |
 | 商品关联 | list_code | STRING | | checklist code |
 | 商品关联 | panini_list_id | BIGINT | | 帕尼尼 list id(业务库快照冗余)|
-| 分类 | sport | STRING | | 运动类型(含 §3.2 脏数据清洗)|
+| 分类 | category | STRING | cgi.sport | 品类(lv2,含 §3.2 脏数据清洗)|
 | 分类 | year | STRING | | 年份(赛季)|
 | 分类 | manufacturer | STRING | | 厂商 |
 | 分类 | sets | STRING | | 系列 |

+ 1 - 0
kb/92-重构进度.md

@@ -178,6 +178,7 @@
 | 2026-04-21 | **聚簇 B.1 `__init__.py` 瘦身(修剪式,不拆 `core/`)**:`dw_base/__init__.py` 从 127 行 → 83 行。三处删除:(a) `import findspark` + `findspark.init()` —— 查证 3 条事实后安全删:findspark 全仓仅此 2 处引用;入口全走 `python3 xxx.py`(非 `spark-submit`),`SPARK_HOME` 从未被代码注入,findspark 在 CDH 节点上 `which spark-submit → readlink -f` 反推出 parcel `$SPARK_HOME` 把 `$SPARK_HOME/python` 前插进 sys.path,但 pip pyspark 2.4.0 和 parcel pyspark 2.4.0 同版本,业务表现零差异(见里程碑 `datax+spark-smoke-2026-04-20` 冒烟链路,HMS 真正入口是 `SPARK_CONF_DIR=/etc/spark/conf/hive-site.xml`,与 findspark 无关);(b) 删 21 个外部零引用的颜色常量 —— `CHG_BOLD` / `NORM_BLU` / `NORM_WHT` / 7×`BOLD_*` / 7×`BGRD_*`(if/else 两分支同步删),保留实际被引用的 6 个(`DO_RESET` / `NORM_RED` / `NORM_GRN` / `NORM_YEL` / `NORM_MGT` / `NORM_CYN`);(c) 删 `IS_RUN_BY_NORMAL_USER` 状态变量(两处赋值外部无引用,仅内部 `elif` 分支走到时为 `True`,无消费者)。**不拆 `core/*` 的理由**:findspark 去掉后"懒加载"诉求大半消失,拆分需改 11 处调用点 import,ROI 低;py/sh 颜色双份是运行时分家的必然(跨 runtime 单源化要加 subprocess 解析,得不偿失),真冗余只是 py 侧定义超过实际被用的部分。联动:`requirements.txt:3` 删 `findspark==2.0.1`;`tests/README.md:26` findspark 段改写为 HMS 入口说明;`kb/00 §1` `__init__.py` 行注释去 findspark;`kb/90 §三` 改写为"已完成 · 修剪式"并附未拆 `core/` 的理由;`kb/90 §7.1` KEEP 行去 findspark + 末尾 TODO 行改写为"已删除" | — |
 | 2026-04-22 | **勘误:移除 "SQL SET 资源类参数不生效" 的错误表述**:A.4 落地时误把 "`SparkSession.conf.set()` 对已启动 session 不改变资源" 这条 Spark 固有行为类推到"SQL 里的 SET"。实际 `spark_sql.py:query()` L433-440 对 SQL 内 `SET spark.*` 做预扫描,在 session 启动前塞进 `_final_spark_config`,`__init_spark_session` 通过 `builder.config()` 写入后才 `getOrCreate()`——**资源类 SET 同样生效**。清理 4 处错误:`dw_base/spark/spark_sql.py:155` 注释、`conf/spark-tuning.conf` L6-7 注意段、`kb/90 §2.3` "落地坑"段 + L2 行括号、本文 L74 基于错误前提的验证项 | — |
 | 2026-05-09 | **kb/27-dwd建模.md + kb/28-dim建模.md 新建(用户标签 1 期建模落地)**:基于 tdm.md 标签清单(用户属性 7 个 + 16 品类 × 3 窗口 × 2 度量)倒推得 3 张表。kb/27 含 `dwd_trd_order_pay_apd_d`(订单支付明细,业务过程定义 / 粒度 / `payment_success_time` 业务时间分区 / 维度退化字段来源 / `accounts_payable_cny` 含 `point_type LIKE 'mer_act%'` 时除 100 的换算规则 / 字段表);kb/28 含 `dim_usr_user_ful_d`(base_user LEFT JOIN cert_info,性别/生日仅取 cert)与 `dim_trd_card_group_ful_d`(拼团维度,`sport` 内置脏数据清洗 mlb→MLB / Boxing→UFC / other→NULL,下游直引)。通用约定:DWD 单分区 `dt=T-1` 不回算(ODS 漂移已在 ODS 层归位);DIM 跑批初始化扫全量 + ROW_NUMBER 取最新行、日常增量"昨日 dim + 今日 ods"按 pk 合并去重;脏数据清洗位置统一放 DIM 层。**关键决策点**:1 期品类直取 `cgi.sport`(推翻早先"panini 是品类权威源"的草稿结论),不引产品表(panini / checklist / version_config 1 期不建对应 dim 表),业务依据是拼团可单品/组合品跨类,按拼团大类聚合贴近业务侧分析口径;C3 字段圈定 `id_card`(已 md5)/ `code` 纳入,`live_anonymous` / 通知三件套 / `live_config_json` 不纳入。**不入 kb 的**:1 期不实施的 `dwd_trd_order_refund_apd_d`(A3 锁不做退款扣减,2 期实施时再补 kb 章节)+ `dim_prd_checklist_ful_d`。设计稿留 `workspace/20260508/dwd_dim_draft.md`(含 1 期倒推链路 / refund 字段草稿 / 待办依赖等过程性内容,2 期实施时回查)。README §2x 数仓建模索引加 27 / 28 两行 | — |
+| 2026-05-09 | **kb/27 + kb/28 sport→category(lv2 品类字段命名拍板)+ workspace 三份工作稿标已部分作废**:(a) 品类字段命名按 kb/21 §1 一词一义原则,业务库 sport 实际多义(16 值里"影视收藏 / 综合收藏 / 综合体育"等非 sport 语义),数仓字段改用中性的 `category`;lv1 大类(业务库 `first_sport`,1 期不引)未来引入命名 `main_category`;改动点 kb/28 §3.2(命名说明 + 清洗规则措辞)+ §3.3 字段表 sport 行 + kb/27 §2.4 维度退化表 + 末段 + §2.6 字段表 sport 行。(b) `workspace/20260508/` 下 `dws_tdm_draft.md` / `dwd_modeling_questions.md` / `industry_practice_review.md` 顶部加"已部分作废 2026-05-09"段,建模结论以 kb/27 + kb/28 为准;workspace 在 .gitignore 不入 commit,本地档案保留作设计推理过程档案。 | — |
 | 2026-04-22 | **仓库改名 `tendata-warehouse-release` → `poyee-data-warehouse` 收尾**:项目根目录由用户手动改名完成;代码侧 `dw_base/utils/file_utils.py:9` + `dw_base/utils/hdfs_merge_small_file.py:7` 两处 `re.sub(r"tendata-warehouse.*", ...)` 字面量同步更新。`.idea/*.iml` / `modules.xml` / `workspace.xml` 因 `.idea` + `*.iml` 在 `.gitignore`,属本地 IDE 状态,不入库亦不影响运行(老 `tendata-warehouse-release.iml` + modules.xml / workspace.xml 里的 module name 残留不处理)。联动 kb/90 §1.1 L88 表格行打勾 + §2.3 末尾"与仓库改名的联动"段压缩为一行记录 | — |
 | 2026-04-21 | **聚簇 A.4 Spark 参数外配 + `spark_sql.py` 三级覆盖**:按业务调整频率拆两文件入库 —— `conf/spark-defaults.conf`(12 条底层行为/开关类,初始化后少改:`spark.sql.adaptive/broadcastTimeout/codegen/arrow*/files/statistics.*` + `spark.dynamicAllocation.enabled` + `spark.files.ignoreCorruptFiles` + `spark.debug.maxToStringFields` + `spark.port.maxRetries` + `hive.exec.orc.default.block.size`)+ `conf/spark-tuning.conf`(10 条资源/并行度/队列,业务早期常改:`spark.{driver,executor}.{memory,cores}` + `spark.executor.instances` + `spark.executor.memoryOverhead` + `spark.driver.maxResultSize` + `spark.default.parallelism` + `spark.sql.shuffle.partitions` + `spark.yarn.queue`)。`dw_base/spark/spark_sql.py` 改造:(a) 模块级新增 `_load_spark_conf_file(path)`,读 Spark 原生 `key value` 格式,支持 `#` 注释与空行,文件缺失返回 `{}` 容错单测;(b) `__init__` 10 个 tuning 相关构造参数默认值 `'2g' / 200 / ...` → `Optional[...] = None` sentinel,不破坏既有调用点显式传参;(c) `__init_spark_session` 原 22 条硬编码 `.config(...)` 链替换为三段:L1 先 `spark-defaults.conf` 后 `spark-tuning.conf`(相同 key tuning 覆盖 defaults)→ L2 `self._final_spark_config`(SQL 内 SET)→ L3 构造参数非 None 项 + `extra_spark_config`(L3 内 extra 覆盖 named),保持原"extra > SQL SET > named" 的向后兼容;日志分层打 `L1/L2/L3` 前缀便于排查。联动:`kb/90 §2.2` conf 结构加 `spark-tuning.conf` + `§2.3` 改写为两文件模型(去单文件草案)+ 删"坑 2"(B1 → A2 依赖边)+ 聚簇 L59 依赖边删 | — |
 | 2026-04-22 | **datasource 扁平化 + db_type 按父目录段判定(方向反转)**:反转 2026-04-15 起立项的"一套代码跑多环境"设计(kb/90 原 §2.5:`-env` 参数 + `datasource/{db_type}/{env}/{instance}.ini` 分层 + env 注入)。实际前期跨环境同步是常态(test 业务库 → prod HDFS),"全局 env"概念不成立。新方案:(a) source ini 落位 `datasource/{db_type}/{env}-{实例简称}.ini`,env 写进文件名(env ∈ dev/test/prod),扁平组织;(b) sync ini 内 `dataSource = {db_type}/{env}-{实例简称}`(强制带 db_type 前缀;旧裸名 `hdfs-ha` 不再支持);(c) 代码侧 `dw_base/datax/plugins/plugin.py:37` + `plugin_factory.py:34` 的 db_type 提取从"文件名按 `-` 切首词"改为"按 `/` 切首段"(父目录名)—— 旧算法在新文件名出现 `-` 时会把 `env` 误判为 db_type,必须改。联动:kb/00 §1 目录树重绘(去 env 子目录,加样例 `prod-hobby.ini` / `test-hobby.ini` / `prod-ha.ini` 等 + sync ini 引用形式说明段)+ §6.1 配置分类表落位描述、kb/02 §4 同步、kb/21 §3.9 过时 3 行修正(废 `-env` 注入表述;引用形式 `{db_type}/{env}-{实例简称}`;JSON 输出路径去 `{env}/` 层)、kb/90 §2.1 硬编码表合并 3 行为 1 行 + §2.5 大幅压缩(三阶段设计整段删,保留路径解耦部分)+ §2.8 末尾表行更新 + §八 状态表合并、kb/92 L90 checklist 落位改扁平。conf/templates/datasource/\*.template.ini × 3 头注释补"落位"+"dataSource 引用"两行。`bin/datax-job-config-generator.py` L5/L114/L115 的路径注释讲的是另一个 `conf/datax/config/` 作业分组层级,与本次 datasource 扁平化无关,不动;`dw_base/datax/plugins/reader/mysql_reader.py:178` `{group}/mysql-{database}` 生成逻辑是非活跃代码(批量采集未启动),留到 §2.7 重构时对齐 | — |