欢迎你们前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~java
市场上的许多玩家已经创建了成功的MapReduce工做流程来天天处理以TB计的历史数据。可是谁愿意等待24小时才能得到最新的分析结果?这篇博文将向您介绍旨在利用批处理和流处理方法的Lambda架构。咱们将利用Apache Spark(Core,SQL,Streaming),Apache Parquet,Twitter Stream等实时流数据快速访问历史数据。还包括清晰的代码和直观的演示!git
Apache Hadoop的丰富历史始于2002年。Hadoop由Doug Cutting建立,Doug Cutting是Apache Lucene(一个被普遍使用的文本搜索库)的建立者。Hadoop起源于Apache Nutch,一个开源的网络搜索引擎,它自己就是Lucene项目的一部分。它在10年前成为一个独立的项目。github
所以,大量客户实施了有效的基于Hadoop的M/R处理管道。现实生活中有一些很好的例子:算法
商业现实已经发生了变化,因此如今更快作出的决定更有价值。除此以外,技术也在不断发展。Kafka,Storm,Trident,Samza,Spark,Flink,Parquet,Avro,Cloud providers等都是工程师和企业普遍采用的流行语。apache
所以,现代基于Hadoop的M/R管道(使用Kafka,Avro和数据仓库等现代二进制格式,即Amazon Redshift,用于临时查询)可能采用如下方式:缓存
这看起来至关不错,但它仍然是一种传统的批处理方式,具备全部已知的缺点,主要缘由是客户端的数据在批处理花费大量时间完成以前的数据处理时,新的数据已经进入而致使数据过期。bash
Nathan Marz针对通用的,可扩展的和容错的数据处理架构提出了术语Lambda Architecture。它是一种旨在经过利用批处理和流处理这二者的优点来处理大量数据的数据处理架构。网络
我强烈建议阅读Nathan Marz的书,由于它从提出者的角度提供了Lambda Architecture的完整表述。架构
从宏观角度看,它的处理流程以下:app
全部进入系统的数据都被分配到批处理层和速度层进行处理。批处理层管理主数据集(一个不可变的,仅可扩展的原始数据集)并预先计算批处理视图。服务层对批处理视图进行索引,以即可以在低延迟的状况下进行点对点查询。速度层只处理最近的数据。任何传入的查询都必须经过合并来自批量视图和实时视图的结果来获得结果。
许多工程师认为Lambda Architecture是所有关于这些层次和定义的数据流的,但Nathan Marz在他的书中将重点放在其余重要方面,如:
如前所述,任何传入查询都必须经过合并来自批量视图和实时视图的结果来获得答案,所以这些视图须要可合并性。须要注意的一点是,实时视图是之前的实时视图和新数据增量的函数,所以可使用增量算法。批处理视图是全部数据的函数,所以应该在那里使用重算算法。
咱们生活中的每一件事都是一种折衷,而Lambda Architecture也不是一个例外。一般,咱们须要解决一些主要的折衷:
有多种实现Lambda体系结构的方法,由于它对于每一个层的底层解决方案都是不可知的。每一层都须要底层实现的特定功能,这可能有助于作出更好的选择并避免过分的决定:
例如,其中一个实现(使用Kafka,Apache Hadoop,Voldemort,Twitter Storm,Cassandra)可能以下所示:
Apache Spark能够被视为在全部Lambda体系结构层上处理的集成解决方案。它包含Spark Core,包括高层次的API,而且支持通用执行图表的优化引擎,Spark SQL为SQL和结构化数据提供处理,以及Spark Streaming,支持可扩展性,高吞吐量,容错流的实时数据流的处理。固然,使用Spark进行批量处理可能会很是昂贵,而且可能不适合全部场景和数据量,但除此以外,它是Lambda Architecture实施方案的适当匹配。
让咱们用一些捷径建立一个示例应用程序来演示Lambda架构,这个程序的主要目标是提供在#morningatlohika推文中使用的主题标签统计数据。
源代码位于GitHub上,关于上述主题的更多视觉信息位于Slideshare上。
批处理视图
为了简单起见,假设咱们的主数据集包含自开始以来的全部推文。另外,咱们实施了批量处理,建立咱们业务目标所需的批处理视图,所以咱们有一个预先计算的批处理视图,其中包含与#morningatlohika一块儿使用的全部主题标签统计信息:
apache – 6 architecture – 12 aws – 3 java – 4 jeeconf – 7 lambda – 6 morningatlohika – 15 simpleworkflow – 14 spark – 5
数字很容易记住,由于我简单地在相应的主题标签中使用了许多字母。
实时视图
想象一下,当应用程序启动并运行时,如今有人正在发送推文消息:
“ @tmatyashovsky关于 #lambda #architecture使用 #apache #spark在#morningatlohika的酷博客文章 ”
在这种状况下,适当的实时视图应该包含如下hash标签和它们的统计信息(在咱们的例子中仅为1,由于相应的hash标签只用了一次):
apache – 1 architecture – 1 lambda – 1 morningatlohika – 1 spark – 1
查询
当客户端为了实时获得全部的Hash标签的统计结果进行查询时,咱们只须要将批量视图与实时视图合并便可。因此输出应该以下所示(适当的hashtags的统计数字增长1):
apache – 7 architecture – 13 aws – 3 java – 4 jeeconf – 7 lambda – 7 morningatlohika – 16 simpleworkflow – 14 spark – 6
演示方案
演示场景的简化步骤以下:
技术细节
源代码基于Apache Spark 1.6.x,即在引入结构化流式传输以前。Spark Streaming架构是纯粹的微批处理架构:
所以,对于流媒体应用程序,我是用DSTREAM使用链接到Twitter TwitterUtils:
JavaDStream < Status > twitterStatuses = TwitterUtils.createStream ( javaStreamingContext,createTwitterAuthorization (),new String [ ] {twitterFilterText } );
在每一个微批处理中(使用可配置的批处理间隔),我正在执行新推文中hashtags统计的计算,并使用updateStateByKey()有状态转换更新实时视图的状态。为了简单起见,使用临时表将实时视图存储在内存中。
查询服务反映了经过代码显式合并由DataFrame表示的批处理视图和实时视图:
DataFrame realTimeView = streamingService . getRealTimeView ( ) ; DataFrame batchView = servingService . getBatchView ( ) ; DataFrame mergedView = realTimeView . unionAll ( batchView ) . groupBy ( realTimeView . col ( HASH_TAG . getValue ( ) ) ) . sum ( COUNT . getValue ( ) ) . orderBy ( HASH_TAG . getValue ( ) ) ; List < Row > merged = mergedView . collectAsList ( ) ; return merged . stream ( ) . map ( row - > new HashTagCount ( row . getString ( 0 ) , row . getLong ( 1 ) ) ) . collect ( Collectors . toList ( ) ) ;
使用简化的方法,开头提到的真正基于Hadoop的M/R管道可能会使用Apache Spark进行加强,并按如下方式查看:
正如前面提到的,Lambda Architecture有其优势和缺点,人们也划分红支持者和反对者两派。他们中的一些人说批处理视图和实时视图有不少重复的逻辑,由于他们最终须要从查询角度建立可合并的视图。因此他们建立了Kappa架构 - 简化了Lambda架构。Kappa架构系统是删除了批处理系统的架构。要取代批处理,数据只需经过流式传输系统快速提供:
但即便在这种状况下,Kappa Architecture也有使用Apache Spark的地方,例如流处理系统:
问答
如何使用MySQL和ApacheSPark?
相关阅读
大数据系统的Lambda架构
Spark生态顶级项目汇总
大数据平台架构技术选型与场景运用
此文已由做者受权腾讯云+社区发布,原文连接:https://cloud.tencent.com/dev...