本文聚焦在数据平台层面的转型实践，强调在规模化增长环境下，如何通过 Lakehouse 架构实现可扩展性与数据治理能力的提升。以下内容对架构、组件以及实现策略进行梳理，保留原文中的图片占位符 [[[IMG_n]]]，以便在后续整合时保持一致的媒体引用。
新架构
在面向未来的数据平台中，平台架构被划分为多层，目标是将数据从摄取到分析的整个流程清晰分离、可扩展且成本可控。以下是经过改进的架构要点与层级划分。
- 数据摄取/提取层
该层关注在原始区域内获取数据，随后在处理区域进行使用与加工。大多数点击流捕获工具都提供内置的数据摄取能力，便于把原始区域的数据接入后续处理。对于事务性数据源（如 MySQL、PostgreSQL 等），采用基于 CDC 的提取策略。基础设施以云环境托管，因此选用了相应的 CDC 迁移服务来执行迁移。
- 处理层
在此阶段避免大规模转换，而是将原始数据转化为适合存储和处理的列式格式。原始数据以多种格式（CSV、JSON 等）进入，需转换为列格式（如 Parquet），以提升在数据湖中的处理效率。类型转换会以数据湖的兼容性为准，时区统一为目标时区时间戳。
- 转换层
面对大规模数据处理与成本控制的挑战，选用分布式处理框架实现数据转换与建模。该层在数据仓库中形成数据模型，支撑报表与仪表板的底层数据需求。
- 报告层
报告层聚合来自维度表与事实表的数据，提供下游分析视图。大多数仪表板依赖这些报表与物化视图，降低跨表连接的重复计算成本。平台在层级划分清晰的情况下，选择合适的工具组合以覆盖大多数下游用例。
进一步了解平台所用组件时，涉及的环节包括：管理系统、数据存储、处理与编排、分析与查询、以及监控与自动化等。
涉及的组件
- 管理系统
数据迁移与变更捕获工具用于从源数据库读取变更并写入目标存储。通过自动化脚本与云服务实现资源创建与参数配置，便于在控制表中添加新表或调整原始区域设置。
- S3 – 原始区域
变更捕获数据以分区化方式存储在原始区域，按插入或更新进行追加，保持数据未清洗的原始状态。原始区域是后续数据集回填与处理的基础层，同时承载从点击流工具等来源摄取的数据。
- EMR – HUDI + PySpark
HUDI 用于对数据湖中的数据执行 UPSERT，PySpark 作业定时从原始区域读取数据、处理后写入处理区域，使处理区域具备对源系统行为的复制能力。
- S3 – 处理区
数据湖的处理区用于存放可变与不可变数据集。HUDI 用于维护可变数据，未变数据以列式格式转存至处理区并管理分区以优化查询。
- Glue 数据目录
注册表用于统一元数据管理，Athena 可基于注册表在临时分析场景中进行查询。
- Athena
作为无服务器查询引擎，处理数据湖中的数据集的临时分析请求。
- Redshift
作为数据仓库，支撑报告与 BI 场景。数据模型分层存放在不同层级，包含事实与维度等数据结构，并维护物化视图以提高聚合性能；同时实现了 SCD 类型 1/2 以追踪历史变化。
- MWAA
用于编排工作流，确保数据管道的有序执行。
- 日志与监控
通过监控与告警系统（如云监控、集中日志栈）实现对各组件的可观测性。
- DynaModb
用于对失败事件进行记录与重处理，建立再处理框架以按计划将未处理的事件推送回控制表。
二、为何采用基于 CDC 的方法
在数据工程早期阶段，基于时间戳的数据迁移是常见做法。随着业务增长，数据规模呈指数级扩大，单一迁移实例难以承担，成本随之上升。
面临的问题包括：源端产生高量数据导致迁移集群膨胀、数据质量在未更新变更列时存在风险、以及在目标端处理架构变更的复杂性。通过启用源数据库的日志捕获（如 MySQL 的二进制日志、PostgreSQL 的 WAL），可以持续读取变更并生成新的事件文件。为控制成本，通常将日志轮询频率设定为较低单位时间，逐步增加迁移吞吐，并通过 CDC 解决数据量快速增长带来的挑战，确保以更高的分钟级粒度进行迁移，同时降低对下游查询的影响。
三、使用 Apache Hudi
HUDI 为开放数据湖提供内置支持。引入 HUDI 时，需解决若干挑战并制定策略以确保数据一致性与查询效率。
- 最大提交保留策略
HUDI 根据配置保留历史提交。为满足 75 分钟内完成 ETL 的需求，将 hoodie.cleaner.commits.retained 设置为 15，确保增量查询不中断，同时考虑压缩和扩展带来的影响，制定合适的清理策略。
- 分区表的确定
在数据湖中合理分区可显著降低扫描量并提升查询性能；历史数据可归档到其他存储层以优化成本与访问性。
- 存储类型的选择
HUDI 支持多种存储类型，需结合用例和工作负载选择。低延迟访问场景选用 MoR，较高延迟容忍场景可选 CoW。
- MoR 视图的应用
MoR 提供 _Ro（读取优化）与 _Rt（实时）视图，需根据 ETL 与报告需求选取对应视图。
- HUDI 索引
全局与非全局索引有助于提升 UPSERT 与查询性能。默认 Bloom 索引结合静态列选择非全局索引，利用提交时间来推断增量数据，降低迟到数据的处理难度。
五、为何框架驱动
此前多为管道驱动的实现方式，在平台 2.0 中引入框架驱动概念，在各层构建通用框架（如数据摄取框架、数据处理框架、报告框架），通过预定义输入执行特定任务，从而减少冗余代码，简化新表的加载与维护。
- 表格化控制平面的优势
控制平面存储元数据，帮助在数据湖与数据仓库中加载新表并管理迁移配置。元数据在自动化与管道控制方面至关重要，通常选择合适的数据库存储与 API 层，以支持审计和数据安全。
- 自动化
通过持续集成与按钮化操作实现流水线自动化，利用脚本与云服务快速创建 DMS 等资源。
- 记录、监控与告警
为各组件提供监控与告警，确保在系统异常时能够及时发现并响应。
- 工作流编排
依然使用成熟的编排工具，以 MWAA 为核心，提升维护性与成本效益，并在部署中持续优化。
五、概括
本文回顾了 Lake House 架构下的数据平台 2.0 的核心组件及实现要点，重点在于把 HUDI 应用于数据湖，提升数据处理与分析能力。随着基础设施的搭建就绪，后续将聚焦以下方向：提升数据质量、完善元数据与治理能力、优化成本与性能，以及进一步增强下游分析的稳定性与可扩展性。
