基于Lambda架构的山东省智慧旅游数据分析平台的研究
来源:用户上传
作者:
摘要：智慧旅游“以人为本”且“以数据为中心”，重点关注游客旅游体验，其关键技术是对海量的数据进行处理。以Lambda架构为基础搭建山东省智慧旅游数据分析平台即能处理大批量的离线数据又能处理实时的在线流数据。Spark因其运算速度快和高容错性等优点在Lambda架构搭建中用做离线处理;Flink因其容错性和窗口技术等特点做实时计算处理。
关键词：智慧旅游;Lambda架构;批处理;实时处理
中图法分类号：TP301 文献标识码：A
文章编号：1009-3044（2020）17-0211-03
素有“孔孟之乡，礼仪之邦”美誉的山东是一个文化资源大省，同时又是一个旅游资源大省。全省每个地市都有自己的特色旅游文化，如：滕州的墨子文化，邹城的孟子文化，曲阜的孔子文化，泰安的泰山文化等。富有地域特色的齐鲁旅游文化每年吸引着国内外数十亿游客游玩、考察。据统计，2018年，全省接待游客8.6亿人次，实现旅游消费总额突破1万亿元，同比增幅分别超过9%和13%[1]。随着旅游人数不断攀升，景区管理弊端尽显，如旅游景点人满为患，道路堵车严重，停车场无处可停车等。这些问题的暴露和游客需求的不断升级都推动着智慧旅游建设的步伐。智慧旅游是在智慧城市的基础上发展而来，“以人为本”，“以数据为中心”，其关键技术是对海量的数据进行处理。如何在海量的大数据中分析出有价值的信息呢？本文提出以Lambda架构为基础搭建山东省智慧旅游数据分析平台，以期对平台数据进行快速有效处理，提高游客体验和管理手段。
1平台数据分析
智慧旅游平台涉及的数据不计其数，按其类别大体可以分为基础数据、旅游管理部门数据、运营商数据、联动厅局数据、互联网数据、物联网数据，如图1所示。
其中基础数据包含旅游景区、旅游酒店、旅行社和餐饮娱乐等方面的价格数据、评论数据等;旅游管理部门包含国家旅游局和各省市县旅游局旅游数据、旅游动态数据、旅游执法数据以及公共服务数据等;运营商数据包含来自电信、联通、移动三大运营商的游客基本信息数据;联动厅局数据包含气象局和交通局等的实时数据;互联网包含微信、微博、在线旅游平台的实时评论数据等;视频监控数据包含游客的实时行踪信息等。如此庞大的数据都需要智慧旅游平台进行处理，但并不是所有数据在同一时间处理，这样一方面系统负荷过于沉重，另一方面系统计算延迟会大大降低游客体验。例如游客需要规划景区行驶路线，监测系统对这些实时产生的数据进行实时分析时超出用户预期的时间，再如游客在查询酒店等服务信息时超出预期时间等，都会降低用户的体验。这些数据需要根据其特点，采用不同的处理方法。总体分成两大类，一类是对庞大的历史数据采用批处理的方法进行离线处理，如基础数据中，需要事先运算对其进行景区画像、旅行社画像、餐馆画像、酒店画像等;另一类是采用在线实时处理，如视频监控数据、实时交通数据等。这样离线数据预先计算，实时数据实时计算，才能在游客进行查询时，快速给出结果。例如用批处理方式事先对酒店进行星级、价格、评分等多维度画像，在游客查询自己需要的酒店时，平台会根据画像再结合游客查询的关键字，给出游客个性化的智能推荐。Lambda架构正是批处理与实时处理相结合的一种大数据处理架构。
2 Lambda架构
2.1 背景介绍
Lambda架构是著名的分布式容错实时大数据处理框架Storm的创始人Nathan Marz提出的一个实时大数据处理框架。Nathan Marz根据自己多年的分布式大数据实战经验凝练出此框架。然而，Lambda框架并不像Apache Storm、Spark Streaming等計算框架一样有实体的软件产品，它只是一个流计算框架搭建指导模型。所以使用者可以根据自己实际的业务需要，依据此指导模型，任意选择开源的Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件，或者选择其他商业软件来搭建自己的系统。
2.2 Lambda架构的三层模型
Nathan Marz提出数据系统的本质就是Query = Function （ All Data ），即“查询+数据”，然而随着数据量的急剧增加，想要在大数据系统中进行实时查询并非易事[2]。如果单纯用Hadoop对全体数据进行在线查询，不仅计算量会很大，延迟也会特别高。例如在旅游过程中产生的旅游评论信息、实时交通信息、实时景点游客信息等不能一概而论采用统一的方法进行处理，需要对不同数据进行不同的计算方法。对于实时要求高的数据如实时交通数据需要实时计算以降低延迟来提高用户体验;而对应实时性要求低的数据如旅游评论信息、微信微博信息等进行批处理即可。Lambda架构整合了对全体数据进行离线计算和部分数据进行实时计算的方法将大数据系统架构分成了三个层次：批处理层（Batch Layer）、实时处理层（Speed Layer）、服务层 （Serving Layer），如图2所示。
批处理层（Batch Layer）：Batch Layer选用诸如Hadoop这样的组件对所有数据进行存储，并根据不同的企业需求进行预先批处理运算，生成对应的Batch Views，并对所有Views建立索引来供给Serving Layer进行查询。随着新数据的不断到达，预查询工作每隔一段时间就进行一次，Batch Views也随之更新。Batch Layer进行预运算可以大大改善实时查询的性能，但这是有前提条件的，即需要预先知道查询的数据。Batch Layer执行的方式可以用一段伪代码来表示：
function runBatchLayer（）：
while （true）：
recomputeBatchViews（） 实时处理层（Speed Layer）：Batch Layer对预查询的数据进行批处理，但花费的时间会比较长，通常是几个小时到几天。在这个时间段Serving Layer并没有因为新数据的到来而更新，其使用的仍然是旧版本的Batch Views，那么新数据将被排除在最后的计算结果之外。因此，Speed layer的职责是用来处理不断新增加的实时数据。Speed Layer和Batch Layer比较类似，Batch Layer产生Batch Views，而Speed Layer产生Realtime Views。两者之间最大的区别是Batch Layer要处理所有的数据，而Speed Layer只是处理最近的数据。为了提高效率降低延迟，Speed Layer与 Batch Layer采用不同的计算模型，Speed Layer采用的是增量计算模型（Incremental Updates），而Batch Layer采用重新计算模型（Recomputation Updates）。
服务层（Serving Layer）：Serving Layer的作用是将Batch Views和Realtime Views的结果进行了合并，得到的最后结果进行保存在NoSQL数据库中，用于用户在线查询请求。
3搭建平台所需组件
Lambda架构是一个理论指导模型，实际平台搭建可以根据实际需要进行选择所需要的组件。在山东省智慧旅游数据分析平台中，其组件的选择如图3所示。
3.1 批处理层
批处理层离线数据集的存储可选用Hadoop的HDFS，离线数据的计算可选用Apache Spark。选用Apache Spark原因有以下几点：
Spark基于内存进行运算[3]，运算中间结果保存在内存中，如后续有其他任务需要前面任务的输出结果，则直接从内存读取即可，大大减少磁盘I/O操作，计算效率更高;而Hadoop MapReduce是基于磁盘进行运算的，其运算中间结果保存在磁盘中，后续任务的依赖任务只能从磁盘进行读取，需要大量的磁盘I/O操作，其速度要明显慢很多。据统计Spark比MapReduce在内存中快100倍，比MapReduce在磁盘中快10倍。
高效的容错性。Spark通过弹性分布式数据集RDD来实现高效容错。在RDD设计中不是通过数据冗余的方式实现容错，而是通过RDD父子依赖关系重新计算来实现容错。例如某个阶段的RDD丢失或者出错，只需要对其上一个RDD再做相应计算即可，而无须从头计算，从而避免数据的高开销复制，实现了高效的容错。
Spark支持Java、Scala、Python、R多种语言编程，用起来比较方便，可以快速写一个Spark应用程序。
3.2 实时处理层
实时处理层（Speed Layer），在选择流数据框架时对数据的一致性要求会非常高。Apache Flink无疑是非常合适的选择。Apache Flink是Apache软件基金会的5个最大的大数据项目之一，其具有非常多的功能，如实现了低延迟、高吞吐和exactly-once语义的实时计算等。其技术栈的核心组成部分如图4所示。
Flink体系架构遵从分层设计理念，这样设计的好处是既降低了系统的耦合度又为上层用户提供丰富易用的接口。整个架构体系共分为物理部署层、Runtime核心层和面向用户的API 以及 Libraries层[4]。Flink支持多种部署，不仅可以部署在集群上，也可以部署在单机上。当部署在集群上时，既可以作为独立计算工具运行也可以作为Hadoop 中的一个组件部署在Yarn上或在Mesos管理的群集上。Runtime核心层为上层面向用户的API提供基础服务，其提供了支持Flink计算的全部核心实现（支持分布式Stream处理、JobGraph到ExecutionGraph的映射、调度等等）。面向用户的API层，分别提供了面向流处理的接口（DataSet API）和面向批处理的接口（DataStream API）[5]。因此，Flink对于流处理和批处理都可以完成。Libraries层即Flink的应用框架层，在API层基础上构建面向流处理（复杂事件处理、基于Table的关系操作）和面向批处理（机器学习库、图处理）的特定应用计算框架。
Flink解决了许多其他流处理框架所存在的问题，例如其在不增加过多额外开销的情况下保证了exactly-once语义以及基于事件时间的数据窗口等。选用Flink的原因如下：
Flink流处理的容错机制。批处理系统采用重复访问文件的方式来重启失败任务，用于实现容错是比较容易的。但是在流处理系统中由于数据流是无限的，如果缓存或持久化所有的数据来完成重启基本是不可行的。Flink采用检查点机制 [6]，来实现当任务失败或出现故障时，将应用流图的状态恢复到出现失败或故障之前的某一个状态，然后再重新从这个状态进行计算，从而实现容错。举一个类比例子来了解检查点的作用。假设我们来数一个项链上的珠子，每数一个珠子数量增加一，如果在数的过程中因为有人打扰或自己分神忘记数到哪里了，怎么办呢？或许你会想到重新数，但是如果项链很长珠子很多，且都数过半了呢，显然谁都不想再数一遍。有一个方法就是，每数一段时间（如数到50个珠子）就系一个有色皮绳（不同颜色的皮绳可以代表不同的数字），将珠子分开，这样当再次数错时就不必重新从第一颗珠子开始了，直接从上一次系有色皮绳的位置开始就行，从而大大减少计算量，且保证了正确性。Flink检查点机制就类似于有色皮绳所做的标记，是Flink可靠性保障的重要基石。
Flink 窗口技术。在流处理应用中，对于不断产生的事件流数据（如电子商务网站的交易数据、社交网站的点击数据等）必须马上处理或一段时间或达到一定量处理一次，而不是等到所有数据到了之后才开始处理。如果一段时间处理或达到一定量再进行处理，需要对数据进行聚合类处理。这种情况下需要我们定义一个窗口来收集数据并计算。窗口就一种按着时间或其他特點进行分组，然后以分组作为整体进行分析的机制。Flink支持的很多窗口类型，其中根据时间进行分组的窗口最常见。Flink支持三种时间窗口：事件时间（Event Time）[7]、处理时间（Processing Time）和摄入时间（Ingestion Time），而事件时间（Event Time）是最有特色的。处理时间（Processing Time）是指在执行相应的操作时机器时间。每小时处理时间（Processing Time）窗口将包括在系统时钟指示整个小时之间到达特定操作的所有事件。比如某程序从上午8：30开始作业，那上午8：30到9：00是第一个处理时间窗口，以后每一个小时为一个时间窗口。处理时间（Processing Time）因为不需要数据流和机器之间的协调，因此是最简单的概念。但是不同节点由于系统时钟可能不太一样，或者消息延迟有快有慢，如果本属于同一个时间窗口处理的消息，在到达下一个节点时被分到不同的时间窗口中，就会产生不符合预期的结果，从而降低用户体验。假设这样一个场景，某应用程序正在分析不同游戏用户的行为事件，并根据用户行为做出相应的反应（例如加分、升级等），如果某一用户因为突然网络中断或信号差把本属于同一时间窗口的消息被切分到不同的时间窗口进行计算，因而导致的不符合逻辑或预期的结果便会产生。Flink事件时间（Event Time）就是专门用来解决数据延迟或数据乱序等问题的时间窗口。事件时间（Event Time）不是采用数据到达系统的时间进行处理，而是记录每条事件实际产生的时间，并以此时间为依据进行划分计算窗口，即依赖于事件本身。事件时间（Event Time）可以处理延时或乱序事件从而保证正确的结果，但是这并不是说处理时间（Processing Time）就没有用了。在不考虑延迟等情况或准确性情况下，处理时间（Processing Time）会更方便。
4总结
智慧旅游平台数据规模庞大，处理得当会提高政府管理效率，增加用户体验，优化企业营销方案，反之会使平台成为一种负担。Lambda架构既能处理离线数据又能处理实时数据，是建设山东省智慧旅游数据分析平台的一个非常好的选择。当然，随着应用的推进和处理技术的不断进步，必将将会产生新问题，各种计算框架将会面临更多的挑战[8]，而作为大数据分布式处理的架构，Lambda架构有着不可替代的地位和作用。
参考文献：
[1] 国家旅游局.2018 年全国旅游统计数据[R].2018 年全国旅游工作会议资料汇编，2018（1）.
[2]阿里云技术.Lambda plus： 云上大数据解决方案[EB/OL].2019，6.
[3] 林子雨，赖永炫，陶继平.Spark编程基础[M].北京：人民邮电出版社，2018.
[4] 埃伦·弗里德曼，（希）科斯塔斯·宙马斯著王绍翾译.Flink基础教程[M].北京：人民邮电出版社，2018.
[5] Apache Flink. [EB/OL].https：//flink.apache.org/.
[6] Flink distributed snapshot： High-throughput， low-latency， and exactly-once stream processing with Apache Flink.
[7] Flink Event Time： Time and Order in Streams.
[8] 赵晟，姜进磊.典型大数据计算框架分析[J].中兴通讯技术，2016，22（2）：14-18.
【通联编辑：王力】
转载注明来源:https://www.xzbu.com/8/view-15314890.htm
