反馈已提交

网络繁忙

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

公共数据体系设计

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

    1.1 应用场景

    在进行企业数据分析时,经常会遇到这样的问题:

    信息部数据管理人员

    对于数据的分发管控困难,取数分散,数据口径不统一;

    数据维护更新困难,数据变动或者指标缺失时维护成本很高;

    数据复杂,数据未分层,跨层关联多,更新和计算性能不好。

                       业务分析人员分析需求响应缓慢,没有数据集市,无法快速获取想要的数据,实现自助分析。

    此时搭建「公共数据体系」进行数据的分组即可以解决这些问题。

    通过新建文件夹,分门别类的将数据表存放在 BI 中,理清杂乱的数据关系。

    让没有数据分析基础的用户,可以根据分析所需维度&指标,快速地获取数据,减少数据分析的阻力;同时为数据更新和后续的数据权限开放打好坚实的基础。

    公共数据体系在搭建后能实现:

    • 数据表文件夹分门别类,统一命名规范,方便查找与管理。

    • 便于后续持续的进行数据的添加和补充。

    1.2 预期效果

    将数据库中的数据表进行分类,有序添加至 FineBI 中,并进行层级梳理,使得不同用户能够取自己需要的数据进行自助分析。

    以下为一个企业 BI 公共数据体系示例:

    1.3 实现思路

    2. 公共数据层级构建规则

    1)在BI中给公共数据分层,应遵循便捷数据分发管理、提高系统性能、便于数据维护更新的原则,使得公共数据分层之后,尽量减少层级关联,控制更新量级,数据权限分配更简易。

    2)由于各公司所处行业、数仓架构各不相同,BI中可以根据公司业务类型、系统、使用部门、公共数据负责人来构建公共数据体系。参考案例:

    3)一般来说,管理员在管理公共数据时需遵循公共数据责任制:

    • 每个文件夹按需分配数据管理员,通常原始数据管理员为IT人员、基础数据为部门数据分析师、分析表负责人为制作该分析表的部门业务人员。

    • 管理员为自己的文件夹数据质量兜底,包括但不限于无重复数据表、指标逻辑正确、数据口径一致等。

    • 公共数据为官方唯一出口,公共数据管理员所发布的数据为对应模块的唯一官方数据。

    • 权限和维护制度参考案例:

    4)公共数据命名四要素为:①业务/系统/使用部门 + ②公共数据层级 + ③数据信息 + ④公共数据负责人。命名规则可根据企业实际情况来调整,不一定要严格按照命名规范中的定义,例如在有一些客户应用过程中,就通常会简化命名,直接省略一些前缀。参考案例:

    公共数据命名规则
    文件夹
    层次结构命名规则层次结构命名规则
    原始数据所属文件夹
    • 需包含业务属性&表层级属性

    • 命名示例:OA_原始数据、公共_原始数据

    原始数据
    • 需包含业务属性&表层级属性&使用部门属性&责任人属性&表名属性

    • 命名示例:人事部_OA原始数据_流程节点部门维度表_张三

    基础数据所属文件夹
    • 需包含业务属性&表层级属性

    • 命名示例:OA_原始数据、公共_原始数据

    基础数据
    • 需包含业务属性&表层级属性&使用部门属性&责任人属性&表名属性

    • 命名示例:人事部_OA基础数据_流程节点耗时大宽表_张三

    分析数据所属文件夹
    • 需包含业务/部门属性&表层级属性

    • 命名示例:OA_分析数据、营销部_分析数据

    分析数据
    • 需包含业务属性&表层级属性&使用部门属性&责任人属性&表名属性

    • 命名示例:人事部_OA分析数据_报销流程费用汇总_张三

    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)公共数据最理想的情况,可以从以下角度参考:

    • 以业务模块作为区分不再分层,每个用户在自己的团队目录下就能找到所有需要的数据,并且相同的数据只有一份(不再区分数据表的类型)

    • 公共中的数据都有良好数据质量,维度清晰、口径统一、主键清晰。不需要用户再去确认维度信息、校验计算口径是否符合预期;跨数据域的联合分析,不会出现关联不上,强行拼接数据的情况。

    • 权责清晰,所有发布到公共中的数据表都进行过严格的审核,并且不会出现相似数据重复发布的情况。

    • 支持数据模型的发布,用户可直接引用或复用成型的数据模型;并基于新的分析结论,不断反哺优化已有的数据模型。

    附件列表


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

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

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

    不再提示

    10s后关闭

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