数据更新方案

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

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

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

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

单表数据量越大，更新越慢；同时更新数据量过大也可能导致系统因磁盘不足或内存不足宕机。

2.1 限制更新

• 基础表数据行数在1亿以上的单表，建议拆分成多个子表使用；单表列数不超过100列。

• 使用参数 SystemOptimizationConfig.tableLoadDataLimit 限制数据集抽取数量，默认是不限制，参考：限制数据集抽取数量

• 新增表的更新先检查数据量，如果数据量远超已有基础表数据量时，建议提前确认磁盘剩余空间是否充足，数据量对应生成的文件大小见本文 「4. 性能标准>4.3 数据量对应生成的文件大小」。

• 手动触发更新时，对于数据量大的表，先在更新信息处或通过其他方式确认表的占用空间；定时更新的量一般相对固定，不易导致磁盘占用异常增长，日常保持监控增量即可。

• 限制更新权限发放。为了不使用户随意触发和设置更新，需要管控拥有数据权限-管理权限的用户，合理分配公共业务包和数据集的管理权限。数据权限分配可参考文档：公共数据文件夹管理权限

2.2 提前预警

• 管理员定期检查磁盘空间剩余量，空闲磁盘空间至少不能低于总db大小。

• 开启BI自带的磁盘监控预警提醒，并定期通过「公共数据管理」功能对无用表进行清理。

• 抽数目录隔离。将工程目录和抽取目录设置在两个不同磁盘目录（本地磁盘，非外挂磁盘），这样即便抽数目录满了也不易使工程宕机。修改数据存放路径可参考文档：数据存放路径

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表。

目前产品保证性能的前提：

• 磁盘写入速度>100MB/s

• BI和数据源之间的网速>500Mbps/s

服务器推荐配置：

• CPU：优于 8 核 16 线程 2.5GHZ

• JVM 内存：大于 16GB

4.1 更新单场景受影响的因素

• SQL表全量和增量更新主要依赖SQL复杂度和数据源数据库性能。

提升整体更新速度：增大jvm分配值，使用固态硬盘。

4.2 更新性能标准

1）无并发更新下的性能标准

CPU、内存、磁盘性能、数据源数据库性能、网速满足推荐配置的前提下

2）符合性能标准的场景

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

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