处理层负责将数据从存储层的“原始（Raw）”部分转换为数据湖的“列式（Columnarized）”部分中的标准化列式和分区结构。我们使用Lambda架构来协调给定数据源的批和流数据，这种数据处理模型使我们能够将高质量的批量快照与一分钟延迟流文件相结合来生成给定数据集的最新列式版本。我们将AWS Glue及其Data Catalog（数据目录）用作数据湖的中央metastore管理服务，metastore包含每个数据集的元数据，例如在S3中的位置、结构定义和整体大小，也可以使用AWS Glue Crawlers捕获和更新该元数据，整个流程如下：
调度层启动处理特定数据集Lambda架构的DAG。
DAG将PySpark应用程序加载到S3，启动AWS EMR集群，并在EMR中运行PySpark应用程序。
来自存储层“原始”部分的批和流数据均作为EMR Spark应用程序的输入，最终输出是存储层“列式”部分中使用Lambda架构进行协调的Parquet数据集。
完成EMR步骤后终止EMR集群以便降低EMR成本。
运行AWS Glue Crawler程序以更新AWS Glue目录中表的元数据，该目录元数据充当整个数据湖的中央metastore。
S3作为存储平台的原因有以下三个：易用性、高可靠性和相对低成本。数据存储在存储层中的“原始”和“列式”两部分都基于S3，而“数仓（Warehouse）”中的数据位于Redshift集群中。数据湖中的所有数据首先通过摄入层以各种格式进入“Raw”部分，为了使数据保存到“列式”部分中，数据会通过处理层转换为“列式”部分，并遵守分区标准。我们选择Apache Parquet作为标准列式文件格式，因为Apache Parquet广泛用于数据处理服务中，并且具有性能和存储优势。存储层的“数仓”部分由Redshift数据仓库组成，其数据来自“原始”和“列式”部分。还可以通过数据“热度”对存储层的各部分进行分类，类比于数据的访问频率，“原始”数据数据最冷，“列式”数据比“原始”数据更热，而“数仓”数据是最热的数据，因为它经常会被自动化仪表板和报告访问。S3的另一个优势是我们能够根据数据规模控制成本，对于较冷的数据，我们可以更变S3存储类型或者将数据迁移到AWS Glacier以降低成本。
5.5 从数据湖访问数据技术团队和非技术团队都会使用数据湖，以便更好地为决策提供依据并增强整体产品体验，非技术团队通常通过商业智能平台Looker来访问数据，以自动化仪表板和报告的形式监控各项指标。
技术团队应用范围更广，从探索性分析中的即席查询到开发机器学习模型和管道。可以通过AWS Athena托管的Presto服务或通过Redshift数据仓库直接查询数据湖中的数据。AWS Athena还与AWS Glue的数据目录集成，这使Athena可以完全访问我们的中央metastore，这种原生集成使得Athena可以充当S3中存储数据的主要查询服务。我们还能够利用Redshift Spectrum查询S3数据，这在即席查询场景下特别有用，我们也希望使用S3的数据来丰富Redshift集群的数据。为了对机器学习模型进行更正式的探索性分析和开发，需要结合使用Spark和Glue目录来查询或直接与S3中的对象进行交互。
5.6 检查与监控确保数据湖的消费者完全信任数据的准确性至关重要，我们建立了一套全面的检查和监控程序以提醒我们任何意外情况。我们通过Airflow DAG构建的绝大多数数据湖流程，并且能够使用Datadog监视Airflow作业失败，并通过PagerDuty将关键问题转发给工程师。为了建立数据质量检查，我们还构建了一系列Airflow DAG，以生成特定数据集的自定义数据验证指标，我们在给定数据集上运行的一组标准的验证检查和指标包括但不限于空检查、行计数检查和数据延迟指标，这些指标都会被推送到Datadog，这样便可以在其中监视异常并在必要时向参与者发出告警。