跳到主要内容

统计分析

引用文件

本文引用的文件

目录​

  1. 简介
  2. 项目结构
  3. 核心组件
  4. 架构总览
  5. 详细组件分析
  6. 依赖分析
  7. 性能考量
  8. 故障排查指南
  9. 结论
  10. 附录

简介​

本技术文档围绕统计分析系统，系统性阐述播放量统计机制（广告播放次数、设备启动次数、用户观看时长等核心指标）、用户行为分析（偏好、设备使用习惯、区域分布）、区域分布与时段分析（24小时趋势、周/月周期、节假日效应）、TDengine 时序数据库的应用（数据模型、查询优化、压缩策略），以及统计 API 与数据导出能力。文档同时提供最佳实践与性能优化建议，帮助读者快速理解并落地实施。

项目结构​

统计分析模块位于文档目录 docs/analytics 下，包含多个专题文档，覆盖 APP 运行记录、设备日活、APP 安装列表等关键主题；配套的 TDengine 数据模型 SQL 位于 sql/tdengine 目录。整体呈现“文档 + 数据模型 + 实践总结”的结构。

Mermaid Diagram Code:

graph TB
A["数据分析-概览"] --> B["APP运行记录管理"]
A --> C["设备日活统计管理"]
A --> D["APP安装列表"]
B --> E["TDengine 乱序插入压缩问题"]
B --> F["APP运行记录建库建表"]
C --> G["设备运行时长建库建表"]
D --> H["APP安装统计建库建表"]

图表来源

章节来源

核心组件​

  • 数据采集与上报
    • 设备端按日汇总上报 APP 运行记录与 APP 安装列表，亦支持事件上报接口（APP_RUNTIME、APP_INSTALL）。
    • 网关/API 接收后写入 Kafka 消息队列，供下游消费者处理。
  • 实时处理与离线分析
    • Kafka 消费者统一清洗、校验、入库（TDengine 热表/归档表、MySQL 元数据表）。
    • XXL-JOB 定时任务完成维度转换、聚合统计与归档。
  • 存储与归档
    • TDengine 热表保留近期数据，历史数据通过归档流程有序重写，显著降低存储成本。
  • 前端与导出
    • 提供一级/二级页面查询、同步/异步导出能力，异步导出通过导出任务模块跟踪进度。

章节来源

架构总览​

下图展示从设备上报到 TDengine 存储、统计与归档的全链路流程。

Mermaid Diagram Code:

flowchart TD
subgraph 设备端
Dev[设备] --> GW["网关/API"]
end
subgraph 中间件
GW --> KFK["Kafka Topic: app-runtime-list / app-install-list"]
end
subgraph 后端服务
CON["AppRuntimeConsumer / AppInstallListConsumer"]
JOB1["AppRuntimeJob / appInstallDeviceToPackage"]
JOB2["appinstallCountByPackageName"]
ARCH["AppRuntimeArchiveJob"]
end
subgraph 存储层
TDHOT["TDengine 热表"]
TDARCH["TDengine 归档表"]
MYSQL["MySQL 元数据/统计表"]
FILES["本地/远程文件系统"]
end
Dev --> KFK
KFK --> CON
CON --> TDHOT
CON --> MYSQL
JOB1 --> MYSQL
JOB2 --> MYSQL
ARCH --> FILES
FILES --> TDARCH
ARCH --> MYSQL

图表来源

详细组件分析​

播放量统计机制（广告播放次数、设备启动次数、用户观看时长）​

  • 指标定义
    • 广告播放次数：通过事件上报接口上报的广告播放事件进行累计。
    • 设备启动次数：设备心跳或开机事件触发的启动计数。
    • 用户观看时长：APP 运行记录中的运行时长与打开次数，按设备/包名/版本号聚合。
  • 实时统计
    • 设备端按日汇总上报运行记录；事件上报（APP_RUNTIME）实时进入 Kafka，由消费者清洗后写入 TDengine 热表。
    • 包名与 APP 名称通过包名库映射，异常包名可配置为不统计。
  • 历史数据存储
    • 热表保留近期数据，历史数据通过归档任务有序重写至归档表，显著降低存储成本。
  • 查询与导出
    • 一级页面按月统计结果来自离线聚合表，二级页面支持按设备/日期范围查询实时明细。
    • 大数据量采用异步导出，小数据量支持同步导出。

Mermaid Diagram Code:

sequenceDiagram
participant Dev as "设备"
participant API as "网关/API"
participant MQ as "Kafka"
participant C as "AppRuntimeConsumer"
participant TD as "TDengine 热表"
participant S as "统计任务(AppRuntimeJob)"
participant M as "MySQL 统计表"
Dev->>API : "上报运行记录/事件(APP_RUNTIME)"
API->>MQ : "写入 app-runtime-list"
MQ-->>C : "消费消息"
C->>C : "清洗/校验/包名映射/任务关联"
C->>TD : "写入热表"
C->>M : "更新关联任务状态"
S->>TD : "读取热/归档表(按月)"
S->>M : "写入月报统计"

图表来源

章节来源

用户行为分析（偏好、设备使用习惯、区域分布）​

  • 偏好分析
    • 包名统计：按 APP 包名与版本号聚合，统计安装设备数与打开次数，辅助判断用户偏好。
    • 设备统计：按设备维度查看安装 APP 明细，支持跨月快照还原。
  • 设备使用习惯
    • 设备日活统计：基于心跳上报统计日活，支持按 MAC/CPU/地区筛选。
    • 设备运行时长：按日/月/年稳定表统计设备运行时长，支持按记录时间维度聚合。
  • 区域分布特征
    • 日活列表支持按地区筛选，结合设备维度数据进行区域分布分析。
    • APP 安装列表支持按地区维度的包名统计与设备统计联动分析。

Mermaid Diagram Code:

flowchart TD
A["设备上报(心跳/安装/运行)"] --> B["Kafka 消费入库"]
B --> C["TDengine 热/归档表"]
B --> D["MySQL 元数据/统计表"]
C --> E["日活/运行时长/安装统计"]
D --> E
E --> F["区域分布/偏好分析"]

图表来源

章节来源

区域分布分析（省市区、运营商、网络类型等）​

  • 数据来源
    • 日活统计列表包含地区字段，支持按地区筛选与导出。
    • APP 安装与运行统计可结合地区维度进行交叉分析。
  • 聚合与可视化
    • 通过前端页面按地区维度聚合设备数量、安装设备数、运行时长等指标，支持导出用于进一步可视化。

章节来源

时段分析（24小时趋势、周/月周期、节假日效应）​

  • 24小时趋势
    • 基于运行记录的 record_time（设备端统计时间）与 create_time（服务器入库时间）进行小时级聚合，观察设备活跃与运行高峰。
  • 周/月周期
    • 按日/周/月维度聚合日活与运行时长，识别周期性波动。
  • 节假日效应
    • 结合日历事件与日活/运行时长对比，评估节假日对设备活跃度与使用时长的影响。

章节来源

TDengine 时序数据库应用​

  • 数据模型设计
    • APP 运行记录：超级表包含包名、日期等标签，主键 data_key 与时间戳，关键指标（版本号、时长、打开次数）标注为高优先级压缩级别。
    • 设备运行时长：按日/月/年建立稳定表，标签记录时间维度，便于按周期查询。
    • APP 安装统计：按包名与设备维度建立统计表，标签含统计月份，便于月度对比。
  • 查询优化
    • 利用标签过滤与时间范围扫描，减少数据扫描量。
    • 热/归档双库策略：近期查询走热表，历史查询走归档表，平衡性能与成本。
  • 数据压缩策略
    • 归档流程通过“乱序导出 -> 压缩 -> 有序重写”恢复列式压缩优势，压缩比从 30%+ 降至 5% 左右，磁盘占用降低约 7.68 倍。
    • 建议在应用层尽量保持写入时间有序，或通过归档流程恢复有序性。

Mermaid Diagram Code:

erDiagram
FLOW_APP_RUNTIME {
timestamp record_time
varchar data_key PK
varchar mac
varchar cpu_id
int version_code
int duration
int open_time
timestamp create_time
}
TAGS {
varchar package_name
int day
}
FLOW_APP_RUNTIME ||--|| TAGS : "按包名/日期分桶"
DEVICE_RUNTIME_COUNT_DAY {
timestamp ts
varchar data_key PK
varchar mac
varchar cpu
int device_duration
}
TAGS2 {
int record_time
}
DEVICE_RUNTIME_COUNT_DAY ||--|| TAGS2 : "按 record_time 分桶"

图表来源

章节来源

统计 API 与数据导出​

  • 统计 API
    • 事件上报接口：/task/recoedDeviceEvent（事件类型：APP_RUNTIME、APP_INSTALL）。
    • 网关/API：接收设备上报，写入 Kafka，供消费者处理。
  • 数据导出
    • 同步导出：适用于中小数据量，点击即返回结果。
    • 异步导出：大数据量采用异步导出，通过导出任务模块跟踪进度与下载文件。

章节来源

依赖分析​

  • 模块耦合
    • 数据分析模块与设备管理、渠道信息、首页看板、导出任务模块存在强关联。
    • 存储层依赖 TDengine 热/归档库与 MySQL 元数据表。
  • 外部依赖
    • Kafka 消息队列承载设备上报数据的统一接入。
    • XXL-JOB 调度离线任务与归档作业。

Mermaid Diagram Code:

graph TB
subgraph "前端"
UI["数据分析页面"]
end
subgraph "后端"
SVC["业务服务"]
MQ["Kafka"]
TD["TDengine"]
DB["MySQL"]
JOB["XXL-JOB"]
end
subgraph "设备端"
DEV["设备"]
end
DEV --> SVC
SVC --> MQ
MQ --> TD
MQ --> DB
JOB --> TD
JOB --> DB
UI --> SVC

图表来源

章节来源

性能考量​

  • 写入顺序优化
    • 保持写入时间有序，避免 TDengine 因频繁回写旧块导致压缩比劣化与磁盘膨胀。
  • 冷热分离
    • 热表保留近期数据，历史数据归档至归档库，兼顾查询性能与存储成本。
  • 并发与批处理
    • 归档阶段采用多线程与批量写入，提升吞吐量。
  • 监控与告警
    • 持续监控磁盘占用与压缩比，识别异常并及时优化。

章节来源

故障排查指南​

  • 归档失败
    • 检查归档记录表状态，确认失败日期与错误信息；利用自动重试机制扫描并重试最近 N 天失败任务。
  • 数据缺失或延迟
    • 核对 Kafka 消费状态与 TDengine 写入日志；检查设备上报时间与服务器时间偏差。
  • 查询性能异常
    • 确认查询时间范围与标签过滤是否合理；必要时切换至归档库查询。

章节来源

结论​

统计分析系统通过“设备上报 -> Kafka -> 实时清洗入库 -> 离线聚合 -> 归档优化”的全链路设计，实现了播放量、设备启动次数、用户观看时长等核心指标的实时统计与历史归档。配合 TDengine 的冷热分离与归档策略，系统在保证查询性能的同时显著降低了存储成本。建议在应用层保持写入有序或通过归档恢复有序性，并结合监控体系持续优化。

附录​

  • 相关模块入口
    • 数据分析模块入口与关联模块详见“数据分析-概览”。

章节来源

用户文档
AI 助手
Agent 列表
请选择一个 Agent 开始对话
AI 问答