CN105930360B - 一种基于Storm流计算框架文本索引方法及系统 - Google Patents

一种基于Storm流计算框架文本索引方法及系统 Download PDF

Info

Publication number
CN105930360B
CN105930360B CN201610221562.8A CN201610221562A CN105930360B CN 105930360 B CN105930360 B CN 105930360B CN 201610221562 A CN201610221562 A CN 201610221562A CN 105930360 B CN105930360 B CN 105930360B
Authority
CN
China
Prior art keywords
text
word
classification
storm
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN201610221562.8A
Other languages
English (en)
Other versions
CN105930360A (zh
Inventor
罗磊
蒋勰
张永刚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yunnan University YNU
Original Assignee
State Taxation Bureau Of Yunnan Province
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by State Taxation Bureau Of Yunnan Province filed Critical State Taxation Bureau Of Yunnan Province
Priority to CN201610221562.8A priority Critical patent/CN105930360B/zh
Publication of CN105930360A publication Critical patent/CN105930360A/zh
Application granted granted Critical
Publication of CN105930360B publication Critical patent/CN105930360B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/35—Clustering; Classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/23—Clustering techniques
    • G06F18/232—Non-hierarchical techniques
    • G06F18/2321—Non-hierarchical techniques using statistics or function optimisation, e.g. modelling of probability density functions
    • G06F18/23213—Non-hierarchical techniques using statistics or function optimisation, e.g. modelling of probability density functions with fixed number of clusters, e.g. K-means clustering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F18/00—Pattern recognition
    • G06F18/20—Analysing
    • G06F18/24—Classification techniques
    • G06F18/241—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches
    • G06F18/2415—Classification techniques relating to the classification model, e.g. parametric or non-parametric approaches based on parametric or probabilistic models, e.g. based on likelihood ratio or false acceptance rate versus a false rejection rate
    • G06F18/24155—Bayesian classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/279—Recognition of textual entities
    • G06F40/284—Lexical analysis, e.g. tokenisation or collocates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/279—Recognition of textual entities
    • G06F40/289—Phrasal analysis, e.g. finite state techniques or chunking

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Artificial Intelligence (AREA)
  • Probability & Statistics with Applications (AREA)
  • General Health & Medical Sciences (AREA)
  • Computational Linguistics (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Evolutionary Biology (AREA)
  • Evolutionary Computation (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种基于Storm流计算框架文本索引方法及系统，包括：storm的topology实现，设计Storm实时数据处理框架，完成网络爬虫这个自动网页提取程序；关键词自动抽取；文本分类，根据文本的内容或属性，将文本归到一个或多个类别中。本发明使自身在数据损坏、丢失等情况下将备份数据倒回，实现数据的恢复；提供对系统自身的集中操作维护的功能；界面美观实用，方便和直观的图形用户管理界面；功能扩展满足用户今后系统扩充和扩大使用范围的要求；容错性:当用户输入或误操作导致非法数据产生时，系统具有一定的容错机制。

Description

一种基于Storm流计算框架文本索引方法及系统
技术领域
本发明属于数据处理技术领域，涉及一种基于Storm流计算框架文本索引方法及系统。
背景技术
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语言实现的，而TwitterStorm是使用Clojure(发音同closure)语言实现的。Clojure是Lisp语言的一种现代方言。类似于Lisp，Clojure支持一种功能性编程风格，但Clojure还引入了一些特性来简化多线程编程(一种对创建Storm很有用的特性)。Clojure是一种基于虚拟机(VM)的语言，在Java虚拟机上运行。但是，尽管Storm是使用Clojure语言开发的，您仍然可以在Storm中使用几乎任何语言编写应用程序。所需的只是一个连接到Storm的架构的适配器。已存在针对Scala、JRuby、Perl和PHP的适配器，但是还有支持流式传输到Storm拓扑结构中的结构化查询语言适配器。NathanMarz提供了在Twitter中使用Storm的大量示例。一个最有趣的示例是生成趋势信息。Twitter从海量的推文中提取所浮现的趋势，并在本地和国家级别维护它们。这意味着当一个案例开始浮现时，Twitter的趋势主题算法就会实时识别该主题。这种实时算法在Storm中实现为Twitter数据的一种连续分析。Storm实现的一些特征决定了它的性能和可靠性的。Storm使用ZeroMQ传送消息，这就消除了中间的排队过程，使得消息能够直接在任务自身之间流动。在消息的背后，是一种用于序列化和反序列化Storm的原语类型的自动化且高效的机制。Storm的一个最有趣的地方是它注重容错和管理。Storm实现了有保障的消息处理，所以每个元组都会通过该拓扑结构进行全面处理；如果发现一个元组还未处理，它会自动从喷嘴处重放。Storm还实现了任务级的故障检测，在一个任务发生故障时，消息会自动重新分配以快速重新开始处理。Storm包含比Hadoop更智能的处理管理，流程会由监管员来进行管理，以确保资源得到充分使用。Struts2是Struts的下一代产品，是在struts1和WebWork的技术基础上进行了合并的全新的Struts2框架。其全新的Struts2的体系结构与Struts1的体系结构差别巨大。Struts2以WebWork为核心，采用拦截器的机制来处理用户的请求，这样的设计也使得业务逻辑控制器能够与ServletAPI完全脱离开，所以Struts2可以理解为WebWork的更新产品。虽然从Struts1到Struts2有着太大的变化，但是相对于WebWork，Struts2的变化很小。网络爬虫(又被称为网页蜘蛛，网络机器人，在FOAF社区中间，更经常的称为网页追逐者)，是一种按照一定的规则，自动的抓取万维网信息的程序或者脚本。另外一些不常使用的名字还有蚂蚁，自动索引，模拟程序或者蠕虫。基于目标数据模式的爬虫针对的是网页上的数据，所抓取的数据一般要符合一定的模式，或者可以转化或映射为目标数据模式。另一种描述方式是建立目标领域的本体或词典，用于从语义角度分析不同特征在某一主题中的重要程度。网页的抓取策略可以分为深度优先、广度优先和最佳优先三种。深度优先在很多情况下会导致爬虫的陷入问题，目前常见的是广度优先和最佳优先方法。
网上资源存在多样性和异构性，高度动态来源的实时信息难以采取、复杂事件处理的性能需要提高、事件洪流中有意义的事件难以识别并实时进行处理。
发明内容
本发明的目的在于提供一种基于Storm流计算框架文本索引方法及系统，旨在解决网上资源存在多样性和异构性，高度动态来源的实时信息难以采取、复杂事件处理的性能需要提高、事件洪流中有意义的事件难以识别并实时进行处理的问题。
本发明是这样实现的，一种基于Storm流计算框架文本索引方法，所述基于Storm流计算框架文本索引方法包括：
步骤一，将网页搜索转换成没有终点的数据流，通过网络实时数据处理框架，实时搜索网页和更新网页数据库；Storm集群有两种节点：Supervisor节点和worker节点，Supervisor节点负责在集群范围内分发代码、为worker分配任务和故障监测；Supervisor监听分配给所在机器的工作，基于Nimbus分配给它的事情来决定启动或停止工作者进程；
步骤二，关键词自动抽取：读放网页文件，进行分词，根据删除词库，过滤掉其中的应删除词；计算TF，即各词语在网页文件中出现的次数，并进行归一化；计算IDF，即逆向文件频率；
步骤三，文本分类，根据文本的内容或属性，将文本归到一个或多个类别中。
进一步，获取原始网页数据库中的HTML代码，利用XPath对HTML代码进行过滤，提取出网页代码内具有实际意义和被用于检索的文字信息；输入为网页HTML代码，输出为网页内文字信息；将文字提取模块提取出的文字，按照词库内的分词规则进行分词，若定义的删除词库中有该词，则删除该词；输入为HTML代码内提取出的文字，输出为分词后的词集；对每个网页文件，计算其中词语的出现频率IF；对词集内的词，逐个建立倒排索引，索引中包含出现该词的网页ID以及词在网页中出现的位置，其输入为分词后的词集，输出为倒排索引表；根据索引表计算各词语在各网页文件中出现的次数IDF，并进行归一化。
所述步骤三进一步包括：
准备工作阶段，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然后由人工对一部分待分类项进行分类，形成训练样本集合；输入是所有待分类数据，输出是特征属性和训练样本；
分类器训练阶段，生成分类器，计算每个类别在训练样本中的出现频率及每个特征属性划分对每个类别的条件概率估计，并将结果记录。其输入是特征属性和训练样本，输出是分类器；生成分类器，计算每个类别在训练样本中的出现频率及每个特征属性划分对每个类别的条件概率估计，并将结果记录；输入是特征属性和训练样本，输出是分类器；结合贝叶斯改进的TF-IDF算法，将IDF结合贝叶斯改为NIDF，其计算公式为：
Figure GDA0001993509870000031
其中D和E为利用分类模型得到的近似度的方差和期望，λ是个常量；mi对应每一个分类中的加权，计算公式为mi＝IDF(key,Ci)*logBi*-1，其中Ci为第i类样本的Token构成的整体域，IDF为计算该词放到第i类文本中的逆文本频率，Bi为通过贝叶斯得到的第i类分类与当前文本的近似度，采用对数函数从而降低概率差异所带来的过分影响；
应用阶段，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出是待分类项与类别的映射关系。
进一步，所述对文档中的单词进行聚类，形成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数；
Figure GDA0001993509870000042
D根据分类模型得到的近似度的方差；
E根据分类模型得到的近似度的期望；
λ常量系数；
mi对应每一个分类中的加权；
mi＝IDF(key,Ci)*logBi*-1；
Ci第i类样本的Token构成的整体域；
IDF计算该词如果放到第i类文本中的逆文本频率；
Bi通过贝叶斯得到的第i类分类与当前文本的近似度；
Log用于降低概率差异所带来的过分影响；
-1使概率小于1log后为负数。
本发明的另一目的在于提供一种所述基于Storm流计算框架文本索引方法的系统，所述系统包括：
转换模块，用于将网页搜索转换成没有终点的数据流，通过网络实时数据处理框架，实时搜索网页和更新网页数据库；Storm集群有两种节点：master节点和worker节点，master节点运行“nimbus”后台程序，负责在集群范围内分发代码、为worker分配任务和故障监测；worker节点运行“Supervisor”后台程序，Supervisor后台程序监听分配给所在机器的工作，基于nimbus后台程序分配给它的事情来决定启动或停止工作者进程；
抽取模块，用于关键词自动抽取：读取网页文件，进行分词，根据删除词库，过滤掉其中的应删除词；计算TF即各词语在网页文件中出现的次数，并进行归一化；计算IDF即逆向文件频率；
文本分类模块，用于根据文本的内容或属性，将文本归到一个或多个类别中；
所述文本分类模块进一步包括：
准备工作阶段单元，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然后由人工对一部分待分类项进行分类，形成训练样本集合；输入是所有待分类数据，输出是特征属性和训练样本；
分类器训练阶段单元，用于生成分类器，计算每个类别在训练样本中的出现频率及每个特征属性划分对每个类别的条件概率估计，并将结果记录；其输入是特征属性和训练样本，输出是分类器；结合贝叶斯改进的TF-IDF算法，将IDF结合贝叶斯改为NIDF，其计算公式为：
其中D和E为利用分类模型得到的近似度的方差和期望，λ是个常量；mi对应每一个分类中的加权，计算公式为mi＝IDF(key，Ci)*logBi*-1，其中Ci为第i类样本的Token构成的整体域，IDF为计算该词放到第i类文本中的逆文本频率，Bi为通过贝叶斯得到的第i类分类与当前文本的近似度，采用对数函数从而降低概率差异所带来的过分影响；
应用阶段定义，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出是待分类项与类别的映射关系。
本发明的另一目的在于提供一种包含所述基于Storm流计算框架文本索引方法的信息流处理系统。
本发明的另一目的在于提供一种包含所述基于Storm流计算框架文本索引方法的连续计算系统。
本发明的另一目的在于提供一种包含所述基于Storm流计算框架文本索引方法的分布式远程过程调用系统。
本发明提供的基于Storm流计算框架文本索引方法及系统，使用TwitterStorm开源框架，进行网络爬虫，而用户可以实现搜索自己想要搜索的文件，也就是说的系统是一个类似百度文库的网站；当用户上传一个文档的时候，系统可以使用分类算法对上传的文档进行检测，并得出文档的分类，系统自动将文档分类；可以抓取RSS。可以抓取网页；可以抓取文本文档，抓取后计算已存在数据库中的文库与抓取的相似度；计算关键词和文章的权重；反映关键词和文章的相关性。提供索引。本发明的系统能真正做到使自身在数据损坏、丢失等情况下将备份数据倒回，实现数据的恢复；提供对系统自身的集中操作维护的功能；界面设计：系统应提供美观实用，方便和直观的图形用户管理界面，充分考虑员工的习惯，简单易学，操作方便，所有菜单驱动的处理和各种快捷键，一键功能以确保多数达到；功能扩展：系统从系统结构、功能设计、管理对象等各方面的功能扩展来考虑，以满足用户今后系统扩充和扩大使用范围的要求；软硬件升级：系统应采取的硬件和软件平台，软件和硬件的负载平衡机制的可扩展性充分考虑；系统要具有灵活的扩展能力，来适应关键的软件和硬件的开发及管理能力的上升；系统的数据格式应符合国家相关标准及行业标准，以此确保应用程序具有良好的互操作性和移植的可能；时间特性要求，系统的更新处理时间应该在可接受的范围内；系统的数据查询时间应该在可接受的范围内；系统的数据统计时间应该在可接受的范围内；容错性:当用户输入或误操作导致非法数据产生时，系统应具有一定的容错机制；在这种情况下，系统应给出友好的提示，提示用户重新输入或者进行自动的修复校正；系统的外在环境安全：安全系统要以充分考虑网络的高级别，多层次的安全性措施为前提，包括系统的备份，防火墙，用户权限和其他措施，以确保数据安全和机密信息不被泄露；考虑到系统的硬件和软件故障恢复等应急措施，以保障网络的安全和处理安全性；形成相对独立的安全机制，以防止来自系统外的未经授权的访问；系统内部安全：确保外部系统安全的同时，该系统还必须确保授权用户的合法使用。系统运行安全：从逻辑上讲，该系统应具有抵抗非法入侵的能力；在物理方面，该系统应确保没有潜在的单点故障，并提供资源的数据备份功能；系统支持定期自动和手动数据备份，能够在数据损坏或数据丢失的情况下找回数据，实现一定程度的数据恢复。这个公式的意义在于改善了传统TF-IDF对领域或归类后文本识别的不足，遇到分类后的文章会把识别关键词识别为非关键词，IDF不够智能。改进TF-IDF实现；TF-IDF对在文档中出现频率高，而在整个文档集合的其他文档中出现频率少的词语，取TF词频作为测度，体现同类文本的特点；对出现的文本频数小的单词取逆文本频度IDF进行衡量，以TF和IDF的乘积作为特征空间坐标系的取值测度，突出重要单词，抑制次要单词。因为IDF的简单结构并不能有效地反映单词的重要程度和特征词的分布情况，所以本发明给汉语中的每个词赋予一个权重，词的预测主题能力越强，权重就越大，反之，权重就越小。应删除词的权重为零，较好地完成对权值调整的功能。本发明对Storm运行平台进行大量实证分析和改进，通过增加Count的执行单元数、优化代码结构、改进服务器配置和Bolt的资源分配、更改网络设置、及执行延时估算，提高了整个系统的运行性能。使用Storm框架持续处理到达的事件流，用于识别其中有意义的网页数据，然后实时地处理这些网页。在Storm中使用ZeroMQ传送消息，采用序列化和反序列化Storm的原语类型的自动化且高效的机制，能消除中间的排队过程，使得消息能够直接在任务自身之间流动。本发明使用Storm实现了任务级的故障检测，在一个任务发生故障时，消息会自动重新分配以快速重新开始处理，流程会由监管员来进行管理，以确保资源得到充分使用。。这一阶段由Storm程序完成。本发明针对资源分配不均匀的问题进行改进，增加了Count的执行单元数、优化了代码结构，解决了完整执行完成的单元数目不多，而且越到后面越拥塞的问题。
附图说明
图1是本发明实施例提供的基于Storm流计算框架文本索引方法流程图。
图2是本发明实施例提供的Storm实现流程图。
图3是本发明实施例提供的TF-IDF实现流程图。
图4是本发明实施例提供的Bayes实现流程图。
图5是本发明实施例提供的Emitted在各阶段执行数目示意图。
图6是本发明实施例提供的两种执行结果的对比示意图。
图7是本发明实施例提供的Master1+Slave2的执行情况示意图。
图8是本发明实施例提供的Master1+Slave4的执行情况示意图。
图9是本发明实施例提供的执行情况对比示意图。
图10是本发明实施例提供的执行情况对比示意图。
图11是本发明实施例提供的Master1+Slave2的执行情况示意图。
图12是本发明实施例提供的Master1+Slave4的执行情况示意图。
图13是本发明实施例提供的两种改进后的情况的执行对比示意图。
图14是本发明实施例提供的五种情况的执行对比示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
下面结合附图对本发明的应用原理作详细的描述。
如图1所示，本发明实施例的基于Storm流计算框架文本索引方法包括以下步骤：
S101：设计Storm实时数据处理框架，完成网络爬虫这个自动网页提取程序；
S102：关键词自动抽取，读放网页文件，进行分词，根据删除词库，过滤掉其中的应删除词；计算TF，即各词语在网页文件中出现的次数，并进行归一化；计算IDF，即逆向文件频率；
S103：文本分类，根据文本的内容或属性，将文本归到一个或多个类别中。
步骤S101具体包括：
1.设计网络爬虫，将其抽象为一张有向无环流转换图，对应为storm中最高层次的抽象概念：Topology(拓扑)。本发明Storm集群有两种节点：控制(master)节点和工作者(worker)节点。控制节点运行一个称之为“nimbus”的后台程序，负责在集群范围内分发代码、为worker分配任务和故障监测；
2.本发明中每个工作者节点运行一个称之“Supervisor”的后台程序。Supervisor监听分配给它所在机器的工作，基于Nimbus分配给它的事情来决定启动或停止工作者进程。每个工作者进程执行一个topology的子集(也就是一个子拓扑结构)；一个运行中的topology由许多跨多个机器的工作者进程组成。其中一个Zookeeper集群负责Nimbus和多个Supervisor之间的所有协调工作(一个完整的拓扑可能被分为多个子拓扑并由多个supervisor完成)；
3.Nimbus后台程序和Supervisor后台程序都是快速失败和无状态的；所有状态维持在Zookeeper或本地磁盘。这意味着本发明可以杀掉nimbus进程和supervisor进程，然后重启，它们将恢复状态并继续工作，这种设计使storm极其稳定。这种设计中Master并没有直接和worker通信，而是借助一个中介Zookeeper，这样一来可以分离master和worker的依赖，将状态信息存放在zookeeper集群内以快速回复任何失败的一方。
步骤S103具体包括：
1.准备工作阶段，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然后由人工对一部分待分类项进行分类，形成训练样本集合。这一阶段的输入是所有待分类数据，输出是特征属性和训练样本；
2.分类器训练阶段，主要工作是生成分类器。计算每个类别在训练样本中的出现频率及每个特征属性划分对每个类别的条件概率估计，并将结果记录。其输入是特征属性和训练样本，输出是分类器。这一阶段是机械性阶段，根据前面讨论的公式可以由程序自动计算完成；
3.结合贝叶斯改进的TF-IDF算法，改善在领域内过于频繁出现关键字造成实际IDF降低，但其确实是实用关键字的问题；
4.应用阶段。这个阶段的任务是使用分类器对待分类项进行分类，其输入是分类器和待分类项，输出是待分类项与类别的映射关系。这一阶段也是机械性阶段，由程序完成。
如图2所示，所述Storm实现具体包括：使用TwitterStorm开源框架，进行网络爬虫，抓取RSS、网页、文本文档，抓取后计算已存在数据库中的文库与抓取的相似度；用户可以实现搜索自己想要搜索的文件；当用户上传一个文档的时候，使用分类算法对上传的文档进行检测，系统自动将文档分类。
所述TF-IDF实现具体包括：
由于一篇文档会有许多单词组成，文本分类面临着高维性，分类器的算法和实现的复杂度会随特征空间维数的增加而增加。为了降低高维性对分类精度的影响，需要对文本进行维数削减。本发明首先采用k—means算法对文档中的单词进行聚类，形成k个单词簇，再以单词簇为特征代表，使用朴素贝叶斯分类器进行分类。分类器对于给出的单词，求解在此单词出现的条件下各个类别出现的概率，就认为此待分类项属于概率最大的类别。
在某些分类中出现的词分类后会大概感知到其分类的信息，改善当遇到后会降低由于在此领域内过于频繁造成实际IDF降低，但其确实是实用关键字的问题。其算法如下。
W(key，file)＝TF(key，file)*NIDF(key，allFile)
key分词后的词字Token
file当前的文件整个文本
allFile分类参照样本库
W(key，file)当前token在这个文件中的权值
TF(key，file)当前token在这个文件的词频
NIDF(key,allFile)改进过的逆文本频率
Figure GDA0001993509870000101
wordcount(key,file)当前token在这个文本中的出现次数
totalword(file)所有的token数
Figure GDA0001993509870000102
D根据分类模型得到的近似度的方差
E根据分类模型得到的近似度的期望
λ常量系数
mi对应每一个分类中的加权
mi＝IDF(key,Ci)*logBi*-1
Ci第i类样本的Token构成的整体域
IDF计算该词如果放到第i类文本中的逆文本频率
Bi通过贝叶斯得到的第i类分类与当前文本的近似度
Log用于降低概率差异所带来的过分影响
-1使概率小于1log后为负数。
结合贝叶斯改进的TF-IDF，对于仅在某些分类中出现的词分类后会大概感知到其分类的信息，改善当遇到后会降低由于在此领域内过于频繁造成实际IDF降低，但其确实是实用关键字的问题。其算法如下。
W(key，file)＝TF(key，file)*NIDF(key，allFile)
key分词后的词字Token；
file当前的文件整个文本；
allFile分类参照样本库；
W(key，file)当前token在这个文件中的权值；
TF(key，file)当前token在这个文件的词频；
NIDF(key，allFile)改进过的逆文本频率；
Figure GDA0001993509870000111
wordcount(key,file)当前token在这个文本中的出现次数
totalword(file)所有的token数
Figure GDA0001993509870000112
D根据分类模型得到的近似度的方差
E根据分类模型得到的近似度的期望
λ常量系数
mi对应每一个分类中的加权
mi＝IDF(key,Ci)*logBi*-1
Ci第i类样本的Token构成的整体域
IDF计算该词如果放到第i类文本中的逆文本频率
Bi通过贝叶斯得到的第i类分类与当前文本的近似度
Log用于降低概率差异所带来的过分影响
-1使概率小于1log后为负数；
改善了传统TF-IDF对领域或归类后文本识别的不足，遇到分类后的文章会把识别关键词识别为非关键词，IDF不够智能。
下面结合测试对本发明的应用效果作详细的描述。
1单机版测试结果
首先，设定只有一个Spouts(水管)，从而统计10秒、3小时、1天和全部时长的Emitted(Spout或Bolt传输的次数)、Transferred(Spout或Bolt传输的元素个数)以及Completelatency(延时)，如表1和表2。
表1在一个执行者的情况下，传输测试结果
Emitted：Spout或Bolt传输的次元 3680420
Transferred：Spout或Bolt传输的元素个数 3680420
CL：延时 0.000
Acked：正确验证的 0
Failed：失败的 0
表2在一个水管的情况下Bolts的测试结果
Executors：物理执行线程 1
Task：该Spout的线程 1
Emitted：Spout或Bolt传输的次数 6340
Transferred：Spout或Bolt传输的元素个数 0
Capacity：容量 0.978
Executelatencu：执行延时 92.870
Executed：执行完成的 6320
ProcessLatency：进程延时 124.464
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为500)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果如下：
为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了图5。
2改进单机版测试结果
在之前的单机版中，发现了如下问题：资源分配不均匀；最后完整执行完成的数目不多，而且越往后面执行，问题越大。简单的Bolt执行快，但是也会被阻塞住。为此进行更改，增加了Count的执行单元数、优化了代码结构。得到的结果和原来的测试结果对比：
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为160)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果。
将两次的执行情况进行对比，图6是的对比结果，可以看出，绿色的线代表第一次的执行结果，而蓝色的线代表第二次的执行结果。在相同的时间内每个阶段的执行数目蓝色测试结果都比绿色测试结果多。
问题分析，最后的Count在增加了8倍权重后依然比较慢，于是分析有可能是单机负载能力影响了执行效果，测试结果显示，执行效果与CPU和内存的占用情况有关。
从Worker＝1开始进行检测，探寻资源的消耗。
测试到的结果如下：在master上运行的服务过多，最多支撑到三个worker；CPU消耗一般，有剩余资源；初始可用内存较少Worker大于三个后内存完全耗尽，在Worker＝4后内存消耗过大，系统失去响应，无法获得测试结果；内存消耗主要在爬虫的页面获取上(这个Bolt一次获取100个网页)。
3分布双机测试
3.1Master1+Slave2测试
Master共计开放了1个端口，Slave共计开放了6个端口，该测试分别占用1个Master和2个Slave。
首先，设定只有一个Spouts(水管)，从而统计10秒、3小时、1天和全部时长的Emitted(Spout或Bolt传输的次数)、Transferred(Spout或Bolt传输的元素个数)以及Completelatency(延时)。如表3和表4。
表3在一个执行者的情况下，传输测试结果
Emitted：Spout或Bolt传输的次元 5980
Transferred：Spout或Bolt传输的元素个数 5980
CL：延时 0.000
Acked：正确验证的 0
Failed：失败的 0
表4在一个水管的情况下Bolts的测试结果
Executors：物理执行线程 2
Task：该Spout的线程 12
Emitted：Spout或Bolt传输的次数 360
Transferred：Spout或Bolt传输的元素个数 0
Capacity：容量 1.925
Executelatencu：执行延时 3812.188
Executed：执行完成的 320
ProcessLatency：进程延时 468.118
Acked：正确验证的 340
Failed：失败的 0
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为5980)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果如下：
同时记录Master1+Slave2CPU和内存的负载情况，可以发现CPU的占用率大约为20％而内存的占用率为40％。
为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了图7。
3.2Master1+Slave4测试
Master共计开放了1个端口，Slave共计开放了6个端口，该测试分别占用1个Master和4个Slave。
首先，设定只有一个Spouts(水管)，从而统计10秒、3小时、1天和全部时长的Emitted(Spout或Bolt传输的次数)、Transferred(Spout或Bolt传输的元素个数)以及Completelatency(延时)。如表5和表6。
表5在一个执行者的情况下，传输测试结果
Emitted：Spout或Bolt传输的次元 5880
Transferred：Spout或Bolt传输的元素个数 5880
CL：延时 0.000
Acked：正确验证的 0
Failed：失败的 0
表6在一个水管的情况下Bolts的测试结果
Executors：物理执行线程 2
Task：该Spout的线程 12
Emitted：Spout或Bolt传输的次数 100
Transferred：Spout或Bolt传输的元素个数 0
Capacity：容量 1.941
Executelatencu：执行延时 13291.000
Executed：执行完成的 100
ProcessLatency：进程延时 13491.200
Acked：正确验证的 100
Failed：失败的 0
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为5880)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果。
同时记录Master1+Slave4CPU和内存的负载情况，可以发现CPU的占用率大约为20％而内存的占用率为63.1％。
为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了图8。可以将Master1+Slave2的执行情况和Master1+Slave4的执行情况进行对比，将两次的执行情况进行对比，图9是的对比结果，可以看出，蓝色的线代表Master1+Slave2的执行情况、绿色的线代表Master1+Slave4的执行情况。发现结果显示网站的服务器还是有问题，不利于Slave1的Bolt执行，最后执行索引的数量Index反而下降。
可以将单机的执行情况、Master1+Slave2的执行情况和Master1+Slave4的执行情况进行对比，将三次的执行情况进行对比，图10是的对比结果，可以看出，蓝色的线代表单机的执行情况，而蓝色的线代表Master1+Slave2的执行情况、黄色的线代表Master1+Slave4的执行情况。发现最终发布后，Index(执行整个过程完成)的执行数量大幅提升，但由于涉及问题的存在到时Slave1上导致Resource到Record阶段的执行数量大幅下降，为解决这一问题通过以下几个手段：
1.改进服务器配置，更改网络设置，使之在同一个网段。
2.改进Bolt的资源分配，通过执行延时进行估算，相对延时长的分配资源相对较多，相对延时短的分配资源相对较少。
3.3Master1+Slave2改进后测试
Master共计开放了1个端口，Slave共计开放了6个端口，该测试分别占用1个Master和2个Slave。
首先，设定只有一个Spouts(水管)，从而统计10秒、3小时、1天和全部时长的Emitted(Spout或Bolt传输的次数)、Transferred(Spout或Bolt传输的元素个数)以及Completelatency(延时)。如表7和表8所示。
表7在一个执行者的情况下，传输测试结果
Emitted：Spout或Bolt传输的次元 5980
Transferred：Spout或Bolt传输的元素个数 5980
CL：延时 0.000
Acked：正确验证的 0
Failed：失败的 0
表8在一个水管的情况下Bolts的测试结果
Executors：物理执行线程 16
Task：该Spout的线程 16
Emitted：Spout或Bolt传输的次数 620
Transferred：Spout或Bolt传输的元素个数 0
Capacity：容量 4.210
Executelatencu：执行延时 12509.134
Executed：执行完成的 600
ProcessLatency：进程延时 10055.038
Acked：正确验证的 520
Failed：失败的 0
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为5880)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果如下：
通过对比改进前与改进后的执行情况，发现改进后执行数量明显提高。
同时记录Master1+Slave2CPU和内存的负载情况，可以发现CPU的占用率大约为10％而内存的占用率为40.4％。
为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制了图11。
3.4Master1+Slave4改进后测试
Master共计开放了1个端口，Slave共计开放了6个端口，该测试分别占用1个Master和4个Slave。
首先，设定只有一个Spouts(水管)，从而统计10秒、3小时、1天和全部时长的Emitted(Spout或Bolt传输的次数)、Transferred(Spout或Bolt传输的元素个数)以及Completelatency(延时)。如表9和表10。
表9在一个执行者的情况下，传输测试结果
Emitted：Spout或Bolt传输的次元 5800
Transferred：Spout或Bolt传输的元素个数 5800
CL：延时 0.000
Acked：正确验证的 0
Failed：失败的 0
表10在一个水管的情况下Bolts的测试结果
Executors：物理执行线程 16
Task：该Spout的线程 16
Emitted：Spout或Bolt传输的次数 780
Transferred：Spout或Bolt传输的元素个数 0
Capacity：容量 4.767
Executelatencu：执行延时 11221.743
Executed：执行完成的 780
ProcessLatency：进程延时 12188.029
Acked：正确验证的 680
Failed：失败的 0
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为14300)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果如下：
通过对比改进前与改进后的执行情况，发现改进后执行数量明显提高。
同时记录Master1+Slave4CPU和内存的负载情况，可以发现CPU的占用率大约为30％而内存的占用率为66.1％。
为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，绘制图12。
对改进后的Master1+Slave2的执行情况和Master1+Slave4的执行情况进行对比。绿色的线代表改进后Master1+Slave2的执行情况，蓝色的线代表改进后Master1+Slave4的执行情况。发现两种执行情况的差别并不明显，但Master1+Slave4执行完成后的Index更多，因此认为将以上几种情况进行对比来看，改进后的Master1+Slave4的执行情况最佳，从五种情况的对比图13和图14也可看出，到最后一步Index的执行数量是最多的。
从以上五种情况的对比图来看，改进后，使用了比原来多5倍的Slot，而执行数量60提高到了680，提升了11倍。
3.5Master1+Slave6测试
Master共计开放了1个端口，Slave共计开放了6个端口，该测试分别占用1个Master和6个Slave。
首先，设定只有一个Spouts(水管)，从而统计10秒、3小时、1天和全部时长的Emitted(Spout或Bolt传输的次数)、Transferred(Spout或Bolt传输的元素个数)以及Completelatency(延时)。如表11和表12。
表11在一个执行者的情况下，传输测试结果
Emitted：Spout或Bolt传输的次元 4600
Transferred：Spout或Bolt传输的元素个数 4600
CL：延时 0.000
Acked：正确验证的 0
Failed：失败的 0
表12在一个水管的情况下Bolts的测试结果
Executors：物理执行线程 16
Task：该Spout的线程 16
Emitted：Spout或Bolt传输的次数 800
Transferred：Spout或Bolt传输的元素个数 0
Capacity：容量 2.644
Executelatencu：执行延时 9597.884
Executed：执行完成的 860
ProcessLatency：进程延时 12151.289
Acked：正确验证的 900
Failed：失败的 0
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为14300)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果。
同时记录Master1+Slave6CPU和内存的负载情况，可以发现CPU的占用率大约为60％而内存的占用率为73.3％。
为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，发现Master1+Slave6的情况下，各阶段的执行数量较为平缓，并且执行数量也有所增加。只有到Count阶段到Index阶段的执行情况收到了影响。
3.6Master2+Slave6测试
看到，在Master1+Slave6的情况下，执行状况良好，在这种情况下Slave的内存和CPU都达到80％，Master内存达到80％，CPU达到30％左右。因此为了进行最高压测试，因此多开放一个Slot，加大不占用内存的Index的计算任务数。
Master共计开放了1个端口，Slave共计开放了6个端口，该测试分别占用2个Master和6个Slave。
首先，设定只有一个Spouts(水管)，从而统计10秒、3小时、1天和全部时长的Emitted(Spout或Bolt传输的次数)、Transferred(Spout或Bolt传输的元素个数)以及Completelatency(延时)。
由以上结果得出，在单机调试的情况下，设定相同水管(Spout数为14300)在各个阶段Resource：资源数、Record：记录数、Split：分词执行数、Count：关键词计算数、Index：索引执行数的结果。
从以上两种情况的对比来看，Master2+Slave6因为压力的增大，使得系统无法响应。
同时记录Master2+Slave6CPU和内存的负载情况，可以发现CPU的占用率大约为80％而内存的占用率为73.4％。
为了清晰的看出Spout或Bolt传输的次数，在各个阶段的执行数目变化，发现Master2+Slave6的情况下，各阶段的执行数量比较之前Master1+Slave6的执行情况，没有原来平缓，而且从Split阶段就已经开始有了明显的减缓。
因此得出结果，虽然Master2+Slave6的确认的ACK数量高于原来Master1+Slave6的执行情况，但是执行数量却有明显的减少。所以为了保证系统的响应，因此不应该给系统太大的压力。
对改进后的Master1+Slave2的执行情况、Master1+Slave4的执行情况、Master1+Slave6的执行情况以及Master2+Slave6的执行情况进行对比。可以看到Master1+Slave6的执行情况最好，每个阶段的执行数量变化较为平缓且最终执行数量也最多。
以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (7)

1.一种基于Storm流计算框架文本索引方法，其特征在于，所述基于Storm流计算框架文本索引方法包括：
步骤一，将网页搜索转换成没有终点的数据流，通过网络实时数据处理框架，实时搜索网页和更新网页数据库；Storm集群有两种节点：master节点和worker节点，master节点运行“nimbus”后台程序，负责在集群范围内分发代码、为worker分配任务和故障监测；worker节点运行“Supervisor”后台程序，Supervisor后台程序监听分配给所在机器的工作，基于nimbus后台程序分配给它的事情来决定启动或停止工作者进程；
步骤二，关键词自动抽取：读取网页文件，进行分词，根据删除词库，过滤掉其中的应删除词；计算TF即各词语在网页文件中出现的次数，并进行归一化；计算IDF即逆向文件频率；
步骤三，文本分类，根据文本的内容或属性，将文本归到一个或多个类别中；
所述步骤三进一步包括：
准备工作阶段，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然后由人工对一部分待分类项进行分类，形成训练样本集合；输入是所有待分类数据，输出是特征属性和训练样本；
分类器训练阶段，生成分类器，计算每个类别在训练样本中的出现频率及每个特征属性划分对每个类别的条件概率估计，并将结果记录；
应用阶段，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出是待分类项与类别的映射关系。
2.如权利要求1所述的基于Storm流计算框架文本索引方法，其特征在于，获取原始网页数据库中的HTML代码，利用XPath对HTML代码进行过滤，提取出网页代码内具有实际意义和被用于检索的文字信息；输入为网页HTML代码，输出为网页内文字信息；将文字提取模块提取出的文字，按照词库内的分词规则进行分词，若定义的删除词库中有分词所得词语，则删除该词；输入为HTML代码内提取出的文字，输出为分词后的词集；对每个网页文件，计算其中词语的出现频率IF；对词集内的词，逐个建立倒排索引，索引中包含出现该词的网页ID以及词在网页中出现的位置，其输入为分词后的词集，输出为倒排索引表；根据索引表计算各词语在各网页文件中出现的次数TF，并进行归一化。
3.如权利要求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)改进过的逆文本频率；
Figure FDA0001993509860000021
wordcount(key,file)当前token在这个文本中的出现次数；
totalword(file)所有的token数；
D根据分类模型得到的近似度的方差；
E根据分类模型得到的近似度的期望；
λ常量系数；
mi对应每一个分类中的加权；
mi＝IDF(key,Ci)*logBi*-1；
Ci第i类样本的Token构成的整体域；
IDF计算该词如果放到第i类文本中的逆文本频率；
Bi通过贝叶斯得到的第i类分类与当前文本的近似度；
Log用于降低概率差异所带来的过分影响；
-1使概率小于1log后为负数。
4.一种如权利要求1所述基于Storm流计算框架文本索引方法的系统，其特征在于，所述系统包括：
转换模块，用于将网页搜索转换成没有终点的数据流，通过网络实时数据处理框架，实时搜索网页和更新网页数据库；Storm集群有两种节点：master节点和worker节点，master节点运行“nimbus”后台程序，负责在集群范围内分发代码、为worker分配任务和故障监测；worker节点运行“Supervisor”后台程序，Supervisor后台程序监听分配给所在机器的工作，基于nimbus后台程序分配给它的事情来决定启动或停止工作者进程；
抽取模块，用于关键词自动抽取：读取网页文件，进行分词，根据删除词库，过滤掉其中的应删除词；计算TF即各词语在网页文件中出现的次数，并进行归一化；计算IDF即逆向文件频率；
文本分类模块，用于根据文本的内容或属性，将文本归到一个或多个类别中；
所述文本分类模块进一步包括：
准备工作阶段单元，根据具体情况确定特征属性，并对每个特征属性进行适当划分，然后由人工对一部分待分类项进行分类，形成训练样本集合；输入是所有待分类数据，输出是特征属性和训练样本；
分类器训练阶段单元，用于生成分类器，计算每个类别在训练样本中的出现频率及每个特征属性划分对每个类别的条件概率估计，并将结果记录；
应用阶段定义，使用分类器对待分类项进行分类，输入是分类器和待分类项，输出是待分类项与类别的映射关系。
5.一种包含如权利要求1-3任意一项所述基于Storm流计算框架文本索引方法的信息流处理系统。
6.一种包含如权利要求1-3任意一项所述基于Storm流计算框架文本索引方法的连续计算系统。
7.一种包含如权利要求1-3任意一项所述基于Storm流计算框架文本索引方法的分布式远程过程调用系统。
CN201610221562.8A 2016-04-11 2016-04-11 一种基于Storm流计算框架文本索引方法及系统 Expired - Fee Related CN105930360B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610221562.8A CN105930360B (zh) 2016-04-11 2016-04-11 一种基于Storm流计算框架文本索引方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610221562.8A CN105930360B (zh) 2016-04-11 2016-04-11 一种基于Storm流计算框架文本索引方法及系统

Publications (2)

Publication Number Publication Date
CN105930360A CN105930360A (zh) 2016-09-07
CN105930360B true CN105930360B (zh) 2019-10-15

Family

ID=56840192

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610221562.8A Expired - Fee Related CN105930360B (zh) 2016-04-11 2016-04-11 一种基于Storm流计算框架文本索引方法及系统

Country Status (1)

Country Link
CN (1) CN105930360B (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106681820B (zh) * 2016-12-30 2020-05-01 西北工业大学 基于消息组合的可扩展大数据计算方法
CN106897625B (zh) * 2017-01-22 2019-08-06 北京理工大学 支持漏洞关联性挖掘的漏洞自动分类方法
CN106844712A (zh) * 2017-02-07 2017-06-13 济南浪潮高新科技投资发展有限公司 采用流式计算进行爬取数据的实时分析的实现方法
CN107169024A (zh) * 2017-04-11 2017-09-15 微梦创科网络科技（中国）有限公司 一种兼容型的业务系统及业务实现方法
CN107241352B (zh) * 2017-07-17 2020-01-21 浙江鹏信信息科技股份有限公司 一种网络安全事件分类与预测方法及系统
CN108494600B (zh) * 2018-03-30 2022-12-23 大唐丘北风电有限责任公司 拓扑创建管控的方法、装置及存储介质
CN108875786B (zh) * 2018-05-23 2021-04-09 北京化工大学 基于Storm的食品数据并行计算一致性问题的优化方法
CN110941713B (zh) * 2018-09-21 2023-12-22 上海仪电（集团）有限公司中央研究院 基于主题模型的自优化金融资讯版块分类方法
CN111090668B (zh) * 2019-12-09 2023-09-26 京东科技信息技术有限公司 数据检索方法及装置、电子设备和计算机可读存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010107114A1 (ja) * 2009-03-19 2010-09-23 日本電気株式会社 パターンマッチング装置
CN103839222B (zh) * 2014-02-18 2017-10-24 中国林业科学研究院资源信息研究所 一种基于分层次边界拓扑搜索模型的栅格转矢量并行系统
CN103838829B (zh) * 2014-02-18 2017-01-18 中国林业科学研究院资源信息研究所 一种基于分层次边界拓扑搜索模型的栅格转矢量系统

Also Published As

Publication number Publication date
CN105930360A (zh) 2016-09-07

Similar Documents

Publication Publication Date Title
CN105930360B (zh) 一种基于Storm流计算框架文本索引方法及系统
Xie et al. Topicsketch: Real-time bursty topic detection from twitter
CA2933423C (en) Data acceleration
CN109739849A (zh) 一种数据驱动的网络敏感信息挖掘与预警平台
CN109740037A (zh) 多源、异构流态大数据分布式在线实时处理方法及系统
CN107103100B (zh) 一种容错的基于图谱架构的智能语义搜索方法
US11562252B2 (en) Systems and methods for expanding data classification using synthetic data generation in machine learning models
Kotenko et al. Attack detection in IoT critical infrastructures: a machine learning and big data processing approach
Li et al. Bursty event detection from microblog: a distributed and incremental approach
Ragmani et al. Adaptive fault-tolerant model for improving cloud computing performance using artificial neural network
Agrawal et al. Adaptive real‐time anomaly detection in cloud infrastructures
Ali et al. Big data classification efficiency based on linear discriminant analysis
Patil Fake news detection using majority voting technique
Chen et al. An empirical study of massively parallel bayesian networks learning for sentiment extraction from unstructured text
Wladdimiro et al. Disaster management platform to support real-time analytics
Liu et al. A new method for webshell detection based on bidirectional gru and attention mechanism
Dass et al. Amelioration of Big Data analytics by employing Big Data tools and techniques
Ali et al. An effective classification approach for big data with parallel generalized Hebbian algorithm
Martínez-Castaño et al. Polypus: a big data self-deployable architecture for microblogging text extraction and real-time sentiment analysis
Gaykar et al. Faulty Node Detection in HDFS Using Machine Learning Techniques.
Chatel et al. Fast gaussian pairwise constrained spectral clustering
Noori et al. Feature selection from disaster tweets using Spark-based parallel meta-heuristic optimizers
CN111475380A (zh) 一种日志分析方法和装置
Gang et al. [Retracted] Research on Clue Mining in Criminal Cases of Smart Phone Trojan Horse under the Background of Information Security
Zhu et al. Generating interpretable data-based explanations for fairness debugging using gopher

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20191211

Address after: 650031 Yunnan province Kunming City Lake Road No. 2

Co-patentee after: Li Hao

Patentee after: Yunnan University

Co-patentee after: Kang Yan

Address before: 650000 Yunnan Province, Kunming Panlong District Baita Road No. 304

Patentee before: State Taxation Bureau of Yunnan Province

TR01 Transfer of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20191015

Termination date: 20200411

CF01 Termination of patent right due to non-payment of annual fee