category
什么是数据编织？
数据编织是一种技术不可知、基于网络、以自动化为重点的数据架构和设计模式，其核心是为您提供一致可靠的数据处理方式。数据编织背后的核心思想是模拟将各种数据资源编织到一个将所有数据资源结合在一起的结构中。
本文将带您了解数据编织背后的基本思想，数据编织解决的核心问题，以及使用数据编织如何帮助您的业务。
目录
- 什么是数据编织？
- 为什么选择数据编织？
- 数据编织架构和原理
- 数据编织备选方案
- 数据编织：我们学到了什么？
- 数据编织：相关读取
为什么选择数据编织？
数据编织节省了数据处理和移动成本，同时使您的架构经得起未来考验，可以添加更多的数据源和孤立的数据。
在过去几年中，各种数据技术、基于API的开发和基于微服务的应用程序架构迅速增加。随着这一增长，企业已经有了各种数据源可供整合。
数据处理技术的出现为希望根据自己的需求利用数据的各种业务功能提供了更多的权力和自由。这也导致企业拥有更加分散和分散的数据，通常被称为孤立数据。
有几种数据平台工程方法可以帮助处理竖井：
- 不要允许孤立的数据——数据仓库可以帮助实现这一点；在某种程度上，数据湖也可以帮助实现这一点。
- 允许孤立的数据，让业务团队拥有孤立的数据——这基本上就是数据网格所采用的方法。
- 允许孤立的数据并连接这些孤立的数据，以便它们被孤立并与业务无关，而无需四处移动或复制数据。
数据编织采用上述方法中的第三种方法。
数据编织架构和原理
尽管如前所述，数据编织是一种技术不可知的架构模式，但有几个核心功能可以定义它是什么。在本节中，我们将从核心原理和功能的角度讨论数据编织的组成：
- 无缝的数据集成和交付
- 完成数据编目和发现
- 数据治理和安全
- 可观察性和透明度
- 高度自动化
数据移动和复制是数据平台存在的障碍。让我们先来看看数据编织是如何帮助圆变平方的。
无缝的数据集成和交付
数据编织的主要产品之一是无缝集成异构、分散且通常是孤立的数据源。通过使用跨平台数据共享、洁净室和CDC（变更数据捕获）等概念，数据编织可以将数据源编织在一起，以适应单个数据平面。
然而，实际上，通过传统的数据移动模式，如ETL或ELT，可以减少企业内数据生态系统的额外工作负载。
数据编织可以让您精确地实现这一点。由于数据不会频繁移动或复制，这使得数据管理更加容易，并且数据所有者可以控制访问。
尽管在数据湖或数据仓库上建立数据编织似乎与不移动或复制数据的想法背道而驰，但事实并非如此。
任何传统的数据系统都可以成为数据编织的一部分，前提是它能够支持操作所需的基本功能，例如通过JDBC连接器和RESTAPI公开数据。让我们以跨组织共享数据为例。
数据编织将为您提供多种方法来访问当前所在的共享数据。
显然，在您访问共享数据之前，所有的治理和隐私政策都将适用，这就是为什么控制权始终在于与您共享数据的企业。
完成数据编目和发现
数据目录和数据发现工具由元数据提供支持。元数据可以直接从各种数据源获取，以及它们的业务上下文和数据沿袭信息。在数据编织中，最小复制和数据移动的原则也适用于处理元数据。
数据编织在处理数据编目和发现问题时的不同之处在于它能够提供更健康和最新的数据生态系统视图。这就是为什么数据目录成为数据消费者在数据编织中探索和与数据交互的第一层。
数据编织的数据目录并不完全像数据仓库或数据湖的数据目录。在这里，当不同类型的元数据（如数据字典、数据沿袭、业务上下文等）导致构建数据资产的语义网络时，数据编目的作用就扩大了。这种网络通常被称为知识图谱。
在数据编织中，数据目录成为数据消费者的第一个接触点，并使数据对他们可用。这意味着数据消费者可以使用单个接口搜索、理解和访问业务数据。
在这个关键时刻，身份管理、权限、数据隐私、数据安全以及数据治理的首要主题都出现了。让我们在下一节中讨论这个问题。
数据治理和安全
数据编织中的一切，包括数据集成、编目和发现，都发生在结构创建的虚拟化层之上。数据治理和安全也没什么不同。
与数据访问、共享、修改和分析相关的权限都在虚拟化层进行控制。
数据治理遭受着与大型组织中大多数耗时流程相同的官僚摩擦。
引入数据治理工具和流程是为了解决数据访问问题，但它们最终会使访问数据变得不必要地困难。
数据编织使您能够在不移动任何源数据的情况下从虚拟化层管理数据，从而帮助解决该问题。
虚拟化层成为您和数据之间的桥梁。这座桥可以让你从任何地方运输任何形状和大小的货物，有适当的安全措施和检查站来检查货物及其收货人。
可观察性和透明度
数据可观察性是一个涵盖数据可靠性、可用性、质量、安全性、治理等方面的总体主题。
从对流程和作业的基本监控，到记录自定义的、细粒度的消息，以了解谁在使用什么数据以及如何使用——可观察性涵盖了所有这些。
使用数据编织在系统中建立可观察性也会自动建立对系统的信任。数据编织通过其虚拟化层，使您可以很容易地查看系统的任何组件，并了解它在做什么，不仅是在事件或引发的错误之后，而且是实时的。
SRE的可观测性方法首先让开发人员在代码出现问题时很容易得到警报。一旦他们收到警报，他们就可以评估问题的影响。
这就引出了一个最重要的问题——现在该怎么办？通过适当配置的可观察性，可以通过访问正确的数据来解决这一问题，这使开发人员能够完全了解问题所在。
数据可观察性具有所有这些，但它也添加了治理方面。如果违反了PII或PHI数据共享规则，数据可观察性使您能够查看是否遵循了RBAC和ABAC规则，以及是否存在盲点，使业务易受数据相关安全事件的影响。
高度自动化
如果没有所有数据相关过程的核心自动化，无论是管理权限、共享数据、更新知识图等，上述领域都无法得到解决。可观察性支柱完全取决于将日志和消息自动传递到搜索引擎。
在基础设施方面，Terraform、Pulumi和CloudFormation等技术非常有用，尤其是在处理不断变化的多云设置时。
还有CI/CD工具，它们允许代码升级和交付，并集成了数据质量、测试和分析。
有了数据治理，您也可以通过创建自动化的治理测试来实时报告数据隐私和安全相关事件。这些问题，如果及早引起，有时可以防止灾难、巨额罚款和声誉损失。
数据编织备选方案
数据网格与数据编织
数据编织最突出的替代方案是数据网格。数据网格和数据编织都以各自的方式解决了孤立数据的问题。
数据网格通过将数据制作成不同团队和个人拥有的产品，解决了数据孤立的问题。因此，数据网格采用了一种去中心化的数据组织方法。数据编织采用稍微不同的方法。
尽管与数据网格一样，数据编织并没有摆脱孤立的数据，但它确实试图以一种看起来像是同一平面的一部分的方式将其连接起来；也就是说，存在孤立数据的事实与最终用户无关。
数据编织中的所有数据源都可以通过一个集中的数据目录进行访问，该目录水平放置在系统中的每个数据资产上。
数据编织与数据仓库与数据湖
将数据编织与数据仓库和数据湖进行比较并不是同类比较。有了这些和数据编织，就不是你是否或何时考虑实现数据解决方案的问题了。
数据编织不能取代数据仓库或数据湖。它通常与这两者中的任何一个或两者共存。这就是为什么将数据编织与数据网格进行比较是公平的，而不与数据仓库和数据湖进行比较。
数据编织：我们学到了什么？
本文讨论了当数据编织成为一个好的用例时，它是如何构成数据编织的，以及它如何在不删除孤立数据、不复制或移动大量数据的情况下解决孤立数据的问题。
数据编织：相关读取
- Data Fabric vs. Data Virtualization: Overview, Comparison, and Differences
- Data Catalog for Data Fabric: 5 Essential Features to Consider
- Data Mesh vs. Data Fabric: How do you choose the best approach for your business needs?
