1. 概述
1.1 应用场景
在进行企业数据分析时，经常会遇到这样的问题：
| 信息部数据管理人员 | 对于数据的分发管控困难，取数分散，数据口径不统一； 数据维护更新困难，数据变动或者指标缺失时维护成本很高； 数据复杂，数据未分层，跨层关联多，更新和计算性能不好。 |
|---|---|
| 业务分析人员 | 分析需求响应缓慢，没有数据集市，无法快速获取想要的数据，实现自助分析。 |
此时搭建「公共数据体系」进行数据的分组即可以解决这些问题。
通过新建文件夹，分门别类的将数据表存放在 BI 中，理清杂乱的数据关系。
让没有数据分析基础的用户，可以根据分析所需维度&指标，快速地获取数据，减少数据分析的阻力；同时为数据更新和后续的数据权限开放打好坚实的基础。
公共数据体系在搭建后能实现：
数据表文件夹分门别类，统一命名规范，方便查找与管理。
便于后续持续的进行数据的添加和补充。
数据治理经验请参考：数据治理规范
1.2 预期效果
将数据库中的数据表进行分类，有序添加至 FineBI 中，并进行层级梳理，使得不同用户能够取自己需要的数据进行自助分析。
以下为一个企业 BI 公共数据体系示例：
1.3 实现思路
2. 公共数据层级构建规则
1）在BI中给公共数据分层，应遵循便捷数据分发管理、提高系统性能、便于数据维护更新的原则，使得公共数据分层之后，尽量减少层级关联，控制更新量级，数据权限分配更简易。
2）由于各公司所处行业、数仓架构各不相同，BI中可以根据公司业务类型、系统、使用部门、公共数据负责人来构建公共数据体系。参考案例：
3）一般来说，管理员在管理公共数据时需遵循公共数据责任制：
每个文件夹按需分配数据管理员，通常原始数据管理员为IT人员、基础数据为部门数据分析师、分析表负责人为制作该分析表的部门业务人员。
管理员为自己的文件夹数据质量兜底，包括但不限于无重复数据表、指标逻辑正确、数据口径一致等。
公共数据为官方唯一出口，公共数据管理员所发布的数据为对应模块的唯一官方数据。
权限和维护制度参考案例：
4）公共数据命名四要素为：①业务/系统/使用部门 + ②公共数据层级 + ③数据信息 + ④公共数据负责人。命名规则可根据企业实际情况来调整，不一定要严格按照命名规范中的定义，例如在有一些客户应用过程中，就通常会简化命名，直接省略一些前缀。参考案例：
注：为了方便用户使用，方便找到相应的数据管理员。每个文件目录都以业务团队来命名，并且每个文件夹的命名都会带有对应数据管理员的名字。
| 公共数据命名规则 | |||
| 文件夹 | 表 | ||
| 层次结构 | 命名规则 | 层次结构 | 命名规则 |
| 原始数据所属文件夹 |
| 原始数据 |
|
| 基础数据所属文件夹 |
| 基础数据 |
|
| 分析数据所属文件夹 |
| 分析数据 |
|
5）除了根据不同组织、系统、业务主题划分文件夹外，为便于后续对不同的用户分配不同的数据使用等权限，可以创建「公共」文件夹，用于存放 BI 系统中多个部门公共使用的数据表以及配置 BI 权限的数据表，避免权限混乱。同时管理员定期关注业务用户自助分析沉底出的关键数据，基于此不断滚动优化提供的公共数据表质量。
6）公共数据体系设计参考案例：
3. 数据集规则
3.1 数据集命名规则
对于公共数据集来说，名字是最直观的能够解释数据的要素，因此统一的命名规则很重要，良好且清晰的命名有助于减少沟通成本、快速理解数据集内容。
参考命名规范：
部门_数据集内容_添加者
分析指标_业务用途_添加者
表粒度_业务含义_来源库
3.2 数据管理
公共数据集中应包括原始数据、基础数据和分析表，同一类的表应在同一层内。在按照部门或业务类型分组后，需要再在此分组下再划分原始数据、基础数据和分析表。
构建原则：
1）原始数据一般是来自ODS层的表，在BI中作为不会直接使用的底层表存在，为非必须层级，主要是为了保持可扩展性，当数据量较大时，会造成一定的数据冗余,可根据实际情况选择。
2）基础数据一般是来自DM层的表，具有一定的业务含义和覆盖范围。
添加规则：高内聚 低耦合。
要保证表中包含的字段与基础表主题是高度贴合的。
3）分析表一般是业务人员在BI中加工基础表得到的汇总表，管理员只需要准备好原始数据与基础数据并分配权限即可,分析数据一般不需要管理员进行添加。
3.3 公共数据管理思路
6.0的公共数据在概念上属于企业内部对用户开放的公共数据，这部分数据若不加规范，长期来看会使得企业的数据使用情况不佳，主要体现在冗余资源不断增多、数据血缘关系逐渐混乱、用户使用数据难度增加。
超级管理员以及所有的次级管理员（有权限进行公共数据管理的用户）应当具有以下意识：
1）上下架流程规范化：公共数据内数据的上架和下架，都要符合一定的流程规范，记录必要的信息。
2）数据表维护责任制：每一个数据表都要有明确的责任人，由责任人负责对该数据的解释、答疑、查错和后续的维护。
3）完善公共数据描述：对公共数据集来说，简单但完善的说明有利于其他人员的使用。
4）明确数据集逻辑和边界：尽量保证数据集之间的联系和区别是清晰的，避免出现相同的业务有多个表的情况。
5）公共数据最理想的情况，可以从以下角度参考：
以业务模块作为区分不再分层，每个用户在自己的团队目录下就能找到所有需要的数据，并且相同的数据只有一份（不再区分数据表的类型）
公共中的数据都有良好数据质量，维度清晰、口径统一、主键清晰。不需要用户再去确认维度信息、校验计算口径是否符合预期；跨数据域的联合分析，不会出现关联不上，强行拼接数据的情况。
权责清晰，所有发布到公共中的数据表都进行过严格的审核，并且不会出现相似数据重复发布的情况。
支持数据模型的发布，用户可直接引用或复用成型的数据模型；并基于新的分析结论，不断反哺优化已有的数据模型。
更多数据治理经验请参考：数据治理规范
