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公司能夠為用戶提供更復雜的數據產品，例如基于流和現代機器學習產品的實時分析。
