常见问题

2021-6-29 About 23 min

# 常见问题

# 新建数据源保存失败

解决办法：查看 CBoard 源数据库连接配置是否正确，CBoard/src/main/resources/config.properties

validationQuery=SELECT 1
jdbc_url=jdbc:mysql://localhost:3306/cboard
jdbc_username=root
jdbc_password=111111

1
2
3
4

# Mysql 保存中文元数据乱码问题

进入 mysql 命令行, 查看 mysql 相关编码

mysql> show variables like 'character_set_%';
+--------------------------+---------------------------------------------------------+
| Variable_name | Value |
+--------------------------+---------------------------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | C:\Program Files\MySQL\MySQL Server 5.7\share\charsets\ |
+--------------------------+---------------------------------------------------------+
8 rows in set (0.00 sec)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

确保下面两项编码为 utf-8

| character_set_database | utf8
| character_set_server | utf8

1
2

character_set_server 如果编码不对，有两种解决方案，

修改 config.properties 里面 mysql 的 jdbc_url 添加参数 characterEncoding=utf-8

jdbc_url=jdbc:mysql://localhost:3306/cboard?characterEncoding=utf-8

如果你的数据源查询也出现了乱码, 或者本来有的数据加上中文条件之后查询不出来, 可以尝试通过同样的方式修复

参考这个网页，重新设置 mysql 服务 (opens new window), 设置完成之后，重新 cboard 数据库如果只有第一项数据库编码不对，可以先尝试 drop 掉 DB 之后重新创建 CREATE DATABASE cboard CHARACTER SET utf8;
MAC 用户修改 my.cnf, 在[mysqld]之后添加一行 character-set-server = utf8 behind

# 保存数据源提示InvalidKeyException: No installed provider supports this key: javax.crypto.spec.SecretKeySpec

如果使用的OracleJDK请升级jdk1.8的版本到1.8.0_162以上或1.8最高版本，或换成OpenJDK

# 保存数据源提示InvalidKeyException: Illegal key size or default parametersx

如果使用的OracleJDK请升级jdk1.8的版本到1.8.0_162以上或1.8最高版本，或换成OpenJDK

# 图表样式改变了看板上为什么没有生效

因为引用图加到看板的时候会复制一套首次加入看板时的样式配置, 这样才能做到一个引用图在不同的看板有不同的样式效果，如果引用图主图有样式更改，强行同步所有看板中的样式会导致看板中个性化配置被覆盖，当然您可以手工同步引用图的样式

# 看板分享为什么动态日期不生效

看板分享实例为带状态的链接，为了让分享查看者看到的数据与分享者相同，分享实例会包含分享实例生成时的日期值
动态日期的优先级低于分享实例参数赋值，所以当分享实例的日期参数有值时动态日期不会生效，如果分享日期用于看板集成需要动态日期，可以通过编辑分享实例的参数状态，删除日期参数对应配置即可

# 关于缓存

首先声明缓存使用场景是: 查询慢, 但是返回数据量不大的数据集(对此我们也特意对离线数据集结果集大小做了合理限制), 对于数据源聚合的数据集, 默认你的数据源应该有比较强的计算能力, 故系统不会对数据源聚合的数据集做缓存缓存从 0.1 到 0.4 经历了不同阶段的演进:

第一阶段: 最早引入 jvm 缓存是为了解决离线数据集太多之后, JVM 压力过大引起内存溢出, 为此首先想到的是采用 redis 把数据移到外部分布式缓存;
第二阶段: 考虑到 redis 本身也不是所有小规模公司都会有现成的集群, 在加上 redis 对于大规模的读写性能也不是太好, 我们引入了 ehchace 可以混用 JVM 和文件系统做存储
第三阶段: 上述两个缓存策略都还只是解决了存储问题, 大家知道 CBoard 存储离线数据集之后是需要二次聚合操作的, 这就需要 CBoard 从 redis/ehcahce 里面把数据从 JVM 堆外读到堆内, 然后用最早的 JvmAggregator 做二次聚合操作. 实践下来, 这个过程当中两次 IO 加上大量的 JVM 计算开销, 性能并不好; 如是就有了内嵌数据库 h2, 该数据库可以把数据存在内存或者文件系统, 同时还可以做聚合操作, 相比如自己实现的聚合算法性能还非常好, 同样有帖子对此做跟踪解释关于 redis 缓存 (opens new window), 下面是 config.properteis 里面 h2 相关配置:
```
# Storage File Syatem
# 1 Stores data in file system
aggregator.h2.url=jdbc:h2:~/H2Data/cboard;AUTO_SERVER=TRUE;LOG=0;UNDO_LOG=0
# 2 Stores data outside of the VM's heap - useful for large memory DBs without incurring GC costs.
#aggregator.h2.url=jdbc:h2:nioMemFS:cboard;LOG=0;UNDO_LOG=0
aggregator.h2.database.name=cboard
```
1
2
3
4
5
6

# 为什么交叉表数据不全

为了让BI系统能以较高的性能运行，我们在以下场景做了数据量上限控制，防止误操作导致系统卡顿、内存压力过大甚至宕机发生

配置项	解释
dataprovider.agg.resultLimit	聚合结果集大小限制，所有汇总类型的图表，实际执行查询之后返回数据量都受该配置限制，调大会增加服务端压力, 默认:1万
dimension.member.resultLimit	维度成员查询返回结果集大小限定，影响维度过滤框加载维度成员与看板参数下拉框选择加载，默认:2000
dataprovider.resultLimit	离线数据集缓存大小限制，默认:30万

交叉表数据不全一般是受dataprovider.agg.resultLimit影响

注意

问: 但是有些用户可能会说，我的交叉表数据行明明就不到默认的1万行，为什么还是数据不完整呢？
答: 那是因为上面配置项控制的是多维计算处理之前的数据量，如下图所示，设计1和设计2发起的数据库查询脚本是一模一样的，都是4行数据(对应聚合结果集大小限制)，设计1的性别在行维，展示在交叉表记录数为4行，设计2的性别在列维，展示记录数为2行，也就是我们俗称的行转列操作，所以行转列之后行记录数可能会减少，前端交叉表显示的不到1万行，实际在后天汇总实际可能已经超过阈值了

该配置在v1.10支持配置页面，管理员可以进行更新

在v1.10之前可通过添加配置项修改, 或者修改系统运行配置文件

# 关于企业版

# 为什么要做商业版

随着时间推移, CBoard 从开源到商业历时6年多时间, 从默默无闻到现在越来越多的用户开始接受, 并且在大大小小的众多公司得到了很好的实践与生产检验. 这个过程当中我们没有做过任何市场推广与宣传.

同时两年多时间我们培养了一大批用户, 包括之前从来没有接触过 BI, OLAP, 多维分析概念的用户, 这让我们感到欣慰. 但是真正参与项目社区开发的人少之又少; 再加上从一开始这个项目就没有得到公司的支持, 只是社区上几个小伙伴利用工作之余的时间进行开发与维护(当中付出了无数工作日的夜晚与节假日). 这种状态下, 几个开发者本质工作稍微有些变动或是公司政策上稍有约束就不能继续参与到项目开发中来, 确实我们几个开发者都经历这种遭遇, 类似单点故障, 这样的结果当然是发起者和用户都最不愿意看到的.

在这个过程当中, 我们见过太多从一开始就想在社区产品之上独立二次开发包装成自己产品, 导致在社区版有重大更新的时候和项目脱节; 又或是用户投入了大量的人力物力, 结果开发思路就和产品本身不符合, 最终半途而废; 经过很长一段时间的挣扎, 我们决定依托于商业支持主导项目的发展.

# 企业版的定位

企业版后期的定位是在尽量提供通用分析能力的基础上, 做一个开放的 BI 产品开放平台, 允许用户和二次开发商能够自定定制 UI 与交互形式. 一方面兼容社区版的 CBoard 的元数据与操作流程, 另一方面在核心前后端 SDK 丰富的前提下用户可以基于之前社区版主要设计理念做自己的定制开发工作. 最重要的是保证性价比还要高, 让大家都能用得起;

Business Object 性能调优