基于Hadoop的Clearinghouse系统架构设计

标签: hadoop clearinghouse 系统架构 | 发表时间:2013-08-25 22:17 | 作者:zhongyangzhong
出处:http://blog.csdn.net

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采取了基于扫描的处理模式和对中间结果步步物化的执行策略,从而导致较高的I/O代价,为了减少数据预处理时间,MapReduce没有使用模式、索引、物化视图等技术手段,其数据预处理仅是一次数据加载操作,但由此导致了一个问题———较高的元组解析代价。MapReduce环境下,每个查询都是直接从文件系统中读入原始数据文件,而非传统的从数据库中读入经处理过的文件,因此其元组解析代价远高于关系数据库,对数据分析领域来说,连接是关键操作(如传统的星型查询和雪花查询均是依赖于连接来处理查询),但MapReduce处理连接的性能尤其不尽如人意,原因在于MapReduce最初是针对单数据集设计的处理模型,而连接操作往往涉及多个数据集,在利用MapReduce实现连接时,最直接的方式是每个任务执行一个属性上的连接操作,然后将多个MapReduce任务通过物化的中间结果串接起来,这种实现方式往往涉及中间结果的读写,从而导致大量的I/O操作和网络传输。

 6) 数据导入

       在海量数据导入方面,hadoop比并行数据库更高效。因为并行数据库需要先把数据装载到数据库中,按特定的格式存储成特定的页文件,然后才能查询。

而基于Hadoop平台的数据分析,无需复杂的数据预处理和写入数据库的过程,而是可以直接基于平面文件进行分析,同时hadoop支持多种文件格式,并且可以使用用户定制的格式实现),这样大大节省了数据导入的开销。同时hadoop能够导入非结构化数据,这为空间元数据和非结构化数据进行关系分析提供了保障。

2.3 分布实时查询

1) 缓存数据:根据用户日志,通过数据挖掘算法,用hadoop分析出热点查询数据,然后将分析结果存入数据库中,以便用户查询。

2) 如果查询的数据不在缓存数据库中,通过发布查询各个数据节点,因为是在海量数据下进行发布式查询,需要解决以下问题:

有状态的查询:大数据环境下需要实时获取各个数据节点的查询状态;

容错性查询:部分节点查询失效时,只需要重做该节点的查询任务,无需重做整查询任务,提供系统容错性;

查询优先调度策略:先查到的结果先返回;

中断查询:如果某个节点长时间没返回查询结果,可中断该节点上的查询任务。

2.4 对外服务接口

对外接口可以采用OGC的CSW目录服务接口,实现接口的标准化服务。

3 Clearinghouse架构设计

        综合上述分析关系数据库和Hadoop各自的优缺点,我们可以利用数据库的高效查询性能,实现Clearinghouse的分布实时查询;利用Hadoop的数据处理能力,实现数据的深度分析。基于此,设计的大数据环境下的Clearinghouse架构如下:



Clearinghouse系统架构

作者:zhongyangzhong 发表于2013-8-25 22:17:43 原文链接
阅读:88 评论:0 查看评论

相关 [hadoop clearinghouse 系统架构] 推荐:

基于Hadoop的Clearinghouse系统架构设计

- - CSDN博客架构设计推荐文章
1 Clearinghouse(数据交换中心)介绍.        Clearinghouse(数据交换中心)是随着异构组织之间共享空间数据而产生的,它的目标是建立一个虚拟空间数据机制,用来收集空间数据的元数据和发布服务,以便高效的获取空间数据,同时利用空间数据提供决策支持. 通常建立Clearinghouse的基本途径是通过一套元数据标准,收集各个组织中空间数据的元数据,通过服务接口帮助用户确定存在哪些数据,以及获取这些数据的方式等.

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.

Digg.com 的系统架构

- - 标点符
在过去的几年间,我们一直致力于重构Digg的架构,现在我们称之为“Digg V4”.本文我们将全面介绍Digg的使用的系统和技术. 首先,我们来看下Digg给大众用户提供的服务吧:. 人们通过浏览器或者其他应用来访问这些Digg服务. 一些有Digg账户的用户,可以得到“我的新闻”. 每位用户可以得到的我们称之为“热门新闻”.

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.

twitter系统架构分析

- - 企业架构 - ITeye博客
twitter系统架构分析. (一)twitter的核心业务. twitter的核心业务,在于following和be followed:. (1)following-关注. 进入个人主页,会看到你follow的人发表的留言(不超过140个字),这是following的过程;. (2)followed-被关注.

支付宝系统架构

- - 编程语言 - ITeye博客
支付宝的开源分布式消息中间件–Metamorphosis(MetaQ). Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件,类似于LinkedIn的Kafka,具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性,适用 于大吞吐量、顺序消息、广播和日志数据传输等场景,在淘宝和支付宝有着广泛的应用,现已开源.

大型网站系统架构粗探

- - 网站架构_搜搜博客搜索
  软件架构有很多种定义,下面是卡内基梅隆大学软件研究所关于软件架构的定义:.   软件架构是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计. 软件架构描述的对象是直接构成系统的抽象组件. 各个组件之间的连接则明确和相对细致地描述组件之间的通讯. 在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象.