为什么我们需要数据架构？
成为一个数据驱动的组织仍然是许多公司的首要战略目标。数据驱动意味着将数据置于组织中所有决策和流程的中心。
领导者明白，成为数据驱动组织是改善客户体验的唯一途径，通过超个性化和客户旅程重新设计，通过自动化和机器学习降低运营成本，并了解对高层重要的业务趋势战略和市场定位。数据平台为数据的蓬勃发展创造了繁荣的环境。
数据平台是组织所有数据的存储库和处理室。它处理数据的收集、清理、转换和应用，以生成业务见解。它有时被称为“现代数据堆栈”，因为数据平台通常由不同供应商支持的多个集成工具组成（Dbt、Snowflake、Kafka等）。
数据平台的主要元素之一是数据架构。数据架构是设计、构建和管理组织数据资产结构的过程。它就像一个用于集成来自不同来源和应用程序的数据的框架。
设计良好的数据体系结构的主要目标是减少数据孤岛，最大限度地减少数据重复，并提高数据管理过程的整体效率。随着数据格局在过去几十年的演变，数据体系结构也在不断发展。让我们更详细地了解这种演变。
在新的消费模型的驱动下，分析数据经历了进化的过程，从支持商业决策的传统分析到增强 ML的智能产品。
图 1-数据体系结构的演变
第一代：数据仓库体系结构
数据仓库体系结构是由从操作系统（SAP、Salesforce）和第一方数据库（MySQL、SQL Server）到商业智能系统的数据移动定义的。数据仓库是定义模式（雪花模式、星形模式）的中心点，数据将存储在维度和事实表中，使企业能够跟踪其运营和客户互动中的变化。数据为：
1、从许多操作数据库和来源中提取。
2、转换为以多维和时变表格格式表示的通用模式。
3、通过CDC（变更数据捕获）过程加载到仓库表中。
4、通过类似SQL的查询访问。
5、主要为报告和分析可视化用例的数据分析师提供服务。
这种体系结构中，数据集市也开始发挥作用。它们是数据仓库之上的一个附加层（由一个或多个表组成），以特定的模式格式为特定的部门业务问题提供服务。如果没有数据集市，这些部门将不得不在仓库中探索和创建多个查询，以获得具有所需内容和格式的数据。
图 2-数据仓库体系结构|来源：数据网格书
这种方法的主要挑战：
- 随着时间的推移，构建了数千个ETL作业、表和报告，只有专业团队才能理解和维护它们。
- 代工程实践如CI/CD不适用。
- 数据仓库的数据模型和模式设计过于僵化，无法处理来自多个来源的大量结构化和非结构化数据。
这将引导我们进入下一代数据体系结构。
第二代：数据湖架构
数据湖架构于2010年推出，以应对数据仓库架构在满足数据新用途方面的挑战：数据科学家在机器学习模型训练过程中访问数据。
数据科学家需要原始形式的数据来进行机器学习（ML）模型训练过程。ML模型还需要大量数据，这些数据很难存储在数据仓库中。
第一个构建出来的数据湖涉及在Hadoop分布式文件系统（HDFS）中跨一组集群计算节点存储数据。数据将使用MapReduce、Spark和其他数据处理框架进行提取和处理。
数据湖体系结构在ELT过程中工作，而不是ETL过程。数据从操作系统中提取（E），并加载（L）到中央存储库中。然而，与数据仓库不同的是，数据湖只需要很少或根本不需要预先对数据进行转换和建模。目标是保持数据接近其原始形式。一旦数据进入湖泊，该架构就会通过数据转换管道（T）进行扩展，以对原始数据进行建模，并将其存储在数据仓库或功能存储中。
数据工程团队，为了更好地组织湖泊，创建不同的“区域”。目标是根据清理和转换的程度存储数据，从最原始的数据到数据丰富的步骤，再到最干净、最可访问的数据。
这种数据体系结构旨在改善数据仓库所需的大量前期建模的无效性和摩擦性。前置转换是一个障碍，会导致数据访问和模型训练的迭代速度减慢。
图 3-数据湖架构|来源：数据网格书
这种方法的主要挑战：
- 数据湖架构存在复杂性和退化，导致数据质量和可靠性较差。
- 批处理或流式作业的复杂管道需要由超专业数据工程师组成的中心团队操作。
- 创建了非托管数据集，这些数据集通常不受信任且不可访问，几乎没有价值。
- 数据沿袭和依赖关系很难跟踪。
- 没有广泛的前期数据建模会给在不同数据源之间建立语义映射带来困难，从而产生数据沼泽。
第三代：云数据湖架构
从第二代到第三代数据架构的最大变化是向云的转换、实时数据可用性以及数据仓库和数据湖之间的融合。更详细地说：
- 使用Kappa等架构支持流式传输，以实现近乎实时的数据可用性。
- 尝试将数据转换的批处理和流处理与Apache Beam等框架统一起来。
- 完全接受基于云的托管服务，并使用具有独立计算和存储的现代云原生实现。存储数据变得更加便宜。
将仓库和lake融合为一种技术，要么扩展数据仓库以包括嵌入式ML训练，要么将数据仓库的完整性、事务性和查询系统构建到数据lake解决方案中。Databricks Lakehouse是一个具有类似仓库的事务和查询支持的传统湖泊存储解决方案的示例。
图4-从数据仓库到数据仓库体系结构（右）|来源：Databricks博客
云数据湖正在解决前几代人的一些差距。然而，仍然存在一些挑战：
- 数据湖架构的管理仍然非常复杂，影响了数据质量和可靠性。
- 架构设计仍然是集中的，需要一支超专业的数据工程师团队。
- 需要很长时间才能获得真知灼见。数据消费者继续等待数月才能获得用于分析或机器学习用例的数据集。
- 数据仓库不再是通过数据复制真实世界，在探索数据的同时影响数据消费者的体验。
所有这些挑战使我们想到了第四代数据体系结构，在本文发表时，该体系结构仍处于早期阶段。
第四代：数据网格体系结构
数据网格体系结构是一种相对较新的数据体系结构方法，旨在解决以前集中式体系结构中发现的一些挑战。
数据网格为数据架构带来了微服务为单片应用带来的东西。
在数据网格中，数据是分散的，数据的所有权分布在各个域中。每个域都负责其范围内的数据，包括数据建模、存储和治理，体系结构必须提供一套实践，使每个域能够独立管理其数据。
以下是数据网格体系结构的关键组件：
- 域。域是一个独立的业务单元，拥有并管理自己的数据。每个域都有明确的业务目的，并负责定义数据建模、实体、模式和策略来管理数据。这一概念不同于为营销或销售等不同团队设计的数据仓库架构中的数据集市。在数据网格体系结构中，销售可以有多个领域，这取决于团队可能拥有的不同重点/领域。
- 数据产品。数据产品是域产生的最终结果，可供其他域或应用程序使用。每个数据产品都有明确的商业目的。一个域可以处理多个数据产品。并非所有数据资产都将被视为数据产品或应接受数据产品处理（尽管在完美的世界中是这样）。数据产品是在组织中发挥关键作用的数据资产。
- 数据基础设施。数据基础设施包括管理域内数据所需的工具和技术，类似于软件应用程序的容器化微服务。这包括数据存储、处理和分析工具。
- 数据治理。数据治理由每个域管理。这是指管理数据质量、隐私和安全的一套程序。
- 网格API。就像微服务通过HTTP REST API公开所有内容一样，数据网格域将通过定义良好的接口公开所有内容，其他域和数据产品可以使用该接口。
图 5-数据网格体系结构。每个领域团队自行执行跨领域数据分析。该域吸收运营数据，将分析数据模型构建为数据产品，并与数据契约一起发布，以满足其他域的数据需求|来源：datamesh-architecture.com
您可以将数据网格视为当今数据架构设计方式和数据团队组织方式的范式转变：
- 数据团队成为跨职能团队，专门从事一个或多个业务领域（而非技术），就像软件产品团队需要适应服务一样。
- 每个由一个或多个微服务组成的业务领域都有自己的OLAP数据库和分布式文件存储系统，就像微服务的任何部分都被容器化以独立工作一样。
- 数据产品A将被数据产品B消费，两者都将通过流或REST API与其他数据产品通信，就像应用程序微服务相互通信一样。
- 数据产品API之后将是传统的REST API文档，并且可以通过网格数据目录发现数据产品。
图 6：当团队使用其他域的数据产品时，网格就会出现。上游域发布文章、订单和客户数据产品，这些产品要么在上游被其他数据产品（如发货）消费，要么在下游被ML模型、CRM系统或分析消费。|来源：datamesh-architecture.com
除了体系结构之外，数据网格还有什么变化？
数据网格最具影响力的变化是架构。但是，从集中式数据湖转移到去中心化数据网格是一种社会技术现象，这意味着还有一些额外的变化。
如果你还记得的话，从单片应用程序到微服务应用程序的转变使软件工程团队改变了他们的开发生命周期、组织结构、动机、技能和治理。这时，产品经理的角色出现了，以确保应用程序能够真正解决用户问题。在应用数据网格体系结构时也需要发生同样的情况。
原文作者：Diogo Silva Santos