业务元数据管理——洞悉数据背后的业务含义

最新推荐文章于 2022-10-13 01:25:49 发布

weixin_33782386

最新推荐文章于 2022-10-13 01:25:49 发布

阅读量115

点赞数

文章标签：大数据数据库人工智能

原文链接：https://yq.aliyun.com/articles/219367

版权

本文讲的是业务元数据管理——洞悉数据背后的业务含义，目前，很多企业已经意识到，由于业务人员看不懂系统中存储的数据，所以难以通过大数据来提升业务创新能力，本文就来谈谈解决这个问题的方法——业务元数据管理。（同系列文章请点击王轩的文章《面向业务的企业元数据管理》）

目录：
一、计算机和人之间出现“语义屏障”
二、业务元数据——数据背后的业务上下文
三、基于本体的业务元数据管理实践
四、总结与展望
一、计算机和人之间出现“语义屏障”
大概70多年前的一个情人节，ENIAC诞生在了美国宾夕法尼亚大学，从此人类开启了在计算机“智能化”上的探索，“语言识别”、“图像识别”、“自然语言处理”各种技术日益成熟，我们几乎可以往计算机系统中输入任何想输入的信息，但是反过来，我们能否正确理解计算机的输出数据？

随着数据的增多，我们发现已经很难弄清楚这些数据背后的具体含义——我们和计算机系统之间的语义屏障已经产生。语义屏障的存在，给企业带来了一系列问题：

业务理解不一致
员工对业务的理解不一致的现象在企业中非常普遍。对业务术语理解的不一致让员工无法交流，产生误会，降低沟通效率；在会议决策时，领导对业务理解不一致有可能导致错误决策；在部门统计时，对业务定义的理解不一致将会导致统计方式不一致，造成统计不准确，甚至会影响到企业多个指标和KPI的统计结果。
查找信息很困难
大数据时代，企业数据量呈爆发式增长，员工查找信息越来越像“大海捞针”。据统计，企业员工每天要花费15%——35%的时间在海量信息中查找需要的数据，只有少于50%的搜索结果是满足需求的，大多情况下的查找结果都不尽如人意；因为查找不到已经存储过的信息，企业经常会做一些不必要的重复工作。
人员流失损失大
据统计，企业平均每年的人员离职率在12%左右，因为没有一套业务上的管理办法，企业经常要在很懂“计算机”的员工离职后，花费大量的时间和成本来给新人做培训，造成严重的知识流失和金钱消耗。
以上一系列问题的出现，归根结底是因为企业员工“读不懂”计算机中的数据，企业需要打破计算机与人之间的语义屏障，将计算机输出变成业务人员可理解的业务语言，避免这些问题的发生，业务元数据正是解决问题的关键。

二、业务元数据——数据背后的业务上下文
要说清楚业务元数据是什么，得从元数据的分类说起，目前业界比较认可的一种分类方式是将元数据分为两种：技术元数据和业务元数据。
技术元数据包括：字段名称、字段长度、数据库表结构等。
业务元数据包括：业务名称、业务定义、业务描述等。
业务人员更多关注的是与“客户”、“结算日期”、“销售金额”等相关的内容，这些内容很难从技术元数据中体现出来。
业务元数据使用业务名称、定义、描述等信息表示企业环境中的各种属性和概念，从一定程度上讲，所有数据背后的业务上下文都可以看成是业务元数据。与技术元数据相比，业务元数据能让用户更好地理解和使用企业环境中的数据，比如用户通过查看业务元数据就可以清晰地理解各指标的含义，指标的计算方法等信息。
业务元数据广泛存在于企业环境中，业务元数据的来源主要有：
ERP
企业ERP系统中存储着大量的业务元数据，比如说财务计算公式、过程逻辑、业务规则等。
报表
报表的表头也是一种业务元数据，特别是那些包含合计、平均数等带有总结性质的列，报表中的一些计算公式等。
表格
与报表类似，EXCEL的表头和公式也是很重要的业务元数据。与报表不同的是，大多数表格中会有单独一列“描述”，有些表格中还会有一列代码和代码描述，这些都是很有用的业务元数据。
文件
文件中到处都是业务元数据，比如标题、作者、修改时间等，文件内容中的业务元数据的获取相对比较困难，涉及到机器学习等技术。
BI工具
BI中经常会用到的操作就是“钻取”操作，向上和向下钻取中通常定义了企业的各种分类结构，例如产品等级和组织结构等级等，这些都是很重要的业务元数据。
数据仓库
数据仓库中也有业务元数据存在，比如说，构建数据仓库之前通常需要做大量调研来研究如何集成多个数据源，这些如数据仓库构建过程相关的文件中存在着大量的业务元数据。

下图是两个具体的例子：
左图是某建筑公司的一张报表，我们可以看到，报表中包含了报表名称、填报时间、制表人和报表表头名称等，这些都是高价值的业务元数据；右图是某公司新员工入职申请表，和报表类似，申请表名称、姓名、性别等申请表各栏名称都是业务元数据。

目前，大部分企业只关注到了技术元数据，忽略了对业务元数据的管理。技术元数据缺少业务含义，很难被技术人员之外的人所理解，比如可能用“rec_temp_fld_a”表示某个字段，用“236IN_TAB”表示数据库中的某张表，在不被理解的情况下很难给企业业务带来收益。业务元数据能代表数据背后的业务含义，企业在对技术元数据管理的同时需要注重业务元数据的管理。

与技术元数据相比，业务元数据来源更复杂，分散在企业环境的方方面面，为实现业务元数据的管理，企业需要有效的方法和手段。
三、基于本体的业务元数据管理实践
前业界比较认可的本体定义是：共享概念模型的明确的形式化规范说明。其中，概念模型是将客观世界中的一些现象抽象出来得到的模型，是客观世界的抽象和简化；共享是指，本体中所描述的知识不是个人专有的而是领域公认的；明确是说，对于所使用的概念的类型以及概念用法的约束都明确地加以定义；形式化是指，本体是机器可读的，同时也是人类可理解的。
总结之，本体能够对领域中的客体进行分析，并找出这些客体之间的关系，从而明确、形式化地描述这个领域中的业务。
下图是“合同”本体的可视化表示，从图中可以看到“合同”这个本体中包含了“合同权限”、“合同条款”、“合同义务”等大量与合同有关的概念和“conformed by”、“implied by”、“has terms”等概念之间的关系，能够让人们充分理解合同相关业务。因为本体是机器可读的，这意味着，若企业能够构建出业务相关的所有本体，通过本体的方式来管理业务元数据，就可以消除计算机与人类之间的语义屏障。

通过本体来管理业务元数据需要注意三个关键点：本体的构建、本体的存储、本体的使用。
1、构建——采用元数据管理自动化构建本体
传统构建本体的方式是根据业务专家的建议，人工梳理出业务领域的本体，这种人工梳理的方式存在一系列问题：
效率问题：在大数据环境下，数据复杂，来源多样，业务领域持续增多,人工梳理的速度已经不能满足企业需求。
工具问题：业务专家缺少具备自动化能力的工具，导致复杂本体的构建要消耗大量的时间和资源。
第三方数据：企业专家不了解第三方数据的相关业务，很难完成相关本体的构建。

在大数据环境下企业需要新的本体构建方式，企业可以通过元数据管理工具自动抽取企业应用系统和各类文档中的元数据，初步形成本体之后，再交给业务专家二次审核，最后完成企业本体的构建。
2、存储——以MOF为基础实现OWL规范存储本体
本体的存储需要依据一定的标准，同时存储的方式需要具备灵活性和扩展性。OWL规范是W3C推荐的规范，是目前广泛认可的本体存储与交换规范,由于我们的元数据基于MOF，可以在元模型中建立OWL的元模型，所以能实现本体在元数据库内的存储和管理。

由于技术元数据和本体都已经存储在元数据库中，而本体本来也是从技术元数据中抽取出来的，这样很容易获得本体和技术元数据之间的关联，让业务人员清晰地了解数据背后的业务含义。
3、使用——通过业务元数据服务，获得业务上下文
最后，需要把业务元数据的服务提供给所有业务人员，内嵌在业务人员的工作环境中，使业务人员能够快速地从业务角度理解数据，从而帮助业务人员更好地使用数据。