1. 概述
1.1 应用场景
当 FineBI 从推广期进入稳定期后，需要对已经产生的数据进行运营和治理，保证系统的稳定运行。这对于高活跃量、高覆盖率、高访问量的系统是非常重要的。文章能够通过公共数据中权限调整、无用表清理，将BI系统进行规范化，清理出更多的空间，提升运行速度。
帆软内部 BI 系统（我们称为 crmBI）是一个超高活跃量的 BI 系统，经过三年半的运营，系统的日均访问量从早期小有规模的 1k+，增长到了现在的 1w，覆盖了帆软的所有业务团队。系统的公共数据中一共有 2w+个数据集，用户自己的自助数据集还不算在内。因为数据集太多，同一个业务场景下可能有多个由不同业务人员制作的数据表，比如搜索“需求处理”，可能会搜到十几个sql数据集、30多个自助数据集。使用者面对如此多的数据集，完全不知道自己应该用哪个。另外对于系统来说，数据集越多，对系统的资源压力也越大，无论是更新时长还是磁盘占用，长久来看都是有较大的风险的。
依据文档的分析思路，先已成功完成数据治理，提高了分析效率。
1.2 解决思路
出于使用的困扰和系统运维的考虑，crmBI运营团队开始开展对公共数据的“瘦身”。在进行了用户调研之后，运营团队得出了
1.3 推动执行人
数据运营团队
2. 数据体系搭建
大数据、高覆盖、高活跃的 BI 系统公共数据体系搭建，需要阅读以下建议：
2.1 搭建规范
数据管理员负责表数应尽量小于200
公共数据中要提供，支撑整个团队/部门或全体分析用户使用的官方数据，并且有明确的数据管理员对数据负责（包括但不限于对报错或新需求进行响应，对内容进行解释）
提供给分析用户可使用的表为结果数据（以宽表为主）；对于未处理的原始表，和过程中的中间表不提供给用户使用（如果从数据库中添加的表直接是可以使用的，那么它也是结果数据）
原因：
用户大部分需求集中在少数数据集中，需要重点关注，
用户的大部分分析需求，主要是集中在使用少部分数据集，基本符合二八定律
数据表越多会不断造成理解成本提升、数据准确性和使用体验的极大下降
2.2 层级设计
公共数据数据划分成三个层级，如下文所示：
分析数据
由业务团队使用基础数据加工后产生，在团队中具有较广泛的应用范围；主要是带有较强的业务逻辑数据。
对所在业务团队、或强业务配合团队开放“使用权限”
由业务团队的数据分析师承担数据管理员
有些数据是有业务团队产生的，并且供业务团队中的其他用户使用。对于这种数据的提供与管理就交由业务团队进行。但为了防止其他业务团队再不确认的情况下随便引用，所以不进行全员开放。
基础数据
提供由各类系统产生的业务基础数据，主要是原始数据，没有特别强的业务逻辑。
可对全员、或相关业务团队直接开放“使用权限”
由对应业务系统的IT人员，或负责对应业务分析师承担数据管理员角色
不公开数据
存放冷数据、中间表、不希望公开的原始表
冷数据：历史较为活跃，但当前使用量较低，现在偶尔有人在用，数据管理员准备不再维护。
中间表：数据管理员不希望客户使用的中间过程表。但现在已经被不少用户使用，难以很快都转为使用结果表
不公开原始表：未做任何处理的db表、sql表；多是还未关联维度、校验准确的事实表。
对用户仅开放“组件数据”权限，让已经使用的用户仍可查看，但无法在公共数据中找到该表，进行引用分析。
必须有相应的数据管理员
原因：对于冷数据与中间表：因为历史原因，用户还在用；但用户暂时没有时间去修改引用其他数据表，如果直接删除会导致不少报错，所以给用户一个过渡期。对于不公开原始表：主要因为基础表必须在公共数据的逻辑，同时又希望用户使用处理好的结果表，而不要直接使用该原始表
同时，为了方便用户使用，方便找到相应的数据管理员。每个文件目录都以业务团队来命名，并且每个文件夹的命名都会带有对应数据管理员的名字。
3. 公共数据治理
确定好治理的总思路之后，运营团队开启了以下3个动作：
清理不用的表
确定责任人及权责
理清权限
3.1 无用表清理
3.1.1 情况摸底
要整理某个空间，首先要把空间里的内容都展现在眼前。
对当前系统资源进行摸底统计，不但可以比较清晰的了解系统状况；也可以和治理后的情况进行对比，衡量效果。
通过 BI系统配置数据集 ，FineBI 管理员对数据集进行摸底，统计：
基础数据集的总数
自助数据集的总数、发布的个数
数据集的子数据集个数
某个时间段以后没有更新过的数据集个数
并根据数据表的敏感程度和生命周期确定治理优先级（需要根据业务情况具体了解）
敏感程度：常规数据-人事数据-营销财务数据
生命周期：个人属性的发布数据 > 废弃数据 > 不公开数据(冷数据、中间表、不公开原始表) > 公共中的Excel
3.1.2 取消发布「个人属性的发布数据」
如果是从 5.x升级上来的FineBI， 依据兼容逻辑会导致历史很多个人性质的数据表也被发布到了公共数据。例如：
A用户在给业务制作仪表板的过程中，使用了基础数据x，由于系统处理数据功能的限制，不得不基于x制作3个“中间自助数据集”，x1/x2/x3，而后再把这三个数据集合并成为自助数据集Y，将Y用于仪表板的开发。
受到权限体系的影响，这三个中间自助数据集不得不从“我的自助数据集”移动到普通的业务包目录中，在升级时，它们就会被发布为公共数据。而实际上，它们不会被其他任何人使用。
用户A会看到，在使用关系上，Y使用的是公共数据中的x1/x2/x3，而不是使用“我的分析”中的x1/x2/x3，违背了他制作的本意。
因此，本步骤的目的是通过工具，对这部分数据，将引用关系刷成「我的分析」中的数据，这样就将公共数据中个人属性的发布表孤立出来了，可以更方便清理。对于用户使用上来讲也是无感的。
利用上面提到的表信息统计工具，以及 合并主题插件 的功能，完成以下操作过程：
中间表识别，即表的创建者 和 子表/仪表板的创建者都是同一人的表。
发布替换下架通知
非敏感数据全量替换
对敏感数据进行沟通后谨慎替换（涉及人事、绩效考核、营销、财务统计的）
替换完成的表取消发布
3.1.3 清理已废弃数据
先和企业内部的相关团队开会讨论，确认「废弃数据」定义。
例如：升级后3个月没有更新的自助数据集+影响子表<2的db/sql表+影响子表<4的excel表。这些表在系统中，要么是不活跃的，要么是覆盖范围极小而不需要占用系统资源的。
确定一个较小的指标，是为了限制首次清理的范围，尽量减少对单个用户的使用影响。在后续的清理中，可以根据实际情况来调整指标值，例如可以考虑继续放宽限制为1个月未更新。
确定废弃表之后，运营团队将信息整理到文档中，并发布给所有使用者，公示一周进行确认。
而后，使用产品自带的 公共数据管理 功能，对db/sql表进行了删除处理，对自助数据集进行了取消发布。
3.1.4 处理不公开的表
在 2.2 节中，已经定义“不公开的表”。由于每个数据域的情况不尽相同，会和业务使用存在强关联。这一步无法由系统管理员直接执行，最好是由每个数据管理员根据业务需要来执行。因为业务逻辑不通，可能衡量的指标也有所差异。
数据运营团队将公共数据管理开放给次管直接使用，帮助了各业务部门的次管识别出不公开的表，而后辅助进行了目录创建、评估表使用情况、数据集移动、权限分配。
创建不公开目录
权限分配（详见下方3.3节）
评估表使用情况
数据管理员逐个沟通推进处理
3.2 确定责任人
公共数据管理不可能是一劳永逸的事情，也不是一个人就能干好的事情。为了能够让公共数据治理动作能够推动，且保持公共数据的长期保持较高质量，稳定使用。数据运营团队与部分拥有数据管理权责的同学达到一致，通过这些数据管理员（次管）同学，共同维护公共数据的整洁。
在这个阶段，进行了如下动作
划分数据域（同时引出目录整理动作），明确对应数据管理员
整理数据域的信息与其负责人，在企业内进行公开
系统中的文件夹和数据集进行署名
与业务负责人沟通，明确其管理数据范围、吸收数据管理方法、总结权责规范、监督实施
3.3 权限分配
3.3.1 应用背景
推广期
当BI还在推广期，往往数据大部分开放程度很高，除了一些高级别的人事、财务数据，绝大部分数据都可全员开放。这也导致了BI搭建之初，管理员也不知道如何较好的管理权限。所以当时admin给哪个部门开什么权限，都是admin拍脑袋自己决定的，唯一的依据就是挂模板时，说给xx部门开放，那就是要保证xx部门有这个业务包的权限。同时次级管理员给xx部门开哪些业务包权限，都由次管决定。
这样做的好处是：用户进入系统“公共数据”中的数据本身就不是非常多。为了推广用户增加粘性，给与用户较高程度的自由度，对比没有BI之前“给IT提需求”的使用模式，体验是很好的；同时管理员也不需要在权限维护和管理上投入很多精力，可以更好的投入到推广用户上。
稳定期
在系统过渡到稳定使用阶段之后，也带来了一些问题：“数据准备”中的表越来越多，每个团队都在不断的新增，用户经常会看到很多和自己没什么关系的数据表，这对搜索、寻找数据都带来了不好的体验。
3.3.2 实现思路
将“部门”迁移到了“角色”进行管理，仅保留“所有部门选项”用于开全员权限。
改为采用「角色」管理而不是「部门」主要是因为以下2点：
1. 有效减少层级关系和交集的问题，这类问题极大影响了权限的排查和设计
例如，将A表开给了所有部门角色，在排查某个同学为什么看不到A表时，需要从上往下一层一层检查是在哪个层级单独设置了关闭（基于用户看显示不出来）
2. 结合实际公司情况，因为公司内部职能线和业务线交叉混杂，这两条线并不适合一棵树进行管理
3.3.3 搭建默认角色框架
因此我们选择通过多个角色进行权限管控，比如按照部门时是XX产品线-XX小组，现在基于角色就是角色1：XX产品线，角色2：XX小组
转为角色管理后的优点：
角色更加灵活，结构较为简单
不需要考虑层级关系
角色间权限逻辑全部为并集
为了能够尽可能方便权限分配，每个BI设计用户会默认带四个角色（同用户同步模块）
一级组织：预留，实际未使用
团队：最常使用，基本代表业务单元
职能：较少使用，用于赋权职能侧公共数据，兼容之前的部门权限
团队职能：少量使用，特殊小团队控制权限使用，如：用户研究
3.3.4 权限梳理
1）操作步骤
有了默认角色框架，需要将原有部门上权限进行转移。先根据业务进行梳理，然后再重新配置权限，这里也是耗时较久的地方。操作步骤如下：
注：以上默认角色是通过同步实现的，我们可以通过修改角色同步的数据集，为每个用户直接同步多个默认角色，这里是不需要手动去维护默认角色的。
基于业务梳理权限，手动调配
基于sql脚本，将原有部门权限，全部刷到同名的角色权限上
2）注意事项
在重新梳理权限，决定给用户开放哪些数据时，要做好平衡：能让用户上来既能看到自己的数据，又不会出现大堆东西让用户不知所措。
既不能嫌麻烦，把所有数据直接做全员开放。这样会导致每个用户上来看到的公共数据一大堆，用的时候不知道用哪个，还是要来询问。
也不能不敢开，把所有权限都收紧。这样会导致新用户上来找不到自己想用的相关数据，很大程度抑制了自助分析的积极性。
除了默认角色之外，所有次级管理员(数据管理员)也全部通过角色进行维护。
该类角色为手动创建，基于实际数据管理员的管理范围配置对应管理及授权权限。
上一篇：数据更新规范
