Blog
数据库图表业务逻辑梳理
基于 SQLite 数据库和 Dashboard 图表，梳理数据来源、指标聚合、业务信号、可视化展示和后续监控规则。
这篇文章基于当前 SQLite 数据库和 Dashboard 图表，目标不是单纯解释页面上有哪些图，而是把背后的业务逻辑梳理出来：数据从哪里来，如何被清洗聚合，哪些指标应该优先展示，以及这些指标最终要支持什么监控动作。
一句话结论
当前 Dashboard 的核心业务目标是把 Lumi 算力使用从“账单明细”整理成“经营监控面板”：
当前数据没有表现出余额即将耗尽的风险，但表现出明显的消耗集中度风险：近 7 日确认消耗为 55,275.2，其中 chaoyouwenhua_lumi 和 创意画布 / thirdAPI 都占 88.4%。因此，短期重点不是补充算力，而是确认 2026-06-23 的峰值消耗是否为计划内批量任务，并为高消耗账号与高消耗服务设置预算阈值。
数据库里的业务对象
当前数据库位于项目的 work/usage.db，主要表可以按业务含义分成五类。
| 表 | 业务含义 | 当前作用 |
|---|---|---|
lumi_balance_snapshots |
算力余额快照 | 计算当前余额、总额度、剩余比例、预计可用天数 |
lumi_consume_logs |
Lumi 消费流水 | 计算近 7 日趋势、用户排行、服务排行、作品任务排行、最近消费 |
lumi_users |
用户缓存 | 在消费日志缺少用户名时补齐用户身份 |
lumi_user_resource_daily / hourly |
用户资源聚合表 | 为用户、服务、场景、资源维度明细提供聚合口径 |
lumi_resource_dimensions |
资源维度字典 | 识别资源、场景和子场景组合 |
当前样本概况：
| 指标 | 数值 |
|---|---|
| 消费日志 | 100 条 |
| 用户缓存 | 94 个用户 |
| 余额快照 | 1 条 |
| 当前余额 | 7,767,241.91 |
| 总额度 | 32,000,000 |
| 剩余比例 | 24.27% |
| 近 7 日确认消耗 | 55,275.2 |
| 近 7 日日均确认消耗 | 7,896.46 |
| 预计可用天数 | 983.64 天 |
| 当前预扣 | 0 |
从数据到图表的处理链路
这套 Dashboard 的业务链路可以拆成 4 层。
第一层是原始采集。系统从 Lumi API 拉取余额、消费日志和用户信息，写入 SQLite。这里的关键不是展示，而是保证流水完整、可追溯、可重复聚合。
第二层是字段清洗。消费日志里的 source_json 会补充 sub_scene、work_id、task_id、name 等信息；用户名称优先取日志自身字段，缺失时再从 lumi_users 里补齐。这样才能把一条消费流水映射到“用户、服务、场景、子场景、作品或任务”。
第三层是指标聚合。后端把近 7 日数据整理成 summary、daily_trend、user_rankings、service_rankings、work_rankings、recent_logs 和 user_resource_breakdown。
第四层是业务信号。页面最上方不应该只是堆图，而应该把数据库解析出的重点动作展示出来，所以新增了 business_signals，把容量、峰值、账号集中度、服务集中度、预扣和数据新鲜度统一成一张行动队列表。
需要展示的业务需求
Dashboard 顶部应该优先回答 6 个问题。
| 业务问题 | 对应信号 | 展示方式 | 业务动作 |
|---|---|---|---|
| 余额还安全吗 | 余额容量 | 余额卡片、容量进度条、预计可用天数 | 判断是否需要补充算力或压降任务 |
| 最近是否突增 | 峰值突增 | 7 日柱状趋势、峰值日期、峰值倍数 | 回看峰值日的账号、服务和作品来源 |
| 谁是主要消耗方 | 账号集中度 | 用户消耗 Top、账号占比 | 判断是否为计划任务或异常批量调用 |
| 算力花在哪类业务 | 服务集中度 | 服务构成图、服务占比 | 评估是否需要服务级预算阈值 |
| 能否追到具体任务 | 作品 / 任务消耗 Top | 作品任务排行、明细表 | 定位具体作品、任务或调用来源 |
| 数据是否可靠 | 数据新鲜度 | 最新消费时间、采集状态 | 判断采集任务是否中断 |
这些问题共同组成一个监控闭环：
当前图表反映出的业务结论
1. 容量不是短期主风险
当前剩余比例为 24.27%，低于一个非常宽裕的状态，但还没有跌破 20% 观察线。按近 7 日日均 7,896.46 计算，预计可用 983.64 天。
这里要注意一个判断细节：预计可用天数很长，不代表永远安全。它只是基于近 7 日样本推算。如果后续出现持续批量任务，日均消耗会被快速拉高。因此容量卡片应该保留，但目前优先级是“正常巡检”。
2. 2026-06-23 是最需要复盘的峰值日
近 7 日总确认消耗 55,275.2，其中 2026-06-23 单日消耗 40,325，占近 7 日总量的大部分，也约为近 7 日日均的 5.1 倍。
这说明系统不是平稳消耗，而是存在明显批量任务或集中调用。业务上应该优先追问：
- 当天是否有计划内批量生成、批量处理或第三方 API 任务
- 峰值是否集中在单一账号
- 峰值是否集中在单一服务场景
- 是否需要对该类任务建立事前预算和事后复盘
3. 账号集中度很高
用户消耗 Top 显示，chaoyouwenhua_lumi / 7641585408362430500 近 7 日确认消耗 48,865，占 88.4%。
这类集中度本身不是错误，但它把业务风险收敛到一个账号上。后续监控应该把这个账号列为重点观察对象，并为它建立单独阈值：
- 单日消耗超过日均 2 倍时提醒
- 单小时消耗超过固定阈值时提醒
- 连续多日占比超过 80% 时提醒
- 如果该账号不是计划任务账号，需要人工确认调用来源
4. 服务集中度也很高
服务构成图显示，创意画布 / thirdAPI 确认消耗 48,865，同样占 88.4%。第二位是 智能视频，确认消耗 6,408；智能生图 只有 2.2。
这说明当前算力主要花在创意画布相关的第三方 API 场景，而不是平均分布在多类业务上。业务上应该把服务预算拆成两层：
只看总余额会掩盖单服务异常，服务级预算能更早发现某个业务场景的失控。
5. 作品任务维度适合做追责和复盘
作品 / 任务排行里，多个 创意画布 任务单条消耗为 1,125。这类数据适合用来做事后复盘，而不是只做总览。
建议明细表保留以下字段：
| 字段 | 用途 |
|---|---|
work_id / task_id |
追踪具体作品或任务 |
work_name |
给业务人员快速识别 |
user_name |
定位责任账号 |
scene / sub_scene |
判断服务场景 |
confirmed / withholding |
区分已扣费和待确认 |
event_at |
回看任务发生时间 |
6. 当前没有预扣积压
当前预扣量为 0，说明样本里没有待确认或待释放的预扣堆积。这是一个健康信号。
不过预扣仍然应该放在顶部，因为一旦出现大额预扣，业务含义通常比较重要：可能是长耗时任务、异步生成任务、任务取消后的释放延迟，或者 Lumi 账务状态还没有最终确认。
7. 数据新鲜度正常，但需要系统化监控
当前最新一条消费来自 zhsm，服务是 智能视频，金额为 600，距离 Dashboard 生成时间约 5.9 小时。当前仍可视为正常。
但“数据新鲜度”不应该只靠肉眼看。后续需要新增采集运行记录表，例如 collector_runs，记录每次采集是否成功、写入多少条、失败原因是什么。监控系统本身也需要被监控。
顶部图表应该如何组织
最上方建议固定为“三图一表”。
| 区域 | 内容 | 目的 |
|---|---|---|
| 左侧容量卡 | 剩余比例、总额度、日均、可用天数、容量进度条 | 先判断是否有资金或额度风险 |
| 右侧趋势图 | 近 7 日确认消耗和预扣堆叠柱状图 | 找到峰值和异常日期 |
| 行动队列表 | 余额容量、峰值突增、账号集中度、服务集中度、预扣、数据新鲜度 | 把图表翻译成需要处理的业务动作 |
| 下方排行图 | 用户 Top、服务构成、作品任务 Top | 支撑行动队列里的定位和复盘 |
这样的顺序比单纯放排行榜更适合监控，因为它先回答“有没有风险”，再回答“风险来自哪里”。
推荐告警规则
后续可以把 business_signals 里的逻辑升级为告警规则。
| 规则 | 阈值 | 级别 |
|---|---|---|
| 余额低 | 剩余比例低于 20% | 中 |
| 余额危险 | 剩余比例低于 10% 或预计可用天数低于 7 天 | 高 |
| 峰值突增 | 单日消耗大于近 7 日日均 2 倍 | 中 |
| 账号集中 | 单账号占近 7 日消耗 60% 以上 | 中 |
| 服务集中 | 单服务占近 7 日消耗 70% 以上 | 中 |
| 预扣积压 | 预扣量大于 0 且持续存在 | 中 |
| 数据延迟 | 最新消费或最新采集超过 6 小时 | 观察 |
| 数据中断 | 最新成功采集超过 24 小时 | 高 |
当前数据触发的重点规则是：
- 峰值突增：2026-06-23 消耗 40,325
- 账号集中：
chaoyouwenhua_lumi占 88.4% - 服务集中：
创意画布 / thirdAPI占 88.4%
下一步优化方向
第一，补充采集运行表。建议新增 collector_runs，记录每次采集的开始时间、结束时间、状态、错误、插入条数、更新条数和聚合条数。没有这个表时，Dashboard 只能监控 Lumi 业务，不能监控采集器自身。
第二，沉淀预算阈值配置。当前阈值写在业务信号逻辑里，后续可以放到 config/config.yaml，例如账号阈值、服务阈值、峰值倍数、余额警戒线都应该可配置。
第三，增加日维度和小时维度的异常检测。当前 Dashboard 主要看近 7 日，后续可以加入小时级峰值，用来发现短时间异常调用。
第四，把 business_signals 作为 API 输出。无论未来是静态 Dashboard、定时刷新页面，还是 FastAPI 动态接口，都应该复用同一份业务信号，而不是让前端重复计算。
第五，建立告警通道。可以先从最简单的企业微信、飞书、邮件或 Telegram 开始，只推送高优先级信号，避免告警噪音。
最终业务逻辑
这个项目的业务逻辑可以总结为一句话：
用 SQLite 保存 Lumi 账务和消费事实，
用 Python 聚合出容量、趋势、账号、服务、任务和新鲜度，
用 Dashboard 把这些指标转成可执行的监控动作。
因此，当前 Dashboard 顶部最重要的不是“图表漂亮”，而是“图表能直接指向业务判断”。这也是后续从本地监控走向云端定时监控、准实时 Dashboard 和自动告警的基础。