一个form如何做两次提交_如何做一个好的大数据平台架构

一、Lambda架构需求

Lambda架构背后的需求是由于MR架构的延迟问题。MR虽然实现了分布式、可扩展数据处理系统的目的&＃xff0c;但是在处理数据时延迟比较严重。实际上如果内存和CPU足够强大&＃xff0c;MR也可以实现近实时运算&＃xff0c;但实际业务环境并非如此&＃xff0c;因此我们需要权衡&＃xff0c;选择实时处理和批处理所需要数据量和恰当的资源。2012年Storm的作者Nathan Marz提出的Lambda数据处理框架。Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构&＃xff0c;包括有&＃xff1a;高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算&＃xff0c;融合不可变性(Immunability)&＃xff0c;读写分离和复杂性隔离等一系列架构原则&＃xff0c;可集成Hadoop&＃xff0c;Kafka&＃xff0c;Storm&＃xff0c;Spark&＃xff0c;Hbase等各类大数据组件。二、Lambda架构的关键

• 横向扩容

可扩展性意味着为满足日益增长的用户服务需求&＃xff0c;同时不用对底层架构或者代码&＃xff0c;可以通过现有机器添加内存或者磁盘资源来实现(垂直扩展)&＃xff0c;或者可以通过在集群中添加机器实现(水平扩展)。无论是实时或者批处理&＃xff0c;都应该能够不停服务的情况下&＃xff0c;可以实施水平扩展。

• 故障容错

系统需要妥善处理故障&＃xff0c;确保系统在某些组件发生故障的情况下&＃xff0c;整个系统服务的可用性。可能部分组件故障会导致集群中部分节点宕机&＃xff0c;影响了整理的SLA&＃xff0c;但是系统还是可以相应的&＃xff0c;系统不能有单点故障。

• 低延迟

很多应用对于读和写操作的延时要求非常高&＃xff0c;要求对更新和查询的响应是低延时的。

• 可扩展

系统需要足够灵活&＃xff0c;能够实现新增和修改需求&＃xff0c;又不需要重构整个系统。实时处理和批处理隔离开&＃xff0c;能够灵活修改需求。

• 易维护

开发部署不能够太复杂。

三、Lambda架构的分层

在Lambda架构中新数据到达时&＃xff0c;会被同时分派到批处理层和快速处理层。一旦数据到达批处理层&＃xff0c;按照常规批处理时间间隔&＃xff0c;每次都从头开始重新计算并生成批处理视图。类似地&＃xff0c;只要新数据到达快速处理层&＃xff0c;快速处理层就会使用新数据生成快速视图。在查询到达服务层时&＃xff0c;它会合并快速视图和批处理视图来生成适当的查询结果。生成批处理视图后&＃xff0c;快速视图将被丢弃&＃xff0c;除非有新数据抵达&＃xff0c;否则只需要查询批处理视图&＃xff0c;因为此时批处理层中拥有所有的数据。

Lambda架构定义主要层以及每个组件之间的集成。注意分为以下层&＃xff1a;

• 数据源

数据源指外部的数据库、消息队列、文件等&＃xff0c;可以开发数据消费层&＃xff0c;隐藏来自不同访问数据的复杂性&＃xff0c;定义好数据格式。

• 数据消费层

负责封装不能数据源获取数据的复杂性&＃xff0c;将其转换可由批处理或者流处理进一步使用同一的格式进行消费。

• 批处理层

这是Lambda架构核心层之一&＃xff0c;批处理接受数据&＃xff0c;持久化到用户定义好的数据结构中&＃xff0c;维护着主数据。数据结构一般不做改变&＃xff0c;只是追加数据。批处理还负责创建和维护批处理视图。比如我们常做的Hive ETL ,统计一些数据&＃xff0c;最后将结果保存在hive表中&＃xff0c;或者数据库中&＃xff0c;就属于批处理层。

• 实时层

这是Lambda另一个核心层。批处理在很多场景下能够满足需求&＃xff0c;但是随着业务需求“苛刻性”&＃xff0c;他们希望能够及时看到数据&＃xff0c;而不是等到第二天才看指标变化和分析结果。所以引入了实时处理。实时层解决了一个问题&＃xff0c;即只存储可立即向用户提供的一组数据&＃xff0c;这样就不需要对全量数据进行处理&＃xff0c;大大提供处理效率。比如流处理仅仅存储最近5分钟的数据&＃xff0c;处理计算并形成结果&＃xff0c;这就是我们用spark streaming中要有的时间窗口。

• 服务层

这是Lambda架构的最后一层&＃xff0c;服务层的职责是获取批处理和流处理的结果&＃xff0c;向用户提供统一查询视图服务。

四、Lambda架构总结

Lambda数据架构曾经成为每一个公司大数据平台必备的架构&＃xff0c;它解决了一个公司大数据批量离线处理和实时数据处理的需求。

数据从底层的数据源开始&＃xff0c;经过各种各样的格式进入大数据平台&＃xff0c;在大数据平台中经过Kafka、Flume等数据组件进行收集&＃xff0c;然后分成两条线进行计算。一条线是进入流式计算平台(例如 Storm、Flink或者Spark Streaming)&＃xff0c;去计算实时的一些指标&＃xff1b;另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive&＃xff0c;Spark SQL)&＃xff0c;去计算T&＃43;1的相关业务指标&＃xff0c;这些指标需要隔日才能看见。

Lambda架构经历多年的发展&＃xff0c;非常稳定&＃xff0c;对于实时计算部分的计算成本可控&＃xff0c;批量处理可以用晚上的时间来整体批量计算&＃xff0c;这样把实时计算和离线计算高峰分开&＃xff0c;这种架构支撑了数据行业的早期发展&＃xff0c;但是它也有一些致命缺点&＃xff1a;

• 实时与批量计算结果不一致

因为批量和实时计算走的是两个计算框架和计算程序&＃xff0c;算出的结果往往不同&＃xff0c;经常看到一个数字当天看是一个数据&＃xff0c;第二天看昨天的数据反而发生了变化。

• 批处理的健壮性

随着数据量级越来越大&＃xff0c;经常发现夜间只有4、5个小时的时间窗口&＃xff0c;已经无法完成白天20多个小时累计的数据&＃xff0c;保证早上上班前准时出数据已成为每个大数据团队头疼的问题&＃xff0c;同时做个任务并行执行对于大数据集群的稳定性也是巨大的考验&＃xff0c;经常会有任务因为资源不足没有定时启动或者报错。

• 开发和维护的复杂

Lambda 架构中对同样的业务逻辑进行两次编程&＃xff1a;一次为批量计算的ETL系统&＃xff0c;一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库&＃xff0c;各有不同的漏洞。

• 存储增长快

数据仓库的设计不合理&＃xff0c;会产生大量的中间结果表&＃xff0c;造成数据急速膨胀&＃xff0c;加大服务器存储压力。比如我们经常纠结于数据仓库到底怎么分层&＃xff0c;是直接ODS层到应用呢&＃xff1f;还是ODS层要景观DWS、DW等&＃xff0c;最后才到应用呢&＃xff1f;

Lambda架构虽然有缺点&＃xff0c;但是在很多公司依然适用&＃xff0c;有时候我们没有那么大的业务量&＃xff0c;实时业务需求并没有那么明显&＃xff0c;用着Lambda架构依然很爽。对于超大数据量的业务或者实时业务同样多的情况&＃xff0c;可以探索改良Lambda&＃xff0c;业内也提出了Kappa架构&＃xff0c;感兴趣的小伙伴可以搜索学习下。

推荐阅读

如何从0到1搭建大数据平台

用 Django 开发一个 Python Web API

高性能 Pandas 方法&＃xff1a;query 和 eval

社区会员

点赞鼓励一下