BI（商业智能）

BI 核心：接入多源数据、建模、自助分析、仪表盘 / 大屏、报表、嵌入业务系统；区分【通用 BI】和【时序 / 地图 IoT 专用可视化】

国产商用 BI

帆软 FineBI / FineReport

优势：国内占有率最高，大屏能力强、地图组件丰富、权限体系完善、私有化部署、支持国产数据库；支持嵌入 Web；报表 + BI 一体；
短板：价格偏高；复杂实时高频轨迹性能一般（高频点位回放不适合）

瓴羊 Quick BI（阿里）

优势：阿里云原生，SaaS / 私有化，对接 MySQL、MaxCompute、时序库；地图组件成熟；支持嵌入；成本适中
短板：自建机房离线部署方案不如帆软成熟
适合：上云项目、阿里云生态、大屏看板

观远数据、派可数据、永洪 BI

永洪：大数据量、MPP 内置，自助分析强；
观远：偏向业务敏捷、自然语言问数；
派可：私有化、国产化适配强

国外：Power BI（微软）Tableau

开源 BI

DataEase（飞致云，国内最火开源 BI） ✅ 中文友好、拖拽大屏、内置地图、支持 MySQL/PostgreSQL、时序库、API 数据源；Docker 一键部署；支持嵌入 iframe；社区活跃；免费商用 ⚠️ 超大数据量、高频实时刷新性能一般；自定义地图图层需要二次开发

Apache Superset ✅ 开源老牌，SQL 优先，大数据（ClickHouse、Doris）友好；适合指标分析 ⚠️ 英文原生、大屏弱、地图组件简陋、上手门槛高

Metabase：极简、SQL 查询 + 看板，适合内部快速报表，大屏弱

Datart：国产开源 BI，权限完善、嵌入友好，适合项目集成

Grafana = 时序监控可视化 ，不是 BI：擅长 Prometheus、InfluxDB、TDengine，高频 IoT、传感器、车辆实时时序指标；地图轨迹回放、点位实时刷新非常强；但弱在多表关联、复杂业务指标建模、中国式报表。

技术架构

多数据源接入 → 数据抽取 / 计算引擎 → 语义模型层 → 可视化渲染层 → 权限 & 调度 & 对外服务

不同厂商差异主要在计算引擎、是否 MPP、存储模式、云原生改造程度。

A 类：报表 + BI 一体化（帆软 FineBI/FineReport）：偏向服务化、中国式报表、大屏、混合计算
B 类：MPP 原生 BI（永洪 BI）：内置分布式 MPP，面向大数据自助分析
C 类：云原生 SaaS BI（瓴羊 QuickBI）：轻计算，依赖外部数仓（MaxCompute/ClickHouse）

标准分层架构

复制代码

【前端可视化层】
        ↓
【应用服务层（权限、调度、分享、嵌入、API）】
        ↓
【核心计算&语义模型层（最关键差异点）】
        ↓
【数据接入层】
        ↓
【底层数据源】

底层数据源（接入层）

关系库：MySQL、PostgreSQL、Oracle、达梦、人大金仓、OceanBase、GaussDB
数仓 / OLAP：ClickHouse、Doris、StarRocks、Greenplum、Hive
时序库：TDengine、InfluxDB
文件：Excel、CSV
API：HTTP 接口
其他：Kafka、FTP

数据接入模式

直连模式（实时）：BI 不存数据，查询下发 SQL 到源库；适合工单、业务实时指标；压力落在业务库
抽取模式（离线 / 准实时）：定时 ETL 拉到 BI 内置引擎；适合高频自助分析、大报表，隔离业务库压力

时序 GPS 轨迹一般不进 BI 内置引擎，BI 只消费聚合后的统计指标（里程、在线时长、报警数量），原始轨迹放 TDengine等时序库

核心计算 & 语义模型层

（1）语义层（业务数据模型

屏蔽底层表结构，给业务人员用：

物理表关联、维度 / 指标定义、计算字段、过滤、权限行级过滤
支持行权限、列权限（环卫项目：不同片区管理员只能看自己片区车辆）
支持参数、联动、动态过滤；和报表、大屏、自助分析共用一套模型

帆软叫「业务包」；永洪叫「数据集 / 数据模型」；QuickBI 叫「数据集 + 模型」

（2）计算引擎（三大路线）

路线 1：帆软模式【混合引擎：本地内存引擎 + 直连 SQL 下发 + 分布式集群】

抽取后数据存内置列式文件引擎（FineData 引擎），单机内存优先，集群分片
不是完整 MPP，偏向轻量汇总、交叉报表、中国式复杂报表
大查询优先下推 SQL 到源库（ClickHouse/Doris），BI 只做上层二次渲染计算
特点：报表能力极强，复杂表头、分组、分页、打印、导出是强项；海量明细自助分析弱于永洪

路线 2：永洪 BI【内置分布式 MPP 列式引擎（Yonghong Z-Engine）】

自带 MPP，数据抽取进入 BI 自身分布式列式存储
分布式分片、向量化、压缩，适合亿级明细自助拖拽、多维度下钻
代价：数据要入仓，存储成本高；复杂中国式报表不如帆软顺手
适合：运营多维分析、车辆运行明细多维度统计

路线 3：QuickBI【无重型内置引擎，计算下沉外部 OLAP】

本身只做语义层、可视化、SQL 代理；计算全部下压到 MaxCompute/ClickHouse/Doris
云原生无状态，弹性好；私有化版本依赖外部数仓
适合阿里云生态，不适合单独扛大量计算

应用服务层（管控中台）

所有国产商用 BI 必有的模块：

权限中心：用户、角色、组织、资源权限、行级权限 RLS、列脱敏（环卫敏感：驾驶员信息、车辆位置脱敏）
任务调度：定时刷新数据集、定时报表推送、预警告警
嵌入 SDK / OpenAPI：
- iframe 嵌入、JS 嵌入、单点登录 SSO（OAuth2、CAS、LDAP，和你 SpringBoot/OIDC 打通）
- 报表导出 PDF/Excel、获取图表数据接口（你的 Vben 大屏可以调 BI 指标接口）
版本、水印、审计日志、操作日志（等保 2.0 必备）
消息推送：邮件、钉钉、企业微信

前端可视化层

自助分析：拖拽数据集、图表、筛选、联动、钻取
报表模块：复杂分组、交叉表、斜线表头、套打（FineReport 最强）
大屏驾驶舱：拖拽布局、动画、轮播、地图组件
- 内置地图：高德 / 百度底图、GCJ02 支持；但原生地图只适合点位聚合、热力图；不适合轨迹回放、动态车辆移动
移动端：H5、App、钉钉 / 企业微信集成

列式文件（列式存储文件）

存储	存储形态	适用场景
MySQL InnoDB	行式	工单、车辆基础信息、业务主库，频繁增改
TDengine	时序列式（按时间片 + 设备）	GPS 轨迹、速度、上报时序点，高频写入 + 范围查询
ClickHouse	列式数据库（底层 Parquet 类列式文件）	车辆聚合统计、大报表、多维下钻
FineBI FineData	自研私有列式文件	BI 抽取数据集，自助分析、报表缓存，BI 独占
Parquet	开源列式文件	数据湖、Doris、Spark，跨引擎交换

ClickHouse / Apache Doris

两者都是列式 OLAP，面向海量分析；

CK 单表扫描 / 聚合更强、适合流水日志；

Doris MPP + 标准 SQL、Join / 更新 / 并发更强、更适合对接 BI、多表业务报

时序数据库

时序库（InfluxDB/Timescale/TDengine）

行业标准最佳实践：冷热分层组合方案（推荐） Redis（热：最新位置 + 在线状态） + TDengine（温：最近 30 天轨迹，回放主力） + ClickHouse（冷：归档，>30 天统计 / 导出）

如果项目大量电子围栏、区域报警、地理运算：替换 TDengine → TimescaleDB + PostGIS

轨迹数据特征

时序为主：每条轨迹带 GPS 时间（gps_time）+ 报文流水号 + 终端 ID；存在乱序、后发先至（补发），不是单纯 append
写入量大：单车 10s / 条，1 万台：6w/min；十万车就是 60w/min
冷热分明：最近 1~7 天高频回放查询；超过 30 天极少访问，长期归档
去重刚需：同一条 0x0200 多次补发，依靠 terminal_id + msg_sn 唯一键去重
字段：终端号、GPS 时间、接收时间、经纬度、速度、方向、定位状态、报警位、附加信息（里程、油量等）