2019-10-26

我们通常会使用MySQL管理hive的元数据，只要在hive-site.xml中写入库路径、连接驱动、用户名和密码即可。
但是在企业中，我们可以使用统一元数据管理：EMR
相较于MySQL，EMR有如下优点

EMR中的数据不会随着集群的释放而消失，所以可以实现元数据的持久化存储，但是需要注意的一点是在删除表之前，一定要确认元数据已经删除，否则会造成脏数据的产生
第二个优点，可以实现计算存储分离，可以把数据放在阿里云的OSS上，节省了数据迁移问题的同时，也大大节省了集群成本，EMR集群只负责计算，计算后可直接释放，在OSS上实现存储
可以实现多个EMR集群的资源共享，不必进行元数据的迁移和共享，所有的数据都存储在OSS，可以直接进行访问。
但是要注意的是EMR-WEB端只能创建外部表和分区表。

有了统一的元数据管理之后，就可以实现：
提供持久化的元数据存储
之前元数据都是在集群内部的 mysql 数据库，元数据会随着集群的释放而丢失，特别是 EMR 提供了灵活按量模式，集群可以按需创建用完就释放。如果用户需要保留现有的元数据信息，必须登录上集群手动将元数据信息导出。支持统一的元数据管理之后，不再存在该问题。

能更方便地实现计算存储分离
EMR 上可以支持将数据存放在阿里云 OSS 中，在大数据量的情况下将数据存储在 OSS 上会大大降低使用的成本，EMR 集群主要用来作为计算资源，在计算完成之后机器可以随时释放，数据在 OSS 上，同时也不用再考虑元数据迁移的问题。

更方便地实现数据共享
使用统一的元数据库，如果用户的所有数据都存放在 OSS 之上，则不需要做任何元数据的迁移和重建所有集群都是可以直接访问数据，这样每个 EMR 集群可以做不同的业务，但是可以很方便地实现数据的共享。

什么是元数据：
元数据MetaData狭义的解释是用来描述数据的数据，广义的来看，除了业务逻辑直接读写处理的那些业务数据，所有其它用来维持整个系统运转所需的信息／数据都可以叫作元数据。比如数据表格的Schema信息，任务的血缘关系，用户和脚本／任务的权限映射关系信息等等。

数据治理的第一步，就是收集信息，很明显，没有数据就无从分析，也就无法有效的对平台的数据链路进行管理和改进。所以元数据管理平台很重要的一个功能就是信息的收集，至于收集哪些信息，取决于业务的需求和我们需要解决的目标问题。

信息收集再多，如果不能发挥作用，那也就只是浪费存储空间而已。所以元数据管理平台还需要考虑如何以恰当的形式对这些元数据信息进行展示，进一步的，如何将这些元数据信息通过服务的形式提供给周边上下游系统使用，真正帮助大数据平台完成质量管理的闭环工作。

应该收集那些信息，虽然没有绝对的标准，但是对大数据开发平台来说，常见的元数据信息包括：

数据的表结构Schema信息
数据的空间存储，读写记录，权限归属和其它各类统计信息
数据的血缘关系信息
数据的业务属性信息

数据的表结构Schema信息
数据的表结构信息，这个很容易理解了，狭义的元数据信息通常多半指的就是这部分内容了，它也的确属于元数据信息管理系统中最重要的一块内容。

不过，无论是SQL还是NoSQL的数据存储组件，多半自身都有管理和查询表格Schema的能力，这也很好理解如果没有这些能力的话，这些系统自身就没法良好的运转下去了不是。比如，Hive自身的表结构信息本来就存储在外部DB数据库中，Hive也提供类似 show table，describe table之类的语法对这些信息进行查询。那么我们为什么还要多此一举，再开发一个元数据管理系统对这些信息进行管理呢？

这么做，可能的理由很多，需要集中管理可以是其中一个理由，但更重要的理由，是因为本质上，这些系统自身的元数据信息管理手段通常都是为了满足系统自身的功能运转而设计的。也就是说，它们并不是为了数据质量管理的目的而存在的，由于需求定位不同，所以无论从功能形态还是从交互手段的角度来说，它们通常也就无法直接满足数据质量管理的需求。

举个很简单的例子，比如我想知道表结构的历史变迁记录，很显然多数系统自身是不会设计这样的功能的。而且一些功能就算有，周边上下游的其它业务系统往往也不适合直接从该系统中获取这类信息，因为如果那样做的话，系统的安全性和相互直接的依赖耦合往往都会是个问题。

所以，收集表结构信息，不光是简单的信息汇总，更重要的是从平台管理和业务需求的角度出发来考虑，如何整理和归纳数据，方便系统集成，实现最终的业务价值。