智慧旅游大數(shù)據(jù)集成平臺-方案建議書

1、智慧旅游大數(shù)據(jù)集成平臺方案建議書 PAGE 3目 錄 TOC o 1-3 h z u HYPERLINK l _Toc527059290 1. 項目建設(shè)背景 PAGEREF _Toc527059290 h 4 HYPERLINK l _Toc527059291 2. 旅游大數(shù)據(jù)集成平臺 PAGEREF _Toc527059291 h 311 HYPERLINK l _Toc527059292 2.1. 旅游大數(shù)據(jù)集成平臺概述 PAGEREF _Toc527059292 h 311 HYPERLINK l _Toc527059293 2.1.1. 建設(shè)背景 PAGEREF _Toc5270592

2、93 h 311 HYPERLINK l _Toc527059294 2.1.2. 大數(shù)據(jù)云平臺現(xiàn)狀 PAGEREF _Toc527059294 h 311 HYPERLINK l _Toc527059295 2.2. 平臺指導思想 PAGEREF _Toc527059295 h 313 HYPERLINK l _Toc527059296 2.2.1. 平臺設(shè)計的指導思想 PAGEREF _Toc527059296 h 313 HYPERLINK l _Toc527059297 2.2.2. 平臺選擇的指導思想 PAGEREF _Toc527059297 h 314 HYPERLINK l _

3、Toc527059298 2.2.3. 平臺應(yīng)用的指導思想 PAGEREF _Toc527059298 h 314 HYPERLINK l _Toc527059299 2.3. 總體解決方案 PAGEREF _Toc527059299 h 316 HYPERLINK l _Toc527059300 2.3.1. 總平臺旅游大數(shù)據(jù)的存儲解決方案 PAGEREF _Toc527059300 h 318 HYPERLINK l _Toc527059301 2.3.2. 總平臺旅游大數(shù)據(jù)的計算解決方案 PAGEREF _Toc527059301 h 319 HYPERLINK l _Toc527059

4、302 2.3.3. 總平臺旅游大數(shù)據(jù)的文件傳輸解決方案 PAGEREF _Toc527059302 h 321 HYPERLINK l _Toc527059303 2.4. 平臺總體設(shè)計 PAGEREF _Toc527059303 h 324 HYPERLINK l _Toc527059304 2.4.1. Hadoop 云平臺的總設(shè)計原則 PAGEREF _Toc527059304 h 324 HYPERLINK l _Toc527059305 2.4.2. Hadoop 云平臺架構(gòu) PAGEREF _Toc527059305 h 325 HYPERLINK l _Toc527059306

5、 2.4.3. 平臺的基礎(chǔ)架構(gòu)設(shè)計 PAGEREF _Toc527059306 h 326 HYPERLINK l _Toc527059307 2.4.4. 高用性設(shè)計 PAGEREF _Toc527059307 h 334 HYPERLINK l _Toc527059308 2.4.5. 業(yè)務(wù)分析平臺 PAGEREF _Toc527059308 h 335 HYPERLINK l _Toc527059309 2.4.6. 數(shù)據(jù)管理平臺 PAGEREF _Toc527059309 h 337 HYPERLINK l _Toc527059310 2.4.7. 數(shù)據(jù)訪問平臺 PAGEREF _To

6、c527059310 h 342 HYPERLINK l _Toc527059311 2.4.8. 數(shù)據(jù)管制和集成平臺 PAGEREF _Toc527059311 h 352 HYPERLINK l _Toc527059312 2.4.9. 運營平臺 PAGEREF _Toc527059312 h 353 HYPERLINK l _Toc527059313 2.5. 平臺功能 PAGEREF _Toc527059313 h 351 HYPERLINK l _Toc527059314 2.5.1. 總體要求 PAGEREF _Toc527059314 h 351 HYPERLINK l _Toc

7、527059315 2.5.2. 平臺業(yè)務(wù)功能 PAGEREF _Toc527059315 h 351 HYPERLINK l _Toc527059316 2.5.3. 平臺技術(shù)功能 PAGEREF _Toc527059316 h 360項目建設(shè)背景智慧旅游來源于“智慧地球( Smarter Planet) ”及其在中國實踐的“智慧城市( Smarter Cities) ”。2008 年國際商用機器公司( International Business Machine， IBM) 首先提出了“智慧地球”概念，指出智慧地球的核心是以一種更智慧的方法通過利用新一代信息技術(shù)來改變政府、公司和人們相互交

8、互的方式，以便提高交互的明確性、效率、靈活性和響應(yīng)速度。由此，“智慧的城市”、“智慧的企業(yè)”與“智慧的行業(yè)”等概念應(yīng)運而生。全世界的企業(yè)和政府都對“智慧” 產(chǎn)生了自己的認識和理解。旅游業(yè)是高關(guān)聯(lián)度、高綜合拉動性的產(chǎn)業(yè)。它是集交通、旅行社、景區(qū)景點、飯店賓館、餐飲、商業(yè)、娛樂、金融投資、房地產(chǎn)等產(chǎn)業(yè)為一體的產(chǎn)業(yè)群。考慮智慧的旅游公共服務(wù)平臺的建設(shè)，就必須對滿足當前及未來游客，經(jīng)營者， 市場管理者的綜合需求，從引導和打造更加智慧的的產(chǎn)業(yè)鏈角度，以創(chuàng)新的國家級智慧旅游公共服務(wù)平臺這種形式為整個生態(tài)體系進行服務(wù)。獲得國內(nèi)領(lǐng)域的良好實踐后，未來可以考慮向全球提供服務(wù)和體系的輸出。本項目旨在建立旅游行業(yè)的

9、一體化信息服務(wù)平臺，通過構(gòu)建游客服務(wù)網(wǎng)站平臺、智慧旅游景區(qū)（點）信息亭及智慧旅游智能終端應(yīng)用等工具，實現(xiàn)針對游客的旅游信息服務(wù)和旅游體驗表達，服務(wù)游客結(jié)伴出行、緊急救助等業(yè)務(wù)需求。系統(tǒng)按照 SoLoCoMo（Social-Local-Communication-Mobile，社交-本地-溝通-移動）模式構(gòu)建，全面提升游客旅游體驗與旅行品質(zhì)。通過游客服務(wù)網(wǎng)站平臺（So），實現(xiàn)游客出行前信息檢索、結(jié)伴出游、輔助游客完成票務(wù)預訂等； 通過智慧旅游信息亭（Lo）和智能終端（Mo）的交互應(yīng)用，實現(xiàn)智能導覽、緊急求助、旅游感受發(fā)布等，并通過位置服務(wù)等功能，實現(xiàn)同伴位置檢索及網(wǎng)上互動；利用 Wiki 方式，

10、發(fā)動游客參與，嚴格審核，維護針對景區(qū)（點）的唯一、權(quán)威的旅行攻略信息，滿足游客行程規(guī)劃及旅行過程中的旅游輔助需要。最后， 構(gòu)建涵蓋旅游政府主管部門、旅游景區(qū)、旅游服務(wù)機構(gòu)和游客的溝通（Co）體 系讓游客與管理者、經(jīng)營者可以隨時互動，并實現(xiàn)與目前廣泛使用的通用微薄平臺的互連與同步，為旅游活動相關(guān)主體提供網(wǎng)上信息發(fā)布與在線交互的實時聯(lián)動平臺。 PAGE 317旅游大數(shù)據(jù)集成平臺旅游大數(shù)據(jù)集成平臺概述建設(shè)背景 旅游大數(shù)據(jù)的產(chǎn)生：眾所周知，隨著信息社會的快速發(fā)展，信息量以爆發(fā)式的速度增長。這些數(shù)據(jù)的特征表現(xiàn)為數(shù)據(jù)量大，一般為 TB 級或 PB 級甚至更大。數(shù)據(jù)類型多，可以是結(jié)構(gòu)化的表單、半結(jié)構(gòu)化的文本

11、、視頻、圖像、語音、及非結(jié)構(gòu)話的文件。而全國旅游數(shù)據(jù)也是異常巨大，形成了旅游大數(shù)據(jù)，而面對龐大而復雜的信息體系，我們把整個大數(shù)據(jù)分成了兩個層次，第一個層次是基礎(chǔ)數(shù)據(jù)，包括所有的景區(qū)信息、 HYPERLINK /ditu 地圖、POI、景區(qū)周邊環(huán)境信息等等。第二個層次就是應(yīng)用和交易數(shù)據(jù)，以游客所產(chǎn)生的數(shù)據(jù)為主。目前的大數(shù)據(jù)應(yīng)用主要是從第二個層次做延伸，也僅僅體現(xiàn)在在線旅游中，包括做得比較好的百度的旅游數(shù)據(jù)預測系統(tǒng)與螞蜂窩游客點評數(shù)據(jù)等等，它們大都從監(jiān)管和營銷的角度出發(fā)。但是我認為目前市場上沒有一種產(chǎn)品能真正滿足游客的游中體驗，而其實游客才是真正實現(xiàn)智慧旅游的核心價值。而且從游客體驗的吃、住、行、

12、游、購、娛六大要素來看，中國人的旅游方式是以景區(qū)為原點延伸的，景區(qū)基礎(chǔ)數(shù)據(jù)的應(yīng)用應(yīng)該是游客體驗中最重要的一環(huán)，但是目前所有的導航服務(wù)系統(tǒng)都是針對陸路交通的，景區(qū)內(nèi)基礎(chǔ)信息是一個盲點，更談不上基于此基礎(chǔ)數(shù)據(jù)的景區(qū)內(nèi)導航、語音播報、LBS 定點等產(chǎn)品的研發(fā)了。旅游大數(shù)據(jù)的挑戰(zhàn)：如何對這些數(shù)據(jù)進行高效存儲，如何對這些數(shù)據(jù)進行分析和處理， 以獲取更多有價值的信息。旅游大數(shù)據(jù)集成平臺應(yīng)運而生。因此，通過整合國家智慧旅游公共服務(wù)平臺、交通、氣象、酒店、餐飲、旅行社等相關(guān)數(shù)據(jù)，并結(jié)合旅游管理和目的地促銷活動中產(chǎn)生的所有數(shù)據(jù)形成國家旅游大數(shù)據(jù)集成平臺。通過對數(shù)據(jù)篩選、分析，提供如旅游行業(yè)發(fā)展動態(tài)、服務(wù)模式、旅

13、游者偏好等的數(shù)據(jù)分析報告，為國家旅游決策提供數(shù)據(jù)支撐。大數(shù)據(jù)云平臺現(xiàn)狀 目前，隨著云計算的高速發(fā)展，Hadoop 及 Hadoop 的生態(tài)圈逐漸壯大，但真正商用且成熟的 Hadoop 云平臺架構(gòu)卻非常少。本方案結(jié)合國內(nèi)的大數(shù)據(jù)應(yīng)用巨頭百度、阿里巴巴、騰訊，即“BAT”的 Hadoop 云平臺同時，也結(jié)合并學習國外的大數(shù)據(jù)巨頭 Hadoop 應(yīng)用發(fā)布商 Cloudera，Hortonworks，MapR,即“CHM”的 Hadoop 商用云平臺，利用 ApacheHadoop 開源的力量，推出一套穩(wěn)定、商用、高效、成熟、開源、易開發(fā)，易擴展的大規(guī)模hadoop 云平臺HDP（Hadoop Dat

14、a Platform），以滿足全國的旅游數(shù)據(jù)的采集、存儲、分析和發(fā)掘和應(yīng)用。平臺指導思想建設(shè)穩(wěn)定、商用、成熟、高效、節(jié)能統(tǒng)一的大數(shù)據(jù) Hadoop 云平臺。不僅滿足大數(shù)據(jù)的大規(guī)模的采集、存儲、分析計算和應(yīng)用，也為其它平臺和系統(tǒng)提供性能需求、系統(tǒng)穩(wěn)定性、服務(wù)滿意率高技術(shù)支撐和大數(shù)據(jù)支撐。性能需求指網(wǎng)站性能需求，主要指作業(yè)響應(yīng)時間方面的要求，作業(yè)響應(yīng)時間指完成目標系統(tǒng)中的交互或批量處理所需的響應(yīng)時間。網(wǎng)站響應(yīng)時間較短，具有良好的用戶體驗。這對大數(shù)據(jù)的實時性、準確性和有用性提出很高的要求，這需要我們設(shè)計并使用 Hadoop 的大數(shù)據(jù)實時處理的系統(tǒng)架構(gòu)，充分利用 storm、spark 等技術(shù)。系統(tǒng)穩(wěn)

15、定性主要包括系統(tǒng)運營完好、系統(tǒng)故障處理及時率兩個指標。系統(tǒng)運營完好， 有優(yōu)異的災(zāi)備機制，具有保障系統(tǒng)運營的優(yōu)異管理機制。系統(tǒng)故障處理及時率是系統(tǒng)發(fā)生故障時處理的效率。具有良好的系統(tǒng)故障應(yīng)急機制，能夠快速及時的處理系統(tǒng)故障。這對Hadoop 平臺的高可靠性提出高的要求，這需要設(shè)計 Hadoop 云架構(gòu)時，考慮 HA 的優(yōu)化和設(shè)計。服務(wù)滿意率主要考核供應(yīng)商在服務(wù)期限內(nèi)服務(wù)內(nèi)外部客戶的滿意度。包括投訴接通率、報告及時性兩個方面。投訴接通率是公共服務(wù)可信的重要保障。投訴接通率是投訴接通次數(shù)（包括電話、網(wǎng)站響應(yīng)）/投訴總次數(shù)。報告及時性是對國家旅游局要求的相關(guān)服務(wù)的響應(yīng)時間，計算方法為報告按時提交次數(shù)/

16、報告總次數(shù)。 這需要投訴方面的大數(shù)據(jù)有快速的分析和處理，需要設(shè)計 Hadoop 云架構(gòu)中的 storm、hbase、hive 的應(yīng)用和優(yōu)化。下面主要從平臺的設(shè)計、選擇和應(yīng)用來進行思想指導。平臺設(shè)計的指導思想 因為大數(shù)據(jù)是由分布存儲在集群節(jié)點中多個單節(jié)點的磁盤空間中，能被進行分布式處理的數(shù)據(jù)構(gòu)成的一個數(shù)據(jù)總體。大數(shù)據(jù)的規(guī)模可以隨點節(jié)點數(shù)量的不斷增加而不斷擴大。旅游大數(shù)據(jù)集成平臺的設(shè)計目標：可以存儲海量數(shù)據(jù)可以進行高速處理可以快速開發(fā)出并行服務(wù)可以運行在廉價機器搭建的集群上所以，我們選擇 Hadoop。因為 Hadoop 是一個能夠分布式存儲大數(shù)據(jù)，并且能對大數(shù)據(jù)進行分布式處理的軟件框架。主要由

17、HDFS 和 MapReduce 組成。它主要有以下幾個優(yōu)點：高可靠性：Hadoop 按位存儲和處理數(shù)據(jù)的能力值得人們信賴。高擴展性：Hadoop 是在可用的計算機集簇間分配數(shù)據(jù)并完成計算任務(wù)的，這些集簇可以方便地擴展到數(shù)以千計的節(jié)點中。高效性：Hadoop 能在各節(jié)點之間動態(tài)地移動數(shù)據(jù)，并保證各個節(jié)點的動態(tài)平衡，因為其處理速度非?？臁８呷蒎e性：Hadoop 能夠保存數(shù)據(jù)的多個副本，并且能夠自動將失敗的任務(wù)重新分配。低成本：Hadoop 可以運行在廉價服務(wù)器上管理海量數(shù)據(jù)，降低了成本。由 Apache 基金會所開發(fā)，純 Java 編寫的開源系統(tǒng)。平臺選擇的指導思想 為什么選擇 HDP？HDP

18、是企業(yè)級的 Hadoop，其核心是提供線性擴展存儲并跨廣范圍訪問方法（從批量到實時、搜索和流媒體）計算。它在管制、集成、安全性和運營上具有一套完善的功能。平臺應(yīng)用的指導思想 智慧旅游是旅游業(yè)發(fā)展到現(xiàn)階段出現(xiàn)的一種旅游新形態(tài)，是旅游業(yè)與科技創(chuàng)新融合發(fā)展的典范，是旅游業(yè)未來發(fā)展的趨勢。智慧旅游發(fā)展的直接受益者將是旅游者，它將使旅游者享受到更多的智慧旅游服務(wù)。比如游客通過手機、IPAD 等工具，到網(wǎng)上查詢觀光信息、網(wǎng)上訂票，還可以訂制私人旅游線路，合理安排個人日程，最大化地利用旅游時間?？傮w解決方案總體的解決方案是采用成熟、商用、穩(wěn)定的 Hadoop 云平臺HDP，核心技術(shù)主要是Hadoop 與其生

19、態(tài)系統(tǒng)的整個云技術(shù)家族。本平臺架構(gòu)包括數(shù)據(jù)訪問、數(shù)據(jù)管制與集成和數(shù)據(jù)監(jiān)控模塊，平臺提供了豐富的大數(shù)據(jù)接口，為國家旅游各大平臺提供大數(shù)據(jù)的支撐，比如：旅游公共信息發(fā)布及資訊平臺，中國旅游產(chǎn)業(yè)運行監(jiān)管平臺，全國各景區(qū)門票預約與客流預警平臺，多語種的旅游形象推廣平臺等。詳細如下如所示：圖 10-1 Hadoop 云平臺總解決方案圖國家旅游數(shù)據(jù)最重要的是數(shù)據(jù)分析，通過 HDP，可以得到如下的分析：圖 10-2 數(shù)據(jù)分析方案圖數(shù)據(jù)分析結(jié)果快速形成圖表：圖 10-3 數(shù)據(jù)分析展示圖旅游大數(shù)據(jù)分析平臺需要從各個景點的系統(tǒng)傳輸大量的非結(jié)構(gòu)化數(shù)據(jù)文件，我們的文件傳輸解決方案是：320圖 10-4 旅游大數(shù)據(jù)文件

20、數(shù)據(jù)傳輸圖總平臺旅游大數(shù)據(jù)的存儲解決方案 旅游大數(shù)據(jù)不斷增長造成單機系統(tǒng)性能不斷下降，即使不斷提升硬件配置也難以跟上數(shù)據(jù)的增長速度。然而，當今主流的計算機硬件比較便宜而且可以擴展，現(xiàn)在購置八臺 8 內(nèi)核、128GB 內(nèi)存的機器比購置一臺 64 內(nèi)核、TB 級別內(nèi)存的服務(wù)器劃算得多，而且還可以增加或減少機器來應(yīng)對將來的變化。因此選擇 Hadoop 云平臺的大數(shù)據(jù)存儲方案。存儲方案核心技術(shù) 其存儲的核心技術(shù)解決方案是： 高性能分布式存儲系統(tǒng)：HBASE（數(shù)據(jù)庫的首選技術(shù)） 高度容錯性分布式文件系統(tǒng)：HDFS （文件存儲首選技術(shù)）方案核心技術(shù)介紹 HDFS：Hadoop Distributed Fi

21、le System，簡稱 HDFS ，是一個分布式文件系統(tǒng).HDFS 有著高容錯性（fault-tolerant）的特點，并且設(shè)計用來部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）來訪問應(yīng)用程序的數(shù)據(jù)，適合那些有著超大數(shù)據(jù)集（large data set）的應(yīng)用程序。 HBASE:HBase Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用 HBase 技術(shù)可在廉價 PC Server 上搭建起大規(guī)模結(jié)構(gòu)化存儲集群。方案設(shè)計圖 圖 10-5 總平臺旅游大數(shù)據(jù)的存儲解決方案圖總平臺旅游大數(shù)據(jù)的計算解決方案

22、其分析的核心技術(shù)解決方案是： 高性能并行計算引擎：MapReduce2.0（離線）、Spark（內(nèi)存）、Storm（實時）、Tez （底層）MapReduce2.0 的介紹 MapReduce 2.0 或者 MRv2 具有與 MRv1 相同的編程模型，唯一不同的是運行時環(huán)境。MRv2 是在 MRv1 基礎(chǔ)上經(jīng)加工之后，運行于資源管理框架 YARN 之上的 MRv1，它不再由 JobTracker 和 TaskTracker 組成，而是變?yōu)橐粋€作業(yè)控制進程 ApplicationMaster，且ApplicationMaster 僅負責一個作業(yè)的管理，至于資源的管理，則由 YARN 完成。簡而言

23、之，MRv1 是一個獨立的離線計算框架,而 MRv2 則是運行于 YARN 之上的 MRv1。Spark 的介紹 Spark 基于 map reduce 算法實現(xiàn)的分布式計算，擁有 Hadoop 、MapReduce 所具有的優(yōu)點；但不同于 MapReduce 的是 Job 中間輸出和結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫 HDFS，因此 Spark 能更好地適用于數(shù)據(jù)挖掘與機器學習等需要迭代的 map、reduce 的算法。Storm 的介紹 Storm 是一個免費開源、分布式、高容錯的實時計算系統(tǒng)。Storm 令持續(xù)不斷的流計算變得容易，彌補了 Hadoop 批處理所不能滿足的實時要求。S

24、torm 經(jīng)常用于在實時分析、在線機器學習、持續(xù)計算、分布式遠程調(diào)用和 ETL 等領(lǐng)域。Storm 的部署管理非常簡單，而且，在同類的流式計算工具，Storm 的性能也是非常出眾的。Tez 的介紹 Tez 是基于 Hadoop Yarn 之上的 DAG（有向無環(huán)圖，Directed Acyclic Graph）計算框架。它把ap/Reduce 過程拆分成若干個子過程，同時可以把多個ap/Reduce 任務(wù)組合成一個較大的 DAG 任務(wù)，減少了 Map/Reduce 之間的文件存儲。同時合理組合其子過程，也可以減少任務(wù)的運行時間。方案設(shè)計圖 總的來說，各核心技術(shù)各有所長，比如，MapReduce

25、:是一種離線計算框架，將一個算法抽象成 Map 和 Reduce 兩個階段進行處理，非常適合數(shù)據(jù)密集型計算。 而 Spark 則是一種內(nèi)存計算框架，它將數(shù)據(jù)盡可能放到內(nèi)存中以提高迭代應(yīng)用和交互式應(yīng)用的計算效率。Storm:MapReduce 也不適合進行流式計算、實時分析，比如廣告點擊計算等，而 Storm 則更擅長這種計算、它在實時性要遠遠好于 MapReduce 計算框架。Tez: 運行在 YARN 之上支持 DAG 作業(yè)的計算框架，并且更底層，對 pig，hive 等的支持比較高。圖 10-6 總平臺旅游大數(shù)據(jù)的計算解決方案圖總平臺旅游大數(shù)據(jù)的文件傳輸解決方案 旅游大數(shù)據(jù)平臺收集的非機構(gòu)

26、化數(shù)據(jù)來自不同的景區(qū)，通過廣域網(wǎng)遠距離行傳輸。而且非機構(gòu)化數(shù)據(jù)一般較大，例如音頻，視頻，圖片等，文件大小 500M 以上，甚至幾 G 幾十 G。如果通過 FTP 工具傳輸，面臨傳輸速度低，出錯概率大等困難，從而造成數(shù)據(jù)到應(yīng)用的延誤。而且 FTP 不能提供詳盡、易讀的傳輸日志信息，故障診斷和修復的時間會大大增加。文件傳輸解決方案“數(shù)據(jù)通”(Fast File Transfer: FFT)提供文件網(wǎng)關(guān)，核心傳輸工具， 安全認證，傳輸監(jiān)控等功能，為企業(yè)提供一個統(tǒng)一，安全，高效的傳輸平臺。方案功能介紹 FFT 的核心傳輸工具采用一種全新的技術(shù)，克服了傳統(tǒng)數(shù)據(jù)傳輸軟件，例如 FTP, HTTP 以及 W

27、indows CIFS 中的固有瓶頸,實現(xiàn)了在各種共享和私有網(wǎng)絡(luò)環(huán)境中 傳輸速度的 最大化。這種技術(shù)可以獲得完美 的傳輸效率,不為網(wǎng)絡(luò)延遲和丟包所限制。并且用戶享有對傳輸速度以及不同傳輸流 之間帶寬共享的無以倫比的控制。不管網(wǎng)絡(luò) 距離和動態(tài)性能如何, 即便是在最困難的網(wǎng) 絡(luò)條件下(例如衛(wèi)星,無線和洲際遠程鏈接),文件傳輸時間仍然可以得到保障。FFT 具有內(nèi)置的完整安全性功能，包括連接節(jié)點安全驗證,傳輸中數(shù)據(jù)加密以及數(shù)據(jù)完整性驗證。FFT 具有出色的帶寬控制功能，提供了有保障的傳輸時間，充分利用了可用帶寬，同時讓其他網(wǎng)絡(luò)流量可公平使用帶寬。FFT 擁有靈活開放的架構(gòu)，支持在所有主要的操作系統(tǒng)直接

28、的跨平臺傳輸，提供開放的可擴展的軟件開發(fā)包，API 接口，能夠方便的將“數(shù)據(jù)通”的技術(shù)和產(chǎn)品無縫集成到現(xiàn)有的應(yīng)用程序和工作流程管理平臺中。FFT 提供了一個統(tǒng)一的監(jiān)控管理平臺，方便用戶監(jiān)控當前各個“數(shù)據(jù)通”節(jié)點的健康狀態(tài)，管理傳輸節(jié)點的用戶和服務(wù)器配置，Console 還可以實時管理各節(jié)點的傳輸，同時可對各個節(jié)點進行傳輸統(tǒng)計。傳輸架構(gòu)設(shè)計 各地方景點都會用 FFT P2P Server 將各地數(shù)據(jù)上傳到旅游大數(shù)據(jù)平臺，F(xiàn)FT Console監(jiān)控所 FFT 服務(wù)器的運行。此外還可以考慮 HA 架構(gòu)保證服務(wù)的不間斷性。圖 10-7 傳輸架構(gòu)設(shè)計圖平臺總體設(shè)計Hadoop 云平臺的總設(shè)計原則 Had

29、oop 云平臺作為大數(shù)據(jù)的分布式的計算平臺，必須具備分布式系統(tǒng)設(shè)計的重要且必須的設(shè)計原則，本平臺嚴格根據(jù)以下分布式系統(tǒng)的設(shè)計原則進行設(shè)計：High Reliability 高可靠性High Scalabilty高可擴展性High Robustness 高魯棒性High Availabity高可用性高可靠性 硬件錯誤是常態(tài)而不是異常。HDFS 可能由成百上千的服務(wù)器所構(gòu)成，每個服務(wù)器上存儲著文件系統(tǒng)的部分數(shù)據(jù)。我們面對的現(xiàn)實是構(gòu)成系統(tǒng)的組件數(shù)目是巨大的，而且任一組件都有可能失效，這意味著總是有一部分 HDFS 的組件是不工作的。因此錯誤檢測和快速、自動的恢復是 HDFS 最核心的架構(gòu)目標。高可擴

30、展性 運行在 HDFS 上的應(yīng)用具有很大的數(shù)據(jù)集。HDFS 上的一個典型文件大小一般都在 G 字節(jié)至 T 字節(jié)。因此，HDFS 被調(diào)節(jié)以支持大文件存儲。它應(yīng)該能提供整體上高的數(shù)據(jù)傳輸帶寬，能在一個集群里擴展到數(shù)百個節(jié)點。一個單一的 HDFS 實例應(yīng)該能支撐數(shù)以千萬計的文件。高魯棒性 引入 Federation 的最主要原因是簡單，其簡單性是與真正的分布式 Namenode 相比而言的。Federation 能夠快速的解決了大部分單 Namenode HDFS 的問題。Federation 是簡單魯棒的設(shè)計，由于聯(lián)盟中各個 Namenode 之間是相互獨立的。大部分改變是在 Datanode、C

31、onfig 和 Tools，而 Namenode 本身的改動非常少，這樣 Namenode 原先的魯棒性不會受到影響。比分布式的 Namenode 簡單，雖然這種實現(xiàn)的擴展性比起真正的分布式的 Namenode 要小些，但是可以迅速滿足需求。另外一個原因是 Federation 良好的向后兼容性，已有的單 Namenode 的部署配置不需要任何改變就可以繼續(xù)工作。因此Federation（聯(lián)盟）是未來可選的方案之一。在 Federation 架構(gòu)中可以無縫的支持目前單Namenode 架構(gòu)中的配置。高可用性 hadoop2.0 的 HA 機制有兩個 namenode，一個是 active na

32、menode，狀態(tài)是 active；另外一個是 standby namenode，狀態(tài)是 standby。兩者的狀態(tài)是可以切換的，但不能同時兩個都是 active 狀態(tài)，最多只有 1 個是 active 狀態(tài)。只有 active namenode 提供對外的服務(wù)， standby namenode 是不對外服務(wù)的。active namenode 和 standby namenode 之間通過 NFS 或者 JN（journalnode，QJM 方式）來同步數(shù)據(jù)。Hadoop 云平臺架構(gòu) 圖 10-8 Hadoop 云平臺架構(gòu)圖平臺的基礎(chǔ)架構(gòu)設(shè)計 智慧旅游公共服務(wù)平臺需要云計算基礎(chǔ)架構(gòu) 為了快速

33、構(gòu)建以上各種平臺以滿足業(yè)務(wù)功能的建設(shè)，運營和擴張，更好的支撐智慧旅游業(yè)務(wù)的經(jīng)營，需要高等級基礎(chǔ)架構(gòu)平臺進行支撐。根據(jù)旅游行業(yè)的特點，我們建議采用云化的基礎(chǔ)架構(gòu)進行支撐。同時，采用雙活/多活架構(gòu)來滿足業(yè)務(wù)連續(xù)性和客戶體驗的要求。旅游產(chǎn)業(yè)自身是綜合性服務(wù)產(chǎn)業(yè)，同時旅游產(chǎn)業(yè)與其他產(chǎn)業(yè)的正在不斷的深度融合， 這就要求要求智慧旅游的基礎(chǔ)架構(gòu)平臺要能與未來城市與社會服務(wù)的對接能力要能夠支撐未來 510 年的發(fā)展需求，根據(jù)最佳實踐，按需建設(shè)的業(yè)務(wù)需要云化的基礎(chǔ)架構(gòu)。旅游行業(yè)具有季節(jié)性、周期性，作為行業(yè)平臺，需要按需擴展的計算能力進行支撐， 這就必須采用先進的云化建設(shè)模式來滿足業(yè)務(wù)高峰期的處理能力。旅游行業(yè)的

34、客戶體驗具有跨地域特點，同時考慮途體驗和地域體驗，需要平臺能夠為整個過程提供一致的漫游體驗。因此，需要考慮在全國進行業(yè)務(wù)能力的建設(shè)，初期計劃使用雙活的數(shù)據(jù)中心設(shè)計來滿足南北大區(qū)客戶的需求。同時，我們也應(yīng)充分考慮未來旅游業(yè)務(wù)模式的不斷創(chuàng)新的必然性。智慧旅游提供核心基礎(chǔ)架構(gòu)整體設(shè)計 智慧旅游基礎(chǔ)架構(gòu)平臺的整體架構(gòu)設(shè)計：圖 10-9 智慧旅游基礎(chǔ)架構(gòu)平臺的整體架構(gòu)設(shè)計圖在初期建設(shè)中，采用南-北雙活的數(shù)據(jù)中心結(jié)構(gòu)來滿足整個中國的業(yè)務(wù)需求：圖 10-10 南-北雙活的數(shù)據(jù)中心結(jié)構(gòu)圖集中監(jiān)控模塊將各數(shù)據(jù)中心的運行狀態(tài)進行匯總并實現(xiàn)部分自動化操作負載均衡模塊將交易、瀏覽請求發(fā)送至正確的處理節(jié)點并將結(jié)果送回客

35、戶端數(shù)據(jù)復制模塊在數(shù)據(jù)中心間維持數(shù)據(jù)的一致性數(shù)據(jù)中心間軟硬件、網(wǎng)絡(luò)配置一致，同時通過軟件分發(fā)機制及工具維持版本管理跨中心的變更管理、問題管理流程和工具支持技術(shù)構(gòu)架模式上，采用以 POD 為建設(shè)單位的標準化建設(shè)機制：數(shù)據(jù)中心站點內(nèi)的部署結(jié)構(gòu) 多活數(shù)據(jù)中心的整體網(wǎng)絡(luò)架構(gòu)實現(xiàn)：圖 10-11 多活數(shù)據(jù)中心的整體網(wǎng)絡(luò)架構(gòu)在數(shù)據(jù)中心的內(nèi)部，根據(jù)業(yè)務(wù)要求，需要劃分如下邏輯區(qū)域：測試區(qū)核心生產(chǎn)區(qū)域DMZ 區(qū)域管理區(qū)域存儲區(qū)域合理的邏輯分區(qū)保證了業(yè)務(wù)的有序開展數(shù)據(jù)中心外的部署結(jié)構(gòu) CDN 內(nèi)容加速網(wǎng)絡(luò)的建設(shè)也是保證海量客戶體驗的基礎(chǔ)，擬在初期建設(shè)階段完成后， 在后續(xù)階段完成國內(nèi) CDN 節(jié)點的部署。圖 10-

36、12 CDN 內(nèi)容加速網(wǎng)絡(luò)圖CDN 服務(wù)以多媒體視頻為例：圖 10-13 CDN 服務(wù)以多媒體視頻圖考慮國外訪問的需求，在國內(nèi) CDN 網(wǎng)絡(luò)建成后，將前端業(yè)務(wù)平臺擴展到國外。同時完成與國際平臺（B2B 對接，O2O 平臺對接，支付平臺與渠道對接，其他行業(yè)應(yīng)用平臺對接）的整合。擬采用 Softlayer 平臺完成國外的平臺承載能力。整體運維方案 圖 10-14 整體運維圖安全架構(gòu)設(shè)計 在云環(huán)境下，安全管控將發(fā)生如下變化：圖 10-15 安全架構(gòu)設(shè)計圖其中，“基于云的服務(wù)與管理”指智慧旅游公共云提供的公共云安全服務(wù)。本項目將進行適當評估這些云服務(wù)的必要性，并進行整合分析。具體而言，將在如下層面實現(xiàn)

37、安全：終端網(wǎng)絡(luò)業(yè)務(wù)接口資源池： PAGE 344云計算管理平臺：數(shù)據(jù)中心：業(yè)務(wù)連續(xù)性的設(shè)計 可以預見，智慧旅游公共服務(wù)平臺將在未來融入中國社會的重要信息化支撐體系，其信息系統(tǒng)的安全將會直接影響到國民經(jīng)濟的正常運行，直接關(guān)系到社會穩(wěn)定和群眾生活。我國信息安全的防護能力較弱，安全保障水平不高，就信息化平臺來說，建立統(tǒng)一的災(zāi)難恢復和業(yè)務(wù)連續(xù)性管理機制，信息安全和災(zāi)難恢復工作是必須考慮的需求。智慧旅游公共服務(wù)平臺采用雙活/多活的基礎(chǔ)架構(gòu)設(shè)計，在建設(shè)時，充分考慮了業(yè)務(wù)連續(xù)性的設(shè)計。在業(yè)務(wù)連續(xù)和容災(zāi)備份建設(shè)中，以下幾個概念非常重要，它們也是衡量業(yè)務(wù)持續(xù)以及容災(zāi)備份需求的指標。恢復時間目標（RTO）恢復時間

38、目標（Recovery Time Objective，簡稱 RTO）是指信息系統(tǒng)突發(fā)事件發(fā)生后， 從信息系統(tǒng)故障導致業(yè)務(wù)停頓時刻開始，到信息系統(tǒng)恢復至可支持各部門運作、業(yè)務(wù)恢復運營之時，此兩點之間的時間段稱為 RTO。一般而言，RTO 時間越短，即意味要求在更短的時間內(nèi)恢復業(yè)務(wù)至可使用狀態(tài)。雖然從管理的角度而言，RTO 時間越短越好，但是，這同時也意味著更多成本的投入。RTO 目標的確定可以用下圖來說明：圖 10-16 RTO 指標恢復點目標（RPO）恢復點目標（Recovery Point Objective，簡稱 RPO）是指對系統(tǒng)和應(yīng)用數(shù)據(jù)而言，要實現(xiàn)能夠恢復至可以支持各部門業(yè)務(wù)運作，系

39、統(tǒng)及生產(chǎn)數(shù)據(jù)應(yīng)恢復到怎樣的更新程度。這種更新程度可以是上一周的備份數(shù)據(jù)，也可以是上一次交易的實時數(shù)據(jù)。與 RTO 目標不同，RPO 目標的確定不是依賴于企業(yè)業(yè)務(wù)規(guī)模，而是取決于企業(yè)業(yè)務(wù)的性質(zhì)和業(yè)務(wù)操作對數(shù)據(jù)的依賴程度。因此，RPO 目標對相同行業(yè)的企業(yè)而言會有些接近， 而對于不同行業(yè)的企業(yè)來說仍可能會有較大差距。業(yè)務(wù)連續(xù)性的需求 業(yè)務(wù)連續(xù)性有如下的建設(shè)需求考慮資源整合和架構(gòu)優(yōu)化，逐步按照生產(chǎn)、查詢、公共服務(wù)、交換等多種專業(yè)分區(qū)管理，形成南北中心一體化基礎(chǔ)架構(gòu)和運維支持專業(yè)體系；防范可能的不同級別的災(zāi)難的發(fā)生（設(shè)備、機房、區(qū)域性等）成為目前風險防范的重點；需要制定成體系的、規(guī)范的災(zāi)難恢復制度和計

40、劃；需要建設(shè)規(guī)范的、有清晰責任定義的災(zāi)難恢復管理組織；災(zāi)備機制需要針對核心生產(chǎn)進行有計劃的演練，以確保災(zāi)備中心的真實可用。業(yè)務(wù)連續(xù)性的模式設(shè)計1、災(zāi)備工作模式常見的災(zāi)備工作模式主要有兩種，即主備模式和雙活模式；主備模式是災(zāi)備中心處于備份接管狀態(tài)，不對外提供服務(wù)；雙活模式是災(zāi)備中心承擔對外服務(wù)功能，通常需要遠程集群處理技術(shù)支持。本次項目建設(shè)的模式的雙活模式。該模式在系統(tǒng)建設(shè)開始時同步考慮災(zāi)備的實現(xiàn)，即北方生產(chǎn)中心對客戶提供服務(wù)的同時，南方生產(chǎn)中心同時為客戶提供服務(wù)。系統(tǒng)具有如下特點：高可用性最佳實踐所有數(shù)據(jù)中心均為生產(chǎn)中心無需計劃停機維護窗口完全杜絕數(shù)據(jù)中心災(zāi)難、網(wǎng)絡(luò)故障對生產(chǎn)的停頓影響，無需通

41、常意義上的災(zāi)難切換過程所有數(shù)據(jù)中心完全配置一致全局動態(tài)負載均衡絕大部分非計劃性停機故障可由雙中心架構(gòu)自行屏蔽對應(yīng)用影響與網(wǎng)銀類似的 B/S 類型應(yīng)用架構(gòu)，三層模型在計劃內(nèi)維護的場景下：“滾動式計劃停機”對數(shù)據(jù)中心的重大計劃內(nèi)維護可以在正常工作時間完成-由最好的技術(shù)資源支持廣播通知計劃停機信息將計劃維護的數(shù)據(jù)中心從生產(chǎn)處理候選列表摘除停止應(yīng)用、數(shù)據(jù)庫等運行實施所需的任何維護操作應(yīng)用重新啟動測試并確認維護結(jié)果廣播通知計劃內(nèi)維護結(jié)束信息交易請求重新導向維護后的數(shù)據(jù)中心2、運行管理模式多中心并行架構(gòu)對統(tǒng)一監(jiān)控的要求統(tǒng)一監(jiān)控平臺或者 ECC監(jiān)控平臺本身需要雙中心冗余或者也為多中心并行架構(gòu)7*24 在線輪

42、值多中心并行架構(gòu)對運維流程的要求統(tǒng)一日常運行維護，對一個中心的維護必須考慮到對另外一個中心的影響統(tǒng)一變更管理、問題管理、配置管理、版本管理和軟件分發(fā)需要與一體化運維保持一個整體運行，與一體化運維有雙向接口多中心并行架構(gòu)對組織架構(gòu)的要求雙中心間的關(guān)系為既獨立又統(tǒng)一的關(guān)系基礎(chǔ)設(shè)施管理、硬件維護等獨立性較強的工作，可以設(shè)置為垂直管理涉及到多中心并行中心運作的其他運維工作，需要統(tǒng)一的組織架構(gòu)以方便溝通提高效率需要便捷有效的溝通平臺支持協(xié)調(diào)工作，IM 是一個成熟可行的方式，溝通平臺本身也需要雙中心冗余高用性設(shè)計 HDFS 的 HA 功能通過配置 Active/Standby 兩個 NameNodes 實

43、現(xiàn)在集群中對NameNode 的熱備來解決單點故障問題。HDFS HA 的解決方案可謂百花齊放，Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode 等等。目前普遍采用的是 shared NAS+NFS，因為簡單易用，但是需要提供一個 HA 的共享存儲設(shè)備。而社區(qū)版已經(jīng)把基于 QJM/Quorum Journal Manager 的方案 merge 到 trunk 了。高可擴展性是來自于 hadoop 的存儲方案 HDFS，現(xiàn)在急需大規(guī)模的部署和應(yīng)用的商用方案。在大規(guī)模部署

44、中，熟練使用和 Ambari 是必須且首要的選擇。而在 CM 與 Ambari 中只有 Ambari 是 Apache 的頂級開源項目，所以選擇 Ambari 來管理并設(shè)計。圖 10-17 Hadoop 云平臺運行監(jiān)控圖業(yè)務(wù)分析平臺 作為業(yè)務(wù)分析和決策支持的手段分為四種：標準報表、主題分析、在線分析、數(shù)據(jù)挖掘。1、標準報表標準報表是決策支持平臺的核心功能，可以綜合日常醫(yī)療衛(wèi)生報表序列。2、主題分析主題是在較高層次上將組織信息系統(tǒng)中的數(shù)據(jù)進行綜合、歸類和分析利用的一個抽象概念，每一個主題基本對應(yīng)一個宏觀的分析領(lǐng)域。在邏輯意義上，它是對應(yīng)組織中某一宏觀分析領(lǐng)域所涉及的分析對象。面向主題的數(shù)據(jù)組織方

45、式，就是在較高層次上對分析對象數(shù)據(jù)的一個完整并且一致的描述，能刻畫各個分析對象所涉及的企業(yè)各項數(shù)據(jù)，以及數(shù)據(jù)之間的聯(lián)系。所謂較高層次是相對面向應(yīng)用的數(shù)據(jù)組織方式而言的，是指按照主題進行數(shù)據(jù)組織的方式具有更高的數(shù)據(jù)抽象級別。與傳統(tǒng)數(shù)據(jù)庫面向應(yīng)用進行數(shù)據(jù)組織的特點相對應(yīng)，數(shù)據(jù)倉庫中的數(shù)據(jù)是面向主題進行組織的。3、聯(lián)機分析聯(lián)機分析處理（OLAP）是使分析人員、管理人員或執(zhí)行人員能夠從多角度對信息進行 快速、一致、交互地存取,從而獲得對數(shù)據(jù)的更深入了解的一類軟件技術(shù)。OLAP 的目標是滿足決策支持或者滿足在多維環(huán)境下特定的查詢和報表需求,它的技術(shù)核心是維這個概念?！熬S”是人們觀察客觀世界的角度,是一種

46、高層次的類型劃分?！熬S”一般包含著層次關(guān)系, 這種層次關(guān)系有時會相當復雜。通過把一個實體的多項重要的屬性定義為多個維，使用戶 能對不同維度上的數(shù)據(jù)進行比較。因此 OLAP 也可以說是多維數(shù)據(jù)分析工具的集合。OLAP 的基本多維分析操作有鉆取、切片和切塊、以及旋轉(zhuǎn)等。鉆取是改變維的層次，變換分析 的粒度。它包括向上鉆取和向下鉆取。向上鉆取是在某一維上將低層次的細節(jié)數(shù)據(jù)概括到 高層次的匯總數(shù)據(jù)，或者減少維數(shù)；而向下鉆取則相反，它從匯總數(shù)據(jù)深入到細節(jié)數(shù)據(jù)進 行觀察或增加新維。切片和切塊是在一部分維上選定值后，關(guān)心度量數(shù)據(jù)在剩余維上的分 布。如果剩余的維只有兩個，則是切片；如果有三個，則是切塊。旋轉(zhuǎn)是

47、變換維的方向， 即在表格中重新安排維的放置（例如行列互換）。OLAP 有多種實現(xiàn)方法，根據(jù)存儲數(shù)據(jù)的方式不同可以分為關(guān)系 OLAP（ROLAP）、多維 OLAP（MOLAP）、混合 OLAP（HOLAP）。ROLAP 表示基于關(guān)系數(shù)據(jù)庫的 OLAP 實現(xiàn)。以關(guān)系數(shù)據(jù)庫為核心,以關(guān)系型結(jié)構(gòu)進行多維數(shù)據(jù)的表示和存儲。ROLAP 將多維數(shù)據(jù)庫的多維結(jié)構(gòu)劃分為兩類表:一類是事實表,用來存儲數(shù)據(jù)和維關(guān)鍵字;另一類是維表,即對每個維至少使用一個表來存放維的層次、成員類別等維的描述信息。維表和事實表通過主關(guān)鍵字和外關(guān)鍵字聯(lián)系在一起,形成了“星型模式”。對于層次復雜的維,為避免冗余數(shù)據(jù)占用過大的存儲空間,可以

48、使用多個表來描述,這種星型模 式 的 擴 展 稱 為 “ 雪花模式 ” 。 MOLAP 表 示 基 于 多 維 數(shù) 據(jù) 組織的 OLAP 實現(xiàn) （Multidimensional OLAP）。以多維數(shù)據(jù)組織方式為核心,也就是說,MOLAP 使用多維數(shù)組存儲數(shù)據(jù)。多維數(shù)據(jù)在存儲中將形成立方塊（Cube）的結(jié)構(gòu),在 MOLAP 中對立方塊的 旋轉(zhuǎn)、切塊、切片是產(chǎn)生多維數(shù)據(jù)報表的主要技術(shù)。HOLAP 表示基于混合數(shù)據(jù)組織的OLAP 實現(xiàn)（Hybrid OLAP）。如低層是關(guān)系型的，高層是多維矩陣型的。這種方式具有更好的靈活性。4、數(shù)據(jù)挖掘數(shù)據(jù)挖掘是根據(jù)企業(yè)的既定業(yè)務(wù)目標和存在的問題，對大量的業(yè)務(wù)數(shù)據(jù)

49、進行探索，揭示隱藏其中的規(guī)律，并將其模型化，指導并應(yīng)用于實際的企業(yè)經(jīng)營中。數(shù)據(jù)挖掘與 OLAP 分析、預定義報表和即席查詢等有很大的區(qū)別。后三者通常是用戶對所關(guān)心的業(yè)務(wù)指標，按照已知的角度進行分析；而前者則是在業(yè)務(wù)問題和目標明確，但考察的角度不清楚時，對數(shù)據(jù)進行探索，揭示隱藏其中的規(guī)律性，進而將其模型化。不同的實際問題所采用的數(shù)據(jù)挖掘方法有所不同，有的問題甚至需要結(jié)合多種方法共同進行解決。數(shù)據(jù)挖掘的方法一般分為預測型和描述型。具體而言，本系統(tǒng)要求數(shù)據(jù)挖掘應(yīng)用能支持以下各類方法：預測型（Predictive）方法通常包含以下幾種：分類(Classification)/決策樹算法(Decision

50、 Tree)回歸分析（Regression）時間序列分析（Time Series）描述型（Descriptive）方法通常包含以下幾種：關(guān)聯(lián)分析（Association Analysis）序列關(guān)聯(lián)分析（Sequential Analysis） 聚類分析（Clustering）數(shù)據(jù)管理平臺 主要的組件是 HDFS 和 YARN。HDFS 的介紹 Hadoop 分布式文件系統(tǒng)（HDFS）是運行在通用硬件上的分布式文件系統(tǒng)。HDFS 提供了一個高度容錯性和高吞吐量的海量數(shù)據(jù)存儲解決方案。HDFS 已經(jīng)在各種大型在線服務(wù)和大型存儲系統(tǒng)中得到廣泛應(yīng)用，已經(jīng)成為海量數(shù)據(jù)存儲的事實標準。隨著信息系統(tǒng)的快速發(fā)

51、展，海量的信息需要可靠存儲的同時，還能被大量的使用者快速地訪問。傳統(tǒng)的存儲方案已經(jīng)從構(gòu)架上越來越難以適應(yīng)近幾年來的信息系統(tǒng)業(yè)務(wù)的飛速發(fā)展，成為了業(yè)務(wù)發(fā)展的瓶頸和障礙。HDFS 通過一個高效的分布式算法，將數(shù)據(jù)的訪問和存儲分布在大量服務(wù)器之中，在可靠地多備份存儲的同時還能將訪問分布在集群中的各個服務(wù)器之上，是傳統(tǒng)存儲構(gòu)架的一個顛覆性的發(fā)展。HDFS 可以提供以下特性：可自我修復的分布式文件存儲系統(tǒng)高可擴展性，無需停機動態(tài)擴容高可靠性，數(shù)據(jù)自動檢測和復制高吞吐量訪問，消除訪問瓶頸使用低成本存儲和服務(wù)器構(gòu)建YARN 的介紹 YARN 是下一代 MapReduce，即 MRv2，是在第一代 MapRe

52、duce 基礎(chǔ)上演變而來的， 主要是為了解決原始 Hadoop 擴展性較差，不支持多計算框架而提出的。它完全不同于Hadoop MapReduce，所有代碼全部重寫而成。整個平臺由 Resource Manager（master，功能是資源分配）和 Node Manager 組成（slave，功能是節(jié)點管理）。較于HadoopMapReduce，其最大特點是將 JobTracker 拆分成 Resource Manager 和 ApplicationMaster，其中 Resource Manager 是全局的資源管理器，僅負責資源分配（由于 ResourceManager 功能簡單，所以不會

53、嚴重制約系統(tǒng)的擴展性），而 Application Master 對應(yīng)一個具體的 application（如 Hadoop job， Spark Job 等），主要負責 application 的資源申請，啟動各個任務(wù)和運行狀態(tài)監(jiān)控（沒有調(diào)度功能）。所以 YARN,作為資源統(tǒng)一管理和調(diào)度平臺， 具有以下的特點支持多種計算框架資源統(tǒng)一管理和調(diào)度平臺應(yīng)該提供一個全局的資源管理器。所有接入的框架要先向該全局資源管理器申請資源，申請成功之后，再由框架自身的調(diào)度器決定資源交由哪個任務(wù)使用，也就是說，整個大的系統(tǒng)是個雙層調(diào)度器，第一層是統(tǒng)一管理和調(diào)度平臺提供的， 另外一層是框架自身的調(diào)度器。資源統(tǒng)一管理和

54、調(diào)度平臺應(yīng)該提供資源隔離。不同的框架中的不同任務(wù)往往需要的資源（內(nèi)存，CPU，網(wǎng)絡(luò) IO 等）不同，它們運行在同一個集群中，會相互干擾，為此，應(yīng)該提供一種資源隔離機制避免任務(wù)之間由資源爭用導致效率下降。擴展性好現(xiàn)有的分布式計算框架都會將系統(tǒng)擴展性作為一個非常重要的設(shè)計目標，比如Hadoop，好的擴展性意味著系統(tǒng)能夠隨著業(yè)務(wù)的擴展線性擴展。資源統(tǒng)一管理和調(diào)度平臺融入多種計算框架后，不應(yīng)該破壞這種特性，也就是說，統(tǒng)一管理和調(diào)度平臺不應(yīng)該成為制約框架進行水平擴展。容錯性同擴展性類似，容錯性也是當前分布式計算框架的一個重要設(shè)計目標，統(tǒng)一管理和調(diào)度平臺在保持原有框架的容錯特性基礎(chǔ)上，自己本身也應(yīng)具有良好

55、的容錯性。高資源利用率如果采用靜態(tài)資源分配，也就是每個計算框架分配一個集群，往往由于作業(yè)自身的特點或者作業(yè)提交頻率等原因，集群利用率很低。當將各種框架部署到同一個大的集群中，進行統(tǒng)一管理和調(diào)度后，由于各種作業(yè)交錯且作業(yè)提交頻率大幅度升高，則為資源利用率的提升增加了機會。非結(jié)構(gòu)化大數(shù)據(jù)管理及內(nèi)容分析平臺 圖 10-18 非結(jié)構(gòu)大數(shù)據(jù)管理及分析平臺圖非結(jié)構(gòu)化大數(shù)據(jù)管理及分析平臺由以下幾個主要功能模塊組成： 統(tǒng)一的非結(jié)構(gòu)化數(shù)據(jù)管理模塊，內(nèi)容分析模塊，報表/BI 的連接及數(shù)據(jù)導出模塊。外部的非結(jié)構(gòu)化數(shù)據(jù)，包括文檔， 圖片，音頻，視頻等形式的非結(jié)構(gòu)化數(shù)據(jù)，通過上傳，保存，歸檔等功能，保存在非結(jié)構(gòu)化統(tǒng)一的

56、內(nèi)容管理平臺中，內(nèi)容管理由傳統(tǒng)的數(shù)據(jù)庫和 HBase 作為適用于不同類型業(yè)務(wù)的索引信息及元數(shù)據(jù)管理。小文件（主要包括文檔， 圖片等）保存在傳統(tǒng)的存儲設(shè)備，比較大的文件，則保存在 HDFS 的分布式文件存儲中。存儲的管理，由內(nèi)容管理模塊中的存儲設(shè)備管理和存儲策略管理功能實現(xiàn)自動化。在傳統(tǒng)存儲中的小文件，由于生命周期等觸發(fā)條件，可以由內(nèi)容管理模塊中的內(nèi)容歸檔系統(tǒng)，打包保存到 HDFS 中。非結(jié)構(gòu)化內(nèi)容管理模塊景點非結(jié)構(gòu)化數(shù)據(jù)的快速管理。分別針對各個景點的資料，可以對接收景點大數(shù)據(jù)信息的進行模版化的快速創(chuàng)建。如下圖，可以針對北京故宮景點，直接指定景點模版創(chuàng)建。圖 10-19 景點模板圖通過模版創(chuàng)建的

57、分類管理，可以針對不同景點，旅游局不同業(yè)務(wù)部門，快速建立對應(yīng)的團隊管理空間。如下兩個示例：杭州西湖景區(qū)的內(nèi)容管理和模版保持一致。圖 10-20 模板創(chuàng)建圖同時，在不同景點管理空間內(nèi)，景點的管理員可以自己進行更詳細的管理。如下圖： 故宮特色的展覽資料管理等。圖 10-21 景點資料管理圖帶有索引信息的非結(jié)構(gòu)化數(shù)據(jù)的管理。如下圖，保存非結(jié)構(gòu)化數(shù)據(jù)的時候，保留適當?shù)脑獢?shù)據(jù)索引信息，方便信息的快速查詢。圖 10-22 信息查詢圖針對視頻資料的管理，除了在原始文件的管理基礎(chǔ)上，還利用大數(shù)據(jù)平臺，進行各種編碼的轉(zhuǎn)換，適應(yīng)在不同的終端上，景點的宣傳播放。內(nèi)容管理平臺內(nèi)置的詳細的安全權(quán)限管理，達到不同景點，不

58、同的部門間權(quán)限可控。圖 10-23 權(quán)限管理圖統(tǒng)一的內(nèi)容管理平臺具備不同存儲設(shè)備的管理功能。如下，針對傳統(tǒng)的存儲，和 HDFS 的分布式存儲，可以通過存儲策略直接進行管理。內(nèi)容分析功能圖 10-24 非結(jié)構(gòu)化數(shù)據(jù)存儲圖大數(shù)據(jù)內(nèi)容分析功能模塊，主要區(qū)分文本內(nèi)容和音視頻內(nèi)容兩類。針對文本內(nèi)容，可以通過針對外部網(wǎng)站的爬蟲，和內(nèi)部非結(jié)構(gòu)化統(tǒng)一管理平臺爬蟲，進行數(shù)據(jù)的統(tǒng)一爬取， 同時進行統(tǒng)一的分析。分析的結(jié)果，不但可以直接通過分析界面進行展示，更可以導出到報表系統(tǒng)中，結(jié)合數(shù)據(jù)倉庫的結(jié)構(gòu)化數(shù)據(jù)，進行統(tǒng)一的報表和業(yè)務(wù)價值挖掘。內(nèi)容分析可以從時間序列的維度進行總結(jié)，如下圖：在不同的時間段，同樣的內(nèi)容是不一樣的

59、。例如通過分析各個旅游景點照片網(wǎng)上的發(fā)帖量，旅游攻略的閱讀量等信息，通過以下的圖片，可以直觀的得到哪些月份會是游客高峰。340圖 10-25 游客高峰統(tǒng)計圖還可以根據(jù)相應(yīng)的參數(shù)，制定一些數(shù)據(jù)共識，對數(shù)據(jù)分析結(jié)果進行數(shù)學偏差的糾正。圖 10-26 數(shù)據(jù)分析結(jié)果圖對各緯度信息的趨勢進行評估： PAGE 354圖 10-27 數(shù)據(jù)趨勢圖通過自動識別的地理位置信息，進行分析。如下圖：各個城市的旅游游記的發(fā)表數(shù)量：圖 10-28 地理位置信息分析圖熱點抽取，可以根據(jù)某個景點的所有非結(jié)構(gòu)化數(shù)據(jù)，進行大數(shù)據(jù)分析，得到景點的各種環(huán)境信息。如下圖：圖 10-29 景點的各種環(huán)境信息圖通過各種大數(shù)據(jù)的集中，可以分

60、析某個景點的游客的消費喜好，例如下圖：從游客的游記和相關(guān)的內(nèi)容資料中，抽取各種金融機構(gòu)的關(guān)聯(lián)關(guān)系，可以看出，游客更喜歡國內(nèi)的阿里巴巴和京東。在景點的門票銷售，促銷方案，就可以在這些網(wǎng)站上進行推廣。圖 10-30 非結(jié)構(gòu)化數(shù)據(jù)分析結(jié)果圖數(shù)據(jù)訪問平臺 主要的組件是 HYPERLINK /hadoop/hive Hive | HYPERLINK /hadoop/tez Tez | HYPERLINK /hadoop/pig/ Pig | HYPERLINK /hadoop/storm/ Storm | HYPERLINK /hadoop/spark/ Spark | HYPERLINK /hadoo