为什么我们需要数据架构？

成为一个数据驱动型组织仍然是许多公司的首要战略目标之一。数据驱动意味着将数据置于组织中进行的所有决策和流程的核心位置。

领导者们明白，成为数据驱动型是改善客户体验的唯一途径，通过超个性化和客户旅程重新设计来实现；通过自动化和机器学习来降低运营成本；以及了解对高级战略和市场定位至关重要的业务趋势。数据平台为数据繁荣创造了一个繁荣的环境。

数据平台是组织所有数据的存储和处理中心。它负责数据的收集、清洗、转换和应用，以生成业务洞察。有时它被称为“现代数据堆栈”，因为数据平台通常由多个集成工具组成，由不同的供应商提供支持（例如Dbt、Snowflake、Kafka等）。

数据平台的主要组成部分之一是数据架构。数据架构是设计、构建和管理组织数据资产结构的过程。它类似于一个框架，用于整合来自不同来源和应用程序的数据。

一个良好设计的数据架构的主要目标是减少数据孤岛，最小化数据重复，并提高数据管理过程的整体效率。

随着过去几十年间数据领域的发展，数据架构也在不断演进。让我们更详细地了解这种演进。

分析数据经历了演进性变化，受到新的消费模式驱动，从支持业务决策的传统分析到通过机器学习增强的智能产品。

第一代：数据仓库架构

数据仓库架构的定义是指从操作系统（如SAP、Salesforce）和第一方数据库（如MySQL、SQL Server）向商业智能系统中传输数据的数据流动方式。数据仓库是一个中心点，其中定义了一个模式（雪花模式、星型模式），数据将以维度表和事实表的形式存储在其中，使企业能够追踪和跟踪其业务操作和客户互动的变化。数据的处理过程如下：

从多个操作数据库和源中提取数据
转换为通用模式 - 以多维度和时间变量的表格格式表示
通过CDC（变更数据捕获）过程加载到数据仓库表中
通过类似SQL的查询进行访问
主要用于为数据分析师提供报告和分析可视化的使用场景

在这种架构风格中，数据集市也起到了作用。它们是数据仓库之上的附加层（由一个或多个表组成），用于根据特定的模式格式为特定部门的业务问题提供服务。如果没有数据集市，这些部门将不得不在数据仓库中探索和创建多个查询，以获得他们所需的内容和格式的数据。

这种方法面临的主要挑战有：

随着时间的推移，构建了数千个ETL作业、表格和报告，只有专门的团队才能理解和维护。
现代工程实践，如持续集成/持续交付（CI/CD），没有得到应用。
数据仓库的数据模型和模式设计过于僵化，无法处理来自多个来源的大量结构化和非结构化数据。

这引导我们进入下一个数据架构的演进阶段。

第二代：数据湖架构

数据湖架构于2010年引入，是为了应对数据仓库架构在满足新的数据用途（例如数据科学家在机器学习模型训练过程中对数据的访问）方面的挑战。

数据科学家需要以原始形式获取数据进行机器学习（ML）模型训练过程。同时，ML模型需要大量的数据，这在数据仓库中可能难以存储。

最早建立的数据湖使用Hadoop分布式文件系统（HDFS）在一组集群计算节点上存储数据。数据会通过MapReduce、Spark和其他数据处理框架进行提取和处理。

数据湖架构采用ELT（提取-加载-转换）过程，而不是ETL（提取-转换-加载）过程。数据从操作系统中提取（E），加载（L）到中央存储库。然而，与数据仓库不同，数据湖在前期对数据进行非常少或没有转换和建模。其目标是保持数据接近其原始形式。一旦数据进入数据湖，架构会通过数据转换流程（T）对原始数据进行建模，并将其存储在数据仓库或特征存储中。

为了更好地组织数据湖，数据工程团队会创建不同的“区域”。其目标是根据数据的清洗和转换程度存储数据，从最原始的数据到数据增强步骤，再到最干净和最可访问的数据。

这种数据架构旨在改善数据仓库在广泛的前期建模方面的低效和摩擦。前期的转换是一个阻碍因素，导致数据访问和模型训练的迭代速度变慢。

这种方法面临的主要挑战有：

数据湖架构存在复杂性和退化问题，导致数据质量和可靠性不佳。
由一支中心化的高度专业化数据工程团队操作的复杂批处理或流式作业管道。
它创建了无管理的数据集，这些数据集通常不可信且难以访问，提供的价值有限。
数据的血缘关系和依赖关系难以追踪。
没有广泛的前期数据建模使得在不同数据源之间建立语义映射变得困难，从而导致数据混乱。

第三代：云数据湖架构

第三代数据架构与第二代数据架构相比，最大的变化是转向云端、实时数据可用性的提高以及数据仓库与数据湖之间的融合。具体来说：

支持流式数据处理，实现接近实时的数据可用性，采用了Kappa等架构。
尝试统一批处理和流处理，使用Apache Beam等框架进行数据转换。
充分利用基于云的托管服务，采用现代云原生实现，实现计算和存储的隔离。存储数据的成本大大降低。
将数据仓库和数据湖合并为一种技术，可以将机器学习训练集成到数据仓库中，或者将数据仓库的完整性、事务性和查询系统构建到数据湖解决方案中。Databricks Lakehouse就是一个传统的数据湖存储解决方案，具备类似数据仓库的事务性和查询支持。

云数据湖解决了前几代存在的一些问题，但仍然面临一些挑战：

数据湖架构仍然非常复杂，难以管理，影响数据质量和可靠性。
架构设计仍然集中化，需要一支由高度专业化的数据工程师组成的团队。
获取洞察力的时间较长。数据消费者仍需等待数月才能获取用于分析或机器学习的数据集。
数据仓库不再是通过数据复制来复制真实世界的，这影响了数据消费者在探索数据时的体验。

所有这些挑战使我们进入了第四代数据架构，在本文发布时，该架构仍处于早期阶段。

第四代：数据网格架构

数据网格架构是一种相对较新的数据架构方法，旨在解决先前集中式架构中存在的一些挑战。

数据网格将微服务为单体应用带来的好处引入到数据架构中。

在数据网格中，数据是分散的，并且数据的所有权在不同领域之间分布。每个领域负责其范围内的数据，包括数据建模、存储和治理，架构必须提供一套实践方法，使每个领域能够独立管理其数据。

以下是数据网格架构的关键组成部分：

1、领域（Domains）- 领域是一个自包含的业务单元，拥有并管理自己的数据。每个领域具有明确的业务目标，负责定义数据建模、实体、模式和数据管理策略。

这个概念与数据仓库架构中为不同团队（如市场营销或销售）设计的数据集不同。在数据网格架构中，销售部门可以有多个领域，取决于团队可能具有的不同关注点/领域。

2、数据产品（Data Products）- 数据产品是领域生成的最终产品，可供其他领域或应用程序使用。每个数据产品都有明确的业务目的。

一个领域可以处理多个数据产品。并非所有数据资产都被视为数据产品或应接受数据产品处理（尽管在理想的情况下，应该是这样）。数据产品是在组织中发挥重要作用的数据资产。

3、数据基础设施（Data Infrastructure）- 数据基础设施包括在领域内管理数据所需的工具和技术，类似于软件应用程序的容器化微服务。这包括数据存储、处理和分析工具。

4、数据治理（Data Governance）- 数据治理由每个领域进行管理。这涉及一组用于管理数据质量、隐私和安全性的程序。

5、网格 API（Mesh API）- 就像微服务通过HTTP REST API公开所有内容一样，数据网格领域将通过定义良好的接口公开所有内容，其他领域和数据产品可以使用该接口消费数据。

您可以将数据网格视为数据架构设计和数据团队组织方式的范式转变：

数据团队变成了跨职能团队，专注于一个或多个业务领域（而非技术），就像软件产品团队非常服务导向一样。
每个由一个或多个微服务组成的业务领域都将拥有自己的OLAP数据库和分布式文件存储系统，就像微服务的每个组件都被容器化以独立工作一样。
数据产品A将被数据产品B使用，并且两者将通过流式传输或REST API与其他数据产品进行通信，就像应用程序微服务彼此之间的通信一样。
数据产品的API将按照传统的REST API文档进行，可以通过网格数据目录来发现数据产品。

除了架构之外，数据网格还带来了其他变化

最具影响力的变化是从数据湖向分散的数据网格的架构转变。但是从集中式数据湖向分散式数据网格的转变是一个社会技术现象，涉及到其他一些变化。

如果你回想一下，从单体应用到微服务应用的转变让软件工程团队改变了他们的开发生命周期、组织结构、动机、技能和治理。这时候产品经理的角色出现了，以确保应用程序能够解决真正的用户问题。

在应用数据网格架构时，也需要出现类似的变化。

在即将发布的文章中，我将更多地讨论数据网格实施的挑战。