背景
对适应性强的数据管理体系结构的需求从来没有像现在这样迫切。然而，实现这一目标似乎比以往任何时候都更加令人困惑。这个领域充斥着流行词——数据湖、数据湖屋、数据结构、数据网格、数据枢纽、数据即网络。软件供应商很自然地将这些流行语作为他们营销方法的一部分，从架构到市场架构的一种转变。不幸的是，每个供应商对这些术语的定义可能不同，这增加了混乱。下表显示了一些从网络搜索中快速提取的引用。
这些引用说明了各种流行词以及对这些术语的不同看法。每一个术语——数据结构、数据网格、数据湖、数据湖屋、数据枢纽、数据即网络——都为数据架构领域带来了重要的概念。但总的来说，它们并不能为适应性强的数据体系结构开辟一条清晰的道路。在很多方面，它变得不那么清晰了。我需要数据湖还是数据湖屋?数据网格还是数据结构?集成的数据集线器还是作为网络的数据?什么能满足今天的需求?我们将来需要什么?当下一个流行词出现时，我们该怎么办?
一 复杂性和复杂化
复杂性是数据管理不可避免的现实。它本质上是复杂的，但它不需要复杂。让我们明确一下区别。复杂性是事物固有的特性。复杂化是采取或不采取某些行动的结果。记住，复杂化是一个动词。事情之所以复杂，是因为我们把它们复杂化了。我们可以设计体系结构来处理数据管理的复杂性，而不使体系结构变得复杂。
这种建筑设计方法不像我们通常做的那样复杂，从三种不同的角度看待织物、网格、轮毂等。首先，它们是概念，而不是东西。作为架构概念的数据中心不同于作为数据库的数据中心。其次，它们是组成部分，而不是替代品。对于架构来说，同时包含数据结构和数据网格是很实用的。它们不是相互排斥的。最后，它们是架构框架，而不是架构。在根据您的需求、数据、流程和术语对框架进行调整和定制之前，您还没有体系结构。
我写这篇文章的目的是说明前两点，概念和组件以及它们如何在不增加复杂性的情况下帮助管理复杂性。首先，我将介绍一些体系结构框架，然后看看它们如何作为自定义体系结构一起工作的一个例子。
二 数据湖和数据集线器框架
数据湖和数据集线器是用于收集、精炼、存储和共享数据的数据管理方法。湖泊与集线器的最大区别在于对数据的管理和控制程度。数据集线器受到严格控制，以确保数据的质量和可靠性。数据湖通常被治理以管理安全性和遵从性，但较少关注数据的质量控制。
数据集线器和数据湖使用类似的架构模式从数据源收集数据、精炼数据、分析和收集元数据，以及共享数据，以便为报告和分析准备和使用数据。
三 数据结构框架
数据结构是体系结构、技术和服务的组合，旨在简化管理多种不同类型数据、使用多个数据库管理系统和跨各种平台部署的复杂性。它为跨多种技术和部署平台的数据管理提供了一个单一、统一的平台。需要强调这个定义中的一个关键点:数据结构是体系结构、技术和服务的组合。架构本身并不能构成数据结构，但架构是结构的重要组成部分。
数据结构的体系结构框架从数据源开始，支持所有类型的数据和所有内部和外部的数据源。数据采集支持批处理、数据流和更改数据捕获(CDC)。数据存储和精炼支持多个共享数据存储库，包括数据仓库、数据湖、操作数据存储和主/引用数据管理。数据结构中的一类服务支持数据访问，包括查询、虚拟化、抽象和语义层，以及与数据编目、数据治理和数据安全互操作的基于SOA的服务。访问服务为各种数据使用者提供数据。第二类服务支持跨平台的处理编排和数据管道执行。
四 数据网格框架
数据网格与数据结构形成了有趣的对比。当结构试图集中和协调数据管理时，数据网格则倾向于另一个方向，强调去中心化和数据域自治。数据网格的重大转变在于将数据作为一组产品来管理，而不是作为流程和管道的集合来管理。
通过这种转变，每个数据域都可以独立地操作和管理其数据，而不依赖于其他域的实践。数据领域指的是数据所有权和管理的特定域——可能是一个业务功能域(如市场营销或财务)，可能是一个区域名称(如亚太地区)，也可能是一个主题域(如客户数据)，或者它们的任何组合。任何需要收集和管理数据的域都可以自由地这样做。但是每个域都有责任在数据治理约束范围内操作，创建和共享供其他域使用的数据产品，并遵守这些产品的互操作性标准。所有域共享一个用于存储、编目、访问控制和其他基础设施组件的公共数据基础设施。
从架构上讲，数据网格是从企业数据管理向具有企业协作的领域数据管理的转变。这意味着企业数据体系结构让位于多个领域的数据体系结构，企业数据集成被企业数据互操作性所取代。
五 设计一个可适应的数据管理体系结构
这三个框架都有一些理想的特性。数据湖/数据中心体系结构比较熟悉，相对简单，并且与典型的数据工程师的技能非常匹配。数据结构之所以吸引人，是因为它减轻了跨平台数据管理的痛苦，并使用AI/ML来自动化许多数据管理和数据操作任务。数据网格之所以引人注目，是因为它让我们不再为集成而烦恼。
每个框架都有其缺点。数据湖/数据中心是建立在以多种格式多次存储数据的概念之上的——数据的副本，副本的副本，然后……每个人都应该清楚，随着数据量的增长，这种方法无法扩展，也不可持续。数据结构表面上看起来很好，但它非常依赖技术，我们不得不考虑供应商的限制。大多数数据结构工具在跨平台互操作性方面做得很好，但它们不能很好地与其他工具集成。当构造元数据与目录元数据不同步时会有什么后果?数据网呢?这是一个有趣的概念，但也是一个巨大的范式转变。
同样重要的是要意识到我们没有一个人可以有一个全新的开始。我们都有数据仓库、数据湖、数据管道和分析应用需要管理。宣称它们是遗产并不会让它们更易于管理。它们将如何与新的架构、网格或其他现代构造相适应?
所以，好处，坏处，遗产数据管理。哪种现代数据体系结构的方法对您有意义?这是一个艰难的决定，但幸运的是你不必做出选择。记住这些都是框架，它们是概念和组件，而不是体系结构。将它们作为正确的材料来帮助您定义混合数据架构，该架构混合了集成、构造、网格和其他您可能想要引入的概念。下图展示了这种方法的一个示例。
这个示例混合了数据湖、数据结构、数据网格和其他我还没有讨论过的架构概念。在顶部，您可以看到数据湖架构，与数据湖/数据集线器框架非常相似。显著的区别是增加了一个数据服务组件。我选择添加一个服务层来将数据消费与数据存储解耦，并将安全性和治理与数据访问紧密耦合。向下移动图，在左侧，您可以看到数据网格与独立的数据域产生数据产品。我们不再需要将数据集成作为一种通用的数据共享解决方案，我们可以将遗留数据仓库定位为独立的数据域。底部是多个数据平台。数据结构的跨平台自动化和编配能力是解决多平台数据蔓延的最佳方案。
最后，让我们看看适应性。在可预见的未来，新的概念和组件将继续改变数据管理的前景。从头开始不断地重新定义架构是不现实的，但快速修复也不是一种可持续的方法。我们需要能够将新的概念和组件巧妙地融入现有的体系结构中——以不受干扰地适应变化。这里的例子包括数据网络/数据链接，它适用于一种新兴的、高度引人注目的方法，即零拷贝集成。还要注意，作为元数据管理的一部分，数据目录中还添加了知识图。这增加了剑桥语义所提倡的图扩展数据结构的概念。
六 真正有效的数据架构
我在这个例子中所展示的并不是一个完美的架构。这是如何设计真正有效的数据体系结构的一个例子，该体系结构满足当今的数据管理需求，适应与现代体系结构思想不同步的遗留数据系统，并在新思想出现时随时适应变化。数据架构是困难的，但它也可以是有益的。我对从事这项具有挑战性工作的人的建议是:
•不要让复杂导致你陷入复杂。
•不要依赖遗留数据系统，但也不要将它们抛诸脑后。
•不要让对今天需求的狭隘眼光为未来带来技术债务。
•一定要享受这份工作，为自己的工作感到自豪，因为它真的很重要!
