反馈已提交

网络繁忙

您正在浏览的是 FineBI6.0 帮助文档,点击跳转至: FineBI5.1帮助文档

数据更新方案

  • 文档创建者:Roxy
  • 历史版本:12
  • 最近更新:9tskIrGE 于 2024-03-19
  • 1. 概述

    梳理好数据在 BI 中的存放结构后,就可以将数据库中的数据接入 BI (添加数据库表添加SQL数据),存放在对应的位置。

    如果你使用的是 抽取版本,还需要进行数据更新 后才能保证数据的时效性和可用性。

    此时,由于 BI 系统中数据表繁多且数据量大,关联、引用等复杂,更新时间势必很长,如果没有好的数据更新方案,就会出现数据时效性不足,更新缓慢、系统性能差等问题。

    因此作为管理员该如何设计 BI 系统的更新方案就非常重要。

    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版本中,为避免业务人员无意识地对单表和文件夹重复设置定时更新,增加了更新设置提示。当数据集已经有未结束的定时更新任务时,再对其所属的文件夹设置定时更新则会有下图提示;反之同理。

    download_image (3).png


    3.5 自助数据集更新

    1)影响因素

    • 自助数据集更新时长受计算时间和结果集大小影响,计算时间受原始表行数、结果表行数(分组汇总对应为分组数)、结果表列数、cpu性能等影响。

    • 原始表相同的情况下,步骤越复杂、越多,计算耗时就越长。

    • 更新性能较差的场景:过滤-公式/函数,新增列-所有值求平均、排名、累计值,新增列-汇总值-数值字段去重计数,新增列-公式/函数(特别是嵌套场景,如 上一个新增列字段在下一个新增列中使用,或者def嵌套),多字段行列转换(大于10个)、多表(大于5个)选字段左右合并和分组汇总。

    • 更多详细性能标准数据见本文 「4.2 更新性能标准」。

    2)更新设置

    • 通常情况设置跟随父表更新即可(默认配置无需修改),如果不设置随父表更新,除了手动触发外,可设置定时更新,不过这个功能使用场景较少。

    • 定时更新/手动更新的时间、频率与本文「3. 更新设置」中的3.2节、3.3节相同。

    3.6 关联更新

    1)影响因素

    • 关联时长受关联配置两端字段行数、整个关联链路长度影响。原始表行数越多,关联链路越长,则更新时长越久。为保证性能,建议把关联的基础表都设置在同一个时间更新,不要太分散。

    • 详细性能标准数据见本文 「4.2 更新性能标准」。

    2)关联优化

    BI6.0.8 起可将分析主题内的表在模型中建立关联,使用多表分析,很大程度上能代替之前的基础表关联,功能详见:主题模型应用示例

    因此对于旧关联,可通过 更新任务管理-历史运行情况,找到更新耗时长的关联,根据实际情况进行适当调整。download_image (4).png

    为了进行多表联合分析而添加的新关联,可在分析主题中完成;在非必要的情况下,应减少关联的创建,并将关联前置到数仓中进行。

    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.3min1kw行20列符合20min内更新完成性能标准时长的最大量
    级,从而表示小于该量级均满足性能标准
    56.92min1ww行100列符合90min内更新完成性能标准时长的最大量
    级,从而表示小于该量级均满足性能标准
    增量增加更新0.43min200w行20列符合1min内更新完成性能标准时长的最大量级,从而表示小于该量级均满足性能标准
    增量删除更新
    1.3min200w行20列符合20min内更新完成性能标准时长的最大量
    级,从而表示小于该量级均满足性能标准
    关联更新1:N-1:N关联更新
    9.6min1ww行20列符合15min内更新完成性能标准时长的最大量
    级,从而表示小于该量级均满足性能标准
    自助数据集更新2个公式新增列步骤4.2min1kw行20列符合10min内更新完毕性能标准时长的最大量级,从而表示小于该量级均满足性能标准
    全局更新276基础表+705自助数据集+88关联5.08h88%的基础表不超过kw,12%基础表超过1kw,总表数量981符合6h内更新完毕性能标准时长的最大量级,从而表示小于该量级均满足性能标准

    3)自助数据集性能偏弱的场景

    单场景更新耗时
    基础数据量测试场景
    5min~10min
    1kw行列转行-10字段
    1ww行左右合并-右合并、并集合并,新增列-公式、分组赋值、时间差、组内所有值排名、组内所有值求平均、组内累计值、获取时间,排序,过滤-非空
    10min~30min
    1kw行10个表多表选字段-字段设置,30个嵌套新增列,行转列-10字段
    1ww行新增列-所有值求平均、排名、累计值
    30min~1h1kw行10个表多表选字段-分组汇总,10个表多表选字段-左右合并
    2h以上1kw行10个表多表选字段-10字段行转列
    4.3 数据量对应生成的文件大小(参考)

    注:表中数值字段占比超过70%的情况。

    行数
    表列数生成大小(G)
    100w210.58
    200w211.14
    500w212.67
    1kw273.25
    1076.86
    1ww
    2726.63
    10762.14
    500w2007.43
    41122.09

    附件列表


    主题: 管理系统
    • 有帮助
    • 没帮助
    • 只是浏览
    中文(简体)

    鼠标选中内容,快速反馈问题

    鼠标选中存在疑惑的内容,即可快速反馈问题,我们将会跟进处理。

    不再提示

    10s后关闭

    联系我们
    在线支持
    获取专业技术支持,快速帮助您解决问题
    工作日9:00-12:00,13:30-17:30在线
    页面反馈
    针对当前网页的建议、问题反馈
    售前咨询
    采购需求/获取报价/预约演示
    或拨打: 400-811-8890 转1
    qr
    热线电话
    咨询/故障救援热线:400-811-8890转2
    总裁办24H投诉:17312781526
    提交页面反馈
    仅适用于当前网页的意见收集,帆软产品问题请在 问答板块提问前往服务平台 获取技术支持