元数据办理理论\u0026数据血统

leixinyi

甚么是元数据？元数据MetaData广义的解释是用来形容数据的数据，狭义的来看，除了业务逻辑间接读写处置的那些业务数据，一切其它用来维持全部零碎运行所需的信息／数据均可以叫作元数据。好比数据表格的Schema信息，工作的血统瓜葛，用户和脚本／工作的权限映照瓜葛信息等等。
办理这些附加MetaData信息的目的，一方面是为了让用户可以更高效的挖掘和使用数据，另外一方面是为了让平台办理人员能更为无效的做好零碎的保护办理任务。
登程点很好，但通常这些元数据信息是散落在平台的各个零碎，各种流程之中的，而它们的办理也可能或多或少能够经过各种子零碎本身的工具，计划或流程逻辑来完成。那末咱们所说的元数据办理平台又是用来做甚么的？是否一切的信息都应该或者有须要采集到一个零碎中来进行一致办理呢，详细又有哪些数据应该被归入到元数据办理平台的办理规模之中呢？上面咱们就来讨论一下相干的内容。
元数据办理平台管甚么
数据治理的第一步，就是采集信息，很显著，没无数据就无从剖析，也就无奈无效的对平台的数据链路进行办理和改进。所以元数据办理平台很首要的一个功用就是信息的采集，至于采集哪些信息，取决于业务的需要和咱们需求解决的指标问题。
信息采集再多，假如不克不及发扬作用，那也就只是挥霍存储空间罢了。所以元数据办理平台还需求斟酌如何以失当的方式对这些元数据信息进行展现，进一步的，如何将这些元数据信息经过办事的方式提供应周边上上游零碎使用，真正帮忙大数据平台实现品质办理的闭环任务。
应该采集那些信息，虽然没有绝对的规范，然而对大数据开发平台来讲，常见的元数据信息包罗：
数据的表构造Schema信息数据的空间存储，读写记载，权限归属和其它各类统计信息数据的血统瓜葛信息数据的业务属性信息
上面咱们针对这四项内容再详细展开探讨一下
数据的表构造Schema信息
数据的表构造信息，这个很容易了解了，广义的元数据信息通常多半指的就是这部份内容了，它也确实属于元数据信息办理零碎中最首要的一块内容。
不外，无论是SQL仍是NoSQL的数据存储组件，多半本身都有办理和查问表格Schema的才能，这也很好了解假如没有这些才能的话，这些零碎本身就没法良好的运行上来了不是。好比，Hive本身的表构造信息原本就存储在内部DB数据库中，Hive也提供相似 show table，describe table之类的语法对这些信息进行查问。那末咱们为何还要多此一举，再开发一个元数据办理零碎对这些信息进行办理呢？
这么做，可能的理由得多，需求集中办理能够是其中一个理由，但更首要的理由，是由于实质上，这些零碎本身的元数据信息办理伎俩通常都是为了知足零碎本身的功用运行而设计的。也就是说，它们并非为了数据品质办理的目的而存在的，因为需要定位不同，所以无论从功用状态仍是从交互伎俩的角度来讲，它们通常也就无奈间接知足数据品质办理的需要。
举个很简略的例子，好比我想知道表构造的历史变迁记载，很显然少数零碎本身是不会设计这样的功用的。并且一些功用就算有，周边上上游的其它业务零碎往往也不合适间接从该零碎中获得这种信息，由于假如那样做的话，零碎的平安性和互相间接的依赖耦合往往都会是个问题。
所以，采集表构造信息，不光是简略的信息汇总，更首要的是从平台办理和业务需要的角度登程来斟酌，如何整顿和归结数据，便利零碎集成，完成终究的业务价值。
数据的存储空间，读写记载，权限归属和其它各类统计信息
这种信息，可能包罗但不限于：数据占领了多少底层存储空间，比来是不是有过修正，都有谁在何时使用过这些数据，谁有权限办理和查阅这些数据等等。另外，还能够包罗相似昨天新增了多少个表格，删除了多少表格，创立了多少分区之类的统计信息。
在正常的任务流程中，少数人可能不需求也不会去关怀这种信息。然而落到数据品质办理这个话题上时，这些信息关于零碎和业务的优化，数据的平安管控，问题的排查等任务来讲，又往往都是不成或缺的首要信息，所以通常这种信息也能够从Audit审计的角度来归类对待。
与表构造信息相似，关于这种Audit审计类信息的收集和办理，通常详细的底层数据存储办理组件本身的功用也无奈间接知足咱们的需要，需求经过专门的元数据办理平台中一致进行收集，加工和办理。
数据的血统瓜葛信息
血统信息或者叫做Lineage的血缘信息是甚么，简略的说就是数据之间的上上游来源去向瓜葛，数据从哪里来到哪里去。知道这个信息有甚么用呢？用处很广，举个最简略的例子来讲，假如一个数据有问题，你能够按照血统瓜葛往下游排查，看看究竟在哪一个环节出了问题。另外咱们也能够经过数据的血统瓜葛，建设起出产这些数据的工作之间的依赖瓜葛，进而辅佐调度零碎的任务调度，或者用来判别一个失败或过错的工作可能对哪些上游数据形成影响等等。
剖析数据的血统瓜葛看起来简略，但真的要做起来，其实不容易，由于数据的来源多种多样，加工数据的伎俩，所使用的计算框架可能也各不相反，另外也不是一切的零碎天生都具备获得相干信息的才能。而针对不同的零碎，血统瓜葛详细可以剖析到的粒度可能也纷歧样，有些能做到表级别，有些乃至能够做到字段级别。
以hive表为例，经过剖析hive脚本的履行方案，是能够做到相对于准确的定位出字段级别的数据血统瓜葛的。而假如是一个MapReduce工作生成的数据，从内部来看，可能就只能经过剖析MR工作输入的Log日志信息来粗略判别目录级别的读写瓜葛，从而直接推导数据的血统依赖瓜葛了。
数据的业务属性信息
后面三类信息，一定水平上均可以经过技术伎俩从底层零碎本身所具有的信息中获得失掉，又或着能够经过一定的流程二次加工剖析失掉。与之相同，数据的业务属性信息，通常与底层零碎本身的运转逻辑有关，多半就需求经过其余伎俩从内部获得了。
那末，业务属性信息都有哪些呢？最多见的，好比，一张数据表的统计口径信息，这张表干甚么用的，各个字段的详细统计形式，业务形容，业务标签，脚本逻辑的历史变迁记载，变迁缘故等等，另外，你也可能会关怀对应的数据表格是由谁担任开发的，详细数据的业务部门归属等等。
上述信息假如整个需求依托数据开发者的盲目填写，不是不行，然而显然不太靠谱。毕竟关于少数同窗来讲，关于实现数据开发任务中心链路之外的任务量，很天然的反映就是能不做就不做，越省事越好。假如没有流程体系的标准，假如没有发生实际的价值，那末相干信息的填写很容易就会成为一个担负或者是流于方式。
所以，只管这部份信息往往需求经过内部伎俩人工录入，然而仍是需求尽可能斟酌和流程进行整合，让它们成为业务开发必不成少的环节。好比，一部份信息的收集，能够经过总体数据平台的开发流程标准，嵌入到对应数据的开发过程当中进行，例如历史变迁记载能够在修正工作脚本或者表格schema时强迫要求填写；业务担任人信息，能够经过以后开发人员的业务线和开发群组归属瓜葛自动进行映照填充；字段统计形式信息，尽量经过规范的维度目标办理体系进行标准定义。
整体来讲，数据的业务属性信息，必定首先是为业务办事的，因此它的收集和展现也就需求尽量的和业务环境相融会，只要这样能力真正发扬这部份元数据信息的作用。
元数据办理相干零碎计划引见Apache Atlas
社区中开源的元数据办理零碎计划，常见的好比Hortonworks主推的Apache Atlas，它的根本架构思想如下图所示


Atlas的架构计划应该说至关典型，根本上这种零碎大抵都会由元数据的采集，存储和查问展现三部份中心组件组成。另外，还会有一个办理后盾对总体元数据的收集流程以及元数据格局定义和办事的部署等各项内容进行配置办理。
对应到Atlas的完成上，Atlas经过各种hook/bridge插件来收集几种数据源的元数据信息，经过一套自定义的Type 体系来定义元数据信息的格局，经过搜寻引擎对元数据进行全文索引和前提检索，除了自带的UI管制台不测，Atlas还能够经过Rest API的方式对外提供办事。
Atlas的总体设计着重于数据血统瓜葛的收集以及表格维度的根本信息和业务属性信息的办理。为了这个目的，Atlas设计了一套通用的Type体系来形容这些信息。次要的Type根底类型包罗DataSet和Process，前者用来形容各种数据源自身，后者用来形容一个数据处置的流程，好比一个ETL工作。
Atlas现有的Bridge完成，从数据源的角度来看，次要掩盖了Hive，HBase，HDFS和Kafka，另外还有适配于Sqoop, Storm和Falcon的Bridge，不外这三者更多的是从Process的角度动手，最初落地的数据源仍是上述四种数据源。
详细Bridge的完成多半是经过上述底层存储，计算引擎各自流程中的Hook机制来完成的，好比Hive SQL的Post Execute Hook，HBase的Coprocessor等，而收集到的数据则经过Kafka动静队列传输给Atlas Server或者其它定阅者进行消费。
在业务信息办理方面，Atlas经过用户自定义Type 属性信息的形式，让用户能够完成数据的业务信息填写或者对数据打标签等操作，便于后续对数据进行定向过滤检索。
最初，Atlas能够和Ranger配套使用，允许Ranger经过Atlas顶用户自定义的数据标签的方式来对数据进行为态受权办理任务，相对于于基于门路或者表名/文件名的方式进行动态受权的形式，这类基于标签的形式，有时分能够更为灵敏的处置一些特定场景下的权限办理任务。
整体而言，Atlas的完成，从构造原理的角度来讲，还算是对比公道的，但从现阶段来看，Atlas的详细完成还对比粗拙，得多功用也是处于可用但其实不完美的形态。另外Atlas在数据审计环节做的任务也未几，与总体数据业务流程的集成运用方面的才能也颇有限。Atlas名目自身很长期也都处于Incubator形态，因此还需求大家一同多致力来帮忙它的改进。
Cloudera Navigator Data Management
此外一个对比常见的解决计划是Cloudera CDH发行版中主推的Navigator，比拟Atlas而言，Navigator的总体完成更为成熟一些，更像一个残缺的解决计划，不外，Navigator并非开源的，也难怪，毕竟要卖钱的的货色，也就更有能源去完美 ；）
Navigator的产品定位是Data Management数据办理，实质上也是经过办理元数据来办理数据，但周边工具和配套设施相对于完美，和Cloudera Manager办理后盾的产品集成任务也做得对比完全。比拟Atlas来讲，Navigator的总体组件架构也更为繁杂一些。Navigator的大抵组件架构如下图所示


Navigator定位为数据办理，所以对数据的审计办理方面的任务也会做得更多一些，除了收集和办理Hive/Impala等表格的血统信息，Navigator也能够配置收集包罗HDFS的读写操作记载，Yarn/Spark/Pig等功课的运转统计数据在内的信息。Navigator同时还为用户提供了各种统计剖析视图和查问办理工具来剖析这些数据。
从底层完成来看，Navigator一样经过Hook或着Plugin插件的方式从各种底层零碎的运转过程当中获得相干信息。但与Atlas不同的是，Navigator的元数据收集传输处置流程并无把这些信息写入到动静队列中，而是次要经过这些插件写入到相干办事所在的当地Log文件中，而后由Cloudera Manager在每台办事节点上部署的Agent来读取，过滤，剖析处置并传输这些信息给Audit Server。
另外Navigator还经过独立的Metadata Server来采集和剖析一些非Log来源的元数据信息，并一致对外提供元数据的配置办理办事。用户还能够经过配置Policy战略，让Metadata Server自动基于用户定义的规定，替用户实现数据的Tag标签打标任务，进而晋升数据自动化自治办理的才能。
整体而言，Navigator和Cloudera Manger的产品集成任务做得相对于完美，假如你使用CDH发行版全家福套件来办理你的集群的话，使用Navigator应该是一个不错的选择。不外，假如是自主办理的集群或者自建的大数据开发平台，深度集成定制的Navigator就很难为你所用了，但无论如何，关于自主开发的元数据办理零碎来讲，Navigator的总体设计思想也仍是值得鉴戒的。
蘑菇街元数据办理零碎理论
蘑菇街大数据平台的元数据办理零碎，大体的体系架构思想和上述零碎也对比相似，不外，主观的说咱们的零碎的开发是一个伴有着总体开发平台的需要演进而渐进拓展的进程，所以从数据办理的角度来讲，没有上述两个零碎那末关注数据格局类型零碎的广泛合用性。好比Schema这部份信息的办理，就次要着重于表格类信息的办理，好比Hive，HBase等，而非彻底通用的类型零碎。但相对于的，在对外办事方面，咱们也会更为重视元数据办理零碎和业务零碎运用需要的关联，架构迥然不同，上面次要简略引见一下产品交互状态和一些特殊的功用殊效设定等。
如图所示，是咱们的元数据办理零碎的产品后盾针对Hive表格元数据信息的部份查问界面，次要为用户提供表格的各种根底schema信息，业务标签信息，血统瓜葛信息，样本数据，以及底层存储容量星系，权限和读写修正记载等审计信息。


除了表格元数据信息办理之外，咱们的元数据办理零碎次要的功用之一是“业务组”的办理，业务组的设计指标是贯通全部大数据开发平台的，做为大数据开发平台上开发人员的自主办理单元组织方式。将一切的数据和工作的办理任务都下放到业务组外部由业务组办理员办理。
从元数据办理零碎的角度来讲，业务组的办理，包罗数据和工作与业务组的归属瓜葛映照，业务组内角色的权限映照瓜葛等，另外，为了顺应业务的疾速变动，也给用户提供的数据资产的归属瓜葛转移等功用。
整体来讲，业务组的办理功用，更多的是需求和大数据开发平台的其它组件相结合，好比和集成开发平台IDE相结合，在开发平台中提供基于业务组的多租户开发环境办理功用，再好比与调度零碎相结合，按照工作和数据的业务组归属信息，在工作调度时实行计算资源的配额办理等。
最初，对于数据的血统瓜葛跟踪，再多说两句。在Atlas和navigator中，次要经过计算框架本身反对的运转时hook来获取数据有关元数据和血统相干信息，好比hive的hook是在语法解析阶段，storm的hook是在topology submit阶段。
这么做的优点是血统的追踪剖析是基于实在运转工作的信息进行剖析的，假如插件部署片面，也不太会有脱漏问题，然而这类形式也有得多不太好解决的问题，好比
如何更新一个历史上有依赖起初再也不依赖的血统瓜葛关于一个还未运转的工作，不克不及提前获得血统信息暂时脚本或者过错的脚本逻辑对血统瓜葛数据的净化
简略总结一下，就是基于运转时的信息来收集血统瓜葛，因为不足动态的业务信息辅佐，如何甄别和更新血统瓜葛的生命周期和无效性会是一个辣手的问题，一定水平上也限度了运用的规模。
咱们的做法是，血统信息的收集不是在运转时动进行的，而是在脚本保留时进行的。因为开发平台一致办理了一切用户的工作脚本，所以，咱们能够对脚本进行动态的剖析，加之脚本自身业务信息，履行状况和生命周期对开发平台是可知的。所以一定水平上能解决上述提到的几个问题。
固然，这类计划也有本人的短板需求战胜，好比：假如脚本管控不到位，血统瓜葛剖析可能掩盖不全；血统瓜葛是基于最新的脚本的动态的逻辑瓜葛，无奈做到基于某一次真正的运转实例进行剖析。不外，这些短板对咱们来讲从需要的角度来讲都不是很中心的问题，又或者经过周边零碎的配套建立能够在一定水平上加以解决战胜的。