在前后端开发联调前 的提交20260223
This commit is contained in:
126
.kiro/specs/etl-fullstack-integration/design.md
Normal file
126
.kiro/specs/etl-fullstack-integration/design.md
Normal file
@@ -0,0 +1,126 @@
|
||||
# 设计文档:ETL 全流程前后端联调(etl-fullstack-integration)
|
||||
|
||||
## 概述
|
||||
|
||||
本 Spec 是一个运维联调任务,不涉及新功能开发。目标是验证 `admin-web-console` Spec 产出的前后端代码在真实环境下的端到端正确性,同时收集性能数据。
|
||||
|
||||
核心流程:
|
||||
1. 启动后端 + 前端服务
|
||||
2. 通过 API 登录获取 JWT
|
||||
3. 提交全流程 ETL 任务(api_full, full_window, force-full, 全选常用任务, 自定义窗口 2025-11-01~2026-02-20, 30天切分, 全部门店)
|
||||
4. 实时监控执行过程,捕获错误/警告
|
||||
5. 执行完成后生成综合报告
|
||||
|
||||
## 架构
|
||||
|
||||
```
|
||||
联调脚本 (scripts/ops/)
|
||||
│
|
||||
├── 1. 启动服务
|
||||
│ ├── uvicorn app.main:app (后端 :8000)
|
||||
│ └── pnpm dev (前端 :5173)
|
||||
│
|
||||
├── 2. API 调用链
|
||||
│ ├── POST /api/auth/login → JWT
|
||||
│ ├── GET /api/tasks/registry → 任务列表
|
||||
│ ├── GET /api/tasks/sync-check → 同步检查
|
||||
│ ├── POST /api/tasks/validate → CLI 预览
|
||||
│ └── POST /api/execution/run → 触发执行
|
||||
│
|
||||
├── 3. 监控循环
|
||||
│ ├── GET /api/execution/queue → 状态轮询
|
||||
│ ├── GET /api/execution/{id}/logs → 日志获取
|
||||
│ └── 错误/警告检测
|
||||
│
|
||||
└── 4. 报告生成
|
||||
└── 输出到 SYSTEM_LOG_ROOT
|
||||
```
|
||||
|
||||
## 任务参数
|
||||
|
||||
根据用户需求,联调任务的具体参数:
|
||||
|
||||
```python
|
||||
INTEGRATION_TASK_CONFIG = {
|
||||
"flow": "api_full", # 全流程:API → ODS → DWD → DWS → INDEX
|
||||
"processing_mode": "full_window", # 全窗口处理
|
||||
"window_mode": "custom", # 自定义时间范围
|
||||
"window_start": "2025-11-01 00:00",
|
||||
"window_end": "2026-02-20 00:00",
|
||||
"window_split": "day", # 按天切分
|
||||
"window_split_days": 30, # 30天一个切片
|
||||
"force_full": True, # 强制全量
|
||||
"dry_run": False,
|
||||
"tasks": [ # 全选 is_common=True 的任务
|
||||
# ODS 层(22 个)
|
||||
"ODS_ASSISTANT_ACCOUNT", "ODS_ASSISTANT_LEDGER", "ODS_ASSISTANT_ABOLISH",
|
||||
"ODS_SETTLEMENT_RECORDS", "ODS_TABLE_USE", "ODS_TABLE_FEE_DISCOUNT",
|
||||
"ODS_TABLES", "ODS_PAYMENT", "ODS_REFUND", "ODS_PLATFORM_COUPON",
|
||||
"ODS_MEMBER", "ODS_MEMBER_CARD", "ODS_MEMBER_BALANCE", "ODS_RECHARGE_SETTLE",
|
||||
"ODS_GROUP_PACKAGE", "ODS_GROUP_BUY_REDEMPTION",
|
||||
"ODS_INVENTORY_STOCK", "ODS_INVENTORY_CHANGE",
|
||||
"ODS_GOODS_CATEGORY", "ODS_STORE_GOODS", "ODS_STORE_GOODS_SALES", "ODS_TENANT_GOODS",
|
||||
# DWD 层(1 个常用)
|
||||
"DWD_LOAD_FROM_ODS",
|
||||
# DWS 层(15 个常用,排除 DWS_MAINTENANCE)
|
||||
"DWS_BUILD_ORDER_SUMMARY", "DWS_ASSISTANT_DAILY", "DWS_ASSISTANT_MONTHLY",
|
||||
"DWS_ASSISTANT_CUSTOMER", "DWS_ASSISTANT_SALARY", "DWS_ASSISTANT_FINANCE",
|
||||
"DWS_MEMBER_CONSUMPTION", "DWS_MEMBER_VISIT",
|
||||
"DWS_FINANCE_DAILY", "DWS_FINANCE_RECHARGE", "DWS_FINANCE_INCOME_STRUCTURE",
|
||||
"DWS_FINANCE_DISCOUNT_DETAIL",
|
||||
"DWS_GOODS_STOCK_DAILY", "DWS_GOODS_STOCK_WEEKLY", "DWS_GOODS_STOCK_MONTHLY",
|
||||
# INDEX 层(3 个常用,排除 DWS_ML_MANUAL_IMPORT)
|
||||
"DWS_WINBACK_INDEX", "DWS_NEWCONV_INDEX", "DWS_RELATION_INDEX",
|
||||
],
|
||||
# store_id 由后端从 JWT 注入(默认管理员 site_id=1)
|
||||
# 注意:用户要求"全部门店",但当前系统只有 site_id=1,后续多门店需逐个执行
|
||||
}
|
||||
```
|
||||
|
||||
## 监控策略
|
||||
|
||||
- 轮询间隔:30 秒
|
||||
- 最长等待:30 分钟(无新日志输出时)
|
||||
- 错误检测:日志行匹配 `ERROR`、`CRITICAL`、`Traceback`、`Exception`
|
||||
- 警告检测:日志行匹配 `WARNING`、`WARN`
|
||||
- 计时解析:从日志中提取时间戳,计算阶段耗时
|
||||
|
||||
## 报告格式
|
||||
|
||||
报告输出为 Markdown 文件,路径:`{SYSTEM_LOG_ROOT}/{date}__etl_integration_report.md`
|
||||
|
||||
```markdown
|
||||
# ETL 全流程联调报告
|
||||
|
||||
## 执行概要
|
||||
- 任务参数:...
|
||||
- 开始时间 / 结束时间 / 总时长
|
||||
- 退出码 / 最终状态
|
||||
|
||||
## 性能报告
|
||||
- 各窗口切片耗时对比表
|
||||
- Top-5 耗时阶段
|
||||
- 总体吞吐量估算
|
||||
|
||||
## DEBUG 报告(如有)
|
||||
- 错误摘要
|
||||
- 警告摘要
|
||||
- 相关日志片段
|
||||
- 可能的原因分析
|
||||
```
|
||||
|
||||
## 正确性属性
|
||||
|
||||
本 Spec 为运维联调任务,不涉及新功能代码开发,因此不定义形式化的属性测试。验证通过以下方式进行:
|
||||
- 服务健康检查通过
|
||||
- 任务提交成功并开始执行
|
||||
- 执行完成后退出码和日志符合预期
|
||||
- 报告文件成功生成
|
||||
|
||||
## 测试策略
|
||||
|
||||
本 Spec 本身就是一次集成测试。不额外编写单元测试或属性测试。验证标准:
|
||||
- 后端 API 响应正确
|
||||
- ETL CLI 子进程正常启动和执行
|
||||
- 日志正确捕获和推送
|
||||
- 报告文件正确生成到 SYSTEM_LOG_ROOT
|
||||
70
.kiro/specs/etl-fullstack-integration/requirements.md
Normal file
70
.kiro/specs/etl-fullstack-integration/requirements.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# 需求文档:ETL 全流程前后端联调(etl-fullstack-integration)
|
||||
|
||||
## 简介
|
||||
|
||||
基于已完成的 `admin-web-console` Spec 产出的前后端代码,进行一次完整的端到端联调验证。通过管理后台 API 提交 ETL 全流程任务(api_full),覆盖 ODS → DWD → DWS → INDEX 全链路,验证前后端协作、子进程执行、日志推送、错误处理等环节的正确性。同时收集精细计时数据,定位性能瓶颈。
|
||||
|
||||
## 术语表
|
||||
|
||||
- **联调**:将 admin-web 后端 API 与 feiqiu ETL CLI 串联,通过真实 API 调用触发 ETL 全流程执行
|
||||
- **全选常用任务**:任务注册表中 `is_common=True` 的所有任务(排除工具类、手动导入、维护类等 `is_common=False` 的任务)
|
||||
- **精细计时**:在 ETL 执行过程中,通过日志解析或 CLI 输出,记录每个阶段(ODS/DWD/DWS/INDEX)和每个子任务的耗时
|
||||
|
||||
## 需求
|
||||
|
||||
### 需求 1:服务启动与健康检查
|
||||
|
||||
**用户故事:** 作为开发者,我希望一键启动后端和前端服务,并确认服务健康可用,以便开始联调。
|
||||
|
||||
#### 验收标准
|
||||
|
||||
1. WHEN 启动后端服务, THE Backend_API SHALL 在 `http://localhost:8000` 上响应请求
|
||||
2. WHEN 启动前端服务, THE Admin_Web SHALL 在 `http://localhost:5173` 上可访问
|
||||
3. WHEN 调用 `POST /api/auth/login`, THE Backend_API SHALL 返回有效的 JWT 令牌
|
||||
4. WHEN 调用 `GET /api/tasks/registry`, THE Backend_API SHALL 返回非空的任务注册表
|
||||
5. WHEN 调用 `GET /api/tasks/sync-check`, THE Backend_API SHALL 确认后端任务注册表与 ETL 真实注册表同步
|
||||
|
||||
### 需求 2:全流程任务提交与执行
|
||||
|
||||
**用户故事:** 作为开发者,我希望通过后端 API 提交一个覆盖全链路的 ETL 任务,验证任务配置、CLI 构建、子进程执行的完整流程。
|
||||
|
||||
#### 验收标准
|
||||
|
||||
1. WHEN 提交 TaskConfig(api_full + full_window + 全选常用任务 + 自定义窗口 2025-11-01~2026-02-20 + 30天切分 + force-full), THE Backend_API SHALL 验证配置有效并返回 CLI 命令预览
|
||||
2. WHEN 提交任务到执行队列, THE Backend_API SHALL 创建队列任务并自动开始执行
|
||||
3. WHILE ETL 子进程运行中, THE Backend_API SHALL 通过 WebSocket 推送实时日志
|
||||
4. WHEN ETL 子进程完成, THE Backend_API SHALL 记录退出码、执行时长、完整日志到 task_execution_log
|
||||
|
||||
### 需求 3:执行监控与错误处理
|
||||
|
||||
**用户故事:** 作为开发者,我希望在任务执行过程中实时监控状态,对报错或警告及时发现并进行 DEBUG。
|
||||
|
||||
#### 验收标准
|
||||
|
||||
1. WHILE 任务执行中, THE 监控脚本 SHALL 每 30 秒轮询执行状态和日志
|
||||
2. WHEN 日志中出现 ERROR 或 WARNING 级别信息, THE 监控脚本 SHALL 立即记录并标记
|
||||
3. WHEN 任务执行完成(成功或失败), THE 监控脚本 SHALL 停止轮询并收集最终状态
|
||||
4. IF 任务执行超过 30 分钟无新日志输出, THEN THE 监控脚本 SHALL 报告超时警告
|
||||
5. IF 任务执行失败, THEN THE 监控脚本 SHALL 收集完整的 stderr 和错误上下文
|
||||
|
||||
### 需求 4:性能计时与瓶颈分析
|
||||
|
||||
**用户故事:** 作为开发者,我希望获得精细粒度的执行计时数据,以便发现性能瓶颈。
|
||||
|
||||
#### 验收标准
|
||||
|
||||
1. WHEN 任务执行完成, THE 报告 SHALL 包含总执行时长
|
||||
2. WHEN 日志中包含阶段性时间戳, THE 报告 SHALL 解析并展示每个窗口切片的耗时
|
||||
3. THE 报告 SHALL 标注耗时最长的 Top-5 阶段/任务
|
||||
4. THE 报告 SHALL 包含每个窗口切片(30天)的独立耗时对比
|
||||
|
||||
### 需求 5:联调报告输出
|
||||
|
||||
**用户故事:** 作为开发者,我希望联调完成后获得一份综合报告,包含执行情况、性能数据和可能的 DEBUG 信息。
|
||||
|
||||
#### 验收标准
|
||||
|
||||
1. THE 报告 SHALL 包含:执行概要(任务参数、开始/结束时间、总时长、退出码)
|
||||
2. THE 报告 SHALL 包含:性能报告(各阶段耗时、窗口切片耗时对比、Top-5 瓶颈)
|
||||
3. IF 执行过程中出现错误或警告, THEN THE 报告 SHALL 包含 DEBUG 报告(错误摘要、相关日志片段、可能的原因分析)
|
||||
4. THE 报告 SHALL 输出到 `SYSTEM_LOG_ROOT` 环境变量指定的目录
|
||||
86
.kiro/specs/etl-fullstack-integration/tasks.md
Normal file
86
.kiro/specs/etl-fullstack-integration/tasks.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# 实现计划:ETL 全流程前后端联调(etl-fullstack-integration)
|
||||
|
||||
## 概述
|
||||
|
||||
基于 `admin-web-console` 已完成的前后端代码,进行端到端联调验证。通过后端 API 提交 api_full 全流程 ETL 任务(自定义窗口 2025-11-01~2026-02-20,30天切分,force-full,全选常用任务),实时监控执行过程,收集性能数据,最终生成综合报告。
|
||||
|
||||
## 任务
|
||||
|
||||
- [ ] 1. 服务启动与健康检查
|
||||
- [ ] 1.1 启动后端服务(`apps/backend/`,uvicorn :8000),确认 API 可达
|
||||
- 启动 `uvicorn app.main:app --host 0.0.0.0 --port 8000`,cwd 为 `apps/backend/`
|
||||
- 验证 `GET /api/tasks/flows` 返回 200
|
||||
- _Requirements: 1.1_
|
||||
|
||||
- [ ] 1.2 启动前端服务(`apps/admin-web/`,pnpm dev :5173),确认页面可访问
|
||||
- 启动 `pnpm dev`,cwd 为 `apps/admin-web/`
|
||||
- 验证 `http://localhost:5173` 可达
|
||||
- _Requirements: 1.2_
|
||||
|
||||
- [ ] 1.3 API 健康检查:登录获取 JWT,验证任务注册表,执行 sync-check
|
||||
- `POST /api/auth/login` 使用默认管理员账号(admin / admin123),获取 JWT
|
||||
- `GET /api/tasks/registry` 确认返回非空任务列表
|
||||
- `GET /api/tasks/sync-check` 确认 `in_sync=true`(后端注册表与 ETL 真实注册表一致)
|
||||
- 如果 sync-check 不一致,记录差异并向用户报告
|
||||
- _Requirements: 1.3, 1.4, 1.5_
|
||||
|
||||
- [ ] 2. 全流程任务提交
|
||||
- [ ] 2.1 构建 TaskConfig 并调用 validate 预览 CLI 命令
|
||||
- 构建 TaskConfig:flow=api_full, processing_mode=full_window, window_mode=custom, window_start="2025-11-01 00:00", window_end="2026-02-20 00:00", window_split=day, window_split_days=30, force_full=True, tasks=全选 is_common=True 的任务
|
||||
- 调用 `POST /api/tasks/validate` 验证配置有效
|
||||
- 记录生成的 CLI 命令预览,确认参数完整(--flow api_full --processing-mode full_window --window-start ... --window-end ... --window-split day --window-split-days 30 --force-full --store-id 1 --tasks ...)
|
||||
- _Requirements: 2.1_
|
||||
|
||||
- [ ] 2.2 提交任务执行(`POST /api/execution/run`),记录 execution_id
|
||||
- 调用 `POST /api/execution/run` 提交任务
|
||||
- 记录返回的 execution_id
|
||||
- 确认任务状态变为 running
|
||||
- _Requirements: 2.2, 2.4_
|
||||
|
||||
- [ ] 3. 执行监控与 DEBUG
|
||||
- [ ] 3.1 启动监控循环:每 30 秒轮询状态和日志,检测错误/警告,最长等待 30 分钟
|
||||
- 轮询 `GET /api/execution/queue` 检查任务状态
|
||||
- 轮询 `GET /api/execution/{id}/logs` 获取增量日志
|
||||
- 检测日志中的 ERROR / CRITICAL / Traceback / Exception / WARNING
|
||||
- 记录每次轮询的时间戳和日志增量行数
|
||||
- 如果连续 30 分钟无新日志输出,报告超时警告
|
||||
- 任务完成(success/failed/cancelled)时停止轮询
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5_
|
||||
|
||||
- [ ] 3.2 对执行过程中发现的错误/警告进行 DEBUG 分析
|
||||
- 收集所有 ERROR 和 WARNING 日志行及其上下文(前后各 5 行)
|
||||
- 分析错误类型:API 超时、数据库连接、数据质量、配置问题等
|
||||
- 如果任务失败,获取完整 stderr 并分析根因
|
||||
- 记录 DEBUG 发现到报告中
|
||||
- _Requirements: 3.2, 3.5_
|
||||
|
||||
- [ ] 4. 性能计时与报告生成
|
||||
- [ ] 4.1 解析执行日志,提取精细计时数据
|
||||
- 从日志中提取每个窗口切片(30天)的开始/结束时间
|
||||
- 计算每个切片的耗时
|
||||
- 识别 ODS / DWD / DWS / INDEX 各阶段的耗时
|
||||
- 标注 Top-5 耗时最长的阶段/任务
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4_
|
||||
|
||||
- [ ] 4.2 生成综合联调报告,输出到 SYSTEM_LOG_ROOT
|
||||
- 报告包含:执行概要(参数、时间、退出码)
|
||||
- 报告包含:性能报告(各切片耗时对比、Top-5 瓶颈)
|
||||
- 报告包含:DEBUG 报告(如有错误/警告)
|
||||
- 输出路径:`{SYSTEM_LOG_ROOT}/{date}__etl_integration_report.md`
|
||||
- 路径通过 `SYSTEM_LOG_ROOT` 环境变量获取,缺失时报错
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4_
|
||||
|
||||
- [ ] 5. 服务清理
|
||||
- [ ] 5.1 停止后端和前端服务,清理资源
|
||||
- 停止 uvicorn 进程
|
||||
- 停止 pnpm dev 进程
|
||||
- 报告联调完成状态
|
||||
|
||||
## 说明
|
||||
|
||||
- 本 Spec 为运维联调任务,不涉及新功能代码开发
|
||||
- 不编写属性测试或单元测试,联调本身即为集成验证
|
||||
- 全选常用任务 = 任务注册表中 `is_common=True` 的所有任务(共 41 个)
|
||||
- "全部门店":当前系统仅有 site_id=1(默认管理员绑定),如需多门店需逐个执行
|
||||
- 监控允许空闲等待,最长 30 分钟无新日志才报超时
|
||||
- 报告输出路径遵循 export-paths 规范,通过 SYSTEM_LOG_ROOT 环境变量获取
|
||||
Reference in New Issue
Block a user