数据架构“变形记”：从孤岛林立到智能协同

在全球范围内，各行各业都投资于分析其海量数据并创建有效的数据策略,其市场规模预计到 2030 年将达到 6,841.2 亿美元。数据架构是如何通过 IT 基础设施支持数据策略的框架。作为数据战略的基础，数据架构在有效的战略实施中起着至关重要的作用。多年来数据架构的演变相应地形成了数据战略的有效性。

数据模型、架构和存储随着时间的推移而发展，以满足不同的分析工作。在本文中，尝试介绍各种数据架构，它们已经发展到可以满足不断增长的分析需求。这些演变中的每一种架构都值得一本书来描述，以至于不能在一篇文章中得到完整的细节。然而，本文的目的是在这里描述其中每种架构的高级特性，以便获得系统性观点。

1. 为什么需要数据架构？

成为数据驱动型组织仍然是众多企业的核心战略目标之一。所谓数据驱动，意味着将数据作为所有决策和业务流程的核心依据。企业管理者深知，要在当今竞争激烈的市场中保持优势，唯有通过数据实现客户体验优化、运营效率提升以及商业趋势洞察。例如，借助超个性化技术与客户旅程重塑来提升用户体验，利用自动化和机器学习降低运营成本，这些都使数据驱动成为不可或缺的战略路径。

在这一过程中，数据平台扮演着关键角色，它为数据的采集、整合、存储与应用提供了支撑环境，促进了数据的高效流动与价值释放。而数据架构作为数据平台的核心组成部分，负责设计、构建和管理组织内数据资产的整体结构。它类似于一个集成框架，将来自不同来源和系统的数据统一组织起来，确保其可用性与一致性。

优秀的数据架构旨在减少数据孤岛、降低冗余数据带来的管理负担，并提升整个数据生命周期的管理效率。随着数据消费模式的不断演进，数据分析也从传统的商业智能（BI）逐步扩展到融合机器学习的智能产品，推动企业向智能化、预测性决策方向迈进。

2. 早期的数据架构ODS、 EDW 和 Data Marts

在早期，为了满足决策支持系统的需求，操作型数据存储（ODS, Operational Data Store）被开发出来，主要服务于需要预定义报表的用户群体。ODS 通常仅保存较短时间内的当前数据（一般为6个月），用于生成日常运营报告并支持战术层面的决策。例如，银行工作人员可以根据ODS中的实时信息判断是否为排队等候的客户提供透支服务或提升其信用额度等。

随着商业智能（BI）工具的兴起，分析型用户的范围得到了显著扩展，其中包括偏好通过图形化方式查看汇总信息的高层管理人员。为满足这类用户的需求，数据集市（Data Marts）和维度建模技术（如星型模型和雪花型模型）应运而生。数据集市主要用于描述性与诊断性分析，聚焦于特定的主题领域，帮助用户理解“发生了什么”、“正在发生什么”、“为什么会发生”以及进行“假设分析”。

尽管 ODS 和数据集市分别服务于不同类型的分析需求，但它们通常局限于特定的业务功能领域。随着企业对跨部门、跨系统综合分析的需求不断增长，企业级数据仓库（Enterprise Data Warehouse, EDW）应运而生。数据仓库不仅整合了来自多个系统的数据，还长期存储历史数据，以挖掘其中的趋势和长期模式。其设计通常结合企业的整体数据架构偏好，采用实体-关系图（ER图）和维度建模相结合的方法，以实现灵活性与性能的平衡。

3. 企业数据分析架构：MDDB

传统的关系型数据库管理系统（RDBMS），如Db2、Oracle和SQL Server，常用于实现操作型数据存储（ODS）、数据集市（Data Marts）和企业级数据仓库（EDW），以支持报告生成和执行仪表盘展示。这些报告和仪表盘通常依据预定义的时间表（一般为每日）通过批处理模式交付。然而，对于即席查询和交互式分析，这类系统往往面临严格的性能限制。

为了克服这些挑战并满足高级分析需求，多维数据库（MDDB），例如Oracle Express等被开发出来。由于早期MDDB存在大小限制（每个数据集通常最大支持2GB的数据），它们主要用于特定主题领域的数据分析，如财务规划与预算、会计、采购、销售及市场营销等。用户能够利用这些MDDB进行包括上下钻取、假设分析以及场景规划在内的交互式分析，但仅限于特定的功能区域。

因此，在这一阶段，一个典型的企业数据分析架构通常包含以下组成部分：使用RDBMS来管理结构化数据，并定期生成报告；同时，采用MDDB来支持特定业务领域的深入分析，提供更加灵活的数据探索方式，尽管其应用范围受限于数据集大小和功能领域。

4. 数据仓库架构

数据分析通常需要在聚合层面对数据进行处理，以发现新的模式和洞察。然而，传统的关系型数据库管理系统（RDBMS），如 DB2、Oracle 和 SQL Server，在通用硬件上运行时，往往难以满足这类分析工作负载对性能和响应时间的要求。为此，专门面向大规模数据分析优化的系统应运而生，例如 Teradata、Microsoft Parallel Data Warehouse（PDW）以及 SAP HANA 等。这些系统基于专用硬件平台，采用大规模并行处理架构（MPP）和内存计算技术，显著提升了查询性能与处理能力，广泛应用于企业级数据仓库的建设。

尽管如此，除了 Teradata 之外，其他系统的市场接受度和应用成功率相对有限。

典型的数据仓库架构通常由以下流程定义：从操作型系统（如 SAP、Salesforce）和第一方数据库（如 MySQL、SQL Server）中抽取数据，并最终加载到商业智能（BI）系统中进行展示和分析。数据仓库作为这一流程的核心枢纽，采用预定义的模式（如星型模型或雪花模型），将数据组织为维度表和事实表，从而帮助企业追踪业务操作及客户交互中的变化。

该架构的主要流程包括：

1. 提取（Extract）从多个操作型数据库和其他数据源中抽取原始数据；
2. 转换（Transform）将数据统一转换为多维、时变的通用格式；
3. 加载（Load）通过变更数据捕获（CDC）机制，将数据加载至数据仓库表中；
4. 查询（Query）用户可通过类 SQL 查询语言访问数据；
5. 分析（Analyze）主要服务于数据分析师，用于生成报表和可视化分析结果。

在此类架构中，数据集市（Data Marts）也扮演着重要角色。它们是构建在数据仓库之上的逻辑层，通常由一个或多个表组成，专注于解决特定部门或业务领域的具体问题。如果没有数据集市，相关部门就需要在庞大的数据仓库中自行探索并编写多个复杂查询，才能获取符合其需求的数据内容和格式。

然而，这种传统架构也面临诸多挑战：

• 随着时间推移，系统中积累了成千上万的 ETL 作业、数据表和报表，只有少数熟悉系统历史的专业团队才能维护和理解；
• 缺乏现代工程实践的支持，例如持续集成/持续交付（CI/CD）等；
• 数据仓库的数据模型和模式设计较为僵化，难以灵活应对来自多个来源的大量结构化与非结构化数据。

这些问题促使我们进入下一阶段的数据架构演进，即更灵活、可扩展、支持实时和多样化数据类型的新一代数据平台。

5. 数据湖架构

企业数据仓库（EDW）和数据集市主要处理结构化的企业数据，无法直接支持半结构化（如JSON、XML等）和非结构化数据（如文本、文档、图像、视频、音频等）的存储与分析。此外，由于这些技术在云计算兴起之前便已发展成熟，它们通常将计算和存储资源紧密结合，导致为应对峰值负载而规划的资源，在低负载期间利用率低下。

随着大数据技术的发展，数据湖作为一种新的数据架构模式应运而生。尽管其目标与EDW或数据集市类似，但数据湖特别适用于处理半结构化和非结构化数据，并且更常部署于云基础设施之上（如AWS S3、Azure Blob Storage或Google Cloud Storage）。数据湖作为所有类型数据的原始存储库，以最低的成本保存数据，并可根据特定需求通过数据仓库、数据集市或数据管道进行加工，服务于数据科学和认知计算应用。

自2010年引入数据湖架构以来，它解决了传统数据仓库在适应新用途方面的局限性，特别是满足了数据科学家在机器学习模型训练过程中对原始数据的需求。机器学习模型不仅需要大量的数据，而且这些数据难以有效地存储于传统的数据仓库中。早期的数据湖实现涉及使用Hadoop分布式文件系统（HDFS）跨集群节点存储数据，并利用MapReduce、Spark等框架进行数据处理。

不同于需要预定义schema的数据仓库和数据集市，数据湖中的数据无需在写入时定义schema，这使得它能够灵活地存储大量多样的数据。然而，数据湖也面临着自己的挑战，包括缺乏事务支持、数据质量问题、安全措施不足以及随着数据量增加而出现的性能下降问题。

典型的数据湖遵循ELT（Extract, Load, Transform）而非ETL流程工作。数据首先从源系统提取并加载到中央存储库中，然后根据具体需求通过数据转换管道进行处理。这种架构允许数据保持接近其原始状态，同时提供了灵活性以满足不同应用场景的需求。为了更好地组织数据湖，数据工程团队会创建不同的“区域”，依据数据清理和转换的程度来分类存储，从最原始的数据逐步过渡到经过清洗和丰富化的高质量数据集。

该数据架构的设计旨在减少传统数据仓库中大规模预先建模所带来的效率低下和操作摩擦，简化了数据访问和模型训练的过程，促进了更快的迭代速度。

6.数据编织架构：Data Fabric

Data Fabric（数据编织）是一种集中化的、以元数据驱动并以技术为核心的数据集成架构方法。它通过元数据管理、数据目录、逻辑数据模型以及数据交付 API 构建而成，旨在实现跨异构环境的数据统一访问与治理。

在 Data Fabric 架构中，部分数据通过虚拟化的方式进行实时访问，而其余数据则被集中存储，类似于传统数据仓库的做法，从而在保证性能的同时提升数据可用性。

该架构还辅以统一的数据生命周期管理策略，涵盖从数据创建到归档或删除的全过程，主要包括以下关键方面：

• 数据治理包括活动元数据管理、访问控制、数据血缘追踪、质量监控等；
• 隐私保护如对敏感信息（信用卡号、个人身份信息等）进行屏蔽或脱敏处理；
• 合规性管理确保符合 GDPR、HIPAA、FCRA 等相关法规要求。

目前市场上已有多个支持 Data Fabric 架构的产品，例如 SAP Data Intelligence、IBM 的 Cloud Pak for Data、Oracle Coherence 和 Talend Data Fabric 等。此外，Denodo 也是该领域的重要参与者，其核心优势在于数据虚拟化技术——这也是实现 Data Fabric 架构灵活性和高效集成的关键支撑技术之一。

7.湖仓一体架构

在传统的数据湖与数据仓库并行的架构中，由于不同类型的分析工作负载对数据访问的需求各异，往往需要各自独立的数据管道，从而导致相同数据在理解和使用上的不一致问题。为了解决这一挑战，湖仓一体架构（Lakehouse Architecture） 应运而生。

湖仓一体的核心思想是将数据湖和数据仓库的能力融合于统一的技术平台：要么通过扩展数据仓库的功能，使其支持嵌入式机器学习训练；要么将数据仓库所具备的完整性、事务性及高效查询能力内建到数据湖解决方案中。例如，Databricks Lakehouse 就是一个典型的湖仓一体化实现，它在传统数据湖的存储基础上引入了类似数据仓库的事务支持与查询性能。

然而，湖仓一体架构也在数据源系统（业务应用）与消费系统（分析应用）之间引入了一个新的中间层——即统一的数据存储平台。这意味着数据首先必须进入湖仓一体平台，然后再流向下游的应用程序，这种额外的流转环节可能会影响关键洞察的时效性和价值。

与传统数据湖相比，湖仓一体架构显著提升了对事务性应用场景的支持能力，具备完整的 ACID 事务保障。它融合了数据仓库在数据一致性、事务处理和高性能查询方面的优势，以及数据湖在存储多样性、灵活性和成本效率上的优点，从而有效应对了两者各自的局限。

总的来说，湖仓一体架构旨在为所有类型的数据分析工作负载（如报表、BI、机器学习、实时分析等）提供一个统一、高效且可扩展的数据平台。

8. 数据网格：data mesh

传统的数据仓库和数据湖架构通常采用集中式的实现方式，这种设计在数据的可扩展性和可用性方面存在明显限制。这些系统往往开发周期长、维护复杂，侧重于技术实现而非最终用户体验。它们主要由专业的数据工程团队设计和管理，而这类人才稀缺且难以获取，进一步制约了数据分析能力的普及与扩展。

更重要的是，这些技术人员通常远离生成数据的业务一线，导致对数据背后业务上下文的理解不足，影响了数据的实际价值挖掘。这种“技术中心”而非“业务驱动”的模式，削弱了数据在组织中的真正潜力。

为了解决上述问题，数据网格（Data Mesh）架构应运而生。这是一种全新的分布式数据架构方法，其核心理念是将数据视为产品，并按照功能领域或主题域进行去中心化管理。每个数据产品由熟悉该业务领域的团队拥有和维护，使其能够深入理解数据的业务背景、含义及使用方式。

在数据网格中，数据产品所有者通常在数据工程师的支持下，负责设计、治理和分发面向分析的数据产品。同时，组织会建立一个统一的数据产品目录，使所有使用者都能发现、理解并有效地使用这些数据产品。

数据网格的核心原则包括：

• 数据即产品（Data as a Product）：数据被当作高质量的产品来构建和维护，确保其可用性、可发现性和可靠性。
• 面向领域的去中心化所有权（Domain-Oriented Decentralized Ownership）：每个业务领域对其数据拥有完全控制权，包括建模、存储和治理。
• 自服务平台（Self-Service Data Infrastructure as a Platform）：提供统一的技术平台和工具链，支持各领域独立管理和交付数据产品。
• 联合治理（Federated Governance）：在去中心化的基础上，通过协作式治理机制确保跨域数据的一致性、安全性和合规性。

从本质上讲，数据网格代表了数据架构设计以及数据团队组织方式的一次范式转变。它推动数据团队向以业务为中心的跨职能团队转型，类似于现代软件工程中以服务为导向的微服务团队。

在这一架构中，每个业务域可以拥有自己的 OLAP 数据库和分布式文件系统，就像微服务架构中每个服务都可以独立部署一样。数据产品之间通过流式处理或 REST API 实现通信，形成灵活、解耦的数据生态系统。

此外，数据产品接口（Data Product API）遵循标准的 REST API 文档规范，并可通过统一的数据目录进行发现和访问。

虽然数据网格最显著的变化体现在架构层面，但它的实施也带来了深刻的社会化变革。正如从单体应用向微服务架构的演进促使软件工程团队在开发流程、组织结构、技能模型和治理机制上发生转变一样，数据网格的落地也需要类似的组织文化与角色定位的调整。

例如，在微服务中产品经理的角色至关重要，他们确保技术解决方案真正解决用户的实际需求。同样地，在数据网格中，也需要引入类似的角色——如数据产品经理——来保证数据产品能够满足业务用户的需求，并持续创造价值。

9. 小结

数据架构的演进，始终围绕着一个核心目标：满足日益复杂和多样的分析与智能计算需求。从传统数据仓库到数据湖，再到 Lakehouse 与数据网格，每一次变革都是对技术边界的一次突破，也是对业务价值的一次重新定义。

在云计算与大数据技术的推动下，组织如今拥有了更多选择，可以根据自身的数据成熟度、数据类型以及业务需求，量身打造最合适的数据架构。虽然 Lakehouse 架构被寄予厚望，被视为融合数据湖与数据仓库优势的理想方案，但其技术和生态仍在发展中；而数据网格作为一种全新的架构理念，虽尚未有成熟的商业化产品落地，却已展现出深远的潜力与变革意义。

可以说，数据架构不仅是技术体系的核心，更是企业实现数据驱动战略的基石。选择合适的数据架构，意味着为数据赋予真正的生命力，也意味着让“用数据说话”真正成为现实。

如果您身处制造业等传统行业， 如何更好地实习数据战略呢？ 推荐阅读王晓钰老师的 《工业数字化转型：系统方法与敏捷实践》 一书——

如果您期望通过企业架构实现数据战略，推荐阅读武艳军老师的《企业架构驱动数字化转型》一书——

如果您期望通过数据战略来完善供应链金融， 推荐阅读冯天驰老师的 《数字要素驱动供应链金融》一书——

【参考资料与关联阅读】

• https://dataproducthinking.substack.com/p/the-problems-in-the-modern-data-stack
• https://medium.com/@diogo22santos/the-past-present-and-future-of-data-architecture
• https://medium.com/krtrimaiq-cognitive-solutions/evolution-of-data-architectures
• References
• https://www.javatpoint.com/data-warehouse-operational-data-stores
• https://www.techtarget.com/searchoracle/definition/multidimensional-database
• https://www.astera.com/type/blog/data-warehouse-concepts/
• https://www.snowflake.com/guides/what-feature-store-machine-learning
• https://jamesdixon.wordpress.com/2010/10/14/pentaho-hadoop-and-data-lakes/
• https://databricks.com/discover/data-lakes/introduction#introduction
• https://databricks.com/research/lakehouse-a-new-generation-of-open-platforms-that-unify-data-warehousing-and-advanced-analytics
• https://www.gartner.com/smarterwithgartner/data-fabric-architecture-is-key-to-modernizing-data-management-and-integration
• https://martinfowler.com/articles/data-mesh-principles.html
• 数据分析中10种常见的可视化图例
• 面向数据产品的10个技能
• 浅析dashboard的10个实现原则
• 数据集中的10种变量类型
• 数据工程师常见的10个数据统计问题
• 浅析数据工程
• 数据架构中的数据问题
• 温故知新：数据科学札记
• 清单管理？面向机器学习中的数据集
• web系统中的结构化数据标记
• 老曹眼中的面向数据架构
• NoSQL 之于大数据
• 解读向量数据库
• 在大模型RAG系统中应用知识图谱
• 让知识图谱成为大模型的伴侣
• 大模型系列——解读RAG
• 7B？13B？175B？解读大模型的参数
• 全网首发：MCP 的10种架构模式