3sNews訊 為期兩天的2012地理信息開發(fā)者大會(簡稱：WGDC)在北京國家會議中心舉行，本次大會以“新技術(shù)、新模式、新商業(yè)”為主題，是地理信息領(lǐng)域最具影響力的技術(shù)性盛會，其宗旨是不斷引領(lǐng)和促進地理信息技術(shù)的創(chuàng)新與變革。在第二天“Map+與開發(fā)者訓(xùn)練營”分會場，來自《3s新聞周刊》的特約撰稿人蔣波濤博士為大家?guī)眍}為《PaaS平臺Hadoop在GIS數(shù)據(jù)分析中的應(yīng)用》的演講。

地理信息技術(shù)作家蔣波濤

　　以下為文字實錄：

　　我跟大家分享的是《PaaS平臺Hadoop在GIS數(shù)據(jù)分析中的應(yīng)用》。剛才百度和諾基亞都已經(jīng)做好了大餐，包括開源軟件也是，你現(xiàn)在用開源軟件發(fā)布一個地圖應(yīng)該說是非常簡單的事情，不管是數(shù)據(jù)庫也好，還是切圖的也好，或者是最終能發(fā)布出來也好。我現(xiàn)在要講的東西可能你自己要做很多，充分發(fā)揮自己的思路或者是技巧。當(dāng)然我會講一個例子，就是如何把我們這種空間的查詢關(guān)系轉(zhuǎn)換一種思路，在大數(shù)據(jù)庫里，或者是在這種數(shù)據(jù)庫處理當(dāng)中轉(zhuǎn)換一種思路，解決問題。

　　我的介紹包括云計算大數(shù)據(jù)，Hadoop的介紹，介紹一下MapReduce的并行計算機制，其實它和地圖一點關(guān)系都沒有，Map就是一個映射，就如同Project在測繪領(lǐng)域是投影，而不是工程。還有就是怎么樣用Hadoop里解決我們的問題，它的確可以解決問題，但是解決的絕對不是說把地圖去存儲，去可視化，去做查詢，不是做這個事情的。最后是一個結(jié)論。

　　現(xiàn)在比較熱門的詞匯是云計算，大數(shù)據(jù)，人們都在談?wù)撛朴嬎?，大家也把它分成了三種類型。IaaS、Paas、SaaS，他們編了一個大數(shù)據(jù)，他們能夠提供的存儲容量非常高了，但是后來看了一下，好像我們調(diào)的影像數(shù)據(jù)加起來也才10幾個TB，和他們宣傳的大數(shù)據(jù)的量，好像我們地理行業(yè)永遠夠不上那個標(biāo)準(zhǔn)。這個大數(shù)據(jù)可能我們所謂的數(shù)據(jù)也不可能有那么大，或者我們一般的影像數(shù)據(jù)或者是矢量數(shù)據(jù)有沒有那么大。我們現(xiàn)在還在討論一個問題，包括我們現(xiàn)在GIS的這種公司也在討論自己的軟件，是不是云平臺商，是云GIS的軟件。我覺得這個討論好像也沒有什么必要。因為從云計算本質(zhì)來講，可能軟件或者服務(wù)放在互聯(lián)網(wǎng)任何一個地方，用戶感覺不到，你只要能夠使用它，通過網(wǎng)絡(luò)使用就夠了。不管是我們開源的軟件也好，或者是商業(yè)公司軟件，不管是超圖或者是什么，如果有一天它的軟件能達到這種效果了，讓你感覺不到你有什么樣的困難，或者是他能通過在線Web服務(wù)的方式提供的話，都是云計算的模式。我后來也找了一下維基百科上關(guān)于云計算的定義，是基于互聯(lián)網(wǎng)的計算方式，通過這種計算方式，我們可以共享軟硬件的資源和信息，用戶不用關(guān)心你的資源從哪里來，信息從哪里來，甚至你計算的服務(wù)器從哪里來?？赡苁亲庥玫?，可能是免費的，也可能是收費的，這個都不成問題。我們現(xiàn)在要討論的問題就是說，怎么樣自己來做一個小型的東西，寫論文可以，或者是最終做商業(yè)實踐也可以。今天上午方正國際的周總介紹，他們自己也用Hadoop在解決一些問題。

　　現(xiàn)在把云計算分為三個層次，我要介紹的是中間這個曾經(jīng)。IaaS就是設(shè)施及服務(wù)，我們現(xiàn)在把它已經(jīng)抽象成為我們?nèi)ベI一堆服務(wù)器，我們?nèi)パb一個System Center或者是一個VMware，你虛擬出一大堆東西出來，或者是有一個軟件管理這一堆虛擬機，當(dāng)你需要的時候，虛擬化出一個新的系統(tǒng)出來，或者是你不需要的時候關(guān)掉。現(xiàn)在提供IaaS服務(wù)的，除了很多我們傳統(tǒng)的機房以外，現(xiàn)在盛大、阿里也在提供虛擬機，主要去設(shè)不同的CPU、內(nèi)存、硬盤或者是帶寬，交多少錢就可以去使用，也不用擔(dān)心它在什么地方。其他更多的是SaaS，很多軟件都稱為是SaaS的平臺，就在上面可以使用，我覺得這個問題不大。

　　唯一的一點就是說，中間這個PaaS，因為它是需要建立在基礎(chǔ)設(shè)施及服務(wù)上面的一種框架，一種應(yīng)用?？赡苡嬎愕慕Y(jié)果需要提供給SaaS，就顯得特別困難。因此我們看到，很多公司也好，它自己也似乎從來不稱自己的軟件為PasS平臺，這個可能是比較難的。PaaS難在什么地方?首先是一個應(yīng)用的框架，它提供一個東西，一個插件，比如說插件外面一個架子，你要在這個架子里面寫東西，才能完成你自己的任務(wù)。它是一個Long time，提供一個運行的環(huán)境。一般代碼寫好以后，你可以用這個Long time去做執(zhí)行和處理的一些工作。它可能是一個工作流的環(huán)境，也就是說，這個數(shù)據(jù)的處理是有始有終，中間的過程是預(yù)先給你規(guī)定好的。我們可以在這個過程當(dāng)中加入自己的一些思路和想法，這也是Hadoop最終要解決的問題。

　　我們的大數(shù)據(jù)從何而來?社會化的網(wǎng)絡(luò)，我們最近注意一下超圖他們做的GIS精彩，開發(fā)者已經(jīng)把微博和GIS聯(lián)系了，產(chǎn)生了大量的數(shù)據(jù)點，這是非常重要的一件事情。我知道一個例子，電子商務(wù)會存在最后一公里的問題，有些電子商務(wù)商可能有一些想法，就是在我們的一些城市里面，比如說收貨比較聚集的地方去建一個提貨站，你到那里去提貨，減少最后的問題。但是對于電子商務(wù)來講也有問題，它每天的交易量可能上百萬、上千萬，把它變成地址，以后會有存儲，會有檢索和查詢這樣的問題。然后是智能手機的一些普及，圖片的共享，這是一些非結(jié)構(gòu)化的數(shù)據(jù)。所謂非結(jié)構(gòu)化就是說，不能存到數(shù)據(jù)庫。電子商務(wù)的應(yīng)用中的地名地址數(shù)據(jù)也是一個龐大的數(shù)據(jù)源，還有我們地理信息數(shù)據(jù)采集的尺度越來越小，帶來的數(shù)據(jù)也越來越多。比如說飛機飛過一次，拍這個點，這個點一出來，應(yīng)該是說上千萬、上億的點，都出來了，所以說數(shù)據(jù)量太大。

　　我們來介紹Hadoop這樣一個軟件體系。為什么放一駕馬車放在這里，是借用一個故事。我們?nèi)祟愙s一匹馬去拉貨，比如說這個貨太重了，我們不會去培養(yǎng)一匹更大的馬，繁殖幾代，變成以前的高幾倍，變成馬力更大，我們不會，我們用兩匹或者是三匹馬去拉，這就是一個變相的思維。同樣我們在現(xiàn)實的生活或者工作中，處理數(shù)據(jù)的計算量很大，可能有幾十臺服務(wù)器，或者是在PC機上去做。我們能不能分解成多個用戶?在多臺計算機上一起做?因為我們一般來講，有些用戶可能是臨時性的，也不可能給你再去多購買很多硬件。Hadoop就是秉承這樣一個思路，把任務(wù)分解，然后不同的任務(wù)交給不同的計算節(jié)點，這個計算節(jié)點可能很簡單，就是不同的PC機來執(zhí)行。它可以做什么呢?比如說從數(shù)百萬份的氣象站記錄里面獲得某一年份的最高或者是最低溫度記錄，可以記錄一年或者是幾年的數(shù)據(jù)，這種并不適合于Hadoop來做，因為Hadoop適宜于做少的大文件，這樣的話，它是為每一個文件開啟一個計算進程。如果你真的是幾百萬個這樣的文件，每個文件有那么一兩兆來給它來做的話，它就要反反復(fù)復(fù)開啟好幾百萬個進程，這個實際上是得不償失的。對于柵格數(shù)據(jù)進行地圖的分析，這是我自己做過實驗的，的確非常好，它把柵格數(shù)據(jù)當(dāng)成一個矩陣，互相之間進行地圖算法的計算，最后再融合，形成一份或者是多份數(shù)據(jù)。還可以在架構(gòu)上構(gòu)建地理脫鋪網(wǎng)絡(luò)的數(shù)據(jù)集，我自己也做過相應(yīng)的實驗，也是可行的?；蛘呤荳eb海量信息的檢索，這個實際上是Hadoop提出的一套初衷，它為什么提出來?最開始就是為了解決這個問題的，以及最后的這種海量數(shù)據(jù)的挖掘，包括空間數(shù)據(jù)的挖掘，也可以解決這些問題。

　　谷歌遇到了同樣的問題，它有很多數(shù)據(jù)，還有很多非結(jié)構(gòu)化的數(shù)據(jù)，比如圖片、視頻越來越多，需要存儲的量越來越大，計算量也始終保持在很高的水平。他們解決了一些方法，比如說在寒冷或者是低電價的地方建數(shù)據(jù)中心，減少機房電費的支出。大家都知道一個事情就是，我們在服務(wù)器上用一塊錢的電，就要在空調(diào)上要用一塊五毛錢的電甚至更多的來解決散熱的問題，很多地方在建計算中心，建機房，有的沿海的缺電的省份也在做，海南都要開始做云計算機房，我也不知道他們到時候怎么去解決散熱問題，怎么去解決電力問題。使用改造后的直流電服務(wù)器，或者是使用普通PC服務(wù)器。但是更重要的在下面，就是說他們發(fā)明了很多計算模型或者是工具，像MapReduce，過程是GFS谷歌的文件系統(tǒng)，或者是Big Table等并行計算模型、文件存儲模型和NoSQL數(shù)據(jù)庫模型。用他們無窮的智慧，將谷歌的產(chǎn)品進行開源化。谷歌把這些這套東西介紹出來，Doug Cutting敏銳地捕捉到這一契機，在業(yè)余時間就開始開發(fā)自己的分布式計算框架Hadoop。后來被雅虎招安，后來項目被贈送給Apache基金會，并成為Apache，后來被商業(yè)社會和學(xué)術(shù)界接受。

　　我們看一下主要的四個組件，或者應(yīng)用到的例子。包括Hadoop這種分布式的文件系統(tǒng)，也就是說不僅僅是一個框架，還是一種文件系統(tǒng)，這個文件系統(tǒng)是高可用的，自己就構(gòu)建了一些備份的機制，能夠保證你的數(shù)據(jù)不會丟失。所以設(shè)備是適合于做這種文件備份系統(tǒng)，據(jù)說亞馬遜的存儲服務(wù)也是通過Hadoop的HDFS做出來的，昨天我們也討論過，能不能存儲柵格數(shù)據(jù)，我覺得還是非常合適的。MapReduce是一種分布式的計算模型，提供了兩個函數(shù)的接口，讓你自己選，一個是Map的函數(shù)，一個是Reduce的函數(shù)。還有一個HBase，是面向行的數(shù)據(jù)庫，這種特性是建立在HDFS之上的。我的數(shù)據(jù)如果存儲，一般的數(shù)據(jù)庫容量大了，我要做分庫分表的操作，這個不用，可以繼續(xù)加一個節(jié)點上去就可以寫數(shù)據(jù)。數(shù)據(jù)庫不支持查詢，通過這個來做數(shù)據(jù)查詢的工作。

　　HDFS是怎么樣保證數(shù)據(jù)具有高可靠性的?當(dāng)我安裝起一個Hadoop的軟件以后，我把我的數(shù)據(jù)存到這個HDFS上面，比如你的數(shù)據(jù)有1G，它會按照168個數(shù)據(jù)塊進行切分，并且把每一份數(shù)據(jù)塊都放在不同的數(shù)據(jù)節(jié)點上，一般是三份，可以調(diào)更多，調(diào)四份或者是調(diào)五份。我們舉這個例子，一個文件如果被切分到四份，有500多兆的話，切成了四份，數(shù)據(jù)塊會被放在一號二號和三號機，它的優(yōu)點是什么呢?就是說如果我這個機器壞了，實際上對我是沒有影響的。因為我從外面Hadoop的平臺讀這個數(shù)據(jù)的話是沒有影響的，這就能保證這個數(shù)據(jù)不會丟失。除非說你所有的兩臺甚至是三臺機器壞了就很難說了。通過這個節(jié)點，會記錄文件的位置，也會對一些大數(shù)據(jù)量進行優(yōu)化和保存。我們可以自己進行調(diào)整，有的時候可能調(diào)整得更小一點，調(diào)整到64兆，在用戶數(shù)據(jù)的處理上會更大，關(guān)鍵是看數(shù)據(jù)的規(guī)模有多大。當(dāng)我們講數(shù)據(jù)存到HDFS以后，我們要對它進行處理，這個是MapReduce的一個并行計算的框架，它是一種計算分布式的模型，從一大堆的結(jié)算節(jié)點，把它作為一個集群來解決這個問題。作為MapReduce它解決問題有一個很有趣的地方，因為它是把這個數(shù)據(jù)切開以后，給你進行計算，最后得出一個結(jié)果。我們前面說過，我的數(shù)據(jù)都被切成一片一片的，放在不同的企業(yè)上。它不會把你這個數(shù)據(jù)，比如一號這個數(shù)據(jù)需要做計算了，他不會把你的機器移到四號機器上做計算，就會本身在一號機器上做完，把結(jié)果可能放到一個Reduce里面，那臺機器把數(shù)據(jù)移過去，所以是盡量避免網(wǎng)間數(shù)據(jù)的開銷，稱這種特性叫做移動計算比移動數(shù)據(jù)更加經(jīng)濟。因為如果你的數(shù)據(jù)增得很大，哪怕在局域網(wǎng)當(dāng)中傳來傳去，還會遇到丟包等事情，最后造成計算功虧一簣。MapReduce是運行在Java上面的，如果你的計算是失敗了，你錯了怎么辦?它會自動的再重啟這個計算過程，有一個心跳的檢測，直到你這個計算成功為止。

　　HBase，可能一般的習(xí)慣于放在HDFS上面，但是以后的還是習(xí)慣放在數(shù)據(jù)庫里面。是建立在HDFS的數(shù)據(jù)庫，通過原生的HDFS支持。一個好處就是能夠使用MapReduce的平臺和算法來處理里面存儲的數(shù)據(jù)。但是它的缺點也很明顯，就是查詢的時候，可以裝很多數(shù)據(jù)，它的數(shù)據(jù)是橫向的擴展過去的，但是沒有這種機制，只能通過硬暴力的方式來解決查詢的問題。為了解決這個問題，他們還有一個新的工具就是Hive，Hive是一種數(shù)據(jù)倉庫，能夠基于MR架構(gòu)。這種查詢意味著什么?意味著它跑得再快，可能也不如我們這種關(guān)系數(shù)據(jù)庫里面這種東西跑得快。比如說我查GIS查詢的話，我可能希望我輸入一個SQL的命令進去，可能零點幾秒鐘數(shù)據(jù)就進去了，通過Hive的查詢，最快也要20多秒，30秒，甚至是更慢，因為它要啟動進程，它要處理，要查找，把查找的結(jié)果匯聚到一點，最后輸出。

　　我們按照分布式的并行機制，可以在上千臺PC機組成的集成里面進行海量的計算。一般來講，我們做這種完全分布式的部署的話，有一臺主機的一個節(jié)點，負責(zé)監(jiān)控所有的節(jié)點，就是說負責(zé)讀取數(shù)據(jù)，負責(zé)分發(fā)錄入，也負責(zé)監(jiān)督下面的這些子節(jié)點有沒有正常工作，如果沒有正常工作，是不是再提交一次，再計算一次?會自己通過這種機制來解決負載均衡的問題。Reduce深受Lisp的影響，不知道大家使用過Lisp的沒有，它將任務(wù)分為兩個階段，實際上兩個函數(shù)，一個是Map函數(shù)，一個是Reduce函數(shù)。我們所有編程的任務(wù)都到這個函數(shù)里面實現(xiàn)，從HDFS或者是HBase里面讀取出來，不一定是數(shù)值，可是你想要的任何數(shù)據(jù)，任何文本，甚至是對象都可以。讀進來之后，你需要對它進行一些處理，然后把它輸出為新的對。這個處理的過程，普遍就是我們處理的過程。輸出可能會通過一個過程進入到Reduce這個階段，有這么一個過程，是混寫，會把所有Key相同的來合并，這樣就使我們的數(shù)據(jù)量更小，然后Reduce再把它輸出。

　　讀入數(shù)據(jù)，沖洗數(shù)據(jù)，進行交換和輸出，這是MapReduce的一個數(shù)據(jù)庫，比如168的，或者是更小的，可以讀入到一個Map的過程，通過排序進入Reduce的階段，這個過程中間的過程我們不用去管它，但是我們可以寫自定義的代碼，你排序的規(guī)則是什么，我們一般這種Key可能是一個值。但是如果你現(xiàn)在記錄一個位置，記錄一個值的話，你想要把一堆進行排序，比如先排橫坐標(biāo)，再排縱坐標(biāo)，這種排序需要自己寫相應(yīng)的自定義排序的算法。這個也并不復(fù)雜，也就是一個接口實現(xiàn)各相應(yīng)的功能就夠了。這是一個Reduce過程，會生成一份結(jié)果，比如我們做柵格處理的時候，有好幾個柵格數(shù)據(jù)，最后需要加加減減，做成這種計算，最后生成一份結(jié)果，我們就只能要一個Reduce?；蛘呤悄阌袃蓚€Reduce更好，中間會把排序的數(shù)據(jù)傳到不同的Reduce的節(jié)點上去。當(dāng)然，時間會降低，因為Reduce實際上回洗過程是非常耗時的過程，如果數(shù)據(jù)量很大的情況下，你的輸出又很大的情況下，其實Reduce非常耗時，這也是我們的一個經(jīng)驗，那就看你自己的選擇了，或者是一個根本就沒有Reduce的過程也可以，你如果一次性把它讀出來，處理了，寫出去，存在一個文件里面也可以。這是一個基本的示例，這么一個過程，我們選的是兩份文件。比如我們假設(shè)一行文件被加入到一個Map的過程，當(dāng)它讀出來的時候是How有1個，Browe有1個，Does有1個，如果說How有2個了，可以經(jīng)過經(jīng)過排序，把Key相同的放在一起。這種數(shù)據(jù)流程看起來非常簡單，但是你開動腦筋就會發(fā)現(xiàn)，其實可以做很多事情，這是一個經(jīng)典的例子，算一個文檔里面哪些字符有多少個是最經(jīng)典的一個例子。

　　這是我自己做的一個實驗，Hadoop這個東西也不是萬能的，至少你不能把那個數(shù)據(jù)直接放上去讀。做的實驗就是用MR來做自動構(gòu)面計算的實驗，還有就是用GIS做檢索的實驗。第一個很簡單，一堆點構(gòu)成一個拓撲網(wǎng)絡(luò)，可以通過左轉(zhuǎn)或者是右轉(zhuǎn)的方式，從任何一個點出發(fā)，按照那種算法的要求，你可以構(gòu)成一個面起來。它的好處就是說，不管你選哪一個點觸發(fā)，其實與其他的點沒有什么關(guān)系的。如果你寫一個程序，你的那個程序上同時運行10個這樣的程序也是可以的，也就是它可以切分這個任務(wù)。如果你有1萬個點，你只有一臺機器，那么你就是1萬個點，如果你有這樣一個機制，就是說你有5臺機器，每個機器上分兩千個點，5個節(jié)點同時來做，所用的時間肯定比1萬個點到一臺機器上做的要好得多。這個過程就是，我用了兩個MapReduce的過程，第一個是把它做拓撲網(wǎng)絡(luò)，把這個數(shù)據(jù)讀進去可能大家比較擔(dān)心，不是原生的這種，還是文本文件式的，記錄一下你這個點的POI是多少，是用Java編寫的，因此可以直接調(diào)用Java的API，或者是AO的Java的API，是一點問題沒有的，可以繼續(xù)調(diào)用我們基礎(chǔ)數(shù)據(jù)庫的信息，把和它相關(guān)聯(lián)的找出來，然后自己去記錄一下在輸出的地方記錄一下我要哪些點，和哪些邊相連，就構(gòu)成一個拓撲網(wǎng)絡(luò)了。我把上面的一堆結(jié)果重新讀取出來，選取一個點開始，所不同的就是，我可能有一萬個點，現(xiàn)在分到四五臺機器上，現(xiàn)在每個點做面，做的也不是一個面，最終還是從我這個點出發(fā)，我們可能循環(huán)多少個點，最終形成一個面，記錄的是這個東西。最終它的結(jié)果我們可能把它再記錄一下，再通過其他的一些，把這幾個點找到，把這個面構(gòu)成起來。因此，具體的處理邏輯還是需要我們自己來實現(xiàn)的，這個是非常簡單的一個例子。

　　每天幾百萬條的POI需要保存到數(shù)據(jù)庫中，我覺得這個東西很現(xiàn)實。你做電子商務(wù)的，阿里巴巴或者是京東，每天不止幾百萬條，每天的交易量有幾千萬條，如果把幾千萬條的地址地名變成地址，你怎么去存?你把它用點的形式去存嗎?是搞不定的。你無時無刻都在寫數(shù)據(jù)庫，你寫是一回事，還面臨著去讀它的問題。還有一個問題就是說，我們現(xiàn)在基站更多的時候到了上億條。我看到一個說法，關(guān)系數(shù)據(jù)庫的表，大概在1億條的時候就跑不動了，效率非常低。遇到的問題就是沒有一種空間數(shù)據(jù)庫能夠滿足這種要求或者是需要。

　　我們解決一下檢索很慢的問題，使用什么樣的數(shù)據(jù)庫來存儲這些數(shù)據(jù)?這些數(shù)據(jù)庫是空間形式嗎?比如說你把它還存儲一個點，如果是通過這樣的點來描述，怎么樣做這種查詢呢?比如說哪怕是你的ArcGIS或者是超圖，從其中一個點找特定的點，耗的時間是很長的。我們還有沒有其他的更加好的、更有效的空間檢索方式?我們通過Geohash的方式方式存儲這些點，把一個空間分成4份，比如說左上角是00，右下角是11，最大范圍分成4塊，比如說這個往下繼續(xù)分，01繼續(xù)加上00、11，可以無限的分下去。我們可以注意一下，實際上是對半分，哪怕是整個地球的范圍，分布到多少次，就可以把你這個格子縮小到一個足夠小的程度，完全能夠標(biāo)注POI點的程度。如果我們把地球上的一個點精度也這樣分，因為我們用的是WGS84，因為你使用的是84這個坐標(biāo)，從-180到180，-90到90的范圍，劃分到這種范圍就分，橫向上你去把它寫成這些0101的值，縱向上也把它做這些值。然后把它們橫向上的，就是說奇位數(shù)為橫坐標(biāo)，偶位數(shù)縱坐標(biāo)，最終就能夠得到一個比較短的值。大家感興趣的話可以自己到網(wǎng)上去查一下這種方式。這是5位編碼，也就是畫了10次網(wǎng)格之后的結(jié)果。這個表示了一個范圍，其實它的范圍很大，里面更大的，從6位其實范圍已經(jīng)很小了。如果你到8位的時候，實際上9個格子就已經(jīng)可以描述一棟房子了。我們自己做過一個計算，9位的時候，格子的長度和寬度是不一樣，不是一個正方形的格子，是一個長方形的格子。到第9位的時候，每個格子的長度和寬度大概就是0.3米左右，也就是說，精度是絕對足夠的，就是用點來描述地球上的位置也是空的。現(xiàn)在只不過是用遞進的方式，把這個位置劃到一個小的方框里面來。下面檢索的問題就解決了，其實檢索的問題很好解決。我們可以看到，如果對于8位的數(shù)字來講，其實前7位的值都是一樣的，就是第8位不一樣。如果我們用這種方式去存儲數(shù)據(jù)，將來你檢索的時候怎么來檢索?就是判斷它的前面有幾位相同。比如說我這里有一個點，我檢索一下大概是200米，周圍有哪些其他的POI點的存在，我先把自己的點大概編到一個7位就足夠了。然后我就去在整個數(shù)據(jù)庫里面找一項和我前面6位相同的這些格網(wǎng)有哪些，也就是找它周圍的這么8個，或者甚至找更大范圍相同的都可以，可以把這些格網(wǎng)找出來。當(dāng)然一個問題就是說，不可能精確到200米，因為格網(wǎng)的寬度不是很固定的。比如我們到了第9級的0.3米，到了第8級的時候可能有13米多，更大一點的，可能有40多米，1千多米，范圍不是一個固定的。但是，通過這種方式，足夠讓你在一個海量的數(shù)據(jù)庫里面檢索區(qū)域內(nèi)相對較少的點出來，然后你再去判斷它的距離，判斷兩個經(jīng)緯度之間的距離，如果超過了200米，那你就不要了，如果小于200米就包含它。我們通過這種方式，把一個空間判斷的問題轉(zhuǎn)換成了一種匹配的，相對來講較為簡單的這么一種問題。就是說既能夠解決海量POI數(shù)據(jù)的存儲，又能解決它的檢索，要不然你幾百萬、上千萬的點存到里面去，是很難再查出來的，或者查出來的速度滿足不了。當(dāng)然最后查出來的速度取決于你有多少臺機器，也不用說非?？欤膊挥谜f你現(xiàn)在輸入命令進去以后，至少可能是40秒或者是1分鐘左右。至少我自己在測那些速度的時候，基本上都是1分鐘。如果做事后的分析，做技術(shù)查詢也是足夠的。

　　MapReduce和Hadoop與我們GIS沒有太直接的關(guān)系，就是一個框架。你怎么去使用它完全取決于你自己的創(chuàng)造力、想法和思路。它適用的范圍是我前面講到的三個數(shù)據(jù)的存儲、計算分析，解決海量地址的查詢，或者是其他一切可以劃分為多個問題來解決的這些技術(shù)問題。其中技術(shù)處理方面的問題都可以，我看到不少的論文都是這樣來解決的，不會直接拿Hadoop來當(dāng)做一個普通的數(shù)據(jù)鏈，去存儲數(shù)據(jù)和切圖，不會那樣做，還是一個可并行計算的工具。

　　我的演講就是這些內(nèi)容，謝謝大家!
 

　　(以上內(nèi)容根據(jù)速記整理，未經(jīng)本人審核)