3sNews讯 为期两天的2012地理信息开发者大会(简称：WGDC)在北京国家会议中心举行，本次大会以“新技术、新模式、新商业”为主题，是地理信息领域最具影响力的技术性盛会，其宗旨是不断引领和促进地理信息技术的创新与变革。在第二天“Map+与开发者训练营”分会场，来自《3s新闻周刊》的特约撰稿人蒋波涛博士为大家带来题为《PaaS平台Hadoop在GIS数据分析中的应用》的演讲。
地理信息技术作家蒋波涛
以下为文字实录：
我跟大家分享的是《PaaS平台Hadoop在GIS数据分析中的应用》。刚才百度和诺基亚都已经做好了大餐，包括开源软件也是，你现在用开源软件发布一个地图应该说是非常简单的事情，不管是数据库也好，还是切图的也好，或者是最终能发布出来也好。我现在要讲的东西可能你自己要做很多，充分发挥自己的思路或者是技巧。当然我会讲一个例子，就是如何把我们这种空间的查询关系转换一种思路，在大数据库里，或者是在这种数据库处理当中转换一种思路，解决问题。
我的介绍包括云计算大数据，Hadoop的介绍，介绍一下MapReduce的并行计算机制，其实它和地图一点关系都没有，Map就是一个映射，就如同Project在测绘领域是投影，而不是工程。还有就是怎么样用Hadoop里解决我们的问题，它的确可以解决问题，但是解决的绝对不是说把地图去存储，去可视化，去做查询，不是做这个事情的。最后是一个结论。
现在比较热门的词汇是云计算，大数据，人们都在谈论云计算，大家也把它分成了三种类型。IaaS、Paas、SaaS，他们编了一个大数据，他们能够提供的存储容量非常高了，但是后来看了一下，好像我们调的影像数据加起来也才10几个TB，和他们宣传的大数据的量，好像我们地理行业永远够不上那个标准。这个大数据可能我们所谓的数据也不可能有那么大，或者我们一般的影像数据或者是矢量数据有没有那么大。我们现在还在讨论一个问题，包括我们现在GIS的这种公司也在讨论自己的软件，是不是云平台商，是云GIS的软件。我觉得这个讨论好像也没有什么必要。因为从云计算本质来讲，可能软件或者服务放在互联网任何一个地方，用户感觉不到，你只要能够使用它，通过网络使用就够了。不管是我们开源的软件也好，或者是商业公司软件，不管是超图或者是什么，如果有一天它的软件能达到这种效果了，让你感觉不到你有什么样的困难，或者是他能通过在线Web服务的方式提供的话，都是云计算的模式。我后来也找了一下维基百科上关于云计算的定义，是基于互联网的计算方式，通过这种计算方式，我们可以共享软硬件的资源和信息，用户不用关心你的资源从哪里来，信息从哪里来，甚至你计算的服务器从哪里来。可能是租用的，可能是免费的，也可能是收费的，这个都不成问题。我们现在要讨论的问题就是说，怎么样自己来做一个小型的东西，写论文可以，或者是最终做商业实践也可以。今天上午方正国际的周总介绍，他们自己也用Hadoop在解决一些问题。
现在把云计算分为三个层次，我要介绍的是中间这个曾经。IaaS就是设施及服务，我们现在把它已经抽象成为我们去买一堆服务器，我们去装一个System Center或者是一个VMware，你虚拟出一大堆东西出来，或者是有一个软件管理这一堆虚拟机，当你需要的时候，虚拟化出一个新的系统出来，或者是你不需要的时候关掉。现在提供IaaS服务的，除了很多我们传统的机房以外，现在盛大、阿里也在提供虚拟机，主要去设不同的CPU、内存、硬盘或者是带宽，交多少钱就可以去使用，也不用担心它在什么地方。其他更多的是SaaS，很多软件都称为是SaaS的平台，就在上面可以使用，我觉得这个问题不大。
唯一的一点就是说，中间这个PaaS，因为它是需要建立在基础设施及服务上面的一种框架，一种应用。可能计算的结果需要提供给SaaS，就显得特别困难。因此我们看到，很多公司也好，它自己也似乎从来不称自己的软件为PasS平台，这个可能是比较难的。PaaS难在什么地方?首先是一个应用的框架，它提供一个东西，一个插件，比如说插件外面一个架子，你要在这个架子里面写东西，才能完成你自己的任务。它是一个Long time，提供一个运行的环境。一般代码写好以后，你可以用这个Long time去做执行和处理的一些工作。它可能是一个工作流的环境，也就是说，这个数据的处理是有始有终，中间的过程是预先给你规定好的。我们可以在这个过程当中加入自己的一些思路和想法，这也是Hadoop最终要解决的问题。
我们的大数据从何而来?社会化的网络，我们最近注意一下超图他们做的GIS精彩，开发者已经把微博和GIS联系了，产生了大量的数据点，这是非常重要的一件事情。我知道一个例子，电子商务会存在最后一公里的问题，有些电子商务商可能有一些想法，就是在我们的一些城市里面，比如说收货比较聚集的地方去建一个提货站，你到那里去提货，减少最后的问题。但是对于电子商务来讲也有问题，它每天的交易量可能上百万、上千万，把它变成地址，以后会有存储，会有检索和查询这样的问题。然后是智能手机的一些普及，图片的共享，这是一些非结构化的数据。所谓非结构化就是说，不能存到数据库。电子商务的应用中的地名地址数据也是一个庞大的数据源，还有我们地理信息数据采集的尺度越来越小，带来的数据也越来越多。比如说飞机飞过一次，拍这个点，这个点一出来，应该是说上千万、上亿的点，都出来了，所以说数据量太大。
我们来介绍Hadoop这样一个软件体系。为什么放一驾马车放在这里，是借用一个故事。我们人类赶一匹马去拉货，比如说这个货太重了，我们不会去培养一匹更大的马，繁殖几代，变成以前的高几倍，变成马力更大，我们不会，我们用两匹或者是三匹马去拉，这就是一个变相的思维。同样我们在现实的生活或者工作中，处理数据的计算量很大，可能有几十台服务器，或者是在PC机上去做。我们能不能分解成多个用户?在多台计算机上一起做?因为我们一般来讲，有些用户可能是临时性的，也不可能给你再去多购买很多硬件。Hadoop就是秉承这样一个思路，把任务分解，然后不同的任务交给不同的计算节点，这个计算节点可能很简单，就是不同的PC机来执行。它可以做什么呢?比如说从数百万份的气象站记录里面获得某一年份的最高或者是最低温度记录，可以记录一年或者是几年的数据，这种并不适合于Hadoop来做，因为Hadoop适宜于做少的大文件，这样的话，它是为每一个文件开启一个计算进程。如果你真的是几百万个这样的文件，每个文件有那么一两兆来给它来做的话，它就要反反复复开启好几百万个进程，这个实际上是得不偿失的。对于栅格数据进行地图的分析，这是我自己做过实验的，的确非常好，它把栅格数据当成一个矩阵，互相之间进行地图算法的计算，最后再融合，形成一份或者是多份数据。还可以在架构上构建地理脱铺网络的数据集，我自己也做过相应的实验，也是可行的。或者是Web海量信息的检索，这个实际上是Hadoop提出的一套初衷，它为什么提出来?最开始就是为了解决这个问题的，以及最后的这种海量数据的挖掘，包括空间数据的挖掘，也可以解决这些问题。
谷歌遇到了同样的问题，它有很多数据，还有很多非结构化的数据，比如图片、视频越来越多，需要存储的量越来越大，计算量也始终保持在很高的水平。他们解决了一些方法，比如说在寒冷或者是低电价的地方建数据中心，减少机房电费的支出。大家都知道一个事情就是，我们在服务器上用一块钱的电，就要在空调上要用一块五毛钱的电甚至更多的来解决散热的问题，很多地方在建计算中心，建机房，有的沿海的缺电的省份也在做，海南都要开始做云计算机房，我也不知道他们到时候怎么去解决散热问题，怎么去解决电力问题。使用改造后的直流电服务器，或者是使用普通PC服务器。但是更重要的在下面，就是说他们发明了很多计算模型或者是工具，像MapReduce，过程是GFS谷歌的文件系统，或者是Big Table等并行计算模型、文件存储模型和NoSQL数据库模型。用他们无穷的智慧，将谷歌的产品进行开源化。谷歌把这些这套东西介绍出来，Doug Cutting敏锐地捕捉到这一契机，在业余时间就开始开发自己的分布式计算框架Hadoop。后来被雅虎招安，后来项目被赠送给Apache基金会，并成为Apache，后来被商业社会和学术界接受。
我们看一下主要的四个组件，或者应用到的例子。包括Hadoop这种分布式的文件系统，也就是说不仅仅是一个框架，还是一种文件系统，这个文件系统是高可用的，自己就构建了一些备份的机制，能够保证你的数据不会丢失。所以设备是适合于做这种文件备份系统，据说亚马逊的存储服务也是通过Hadoop的HDFS做出来的，昨天我们也讨论过，能不能存储栅格数据，我觉得还是非常合适的。MapReduce是一种分布式的计算模型，提供了两个函数的接口，让你自己选，一个是Map的函数，一个是Reduce的函数。还有一个HBase，是面向行的数据库，这种特性是建立在HDFS之上的。我的数据如果存储，一般的数据库容量大了，我要做分库分表的操作，这个不用，可以继续加一个节点上去就可以写数据。数据库不支持查询，通过这个来做数据查询的工作。
HDFS是怎么样保证数据具有高可靠性的?当我安装起一个Hadoop的软件以后，我把我的数据存到这个HDFS上面，比如你的数据有1G，它会按照168个数据块进行切分，并且把每一份数据块都放在不同的数据节点上，一般是三份，可以调更多，调四份或者是调五份。我们举这个例子，一个文件如果被切分到四份，有500多兆的话，切成了四份，数据块会被放在一号二号和三号机，它的优点是什么呢?就是说如果我这个机器坏了，实际上对我是没有影响的。因为我从外面Hadoop的平台读这个数据的话是没有影响的，这就能保证这个数据不会丢失。除非说你所有的两台甚至是三台机器坏了就很难说了。通过这个节点，会记录文件的位置，也会对一些大数据量进行优化和保存。我们可以自己进行调整，有的时候可能调整得更小一点，调整到64兆，在用户数据的处理上会更大，关键是看数据的规模有多大。当我们讲数据存到HDFS以后，我们要对它进行处理，这个是MapReduce的一个并行计算的框架，它是一种计算分布式的模型，从一大堆的结算节点，把它作为一个集群来解决这个问题。作为MapReduce它解决问题有一个很有趣的地方，因为它是把这个数据切开以后，给你进行计算，最后得出一个结果。我们前面说过，我的数据都被切成一片一片的，放在不同的企业上。它不会把你这个数据，比如一号这个数据需要做计算了，他不会把你的机器移到四号机器上做计算，就会本身在一号机器上做完，把结果可能放到一个Reduce里面，那台机器把数据移过去，所以是尽量避免网间数据的开销，称这种特性叫做移动计算比移动数据更加经济。因为如果你的数据增得很大，哪怕在局域网当中传来传去，还会遇到丢包等事情，最后造成计算功亏一篑。MapReduce是运行在Java上面的，如果你的计算是失败了，你错了怎么办?它会自动的再重启这个计算过程，有一个心跳的检测，直到你这个计算成功为止。
HBase，可能一般的习惯于放在HDFS上面，但是以后的还是习惯放在数据库里面。是建立在HDFS的数据库，通过原生的HDFS支持。一个好处就是能够使用MapReduce的平台和算法来处理里面存储的数据。但是它的缺点也很明显，就是查询的时候，可以装很多数据，它的数据是横向的扩展过去的，但是没有这种机制，只能通过硬暴力的方式来解决查询的问题。为了解决这个问题，他们还有一个新的工具就是Hive，Hive是一种数据仓库，能够基于MR架构。这种查询意味着什么?意味着它跑得再快，可能也不如我们这种关系数据库里面这种东西跑得快。比如说我查GIS查询的话，我可能希望我输入一个SQL的命令进去，可能零点几秒钟数据就进去了，通过Hive的查询，最快也要20多秒，30秒，甚至是更慢，因为它要启动进程，它要处理，要查找，把查找的结果汇聚到一点，最后输出。
我们按照分布式的并行机制，可以在上千台PC机组成的集成里面进行海量的计算。一般来讲，我们做这种完全分布式的部署的话，有一台主机的一个节点，负责监控所有的节点，就是说负责读取数据，负责分发录入，也负责监督下面的这些子节点有没有正常工作，如果没有正常工作，是不是再提交一次，再计算一次?会自己通过这种机制来解决负载均衡的问题。Reduce深受Lisp的影响，不知道大家使用过Lisp的没有，它将任务分为两个阶段，实际上两个函数，一个是Map函数，一个是Reduce函数。我们所有编程的任务都到这个函数里面实现，从HDFS或者是HBase里面读取出来，不一定是数值，可是你想要的任何数据，任何文本，甚至是对象都可以。读进来之后，你需要对它进行一些处理，然后把它输出为新的对。这个处理的过程，普遍就是我们处理的过程。输出可能会通过一个过程进入到Reduce这个阶段，有这么一个过程，是混写，会把所有Key相同的来合并，这样就使我们的数据量更小，然后Reduce再把它输出。
读入数据，冲洗数据，进行交换和输出，这是MapReduce的一个数据库，比如168的，或者是更小的，可以读入到一个Map的过程，通过排序进入Reduce的阶段，这个过程中间的过程我们不用去管它，但是我们可以写自定义的代码，你排序的规则是什么，我们一般这种Key可能是一个值。但是如果你现在记录一个位置，记录一个值的话，你想要把一堆进行排序，比如先排横坐标，再排纵坐标，这种排序需要自己写相应的自定义排序的算法。这个也并不复杂，也就是一个接口实现各相应的功能就够了。这是一个Reduce过程，会生成一份结果，比如我们做栅格处理的时候，有好几个栅格数据，最后需要加加减减，做成这种计算，最后生成一份结果，我们就只能要一个Reduce。或者是你有两个Reduce更好，中间会把排序的数据传到不同的Reduce的节点上去。当然，时间会降低，因为Reduce实际上回洗过程是非常耗时的过程，如果数据量很大的情况下，你的输出又很大的情况下，其实Reduce非常耗时，这也是我们的一个经验，那就看你自己的选择了，或者是一个根本就没有Reduce的过程也可以，你如果一次性把它读出来，处理了，写出去，存在一个文件里面也可以。这是一个基本的示例，这么一个过程，我们选的是两份文件。比如我们假设一行文件被加入到一个Map的过程，当它读出来的时候是How有1个，Browe有1个，Does有1个，如果说How有2个了，可以经过经过排序，把Key相同的放在一起。这种数据流程看起来非常简单，但是你开动脑筋就会发现，其实可以做很多事情，这是一个经典的例子，算一个文档里面哪些字符有多少个是最经典的一个例子。
这是我自己做的一个实验，Hadoop这个东西也不是万能的，至少你不能把那个数据直接放上去读。做的实验就是用MR来做自动构面计算的实验，还有就是用GIS做检索的实验。第一个很简单，一堆点构成一个拓扑网络，可以通过左转或者是右转的方式，从任何一个点出发，按照那种算法的要求，你可以构成一个面起来。它的好处就是说，不管你选哪一个点触发，其实与其他的点没有什么关系的。如果你写一个程序，你的那个程序上同时运行10个这样的程序也是可以的，也就是它可以切分这个任务。如果你有1万个点，你只有一台机器，那么你就是1万个点，如果你有这样一个机制，就是说你有5台机器，每个机器上分两千个点，5个节点同时来做，所用的时间肯定比1万个点到一台机器上做的要好得多。这个过程就是，我用了两个MapReduce的过程，第一个是把它做拓扑网络，把这个数据读进去可能大家比较担心，不是原生的这种，还是文本文件式的，记录一下你这个点的POI是多少，是用Java编写的，因此可以直接调用Java的API，或者是AO的Java的API，是一点问题没有的，可以继续调用我们基础数据库的信息，把和它相关联的找出来，然后自己去记录一下在输出的地方记录一下我要哪些点，和哪些边相连，就构成一个拓扑网络了。我把上面的一堆结果重新读取出来，选取一个点开始，所不同的就是，我可能有一万个点，现在分到四五台机器上，现在每个点做面，做的也不是一个面，最终还是从我这个点出发，我们可能循环多少个点，最终形成一个面，记录的是这个东西。最终它的结果我们可能把它再记录一下，再通过其他的一些，把这几个点找到，把这个面构成起来。因此，具体的处理逻辑还是需要我们自己来实现的，这个是非常简单的一个例子。
每天几百万条的POI需要保存到数据库中，我觉得这个东西很现实。你做电子商务的，阿里巴巴或者是京东，每天不止几百万条，每天的交易量有几千万条，如果把几千万条的地址地名变成地址，你怎么去存?你把它用点的形式去存吗?是搞不定的。你无时无刻都在写数据库，你写是一回事，还面临着去读它的问题。还有一个问题就是说，我们现在基站更多的时候到了上亿条。我看到一个说法，关系数据库的表，大概在1亿条的时候就跑不动了，效率非常低。遇到的问题就是没有一种空间数据库能够满足这种要求或者是需要。
我们解决一下检索很慢的问题，使用什么样的数据库来存储这些数据?这些数据库是空间形式吗?比如说你把它还存储一个点，如果是通过这样的点来描述，怎么样做这种查询呢?比如说哪怕是你的ArcGIS或者是超图，从其中一个点找特定的点，耗的时间是很长的。我们还有没有其他的更加好的、更有效的空间检索方式?我们通过Geohash的方式方式存储这些点，把一个空间分成4份，比如说左上角是00，右下角是11，最大范围分成4块，比如说这个往下继续分，01继续加上00、11，可以无限的分下去。我们可以注意一下，实际上是对半分，哪怕是整个地球的范围，分布到多少次，就可以把你这个格子缩小到一个足够小的程度，完全能够标注POI点的程度。如果我们把地球上的一个点精度也这样分，因为我们用的是WGS84，因为你使用的是84这个坐标，从-180到180，-90到90的范围，划分到这种范围就分，横向上你去把它写成这些0101的值，纵向上也把它做这些值。然后把它们横向上的，就是说奇位数为横坐标，偶位数纵坐标，最终就能够得到一个比较短的值。大家感兴趣的话可以自己到网上去查一下这种方式。这是5位编码，也就是画了10次网格之后的结果。这个表示了一个范围，其实它的范围很大，里面更大的，从6位其实范围已经很小了。如果你到8位的时候，实际上9个格子就已经可以描述一栋房子了。我们自己做过一个计算，9位的时候，格子的长度和宽度是不一样，不是一个正方形的格子，是一个长方形的格子。到第9位的时候，每个格子的长度和宽度大概就是0.3米左右，也就是说，精度是绝对足够的，就是用点来描述地球上的位置也是空的。现在只不过是用递进的方式，把这个位置划到一个小的方框里面来。下面检索的问题就解决了，其实检索的问题很好解决。我们可以看到，如果对于8位的数字来讲，其实前7位的值都是一样的，就是第8位不一样。如果我们用这种方式去存储数据，将来你检索的时候怎么来检索?就是判断它的前面有几位相同。比如说我这里有一个点，我检索一下大概是200米，周围有哪些其他的POI点的存在，我先把自己的点大概编到一个7位就足够了。然后我就去在整个数据库里面找一项和我前面6位相同的这些格网有哪些，也就是找它周围的这么8个，或者甚至找更大范围相同的都可以，可以把这些格网找出来。当然一个问题就是说，不可能精确到200米，因为格网的宽度不是很固定的。比如我们到了第9级的0.3米，到了第8级的时候可能有13米多，更大一点的，可能有40多米，1千多米，范围不是一个固定的。但是，通过这种方式，足够让你在一个海量的数据库里面检索区域内相对较少的点出来，然后你再去判断它的距离，判断两个经纬度之间的距离，如果超过了200米，那你就不要了，如果小于200米就包含它。我们通过这种方式，把一个空间判断的问题转换成了一种匹配的，相对来讲较为简单的这么一种问题。就是说既能够解决海量POI数据的存储，又能解决它的检索，要不然你几百万、上千万的点存到里面去，是很难再查出来的，或者查出来的速度满足不了。当然最后查出来的速度取决于你有多少台机器，也不用说非常快，也不用说你现在输入命令进去以后，至少可能是40秒或者是1分钟左右。至少我自己在测那些速度的时候，基本上都是1分钟。如果做事后的分析，做技术查询也是足够的。
MapReduce和Hadoop与我们GIS没有太直接的关系，就是一个框架。你怎么去使用它完全取决于你自己的创造力、想法和思路。它适用的范围是我前面讲到的三个数据的存储、计算分析，解决海量地址的查询，或者是其他一切可以划分为多个问题来解决的这些技术问题。其中技术处理方面的问题都可以，我看到不少的论文都是这样来解决的，不会直接拿Hadoop来当做一个普通的数据链，去存储数据和切图，不会那样做，还是一个可并行计算的工具。
我的演讲就是这些内容，谢谢大家!
(以上内容根据速记整理，未经本人审核)
{{item.content}}