本发明涉及大数据处理与并行计算方法。
背景技术：
随着网络服务技术的发展，获取到的数据越量也越来越大，服务领域的数据处理与分析的时间耗费就越大。因此，传统的数据处理技术和串行计算技术难以满足高精细地理大数据处理的需求。supermap支持并行计算，有效的提高了大数据处理的效率。
并行计算原理是，并行计算是将一个任务分解成若干个小任务并协同执行以完成求解的过程，是增强复杂问题解决能力和提升性能的有效途径。并行计算可以通过多种途径实现，包括多进程、多线程以及其他多种方式，supermap是通过多线程方式实现并行计算的，可充分和更加高效地利用多核计算资源，从而降低单个问题的求解时间，节省成本，也能够满足更大规模或更高精度要求的问题求解需求。经比较发现：串行与并行两种计算方式。当一个任务被划分为a、b、c三个子任务时，串行需要依次执行三个子任务，而多线程并行则可以通过三个线程同时执行三个子任务。
在并行计算支持下，一台普通的四核计算机上某次执行“提取等值线”分析时cpu的使用情况。当使用1个线程分析时，cpu利用率较低，只有一个cpu参与运算，当设置并行线程数为4时，所有四个cpu核心都参与运算，cpu利用率最高可达100％。
当一个生成三维晕渲图的实例，对比多线程并行计算和单线程计算的操作时间。本实例应用的数据为某地区的dem数据行列数为15000*20000，数据量大小为884m，分别对其进行三维晕渲图操作，使用单线程的supermapidesktop8c进行分析需要80秒，而通过并行计算只需15秒即可完成同样的操作。通过上例可知，同样的数据处理通过并行计算可节省3-5倍的时间，大大的节省了时间成本，提高了分析的性能及工作效率。并行计算与单线程耗时对比：分析的性能提升十倍以上，整体性能提升五倍，并行计算花费的运算时间是单线程15％左右
支持并行计算的功能，目前，supermap支持并行计算的功能有：栅格分析、水文分析、网络分析、拓扑预处理、叠加分析、空间查询等。
栅格分析：栅格分析功能模块中支持并行计算的功能有：插值分析、提取等值线、提取等值面、坡度分析、坡向分析、栅格填挖方、面填挖方、反算填挖方、表面面积量算、表面体积量算、查找极值、生成三维晕渲图、生成正射三维影像、单点可视域分析、多点可视域分析、栅格重采样、栅格重分级、栅格聚合等。
叠加分析：对线面叠加分析都支持并行计算，包括线面的裁剪、擦除、合并、相交、同一、对称差、更新。
空间查询：面对象的包含和求交查询支持并行计算。
本发明目的是，提出一种项目数据和个体数据并行管理的处理方法，设置线程数目：线程数目的设置有两种方式，一种是直接在“环境”对话框中设置；另一种是修改配置文件。具体设置方式如下：l)单击“文件”按钮，在菜单中选择“选项”，在弹出的“supermapidesktop8c选项”对话框的“环境”设置页面中，直接设置“并行计算线程数”即可；
系统配置文件supermap.xml中的节点用于指定线程数目，初始值为2。
supermap.xml位于组件产品安装目录\bin文件夹下；设置线程数目为4，则配置文件应修改为：4。
建立用于数据分析的supermap并行计算环境；将各个节点上独立运行的并行进程组织为并行程序。
首先向资源管理器申请计算节点，为单个业务分配的所有节点将共同组成业务集；选择一个进程作为主进程，其余进程作为分进程。
将各个节点上独立运行的并行进程组织为并行程序，对程序的代码进行修改，将主函数修改为可被各并行进程执行的函数。
所述主进程维护的文档元数据缓存，分进程维护本地文档缓存以及分进程所开启的工作线程和数据线程。
在进程管理器调度执行业务的supermap进程之前，首先调度并执行文档初始化进程，然后向进程管理器请求执行进程。
用于文本数据分析的supermap并行计算环境；将各个节点上独立运行的并行进程组织为并行程序中：所述调度并执行文档初始化进程，然后向进程管理器请求执行进程，具体包括：
初始化完成之后，进程管理器等待一轮心跳通信的时间周期，以获知某个进程管理器有空闲的map/reduce时隙并且该进程管理器向进程管理器请求执行进程；
当接到该心跳信息之后，进程管理器将调度该文档初始化进程到该进程管理器上执行；对应的进程管理器负责执行文档初始化进程，并在执行过程中通过周期性的心跳通信向进程管理器汇报该进程的状态直至进程完成。
应用程序启动时会优先读取配置文件中的线程数，若在“并行计算线程数”处修改了线程数，则会立即生效，同时会自动修改配置文件中的值；而配置文件中的线程数目只在应用程序启动时被读取一次，手动修改配置文件后，需要重新启动应用程序才能生效。线程数目的有效范围为1-16。如果配置文件中的线程数目超出范围，则设置无效，使用默认值2；如果在“并行计算线程数”处设置的值大于16，则设置的值会自动调整为16。那么如何设置合理的线程数呢？可参考如下进行设置：
1.指定的多个线程将在计算机处理器所有核之间分配，当线程数目等于处理器总核数时，所有核都参与计算，可以充分利用计算机的计算资源。
2.线程数目多于计算机核数时，线程调度与负载均衡问题可能会导致占用更多时间，即使分析计算的时间进一步降低，也可能导致整体性能提升不明显。因此不建议这样做。
地理空间分析具有算法逻辑复杂、数据规模大等普遍特点，是一种计算密集、数据密集型功能，通过并行计算可以充分利用多核计算资源，从而大大降低分析时间，提高性能。并行计算的实现为大数据处理提供了强劲有力的支撑。
项目数据和个体数据并行管理的处理方法，项目数据和个体数据并行管理的处理
需要考虑相关的项目数据和个体数据并行管理并发访问。而并发问题是困难的，需要满足常见的并发和同步。
有益效果：本发明项目数据和个体数据并行管理的异步，同步，就是一个线程执行一个方法或函数的时候，会阻塞其它线程，其他线程要等待它执行完毕才能继续执行。异步，就是多个线程之间没有阻塞，多个线程同时执行。通俗一点来说，同步就是一件事一件事的做，异步就是做一件事，不影响做其他事情，多线程处理是异步。
具体实施方式：
用于文本数据分析的supermap并行计算环境；将各个节点上独立运行的并行进程组织为并行程序中：所述调度并执行文档初始化进程，然后向进程管理器请求执行进程，具体包括：
初始化完成之后，进程管理器等待一轮心跳通信的时间周期，以获知某个进程管理器有空闲的supermap时隙并且该进程管理器向进程管理器请求执行进程；
当接到该心跳信息之后，进程管理器将调度该文档初始化进程到该进程管理器上执行；对应的进程管理器负责执行文档初始化进程，并在执行过程中通过周期性的心跳通信向进程管理器汇报该进程的状态直至进程完成。
处理并发和同同步问题主要是通过锁机制。悲观锁：正如其名，它指的是对数据被外界(包括本系统当前的其他事务，以及来自外部系统的事务处理)修改持保守态度。因此，在这个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)。一个典型的倚赖数据库的悲观锁调用：
select*fromaccountwherename＝”erica”forupdate
这条sql语句锁定了account表中所有符合检索条件(name＝”erica”)的记录。本次事务提交之前(事务提交时会释放事务过程中的锁)，外界无法修改这些记录。hibernate的悲观锁，也是基于数据库的锁机制实现。
下面的代码实现了对查询记录的加锁：
1stringhqlstr＝"fromtuserasuserwhereuser.name＝'erica'"；
2queryquery＝session.createquery(hqlstr)；
3query.setlockmode("user",lockmode.upgrade)；//加锁
4listuserlist＝query.list()；//执行查询，获取数据
观察运行期hibernate生成的sql语句：
selecttuser0_.idasid,tuser0_.nameasname,
5tuser0_.group_idasgroup_id,tuser0_.user_typeasuser_type,
tuser0_.sexassexfromt_usertuser0_where
(tuser0_.name＝'erica')forupdate
这里hibernate通过使用数据库的forupdate子句实现了悲观锁机制。
hibernate的加锁模式有：
只有在查询开始之前(也就是hiberate生成sql之前)设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含forupdate子句的selectsql加载进来，所谓数据库加锁也就无从谈起。
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时(如更改用户帐户余额)，如果采用悲观锁机制，也就意味着整个操作过程中(从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间)，数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本version)记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
假如数据库中账户余额为100，version为1，操作员a读出余额，并修改为50，而在a操作的同时操作员b也读出了账户余额100，并修改为80，a完成了操作录入系统，version从1加上1变为2，余额修改为50，操作员b也提交了记录，version也变为2，余额则是80，但是此时数据库发现，b提交的version为2，当前版本也是2，不满足“提交版本必须大于记录当前版本才能执行更新“的乐观锁策略。因此，操作员b的提交被驳回。这样，就避免了操作员b用基于version＝1的旧数据修改的结果覆盖操作员a的操作结果的可能。从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销(操作员a和操作员b操作过程中，都没有对数据库数据加锁)，大大提升了大并发量下的系统整体性能表现。需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整(如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开)。hibernate在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用hibernate提供的透明化乐观锁实现，将大大提升我们的生产力。
锁同步同步更多指的是应用程序的层面，多个线程进来，只能一个一个的访问，java中指的是syncrinized关键字。锁也有2个层面，一个是java中谈到的对象锁，用于线程同步；另外一个层面是数据库的锁；如果是分布式的系统，显然只能利用数据库端的锁来实现。