1. 概述
1.1 应用场景
梳理好数据在 BI 中的存放结构后,就可以将数据库中的数据接入 BI (添加数据库表、添加SQL数据),存放在对应的位置。
如果你使用的是 抽取版本,还需要进行数据更新 后才能保证数据的时效性和可用性。
此时,由于 BI 系统中数据表繁多且数据量大,关联、引用等复杂,更新时间势必很长,如果没有好的数据更新方案,就会出现数据时效性不足,更新缓慢、系统性能差等问题。良好的数据更新规范能保证数据正常使用,系统性能稳定、数据更新速度较快,资源消耗相对较少;同时避免因为错误设置带来的问题和风险。因此作为管理员该如何设计 BI 系统的更新方案就非常重要。
1.2 更新类型选择
1)数据表为维度表/数据量不大的表,可以使用全量更新。
2)表内有「时间戳」字段可用来和「更新时间」做对比以实现增量更新,并且历史数据不会变动的,优先考虑增量更新的方式。(服务器数据集和Excel数据集除外)
配置了增量更新时,增量更新的SQL不能为空。
增量删除时,请勿select * ,需要仅select唯一区分的字段,例如uuid。
1.3 更新任务调度策略
整体的更新策略为:全局定时更新+特殊文件夹定时更新+特殊单表定时更新。
也就是:除少部分特殊需求(如实时性要求较高,按天更新无法满足需求,或是业务具有特殊性可另行单独设置)外,其它非数据时效性需求的抽取模式数据集更新统一采用全局更新(文件夹跟随全局更新进行更新,基础数据集跟随文件夹更新进行更新,自助数据集跟随父表更新进行更新)。
1.4 注意事项
在梳理更新策略时,可以优先设计全局更新时间(可依照中台最晚数据抽取完成时间进行灵活调整),若出现特殊情况,再配置文件夹、表的定时更新。自助数据集无需配置,会跟随使用到的父表而自动更新。
不做全局更新,或在全局更新基础上仍要在别的时间单独更新较多表/文件夹的,应当事先查看其相关血缘表。对于相关血缘表重合较多的任务,建议放到同一时间更新,因为只要一起更新,会自动去重,不会出现重复更新的问题;相反若设置为错开一段时间更新,两个更新任务牵连的表都有同一张表的话,那这张表可能会出现重复更新的情况,浪费资源;如果多个任务的相关血缘表几乎没有重合,则建议错开更新时间,防止系统阻塞。
如与数仓/中台数据更新时间有冲突,导致平台数据未能展示最新数据,管理员应当及时更新;但在更新时应当考虑数量级以及关联数据集个数,若数据集太大,或者关联过多(>50个),应当在系统空余时间点击更新。
2. 更新数据量
单表数据量越大,更新越慢;同时更新数据量过大也可能导致系统因磁盘不足或内存不足宕机。
2.1 限制更新
基础表数据行数在1亿以上的单表,建议拆分成多个子表使用;单表列数不超过100列。
使用参数 SystemOptimizationConfig.tableLoadDataLimit 限制数据集抽取数量,默认是不限制,参考:限制数据集抽取数量
新增表的更新先检查数据量,如果数据量远超已有基础表数据量时,建议提前确认磁盘剩余空间是否充足,数据量对应生成的文件大小见本文 「4. 性能标准>4.3 数据量对应生成的文件大小」。
手动触发更新时,对于数据量大的表,先在更新信息处或通过其他方式确认表的占用空间;定时更新的量一般相对固定,不易导致磁盘占用异常增长,日常保持监控增量即可。
限制更新权限发放。为了不使用户随意触发和设置更新,需要管控拥有数据权限-管理权限的用户,合理分配公共业务包和数据集的管理权限。数据权限分配可参考文档:公共数据文件夹管理权限
2.2 提前预警
管理员定期检查磁盘空间剩余量,空闲磁盘空间至少不能低于总db大小。
开启BI自带的磁盘监控预警提醒,并定期通过「公共数据管理」功能对无用表进行清理。
抽数目录隔离。将工程目录和抽取目录设置在两个不同磁盘目录(本地磁盘,非外挂磁盘),这样即便抽数目录满了也不易使工程宕机。修改数据存放路径可参考文档:数据存放路径
3. 更新设置
3.1 全量/增量更新
全量更新的原始表越大,生成文件越大,耗时越久;增量更新同理,且增量的总单元格数越多,耗时越久;增量删除比增量增加慢。
增量更新常用于频繁更新且数据量比较大的表,使用增量更新来缩短基础表更新时长。若是单表的数据量比较小(不超过1kw行),或者更新频率较低(不超过1次/天),那么使用全量更新也没问题。
全量更新与增量的详细性能标准数据见本文 「4.2 更新性能标准」。
3.2 更新频率
设置过于频繁的更新频率,可能出现数据还没更新完,系统就开始下一次更新的情况,容易造成更新任务阻塞,严重可能导致宕机。
全局更新:建议不超过每天一次。
单表/文件夹更新:建议间隔时间不低于 2h,一天不超过 10 次。
如果对实时性要求比较高,可根据正常更新表所在的分组的耗时来设置定时频率,更新间隔为分组更新完成所需时间的 2 倍以上 ;如果对实时性要求非常高,可将表添加为实时数据,就无需进行更新。
3.3 更新执行时间
合理设置定时更新的执行时间和手动更新的触发时间:
定时更新/全局更新建议设置在业务使用量较少的时间段,如夜里22:00-凌晨06:00,需要留足更新的时间。
不建议在业务使用量较大的工作时间段手动触发大表更新,可结合系统的平均负载情况分析,禁止在某个时间段手动更新大表;如果数据量较小或更新拉起的相关表不多,可结合当前负载状况触发手动更新。
关联度较大的更新任务,比如A文件夹和B文件夹中的表存在血缘关系或者关联关系,尽量将任务设置到同一时间执行。如 A、B任务均设置为每天更新一次,A开始时间为 20xx-xx-xx 02:00,B开始时间为 20xx-xx-xx 04:00,这样有可能导致A和B里的表都被更新了两次,因此可将时间都调整至 02:00 。
除全局更新以外的定时更新,不建议全都设置在一个时间点执行,可以将无关联的任务 在允许的更新时间 内错开更新,防止出现同时更新多个大表的情况。
3.4 文件夹更新/单表更新
通常如果对文件夹和单表均设置定时更新任务,是一种重复更新、资源浪费,容易造成更新任务阻塞,严重可能导致宕机。
建议使用文件夹更新的场景:公共数据中按业务模块分类,一个文件夹内的表都有血缘关系或关联关系。
建议使用单表更新的场景:文件夹中的表数量超过 50 个,文件夹中的表几乎无关系;单表血缘关系较浅,子表数量和关联表数量不超过 20 个。
如果实际使用过程中无法避免任务交叉的场景,尽量把设置在文件夹和单表上的任务调整至同一时间执行。
BI 6.0版本中,为避免业务人员无意识地对单表和文件夹重复设置定时更新,增加了更新设置提示。当数据集已经有未结束的定时更新任务时,再对其所属的文件夹设置定时更新则会有下图提示;反之同理。
3.5 自助数据集更新
1)影响因素
自助数据集更新时长受计算时间和结果集大小影响,计算时间受原始表行数、结果表行数(分组汇总对应为分组数)、结果表列数、cpu性能等影响。
原始表相同的情况下,步骤越复杂、越多,计算耗时就越长。
更新性能较差的场景:过滤-公式/函数,新增列-所有值求平均、排名、累计值,新增列-汇总值-数值字段去重计数,新增列-公式/函数(特别是嵌套场景,如 上一个新增列字段在下一个新增列中使用,或者def嵌套),多字段行列转换(大于10个)、多表(大于5个)选字段左右合并和分组汇总。
更多详细性能标准数据见本文 「4.2 更新性能标准」。
2)更新设置
通常情况设置跟随父表更新即可(默认配置无需修改),如果不设置随父表更新,除了手动触发外,可设置定时更新,不过这个功能使用场景较少。
定时更新/手动更新的时间、频率与本文「3. 更新设置」中的3.2节、3.3节相同。
3.6 关联更新
1)影响因素
关联时长受关联配置两端字段行数、整个关联链路长度影响。原始表行数越多,关联链路越长,则更新时长越久。为保证性能,建议把关联的基础表都设置在同一个时间更新,不要太分散。
详细性能标准数据见本文 「4.2 更新性能标准」。
2)关联优化
BI6.0.8 起可将分析主题内的表在模型中建立关联,使用多表分析,很大程度上能代替之前的基础表关联,功能详见:主题模型应用示例
因此对于旧关联,可通过 更新任务管理-历史运行情况,找到更新耗时长的关联,根据实际情况进行适当调整。
为了进行多表联合分析而添加的新关联,可在分析主题中完成;在非必要的情况下,应减少关联的创建,并将关联前置到数仓中进行。
3.7 服务器数据集更新
服务器数据集的更新性能较差,超过100w、100列的服务器数据集不建议进行更新。
不建议添加大数据量服务器数据集添加到公共数据中使用。可以减少数据量,或用其他功能替代取数,如直接添加SQL表。
4. 性能标准
目前产品保证性能的前提:
磁盘写入速度>100MB/s
BI和数据源之间的网速>500Mbps/s
服务器推荐配置:
CPU:优于 8 核 16 线程 2.5GHZ
JVM 内存:大于 16GB
4.1 更新单场景受影响的因素
表类型 | 业务步骤 | 数据源库性能 | BI与数据源网速 | 磁盘写入速度 | CPU | 内存 |
---|---|---|---|---|---|---|
DB表 | -- | 大 | >500Mbps/s | >100MB/s | 小 | 小 |
SQL表 | sql执行性能 | 大 | 小 | 小 | ||
自助数据集 | 大 | -- | -- | 大 | 大 |
DB表全量和增量更新主要受数据源数据库性能、BI与数据源的网速影响。
SQL表全量和增量更新主要依赖SQL复杂度和数据源数据库性能。
提升整体更新速度:增大jvm分配值,使用固态硬盘。
4.2 更新性能标准
1)无并发更新下的性能标准
CPU、内存、磁盘性能、数据源数据库性能、网速满足推荐配置的前提下
更新类型 | 性能标准 | |
---|---|---|
基础表 | 全量更新 | 10亿单元格内,20分钟内更新完毕100亿单元格内,1.5小时内更新完毕 |
增量更新 | 4干万单元格内,增量增加1分钟内更新完毕 1十万单元格内,增量删除1分钟内更新完毕 1亿单元格内,增量删除 5分钟内更新完毕 4亿单元格内,增量删除20分钟内更新完毕 | |
关联更新 | 关联链路长度不超过3个,且最大1个表数据量达到1千万行,关联更新更新时长1分钟内关联链路长度不超过9个,且最大2个表数据量达到1亿行,关联更新更新时长10分钟内 | |
自助数据集更新 | 受原始表行数、结果表行数(分组汇总对应为分组数)、结果表列数、cpu性能等影响,无统一标准,性能较弱的场景见本节(3)表 | |
全局更新 | 所有的基础表都是百万级别,且基础表+所有自助数据集数量不超过500,全局更新耗时3小时内 90%的基础表都不超过千万级别,且基础表+所有自助数据集数量不超过1000,全局更新耗时6小时内 90%的基础表都不超过千万级别,且基础表+所有自助数据集数量不超过10000,全局更新耗时10小时内 | |
更新停止 | 单表停止5秒内;多表(包括子表)停止耗时时间为表数量/秒;全局更新停止5分钟内 |
2)符合性能标准的场景
功能场景 | 功能细节 | 更新时长 | 量级 | 是否满足性能标准 |
---|---|---|---|---|
基础表更新 | 全量更新 | 2.3min | 1kw行20列 | 符合20min内更新完成性能标准时长的最大量 级,从而表示小于该量级均满足性能标准 |
56.92min | 1ww行100列 | 符合90min内更新完成性能标准时长的最大量 级,从而表示小于该量级均满足性能标准 | ||
增量增加更新 | 0.43min | 200w行20列 | 符合1min内更新完成性能标准时长的最大量级,从而表示小于该量级均满足性能标准 | |
增量删除更新 | 1.3min | 200w行20列 | 符合20min内更新完成性能标准时长的最大量 级,从而表示小于该量级均满足性能标准 | |
关联更新 | 1:N-1:N关联更新 | 9.6min | 1ww行20列 | 符合15min内更新完成性能标准时长的最大量 级,从而表示小于该量级均满足性能标准 |
自助数据集更新 | 2个公式新增列步骤 | 4.2min | 1kw行20列 | 符合10min内更新完毕性能标准时长的最大量级,从而表示小于该量级均满足性能标准 |
全局更新 | 276基础表+705自助数据集+88关联 | 5.08h | 88%的基础表不超过kw,12%基础表超过1kw,总表数量981 | 符合6h内更新完毕性能标准时长的最大量级,从而表示小于该量级均满足性能标准 |
3)自助数据集性能偏弱的场景
单场景更新耗时 | 基础数据量 | 测试场景 |
---|---|---|
5min~10min | 1kw行 | 列转行-10字段 |
1ww行 | 左右合并-右合并、并集合并,新增列-公式、分组赋值、时间差、组内所有值排名、组内所有值求平均、组内累计值、获取时间,排序,过滤-非空 | |
10min~30min | 1kw行 | 10个表多表选字段-字段设置,30个嵌套新增列,行转列-10字段 |
1ww行 | 新增列-所有值求平均、排名、累计值 | |
30min~1h | 1kw行 | 10个表多表选字段-分组汇总,10个表多表选字段-左右合并 |
2h以上 | 1kw行 | 10个表多表选字段-10字段行转列 |
4.3 数据量对应生成的文件大小(参考)
注:下表中数据量生成文件的大小以表中数值字段占比超过70%的情况为例。
行数 | 表列数 | 生成大小(G) |
---|---|---|
100w | 21 | 0.58 |
200w | 21 | 1.14 |
500w | 21 | 2.67 |
1kw | 27 | 3.25 |
107 | 6.86 | |
1ww | 27 | 26.63 |
107 | 62.14 | |
500w | 200 | 7.43 |
411 | 22.09 |