首页 > 编程知识 正文

空流数据大怎么回事,大数据流式计算与批量计算的比较

时间:2023-05-04 11:45:27 阅读:53019 作者:259

Lambda框架和Kappa框架本章内容包括: https://do cherish.com/post/da-Shu-ju-Chang-Yong-de-Jia-Gou-lambda-he-he

1.1 Lambda体系结构

Lambda架构基本介绍:

Lambda体系结构最初由storm创始人Nathan Marz提出,并介绍了我们目前所知的Lambda体系结构。

Lambda体系结构是有成见的,适用于大多数公司。 大多数公司从刚开始大数据技术的发展到现在都采用Lambda架构。

Lambda架构的离线和实时处理技术通过两条线,离线专用于离线数据处理,例如使用Hive、Impala、Presto、SparkSQL等各种OLAP技术框架例如Storm、SparkStreaming、Flink流处理程序等)

Lambda架构的核心思想:

数据从基础数据源开始,经过多种格式进入大数据平台,在大数据平台上经过Kafka、Flume等数据组件收集,并分为两条线进行计算。 线条是进入流计算平台(如Storm、Flink或Spark Streaming )并计算实时指标。 另一条线进入批量数据处理脱机计算平台,如Mapreduce、Hive和Spark SQL,用于计算与T 1相关的业务指标。 这些指标以隔日显示。

Lambda架构优缺点分分析:

Lambda体系结构经过多年的发展,其优点稳定,实时计算部分的计算成本可控,批处理在晚上的时间总体上可以批量计算。 这样将实时计算和离线计算的痴情之枕分开,支撑着数据行业的早期发展,但也有致命的缺点,在大数据3.0时代越来越不能适应数据分析业务的需要。

缺点如下。

实时和批处理计算结果不一致引起的数据口径问题:批处理和实时计算是两个计算框架和计算程序进行的,计算结果往往不同,一个数字当天是一个数据,第二天看昨天的数据反而变化批量计算不能在计算窗口内进行:在IOT时代,数据量的水平越来越大,晚上往往只有四五个小时的时间窗口,无法完成白天20小时以上的累计数据,保证早上上班前按时发出数据数据源更改需要重新开发,开发周期长:每次数据源格式更改、业务逻辑更改都需要对ETL和Streaming进行开发修改,整体开发周期长,业务响应充分服务器存储容量大—典型的数据仓库设计会生成大量的中间结果表,使数据快速增长,增加服务器存储的压力。 1.2 Kappa体系结构

Kappa架构基本介绍:

针对这些缺点(如需要维护Lambda体系结构的两个程序),LinkedIn的Jay Kreps结合实际经验和个人经验提出了Kappa体系结构。 Kappa体系结构的核心思想是通过改进流计算系统解决数据总量处理问题,并在实时计算和批处理过程中使用相同的代码集。

Kappa体系结构还认为,只有在需要时才能重复计算历史数据,但如果需要重复计算,则可以在Kappa体系结构下启动许多实例进行重复计算。 在33558www.Sina.com/kafka或MQ队列系统这样的系统中收集各种数据,需要几天的数据量存储几天。 如果需要进行总量重新计算,请重新创建流计算实例,从头开始处理,然后将其输出到新的结果存储。 新实例完成后,停止旧的流计算实例并删除部分旧结果。Kappa架构的核心思想:

Kappa体系结构的优点是将实时代码和脱机代码统一起来,从而方便地维护和统一数据口径问题。 Kappa的缺点也很明显。 流媒体处理无法应对历史数据的高吞吐量。 所有数据都是以流方式计算的,即使增加并发实例数,也很难满足IOT时代对数据查询响应的即时性要求。 开发周期长: Kappa体系结构中收集到的数据格式不一致,每次都需要开发不同的流程序,开发周期长。 浪费服务器成本: Kappa体系结构的核心原理取决于外部高性能存储Redis和HBase服务。 然而,这两种系统组件并非旨在满足整体数据存储设计,导致服务器成本极大浪费的两个数据场景的特征分析是当前广告召回的实际场景中的数据总量和更新频率这两个

各数据总量更新场景的应用技术分析如下

可综合得出初步结论:

在数据量较少的场景中,Kappa体系结构是一种更好的故障快速丢失防范和恢复方案,Lambda体系结构可以通过优化“切换”速度来弥补数据量较大的场景中的这一差距Lambda是构建速度和机器资源开销方面更好的方案。 但是,Lambda架构需要解决频繁切换大数据量时的服务稳定性问题

关于上述两个“优化方案的缺点”,说明如下。 数据经过“构建”“切换”两个阶段后生效,故障恢复时间变长

Lambda架构可以通过支持“数据热交换”功能和提高交换速度来弥补这一差距。 如果不能双缓冲,频繁切换大量数据会对在线服务的稳定性产生不良影响

三个未来的技术计划,将一次大数据更新分解为几个小数据更新,从而实现“双缓冲”

考虑到在线设备资源利用率和服务稳定性是平台化建设最重要的保障目标,基本确定系统未来将以Lambda架构为主体。 它还提供了类似Kappa体系结构的全量更新模式,以解决系统在出现故障时停止丢失/恢复和不可分割大数据频繁切换的场景中的稳定性和可靠性。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。