Twitter数据挖掘及其可视化
前阵子有学弟学妹问我毕设做的啥,于是我决定记录一下去年毕设的内容。
主要是基于twitter的内容有:
- 实时热点话题检测
- 情感分析
- 结果可视化
- Twitter数据挖掘平台的设计与实现
毕设、论文内容
毕设从16年3月开始做,做到5月初,开始写论文,当时写的论文一共有七章,写了一个礼拜,从早到晚- -| 共24834字。,数据有的从15年11月左右开始抓的。
论文总共有七章,结构安排如下:
第一章,引言。主要介绍了Twitter下进行的数据挖掘的背景,以及国内外研究现状,并简要的说明了本文的主要研究内容。
第二章,Twitter相关的内容介绍。主要介绍Twitter的一些特殊语法,如用户提及@,hashtags等,接着讨论了Twitter中大量存在的拼写错误、缩写、重复字母现象,最后介绍了Twitter的REST API与StreamAPI。
第三章,实时热点话题挖掘。该章节首先介绍了LDA相关的模型,接着提出了WOLDA算法,以及最具有代表性推文的计算方法。
第四章,情感分析。该章节介绍了Twitter下的情感分析分类、以及机器学习的一般过程,接着介绍本文使用机器学习和情感词典相结合的方法。
第五章,数据可视化。介绍了几种基于统计的可视化方法,还有主题分析和情感分析的可视化的方法,可以更直观的表示结果。
第六章,Twitter数据挖掘平台的设计与实现。结合了前面几章的内容,介绍实现该系统的细节。
第七章总结了本文的工作,针对目前的不足,提出下一步改进的方案。
本篇博文为缩减版,除了略去一二章外,其它章节也做了精简。
实时热点话题挖掘
Twitter从2006年以来,发展迅猛。举两个数据来讲,
- 2015年5月,Twitter拥有超过5亿的用户,其中有超过3.32亿的活跃用户
- 2016年2月28日莱昂纳多获得第88届奥斯卡最佳男主角奖时,据统计,这一消息在Twitter上的讨论达到每分钟44万次
可以看出,Twitter的数据量是十分庞大的。为了能够了解Twitter上人们在谈论些什么,我们希望能够有一种有效的方 式来获取 Twitter 实时的热点话题。要求该方式:
- 能处理流数据并且对模型进行周期性的更新 。
- 产生的主题 与过去的 主题有关联 以便 观测话题的演变 。
- 资源占用稳定,不随时间增大而以便保证效率和对新话题的敏感 。
LDA模型
首先想到的就是主题模型。
2003年,D.Blei等人提出了广受欢迎的LDA(Latentdirichlet allocation)主题模型 [8]。LDA除了进行主题的分析外,还可以运用于文本分类、推荐系统等方面。
LDA模型可以描述为一个“上帝掷骰子”的过程,首先,从主题库中随机抽取一个主题,该主题编号为K,接着从骰子库中拿出编号为K的骰子X,进行投掷,每投掷一次,就得到了一个词。不断的投掷它,直到到达预计的文本长度为止。简单的说,这一过程就是“随机的选择某个主题,然后从该主题中随机的选择词语”。按照之前的描述,一篇文档中词语生成的概率为:
可以用矩阵的乘法来表示上述的过程:
回到LDA模型来说,LDA模型的输入是一篇一篇用BOW(bag ofwords)表示的文档,即用该文档中无序的单词序列来表示该文档(忽略文档中的语法和词语的先后关系)。LDA的输出是每篇文档的主题分布矩阵和每个主题下的单词分布矩阵。简而言之,LDA主题模型的任务就是已知左边的矩阵,通过一些方法,得到右边两个小矩阵。这里的“一些方法”即为LDA采样的方法,目前最主要的有两种,一种是变分贝叶斯推断(variationalBayes, VB),另一种叫做吉布斯采样(Gibbs Sampling),其中吉布斯采样也被称为蒙特卡洛马尔可夫 (Markov Chain MonteCarlo,MCMC)采样方法。
总的来说,MCMC实现起来更加简单方便,而VB的速度比MCMC来得快,研究表明他们具有差不多相同的效果。所以,对于大量的数据,采用VB是更为明智的选择。
Hoffman OLDA
虽然VB的速度相对而言比较快,但是对于巨大的数据来说,VB计算量仍十分巨大的,对此,Hoffman提出了Online variational Bayes (VB)算法(下面简称为OLDA),将数据集其分为一些小的batch, 然后更新,运算速度得到了巨大的提升。
WOLDA
虽然Hoffman提出的OLDA算法可以对后加进来的文档不断的更新,但是,该算法仍不能称得上是在线的算法。原因如下:
- 该算法采用静态词库(忽略不在词库中的词),而对于Twitter来说,新词不断涌现,缩写词、网络流行语、特殊事件人名、地名频繁出现,基本无法预测。即使我们拥有一个囊括了所有词的词库,那么这个词库也必然是巨大的,造成矩阵过于稀疏,运算效率低下。
- OLDA算法对旧话题“淡忘”速度越来越慢。如果一开始出现了所谓的“离题”(topic drift)现象,结果将会十分差劲,这不利于新话题的检测。
为此,改进的算法命名为WOLDA。
WOLDA采用动态的词库,(滑动时间窗口)
- 时间分为一个个时间片
- 只保留时间窗口L内的词 && 词频 > min_df(预设值)
对于1~L个时间片,对词频不小于min_df的词作为当前WOLDA的词库。
第L+1个时间片到来时,删除第1个时间片的文档,对第2个到第L+1个时间窗口内的文档重新计算词频,并将词频不小于min_df的词作为当前WOLDA的词库。
模型的更新方法为,对于新词,进行随机的初始化,而对于原本存在词库中的词有:
$$\lambda = C * \lambda$$
贡献因子C使得模型具有事件演变的能力,它将连续时间切片上的前后模型相结合。在具体的实现上,对于给定贡献因子C,我们只需要反解出OLDA中的更新次数t,将OLDA的更新次数重新设置为t即可,公式如下:
$$t = (1-C)^{-\frac{1}{\kappa}}-\tau_0$$
此外,还需要更新OLDA相应参数,如单词总数W和文档长度D。
算法描述如下:
定义窗口大小 L,贡献因子c,最小的词频 min_df for n = 0 to ∞ do 对时间片n的文档集合进行预处理,如去除停止词等操作。 if n==1: 该文档集过滤词频小于min_df的,正常运行OLDA else if 2 <= n <= L: 把第2~n的文档所有词重新计算词频,词频不小于min_df的词作为当前OLDA词库,新的词随机初始化。计算t,更新W和D,运行OLDA算法。 else if n > L: 删除第n-L篇文档,将第n–L+1 ~ n的文档的所有词重新计算词频,词频不小min_df的词作为当前OLDA词库,新的词随机初始化。计算t,更新W和D,运行OLDA算法。 end for
最具有代表性的推文计算
行WOLDA算法后,我们得到了每个主题下对应的主题词,主题词有时候对于主题的描述不够直观,为此我们希望从该主题下,能找到最具有代表性的推文,用来帮助解释和说明该主题的内容。本小节提出几种最具有代表性的推文的计算方法,并在之后的实验中加以对比。
KL-mean
KL散度(Kullback–Leibler divergence)又称为相对熵(relative entropy),它可以用来衡量两个概率分布的相似程度。对于离散型的随机变量,其概率分布P和Q的KL散度定义如下:
$$D_{KL}(P||Q) = \sum_iP(i) ln\frac{P(i)}{Q(i)}$$
通常情况下KL散度是非对称的,因此这里采用KL-mean方式(求P和Q KL散度以及Q和P KL散度的均值)
$$D_{KL-mean}(P||Q) = \frac{1}{2}(D_{KL}(P||Q) +D_{KL}(Q||P) )$$
使用KL-mean距离计算最具有代表性的推文伪代码如下:
pro_matrix: 主题-单词矩阵 features = [] for tweet_id,tweet in tweets do topic_id根据文档-主题矩阵得到当前推文最大可能从属的主题序号 feature = [0 …] // 长度为词库的大小的全0数组 for word_id, each word in tweet do: //word_id 为当前单词在词库中的下标 feature[word_id] = word_cnt * pro_matrix[topic_id][word_id] //当前单词出现的次数乘以相应的主题-单词矩阵中的概率 end for features.append(feature) end for 对于所有相同主题序号的推文,计算其feature的平均值作为主题的中心。 接着使用KL-mean距离计算每条推文与其主题中心的距离dis 对于每个主题,找到与类中心最小距离的推文,该推文即为最具有代表性的推文。
余弦距离
余弦距离常常用来衡量相似度(通过计算两个向量夹角的余弦值)。其定义如下:
$$D_{cos}(P,Q) = \frac{P·Q}{||P||·||Q||}$$
使用余弦距离计算最具有代表性的推文的方法与KL散度的方法过程类似,只不过最后采用了余弦距离来计算每条推文与其主题中心的距离。
最大熵
在信息学中,熵(Entropy)常常被用来衡量信息不确定度的大小,信息的不确定度,表明其信息量也越大,同时熵也越大。熵的计算公式如下:
$$Entropy(X) = -\sum_iP(x_i)log_2P(x_i)$$
p: 主题-单词矩阵 entropy = [] for tweet_id,tweet in tweets do topic_id根据文档-主题矩阵得到当前推文最大可能从属的主题序号 cur_entropy = 0 for word_id, each word in tweet do: //word_id 为当前单词在词库中的下标 cur_entropy += -p[topic_id][word_id] * log2 (p[topic_id][word_id]) end for entropy.append(feature) end for 对于每个主题,找到熵最大的推文,该推文即为最具有代表性的推文
情感分析
为什么要进行情感分析?Twitter的作为一个微博客服务,它的推文中又充斥着大量的观点见解,进行情感分析也同样具有广阔的应用场景,比如说以下的这个方面:
- 情感分析可以帮助用户做出是否购买的决策。例如,消费者在犹豫是否购买产品时,会很自然的去查看其他人对于该商品的评价。如果“好评”居多,该消费者可能就会进行购买;反之,如果“差评”占大多数,那么该消费者一般而言就不会进行购买了。如果能针对Twitter这种既有强时效性又有广泛话题领域的社交媒体进行情感分析,那将给用户带来更多的便利。
- 情感分析还可以帮助企业进行市场调研。企业在推出一款新的产品之后,可以通过情感分析来从大量的用户评价中得到有用的信息,如用户喜欢什么,不喜欢哪一方面,对公司的产品和服务有哪些正面或负面的影响。从而企业可以了解自身的优势和不足,可以更好的制定相应的措施进行服务的改进,从而在激烈的市场竞争中占据主动地位。
- 舆情监控。由于用户可以在社交媒体上相对自由的发表自己的观点,这使得社交媒体成为了舆情话题产生和传播的重要方式。通过对社交媒体的情感分析,可以为政府了解民意、引导舆论提供有效的工具。对于负面的消息,可以较为及时的安抚好民众的情绪,避免事态进一步恶化。同时,政府也可以制定相应的策略来改善现有的服务。
- 事件预测。随着互联网发展,越来越多的民众愿意到网上发表自己对某一事件的看法,无论是在诸如Twitter、新浪微博这样的微博客,还是在贴吧、知乎等站点上。一个典型的例子就是最近阿里人工智能运用神经网络、情绪感知等技术对《我是歌手》第四季总决赛的歌王进行了成功的预测。此外,Twitter这一个平台也常常被拿来预测选举、股票等。
情感分析方法
本文采用的情感分析可以说是一个标准的机器学习的分类问题。
目标是给定一条推文,将其分为正向情感、负向情感、中性情感。
预处理
- POS标注
- CMU ArkTweetNLP
- 字母连续三个相同
- 替换 “coooooooool”=>“coool”
- 删除非英文单词
- 删除URL
- 删除@
- 删除用户的提及@username
- 删除介词、停止词
- 否定展开
- 将以”n’t”结尾的单词进行拆分,如”don’t” 拆分为”do not”,这里需要注意对一些词进行特殊处理,如”can’t”拆分完之后的结果为”can not”,而不是”ca not”。
- 否定处理
- 从否定词(如shouldn’t)开始到这个否定词后的第一个标点(.,?!)之间的单词,均加入_NEG后缀。如perfect_NEG。 “NEG”后缀
特征提取
- 文本特征
- N-grams
- 1~3元模型
- 使用出现的次数而非频率来表示。不仅是因为使用是否出现来表示特征有更好的效果 [16],还因为Twitter的文本本身较短,一个短语不太可能在一条推文中重复出现。
- 感叹号问号个数
- 在句子中的感叹号和问号,往往含有一定的情感。为此,将它作为特征。
- 字母重复的单词个数
- 这是在预处理中对字母重复三次以上单词进行的计数。字母重复往往表达了一定的情感。
- 否定的个数
- 否定词出现后,句子的极性可能会发生翻转。为此,把整个句子否定的个数作为一个特征
- 缩写词个数等
- POS 标注为[‘N’, ‘V’, ‘R’, ‘O’, ‘A’] 个数(名词、动词、副词、代词、形容词)
- N-grams
- 词典特征(本文使用的情感词典有:Bing Lius词库 [39]、MPQA词库 [40]、NRC Hashtag词库和Sentiment140词库 [42]、以及相应的经过否定处理的词库 [45])
- 推文中的单词在情感字典个数 (即有极性的单词个数)
- 推文的 总情感得分:把每个存在于当前字典单词数相加,到推文的 总情感得分:把每个存在于当前字典单词数相加,到推文的 总情感得分:把每个存在于当前字典单词数相加,到推文总分,这个数作为一特征。
- 推文中单词最大的正向情感得分和负。
- 推文中所有正向情感的单词分数 和以及 所有负向情感单词的分数和。
- 最后一个词的分数
- 表情特征
- 推文中正向 情感 和负向的表情个数
- 最后一个表情的极性是 否为正向
特征选择
本文 特征选择主要是针对于 N-grams 特征 的,采用方法如下:
设定min_df(min_df>=0)以及threshold(0 <= threshold <= 1) 对于每个在N-grams的词: 统计其出现于正向、负向、中性的次数,得到pos_cnt, neg_cnt, neu_cnt,以及出现总数N,然后分别计算 pos = pos_cnt / N neg = neg_cnt / N neu = neu_cnt / N 对于 pos,neg,neu中任一一个大于阈值threshold 并且N > min_df的,保留该词,否则进行删除。
上述算法中滤除了低频的词,因为这可能是一些拼写错误的词语;并且,删除了一些极性不那么明显的词,有效的降低了维度。
分类器选择
在本文中,使用两个分类器进行对比,他们均使用sklearn提供的接口 。第一个分类器选用SVM线性核分类器,参数设置方面,C = 0.0021,其余均为默认值。第二个分类器是最大熵分类器,其中,设置参数C=0.01105。在特征选择上,min_df=5, threshold=0.6。
实验
- SemEval(国际上的一个情感分析比赛)训练数据和测试数据
- 评价方法采用F-score
- 对比SemEval2016结果如下
测试集名 | SVM(F-score/Rank) | MaxEnt(F-score/Rank) |
---|---|---|
2013 Tweet | 0.701 / 5 | 0.714 / 3 |
2013 SMS | 0.719 / 1 | 0.722 / 1 |
2014 Tweet | 0.693 / 8 | 0.692 / 8 |
2014 Tweet sarcasm | 0.478 / 6 | 0.478 / 6 |
2014 Live Journal | 0.712 / 4 | 0.726 / 2 |
数据可视化
为什么要进行数据可视化呢?因为可以更快速、更轻松的提取出数据的含义。例如
- 将3标注为红色容易找出所有的3
- 画柱状图容易找数组【 321, 564, 1391, 245, 641, 798,871 】中的最大值
简单的统计结果可视化
Hashtag统计
由于Hashtag是用户手动添加的、用来表明当前发表的推文的主题。因此对其进行统计,然后进行可视化也是具有一定意义的。简单的说,进行hashtag统计的可以有柱状图、饼状图、趋势图三种方法。
地理位置信息的可视化
Twitter的API返回字段中,有几个字段是和地理位置相关的,用来表示该推文的发表位置,或者某地点和该推文相关。我们可以对地理位置信息进行统计计数。一个可视化的办法就是在地图上根据经纬度坐标画一个个的点,但是当有多个点再一个小区域的时候可读性较差,因此本文使用的是热力图。一个样例图如下:
话题结果可视化
在LDA主题模型中,输出结果有两个矩阵,其中一个是主题-单词矩阵,这也是本小节要探讨的可视化内容。
为了能够很好的表示出主题以及对应的单词,本文提出可以使用矩形树图(TreeMap)、气泡图(Bubble)、以及旭日图(Sunburst)来表示LDA的结果。
矩形树图
矩形树图是由一个个矩形递归组成的。
同一个颜色表示同一主题,而矩形大小表示概率大小。
在图形交互方面,矩形树图支持点击后放大查看。
气泡图
同一个主题同一个圈,同一个圈内的圆大小表示概率的大小。
在图形交互方面,气泡图支持点击后放大查看某一主题下的内容。
旭日图
旭日图它可以说是饼状图的升级版。在最内圈的数据为每个主题,同时,用不同的颜色加以区分,内圈所占的大小就反映了主题的热度。接着,对于每个主题,向外延伸出对应的主题词,每个主题词占的面积大小就反映了其概率的大小。此外,本文做出了特殊的处理,将主题词中更重要的主题词在加一层显示。
最重要的主题词计算方法为:按主题的概率从大到小排序,然后,从大到小进行遍历,对概率和进行累加,当对某一项i累加后的和大于0.4,则从第一个主题词到第i个主题词为该主题的最重要的主题词。
旭日图的用户交互为,点击某一块区域,则图形变化为某主题下的单词概率分布饼图。
情感分析的可视化
针对于情感分析,我们的任务是对于给定一些推文,判断其实情感类别。在分类结果完成后,我们可以对分类的结果进行统计。可以采用类似于对Hashtag的统计结果进行可视化的方法,如柱状图、饼状图,这里不再赘述。此外,还可以用“仪表盘”的方式来进行可视化。
Twitter数据挖掘平台的设计与实现
本章基于前面几个章节所讨论的问题与相关的算法,设计并实现了Twitter数据挖掘与可视化系统。这个系统主要包含数据抓取模块、数据存储模块、主题分析模块、情感分析模块、WEB模块一共六大模块。开发系统时使用 Git进行版本控制,并且提交到Github这个开源代码网站,方便多个人共同进行开发和维护。
系统的总体框架
本文系统的后端使用了Python的Django框架,前端可视化采用了D3.js和Echarts,除此之外,使用了JQuery + Bootstrap进行用户界面的快速开发。数据存储方面,使用的是MongoDB数据库。
下面是框架图:
数据抓取模块
数据抓取模块的主要功能是根据用户想要追踪的信息,向Twitter发送相应的请求。对于数据挖掘的平台来说,一个健壮的数据挖取模块是十分必要的。这个模块除了应对超过API的限定的速率错误外,各种HTTP的错误也是需要进行处理的。Twitter常见的HTTP错误及应对措施如下:
错误代码 | 错误描述 | 应对措施 |
---|---|---|
401 | 无OAuth验证或验证失败 | 提示进行OAuth验证 |
404 | URI请求不合法或查询内容不存在 | 返回空 |
429 | 超出速率限制 | 等待15分钟继续,或者换另外一个账号继续抓取 |
500,502,503,504 | 服务器错误 | 等一段时间继续,每次错误将等待时间延长,超过一定的错误次数报错。 |
更多的Twitter从错误代码详见 Twitter开发者平台。
数据存储模块
数据存储的功能主要是对于数据抓取模块所抓取的数据进行存储,方便日后的继续研究;以及对存储内容的读取、查询。主要用到了MongoDB数据库。
MongoDB
MongoDB是由C++语言编写的,一个基于分布式文件存储的开源数据库系统。同时,MongoDB也是一种NoSQL(Not only SQL)数据库。
它可以方便的进行数据分片,采用水平扩展的方式,添加更多的节点,来保证服务器的性能,并且成本相对垂直扩展来说更加低廉,同时,它原生的支持Map-Reduce操作。
文献[46]比较了MongoDB和MySQL的优缺点。文献[47]和文献[48]比较了mongodb和关系型数据库如MySQL,MS-SQL数据库的速度,结论是mongodb具有更快的速度。
关系型数据库与NoSQL数据库 数据大小-查询时间对比图如下 [33]
正是由于MongoDB有更好更稳定的性能,且数据格式为JSON和twitter返回的一致。因此本系统选择了MongoDB作为数据库,并采用了索引技术。
数据压缩
MongoDB将数据存储为一个文档,数据结构由键值对(key=>value)组成。MongoDB 文档的存储类型是BSON,它类似于 JSON 对象。字段值可以包含其他文档,数组及文档数组。它不像MySQL之类的关系型数据库,必须先指定好数据表中的列,而可以随意的增加或删除文档中的字段(即关系型数据库中的列),但每一条数据都要保存相应的字段名。
Twitter 返回的原始推文信息是十分庞大的,除了140字符的文字,还有许多其他的字段。若将其展开,其内容将会超过5KB,这大约我们认为的140个字符文字的37倍!并且由于Twitter中有大量的字段经常为空,用MongoDB进行存储时,不管该字段是否为空,都会进行存储,这样一来将占据大量的存储空间,并且其占据的空间与字段长度成正相关的关系。比如说,”in_reply_to_user_id” 一栏往往为空,但是存储中仍会有这个字段。
对此,需要对字段进行删减,只保留一些有用的字段,当该字段为空的时候不存储,且对字段进行重命名操作,减少其长度。
更新后所保留的字段如下表:
字段名 | 原字段名 | 类型 |
---|---|---|
geo | coordinates | array |
date | created_at | date |
like | favorite_count | int |
id | id_str | string |
reply_id | in_reply_to_status_id_str | string |
reply_user_id | in_reply_to_user_id_str | string |
quoted_id | quoted_status_id_str | string |
retweet_id | retweeted_status[‘id_str’] | string |
retweet_count | retweet_count | int |
text | text | string |
use_id | user[‘user_id_str’] | string |
hashtags | entities[‘hashtags’][‘text’] | array |
urls | entities[‘usrls’][‘expanded_url’] | array |
user_mentions | entities[‘mentions’][‘id_str’] | array |
个直观的对比就是1000多万条推文的时候,按Twitter API返回的结果直接进行存储,就有97.906GB的空间。而精简后的只剩下了9.949GB,体积减少了将近90%,但是携带的有用的信息几乎没少,这有利于数据的查询和存储。
主题分析模块
主题的模块主要是对推文数据进行主题的挖掘,这些推文数据可以来自抓取模块中实时获取的Twitter数据,也可以来自数据存储模块中获取历史的数据。通过对数据的实时计算,计算出主题词以及最具有代表性的推文,并按照话题的热度进行排序,返回给前台页面。
对于在线的数据流,本文使用了多线程,一个线程进行调用Stream API请求,一个线程进行WOLDA模型的计算,一个线程负责接收WOLDA的结果。具体的流程如下:
其中,涉及到了线程安全,如从结果队列中取出数据的时候,需要对其进行加锁等。
使用在线数据时,默认对每分钟的数据进行计算。采用一分钟的计算间隔是基于如下几点考虑:(1)若时间过短,那么推文数过少,更新没有太多的意义(2)若设置时间过长,则可能无法第一时间捕捉到紧急的话题等。因此,本文采用一分钟的间隔,这样可以保证话题的实时性又不会有过多无用的计算。
此外,用户可自定义WOLDA算法的相应参数,如时间窗口L,主题数K等。
情感分析模块
情感分析模块调用了抓取模块,将用户待查询的关键字作为参数,然后对Twitter返回的推文进行情感分析。将推文进行情感分析之后,并且返回一些参考的推文在前台展示。
这其中,需要用到之前的情感分析算法,只不过分类器是已经训练好的,只需要对推文进行相应的预测即可。
WEB模块
WEB模块主要作用是用户交互,包括了用户的界面、用户自定义的参数处理、结果的可视化等。
为了改善用户体验,使用了AJAX技术,在获取服务器分析的结果时,添加等待效果。(见 为AJAX添加等待效果)
此外,利用了Google Map API在地图上点击来获取地区的经纬度,方便对某地区进行话题追踪。(见 使用google map API获取经纬度)
界面展示
总结与展望
主要内容总结
- 提出了WOLDA算法,该算法改进自Hoffman的OLDA算法。WOLDA算法使用动态的词库,能更好的处理流式数据并进行周期性的更新,并且该方式资源占用稳定,不随时间的增大而无限的增大,保证效率和对新话题的敏感程度。同时,提出了最具有代表性推文的计算方法,方便对于主题的理解和分析。
- 结合了基于情感词典的方法和基于机器学习的方法,将情感词典作为分类器的一部分特征,在SemEval2016最新的结果中,取得较为靠前的排名。
- 提出了Twitter进行可视化的方法,包括简单的统计、主题模型结果的可视化、情感分析结果的可视化。
- 基于本文中算法和可视化的方法,设计并实现了Twitter数据挖掘与可视化平台。
工作展望
本文所涉及的相关研究仍有不足,为此,以下列出了主要可以改进的内容:
热点话题方面
- 本文WOLDA仍需要手动的指定主题的个数K,这个K值将影响结果的好坏,K如果设置过大,那么原本属于一个主题的将会被拆分成多个主题;若设置过小,则多个主题可能会被合并为一个。为此,需要合适的方法来动态的设置主题个数。
- WOLDA算法本质上仍是一个LDA模型,无法克服LDA对于Twitter这样的的短文本效果不佳的状况。它不能简单的采用LDA-AT的模型进行改进,因为在短时间内,同一作者的推文往往数量极少,因此可能需要对整个模型本身进行重构。
- 推文中有大量的无意义的内容,可以进一步使用命名实体识别(NER)来进行去除。
情感分析方面
- 进一步的提高对于反语分类的精度。
- 可以采用word2vector来代替ngram来表示词的特征
- 情感分析的对象可以不受限于文本,Twitter的图片等多媒体信息也是可以进行研究的。
数据挖掘系统
- 进一步提高系统的稳定性与用户操作的便利性。
- 随着数据的不断增多,对于数据存储,由于采用MongoDB,可以方便的采用数据分片的方式来解决。相应的算法可以考虑移植到Spark上运行,提高对海量数据的运算能力。
除了以上的几个改进方面外,本论文只探讨了Twitter下的数据挖掘,未来可以转向对新浪微博进行相关的研究。
本文的代码已在Github开源: twitterDataMining
Twitter数据挖掘及其可视化,首发于 细语呢喃。