大规模数据库范文（精选10篇）
大规模数据库 第1篇
随着国产化战略的发展,“自主可控、 安全可信、高效可用”的国产信息化产品已逐步在政府、事业单位等机构进行全面使用,而在国产化推进进程中,如何实现主流数据库中的历史数据向国产化数据库的迁移成为推进过程中的难点,也制约着部分机构推进国产化的积极性。 本文描述迁移前的模型对比、策略和方法的选择及迁移工具准备,详细介绍了Oracle数据向国产数据库迁移的准备、转换、校验各阶段,并就数据迁移后的性能、系统的调优工作给出了建议。
2 研究向国产数据库迁移的必要性
2.1 国家信息安全的要求
随着国家信息化的建设, 我国软件业虽然发展很快,但基础软件仍被外国公司控制,就数据库产品,国外产品当前的市场占有率在95%以上,这种情况存在着严重的安全隐患。 如“棱镜门”事件,如果这类基础软件被外国控制,那我国的信息系统、网络系统在外国信息监控计划面前几乎没有防御能力。 因此,国家提出了“核高基“重大科技专项课题,要以国产可靠基础软件替换国外软件,在这个项目中把Oracle数据向国产数据库迁移是重要组成部分。 所以说,研究向国产数据库迁移是国家信息安全的要求。
2.2 打破国外垄断的重要条件
目前在国内商用市场, 特别是金融和通信领域,商用数据库Oracle和DB2处于垄断地位, 其中Oracle占了大部分的市场。 Oracle进入国内市场较早,有先入为主的优势,同时在技术上不断创新奠定了Oracle的领先地位。 国产数据库软件行业已有一定发展,如达梦,神州通用、人大金仓等均具有自主知识产权,且已应用于国民经济的诸多行业,成熟度较高。 软件基础已经具备,那下一步需要研究怎么实现大规模的把Oracle数据向国产数据库迁移,这是打破国外垄断的重要条件。
2.3 促进国产软件产业链发展的必要条件
我国国产软件产业链发展缓慢的原因主要有两点:第一,由于我国软件行业起步较晚,国内市场已被进口软件垄断了,造成国内基础软件的市场需求很小,很难进一步发展;第二,国外基础软件公司利用其垄断地位制定行业标准,并与国外基础硬件形成产业联盟,为国产数据库软件进入行业设置了门槛,如我国金融行业的信息系统基本上被IBM、Oracle和EMC三家所控制,被称之为“IOE”依赖症。国内基础软件的发展,特别是数据库基础软件的发展,能形成和促进国内的软件产业链的发展,实现“去IOE”。 但是,如何保证数据安全完整的从国外数据库迁移到国产数据库上, 是难以避开的难题,这是发展国产数据库、促进国产软件产业链发展的必要条件。
3 数据迁移的技术前提
3.1 数据迁移前的对比分析
对原Oracle数据库与国产数据库分析的目的在于了解数据模型,判断数据迁移的工作量及确定迁移工作的重点和方案,主要包括一些内容。
(1)原Oracle数据库的相关信息 ,包括其后台的操作系统、数据库的版本、前台的开发模式、应用系统常用的接口、运行的中间件环境、应用涉及到的库数量及之间的关系等等。
(2)涉及的数据类型 ,常规的如CHAR、VARCHAR等,这些各种国产数据库一般都支持。 如果系统用到了如日期、时间、文本、图像等类型时,在做数据迁移的时候要注意Oracle与国产数据库之间的差异,主要关注长度 、精度 、标度信息 ,有时候需要 做些类型 转换 ,如在Oracle中的VARCHAR(8000), 在达梦数据库中可考虑将其转换成TEXT类型或采用16KB以上的建库模式加以解决。
(3)注意表的定义信息 ,主要是关注自定义的数据类型、 自定义的缺省值。 如Oracle数据库可使用create type的语句创建自定义的数据类型和自定义的缺省值 ,而使用国产数据库(如达梦)的DTS工具无法将这些信息转换出来,需要在原系统中查找。
(4)原Oracle数据库中是否使用到了视图 、存储过程、存储函数、触发器、序列等;如果没有使用到这些,则比较简单,主要进行纯数据的迁移;如果用到了这些,且数量较多,则数据迁移工作将主要是脚本的迁移转换工作。
(5)原Oracle数据库是否用到了系统字典 ,因各数据库的系统字典格式和内容均不一样,这时候需要分析原数据库的系统字典的涵义,再根据使用的实际情况作相应的手工处理。
(6)是否有其它的特别的要求 ,如安全控制 、双机热备、数据同步等,如果有这些要求,这些要求也要加到数据迁移工作的重点和难点中。
3.2 数据迁移的策略和方法
数据迁移的方法主要有三种, 一种系统升级前通过手工的方式录入, 另外一种是系统升级前通过工具进行迁移, 最后一种是系统升级完成后, 在新系统中生成所要的数据。 目前, 最主要的数据迁移方式还是通过工具进行数据迁移, 通过计算机工具来对数据进行清洗和规范化, 同时搭配另外两种方式进行处理, 大量数据通过工具迁移, 少量数据通过手工和系统生成, 这样即可以保证数据迁移的效率, 同时又保证了数据迁移的质量。
Oracle数据库向国产数据库的数据迁移工作主要是脚本的移植和纯数据的迁移工作。 一般采用的顺序是先进性脚本的移植,再进行纯数据的迁移,这样做的好处主要有几点:1) 整理好脚本之后, 便于快速搭建移植环境;2) 有了脚本文件,能够对系统有一个整体的了解,便于对系统的把握;3) 容易进行相应的特殊处理, 如缺省值、类型、主键、外键等的处理;4) 便于存储模块的移植;5) 便于优化系统等。
3.3 数据迁移工具的准备
数据迁移的工作原本就具有复杂、 工作量大的特点, 尤其是面对大规模的Oracle数据向国产数据库迁移,难度更大。 海量的数据靠人工执行各种各样的脚本来完成数据迁移是难以想象的,出错的风险非常高。 同时当数据迁移出错时,查找问题变得非常困难。 所以使用迁移工具来完成可以极大的降低风险,提高效率。 目前主流的国产数据库都已经开发出各自的数据迁移工具,支持从Oracle迁移数据,包括表结构、数据、主键、外键、索引以及视图等的迁移,如达梦DM数据库DTS数据迁移工具,人大金仓的Kingbase数据库的JDTS迁移工具等。 数据迁移工具必须具备完整性、可扩展性、可移植性、并发性的特点。 但在使用迁移工具之前需测试工具是否满足项目要求,如一些国产数据库自带的迁移工具在处理大体量的数据时会出现数据丢失和效率低下的问题,这种情况可从第三方迁移工具中挑选合适的工具,合理有效地利用迁移工具可以事半功倍。
4 Oracle 数据向国产数据库迁移迁移流程
大规模Oracle数据向国产数据库迁移的流程可分为三个阶段:准备阶段、转换阶段以及校验阶段,如图1所示。
4.1 准备阶段
首先搭建系统环境,包括原系统运行环境和新系统环境,便于后续开展迁移工作。 其次,一方面对比新旧系统的数据库的表结构及数据字典,把Oracle数据库的数据与国产数据库系统数据作差异化分析,将它们之间的映射关系找出来, 并且制定新旧数据的转换规则; 另一方面分析应用系统的数据库操作代码,根据数据库的差异调整代码。
4.2 转换阶段
Oracle数据库中的数据不是一提取出来就可以直接导入到国产数据库的, 而是需要一系列的变换、运算,才能成为国产数据库中的数据。 所以第二步根据提取出来的新旧系统映射关系, 利用数据迁移工具把Oracle数据经过数据抽取,多次转换之后,生成中间数据,同时移植应用系统到新的系统平台上。
4.3 校验阶段
在数据迁移完成后, 对数据的校验和测试分别从两个方面展开; 一是对迁移后数据库的校验, 主要包括完整性检查( 检查外键约束是否存在) 、一致性检查( 检查相同含义的数据在不同位置的值是否一致) 、 记录条数检查( 检查新旧数据库对应的记录条数是否一致) 、特殊样本数据的检查( 检查同一样本在新旧数据库中是否一致) ;二是检查国产数据库系统运行是否正常,进行数据一致性测试、执行功能测试、性能测试、数据备份和恢复测试等。 这两个方面校验的结果是判断国产数据库系统内能否正式启用的重要依据。
在应用系统迁移完成后,对应用系统的校验和测试同样从两个方面展开:一是对功能的校验,验证系统是否能正常运行,功能点是否都能实现,执行结果是否正确等;二是进行性能测试,找出运行缓慢的功能点,并进行针对性的优化处理。
5 数据迁移后的调优工作
5.1 数据迁移后的性能调优
对于数据迁移后查询效率变低的问题,需要对国产数据库系统做性能优化。 可跟踪系统实际运行的SQL语句,分析SQL语句组成、功能和相关的表,建立合适的索引一般能解决性能问题;如有必要,也可采用改写等价SQL语句的方法进行。 SQL优化主要包括几个方面:(1) 在合适的地方建立适当的索引;(2)IN,NOT IN,<> 等操作符的转换 ; (3)OR的优化 ; (4)IN到EXISTS的转换;(5)只查询用的列等。
5.2 数据迁移后的系统调优
在数据成功迁移后, 为保证国产数据库能平稳运行,还应该对其进行系统测试,测试内容至少包括数据库系统可用性测试,数据库系统综合压力测试,数据库系统性能测试,数据库系统健壮性测试。 在投入运行前应进行一定 周期的模 拟运行和试运行,并建立相关的测试报告。 根据系统测试报告,对国产数据库硬件的配置和各种 数据库参 数的配置进行优化,这也是影响国产数据库 性能的重 要源头之一。
国产数据库的硬件配置调优,主要包括CPU、内存、I/O的配置, 需要根据运行状况提高配置或者优化资源分配。 对国产数据库参数的调优,主要包括数据缓冲区、共享池、日志缓冲区、数据库块大小等参数,需要根据处理事务的类型调整各参数大小,以提高运行速度。
6 结束语
大规模数据库 第2篇
利用虛拟化技术，能够实现大规模廉价计算平台，将存储、应用程序、网络、计算等资源作为虛拟化实体。对闲散的计算资源进行抽象，使之形成相互之间完全独立的虛拟服务器实例，从而独立的完成数据处理和计算。通过这种方式，就能够实现底层硬件的虛拟化。构建可扩展计算节点资源池，并在其中实现集成管理虛拟计算流程和计算节点。这样，大规模数据子处理任务就能够完成实时迁移、资源转换、系统监控和任务部署。
建设大规模计算平台的过程，也是云计算环境下大规模数据处理的一个重要步骤。具体来说，首先要对数据处理需要的资源进行参数化的配置，根据相应的.要求进行定制。通过这一过程，用户能够获取自己需要的资源。在不同的操作模式下为用户提供参数服务。在设置参数完成定制之后，以此为基础，在大规模数据处理的时候，部署存储和计算资源，设定计算流程和数据处理方案。将相关参数设置信息在存储和计算资源的配置文件当中进行写入之后，以此对计算流程进行分配，从而在计算节点中启动相关的资源，并且管理和部署计算节点的定制处理服务。
部署工具通过网络连接到目标计算节点和计算流程，然后执行大规模数据处理方案。然后根据相应的方案，通过代码对存储和计算资源进行分配和执行。将部署在计算节点进行进行启动，利用网络在各个计算节点发送数据处理命令，从而完成调度和部署计算流程的工作。
1.2Map Reduce技术的支持
采用Map Reduce分布式和并行式编程模型，从而在模型内部对任务容错处理、计算节点负载均衡、空间局部性优化、并行任务调度等方加以实现。在Map Reduce的开发过程中，只需对Map、Reduce两个接口进行定义，通过计算机集群，对用户编写程序进行运行，拆分大规模数据集合，使之形成若干数据片段，从而得到一系列键值对[4]。然后向一个Map任务中分配一个数据片段，在Map Reduce框架下，向大规模计算集群中的节点进行子任务的分配。最后，结合得到的键值对进行计算，生成键值对集合，向Reduce当中进行输出。
大规模数据库 第3篇
中国工程院院士邬贺铨说，随着社交网络的逐渐成熟、移动带宽迅速提升，更多的传感设备、移动终端接入网络，产生的数据及其增长速度比历史上任何时期都要多，互联网上的数据流量正在迅猛增长。邬贺铨认为，在云计算、物联网等技术的带动下，中国的移动互联网已经步入“大数据”时代。继云计算后，大数据成为信息技术领域最为热门的概念之一。
信息技术的发展推动人与自然之间的信息沟通方式的发展，因此人们生活的环境将越来越具备“智慧”特征，人们也将能更“智慧”地利用信息，对世界和他人做出更加“智慧”的判断与回应。而智慧城市的发展是城市信息化发展的新阶段，只有确立了“智慧来自大数据”的核心共识，推进智慧城市建设才能够达到“四两拨千斤”的效果。
大规模数据库 第4篇
数据挖掘(Data Mining)主要是指在大型数据库中从大量的原始数据中挖掘出一些具有未知潜在应用价值的信息。数据挖掘是解决信息技术迅速发展下数据丰富而信息匮乏的一种有效解决方式。在众多的数据挖掘方法中关联规则是一种比较重要的挖掘技术方式,对关联规则挖掘算法——Aprion算法进行详细分析,进一步研究大规模数据库关联规则挖掘的技术,促进数据库挖掘技术的发展。
1 Aprion算法概述
数据关联是信息技术发展模式下各种软件数据库中存在的一纵横能够反映一个或其他事件之间依赖性和关联性的一种信息。2 个或者2 个以上的数据之间存在的一种规律性,通过对这种规律性的分析,建立数据关联规则,进而挖掘出隐藏在数据之间的相互关系,并将这种关联进行有效分析。而关联规则挖掘Aprion算法是一种比较全面的分析模式算法,它能够发现记录中不同数据属性之间的关联性,而且能够反映出给定数据集中特征属相鉴定的关联性,发现每条信息记录中不同特征属相之间的相互依赖关系。可以说Aprion算法是一种最经典、最具影响力的关联规则挖掘算法。
Aprion算法主要计算模式原理是利用一种称作逐层迭代的候选集进行测试的一种定点,利用频繁k项集搜索候选(k+1)项集。产生1-频繁项目集L1,而后是2-频繁项目集L2,一直到不能再扩展频繁项目集的元素数据时才会停止算法;在Aprion算法的第k次循环中会产生k-候选项目集的集合Ck,而后实施数据库扫描程序,以便生成支持度并测试产生k-候选项目集Lk,利用频繁项目集产生关联规则。然后结合频繁项目集的向下封闭性特点实施进一步的分析,这就是常说的频繁项目集,同时也正是因为这个特点使得Aprion算法产生一种检验方法使分析过程中的数据进行有效压缩,无限缩小候选集,提高Aprion算法性能。
Aprion算法在计算的过程中使用逐层搜索方法,k项集主要用于探索(k+1)-项集。在这个算法分析过程中首先找到频繁1-项集,然后找到频繁2-项集集合,以此类推便能够有效提高Aprion算法的分析效率,压缩其搜索空间。Aprion算法的性质主要表现在以下几个方面:
(1)如果项集I不能够满足最小支持度阈值,那么I不是频繁的,只有I出现频繁的频率时才被看做是其性质的一种表现;
(2)如果项A被添加到项I中,项I会生成一种项集IUA的集合项,IUA项也不是频繁的,此性质属于反单调性质,也就是说如果一个集合不能通过测试,那么它所有的超集也不能通过相同的测试。
这种算法具有较高的效能性,能够利用大项集合的封闭性达到缩小计算最小支持度频繁项集数量的目的,也就是说具有避免计算不可能成为大项集的数量和候选集项,进而促进算法效能的提高。
2 Aprion算法比较分析
Aprion算法在数据分析的过程中能够产生大量的项集,而且在分析的过程中需要重复扫描数据库信息,其他算法在数据库信息分析中一般采取分而治之的策略,然后将数据库压缩到频繁模式树中,将其分为条件数据库,以便减少后续数据扫描时间,同时又能够采取频繁模式增长的方法将候选项集剔除在外,以便使其挖掘过程数据库中不存在新事务和需要解决的问题。
另外,通过对数据库信息中典型数据集的分析和实验,并进行相应的结果对比分析,发现对一些比较稀疏的数据集来说,数据挖掘分析中要求的最小支持度比0.2稍微大些,或者对于一些稠密的数据集在分析的过程中要求其支持度大于0.5,这种情况下采用Aprion算法比较合适,如果支持度不在这个范围内可以考虑其他形式算法的实施,以便最大限度的提高数据库分析效能。
3 关联分析规则的应用
3.1 数据关联规则的生成
数据挖掘工具中有很多集成了典型数据挖掘算法的模型,Aprion算法是其中之一,这种模型算法可以通过设置不同的最小置信度/支持度和关联规模。制定事务项属性在关联规则中的位置,进而优化关联规则。所以Aprion算法应用于关联数据的挖掘中能够有效提高算法效率。
3.2 算法应用举例分析
比如分析一个病例关联数据,首先针对病例系统产生的数据事务建立病例数据关联模型,然后过滤病历号、姓名等对疾病无关紧要的数据,然后剔除嗜烟嗜酒等对病例关联性不强的数据,然后将左侧设置为诊断外事项,将右侧设置为最后诊断之间的关联规则和因素。这时产生的关联规则数据比较多,但是有很多规则价值性不大;必须通过模型进行重新设置,增加最小支持度和最小置信度,此时事务数据库中最小支持度和最小置信度分别为40%,60%,如表1 所示,然后根据以上数据库生成FP-tree。
然后根据数据集设置最小置信度和最小支持度,这时会得到一个关联规则数量分析表,如表2 所示。
%
由表2 可以得到图1,图1 能够比较直观地表示数据关联中最小置信度和最小支持度之间的数据规律,图中横坐标代表最小置信度,纵坐标代表最小支持度。从图1 中可以得出:最小支持度和最小置信度比较小时产生的关联规则数据比较多,随着这两个数据的增大,关联规则数量逐渐减小。
4 结语
在当今这个大数据信息量时代,数据挖掘技术显得尤为重要,挖掘方法也比较多,但是必须选择合适的挖掘方法,提高数据挖掘效率,在数据关联性分析过程中要充分利用Aprion算法,使数据挖掘的效率提高。
参考文献
[1]王祥瑞.数据挖掘技术中关联规则挖掘的应用研究[J].煤炭技术,2011,30(8):205-207.
[2]于延,王建华,付伟,等.基于改进的Apriori算法的入侵检测系统研究[J].计算机工程与科学,2010,32(9):23-26.
[3]张梅峰,张建伟,张新敬,等.基于Apriori的有效关联规则挖掘算法的研究[J].计算机工程与应用,2003,39(19):196-198.
[4]蓝祺花.动态的关联规则挖掘算法研究[D].厦门:厦门大学,2009.
[5]丁艳辉.大规模数据库关联规则挖掘算法研究[D].济南:山东师范大学,2007.
[6]MEYER C G,PAPASTAMATIOU Y P,HOLLAND K N.Seasonal,diel,and tidal movements of green jobfish(aprion virescens,lutjanidae)at remote Hawaiian atolls:implications for marine protected area design[J].Marine biology,2007,151(6):2133-2143.
[7]刘海蓉,闫仁武.一种改进的加权关联规则挖掘算法[J].现代电子技术,2011,34(12):51-54.
大规模数据库 第5篇
2018-08-14 20:08 来源： 人民银行网站
初步统计，7月末社会融资规模存量为187.45万亿元，同比增长10.3%。其中，对实体经济发放的人民币贷款余额为129.07万亿元，同比增长12.9%；对实体经济发放的外币贷款折合人民币余额为2.52万亿元，同比下降2%；委托贷款余额为13.07万亿元，同比下降5.4%；信托贷款余额为8.23万亿元，同比增长6.8%；未贴现的银行承兑汇票余额为3.89万亿元，同比下降8.7%；企业债券余额为19.28万亿元，同比增长7.8%；非金融企业境内股票余额为6.92万亿元，同比增长10.5%。
从结构看，7月末对实体经济发放的人民币贷款余额占同期社会融资规模存量的68.9%，同比高1.6个百分点；对实体经济发放的外币贷款余额占比1.3%，同比低0.2个百分点；委托贷款余额占比7%，同比低1.1个百分点；信托贷款余额占比4.4%，同比低0.1个百分点；未贴现的银行承兑汇票余额占比2.1%，同比低0.4个百分点；企业债券余额占比10.3%，同比低0.2个百分点；非金融企业境内股票余额占比3.7%，同比持平。
注1：社会融资规模存量是指一定时期末（月末、季末或年末）实体经济（境内非金融企业和个人）从金融体系获得的资金余额。
注2：数据来源于中国人民银行、中国银行保险监督管理委员会、中国证券监督管理委员会、中央国债登记结算有限责任公司和银行间市场交易商协会等部门。
注3：2018年7月起，人民银行完善社会融资规模统计方法，将“存款类金融机构资产支持证券”和“贷款核销”纳入社会融资规模统计，在“其他融资”项下反映。完善后，2017年以来各月社会融资规模存量余额和可比口径同比增速如下：
表1：2017年以来各月完善后的社会融资规模存量余额
浅析大规模关联数据管理 第6篇
相对于英特网上不断增长的海量数据来说, 海量数据之间的联系显得十分薄弱, 业界越来越重视使用轻量级技术整合数据资源是过去十年一个重要发展趋势。这些轻量级的技术有个共同的目标:使用松散一体化的数据空间代替紧密一体化的数据库或分布式数据库。早期轻量级的数据资源集成方式主要基于Web协议, 使用URI (Uniform Resource Identifier) 标识数据表中的每一列, 不同数据表的列通过URI和Web协议来链接, 通过这种链接表示列之间的联系。
数据资源轻量级集成方式中, 最成功的要数蒂姆·伯纳斯-李提出的关联数据原则:
(1) 使用URI作为任何事物的标识名称, 不仅是标识文档;
(2) 使用HTTP URI, 使任何人都可以参引 (dereference) 这一全局唯一的名称;
(3) 当有人访问名称时, 以RDF形式提供有用的信息;
(4) 尽可能提供链接, 指向其他的URI, 以使人们发现更多的相关信息。
本文将集中介绍云计算环境下的大规模的关联数据管理, 即使用No SQL等云计算技术处理大规模的关联数据。一般大规模的数据或科学领域大规模的数据不在本文的讨论范围之列。
大规模关联数据管理需要解决的问题
关联数据经过多年的发展, 在很多方面出现了需要解决的问题。在很多领域的项目中, 关联数据的研究者与应用实践者展开合作, 经过研究得出:关联数据管理需要面对的急需解决的问题。结合本人对关联数据近期的研究, 认为关联数据急需解决的问题主要包括:运行硬件环境、吞吐量、数据规模及处理系统的扩展性等等, 具体如下:
1支持URIs标示
关联数据必须支持URIs作为主键 (Primary keys) 。关联数据原则的第一条规定必须使用URIs标示任何实体的名称。关联数据管理系统必须能允许使用URIs作为名称标示, 或者能够高效的将URIs标示转换为系统自己格式的标示。
2支持RDF
关联数据管理系统必须能够高效的访问RDF数据集。在LOD云中, 数据都是以RDF序列表示输出的, 因此, 系统要求能够导入RDF小规模数据集 (如RDF/XML文件) , 也能够导入大规模数据集 (大的N-Triples文件或者大的N-Quads文件) 。
3系统接口
关联数据管理系统必须提供使用HTTP协议访问的服务。经常需要使用HTTP协议访问关联数据集, 使用URIs链接访问关联数据元素等附加信息的时候也要使用HTTP协议。
4数据更新
关联数据系统必须提供便利的数据更新方式, 如, 通过HTTP协议的HTTP PUT/POST或者通过SPARQL更新语句来实现对数据集的插入和更新操作。
5检索功能
关联数据系统须提供模块化的检索子系统, 如, 可以通过SIREn (Semantic Information Retrieval Engine) 已有的文本检索系统来扩展关联数据系统的检索功能。这种检索功能对于LOD应用程序来说是很重要的, 如, Same As.org就提供了全文本的检索接口和联合参考服务的功能。
6逻辑推理
关联数据系统须支持推理能力, 如, 通过owl:same As推理出等价语句, 或者借助RDFS及OWL的其他逻辑推理框架。
7宽泛的数据处理功能
关联数据管理系统须提供便利的查询功能。查询的范围根据实际应用程序功能及可扩展性的需求而定, 包括范围从简单关联数据三元组查询到复杂的连接查询及各种SPARQL查询。
几种关联数据管理系统综合比较
云计算及数据存储方面的概念及术语可以参考相关文献[1]。下面将介绍几种数据存储系统, 并比较他们在管理大规模关联数据方面的能力。
1 Big Query
Big Query是有Google提供的云计算查询工具, Big Query主要是为了弥补Map Reduce在交互查询处理方面的不足, 在2010年, 由Google连同Google存储及Google预测API一起推出的。2010年后可以利用Big Query Endpoint来进行关联数据的查询处理, Big Query Endpoint是基于GAE平台 (Google App Engine) 的, 首先将RDF/N-Triples数据载入到Google存储系统中, 然后再是用Big Query Endpoint进行查询。
2 Hapood/Pig
Apache Hadoop是使用Java编写的软件框架, 它能提供可靠的、可扩展的分布式计算。Apache Pig是一种基于Hadoop/Mapreduce编程框架的高级数据分析语言。
3 HBase
Apache HBase是一种分布式、基于列的数据存储模型, 也是使用Java编写的, 采用了Google’Bigtable的实现原理。Mendeley、Facebook、Adobe等公司使用HBase存储模型。
4其他系统
还有一系列其他系统都能够在云环境下管理关联数据, 但是这些系统的云部署或其它特征在实际应用是不可行, 如, Neo4j、Microsoft’s Trinity、Golden Orbit、Monet DB、Sindice等系统。
以上这些系统中, 有的系统需要首先将RDF三元组结构转换成键值对的存储结构, 有的系统注重于优化数据的连接处理能力。另外, 有的系统已经很成熟, 提供了插入、更新和查询的用户界面, 而有的系统还处于原型研究阶段, 还需进一步完善。
总结及展望
大规模数据比对的新型实现方法 第7篇
MapReduce适合于处理TB级或PB级的数据处理,因此对于目前信息爆炸的时代,我们有些利用传统的方法无法解决或者需要很长计算时间才能得出结果的问题需要引进MapReduce的方法进行处理。MapReduce把解决问题分成两个不同的步骤:
Map:初始化数据的读入和转换,在此期间,框架对互不依赖的输入记录进行并行处理。
Reduce:处理数据的组合和抽样,有关联的数据必须通过一个模块进行集中处理。
Map任务首先并行的对每一块进行单独的处理。这些逻辑块的处理结果会被重新组合成不同的排序的集合,这些集合最后由Reduce任务进行处理。图1是MapReduce的处理模型。
一个Map任务可以执行在集群中的任何一个计算机节点上。多个Map任务可以并行的执行在集群中的多个节点上。Map任务负责转换输入记录成为名值对。所有Map任务的输出会被重新组合成多个排序的集合,这里面的每一个排序的集合会被派发给一个单独的Reduce任务。Reduce任务会对集合中排序的关键词和关联在关键词的多个数据值进行处理。Reduce任务也是并行的运行在集群中的不同节点上的[2]。
目前在很多实际应用中,需要处理大量的比对任务,传统的解决方案是利用大型成熟关系型数据库在小型机上进行数据关联运算,目前,数据比对分前台比对与后台比对,但是比对方案都是利用了关系型数据库的关系运算来实现。如图2所示。
如图2所示,传统的比对算法将待比对的数据源中的数据表抽取到中间临时的比对数据库中,然后根据所需要比对的字段(Table1的value和Table2的value)进行是否相同的比对,比对的最终结果是保存在比对结果表中(Tableresult)。如上图中比对经过,计算机需要将其中一张表的所有的value值与另外一张表的value值进行比对,计算次数为Table1和Table2的被比对字段记录数的乘积,该方法可以通过数据库优化的方式实现,例如添加被比对列的索引和分区来实现,但是并不是所有的被比对列都已经加了索引和分区,如果需要临时加则索引和分区的创建时间更长。因此在遇到大的数据量比对的情况下,传统的比对方式显然力不从心,因为在传统的方式下,一个比对任务一般是由一个进程完成,在一个进程里利用的cpu仅仅是一个,因此不管是计算量多大,都考验着这个cpu的计算能力和相应的内存、I/O等,整个比对进程的执行时间是与被比对的数据量大小成正比的,如果想提高计算速度只能提高cpu的运算能力以及相关内存大小以及I/O的吞吐能力,如果其中一个速度慢则称为整个计算速度的瓶颈。
因此在数据量越来越大的情况下,比对运算单靠一个cpu已经无法满足实际需要,因此要引入成熟的并行计算框架,让比对任务分成多份,由多个cpu或多台机器实现相应的比对功能。Mapreduce正是为我们提供了这样一个成熟的计算框架,使我们的运算可以在多台机器上并行,最终使这些机器实现我们大规模数据的比对运算。
1)在AB两个库里面的key值分别加上’A’和‘B’标记,这里是做map的过程,然后将两个库比对的数据进行汇总,把两个库的所有记录统一作为Map的输入。
2)然后将整理好的记录汇总表分割成若干小片,小片的大小以数据总量和需要进行并行计算的cpu来看。
3)上述的多个分割程序中的一个称之为master,其余的拷贝由Master赋予work,有称之为M的map任务和称之为R的Reduce任务。master将唤醒空闲状态的work线程,并赋予其map任务或Reduce任务。
4)每个map任务还根据自己的value对各自的记录进行排序。
5)reduce线程对经过排序的中间数据进行迭代遍历,将其遇到的每一个value值传送给用户定义的reduce功能,附带传送该键所对应的值的集合。
6)当所有的map任务和reduce任务全部结束,master将唤醒用户程序,经过集合好的数据重新整理如果两个记录同时又相同的value的则进行数据转换操作,最终形成比对结果。
(1)合并记录,如图3所示。
(2)分割作MAP标记,如图4所示。
(3)分别进行排序操作,以及进行REDUCE聚合,如图5所示。
遍历整个记录并进行结果重组,如图所示。
在实际应用中,往往是仅要输出某一种数据源的结果,则可以将输出再做一次MapReduce操作,即将数据源本身作为map标记,然后根据记录的value值进行分割操作,在每一个map里面做value的count操作,将count值更换原先的value值,然后根据将count值大于1的通过reduce操作输出出来,然后根据需要输出的数据源标记判定比对完成的数据源。
我们的数据如今大多存储在传统关系型数据库中,因此当用户程序调用MapReduce时,不是直接读取我们现有的数据库数据,而是通过一下几步完成整个计算:
1)将关系型数据库需要比对的数据按照MapReduce的要求导成一定格式的文件。
2)MapReduce首先将输入文件分割成M个小片,大小从16M到64M不等。
3)上述的多个集群节点的一个称之为master,其余的拷贝由Master赋予任务,有称之为M的map任务和称之为R的Reduce任务。master将唤醒空闲状态的线程,并赋予其map任务或Reduce任务。
4)被赋予了map任务的工作线程读取相应的输入分割文件的内容,并将产生的中间键值对被缓存在内存当中。
5)这些中间值会不断写到本地磁盘之上,在本地磁盘上缓存着的中间键值对的地址被传递回master,master此时通知Reduce进程通过远程调用的方式访问这些存储在磁盘上的中间键值对,并开始Reduce计算操作。
6)当所有的map任务和reduce任务全部结束,master将唤醒用户程序,用户程序将结果生成的数据文件导入再导入到关系数据库中。
通过以上方式,我们探索了在大数据量的情况下,利用现在流行的MapReduce计算框架实现对传统关系型数据库的数据的比对操作,该方法对于小规模数据比对的速度提升并不明显,因为其在数据比对过程中穿插做map和reduce操作,消耗了一定的cpu工作时,另外还会消耗部分的I/O操作,但是对于大规模数据比对,在一般串行计算的比对操作主要cpu工作时都在数据比较的情况下,该种并行计算框架随着参与计算的服务器的数量的增多则可以提供较快的比对输出结果。该种方式在对于跨节点的内存数据访问如果能够突破的话,则更加能够加快数据计算速度。
摘要：MapReduce是一个“与处理以及生成大量数据集相关联的”程序模型。程序员用这种风格的程序写出的代码可以自动并行。运行时系统关注输入数据的分区,通过一系列机器的集合来规划程序的执行,处理程序失效以及把控必要的系统内部交互。详细描述了通过MapReduce框架实现传统应用的过程。
关键词：MapReduce,云计算,比对
参考文献
[1]Valiant L G.A bridging model for parallel of the ACM,1997,33(8):103-111.
大规模数据库 第8篇
Hadoop是基于分布式文件系统HDFS和Map Reduce计算框架的大数据处理工具, 用于在廉价硬件上构造分布式系统, 并具有较高的容错性和伸缩性, 是分析海量数据的首选工具。
1.1 Map Reduce
Map Reduce的价值在于, 它抽象出了海量数据分析的一种通用模型, 即“分解——合并”的编程模型。在大规模数据分别存储于不同的机器的前提下, 让这些机器各自处理自己的一小部分数据, 最后将这些机器的结果进行整合, 得到最终结果。Map Reduce计算过程分为Map过程和Reduce过程, 处理方法分别由程序员写成map () 函数和reduce () 函数, 前者负责将原始数据“切片”, 整理成<key, value>形式的中间结果, 后者接收这些中间数据, 将其整合成最终结果。
1.2 HDFS
HDFS (分布式文件系统) 为Map Reduce提供了文件操作和存储支持, 具有高度的容错性。文件分块 (block) 存储在不同机器上。HDFS采用“主从”架构, 一个HDFS集群由一个Name Node (名字节点) 和多个Data Node (数据节点) 组成, 一个节点一般只运行一个Name Node进程或者Data Node进程。Name Node是“主”, 负责文件系统的命名空间和控制客户端的访问, Data Node是“从”, 负责响应客户端的读写请求。为了容错, 每一个block都会有多个副本, 并且存储在其他节点上, 防止本机突然失效时不会丢失数据。
1.3 大规模数据排序
排序算法是计算机领域的重要研究问题, 常用的排序算法有希尔排序、快速排序、基数排序等, 其中公认的综合性能较好的是快速排序。但随着数据规模的快速增加, 在单机上运行简单的排序程序已经无法满足大规模数据所要求的时间性能。所以, 在处理大规模数据的平台上实现高效的排序算法, 是十分必要的。
2 实验环境搭建
由于实验条件的限制, 本实验采用Hadoop伪分布式的硬件环境进行验证。Hadoop版本为0.20.0, JDK版本为1.6。
处理器:Intel (R) Core (TM) i5-3317U CPU@1.70GHz1.70 GHz
内存:4.00 GB
操作系统:Cent Os 6.5
开发工具:Eclipse
测试数据:均为50000以内的随机数
3 单个关键字简单排序
3.1 算法描述与实现
单个关键字简单排序的基本思想为:将关键字本身作为map过程后的key值, 利用Hadoop本身自带的对key的排序过程, 使其自动排序。在reduce阶段中将map后的key作为value输出。由此写出Map函数和Reduce函数, 以下是关键代码:
3.2 性能分析
为了分析上述算法的时间性能, 与相同环境下的快速排序作比较, 结果如表1所示。
根据Hadoop原理可知, Hadoop对于处理小规模数据并没有明显优势, 它更适合处理以P或T为单位的大规模数据, 而与快速排序的对比也验证了这一点。随着数据量按指数增大, Hadoop平台下的排序算法在时间上取得了明显优势。由此可以得出结论, Hadoop平台上的单个关键字排序算法在时间上优于单机模式下的快速排序算法。
4 多次排序
对单个关键字的排序在很多情况下不能满足用户的需求, 例如, 对学生的期末成绩进行排序, 一条待排记录包含以下几项:语文、数学、英语、总分及平均分, 要求先对所有学生的平均分进行由大到小的排序, 平均分相同的记录按照总分由大到小排序, 以此类推, 还有三次排序、四次排序……本文将以二次排序为例分析算法, 多次排序与二次排序大致相同, 稍作修改即可。
4.1 算法描述与实现
多个关键字排序算法基本思想为:将两个关键字的组合抽象成一个类型, 并且定义一个此类型的排序方法, 利用map过程解析成<<key1, key2>, key2>的形式。reduce过程之前Hadoop将调用自定义类型的排序方法进行key的排序, reduce只需要将key的两个成员输出即可。算法过程如图1所示。
首先要将自定义key封装成一个类, 并且实现Writable Comparable接口。以下是这个自定义类的关键代码:
实现自定义key类型后, 可以将将map和reduce作如下定义, 示例代码如下:
4.2 算法优化
为了提高效率, 实际开发中通常设置多个reduce, 以此为目标进行如下优化:首先将所有记录进行分区。根据第一个关键字选取几个“标杆”将数据分为几个区, 确保了第一个关键字相同的记录在同一区中。“分区”完成后, 每个reduce将会对分给自己的记录进行“分组”, 第一个关键字相同的记录属于同一组, 而第一个关键字不同的记录属于不同组。同一组的键值对, 他们的value将排序、整合到同一个list-values, 不同组的键值对只比较第一个关键字, 输出的总是某组的最后一个记录。算法流程如图2所示。
为实现这个算法, 需要定义一个分区类继承Partitioner接口和一个分组类继承Writable Comparator接口。Hadoop自带的例子Secondary Sort就是这种思想的体现, 以下是对其进行改进后的示例代码:
4.3 性能分析
对于二次排序, 更通用的处理工具是Sql Server, 对Hadoop下的二次排序和Sql Server下的二次排序进行比较, 结果如表2所示。
对以上结果分析可知, 单看时间性能这一点, 对于排序算法而言, Sql Server的性能优于Hadoop平台。这是对于400万行以下数据的实验结果, 对于更大规模数据而言, 分布式存储将是必然的选择, 而Hadoop可以构建分布式系统的特点, 是Sql Server无法取代的。
5 结语
需要说明的是, 由于条件限制, 在分析各个算法的时间性能时使用的数据, 其规模远远不及真正意义上的“大规模数据”。但对于验证算法正确性和分析时间性能来说, 具有一定的代表性。
本文提出的Hadoop平台下的排序方法, 时间性能明显优于单机模式下的快速排序算法, 不及Sql Server平台下的时间性能, 但易于构建分布式系统, 更适用于大规模数据。
摘要：本文在对Hadoop平台上的分布式文件系统HDFS和计算模型Map Reduce进行深入分析和研究的基础上, 提出了对单个关键字和对多个关键字的大数据排序方法, 给出了排序算法的描述、Hadoop平台上的实现和性能分析。实验结果表明, Hadoop平台下的排序算法更适用于大规模数据排序。
关键词：排序算法,Hadoop Map Reduce,大规模数据
参考文献
[1]Tom White.Hadoop权威指南[M].第2版.北京:清华大学出版社, 2011:15-18.
大规模数据库 第9篇
目前, 社区问答服务包含了大量用户生成内容 (usergenerated contents, 简记为UGC) 。以Yahoo!Answers为例, 目前Yahoo!Answers包含问题涵盖26大类、1 400多小类, 共有超过3亿规模的问题和10亿的答案由用户提出和发布。如此庞大的数据规模, 促进了非事实问答研究的大规模开展, 使得问答系统不再局限于对应命名实体、日期等较短答案的事实类问题上。
这些用户生成内容不仅具有海量、多样性等特点, 还有着高质量和重用的价值, 充分利用这些资源可以高效、准确地满足人们对信息的需求。如Liu等[1]研究的发现, 在Yahoo!Answers中的四个流行问题分类中, 有接近83%的最佳答案可以重用来回答相似的问题。
因此, 随着各类问题数据的积累与各项相关技术的成熟, 研究面向大规模问答数据的问题检索方法, 是一个既具研究挑战又有应用前景的重要技术课题。
全文共分为五部分, 其内容具体安排为:第一部分引言, 介绍面向问答社区的问题检索课题的研究背景和研究意义。第二部分介绍相关领域的研究现状。第三部分介绍问题检索的模型与特征选择。第四部分介绍实验和结果分析。最后第五部分是本文的结论和对下一步研究的展望。
1 相关工作
问题检索依赖于已经建立的问答对数据集, 对于给定的查询问句, 自动返回相关的问题及其对应答案。问题检索任务的主要挑战是如何解决已有问题和查询问句的词语不匹配问题, 因为多数情况下查询问句和问题句并不是字面上相同的。
Jeon等[2]比较了不同检索方法在解决查询问句与问题的词汇不匹配问题的效果, 所得出的统计机器翻译方法最为有效。研究中, 构造机器翻译的平行语料的方式是以问题的答案作为索引, 并用答案去查询其他相似答案。如果某问题的答案与查询答案的相似度高于一定阈值, 则认为这两个答案是相似的, 同时又假设其对应问题也是相似的。以此方法构造平行语料来训练统计机器翻译模型。基于以上工作, Xue等[3]提出一个统计机器翻译[4]加语言模型[5]的混合模型来进行问题检索, 通过利用问题句和答案作为平行语料来进行机器翻译模型的训练。Wang等[6]提出了一个基于句法树结构的新的检索方法来处理相似问题匹配任务, 可通过句法分析将问题和查询问句转化为句法树, 再通过句法树之间的相似度来衡量问题和查询问句的语义相似度。Bian等[7]提出一个新的问题检索方法GBrank以及其后续工作中的GBrank-MR都能够较好地处理事实性问题, 并给出较为满意的答案。Cao等[8]提出基于叶分类信息进行平滑的语言模型来解决词语之间的不匹配问题。该方法的基本思想是同一分类下的问题通常比不同分类下的问题更相似, 于是用同一个分类下的词分布信息对语言模型进行平滑, 如此可有效提高问题检索的相关性。Zhou等[9]考察了应用用户权威性和用户信息评价对于问题检索相关性的影响, 其结论是由于问答社区中的信息过于稀疏, 直接应用这些信息并不能够为问题的检索效果带来明显的提升。Duan等[10]应用短语级别的问题焦点和主体识别方法来提高问题检索的相关度。
2 问题检索的模型与特征选择
2.1 问题检索模型
问题检索的目的是给定一个查询问句, 系统返回与该问句语义相同或者相似的问题, 而由于同义问题语言表达的多样性特点, 仅仅对问句和问题进行词语级别的匹配是远远不够的。本文应用排序支持向量机 (Ranking SVM) 算法作为问题检索的排序模型。
在进行问题检索前, 本文应用朴素贝叶斯分类器来构建查询进行分类。这样做法的目的在于相似的问题通常会被分到同一类别当中, 对查询问句进行分类, 而且只查询与查询问句分类相同的数据就既可以提高检索的效率, 也可在一定程度上增强检索的效果。
本文利用1.2亿的Yahoo!Answers数据集训练得到的分类器, 将训练数据中的120万的Yahoo!Answers问题句作为测试数据, 可达到超过85%的预测准确率。
2.2 问题检索的特征选择
在问题检索过程中, 特征和模型的选择同样重要。为了提高问题检索过程中的词语不匹配问题的解决能力, 本文考察了大量的可用于量测字符串相似度的特征。
2.2.1 基于统计分布的特征
基于统计分布的特征是指应用社区问答数据中的所有问题的词语分布信息来调整问题中每个词语的权重信息。
词频-反向文档词频TF-IDF:很多的检索模型都是应用IDF这一指标来对词语的权重进行调整的, 如Okapi BM25和向量空间模型VSM (Vector Space Model) 。
信息熵:熵是用于表示信息不确定度的计量标注, 应用问题中的类别信息即可计算一个词语对不同类别下问题的权重贡献, 由此达到调整词权重的目的。
2.2.2 基于结构的特征
基于结构的特征是指应用查询问句和问题中的短语、词语顺序和句法结构等信息来衡量查询问句和问题相似度的特征。文中涉及的相关概念如下:
N元文法:由于存储空间和计算效率的限制, 本文只采用了二元文法Bigram。
短语:对于查询问句和问题, 可以应用组块分析技术抽取其中的名词短语NP (Noun Phrase) , 动词短语VP (Verb Phrase) 和介词短语PP (Prop Phrase) 。本文应用Jaccard相似度指标来计算短语集合的相似度。
命名实体:命名实体NE (Named Entity) 是指文本中预先定义了类别的词语或结构片段, 如人名、地名、机构名等。同样应用Jaccard相似度指标来计算命名实体的相似度。
最长公共字串和最长公共子序列:本文利用最长公共字串和子序列与问题长度的比例来衡量查询问句和问题之间的相似度。
编辑距离:编辑距离是衡量两个字符串之间差别的一个标准。由于编辑距离和两个词序列之间的相似度成反比, 故本文选取编辑距离的倒数来衡量查询问句和候选答案的相似度。
字符串核函数:本文应用了Bu等[11]提出的字符串重写核函数 (String Re-writing Kernel) 来计算查询问句和问题之间的相似度。
依存分析:依存分析 (Dependency Parsing) 是通过依存文法对语句进行句法分析生成依存句法树的过程。图1为语句“Bell, based in Los Angeles, makes and distributes electronic, computer and building products.”的依存句法树示意图。
如图1所示, 树的任意节点和其子孙节点都会形成一个依存路径 (Dependency Path) 。路径的长度为路径中节点的数量。本文中统计查询问句和问题的依存句法树中的全部长度为2的依存路径, 并加上其中的弧标签。再通过计算两个依存路径集合的相似度来得到查询问句和问题的相似度。
以上基于统计和基于结构的特征可以概括为基于词的特征, 这些特征从最简单的无结构特征 (如关键词) , 到浅层结构特征 (如N元文法、短语、命名实体等) , 再到结构化的依存句法树, 分别表示了查询文件和问题所包含的各个层面的信息。
2.2.3 基于语义的特征
为了更好地解决查询问句和问题的词语不匹配问题, 仅仅利用基于词的特征是远远不够的, 本文还考察了基于语义的特征在问题检索过程中的应用。基于语义的特征是指应用查询问句和问题的词语之外的可以表征语句的语义或语义特点的信息的特征。现将该技术中的各类方法综述如下:
(1) LML:LML应用了问题的叶节点分类信息来调整语言模型, 用以查询问句与问题之间的相似度。该方法的基本思想是:在Yahoo!Answers的分类系统中, 每个大类下面都会分为很多小类, 这些分类信息都可以通过一个树形结构形象表示, 而树中的叶子节点则代表某问题的最小分类信息, 如图2所示。
在叶节点分类中, 由于话题限定更窄, 用户更倾向于讨论相近的问题, 如果查询问句中的词在某一叶节点分类中出现的频率更高, 则该分类中的问题便极有可能和查询问句相似。
(2) 翻译语言模型:模型的关键是训练得出词到词的翻译概率, 而用于训练的、可对齐的平行语料却很难获得。本文使用基于商业搜索引擎点击数据中查询问句和网页的标题而训练得出的词到词翻译概率作为翻译模型来计算两个句子的相似度。
(3) 复述模型:复述 (Paraphrasing) 是指对相同信息的不同表达方式, 而问题检索的目的便是要找到与查询问题一样或者是查询问句的复述的问题。本文应用通过商业搜索引擎的网络查询日志而训练得出的复述模型判断查询问句和问题之间互为复述的概率。
(4) Word Net语句相似度:Word Net是英文的语义词典数据库。通过Word Net中同义词集合语义的关系, 可以应用Wu和Palmer提出的相关性公式来计算两个词之间的相关性。词a和词b在Word Net中同义词的集合关系如图3所示, 并可由如下公式计算得出:
其中, depth为树中节点的深度, Icaab为节点a和节点b的最近公共祖先。
最后, 应用查询问句和问题中每个词的Word Net相似度进行组合, 即可得到两句话间的Wordnet语义相似度。
3 实验和结果分析
3.1 训练数据与工具
3.1.1 训练工具
本文应用Joachims开发的SVMRank工具包来训练Ranking SVM排序模型, 该工具简单高效, 只需将特征文件编写成其要求的格式作为输入, 并指定误差容忍度参数c, 运行该工具即可生成模型文件和排序预测结果。
3.1.2 训练数据
为了避免出现训练得到的模型发生对训练数据过度拟合的问题, 在训练数据中需包含两个部分:训练集和调试集。分别论述如下:
(1) 训练集:选取商业搜索引擎的部分查询日志的标注数据, 所有的查询都是问题查询, 且用户输入查询后点击了Yahoo!Answers的页面。数据采用5级标注, 将标注中得分为3及以上的问题视作正例 (相关) , good以下的当作负例 (不相关) 。最后, 正负例共有29 485条。
(2) 调试集:在三百万的Yahoo!Answers数据集上随机选出200条问题, 并在剩余的数据上通过应用语言模型进行检索。每个问题取出前100个候选结果, 再对问题的相关性进行标注, 去掉找不到相关结果的问题, 最后剩余176个问题, 即正负例共有17 600条。
基于调试集依次通过比较第一项准确率 (Precision@1) , 平均准确率 (Mean Average Precision) , 平均倒数排名 (Mean Reciprocal Rank) 三个指标来选取排序模型。
3.2 实验结果与分析
3.2.1 实验数据
本文应用了两组不同的实验数据来验证问题检索方法的有效性。
(1) 从2012年上半年的商业搜索引擎查询日志中选取200条高频的查询问句和100条较长的中等频度的查询问句, 共300条查询问句。
(2) Cao等提出LML方法时用到的Yahoo!Answers的问答数据。全部数据中包含超过三百万的问题及其答案, 其中测试数据为252条查询问句。因其提供的数据同时给出了对应的每个查询问句, 应用其方法即找到相关问题。
(3) 应用上一节中提到的调试数据集对和一些传统经典信息检索模型进行对比。随机选取156个问题作为测试集, 剩余20个问题作为模型参数的调试集。
3.2.2 实验结果与分析
在搜索引擎日志查询问句数据集1中, 对每个查询问句在全部超过130亿的问题数据中进行检索, 给出10个相似度最高的问题, 然后对所有问题进行人工标注, 并计算其Precision@1, MAP和MRR三个评价指标, 实验结果如表1所示。
如表1所示, Precision@1、MAP和MRR三个指标的结果比其他的实验结果要高出很多, 这是因为该测试数据集中的查询问句主要由查询日志中的高频查询组成。应用该测试数据集的目的是为了检测本文构建的问答系统的实用性, 因为大部分用户提出的问题与查询日志中的查询问句都是一致的, 这个结果也说明本文的问答系统具有很高的实用性。
在Cao等实验数据集2中, 为了得到真实的对比效果, 本文应用其小规模的问答数据重新构建了一套检索系统, 即两种方法均是在相同的实验数据集上进行对比的。表2为实验对比结果。
在表2中, R-Prec是Cao等在评测时用到的一个评测指标R-Precision, R则指该问题有R个相关问题标注。因为其公开的数据中只有一个查询问句的相关问题, 而并未给出其方法找出的不相关问题, 就使得绝大部分的结果都是未标注的。本文结果A是指直接应用其方法找出的相关问题, 并以其作为相关问题。这样相当于将全部的未标注问题均当成不相关的进行处理, 就会对结果产生很大影响, 因此结果中, 只有MAP略高于Cao等的方法。本文结果B是对检索结果进行了补充标注, 即评测时不再包含未标注问题, 从结果中可以看出, 本文在各项指标上都要优于Cao等的方法, 而在MAP和P@5上则有明显的提高。
在人工标注的调试集3中, 本文和传统的经典信息检索模型进行了对比, 包括向量空间模型 (VSM) 、Okapi BM25语言模型 (LM) 、LML、翻译模型 (TM) 。对比结果如表3所示。
从表3可以看出, 其中LML的结果是应用本文的数据重新训练生成模型计算得到的, 这与数据集2中LML直接对照Cao等的实验结果是根本不同的。相对于传统的经典信息检索模型, 本文的方法表现了很大的优势, 在各个评测指标上都有显著提高。
4 结束语
本文应用查询问句和问题的结构信息和语义信息, 并结合排序学习算法来融合多种不同类别的特征的方法, 再应用训练数据生成排序模型来提高问题检索的相关性和词语不匹配等问题。实验表明, 本文的方法在各个数据和评价指标上都要明显优于基准方法。在接下来的研究中, 本文可利用问题检索过程中得到的问题及其答案来构造高质量的问答知识库, 以将其应用到信息检索系统和其他信息服务当中。
参考文献
[1]LIU Y, LI S, CAO Y, et al.Understanding and summarizing answers in community-based question answering services[C]//Proceedings of the 22ndInternational Conference on Computational LinguisticsVolume 1, COLING’08, Stroudsburg, PA, USA, 2008:497–504.
[2]JEON J, CROFT W B, LEE J H.Finding similar questions in large question and answer archives[C]//Proceedings of the 14thACM international conference on Information and knowledge management.ACM, 2005:84-90.
[3]XUE X, JEON J, CROFT W B.Retrieval models for question and answer archives[C]//Proceedings of the 17thACM international conference on Information and knowledge management, 2008:475–482.
[4]BERGER A, LAFFERTY J.Information retrieval as statistical translation[C]//Proceedings of the 22ndAnnual International ACM SIGIR Conference on Research and Development on Information Retrieval, 1999:222–229.
[5]PONTE J M, CROFT W B.A language modeling approach to information retrieval[C]//Proceedings of the 21stannual international ACM SIGIR conference on Research and development in information retrieval.ACM, 1998:275-281.
[6]WANG K, MING Z, CHUA T S.A syntactic tree matching approach to finding similar questions in community-based qa services[C]//Proceedings of the 32ndAnnual International ACM SIGIR Conference on Research and Development on Information Retrieval, Boston, MA, USA, 2009:187–194.
[7]BIAN J, LIU Y, AGICHTEIN E, et al.A few bad votes too many?:towards robust ranking in social media[C]//Proceedings of the 4thinternational workshop on Adversarial information retrieval on the web.ACM, 2008:53-60.
[8]CAO X, CONG G, CUI B, et al.A generalized framework of exploring category information for question retrieval in community question answer archives[C]//Proceedings of the 19thinternational conference on World wide web.ACM, 2010:201-210.
[9]ZHOU Z, LAN M, NIU Z, et al.Exploiting user profile information for answer ranking in Companion Proceedings of the 21stinternational conference companion on Pages 767-774.
[10]DUAN H, CAO Y, LIN C Y, et al.Searching questions by identifying question topic and question focus.[C]//Proceedings of 46th Annual Meeting of the Association for Computational Linguistics:Human Language Technologies (ACL:HLT) , Columbus, OH, June2008.
大规模天线下的数据传输方案研究 第10篇
随着无线通信需求的增加，为进一步提升频谱效率和增加系统的容量，在无线系统中引入大规模天线技术。大规模天线(Massive MIMO)技术，通常指基站天线数目庞大，而用户终端采用很少的天线数接收的通信方式，是未来5G通信中的重要技术。大规模天线阵列带来的巨大阵列增益和干扰抑制增益，使得小区总的频谱效率和边缘用户的频谱效率得到极大提升[1]。与现有的2、8天线相比，其天线数目可达64、128根[2,3]。在此条件下，可以综合利用无线信号的空间传输特性、用户与基站的距离(功率)、UE对无线信道的反馈等条件，确定下行数据的传输方案。
目前，3GPP(第三代合作伙伴计划)R10/R11中的多天线技术只支持最大8天线端口的水平维度波束赋形技术[4]。现有技术基于码本反馈的方案，首先需要确定出对应的层数，然后再确定出相应的码本[5]。这在大规模天线下，例如128根天线，其层数可能是1～128中的任意数值，并且每一层对应的码本个数也是相当多的，其反馈量是相当大的，UE的处理也会相当的复杂。UE反馈相应的码本以后，基站还要经过复杂的运算和处理(尤其是多个用户共同使用相同的时频资源进行MU-MIMO配对传输时)，才能确定UE的下行传输方案。因此，设计一种合理、优化的下行数据传输方案具有非常重要的意义。
1 基于子空间反馈的方案
本文设计了一种基于子空间反馈的数据传输方案，通过计算信道系数矩阵协方差矩阵最大特征值对应的特征向量，判断其与不同子空间的夹角是否在一定门限内，从而将UE划分为相同或者不同的子空间，UE将相应的子空间上报给基站，用于基站确定UE的下行传输方案，或者MU-MIMO配对算法使用。
1.1 方案设计原理
对于基站是多个天线的系统来说，可以按照以下方式进行数据的传输:
首先，按照图1分区域的方式设计下行参考信号，不同区域的参考信号占用不同的时频资源，相同区域的参考信号用不同的正交码进行区分。
如图1所示，共32个天线端口，分成A、B、C、D四个区域，不同的区域使用不同的时频资源进行区分。对于特定的某一区域，如A，在指定的时频资源上，用正交码再次区分同区域的不同的天线端口。
举例来说，A区域的8个天线端口共用图2的相同的时频资源，不同的天线端口用正交码进行区分，如图2所示。
可以采用的正交码如表1所示。
其次，UE对基站发送的下行参考信号进行测量，并且计算信道矩阵协方差矩阵最大特征值和其对应的特征向量。然后计算特征向量与子空间的夹角，根据预设的门限，判断UE是否可以划分到某个子空间。
举例来说，对于某个UE，其最大特征值为λ，并且其对应的特征向量为α=(a1,a2，…，a32)。设向量ek为第k项为1，其余项为0的行向量。
ΧA是由基向量e1,e2,e3,e4,e5,e6,e7,e8构成的子空间;
ΧB是由基向量e9,e10,e11,e12,e13,e14,e15,e16构成的子空间;
ΧC是由基向量e17,e18,e19,e20,e21,e22,e23,e24构成的子空间;
ΧD是由基向量e25,e26,e27,e28,e29,e30,e31,e32构成的子空间;
分别计算特征向量α与子空间ΧA、ΧB、ΧC、ΧD之间的夹角，取夹角中的最小值与设定的门限值进行比较(如门限值设定为70°)，如果小于门限值，则将对应的特征空间上报给基站。
设夹角为θ，计算夹角公式如式(1)所示:
举例来说，特征向量α与子空间ΧA、ΧB、ΧC、ΧD之间的夹角最小值分别为45°、80°、90°、85°，由于α与ΧA之间的夹角最小并且小于70°，则将ΧA上报给基站。
如果特征向量α与子空间ΧA、ΧB、ΧC、ΧD之间的夹角均不小于门限值，则将此结果上报给基站。
1.2 反馈信息设计
设置1个bit位表示UE的特征向量与子空间ΧA、ΧB、ΧC、ΧD之间的夹角是否小于门限值，例如1表示小于门限值，0表示所有的值均不小于门限值。
对于1的情况，紧接着用一定的bit位表示与特征向量夹角最小的子空间。例如上面的示例中，可以用2bits表示相应的子空间，具体的对应关系如表2所示。
2 下行传输方案选择
根据UE上报的结果，基站确定下行数据的传输方式。首先根据UE上报结果的第1个bit位将所有的UE划分为两个组，值为1的UE在一个组，值为0的UE在另外一个组。不同组的UE按照时分的方式进行调度(即不在同一个子帧上进行调度)。对于值为1的情况，在同一个子帧上，优先选择不同子空间的UE进行MU-MIMO配对。对于值为0的情况，可以采用下行波束赋形方案进行传输。
类似的，可以将天线的端口数目进一步的扩大，并且使用上述方法进行下行数据的传输。图3所示为128天线子空间划分图，此时，子空间划分多，MU-MIMO可配对的用户数增多。
3 结束语
对于Massive MIMO系统来说，下行传输模式的确定、多用户配对算法、波束赋形等是资源调度问题的核心研究内容。本文提出一种大规模天线系统下的数据传输方案选择方法，基于子空间反馈，可以大大减小UE反馈量，比较简单地确定下行传输方案，也比较容易进行下行多用户MIMO配对。但在实际系统中也要考虑天线数较大时，计算信道矩阵协方差矩阵最大特征值和特征向量所带来的矩阵运算复杂度问题，这在一定程度上增加了系统的延时，如何设计合理的方案还需要进一步研究。
参考文献
[1]许森,张光辉,曹磊.大规模多天线系统的技术展望[J].电信技术,2013(12):25-28.
[2]Fredrik Rusek,Thomas L,Marzetta,et al.Scaling UP MIMO:Opportunities and challenges with very large arrays[J].IEEE Signal Processing Magazine.2013-03-21.
[3]Marzetta T L.Noncooperative cellular wireless with unlimited numbers of base station antennas[J].IEEETransactions on Wireless Communication.Nov.2010,9(11):3590-3600.
[4]3 GPP TS 36.211 V11.0.0,Evolved Universal Terrestrial Radio Access(E-UTRA);Physical Channels and Modulation[S].2012-09.