从传统BI到LakeHouse，数据架构的演变【案例】
A公司是一家科技初创企业，其数据领域却是按照传统的商业智能框架开始的，A公司数据架构基于批量ETL（提取、转换和加载）管道来提取和处理数据；操作数据存储(ODS)作为暂存区域和最终数据仓库结构，细分为数据集市，以支持决策过程。
随着时间的推移，公司不断发展壮大，内部和外部的数据来源也越来越广泛和多样化。此外，数据处理和整合变得越来越复杂，现有的数据架构不足以向利益相关者提供现成的数据。
A公司重新审视了数据架构，寻找一种更有效的方法来处理大量和不同类型的数据，以及更容易维护和扩展的方法，否则很快就会再次达到上限。A公司找到了一个大数据架构，该架构能够处理大量数据，并为长期发展提供一个非常可扩展的环境。
传统BI架构
A公司中的数据域的创建是为了更好地组织来自单一来源的数据，主要目标是分析产品数据，而无需直接访问公司的应用程序数据库。由于需求简单，因此应用了商业智能方法，其中每日批处理作业将从源中提取数据，进行相应处理并将其加载到最终位置。此提取-转换-加载流程（或ETL）将为数据仓库中的临时分析、报告提取和基本数据可视化提供准备就绪的数据平台。
ETL和数据仓库(DW)是商业智能架构中的核心概念：
ETL流程负责从源中提取数据；清理交易数据；根据业务规则处理数据；对数据进行建模，将数据组织成数据仓库中的数据集市。A公司遵循星型架构维度建模框架，该框架提供按业务流程/区域排列为数据集市的数据。
ETL过程的最后一步是数据的加载。
拉尔夫·金博尔数据仓库工具包
数据仓库是可供使用的数据和渴望使用它们的用户之间的边界。数据仓库将被频繁访问以进行数据检索，尤其是报告和数据可视化工具。频繁的访问需要精心组装的数据（星型模式数据集市涵盖了这些数据）以及为此优化的软件。对于后者，A公司正在使用AWSRedshift，它提供了巨大的计算能力和快速响应时间。
尽管如此，BI架构中还有一个重要的中间部分需要提及，即ODS：
ODS或操作数据存储是源数据库（包含交易数据）和数据仓库（包含分析和建模数据）之间的中间位置。在A公司的体系结构中，Airflow中的管道将数据加载到ODS中，A公司的部署为RDS的postgres，之后Airflow中的下一个任务不断清理、处理和连接关系数据库中不同架构和表中的数据，直到它们组织得足够好，可以建模为Redshift的星型架构框架。
A公司的Airflow管道足以向运行批处理和日常作业的利益相关者提供数据。然而，慢慢开始面临一些SLA（服务级别协议）问题，即无法每天按时交付即用型数据。夜间运行的管道事故越来越常见，在极端情况下，有些事故可能会导致交付延迟半天。
延迟数据交付的一个问题是ETL背后的技术。数据提取是用Python制成的，通常使用petl库，它将数据加载到内存中的表对象，不适用于大型数据集。在一些更复杂的管道中，由于源数据库中不断增长的大量数据而不是数据量不断增长，数据的传输会出现延迟。使用Python处理速度足够快。
QuintoAndar中的源数据库过去因缺乏完全可信的审计架构而存在巨大问题。并非所有表格都实施了审计，因为这是一个手动过程，对于那些实施了审计的表格，通常会发现一些不一致之处。因此，大多数数据库提取都是满的——每天都会冗余地加载每个表中的每一行。
此外，Airflow实例会提供一些内存和处理限制，因为它部署在AWSEC2实例中。这些限制开始成为一种痛苦：Airflow实例中的大量内存使用，多个和内存中巨大的petl表正在影响环境-一旦同时运行的各种DAG需要更强大的AWSEC2实例，。由于Airflow中缺乏可用内存而导致的管道崩溃变得越来越频繁，并且增加了SLA批评者的列表。
向分布式文件系统的转变
有两种方法帮助应对处理和编译大量数据的挑战：数据湖存储，以及并行数据处理框架。
一、数据湖
数据湖是一个中央存储库，可大规模存储结构化和非结构化数据。它改变了规则，可以处理大量且多样化的数据，并以较低的存储成本为后盾。
A公司开始实施DataLake架构来替代ODS框架。A公司使用基于AWSS3数据湖层框架，通过在存储中定义具有不同目标和不同受众的层：
原始层-存储未处理和未修改的数据，保留原始文件格式（通常为JSON或CSV）。该层不应由分析师或服务访问，它应仅用于内部数据处理。
干净层-以优化的文件格式存储转换后的数据以供使用，在A公司的示例中为Parquet。该层中的数据进行了基本清理并应用了标准。该层应该被访问以进行探索性分析并用作星型模式的来源。
丰富层-存储经过良好处理的数据，这些数据还可以通过聚合和连接过程为每个原始表生成一个或多个表。该层还可用于探索性分析并用作星型模式的来源。
数据湖方法使A公司能够灵活地处理不同类型的数据，并为A公司以前无法提供帮助的不同产品提供支持，例如机器学习算法和预测分析，此外还支持分析公司的支柱，优化KPI和报告质量。借助云对象存储和Spark，A公司能够将存储需求与处理需求分开，而在ODS中，它们都在相同的Postgres架构。
二.Spark
Spark是A公司分布式体系结构的另一个支柱。它是一个分布式数据处理引擎，可以处理大量数据。它利用内存中的缓存和优化的查询执行，对任何大小的数据进行快速查询。Spark是最有效的数据处理框架，因为它能处理大数据集、速度快、整体灵活性强。它非常适合A公司当时的要求：在可行的时间内处理大量数据。
Databricks是A公司运行Spark的选择。Databrickss是一个基于云的平台，A公司可以在其中快速创建和部署Spark集群，并基于PySpark运行ETL。Databricks为A公司提供了Spark基础设施和集群管理。它非常好地遵守了AWS，并且很容易集成到A公司在Airflow的管道中，因为它有本地的通信运营商。
向DataLakehouse的转变
当时，A公司的数据平台基于AWSS3中的存储、通过Spark在Databricks中的数据处理、Airflow中的管道编排以及AWSRedshift中的数据仓库。尽管理论上Redshift是最后一层，但用户和数据服务可能仍然需要访问前一层的数据（例如数据湖的干净且可用的数据丰富层），这是通过Athena或RedshiftSpectrum功能完成的。A公司的目标是找到一种统一数据访问策略的方法，而不是依赖于三种不同的工具……然后DataLakehouse架构就开始发挥作用了！
DataLakehouse是一种全新的架构，旨在将数据仓库的数据结构和数据管理功能与低层架构相结合。通过将元数据层聚合到数据湖中存储的数据并独立于数据所在的层来统一数据的访问，从而降低数据湖的存储成本。
为了实现DataLakehouse架构，A公司需要在S3中存储的数据之上添加一个元数据层。该层将负责映射数据的元数据，并为A公司提供一些选项：
通过将查询引擎插入元数据层，A公司将拥有一个集中式访问点。集中式访问点将允许A公司执行联合查询。
元数据层将为A公司提供发展A公司的安全和治理平台所需的功能。从治理的角度来看，A公司将能够添加数据文档、地图数据沿袭，并添加自定义元数据，例如标签识别PII（个人身份信息）。从安全角度来看，A公司可以使用元数据来映射用户的信息，访问个人资料。
Redshift的扩展能力有限，只能水平扩展。平均而言，A公司的内存和CPU使用率达到了70%，而存储方面只有1%左右。因此，为了实现DataLakehouse架构，A公司选择用HiveMetastore和Trino的新堆栈替换Redshift（及其Spectrum功能）和Athena。
HiveMetastore是一个数据目录，负责管理和保留关系数据库中的元数据。Trino是一个高度并行的分布式查询引擎，能够查询PB级数据。
总而言之，A公司将存储迁移到分布式文件系统，非常注重职责明确的层（S3上的数据湖、数据仓库和Redshift上的数据集市）以及通过Airflow的ELT流。之后，A公司通过向堆栈添加CloudComposer（GCP完全托管的Airflow）来实现全云，它编排和管理A公司的管道，所有这些都依赖于通过Databricks在Spark上进行并行处理。
尽管改进后的架构非常引人注目，但在Redshift之上设计的分析层仍然不能很好地处理A公司频繁的扩展需求。因此，通过根据基于S3、Hive和Trino的LakeHouse策略替换Redshift上提供的数据仓库层，A公司向一流的LakeHouse架构又迈进了一步。
这些变化是超现实的！将每一层彼此解耦，使A公司能够单独、简单、快速地自定义和扩展各层，从而减少管理基础设施的工作量并降低总体成本。此外，A公司可以在更短的时间内处理更多的数据，从而减少交付时间并促进重新处理和回填。
作为与业务相关的结果，新的基础设施使A公司能够为用户提供更复杂的数据产品，例如基于流和现代机器学习产品的实时分析。
往期推荐