大數(shù)據(jù)處理框架的演變和發(fā)展

大數(shù)據(jù)處理框架演變和發(fā)展2016年1月摘要大數(shù)據(jù)時(shí)代的到來(lái)，意味著數(shù)據(jù)量不斷增大、數(shù)據(jù)類型繁多，對(duì)數(shù)據(jù)的處理效率和速度的要求將不斷提高。針對(duì)不同的數(shù)據(jù)處理需求，涌現(xiàn)出了許多具有針對(duì)性的大數(shù)據(jù)處理框架。本文從該點(diǎn)入手，簡(jiǎn)述了大數(shù)據(jù)處理框架的演變，總結(jié)了三種主流的大數(shù)據(jù)處理框架及其特點(diǎn)，Hadoop、Storm和Spark，并以一個(gè)建設(shè)智慧城市的案例為例，探討大數(shù)據(jù)在其中的運(yùn)用，最后提出了大數(shù)據(jù)框架未來(lái)可能的發(fā)展方向。關(guān)鍵字：大數(shù)據(jù)框架，Hadoop，Storm，Spark、智慧城市#Client向NameNode發(fā)起讀取文件的請(qǐng)求。NameNode返回文件存儲(chǔ)的DataNode信息。Client讀取文件信息。備份數(shù)據(jù)的存放是HDFS可靠性和性能的關(guān)鍵。HDFS采用一種稱為rack-aware的策略來(lái)決定備份數(shù)據(jù)的存放。通過(guò)一個(gè)稱為RackAwareness的過(guò)程，NameNode決定每個(gè)DataNode所屬rackid。缺省情況下，一個(gè)block塊會(huì)有三個(gè)備份，一個(gè)在NameNode指定的DataNode上，一個(gè)在指定DataNode非同一rack的DataNode上，一個(gè)在指定DataNode同一rack的DataNode上。這種策略綜合考慮了同一rack失效、以及不同rack之間數(shù)據(jù)復(fù)制性能問(wèn)題。4、Storm4.1概念Storm是一個(gè)免費(fèi)開(kāi)源、分布式、高容錯(cuò)的實(shí)時(shí)計(jì)算系統(tǒng)。它是2011年9月由Twitter開(kāi)源的一個(gè)免費(fèi)的、分布式的實(shí)時(shí)計(jì)算系統(tǒng)，它使無(wú)線流數(shù)據(jù)處理變得容易，填補(bǔ)了Hadoop批處理所不能滿足的實(shí)時(shí)要求。建立storm集群可以解決包括實(shí)時(shí)分析、連續(xù)計(jì)算、在線機(jī)器學(xué)習(xí)、ETL、分布式遠(yuǎn)程過(guò)程調(diào)用等各種各樣的問(wèn)題。Storm的處理速度驚人。根據(jù)Twitter統(tǒng)計(jì)，每個(gè)節(jié)點(diǎn)每秒鐘可以處理100多萬(wàn)個(gè)元組，而且Storm可以集成各種隊(duì)列和數(shù)據(jù)庫(kù)技術(shù)，實(shí)現(xiàn)一整套完成的生態(tài)系統(tǒng)。Storm的編程模型非常簡(jiǎn)單，可以使用任何語(yǔ)言，用任意復(fù)雜的方式處理流數(shù)據(jù)，在不同階段根據(jù)需要重新劃分?jǐn)?shù)據(jù)流。4.2Storm特性Storm有如下一些特性：1）簡(jiǎn)單的編程模型類似于MapReduce的編程結(jié)構(gòu)，使用者只需要編寫Spout用于發(fā)射數(shù)據(jù)，Bolt用于處理數(shù)據(jù)，構(gòu)造Topology形成計(jì)算任務(wù)即可。2）支持各種編程語(yǔ)言可以在Storm之上使用各種編程語(yǔ)言。默認(rèn)支持Clojure、Java、Ruby和Python。要增加對(duì)其他語(yǔ)言的支持，只需實(shí)現(xiàn)一個(gè)簡(jiǎn)單的Storm通信協(xié)議即可。3）支持容錯(cuò)Storm會(huì)管理工作進(jìn)程和節(jié)點(diǎn)的故障。有節(jié)點(diǎn)故障時(shí)，可以講任務(wù)重新分配,Nimbus和Supervisor服務(wù)的故障不影響正在運(yùn)行的任務(wù)。支持水平擴(kuò)展可以自由在集群中增加supervisor節(jié)點(diǎn)，運(yùn)行新提交的任務(wù)會(huì)自動(dòng)進(jìn)行負(fù)載均衡，并且提供對(duì)已有任務(wù)進(jìn)行重新負(fù)載的接口?？煽康南⑻幚鞸torm保證每個(gè)消息至少能得到一次完整處理。任務(wù)失敗時(shí)，它會(huì)負(fù)責(zé)從消息源重試消息。高效消息處理系統(tǒng)的設(shè)計(jì)保證了消息能得到快速的處理，使用ZeroMQ作為底層消息隊(duì)列。但是Storm只提供計(jì)算，不提供存儲(chǔ)。如果需要進(jìn)行狀態(tài)數(shù)據(jù)的計(jì)算，或者任務(wù)failover后的內(nèi)存狀態(tài)恢復(fù)，需要用戶在任務(wù)中使用外部存儲(chǔ)進(jìn)行狀態(tài)存儲(chǔ)。4.3Storm應(yīng)用場(chǎng)景Storm的主要應(yīng)用場(chǎng)景有：信息流處理(Streamprocessing)Storm可用來(lái)實(shí)時(shí)處理新數(shù)據(jù)和更新數(shù)據(jù)庫(kù)，兼顧容錯(cuò)性和可擴(kuò)展性。持續(xù)計(jì)算(Continuouscomputation)Storm可進(jìn)行持續(xù)Query并把結(jié)果即時(shí)反饋給客戶端。分布式遠(yuǎn)程程序調(diào)用(DistributedRPC)Storm可用來(lái)并行處理密集查詢。Storm的拓?fù)浣Y(jié)構(gòu)是一個(gè)等待調(diào)用信息的分布函數(shù),當(dāng)它收到一條調(diào)用信息后，會(huì)對(duì)查詢進(jìn)行計(jì)算，并返回查詢結(jié)果。例如DistributedRPC可以做并行搜索或者處理大集合的數(shù)據(jù)。根據(jù)Storm官網(wǎng)的介紹(/nathanmarz/storm/wiki/Powered-By)，有部分公司已經(jīng)使用，主要用于實(shí)時(shí)日志統(tǒng)計(jì)，廣告點(diǎn)擊計(jì)算及精準(zhǔn)投放，反作弊等領(lǐng)域。4.4Storm處理平臺(tái)研究4.4.1Storm的整體架構(gòu)與Hadoop主從架構(gòu)一樣，Storm也采用Master/Slave體系結(jié)構(gòu)，分布式計(jì)算由Nimbus和Supervisor兩類服務(wù)進(jìn)程實(shí)現(xiàn)。Nimbus進(jìn)程運(yùn)行在集群的主節(jié)點(diǎn)上，負(fù)責(zé)任務(wù)分配、代碼分發(fā)、集群監(jiān)控等工作。Supervisor是運(yùn)行在集群的從節(jié)點(diǎn)，用于監(jiān)聽(tīng)工作,開(kāi)始并終止工作進(jìn)程。Storm集群的架構(gòu)如下圖4.1所示，圖4.1Storm集群架構(gòu)圖如上圖所示，連接Nimbus和Supervisor的是Zookeeper集群。其中Nimbus和Supervisor都是快速失敗，無(wú)狀態(tài)的，所以某一個(gè)節(jié)點(diǎn)當(dāng)?shù)袅⒓粗貑⒉粫?huì)影響系統(tǒng)的運(yùn)行，主節(jié)點(diǎn)和工作節(jié)點(diǎn)之間的協(xié)調(diào)市通過(guò)Zookeeper完成的。Zookeeper是一種開(kāi)源、高效的分布式應(yīng)用協(xié)調(diào)服務(wù)。一個(gè)Zookeeper集群（簡(jiǎn)稱ZK集群）通常由多個(gè)Zookeeper節(jié)點(diǎn)組成。ZK集群有一個(gè)leader節(jié)點(diǎn)，其他的都是follow節(jié)點(diǎn)。Leader節(jié)點(diǎn)負(fù)責(zé)寫服務(wù)和數(shù)據(jù)同步，follow節(jié)點(diǎn)負(fù)責(zé)讀服務(wù)。ZK集群支持高可用。一般ZK集群中只要有超過(guò)半數(shù)的節(jié)點(diǎn)存活，ZK集群就仍然高可用。ZK集群負(fù)責(zé)Nimbus與Supervisor節(jié)點(diǎn)之間的通信。監(jiān)控各個(gè)節(jié)點(diǎn)之間的狀態(tài)。提交的任務(wù)首先交到Nimbus上執(zhí)行，接著ZK集群將任務(wù)分發(fā)給Supervisor節(jié)點(diǎn)執(zhí)行。但是，整個(gè)storm集群只有一個(gè)Nimbus節(jié)點(diǎn)。當(dāng)Nimbus節(jié)點(diǎn)出現(xiàn)故障，任務(wù)不會(huì)停止執(zhí)行，任務(wù)管理會(huì)出現(xiàn)問(wèn)題。此時(shí)，只要重新恢復(fù)Nimbus服務(wù)即可。4.4.2Storm保證消息被處理Storm與S4的最大區(qū)別是Storm保證每一條消息得到完全處理。Storm中由spout發(fā)出的每條消息到消息處理完成會(huì)形成一個(gè)tuple樹(shù)，storm通過(guò)追蹤由每個(gè)spout所產(chǎn)生的tuple樹(shù)來(lái)跟蹤tuple是否完全處理完成。但如果為每個(gè)spout發(fā)送的消息都構(gòu)建一棵樹(shù)的話，內(nèi)存很快就會(huì)耗盡。Storm的策略非常巧妙，對(duì)于任意的一棵樹(shù)，只需要20字節(jié)的固定內(nèi)存就可以跟蹤。算法的主要思想是將創(chuàng)建的所有tuple-id以及ackdetuple-id一起異或。系統(tǒng)在生成一個(gè)新的tuple的時(shí)候會(huì)通知自己的tuple-id，在處理完成一個(gè)tuple后也會(huì)通知storm自己的tuple-id，這樣storm就可以知道每一個(gè)tuple是否處理完成，在最后一個(gè)tuple處理完成之后通知spout，整個(gè)tuple樹(shù)處理完成。消息的ID是隨機(jī)的一個(gè)64bit值，理論上可能存在相同的值，但實(shí)際的概率很小,幾乎可以忽略，所以ack-val在樹(shù)處理完之前被置為0的概率很小。acker任務(wù)保存了spout組件的tuple-id到一對(duì)值得映射。第一個(gè)是spout發(fā)出的tuple的id，用于一個(gè)tuple被完全處理時(shí)，acker向spout發(fā)送消息。第二個(gè)是ack-val，它是數(shù)中所有創(chuàng)建的tuple-id與ack的tuple-id異或的結(jié)果，表示了整棵樹(shù)的狀態(tài)，當(dāng)ack-val值為0，表明這棵樹(shù)被完全處理了。4.4.3Storm的處理模型Topology用于封裝一個(gè)實(shí)時(shí)計(jì)算應(yīng)用程序的邏輯,類似于Hadoop的MapReduceJob,由Spout，Bolt組件和Streams組成。每個(gè)Spout，Bolt在集群中都是多線程運(yùn)行，消息傳遞根據(jù)StreamGrouping完成。圖2是storm的Topology示意圖。圖4.2StormTopology示意圖由上圖可知，Storm架構(gòu)中使用Spout/Bolt編程模型來(lái)對(duì)消息進(jìn)行流式處理。消息流是Storm中對(duì)數(shù)據(jù)的基本抽象，一個(gè)消息流是對(duì)一條輸入數(shù)據(jù)的封裝，源源不斷輸入的消息流以分布式的方式被處理。Spout組件是消息生產(chǎn)者，是Storm架構(gòu)中的數(shù)據(jù)輸入源頭，它可以從多種異構(gòu)數(shù)據(jù)源讀取數(shù)據(jù)，并發(fā)射消息流oBolt組件負(fù)責(zé)接收Spout組件發(fā)射的信息流，并完成具體的處理邏輯。在復(fù)雜的業(yè)務(wù)邏輯中可以串聯(lián)多個(gè)Bolt組件，在每個(gè)Bolt組件中編寫各自不同的功能，從而實(shí)現(xiàn)整體的處理邏輯。4.5Storm的現(xiàn)狀與未來(lái)目前，Storm被廣泛應(yīng)用于實(shí)時(shí)分析，在線機(jī)器學(xué)習(xí)，持續(xù)計(jì)算、分布式遠(yuǎn)程調(diào)用領(lǐng)域。例如一淘使用是十分分析系統(tǒng)pora，實(shí)時(shí)分析用戶的屬性，反饋給搜索引擎。攜程利用HTML5提供的performance標(biāo)準(zhǔn)獲得可用的指標(biāo)，并記錄日志。Storm集群實(shí)時(shí)分析日志和入庫(kù)。使用DRPC聚合成報(bào)表，通過(guò)歷史數(shù)據(jù)對(duì)比等判斷規(guī)則，出發(fā)預(yù)警事件。在流式處理領(lǐng)域里，Storm的直接對(duì)手是S4。不過(guò)，對(duì)比S4冷淡的社區(qū)、半成品的代碼，在實(shí)際商用方面Storm具有比較大的優(yōu)勢(shì)。如果把范圍擴(kuò)大到實(shí)時(shí)處理，Storm就有更多對(duì)比的處理方案。Facebook使用puma和Hbase相結(jié)合來(lái)處理實(shí)時(shí)數(shù)據(jù)，使批處理計(jì)算平臺(tái)具備一定實(shí)時(shí)能力。HStreaming嘗試為Hadoop環(huán)境添加一個(gè)實(shí)時(shí)的組件HStreaming能讓一個(gè)Hadoop平臺(tái)在幾天內(nèi)轉(zhuǎn)為一個(gè)實(shí)時(shí)系統(tǒng)。Storm有Yarn-Storm項(xiàng)目，能讓Storm運(yùn)行在Hadoop2.0的Yarn框架上，可以讓Hadoop的MapReduce和Storm共享資源。5、Spark5.1概念Spark是UCBerkeleyAMPlab所開(kāi)源的類HadoopMapReduce的通用并行框架，Spark，擁有HadoopMapReduce所具有的優(yōu)點(diǎn)；但不同于MapReduce的是Job中間輸出結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫HDFS，因此Spark能更好地適用于數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)等需要迭代的MapReduce的算法。Spark是一種與Hadoop相似的開(kāi)源集群計(jì)算環(huán)境，但是兩者之間還存在一些不同之處，這些有用的不同之處使Spark在某些工作負(fù)載方面表現(xiàn)得更加優(yōu)越，換句話說(shuō),Spark啟用了內(nèi)存分布數(shù)據(jù)集，除了能夠提供交互式查詢外，它還可以優(yōu)化迭代工作負(fù)載。Spark是在Scala語(yǔ)言中實(shí)現(xiàn)的，它將Scala用作其應(yīng)用程序框架。與Hadoop不同，Spark和Scala能夠緊密集成，其中的Scala可以像操作本地集合對(duì)象一樣輕松地操作分布式數(shù)據(jù)集。盡管創(chuàng)建Spark是為了支持分布式數(shù)據(jù)集上的迭代作業(yè)，但是實(shí)際上它是對(duì)Hadoop的補(bǔ)充，可以在Hadoop文件系統(tǒng)中并行運(yùn)行。通過(guò)名為Mesos的第三方集群框架可以支持此行為。Spark由加州大學(xué)伯克利分校AMP實(shí)驗(yàn)室(Algorithms，Machines，ndPeopleLab)開(kāi)發(fā)，可用來(lái)構(gòu)建大型的、低延遲的數(shù)據(jù)分析應(yīng)用程序。5.2Spark解決的問(wèn)題在這里不得不提大數(shù)據(jù)，大數(shù)據(jù)有兩個(gè)根本性的問(wèn)題，一個(gè)是數(shù)據(jù)很大，如何存儲(chǔ)？另外一個(gè)是數(shù)據(jù)很大，如何分析？畢竟分析大數(shù)據(jù)是為了改善產(chǎn)品的用戶體驗(yàn)，從而獲取更多的價(jià)值。對(duì)于第一個(gè)問(wèn)題，開(kāi)源社區(qū)給出的方案就是HDFS，一個(gè)非常優(yōu)秀的分布式存儲(chǔ)系統(tǒng)。對(duì)于第二個(gè)問(wèn)題，在Hadoop之后，開(kāi)源社區(qū)推出了許多值得關(guān)注的大數(shù)據(jù)分析平臺(tái)。這些平臺(tái)范圍廣闊，從簡(jiǎn)單的基于腳本的產(chǎn)品到與Hadoop類似的生產(chǎn)環(huán)境。Bashreduce在Bash環(huán)境中的多個(gè)機(jī)器上執(zhí)行MapReduce類型的操作，可以直接引用強(qiáng)大的Linux命令。GraphLab也是一種MapReduce抽象實(shí)現(xiàn)，側(cè)重于機(jī)器學(xué)習(xí)算法的并行實(shí)現(xiàn)。還有Twitter的Storm（通過(guò)收購(gòu)BackType獲得）。Storm被定義為實(shí)時(shí)處理的Hadoop，它主要側(cè)重于流處理和持續(xù)計(jì)算。Spark就是解決第二個(gè)問(wèn)題的佼佼者。5.3WhySpark在2014上半年，Spark開(kāi)源生態(tài)系統(tǒng)得到了大幅增長(zhǎng)，已成為大數(shù)據(jù)領(lǐng)域最活躍的開(kāi)源項(xiàng)目之一，當(dāng)下已活躍在Hortonworks、IBM、Cloudera、MapR和Pivotal等眾多知名大數(shù)據(jù)公司。那么Spark究竟以什么吸引了如此多的關(guān)注，這里我們參考Dzone上的6個(gè)總結(jié)。1）輕量級(jí)快速處理提到大數(shù)據(jù)處理，速度往往是最優(yōu)先被考慮的因素。與Hadoop的MapReduce相比,Spark基于內(nèi)存的運(yùn)算比MR要快100倍；而基于硬盤的運(yùn)算也要快10倍。Spark通過(guò)減少磁盤IO來(lái)達(dá)到性能提升，它們將中間處理數(shù)據(jù)全部放到了內(nèi)存中。NumberofIterations圖5.1Hadoop和Spark的迭代處理時(shí)間對(duì)比Spark使用了RDD（ResilientDistributedDataset）的理念，這允許它可以透明的內(nèi)存中存儲(chǔ)數(shù)據(jù)，只在需要時(shí)才持久化到磁盤。這種做法大大的減少了數(shù)據(jù)處理過(guò)程中磁盤的讀寫，大幅度的降低了所需時(shí)間。2）易于使用，Spark支持多語(yǔ)言Spark支持Java，Python和Scala。而且支持交互式的Python和Scala的shell，它自帶了80多個(gè)高等級(jí)操作符，允許在shell中進(jìn)行交互式查詢。這意味Spark使用者可以非常方便地在這些shell中使用Spark集群來(lái)驗(yàn)證解決問(wèn)題的方法，而不是像以前一樣，這對(duì)于原型開(kāi)發(fā)非常重要。Hadoop的WorldCount的Mapper和Reducer加起來(lái)大概需要20多行，而Spark僅需要：valfile=spark.textFile("hdfs://...")valcounts=file.flatMap(line=>line.split(”")).map(word=>(word,1)).reduceByKey(—+_)counts.saveAsTextFile("hdfs://...")支持復(fù)雜查詢除了簡(jiǎn)單的“map”及“reduce”操作之外，Spark還支持SQL查詢、流式查詢及復(fù)雜查詢，比如開(kāi)箱即用的機(jī)器學(xué)習(xí)機(jī)圖算法。同時(shí)，用戶可以在同一個(gè)工作流中無(wú)縫的搭配這些能力。實(shí)時(shí)的流處理對(duì)比MapReduce只能處理離線數(shù)據(jù)，Spark支持實(shí)時(shí)的流計(jì)算。Spark依賴SparkStreaming對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)的處理，當(dāng)然在YARN之后Hadoop也可以借助其他的工具進(jìn)行流式計(jì)算。對(duì)于SparkStreaming，Cloudera的評(píng)價(jià)是：圖5.2Storm和Spark吞吐量對(duì)比簡(jiǎn)單：輕量級(jí)且具備功能強(qiáng)大的API，SparksStreaming允許你快速開(kāi)發(fā)流應(yīng)用程序。容錯(cuò):不像其他的流解決方案，比如Storm，無(wú)需額外的代碼和配置,SparkStreaming就可以做大量的恢復(fù)和交付工作。集成：為流處理和批處理重用了同樣的代碼，甚至可以將流數(shù)據(jù)保存到歷史數(shù)據(jù)中。4)可以與Hadoop和已存Hadoop數(shù)據(jù)整合Spark可以獨(dú)立的運(yùn)行，除了可以運(yùn)行在當(dāng)下的YARN集群管理之外，它還可以讀取已有的任何Hadoop數(shù)據(jù)。這對(duì)于已經(jīng)部署Hadoop集群的用戶特別重要，畢竟不需要做任何的數(shù)據(jù)遷移就可以使用Spark的強(qiáng)大處理能力，這個(gè)特性讓用戶可以輕易遷移已有Hadoop應(yīng)用。同時(shí)，Spark可以讀HDFS,HBase,Cassandra等一切Hadoop的數(shù)據(jù)。當(dāng)然了對(duì)于沒(méi)有部署并且沒(méi)有計(jì)劃部署Hadoop集群的用戶來(lái)說(shuō)，Spark仍然是一個(gè)非常好的解決方法，它還支持standalone，EC2和Mesos。只要保證集群的節(jié)點(diǎn)可以訪問(wèn)共享的內(nèi)容，比如通過(guò)NFS就可以非常容易的使用Spark。5）活躍和無(wú)限壯大的社區(qū)Spark起源于2009年，當(dāng)下已有超過(guò)50個(gè)機(jī)構(gòu)250個(gè)工程師貢獻(xiàn)過(guò)代碼，和去年六月相比，代碼行數(shù)幾乎擴(kuò)大三倍，這是個(gè)令人艷羨的增長(zhǎng)。5?4Spark特點(diǎn)5.4.1優(yōu)點(diǎn)（1）Spark是基于內(nèi)存的迭代計(jì)算框架，適用于需要多次操作特定數(shù)據(jù)集的應(yīng)用場(chǎng)合。（2）Spark不適用那種異步細(xì)粒度更新?tīng)顟B(tài)的應(yīng)用，例如web服務(wù)的存儲(chǔ)或者是增量的web爬蟲(chóng)和索引。（3）Spark的適用面比較廣泛且比較通用。（4）輕：Sparkl.0核心代碼3萬(wàn)行，Hadoopl.09萬(wàn)行，2.022萬(wàn)行。（5）快：Spark對(duì)小數(shù)據(jù)集能達(dá)到亞秒級(jí)的延遲這對(duì)于HadoopMapReduce是無(wú)法想象的（由于沁跳”間隔機(jī)制，僅任務(wù)啟動(dòng)就有數(shù)秒的延遲）。就大數(shù)據(jù)集而言，對(duì)典型的迭代機(jī)器學(xué)習(xí)、圖計(jì)算等應(yīng)用，Spark版本比基于MapReduce、Hive和Pregel的實(shí)現(xiàn)快上十倍到百倍。其中內(nèi)存計(jì)算、數(shù)據(jù)本地性（locality）和傳輸優(yōu)化、調(diào)度優(yōu)化等該居首功。（6）靈：Spark提供了不同層面的靈活性。在實(shí)現(xiàn)層，可更換的集群調(diào)度器、序列化庫(kù)；在原語(yǔ)（Primitive）層，它允許擴(kuò)展新的數(shù)據(jù)算子、新的數(shù)據(jù)源、新的language（Java和Python）；在范式（Paradigm）層，Spark支持內(nèi)存計(jì)算、多迭代批量處理、即時(shí)查詢、流處理和圖計(jì)算等多種范式。（7）巧：巧在借勢(shì)和借力。Spark借Hadoop之勢(shì)，與Hadoop無(wú)縫結(jié)合；接著SparkSQL借了Hive的勢(shì)；5.4.2缺點(diǎn)（1）JVM的內(nèi)存overhead太大，1G的數(shù)據(jù)通常需要消耗5G的內(nèi)存；（2）不同的sparkapp之間缺乏有效的共享內(nèi)存機(jī)制；（3）不穩(wěn)定，集群偶爾會(huì)掛掉。只適合做計(jì)算，不適合直接提供服務(wù)；（4）數(shù)據(jù)的partition不夠好，會(huì)導(dǎo)致集群中的各臺(tái)機(jī)器上計(jì)算任務(wù)分配不平均;（5）任務(wù)調(diào)度不夠好。5.5系統(tǒng)框架5.5.1技術(shù)生態(tài)SparkSQLSparkStreamingMLlib(machinelearning)GraphX(graph)ApacheSpark圖5.3Spark生態(tài)圈（1）SparkSQL:應(yīng)用于即席查詢（Ad-hocquery）SparkSQL解決了這兩個(gè)問(wèn)題。第一，SparkSQL在Hive兼容層面僅依賴HQLparser、HiveMetastore和HiveSerDe。也就是說(shuō)，從HQL被解析成抽象語(yǔ)法樹(shù)（AST）起，就全部由SparkSQL接管了。執(zhí)行計(jì)劃生成和優(yōu)化都由Catalyst負(fù)責(zé)。借助Scala的模式匹配等函數(shù)式語(yǔ)言特性，利用Catalyst開(kāi)發(fā)執(zhí)行計(jì)劃優(yōu)化策略比Hive要簡(jiǎn)潔得多。去年Sparksummit上Catalyst的作者M(jìn)ichaelArmbrust對(duì)Catalyst做了一個(gè)簡(jiǎn)要介紹。第二，相對(duì)于Shark，由于進(jìn)一步削減了對(duì)Hive的依賴，SparkSQL不再需要自行維護(hù)打了patch的Hive分支。Shark后續(xù)將全面采用SparkSQL作為引擎，不僅僅是查詢優(yōu)化方面。（2）SparkStreaming:應(yīng)用于流式計(jì)算SparkStreaming是一種構(gòu)建在Spark上的實(shí)時(shí)計(jì)算框架，它擴(kuò)展了Spark處理大規(guī)模流式數(shù)據(jù)的能力。它將流式計(jì)算分解成一系列短小的批處理計(jì)算，并且提供高可靠和吞吐量服務(wù)。SparkStreaming的優(yōu)勢(shì)在于：1）能運(yùn)行在100+的結(jié)點(diǎn)上，并達(dá)到秒級(jí)延遲。2）使用基于內(nèi)存的Spark作為執(zhí)行引擎，具有高效和容錯(cuò)的特性。3）能集成Spark的批處理和交互查詢。4）為實(shí)現(xiàn)復(fù)雜的算法提供和批處理類似的簡(jiǎn)單接口。（3）MLlib:應(yīng)用于機(jī)器學(xué)習(xí)MLlib是Spark對(duì)常用的機(jī)器學(xué)習(xí)算法的實(shí)現(xiàn)庫(kù)，同時(shí)包括相關(guān)的測(cè)試和數(shù)據(jù)生成

器。MLlib目前支持四種常見(jiàn)的機(jī)器學(xué)習(xí)問(wèn)題：二元分類，回歸，聚類以及協(xié)同過(guò)濾,

同時(shí)也包括一個(gè)底層的梯度下降優(yōu)化基礎(chǔ)算法。(4)GraphX:應(yīng)用于圖處理SparkGraphX是一個(gè)分布式圖處理框架，SparkGraphX基于Spark平臺(tái)提供對(duì)圖計(jì)算和圖挖掘簡(jiǎn)潔易用的而豐富多彩的接口，極大的方便了大家對(duì)分布式圖處理的需求。SparkGraphX的優(yōu)勢(shì)在于能夠把表格和圖進(jìn)行互相轉(zhuǎn)換，這一點(diǎn)可以帶來(lái)非常多的優(yōu)勢(shì)，現(xiàn)在很多框架也在漸漸的往這方面發(fā)展，例如GraphLib已經(jīng)實(shí)現(xiàn)了可以讀取Graph中的Data，也可以讀取Table中的Data，也可以讀取Text總的data即文本中的內(nèi)容等，與此同時(shí)SparkGraphX基于Spark也為GraphX增添了額外的很多優(yōu)勢(shì)，例如和mllib、SparkSQL協(xié)作等。5.5.2運(yùn)行架構(gòu)運(yùn)行框架如下圖所示，首先有集群資源管理服務(wù)(ClusterManager)和運(yùn)行作業(yè)任務(wù)的結(jié)點(diǎn)(WorkerNode)，然后就是每個(gè)應(yīng)用的任務(wù)控制結(jié)點(diǎn)Driver和每個(gè)機(jī)器節(jié)點(diǎn)上有具體任務(wù)的執(zhí)行進(jìn)程(Executor)。DriverProgramSparkContext*ClusterMaragerClusterMaragerDriverProgramSparkContext*ClusterMaragerClusterMarager圖5.4Spark運(yùn)行框架DriverProgram:運(yùn)行main函數(shù)并且新建SparkContext的程序。SparkContext：Spark程序的入口，負(fù)責(zé)調(diào)度各個(gè)運(yùn)算資源，協(xié)調(diào)各個(gè)WorkerNode上的ExecutoroClusterManager：集群的資源管理器(例如：Standalone,Mesos,Yarn)WorkerNode：集群中任何可以運(yùn)行應(yīng)用代碼的節(jié)點(diǎn)Executor:是在一個(gè)workernode上為某應(yīng)用啟動(dòng)的一個(gè)進(jìn)程，該進(jìn)程負(fù)責(zé)運(yùn)行任務(wù),并且負(fù)責(zé)將數(shù)據(jù)存在內(nèi)存或者磁盤上。每個(gè)應(yīng)用都有各自獨(dú)立的executorsTask:被送到某個(gè)executor上的工作單元了解了各個(gè)術(shù)語(yǔ)的含義后，我們看一下一個(gè)用戶程序是如何從提交到最終到集群上執(zhí)行的：SparkContext連接至UClusterManager，并且向ClusterManager申請(qǐng)executors。SparkContext向executors發(fā)送applicationcode。SparkContext向executors發(fā)送tasks,executor會(huì)執(zhí)行被分配的tasks。5.6關(guān)鍵技術(shù)5.6.1彈性分布式數(shù)據(jù)集RDD是Spark計(jì)算框架的核心技術(shù)。在Spark中，所有的數(shù)據(jù)都抽象成RDD。用戶可將中間結(jié)果緩存在內(nèi)存中，便于有效地被重用和進(jìn)行并發(fā)操作，免去不必要的I/O開(kāi)銷。RDD只能通過(guò)兩種方式創(chuàng)建，一是讀取本地或Hadoop分布式文件系統(tǒng)（HDFS）上的文件，二是由其他RDD轉(zhuǎn)換而來(lái)，具有只讀（一組RDD可以通過(guò)數(shù)據(jù)集操作生成另外一組RDD，但是不能直接被改寫）、彈性擴(kuò)展和容錯(cuò)等特性。RDD支持兩種操作：轉(zhuǎn)換（transformation）從現(xiàn)有的數(shù)據(jù)集創(chuàng)建一個(gè)新的數(shù)據(jù)集;而動(dòng)作（actions）在數(shù)據(jù)集上運(yùn)行計(jì)算后，返回一個(gè)值給驅(qū)動(dòng)程序。例如，map就是一種轉(zhuǎn)換，它將數(shù)據(jù)集每一個(gè)元素都傳遞給函數(shù)，并返回一個(gè)新的分布數(shù)據(jù)集表示結(jié)果。另一方面‘reduce是一種動(dòng)作，通過(guò)一些函數(shù)將所有的元素疊加起來(lái)，并將最終結(jié)果返回給Driver程序。（不過(guò)還有一個(gè)并行的reduceByKey,能返回一個(gè)分布式數(shù)據(jù)集）（1）為什么會(huì)產(chǎn)生RDD?傳統(tǒng)的MapReduce雖然具有自動(dòng)容錯(cuò)、平衡負(fù)載和可拓展性的優(yōu)點(diǎn)，但是其最大缺點(diǎn)是采用非循環(huán)式的數(shù)據(jù)流模型，使得在迭代計(jì)算式要進(jìn)行大量的磁盤10操作。RDD正是解決這一缺點(diǎn)的抽象方法?RDD的具體描述RDD（彈性數(shù)據(jù)集）是Spark提供的最重要的抽象的概念，它是一種有容錯(cuò)機(jī)制的特殊集合，可以分布在集群的節(jié)點(diǎn)上，以函數(shù)式編操作集合的方式，進(jìn)行各種并行操作?？梢詫DD理解為一個(gè)具有容錯(cuò)機(jī)制的特殊集合，它提供了一種只讀、只能有已存在的RDD變換而來(lái)的共享內(nèi)存，然后將所有數(shù)據(jù)都加載到內(nèi)存中，方便進(jìn)行多次重用°A.它是分布式的，可以分布在多臺(tái)機(jī)器上，進(jìn)行計(jì)算；B.它是彈性的，計(jì)算過(guò)程中內(nèi)存不夠時(shí)它會(huì)和磁盤進(jìn)行數(shù)據(jù)交換；C.這些限制可以極大的降低自動(dòng)容錯(cuò)開(kāi)銷；D.實(shí)質(zhì)是一種更為通用的迭代并行計(jì)算框架，用戶可以顯示的控制計(jì)算的中間結(jié)果，然后將其自由運(yùn)用于之后的計(jì)算。?RDD的容錯(cuò)機(jī)制實(shí)現(xiàn)分布式數(shù)據(jù)集容錯(cuò)方法有兩種:數(shù)據(jù)檢查點(diǎn)和記錄更新RDD采用記錄更新的方式：記錄所有更新點(diǎn)的成本很高。所以，RDD只支持粗顆粒變換，即只記錄單個(gè)塊上執(zhí)行的單個(gè)操作，然后創(chuàng)建某個(gè)RDD的變換序列（血統(tǒng)）存儲(chǔ)下來(lái)；變換序列指，每個(gè)RDD都包含了他是如何由其他RDD變換過(guò)來(lái)的以及如何重建某一塊數(shù)據(jù)的信息。因此RDD的容錯(cuò)機(jī)制又稱“血統(tǒng)”容錯(cuò)。要實(shí)現(xiàn)這種“血統(tǒng)”容錯(cuò)機(jī)制，最大的難題就是如何表達(dá)父RDD和子RDD之間的依賴關(guān)系。實(shí)際上依賴關(guān)系可以分兩種，窄依賴和寬依賴：窄依賴：子RDD中的每個(gè)數(shù)據(jù)塊只依賴于父RDD中對(duì)應(yīng)的有限個(gè)固定的數(shù)據(jù)塊；寬依賴：子RDD中的一個(gè)數(shù)據(jù)塊可以依賴于父RDD中的所有數(shù)據(jù)塊。?RDD內(nèi)部的設(shè)計(jì)每個(gè)RDD都需要包含以下四個(gè)部分:a.源數(shù)據(jù)分割后的數(shù)據(jù)塊,源代碼中的splits變量b.關(guān)于“血統(tǒng)”的信息，源碼中的dependencies變量c.一個(gè)計(jì)算函數(shù)(該RDD如何通過(guò)父RDD計(jì)算得到)，源碼中的iterator(split)和compute函數(shù)d.一些關(guān)于如何分塊和數(shù)據(jù)存放位置的元信息，如源碼中的partitioner和preferredLocations例如：A.—個(gè)從分布式文件系統(tǒng)中的文件得到的RDD具有的數(shù)據(jù)塊通過(guò)切分各個(gè)文件得到的，它是沒(méi)有父RDD的，它的計(jì)算函數(shù)知識(shí)讀取文件的每一行并作為一個(gè)元素返回給RDD；B.對(duì)與一個(gè)通過(guò)map函數(shù)得到的RDD，它會(huì)具有和父RDD相同的數(shù)據(jù)塊，它的計(jì)算函數(shù)式對(duì)每個(gè)父RDD中的元素所執(zhí)行的一個(gè)函數(shù)。(2)RDD在Spark中的地位及作用因?yàn)閭鹘y(tǒng)的并行計(jì)算模型無(wú)法有效的解決迭代計(jì)算(iterative)和交互式計(jì)算(interactive)；而Spark的使命便是解決這兩個(gè)問(wèn)題，這也是他存在的價(jià)值和理由。其主要實(shí)現(xiàn)思想就是RDD,把所有計(jì)算的數(shù)據(jù)保存在分布式的內(nèi)存中。迭代計(jì)算通常情況下都是對(duì)同一個(gè)數(shù)據(jù)集做反復(fù)的迭代計(jì)算，數(shù)據(jù)在內(nèi)存中將大大提升10操作。這也是Spark涉及的核心：內(nèi)存計(jì)算。因?yàn)镾park是用scala語(yǔ)言實(shí)現(xiàn)的，Spark和scala能夠緊密的集成，所以Spark可以完美的運(yùn)用scala的解釋器，使得其中的scala可以向操作本地集合對(duì)象一樣輕松操作分布式數(shù)據(jù)集。RDD是一種具有容錯(cuò)性基于內(nèi)存的集群計(jì)算抽象方法，Spark則是這個(gè)抽象方法的實(shí)現(xiàn)。5.6.2共享變量與MapReduce不同的是，Spark提供廣播(Broadcast)和累加器(Accumulators)兩種受限的共享變量，可以像分布式內(nèi)存系統(tǒng)一樣提供全局地址空間接口，提高了數(shù)據(jù)的共享性。5.6.3容錯(cuò)機(jī)制分布式共享內(nèi)存系統(tǒng)一般通過(guò)檢查點(diǎn)(checkpoint)和回滾(rollback)方式容錯(cuò)，而RDD通過(guò)稱為“世系關(guān)系”(Lineage)的機(jī)制提供高效的容錯(cuò)，該機(jī)制使RDD包含其演化過(guò)程中一系列的依賴關(guān)系，能夠自動(dòng)從節(jié)點(diǎn)失敗中重構(gòu)丟失的RDD。5.6.4支持有向無(wú)環(huán)圖編程框架由于MapReduce設(shè)計(jì)上的約束，Hadoop缺少對(duì)迭代計(jì)算和DAG運(yùn)算的支持。Spark具有豐富全面的數(shù)據(jù)集運(yùn)算操作，除了Map和Reduce操作，還增加了過(guò)濾、抽樣、分組、排序、并集、連接、分割、計(jì)數(shù)、收集、查找等80多種算子，并合理地劃分為Transformation（變換）和Action（動(dòng)作）兩大類。利用這些算子，能夠方便地建立起RDD的DAG計(jì)算模型，將所有操作優(yōu)化成DAG圖，提高計(jì)算效率和編程靈活性。5.7Spark的現(xiàn)狀與未來(lái)（1）2009：Spark誕生于AMPLab（2）2010：開(kāi)源（3）2013年6月：Apache孵化器項(xiàng)目（4）2014年2月：Apache頂級(jí)項(xiàng)目Hadoop最大的廠商Cloudera宣稱加大Spark框架的投入來(lái)取代Mapreduce；Hadoop廠商MapR投入Spark陣營(yíng)；Apachemahout放棄MapReduce，將使用Spark作為后續(xù)算子的計(jì)算平臺(tái)（5）2014年5月：Spark1.0.0發(fā)布（6）2014年12月：Spark1.2發(fā)布引入MLpipeline作為機(jī)器學(xué)習(xí)的接口。（7）2015年3月：Spark1.3發(fā)布引入了DataFrame作為Spark的一個(gè)核心組件。（8）2015年6月：Spark1.4發(fā)布引入R語(yǔ)言作為Spark的接口。R語(yǔ)言接口在問(wèn)世一個(gè)多月之后的調(diào)查中就有18%的用戶使用。（9）2015年9月：Spark1.5發(fā)布。Tungsten項(xiàng)目第一階段的產(chǎn)出合并入DataFrame的執(zhí)行后端，DataFrame的執(zhí)行效率得到大幅提升。（10）2016年1月：Spark1.6發(fā)布引入Dataset接口。Spark的發(fā)展會(huì)結(jié)合硬件的發(fā)展趨勢(shì)。首先，內(nèi)存會(huì)變得越來(lái)越便宜，256GB內(nèi)存以上的機(jī)器會(huì)變得越來(lái)越常見(jiàn)，而對(duì)于硬盤，則SSD硬盤也將慢慢成為服務(wù)器的標(biāo)配。由于Spark是基于內(nèi)存的大數(shù)據(jù)處理平臺(tái)，因而在處理過(guò)程中，會(huì)因?yàn)閿?shù)據(jù)存儲(chǔ)在硬盤中，而導(dǎo)致性能瓶頸。隨著機(jī)器內(nèi)存容量的逐步增加，類似HDFS這種存儲(chǔ)在磁盤中的分布式文件系統(tǒng)將慢慢被共享內(nèi)存的分布式存儲(chǔ)系統(tǒng)所替代，諸如同樣來(lái)自伯克利大學(xué)的AMPLab實(shí)驗(yàn)室的Tachyon就提供了遠(yuǎn)超HDFS的性能表現(xiàn)。因此，未來(lái)的Spark會(huì)在內(nèi)部的存儲(chǔ)接口上發(fā)生較大的變化，能夠更好地支持SSD、以及諸如Tachyon之類的共享內(nèi)存系統(tǒng)。隨著Spark的逐漸成熟，并在活躍社區(qū)的推動(dòng)下，它所提供的強(qiáng)大功能一定能得到更多技術(shù)團(tuán)隊(duì)和企業(yè)的青睞。相信在不遠(yuǎn)的將來(lái)會(huì)有更多傳統(tǒng)企業(yè)開(kāi)始嘗試使用Spark。6、案例分析6.1背景智慧城市是運(yùn)用信息和通信技術(shù)手段感測(cè)、分析、整合城市運(yùn)行核心系統(tǒng)的各項(xiàng)關(guān)鍵信息，對(duì)包括民生、環(huán)保、公共安全、城市服務(wù)、工商業(yè)活動(dòng)在內(nèi)的各種需求做出智能響應(yīng)。其實(shí)質(zhì)是利用先進(jìn)的信息技術(shù)，實(shí)現(xiàn)城市智慧式管理和運(yùn)行。智慧城市的熱潮和探索，引發(fā)了社會(huì)經(jīng)濟(jì)，生活，商業(yè)模式的迅速變革。智慧城市建設(shè)引領(lǐng)產(chǎn)業(yè)升級(jí)、社會(huì)轉(zhuǎn)型、惠及民生、生態(tài)文明的演進(jìn)。6.2大數(shù)據(jù)助力智慧城市建設(shè)6.2.1大數(shù)據(jù)與智慧城市智慧城市領(lǐng)域，數(shù)據(jù)具有非常重要的地位，包括地理空間數(shù)據(jù)、行業(yè)數(shù)據(jù)、普查數(shù)據(jù)、傳感器檢測(cè)數(shù)據(jù)等，這些是智慧城市建設(shè)的基礎(chǔ)。如何對(duì)海量多源的異構(gòu)數(shù)據(jù)進(jìn)行有效地存儲(chǔ)和管理是智慧城市建設(shè)中面臨的重要問(wèn)題。在此基礎(chǔ)上，利用計(jì)算機(jī)技術(shù)、信息技術(shù)、機(jī)器學(xué)習(xí)技術(shù)使得計(jì)算機(jī)系統(tǒng)能夠基于海量數(shù)據(jù)進(jìn)行自主學(xué)習(xí)和分析，為城市管理者提供決策支持也是智慧城市區(qū)別于數(shù)字城市的一個(gè)重要特征。6.2.2技術(shù)體系框架本案例參考北京大學(xué)數(shù)字地球工作室在數(shù)字城市云計(jì)算框架和關(guān)鍵技術(shù)研究成果，結(jié)合目前大數(shù)據(jù)技術(shù)領(lǐng)域的相關(guān)進(jìn)展，提出了如下圖所示的體系框架圖。

圖6.1智慧城市技術(shù)體系框架圖6.3關(guān)鍵技術(shù)6?3?1網(wǎng)絡(luò)數(shù)據(jù)的獲取隨著互聯(lián)網(wǎng)的不斷發(fā)展，網(wǎng)絡(luò)數(shù)據(jù)逐漸成為重要的信息來(lái)源，需要設(shè)計(jì)合理的方案獲取、存儲(chǔ)和分析網(wǎng)絡(luò)數(shù)據(jù)。網(wǎng)絡(luò)數(shù)據(jù)一般采用爬蟲(chóng)的形式獲取。爬蟲(chóng)是一種計(jì)算機(jī)程序，可以在網(wǎng)絡(luò)上通過(guò)一定的規(guī)則不斷地獲取網(wǎng)絡(luò)上的數(shù)據(jù)。實(shí)現(xiàn)簡(jiǎn)單的爬蟲(chóng)程序可分為3個(gè)步驟：1.根據(jù)URL獲取數(shù)據(jù)流2?對(duì)數(shù)據(jù)流進(jìn)行解析，獲得有用的數(shù)據(jù)。3?將有用的數(shù)據(jù)進(jìn)行合理的存儲(chǔ)。其中，對(duì)于步驟3根據(jù)存儲(chǔ)的數(shù)據(jù)形式可分為格式化數(shù)據(jù)、半格式化數(shù)據(jù)、文本數(shù)據(jù)。格式化數(shù)據(jù)采用成熟的關(guān)系型數(shù)據(jù)庫(kù)作為存儲(chǔ)的解決方案，半格式化數(shù)據(jù)采用NoSQL數(shù)據(jù)庫(kù)進(jìn)行管理和存儲(chǔ)，文本數(shù)據(jù)采用HDFS進(jìn)行存儲(chǔ)，利用YRAN實(shí)現(xiàn)資源管理的調(diào)度和管理。對(duì)于實(shí)時(shí)數(shù)據(jù)首先采用內(nèi)存數(shù)據(jù)庫(kù)進(jìn)行存儲(chǔ)和管理，經(jīng)處理后再進(jìn)行持久化存儲(chǔ)。6.3.2海量數(shù)據(jù)分析主要分為兩部分內(nèi)容：模型實(shí)現(xiàn)和分布式處理。模型實(shí)現(xiàn)在實(shí)際系統(tǒng)中一般采用模型服務(wù)器的形式進(jìn)行實(shí)現(xiàn)，以服務(wù)的形式提供模型計(jì)算能力，模型服務(wù)器一般包括很多分析模塊，其中空間分析模塊主要用來(lái)為各種應(yīng)用提供利用空間信息的能力；統(tǒng)計(jì)分析模塊用來(lái)實(shí)現(xiàn)簡(jiǎn)單的統(tǒng)計(jì)分析功能；機(jī)器學(xué)習(xí)模塊用來(lái)實(shí)現(xiàn)復(fù)雜的機(jī)器學(xué)習(xí)算法。實(shí)現(xiàn)海量的數(shù)據(jù)分析，需要進(jìn)行分布式處理。一方面，巨大的數(shù)據(jù)量無(wú)法用單機(jī)進(jìn)行處理，模型運(yùn)算時(shí)間很長(zhǎng)。另一方面，當(dāng)部分服務(wù)器出現(xiàn)問(wèn)題，模型計(jì)算要求不受影響繼續(xù)進(jìn)行。因此，對(duì)于實(shí)時(shí)性要求不高的分析任務(wù)，用MapReduce計(jì)算框架和Mahout相結(jié)合的方案進(jìn)行分析計(jì)算；對(duì)于實(shí)時(shí)性要求很高的任務(wù)，采用Spark生態(tài)系統(tǒng)作為解決方案。6.3.3云-端應(yīng)用模式云計(jì)算技術(shù)和移動(dòng)互聯(lián)網(wǎng)的不斷發(fā)展大大提高了互聯(lián)網(wǎng)應(yīng)用提供服務(wù)的能力，并促進(jìn)了云-端應(yīng)用模式的發(fā)展。云-端應(yīng)用模式是指利用云計(jì)算技術(shù)實(shí)現(xiàn)強(qiáng)大的計(jì)算能力和永不間斷的服務(wù)能力，利用智能終端和移動(dòng)互聯(lián)網(wǎng)技術(shù)實(shí)現(xiàn)隨時(shí)隨地提供服務(wù)的能力，可以利用智能終端設(shè)備上所搭載的傳感器實(shí)現(xiàn)信息搜集并上傳至云端，借云端的實(shí)時(shí)計(jì)算能力進(jìn)行實(shí)時(shí)反饋，通過(guò)網(wǎng)絡(luò)對(duì)相關(guān)設(shè)備發(fā)送指令進(jìn)行控制。在智慧城市建設(shè)過(guò)程中，云-端應(yīng)用模式具有非常大的想象空間和發(fā)展前景，可以應(yīng)用于智能家居、智慧醫(yī)療、城市應(yīng)急管理等領(lǐng)域。6.4應(yīng)用實(shí)例驗(yàn)證基于上述的智慧城市技術(shù)體系框架，對(duì)空氣質(zhì)量監(jiān)測(cè)、建模與模擬進(jìn)行了系統(tǒng)分析和設(shè)計(jì)，并將關(guān)鍵部分進(jìn)行了原型實(shí)現(xiàn)，驗(yàn)證了該技術(shù)體系框架的可行性。該系統(tǒng)總體設(shè)計(jì)如圖6.2所示，其系統(tǒng)設(shè)計(jì)思想與圖6.1所示的技術(shù)體系框架相同：天空地一體化對(duì)地監(jiān)測(cè)網(wǎng)絡(luò)對(duì)應(yīng)于數(shù)據(jù)獲取層；云數(shù)據(jù)平臺(tái)對(duì)應(yīng)于數(shù)據(jù)存儲(chǔ)層；地球系統(tǒng)建模環(huán)境對(duì)應(yīng)于數(shù)據(jù)分析層；業(yè)務(wù)應(yīng)用平臺(tái)則對(duì)應(yīng)于應(yīng)用層。應(yīng)臺(tái)信息發(fā)布平臺(tái)反演系統(tǒng)詡里

平臺(tái)噩詡里

平臺(tái)預(yù)測(cè)預(yù)報(bào)系統(tǒng)氣溶膠置感反演模型蠢境

S環(huán)數(shù)據(jù)采集更新Web服務(wù)接口遙翊據(jù)監(jiān)斕抿wsms應(yīng)臺(tái)信息發(fā)布平臺(tái)反演系統(tǒng)詡里

平臺(tái)噩詡里

平臺(tái)預(yù)測(cè)預(yù)報(bào)系統(tǒng)氣溶膠置感反演模型蠢境

S環(huán)數(shù)據(jù)采集更新Web服務(wù)接口遙翊據(jù)監(jiān)斕抿wsms-：一」L___」海量集成箒里量模型圖6.2空氣質(zhì)量監(jiān)測(cè)、建模與模擬系統(tǒng)總體設(shè)計(jì)圖基于該原型系統(tǒng)案例中進(jìn)行城市區(qū)域空氣質(zhì)量監(jiān)測(cè)、建模與模擬系統(tǒng)的相關(guān)研究,包括中國(guó)區(qū)域PM2.5時(shí)空監(jiān)測(cè)與模擬，北京機(jī)動(dòng)車源PM2.5貢獻(xiàn)及人口曝露研究、北京秋冬季灰霾成因機(jī)理研究。為了驗(yàn)證系統(tǒng)設(shè)計(jì)的可行性，開(kāi)發(fā)實(shí)現(xiàn)的原型模型，部分關(guān)鍵如下：1）利用爬蟲(chóng)技術(shù)通過(guò)網(wǎng)絡(luò)獲取了實(shí)時(shí)空氣質(zhì)量數(shù)據(jù)和實(shí)時(shí)氣象數(shù)據(jù)，并編寫了下載腳本用來(lái)自動(dòng)下載所需的遙感影像數(shù)據(jù)。目前已存儲(chǔ)39