提供了一个关于FineBI系统中用户准入管理、开发流程以及性能优化的详细指南。

文档旨在帮助用户理解在BI系统中如何进行有效的用户管理和开发流程，同时提供了确保系统性能和数据质量的最佳实践。

2.2 用户区分

在BI中，根据用户行为的不同，用户可分为以下几种：

对于不同的用户，在系统中需要分配不同的权限，详见：数据体系&权限管理

2.3 用户要求

为保障BI环境各项数据资产的规范性、高性能，在允许用户进入生产环境进行自助开发前，管理员应检查用户，需先完成标准规范学习、通过准入考核，可以“帆软认证初级BI工程师”为参考标准见：FCA-FineBI

注：对于【数据BP用户】和【IT用户】，要求应适当提升，要求其掌握一定的数据处理能力和思维、拥有一定的规范意识，因为无限制的数据处理可能会导致系统性能问题。

3.1 权限申请

1. 查看可见范围：查看当前公开的仪表盘和数据列表。

2. 确认分析权限：针对自己的分析相关的数据，核对有无权限。

3. 进行权限申请：无权限，则进行申请。

4. 权限二次复核：申请通过后再次确认权限是否解决。

3.2 数据开发与发布

3.2.1 流程

对于拥有公共文件夹权限的开发用户，在数据集开发完之后可以通过将数据集发布到「公共数据」的形式，发布数据需注意几点：

• 规范性：遵守企业规定的命名规范。

• 安全性：检查数据敏感性，对其中敏感数据，与次管确认数据权限管控是否到位。

• 准确性：对于数据来源、计算指标、有歧义的数据等应当作出解释，可以放在数据集的备注中。

• 流程性：发布前需向次管确认，发布后及时记录信息。例如：

3.2.2 数据路径

与5.x版本不同，6.0在开发时，新增了“分析主题”的概念。

• 在分析主题中，存在3种实体：

• 数据集

• 组件

• 仪表板

• 分析文档
  

• 在使用路径上，先有数据，再制作组件，最后组成仪表板。

注：不同于5.x的分散，6.0中用户可以根据业务/分析内容来组织这4种实体，在结构上更方便查看和使用。

3.2.3 公共数据概念

在个人的分析主题中，用户可以对数据集和组件进行开发，无法直接在公共业务包内新建数据集。

• 【我的分析】可以认为是一个相对独立且自由的空间，类似于个人PC，用户可以在里面进行各种各样的数据组合和处理，探索各种数据的特征，不会影响到其他人的使用。同时，在“我的分析”中，不支持设置数据集的更新频率，所有的数据集都是跟随公共数据内引用的父表而更新的。

• 【公共数据】则可以认为是一个企业内的网盘，数据必须有一定的复用性、符合一定的规范才能够进入此区域，供他人使用。同时个人需对自己发布到公共区域的数据进行担责和维护。只要是进入“公共数据"中，就肩负起了维护和建设一个良好数据质量的责任，逻辑变更时，一定要考虑到会不会对其他用户造成不好的影响。如果公共数据中的表出现了错误，那么对应的数据管理员就有责任要尽快修复这个问题。如果这个数据将要退出公共数据，那么也要走流程来进行下架，来减少对其他用户的影响。

3.3 可视化开发与分享

3.3.1 命名规则

命名应当以简洁性、特征性为追求。

规范示例：

• “分析主题-分析内容-创建人”

• “分析内容-使用场景-创建人”

• “组内序号-分析内容-创建人”

3.3.2 视觉规则

用户开发的仪表板，在视觉上需遵守一定的规则，要注意 看板的可读性 和 表达的合理性 ，主要体现在：

• 字体字号要合理。

• 排版布局要遵从“主次原则”，有主要部分和次要部分的区别，尊重阅读顺序。

• 图表选择要合理，尽可能将能同时分析的数据放在同一个图表中。

• 整体配色要和谐，避免反差色

• 必要时添加文字注释，例如对数据来源做出解释、对数据结论做出总结。

• 必要时添加logo。

3.3.3 发布途径

1）团队内分享

若分析主题是小团队使用，或者仅需某些用户查看，可以不发布到公共目录。此时需注意以下几点：

• 分享的用户是否有对应数据的权限。

• 是否想让分享的目标用户看到制作者能看到的数据。

• 是否告知分享的用户本主题内资源的内容、使用场景、数据来源。

2）公共目录挂出（发布设置）

• 需要挂出到公共目录时，挂出的主题 配套数据源 一定是已在公共目录下的，否则无法给用户授权数据源查看权限和配置行权限。

• 若使用到的数据源目前尚不存在公共目录下，需先参考本文的 「3.2节数据开发与上架」步骤进行相关数据发布 。

• 申请挂出到公共目录的主题资源，必须进行如下检查：

• 数据准确性：有特殊处理的数据是否做了解释。

• 可读性：查看者能否清晰且快速了解到仪表盘内容，认知无偏差。

• 数据保密性：若有敏感数据，是否已经配置权限。

• UI标准性：是否符合企业的UI标准、视觉效果是否合理。

3）创建公共链接

• 公共链接打开能看的数据权限，跟制作者是完全一致的，故而使用公共链接功能时，需格外注意数据保密性。

• 公共链接使用完后应及时关闭。

4）协作

• 在5.x中，BI支持将数据集进行分享协作，详见分享/协作自助数据集，但该功能无法满足“查看仪表板制作过程”的需求。

• 在 6.0 中，用户可以将文件夹或者主题进行点对点的协作，被协作的用户能查看或者使用相关分析主题的内容，实现分析主题的协同编辑。详情请参见：协作 

4.1 FineBI的合理性能表现(抽取数据)

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

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

4.1.1 整体表现

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

4.1.2 复杂组件展现表现

1）1亿行以下的分组表

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

• 求记录数

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

• 函数计算：todouble、DAYSOFYEAR、DAYS360、DATESUBDATE

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

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

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

• 单维度排序，其他维度组内排序

• 被联动（带有过滤）

• 分析区、待分析区的过滤：属于、介于/不介于、结尾是、TopN（最大的N个、前N个）

• 复杂场景：过滤+计算+排序

• 函数计算（5个维度5个指标的情况下，计算越多越慢）：tointeger、todouble、lower、len、find、SWITCH、RAND、MAX、INT、IF、EXP、DAYSOFYEAR、DAYS360、DATESUBDATE、DATEDIF、AND

注：如果在1kw原始数据的情况下，出现了100w个分组，则会影响展现表现（因为分组越多计算量越大）。其中快速计算和维度排序的表现在30秒以内都是合理的。

2）交叉表

在不做复杂计算、数据集行数在一亿行以内的情况下，10行*10列*10指标和5行*5列*10指标的交叉表，都应在5秒以内展现出来。

3）对于开启了大数据模式的图表来说

• 若数据集的行数在1kw以内，在图表分析时产生的维度分组数在5000以内，柱形图、点、线、面积图这些图表的展现应该在5秒之内完成。

• 若数据集的行数在1kw以内，在图表分析时产生的维度分组数在100w以内，仪表盘、填充地图、文本、漏斗图、热力点、矩形块、饼图、多层饼图、漏斗图、矩形树块、聚合气泡图、词云、雷达图、流向地图、点地图、热力地图这些图表的展现应该在5秒之内完成。

4.1.3 导出表现

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

导出时长包括两部分

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

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

Excel导出速率和单元格数量的关系：最快10w单元格/秒，常规在20~40w单元格/秒。

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

2）导出性能表现标准：

4.2 数据集开发建议

4.2.1 基础数据集

4.2.1.1 通用规范

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

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

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

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

4.2.1.2 Excel数据集使用

导入excel时，若数据量过大，会导致导入慢，或造成前端卡死。

因此建议：

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

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

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

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

因此建议：

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

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

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

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

4.2.2 自助数据集（主题下的数据编辑）

4.2.2.1 字段数建议

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

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

4.2.2.2 步骤数建议

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

• 新增列不超过 10 列。

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

• 分组汇总步骤不超过 3 步。

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

4.2.2.3 步骤顺序建议

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

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

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

4.2.2.4 步骤类型建议

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

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

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

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

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

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

4.2.2.5 血缘层级

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

因此建议：

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

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

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

4.2.3 性能表现参考

• 自助数据集符合性能标准的场景

• 自助数据集不符合性能标准的场景

4.3 可视化开发建议

首先建议开发时使用的浏览器，尽可能使用新版，例如chrome要使用110版本及以上，太旧的浏览器也会导致请求卡顿。

4.3.1布局

组件数量很多时，完全加载出仪表板所需时间很长；30+的复杂图表组件很容易出现渲染慢，view请求慢，导致模板访问白屏。

布局优化建议：

1. 减少组件总数量：最好不超过30个。

2. 使用TAB组件的方式进行异步加载：不推荐过多组件全堆砌在一页，组件越多性能越差。

3. 合理使用页面拆分、页面跳转方式布局：具备下钻逻辑的组件，可以采取页面跳转的方式，减少同一页面内组件数量。

4.3.2 组件效果选择

组件选择优化建议：

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

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

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

4. 数据量级简化：使用大分组图表（分组超过5k）时，建议取消勾选“查看所有数据”。

4.3.3 字段数/数据量

数据量优化建议：

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

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

4.3.4 组件计算

组件中新增计算指标时，若新增指标多、公式复杂，会导致计算慢，进而导致计算线程池满，造成系统卡慢。

仪表板有很多的字段和计算指标，编辑状态下，添加、删除、移动字段前端响应慢。

同时，若有些字段标红，检测逻辑会导致在编辑、导出时损失性能。

组件计算优化建议：

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

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

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

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

5. 减少使用性能偏弱的场景，如：去重计数、表头过滤、公式过滤、维度转指标、分组汇总-环期值&环期比、组件过滤-TopN过滤、过滤混合二次计算混合排序、合计方式-中位数&方差&标准差&求平均&最小值、DEF函数、EXP、TODOUBLE、DATESUBDATE、DAYS3600、行表头字段a按照相关联字段b升序。

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

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

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

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

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

5. 明细函数不与聚合函数混用。

6. 日期转换公式尽量简单。

   例如，正确方式：TODATE(TOSTRING(${日期}),"yyyyMMdd")

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

4.3.5 过滤

过滤优化建议：

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

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

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

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

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

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

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

4.3.6 刷新

使用【BI预览自动刷新模板】插件对模板进行定时刷新时，若刷新频率设置过高，或者同一时间刷新的模板过多，会导致系统卡慢。

刷新优化建议：

1. 单张模板刷新频率不低于60s。

2. 如果有较多模板需要刷新，将大模板的开始刷新时间点错开。

4.3.7 联动

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

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

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

联动优化建议：

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

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

4.3.8 导出场景

导出优化建议：

1. 限制导出数量：在所用表数据量较大的仪表板中说明导出限制，全局导出限制xx，组件导出限制xx。

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

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

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