生产只读实测(7 天 / 281,760 条增量记录): 滞后 p50 2.39h / p99.9 15.39h / max 47.43h;>24h 31 条、>48h 0 条 按表拆:refund max 47.4h(>24h 有 27 条)、临床表 max 15.5h(>24h 全 0) 根因:游标跟 updated_date(源 HIS 改动时刻,≈事件时间),而数据到达取决于 DW 自己的 ETL —— 两者无关。所以必然有"updated_date 比游标旧、此刻才到达"的行,游标追不上。 退费那几条是铁证:源系统 13:05 建、13:13 改完,PAC 47 小时后才看到。⛔ 不能缩:缩 24h 丢 31 条、36h 丢 19 条,且游标推过去是**永久**漏拉。 且 max=47.43h 恰好顶在 48h 边界、>48h 为 0 —— 这是**截断的指纹**, 真实尾巴可能更长。本测量方向单边:能证"够用"不能证"不够"。 根治不在我们这边:DW 十张表一个入仓时间字段都没有(rq 是业务日期已排除)。 若 DW 加一列 ETL 写入的时间戳,游标即可在到达顺序上单调 → 漏拉结构上不可能, fetched 从 24.8 万降到约 1.6 万,摄入 31m → 预计 5~10m。⛔ 另记一个取样陷阱:第一版按 received_at 时间窗取样,混进 5 次 full: 全量补摄的 历史数据,得出"滞后 5 年"的荒谬结果。既有增量又有补摄的系统,取样必须按事件来源限定。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| Name |
Last commit
|
Last update |
|---|---|---|
| .claude | Loading commit data... | |
| .design-sync | Loading commit data... | |
| apps | Loading commit data... | |
| clickhouse/config.d | Loading commit data... | |
| deploy | Loading commit data... | |
| docs | Loading commit data... | |
| packages | Loading commit data... | |
| scripts | Loading commit data... | |
| .gitignore | Loading commit data... | |
| .gitlab-ci.yml | Loading commit data... | |
| .npmrc | Loading commit data... | |
| .prettierrc | Loading commit data... | |
| README.md | Loading commit data... | |
| docker-compose.expose.yml | Loading commit data... | |
| docker-compose.managed.yml | Loading commit data... | |
| docker-compose.prod.yml | Loading commit data... | |
| docker-compose.yml | Loading commit data... | |
| eslint.config.mjs | Loading commit data... | |
| liu.cjs | Loading commit data... | |
| package.json | Loading commit data... | |
| pnpm-lock.yaml | Loading commit data... | |
| pnpm-workspace.yaml | Loading commit data... | |
| tsconfig.base.json | Loading commit data... | |
| turbo.json | Loading commit data... |