Huaxu Sentinel Active Safety Platform with embedded algorithm code, Docker Compose setup, and vendored dataset scaffolds for clone-and-run. Co-authored-by: Cursor <cursoragent@cursor.com>
126 lines
5.9 KiB
Markdown
126 lines
5.9 KiB
Markdown
# 上传到数据湖实施清单
|
||
|
||
本文档用于执行“上传压缩包/文件夹 -> 自动分析 -> 审核 -> 版本入湖 -> 数据目录展示”的完整闭环。
|
||
|
||
## 1. 目标与边界
|
||
|
||
- 目标:把人工回传落盘升级为可追溯的数据入湖流水线。
|
||
- 范围:DMS(检测)与 Lane(2D 车道线)两条数据线。
|
||
- 原则:先入候选区,再自动分析,审核通过后才晋级正式版本。
|
||
|
||
## 2. 端到端流程
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
uploadClient[UploadClient] --> stagingArea[StagingArea]
|
||
stagingArea --> qualityWorker[QualityWorker]
|
||
qualityWorker --> qualityReport[QualityReport]
|
||
qualityReport --> approvalQueue[ApprovalQueue]
|
||
approvalQueue --> curatedLake[CuratedDataLake]
|
||
curatedLake --> catalogIndex[CatalogIndex]
|
||
catalogIndex --> dataDirectory[DataDirectoryUI]
|
||
```
|
||
|
||
## 3. 阶段清单
|
||
|
||
### 阶段 A:上传接入
|
||
|
||
- **检查项**:支持 zip 与目录上传,展示实时进度、失败重试、取消上传。
|
||
- **完成标准**:前端可看到 0-100% 进度,失败可重传,上传完成返回 `candidate_id`。
|
||
- **责任角色**:前端工程师、平台后端工程师。
|
||
- **检查项**:上传文件落到 staging 区,不直接进入正式数据目录。
|
||
- **完成标准**:路径落到 `lake/staging/<project>/<candidate_id>/`;正式目录无未审数据。
|
||
- **责任角色**:平台后端工程师、运维工程师。
|
||
- **检查项**:上传元数据落库(上传人、时间、来源、文件 hash、项目/任务)。
|
||
- **完成标准**:数据库可按 `candidate_id` 查询到完整元数据。
|
||
- **责任角色**:平台后端工程师。
|
||
|
||
### 阶段 B:自动分析
|
||
|
||
- **检查项**:上传完成后自动触发异步分析任务(非阻塞 API)。
|
||
- **完成标准**:Redis/Worker 中出现分析任务,任务状态可在前端轮询或订阅。
|
||
- **责任角色**:平台后端工程师。
|
||
- **检查项**:DMS 自动分析报告生成。
|
||
- **完成标准**:输出类别分布、框宽高分布、bbox 密度、train/val/test 计数。
|
||
- **责任角色**:算法工程师、平台后端工程师。
|
||
- **检查项**:Lane 自动分析报告生成。
|
||
- **完成标准**:输出车道线数量分布、长度分布、曲率分布、train/val/test 计数。
|
||
- **责任角色**:算法工程师、平台后端工程师。
|
||
- **检查项**:质量报告结构化落地(JSON)并可追溯。
|
||
- **完成标准**:`lake/reports/<candidate_id>/quality.json` 可读取,且数据库保存报告摘要。
|
||
- **责任角色**:平台后端工程师。
|
||
|
||
### 阶段 C:审核流
|
||
|
||
- **检查项**:自动分析完成后自动提交审核单(附质量报告与关键指标)。
|
||
- **完成标准**:`approvals` 中出现对应记录,状态为 `pending`。
|
||
- **责任角色**:平台后端工程师。
|
||
- **检查项**:审核通过后触发“晋级入湖”动作;驳回则保留候选并记录原因。
|
||
- **完成标准**:审批动作写入审计日志,审批意见可查询。
|
||
- **责任角色**:审核员、平台后端工程师。
|
||
- **检查项**:审批链路可回放、可追责。
|
||
- **完成标准**:能按 `candidate_id` 追溯上传人、审核人、审核意见、执行任务、最终版本。
|
||
- **责任角色**:平台后端工程师、运维工程师。
|
||
|
||
### 阶段 D:版本入湖
|
||
|
||
- **检查项**:通过审批的数据原子晋级到 curated 正式版本目录。
|
||
- **完成标准**:路径形如 `lake/curated/<project>/<task>/v0001/`,且不会覆盖已有版本。
|
||
- **责任角色**:平台后端工程师。
|
||
- **检查项**:版本号规范化管理。
|
||
- **完成标准**:版本号连续递增(`v0001`, `v0002`),支持回查父版本/来源候选集。
|
||
- **责任角色**:平台后端工程师、数据治理负责人。
|
||
- **检查项**:catalog/data-directory 自动刷新展示新版本。
|
||
- **完成标准**:前端数据目录可见新版本与质量摘要,不需手工改配置。
|
||
- **责任角色**:前端工程师、平台后端工程师。
|
||
|
||
### 阶段 E:运维与安全
|
||
|
||
- **检查项**:失败重试与死信策略。
|
||
- **完成标准**:分析失败可重跑;超过阈值进入死信并告警。
|
||
- **责任角色**:平台后端工程师、运维工程师。
|
||
- **检查项**:容量与配额控制(单包大小、单用户日配额、生命周期清理)。
|
||
- **完成标准**:超过限制明确拒绝并返回原因;staging 过期数据自动清理。
|
||
- **责任角色**:运维工程师、平台后端工程师。
|
||
- **检查项**:权限与审计。
|
||
- **完成标准**:上传/审核/晋级都受 RBAC 控制,关键操作有审计日志。
|
||
- **责任角色**:平台后端工程师、安全负责人。
|
||
|
||
## 4. 数据目录展示规范(必须)
|
||
|
||
### 4.1 版本信息最小字段
|
||
|
||
- `project` / `task` / `version`
|
||
- `created_at` / `source_candidate_id`
|
||
- `status`(候选、待审、已晋级、已驳回)
|
||
- `train_count` / `val_count` / `test_count`
|
||
|
||
### 4.2 DMS 展示最小字段
|
||
|
||
- 类别分布(可视化)
|
||
- bbox 宽高分布(散点或密度)
|
||
- 框密度(box per image)
|
||
- train/val/test 样本计数
|
||
|
||
### 4.3 Lane 展示最小字段
|
||
|
||
- 每帧车道线数量分布
|
||
- 线长度分布
|
||
- 曲率分布
|
||
- train/val/test 样本计数
|
||
|
||
## 5. 目录与命名建议
|
||
|
||
- `lake/raw/<project>/<date>/<upload_id>/`:原始上传留存
|
||
- `lake/staging/<project>/<candidate_id>/`:待分析/待审核候选区
|
||
- `lake/curated/<project>/<task>/v0001/`:正式数据湖区
|
||
- `lake/reports/<candidate_id>/quality.json`:质量报告
|
||
|
||
## 6. 验收标准
|
||
|
||
- 文档可直接给工程团队逐条执行,不依赖口头补充。
|
||
- DMS 与 Lane 都有明确的自动分析指标与展示字段。
|
||
- 数据目录必须明确显示每个版本的 `train/val/test`,不允许只给总量。
|
||
- 上传、分析、审核、入湖全链路具备可追溯 ID(`upload_id` / `candidate_id` / `approval_id` / `job_id`)。
|
||
- 任一阶段失败时,系统能给出可读错误原因与重试入口。
|