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