请注意：本文中部分演示内容为5.x版本。
1. 概述编辑
数据管理部分主要是让你了解如何对已经梳理好的现有的数据接入 BI 系统，并保证数据在 BI 中的持续可用性。
主要内容包括：
适用人群：平台管理员、IT 运维人员
2. 数据连接管理编辑
权限管控：创建数据连接的权限仅开放给超管&次管。
重复性校验：在创建数据连接之前，需检索数据连接是否已存在，不可创建两个指向(数据库地址、库名、用户等参数)完全一样的数据连接。
命名规范：数据连接命名需有统一规范，可遵照例如“业务系统/数据主题_数据库类型”形式，如“BI平台运营_MySQL”、“xxERP系统交易数据_GP”；或者“业务系统/数据主题_使用部门_添加/负责人”，如“BI平台使用记录_运营部_peter”等规范进行命名。超级管理员需对数据连接命名做统一监控。
固定连接名：数据连接名不能轻易修改，更改后数据库表会因为找不到数据库而报错，因此需要提前规划好数据连接名称。更改数据连接名后，SQL 数据集需要进入修改SQL页面重新选择数据连接，若数据连接名很可能要改，则尽量用 SQL 添加基础表而不是数据库db表。
3.数据策略(直连or抽取)编辑
FineBI支持两种取数模式，分别是直连模式——直接使用数据库中的数据和能力进行计算，和抽取模式——数据需要抽取保存到 FineBI 的引擎中进行计算。详情可参考文档：直连数据和抽取数据的区别
对于同一个系统来说，抽取和直连数据都可以存在，但需注意每个仪表板只能用一种模式的数据。
若企业有较为专业的大数据平台，数据质量很高，或者对数据实时性的要求很高，不接受T+1数据，或者数据安全性要求很高的，不希望将数据另外存储到BI工程中，此时可以选择直连模式。
此外，若企业的最大数据量超过1亿，且需要对大数据量的表进行频繁的分析，我们建议也使用直连模式，将计算下放到数据库，减少BI服务的压力。
但直连版本不支持对跨数据源的数据表做联合分析（建立关联、上下合并、左右合并等），若实际业务有跨表关联的诉求，可以借由Finedatalink产品实现数据的跨库同步。
抽取数据的计算，使用的是BI服务器的计算能力和资源（主要是内存），其性能相关因素主要在于服务器资源情况以及BI对于资源的使用能力；而直连的计算，是FineBI经过引擎处理，将前端的计算逻辑转化为数据库sql，然后发送给数据库进行计算，BI获取数据库返回的结果做展现，性能与数据库引擎强相关。若企业使用直连数据，需确认业务数据库能否支撑BI发送的高并发sql计算，包括在高并发下的查询速度和资源使用情况。
4. 抽取数据更新编辑
良好的数据更新规范能保证数据正常使用，系统性能稳定、数据更新速度较快，资源消耗相对较少；同时避免因为错误设置带来的问题和风险。
注：详细的抽取数据性能表现，请参考本系列另一文档：https://wsfwom2o40.feishu.cn/docx/RGrUdleDLoiNXuxwjzvcobstn7f
4.1 更新类型选择
1）数据表为维度表/数据量不大的表，可以使用全量更新。
2）表内有「时间戳」字段可用来和「更新时间」做对比以实现增量更新，并且历史数据不会变动的，优先考虑增量更新的方式。（服务器数据集和Excel数据集除外）
配置了增量更新时，增量更新的SQL不能为空。
增量删除时，请勿select * ，需要仅select唯一区分的字段，例如uuid。
4.2 更新任务调度策略
整体的更新策略为：全局定时更新+特殊业务包定时更新+特殊单表定时更新。也就是：除少部分特殊需求（如实时性要求较高，按天更新无法满足需求，或是业务具有特殊性可另行单独设置）外，其它非数据时效性需求的抽取模式数据集更新统一采用全局更新（业务包跟随全局更新进行更新，基础数据集跟随业务包更新进行更新，自助数据集跟随父表更新进行更新）。
在梳理更新策略时，可以优先设计全局更新时间（可依照中台最晚数据抽取完成时间进行灵活调整），若出现特殊情况，再配置业务包、表的定时更新。自助数据集无需配置，会跟随使用到的父表而自动更新。
不做全局更新，或在全局更新基础上仍要在别的时间单独更新较多表/业务包的，应当事先查看其相关血缘表。对于相关血缘表重合较多的任务，建议放到同一时间更新，因为只要一起更新，会自动去重，不会出现重复更新的问题；相反若设置为错开一段时间更新，两个更新任务牵连的表都有同一张表的话，那这张表可能会出现重复更新的情况，浪费资源；如果多个任务的相关血缘表几乎没有重合，则建议错开更新时间，防止系统阻塞。
如与数仓/中台数据更新时间有冲突，导致平台数据未能展示最新数据，管理员应当及时更新；但在更新时应当考虑数量级以及关联数据集个数，若数据集太大，或者关联过多(>50个)，应当在系统空余时间点击更新。
5.一些与系统性能有关的方案编辑
1）使用【全局内存控制】插件（已内置）：当业务使用使内存升高达到内存预警值时，可通过BI内存监控的保护机制，主动打断导出线程。
2）设置Excel导出限制参数：【管理系统】→【系统管理】→【常规】中，有两个参数对导出进行限制：
【Excel导出数据量限制】参数默认不设置，建议配置范围：0-1000000000；
【明细表导出并发线程数限制】默认值：3，建议配置范围：1-5（建议保持默认值）。
3）若使用nginx，可配置http2：可增加浏览器请求并发数（开启http2协议会导致数据库的并发数增多，需结合数据库性能评估）。
4）使用 FINE_CONF_ENTITY可视化配置 插件配置 SystemOptimizationConfig.queryConditionCountRestriction 参数：可对过滤条件数量超出限制的查询直接打断，并报错：condition count out of restriction: xxxx。
建议值：30（也可更小，取决于实际的过滤场景）。
5）安装【BI联动限制】插件：当一张仪表板中多个组件发生互相联动时，三层以及以上的联动会被删除，保留最后一次受到联动的组件之前的两层联动，由此保证了仪表板性能，不会产生加载很慢的现象。
6）限制组件查询时长：【管理系统】→【系统管理】→【常规】，有两个参数对组件查询时长进行限制：
当仪表板因组件过多，组件查询时间会过长，或者仪表板中某个组件查询时间过长，导致后续 BI 请求被阻塞误认为产品宕机时，可通过这两个参数设置【直连/抽取查询超时时间】，所有实时/抽取数据查询超时之后将会中止查询，防止异常慢查询阻塞其他正常查询。
建议配置范围：10-300，可根据实际业务情况和能接受的等待时长配置。
*注：此处抽取参数限制的是polars引擎，如果要使spider引擎也生效，需要设置 DistributedOptimizationConfig.spiderConfig.spider_query_timeout_open 和 DistributedOptimizationConfig.spiderConfig.spider_query_timeout_limit 参数，在并发大的情况下可以截断请求保证系统可用。
