数据分析流程中的Lambda架构，以及数据湖基于Hadoop、Spark的实现

一、Lambda架构

1、Lambda的三层架构

Batch View（批处理视图层）
Speed Layer（速度层）（实时处理层）
Serving Layer（服务层）

2、简单解释：

• 1、批处理视图层：负责处理大量的历史数据，生成批处理视图，这个视图通常是基于固定时间间隔（如每天、每小时）对数据进行处理得到的，也就是离线分析的部分
• 2、速度层：处理实时数据，对最新的数据进行增量计算，补充批处理层的结果
• 3、服务层：用于合并批处理层和速度层的结果，并将最终的结果提供给用户或其他应用程序（比如MySQL）

总结下来，Lambda架构就是下面三个等式：

# function 就是作用在数据集上的函数
batch view = function(all data)
# 其中参数中的 realtime view 就是不断的对以后的 realtime view 进行迭代更新，知道被 batch view 追上丢弃
realtime view = function(realtime view,new data)
# 服务层就是对 批处理视图 和 实时处理层 的结果进行动态合并
serving layer = function(batch view + realtime view)

3、Lambda架构的优缺点

优点：

• 成熟稳定、实时计算成本可控、批处理利用了系统空闲时间、将离线和实时分析高峰错开来

缺点：

• 实时和批处理结果不一致、批量计算无法在有限时间内完成、开发维护困难、中间数据的产生会导致服务器存储开销大

二、数据湖基于Hadoop、Spark的实现

1、架构

其中HDFS实现了海量数据存储，Spark、MR、Flink等实现了海量数据分析
所以说，Hadoop生态本质上就是数据湖最合适的实现方案

针对某个业务搭建的数仓可视化平台的架构和这个数据湖架构几乎一样，但是区别就在于数据来源（数仓可视化平台是经过修饰的数据，而数据湖是未被修饰的数据）

2、数据管理（存储层的辅助功能）

• 数据安全：数据湖中的数据要保证其安全性
• 审计：对数据进行全面的审查和分析，以确定数据是否符合特定的标准和要求，目前大多数做法就是开启NameNode的审计日志，读取并导入其他日志处理框架中。但是读取NameNode的审计日志比较难，而Delta Lake就很好的做到了这一点。
• 元数据管理：数据湖中的数据又多又杂，如果没有元数据管理，很容易变成数据沼泽，也就是数据垃圾。