Add philosophy and wsf directories

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-19 10:12:27 +08:00
parent 1c55e2974b
commit 09ecdbb654
19 changed files with 661995 additions and 0 deletions
@@ -0,0 +1,95 @@
+---
+title: wanshifu_dw 表目录（元数据索引，非 DDL）
+source_status: ddl_metadata（来自 WeData `DescribeTableMetas` 接口的表/字段元数据，非人工确认口径）
+fetched_at: 2026-07-30
+---
+
+# `wanshifu_dw` 表目录
+
+通过腾讯云 WeData API 的 `DescribeTableMetas`（表清单接口）批量抓取生成，**没有调用 `DescribeTableDdl`**——
+按用户要求，这一步只建索引，不批量拉 DDL。但 `DescribeTableMetas` 本身已经返回了字段名、字段类型、
+字段中文注释和分区信息，覆盖率相当高（见下表），对大多数表已经够用；真正需要完整 DDL（含建表属性、
+存储格式等）时再针对单张表调用 `scripts/get_wedata_ddl.py` 或 `skills/wedata-table-readiness`。
+
+## 抓取范围与覆盖率
+
+`wanshifu_dw` 库总共 24,360 张表（含大量测试/临时表，如 `abc_1`），本次只抓取核心数仓分层前缀，
+按用户选择跳过了 ODS 之外无法识别命名规律的表：
+
+| 文件 | 前缀 | 表数 | 有字段注释 | 分区表数 | 新套 `_v` 表数 |
+|---|---|---|---|---|---|
+| [ods.json](ods.json) | `ods_` | 2194 | 2182（99%） | 2045 | 487 |
+| [dwd.json](dwd.json) | `dwd_` | 2445 | 2396（98%） | 1755 | 221 |
+| [dws.json](dws.json) | `dws_` | 638 | 573（90%） | 189 | 48 |
+| [dim.json](dim.json) | `dim_` | 277 | 239（86%） | 22 | 85 |
+| [ads_analyze.json](ads_analyze.json) | `ads_analyze_` | 25 | 17（68%） | 0 | 5 |
+| [mid_analyze.json](mid_analyze.json) | `mid_analyze_` | 0 | — | — | — |
+
+合计约 **5579 张表**。`mid_analyze_` 前缀当前一张表都没有——说明分析师规范里定义的 `mid_analyze_` 命名规则
+还没有实际落地的表，需要时应先跟数仓侧确认这一层是否已启用。
+
+未抓取：`wanshifu_enterprise` 库（项目规则明确排除）；`wanshifu_dw` 里不匹配 `ods_/dwd_/dws_/dim_/ads_analyze_/mid_analyze_`
+前缀的表（含大量无法识别层级的历史/测试表，以及数量极少的 `ads_` 非 analyze 子类型表）。
+
+## 数据结构
+
+每个 JSON 文件结构：
+
+```json
+{
+  "database": "wanshifu_dw",
+  "prefix": "ods_",
+  "count": 2194,
+  "source": "DescribeTableMetas (list + column comments, no DDL fetched)",
+  "fetched_at": "2026-07-30 10:53:xx",
+  "tables": [
+    {
+      "table_id": "...",
+      "database": "wanshifu_dw",
+      "table": "ods_account_info_n",
+      "project": "...",
+      "technology_type": "HIVE",
+      "is_view": false,
+      "is_partition_table": true,
+      "partition_columns": ["etl_date"],
+      "create_time": "...",
+      "modify_time": "...",
+      "columns": [
+        {"name": "...", "type": "...", "comment": "...", "is_partition": false}
+      ],
+      "layer": "ODS",
+      "suite": "new_v",
+      "incremental_name": false,
+      "full_snapshot_name": true
+    }
+  ]
+}
+```
+
+`layer`/`suite`/`incremental_name`/`full_snapshot_name` 是按 [../warehouse.md](../warehouse.md) 里的选表规则
+从表名推断出来的（`table_name_inference`，知识优先级里最低一档，仅供参考，实际选表仍要看字段是否满足需求）。
+
+出于脱敏考虑，**没有保留** `TableProperties`（存储路径、SerDe 等实现细节，含 COS 路径，等同于 DDL 里会被脱敏的 `LOCATION` 属性）。
+
+## 已知局限
+
+- 字段注释是数仓开发时手工填的，不是每张表都填了（尤其 `dim`/`ads_analyze` 层覆盖率明显更低）；空注释不代表字段没有业务含义，只代表没人补录。
+- 这只是元数据快照（抓取于 2026-07-30），表结构可能已变化；正式写 SQL 前仍应走 `wedata-table-readiness` 重新核实。
+- 分区语义（`full_snapshot_name` 等）是按表名规则推断的粗略标注，不是"已验证的表级知识"；具体到某张表要不要按 `T-1` 过滤，仍按 [../warehouse.md](../warehouse.md) 里的规则最终核实。
+- 未抓取字段级血缘、上下游依赖——这依然需要 `DescribeLineageInfo`，按需单表查询。
+
+## 下一步：单表 DDL 按需获取
+
+需要某张表完整 DDL（建表语句、存储属性等）时，不要重跑本目录的批量抓取，改用现有单表工具：
+
+```bash
+python scripts/get_wedata_ddl.py <table_id>
+```
+
+或走完整就绪检查（含血缘、字段满足度判断）：
+
+```bash
+python skills/wedata-table-readiness/scripts/readiness.py --input request.json
+```
+
+`table_id` 可以直接从本目录对应 JSON 文件里的 `table_id` 字段查到，不用再调 `DescribeTableMetas` 按名字反查一次。
@@ -0,0 +1,8 @@
+{
+  "ods": 2194,
+  "dwd": 2445,
+  "dws": 638,
+  "dim": 277,
+  "ads_analyze": 25,
+  "mid_analyze": 0
+}
@@ -0,0 +1,8 @@
+{
+  "database": "wanshifu_dw",
+  "prefix": "mid_analyze_",
+  "count": 0,
+  "source": "DescribeTableMetas (list + column comments, no DDL fetched)",
+  "fetched_at": "2026-07-30 10:54:15",
+  "tables": []
+}