FineBI6.1灵活开发与系统性能

用户使用 FineBI 时，需要培养良好的使用习惯，提高 FineBI 系统的敏捷度。

在FineBI中，展现速度是随着仪表板组件的复杂程度而各有不同的，组件越复杂，展现速度越慢。

此处列出一些会导致性能表现差异的因素，和它们对应的时间指标。

2.1 整体表现

对 FineBI 的抽取数据来说，最大支持的底表数据量是1亿（行），在不超过此限制的情况下，单组件响应时长应在 3 秒内，仪表板有 15 个组件时，响应时长应在 30 秒内。

2.2 复杂组件展现表现

1）1亿行以下的分组表

• 以下场景在3秒以内展现出来是合理的：

• 求记录数

• 去重计数
  

• 快速计算：环期值、环期比、同期值、同期比

• 日期函数计算：DATEDELTA、DATETINUMBER、DAY、DAYSOFMONTH、DAYSOFYEAR、DAYVALUE、DECOND、FORMAT(数值，数值）、FORMAT（数值，文本）、HOUR、MINUTE

• 汇总计算：求和、平均、最大值、最小值、中位数、方差、标准差

• 合计方式：自动、中位数、平均、方差、最小值、标准差

• 指标排序、维度依赖指标排序、维度排序

• 过滤：TopN（Top10）、汇总
  

• 合计联动、指标联动、维度联动

• 复杂场景：公式计算+记录数去重计数：聚合函数嵌套IF嵌套AND嵌套日期函数+去重计数、公式计算+过滤组件：日期函数+时间动态过滤组件、日期函数+时间过滤组件、聚合函数嵌套IF嵌套AND嵌套日期函数+数值过滤组件、维度自定义排序&过滤+快速计算公式+数据条

• 以下场景在5秒以内展现出来是合理的：

• 函数计算：len、datedif 、datesubdate、 daysofQuarter、def_add 、def_sub

• 分组数不大于10万的数据条

• 跳转：明细表跳转到明细表、明细表跳转到分组表、分组表跳转到明细表
  

• 复杂场景：公式计算+公式过滤：日期函数+聚合函数+公式过滤、公式计算+快速计算：SWITCH十层嵌套+聚合函数+快速计算

2）明细表

在不做复杂计算、数据集行数在1kw以内的情况下，100列指标和50列指标的明细表，都应在3秒以内展现出来。

3）交叉表

在做了一次计算/二次计算/日期分组/自定义分组/汇总的情况下，普通单场景的交叉表，都应在3秒~6秒展现出来。

注：如果在大表多行多列的情况下，出现了100w个分组，在数据量的行数大于1kw，字段列数大于100，则导致取数性能风险，其中行数6kw100列以及行数在1ww~5ww的数据取数都是在20s内是合理的。

2.3 导出表现

固定配置下，单元格越少、分组数越低、计算越简单，系统能支撑的最大并发数越大。超过推荐的最大并发数时系统仍然支持，不会报错，但响应时间将大于等于单独导出时的3倍。

导出时长包括两部分

• 准备导出时长：开始导出至服务端导出数据准备完毕的时长。该段时长依赖于计算速度，主要由工程分配内存和模板本身的计算量有关。

• 数据传输时长：服务器数据传回客户端以完成请求响应的时长。该段时长受网络传输、浏览器、网络环境、服务器等因素影响。

Excel导出耗时分三部分，服务端准备导出+服务端传回浏览器+浏览器下载耗时，前两部分耗时由2个请求分别完成。本测试结果仅记录前两部分耗时，第三部分耗时由浏览器下载网速和文件大小决定。

注：6.0版本下载耗时会记录在请求中，但6.1版本取消了这一设计，下载耗时仅由浏览器自身决定。

1）不同类型表的导出特性

2）表格导出性能表现标准

• 6.1与6.0版本性能表现一致。

3）图表导出性能表现标准

区别于表格导出，图表的计算一般不会太复杂，分组数也相对较少，压力在于生成截图或pdf。

对于图表组件，导出单元格2千左右，建议不超过150并发；定时调度导出图表建议不超过40并发（并发数与通知人数、模板个数相关）。

2.4 数据集性能表现

1）单步骤数据集编辑6.1与6.0性能相比：

• 无权限场景：

与6.0版本对比，78.77%场景有性能提升，0.56%场景有性能下降，20.67%场景性能相当。

• 有权限场景：

与6.0版本对比，65.46%场景有性能提升，5.29%场景有性能下降，29.25%场景性能相当。

性能提升的场景示例：

性能偏弱的场景示例：

2）多步骤数据集编辑6.1与6.0性能相比：

与6.0版本对比，50.89%场景有性能提升，1.57%场景有性能下降，47.54%场景性能相当。

性能偏弱的场景示例：

2.5 数据更新性能表现

1）全量、增量更新

6.1版本原始表（全量、增量）更新性能和6.0.x版本相比基本一致；

2）关联更新

6.1引擎升级，关联更新对比6.0版本很快，因为6.1版本不再生成关联缓存文件，只是配置了一层关联关系。

3）自助数据集更新

• 单步骤数据集更新

与6.0版本对比，76.57%场景有性能提升，5.94%场景有性能下降，17.48%场景性能相当。性能下降的主要是行转列：去重计数/记录个数+大分组多列的场景。

性能提升的场景示例：

性能偏弱的场景示例：

• 多步骤数据集更新
  

与6.0版本对比，49.50%场景有性能提升，39.60%场景有性能下降，10.89%场景性能相当。

性能提升的场景示例：

性能偏弱的场景示例：

4）全局更新

6.1更新耗时对比6.0有30~40%的提升，磁盘在gc后占用相对6.0会少50%~70%。

2.6 主题模型性能表现

主题模型6.1与6.0性能相比：

• 与6.0版本对比，62.50%场景有性能提升，33.33%场景有性能下降，4.17%场景性能相当。大多数主题模型计算场景都有性能提升，主要包括维度表分析事实表、维度事实表共同分析维度事实表等。性能下降的场景主要有：主题模型+指标排序、主题模型+交叉表聚合计算等。

性能提升的场景示例：

性能偏弱的场景示例：

3.1 基础数据集

通用规范

1. 添加基础数据集时，数据集个数建议不超过100个且数据编辑步骤数不超过10，数据集个数增多对性能会有一定程度的影响。

2. 如果需要对基础表进行字段类型转换，建议改成SQL表，在SQL中进行字段类型转换。

3. 若数据表在数据库中查询超5s，则不推荐添加成DB表，建议优化数据库中对应的表SQL（直连+抽取）。优化过程参考一份非常完整的MySQL规范、SQL 性能起飞了。

4. 建议使用的基础表数据量不超过1kw，或者先过滤到1kw再进行分析。

Excel数据集使用

1）导入Excel时，上传的Excel表不超过2000w个单元格，若数据量过大，会导致导入慢，或造成前端卡死。

因此建议：

1. 限制单个Excel导入的文件大小在100M以下。

2. 去除Excel中无用行/空行，只保留有效数据。

3. Excel落库，通过添加SQL表或DB表的形式替代。

2）如果在直连模式下使用excel，制作大量自助数据集，且自助数据集的血缘层级很深，对拥有复杂血缘的自助数据集数据集进行编辑、预览、制作组件等操作时，容易占用大量内存造成宕机。

因此建议：

1. 使用Excel进行数据分析时，如非必须使用实时数据的场景，建议在抽取数据下添加Excel。

2. 直连模式下的Excel表不建议超过10w行。

3. Excel与其他数据集进行融合分析时，数据集所在的最深血缘层级不能超过3层。

直连sql数据集使用

1. 创建SQL数据集时，避免写非常复杂的SQL语句，查询时间不超过5s。若SQL表的查询时间过长，使用SQL表制作仪表板和自助数据集只会更慢。可将一个表分成若干部分，减少单次扫描的数据量，提升效率。

2. SQL书写性能规范：

1. 使用 SELECT 语句时，应指出列名，只取需要的字段，不应使用列的序号或者用“*”替代所有列名，所有操作尽量明确指定列名。

2. 大表关联查询语句中，做到先过滤再关联，不允许使用WHERE来进行关联。

3. 如果SQL语句中有多处重复的子查询，可以将其提取出来，进行参数化，减少数据库查询次数。减少子查询（嵌套查询）至三层以内（即三次以内的左右合并、上下合并），嵌套太多则会影响最终展现的性能。

4. 减少不必要的扫描计算。如果UNION ALL可满足要求，就使用UNION ALL，而不用UNION，因为UNION会有一个比较然后去重的过程，而UNION ALL没有。

5. 避免对大表的全表扫描操作，经常查询的大数据量表，需要在数据库底表中创建索引，过滤和排序尽量放在索引列上操作，提高SELECT效率，WHERE 语句尽量避免使用函数和算数运算等。

6. 区间范围比较（特别是索引列比较）要有明确边界，降低比较时的计算精度，用>=、<=代替>、<。

7. 大表查询时，避免不必要的排序，排序需放在执行计划最后一步。尽量在子查询中避免ORDER BY、DISTINCT等语句。其中ORDER BY是对结果进行排序，而DISTINCT和GROUP BY是在计算过程中排序。子查询数据量较大时用EXISTS子句代替DISTINCT。

8. 检测 SQL 逻辑是否笛卡尔积，或者检测数据量是不是太大，数据量大的情况就采用分表、分区、瘦身、合并、索引等数据库策略。

3. 合理使用直连缓存。参考【直连】缓存设置，对高频使用但每次查询性能较差的数据集，可依据数据时效性配置缓存功能，减少数据库查询，提升展示效率。

3.2 自助数据集（在主题数据编辑后发布的表）

字段数建议

1. 选字段字段数建议不超过30个。

2. 创建自助数据集，在选字段阶段应只选择需要用到的字段，不建议直接全选，避免造成服务器物理空间浪费与更新耗时增加

步骤数建议

1. 单个数据集数据处理步骤不超过 15步。

2. 新增列不超过 10列。

3. 左右合并步骤不超过 3 步。

4. 分组汇总步骤不超过 3 步。

超过推荐步骤数，建议转化成数据库表再加入使用。

步骤顺序建议

1. 优先对数据进行过滤，不要用全部数据进行计算。

2. 大数据量排序性能不佳，把排序的步骤尽量放在过滤步骤之后。

3. 新增公式列后再对新增列进行排序或者汇总，性能会非常差，建议减少在新增列后使用排序和汇总。

步骤类型建议

1. 左右合并、分组汇总、其他表添加列、行列转换 步骤性能偏弱，数据量大于 1000w 行时尽量减少使用，若超过1kw则先进行过滤以减少数据量。

2. 左右合并/其他表添加列避免出现 N:N 情况，若逻辑需要 N:N，控制笛卡尔积后的数据量不超过 1000w 行。

3. 分组汇总字段总数不超过10个，包含汇总条件的字段数不超过3个，结果不超过 1000w 行。

4. 新增列计算性能和函数复杂度强相关，函数公式越复杂性能越差；使用DEF函数的字段不超过3个，且避免嵌套；新增列-所有值汇总、新增列-汇总值含分组 性能偏弱；数据处理公式 同比环比等日期形式的计算在组件中「快速计算」中进行。

5. 字段设置-字段类型转换建议在SQL表中使用SQL语句进行字段类型转换。若自助数据集最简表中有字段类型转换操作，建议增加步骤，使表抽取到本地。

若步骤公式过于复杂，建议转化成数据库表再加入使用。

血缘层级

自助数据集血缘关系过于复杂时，会导致基础表、自助数据集更新慢，相关基础表长时间无法使用。

因此建议：

1. 抽取自助数据集所在的最深血缘层级，建议不超过 5 层。

2. 直连数据集所在的最深血缘层级，建议不超过 2 层。

若超过，建议通过SQL数据集实现，或下沉到数据库表再通过添加DB表添加使用。

3.3 主题模型

• 主题内数据模型，默认关联上限为 100 张表

• 如果使用主题模型，自助数据集不能有复杂计算步骤
  

• 数据模型建议使用星形结构、雪花结构，详情请参见文档：主题模型的官方使用推荐

• 不推荐使用交叉表，使用复杂场景
  

• 尽量不要使用模型的N:N关联表分析，会降低性能水平，且膨胀易有限制报错。场景示例：

• A:B=n:n，使用A、B进行分析

• A:B=1:N，A:C=1:N  使用B、C进行分析

• 过滤组件绑定多张N端表字段进行过滤

4.1 组件效果选择

组件选择优化建议：

1. 组件类型简化：如无必须使用图表组件的场景，使用表格组件代替；交叉表仅使用行维度或列维度时，使用分组表代替。

2. 分析维度简化：使用诸如柱形图、条形图、散点图等图表时，尽量选取更高效的分析维度，分析维度不宜过多，在 30 个之内。

3. 数据展示简化：原始表行数在1kw以上时，不建议开启指标数据条。

4. 数据量级简化：使用大分组图表（分组超过5k）时，建议降低主题的数据量。

4.2 组件字段数/数据量

数据量优化建议：

1. 减少字段总数量：组件个数不超过30个，组件使用到的计算字段数不超过50个，在主题内的数据集，可以通过字段设置取消勾选不会用到的字段，以限制可能被组件使用的字段数量；同时需要定期检查，去除无用字段。

2.减少编辑预览计算数据量：编辑组件时，取消分组表/图表组件的“查看所有数据”，取消勾选即使用部分数据（1万条）查询，可以显著提升性能体验。

4.3 组件计算

• 组件中新增计算指标时，若新增指标多、公式复杂，会导致计算慢，进而导致计算线程池满，造成系统卡慢。仪表板有很多的字段和计算指标，编辑状态下，添加、删除、移动字段前端响应慢。同时，若有些字段标红，检测逻辑会导致在编辑、导出时损失性能。

组件计算优化建议：

1. 单个组件新增计算不超过 5 个。

2. 手动检查，确保仪表板中没有标红字段。

3. 减少计算字段间相互嵌套。

4. 复杂公式下放到自助数据集中计算，如去重计数、表头过滤、公式过滤、维度转指标。

5. 减少使用性能偏弱的场景，如：交叉表计算同环比、交叉表+组内合计+聚合计算/快速计算/日期分组等、分组表+组内合计+维度转指标明细过滤+快速计算、维度过滤+复杂公式计算、主题模型+def类函数计算、交叉表使用主题模型、使用主题模型分析多个维度表或多个事实表、文本函数过滤-结果行500w、TopN过滤组合其他场景。

6. 特殊函数使用注意点：

• 文本函数中减少使用长文本，长文本很容易导致宕机，建议文本处理尽量都放在数据集中进行。

• IN/NOT函数，里面参数不宜过多，建议不超过100个；如果是长文本的话尽量控制在10个值以内。

• IF公式嵌套不要超过4层，尽量用SWITCH代替IF嵌套。

• DEF函数嵌套不超过4层

• 函数尽量减少嵌套层数

• 少使用 earlier 函数
  

• 明细过滤字段不使用 FIXED/DEF 函数。

• 明细函数不与聚合函数混用。

• 日期转换公式尽量简单。

• 例如，正确方式：TODATE("20240611","yyyyMMdd")

  错误方式：TODATE(CONCATENATE(LEFT(${日期},4),"- ",MID(${日期},5,2),"-",RIGHT(${日期},2))) 。

4.4 过滤

过滤优化建议：

1. 对于及相对固定的一些过滤，下放到自助数据集中进行；在组件中使用过滤组件的参数参与计算和过滤时，除非需要查看时动态改变参数值，否则尽量放在自助数据集解决。

2. 将表头过滤 修改为 结果过滤器过滤 或者 过滤组件过滤，达到同样的过滤效果。

3. 用“包含/不包含”等条件，替代 “属于固定值再进行模糊搜索”的过滤 。

4. 减少过滤组件和明细过滤的联动，尽量使用FineBI自带组件过滤。

5. 为过滤组件配置对应的维度表作为下拉选项，过滤控件绑定值不要与事实表绑定。

• 维度表：用来绑定参数控件值的数据表，例：产品维度表。

• 事实表：数据库表某业务表明细数据，数据量大，例：产品销售明细表。

4.5 联动

• 在6.0版本中，添加组件时，当多个组件使用的数据表是同一张数据表，那么这多个组件之间有系统默认设置的联动。

• 在6.1版本中，添加组件时，支持默认的过滤组件联动效果，即只需要将数据跟过滤组件进行绑定，FineBI 就会自动读取被绑定数据之间的关联关系，实现组件联动。

编辑或者预览时点击触发联动，多层联动嵌套场景，类似 组件A 联动到 组件B 再联动 组件C ，在多个组件间互相点击进行联动，超过 5 个组件时，会造成前端浏览器卡死，服务器的cpu内存上升，日志膨胀，进而导致服务不可用。

联动优化建议：

1. 如果实际业务场景并不需要默认联动，则关闭仪表板的【开启默认联动】；根据组件间逻辑手动添加需要的联动。

2. 如果实际业务场景需要默认联动，但并不需要多次联动后的结果，则可以在组件间联动三次后，手动清除仪表板联动。

4.6 并发

仪表板编辑与预览并发建议：

在BI 8G4C+ worker 32G16C 的推荐配置下

1. 主题编辑的最大吞吐量在71/s，最佳并发数在70个用户。

2. 无缓存情况下，模板预览的最大吞吐量在4.43~12.3/s，最佳并发数在10~25个用户。

3. 有缓存情况下，模板预览的最大吞吐量在55~110/s，最佳并发数在120~150个用户。

4.7 导出

导出优化建议：

1. 限制导出数量：在所用表数据量较大的仪表板中说明导出限制，全局导出限制xx，组件导出限制xx。仪表板导出 Excel 不超过 2ww 个单元格。

2. 减少数据量：通过组件过滤的方式，减小数据量、分多次导出。（BI v5.1.20及之后的版本，默认限制交叉表导出列数为100，不建议导出超过100列的数据，会有宕机风险。建议超过该限制的表格通过调整数据来满足限制。）

3. 减少计算量：包括排序，分组汇总，计算指标，过滤等，如果计算量过大，可以做成抽取自助数据集优化。

4. 限制导出时间：使用定时调度功能，在工程空闲时段进行导出。