基于Hadoop的Clearinghouse系统架构设计
1 Clearinghouse(数据交换中心)介绍
Clearinghouse(数据交换中心)是随着异构组织之间共享空间数据而产生的，它的目标是建立一个虚拟空间数据机制，用来收集空间数据的元数据和发布服务，以便高效的获取空间数据，同时利用空间数据提供决策支持。通常建立Clearinghouse的基本途径是通过一套元数据标准，收集各个组织中空间数据的元数据，通过服务接口帮助用户确定存在哪些数据，以及获取这些数据的方式等。但是随着各个组织中的空间数据的快速增长，其元数据条目也在不断增多。
Clearinghouse的功能概括如下：
(1)是一个可查询的信息目录。它覆盖所有参与信息共享的地理区域，为用户提供了对相关地理信息进行查询、发布等操作的工具。这个信息目录包含的不是数据本身，而是关于数据的信息，即元数据。
(2)是一个虚拟信息空间。在这里，可以通过简单操作来搜寻和定位感兴趣的地理信息。它是采用统一的元数据，相同的查询和检索协议，以及用于各种元数据收集的注册系统来完成的，可借以实现信息挖掘。
(3)是一个集中式服务系统。所有地理数据的元数据都存放在clearinghouse中，客户端采用现有的Web技术，通过查询元数据来获取数字化地理信息。
在大数据环境下，Clearinghouse存在和需要解决如下问题：
1） 数据量大，增长快。
这里所涉及的数据量比传统事务处理大得多，且随时间的推移而累积。在这种环境下对任何一种数据处理平台的一个关键性要求是它必须具有快速的支持系统扩展的应变能力。
2） 分析需求：复杂的数据挖掘算法
根据TDWI对大数据分析的报告，数据分析由常规分析转向深度分析。深度分析包括数据关联分析、回归分析等复杂分析。
数据分析趋势
2 Clearinghouse关键技术
2.1 在SOA中的角色
SOA（Service‐Oriented Architecture, SOA）是一个面向服务的框架体系，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。SOA架构中主要包括服务提供者、注册中心和服务请求者三个角色。服务提供者将服务按一定规则发布到注册中心，服务提供者是服务的所有者，从体系结构上看它是提供服务访问的平台。服务请求者是需要服务的人或组织，从体系结构上看是查找和调用服务的客户端应用程序。注册中心充当存储服务描述信息的角色，是建立服务提供者与服务使用者之间的桥梁。SOA的三种操作：发布操作：为了使服务可访问，需要发布服务描述以使服务使用者可以发现它。查找操作：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。绑定操作：在检索到服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。
从SOA框架来看，Clearinghouse即是服务请求者，也是服务提供者。
SOA服务过程
2.2 数据分析
大数据环境下Clearinghouse应具备的特性
| 实时查询 |
快速响应查询，并实时返回查询结果 |
| 较低的分析延迟 |
业务需求变化时，能快速反应；对数据进行复杂分析时， 能在合理时间范围内完成 |
| 高容错性 |
查询和数据分析失败时，只需重做部分工作 |
| 高度可扩展性 |
横向大规模可扩展 |
| 较低成本 |
较高的性价比 |
下面通过比较数据库和hadoop，提出结合数据库和hadoop各自优点设计Clearinghouse。
1）较低的分析延迟
当系统按需服务的需求发生变化时，系统能够动态地适应按需服务环境的变化，能在合理的时间范围内处理海量数据。
2）高容错性
海量数据的处理通常是通过并行系统来解决，因此要求在处理处理过程中，当部分节点失效的情况下，不需要重做整个任务，只需要重做部分工作。在大规模机群环境下，节点的失败将不再是稀有事件，根据google报告，平均每个MapReduce数据处理任务就有1.2个工作节点失效，因此在大规模机群环境下，系统不能依赖于硬件来保证容错性，要更多地考虑软件级容错。
并行数据库容错能力较差。当一个查询运行于并行数据库上时，一旦一个节点出现故障，并行数据库就必须重新执行该查询。因此，当一个集群中的单点故障发生率较高时，并行数据仓库的性能就会下降。在存储海量数据的大规模机群环境下，查询失败将会变为一个普通事件，在极端情况下，有可能会出现不停重做查询的情况。
hadoop有较好的容错性，如果某个节点失败，只需要重新调度执行该节点的任务即可，不需要重新提交全部任务。
3）容易横向扩展
为了支持海量数据并行处理，不能依靠一台或少数几台机器的升级（纵向扩展）满足数据量的快速增长，而是希望系统能够通过横向可扩展来实现此目标。
普遍认为无共享结构（shared nothing每个节点拥有私有内存和磁盘，并且通过高速网络同其它节点互连）具备较好的扩展性，分析型操作往往涉及大规模的并行扫描、多维聚集及星型连接操作，这些操作也比较适合在无共享结构的网络环境运行。
并行数据库大多支持有限扩展。一方面，并行数据库需要高端硬件来保证其可靠性，如果并行数据库要进行大规模扩展，其代价会很高，从而限制了并行数据库的扩展性。
另一方面从CAP理论考虑，一个分布式系统不可能同时满足数据一致性、可用性和分区容忍性这三个需求，选择其中任两项，便会损害另一项，而并行数据库追求的是数据一致性和系统的可用性，从而影响了它的扩展能力。
Hadoop由于各节点的松耦合性，使其具有卓越的扩展能力。Hadoop集群中的节点可以被任意地移除，而几乎不影响现有任务的运行，同时其扩展能力已在工业界得到了充分验证，如Google、Facebook、百度、阿里巴巴等。
4）较低成本：较高的性价比
在满足需求的前提下，某技术成本越低，其生命力就越强，需要指出的是成本是一个综合指标，不仅仅是硬件或软件的代价，还应包括日常运维成本（网络费用、电费、建筑等）和管理人员成本等，据报告，数据中心的主要成本不是硬件的购置成本，而是日常运维成本，因此，在设计系统时需要更多地关注此项内容。
并行数据库大部分是商业化的，需要高端硬件的支持和购买昂贵的软件系统。
Hadoop对硬件的要求较低，可以基于异构的廉价硬件来搭建机群，同时Hadooop是免费开源的，因此其构建成本比并行数据库低。
5）实时查询
Clearinghouse的基本功能是能够根据用户的需求查询空间元数据，并快速返回查询结果。这在海量数据环境下，对数据的更新、查询提取了新的需求。
并行数据库由于采用了许多先进的技术手段和算法，如索引、数据压缩、视图等，使其查询性能很高。
在同等硬件条件下，Hadoop的查询性能远低于并行数据库，这是由其最初的设计定位决定的，MapReduce的设计初衷是面向非结构化数据的处理，这些数据具有数据量大，处理复杂等特点，而且往往是一次性处理，为了获得较好的扩展能力和容错能力，MapReduce采取了基于扫描的处理模式和对中间结果步步物化的执行策略，从而导致较高的Ｉ／Ｏ代价，为了减少数据预处理时间，MapReduce没有使用模式、索引、物化视图等技术手段，其数据预处理仅是一次数据加载操作，但由此导致了一个问题———较高的元组解析代价。MapReduce环境下，每个查询都是直接从文件系统中读入原始数据文件，而非传统的从数据库中读入经处理过的文件，因此其元组解析代价远高于关系数据库，对数据分析领域来说，连接是关键操作（如传统的星型查询和雪花查询均是依赖于连接来处理查询），但MapReduce处理连接的性能尤其不尽如人意，原因在于MapReduce最初是针对单数据集设计的处理模型，而连接操作往往涉及多个数据集，在利用MapReduce实现连接时，最直接的方式是每个任务执行一个属性上的连接操作，然后将多个MapReduce任务通过物化的中间结果串接起来，这种实现方式往往涉及中间结果的读写，从而导致大量的Ｉ／Ｏ操作和网络传输。
6） 数据导入
在海量数据导入方面，hadoop比并行数据库更高效。因为并行数据库需要先把数据装载到数据库中，按特定的格式存储成特定的页文件，然后才能查询。而基于Hadoop平台的数据分析，无需复杂的数据预处理和写入数据库的过程，而是可以直接基于平面文件进行分析，同时hadoop支持多种文件格式，并且可以使用用户定制的格式实现)，这样大大节省了数据导入的开销。同时hadoop能够导入非结构化数据，这为空间元数据和非结构化数据进行关系分析提供了保障。
2.3 分布实时查询
1） 缓存数据：根据用户日志，通过数据挖掘算法，用hadoop分析出热点查询数据，然后将分析结果存入数据库中，以便用户查询。
2） 如果查询的数据不在缓存数据库中，通过发布查询各个数据节点，因为是在海量数据下进行发布式查询，需要解决以下问题：
有状态的查询：大数据环境下需要实时获取各个数据节点的查询状态；
容错性查询：部分节点查询失效时，只需要重做该节点的查询任务，无需重做整查询任务，提供系统容错性；
查询优先调度策略：先查到的结果先返回；
中断查询：如果某个节点长时间没返回查询结果，可中断该节点上的查询任务。
2.4 对外服务接口
对外接口可以采用OGC的CSW目录服务接口，实现接口的标准化服务。
3 Clearinghouse架构设计
综合上述分析关系数据库和Hadoop各自的优缺点，我们可以利用数据库的高效查询性能，实现Clearinghouse的分布实时查询；利用Hadoop的数据处理能力，实现数据的深度分析。基于此，设计的大数据环境下的Clearinghouse架构如下：
Clearinghouse系统架构