2.2 KiB
title, type, permalink, stable_id, scope, project_id, memory_type, status, revision, restored_from_commit, created_at, updated_at, tags
| title | type | permalink | stable_id | scope | project_id | memory_type | status | revision | restored_from_commit | created_at | updated_at | tags | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Checkpoint 2026-09-17 03:46:37 UTC [16147020e2] | checkpoint | main/projects/62afe036-4c36-42b0-89fd-e2231d3d6788/checkpoint-2026-09-17-03-46-37-utc-16147020e2 | 5e8e39d4-dccf-4052-8b9a-bbcd0fa22e58 | project | 62afe036-4c36-42b0-89fd-e2231d3d6788 | checkpoint | active | 1 | 6a6a895eaf |
2026-09-23T14:55:41.413035+00:00 | 2026-09-23T14:55:41.413090+00:00 |
|
完成：把 2026-09-17 新导出的两个周指标 xlsx（2026-07-12 ~ 2026-09-13 共 10 周）合并进 SourceData/2.6G.xlsx 和 SourceData/700M.xlsx，列结构以旧文件为准，新文件的 gNBplmn/gNBId/cellId 由 masterOperatorId 拆出。合并后 2.6G 487321 行，700M 643294 行，共 38 个周（2025-12-28 ~ 2026-09-13）。原文件和两个新导出文件已移到 SourceData/Backup_20260917/（不在 main.py 的 glob 范围内）。已用 main.rebuild_metric_cache 重建 CacheData/metric_cache.sqlite 并验证新旧衔接处数值量级一致。合并脚本是 /tmp 临时脚本，未入库；main.py 未改动。同时用 uv + Python 3.13 重建了失效的 .venv。
数据质量问题（已告知用户）：
- 2026-07-05 周是残缺周（旧文件导出于 07-06，只有约 1 天数据，流量约为正常周 1/7），新导出从 07-12 开始未覆盖它。开通日在 06-28~07-19 附近的站点，前后周对比会失真。
- 2026-09-13 周（09-13~09-20）导出时也未走完，同样是残缺周。
下一步：若用户重新导出 07-05 周（或以后的 09-13 周），需要先删除合并文件中该周的旧行再追加（当前合并逻辑是“周已存在则跳过”，不会自动替换）。可选改进：让 main.py 直接兼容新模板（缺 gNBplmn/gNBId/cellId 时从 masterOperatorId 拆），以后新导出直接丢进 SourceData 即可，不用再合并。
给下个会话：验证/辅助脚本如果调用 main 里的进程池函数，必须放在 if name == "main" 下，否则 Windows spawn 会报 BrokenProcessPool。openpyxl write_only 写 5065MB xlsx 约 34 分钟。700M.xlsx 已 64 万行，每周增约 1 万行，距 Excel 104 万行上限还有约 40 周。