本文介绍了“Apache Spark的Lambda架构示例分析”的知识。很多人在实际案例的操作中会遇到这样的困难。接下来,让边肖带领大家学习如何应对这些情况!希望大家认真阅读,学点东西!
Apache Hadoop简史
Apache Hadoop是由Apache软件基金会于2005年秋季作为Lucene的子项目Nutch的一部分正式引入的。它的灵感来自* *地图/减少和谷歌实验室开发的谷歌文件系统(GFS)。这已经是一个独立的项目10年了。
目前,许多客户已经实现了基于Hadoop的M/R管道,并已成功运行至今:
ozie的工作流程每天运行,处理超过150TB的数据并生成分析报告。
Bash的工作流每天运行,处理超过8TB的数据并生成分析报告。
2016年来了!
2016年商业现实发生了变化,你做决定的速度越快,价值就越大。此外,技术本身也在发展。Kafka、Storm、Trident、Samza、Spark、Flink、Parquet、Avro、云提供商等等都成为了工程师们的流行语。
因此,现代基于Hadoop的M/R管道可能如下图所示:
图中的M/R通道看起来不错,但实际上还是传统的批量处理,存在传统批量处理的弊端。当新数据不断进入系统时,仍然需要大量的时间来处理。
Lambda 架构
针对上述问题,Nathan Marz提出了一种通用的、可扩展的、容错的数据处理架构,即Lambda架构,该架构采用批处理和流处理的方法处理大量数据。Nathan Marz的书从源代码的角度详细介绍了Lambda架构。
层结构
这是Lambda架构的自顶向下的层结构:
进入系统后,所有数据被分配到批处理层和速度层进行处理。批处理层管理主数据集(只能添加的不可更改的原始数据集)并预先计算批处理视图。服务层为批处理视图编制索引,以便可以进行低延迟的临时查询。速度层只处理最近的数据。的所有查询结果必须结合批处理视图和实时视图的查询结果。
大意
很多工程师认为Lambda架构只包含层结构和定义数据流,但是Nathan Marz的书向我们介绍了其他几个要点:
分布式思维
避免增量结构。
数据的不变性
创建重新计算算法
数据相关性
如前所述,任何查询结果都必须从批处理视图和实时视图中合并,因此这些视图必须是可合并的。这里需要注意的是,实时视图是以前的实时视图和新数据增量的函数,所以这里使用增量算法,批处理视图是所有数据的函数,所以应该使用重新计算算法。
权衡
世间万物都在不断的妥协与平衡中发展,Lambda结构也不例外。一般来说,我们需要解决几个主要的权衡问题:
完全重新计算 vs.部分重新计算
在某些情况下,可以使用布隆过滤器来避免完全重新计算。
重计算算法 vs. 增量算法
增量算法其实很有吸引力,但有时候根据准则,我们不得不使用重新计算算法,即使很难得到同样的结果。
加法算法 vs. 近似算法
虽然Lambda架构可以很好地与加法算法配合使用,但在某些情况下更适合使用近似算法,例如使用HyperLogLog处理计数-distinct问题。
实现
p>实现Lambda架构的方法有很多,因为每个层的底层解决方案是独立的。每个层需要底层实现的特定功能,有助于做出更好的选择并避免过度决策:
-
批量层:一次写入,批量读取多次
-
服务层:支持随机读取但不支持随机写入; 批量计算和批量写入
-
速度层:随机读写; 增量计算
例如,其中一个实现(使用Kafka,Apache Hadoop,Voldemort,Twitter Storm,Cassandra)可能如下所示:
Apache Spark
Apache Spark被视为在所有Lambda架构层上进行处理的集成解决方案。 其中Spark Core包含了高级API和支持常规执行图的优化引擎,SparkSQL用于SQL和结构化数据处理,Spark Streaming支持实时数据流的可扩展,高吞吐量,容错流处理。 当然,使用Spark进行批处理的价格可能比较高,而且也不是所有的场景和数据都适合。但是,总体来说Apache Spark是对Lambda架构的合理实现。
示例应用
我们创建一个示例应用程序来演示Lambda架构。这个示例的主要目的统计从某个时刻到现在此刻的#morningatlohika tweets哈希标签。
批处理视图
为了简单起见,假设我们的主数据集包含自时间开始以来的所有tweets。 此外,我们实现了一个批处理,创建了我们的业务目标所需的批处理视图,因此我们有一个预计算的批处理视图,其中包含与#morningatlohika一起使用的所有主题标记的统计信息:
因为数字方便记忆,所以我使用对应标签的英文单词的字母数目作为编号。
实时视图
当应用程序启动并运行时,有人发出了如下的tweet:
在这种情况下,正确的实时视图应包含以下标签及其统计信息(在我们的示例中为1,因为相应的hash标签只使用了一次):
查询
当终端用户查询hash标签的统计结果时,我们只需要将批量视图与实时视图合并起来。 所以输出应该如下所示:
场景
示例场景的简化步骤如下:
-
通过Apache Spark创建批处理视图(.parquet)
-
在Apache Spark中缓存批处理视图
-
流应用程序连接到Twitter
-
实时监控#morningatlohika tweets
-
构建增量实时视图
-
查询,即合并批处理视图和实时视图
技术细节
源代码基于Apache Spark 1.6.x,(在引入结构化流之前)。 Spark Streaming架构是纯微型批处理架构:
所以处理流应用程序时,我使用DStream连接使用TwitterUtils的Twitter:
在每个微批次(使用可配置的批处理间隔),对新的tweets中hashtags的统计信息的计算,并使用updateStateByKey()状态转换函数更新实时视图的状态。 为了简单起见,使用临时表将实时视图存储在存储器中。
查询服务反映批处理和实时视图的合并:
输出
文章开头提到的基于Hadoop的M/R管道使用Apache Spark来优化:
后记:
正如之前提到的Lambda Architecture有其优点和缺点,所以支持者和反对者都有。 有些人说批处理视图和实时视图有很多重复的逻辑,因为最终他们需要从查询角度创建可合并的视图。 所以他们创建了一个Kappa架构,并称其为Lambda架构的简化版。 Kappa架构系统是删除了批处理系统,取而代之的是通过流系统快速提供数据:
但即使在这种情况下,Kappa Architecture中也可以应用Apache Spark,例如流处理系统:
“Apache Spark的Lambda架构示例分析”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站,小编将为大家输出更多高质量的实用文章!
内容来源网络,如有侵权,联系删除,本文地址:https://www.230890.com/zhan/145796.html