介绍

回顾历史，数据架构是针对现有IT解决方案的痛点和新业务需求而开发的，通常是在新兴技术时期。了解这种演变有助于将诸如数据织构和数据网格之类的新数据架构趋势置于组织中现有数据景观的背景下。为了展示新数据架构的价值，关键在于确定能从新数据架构趋势中受益的用例，并定义项目的范围，以在合理的时间内为业务提供价值。

自数据库的发明以来，尤其是上世纪70年代具有标准化应用程序编程接口（API）Structured Query Language（SQL）的关系数据库管理系统（RDBMS），组织数据的需求以一种可用于回答业务驱动问题的方式存在着。在1990年代中期，数据仓库的数据架构主要是为了报告和结构化历史数据的数据分析而发展，可能结合了不同的数据存储。在2010年代，随着人工智能、物联网（IoT）和边缘计算的广泛采用，处理大量结构化、半结构化和非结构化数据的需求出现了。这导致了数据湖的数据架构，它具有非常引人注目的承诺，将来自不同来源的数据以原始格式存储在单个位置，通常作为文件以满足任何所需的数据消费。作为进一步的演变，出现了数据湖仓4架构，即数据湖和数据仓库概念的合并，它使得在数据湖上进行机器学习（ML）和业务分析成为可能。

最近，可用的处理能力和用于管理数据架构元数据的人工智能开发，导致了数据织构和数据网格架构及解决方案概念的出现，这些概念利用智能和自动化系统实现了各种数据管道和云环境的端到端集成。这种高层次的架构演变如图1-1所示。

许多数据架构能力，如数据集成、数据复制、提取-转换-加载（ETL）管道、数据治理等，已经存在很长时间了。过去，所有用例都被规定了一组特定的这些能力，即使它们并不满足用例的要求。数据织构架构承诺通过智能元数据引导，为每个用例选择适当的能力。

数据架构：价值与挑战

关系数据库管理系统（RDBMS）引入了几个后来成为数据架构基础的功能。

第一个功能是将逻辑数据模型 - 关系模型 - 与数据的物理存储分开。这种分离创造了一个需要引入元数据目录的需求，描述数据在表中的逻辑布局以及其与物理存储的映射，维护诸如数据大小、数据分布和其他特征的统计信息。 RDBMS提供了维护数据的物理存储的功能，当数据变化过多导致物理布局及数据访问不够优化时，可以重新组织数据到定义的顺序中。它还通过提供备份和恢复功能利用可用的系统功能来确保数据的可用性。

第二个功能是标准化的结构化查询语言（SQL）用于访问数据。如今，对SQL的支持存在于所有世代的编程语言中，例如汇编语言、COBOL、Java和Python。SQL不断扩展，包括数据类型，如XML和JSON，以及最近用于干扰ML和深度学习（DL）模型的新功能。RDBMS的这两个关键功能成为建立企业数据仓库（EDW）架构的基础，我们将在下一节中探讨。

企业数据仓库（EDW）

有趣的是，最初使用关系数据库管理系统（RDBMS）存储数据是为了报告目的，使用SQL和生成SQL的工具作为快速获取结果的途径。在1970年代，与将数据存储在数据集或层次数据库中相比，RDBMS中的数据访问性能对于事务应用来说还不够。随着可用计算能力的增加，大多数事务系统的数据被迁移到了关系数据库中，这显著提高了应用程序员的生产力。

以下两个主要业务需求促使了EDW架构的发展：

事务和报告应用的数据库分离：诸如核心银行业务或航空公司订票应用等事务系统是业务关键的，并且与报告应用相比具有不同的可用性和响应时间特性。业务要求将用于事务和报告应用的数据库分开，以避免影响事务应用的性能或可用性。
集成来自多个源的数据并进行重新结构以提高性能和数据可用性：来自事务应用的数据并不适合报告和分析应用程序的存储。人们意识到需要将数据从源头复制并将其转换为适合报告和分析的格式。

上述需求导致了EDW4架构的形成，其中数据从事务应用上传到一个暂存区，然后经过复杂的数据清洗和转换步骤，派生数据被存储在EDW中。通常，在中间暂存区存储了多次数据。

该EDW架构如图1-2所示。

EDW架构提供了以下特征以解决业务需求：

合并和清洗（使一致）来自多个事务源的数据。
分离用于事务和报告应用的数据。
即使源数据不提供，也保持数据历史。
将数据转换为适合报告性能的数据模型（使用星型或雪花模式）。转换管道为维度表（例如时间、销售地区、产品等）提供数据，而中间的事实表保持维度之间的关系记录，例如在某一时间段内某个地区的产品销售情况。
使数据对业务用户易于消费。

EDW架构取得了巨大成功，几乎每个组织都实施了它。如果不是所有组织，今天仍然在许多报告需求中使用EDW。

然而，随着业务希望能够了解更多的数据，包括半结构化和非结构化数据，以做出更好的数据驱动型业务决策，EDW架构也带来了新的挑战：

ETL过程还在EDW中创建了新的数据质量问题。事务应用程序不断向其数据库中添加数据元素（模式更改）。这些新添加或更改的数据元素需要在ETL管道中反映出来。由于ETL流程没有正确更新或完全忽略了这些变化，EDW实施通常不能充分反映事务应用程序的数据。
EDW中的数据延迟通常超过1天，这对许多分析应用程序来说已不再可接受。一些报告应用程序使用的数据可能已经超过一周。
如果数据不在EDW中已经可用，或者实施ETL流程以添加新的数据元素需要很长时间，那么基于EDW中存储的数据进行的数据分析的新业务请求通常会被拒绝。
即使今天许多事务应用程序被法律要求保留历史数据，或者可以使用SQL构造（如双时间功能）以很少的开销实现历史数据，ETL流程仍然大部分时间用于计算历史数据，这增加了数据延迟和数据质量的挑战。
最后，EDW非常适合结构化数据。集成半结构化和非结构化数据是一项挑战。

在新可用技术的背景下，借助Apache Hadoop开源项目提供的网络化的多台计算机和大规模廉价存储，满足了这些需求，从而形成了数据湖架构。

大数据、数据湖和数据湖仓

业务用户需要访问其组织的数据，以探索内容、选择和注释，并使用自己的术语访问信息，并以数据保护和治理为基础，例如，市场营销人员寻找新的活动数据，需要临时访问各种各样的数据源，并支持决策制定。

存储和处理大数据需要一种新的数据架构。产生结构化、半结构化（例如，XML、JSON）和非结构化（例如，文本、音频、图片）数据的大量新数据源无法在EDW中处理。

Apache Hadoop开源项目诞生于处理这些海量数据的需求。它提供了一些关键技术，成为许多数据湖实现的基础：

Hadoop分布式文件系统（HDFS），一个分布式文件系统，为存储在文件系统上的数据提供可扩展且性能良好的访问。
MapReduce，一个用于大规模数据处理的大规模并行的批处理编程模型。Apache Spark和Apache Hive利用内存技术提供了更快的大数据处理，以满足ML算法所需的要求。
YARN，一个资源管理平台，负责在集群中管理计算资源以及Hadoop通用库和实用程序。

随着公共云解决方案的更广泛接受，今天数据湖可以使用云存储服务来实现，除了本地的Hadoop实现。

数据湖架构通常具有单一的数据存储库，通常以原始格式存储。它不需要像EDW中那样严格维护的模式定义。相反，用户可以在查询中构建自定义模式，使数据源集成更加灵活。

图1-3显示了一个数据湖架构。在左侧是所有可能的数据源，使用不同的技术（例如流式处理、数据复制和数据集成）将其复制到数据湖中。它具有多个数据区域，用于不同类型的数据处理。着陆区存储所有传入数据的原始格式。分析区和存档区存储用于报告、高级分析和ML的转换后的数据。数据值可能会在数据湖中的多个数据区域中复制。右侧是数据消费应用程序，例如决策管理系统和预测分析工具。信息治理概念被引入以管理对数据副本的访问权限，在原始数据源中应严格保护这些数据。

许多进行数据湖项目的组织意识到，将所有数据存储在一个地方的模型不仅带来了机遇，还带来了新的挑战。最大的挑战不是创建数据湖，而是利用其所带来的机遇。

如果没有仔细管理，复制大量数据可能会导致以下挑战：

由于数据湖中的更新延迟，存在使用陈旧数据进行分析的风险。
随着数据源数量的增加，理解和解决真相版本之间的复杂性。
随着数据和数据源数量的增加，存储和集成成本以及复杂性增加。
使业务面临许多监管风险。随着原始数据源的元数据不断变化，数据治理变得极其困难和昂贵，这导致数据湖需要进行适应性调整。

因此，许多组织开始质疑数据湖相较于最初的承诺所带来的衍生业务价值。数据湖变成了数据沼泽。EDW和数据湖的挑战促使了新的数据管理概念的需求，即数据湖仓，它是一个开放的数据管理架构，将数据湖的灵活性、成本效益和规模与EDW的数据管理和ACID（原子性、一致性、隔离性、持久性）事务结合起来，从而使传统的商业智能（BI）和ML能够在各种数据结构上运行。因此，数据湖仓结合了数据湖和EDW的特征和能力。这通常基于开源组件，例如delta lake，它是一个经过优化的存储层，为数据湖仓平台中的数据和表提供基础。delta lake是一个开源软件，它通过为ACID事务和可伸缩的元数据处理提供基于文件的事务日志，扩展了Parquet数据文件。

作为一种新的数据和人工智能平台，实施数据湖仓需要一种新的数据架构，即数据织构。在第10章中，我们进一步阐述了数据织构架构和数据网格解决方案的演变。如今的企业需要一种敏捷的数据架构 - 数据织构架构 - 它可以隐藏数据源景观日益增加的复杂性，并实现业务用户的轻松数据消费。以智能和敏捷的数据织构架构为基础，数据网格解决方案通过建立数据市场和以数据为产品消费模式来实现其承诺，是前进的道路。

在下一章中，我们将讨论数据织构架构和数据网格解决方案之间的关系和共存。

主要观点

我们总结本章的几个主要观点，如表1-1所述。

#	主要观点	高层描述
1	数据架构是一个演变。	数据架构通常是基于业务需求利用最先进技术开发而来的。
2	关系数据库和通过SQL访问数据。	关系数据库引入了数据存储与逻辑数据组织的分离，以及通过SQL进行标准化数据访问。
3	企业数据仓库（EDW）整合来自不同来源的数据。	企业数据仓库是一个集成和转换的中央存储库，存储着来自不同来源的结构化数据，并用于报告和数据分析。
4	EDW由复杂的ETL或ELT过程填充。	EDW由复杂的基于ETL或ELT的过程填充，这些过程会产生数据延迟、数据质量和灵活性方面的挑战。
5	数据湖存储原始结构化和非结构化数据。	数据湖是一个存储结构化和非结构化原始数据的仓库系统，位于一个中心位置。
6	数据湖可能变成数据沼泽。	管理不善的数据湖被称为数据沼泽，对业务价值提供很少的帮助。
7	EDW和数据湖的挑战导致了数据织构的出现。	实施EDW和/或数据湖的挑战促使了一种新的数据架构 - 数据织构的产生。
8	数据织构是数据和连接过程的集成层（织物）。	数据织构是基于活动元数据的数据源和连接过程的集成层。

数据织构概念

2016年，NetApp在一份白皮书中首次提出了"数据管理愿景...，无缝连接不同的云，无论它们是私有的、公有的还是混合的环境。" NetApp对数据织构的描述聚焦于混合云景观，突出了诸如数据安全、治理、集成、应用和服务层等关键方面。然而，它忽略了一些关键的数据织构能力，例如，基于活动元数据驱动的方法、融入人工智能/机器学习任务以及自助服务交付。

Gartner将数据织构定义为"作为数据和连接过程的集成层（织物）的设计概念。数据织构利用现有、可发现的和推断的元数据资产进行持续分析，以支持集成和可重复使用的数据的设计、部署和利用，包括混合和多云平台。"在他们的数据织构架构中，Gartner强调了一些关键特征，如嵌入式人工智能/机器学习、语义知识图谱、自动化重复任务、活动元数据（技术、业务、操作和社会）、动态数据集成、数据目录和自动化数据编排。有了这些特征，Gartner的数据织构架构描述是相当全面和先进的。

Forrester定义了数据织构为提供"统一、集成和智能的端到端数据平台，以支持新兴用例。它自动化所有数据管理功能 - 包括摄取、转换、编排、治理、安全、准备、质量和策划 - 从而加速用例的洞察和分析。"在他们的文档中，Forrester强调了在所有数据管理功能中内置的自动化和智能化、治理和合规要求、数据目录、集成、人工智能/机器学习、知识图谱以及与主数据管理（MDM）的集成，这是一套相当全面和完整的数据织构能力。

数据织构框架

正如您在第1章中所看到的，数据织构是数据架构演变的结果。然而，在提出"数据织构"这个术语之前，许多它的能力已经存在了很长时间。例如，数据集成和数据治理已经在IT行业的议程上存在了几十年。那么，有哪些新的要求和能力突出呢？

首先是基于人工智能/机器学习的对所有数据织构领域的增强和自动化，包括基于人工智能/机器学习的智能集成，生成活动元数据和知识图谱以被捕获在知识目录中。此外，确保可信的人工智能，并将传统数据治理的范围扩展到统一的人工智能治理是一个相对较新的领域，这远远不仅仅关注数据，还包括将AI模型和相应的AI工件纳入治理领域。最后，自动生成、发现和执行数据规则和政策的需求越来越多地依赖于人工智能/机器学习。

这些新的要求和特征在图2-1中进行了描述，这是一个高层次的示意图，展示了一个现代数据织构框架。

以下是关键的数据织构任务和能力的简要描述，这些能力可以用于实施数据网格或其他解决方案。这些任务和能力可以轻松地映射到图2-1所示的数据织构框架：

对所有数据进行目录编制：包括业务词汇表以及设计时和运行时的元数据（业务、技术和操作元数据）。
启用自助服务能力：解决数据发现、剖析、探索、质量评估、数据产品消费等问题。
提供知识图谱：可视化数据、人员、流程、系统等之间的相互关系，推导出额外的可操作洞察。
提供智能信息集成：支持IT人员和业务用户在数据集成和转换、数据虚拟化和联合任务方面。
从元数据中获得洞察：对数据集成、数据工程和数据治理的任务和作业进行编排和自动化。
确保可信的人工智能：确保人工智能方法和结果的可解释性、透明性和信任度，在存在偏差、漂移、精度和准确性下降等情况时采取适当的行动。
强制执行本地和全局数据规则/策略：包括基于人工智能/机器学习的自动生成、调整和执行规则和策略。
管理端到端统一生命周期：实施一致的端到端的数据织构任务生命周期，跨各种平台、角色和组织。
强制执行数据和人工智能治理：将传统数据治理的范围扩展到包括人工智能工件，例如人工智能模型、管道等，并考虑新出现的数据治理规定和隐私法规。

由于我们已将AI/ML增强和自动化所有数据织构领域作为一个新的关键要求，接下来我们将对此进行详细阐述。

AI融入的数据织构

AI及其相关的ML和DL是理解数据织构概念或架构与我们过去处理的传统数据架构之间的区别的关键。

通过将AI融入到数据织构架构中，能够更深入地了解数据、简化数据访问、实现数据选购、增强传统数据治理、生成活动元数据以及加速产品和服务的开发。一个融入AI的数据织构不仅利用了AI，还是一种管理和处理AI工件的架构，包括AI模型、管道等。

图2-2展示了一个融入AI的数据织构所包含的基本组件。

以下是对这些组件的高层描述：

AI治理：与我们之前对融入AI的数据织构所做的描述类似，AI治理也适用相同的概念：传统数据治理显然通过利用AI方法（AI治理）得到了改进，例如，通过应用机器学习方法来分析数据治理法规和隐私法律，或者实施与治理相关的数据规则和政策。然而，它还需要扩展其范围，包括AI工件的治理（AI治理），例如，通过管理和治理AI模型和其他AI工件。
基于AI的目录编制：基于AI的知识目录构成了融入AI的数据织构的另一个基本连接组件，它通过存储自动生成的元数据、利用AI方法生成增强的知识、生成和存储知识图谱、存储基于数据织构的数字排放元数据，并实现语义丰富化。
可信的人工智能：部署和操作人工智能，以及消费和解释人工智能结果，需要永久的透明度和可解释性。可信的人工智能的目标是在整个生命周期中检测偏见、漂移和准确性和精度降低等AI模型，并提出纠正措施以将AI工件重新对准业务目标。
AI生成的数字排放元数据：所有数据织构任务都会生成额外的数据，例如日志、数据质量度量、AI工件、数据访问路径等。我们将这些数据称为数字排放，它可以转化为数字排放元数据，进一步分析以获得额外的洞察，以改进相应的数据织构任务。
基于AI的语义丰富化：应用AI可以对数据进行自动丰富，以语义知识对数据进行语境化，例如，基于知识图谱和目录中的其他现有元数据。语义丰富化旨在通过利用这种语义洞察来简化和优化应用程序和业务用户对数据的消费。它还可以简化和优化一些关键的数据织构任务，例如在特定业务背景下搜索和发现资产。
融入AI的实体匹配：异构和分散的数据景观、系统和应用程序阻止了业务用户匹配核心信息（主数据），例如人物数据（例如，客户、业务合作伙伴、员工、公民等）、产品和服务。融入AI的实体匹配补充了现有的确定性和概率匹配技术，产生了更准确的匹配结果。

现在，让我们来讨论数据网格概念的关键方面。

数据网格概念

与"数据织构概念"部分类似，我们开始这一部分的讨论，简要介绍了Gartner和Forrester的观点。

根据Gartner的说法，数据网格是"为构建业务专注的数据产品而设计的解决方案架构；它是一个可以在技术中立的框架内指导设计的解决方案架构。"在他们的文章中，Gartner强调了数据网格的关键要求，如以数据为产品、分布式数据治理和权威性，以及将数据网格呈现为解决方案。此外，Gartner还特别描述了数据网格与数据织构的关系，我们将在下一节中讨论。

根据Forrester的说法，数据网格"是一种社会技术方法，用于在复杂和大规模环境中共享、访问和管理分析数据------无论是在组织内还是跨组织。"在他们的文章中，Forrester讨论了数据网格的基本社会技术原则，如"面向领域、数据即产品、自助服务、联合、计算数据治理。它将数据和业务成果的软方面置于首位。"

实质上，数据网格解决方案将数据围绕业务领域所有者组织起来，并将相关数据资产（数据源）转换为可供分布式业务用户从各个业务领域或功能中使用的数据产品。这些数据产品是以自治、分散和自助服务的方式创建、管理和使用的。自助服务能力，正如我们已经提到的数据织构能力，使业务组织能够建立一个具有数据购物特征的数据市场。

图2-3是对数据网格解决方案的概念描述，引用了其关键特征或解决方案设计要求。异构和分散的源数据景观包含了构建数据网格解决方案所需的源数据。为了解释图2-3，我们需要指出在实施数据网格时的一个具体方面：正如您在图2-3中所见，它还可以包括核心信息，即由MDM系统管理的数据源_2（主数据）。这些主数据可能与多个数据产品相关，因此必须由不同的产品所有者发现、访问和使用。因此，一个业务用户（例如，来自业务领域_B的用户），通常访问来自其业务领域_B的数据产品，也可能需要访问由数据领域所有者_A拥有的这些主数据。这种需求在图2-3中通过从中间数据消费者访问由数据领域所有者_A拥有的主数据作为数据产品的箭头来说明。

让我们详细说明构建数据网格解决方案的关键设计要求，如图2-3所示。再次强调，当我们提到数据时，我们指的是传统意义上的数据，但也包括AI工件：

数据源：用于最终构建数据产品的相关数据可以存储在事务系统、DWH系统、数据湖或数据湖仓中，或由应用程序和其他系统管理。它作为创建数据产品的基础。
数据领域所有者：源数据由特定的数据领域所有者托管，他们执行数据治理任务，并负责底层源数据的可消费性。数据领域所有权分散，与相应的数据资产（数据源）相关联的责任明确。
数据领域：由于数据网格解决方案固有地分布在业务领域之间，因此基础数据领域严格位于特定业务领域（业务线）的范围内。
数据产品：在特定业务领域内，创建相应的数据产品。同样，这是一个分布式的过程，特定的数据产品由与该业务领域相关联的数据消费者拥有、管理和使用。
数据市场（数据购物）：数据产品需要在数据市场环境中提供给相应的业务用户。这包括搜索、发现和消费数据作为产品。

数据网格解决方案的价值在于将数据产品的创建分配给最熟悉业务领域及相应需求的数据工程师和主题专家。

正如前面所述，来自其他业务领域的业务用户可能有兴趣访问另一个业务领域的数据产品。这种跨业务领域的数据产品消费也需要由数据网格解决方案来实现。

在前面的章节中，数据织构架构和数据网格解决方案之间的关系似乎已经内在地被理解，尽管我们还没有清晰地描述这一点。我们将在下一节详细阐述这种关系。

关系：数据织构与数据网格

在讨论数据网格解决方案时，我们强调了关键的解决方案要求，如面向业务的数据产品、分布式数据领域所有权、自助服务能力等。这是在没有明确说明实现数据网格解决方案所需的技术能力的情况下完成的。我们的数据网格解决方案设计要求和关键特征可以被视为实施解决方案的一组指导方针。然而，正是数据织构架构使数据网格成为可能。换句话说，数据织构是实现数据网格解决方案的架构基础。

正如您在本章前面所看到的，数据织构由技术能力组成，如数据概要、自动化元数据丰富、业务词汇表、AI治理等，以提供数据作为产品。数据网格的社会技术方法和概念------借用Forrester的术语------是通过这些数据织构技术能力来实现的。根据Gartner的说法，数据织构"可以在不遵循数据网格实践的情况下构建。数据网格必须利用内在于数据织构的发现和分析原则。"

在与IBM客户合作中，我们经常面对这样一种看法，即数据织构和数据网格方法是两种替代方法，必须做出有意识的"二选一"决定。我们更倾向于同意Gartner的观点，即数据织构是构建数据网格解决方案的基础架构。此外，数据织构不仅限于作为数据网格的架构基础；它还可以被有意地调整和设计以服务于其他解决方案，例如，一种最先进的数据仓库系统。

这两个术语之间的关系如图2-4所示。基于数据网格解决方案的设计要求，确定了一组数据织构技术能力。从数据网格业务需求中推导出的数据网格解决方案设计要求是数据网格解决方案的规范。

由于存在多个不同的数据织构使用案例场景或入口点，因此并不是所有可用的技术能力都是必需的------至少最初不是。一旦确定了一组技术能力，就可以推导出一个合适的初始数据织构架构------也就是说，确定的数据织构能力被部署在相应的数据织构架构中，最终作为所需初始数据网格解决方案的架构基础。

随着时间的推移，将确定额外的数据网格业务需求，从而得出相应的数据织构技术能力，这将导致数据织构架构的调整和扩展，进而增强数据网格解决方案。因此，随着时间的推移，会进行迭代调整，以满足可能随时间出现的额外数据网格业务需求。

数据作为产品和数据产品是描述数据网格解决方案时一直使用的最基本术语之一。正是这些术语需要我们更加详细地描述。

数据产品

数据何时成为数据产品？将原始数据转换为可消费的数据产品需要发生什么？将原始数据转换为数据产品并构建数据产品始于对原始数据的明确定义的数据所有权，结束于业务用户等数据消费者轻松使用相应数据产品。

构建数据产品由数据领域所有者实现；然而，构建数据产品本身主要由数据产品所有者驱动，该所有者可以是市场营销或客户关怀组织、售后团队，甚至是个别业务用户。数据产品所有者在整个数据产品构建过程中与数据工程师、数据科学家和其他主题专家合作。

图2-5是构建数据产品所需的高层描述。

除了数据布局和知识目录之外，图2-5描绘了两个主要责任领域，分别与数据领域所有者（左侧）和数据产品所有者（右侧）相关。以下是数据领域所有者和数据产品所有者的责任：

数据领域所有者责任：数据必须在知识目录中可用并注册，并且相应的元数据应该被丰富，我们将在第五章详细说明。数据的可用性、质量、一致性、完整性和货币性必须通过SLAs（服务级别协议）来保证。数据治理 - 包括数据质量 - 可能通过强制执行的数据规则和政策来保证。最重要的是，数据领域所有权并不会因为数据消费者访问并可能将数据复制到其他数据存储中而消失；它会继续存在，无论数据存放在何处，以及谁在以任何目的使用数据产品。
数据产品所有者责任：构建数据产品需要数据的轻松发现性；执行数据剖析；获取额外的见解，例如，通过语义知识图；以及执行必要的数据转换作业。这些任务通过知识目录得以便利，需要以自助服务的方式执行。数据产品是可消费的结果，意味着这些过程的结果，其中原始数据被转换为有意义的业务上下文。数据产品所有权伴随着与数据产品的可用性、业务相关性、易于消费性、完整性和准确性相关的SLAs的保证。在某种程度上，我们可以将术语"购物数据"视为构建数据产品的描述。底层的数据布局架构使DataOps、ModelOps和AIOps能够在数据产品的整个生命周期中编排所需的业务和技术调整。一个数据产品是基于原始数据转换为有意义的业务上下文并且易于被业务用户消费的。它通过知识目录实现，并且可以通过持久的原始数据领域和数据产品所有权来描述，这与先前描述的SLAs一样。生产数据产品需要数据布局功能和具有自助服务功能的基于GUI的应用程序或工具，以便于生产数据产品并将其注册在知识目录中供业务消费。

以下是数据产品的主要特征。我们可以将这些特征视为存储在知识目录中的数据产品规范；数据产品本身以及可供消费的数据市场上都存储和提供了这些规范：

数据产品所有者：有一个明确定义的数据产品所有者，他们指定他们的业务目标、特征和特性，并制定可能随时间实施的增强计划。

数据产品描述：数据产品需要被充分描述，类似于任何其他产品，例如软件程序或软件产品。这可能包括数据产品的目的或业务意图、其版本、法律方面和使用限制、底层原始数据的货币性、使用数据产品的成本等。
语义相关数据和AI资产：数据产品由一组语义相关的数据和AI资产组成，可以是一组关系表，也可以是一组流水线、一系列ETL阶段、一个Jupyter笔记本等。这种语义关系由业务上下文和使用目的定义。识别语义相关数据和AI资产的过程是通过知识目录的元数据丰富功能实现的。
访问方法：数据产品必须包括访问方法，例如REST API、SQL、NoSQL等，以及找到数据资产的位置。例如，这可以是通过定义的REST API访问的URI端点，该REST API与数据产品相关联。
政策和规则：这包括描述谁被允许出于什么目的使用数据产品。它还涉及访问控制、授权、治理方面等，所有这些都由知识目录中定义的数据产品政策和规则管理。
SLAs：这些是数据产品所有者与数据产品消费者之间定义的SLAs，可能包括与数据产品的可用性、性能特征、功能、数据产品使用成本、AI模型的解释性要求、底层数据和AI资产的信任和质量评分等相关的协议。
已定义格式：数据产品需要使用已定义格式进行描述，例如，可以通过JSON或XML文件（或任何其他数据交换格式）来实现，其中包含或指向相关资产（例如，数据产品描述、数据资产、Jupyter笔记本、AI模型）、SLA、访问方法等。数据产品可以存储在知识目录中作为JSON或XML文件。
已编目：所有数据产品都需要在知识目录中注册，其中还需要存储JSON或XML文件。这些数据产品需要可搜索和可发现，供潜在的数据产品消费者和业务用户使用。
可消费：数据产品需要准备好供消费，这意味着例如底层的原始数据和AI资产、数据管道、ETL转换作业等是可用和可访问的。

创建数据产品可能还取决于来自多个数据领域所有者的原始数据。此外，其他数据产品也可以作为构建另一个数据产品的额外输入。例如，数据科学家可能通过使用来自多个数据领域所有者的原始数据或多个可用数据产品作为输入来开发AI模型，其中产生的AI模型作为输入，供营销组织构建定向营销活动作为一组数据产品。因此，我们可以建立一个数据产品的层次结构，其中包含来自其他数据产品以及数据和AI资产的相应依赖关系。

我们需要再次强调，数据产品本身并不存储在知识目录中；它们是通过数据产品规范在知识目录中注册的，这些规范也被视为元数据。因此，数据产品与产品规范的关系与任何其他数据或AI资产与其相应元数据的关系相同。将数据产品规范以XML或JSON文件（或任何其他数据交换格式）的形式提供在知识目录中，使得数据产品可由业务用户和其他数据产品开发人员搜索、发现和使用。

在组织需求的背景下，Data Mesh解决方案专注于数据作为产品，从而遵循分布式和联合实施方法。然而，这将知识目录的编排和多个知识目录之间的元数据交换置于任何Data Mesh实施的中心位置。

此元数据交换可以通过Open Data Platform倡议（ODPi）Egeria实现，这是一个基于开放元数据和治理（OMAG）和开放元数据存储库服务（OMRS）的开源Linux基金会项目，其使元数据存储库能够共享和交换元数据的一组开放API、类型和交换协议。ODPi是一个非营利组织，加速和标准化企业大数据技术的开放生态系统；OMAG是一个项目，旨在创建一组开放API、类型和交换协议，允许所有元数据存储库共享和交换元数据；OMRS是一种服务，用于使元数据存储库交换元数据。

通过Egeria开放元数据存储库队列实现此元数据交换，这是一组服务器使用点对点交换共享元数据，如图2-6所示。任何符合Egeria的知识目录都可以加入Egeria开放队列，使用开放元数据和治理格式和接口交换和共享其元数据。

例如，IBM Watson Knowledge Catalog（WKC）与其他符合Egeria标准的存储库之间的元数据交换可以通过Egeria队列实现。IBM Watson Knowledge Catalog管理数据资产（例如，数据集、表、列、视图、连接和文件以及它们与术语表工件的关系）在Common Assets Managed Services（CAMS）存储库中。商业术语表工件（例如，业务术语、类别、数据类、策略和治理规则）在商业术语表存储库中进行管理，如图2-6所示。CAMS具有内置的Egeria引擎，允许将由IBM Watson Knowledge Catalog管理的目录和商业术语表添加到OMRS队列中。

添加到知识目录的任何资产都会触发Kafka OMRS消息，这些消息会发送到Egeria队列。这要求Kafka服务器可以从IBM Watson Knowledge Catalog访问。正如本章前面所指出的，数据布局是实现数据网格解决方案的架构基础。因此，在随后的章节中，当我们具体指的是架构方面时，我们使用术语"数据布局"，而当我们特别强调数据产品（数据即产品）和数据市场方面时，则使用术语"数据网格"。

数据编织和数据网格使用情景

许多组织意识到实施数据驱动型业务以保持竞争力的重要性。因此，组织的首席数据官（CDO）面临着创建和实施数据战略作为数据驱动型业务基础的挑战。

数据编织架构和数据网格解决方案的基本组成部分如第2章所述，与典型的数据战略关注领域相一致。因此，围绕这两个概念的组件的用例为您的数据编织和数据网格之旅提供了展示价值和有意义的入口点的机会。

图3-1显示了作为开始实施数据编织/数据网格并随时间推移在旅程上前进的有意义且与业务相关的常见用例。这些四个入口点的更深入处理在本书的后续章节中提供：

数据治理与隐私：建立一个自动化和一致的AI治理环境，其中涉及传统意义上的数据，同时也包括AI制品，例如需要进行治理的ML模型。
混合云数据集成：在混合云中创建数据的统一视图，包括公共和私有云部署，以及传统的本地系统。
客户360度视图：通过将AI融入匹配过程，提供对客户、供应商和其他方的全面视图，以保证此核心信息的准确性和信心。
MLOps和可信AI：实施可信AI和MLOps，以检测和解决部署和生产中的AI模型的偏差、漂移和恶化质量指标，并进一步解决AI模型的可解释性。

数据战略中的优先级确定了最适用和相关的用例或入口点，以组织为起点开始您的数据编织和数据网格之旅。在这些入口点的背景下开始您的数据编织和数据网格之旅时，您可以选择一个或甚至多个用例，特别是因为其中一些场景之间存在一定关联。例如，可信和可解释的AI在概念上与AI治理相关。

为了确保成功引入数据编织作为新的数据架构，关键在于明确定义范围良好的用例，并定义一个根据您的数据和AI战略定义的为业务提供价值的结果。它应该展示了在数据编织架构中与组织中现有数据景观（例如数据湖或传统EDW）相比的结果差异，例如，将具有明确定义模式的EDW的结构化数据移动到数据湖中，并将其存储为Hadoop环境中的文件，采用这种方法将丢失在关系数据库中优化处理结构化数据的好处以及明确定义的模式信息，即在星型或雪花模式中定义的信息。数据使用者必须重新检测此前在EDW中readily可用的模式信息。如果相同处理容量下的相同分析需要更长时间，数据使用者必须承担数据结构检测的负担，那么很难向业务推销数据湖的好处。

所讨论的用例为利用数据编织架构和数据网格解决方案为业务提供价值提供了独特的机会。

即使特定用例的目标有所不同，所有用例的实施都将首先导致构建一个增强的、智能的数据或知识目录，作为实现这些概念的核心基础，如图3-2所示。

以下是与知识目录相关的关键活动：

存储元数据：在知识目录中搜索、定位和存储元数据及相关工件（业务、技术和操作元数据）。即使希望最终将所有组织数据放入数据目录中，也需要逐步建立，并专注于定义业务领域或与特定组织相关的选定用例的数据。在医疗保健行业中的一个例子可能是患者信息。知识目录还应存储与AI制品相关的元数据，例如AI模型、Jupyter笔记本、流水线等。
定义数据血缘关系：定义和查看数据血缘关系（业务和技术）并进行影响分析。由数据架构实现，如EDW和数据湖，组织中的数据经常被复制以供不同应用程序使用。使数据流程可见至关重要。首先，像《通用数据保护条例》（GDPR）这样的法规要求组织根据请求删除所有副本中的个人数据。为了执行这一规定，需要知道哪些数据流程处理了该数据以及数据流程执行创建或更新了哪些副本。其次，它还提供了有关数据质量和数据延迟的指标。从位置A复制数据到位置B并不是一个技术上的挑战。在较长的时间内保持位置A和B的副本一致是一个真正的操作挑战。随着复制的副本数量和复制的数据量增加，问题变得无限复杂。第三，它使数据工程师可以看到数据集成优化和替代方法。例如，是否有必要和可取的方式是在数据流程中复制原始数据，而不是用派生数据补充或扩展原始数据，这可能是一种更明智的方法？
定义数据和AI治理：定义数据和AI治理政策、规则和分类对于打破数据孤岛、实现统一数据消费并防止数据滥用至关重要。它包括对合规性的监控和对数据和AI规则和政策的持续执行，以及确保符合法规和法律。
添加额外的洞察力，丰富数据：通过自动分析为数据源添加额外的洞察力。通过增加元数据的额外信息，如数据分布、数据质量和业务术语，对数据和数据产品的消费者提供数据服务（DaaS）至关重要。例如，对客户记录中的电话号码属性进行数据分析可能会显示电话号码在各种数据存储中未被一致地维护，因此对于消费应用程序或用户的价值有限。

通过执行上述活动来建立知识目录对于在静态环境中的少量数据源而言是直观的。在现实世界中，数据源的数量和现有副本可能会很大，并且元数据也在不断变化。

旨在支持数据编织和数据网格实施的产品的功能提供了以下不同iating的价值：

任务自动化：智能自动化发现、分类和编目，以保持元数据的最新性。例如，为了支持交易应用程序中的新功能，将新数据属性添加到客户记录中。这种元数据更改需要传播到数据目录，并警告消费应用程序有关更改的发生。
限制数据移动：将原始数据留在原地，并利用数据虚拟化实施替代数据集成技术，以显著减少数据重复。这种做法可以提高数据的可用性、延迟和质量。许多复制数据的决策是在某个特定时间做出的，利用了可能已经过时的产品和硬件功能。即使是在相对较长的时间内，保持少量元数据变更的最新和一致也已经是一项挑战。在较长时间内保持数千兆字节的数据副本一致是不现实的。
智能部署AI模型：部署AI模型以智能地为特定用例提供数据并进行编排。例如，营销活动服务最好通过数据虚拟化访问原始数据源，以确定营销活动的目标群体，而数据准备服务作为机器学习模型开发的输入，则可以执行数据转换流水线，并将准备好的数据存储为副本，放在分析区域。智能信息集成，即AI注入的信息集成，支持数据工程师简化其任务。

自动化和一致的治理

在许多组织中，建立一个自动化和一致的AI治理环境是数据战略的重点，并且作为实施数据编织架构和数据网格解决方案的首个用例入口点，如图3-3所示。

数据治理是指定义、管理和执行组织数据的访问、隐私、可用性和安全性的过程和责任。通常包括一套政策、规则和数据分类，以及监测和执行合规性的功能。正如前面所述，我们在更广泛的意义上使用术语AI治理，还包括AI制品。

数据治理并不是一个新概念。实施集中化数据和AI治理的需求存在于检测不同数据源之间的数据不一致性的情况下。例如，一个数据属性，比如账户号码，在不同数据源中可能被命名相同，但意义不同，因此无法用于合并相关数据。或者，相同的属性在不同数据源中以不同的名称存储，但没有额外的元数据，数据消费者无法看到它。

每个数据平台都提供定义和管理数据访问规则和政策的功能。这种孤立的实施是跨数据源数据消费的一个痛点。例如，当用户需要访问存储在不同数据平台上的数据时，通常会触发每个平台的特定流程来批准和定义所请求的数据访问，并且需要很长时间才能完成。

监测与不断增加的数据隐私和保护法律的合规性，比如欧盟的GDPR，跨不同数据源，并简单地回答组织中谁获得了什么数据访问权限的问题本身就是问题。因此，许多组织开始建立一个专注于以下活动的数据和AI治理结构：

数据和AI标识：识别数据和AI资产，并为组织或整个企业创建一个相关元数据清单 - 一个知识目录。
数据管理政策：定义管理数据创建、获取、隐私、完整性、安全性、分类和质量的规则和政策。
数据评估：开发衡量数据和AI制品质量、使用情况和影响的过程，以及监测和优化相关行动。
数据沟通：建立通过知识目录获取数据的文化，并保持知识目录中存储的元数据的时效性。

很明显，通过实施智能、增强的数据目录作为Data Fabric架构的基础来建立数据和AI治理结构是可行的。

在没有正确的产品能力的实施和使用下，任何项目执行都将非常困难。所选产品应支持组织中的数据源和平台，并提供AI增强功能，以摄取和自动丰富元数据，使业务用户能够轻松理解、协作、丰富和访问正确的数据，从而快速建立高度自动化和一致的治理环境，并自动保护整个组织的数据。

包括IBM zSystems数据在AI治理中

举例来说，我们想向您介绍IBM zSystems，也被称为主机，它运行了许多大型企业的大部分业务关键应用程序。全球财富500强中有71%的公司在IBM zSystems上运行其业务并存储数据，无论是在关系数据库Db2 for z/OS中，还是在结构化文件系统VSAM中，或者在分层数据库IMS中。许多数据工程师和数据使用者并不熟悉IBM zSystems，并且将理解和访问存储在IBM zSystems上的运营数据视为一个主要的痛点。

一个在IBM zSystems和其他平台上存储数据的组织表达了他们对改进数据消费的需求：

在需求时使数据属性对数据使用者可用。
支持新旧数据平台的共存。
提供用于互操作性和安全性的法规合规性。
应用一致的治理以改善数据质量。
实现对数据的准实时访问。

图3-4展示了该组织如何通过在存储在Db2 for z/OS、VSAM以及其他数据源中实施数据治理服务来响应这些需求的架构概述图。

在这个例子中，IBM Cloud Pak for Data上的IBM Watson Knowledge Catalog提供了一个安全的企业管理平台，该平台得到了一个数据治理框架的支持。数据治理框架确保数据访问和数据质量符合定义的业务规则和流程：

知识目录：IBM zSystems数据需要与IBM Watson Knowledge Catalog集成。存储在Db2 for z/OS中的数据可以直接集成到知识目录中，而存储在IMS或VSAM中的数据首先需要映射到IBM Data Virtualization Manager for z/OS (DVM for z/OS)中的虚拟视图。来自DVM for z/OS的元数据也可以集成到知识目录中。
治理文档：数据管理者和数据质量分析员可以分配AI治理文档，例如数据和AI政策和规则，并分析和改善数据和AI资产的质量，以及定义数据脱敏规则以保护敏感数据。
规则和政策：当访问IBM zSystems数据时，例如插入、删除或更新时，数据治理规则和政策会被一致地应用。这种集成方法展示了如何使存储在IBM zSystems上的数据能够轻松地供利益相关者智能使用，而不需要任何主机知识，同时保持严格的数据质量和合规标准。

跨混合云的统一数据视图

混合云整合了公共云服务、私有云服务和本地基础设施，并提供了跨三者的编排、管理和应用可移植性。如图3-5所示，其采用导致了跨混合云的统一数据视图的需求，从而引发了下一个数据编织或数据网格的用例。

传统上，企业管理自己的本地IT基础设施和计算中心，并安装和维护硬件和软件（操作系统、中间件和应用程序）。根据组织如何跟上现代IT能力的采用以及内部变革流程的复杂性，新的业务解决方案往往过于繁琐，可能需要很长时间，成本也过高，设计和实施起来困难重重。

无法满足新业务需求的能力让业务部门感到沮丧，并为公共云提供商创造了机会。公共云提供商专注于自动化服务资源的配置和计量，并可以提供各种服务。云提供商提供基础设施即服务，快速配置计算资源（例如，计算能力、存储、内存）以部署所需的软件堆栈，以及开发和测试新应用程序，使其可供业务部门使用。其他云提供商提供解决方案作为服务的订阅，例如salesforce.com提供的客户关系管理。

云式配置及其弹性、可伸缩性和服务交付便利性的优势推动了虚拟化、软件管理和自动化技术的发展，组织在其自己的计算中心采用了这些技术，实施了私有云。

图3-6显示了云计算的不同部署选项。许多组织选择了支持其业务需求的应用现代化战略。例如，一个组织可以选择淘汰其自己定制的客户关系管理（CRM）应用程序，转而订阅云原生服务提供商。他们可以决定将其自定义的财务应用程序或与获得分析洞见相关的应用程序迁移到公共云提供商。

许多IT组织还选择了在其IT数据中心实施部署和计量自动化技术的方法，从而创建了一个私有云。另一种常见选择是应用现代化，在本地基础设施中采用现代应用架构，例如微服务架构，这可能是受核心业务应用程序的法规合规性要求的驱动。

图3-7显示了上述示例的架构概述，在此之前，数据以前存储在本地（图3-7左侧），现在分布在多个公共云和多个本地平台上，以各种可能的格式存在（图3-7右侧）。在混合云环境中创建组织数据的统一视图比仅在本地环境中更加复杂。

数据湖架构可能不是满足这种数据访问需求的良好选择，因为每天将大量数据复制到不同的云提供商中的单个数据存储库可能会遇到操作困难（例如，网络延迟和带宽问题，跨多个组件的问题确定）并且成本可能变得难以承受。

在不同的数据源之间实施数据编织，重点是增强数据集成流程，充分利用ETL、数据虚拟化和实时捕获，以优化访问这些多样化的数据源，似乎是更好的架构，能够满足当今对增强敏捷性和灵活性的需求。

这样的项目将按照之前概述的步骤进行，再次在一个明确定义的范围内，比如一个数据领域：

数据识别：在混合云数据源中识别与领域相关的数据资产，对于成功地在混合云环境中实施，所有数据源所有者都承担对数据作为服务提供给数据消费者的责任，因此有强烈的兴趣将数据源的元数据集成到领域知识目录中。此外，他们需要提供适用的业务词汇表。
数据管理政策：数据源所有者需要定义治理该领域数据和AI工件的创建、获取、隐私、完整性、安全性、分类、质量和消费的规则和流程。
数据评估：制定衡量数据和AI资产的质量、使用情况和影响的流程，以及监视和优化相关行动。
数据作为服务（DaaS）：组织为数据消费者提供一个市场变得至关重要，并通过知识目录提供数据。数据集成管道的自动化和数据虚拟化等数据和AI资产集成技术的推荐需要成为这个用例的一部分。

采用数据编织进行混合云数据集成，可以创建跨数据存储的视图，实现操作应用程序之间的一致性。这是整合和简化IT基础架构的绝佳机会，可以在任何地方（本地或任何云上）运行，并自动化数据操作。关键的区别在于实现智能信息集成，通过增强的数据集成流程充分利用各种数据提供方法，例如ETL、数据虚拟化、复制和流式处理技术，以优化对多样化数据源的访问。

数据编织提供了在数据管道中本地构建质量分析和纠正的能力，无需昂贵的下游处理。在混合云环境中构建数据编织解决方案依赖于这样一个数据编织架构的能力。

对于数据消费而言，通过通用的治理规则、政策和流程支持统一的端到端AIDataOps生命周期至关重要。

提供对客户、供应商和其他相关方的全面视图

在商业世界中，人们普遍认为了解客户对业务的各个方面至关重要。图3-8说明了客户360，即对客户、供应商或其他相关方数据的全面视图，作为数据编织或数据网格项目的第三个用例。

这是业务战略的一个重要输入，用于确定投资哪些产品或服务以推动创新，并成功增长销售，同时提供卓越的客户服务。根据2019年麦肯锡的一项调查，大约四分之一的调查参与者描述他们的公司在组织内始终一致地使用客户洞察。

这个用例展示了数据编织架构如何为解决客户或其他相关方资料不一致的问题提供基础，建立一个单一、可信的、全面的客户360度视图，从而实现了数据网格解决方案的方法，该方法需要对客户数据进行360度全面视图以构建相应的数据产品，并通过可信赖的数据市场提供这些产品。

在历史上，组织中的每个应用程序都维护其自己的客户、供应商或其他相关方关系。例如，在保险行业，通常会有不同的应用程序来管理人寿保险、汽车保险和家庭保险。如果一个客户在该保险公司拥有汽车、寿险和家庭保险单，并更改了电话号码，那么电话号码需要更改三次。随着全渠道环境中在线客户互动的趋势，组织开始关注主数据管理（MDM），将客户数据和其他核心信息集中化，并将其与现有应用程序集成。尽管如此，仍然很难回答以下问题：

我的哪些客户也是我的供应商，以便更好地协商合同条款，并且这些客户接受另一个合同的可能性有多大？
客户与服务提供商之间是否存在关系，可能会暴露出潜在的欺诈模式，欺诈的可能性有多大？
如果客户数据库中有多个相似的条目，它们是否代表同一个人或组织，可以包括在营销活动中？

如果所有应用程序都在本地运行，最好是在单个平台上，将客户数据集中到主数据管理（MDM）解决方案中并集成现有应用程序可能效果很好。然而，将新数据源集成到现有的MDM解决方案中是一项相当复杂的工作，并会增加采用新业务解决方案的时间和成本。

当组织采用混合云策略时，情况变得更加复杂和要求更高。

图3-9显示了数据编织架构如何帮助提升客户洞察力。

客户数据被选为领域，项目将包括以下实施数据编织的行动：

数据识别：发现并识别跨数据源分布在混合云环境中的客户、供应商或其他相关方数据。
AI增强的实体匹配：通过应用AI增强的实体匹配，创建高质量的客户、供应商或其他相关方档案。AI增强的实体匹配可以补充现有的确定性和概率匹配技术，从而产生更准确的匹配结果。
丰富的客户档案：通过附加信息（如数据分布、数据质量、业务术语以及客户参与记录等半结构化和非结构化数据），增强客户元数据。
数据管理政策和规则：数据源所有者需要定义用于管理客户数据的规则、政策和流程，包括创建、获取、隐私、完整性、安全性、分类和质量的规定。应自动执行法规。
数据即服务（DaaS）：对于提供客户和其他相关方数据，数据延迟和数据质量尤为重要。应使用AI算法智能地为特定用例提供数据交付和编排建议。对于系统交互而言，使用数据虚拟化访问操作性数据源可能是首选的数据集成技术。它避免了数据消费者的数据不一致性，并简化了新数据源的集成。

围绕智能增强型知识目录的数据编织和数据网格能力支持创建全面的客户、供应商或其他相关方档案，从而增加了数据消费者对主数据的信任。通过应用AI增强的实体匹配，解决不同数据源中的实体，可以创建更好的客户档案，而不是花费时间寻找已经被充分理解的优质数据。

解锁可信的人工智能概念

人工智能继续渗透到业务运营的各个方面，并且实现了改善企业盈利能力、增强人类能力和经验等新的业务用例。图3-10展示了数据编织或数据网格项目的第四个也是最后一个用例。

根据IBM商业价值研究所（IBV）对C级高管的调查，85%的先进采用者正在通过人工智能降低运营成本，99%的参与者报告称使用虚拟代理技术减少了每次联系的成本。尽管人工智能有很多前景，但许多人质疑其可信度。四分之三的高管将人工智能伦理视为竞争差异化的源泉。事实上，许多组织已将人工智能伦理纳入其业务指南；他们在将人工智能伦理实践和行动应用到业务和IT流程中方面遇到了挑战。

对于可信和可解释的人工智能的要求表明需要实现MLOps，将开发和操作化领域连接起来，这意味着数据编织和数据网格需要在一个平台上编排人工智能模型的开发，例如，在本地x86集群或公共云上，并在另一个平台上进行部署和操作化以进行评分和推理，例如在IBM zSystems上。

特别是对于MLOps和可信的人工智能，这还包括在事务性景观内的数据访问和数据集成。

在我们解释可信的人工智能之前，让我们提供一个MLOps的简单例子。MLOps的意义在于专注于自动化与机器学习相关的任务，如特征工程、训练和验证、版本控制，最后是部署和操作化。

图3-11是一个高级架构概述图，右侧展示了基于IBM Cloud Pak for Data和IBM Watson Studio的AI开发环境，可以在本地x86集群或公共云上运行，并且左侧是基于IBM Watson Machine Learning for z/OS和CICS作为事务管理器的操作环境，运行在IBM zSystems上。使用IBM Watson Studio开发的AI模型需要从分布式环境中导出，然后导入并投入生产，用于IBM zSystems侧的每个CICS事务的评分和推理。

一旦AI模型被部署并投入生产，就需要定期监控和衡量AI模型的结果，这可能意味着每天、每周或更长的时间间隔。这是为了了解和确认AI模型的持续业务相关性。

例如，数据科学家和业务用户有兴趣------甚至是受到即将出台的关于可信的人工智能的监管法规的激励------来检测与数据准确性和精度下降相关的偏差和漂移；他们还需要了解AI模型在操作化过程中的公平性变化或质量指标是否在恶化。此外，业务用户越来越需要解释AI模型结果是如何得出的，例如影响特征方面的信息；他们需要建立信任和信心。应对这些挑战的术语总结为可信的人工智能。

以下是可信的人工智能能力的简要列表：

偏差：在整个生命周期中检测和纠正AI模型的公平性（偏差）
漂移：检测和纠正漂移（准确性和数据一致性下降）
可解释性：解释AI模型（AI模型结果的透明性）
质量指标：衡量AI模型质量指标，包括AI模型在操作化时

在数据编织和数据网格的过程中实施可信和可解释的AI用例（或入口点）需要供应商产品中具有不同的功能和特性。此外，例如，如果检测到偏差或漂移，或者在AI模型投入生产时某些AI模型质量指标在恶化，就需要自主地启动纠正措施------至少在可能的情况下------以解决这些问题。这可能包括触发AI模型的重新训练、重新验证和重新测试过程，包括收集更新版本的数据并执行相应的数据准备任务。

使用人工智能的数据织构和数据网格方法——Data Fabric 和 Data Mesh 基础

介绍