申请/专利权人：云南大学

申请日：2017-12-26

公开（公告）日：2021-06-04

公开（公告）号：CN108121807B

主分类号：G06F16/22(20190101)

分类号：G06F16/22(20190101);G06F16/27(20190101)

优先权：

专利状态码：有效-授权

法律状态：2021.06.04#授权;2018.06.29#实质审查的生效;2018.06.05#公开

摘要：本发明公开了一种Hadoop环境下多维索引结构OBF‑Index的实现方法，对数据集进行划分得到数据分片，对每个数据分片分别创建一个OBF索引对象并序列化为OBF索引文件进行存储，构建得到OBF‑Index；在需要使用数据集时，首先设置需要使用的数据集合A，然后分别读取每个数据分片的OBF索引文件并反序列化得到OBF索引对象，利用OBF索引对象查询数据集合A中的数据是否存在于该数据分片中，如果是，则将该数据分片传递给相应的Mapper，否则不作任何操作。本发明设计了一种多维索引结构OBF‑Index，可以高效地实现创建和查询，且能有效降低假阳率。

主权项：1.一种Hadoop环境下多维索引结构OBF-Index的实现方法，其特征在于包括以下步骤：S1：对数据集进行划分得到数据分片；S2：对每个数据分片分别生成一个OBF索引文件并存储，构建得到OBF-Index，生成OBF索引文件的具体方法为：首先对数据分片进行处理，如果是一维数据则不作任何操作，如果是多维数据，将其映射为一维数据；为数据分片初始化一个OBF索引对象，该OBF索引对象中每个位置的初始值为绝对大值，依次读取数据分片的一维数据中的第n个元素an，n＝1,2,…,N，将其插入OBF索引对象，插入方法为：根据K个哈希函数hk计算得到其K个位置hkan，记位置hkan原有值为F0hkan，令第hkan个位置的值Fhkan＝min{k,F0hkan}；将得到的OBF索引对象序列化为OBF索引文件；S3：在需要使用数据集时，首先设置需要使用的数据集合A，然后分别读取每个数据分片的OBF索引文件并反序列化得到OBF索引对象，利用OBF索引对象查询数据集合A中的数据是否存在于该数据分片中，如果是，则将该数据分片传递给相应的Mapper，否则不作任何操作；查询方法为：记需要查询的数据为x，根据K个哈希函数hk计算得到K个位置hkx，记hkx对应位置的原有值为F0hkx，如果所有k≥F0hkx均为真，则该数据存在该OBF索引对象对应的数据分片中，否则不存在。

全文数据：Hadoop环境下多维索引结构OBF-1ndex的实现方法技术领域[0001]本发明属于云存储技术领域，更为具体地讲，涉及一种Hadoop环境下多维索引结构OBF-Index的实现方法。背景技术[0002]我们正生活在一个大数据时代，网络上各种类型的日志（如点击日志）、用户发布的内容如Twitter上用户发布的推文）、图数据如社交网络等都是海量数据的来源。2008年Google每天的数据量已经超过20PB，2016年阿里每天需要处理100PB以上数据、每天有100万以上的大数据任务，根本无法用单机的方式来实现这种数据量的数据处理。近些年，分布式计算、网格计算、云计算技术也日渐成熟。早在2003年和2004年Google便发表了两篇文章，向人们展示了他们为了应对海量数据处理的两项新技术GFS；GoogleFileSystem和MapReduce。[0003]Hadoop是GoogleMapReduce的一种开源实现，因为其稳定性、可扩展性以及低成本性，大到Facebook、Yahoo、阿里、百度，小到几十人的小公司或实验室都对其青睐有加。从Hadoop诞生之日起，在这十年时间里，已经从Hadoopl·0发展到现在的YARNHadoop2.0，以及Hive、HBase、ZooKeeper等配套设施，一个庞大的Hadoop生态系统正在越来越完善。[0004]以HadoopHDFSHadoop分布式文件系统）为代表的云存储系统也逐渐成为大数据处理必不可少的部分，被广泛应用到各种网络应用中，如搜索引擎、社交网络、电子商务等。云存储系统相对于传统的数据存储，正如Hadoop可以通过增加廉价机器来扩充集群一样，扩展性更强，方便存储TB、PB或更大级别的数据;并且云存储系统中，一般都采用数据的冗余备份策略来保证数据的高可用性。诸如Google最早的GFS、Facebook的Cassandra和Amazon的Dynamo等都是非常优秀的此类存储系统。[0005]这类云存储系统基本都采用基于DHT分布式哈希表）的Key-Value模型，通过Key键和Value值之间的映射关系进行数据的存储和查找。这种模型比较适合单点查询，即给定一个要查询的Key，全局扫描得到相应的Value。但是在Hadoop中，因为没有原生支持索引结构，在数据量过于庞大的时候MapReduce任务效率低下，并且对于范围查找、多维查找非常不便。[0006]在文献“TanZL，ZhouKR，ZhangH，etal·BF-MapReduce:ABloomFilterBasedEfficientLightweightSearch[C]IEEEConferenceonCollaborationandlnternetComputing.IEEE,2015:125-129.”中提出了一种基于BloomFilter的高效轻量级索引结构BF-MapReduce，通过使用此辅助索引，可以快速跳过许多无用的输入分片，避免遍历扫描整个数据集，从而提高Map阶段的效率。但是，因为BloomFilter这种概率性的数据结构会随着插入数据的越来越多，假阳率也越来越大。发明内容[0007]本发明的目的在于克服现有技术的不足，提供一种Hadoop环境下多维索引结构OBF-Index的实现方法，在高效构建索引和查询的同时，能有效降低假阳率。[0008]为实现上述发明目的，本发明Hadoop环境下多维索引结构OBF-Index的实现方法包括以下步骤：[0009]Si:对数据集进行划分得到数据分片；[0010]S2:对每个数据分片分别生成一个OBF索引文件并存储，构建得到OBF-Index，生成OBF索引文件的具体方法为:首先对数据分片进行处理，如果是一维数据则不作任何操作，如果是多维数据，将其映射为一维数据;为数据分片初始化一个OBF索引对象，该OBF索引对象中每个位置的初始值为绝对大值，依次读取数据分片的一维数据中的第η个元素an，n=1，2，…，N，将其插入OBF索引对象，插入方法为:根据K个哈希函数hk计算得到其K个位置hkan，记位置hkan原有值为Fqhkan，令第hkan个位置的值Fhkan=min{k，FQhkan};将得到的OBF索引对象序列化为OBF索引文件；[0011]S3:在需要使用数据集时，首先设置需要使用的数据集合A，然后分别读取每个数据分片的OBF索引文件并反序列化得到OBF索引对象，利用OBF索引对象查询数据集合A中的数据是否存在于该数据分片中，如果是，则将该数据分片传递给相应的Mapper，否则不作任何操作;查询方法为:记需要查询的数据为X，根据K个哈希函数hk计算得到K个位置hkX，记hkX对应位置的原有值为Ft3hkX，如果所有hkX均为真，则该数据存在该OBF索引对象对应的数据分片中，否则不存在。[0012]本发明Hadoop环境下多维索引结构OBF-Index的实现方法，对数据集进行划分得到数据分片，对每个数据分片分别构建一个OBF索引对象并序列化为OBF索引文件进行存储，构建得到OBF-Index;在需要使用数据集时，首先设置需要使用的数据集合A，然后分别读取每个数据分片的OBF索引文件并反序列化得到OBF索引对象，利用OBF索引对象查询数据集合A中的数据是否存在于该数据分片中，如果是，则将该数据分片传递给相应的Mapper，否则不作任何操作。本发明设计了一种多维索引结构OBF-Index，可以高效地实现构建和查询，且能有效降低假阳率。附图说明[0013]图1是原始的MapReduce过程示意图；[0014]图2是本发明的MapReduce过程示意图；[0015]图3是本发明Hadoop环境下多维索引结构OBF-Index的实现方法的具体实施方式流程图；[0016]图4是多维数据映射为一维数据的示例图；[0017]图5是本发明OBF索引对象中元素插入示例图；[0018]图6是本实施例中基于MapReduce生成OBF索引文件的示意图；[0019]图7是本实施例中索引环境的不意图；[0020]图8是本发明OBF-Index中元素查找示例图；[0021]图9是本发明与BF-MapReduce的假阳率对比图；[0022]图10是本发明和MapReduce、Hive有无索引）以及BF-MapReduce在不同数据集数据量下的查询速度对比图；[0023]图11是本发明和MapReduce、BF_MapReduce在不同数据集数据量下的Mapper过程时间消耗对比图；[0024]图12是本发明和MapReduce、BF-MapReduce中不同大小文件的查找效率对比图；[0025]图13是本发明OBF-Index和MapReduce、BF-MapReduce中不同数量文件的查找效率对比图；[0026]图14是本发明和Hive、BF-MapReduce中索引文件构建时间对比图。具体实施方式[0027]下面结合附图对本发明的具体实施方式进行描述，以便本领域的技术人员更好地理解本发明。需要特别提醒注意的是，在以下的描述中，当已知功能和设计的详细描述也许会淡化本发明的主要内容时，这些描述在这里将被忽略。[0028]实施例[0029]为了更好地说明本发明的技术方案，首先对本发明的思路进行简要说明。[0030]Hadoop中，通过多个Mapper和多个Reducer的并行运行来达到快速处理数据的目的。因为存储在HDFS上的数据一般都是GB、TB或以上数量级的数据，在执行一个任务时，不可能将所有数据分到一台机器上执行。因此，Hadoop在执行Map之前，首先将输入数据分成固定大小的块，得到数据分片（InputSplits，然后每个分片会被分配给一个独立的Mapper0[0031]图1是原始的MapReduce过程示意图。如图1所示，原始的MapReduce过程中，Mapper接收数据分片，Reducer在运行时往往是从相关的Mapper复制数据并处理，因此Reducer节点的资源相对Mapper要少。Hadoop中默认情况下的分片和每个分片对应一个Mapper的机制提供了一种简单的负载平衡。它假设每条记录需要的处理时间大致相等，并且每个Mapper处理的记录条数相近，那么期望运行时间会随着Mapper数量的增加而增加。换而言之，尽管每个Mapper处理固定数量的记录，但可以通过减少Mapper的数量来降低MapReduce的整体运行时间。[0032]图2是本发明的MapReduce过程示意图。如图2所示，本发明所提出的OBFOrdinalBloomFilter-Index索引）工作于InputSplits到Mapper过程中间。这是因为在一些MapReduce应用中，并不是所有分片中都包含用户所需要的有用信息，如果每个数据分片配置一个Mapper，势必会占用太多的计算资源，并且导致整个MapReduce运行时间过长。本发明所提出的OBF-Index相当于一个过滤器，只将包含目的数据的分片对应到Mapper任务，即split_2。那些不包含所需数据的分片（split_l，split_n则被过滤掉。通过这种方式可以减少Mapper的数量，即减少参与到Map或Reduce阶段的数据量，所以整个MapReduce过程的效率会有较大的提升。[0033]图3是本发明Hadoop环境下多维索引结构OBF-Index的实现方法的具体实施方式流程图。如图3所示，本发明Hadoop环境下多维索引结构OBF-Index的实现方法，其具体步骤如下。[0034]S301:数据分片：[0035]对数据集进行划分得到数据分片，记输入数据集合为D，数据分片的数量为Q，第q个数据分片记为dq，q=l，2,…，Q。[0036]S302:构建OBF-Index:[0037]对每个数据分片分别生成一个OBF索引文件并存储，构建得到OBF-Index。下面对OBF索引文件的生成方法进行详细说明。[0038]在大数据环境下很多数据都是按分隔符分隔的半结构化数据，可以看成是数据库中的表，所以这些数据是有不同维度的。而本发明在构建OBF索引对象时需要使用多个哈希函数，因此，不能简单的将一行数据一条记录直接插入到OBF索引对象中，那样的话将不能按该记录的一部分字段进行查找或多个字段组合查找多维查找）。所以需要有一种方法使得将一条记录存入OBF索引对象时保留其字段信息。因此本发明中需要在OBF索引对象构建之前对数据分片进行处理，如果是一维数据则不作任何操作，如果是多维数据，需要先将多维数据映射为一维数据，具体映射方式可以根据需要来选择。图4是多维数据映射为一维数据的示例图。如图4所示，本实施例中的数据集中的数据为三维数据，按照行优先的方法分字段展开，即可得到一维数据。[0039]接下来需要对一维数据构建OBF索引对象，与传统的BloomFiIter—样，对于数据分片一维数据中的每个元素，采用K个哈希函数hk映射为K个位置，k=0，l，…，K-1。区别在于在传统的BloomFiIter中，每个位置使用一个位来表示，而本发明中还需要存储每个哈希函数的序号k。因此，每个位置至少占用「log^Tl个位，「1表示向上取整，假设一维数据中元素数量为N，则存储N个元素的OBF索引所占用的空间大小是iV「l〇g夏1。[0040]记数据分片的一维数据中第η个元素为an，n=l，2,…，N，根据K个哈希函数hk计算得到的K个位置分别为hkan，记OBF索引对象中的位置数量为M，可以采用如下公式表示：[0041][0042]冒号左边代表位置编号，冒号右边代表这个位置被哪些哈希函数所命中。用Sm表示第m个位置所对应的哈希函数编号集合。那么OBF索引中第m个位置的值Fm应该是集合Sm中的最小值，如下式所示：[0043]Fm=minSm[0044]基于以上说明，本发明中OBF索引对象构建的具体过程为：[0045]初始化OBF索引对象中每个位置的值为绝对大值，由于本发明中哈希函数的数量为K，哈希函数的序号1ί=0，1，···，Κ-1，显然该绝对大值应当大于等于K，本实施例中为K。依次读取数据分片的一维数据中的第η个元素an，将其插入OBF索引对象，插入方法为:根据K个哈希函数hk计算得到其K个位置hkan，记位置hkan原有值为Ft3hkan，令第hkan个位置的值Fhkanhkan}。图5是本发明OBF索引对象中元素插入示例图。如图5所示，某元素e根据K个哈希函数hk计算K个位置hke，其中hoe对应位置原有值为2，则将该位置的值更新为min0,2，即为0;1ηθ对应位置原有值为3,则将该位置的值更新为min1，3，即为I;hke对应位置原有值为Κ，则将该位置的值更新为mink，K。[0046]在得到OBF索引对象后，将其序列化为OBF索引文件进行存储即可，所有数据分片的OBF索引文件即为OBF-Index。[0047]在Hadoop环境下，可以米用MapReduce的方式，分布式生成OBF索引。因为建立索引文件的所有工作可以完全只在Map中完成，所以不需要Reduce过程。在Hadoop中可以通过JobConf对象的setNumReduceTask0方法来设置Reducer个数为0，这样Map的结果便可以直接写到HDFS了。图6是本实施例中基于MapReduce生成OBF索引文件的示意图。如图6所示，在Map方法中，将每一条记录按分隔符分隔开，转换为一维数据;然后按照插入方法依次将一维数据中每个元素插入到OBF索引对象中；当处理完所有记录后，将当前数据分片的路径和偏移量组合为id，并将此id作为输出OBF索引文件名的一部分，将OBF索引对象按字节的形式存储到HDFS上，即序列化为OBF索引文件存储，所有输出的OBF索引文件合称OBF-Index0[0048]为了使OBF-Index的构建更加高效，在构建OBF-Index之前，还可以对构建OBF-Index的相关参数进行分析，以判断配置是否合理。为了能够实现以上功能，需要先得到索引环境的相关参数，索引环境是对索引的应用环境进行精确且量化的描述，可以根据具体情况进行设置。本实施例中，定义索引环境包括集群、数据集、索引三个对象的属性。图7是本实施例中索引环境的示意图。本实施例中索引环境中各个对象包含的对象或属性如下：[0049]1集群:主要描述了集群相关配置的属性，诸如Hadoop版本、机器数量、CPU内存等资源数量、HDFS中Block大小以及JVM配置等属性。集群是整个索引存在的大环境，所以索引构建的速度、资源占用、更新频率等都要受到集群环境的制约。这些属性一般情况下可以继承自集群中的配置。[0050]2数据集:数据集的属性直接决定了是否适合构建索引，以及该怎么构建。所以数据集相关属性的定义是集群环境中的重点。数据集的大小是很自然想到的属性，数据集是IGB还是1TB，对于只有几十或几百MB的输入文件建立索引显然是没什么必要的。一般而言，在HDFS上的文件都是由许多的文件构成的，所以文件的数量、大小以及文件的类型都是要考虑的属性。因为在构建索引时，数据集只是几个大文件还是一堆的小文件都是完全不同的情况。文件的类型决定了在MapReduce过程中由什么样的方式来分片和读取数据。文件是否压缩，对文件的真实体积有所隐藏，所以只有知道文件是否压缩才能对上述文件的其它属性有更准确的估计。最后，需要考虑的便是文件内部记录的相关属性了，诸如，总共有多少条记录、多少个字段等。其中多少个字段就涉及到文件的内容是不是结构化的，是用什么字符分隔等。[0051]3在构建OBF-Index时，操作人员对OBF-Index是有一定预期的。比如OBF索引文件的磁盘占用、构建索引所需要的时间、维护索引的频率等。OBF-Index中核心数据结构为0BF，所以必然也会有与BloomFilter相关的一些参数，比如哈希函数个数、BloomFilter的长度等。最后便是性能参数，是指索引构建者构建索引后期望达到的效果，其中包括索引占用了多少的存储空间，因为BloomFiIter作为一种概率数据结构，使用这个索引在当前数据量下的期望的精度或可容忍的假阳率的阈值。[0052]接下来需要对索引环境进行分析，其具体方法为:预先收集若干OBF-Index构建时的索引环境，如果能成功构建OBF-Index则记其标签为1，否则为0,将索引环境作为输入，对应标签作为期望输出，训练得到回归模型（一般可以采用神经网络）；然后在构建OBF-Index前，将其索引环境输入回归模型，根据输出判定是否能构建成功，如果能构建成功，则构建OBF-Index，否则提示操作人员检查索引环境。[0053]为了更加方便操作人员的使用，在提示操作人员检查索引环境时，可以将索引环境中各个属性的参数与相应的参考值或参考范围进行比较，如果与参考值不同或超出参考范围，则提示操作人员。[0054]在OBF-Index构建好之后，如果数据集发生改变，需要对OBF-Index进行更新。因此可以对数据集进行监测，如果发生改变，则重新构建OBF-Index，否则不作任何操作。[0055]S103:分片过滤：[0056]在需要使用数据集时，首先设置需要使用的数据集合A，然后分别读取每个数据分片的OBF索引文件并反序列化得到OBF索引对象，利用OBF索引对象查询数据集合A中的数据是否存在于该数据分片中，，如果是，则将该数据分片传递给相应的Mapper，否则不作任何操作。采用这种方式，可以过滤掉MapReduce过程不需要的数据分片，只把包含所需数据的分片传递给相应Mapper，达到减少Mapper的目的，减少参加到后续阶段的数据量，从而提升整个MapReduce过程的效率。[0057]OBF-Index的查找和插入十分相似，记需要查询的数据为X，根据K个哈希函数hk计算得到K个位置hkx，记OBF索引对象中hkx对应位置的原有值为Ft3OlkX，如果所有k多Ft3hkX均为真，则该数据存在该OBF索引对象对应的数据分片中，否则不存在。[0058]图8是本发明OBF-Index中元素查找示例图。如图8所示，查询数据X根据K个哈希函数hk计算K个位置hkX，其中OBF索引对象中hoX对应位置值为0，0彡0为真;InX对应位置原有值为3，1多3为假;hkX对应位置原有值为k-2，k多k-2为真，因此查询数据X不在该OBF索引对应的数据分片中。[0059]为了更好地说明本发明的技术效果，对本发明进行实验验证。本次实验中7台主机搭建了一个Hadoop集群，Hadoop集群中配置了ZooKeeper协调服务，配置了两个ResourceManger和两个NameNode其中一个为SecondaryNameNode〇[0000]在Hadoop生态系统中，原生的MapReduce框架并不支持构建索引。在Hive中，一是可以通过使用分区表桶的方式来过滤不必要的数据、避免扫描全表来提高查询的效率;二是从HiveO.7.0版本开始，Hive添加了对索引的支持，并在HiveO.8.0中添加了位图索引，因此可以通过Hive构建索引来提高某些简单查询的效率。BF-MapReduce提出了利用BloomFiIter在Map阶段之前过滤不必要数据分片，从而达到加快MapReduce任务的方法。本次实验中选用MapReduce、Hive有无索引）以及BF-MapReduce作为对比。[0061]图9是本发明与BF-MapReduce的假阳率对比图。本次实验在本发明OBF-Index和BF-MapReduce实现时哈希函数都选用了murmurhash，哈希函数数量K=8，OBF索引文件中位置数量M=213。如图9所示，横坐标表示插入元素的个数，纵坐标表示本发明OBF-IndexSBF-MapReduce在插入当前元素个数下的假阳率，从图中可以看出，本发明的假阳率变化相对平缓。[0062]图10是本发明和MapReduce、Hive有无索引）以及BF-MapReduce在不同数据集数据量下的查询速度对比图。如图10所示，横轴代表的数据量，纵轴表示查询时间，可知本发明OBF-Index和BF-MapReduce查询时间比较稳定，基本上可以在10000毫秒左右完成查找。相反，如果没有索引结构，原生的MapReduce程序会随着数据量的增大而增大，当记录超过IO8条后，查询性能急剧下降。因为本发明OBF-Index和BF-MapReduce经过过滤后真正参加运算的数据较小，Mapper数量也较少;而MapReduce本身的Mapper数量是与数据集数据量成正比，当Mapper的数量大到不能得到足量的Container来执行时，加上等待调度的时间，因此任务执行时间较长。因为Hive中当数据量较小的时候，任务可以在本地运行，所以实验来看，当数据量小于IO7的时候，有没有索引都可以在“瞬间”完成；而且通过索引查找的效果非常的糟糕，甚至比没有索引的情况都要差。[0063]图11是本发明和MapReduce、BF_MapReduce在不同数据集数据量下的Mapper过程时间消耗对比图。如图11所示，本发明OBF-Index的Mapper过程时间消耗较少，与BF-MapReduce基本相当，这是因为OBF-Index和BF-MapReduce均采用了索引过滤机制，一般情况下，只有少数分片包含要查找的数据，所以经过索引过滤后，只有少量Mapper参与到后续的运算中。[0064]图12是本发明和MapReduce、BF-MapReduce中不同大小文件的查找效率对比图。图13是本发明OBF-Index和MapReduce、BF-MapReduce中不同数量文件的查找效率对比图。如图12和图13所示，本发明OBF-Index在查找效率较优，和BF-MapReduce基本相当。[0065]图14是本发明和Hive、BF_MapReduce中索引文件构建时间对比图。如图14所示，本发明中索引文件的构建时间少于Hive，略高于BF-MapReduce。[0066]综合以上实验结果可知，本发明OBF-Index在查找效率、Mapper过程时间、索引构建时间方面的性能均较优，与BF-MapReduce基本相当，但是假阳率大大优于BF-MapReduce，可见本发明综合性能较好。[0067]尽管上面对本发明说明性的具体实施方式进行了描述，以便于本技术领域的技术人员理解本发明，但应该清楚，本发明不限于具体实施方式的范围，对本技术领域的普通技术人员来讲，只要各种变化在所附的权利要求限定和确定的本发明的精神和范围内，这些变化是显而易见的，一切利用本发明构思的发明创造均在保护之列。

权利要求：1.一种Hadoop环境下多维索引结构OBF-Index的实现方法，其特征在于包括以下步骤：SI:对数据集进行划分得到数据分片；S2:对每个数据分片分别生成一个OBF索引文件并存储，构建得到OBF-Index，生成OBF索引文件的具体方法为:首先对数据分片进行处理，如果是一维数据则不作任何操作，如果是多维数据，将其映射为一维数据;为数据分片初始化一个OBF索引对象，该OBF索引对象中每个位置的初始值为绝对大值，依次读取数据分片的一维数据中的第η个元素an，n=l，2,-·_，Ν，将其插入OBF索引对象，插入方法为：根据K个哈希函数hk计算得到其K个位置hkan，记位置hkan原有值为Fqhkan，令第hkan个位置的值Fhkan=min{k，FQhkan};将得到的OBF索引对象序列化为OBF索引文件；S3:在需要使用数据集时，首先设置需要使用的数据集合A，然后分别读取每个数据分片的OBF索引文件并反序列化得到OBF索引对象，利用OBF索引对象查询数据集合A中的数据是否存在于该数据分片中，如果是，则将该数据分片传递给相应的Mapper，否则不作任何操作；查询方法为:记需要查询的数据为X，根据K个哈希函数hk计算得到K个位置hkX，记hkX对应位置的原有值为Ft3hkX，如果所有hkX均为真，则该数据存在该OBF索引对象对应的数据分片中，否则不存在。2.根据权利要求1所述的Hadoop环境下多维索引结构OBF-Index的实现方法，其特征在于，采用MapReduce的方式进行所述OBF索引文件的生成，具体方法为:设置Reducer个数为0,在Map方法中，将每一条记录按分隔符分隔开，转换为一维数据;然后按照插入方法依次将一维数据中每个元素插入到OBF索引对象中；当处理完所有记录后，将当前数据分片的路径和偏移量组合为id，并将此id作为输出文件名的一部分，将OBF索引对象按字节的形式存储到HDFS上，即序列化为OBF索引文件存储。3.根据权利要求1所述的Hadoop环境下多维索引结构OBF-Index的实现方法，其特征在于，在OBF-Index构建之前，先对OBF-Index构建的相关参数进行分析，分析方法为:预先收集若干OBF-Index构建时的索引环境，索引环境包括集群、数据集、索引三个对象的属性，如果能成功构建OBF-Index则记其标签为1，否则为0，将索引环境作为输入，对应标签作为期望输出，训练得到回归模型;然后在OBF-Index构建之构建前，将其索引环境输入回归模型，根据输出判定是否能构建成功，如果能构建成功，则构建OBF-Index，否则提示操作人员检查索引环境。

百度查询： 云南大学 Hadoop环境下多维索引结构OBF-Index的实现方法

免责声明
1、本报告根据公开、合法渠道获得相关数据和信息，力求客观、公正，但并不保证数据的最终完整性和准确性。
2、报告中的分析和结论仅反映本公司于发布本报告当日的职业理解，仅供参考使用，不能作为本公司承担任何法律责任的依据或者凭证。

阅读全文 双屏查看 官方信息 专利公告 收藏专利 下载PDF 下载WORD