白二凈 王曉輝

摘要：智慧旅游“以人為本”且“以數(shù)據(jù)為中心”，重點關注游客旅游體驗，其關鍵技術是對海量的數(shù)據(jù)進行處理。以Lambda架構為基礎搭建山東省智慧旅游數(shù)據(jù)分析平臺即能處理大批量的離線數(shù)據(jù)又能處理實時的在線流數(shù)據(jù)。Spark因其運算速度快和高容錯性等優(yōu)點在Lambda架構搭建中用做離線處理;Flink因其容錯性和窗口技術等特點做實時計算處理。

關鍵詞：智慧旅游;Lambda架構;批處理;實時處理

中圖法分類號：TP301 ? ? ? ?文獻標識碼：A

文章編號：1009-3044（2020）17-0211-03

素有“孔孟之鄉(xiāng)，禮儀之邦”美譽的山東是一個文化資源大省，同時又是一個旅游資源大省。全省每個地市都有自己的特色旅游文化，如：滕州的墨子文化，鄒城的孟子文化，曲阜的孔子文化，泰安的泰山文化等。富有地域特色的齊魯旅游文化每年吸引著國內外數(shù)十億游客游玩、考察。據(jù)統(tǒng)計，2018年，全省接待游客8.6億人次，實現(xiàn)旅游消費總額突破1萬億元，同比增幅分別超過9%和13%[1]。隨著旅游人數(shù)不斷攀升，景區(qū)管理弊端盡顯，如旅游景點人滿為患，道路堵車嚴重，停車場無處可停車等。這些問題的暴露和游客需求的不斷升級都推動著智慧旅游建設的步伐。智慧旅游是在智慧城市的基礎上發(fā)展而來，“以人為本”，“以數(shù)據(jù)為中心”，其關鍵技術是對海量的數(shù)據(jù)進行處理。如何在海量的大數(shù)據(jù)中分析出有價值的信息呢？本文提出以Lambda架構為基礎搭建山東省智慧旅游數(shù)據(jù)分析平臺，以期對平臺數(shù)據(jù)進行快速有效處理，提高游客體驗和管理手段。

1平臺數(shù)據(jù)分析

智慧旅游平臺涉及的數(shù)據(jù)不計其數(shù)，按其類別大體可以分為基礎數(shù)據(jù)、旅游管理部門數(shù)據(jù)、運營商數(shù)據(jù)、聯(lián)動廳局數(shù)據(jù)、互聯(lián)網(wǎng)數(shù)據(jù)、物聯(lián)網(wǎng)數(shù)據(jù)，如圖1所示。

其中基礎數(shù)據(jù)包含旅游景區(qū)、旅游酒店、旅行社和餐飲娛樂等方面的價格數(shù)據(jù)、評論數(shù)據(jù)等;旅游管理部門包含國家旅游局和各省市縣旅游局旅游數(shù)據(jù)、旅游動態(tài)數(shù)據(jù)、旅游執(zhí)法數(shù)據(jù)以及公共服務數(shù)據(jù)等;運營商數(shù)據(jù)包含來自電信、聯(lián)通、移動三大運營商的游客基本信息數(shù)據(jù);聯(lián)動廳局數(shù)據(jù)包含氣象局和交通局等的實時數(shù)據(jù);互聯(lián)網(wǎng)包含微信、微博、在線旅游平臺的實時評論數(shù)據(jù)等;視頻監(jiān)控數(shù)據(jù)包含游客的實時行蹤信息等。如此龐大的數(shù)據(jù)都需要智慧旅游平臺進行處理，但并不是所有數(shù)據(jù)在同一時間處理，這樣一方面系統(tǒng)負荷過于沉重，另一方面系統(tǒng)計算延遲會大大降低游客體驗。例如游客需要規(guī)劃景區(qū)行駛路線，監(jiān)測系統(tǒng)對這些實時產生的數(shù)據(jù)進行實時分析時超出用戶預期的時間，再如游客在查詢酒店等服務信息時超出預期時間等，都會降低用戶的體驗。這些數(shù)據(jù)需要根據(jù)其特點，采用不同的處理方法?？傮w分成兩大類，一類是對龐大的歷史數(shù)據(jù)采用批處理的方法進行離線處理，如基礎數(shù)據(jù)中，需要事先運算對其進行景區(qū)畫像、旅行社畫像、餐館畫像、酒店畫像等;另一類是采用在線實時處理，如視頻監(jiān)控數(shù)據(jù)、實時交通數(shù)據(jù)等。這樣離線數(shù)據(jù)預先計算，實時數(shù)據(jù)實時計算，才能在游客進行查詢時，快速給出結果。例如用批處理方式事先對酒店進行星級、價格、評分等多維度畫像，在游客查詢自己需要的酒店時，平臺會根據(jù)畫像再結合游客查詢的關鍵字，給出游客個性化的智能推薦。Lambda架構正是批處理與實時處理相結合的一種大數(shù)據(jù)處理架構。

2 Lambda架構

2.1 背景介紹

Lambda架構是著名的分布式容錯實時大數(shù)據(jù)處理框架Storm的創(chuàng)始人Nathan Marz提出的一個實時大數(shù)據(jù)處理框架。Nathan Marz根據(jù)自己多年的分布式大數(shù)據(jù)實戰(zhàn)經(jīng)驗凝練出此框架。然而，Lambda框架并不像Apache Storm、Spark Streaming等計算框架一樣有實體的軟件產品，它只是一個流計算框架搭建指導模型。所以使用者可以根據(jù)自己實際的業(yè)務需要，依據(jù)此指導模型，任意選擇開源的Hadoop，Kafka，Storm，Spark，Hbase等各類大數(shù)據(jù)組件，或者選擇其他商業(yè)軟件來搭建自己的系統(tǒng)。

2.2 ?Lambda架構的三層模型

Nathan Marz提出數(shù)據(jù)系統(tǒng)的本質就是Query = Function （ All Data ），即“查詢+數(shù)據(jù)”，然而隨著數(shù)據(jù)量的急劇增加，想要在大數(shù)據(jù)系統(tǒng)中進行實時查詢并非易事[2]。如果單純用Hadoop對全體數(shù)據(jù)進行在線查詢，不僅計算量會很大，延遲也會特別高。例如在旅游過程中產生的旅游評論信息、實時交通信息、實時景點游客信息等不能一概而論采用統(tǒng)一的方法進行處理，需要對不同數(shù)據(jù)進行不同的計算方法。對于實時要求高的數(shù)據(jù)如實時交通數(shù)據(jù)需要實時計算以降低延遲來提高用戶體驗;而對應實時性要求低的數(shù)據(jù)如旅游評論信息、微信微博信息等進行批處理即可。Lambda架構整合了對全體數(shù)據(jù)進行離線計算和部分數(shù)據(jù)進行實時計算的方法將大數(shù)據(jù)系統(tǒng)架構分成了三個層次：批處理層（Batch Layer）、實時處理層（Speed Layer）、服務層 （Serving Layer），如圖2所示。

批處理層（Batch Layer）：Batch Layer選用諸如Hadoop這樣的組件對所有數(shù)據(jù)進行存儲，并根據(jù)不同的企業(yè)需求進行預先批處理運算，生成對應的Batch Views，并對所有Views建立索引來供給Serving Layer進行查詢。隨著新數(shù)據(jù)的不斷到達，預查詢工作每隔一段時間就進行一次，Batch Views也隨之更新。Batch Layer進行預運算可以大大改善實時查詢的性能，但這是有前提條件的，即需要預先知道查詢的數(shù)據(jù)。Batch Layer執(zhí)行的方式可以用一段偽代碼來表示：

function runBatchLayer（）：

while （true）：

recomputeBatchViews（）

實時處理層（Speed Layer）：Batch Layer對預查詢的數(shù)據(jù)進行批處理，但花費的時間會比較長，通常是幾個小時到幾天。在這個時間段Serving Layer并沒有因為新數(shù)據(jù)的到來而更新，其使用的仍然是舊版本的Batch Views，那么新數(shù)據(jù)將被排除在最后的計算結果之外。因此，Speed layer的職責是用來處理不斷新增加的實時數(shù)據(jù)。Speed Layer和Batch Layer比較類似，Batch Layer產生Batch Views，而Speed Layer產生Realtime ?Views。兩者之間最大的區(qū)別是Batch Layer要處理所有的數(shù)據(jù)，而Speed Layer只是處理最近的數(shù)據(jù)。為了提高效率降低延遲，Speed Layer與 Batch Layer采用不同的計算模型，Speed Layer采用的是增量計算模型（Incremental Updates），而Batch Layer采用重新計算模型（Recomputation Updates）。

服務層（Serving Layer）：Serving Layer的作用是將Batch Views和Realtime Views的結果進行了合并，得到的最后結果進行保存在NoSQL數(shù)據(jù)庫中，用于用戶在線查詢請求。

3搭建平臺所需組件

Lambda架構是一個理論指導模型，實際平臺搭建可以根據(jù)實際需要進行選擇所需要的組件。在山東省智慧旅游數(shù)據(jù)分析平臺中，其組件的選擇如圖3所示。

3.1 批處理層

批處理層離線數(shù)據(jù)集的存儲可選用Hadoop的HDFS，離線數(shù)據(jù)的計算可選用Apache Spark。選用Apache Spark原因有以下幾點：

Spark基于內存進行運算[3]，運算中間結果保存在內存中，如后續(xù)有其他任務需要前面任務的輸出結果，則直接從內存讀取即可，大大減少磁盤I/O操作，計算效率更高;而Hadoop MapReduce是基于磁盤進行運算的，其運算中間結果保存在磁盤中，后續(xù)任務的依賴任務只能從磁盤進行讀取，需要大量的磁盤I/O操作，其速度要明顯慢很多。據(jù)統(tǒng)計Spark比MapReduce在內存中快100倍，比MapReduce在磁盤中快10倍。

高效的容錯性。Spark通過彈性分布式數(shù)據(jù)集RDD來實現(xiàn)高效容錯。在RDD設計中不是通過數(shù)據(jù)冗余的方式實現(xiàn)容錯，而是通過RDD父子依賴關系重新計算來實現(xiàn)容錯。例如某個階段的RDD丟失或者出錯，只需要對其上一個RDD再做相應計算即可，而無須從頭計算，從而避免數(shù)據(jù)的高開銷復制，實現(xiàn)了高效的容錯。

Spark支持Java、Scala、Python、R多種語言編程，用起來比較方便，可以快速寫一個Spark應用程序。

3.2 實時處理層

實時處理層（Speed Layer），在選擇流數(shù)據(jù)框架時對數(shù)據(jù)的一致性要求會非常高。Apache Flink無疑是非常合適的選擇。Apache Flink是Apache軟件基金會的5個最大的大數(shù)據(jù)項目之一，其具有非常多的功能，如實現(xiàn)了低延遲、高吞吐和exactly-once語義的實時計算等。其技術棧的核心組成部分如圖4所示。

Flink體系架構遵從分層設計理念，這樣設計的好處是既降低了系統(tǒng)的耦合度又為上層用戶提供豐富易用的接口。整個架構體系共分為物理部署層、Runtime核心層和面向用戶的API 以及 Libraries層[4]。Flink支持多種部署，不僅可以部署在集群上，也可以部署在單機上。當部署在集群上時，既可以作為獨立計算工具運行也可以作為Hadoop 中的一個組件部署在Yarn上或在Mesos管理的群集上。Runtime核心層為上層面向用戶的API提供基礎服務，其提供了支持Flink計算的全部核心實現(xiàn)（支持分布式Stream處理、JobGraph到ExecutionGraph的映射、調度等等）。面向用戶的API層，分別提供了面向流處理的接口（DataSet ?API）和面向批處理的接口（DataStream ?API）[5]。因此，F(xiàn)link對于流處理和批處理都可以完成。Libraries層即Flink的應用框架層，在API層基礎上構建面向流處理（復雜事件處理、基于Table的關系操作）和面向批處理（機器學習庫、圖處理）的特定應用計算框架。

Flink解決了許多其他流處理框架所存在的問題，例如其在不增加過多額外開銷的情況下保證了exactly-once語義以及基于事件時間的數(shù)據(jù)窗口等。選用Flink的原因如下：

Flink流處理的容錯機制。批處理系統(tǒng)采用重復訪問文件的方式來重啟失敗任務，用于實現(xiàn)容錯是比較容易的。但是在流處理系統(tǒng)中由于數(shù)據(jù)流是無限的，如果緩存或持久化所有的數(shù)據(jù)來完成重啟基本是不可行的。Flink采用檢查點機制 [6]，來實現(xiàn)當任務失敗或出現(xiàn)故障時，將應用流圖的狀態(tài)恢復到出現(xiàn)失敗或故障之前的某一個狀態(tài)，然后再重新從這個狀態(tài)進行計算，從而實現(xiàn)容錯。舉一個類比例子來了解檢查點的作用。假設我們來數(shù)一個項鏈上的珠子，每數(shù)一個珠子數(shù)量增加一，如果在數(shù)的過程中因為有人打擾或自己分神忘記數(shù)到哪里了，怎么辦呢？或許你會想到重新數(shù)，但是如果項鏈很長珠子很多，且都數(shù)過半了呢，顯然誰都不想再數(shù)一遍。有一個方法就是，每數(shù)一段時間（如數(shù)到50個珠子）就系一個有色皮繩（不同顏色的皮繩可以代表不同的數(shù)字），將珠子分開，這樣當再次數(shù)錯時就不必重新從第一顆珠子開始了，直接從上一次系有色皮繩的位置開始就行，從而大大減少計算量，且保證了正確性。Flink檢查點機制就類似于有色皮繩所做的標記，是Flink可靠性保障的重要基石。

Flink 窗口技術。在流處理應用中，對于不斷產生的事件流數(shù)據(jù)（如電子商務網(wǎng)站的交易數(shù)據(jù)、社交網(wǎng)站的點擊數(shù)據(jù)等）必須馬上處理或一段時間或達到一定量處理一次，而不是等到所有數(shù)據(jù)到了之后才開始處理。如果一段時間處理或達到一定量再進行處理，需要對數(shù)據(jù)進行聚合類處理。這種情況下需要我們定義一個窗口來收集數(shù)據(jù)并計算。窗口就一種按著時間或其他特點進行分組，然后以分組作為整體進行分析的機制。Flink支持的很多窗口類型，其中根據(jù)時間進行分組的窗口最常見。Flink支持三種時間窗口：事件時間（Event Time）[7]、處理時間（Processing Time）和攝入時間（Ingestion Time），而事件時間（Event Time）是最有特色的。處理時間（Processing Time）是指在執(zhí)行相應的操作時機器時間。每小時處理時間（Processing Time）窗口將包括在系統(tǒng)時鐘指示整個小時之間到達特定操作的所有事件。比如某程序從上午8：30開始作業(yè)，那上午8：30到9：00是第一個處理時間窗口，以后每一個小時為一個時間窗口。處理時間（Processing Time）因為不需要數(shù)據(jù)流和機器之間的協(xié)調，因此是最簡單的概念。但是不同節(jié)點由于系統(tǒng)時鐘可能不太一樣，或者消息延遲有快有慢，如果本屬于同一個時間窗口處理的消息，在到達下一個節(jié)點時被分到不同的時間窗口中，就會產生不符合預期的結果，從而降低用戶體驗。假設這樣一個場景，某應用程序正在分析不同游戲用戶的行為事件，并根據(jù)用戶行為做出相應的反應（例如加分、升級等），如果某一用戶因為突然網(wǎng)絡中斷或信號差把本屬于同一時間窗口的消息被切分到不同的時間窗口進行計算，因而導致的不符合邏輯或預期的結果便會產生。Flink事件時間（Event Time）就是專門用來解決數(shù)據(jù)延遲或數(shù)據(jù)亂序等問題的時間窗口。事件時間（Event Time）不是采用數(shù)據(jù)到達系統(tǒng)的時間進行處理，而是記錄每條事件實際產生的時間，并以此時間為依據(jù)進行劃分計算窗口，即依賴于事件本身。事件時間（Event Time）可以處理延時或亂序事件從而保證正確的結果，但是這并不是說處理時間（Processing Time）就沒有用了。在不考慮延遲等情況或準確性情況下，處理時間（Processing Time）會更方便。

4總結

智慧旅游平臺數(shù)據(jù)規(guī)模龐大，處理得當會提高政府管理效率，增加用戶體驗，優(yōu)化企業(yè)營銷方案，反之會使平臺成為一種負擔。Lambda架構既能處理離線數(shù)據(jù)又能處理實時數(shù)據(jù)，是建設山東省智慧旅游數(shù)據(jù)分析平臺的一個非常好的選擇。當然，隨著應用的推進和處理技術的不斷進步，必將將會產生新問題，各種計算框架將會面臨更多的挑戰(zhàn)[8]，而作為大數(shù)據(jù)分布式處理的架構，Lambda架構有著不可替代的地位和作用。

參考文獻：

[1] 國家旅游局.2018 年全國旅游統(tǒng)計數(shù)據(jù)[R].2018 年全國旅游工作會議資料匯編，2018（1）.

[2]阿里云技術.Lambda plus： 云上大數(shù)據(jù)解決方案[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] 趙晟，姜進磊.典型大數(shù)據(jù)計算框架分析[J].中興通訊技術，2016，22（2）：14-18.

【通聯(lián)編輯：王力】