Data Fabric架构的三种模式

从广义上讲，似乎至少存在三种流行的数据编织架构概念。

第一种方法将数据编织视为一种严格分散的架构，即一种获取原本分布的数据的方法，而无需先将其整合到中央存储库中，例如数据湖或数据仓库。在最平淡的情况下，这样的方案不再强调集中访问在数据架构中的作用。在最激进的情况下，它完全拒绝集中访问的需要。
相比之下，第二种更具包容性的数据编织将这些集中式存储库视为分布式数据架构中的非特权参与者：湖或仓库中的数据像其他来源一样通过数据编织暴露出来以供访问。这种对数据编织架构的看法包括集中式数据资源，但它仍然赋予分散式访问权限。
第三种对数据编织的看法将其视为混合数据架构的基础。该方案实际上要求数据湖和/或数据仓库发挥关键作用。它偏向于集中式访问，而不是分散式访问：数据编织为数据架构师提供了一种方法，既可以将分散的数据资源联系在一起，又可以满足专业消费者（例如数据科学家、ML/AI）不可预测的数据访问需求工程师和软件工程师。

Data Fabric 架构的技术组件

结果是围绕数据编织的概念出现了一种术语上的空洞：在最通用的情况下，它适合每个人；在最具体的情况下，它描述了一种非常具体的分布式数据架构。为了解决这个空白，让我们探索支撑 Data Fabric 架构的核心技术。这应该让我们更好地了解它实际上是如何工作的。

这些是：

数据虚拟化

DV 做了几件有用的事情。

首先，它简化了对数据资源的访问，无论其 GPS 坐标如何。 DV 为分散的资源提供了一个虚拟抽象层。就机器或人类消费者而言，通过 DV 公开的基于云的资源的行为就像本地数据中心中的资源一样。 DV 可用于将分散的资源整合到一个统一的视图中，这与虚拟数据库不同。
其次，DV 支持对分散的数据资源进行基于 API 的通用访问。现代 DV 在数据访问接口方面是普遍的；除了 SQL 访问之外，DV 技术现在还通过 SOA、RESTful 和 GraphQL 端点访问数据。专家还可以使用他们喜欢的工具（Java 和 JDBC；Python 和 ODBC，或 JDBC）通过结构获取数据。
第三，数据虚拟化使得构建和公开不同类型的预先构建的数据视图成为可能。这对于针对分散资源中的数据运行常见查询非常有用——无论是在云中还是在本地。另一个 DV 用例是作为频繁刷新报告的支持技术。这涉及将来自上游资源的数据集成到不同类型的复合“视图”中，这些“视图”在功能上等同于报告、仪表板等。通过这种方式，DV 可以支持基本的面向最终用户的实践（例如决策支持和 BI 分析），以及往往需要大量数据调节的专家实践（例如数据科学或 ML/AI 工程）。（在后一种情况下，DV 引擎可用于转换和集成旨在填充 ML 训练数据集的数据。）从这个意义上说，DV 结合了几种其他离散的数据集成功能——例如，数据分析、ETL 处理和数据清理——整合到一个引擎中。

数据编目

数据目录使用元数据（即描述数据的数据）来发现、识别和分类有用的数据。如果数据缺乏有用的元数据，数据编目使用技术（如数据剖析）来生成新的元数据：是客户数据吗？产品数据？销售数据？

在一定范围内，高级数据编目技术可以发现和/或生成其他类型的元数据，例如数据沿袭。（数据是从哪里来的？对它做了什么？什么时候？由谁做的？）最重要的是，目录是数据发现的重要工具。例如，业务分析师可以交互式地查询数据目录（最好使用自然语言）以发现有用的数据。潜在有价值的来源不仅包括应用程序、服务和数据库，还包括文件数据：CSV、电子表格、PDF，甚至是通过 SMB 和 NFS 网络共享公开的 PowerPoint 文件，或持久存储到对象存储层（如 Amazon S3）。

并且，可选：

知识图谱

这就是魔法发生的地方。知识图识别并建立它在不同数据模型中发现的实体之间的关系。在正式层面上，知识图谱试图将其发现“拟合”到不断发展的本体中。通过这种方式，它生成相互关联的实体的模式，包括抽象的（“客户”）和具体的（“Jane Doe”），将它们分组到域中，并在适用的情况下建立跨域的关系。

因此，例如，知识图确定“CSTMR”和“CUST”与“CUSTOMER”相同，或者以某种方式（xxx-xx-xxxx）格式化的一组数字与实体“SSN”相关，或此 SSN 与此客户相关。在具有统一数据模型的单个数据库中实现这样的事情是一回事；跨不同数据模型链接实体是另一回事：例如，SaaS 销售和营销应用程序中的“CUSTOMER” = 本地销售数据集市中的“CUST” = HR 数据库中的“SSN” = “EMPLOYEE Jane Doe拥有这个 SSN 的人也是客户。”最后一个是全新的知识。

Data Fabric 架构的内在限制

支持者倾向于提出数据编织架构的最佳案例。这种最佳情况视图强调通过抽象简化数据访问，无论接口或位置如何。支持者同样强调联合访问与集中访问不同的好处。例如，一个组织既不移动也不复制数据；业务单位、团体、实践等拥有并控制他们产生的数据。但是支撑数据编织的技术有其自身的成本和收益。

值得简要探索这些以掌握数据编织架构的局限性。

无数据历史记录：

数据编织使用 DV 直接连接到业务应用程序和服务，包括支持财务、销售和营销、人力资源和其他关键业务功能领域的 OLTP 系统。这些系统不保留交易数据的历史；相反，它们会在新事务发生时覆盖现有事务。因此，DV 平台必须结合某种持久性存储来保存和管理历史交易数据。在某个时刻，这开始看起来像是一个以数据仓库为核心的 DV 平台。数据仓库本身也不保存原始交易数据；相反，它摄取和管理该数据的派生子集。问题在于，这些原始或“详细”数据（即仓库未保存的谷壳）可能对业务分析师、数据科学家、ML 工程师和其他专家用户有用。因此，DV 平台也必须包含某种类似数据湖的存储库来捕获这些数据。

另一种劳动密集型：

在 DV 模型中，IT 技术人员和专家用户为非专家用户配置不同类型的预建连接。这项工作涉及公开单个数据源（例如，SaaS 财务、人力资源和销售/营销应用程序），以及构建和维护用于复制报告、仪表板等功能的预构建视图。它涉及构建和维护用于获取、清理和转换 SQL 分析或 ML 数据处理中使用的数据的复杂数据工程管道。
数据目录技术也是如此。一方面，目录是以人工搜索和发现为前提的。另一方面，它们公开了允许用户识别、分类、注释和共享数据的工具。大多数目录还公开了专家可以用来更改或转换数据以及跟踪此数据更改的工具。数据目录自动构建和维护元数据字典和业务词汇表，但在实践中，人类专家通常自行管理这些资源。
知识图谱技术也是如此。知识图谱可用作发现实体以及实体之间获得的关系的一种手段。它是展示新知识的强大工具。但它的发现是不可约的概率。因此，对于敏感的应用程序和用例，它发现的实体和关系以及它所呈现的新知识都必须经过人类专家的审查和批准。

位置很重要：

数据编织掩盖了分布式数据源的物理位置。但是，当数据被整合到不同类型的有用组合中时，数据才是最有价值的。这是 SQL 查询的基本功能。数据仓库架构通过集成和整合数据然后将其移动到一个地方：仓库来解决这个问题。最重要的是，数据仓库使用持久数据编织（索引、预聚合汇总等）来加速查询。这些加速方案中的大多数都涉及缓存数据。

在数据编织中，数据通过分散的位置进行访问，并以物理方式移动到 DV 平台中，在那里进行集成和整合。再次，DV平台必须至少接管仓库的部分功能。为此，它缓存和预聚合数据以及创建索引以加速常见查询的性能。对于真正的即席查询，或处理需要来自分散来源（例如企业边缘的传感器）数据的分析/ML 模型，数据不能被缓存或预聚合；相反，它必须按需获取——无论其位置如何。至少，这会引入显着的延迟；在最坏的情况下——例如当 DV 层必须通过高延迟连接访问边缘数据时——它会导致作业无响应。结果是，作为数据处理引擎，数据编织往往无法预测（与数据仓库相比）。

关键点

这些只是一些权衡（如硬币的反面）抵消了数据编织的积极好处。他们和其他人（例如，数据治理的复杂性增加）都不构成令人瞩目的问题；然而，它们是潜在采用者需要注意的问题。

另一个问题与数据编织的基本偏见有关——即，它偏向于数据访问，而不是数据管理。举一个例子，Gartner 的数据编织概念是一种用于访问和移动数据的技术基础设施。这种偏见是数据编织的一个特征，而不是错误：它是一种简化数据访问的有用方法——例如，分散在多个资源中并由 API 访问的数据。它作为分布式应用程序工作流的集成技术特别有用，例如在应用程序现代化或数字转换工作中。

然而，这种有用性总是与管理数据的优先级相冲突。

问题是，我们管理数据不仅仅是为了管理或控制它；当我们设计方案来保存数据历史时，或者当我们优化数据编织以提高不同类型工作负载的性能时，我们会管理数据。每当我们创建可复制、可重用的数据流以及可复制、可重用的数据清理和调节例程时，我们都会管理数据。

当我们实施数据版本控制功能时，或者当我们为生成用于支持决策、规划、预测和其他活动的清洁、一致的数据定义客观标准时，我们会管理数据。数据编织经常被定位为一种破坏性的零和架构——一种消除集中存储库或摆脱繁重的数据管理工具、策略和实践的方法。将其视为一个既是又是命题——对数据管理工具、实践和概念的补充，而不是替代，会更有帮助。

原文：https://www.itprotoday.com/analytics-and-reporting/data-fabric-architec…

本文：https://jiagoushi.pro/node/2125

本文地址

https://architect.pub/data-fabric-architecture-advantages-and-disadvantages