一种基于Storm流计算框架文本索引方法及系统的制作方法

一种基于Storm流计算框架文本索引方法及系统的制作方法
【专利摘要】本发明公开了一种基于Storm流计算框架文本索引方法及系统，包括：storm的topology实现，设计Storm实时数据处理框架，完成网络爬虫这个自动网页提取程序；关键词自动抽取；文本分类，根据文本的内容或属性，将文本归到一个或多个类别中。本发明使自身在数据损坏、丢失等情况下将备份数据倒回，实现数据的恢复；提供对系统自身的集中操作维护的功能；界面美观实用，方便和直观的图形用户管理界面；功能扩展满足用户今后系统扩充和扩大使用范围的要求；容错性:当用户输入或误操作导致非法数据产生时，系统具有一定的容错机制。
【专利说明】
一种基于Storm流计算框架文本索引方法及系统
技术领域
[0001 ]本发明属于数据处理技术领域，尤其涉及一种基于Storm流计算框架文本索引方 法及系统。
【背景技术】
[0002] Storm是一个开源的、大数据处理系统，与其他系统不同，它旨在用于分布式实时 处理且与语言无关。Hadoop专注于批处理。这种模型对许多情形（比如为网页建立索引）已 经足够，但还存在其他一些使用模型，它们需要来自高度动态的来源的实时信息。为了解决 这个问题，就得借助NathanMarz推出的Storm(现在在Twitter中称为BackType)。Storm不处 理静态数据，但它处理预计会连续的流数据。考虑到Twitter用户每天生成1.4亿条推文 (tweet)，那么就很容易看到此技术的巨大用途。但Storm不只是一个传统的大数据分析系 统:它是复杂事件处理(CEP)系统的一个示例。CEP系统通常分类为计算和面向检测，其中每 个系统都可通过用户定义的算法在Storm中实现。举例而言，CEP可用于识别事件洪流中有 意义的事件，然后实时地处理这些事件。Storm与其他大数据解决方案的不同之处在于它的 处理方式。Hadoop在本质上是一个批处理系统。数据被引入Hadoop文件系统(HDFS)并分发 到各个节点进行处理。当处理完成时，结果数据返回到HDFS供始发者使用。Storm支持创建 拓扑结构来转换没有终点的数据流。不同于Hadoop作业，这些转换从不停止，它们会持续处 理到达的数据。Hadoop的核心是使用Java语言编写的，但支持使用各种语言编写的数据分 析应用程序。最新的应用程序的实现采用了更加深奥的路线，以充分利用现代语言和它们 的特性。例如，位于伯克利的加利福尼亚大学（UC)的Spark是使用Scala语言实现的，而 Twitter Storm是使用Clojure(发音同closure)语言实现的。Clojure是Lisp语言的一种现 代方言。类似于Lisp，Clo jure支持一种功能性编程风格，但Clo jure还引入了一些特性来 简化多线程编程(一种对创建Storm很有用的特性hClojure是一种基于虚拟机(VM)的语 言，在Java虚拟机上运行。但是，尽管Storm是使用Clo jure语言开发的，您仍然可以在Storm 中使用几乎任何语言编写应用程序。所需的只是一个连接到Storm的架构的适配器。已存在 针对3〇3]^、贝油7、？61'1和?即的适配器，但是还有支持流式传输到31:〇1'1]1拓扑结构中的结构 化查询语言适配器。Nathan Marz提供了在Twitter中使用Storm的大量示例。一个最有趣的 示例是生成趋势信息。Twi tter从海量的推文中提取所浮现的趋势，并在本地和国家级别维 护它们。这意味着当一个案例开始浮现时，Twitter的趋势主题算法就会实时识别该主题。 这种实时算法在Storm中实现为Twi tter数据的一种连续分析。Storm实现的一些特征决定 了它的性能和可靠性的。Storm使用ZeroMQ传送消息，这就消除了中间的排队过程，使得消 息能够直接在任务自身之间流动。在消息的背后，是一种用于序列化和反序列化Storm的原 语类型的自动化且高效的机制。Storm的一个最有趣的地方是它注重容错和管理。Storm实 现了有保障的消息处理，所以每个元组都会通过该拓扑结构进行全面处理;如果发现一个 元组还未处理，它会自动从喷嘴处重放。Storm还实现了任务级的故障检测，在一个任务发 生故障时，消息会自动重新分配以快速重新开始处理。Storm包含比Hadoop更智能的处理管 理，流程会由监管员来进行管理，以确保资源得到充分使用。Struts2是Struts的下一代产 品，是在8让1^81和￥6&￥〇4的技术基础上进行了合并的全新的31：1'1^8 2框架。其全新的 Struts2的体系结构与Strutsl的体系结构差别巨大。Struts2以WebWork为核心，采用拦截 器的机制来处理用户的请求，这样的设计也使得业务逻辑控制器能够与ServletAPI完全脱 离开，所以Struts2可以理解为WebWork的更新产品。虽然从Strutsl至ljStruts2有着太大的 变化，但是相对于WebWork，Struts2的变化很小。网络爬虫（又被称为网页蜘蛛，网络机器 人，在F0AF社区中间，更经常的称为网页追逐者），是一种按照一定的规则，自动的抓取万维 网信息的程序或者脚本。另外一些不常使用的名字还有蚂蚁，自动索引，模拟程序或者蠕 虫。基于目标数据模式的爬虫针对的是网页上的数据，所抓取的数据一般要符合一定的模 式，或者可以转化或映射为目标数据模式。另一种描述方式是建立目标领域的本体或词典， 用于从语义角度分析不同特征在某一主题中的重要程度。网页的抓取策略可以分为深度优 先、广度优先和最佳优先三种。深度优先在很多情况下会导致爬虫的陷入问题，目前常见的 是广度优先和最佳优先方法。
[0003] 网上资源存在多样性和异构性，高度动态来源的实时信息难以采取、复杂事件处 理的性能需要提高、事件洪流中有意义的事件难以识别并实时进行处理。

【发明内容】

[0004] 本发明的目的在于提供一种基于Storm流计算框架文本索引方法及系统，旨在解 决网上资源存在多样性和异构性，高度动态来源的实时信息难以采取、复杂事件处理的性 能需要提高、事件洪流中有意义的事件难以识别并实时进行处理的问题。
[0005] 本发明是这样实现的，一种基于Storm流计算框架文本索引方法，所述基于Storm 流计算框架文本索引方法包括：
[0006] 步骤一，将网页搜索转换成没有终点的数据流，通过网络实时数据处理框架，实时 搜索网页和更新网页数据库；Storm集群有两种节点：Supervisor节点和worker节点， Supervisor节点负责在集群范围内分发代码、为worker分配任务和故障监测；Supervisor 监听分配给所在机器的工作，基于Nimbus分配给它的事情来决定启动或停止工作者进程；
[0007] 步骤二，关键词自动抽取:读放网页文件，进行分词，根据删除词库，过滤掉其中的 应删除词;计算TF，即各词语在网页文件中出现的次数，并进行归一化;计算IDF，即逆向文 件频率；
[0008] 步骤三，文本分类，根据文本的内容或属性，将文本归到一个或多个类别中。
[0009] 进一步，获取原始网页数据库中的HTML代码，利用XPath对HTML代码进行过滤，提 取出网页代码内具有实际意义和被用于检索的文字信息;输入为网页HTML代码，输出为网 页内文字信息;将文字提取模块提取出的文字，按照词库内的分词规则进行分词，若定义的 删除词库中有该词，则删除该词;输入为HTML代码内提取出的文字，输出为分词后的词集； 对每个网页文件，计算其中词语的出现频率IF;对词集内的词，逐个建立倒排索引，索引中 包含出现该词的网页ID以及词在网页中出现的位置，其输入为分词后的词集，输出为倒排 索引表;根据索引表计算各词语在各网页文件中出现的次数IDF，并进行归一化。
[0010] 所述步骤三进一步包括：
[0011] 准备工作阶段，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然 后由人工对一部分待分类项进行分类，形成训练样本集合;输入是所有待分类数据，输出是 特征属性和训练样本；
[0012] 分类器训练阶段，生成分类器，计算每个类别在训练样本中的出现频率及每个特 征属性划分对每个类别的条件概率估计，并将结果记录。其输入是特征属性和训练样本，输 出是分类器;生成分类器，计算每个类别在训练样本中的出现频率及每个特征属性划分对 每个类别的条件概率估计，并将结果记录;输入是特征属性和训练样本，输出是分类器;结 合贝叶斯改进的TF-IDF算法，将IDF结合贝叶斯改为NIDF，其计算公式为 其中D和E为利用分类模型得到的近似度的方差和期望，A是个常量;mi对应每一个分类中的 加权，计算公式为nu = IDF(key，Ci)*log Bi*-1，其中Ci为第i类样本的Token构成的整体域， IDF为计算该词放到第i类文本中的逆文本频率，通过贝叶斯得到的第i类分类与当前 文本的近似度，采用对数函数从而降低概率差异所带来的过分影响；
[0013] 应用阶段，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出是待 分类项与类别的映射关系。
[0014] 进一步，所述对文档中的单词进行聚类，形成k个单词簇；以单词簇为特征代表，使 用朴素贝叶斯分类器进行分类，分类器对于给出的单词，求解在此单词出现的条件下各个 类别出现的概率，认为此待分类项属于概率最大的类别，算法如下：
[0015] ff(key,file)=TF(key,file)*NIDF(key,allFile)
[0016] key分词后的词字Token;
[0017] file当前的文件整个文本；
[0018] allFile分类参照样本库；
[0019] W(key，f ile)当前token在这个文件中的权值；
[0020] TF(key，f i le)当前token在这个文件的词频；
[0021] NIDF(key，allFile)改进过的逆文本频率；
[0023] wordcount (key，file)当前token在这个文本中的出现次数；
[0024] totalword( f i le)所有的 token 数；
[0026] D根据分类模型得到的近似度的方差；
[0027] E根据分类模型得到的近似度的期望；
[0028] A常量系数；
[0029] m对应每一个分类中的加权；
[0030] IDF mi = IDF(key，Ci)*log Bi*_l;
[0031] Ci第i类样本的Token构成的整体域；
[0032] IDF计算该词如果放到第i类文本中的逆文本频率；
[0033] 通过贝叶斯得到的第i类分类与当前文本的近似度；
[0034] Log降低概率差异所带来的过分影响；
[0035] -1概率小于〈1 log后为负数。
[0036] 本发明的另一目的在于提供一种所述基于Storm流计算框架文本索引方法的系 统，所述系统包括：
[0037] 转换模块，用于将网页搜索转换成没有终点的数据流，通过网络实时数据处理框 架，实时搜索网页和更新网页数据库；Storm集群有两种节点：Supervisor节点和worker节 点，Supervisor节点负责在集群范围内分发代码、为worker分配任务和故障监测； Supervisor监听分配给所在机器的工作，基于Nimbus分配给它的事情来决定启动或停止工 作者进程；
[0038] 抽取模块，用于关键词自动抽取:读放网页文件，进行分词，根据删除词库，过滤掉 其中的应删除词;计算TF，即各词语在网页文件中出现的次数，并进行归一化;计算IDF，即 逆向文件频率；
[0039] 文本分类模块，用于根据文本的内容或属性，将文本归到一个或多个类别中。
[0040] 所述文本分类模块进一步包括：
[0041]准备工作阶段单元，根据具体情况确定特征属性，并对每个特征属性进行适当划 分，然后由人工对一部分待分类项进行分类，形成训练样本集合;输入是所有待分类数据， 输出是特征属性和训练样本；
[0042] 分类器训练阶段单元，用于生成分类器，计算每个类别在训练样本中的出现频率 及每个特征属性划分对每个类别的条件概率估计，并将结果记录。其输入是特征属性和训 练样本，输出是分类器;生成分类器，计算每个类别在训练样本中的出现频率及每个特征属 性划分对每个类别的条件概率估计，并将结果记录;输入是特征属性和训练样本，输出是分 类器；结合贝叶斯改进的T F -1D F算法，将ID F结合贝叶斯改为NID F，其计算公式为
其中D和E为利用分类模型得到的近似度的方差和期望，A是个常量;mi 对应每一个分类中的加权，计算公式为nu = IDF(key，Ci)*log Bi*-1，其中Ci为第i类样本的 Token构成的整体域，IDF为计算该词放到第i类文本中的逆文本频率，通过贝叶斯得 到的第i类分类与当前文本的近似度，采用对数函数从而降低概率差异所带来的过分影响；
[0043] 应用阶段定义，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出 是待分类项与类别的映射关系。
[0044] 本发明的另一目的在于提供一种包含所述基于Storm流计算框架文本索引方法的 信息流处理系统。
[0045] 本发明的另一目的在于提供一种包含所述基于Storm流计算框架文本索引方法的 连续计算系统。
[0046] 本发明的另一目的在于提供一种包含所述基于Storm流计算框架文本索引方法的 分布式远程过程调用系统。
[0047] 本发明提供的基于Storm流计算框架文本索引方法及系统，使用Twitter Storm开 源框架，进行网络爬虫，而用户可以实现搜索自己想要搜索的文件，也就是说的系统是一个 类似百度文库的网站；当用户上传一个文档的时候，系统可以使用分类算法对上传的文档 进行检测，并得出文档的分类，系统自动将文档分类;可以抓取RSS。可以抓取网页;可以抓 取文本文档，抓取后计算已存在数据库中的文库与抓取的相似度;计算关键词和文章的权 重;反映关键词和文章的相关性。提供索引。本发明的系统能真正做到使自身在数据损坏、 丢失等情况下将备份数据倒回，实现数据的恢复;提供对系统自身的集中操作维护的功能； 界面设计:系统应提供美观实用，方便和直观的图形用户管理界面，充分考虑员工的习惯， 简单易学，操作方便，所有菜单驱动的处理和各种快捷键，一键功能以确保多数达到；功能 扩展:系统从系统结构、功能设计、管理对象等各方面的功能扩展来考虑，以满足用户今后 系统扩充和扩大使用范围的要求;软硬件升级:系统应采取的硬件和软件平台，软件和硬件 的负载平衡机制的可扩展性充分考虑；系统要具有灵活的扩展能力，来适应关键的软件和 硬件的开发及管理能力的上升；系统的数据格式应符合国家相关标准及行业标准，以此确 保应用程序具有良好的互操作性和移植的可能;时间特性要求，系统的更新处理时间应该 在可接受的范围内；系统的数据查询时间应该在可接受的范围内；系统的数据统计时间应 该在可接受的范围内；容错性：当用户输入或误操作导致非法数据产生时，系统应具有一定 的容错机制;在这种情况下，系统应给出友好的提示，提示用户重新输入或者进行自动的修 复校正;系统的外在环境安全:安全系统要以充分考虑网络的高级别，多层次的安全性措施 为前提，包括系统的备份，防火墙，用户权限和其他措施，以确保数据安全和机密信息不被 泄露;考虑到系统的硬件和软件故障恢复等应急措施，以保障网络的安全和处理安全性;形 成相对独立的安全机制，以防止来自系统外的未经授权的访问；系统内部安全:确保外部系 统安全的同时，该系统还必须确保授权用户的合法使用。系统运行安全:从逻辑上讲，该系 统应具有抵抗非法入侵的能力;在物理方面，该系统应确保没有潜在的单点故障，并提供资 源的数据备份功能；系统支持定期自动和手动数据备份，能够在数据损坏或数据丢失的情 况下找回数据，实现一定程度的数据恢复。这个公式的意义在于改善了传统TF-IDF对领域 或归类后文本识别的不足，遇到分类后的文章会把识别关键词识别为非关键词，IDF不够智 能。改进TF-IDF实现;TF-IDF对在文档中出现频率高，而在整个文档集合的其他文档中出现 频率少的词语，取TF词频作为测度，体现同类文本的特点;对出现的文本频数小的单词取逆 文本频度IDF进行衡量，以TF和IDF的乘积作为特征空间坐标系的取值测度，突出重要单词， 抑制次要单词。因为IDF的简单结构并不能有效地反映单词的重要程度和特征词的分布情 况，所以本发明给汉语中的每个词赋予一个权重，词的预测主题能力越强，权重就越大，反 之，权重就越小。应删除词的权重为零，较好地完成对权值调整的功能。本发明对Storm运行 平台进行大量实证分析和改进，通过增加 Count的执行单元数、优化代码结构、改进服务器 配置和Bolt的资源分配、更改网络设置、及执行延时估算，提高了整个系统的运行性能。使 用Storm框架持续处理到达的事件流，用于识别其中有意义的网页数据，然后实时地处理这 些网页。在Storm中使用ZeroMQ传送消息，采用序列化和反序列化Storm的原语类型的自动 化且高效的机制，能消除中间的排队过程，使得消息能够直接在任务自身之间流动。本发 明使用Storm实现了任务级的故障检测，在一个任务发生故障时，消息会自动重新分配以快 速重新开始处理，流程会由监管员来进行管理，以确保资源得到充分使用。。这一阶段由 Storm程序完成。本发明针对资源分配不均匀的问题进行改进，增加了 Count的执行单元数、 优化了代码结构，解决了完整执行完成的单元数目不多，而且越到后面越拥塞的问题
【附图说明】
[0048]图1是本发明实施例提供的基于Storm流计算框架文本索引方法流程图。
[0049]图2是本发明实施例提供的Storm实现流程图。
[0050]图3是本发明实施例提供的TF-IDF实现流程图。
[00511图4是本发明实施例提供的Bayes实现流程图。
[0052]图5是本发明实施例提供的Emitted在各阶段执行数目示意图。
[0053] 图6是本发明实施例提供的两种执行结果的对比示意图。
[0054] 图7是本发明实施例提供的Masterl+Slave2的执行情况示意图。
[0055] 图8是本发明实施例提供的Masterl+Slave4的执行情况示意图。
[0056] 图9是本发明实施例提供的执行情况对比示意图。
[0057]图10是本发明实施例提供的执行情况对比示意图。
[0058]图11是本发明实施例提供的Masterl+Slave2的执行情况示意图。
[0059]图12是本发明实施例提供的Masterl+Slave4的执行情况示意图。
[0060] 图13是本发明实施例提供的两种改进后的情况的执行对比示意图。
[0061] 图14是本发明实施例提供的五种情况的执行对比示意图。
【具体实施方式】
[0062]为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明 进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用 于限定本发明。
[0063]下面结合附图对本发明的应用原理作详细的描述。
[0064]如图1所示，本发明实施例的基于Storm流计算框架文本索引方法包括以下步骤： [0065] S101:设计Storm实时数据处理框架，完成网络爬虫这个自动网页提取程序；
[0066] S102:关键词自动抽取，读放网页文件，进行分词，根据删除词库，过滤掉其中的应 删除词;计算TF，即各词语在网页文件中出现的次数，并进行归一化;计算IDF，即逆向文件 频率；
[0067] S103:文本分类，根据文本的内容或属性，将文本归到一个或多个类别中。
[0068] 步骤S101具体包括：
[0069] 1.设计网络爬虫，将其抽象为一张有向无环流转换图，对应为storm中最高层次的 抽象概念:Topology(拓扑）。本发明Storm集群有两种节点：控制(master)节点和工作者 (worker)节点。控制节点运行一个称之为"nimbus"的后台程序，负责在集群范围内分发代 码、为worker分配任务和故障监测；
[0070] 2 ?本发明中每个工作者节点运行一个称之"Supervisor"的后台程序。Supervisor 监听分配给它所在机器的工作，基于Nimbus分配给它的事情来决定启动或停止工作者进 程。每个工作者进程执行一个topology的子集（也就是一个子拓扑结构）；一个运行中的 topology由许多跨多个机器的工作者进程组成。其中一个Zookeeper集群负责Nimbus和多 个Superv i sor之间的所有协调工作（一个完整的拓扑可能被分为多个子拓扑并由多个 supervisor完成）；
[0071] 3.Nimbus后台程序和Supervisor后台程序都是快速失败和无状态的；所有状态维 持在Zookeeper或本地磁盘。这意味着本发明可以杀掉nimbus进程和supervisor进程，然后 重启，它们将恢复状态并继续工作，这种设计使storm极其稳定。这种设计中Master并没有 直接和worker通信，而是借助一个中介Zookeeper，这样一来可以分离master和worker的依 赖，将状态信息存放在zookeeper集群内以快速回复任何失败的一方。
[0072] 步骤S103具体包括：
[0073] 1.准备工作阶段，根据具体情况确定特征属性，并对每个特征属性进行适当划分， 然后由人工对一部分待分类项进行分类，形成训练样本集合。这一阶段的输入是所有待分 类数据，输出是特征属性和训练样本；
[0074] 2.分类器训练阶段，主要工作是生成分类器。计算每个类别在训练样本中的出现 频率及每个特征属性划分对每个类别的条件概率估计，并将结果记录。其输入是特征属性 和训练样本，输出是分类器。这一阶段是机械性阶段，根据前面讨论的公式可以由程序自动 计算完成；
[0075] 3.结合贝叶斯改进的TF-IDF算法，改善在领域内过于频繁出现关键字造成实际 IDF降低，但其确实是实用关键字的问题；
[0076] 4.应用阶段。这个阶段的任务是使用分类器对待分类项进行分类，其输入是分类 器和待分类项，输出是待分类项与类别的映射关系。这一阶段也是机械性阶段，由程序完 成。
[0077] 如图2所示，所述Storm实现具体包括:使用Twitter Storm开源框架，进行网络爬 虫，抓取RSS、网页、文本文档，抓取后计算已存在数据库中的文库与抓取的相似度；用户可 以实现搜索自己想要搜索的文件；当用户上传一个文档的时候，使用分类算法对上传的文 档进行检测，系统自动将文档分类。
[0078] 所述TF-IDF实现具体包括：
[0079] 由于一篇文档会有许多单词组成，文本分类面临着高维性，分类器的算法和实现 的复杂度会随特征空间维数的增加而增加。为了降低高维性对分类精度的影响，需要对文 本进行维数削减。本发明首先采用k 一 means算法对文档中的单词进行聚类，形成k个单词 簇，再以单词簇为特征代表，使用朴素贝叶斯分类器进行分类。分类器对于给出的单词，求 解在此单词出现的条件下各个类别出现的概率，就认为此待分类项属于概率最大的类别。
[0080] 在某些分类中出现的词分类后会大概感知到其分类的信息，改善当遇到后会降 低由于在此领域内过于频繁造成实际IDF降低，但其确实是实用关键字的问题。其算法如 下。
[0081 ] W(key，file)=TF(key，file)*NIDF(key，allFile)
[0082] key分词后的词字Token [0083] file当前的文件整个文本
[0084] allFile分类参照样本库
[0085] W(key，file)当前token在这个文件中的权值
[0086] TF(key，f i le)当前token在这个文件的词频
[0087] NIDF(key, allFile)改进过的逆文本频率
[0089] wordcount (key，file)当前token在这个文本中的出现次数
[0090] totalword( f i le)所有的 token 数
[0092] D根据分类模型得到的近似度的方差
[0093] E根据分类模型得到的近似度的期望
[0094] X常量系数
[0095] m对应每一个分类中的加权
[0096] IDF nu = IDF(key，Ci)*log Bi*_l
[0097] Ci第i类样本的Token构成的整体域
[0098] IDF计算该词如果放到第i类文本中的逆文本频率
[0099] Bi通过贝叶斯得到的第i类分类与当前文本的近似度
[0100] Log降低概率差异所带来的过分影响
[0101] -1概率小于〈1 log后为负数。
[0102]结合贝叶斯改进的TF-IDF，对于仅在某些分类中出现的词分类后会大概感知到 其分类的信息，改善当遇到后会降低由于在此领域内过于频繁造成实际IDF降低，但其确实 是实用关键字的问题。其算法如下。
[0103] W(key，file)=TF(key，file)*NIDF(key，allFile)
[0104] key分词后的词字Token;
[0105] file当前的文件整个文本；
[0106] allFile分类参照样本库；
[0107] W(key，f ile)当前token在这个文件中的权值；
[0108] TF(key，f i le)当前token在这个文件的词频；
[0109] NIDF(key，allFile)改进过的逆文本频率；
[0111] wordcount(key，f ile)当前token在这个文本中的出现次数；
[0112] totalword( file)所有的 token 数；
[0114] D根据分类模型得到的近似度的方差；
[0115] E根据分类模型得到的近似度的期望；
[0116] A常量系数；
[0117] m对应每一个分类中的加权；
[0118] IDF mi = IDF(key，Ci)*log Bi*_l;
[0119] Ci第i类样本的Token构成的整体域；
[0120] IDF计算该词如果放到第i类文本中的逆文本频率；
[0121] Bi通过贝叶斯得到的第i类分类与当前文本的近似度；
[0122] Log降低概率差异所带来的过分影响；
[0123] -1概率小于〈1 log后为负数；
[0124] 改善了传统TF-IDF对领域或归类后文本识别的不足，遇到分类后的文章会把识 别关键词识别为非关键词，IDF不够智能。
[0125] 下面结合测试对本发明的应用效果作详细的描述。
[0126] 1单机版测试结果
[0127] 首先，设定只有一个Spouts(水管），从而统计10秒、3小时、1天和全部时长的 Emitted(Spout或Bolt传输的次数）、Transf erred(Spout或Bolt传输的元素个数）以及 Complete latency(延时），如表 1 和表2。
[0128] 表1在一个执行者的情况下，传输测试结果
[0130]表2在一个水管的情况下Bolts的测试结果
[0132] 由以上结果得出，在单机调试的情况下，设定相同水管（Spout数为500)在各个阶 段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index:索 引执行数的结果如下：
[0133] 为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了 图5。
[0134] 2改进单机版测试结果
[0135] 在之前的单机版中，发现了如下问题:资源分配不均匀;最后完整执行完成的数目 不多，而且越往后面执行，问题越大。简单的Bolt执行快，但是也会被阻塞住。为此进行更 改，增加了 Count的执行单元数、优化了代码结构。得到的结果和原来的测试结果对比：
[0136] 由以上结果得出，在单机调试的情况下，设定相同水管（Spout数为160)在各个阶 段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index:索 引执行数的结果。
[0137] 将两次的执行情况进行对比，图6是的对比结果，可以看出，绿色的线代表第一次 的执行结果，而蓝色的线代表第二次的执行结果。在相同的时间内每个阶段的执行数目蓝 色测试结果都比绿色测试结果多。
[0138]问题分析，最后的Count在增加了 8倍权重后依然比较慢，于是分析有可能是单机 负载能力影响了执行效果，测试结果显示，执行效果与CHJ和内存的占用情况有关。
[0139] 从Worker = 1开始进行检测，探寻资源的消耗。
[0M0] 测试到的结果如下：在master上运行的服务过多，最多支撑到三个worker; CPU消 耗一般，有剩余资源;初始可用内存较少Worker大于三个后内存完全耗尽，在Worker = 4后 内存消耗过大，系统失去响应，无法获得测试结果；内存消耗主要在爬虫的页面获取上(这 个Bolt-次获取100个网页）。
[0141] 3分布双机测试
[0142] 3 ? lMasterl+Slave2 测试
[0143] Master共计开放了 1个端口，Slave共计开放了 6个端口，该测试分别占用1个 Master和2个Slave 〇
[0144] 首先，设定只有一个Spouts(水管），从而统计10秒、3小时、1天和全部时长的 Emi tted( Spout或Bolt传输的次数）、Transferred (Spout或Bolt传输的元素个数）以及 Complete latency(延时）。如表3和表4。
[0145] 表3在一个执行者的情况下，传输测试结果
[0147]表4在一个水管的情况下Bo 1 ts的测试结果
[0149] 由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为5980)在各个阶 段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index:索 引执行数的结果如下：
[0150] 同时记录Masterl+Slave2CPU和内存的负载情况，可以发现CPU的占用率大约为 20%而内存的占用率为40%。
[0151 ]为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了 图7。
[0152] 3 ? 2Masterl+Slave4 测试
[0153] Master共计开放了 1个端口，Slave共计开放了 6个端口，该测试分别占用1个 Master 和4个 Slave 〇
[0154] 首先，设定只有一个Spouts(水管），从而统计10秒、3小时、1天和全部时长的 Emitted(Spout或Bolt传输的次数）、Transf erred(Spout或Bolt传输的元素个数）以及 Complete latency(延时）。如表5和表6。
[0155] 表5在一个执行者的情况下，传输测试结果
[0157]表6在一个水管的情况下Bolts的测试结果
[0159] 由以上结果得出，在单机调试的情况下，设定相同水管（Spout数为5880)在各个 阶段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index: 索引执行数的结果。
[0160] 同时记录Masterl+Slave4CPU和内存的负载情况，可以发现CPU的占用率大约为 20%而内存的占用率为63.1%。
[0161] 为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了图 8。可以将Masterl+Slave2的执行情况和Masterl+Slave4的执行情况进行对比，将两次的执 行情况进行对比，图9是的对比结果，可以看出，蓝色的线代表Masterl+Slave2的执行情况、 绿色的线代表Mast erl+SlaVe4的执行情况。发现结果显示网站的服务器还是有问题，不利 于Slavel的Bolt执行，最后执行索引的数量Index反而下降。
[0162] 可以将单机的执行情况、Master 1+Slave2的执行情况和Master 1+Slave4的执行情 况进行对比，将三次的执行情况进行对比，图10是的对比结果，可以看出，蓝色的线代表单 机的执行情况，而蓝色的线代表Mast erl+SlaVe2的执行情况、黄色的线代表Masterl + Slave4的执行情况。发现最终发布后，Index(执行整个过程完成）的执行数量大幅提升，但 由于涉及问题的存在到时Slavel上导致Resource到Record阶段的执行数量大幅下降，为解 决这一问题通过以下几个手段：
[0163] 1.改进服务器配置，更改网络设置，使之在同一个网段。
[0164] 2.改进Bolt的资源分配，通过执行延时进行估算，相对延时长的分配资源相对较 多，相对延时短的分配资源相对较少。
[0165] 3 ? 3Masterl+Slave2 改进后测试
[0166] Master共计开放了 1个端口，Slave共计开放了 6个端口，该测试分别占用1个 Master和2个Slave 〇
[0167] 首先，设定只有一个Spouts(水管），从而统计10秒、3小时、1天和全部时长的 Emitted(Spout或Bolt传输的次数）、Transf erred(Spout或Bolt传输的元素个数）以及 Complete latency(延时）。如表7和表8所示。
[0168] 表7在一个执行者的情况下，传输测试结果
[0170]~表8在一个水管的情况下Bo 1 ts的测试结果
[0172] 由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为5880)在各个阶 段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index:索 引执行数的结果如下：
[0173] 通过对比改进前与改进后的执行情况，发现改进后执行数量明显提高。
[0174] 同时记录Masterl+Slave2CPU和内存的负载情况，可以发现CPU的占用率大约为 10%而内存的占用率为40.4%。
[0175] 为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了 图11。
[0176] 3 ? 4Masterl+Slave4 改进后测试
[0177] Master共计开放了 1个端口，Slave共计开放了 6个端口，该测试分别占用1个 Master 和4个 Slave 〇
[0178] 首先，设定只有一个Spouts(水管），从而统计10秒、3小时、1天和全部时长的 Emitted(Spout或Bolt传输的次数）、Transf erred(Spout或Bolt传输的元素个数）以及 Complete latency(延时）。如表9和表 10。
[0179] 表9在一个执行者的情况下，传输测试结果
[0181] 表10在一个水管的情况下Bolts的测试结果
[0183] 由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为14300)在各个 阶段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index: 索引执行数的结果如下：
[0184] 通过对比改进前与改进后的执行情况，发现改进后执行数量明显提高。
[0185] 同时记录Masterl+Slave4CPU和内存的负载情况，可以发现CPU的占用率大约为 30%而内存的占用率为66.1%。
[0186] 为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制图 12。
[0187] 对改进后的Master 1+Slave2的执行情况和Master 1+Slave4的执行情况进行对比。 绿色的线代表改进后Master 1+Slave2的执行情况，蓝色的线代表改进后Master 1+Slave4的 执行情况。发现两种执行情况的差别并不明显，但Masterl+SlaVe4执行完成后的Index更 多，因此认为将以上几种情况进行对比来看，改进后的Masterl+Slave4的执行情况最佳，从 五种情况的对比图13和图14也可看出，到最后一步Index的执彳丁数量是最多的。
[0188] 从以上五种情况的对比图来看，改进后，使用了比原来多5倍的Slot，而执行数量 60提高到了 680,提升了 11倍。
[0189] 3 ? 5Masterl+Slave6 测试
[0190] Master共计开放了 1个端口，Slave共计开放了 6个端口，该测试分别占用1个 Master和6个Slave 〇
[0191] 首先，设定只有一个Spouts(水管），从而统计10秒、3小时、1天和全部时长的 Emitted(Spout或Bolt传输的次数）、Transf erred(Spout或Bolt传输的元素个数）以及 Complete latency (延时）。如表 11 和表 12。
[0192] 表11在一个执行者的情况下，传输测试结果
[0195]表12在一个水管的情况下Bo 1 ts的测试结果
1〇197]^由以上结果得出，在单机调试的情况下，设定相同水管（Spout数为14300)在各个 阶段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index: 索引执行数的结果。
[0198] 同时记录Masterl+Slave6CPU和内存的负载情况，可以发现CPU的占用率大约为 60%而内存的占用率为73.3%。
[0199] 为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，发现 Masterl+Slave6的情况下，各阶段的执行数量较为平缓，并且执行数量也有所增加。只有到 Count阶段到Index阶段的执行情况收到了影响。
[0200] 3 ? 6Master2+Slave6 测试
[0201] 看到，在Masterl+Slavee的情况下，执行状况良好，在这种情况下Slave的内存和 CHJ都达到80%，Master内存达到80%，CPU达到30%左右。因此为了进行最高压测试，因此 多开放一个Slot，加大不占用内存的Index的计算任务数。
[0202] Master共计开放了 1个端口，Slave共计开放了 6个端口，该测试分别占用2个 Master和6个Slave 〇
[0203]首先，设定只有一个Spouts(水管），从而统计10秒、3小时、1天和全部时长的 Emitted(Spout或Bolt传输的次数）、Transf erred(Spout或Bolt传输的元素个数）以及 Complete latency(延时）。
[0204]由以上结果得出，在单机调试的情况下，设定相同水管（Spout数为14300)在各个 阶段Resource:资源数、Record:记录数、Split:分词执行数、Count:关键词计算数、Index: 索引执行数的结果。
[0205]从以上两种情况的对比来看，Master2+Slave6因为压力的增大，使得系统无法响 应。
[0206] 同时记录Master2+Slave6CPU和内存的负载情况，可以发现CPU的占用率大约为 80%而内存的占用率为73.4%。
[0207]为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，发现 Master2+Slave6的情况下，各阶段的执行数量比较之前Masterl+Slave6的执行情况，没有 原来平缓，而且从Spl it阶段就已经开始有了明显的减缓。
[0208] 因此得出结果，虽然Master2+Slave6的确认的ACK数量高于原来Masterl+Slave6 的执行情况，但是执行数量却有明显的减少。所以为了保证系统的响应，因此不应该给系统 太大的压力。
[0209] 对改进后的Master 1+Slave2的执行情况、Master 1+Slave4的执行情况、Master 1+ Slave6的执行情况以及Master2+Slave6的执行情况进行对比。可以看到Masterl+Slave6的 执行情况最好，每个阶段的执行数量变化较为平缓且最终执行数量也最多。
[0210] 以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精 神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
【主权项】
1. 一种基于Storm流计算框架文本索引方法，其特征在于，所述基于Storm流计算框架 文本索引方法包括： 步骤一，将网页搜索转换成没有终点的数据流，通过网络实时数据处理框架，实时搜索 网页和更新网页数据库；Storm集群有两种节点：Super visor节点和worker节点， Supervisor节点负责在集群范围内分发代码、为worker分配任务和故障监测；Supervisor 监听分配给所在机器的工作，基于Nimbus分配给它的事情来决定启动或停止工作者进程； 步骤二，关键词自动抽取:读放网页文件，进行分词，根据删除词库，过滤掉其中的应删 除词;计算TF，即各词语在网页文件中出现的次数，并进行归一化;计算IDF，即逆向文件频 率； 步骤三，文本分类，根据文本的内容或属性，将文本归到一个或多个类别中。2. 如权利要求1所述的基于Storm流计算框架文本索引方法，其特征在于，获取原始网 页数据库中的HTML代码，利用XPath对HTML代码进行过滤，提取出网页代码内具有实际意义 和被用于检索的文字信息;输入为网页HTML代码，输出为网页内文字信息;将文字提取模块 提取出的文字，按照词库内的分词规则进行分词，若定义的删除词库中有该词，则删除该 词;输入为HTML代码内提取出的文字，输出为分词后的词集;对每个网页文件，计算其中词 语的出现频率IF;对词集内的词，逐个建立倒排索引，索引中包含出现该词的网页ID以及词 在网页中出现的位置，其输入为分词后的词集，输出为倒排索引表;根据索引表计算各词语 在各网页文件中出现的次数IDF，并进行归一化。3. 如权利要求1所述的基于Storm流计算框架文本索引方法，其特征在于，所述步骤三 进一步包括： 准备工作阶段，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然后由 人工对一部分待分类项进行分类，形成训练样本集合;输入是所有待分类数据，输出是特征 属性和训练样本； 分类器训练阶段，生成分类器，计算每个类别在训练样本中的出现频率及每个特征属 性划分对每个类别的条件概率估计，并将结果记录； 应用阶段，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出是待分类 项与类别的映射关系。4. 如权利要求1所述的基于Storm流计算框架文本索引方法，其特征在于，所述对文档 中的单词进行聚类，形成k个单词簇；以单词簇为特征代表，使用朴素贝叶斯分类器进行分 类，分类器对于给出的单词，求解在此单词出现的条件下各个类别出现的概率，认为此待分 类项属于概率最大的类别，算法如下： W(key，file)=TF(key，file)*NIDF(key，allFile) key分词后的词字Token; file当前的文件整个文本； allFile分类参照样本库； W( key，file)当前token在这个文件中的权值； TF( key，file)当前token在这个文件的词频； NIDF(key，allFile)幻改进过的逆文本频率；wordcount (key，file)当前token在这个文本中的出现次数； totalword (file)所有的 token 数；D根据分类模型得到的近似度的方差； E根据分类模型得到的近似度的期望； λ常量系数； m对应每一个分类中的加权； IDF mi = IDF(key，Ci)*logBi*_l; Ci第i类样本的Token构成的整体域； IDF计算该词如果放到第i类文本中的逆文本频率； 通过贝叶斯得到的第i类分类与当前文本的近似度； Log降低概率差异所带来的过分影响； -1概率小于〈llog后为负数。5. -种如权利要求1所述基于Storm流计算框架文本索引方法的系统，其特征在于，所 述系统包括： 转换模块，用于将网页搜索转换成没有终点的数据流，通过网络实时数据处理框架，实 时搜索网页和更新网页数据库；Storm集群有两种节点：Supervisor节点和worker节点， Supervisor节点负责在集群范围内分发代码、为worker分配任务和故障监测；Supervisor 监听分配给所在机器的工作，基于Nimbus分配给它的事情来决定启动或停止工作者进程； 抽取模块，用于关键词自动抽取:读放网页文件，进行分词，根据删除词库，过滤掉其中 的应删除词;计算TF，即各词语在网页文件中出现的次数，并进行归一化;计算IDF，即逆向 文件频率； 文本分类模块，用于根据文本的内容或属性，将文本归到一个或多个类别中。6. 如权利要求5所述的系统，其特征在于，所述文本分类模块进一步包括： 准备工作阶段单元，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然 后由人工对一部分待分类项进行分类，形成训练样本集合;输入是所有待分类数据，输出是 特征属性和训练样本； 分类器训练阶段单元，用于生成分类器，计算每个类别在训练样本中的出现频率及每 个特征属性划分对每个类别的条件概率估计，并将结果记录； 应用阶段定义，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出是待 分类项与类别的映射关系。7. -种包含如权利要求1-4任意一项所述基于Storm流计算框架文本索引方法的信息 流处理系统。8. -种包含如权利要求1-4任意一项所述基于Storm流计算框架文本索引方法的连续 计算系统。9. 一种包含如权利要求1-4任意一项所述基于Storm流计算框架文本索引方法的分布 式远程过程调用系统。
【文档编号】G06F17/30GK105930360SQ201610221562
【公开日】2016年9月7日
【申请日】2016年4月11日
【发明人】罗磊, 蒋勰, 张永刚
【申请人】云南省国家税务局