数据编织架构已成为促进支持业务的许多不同系统之间数据交换的一种方式。
数字化转型不仅仅是将工作流(workflows )和流程(process)数字化的问题。这也是改造遗留系统和专有系统以及其他孤立数据源的问题,以参与连接系统、应用程序和服务的生态系统。从本质上讲,这是一个促进支撑企业基本工作流程和流程的所有资源之间的数据交换的问题。
数据编织架构已成为解决此问题的有希望的解决方案。数据编织用于将分布式资源结合在一起,无论它们位于何处(云或本地;本地或远程),或者它们为数据交换而公开的 API。就目前而言,这非常有用。
然而,与任何事物一样,Data Fabric 架构也有优缺点、成本和收益。本文将探讨这些问题。
从广义上讲,似乎至少存在三种流行的数据编织架构概念。
结果是围绕数据编织的概念出现了一种术语上的空洞:在最通用的情况下,它适合每个人;在最具体的情况下,它描述了一种非常具体的分布式数据架构。为了解决这个空白,让我们探索支撑 Data Fabric 架构的核心技术。这应该让我们更好地了解它实际上是如何工作的。
这些是:
DV 做了几件有用的事情。
数据目录使用元数据(即描述数据的数据)来发现、识别和分类有用的数据。如果数据缺乏有用的元数据,数据编目使用技术(如数据剖析)来生成新的元数据:是客户数据吗?产品数据?销售数据?
在一定范围内,高级数据编目技术可以发现和/或生成其他类型的元数据,例如数据沿袭。(数据是从哪里来的?对它做了什么?什么时候?由谁做的?)最重要的是,目录是数据发现的重要工具。例如,业务分析师可以交互式地查询数据目录(最好使用自然语言)以发现有用的数据。潜在有价值的来源不仅包括应用程序、服务和数据库,还包括文件数据: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 的人也是客户。”最后一个是全新的知识。
支持者倾向于提出数据编织架构的最佳案例。这种最佳情况视图强调通过抽象简化数据访问,无论接口或位置如何。支持者同样强调联合访问与集中访问不同的好处。例如,一个组织既不移动也不复制数据;业务单位、团体、实践等拥有并控制他们产生的数据。但是支撑数据编织的技术有其自身的成本和收益。
值得简要探索这些以掌握数据编织架构的局限性。
数据编织使用 DV 直接连接到业务应用程序和服务,包括支持财务、销售和营销、人力资源和其他关键业务功能领域的 OLTP 系统。这些系统不保留交易数据的历史;相反,它们会在新事务发生时覆盖现有事务。因此,DV 平台必须结合某种持久性存储来保存和管理历史交易数据。在某个时刻,这开始看起来像是一个以数据仓库为核心的 DV 平台。数据仓库本身也不保存原始交易数据;相反,它摄取和管理该数据的派生子集。问题在于,这些原始或“详细”数据(即仓库未保存的谷壳)可能对业务分析师、数据科学家、ML 工程师和其他专家用户有用。因此,DV 平台也必须包含某种类似数据湖的存储库来捕获这些数据。
数据编织掩盖了分布式数据源的物理位置。但是,当数据被整合到不同类型的有用组合中时,数据才是最有价值的。这是 SQL 查询的基本功能。数据仓库架构通过集成和整合数据然后将其移动到一个地方:仓库来解决这个问题。最重要的是,数据仓库使用持久数据编织(索引、预聚合汇总等)来加速查询。这些加速方案中的大多数都涉及缓存数据。
在数据编织中,数据通过分散的位置进行访问,并以物理方式移动到 DV 平台中,在那里进行集成和整合。再次,DV平台必须至少接管仓库的部分功能。为此,它缓存和预聚合数据以及创建索引以加速常见查询的性能。对于真正的即席查询,或处理需要来自分散来源(例如企业边缘的传感器)数据的分析/ML 模型,数据不能被缓存或预聚合;相反,它必须按需获取——无论其位置如何。至少,这会引入显着的延迟;在最坏的情况下——例如当 DV 层必须通过高延迟连接访问边缘数据时——它会导致作业无响应。结果是,作为数据处理引擎,数据编织往往无法预测(与数据仓库相比)。
这些只是一些权衡(如硬币的反面)抵消了数据编织的积极好处。他们和其他人(例如,数据治理的复杂性增加)都不构成令人瞩目的问题;然而,它们是潜在采用者需要注意的问题。
另一个问题与数据编织的基本偏见有关——即,它偏向于数据访问,而不是数据管理。举一个例子,Gartner 的数据编织概念是一种用于访问和移动数据的技术基础设施。这种偏见是数据编织的一个特征,而不是错误:它是一种简化数据访问的有用方法——例如,分散在多个资源中并由 API 访问的数据。它作为分布式应用程序工作流的集成技术特别有用,例如在应用程序现代化或数字转换工作中。
然而,这种有用性总是与管理数据的优先级相冲突。
问题是,我们管理数据不仅仅是为了管理或控制它;当我们设计方案来保存数据历史时,或者当我们优化数据编织以提高不同类型工作负载的性能时,我们会管理数据。每当我们创建可复制、可重用的数据流以及可复制、可重用的数据清理和调节例程时,我们都会管理数据。
当我们实施数据版本控制功能时,或者当我们为生成用于支持决策、规划、预测和其他活动的清洁、一致的数据定义客观标准时,我们会管理数据。数据编织经常被定位为一种破坏性的零和架构——一种消除集中存储库或摆脱繁重的数据管理工具、策略和实践的方法。将其视为一个既是又是命题——对数据管理工具、实践和概念的补充,而不是替代,会更有帮助。