数据与业务运营和各种分析工作负载（BI、数据科学、认知解决方案等）的分离与 IT 系统和业务应用程序一样古老。由于分析工作负载是资源密集型的，因此需要将它们与运行业务运营的 IT 系统分开，以便运营工作负载在没有任何资源限制的情况下平稳运行，从而确保积极的客户体验。
多年来，我们对大数据和业务分析的依赖显着增加，预计到 2030 年其市场规模将达到 6841.2 亿美元。在全球范围内，各行各业都在投资分析其海量数据并制定有效的数据策略。数据架构是如何通过 IT 基础架构支持数据策略的框架。作为数据战略的基础，数据架构在战略的有效实施中起着至关重要的作用。多年来数据架构的演变相应地塑造了数据策略的有效性。
数据模型、架构和存储随着时间的推移而发展，以满足不同的分析工作负载。在本文中，我们将介绍为满足不断增长的分析需求而不断发展的各种数据架构。这些演变中的每一个都值得一本书来描述无法在一篇文章中产生的完整细节。但是，目的是在此处描述它们中的每一个的高级细节，并指出其他可用的文献。让我们开始。
1. ODS、EDW 和数据集市
在早期，运营数据存储（ODS）是为了迎合决策支持系统而开发的，主要针对需要预定义报告的运营用户。ODS只存储当前的数据（通常是6个月），用于运营报告和战术决策，例如银行的出纳员。它决定是否为排队的客户提供透支服务，增加信用额度等。
商业智能工具的出现扩大了分析的用户群，涵盖了那些喜欢用图形表示摘要信息的高级管理人员。数据集市和维度建模技术，如星形/雪花模式，已经被开发出来以支持这个用户群。数据集市通常用于专注于特定主题领域的描述性和诊断性分析，帮助用户了解发生了什么，正在发生什么，以及为什么，还可以进行假想分析。
虽然ODS和数据集服务于两组不同的分析用户，但它们往往被限制在特定的功能领域。企业数据仓库（EDW）已经被开发出来，以满足跨职能分析的需要。数据仓库存储历史数据，以寻找数据中的长期模式。根据组织的偏好，它们被设计为采用ER和维度建模技术。
2. MDDBs
ODS、数据集市和EDW是通过传统的RDBMS（如Db2、Oracle和SQL Server）实现的，其目的是提供罐装报告和执行仪表盘，可以按照预定的时间表（通常是每天）以批处理的方式交付。对于专门的报告和交互式分析，它们有严重的性能限制。
为了满足这些需求，多维数据库（MDDBs），如Oracle Express、Cognos Power Play、Hyperion Essbase等，已经被开发出来。由于MDDBs的大小限制（每个立方体通常可以容纳2GB的数据），这些数据库已经被用于特定主题领域分析的数据集市，如财务规划和预算、会计、采购、销售、营销等。用户可以通过这些MDDBs进行交互式分析，包括向上/向下/穿透、假设分析和情景规划，尽管仅限于特定的功能领域。
3. 数据仓库
分析性应用必须在总体水平上处理数据以发现新的模式。传统的RDBMS，如DB2、Oracle和SQL Server，在通用/通用硬件上运行，在满足这些分析性工作负载的需求方面落后了。像Teradata这样的数据库管理系统，像Netezza、Neoview、Parallel Data Warehouse和SAP HANA这样的设备进入市场以满足这些需求。它们在特殊用途的硬件上运行，使用大规模并行架构和内存处理，给予所需的性能提升。这些设备已被用于实现企业数据仓库的一种风味。然而，除了Teradata，所有其他设备技术的成功率都很低。
4. 数据湖
ODS、EDW和数据集市只处理企业结构化数据。他们不能处理和分析半结构化（JSON，XML等）和非结构化数据（文本，文档，图像，视频，音频等）。
此外，它们是在云计算出现之前开发的。因此，存储和计算资源之间存在着紧密的整合。因此，这些资源必须针对应用程序的峰值负载进行规划，当应用程序的负载不高时，这些资源在大多数时候都会被利用不足。
随着大数据技术的到来，数据架构的另一个变体出现了，即数据湖。虽然数据湖的目的与EDW或数据集市相似，但它也满足了半结构化和非结构化数据的需求。它在云基础设施上的实施更为突出，如AWS S3、Azure ADLS或谷歌的GCS。
数据仓库和数据集市是以预定的目的建立的，而数据湖是所有类型数据的原始存储（以最低的存储成本），可以通过旋转数据仓库、数据集市或数据科学和认知科学应用的数据管道来处理特定目的。
由于数据湖持有原始数据，它在编写时不需要模式，不像数据仓库和数据集市在加载数据时需要预定义的模式。
相对于昂贵的专有数据仓库，数据湖的低成本、对象存储和开放格式的特点使它很受欢迎。然而，数据湖也有其自身的挑战，例如。
- 缺乏对事务性应用的支持
- 可靠性低
- 数据质量差
- 安全性的执行
- 随着数据量的增长，性能下降
5. 数据网格
数据仓库和数据湖的架构是集中式的实现，限制了数据的可扩展性和可消费性。这些实现需要很长的时间，限制了对数据的领域理解，并且更多的是面向技术而不是面向终端用户。它们是由数据工程专家设计和拥有的，而这些专家并不容易得到大量的数据，这也是对数据的可扩展性和分析的民主化的一个限制。这些数据工程师远离产生数据的业务应用，因此，它缺乏业务背景和数据的意义。
数据网格架构/概念已经被开发出来以解决这些挑战。在这种方法中，数据与各种功能/主题领域或领域一起被组织为数据产品。它们由负责业务应用的人拥有，因此他们了解数据的业务背景、意义和用途。这些数据产品拥有者接受数据工程师的帮助来设计和发布分析性数据产品。将会有一个这些分析性数据产品的目录，组织中的每个消费者都可以看到，了解其背景，使用任何给定的数据产品，并作出相应的解释。
数据网格的核心原则基本上是：
- 数据是一种产品
- 面向领域的分散的数据所有权
- 自助服务平台
- 设计和架构的联合管理
数据网仍然是一种数据架构的方法。目前市场上还没有实现这种架构的产品。
6. Data Fabric数据结构
Data Fabric也在试图解决Data Mesh所要做的同样问题。然而，他们的方法是完全不同的。Data Mesh是一个领域和面向业务的分布式方法，而Data Fabric是一个集中的元数据驱动和以技术为中心的方法。
Data Fabric是用元数据、目录、逻辑数据模型和数据交付API开发的。部分数据是虚拟化的，而其余的数据是集中的，就像数据仓库一样。它与集中管理的数据生命周期管理策略相辅相成，例如。
- 数据治理--积极的元数据管理、访问控制、世系、质量
- 隐私 - 屏蔽/编辑敏感信息，如信用卡和个人数据
- 合规性--GDPR、HIPPA、FCRA
SAP数据智能、IBM的Cloud Pak for Data、Oracle Coherence和Talend Data Fabric是这个领域的一些产品。
Denodo是另一个产品，它更多地是关于数据虚拟化技术，这是数据结构方法的核心部分。
7. 数据湖仓Lakehouse架构
在数据湖架构中，由于不同的数据访问要求，每种类型的分析工作负载都需要自己的数据管道，导致对相同数据的理解和使用不一致。
它还在分析应用程序（消费者）和产生数据的业务应用程序（来源）之间引入了一个更多的数据存储层。首先，数据必须进入数据湖，然后转移到消费应用程序，这可能会降低关键洞察力的价值，直到它们被采取行动。
数据湖不支持交易事务型应用，并有许多其他的限制，如上节所述。
Lakehouse架构正试图通过为所有类型的数据分析工作负载提供一个通用接口来解决这些问题。它支持事务性应用的ACID属性。它本质上结合了数据仓库和数据湖架构的优势，同时解决了两者的挑战。
结论
数据架构一直在发展，以满足各种分析和认知工作负载日益增长的需求，利用云和大数据技术的创新。根据组织在数据分析成熟度上的位置，它所拥有的各种数据，以及它所需要的分析工作负载的种类，可以选择一个特定类型的数据架构。虽然Lakehouse架构有可能是所有世界中最好的，但它是新的，还没有成熟到可以广泛采用。
数据架构是所有商业数据战略的核心；因此，关注它们是至关重要的。有了适合你具体使用情况的数据架构，你就可以确保数据战略的成功实施。