WeiboEvents的设计与实现
WeiboEvents 分析某事件，图中展⽰ 132105 条微博
WeiboEvents 是在⼤三下学期时，也就是2012 年初开始设计的。上完袁⽼师的可视化课程之后，对这个领域有了⼀定兴趣，就加⼊实验室和张昕师兄、王臻皇和李菁⼀起做微博可视化。这个⼯具主要功能就是对单条微博的转发树进⾏可视分析。⼀条微博及其所有转发构成⼀个转发树，我们成之为事件
(Event)，WeiboEvent 这个名称就是由此⽽来。对转发树的分析可以了解到其中的主要参与者、⽤户的⾏为模式，以及是否有⼈为⼲预等等，从⽽对事件有更深⼊的理解。
这⼤概是我做过的最有影响⼒的⼀个项⽬了吧。从今年 9 ⽉改版以来到写这篇⽂章的时候，有 15000 次使⽤记录，2500 个⽤户。从最初发布到现在，这个⼯具已经积累了 3000 个微博事件可视化作品，其中有⼀部分还是很有价值的（具体参见这⾥）。最近在 PacificVis 会议上发表了 Visualization Notes：
WeiboEvents: A Crowd Sourcing Weibo Visual Analytic System
Ren, Donghao and Zhang, Xin and Wang, Zhenhuang and Li, Jing and Yuan, XiaoruProceedings of IEEE Pacific Visualization Symposium (PacificVis 2014) Notes, Yokohama, Japan, 330-334, 2014PDF doi:10.1109/PacificVis.2014.38
这篇⽂章简单地对积累下来的可视化作品进⾏⼀下总结，然后主要从实现的⾓度讲⼀讲这个⼯具的故事。⼤概会回答下⾯⼏个问题：
微博事件⼤概有哪些模式？
如何利⽤ HTML5 技术设计这样的⼀个⼯具？
如何抓取微博数据？
这只是⼀篇⽇志，也不可能写得很具体，就当是⼀些⼼得吧。好久没有更新过这个博客了，也想练习⼀下写作了 :) 今后会时不时地写点什么~
微博传播模式分类
关于这个话题的研究已经很多了。我对这⽅⾯的了解也不多，但很⾼兴能看到有利⽤WeiboEvents 进⾏分析的⽂章，⽐如下⾯这篇：
微博谣⾔是如何传播的 - 揭秘病毒式传播的奥妙
作为⼯具的设计者，我们似乎也要进⾏⼀定程度上的分析，虽然没有传播学研究者那么专业，但对于微博事件的分类还是可以给出⼀些结论的。
⾸先介绍⼀下 WeiboEvents 中四种转发树的表⽰⽅法，如下图：
四种转发树的表⽰⽅法
1. 树状视图：最直观的树形视图，显⽰转发结构。
2. 圆环视图：根据转发量选取⼀些重要节点，把它们每个画成圆环的形状，较⼩的节点分布在圆环
的周围。
3. 帆状视图：横轴表⽰时间，把⼀条微博的所有转发画成帆的样⼦，帆的⾼度由转发量决定。这个
视图可以直观地看到转发随时间的变化。
4. 时间线视图：与圆环视图类似，也根据转发量选取⼀些重要节点，每个节点和它的转发画成⼀条
随时间变化的曲线。这个视图中不能看到单个节点，但可以直观地⽐较重要节点转发的时间模式。
这四种⽅法各有优缺点，分析时应该综合利⽤。
涉及虚假⽤户的事件
虚假⽤户⼀般是由⼀些机器账户，它们听从所有者的控制，可以⽤来增加转发量，使得某个事件看上去很有影响⼒。这种传播的特征是时间上的模式⾮常明显。例如下图：
⼴告事件的传播模式，很多机器账户匀速发送微博，在帆状视图中呈现为⼀些直线
推⼴的作⽤，后⾯的许多⼤号节点⼏乎同时转发
可以看出⼈为痕迹⾮常明显，这样的事件⼀般具有下⾯⼏个可能的特征：
转发速度恒定：因为机器是按照某个固定频率发送微博的。正常的事件，由于受众逐渐饱和，转发速度会随时间明显下降。
转发时间集中，或者中间有明显间歇：这也是机器账户的特点，不同的机器有不同的策略，从⽽看上
去彼此不同，但都和正常的事件有明显的区别。
省份分布均匀：左右两个事件中的⽤户的省份分布⾮常均匀，正常的事件不⼤可能出现这种情况，因为⼈⼝分布、事件发⽣地点等很多原因，不可能分布得⾮常均匀。
转发层级较浅：机器账户⼀般不会刻意去制造⾮常长的转发链。
⾃然的扩散
下⾯图中展⽰⼀个正常传播的事件。其中包含 13 万条微博。传播速度很快，⼤部分是真实账户。
正常传播的事件，13 万多条微博
这样的事件有下⾯⼀些特点：转发层级很多：除了公共账户的影
响，通过朋友关系传播也很重要。
转发树有⼀种⾃相似的结构：每个⼈转发后都可能导致朋友的转发，直到整个⽹络饱和。
省份分布⽐较符合预期：对于全国范围的事件，⼤致和微博⽤户的⼈⼝分布相同。
有故事性的事件
还有⼀些事件⽐较复杂，不光是⾃然传播，⽽是有⼀定的结构，例如下⾯传媒⼤学保安事件中，是围绕某个问题进⾏争论，⽽这场争论被公众关注，因此每条争论的微博都有⼀定的转发量。
传媒⼤学保安事件：被⼴泛关注的争论
⽽下⾯这个“传媒⼤学学⽣约访姚晨”事件没有争论，但在时间上很有趣，显⽰南⼩七发布了约访姚晨的微博，起初转发量不⼤，但⼀段时间以后，姚晨看到了这条微博（或许是通过社交⽹络转发到了姚晨的圈⼦⾥），从⽽带来了巨⼤的转发量。
传媒⼤学学⽣约访姚晨
事件的整体统计
这⾥考察所有⽤户分析过并保存分析结果的事件。可以获得正确数据并得到特征的总共有 1300 个左右。下⾯三张图展⽰所有微博事件的转发层级、粉丝数、关注数所占的⽐例。这三张图的横轴是转发层级、粉丝数、关注数，纵轴表⽰微博所占的⽐例。图表由很多折线构成，每条折线代表⼀个事件中这些属性的分布，⽽这些分布在⼀起⼜构成⼀个分布的分布。
下⾯是对这些事件中分布的特征的统计。可以看出事件的⼤⼩和转发者的关注、粉丝数的分布关系不⼤。省份分布和城市分布可以很容易发现虚假账户，因为它们创建时都是随机选择省份和城市的，所以省份或成分的分布的熵会⽐正常的⼤很多。以上这些图都是⽤我的新项⽬iVisDesigner 画的，过⼀段时间会发布它。基于 HTML5 的可视化近年来兴起的 HTML5 技术使得在浏览
器中实现⼀些复杂应⽤成为可能。作为⼀个可视化应⽤，与传统的⽹站不同，
关注点主要在绘图和界⾯与交互上。因为是刚开始学 HTML5 开发时写的，并⼀直延续⾄今，WeiboEvents 的代码⽐
较混乱，混合了很多种不同的风格，其
中的⼀些设计可能不是那么合理，下⾯是其中我认为值得⼀提的⼏点。
绘图
HTML5 提供了 Canvas 和 SVG 两种绘图⽅法，它们各有优劣。Canvas 是基于位图的，有⼀套绘图命令，⼩⼀些的事件，6 千多条微博
中等⼤⼩的事件，3 万多条微博，⼤号的作⽤不多，主要是⾃然传播粉丝数的分布
关注数的分布
转发层次的分布
转发层次的分布，散点图
横轴：事件微博总数，纵轴：粉丝数的分布，圆的⼤⼩表⽰微博占的⽐例
横轴：对数时间，100 处为原微博发表后 1 天，150 处为 10 天，纵轴：该时
刻发表微博占总数的⽐例的对数。可以看出 1 天以后的微博数⽬突然减少
横轴：事件总微博数，纵轴：粉丝数平均值
横轴：事件总微博数，纵轴：粉丝数标准差
横轴：事件总微博数，纵轴：关注数平均值
横轴：事件总微博数，纵轴：关注数标准差
横轴：省份分布的信息量（熵），纵轴：城市分布的信息量（熵），这个意义不⼤，因为新浪返回的城市的编号必须知道省份才有意义横轴：省份分布的信息量（熵），纵轴：关注数分布的信息量（熵）。省份⼀共有 37 个可能取值，均匀分布的熵是 5.2，因此右边⼀点基本上是平均分布的，疑似是虚假账户
就像常见的的绘图 API 那样，执⾏⼀个命令就绘制⼀个图元。⽽ SVG 则是基于 DOM 模型的，其中每个图元是⼀个DOM 树上的⼀个节点，通过修改这些节点的属性，或者增减节点，可以完成绘图。Canvas 的好处在于绘图效率⽐较⾼，SVG 的好处则是可以交互实现更⽅便。应该⽤哪种当然要由应⽤的性质来决定了。
WeiboEvents 中只使⽤了Canvas。⼀⽅⾯是因为图中节点⽐较多（显⽰过的最⼤的微博数已经可以达到100,000 条），另⼀⽅⾯是需要导出图⽚，这⾥⽤Canvas 会更⽅便，因为Canvas 中的图像可以直接输出成 PNG 格式。为了提⾼交互的效率，WeiboEvents 中⽤了多层的 Canvas。最底下的⼀层是节点和连接，往上⼀层显⽰⿏标指向的节点和⾼亮的节点，在上是⽤户添加的标注等。这样的好处是当⽤户移动⿏标或者⾼亮节点的时候，不需要重新绘制所有点，只要把上⾯两层重绘即可。对于点很多的可视化来说效率提升是极⼤的。当然，这样做程序的逻辑就会⽐较复杂，因为要判断什么时候重绘整个图像，什么时候只需重绘⼀层。
界⾯与交互
HTML5 设计⽤户界⾯⾮常⽅便，只要⽤⼀些div, span等元素，结合CSS 就可以轻松构建各种界⾯元素了。界⾯的编程主要⽤了jQuery 和，在新版本中加⼊了绑定和事件的机制，让代码中的参数与界⾯元素的同步变得更⽅便了。svg和canvas的区别
对于可视化中常见的点击、拖动等操作，这⾥⼤量采⽤异步和函数闭包的⽅式，例如⿏标拖动的实现：
// Start handling a dragging process.
beginDragging(function(x, y) {
// Mouse moving.
}, function(x, y) {
// Mouse up.
});
这样的编程风格很适合界⾯交互的代码，很多参数不需要定义为全局变量，状态的保存和管理⾮常⽅便。Javascript 语⾔⾮常灵活，可以根据需要设计⼀些帮助函数，⽐如这⾥的beginDragging，可以简化很多代码。核⼼的理念就是将常见的程序流程抽象出来，编写（或利⽤已有的）辅助框架，使得代码变得简洁。
节点的选中操作，需要查⿏标位置对应的节点。逐⼀判断当然不是个好办法，⼀种常见的优化⽅法是⽤四叉树(Quadtrees)，不过在WeiboEvents ⾥⾯⽤了更朴素的⽅法，就是建⽴⼀个像素到节点的索引，每个像素保存⼀下它上⾯有哪些节点。这样需要⼀个和像素数⼀样⼤的数组，⽐较占空间，但实现起来⽐四叉树简单些，效率也可以接受。
服务器端
WeiboEvents 的服务器端⽐较简单，主要就是可视化设计的保存与读取，以及访问⽇志的维护。是基于PHP + MySQL 实现的。⽐较⼤的数据，⽐如⽤户上传的图⽚和微博数据，则存储在⽂件系统中，通过hash 来命名并索引。
最近增加了⼀个后台任务的队列管理程序，⽤户可以在服务器上运⾏⼀些⽐较慢的任务，例如更深⼊的数据抓取。
数据获取
数据的获取就是通过新浪微博的API。对于微博的转发树来说，只要调⽤statuses/repost_timeline接⼝即可。当然，其中会有很多问题，⽐如早期的接⼝不提供pid这个参数，因此⽆法直接得到微博的⽗节点，就需要递归地调⽤ repost_timeline 这个接⼝，很耗时间并且浪费请求数。从某个时间开始pid参数被加进来了，因此需要的请求数⼤幅度减少。但也只能得到最新的 2000 条转发。⾄于是怎么抓取到 13 万条转发的，那就只能说是秘密了。
数据可以在服务器端抓取，也可以在浏览器端抓取。为了减轻服务器的压⼒，最初的设计是数据抓取全部在浏览器端完成，并⼀直沿⽤下来。这样的问题是不够灵活，难以实现实时抓取数据和可视化。浏览器端抓取数据完全采⽤异步模式，也就是下⾯这种形式的调⽤。
// Call API
call_weibo_api(url, parameters, callback_function);
当然不能⼀瞬间发送太多的请求，否则有⼀部分会超时，也很容易瞬间将请求数⽤尽。因此设计了⼀个请求队列，调⽤的⽅式还和上⾯⼀样，只是不会马上发送请求，要等前⾯的请求完成以后才发送。另外，错误的处理也很重要，有时微博API 会不返回或返回⽆效的结果，也可能请求数量超过限制，这些都要正确处理，才能流畅地抓取数据。特别是对于WeiboEvents 这样的分析型应⽤，需要的数据量⽐较⼤，需要连续很多次的抓取，因此这⽅⾯尤为重要。
⼩结
本⽂简述了 WeiboEvents 的设计与实现，以及⼀些关于事件的分析。希望对读者有所帮助。Posted on Jan 11, 2014, 07:24 PM, CST
Tags: Programs

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。