UDA(统一数据架构)是一个基于知识图的基础,用于管理和连接不同系统中的域模型,以解决重复/不一致的模型,不一致的术语,数据质量问题和有限的连接等挑战。
UDA允许团队注册域模型,将这些模型编目并映射到数据容器(如GraphQL服务,Data Mesh源,Iceberg表),将它们转换为各种模式语言(GraphQL,Avro,SQL),自动化数据移动,并启用发现和编程内省。
随着Netflix的产品不断增长--涵盖电影、剧集、游戏、现场活动和广告--支持它的系统也越来越复杂。“演员”或“电影”等核心业务概念在许多地方都有模型:在我们的企业GraphQL网关中为内部应用程序提供支持,在我们的资产管理平台中存储媒体资产,在我们的媒体计算平台中为编码管道提供支持,等等。每个系统对这些概念的建模方式都不同,而且是孤立的,几乎没有协调或共同的理解。虽然这些系统经常在相同的概念上运作,但它们在很大程度上仍然没有意识到这一事实,也没有意识到彼此。
因此,出现了若干挑战:
- 重复和不一致的模型-团队在不同的系统中重新建模相同的业务实体,导致难以协调的冲突定义。
- 术语不一致-即使在一个系统中,团队也可能对同一个概念使用不同的术语,或者对不同的概念使用相同的术语,这使得协作更加困难。
- 数据质量问题-在我们的许多微服务中,难以检测到不一致和损坏的引用。虽然存在标识符和外键,但它们的建模不一致,文档记录也很差,需要领域专家手动工作来查找和修复任何数据问题。
- 有限的连接性-在系统内,数据之间的关系受到每个系统支持的内容的约束。在整个系统中,它们实际上不存在。
这些是引导我们建立UDA的核心思想。
介绍UDA
UDA(统一数据架构)是内容工程中连接数据的基础。它使团队能够对域进行一次建模,并在整个系统中一致地表示它们-支持自动化,可扩展性和语义互操作性。
使用UDA,用户和系统可以:
1、注册和连接域模型:以数据形式表示的联合业务域的正式概念化。
每个人都使用相同的业务概念的官方定义,这避免了混乱,并阻止不同的团队以冲突的方式重建类似的模型。
2、将域模型编目并映射到数据容器,例如域图服务提供的GraphQL类型解析器、数据网格源或冰山表,通过它们的图表示。
为了便于查找这些业务概念的实际数据所在的位置(例如,其中包含特定数据库、表或服务),并了解其结构。
3、将领域模型转换为模式定义语言,如GraphQL,Avro,SQL,RDF和Java,同时保留语义。
直接从域模型自动为各种系统创建一致的技术数据结构(模式),从而节省开发人员的手动工作并减少由不同步定义引起的错误。
4、在数据容器之间忠实地移动数据,例如从联合GraphQL实体到Data Mesh(用于在Netflix系统之间大规模移动数据的通用数据移动和处理平台),更改数据捕获(CDC)源到可连接的Iceberg Data Products。
通过自动处理数据如何在不同系统之间移动和正确转换来节省开发人员的时间。这意味着减少了配置数据移动的手动工作,确保数据在需要的地方一致准确地显示。
5、通过搜索和图遍历发现和探索领域概念。
任何人都可以更轻松地找到他们正在寻找的特定业务信息,了解不同概念和数据之间的关系,并确信他们正在访问正确的信息。
6、使用Java、GraphQL或SPARQL以编程方式内省知识图。
开发人员可以构建更智能的应用程序,这些应用程序可以利用这些连接的业务信息,自动化更复杂的数据依赖工作流,并帮助从数据中的关系中发现新的见解。
这篇文章介绍了UDA作为知识图的基础,通过映射将领域模型连接到数据容器,并以内部元模型或模型的模型为基础,称为Upper。Upper定义了UDA中的领域建模语言,并支持自动生成跨系统模式和管道的投影。
这篇文章还强调了在生产中利用UDA的两个系统:
主数据管理(PDM)是我们管理权威参考数据和分类的平台。PDM将域模型转换为平面或层次分类法,从而为业务用户驱动生成的UI。这些分类模型被投射到Avro和GraphQL模式中,自动在企业网关中的仓库和GraphQL API中提供数据产品。
Sphere是我们面向企业用户的自助式运营报告工具。Sphere使用UDA对跨系统的业务概念进行编目和关联,通过熟悉的术语(如“演员”或“电影”)实现发现。一旦选择了概念,Sphere就会遍历知识图并生成SQL查询来从仓库中检索数据,无需手动连接或技术中介。
UDA是一个知识图谱
UDA需要解决数据集成问题。我们需要一个与模式注册表统一的数据目录,但对语义集成有严格的要求。将业务概念与模式和数据容器以类似于图的结构连接起来,以强大的语义基础为基础,自然会让我们考虑知识图方法。
我们选择RDF和SHACL作为UDA知识图的基础。但是,在企业规模上实施它们面临着一些挑战:
- RDF缺乏可用的信息模型。尽管RDF提供了一个灵活的图结构,但它对如何将数据组织到命名图中、管理本体所有权或定义治理边界几乎没有提供指导。像owl:imports这样的标准follow-your-nose机制只适用于本体,不扩展到命名图;我们需要一个通用的机制来表达和解决它们之间的依赖关系。
- SHACL不是企业数据的建模语言。SHACL旨在验证本机RDF,它假设全局唯一的URI和单个数据图。但是企业数据是围绕本地模式和类型化键构建的,就像GraphQL、Avro或SQL一样。SHACL无法表达这些模式,因此很难跨异构系统对真实世界的数据进行建模和验证。
- 团队缺乏共享的创作实践。没有强有力的指导方针,团队对本体的建模不一致,破坏了语义互操作性。即使是风格、结构或命名上的细微差异也会导致不同的解释,并使转译更难在模式中一致地定义。
- 本体工具缺乏对协作建模的支持。与GraphQL联邦不同,本体框架没有内置的模块化贡献,团队所有权或安全联邦支持。大多数工程师发现工具和概念不熟悉,并且可用的创作环境缺乏协调贡献所需的结构。
为了应对这些挑战,UDA采用了命名图优先的信息模型。每个命名图都符合一个管理模型,该模型本身就是知识图中的一个命名图。这种系统化的方法确保了解决方案、模块化,并实现了对整个图的治理。虽然UDA的信息基础设施的完整描述超出了本文的范围,但接下来的部分将解释UDA如何使用其元模型引导知识图,并使用它来建模数据容器表示和映射。
之前的是搞领域建模
Upper是一种用于形式化描述域(业务或系统)及其概念的语言。这些概念被组织到域模型中:定义键控实体类的受控词汇表,它们的属性,以及它们与其他实体的关系,这些实体可以是键控的或嵌套的,在同一域内或跨域。域模型中的关键概念可以按照类型分类法进行组织,这些类型可以根据业务或数据系统的需要而复杂。
关键概念也可以从其他领域模型中扩展出来--也就是说,新的属性和关系可以被单调地贡献出来。最后,Upper为属性值提供了一组丰富的数据库,这些数据库也可以根据域进行自定义。
上层域模型是数据。它们被表示为概念RDF,并被组织成命名图,使它们在UDA知识图中可内省、可查询和可版本化。这个图不仅统一了域模型本身,还统一了它们转换到的模式- GraphQL,Avro,Iceberg,Java -以及将域概念连接到具体数据容器的映射,例如域图服务提供的GraphQL类型解析器,数据网格源或Iceberg表,通过它们的表示。
Upper提高了传统本体语言之上的抽象层次:它定义了一个严格的语义技术子集,这些语义技术来自于为领域建模而定制和推广的W3C。
它建立在RDFS、OWL和SHACL等本体框架之上,因此领域作者可以有效地建模,甚至不需要学习本体是什么。
Upper是UDA中Connected Data的元模型-所有模型的模型。它被设计为一个自举的上层本体,这意味着Upper是自引用的,因为它将自己建模为领域模型;自描述的,因为它定义了领域模型的概念;自验证的,因为它符合自己的模型。
这种方法使UDA能够引导自己的基础设施:Upper本身被投射到一个生成的基于Jena的Java API和GraphQL模式中,用于GraphQL服务,并被联合到Netflix的Enterprise GraphQL网关中。这些相同的生成的API然后由投影和UI使用。
由于所有域模型都是Upper的保守扩展,因此其他系统域模型(包括GraphQL、Avro、Data Mesh和Mappings)可以无缝集成到同一个运行时中,从而实现跨模式的一致数据语义和互操作性。
受控词汇表(PDM)
Netflix的所有业务活动都依赖于一个庞大的数据模型,该模型捕捉了我们许多业务流程的细节。团队需要能够协调运营活动,以确保内容制作完成,广告活动到位,促销资产准备部署。我们隐含地依赖于共享概念的单一定义,例如内容生产是完整的。多种定义造成了协调方面的挑战。软件(和人类)不知道这些定义的意思是一样的。
我们启动了主数据管理(PDM)计划,为数据模型中的核心概念创建统一一致的定义。这些定义形成了受控的词汇表、标准化的和受治理的列表,以确定在我们的数据模型中的某些字段中允许哪些值。
主数据管理(PDM)是业务用户可以管理受控词汇表的单一位置。我们的数据模型治理分散在不同的工具和团队中,带来了协调挑战。这是一个与参考数据和分类法的定义、维护和一致使用有关的信息管理问题。这个问题并不是Netflix独有的,所以我们向外寻找解决这个问题的现有解决方案。
PDM使用简单知识组织系统(SKOS)模型。它是为建模知识而设计的W3C数据标准。它的术语是抽象的,概念可以组织成概念方案和属性来描述各种类型的关系。每个系统都是硬编码的,这就是软件知道如何操作数据的方式。我们想要一个可以使用数据模型作为输入的系统,所以我们仍然需要一些具体的东西来构建软件。这就是SKOS所提供的,一个我们的系统可以理解的建模知识的通用基础。
PDM使用领域模型将SKOS集成到内容工程生态系统的其余部分中。该系统的一个核心前提是,它采用域模型作为输入,并且可以派生的所有内容都是从该模型派生的。PDM基于模型定义构建用户界面,并利用UDA将此模型投影到类型安全的接口中供其他系统使用。系统将在我们的联合GraphQL API环境中使用UDA从域模型中投影的GraphQL模式提供域图服务(DGS)。
UDA还用于提供数据移动管道,这些管道能够为我们的GraphSearch基础设施提供数据,并将数据移动到仓库中。数据移动系统使用Avro模式,UDA创建从域模型到Avro的投影。
受控词汇表的使用者永远不知道他们在使用SKOS。领域模型使用适合领域的术语。SKOS定义层次结构的广义和狭义概念作为模型中的超级属性对消费者是隐藏的。这允许使用者使用他们熟悉的语言,同时使PDM能够使用任何模型。两全其美。