数据仓库工作日记_记录（二）-数据治理下

  序言

  前面的博客中提到了系统的现状，只有两层，ods和dw，也描述了是做什么用的了，所以我也就不画高大上的流程图，架构图出来了。描述了系统现有的问题情况，也提出了解决的办法，作为数据治理最后的一部分，来讲讲数据仓库的元数据管理。

  所谓元数据管理，就是管理数据仓库中数据以外的数据（具体的官方概念大家依旧可以度娘，狗哥）。我参与了很多数据仓库项目，其中包括像中国某知名运营商省级公司的数据仓库，某国字号保险公司数据仓库的项目和一些股份制银行的项目。对比一下，前面说的通讯行业和保险公司的数据仓库都有国内的外包公司开发，其中并没有元数据据管理模块，而在银行业中，td和ibm提供的解决方案中有健全的元数据管理方案，并完全落地实施了，还是人家外企严谨规范一些啊。

  背景

  其实按照咱[和谐]的大外包行业惯例来说，方案写得美，代码乱成鬼，拼命往上堆（二声），交付全靠嘴，这种地方商业银行项目是不该有元数据管理的。这缘于客户的it经理一直在维护这数据仓库，想把事情做好，也为升职打算；而我做事是要么不做，要么做好，遇到那种2个月出烂项目敷衍客户的事情是不会做的，所以两个人碰到了一起，在数据治理的基础上，建设元数据管理架构，为以后的数据质量和仓库的健壮性打下基础。

  结构设计

  根据需求，提出了基于oracle数据库元数据管理的系统结构图，因为有一些定制性的东西，我进行了一些调整后，结构图如下：

  从右上角开始，介绍一下流程：

  1.新增应用系统：这里的新增应用系统包括数据仓库自身和其他数据应用系统，如报表系统，保送系统等。为了能够更好的将数据仓库相关的数据都纳入管理，所以在这个功能下可以配置数据库ip，用户名，密码，dblink，系统名称等信息，基于以上配置，目前主流的关系性数据库都有以上功能支持，实现跨库，跨应用的数据集成管理。

  2.数据仓库主题配置：之所以在这里增加主题的配置，是应为数据仓库的表太多了，主题是一个很有效也具有实际意义的过滤条件。

  3.新增表配置：表是数据存储的基本单位，这里主要的配置有表名，存储过程名，包名（当存储过程在包里时无法获取表对应的存储过程名，因此需要配置），主题，以及最重要的mapping。mapping数据主要是数据的映射关系，分源和目标，用户可以在界面选择源表及目标表的信息并进行对应配置，包括应用系统也可以配置；配置完成后可以通过比较友好的图形界面查询某一张表和某一个字段的数据映射关系。这里涉及到公司的产品信息，有兴趣的朋友可以联系我。说明：这里的配置信息都是从数据库系统数据读取的，一些用调度工具的项目，可以在此读取调度工具数据库用户下的相关信息。

  4.数据库描述性信息：也就是左侧的一些oracle系统表提供的信息，将目前数据仓库的物理信息提供给用户；并在这里进行一些信息的再利用，比如表空间信息，空间不足时，给出提示，或分区不足时给出提示等。对这些信息收集是一个etl的过程，并将结果数据存进对应的目标里，之所以在这里建通用语义的表，一方面是展示时间少计算量，另一方面考虑的就是可移植性了。

  5.日志分析：日志每个数据仓库基本都有。这里只是将日志的数据加以再利用，如各系统运行时间的占比，数据量变化的折线图等，并保留历史数据，可供深度分析。

  6.标准数据：这个不是每个项目都有的功能，具体的描述，大家可以看我前面的博客。

  展示

  其实我一直都不赞同在数据仓库中，直接部署用户交互复杂的展现页面，数据量大，响应慢，用户体验不好：同时，应用发出的各种语句很难控制，也给数据仓库造成了不必要的安全隐患。

  这里的展示主要包括了一些友好的数据配置界面，和mapping查询，数据仓库日志分析的饼图折线图等内容，感兴趣的朋友可以联系我。