数据编织架构
- 37 次浏览
【数据架构】数据湖/网格/数据编织及其之间的一切（活动元数据）
我对Gartner®2023年数据与分析峰会的印象和展望-第3部分。
本博客系列的内容：
- 有目的的领导。与信任建立联系。产生影响。
- ChatGPT时代的数据与分析治理。
- 数据湖/网格/数据结构和介于两者之间的一切（活动元数据）。
- 数据业务的未来。
在上一篇博客中，我谈到了治理如何为企业在保持质量的同时实现技术突破做好准备。在这篇博客中，我讲述了数据管理新时代的黎明：活动元数据的兴起，它是不同组件之间的粘合剂，也是增强治理和数据结构/数据网格的推动者。
Gartner将20世纪20年代命名为“主动元数据时代”（而不是将2010年代称为“LDW时代”，将21世纪初称为“后EDW时代”）[1]。在Data Lake、Data Mesh、Data Fabric、DataOps、Metadata和其他流行的流行语之间，以及Generative AI工具的兴起，我觉得组织很难决定首先去哪里。
我总结了2023年Gartner数据与分析峰会上关于这些数据管理主题的多个会议，以帮助您理解定义、实施、利弊、长期战略和优先级等。
但第一件事是：我们将在“元数据时代”中使用的底层数据基础设施是什么？我希望，到目前为止，你们中的许多人都会回答“数据湖”
数据湖
“通过满足现代湖泊需求避免数据湖故障”[2]是唐纳德·范伯格关于数据湖以及如何使其工作的会议。随着唐纳德最近宣布退役，我很高兴有机会（对我来说）在舞台上听到唐纳德的最后一次讲话。
数据湖的概念并不新鲜，我们曾经期望ApacheHadoop是一种预处理数据湖，但当然，它没有ACID或治理。根据我使用Hadoop的经验，它主要用于数据科学项目。根据演示，这是一个典型的用例。众所周知，大多数Hadoop安装都不起作用。由于没有管理，Hadoop只是一个巨大的文件包，它需要人才才能访问ETL或商业智能应用程序中的数据。原来是沼泽地。
有趣的是，历史仍然在重演：数据湖应该有元数据、治理和数据区来服务于操作和分析用例。否则，它们很快就会变成沼泽。
Don表示，如果你成功地实现了数据湖，你应该预计数据科学、自助服务、客户360、仓储和报告等用例会呈指数级增长，你应该为此做好准备。
Don的准备建议是使用一个云，而不是在prem或多云上。
此外，Data Lakes应在D&A卓越中心（Architect、Steward、DS/DE/MDM）和职能部门（公民一切）之间进行多方合作。你知道所有关于不同单位“将数据保密”的恐怖故事——这不会随着数据湖而飞。
那么，我们如何促进合作呢？唐说：
- “控制你的数据湖-为了确保所需的数据存在，减少数据冗余，执行数据标准并控制数据保留。
- 管理湖泊数据的使用-为了商业合规、隐私和安全。
- 需要不同的语义（元数据、目录、谱系）——作为湖泊数据的文档，以便于数据探索和重用，并避免沼泽。”
阳光下没有什么是永恒的，正如我所了解到的，数据湖今天正面临一个平稳期，成功使用它们的可寻址市场总数接近20-25%。那么，数据湖之后的下一步是什么呢？湖畔小屋！
湖屋：是什么？Lakehouse是一种将仓库和数据湖结合在同一平台上的架构。如果你实现了它，计划有很多熟练的人才来支持它：从数据架构师和建模师到DE，再到DataOps，从语义专家到DPM、Stewards、DS和业务分析师。
我知道Hadoop的成功实现率在两位数以下，与Lakes类似。你应该如何增加你最终站在这一统计数据正面的机会？
Don建议：
- 专注于提供业务价值：为多个用例设计数据湖，以实现更高的业务价值。
- 选择数据管理工具来支持多种接收、细化、处理和交付方法。
- 向数据生态系统发展：规划所有这些和其他数据湖组件的变化和增长。
- 数据湖的员工和技能提升：数据产品经理、数据科学家和数据工程都备受瞩目。
- 确保你的湖不会变得浑浊：对允许的数据进行管理和保护。
唐纳德引用他的同事Guido De Simoni的话，为他的会议选择了一个有趣的结局：“元数据是数据湖中的鱼类发现者。”如果您现在还不明白它的意思，请继续阅读，直到“活动元数据”部分。
现在，我们已经将数据湖作为现代数据堆栈的主要数据基础设施组件进行了介绍，让我们看看它是如何与数据管理难题中的其他元素相连接的。
数据编织(Data Fabric)
Ehtisham Zaidi在其“实用数据结构-如何构建下一代数据管理设计”课程中提供了对数据结构的深入研究[3]。
正如著名的Simon Sinek所说，“让我们从为什么开始”——为什么我们需要Data Fabric？根据Ehtisham Zaidi在本次会议的开幕词，“Data Fabric为所有数据消费者提供集成数据。”
(Diagram: The Practical Data Fabric — How to Architect the Next-Generation Data Management Design, Ehtisham Zaidi, Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023)
什么是数据结构？
根据Ehtisham的说法，“Data Fabric不是一种单一的工具或技术。它是一种新兴的数据管理设计，用于实现灵活的可重复使用和增强的数据集成管道；利用知识图、语义和基于主动元数据的自动化；支持更快的数据访问和共享，在某些情况下，支持自动化的数据访问与共享，而不考虑部署选项、用例和/或体系结构方法。或者，“Data Fabric=元数据分析+建议。它充当智能编排引擎。”
如果你觉得这很复杂，你并不孤单：我有幸与之交谈的大多数峰会与会者还没有最终确定他们对这种方法的意见。
Data Fabric实现带来的预期好处可以掩盖这粒复杂的苦果（你可能还记得去年D&A峰会博客中的这句话）：
根据Ehtisham的介绍，到2025年，“数据结构中的主动元数据辅助自动化功能将：
- 将人力投入减少一半。
- 数据利用效率提高了四倍。”
据我所知，这些好处应该遍布整个组织：从促进业务用户的自助服务，通过提高数据团队的效率水平，到整个组织的数据素养水平，这将提高数据资产的利用率。
Ehtisham继续实施数据结构的九个实际步骤：首先，从建立元数据集合开始，就像我们几十年前对数据所做的那样。如果没有这个集合，用于管理它的工具将无关紧要。
Ehtisham列出了以下类型的元数据：
- 技术（模式、日志、数据模型）
- 操作（ETL、沿袭、性能）
- 业务（本体论、分类学）
- 社交（查询、观点、部落知识、反馈）
通过观察和比较这些不同类型的元数据，您将能够看到计划与实际用户行为之间的差异。
数据结构实现的第二步是元数据激活。
在过去的几年里，我们听到了很多“元数据激活”。它是什么？
在下图中，Ehtisham解释了元数据激活工具的作用——包括警报、建议、准备和编排。当前状态是“在情况发生变化时发送警报”。激活元数据是通过图形分析和处理异常的建议来完成的。
(Diagram: The Practical Data Fabric — How to Architect the Next-Generation Data Management Design, Ehtisham Zaidi, Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023)
步骤3：创建知识图并用语义丰富它们：
“当使用传统的数据建模和集成方法时，大多数关系见解都会丢失[…]数据结构将多关系数据呈现为知识图。”在这里，我们看到了数据结构和元数据激活如何利用知识图作为推荐的底层技术。
步骤4：使用Data Fabric的自动化建议：
元数据激活自动化功能将包括通过语义和搜索进行参与，深入了解异常和敏感数据标记，甚至自动更正模式漂移和数据源优先级。
步骤5：探索自助式编排机会：
重要的是要记住，数据结构的实现不需要完全自动化，正如Ehtisham Zaidi所指出的：“数据结构不需要数据管理优化，但它确实实现了它——不需要自动化。”因此，即使使用当前的（部分自动化）工具，也可以实现它。
步骤6：利用DataOps优化数据集成交付：
过去几年的另一个趋势术语是DataOps，这是有充分理由的：案例研究表明，“到2025年，一个以DataOps实践和工具为指导的数据工程团队的生产力将比没有这样做的团队高10倍。”听起来值得进一步探索！那么什么是DataOps呢？
DataOps是数据编排、数据可观测性、测试/部署自动化、环境配置管理、版本控制、CI/CD/Git/Jenkins的组合。就像Data Fabric一样，这不是从单个工具或供应商那里获得的功能，而是从上述类别中组装工具。
步骤7：将集成数据作为数据产品交付（或网格式交付）-准备就绪时：
在我看来，本次会议中讨论的所有内容的最终目标都是建立一个可靠的基础，允许为不同业务领域的自助消费提供数据产品。根据Ehtisham的说法，这种交付的运营模式可以是“枢纽和轮辐”（步骤8）。在我之前的博客中，它被称为“特许经营”。在这种方法中，中心团队拥有技术所有权、资源整合、治理和体系结构，数据产品用于业务功能。
埃蒂沙姆属于这种罕见的人，他将长期战略眼光与非常务实、务实的建议方法结合在一起，但如果你有机会与他交谈一次，你可能就会知道这一点。他继续进行最后也是最重要的第9步，根据组织对数据和业务问题的熟悉程度，提出了将Data Fabric投入生产的三条路径：基础路径、高级路径和自动化路径：
(Diagram: The Practical Data Fabric — How to Architect the Next-Generation Data Management Design, Ehtisham Zaidi, Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023.)
如果我试着把注意力集中在Ehtisham Zaidi的会议上，会弹出以下要点：
不要指望“购买”Data Fabric——这是一个概念框架，主要来自具有高度自动化的新技术解决方案。
激活您的元数据，但首先要收集它！
您的实施计划应包括获取利用DataOps的技能。
但是，如果不提及数据网格，我们怎么能谈论这么长时间的数据结构呢？对于这些有些冲突的方法，这似乎是社区中一个两极分化的论点。我在这里有很大的偏见，你可能会觉得这是通过下面这部分的总结得出的。
数据结构或数据网格：决定未来的数据管理体系结构
Robert Thanaraj和Ehtisham Zaidi联合参加了那场会议（“数据结构或数据网格：关于决定未来数据管理架构的辩论”），这场会议非常壮观[1]。
根据会议开幕式，回顾过去，我们可以说，数据架构的演变在经历了2010年代的“LDW时代”和2000年代的“后EDW时代”之后，在20世纪20年代实现了“主动元数据时代”的第三阶段。这种演变最初允许提供碎片化的分析，但后来统一，最后增强。
(Diagram: Data Fabric or Data Mesh: Debate on Deciding Your Future Data Management Architecture, Robert Thanaraj and Ehtisham Zaidi, Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023)
尽管大多数组织都面临着采用数据网格或数据结构概念的决定，但正如演讲者所提醒的那样，值得记住的是，Gartner的2022年数据管理炒作周期，在该周期中，数据网格出现为“高原之前的过时”，数据结构刚刚通过“膨胀预期的峰值”进入“幻灭的低谷”，你同意吗？
另一方面，Data Fabric的优势被评为“转型”，具有新兴技术的成熟度、1-5%的目标受众市场渗透率，以及5-10年的主流采用时间。
下面的幻灯片显示了数据结构实现的技术支柱，颜色编码从表示成熟度的绿色到表示新兴的黄色，再到表示最新功能的红色。
(Diagram: Data Fabric or Data Mesh: Debate on Deciding Your Future Data Management Architecture, Robert Thanaraj and Ehtisham Zaidi, Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023)
在会议的剩余部分，发言者强调了数据结构对数据团队的“共同试点”性质，以及它给业务用户的自助服务带来的信心。
现在来看数据网格：数据网格不是一种既定的最佳实践；它是一种新兴的数据管理方法，是一种领域主导的实践（数据由领域团队中的SME管理和治理），用于定义、交付、维护和治理数据产品（灵活、可重复使用和增强的数据工件）。
或者，换句话说：
(Diagram: Data Fabric or Data Mesh: Debate on Deciding Your Future Data Management Architecture, Robert Thanaraj and Ehtisham Zaidi, Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023.)
正如Robert Thanaraj和Ehtisham Zaidi所介绍的，Gartner对Data Mesh效益的评估被评为“低”，技术成熟度低，目标受众市场渗透率为1-5%，预计在稳定下来并被其他产品或方法吸收之前就会过时。
根据Robert的观点，Mesh的优点包括消费准备、通过市场批准托管人使用、为数据产品消费者自助、由主题所有者审计以及由数据产品经理管理的生命周期。对我来说，这听起来与Medium上Mesh“圣经”中的原始定义非常相似。
有了上面详述的所有缺点和风险，为什么组织要探索数据网格作为其数据管理实践的有效可能性？
据我所知，原因是：
- 失败的部署经常会危及集中式设置。
- 竞争紧迫的业务优先级-通过在业务功能中实现网格，绕过IT以获得速度和规模。
- 快速访问公民分析师的自助服务。
- 克服像意大利面条一样的点对点集成。
Robert和Ehtisham分享了Gartner进行的一项调查的统计数据：
- 大多数组织都让IT部门实施Mesh
- 80%的人对域级别的治理实施不满意
- 另一个风险-数据网格的实施咨询量很大
- 项目通常以手动硬编码的语义层结束
在会话中听了所有这些之后，我看不出Mesh和实现数据仓库硬编码语义层之间的区别！
“2021年Gartner D&A治理调查显示，只有18%的受访者表示，他们的治理已经成熟，并在整个企业中扩展。这一类人在实现治理成果方面的总体成功率远高于其他人。”
那么，什么时候应该使用网格呢？仅当元数据成熟度较低且治理成熟度较高时（！）！！！
85%的组织在这两方面都很低（！！！）那么我们能做什么呢？坚持使用DW并开始捕获元数据。
追求两个“低点”的Mesh将带你回到2000年代的筒仓。
最后，本次会议最重要的幻灯片是：
(Diagram: Data Fabric or Data Mesh: Debate on Deciding Your Future Data Management Architecture, Robert Thanaraj and Ehtisham Zaidi, Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023.)
你可能还记得，元数据是这个博客每一部分的共同主题——从你应该在哪里存储数据（中央数据湖）、如何最大限度地提高其价值（通过治理和管理），以及是优先考虑数据网格还是数据结构框架。这清楚地表明，在引领Data Fabric实现的惊涛骇浪之前，必须谨慎而勤奋地处理元数据。
数据质量是每个人的工作，所以它不是任何人的责任。为了解决这个问题，选择你的冠军，理想情况下，如果你有资源，一次开始所有四个步骤的十二个动作：
- 确定业务用例（并非所有数据都同等重要）-受（较差）数据质量影响的主要业务结果是什么？
- 发现IT部门的利益相关者也倾向于业务职能。教他们DQ的通用语言。
- 确定最关键的DQ问题：通常是在法规遵从性方面。为您的用例定义什么是“足够好的”，定期重新检查，并分析错误容忍度。
- DQ应该是治理倡议的一部分，永远不要单独处理。不仅要与治理委员会对话，还要与其业务利益相关者进行对话。
- 技能：聘请精通沟通和项目管理、政治头脑强、具有商业头脑、数据和分析技能的数据管理员。他们会调查问题，有时甚至会解决问题；策划和管理元数据；定义和监控规则；并协调DQ最佳实践。
- DQ对业务和IT的兴趣是一项团队运动。从最能受益的个人开始，向他们展示成功故事，以及利益集团领导人，激发激情。
- 数据分析和监控：找到一个工具来量化你的DQ。监测异常情况和基准品位。
- 制定一个改进计划，包括短期分析、预防计划和补救任务。
- 从基于真相的模型切换到基于信任的模型。打破信任介绍级别（有保证的、肯定的、证明的、承认的、断言的、未知的）。为每个数据资产定义所需的级别，并确定改进的优先级。这是索尔演讲的一部分（如上所述）。
- 利用自动化和扩充：否则就不可能进行扩展。使用AI/ML的活动元数据是需要查找的工具。
- 将DQ纳入业务工作流程。分析DQ问题发生的频率，并通过集中的DQ服务交付解决这些问题。
- 数据素养：接受DQ思维，让人们关心，并促进知识转移。
我们正处于世代人工智能时代的边缘，ChatGPT在微软强大的品牌支持下率先发展。在将这些先进的Generative AI工具应用于您的数据环境之前，必须解决数据质量和治理问题。否则，我们最终会得到一个更昂贵的“垃圾进垃圾出”版本。但这还不够：你还需要控制Generative AI工具如何将其数据模型解释（或映射）到你自己的数据模型-如果这种映射做得不正确，例如，供应商帐户被错误地映射到客户帐户，即使数据质量最好，我们也会得到错误的结果。因此，治理不仅不会很快取得进展，而且在不久的将来将成为不可或缺的工具。然而，它必须经过高度的自动化才能有效地应对这些新的挑战。自动化或至少增强治理是可能的，其中一种方法是激活元数据。我将在本系列的后面讨论这个问题。
噢，孩子！如果你读了这句话，那就太好了。你在这个博客里熬到了最后！
我选择将Data Lake、Data Fabric、Data Mesh和Active Metadata的主题结合起来，因为它们都解决了我们必须面对和解决的范式转变，以实现第一篇博客中讨论的新现实，并支持我在第二篇博客中涵盖的治理，使其值得信赖。在本系列博客的最后一部分，我将介绍峰会上讨论的数据业务的未来。
[1] Gartner, “Data and Analytics Governance: Foundations and Prospects,” Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023.
[2] Gartner, “Deploy Data and Analytics Governance Effectively to Drive Better Decisions,” Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023.
[3] Gartner, “Twelve Actions to Improve and Sustain Your Data Quality,” Gartner Data & Analytics Summit, Orlando, Florida, 20–22 March, 2023.
- 5 次浏览
【数据架构】数据网格与 Data Fabric：了解差异
在为组织当前和未来的需求构建最佳数据架构的过程中，您有很多选择。由于软件的可邮寄性，这些选项几乎是无限的。但对您来说幸运的是，某些模式已经出现，可以帮助您处理数据路径，包括数据编织和数据网格。
乍一看，数据编织和数据网格概念听起来非常相似。毕竟，网格通常由一种织物制成，它们都是可延展的物品，可以放在物体上——在这种情况下，您的 IT 系统会受到不断增长的数据挤压。
但这两种方法存在根本差异，因此值得花一些时间来了解它们的差异。
数据编织
Forrester 分析师 Noel Yuhanna 是最早在 200 年代中期定义数据编织的人之一。从概念上讲，大数据编织本质上是一种元数据驱动的方式，用于连接不同的数据工具集合，这些工具以一种凝聚力和自助服务的方式解决大数据项目中的关键痛点。具体来说，Data Fabric 解决方案在数据访问、发现、转换、集成、安全、治理、沿袭和编排等领域提供功能。 Graph 也经常用于链接数据资产和用户。
Momentum 正在构建数据编织概念，作为一种在日益多样化的环境中简化数据访问和管理的方式，包括事务和操作数据存储、数据仓库、数据湖和湖屋。组织正在构建更多的数据孤岛，而不是更少，随着云计算的发展，围绕数据多样化的问题比以往任何时候都大。
- A data fabric consists of multiple data management layers (Image source: Eckerson Group)
借助几乎覆盖在各种数据存储库之上的单一数据编织，组织可以为不同的数据源和下游消费者（包括数据管理员、数据工程师、数据分析师和数据科学家）带来某种统一管理。但需要注意的是，管理是统一的，而不是实际的存储，它仍然是分布式的。
包括 Informatica 和 Talend 在内的一些工具供应商提供包含上述许多功能的实用数据编织，而其他工具供应商（例如 Ataccama 和 Denodo）则提供特定的数据编织部分。 Google Cloud 还通过其新的 Dataplex 产品支持数据编织方法。数据编织中各种组件之间的集成通常通过 API 和通用 JSON 数据格式进行处理。
数据网格
虽然数据网格旨在解决许多与数据编织相同的问题，即在异构数据环境中管理数据的困难，但它以完全不同的方式解决问题。简而言之，虽然数据编织试图在分布式数据之上构建一个单一的虚拟管理层，但数据网格鼓励分布式团队组在他们认为合适的时候管理数据，尽管有一些共同的治理规定。
数据网格概念最初是由 Zhamak Dehghani 写下的，他现在是 Thoughtworks North America 的下一代技术孵化主管。 Dehghani 在她 2019 年 5 月的报告“如何超越单体数据湖到分布式数据网格”中阐述了数据网格的许多原则和概念，随后她在 2020 年 12 月发布了题为“数据网格原则和逻辑架构”的报告。”
正如我们今年早些时候所写的，驱动数据网格的核心原则是纠正数据湖和数据仓库之间的不一致。第一代数据仓库旨在存储大量结构化数据让分析师用于回溯 SQL 分析，而第二代数据湖主要用于存储数据科学家构建预测性机器学习的大量非结构化数据楷模。 Dehghani 写了一个以实时数据流和云服务为标志的第三代系统 (Kappa)，但它并没有解决第一代和第二代系统之间潜在的可用性差距。
许多组织构建和维护复杂的 ETL 数据管道，以尝试保持数据同步。这也推动了对负责维护拜占庭系统工作的“超专业数据工程师”的需求。
Dehghani 对这个问题提出的关键见解是，数据转换不能由工程师硬连线到数据中，而应该是一种过滤器，应用于所有用户都可用的公共数据集。因此，与其构建一组复杂的 ETL 管道来将数据移动和转换到各个社区可以分析的专用存储库，不如以大致原始形式保留数据，并且一系列特定领域的团队将拥有该数据的所有权作为他们将数据塑造成产品。 Dehghani 的分布式数据网格通过具有四个主要特征的新架构解决了这一问题：
- 面向领域的去中心化数据所有权和架构；
- 数据作为产品；
- 作为平台的自助数据基础设施；
- 联合计算治理。
实际上，数据网格方法认识到只有数据湖具有处理当今分析需求的可扩展性，但组织试图强加于数据湖的自上而下的管理方式已经失败。数据网格试图以自下而上的方式重新构想所有权结构，使各个团队能够构建满足自己需求的系统，尽管需要进行一些跨团队治理。
网格 VS 编织
正如我们所看到的，数据网格和数据编织方法之间存在相似之处。但是，也有一些差异需要考虑。
根据 Forrester 的 Yuhanna 的说法，数据网格和数据编织方法之间的主要区别在于 API 的访问方式。
“与 [数据] 编织不同，数据网格基本上是面向开发人员的 API 驱动 [解决方案]，”Yuhanna 说。 “[Data Fabric] 与数据网格相反，您正在为 API 编写代码以进行接口。另一方面，数据编织是低代码、无代码的，这意味着 API 集成发生在结构内部，而不是直接利用它，而不是数据网格。”
（阿格桑德鲁/Shutterstock）
James Serra 是安永 (Earnst and Young) 的数据平台架构负责人，之前是微软的大数据和数据仓库解决方案架构师，这两种方法的区别在于用户访问它们的位置。
“数据编织和数据网格都提供了跨多种技术和平台访问数据的架构，但数据编织以技术为中心，而数据网格则专注于组织变革，”塞拉在 6 月的博客文章中写道。 “[A] 数据网格更多的是关于人和流程，而不是架构，而数据编织是一种架构方法，它以一种可以很好地协同工作的智能方式处理数据和元数据的复杂性。”
根据 Eckerson Group 分析师 David Wells 的说法，您可以同时使用数据网格和数据编织，甚至是数据枢纽
“首先，它们是概念，而不是事物，”Wells 在最近的一篇博客文章“数据架构：复杂（Complex ）与复杂（Complicated.）”中写道。 “作为架构概念的数据枢纽不同于作为数据库的数据中心。其次，它们是组件，而不是替代品。架构同时包含数据编织和数据网格是切实可行的。它们不是相互排斥的。最后，它们是架构框架，而不是架构。在框架根据您的需求、数据、流程和术语进行调整和定制之前，您没有架构。”
数据网格和数据编织都在大数据表中占有一席之地。在寻找支持您的大数据项目的架构概念和架构时，一切都归结为找到最适合您自己的特定需求的方法。
原文：https://www.datanami.com/2021/10/25/data-mesh-vs-data-fabric-understand…
- 59 次浏览
【数据编制架构】什么是数据编织(Data fabric)？ 完整指南
本文探讨了 Data Fabric 的内容、原因、方式和人员，包括 Data Fabric 架构、挑战、优势、核心功能、供应商等。
Data Fabric——以数据为中心的企业的“必备”
在过去几年中，“Data Fabric”一词已成为企业数据集成和管理的代名词。 分析公司 Gartner 将“数据编织”列为“2021 年十大数据和分析技术趋势”之一，并预测到 2024 年，25% 的数据管理供应商将为数据编织提供完整的框架——高于目前的 5%。
本文通过引用数据编织的定义、目的、架构、挑战、最佳实践、优势、供应商以及数据编织功能清单来解决数据编织的内容、原因、方式和对象。
Data Fabric 概述
Data Fabric 使整个企业的数据访问大规模民主化。 它是一个单一的、统一的架构——具有一组集成的技术和服务，旨在在正确的时间、以正确的方法向正确的数据消费者提供集成和丰富的数据——以支持运营和分析工作负载 .
Data Fabric 结合了关键数据管理技术，例如数据目录、数据治理、数据集成、数据管道和数据编排。
Gartner: A data fabric stitches together integrated data from many different sources and delivers it to various data consumers.
第 02 章为什么 Data FabricData Fabric
服务于广泛的业务、技术和组织协调驱动因素。
业务驱动因素
- 通过可靠、快速地将数据输送到数据湖和仓库中来缩短洞察时间并做出更明智的决策。
- 获得实时、360度-任何业务实体（例如客户、索赔、订单、设备或零售店）的视图，以实现微细分、减少客户流失、提醒运营风险或提供个性化的客户服务。
- 将总拥有成本降低到通过以增量和快速的方式对遗留系统进行现代化操作、扩展、维护和更改。
数据管理因素
- 程序数据准备自动化使数据科学家、数据工程师和其他 IT 资源免于执行繁琐的重复数据转换、清理和丰富任务。
- 获得访问任何数据交付方法中的企业数据——包括批量数据移动 (ETL)、数据虚拟化、数据流、更改 d数据捕获和 API。
- 数据编织平台集成并增强了公司当前使用的数据管理工具，并允许其他人退休，以提高成本效益。
组织驱动
- 数据工程师和数据消费者之间共享的通用语言改善了数据和数据之间的协作业务团队。
- 自助服务数据访问功能让数据消费者可以随时随地获取所需数据，从而提高业务敏捷性和速度。
第03章Data Fabric架构
Gartner：理想的、完整的 Data Fabric 设计，包含许多组件。
- 设计良好的 Data Fabric 架构是模块化的，支持大规模、分布式多云、内部部署和混合部署。
- 如上图所示，当数据从源头提供给消费者时，它被编目、丰富以提供洞察和建议、准备、交付、编排和设计。
- 数据源的范围从孤立的遗留系统到最现代的云环境。
- 数据编织的数据消费者包括数据科学家和数据分析师（与数据湖合作）、营销分析师（参与客户细分）、销售、营销和数据隐私专家（关注客户细分）、云架构师等.
第 04 章数据网格架构的数据编织
数据网格架构解决了数据管理中的四个关键问题：
- 数据分散在数十个甚至数百个遗留系统和云系统中，因此难以获得单一的事实来源
- 以数据为中心的企业必须处理的数据速度和数量
- 当访问通常需要数据工程时，数据难以获取
- 业务分析师、运营数据消费者、数据工程师和数据科学家之间缺乏沟通。
数据编织非常适合数据网格设计，因为它构建了一个集成的跨广泛数据源的连接数据层，可即时、全面地了解业务，包括分析和运营工作负载。
Data Fabric 建立了不同数据产品的语义定义、数据摄取模式以及保护数据的必要治理策略。
此外，各种业务领域协调额外数据编织节点的部署，使它们能够控制数据管道和服务。
数据网格架构很容易使用数据编织实现。
可以实时管理、准备和交付数据的数据编织创建了理想的数据网格核心。 当然，数据网格架构有其实施挑战，但数据编织很容易处理这些挑战：
|
数据网格实施挑战 |
Data Fabric 如何处理它们 |
|
对数据集成专业知识的要求：跨许多不同企业源系统的数据集成通常需要特定领域的数据管道专业知识。 |
数据即产品：当数据产品是在虚拟数据层中管理的业务实体时，域无需处理底层源系统。 |
|
联合与独立：在对中央数据团队的依赖和域独立之间实现适当的平衡并不简单。 |
企业范围内的协作：特定领域的团队与集中式数据团队协作，为其数据消费者构建 API 和管道，控制和管理访问权限，并监控使用情况。 |
|
批量数据以及实时和批量数据交付：数据产品必须在单一平台上安全高效地提供给离线和在线数据消费者。 |
分析和运营工作负载：Data Fabric 收集和处理来自底层系统的数据，为离线和在线用例按需提供数据产品。 |
第05章Data Fabric核心能力
- 可视化数据沿袭是一项关键技术，因为在使用传统数据建模和集成工具时会丢失关系洞察力。
Data Fabric 支持将以下关键功能集成到单个平台中：
- 数据目录
- 对数据资产进行分类和盘点，可视化呈现信息供应链
- 数据工程
- 为运营和分析用例构建可靠且强大的数据管道
- 数据治理
- 确保质量、遵守隐私法规并使数据可用——安全且大规模
- 数据准备和编排
- 定义从源到目标的数据流，包括数据清理、转换、屏蔽、扩充和验证的步骤序列
- 数据集成和交付
- 从任何来源检索数据并将其交付给任何目标，采用任何方法：ETL（批量）、消息传递、CDC、虚拟化和 APIs
- 数据持久层
- 为了在广泛的关系和非关系模型中动态持久化
数据数据编织还应该解决以下关键的非功能性能力：
数据规模、数量和性能
无论数据量有多大，都可以无缝地动态向上和向下扩展。支持企业级的运营和分析工作负载。
可访问性
支持所有数据访问模式、数据源和数据类型，并集成静态或动态的主数据和事务数据。从内部部署和云系统中以任何格式（结构化或非结构化）摄取和统一数据。数据结构逻辑访问层需要允许数据消费，无论数据存储或分布在何处、如何存储，因此无需深入了解底层数据源。
分发
Data Fabric 应可部署在多云、本地或混合环境中。为了保持事务完整性和数据治理能力，Data Fabric 需要支持智能数据虚拟化策略。
安全
在持久化数据的地方，必须对其进行加密和屏蔽以满足数据隐私法规。数据结构应该能够将用户凭据传递到源系统，以便正确检查和授权访问权限。
第 06 章 用于操作工作负载的Data Fabric vs Data Lakes vs Databases
为了解释 Data Fabric 如何补充和改进运营工作负载的大数据存储，Data Fabric、Data Lakes 和 Databases 之间的比较很有用。
下图总结了每种数据存储的优缺点，因为它涉及大规模、大容量、可操作的用例。
|
|
优点 |
缺点 | |
|
数据仓库, DWH |
|
|
|
|
关系型数据库 |
|
|
|
|
NoSQL Database |
|
|
|
|
Data 编制 |
完整的 SQL 支持
|
因此，虽然 Data Fabric 是针对大规模运营工作负载的卓越解决方案，但它也是用于离线分析工作负载的数据湖和数据库的互惠技术。对于此类工作负载，Data Fabric 可以：将新的、受信任的数据输送到其中，用于离线分析。从它们那里获得业务洞察力，以嵌入到实时运营用例中。
第07章数据编织用例
在企业运营中，有许多用例需要能够支持数千个并发事务的大规模、高速数据架构。示例包括：
提供 360 度客户视图
向自助 IVR、客户服务代理 (CRM)、客户自助服务门户（Web 或移动）、聊天服务机器人和现场服务技术人员提供客户的单一视图
遵守数据隐私法
借助灵活的工作流程和数据自动化解决方案，协调人员、系统和数据的合规性——旨在解决当前和未来的法规
将企业数据输送到数据湖和仓库
使数据工程师能够快速、大规模地准备和交付新的、可信的数据——从所有来源到所有目标——
按需提供测试数据
创建测试数据仓库，并在几分钟内自动向测试人员和 CI/CD 管道交付匿名测试数据，并具有完整的数据完整性
现代化遗留系统
安全地将数据从遗留系统迁移到数据编织中，然后将结构用作新开发应用程序的记录数据库
保护信用卡交易
通过加密和标记原始数据来保护敏感的持卡人信息，以避免数据泄露
预测客户流失、检测客户欺诈、信用评分等
许多操作用例要求 Data Fabric 在瞬间响应复杂的查询。
因此，Data Fabric 必须包括用于处理的内置机制：
实时数据摄取
从操作系统持续更新（每天有数百万到数十亿次更新）
连接到不同的系统
TB 级的数据分布在数十个海量数据库/表中，通常采用不同的技术
动态数据转换、数据清理和数据丰富
实时提供有意义的见解并影响业务成果
实体的特定实例
例如，检索特定客户、位置、设备等的完整数据。
高并发
每秒处理数千个请求
CHAPTER 08 Data Fabric 优势
Data Fabric 与其他数据管理方法（例如主数据管理、数据中心和数据湖）相比具有许多优势，包括：
增强的数据管理
允许自动检索、验证和丰富数据——无需任何转换脚本或第三方工具
扩展数据服务
使用创新引擎来管理和同步数据，完全支持 SQL 和嵌入式 Web 服务层
高一致性、持久性和可用性
符合企业标准，具有值得信赖的数据库层和处理引擎
卓越的性能
依靠能够在少量数据上运行每个查询的架构，以及内存中的处理
严格的安全性
由于采用了复杂的多密钥加密引擎，消除了大规模数据泄露的可能性
CHAPTER 09Data Fabric 好处
Data Fabric 为企业提供的运营优势包括：
简化数据编排
集成外部数据库、业务逻辑、屏蔽、解析和流式处理的算子
自动化测试数据管理
从生产系统生成数据，然后向测试团队提供高质量的测试数据
快速的数据隐私合规性
配置、管理和审计与 GDPR、CCPA、LGPD 等数据隐私法规相关的数据主体访问请求。
全面的数据管理
使用管理管理工具、直观的可视化工作室和 Web 管理工具配置、监控和管理数据
优化拥有成本
依靠商用硬件上的内存性能、完整的线性可扩展性和无风险集成
第 10 章 Data Fabric 供应商
有多家供应商提供一组集成的功能来支持 Data Fabric 架构。排名前 5 位的 Data Fabric 供应商如下所示：
| Strengths | Concerns | ||
| K2View |
|
|
|
| Denodo |
|
|
|
| Talend |
|
|
|
| Informatica |
|
|
|
| IBM Cloud Pak for Data |
|
|
第 11 章用于分析和运营的数据编
织通常认为，数据编织的构建是为了支持大数据分析——特别是趋势分析、预测分析、机器学习和商业智能——由数据科学家在离线模式下执行，以产生业务洞察力。
但数据编织对于依赖准确、完整和新鲜数据的运营用例（例如客户流失预测、信用评分、数据隐私合规、欺诈检测、实时数据治理和 360 度客户视图）同样重要。
数据团队不希望有一种数据编织解决方案用于数据分析，另一种用于运营智能。他们希望两者都有一个单一的数据编织。
理想的数据编织优化了每个业务实体（客户、产品、订单等）的视野和理解深度。它为企业提供干净、新鲜的离线数据分析数据，并为在线运营分析提供实时、可操作的数据。
Data Fabric 同时支持离线数据分析和在线运营智能。
具体方法如下：
- Data Fabric 基于业务实体的 360 度视图持续提供高质量数据，例如特定客户群、公司产品线或特定地理位置的所有零售店 - 到数据湖或 DWH。
- 使用这些数据，数据科学家创建和改进机器学习 (ML) 模型，而数据分析师使用商业智能 (BI) 来分析趋势、细分客户并执行根本原因分析 (RCA)。
- 改进的 ML 模型被部署到数据编织，为单个实体（客户、产品、位置等）实时执行——从而“操作”机器学习算法。数据编织实时按需执行 ML 模型，为其提供单个实体的完整和当前数据。
- ML 输出会立即返回到请求的应用程序，并作为实体的一部分保存在数据编织中，以供将来分析。 Data Fabric 还可以调用实时推荐引擎来提供下一个最佳操作。
第 12 章为什么 K2View
K2View 是唯一能够实时、大规模响应以实体为中心的数据查询并支持运营和分析工作负载的数据编织。
以下是 K2View 成为世界上一些最大企业的首选数据编织的 5 个原因：
适用于每个业务实体的微型数据库
K2View 的专利 Micro-Database™ 提供无与伦比的性能、易于访问、数据完整性和通用语言在业务和 IT 之间。K2View Data Fabric 将来自所有底层源系统的每个业务实体的数据统一到一个单一的微数据库中，一个业务实体的每个实例。
例如，客户微数据库统一了公司对特定客户的了解——包括所有交互（电子邮件、电话、网站门户访问、聊天……）、交易（订单、发票、付款……）和主数据——无论底层源系统、技术和数据格式如何。在这种情况下，为每个客户管理一个微型数据库。
微型数据库可以通过捕获或动态计算的新字段来丰富——例如 KPI、同意信息、流失倾向等。它可以很容易地定义，使用自动发现，从底层系统中提取建议的数据模式。
微型数据库代表企业对特定业务实体的了解。
为了最大限度地提高性能：
- 数据同步规则定义了微型数据库中每个数据元素从源系统更新的频率和事件。
- 数据虚拟化规则定义了哪些数据会被持久化在micro-DB中，并且只会缓存在内存中。
- 每个micro-DB被压缩了大约90%，从而降低了数据传输成本。
每个micro-DB都用自己的唯一密钥加密，这样每个实体都是唯一安全的。这为静态数据保持最高级别的安全性。
K2View Data Fabric 可以扩展以同时管理数亿个安全微型数据库，并部署在分布式内部、云端或混合架构中。
数据从任何来源、任何目标、在任何风格
K2View 开发了一种可操作的数据编织，可以从任何来源以任何数据交付方式摄取数据，然后在几毫秒内将其转换为交付到任何目标。
微服务向消费应用程序提供任何业务实体的单一视图
K2View Data Fabric 提供用于创建和调试微服务的低代码/无代码框架。使用可视化的拖放式构建器，可以快速定制和编排微服务以支持任何操作用例。这种方法有助于将数据视为产品并支持网格架构。
需要访问微服务的用户或令牌被分配一个角色，该角色定义了他们拥有的数据访问级别。部署微服务后，K2View Data Fabric 会控制身份验证和授权，从而适当限制用户访问。
一个平台，许多用例
K2View 平台是一个中央数据中心，可提供任何业务实体的实时、可信和整体视图到任何消费应用程序、数据湖或数据仓库。因此，数据编织的用例很多，并且跨越企业的许多部门。
综上所述，该平台提供：
模块化、开放、可扩展的架构
数据集成、转换、丰富、准备和交付——集成在一个可扩展的平台
中秒速、端到端、响应时间
企业数据编织，专为支持实时运营而构建，可在源和目标之间进行双向数据移动
运营和分析工作负载的数据管理
集成的可信数据，实时交付到消费应用程序中，或管道传输到数据湖和数据仓库中以进行分析
- 237 次浏览
【数据编织】数据编织：它能证明你的架构的未来性、统一你的数据并节省成本吗？
什么是数据编织？
数据编织是一种技术不可知、基于网络、以自动化为重点的数据架构和设计模式，其核心是为您提供一致可靠的数据处理方式。数据编织背后的核心思想是模拟将各种数据资源编织到一个将所有数据资源结合在一起的结构中。
本文将带您了解数据编织背后的基本思想，数据编织解决的核心问题，以及使用数据编织如何帮助您的业务。
目录
- 什么是数据编织？
- 为什么选择数据编织？
- 数据编织架构和原理
- 数据编织备选方案
- 数据编织：我们学到了什么？
- 数据编织：相关读取
为什么选择数据编织？
数据编织节省了数据处理和移动成本，同时使您的架构经得起未来考验，可以添加更多的数据源和孤立的数据。
在过去几年中，各种数据技术、基于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?
- 3 次浏览
【数据编织架构】数据编织架构的前6个用例
企业数据编织作为确保分布式环境中访问和数据共享的一种方式，其采用率一直在上升。以下是数据编织的主要用例。
企业正在转向数据编织架构，以提供其数据的整体视图。关于如何做到这一点，人们有不同的看法，但从本质上讲，每个人似乎都同意，它超越了数据湖、数据目录和数据虚拟化，提供了一个更一致的集成层。
Gartner将数据编织架构列为2019年十大趋势之一，因为它能够在分布式数据环境中实现无缝访问和数据共享。
区块链数据管理平台Fluree的联合首席执行官兼联合创始人Brian Platz表示：“数据编织是一种收集和连接企业数据的综合方法，强调管理、分发和保护数据的独特性。”。
数据编织架构为最大化分布在数据竖井中的信息的价值向前迈出了一步。它还提供了一个目标，组织可以调整该目标，以便在其他复杂的分布式网络环境中提供精简和安全的数据访问。
数据编织优势
数据编织架构有望解决新的隐私法规和安全漏洞事件的增加所带来的许多安全和治理问题。
Cloudera产品营销总监Wim Stoop表示：“到目前为止，数据编织对组织最大的积极影响是将企业范围的数据安全和治理作为部署的一部分，将其确立为一个基本的、持续的过程。”。
数据治理通常是孤立的，与用例联系在一起，比如孤立地解决法规遵从性需求或部门需求。有了数据编织，组织就需要后退一步，全面考虑数据管理。
这提供了对数据和分析的自助访问，企业需要进行实验并快速从数据中推动价值。这种程度的数据管理、治理和安全性也使证明合规性——包括行业和监管——或多或少成为实现结构本身的副作用。尽管这不是一个完整的解决方案，但它大大减少了与遵守法规遵从性要求相关的工作量。
数据编织挑战
普拉茨提醒说，完美数据编织的愿景与当今的实际情况之间存在巨大差距。
Platz说：“在实践中，许多数据编织架构的第一个版本看起来更像是另一个数据湖。”。
第一次构建数据编织的人没有考虑到固有的数据互操作性的需求。不同的系统将以不同的方式格式化数据。不符合全局企业模式的数据本质上不会使用相同的语言。这种本机互操作性的缺乏将增加数据利益相关者实现价值的时间摩擦，并引入对数据进行协调、重复数据消除和清理的需求。
组织需要能够了解其数据消耗以及法规和合规需求，以便正确利用其数据编织。
数据备份、归档和恢复服务Grax的首席技术官Morten Bagai表示：“不了解其中一个或全部领域往往会带来挑战或失败点。”。
一旦组织解决了这些问题，他们就可以开始探索新的数据编织用例，例如以下。
1.人工智能数据协作
数据编织架构可以为人工智能工程师提供广泛的综合数据访问权限，以便做出更明智的决策。
Platz说：“因为人工智能需要广泛访问高完整性数据，数据编织可以支持向人工智能应用程序高效传递信息，以便做出快速、知情的决策。”。
他还表示，该架构正被用于增强人工智能应用程序的交付，以检测欺诈并建立更快的预测分析模型。例如，预测性维护需要对数据编织提供的实时数据进行精简访问。
2.加强安全
云管理平台CloudCheckr的运营副总裁Rajiv Kanauja表示，数据编织还可以通过将来自物理和IT系统的数据和应用程序捆绑在一起来改善安全应用程序。
例如，一个团队可以通过将用于开门的钥匙读取器的信息捆绑在一起来提高安全性，这些信息可以与从设施内访问的计算机系统的事件数据相关联。这将有可能对典型和异常行为进行更复杂的分析，以便在需要时触发实时安全警报。
3.创建全面的客户视图
Kanaujia说，组织还可以使用数据编织架构将客户活动的数据以及与客户互动的各种角色编织在一起，以获得更全面的视图。这可以包含各种销售活动、潜在收入实现、客户入职时间和客户满意度指标的实时数据。
例如，这可能从捕捉到的有关客户在亚马逊上使用SaaS服务的CloudTrail日志开始，合并来自客户支持请求的数据，并与新的销售活动进行协调。数据编织可以在这些不同的数据源之间进行关联，以推动更好的分析并提供有用的建议。
4.提高业务理解
企业还可以使用数据编织来创建跨活动和部门的更全面的业务视图。
Bagai说：“数据编织对于理解一个企业随着时间的推移所发生的任何变化至关重要。”。
他说，将数据编织视为整个企业异常、拐点和业务结果的拓扑图是很有用的。这使其成为机器学习和人工智能理解业务的完美培训和测试集。这也可以使实现流程挖掘项目变得更容易，这些项目可以理解跨多个应用程序的业务流程。
Bagai说：“我们对人工智能和（机器学习）最大的失望实际上源于这样一个事实，即我们经常没有将完整的数据编织输入到我们的训练集中。”。
5.简化预测和触发的行动
数据编织还可以用于训练、配置和部署简单的预测算法，并触发跨各种企业应用程序端点运行的操作。这些类型的用例涵盖了从安全可追溯性到审计合规性和创收事件的方方面面，如放弃购物车行动、广告优化、客户保留、营销，甚至是精心策划的销售。
Bagai表示：“数据编织将改变企业从过去学习并随着时间的推移而发展的基本方式。”。
6.创建数据市场
实现数据编织架构的企业还可以建立一个更容易访问的数据市场，使公民开发人员更容易将不同的数据源编织到新的模型中。数据市场允许数据工程师建立一个可以跨多个用例使用的基础设施，而不是为每个用例单独创建新的基础设施。
Stoop说：“数据市场不是实施特定于业务用例的数据存储或湖泊来应对客户流失、预测性维护或欺诈预防等挑战，而是解决整个企业的数据需求，并解决当前和未来的数据需求。”。
- 3 次浏览
【数据网格】数据管理架构-单片数据架构-与分布式数据网格
这篇文章是软件工程师、数据工程师、数据科学家、MLOps工程师、软件开发人员和数据库架构师的必读书目，他们有兴趣了解有关整体数据架构和分布式数据网格的更多信息。
介绍
数据管理架构-控制组织如何收集、存储、保护、安排、集成和使用数据。一个好的数据管理架构-可以清晰地了解数据的各个方面，以及企业如何充分利用数据实现业务增长和盈利。相反，糟糕的数据管理架构会导致不一致的数据集、不兼容的数据仓库和数据质量问题，使数据变得毫无价值或影响组织运行分析、数据仓库（DW）和商业智能（BI）活动的能力，尤其是大数据。
传统上，大多数组织倾向于从一个中央数据团队和一个单一的数据管理架构开始，在该架构中，所有数据操作都在一个单一、集中的数据平台上进行。虽然单片数据架构相对容易设置，可以处理小规模的数据分析和存储而不会降低性能，但随着时间的推移，情况会变得越来越糟。此外，随着数据量和需求的增加，中央数据管理团队往往成为瓶颈。
由Zhamak Dehghani介绍，分布式数据网格提供了一种协调并希望解决与以前的数据架构相关的挑战的方法，这些挑战通常会受到数据消费者和生产者之间的数据标准化挑战的阻碍。分布式数据网格推动我们走向更强大、更敏捷、更精简、多功能的团队和领域驱动的业务结构。它以分散的方式结合了最佳的数据管理方法，同时维护数据即产品的观点、自助服务用户访问、域意识和治理。
这篇文章将帮助读者了解整体数据架构、与整体数据架构相关的挑战，以及分布式数据网格如何帮助组织将其分析数据转化为产品，并构建高度可扩展、弹性和数据驱动的应用程序。目标受众是软件工程师、数据工程师、数据科学家、MLOps工程师、软件开发人员和数据库架构师，他们对整体数据架构和分布式数据网格感兴趣。
单片数据结构
单片数据架构-是一个框架，应用程序数据从一个集中的数据存储库中存储、转换、操作、消费和管理e.t.c。单片数据架构由一个庞大的平台团队管理，适用于业务领域相对简单且数据环境不不断变化的小型组织，但它们对不断发展的工程团队提出了若干挑战。让我们来看看其中的一些挑战。
第一个问题是单片数据架构不能无限扩展，大多数单片数据库根本无法自动扩展。随着应用程序工作量和数据量呈指数级增长，单一数据库逐渐变得缓慢、昂贵和难以维护。由一个中央团队管理的在一个地方使用和协调无处不在的数据的能力也会降低，因为组织的用例、多个数据源和数据消费者都在快速而广泛地变化。
其次，单片数据库通常具有高延迟和吞吐量，这自然是由应用程序中不同的断开连接的团队和方法并发的数据库读/写引起的。对于单片数据架构，在不改变整个数据管道的情况下响应新需求也是一项挑战。
第三，单片数据架构缺乏模块化，并且受到技术同质化的影响。当单个数据库出现故障或无响应时，它会影响整个应用程序并停止所有与数据库相关的活动。此外，如果工程团队被迫为一个应用程序采用一个数据库，那么创新和实验的空间就不大了。
最终，一个单一的数据架构自然会导致住院数据消费者、断开连接的数据生产者和积压的工程团队，他们背负着沉重的技术债务，在一个变化动态、企业需要快速创新的敏捷世界中努力奋斗。
现在您了解了单片数据架构的含义和局限性。现在我们来看一个更优化的数据架构，它主要解决与单片架构相关的挑战。
分布式数据网格
分布式数据网格高度分散，将数据视为产品，并支持分布式“特定领域数据所有者”，负责以易于消费、用户友好的方式处理自己的数据产品和管道，同时增强不同位置分布式数据之间的通信。在许多方面，分布式数据网格是微服务的平台版本。
工程团队可以通过将整个数据架构分解为更小、面向领域和更分散的组件，并让不同的团队管理每个领域，从而轻松实现分布式数据网格的可扩展性。这样，随着用例数量、数据源和访问模型的多样性的增加，可以更容易地进行扩展。它还允许团队构建高度可扩展的数据驱动应用程序，并有效地使用数据来更好地改进营销活动、降低成本、优化业务运营和做出更明智的决策。
分布式数据网格为数据所有者提供了更大的灵活性、更高的生产力和自主权。通过向最接近数据的人分配和分散责任，分布式数据网格降低了每个数据库的读/写速率，促进了数据创新，并消除了工程团队使用单个数据管道或数据存储满足每个数据消费者需求的负担。在分布式数据网格中，每个团队可以自由决定如何收集、组织、存储和使用数据。
第三，分布式数据网格具有自助式“基础架构即平台”和“联合计算治理”设计，可实现域自治，并为数据产品监控和治理、数据标准化、日志记录、警报、产品质量度量等提供不可知域、互操作和通用的方法。在分布式数据网格中，数据库故障的影响大大降低，每个团队都可以在不改变其他数据存储的情况下更改其数据平台、引入新功能和部署功能更新。
何时从单片数据网格过渡到分散数据网格
分布式数据网格不是适合所有组织和团队的灵丹妙药。正如您可以想象的那样，单片数据架构也不会消失。在从单一数据架构-过渡到分布式数架构-之前，组织需要做好功课，确保迁移对业务来说是明智的决定。
以下是组织及其团队在评估向分散数据网格过渡的准备情况时应提出的一些问题：
- 数据团队规模：数据团队中有多少数据工程师、数据分析师、数据科学家和产品经理？
- 数据大小：我们的数据量有多大？它的增长速度是多少？
- 数据种类和来源：我们有多少数据用例和来源？
- 数据瓶颈：数据团队多长时间忙于解决技术债务（从而减缓新数据产品的实施并将其变成瓶颈）？
- 交付周期：尽管我们的团队规模在增长，但每个团队的成员是否都不联系，或者他们是否缺乏领域知识？
- 数据域的数量：有多少职能团队依赖我们的数据存储做出决策，我们有多少数据驱动的产品和功能？
- 数据治理：我们的组织对数据治理有多大偏好？是否存在关于谁控制的政治内讧
通过提出这些问题并评估响应，组织可以决定是坚持传统的整体架构还是改用分散架构。总的来说，拥有基于微服务的应用程序、非常苛刻和复杂的数据基础设施要求、高数据量、众多数据源和域以及经常不堪重负的大型团队规模的公司将从数据网格中获益更多。否则，我认为去中心化的解决方案将是过度的。
结论
组织需要采用一种新的方法来大规模管理数据，以利用数据增强和改善生活和业务的各个方面。尽管过去的技术进步解决了数据量和数据处理计算的规模，但它们无法解决其他方面的规模问题，例如数据源的扩散、数据环境的变化、对变化的响应速度以及数据用户和用例的多样性。
数据网格架构解决了这些维度，并推动了组织结构和技术架构的新逻辑视图。正确实施的数据网格弥补了IT和业务领导者之间的差距，为他们提供了一个平台，以确保业务战略和技术协调一致，推动业务向前发展。通过从单一数据架构转向分布式数据网格，组织和工程团队可以从根本上缩短交付周期，更好地将数据用于多个用例，并构建可扩展的、数据驱动的应用程序，使其与当前向云原生架构和生态系统的转变保持一致。
- 5 次浏览
【数据网格】数据网格与数据编织：如何选择最适合您业务需求的方法？
数据网格强调数据去中心化、自主化和产品化。相比之下，数据编织架构提倡集中化和统一的数据访问。
微软的行业顾问兼数据与人工智能解决方案架构师James Serra表示，数据编织以技术为中心，而数据网格则专注于组织变革。
两者都是实现数据和见解民主化的宝贵方法，但它们在基本哲学和架构上有所不同。让我们了解这两种方法，然后探讨它们的差异。
目录
- 数据网格和数据编织：基础
- 实施这些方法的主要好处
- 您的组织每种方法的优点和缺点
- 需要考虑的五个因素
- 数据网格与数据编织：在数据治理和安全方面，每种方法的表现如何？
- 在数据质量方面，每种方法的表现如何？
- 为您的组织选择最佳方法
- 如何进行数据成熟度调查，为您选择最佳方法
- 关于数据网格与数据编织的结论
- 数据网格与数据编织：相关读取
数据网格和数据编织：基础
数据网格是一个更多关于人员和流程的设计概念，而数据编织是一种解决数据和元数据复杂性的架构。让我们进一步探讨这些方法。
数据网格是Zhamak Dehghani提出的一种新方法，提倡去中心化的数据架构。
数据网格表明，每个业务领域都负责托管、准备数据，并将其数据提供给自己的领域和更大的受众。这使得灵活和自主的数据团队能够构建和管理自己的数据产品，促进数据所有权和问责制。
Gartner称之为一种解决方案体系编织，用于构建以业务为中心的数据产品这一特定目标。
数据编织是一种集中式的数据体系编织方法。Gartner称之为一种设计概念，它是数据和连接过程的集成层（编织）。
数据编织主张建立一个统一的数据层，为数据提供单一的真实性来源。这确保了数据质量、一致性和安全性，同时允许不同的团队轻松访问和管理数据。
需要注意的是，数据编织不同于数据仓库或数据湖。以下是James Serra的说法：
数据编织扩展了数据仓库的体系编织。数据编织包括构建块，如数据管道、数据访问、数据湖、数据存储、数据策略、摄取框架和数据可视化
实施这些方法的主要好处是什么？
数据网格和数据编织都为希望提高数据管理和分析能力的组织提供了独特的优势。
以下是实施每种方法的主要好处：
数据网格的优势
数据网格实现了数据所有权和治理的去中心化方法，从而提高了数据处理的灵活性和可扩展性。
数据网格的好处包括：
- 领域所有权
- 去中心化和可扩展性
- 创新和敏捷
- 跨职能协作
- 量身定制的数据质量
让我们进一步探索每一个好处。
领域所有权
数据网格允许域团队获得所有权并管理其数据产品。这可以更好地满足特定领域的需求，并提高对不断变化的需求的响应能力。
去中心化和可扩展性
数据网格的去中心化性质使组织能够更有效地扩展其数据管理工作。这是通过在域团队之间分配责任来实现的，避免了瓶颈和单点故障。
创新和敏捷
数据网格通过赋予领域团队对其数据产品的自主权来促进创新。因此，团队可以试验最适合其领域需求的新技术和方法。
跨职能协作
数据网格通过鼓励数据共享和数据产品API的标准化来促进跨功能协作和沟通。这可以改善整个组织的数据驱动决策。
量身定制的数据质量
数据网格使领域团队能够实施特定于其领域需求的数据质量度量。这确保了数据产品能够满足消费者的需求。
点击此处了解有关数据网格的更多信息。
数据编织的优势
数据编织支持一种集中式的数据架构方法，该方法具有单一的数据真实性来源。这确保了数据质量、一致性和安全性，同时允许不同的团队轻松访问和管理数据。
数据编织的好处包括：
- 集中式数据管理
- 标准化和一致性
- 优化的分析和报告
- 数据沿袭和透明度
- 简化的数据基础架构
让我们进一步探索每一个好处。
集中式数据管理
数据编织提供了一个统一的数据平台，简化了跨组织的数据集成、存储、处理和访问。这提高了整体数据的可见性和一致性。
标准化和一致性
数据编织使组织能够通过集中化数据管理来实施一致的数据治理、安全和质量策略。这样可以确保数据符合既定标准。
优化的分析和报告
数据编织为分析和报告提供了一个集中的平台。这使得用户更容易访问和分析来自多个来源的数据，减少了生成见解所需的时间和精力。
数据沿袭和透明度
数据编织促进了数据沿袭和透明度，允许用户跟踪数据的来源和转换。这建立了对数据的信任，并有助于更好的决策。
简化的数据基础架构
数据编织可以通过抽象集成不同数据源和技术的复杂性来帮助组织简化其数据基础设施。这使得用户更容易访问和处理数据。
点击此处了解有关数据编织的更多信息。
数据网格与数据编织：每种方法对您的组织的利弊
数据网格和数据编织都可以提供各种好处，但也有一些潜在的缺点。
数据网格的去中心化性质使组织能够通过跨领域团队分配职责来更有效地扩展其数据管理工作。
如上所述，这将提高对不断变化的需求的响应能力、更好的可扩展性和灵活性。它还可以确保没有瓶颈和单点故障。
然而，它也可能导致数据实践不一致、协调和协作挑战、复杂性增加以及对标准化的依赖。
同时，数据编织集中了数据管理，简化了整个组织的数据集成、存储、处理和访问。它实现了一致的数据治理、安全和质量政策，并简化了分析和报告。您还可以优化资源利用率，减少冗余的数据存储和处理任务。
然而，集中式可能会导致潜在的瓶颈、对特定领域需求的响应速度较慢、对集中式团队的依赖以及可扩展性挑战。
集中式数据管理也可能限制创新和实验，因为团队可能没有自主探索最适合其领域需求的新技术和方法。
数据网格与数据编织：需要考虑的五个因素
要在数据网格和数据编织之间做出决定，应考虑以下五个因素：
- 组织编织和文化
- 复杂性和规模
- 技术成熟度
- 数据治理和安全
- 实施速度和资源可用性
让我们看看这些因素中的每一个是如何应用于数据网格和数据编织的。
组织编织和文化
- 数据网格：团队拥有并管理他们的数据产品。这适用于具有跨职能协作和自主性的组织。
- 数据编织：您可以在整个组织中建立一个统一的数据层。这适用于集中式IT和数据管理编织。
复杂性和规模
- 数据网格：它非常适合复杂、大规模的数据生态系统，其中多个领域团队必须独立工作并共享数据产品。
- 数据编织：它非常适合那些想要统一数据平台的组织，并且无论规模和复杂性如何，都可以从单一的真相来源中受益。
技术成熟度
- 数据网格：它需要高度的技术成熟度，因为它取决于领域团队是否具备独立管理其数据产品的必要技能。
- 数据编织：它专注于构建一个无缝统一的数据平台，对于数据工程团队不太成熟的组织来说，这可能更容易管理。
数据治理和安全
- 数据网格：它通过域团队的所有权和问责制来促进数据治理和安全。然而，这对于跨多个团队执行可能具有挑战性。
- 数据编织：它集中了数据治理和安全性，使在整个组织中实施策略变得更容易。
实施速度和资源可用性
- 数据网格：它可能需要更长的时间来实现，因为它需要为每个域团队建立数据产品所有权和基础设施。
- 数据编织：如果有一个强大的集中式数据工程团队，可以更快地实现。
数据网格与数据编织：在数据治理和安全方面，每种方法的表现如何？
虽然这两种方法都可以解决数据安全和治理问题，但它们以不同的方式实现。
数据网格依赖于领域团队掌握其数据产品的所有权，并遵守组织范围的标准。同时，数据编织集中了安全和治理实践，简化了这些标准的实施和执行。
让我们进一步探讨数据网格与数据编织之间的差异。
数据网格和数据治理实践
数据网格促进了数据管理的去中心化方法，领域团队负责其数据产品的安全。这可以导致针对每个领域的需求量身定制的安全措施。
然而，它也需要团队之间的高度协作和协调，以保持一致的安全实践。
数据治理是通过领域团队的所有权和问责制来实施的。每个团队都对其数据产品的质量、沿袭和元数据负责，确保数据有据可查，并符合组织的数据标准。
因此，网格方法中数据治理的一个潜在挑战是在不同的域团队中保持一致的治理实践。这需要强有力的协作和沟通，以及为所有领域建立全组织的数据治理标准。
数据编织和数据治理实践
数据编织集中了数据管理，这可以更容易地在整个组织中实施一致的安全做法。统一的数据层允许实施标准的安全措施，如加密、访问控制和审计，从而减少安全实践中不一致的可能性。
数据编织还集中了数据治理，使实施和实施组织范围的数据治理策略更加简单。统一的数据平台可以促进一致的数据质量、沿袭和元数据管理，确保所有数据都符合既定标准。
虽然这种方法可以更容易地维护数据治理的一致性，但它需要一个强大的、集中的数据工程团队来有效地管理和实施治理策略。
数据网格与数据编织：在数据质量方面，每种方法的表现如何？
数据网格和数据编织都可以解决数据质量挑战，但它们采用不同的策略。
数据网格强调领域自主权和量身定制的数据质量措施，促进问责制，并鼓励团队在其特定领域内优先考虑数据质量。
同时，数据编织侧重于集中的数据质量监控。这样做可以更好地控制和管理数据质量，因为它是在一个集中的位置进行管理的。
让我们进一步探讨数据网格与数据编织之间的差异。
数据网格和数据质量
数据网格允许域团队实现与其特定数据类型和用例最相关的数据质量度量。这导致了量身定制的数据质量流程，以满足独特的领域需求。
此外，将数据视为一种产品会激励领域团队维护满足消费者需求的高质量数据。
然而，像数据网格这样的去中心化方法可能会导致不同团队的数据质量实践不一致，这可能会影响组织内的整体数据质量。
数据编织和数据质量
数据编织通过统一的数据平台集中化数据管理，从而能够实施全组织的数据质量政策，并减少数据质量实践中不一致的可能性。
然而，集中式方法可能会造成瓶颈或单点故障，从而影响数据可用性和性能，尤其是在组织发展的过程中。
选择最佳方法需要仔细权衡利弊，以及组织的编织、文化、数据质量要求、预期的团队成长和未来的数据需求。
数据网格与数据编织：为您的组织选择最佳方法
要在数据网格和数据编织之间做出最佳决策，您应该：
- 评估组织的编织、文化、技术成熟度和资源
- 运行数据成熟度调查
- 考虑在较小的范围内对每种方法进行试点项目，以评估其是否适合您的组织
最终，数据网格和数据编织之间的选择将取决于哪种方法最符合您组织的目标、资源和战略方向。
数据网格与数据编织：如何运行数据成熟度调查，为您选择最佳方法
数据成熟度调查可以帮助您了解组织内数据管理的当前状态，并指导您在数据网格和数据编织之间进行选择。
调查可以分为两部分：一部分针对组织中的数据领导者，另一部分针对使用数据提取见解的业务用户。
为组织中的数据领导者和其他决策者提供的数据成熟度调查参数
针对数据领导者和决策者的数据成熟度调查应涵盖以下问题：
- 数据战略和愿景
- 组织编织和文化
- 数据治理和安全
- 持续改进和创新
让我们看看具体的问题。
数据战略和愿景：
- 您的组织是否有明确的数据战略和愿景？
- 数据相关目标与整体业务目标的一致性如何？
- 是否有高管对数据举措的支持？
组织编织和文化：
- 公司内部的数据管理职能是如何组织的？它是集中式的、去中心化的还是混合式的？
- 您如何描述不同团队之间在数据共享和使用方面的协作水平？
- 整个组织是否存在数据驱动决策的文化？
数据治理和安全：
- 是否制定了数据治理政策和流程？
- 组织内部对数据质量和数据沿袭的管理情况如何？
- 数据安全和隐私做法是否得到完善和遵守？
持续改进和创新：
- 数据管理和分析实践中是否存在持续改进的文化？
- 是否制定了识别新的数据驱动机会和创新并采取行动的流程？
- 组织在多大程度上适应了数据环境的变化，例如新兴技术和不断变化的法规要求？
这些问题将帮助您评估组织在各个方面的数据成熟度。
根据结果，您可以确定哪种方法（数据网格或数据编织）更适合您的组织的需求和能力。
组织中业务用户的数据成熟度调查参数
在调查需要数据和见解的业务用户时，您应该关注他们在当前数据环境中的需求和痛点。
调查的参数可以如下：
- 数据可访问性和民主化
- 数据质量和信任
- 数据相关性和及时性
- 分析和报告
- 协作和数据共享
- 数据素养和培训
- 支持和沟通
- 工具和自助服务
让我们看看具体的问题。
数据可访问性和民主化：
- 您访问工作所需的数据有多容易？
- 是否有集中的数据目录或数据平台来发现和访问数据？
- 访问来自不同来源的数据是否存在任何障碍或瓶颈？
数据质量和信任：
- 您对用于日常工作流程的数据的准确性和可靠性有多大信心？
- 您是否遇到过数据质量问题，例如数据不一致或丢失？
- 您是否遇到不同系统之间的数据差异或不一致？
- 是否有适当的流程来确保整个组织的数据质量和一致性？
数据相关性和及时性：
- 您工作所需的数据是否随时可用且最新？
- 您是否在接收影响决策的数据或见解时遇到延迟？
分析和报告：
- 当前的分析和报告工具在多大程度上满足了您的需求？
- 是否有您需要但目前不可用的特定分析或报告功能？
- 从数据中获得的见解的传达和执行效果如何？
- 机器学习和人工智能等先进的分析技术是否被用来推动见解和决策？
协作和数据共享：
- 您与其他团队在数据驱动项目上的合作效率如何？
- 在与组织内的其他团队共享数据和见解方面是否存在任何挑战或障碍？
- 是否有标准化的数据格式和API来促进团队之间的数据共享和集成？
数据素养和培训：
- 你对自己理解和解释工作数据的能力有多大信心？
- 您是否认为有任何与数据相关的技能或培训对您的角色有益？
支持和沟通：
- 您对数据工程和数据科学团队的支持和沟通水平有多满意？
- 您认为在哪些方面可以改进沟通或支持？
工具和自助服务：
- 您对可用于数据访问和分析的工具和平台有多满意？
- 您是否希望实现任何工具或自助服务功能？
通过全面考虑所讨论的参数，您可以从业务用户那里收集有价值的反馈，这可以帮助您确定数据工程工作可能产生最重大影响的领域。
这些信息将帮助您在数据网格和数据编织之间进行选择，并设计一个有效满足最终用户需求的数据平台。
例如，如果数据可访问性是一个主要问题，那么数据网格方法可能更适合，因为它可以促进特定领域的数据所有权和可访问性。如果数据质量和信任是一个驱动因素，那么数据编织方法可能会更好，因为它有助于集中数据治理，从而确保整个组织的一致质量。
通过考虑调查见解，您可以选择一种最符合组织需求并解决业务用户痛点的方法。这最终将带来一个更有效的数据平台，为用户提供相关数据和见解，使他们能够做出数据驱动的决策。
结论
总之，数据网格和数据编织都有明显的优点和缺点，为您的组织选择正确的方法取决于几个因素，包括组织编织和文化、技术成熟度以及数据治理和安全要求。
虽然数据网格方法强调去中心化的数据所有权和治理，但数据编织主张建立一个集中的数据平台，以确保数据质量、一致性和安全性。
为了选择最佳方法，组织应评估其需求和能力，进行数据成熟度调查，并开展试点项目以评估每种方法的适用性。
最终，正确的方法将与您组织的目标、资源和战略方向保持一致，使用户能够获得相关数据和见解，从而做出数据驱动的决策。
数据网格与数据编织：相关读取
- What is Data Mesh: Architecture Examples, Case Studies, The Role of Metadata, and More
- Data Mesh Architecture: Core Principles, Components, and Why You Need It?
- Data Mesh Setup and Implementation - An Ultimate Guide
- Data Mesh Principles: Top 4 Fundamentals and Architecture
- Snowflake Data Mesh: Step-by-Step Setup Guide, with Detailed Notes on Scaling and Maintenance
- Data Mesh and Data Lake: Understanding Use Cases & Reasons to Deploy
- What is Data Fabric: Definition, Components, Benefits & Use Cases
- Data Fabric vs. Data Virtualization: Overview, Comparison, and Differences
- Data Catalog for Data Fabric: 5 Essential Features to Consider
- 9 次浏览