Atlas元数据存储模型分析

导语:Atlas 是一个可扩展的核心基础治理服务集 - 使企业能够有效地和高效地满足 Hadoop 中的合规性要求,并允许与整个企业数据生态系统的集成。该项目用于管理共享元数据、数据分级、审计、安全性以及数据保护等各个方面,是数据治理的重要组成部分。本文介绍Atlas的存储子系统,分析Atlas的存储模型和各个元数据要素的存储结构。

Atlas简介

Atlas 是一个可扩展和可扩展的核心基础治理服务集 - 使企业能够有效地和高效地满足 Hadoop 中的合规性要求,并允许与整个企业数据生态系统的集成。从具体功能点看,atlas可以完成元数据系统的以下管理需求:

  • 数据分类:委员数据导入或定制分类和标签,可以自动捕获被分类元数据之间的传播关系。

  • 集中审计:记录应用与数据交互的安全访问信息以及具体的执行步骤等操作痕迹。

  • 搜索与血缘:支持按全文、按分类标签、类sql等各种方式的查询。 对数据集血缘关系的可视化浏览使用户可以下钻到操作,安全以及数据起源相关的信息

  • 安全策略:支持基于角色的运行时合规策略;支持数据信息脱敏如属性级别的masking


其整体架构图如下图所示:


整体来看,atlas由Core、integration、metadata source和Apps几大部分组成。


core包含类型系统、元数据导入导出、图引擎三大模块。类型系统定义了元数据对象的模型,也是下文要继续介绍的重点。导入导出模块支持元数据快速导入到atlas,以及将atlas检测到的元数据更改以事件方式通知到下游服务。图引擎是atlas的存储和计算推导基础,目前采用janusgraph实现。


integration是atlas的IO子系统,支持以REST API和消息系统两种方式将元数据导入Atlas。其中消息系统方式支持kafka作为中间件,可以让atlas和其他数据源服务解耦,具有更好的扩展性。


metadata source模块是atlas的数据源插件,目前支持从常见的大数据服务中捕获元数据以及其变更信息,并及时通知到消息中间件。新的大数据服务要接入atlas,可以在此扩展数据源即可。


Apps是构建在core之上的元数据应用,包括基于web的应用、基于标签的策略和业务分类系统。


Atlas存储

下面从三个方面介绍Atlas存储:类型系统、图存储模型以及类型是实体的存储结构。


类型系统

Atlas 允许用户为他们想要管理的元数据对象定义一个模型。该模型由称为 "类型" 的定义组成。被称为 "实体" 的 "类型" 实例表示被管理的实际元数据对象。类型系统是一个组件,允许用户定义和管理类型和实体。由 Atlas 管理的所有元数据对象(例如Hive表)都使用类型进行建模,并表示为实体。要在Atlas中存储新类型的元数据,需要了解类型系统组件的概念。


Atlas中的 "类型" 定义了如何存储和访问特定类型的元数据对象。类型表示了所定义元数据对象的一个或多个属性集合。具有开发背景的用户可以将 "类型" 理解成面向对象的编程语言的 "类" 定义的或关系数据库的 "表模式"。


Atlas中的类型分为两类:原生类型和结构化类型;原生类型用来描述基础属性的类型,结构化类型用来构造Atlas中元数据相关模型。


原生类型包括:Int,String,Boolean,Date,枚举等等,无需过多解释。


结构化类型包括:集合类型:例如Array,Map;复合类型:Class,Struct,Trait。符合类型是构成Atlas元数据类型的基础,元数据类型正是以复合类型为superType,继承其结构和属性,对业务系统的元数据进行建模。


在复合类型基础上构建起来的Atlas元数据类型,刻画了业务系统元数据的各个方面。元数据从功能上分,有数据元数据和计算元数据,数据元数据继承一般继承子DataSet预定义类型,计算元数据类型一般继承自Process元数据,Atlas的血缘关系正是对Process的输入输出链(数据元数据)进行分析的结果。值得一提的是,就存储本身而言,数据元数据和计算原数据并无差别。


下图给出了当前元数据项目里的部分元数据类型继承关系:

图中不难看出,一个元数据类型包含一个属性集合,这些属性可以是原生类型如string等,也可以是其他的复合类型如struct或其他元数据类型,如tencent_appgroup类型的product字段是另外一种元数据类型tencent_product。


类型系统构成了元数据模型的基石,具体的一条元数据必须复合类型的schema约束,正如关系数据表中的一行数据必须遵守表schema约束一样。


Atlas图存储结构

Atlas中所有数据均采用图存储,包括上文介绍的类型信息schema和具体的元数据实体,目前是janusgraph实现。可以预见,atlas的所有数据最终都会转换成图存储中的顶点vertex、边edge和属性property三种元素。在腾讯内部的元数据系统中,janusgraph以hbase作为落地存储服务。


众所周知,hbase采用列存储模型,其结构如下:


对janusgraph来说,需要将存储的三要素:顶点vertex、边edge和属性property转化为上面的模型。转化方式有两种:顶点切分和边切分。点切分即每个顶点转化为hbase的一行数据,顶点属性和关联此顶点的所有边均作为hbase的column存储在一行中。janusgraph正是采用了点分存储方式。点分示意图如下:

janusgraph存储模型转化后的结果如下图所示:


介绍到这里,我们知道Atlas元数据的schema、底层图存储的物理结构。下面介绍打通存储链路的最后一环,Atlas元数据类型到Janusgraph存储的映射


Atlas元数据存储模型

Atlas在图中存储的数据分两大类:类型定义的存储和元数据的存储。类型定义信息是元数据的元数据,比如tencent_bg类型,描述了腾讯BG拥有的属性名称和类型清单。


类型定义模型

下面描述enum类型定义、struct类型定义、classification类型定义、entity类型定义以及relationship定义对应的janusgraph图顶点信息。


  • enum类型定义(enumDef)

vertex属性__type="typeSystem"__type.category=TypeCategory.ENUM__type.name=具体的类型定义名称如file_action__type.description__type.servicetype=服务类型如file_system__type.version__guid__createdBy=创建者的用户名__timestamp__modifiedBy=更新者的用户名__modificationTimestamp=修改时间__version__type.options#会为每个enum element生成下面两行属性__type.${typeName}.${enumValueName}=${ordinal} #如__type.file_action.READ_WTITE=6__type.__type.${typeName}.${enumValueName}.description=某个具体enumvalue的描述信息__type.${typeName}=所有的enum element值 #如__type.file_action={"NONE","EXECUTE","WRITE","WRITE_EXECUTE","READ","READ_EXECUTE","READ_WRITE","ALL"}__type.${typeName}.defaultValue=enum的默认值 #__type.file_action.defaultValue

(左滑查看完整代码,下同)


  • struct类型定义(structDef)
#vertex属性__type="typeSystem"__type.category=TypeCategory.STRUCT__type.name=具体的类型定义名称如file_action__type.description__type.servicetype=服务类型如file_system__type.version__guid__createdBy=创建者的用户名__timestamp__modifiedBy=更新者的用户名__modificationTimestamp=修改时间__version__type.options#会为每一个attribute生成下一行属性__type.${typeName}.${attrName}=json(AtlasAttribute)__type.${typeName}=List<属性名称>#对于每个非builtin类型的attribute,建立一条边,edgeLabel为:__type.edge.${typeDefName}.${attriDefName}


  • classification类型定义(classificationDef)
vertex属性__type="typeSystem"__type.category=TypeCategory.CLASSIFICATION__type.name=具体的类型定义名称如file_action__type.description__type.servicetype=服务类型如file_system__type.version__guid__createdBy=创建者的用户名__timestamp__modifiedBy=更新者的用户名__modificationTimestamp=修改时间__version__type.options#会为每一个attribute生成下一行属性__type.${typeName}.${attrName}=json(AtlasAttribute)__type.${typeName}=List<属性名称>vertex边#对于每个非builtin类型的attribute,建立一条边,edgeLabel为:__type.edge.${typeDefName}.${attriDefName}__type.supertype      #为每个superType建立一条边__type.entitytype     #为限定可以打标签的entityTypeDef建立一条边


  • entity类型定义(entityDef)
vertex属性__type="typeSystem"__type.category=TypeCategory.ENTITY__type.name=具体的类型定义名称如file_action__type.description__type.servicetype=服务类型如file_system__type.version__guid__createdBy=创建者的用户名__timestamp__modifiedBy=更新者的用户名__modificationTimestamp=修改时间__version__type.options#会为每一个attribute生成下一行属性__type.${typeName}.${attrName}=json(AtlasAttribute)__type.${typeName}=List<属性名称>vertex边#对于每个非builtin类型的attribute,建立一条边,edgeLabel为:__type.edge.${typeDefName}.${attriDefName}__type.supertype      #为每个superType建立一条边


  • relationship定义(relationshipDef)
vertex属性__type="typeSystem"__type.category=TypeCategory.RELATIONSHIP__type.name=具体的类型定义名称如file_action__type.description__type.servicetype=服务类型如file_system__type.version__guid__createdBy=创建者的用户名__timestamp__modifiedBy=更新者的用户名__modificationTimestamp=修改时间__version__type.options#会为每一个attribute生成下一行属性__type.${typeName}.${attrName}=json(AtlasAttribute)__type.${typeName}=List<属性名称>endDef1=json(AtlasRelationshipEndDef)endDef2=json(AtlasRelationshipEndDef)relationshipCategory=RelationshipCategoryrelationshipLabeltagPropagation#边edgeLabel<为每一个endDef对应的顶点建立一条边,若两个endDef是同一个类型,则只建立一条边>__type..relationshipType


元数据实体图模型

元数据实体是指一种具体元数据类型的实例,比如一张具体的tdw hive表信息,或者一个具体BG信息。原始的信息以Json格式存在,后被转化为图存储模型。一个tencent_bg的json化数据如下:
{      "referredEntities": {},      "entities": [{        "typeName": "tencent_bg",        "attributes": {          "owner": "ls",          "qualifiedName": "CSIG@tencent",          "name": "CSIG",          "description": "csig bussiness group"        },        "guid": "-1234567890",        "proxy": false,        "version": 0      }]}


虽然具体的实体如thive表或tencent_bg携带不同的属性或引用关系信息,但是在底层图中存储却有相同的模型。转化为图中的vertex后具有以下存储模型:
vertex属性#每一个primitive类型的属性都对应下面的一个vertext property${entityType}.${attrName}每一个struct类型的Attribute对应一条边:连接entity vertex和该struct对应的vertex,edgeLabel为:__${entityType}.${attrName}每个objectId类型的Attribute,需要创建或更新对应的另一端顶点,然后更新两个顶点的边属性等信息对于每个Map类型的Attribute,若Map的valueType是primitive|enum|array|map类型,则直接生成一个vertexProperty;若Map的valueType是reference类型,则为每个value生成一条边,边的另一端对应这个mapvalue对应的顶点,边的属性__key=map的key对于每个array类型的Attritbue,若array的elementType为primitive|enum|array|map类型,则为entity的vertext生成一个property,${entityType}.${attrName}=array;若array的elementType为reference类型,则为每个element生成或更新对应的vertex,并生成一条边,边有个property:__index=element在array中的index对于classification的处理:1)把该classification的typeName加到vertex属性__traitNames中2)创建classification的vertex,属性包括:    __typeName    __state    __timestamp    __modificationTimestamp    __createdBy    __modifiedBy    __superTypeNames    __entityGuid    __entityStatus    __validityPeriods    __propagate    __removePropagations    为父类structType里的每个Attribute添加一个vertext property3)为entity和classification建立一条边,edgeLabel为classifiedAs,属性:    __state=active    __timestamp    __modificationTimestamp    __createdBy    __modifiedBy    __name=classfication的typeName    __isPropagated4)查找该entity的所有具有传播关系的relation 对端vertex(比如table到包含的各种列),然后为每个传播vertex建立到classification vertex的边,并为该传播vertex添加属性值__propagatedTraitNames5)重新生成entity以及传播entity的fulltext字段entityText(包括entity所有属性和classification的属性),并通知EntityChangeListenerV2处理


Atlas类型解析

Atlas中的类型是是可扩展的,开发人员通过简单的Json格式的类型定义描述,就可以实现新的类型。正是具有扩展性,Atlas需要对所有的类型信息进行解析校验,只有通过解析校验的类型,才是符合Atlas元数据管理规范的,这也是上面所有存储模型能成功落地到图数据库的前件。


解析校验最重要的逻辑是检查类型所有原生类型属性是否符合schema要求、所有引用类型的属性是否在现有图中已定义。其实整个resolve过程简单来看,围绕2方面进行:


  • 属性,包括继承父类属性,解析属性的constraint,以及添加relationship中定义的属性到entityType中;当然会处理relation中边的label和direction等关系

  • 类型继承,填充各种superType和subType


具体来说整个解析校验过程分3个阶段,下面分别介绍之。


  • 解析phase1
AtlasStructType    校验所有attribute:        cardinity为LIST或SET时,attribute类型必须为Array、        attribute类型不能为AtlasClassificationType、        attribute constraint:ownedRef指向的AtlasEntityType必须存在;inverseRef正反向对应的entity必须存在,即指向的AtlasEntityType必须存在,而且指向的AtlasEntityType必须有对应的属性指向自己        收集allAttributes和uniqAttributes(即attributeDef中字段isUnique=true的属性)AtlasEntityType    做父类AtlasStructType的resolveReferences   收集allSuperTypes,superTypes,headerAttributes(包括ENTITY_HEADER_ATTRIBUTES和ENTITY_HEADER_ATTRIBUTES_TDW),minInfoAttributes(包括所有的headerAttributes和schema-attributes)  AtlasClassificationType    做父类AtlasStructType的resolveReferences    校验superType必须为AtlasClassificationType    收集superTypes、allSuperTypes、allAttributes、uniqAttributes    AtlasRelationshipType    做父类AtlasStructType的resolveReferences    校验endDef12必须均为AtlasEntityType    endDef1、endDef2不能指定cardinity=LIST,不能同时为container、有一个end为containetr时,关系类型不能为RelationshipCategory.ASSOCIATION,    类型为COMPOSITION和AGGREGATION时,必须有一个end是container


  • 解析phase2
AtlasStructType    对constraint为inverseRef的Attribute,设置Attribute的字段inverseRefAttribute=指向的entity的AttributeAtlasEntityType     做父类AtlasStructType的resolveReferencesPhase2     为所有父类填充subTypes、allSubTypes、typeAndAllSubTypes,即把当前正在解析的entityType加入到所有父类的subTypes集合中AtlasClassificationType        做父类AtlasStructType的resolveReferencesPhase2    为所有父类填充subTypes、allSubTypes、typeAndAllSubTypes,即把当前正在解析的entityType加入到所有父类的subTypes集合中AtlasRelationshipType        做父类AtlasStructType的resolveReferencesPhase2    确定relationship的edgeLabel:        1)endDef1和endDef2的isLegacyAttribute字段均为false,则edgeLabel=r:${relationName}        2)endDef1 isLegacyAttribute字段为true,则edgeLabel=__${endDef1TypeName}.${endDef1Name}        2)endDef2 isLegacyAttribute字段为true,则edgeLabel=__${endDef2TypeName}.${endDef2Name}    补充endDef1、endDef2两端对应Attribute(可能需要创建)的字段relationshipLabel,并把Attribute添加到end对应entity的relationshipAttributes,补充attrName-->relationType的映射    确定relationship的edge direction:            1)endDef1==endDef2,即对应的entityType和name均相等,则设置两端entity的Attribute的relationshipEdgeDirection=BOTH            2)endDef1和endDef2的isLegacyAttribute字段均为true,则两端entity的Attribute的relationshipEdgeDirection=OUT            3)若只有一个endDef的isLegacyAttribute=true则该端relationshipEdgeDirection=OUT,对端relationshipEdgeDirection=IN            4)两端isLegacyAttribute=false,则endDef1的relationshipEdgeDirection=OUT,endDef2的relationshipEdgeDirection=IN


  • 解析phase3

AtlasEntityType    对于Attribute类型为另一种EntityType,但是没有定义相应的relationship,则打印警告信息    把所有superType的relationshipAttributes添加到当前entityType的relationshipAttributes中    AtlasClassificationType        把所有的superType允许的entityTypes取交集,得到superTypeEntityTypes;获取当前classificationType允许的entityTypes,记为classificationDefEntityTypes    1)若没有superType,则entityTypes=classificationDefEntityTypes    2)若superTypeEntityTypes isEmpty,则抛异常    3)若classificationDefEntityTypes isEmpty,则entityTypes=superTypeEntityTypes   4)若superTypeEntityTypes不包含classificationDefEntityTypes,则抛异常   5) entityTypes中所有entityType的subType同样会被加入entityTypes中


结语

本文介绍了Atlas元数据系统的存储模型,分别从Atlas架构,类型系统,图存储结构,类型定义和实体的图模型以及类型解析等方面展开。希望通过这篇文章,使大家对Atlas元数据存储模型会有更深的了解。

腾讯技术工程
腾讯技术工程

腾讯技术工程事业群在机器之心的内容专栏

工程腾讯关系数据库数据科学
1
相关数据
数据管理技术

数据管理是利用计算机硬件和软件技术对数据进行有效的收集、存储、处理和应用的过程,其目的在于充分有效地发挥数据的作用。

数据库技术

数据库,简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据运行新增、截取、更新、删除等操作。 所谓“数据库”系以一定方式储存在一起、能予多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

映射技术

映射指的是具有某种特殊结构的函数,或泛指类函数思想的范畴论中的态射。 逻辑和图论中也有一些不太常规的用法。其数学定义为:两个非空集合A与B间存在着对应关系f,而且对于A中的每一个元素x,B中总有有唯一的一个元素y与它对应,就这种对应为从A到B的映射,记作f:A→B。其中,y称为元素x在映射f下的象,记作:y=f(x)。x称为y关于映射f的原象*。*集合A中所有元素的象的集合称为映射f的值域,记作f(A)。同样的,在机器学习中,映射就是输入与输出之间的对应关系。

逻辑技术

人工智能领域用逻辑来理解智能推理问题;它可以提供用于分析编程语言的技术,也可用作分析、表征知识或编程的工具。目前人们常用的逻辑分支有命题逻辑(Propositional Logic )以及一阶逻辑(FOL)等谓词逻辑。

关系数据库技术

关系数据库,是创建在关系模型基础上的数据库,借助于集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各种实体以及实体之间的各种联系均用关系模型来表示。关系模型是由埃德加·科德于1970年首先提出的,并配合“科德十二定律”。现如今虽然对此模型有一些批评意见,但它还是数据存储的传统标准。

查询技术

一般来说,查询是询问的一种形式。它在不同的学科里涵义有所不同。在信息检索领域,查询指的是数据库和信息系统对信息检索的精确要求

腾讯机构

腾讯科技股份有限公司(港交所:700)是中国规模最大的互联网公司,1998年11月由马化腾、张志东、陈一丹、许晨晔、曾李青5位创始人共同创立,总部位于深圳南山区腾讯大厦。腾讯由即时通讯软件起家,业务拓展至社交、娱乐、金融、资讯、工具和平台等不同领域。目前,腾讯拥有中国国内使用人数最多的社交软件腾讯QQ和微信,以及中国国内最大的网络游戏社区腾讯游戏。在电子书领域 ,旗下有阅文集团,运营有QQ读书和微信读书。

http://www.tencent.com/
非常强大的atlas介绍,请问有没有Demo程序分享下