论文基于Twitter的社交网络影响力模型化方法研究.docx
《论文基于Twitter的社交网络影响力模型化方法研究.docx》由会员分享，可在线阅读，更多相关《论文基于Twitter的社交网络影响力模型化方法研究.docx（51页珍藏版）》请在冰豆网上搜索。
论文基于Twitter的社交网络影响力模型化方法研究
基于Twitter的社交网络影响力模型化方法研究
目录
1.引言2
2.数据集2
2.1Twitter接口2
2.1.1用户资料采集接口4
2.1.2关系采集接口6
2.1.3Tweet采集接口7
2.1.4接口限制8
2.1.5数据实体描述9
2.2数据收集12
2.2.1随机数据集12
2.2.2纽约数据集13
3.用户活跃规律研究14
3.1统计分析15
3.1.1随机用户活动分析15
3.1.2纽约用户活动分析16
3.2活跃规律分类16
1.引言
2.数据集
研究的数据集由两个部分组成，这两个部分都是通过我的python采集程序调用Twitter的数据接口获取到的。
Twitter应用是微博应用的典型代表，同时Twitter提供了丰富的数据采集接口。
此项研究要求数据集要满足一定的覆盖范围同时也要满足一定的数量。
而Twitter提供的数据接口可以提供大量的实验数据，通过这些接口我可以采集到满足研究目的的数据集。
Twitter用户可以通过点击“关注”来关注自己感兴趣的其他用户，这些“关注关系”是有向的，所有用户的“关注关系”会将他们连在一起组成一个有向图G。
我研究的数据集是G的一个子图。
为了交叉验证实验的结果我采集了两个子数据集，它们一起构成了此项研究的数据集。
第一个子数据集SubSet1是随机选取的G的一个10,000个用户组成的子图
。
在这个子图的基础上我采集了
中所有用户的Tweets、关系和用户基本信息。
Tweets并不是用户发布的所有的Tweets，为了保证数据的有效性我采集的是2013年12月24号至2014年1月24号一个月的数据。
Tweets包含用户发布的，转发的或者回复的所有Tweets。
这些用户来自不同的地方，也就意味着处于不同的时区，有着不同的作息时间，这些随机分布的用户的数据对于我分析用户的活跃规律在时间维度上的变化非常有帮助。
第二个子数据集SubSet2是通过Twitter的StreamingAPI采集到的30,000纽约用户组成的一个子图
。
在
的基础上我们采集了所有用户的Tweets、关系和用户基本信息。
其中Tweets也是包含转发和回复，在SubSet2中我采集的是2013年12月24号至2014年2月28日的数据。
在采集SubSet2时我设置了采集条件“纽约市”，也就是只采集纽约市的用户。
这些用户的地理位置是一样的，也就是他们都属于同一个时区，这些条件随机用户的数据对于我们分析某个地区的用户的活跃规律随时间的变化也是非常有意义的。
大体上介绍完了研究所需要的数据集下面我将详细的介绍Twitter的数据接口和我采集两个数据子集的细节。
2.1Twitter接口
Twitter的数据接口是目前微博应用中最为开放的接口，它提供了多种多样的接口形式去共享他们的数据。
Twitter的数据接口分为两类：
RESTAPI和StreamingAPI。
这两类API还有以下几个不同之处：
1.通过RESTAPI采集到的是历史数据，而StreamingAPI采集到的是Twitter的内置随机方法随机返回的约1%的实时数据。
2.调用RESTAPI采集tweets时需要指定用户的ID标示，而StreamingAPI可以自动的返回实时随机数据不需要指定用户的ID，但是需要指定查询条件：
地理位置或者关键字。
3.StreamingAPI需要在采集过程中保持常连接而RESTAPI则不需要。
这两个接口的内部实现机制是不同的。
比如一个用户向一个web应用请求数据，那么web应用会向Twitter的API发送请求，如果web应用调用RESTAPI那么整个交互流程如下：
而如果调用StreamingAPI那么web应用就无法与Twitter直接建立连接，而是只能与维护Streaming连接的另外一个单独的进行去连接。
这个进行处理web应用的请求，通过查询条件将从Twitter得到的tweets进行过滤、筛选或者整合然后返回处理的结果。
交互流程如下：
StreamingAPI可以实时返回满足查询条件的用户的1%左右的信息。
详细的说，如果我调用此API去采集用户的Tweets同时指定用户的地理位置为纽约市，那么此API接口会随机返回实时的正在发布tweet的1%的纽约用户的Tweets。
这个1%是一个粗略的比例，同时也是随机选择的，也就是说这个比例在实际采集中可能会高也可能会低。
但是StreamingAPI的优势就是它的随机特性。
根据《ISthesamplegoodenough》的研究结果可以知道StreamingAPI可以用来对Twitter的数据进行随机，更详细的说就是通过这个借口采集到的用户以及他们的tweets在地理位置、话题分布、好友数量分布、粉丝数量分布、影响力分布等各种指标下都有不错的随机效果。
鉴于RESTAPI和StreamingAPI的特点，我的数据采集主要步骤是先用StreamingAPI随机选择符合一定条件和一定数量的用户，然后再调用RESTAPI去采集这些用户的关系、tweets、个人资料等信息。
而实际上很多研究者都是这么做的。
因为Twitter官方在2013年10月发布的数据显示Twitter活跃用户超过2亿，而同时这些用户每天发帖的数量超过4亿条。
面对如此巨大的关系网络和数据量，研究者只能是合理的抽样，选择符合研究目的的子数据集。
下面我将详细的介绍我在数据采集过程中使用到的关键接口。
2.1.1用户资料采集接口
Twitter用户信息指的是用户的个人信息，如好友数、粉丝数、发帖数等。
采集用户的这些信息需要随机选择用户，然后再去采集用户的个人资料。
下表列出了这两个采集步骤中使用到的接口方法：
任务
接口类别
方法
随机选择用户
StreamingAPI
POSTstatuses/filter
GETtatuses/sample
采集个人资料
RESTAPI
GETusers/lookup
GETusers/show
POSTstatuses/filter方法是StreamingAPI类型的，它返回满足过滤条件的1%的实时tweets数据。
这个方法有多个参数，当调用时必须指定其中一个参数否则无法对数据进行过滤。
关键参数列表如下：
参数名称
描述
follow
逗号分隔的用户ID列表，用以指定返回指定用户的tweets。
track
逗号分隔的关键字，用以过滤tweets，只返回包含关键字的tweets
locations
坐标，如-74,40,-73,41是纽约市的坐标范围
这三个参数可以同时指定，如果同时指定的话三个参数之间是“或”的关系而不是“与”的关系，且至少需要指定其中的一个参数。
在采集过程中我会使用此方法来随机的选择用户。
具体的使用过程我会在下面的章节中介绍。
GETtatuses/sample方法也是StreamingAPI类型的，它返回一个随机的样本空间。
这个样本是根据所有的公共tweets抽取出来的，不同的用户或者应用调用这个方法得到的结果是相同的。
相比POSTstatuses/filter方法，即使两次调用的参数都是相同的返回的结果也会不相同。
此方法不需要指定参数。
GETusers/lookup方法是RESTAPI类型的，它返回包含详细的用户资料的用户对象，每个请求可以查询至多100个用户的信息。
当查询用户的数量很大时此方法可以大大减少查询的次数。
此方法的关键参数参考下表：
参数名称
描述
screen_name
逗号分隔的用户名称列表，用以指定需要查询的用户
user_id
逗号分隔的用户ID，用以指定需要查询的用户
这两个参数可以同时指定，如果同时指定则两个参数之间是“或”的关系，而且在每次查询中这两个参数至少指定一个。
GETusers/show方法相当于GETusers/lookup方法的简单版本，它一次只能查询一个用户的信息。
这两个方法的参数相同，GETusers/show方法通过指定screen_name或者user_id来查询所需信息。
2.1.2关系采集接口
关系采集接口用来查询用户的“关注关系”。
基于这些关系我可以创建有向的关系图，挖掘关系子图等。
用户的“关注关系”让社交网络中的用户相互建立了联系，是信息传播和沟通的关键数据。
在Twitter提供的API中采集关系数据有不同的方法，下面要介绍的两个方法是最有效的。
任务
接口类别
方法
采集关系数据
RESTAPI
GETfriends/ids
GETfollowers/ids
GETfriends/ids方法返回指定用户的所有好友的ID，结果会分多个组返回，每个组5,000用户ID，每一个组相当于一页。
此方法的关键参数参考下表：
参数名称
描述
screen_name
需要查询用户的名称
user_id
需要查询用户的ID
cursor
查询的页码，当需要分页查询时使用。
默认为-1，即第一页。
“好友”是指某用户关注的那些账号，而“粉丝”是指关注某用户的那些账号。
如果两个用户之间相互关注那么通过此方法查询可以得到两条记录。
例如用户A关注了用户B，同时用户B关注了用户A，那么调用GETfriends/ids方法并指定查询用户为A时会返回B，而当指定查询用户为B时则会返回A。
GETfollowers/ids跟GETfriends/ids方法类似只不过返回的是粉丝的ID，结果的返回格式和参数都跟GETfriends/ids方法相同。
同样如果存在相互关注关系，此方法也会返回两条记录。
这两个方法的返回结果都具有时间顺序：
最新建立的关系优先返回。
2.1.3Tweet采集接口
在应用Twitter中，Tweet指“帖子”，也指“状态”，同时也是我们普通意义上所指的“微博”。
Tweet的采集接口分两类一类是实时数据的采集接口也就是StreamingAPI类型的，另一类是历史数据采集接口也就是RESTAPI类型的。
任务
接口类别
方法
Tweets采集
StreamingAPI
POSTstatuses/filter
RESTAPI
GETstatuses/user_timeline
POSTstatuses/filter方法在2.1.1章节中已经详细介绍过，此方法可以实时的返回符合过滤条件的tweets，只不过这部分tweets只占当前时刻tweets总量的1%左右。
GETstatuses/user_timeline方法是采集tweets的最有效的方法。
此方法会返回指定用户的某个日期之后的所有tweets，但此方法有数据上限的限制：
3200条。
该方法返回的tweets按照发布的时间进行了排序，最新发布的优先返回。
而且结果中包含转发和回复的tweets。
此方法的关键参数参考下面的参数列表：
参数名称
描述
screen_name
需要查询用户的名称
user_id
需要查询用户的ID
since_id
限制结果返回id大于since_id的那些tweets，所以此参数可以配合max_id用来限制采集某个时间段的tweets
max_id
限制结果返回id小于max_id的那些tweets
count
指定返回tweets的数量
exclude_replies
是否去除“回复”，默认为false
include_rts
是否包含“转发”，默认为true
2.1.4接口限制
Twitter在数据共享的同时为了避免服务器的压力，同时也处于隐私的考虑对所有的RESTAPI类型的方法做了速率限制和数据限制。
除此之外当用户设置了不共享自己的数据时，通过所有的结果我们都不会采集到这些用户的任何数据，这就是我在下个列表中列出的“权限限制”。
Twitter的API以15分钟为一个时间间隔对请求的次数做了速率限制。
对于基于GET的方法限速一般是每15分钟不超过180次请求。
对于我在上面章节中介绍到的方法的限制参考下表：
方法名称
接口类型
速率限制
数据上限
权限限制
POSTstatuses/filter
StreamingAPI
无
无
有
GETtatuses/sample
StreamingAPI
无
只返回固定的随机样本。
有
GETusers/lookup
RESTAPI
每15分钟至多请求180次
一次只能查询100个用户的信息
有
GETusers/show
RESTAPI
每15分钟至多请求180次
一次只能查询一个用户的信息
有
GETfriends/ids
RESTAPI
每15分钟至多请求15次
一次只能查询一个用户的信息
有
GETfollowers/ids
RESTAPI
每15分钟至多请求15次
一次只能查询一个用户的信息
有
GETstatuses/user_timeline
StreamingAPI
每15分钟至多请求180次
一次只能查询一个用户的信息
有
上面的这个列表中的所有限制都是针对一个用户来说的。
想要采集Twitter的数据必须要注册Twitter研发者账号，创建自己的项目并且申请采集权限。
如果研发者可以注册多个账号那么这些限制就可以在一定程度上缓解，但需要注意的是2014年2月后Twitter要求普通用户必须要绑定手机号码才可以申请研发者账号。
2.1.5数据实体描述
通过前面2.1.1到2.1.3章节描述的API接口可以采集到两种数据实体：
微博（tweet）和用户信息（user）。
下面我将详细介绍Twitter的API返回的这两种类型的数据实体的格式和各个关键字段的含义。
Tweet实体的关键字段参考下表：
字段
类型
描述
id_str
String
Tweet唯一标示
text
String
UTF-8格式的原文
source_url
String
Tweet的来源，如手机,网页
retweeted_status
String
如果被转发这个字段表示上一条Tweet的id
created_at
String
创建时间（UTC）：
"WedAug2713:
08:
45+00002008"
in_reply_to_user_id_str
String
如果Tweet是“回复”，该字段就是被回复用户的id
in_reply_to_status_id_str
String
如果Tweet是“回复”，该字段就是被回复Tweet的id
favorite_count
Integer
被其他用户喜欢的次数
user
User
发布Tweet的用户信息，User实体包含的信息参考下面对它的解析
lang
String
语言，如果是英语则为：
”en”
entities
Entities
这是一个Entity实体包括的具体内容参考下面对它的解析
retweet_count
Int
被转发的次数
User实体的关键字段参考下表：
字段
类型
描述
id_str
String
User唯一标示
followers_count
Int
粉丝数量
listed_count
Int
用户所属的公开用户组的个数
friends_count
Int
好友数量
statuses_count
Int
所发微博的数量
location
String
地理位置，如”SanF,CA”
utc_offset
Int
用户所处时区与UTC时间的时差
name
String
用户名称
lang
String
语言，如果是英语则为：
”en”
favourites_count
Int
被“喜欢”的次数
在Tweet实体内部有一个内部实体Entities，Entities实体的关键字段参考下表：
字段
类型
描述
hashtags
ArrayofObject
Tweet实体中text字段里如果含有“#”形式的hashtag会包含在本字段中
media
ArrayofObject
保存随Tweet上传的媒介信息，如手机、web网页等
urls
ArrayofObject
Tweet实体中text字段里如果含有url会包含在本字段中
user_mentions
ArrayofObject
Tweet实体中text字段里如果含有“@”形式的内容提到其他用户，则被提到的用户会包含在本字段中
2.2数据收集
在数据收集这一节我主要介绍如何利用2.1章节中介绍到的Twitter的API去采集项目研究需要的两个数据子集：
随机采集一定数量的用户以及相关的信息和固定采集一定数量某个地方的用户以及相关的信息。
2.2.1随机数据集
最终经过2周的采集我采集到了9541个用户及其他们的资料、751468条关系和3560513条tweets（其中603590条转发和792390条回复）。
在后面的章节中我们统一称此数据集为DataSet1。
伊利诺伊大学香槟分校计算机科学部门的KevinChen-ChuanChang,RuiLi,和ShengjieWang三位研究者在他们的研究中共享了他们采集到的部分数据。
他们共享的数据集是Twitter的一个子集，包含28亿的关联关系、300万用户的资料和5000万的tweets数据。
同时他们还共享了一个他们在研究中使用的一个子数据集：
10万用户及其他们的关系和tweets。
该数据集采集于2011年5月份。
由于用户的资料和tweets数据已经过去很久了，不利于我的研究，所以我只取了他们的关系数据并在此基础上挖掘了一个1万人组成的子网。
然后基于此关系网我采集了相关用户的资料，更新了他们之间的关系，采集了2013年12月24号至2014年1月24号的tweets数据。
关系子网的挖掘我采用了一种简单的归并式的挖掘方法。
主要的思想就是假设现在有一个子节点集NodeSet，它们构成了一个图（并不一定连同）。
当去检查一条新的边L时，如果L的起点或者终点在NodeSet中那么就把另外一个点也加入到NodeSet中。
具体的算法如下：
Algorithm1:
L<-alledges
NS<-nodesetsofedges
S<-subsetofnodes
for
inL:
=nodesof
S=
whileScontainsnodeslessthan10,000:
for
inNS:
if
:
delete
fromNS
else:
S=
S=themax
通过Algorithm1我确定了需要采集的用户的id集合，然后调用Twitter的RESTAPI中的方法去采集这些用户的资料、Tweets、关系等数据。
这些数据共同构成了DataSet1。
某些用户的数据无法采集的原因是他们设置了数据隐私。
在后面的章节中我会基于此数据集去做一些研究，当然也需要对这些原始数据进行合理的预处理，这些内容我会在下面的章节中具体使用时给出详细的介绍。
2.2.2纽约数据集
通过2.2.1章节中的采集我得到了不区分用户地理位置的1万用户的数据。
由于本项目研究的是用户的活动习惯在时间维度上的规律，那么用户所处的地理位置或者说时区就会对实验产生很大的影响，所以为了进行全面而且详尽的分析我又采集了这个数据子集。
在后面的章节中我们统一称此数据集为DataSet2。
本数据子集包含的用户都来自同一个地方：
纽约。
此数据子集的采集过程和2.2.1章节中的有很大不同，主要包含一下几个步骤：
Step1：
随机获取位于纽约市的8万个用户的id
Step2：
采集这8万个用户的关系
Step3：
根据用户关系挖掘一个3万用户组成的子关系网
Step4：
采集子关系网内每个用户的资料、tweets。
我们知道Twitter是一个面向全世界开放的平台，所以很多用户关注的人来自很多不同的地方，所以如果我们直接随机获取位于纽约市的1万个用户的话，我们会得到一个非常稀疏的关系网，而且包含很多孤立的子网。
这种数据不利于我后面的研究，所以我在step1中随机获取了8万用户的id，如此这些用户组成的网络就比较稠密，同时我在step3中挖掘出的关系子网也就不会包含孤立的点。
在Step3中我用来挖掘子关系网的算法就是2.2.1章节中的Algorithm1。
这个数据集的采集过程由于TwitterRESTAPI对速率的限制会持续1个月左右。
主要是Step2采集用户关系这一步，调用的方法是RESTAPI中的GETfriends/ids方法。
这个方法的速率限制是15次/15分钟。
所以8万个用户的关系即使在创建了10个账号并行采集的情况下也很耗时。
通过1个月的采集我获取了27192个用户以及他们的资料、217873条关系和xxxx条tweets（其中603590条转发和792390条回复）。
少数无法采集到数据的用户也是由于他们设置了数据隐私。
3.用户活跃规律研究
在这一章节中我将会从统计学的角度对用户活动在时间维度上的规律进行研究。
用户是指Twitter中的注册用户，用户活动是指Twitter用户的发布、转发和回复活动。
对于大部分用户来说—当然有一部分用户可能是机器人--他们在现实世界中都是一个普通的人，他们都有自己的作息规律。
生活在不同地方的人可能会有不同的生物钟，而从事不同职业的人也会在Twitter中体现他们的作息规律。
而这些规律就体现在他们在Twitter中的活跃规律中。
具体的来说，我所研究的重点是这些活动在时间维度上的规律，下面就简称为活跃规律。
用户的不同活跃规律会影响信息的传播，影响好友之间的沟通和交流。
我们知道在现实社会中我们往往会因为某些朋友在加班或者出差而取消我们的聚会，或者说因为某些朋友很忙而很少听到他们的消息。
也就是说，很多时候人与人之间这种不同的活跃规律会在一定程度上影响我们之间的沟通和交流。
而作为一个社交网络，最重要的功能就是提供一个信息传播的平台。
那么在社交网络中会不会也是如此呢？
用户之间的活跃规律的差异到底会对信息的传播、影响力有多大的影响呢？
在回答这些问题之前，让我们首先来了解一下用户的活动到底有哪些规律吧。
3.1统计分析
在这一小节中我将通过统计分析的方法对用户的发布、转发、回复活动在时间维度上的规律进行一个详细的分析。
由于我在数据收集阶段准备了两个数据集：
随机用户数据集和纽约用户数据集。
随机用户数据集中的用户可能来自很多不同的地方，处在不同的时区，有着不同的作息规律。
而纽约用户数据集的用户都来纽约市，他们处在相同的时区。
通过对这两个数据集的分析我们就可以全面，详细的得知不同用户之间的活跃规律是怎样的。
3.1.1随机用户活动分析
我分两个角度统计了用户的活跃规律：
在每天的不同小时里活动的规律和在不同周天（一周中的某一天）里的活跃规律。
当按照小时统计时我将以小时为最小时间单位统计用户在过去的某一段时间里平均在每个小时的活跃程度，那么时间维度就是24维（每天都是24小时）。
同样当按照周天统计时，我将以周天为最小时间单位，那么时间维度就是7维（每周都是7天）
升级会员 