2019-10-27

今日学习心得：
数据的存储空间，读写记录，权限归属和其它各类统计信息
这类信息，可能包括但不限于：数据占据了多少底层存储空间，最近是否有过修改，都有谁在什么时候使用过这些数据，谁有权限管理和查阅这些数据等等。此外，还可以包括类似昨天新增了多少个表格，删除了多少表格，创建了多少分区之类的统计信息。

在正常的工作流程中，多数人可能不需要也不会去关心这类信息。但是落到数据质量管理这个话题上时，这些信息对于系统和业务的优化，数据的安全管控，问题的排查等工作来说，又往往都是不可或缺的重要信息，所以通常这类信息也可以从Audit审计的角度来归类看待。

与表结构信息类似，对于这类Audit审计类信息的采集和管理，通常具体的底层数据存储管理组件自身的功能也无法直接满足我们的需求，需要通过专门的元数据管理平台中统一进行采集，加工和管理。

数据的血缘关系信息
血缘信息或者叫做Lineage的血统信息是什么，简单的说就是数据之间的上下游来源去向关系，数据从哪里来到哪里去。知道这个信息有什么用呢？用途很广，举个最简单的例子来说，如果一个数据有问题，你可以根据血缘关系往上游排查，看看到底在哪个环节出了问题。此外我们也可以通过数据的血缘关系，建立起生产这些数据的任务之间的依赖关系，进而辅助调度系统的工作调度，或者用来判断一个失败或错误的任务可能对哪些下游数据造成影响等等。
分析数据的血缘关系看起来简单，但真的要做起来，并不容易，因为数据的来源多种多样，加工数据的手段，所使用的计算框架可能也各不相同，此外也不是所有的系统天生都具备获取相关信息的能力。而针对不同的系统，血缘关系具体能够分析到的粒度可能也不一样，有些能做到表级别，有些甚至可以做到字段级别。

以hive表为例，通过分析hive脚本的执行计划，是可以做到相对精确的定位出字段级别的数据血缘关系的。而如果是一个MapReduce任务生成的数据，从外部来看，可能就只能通过分析MR任务输出的Log日志信息来粗略判断目录级别的读写关系，从而间接推导数据的血缘依赖关系了。

数据的业务属性信息
前面三类信息，一定程度上都可以通过技术手段从底层系统自身所拥有的信息中获取得到，又或着可以通过一定的流程二次加工分析得到。与之相反，数据的业务属性信息，通常与底层系统自身的运行逻辑无关，多半就需要通过其他手段从外部获取了。

那么，业务属性信息都有哪些呢？最常见的，比如，一张数据表的统计口径信息，这张表干什么用的，各个字段的具体统计方式，业务描述，业务标签，脚本逻辑的历史变迁记录，变迁原因等等，此外，你也可能会关心对应的数据表格是由谁负责开发的，具体数据的业务部门归属等等。

上述信息如果全部需要依靠数据开发者的自觉填写，不是不行，但是显然不太靠谱。毕竟对于多数同学来说，对于完成数据开发工作核心链路以外的工作量，很自然的反应就是能不做就不做，越省事越好。如果没有流程体系的规范，如果没有产生实际的价值，那么相关信息的填写很容易就会成为一个负担或者是流于形式。

所以，尽管这部分信息往往需要通过外部手段人工录入，但是还是需要尽量考虑和流程进行整合，让它们成为业务开发必不可少的环节。比如，一部分信息的采集，可以通过整体数据平台的开发流程规范，嵌入到对应数据的开发过程中进行，例如历史变迁记录可以在修改任务脚本或者表格schema时强制要求填写；业务负责人信息，可以通过当前开发人员的业务线和开发群组归属关系自动进行映射填充；字段统计方式信息，尽可能通过标准的维度指标管理体系进行规范定义。

总体来说，数据的业务属性信息，必然首先是为业务服务的，因此它的采集和展示也就需要尽可能的和业务环境相融合，只有这样才能真正发挥这部分元数据信息的作用。