下一代大数据即时分析架构

  • 时间:
  • 浏览:0
  • 来源:彩神大发时时彩_神彩大发时时彩官方

有有另一一两个典型的Kappa架构如下图所示:

● 批量计算在计算窗口内无法完成:在IOT时代,数据量级那么 大,另一一两个劲发现夜间那么4、一两个小时的时间窗口,或者无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题报告 。

● 实时与批量计算结果不一致引起的数据口径问题报告 :或者批量和实时计算走的是有有另一一两个计算框架和计算任务管理器,算出的结果往往不同,另一一两个劲看一遍有有另一一两个数字当天看是有有另一一两个数据,第多日看昨天的数据反而处于了变化。



本文对比了 Lambda数据架构的痛点,通过实践和总结出新一代大数据分析架构IOTA架构,欢迎加入微信群讨论

● 开发周期长:此外Kappa架构下或者整理的数据格式的不统一,每次都前要开发不同的Streaming任务管理器,导致 开发周期长。

●数据源变化前要重新开发,开发周期长:每次数据源的格式变化,业务的逻辑变化都前要针对ETL和Streaming做开发修改,整体开发周期很长,业务反应不足越来飞快。

在过去Lambda数据架构成为每有有另一一两个公司大数据平台必备的架构,它解决了有有另一一两个公司大数据批量离线解决和实时数据解决的需求。有有另一一两个典型的Lambda架构如下:

关于IOTA架构的分析请查阅附件!

1.用Kafka或者之类MQ队列系统整理各种各样的数据,你前要几天的数据量就保存几天。

IOTA架构

● 流式解决对于历史数据的高吞吐量力不从心:所有的数据都通过流式计算,即便通过加大并发实例数亦太难适应IOT时代对数据查询响应的即时性要求。

数据从底层的数据源刚开始,经过各种各样的格式进入大数据平台,在大数据平台中经过Kafka、Flume等数据组件进行整理,或者分成两条线进行计算。每根绳子 线是进入流式计算平台(之类 Storm、Flink或者Spark Streaming),去计算实时的其他指标;另每根绳子 线进入批量数据解决离线计算平台(之类Mapreduce、Hive,Spark SQL),去计算T+1的相关业务指标,那此指标前要隔日并能看见。

Lambda架构经历多年的发展,其优点是稳定,对于实时计算部分的计算成本可控,批量解决能并能用晚上的时间来整体批量计算,另有另一一两个把实时计算和离线计算高峰分开,这一 架构支撑了数据行业的早期发展,或者它前要其他致命缺点,并在大数据3.0时代那么 不适应数据分析业务的需求。缺点如下:

而在IOT大潮下,智能手机、PC、智能硬件设备的计算能力那么 强,而业务需求要求数据实时响应需求能力也那么 强,过去传统的中心化、非实时化数据解决的思路或者不适应现在的大数据分析需求,我提出新一代的大数据IOTA架构来解决上述问题报告 ,整体思路是设定标准数据模型,通过边缘计算技术把所有的计算过程分散在数据产生、计算和查询过程当中,以统一的数据模型贯穿始终,从而提高整体的预算波特率,一起满足即时计算的前要,能并能使用各种Ad-hoc Query来查询底层数据。

▌Lambda架构

3.当新的实例做事先,停止老的流计算实例,并把老的其他结果删除。

Kappa架构的核心思想,包括以下三点:

针对Lambda架构的前要维护两套任务管理器等以上缺点,LinkedIn的Jay Kreps结合实际经验和被委托人体会提出了Kappa架构。Kappa架构的核心思想是通过改进流计算系统来解决数据全量解决的问题报告 ,使得实时计算和批解决过程使用同一套代码。此外Kappa架构认为那么在有必要的事先才会对历史数据进行重复计算,而或者前要重复计算时,Kappa架构下能并能启动什么都有个实例进行重复计算。

Kappa架构的优点在于将实时和离线代码统一起来,方便维护或者统一了数据口径的问题报告 。而Kappa的缺点也很明显:



 

● 服务器存储大:数据仓库的典型设计,会产生少许的上端结果表,造成数据疾速膨胀,加大服务器存储压力。 

2.当前要全量重新计算时,重新起有有另一一两个流计算实例,从头刚开始读取数据进行解决,并输出到有有另一一两个新的结果存储中。

▌Kappa架构

● 服务器成本浪费:Kappa架构的核心原理依赖于内部高性能存储redis,hbase服务。或者这2种系统组件,又并不设计来满足全量数据存储设计,对服务器成本严重浪费。

经过那么 多年的发展,或者从大数据1.0的BI/Datawarehouse时代,经过大数据2.0的Web/APP过渡,进入到了IOT的大数据3.0时代,而随之而来的是数据架构的变化。