IT瘾twitter推荐

聊聊Twitter的架构决策

Sat, 04 Jun 2022 00:00:00 CST

Twitter有两条时间线：

用户时间线：用户自己所有推文的集合，从磁盘中获取。
主页时间线：用户关注的人的推文的集合，组成了用户的主页。

在设计数据库时，最简单的数据库只是将所有写操作附加到文件的末尾，并在需要时读取。没有什么比简单的附加到文件中更快的了，但是，随着数据库文件的增长，从这种类型的数据库中查询某些内容将花费很长时间。

为了减少查询时间，我们在其中添加索引。但是添加索引将意味着写入将花费更长的时间，因为必须在将其写入数据库之前编辑索引。但由于读取的数量将远远多于写入的数量，这是一种公平的权衡。

同样，Twitter的阅读量也远远超过了写入量。所以他们构建了一个系统，可以更好的为用户的主页时间线服务。他们预先计算出所有用户的主页时间线，并将其存储在Redis集群中。就这么简单！

现在，无论用户何时发布消息，该消息都会被插入每个关注者的时间线队列中。所以如果你有5000个粉丝，你的推文就会有5000个写操作！外加上1个数据库本身的写操作

这听起来很疯狂，但你仔细想想，这是有道理的。现在可以同时为数百万用户提供服务而不需要访问磁盘，这可以从根本上减少延迟。这个过程叫做扇出（fan-out）！

那么到目前为止，Twitter的架构是怎样的呢？
用户访问Twitter的主页。
Twitter在Redis集群中查找用户的主页时间线。
一旦找到，就向用户直接展示。

当用户发送一条推文时，该推文会被复制到用户的所有关注者的时间线上。

还有一些其他的细节：

Twitter维护了一个图数据库，其保存了用户关注关系的所有数据。当发生扇出时，扇出服务查询这个图数据库以确定将推文推送到何处。
扇出将在数据中心的3台不同的机器上进行复制，即每个用户的时间线存储在3台不同的机器上。这是必需的，因为如果其中一台机器出现故障，其他机器可以作为备份提供服务。
推文本身并不存储在集群中，而只存储推文ID。推文将在传递给用户的同时被检索出来。
如果用户超过30天没有登录Twitter，该用户的时间线将不会保存在Redis集群中。对于这类用户，只有当他们返回并向主页时间线发出请求时，才会从磁盘重构他们的时间线。

每个用户的主页时间线上存储的推文数量是有限制的，每次只向用户显示800条推文，这是为了控制内存使用而做出的设计决策！

从0开始设计Twitter系统架构

Mon, 20 Dec 2021 00:39:18 CST

【编者的话】Twitter是全球最大的社交网络之一，如果让我们从0开始设计twitter的系统架构，该怎么做呢？有哪些服务是必须的？有哪些点需要提前考虑？这篇文章简单介绍了设计类twitter系统的思路并在最后给出了参考设计。原文： Twitter System Architecture。

Twitter是全球领先的在线社交网络服务，用户可以在这里发布和阅读被称为“推文（tweets）”的短消息。在系统架构设计面试过程中，当被问及如何设计Twitter时，大多数候选人都会将其设计为单体服务。然而，将Twitter这样的大型服务设计为单体，表明候选人缺乏设计分布式系统的经验。从微服务甚至lambda（或函数）的角度来设计分布式系统在今天是很正常的选择。目前的趋势是，没有人会将新服务设计为单体，公司正逐渐将其庞大的单体服务转换为一组微服务。因此，候选人应该以微服务的方式设计Twitter。

功能需求

用户可以发布或分享新的推文（tweet）
每条推文最多不超过140个字符
用户可以删除推文，但不能更新/编辑发布的推文（写操作）
户可以标记喜欢的推文（写操作）
用户可以关注或取消关注另一个用户（写操作），关注一个用户意味着用户可以看到其他用户在他的时间线上的推文
可以生成两种类型的时间线（读操作），用户时间线由他最后N个推文组成，主页时间线由他正在关注的用户的热门推文按照时间降序生成
用户可以根据关键字搜索推文（读操作）
用户需要有一个帐户来发布或读取推文（暂时使用外部身份服务）
用户可以注册和删除帐户
Twitter支持包含文字和图片/视频的推文，但在我们当前的设计中，将只支持文本
分析/监视服务，以确定其负载、运行状况和功能
分析还可为用户提供关于关注谁、推文通知、热门话题、推送通知和分享推文的意见或建议

非功能需求

服务的高可用是最重要的需求，这意味着用户可以在自己的主页时间线上阅读推文，而感受不到任何停顿
生成时间线的时间最长不得超过半秒
不需要强一致性，只需要最终一致性，可以使用关键词数据库用于搜索基于关键词的推文
随着用户和推文的增加，系统负载也在增加，因此系统应该具有可伸缩性
持久化用户数据

现在我们来做一些计算。

日活跃用户平均请求/天 = 150M*60/86400 = 100k/秒
峰值用户 = 平均并发用户* 3 = 300k
三月内最大峰值用户数 = 峰值用户数*2 = 600k
读QPS = 300k
写QPS = 5k

twitter服务的概要设计

由于系统的复杂性，可以将其划分为若干个服务，其中包括若干个微服务。

推文服务（Tweet service）
用户时间线服务（User timeline service）
扇出服务（Fanout Service）
主页时间线服务（Home timeline service）
社交网络服务（Social graph service）
搜索服务（Search service）

下面是Twitter服务中不同逻辑组件或微服务架构。

twitter服务的详细设计

所有微服务都可以被称为模块。

推文服务（Tweet service）

接收用户推文，转发用户推文到关注者时间线和搜索服务
存储用户信息，推文信息，包括用户的推文数量以及用户喜欢的状态
包括应用服务器、分布式的内存缓存以及后端的分布式数据库，或者使用直接由数据库（例如Redis）支持的内存缓存

然后我们看一下tweet服务的数据库表结构。

用户（Users）表包含用户的所有信息，推文（Tweet）表存储所有推文，Favorite_tweet表存储了喜欢的推文记录，也就是说，每当用户喜欢一条推文时，就会在Favorite_tweet表中插入一条记录。

生成唯一的推文Id

当用户调用postTweet()时，调用会发送给应用服务器。应用服务器为该推文生成一个唯一的id，同样的机制也可以用来为推文生成短URL。另一个方式是基于应用服务器的UUID（Universally unique identifier）。推文ID生成后，应用服务器将该推文插入分布式缓存和数据库的tweet表中。由于需要在执行推文的创建/更新/删除操作的同时更新缓存和数据库，所以我们使用缓存透写机制。

可扩展性设计

我们可以将分布式缓存和数据库划分为多个分区和副本。

基于用户ID分片
基于推文ID分片
基于用户ID和推文ID进行两层/级别分片

社交网络服务（Social graph service）

实现Following API，跟踪用户之间的关注关系
包括应用服务器、分布式缓存和数据库
用于存储用户关系的数据库表结构

Following API：

将被关注用户的时间线异步合并到关注者的信息事件流中
取消关注一个用户后，从关注者的事件流中异步删除他的推文
异步的从信息事件流中挑选推文
之所以需要异步操作，是因为这个过程比较慢，而用户在关注和取消关注其他用户时，希望很快得到反馈
异步的缺点是用户在取消关注后，如果刷新信息事件流，会发现这些信息仍然存在，但最终它们会被删除

用户时间线服务（User timeline service）

返回用户的时间线，以降序排列的方式包含用户所有推文。此服务可用于主页时间线或其他用户的时间线。
该服务包括应用服务器和分布式内存缓存，但没有涉及该服务的数据库。
用户时间线是使用包含用户推文链接列表的数据结构设计的

当用户发布一条推文时，tweet服务调用用户时间线服务，将该推文插入到用户时间线的推文列表顶部，运算复杂度为O(1)。
此外，分析仪表板可以配置参数K，表示可以保留的推文个数，K默认为1000，表示保留用户时间线轴中的最后K条推文。
在用户时间线列表中，推文按creationTime（创建时间）降序存储。当用户时间线列表达到最大K条推文时，最老的条目将被删除。

扇出服务（Fanout Service）

将新推文转发到搜索和主页时间线服务，以及其他组件/微服务，比如趋势服务或通知服务
由多个分布式队列组成
当用户发送一条推文消息时，该服务把消息放入推文队列，社交网络服务必须获得用户的关注者列表，并在第二组队列中插入尽可能多的消息。对于名人用户来说，他们拥有非常多的粉丝，其粉丝数甚至超过了每次推送的阈值。那么，如何处理这个问题呢?
该服务是一个先进先出的任务队列列表，处理共享相同列表的任务，并在完成后反馈给队列服务器。队列服务器是异步任务的重要组成部分，其执行的任务可能不会立即收到响应，但却能够保证最终一致性。

主页时间线服务（Home timeline service）

显示用户的主页时间线
包括来自其他关注的用户的推文，按照推文的creationTime（创建时间）降序显示。
其设计类似于用户时间线服务。
但是比用户时间线服务稍微复杂一点，因为用户将插入最新的推文，并且当推文数量超过K值时需要删除最老的推文，如果用户关注了很多其他用户，服务还需要一些机制来给不同关注用户的推文赋予不同的权重。

搜索服务（Search service）

为用户提供搜索查询服务
扇出服务将推文传递给搜索服务

Ingester（或ingestion engine）：给推文标记上许多标签、术语或关键字。例如这条推文：“我想成为像亚马逊的杰夫·贝索斯一样非常富有的人”，它会过滤掉那些在搜索中没有用的词。除了杰夫·贝索斯（Jeff Bezos）和亚马逊（Amazon），所有其他词都将被丢弃。Ingester可以通过配置或数据库获得词汇表。
一个叫做“词根提取（stemming）”的过程对剩下的单词进行分析，以确定它们的词根。Stemming是处理词干、词根或词根的词形变化(或派生)的过程。因此，会在数据库中保存一个查找表。这种方法的优点是可以简单、快速、轻松的处理异常。缺点是新的或不熟悉的单词即使是完全符合规则的，也不会被处理。
传递到搜索索引
搜索索引微服务将创建反向索引，并存储从内容(如单词)到其所在文档或一组文档中的位置的术语映射索引，在我们的例子中，这是一个或一组推文。
Blender服务：在twitter平台上为用户提供搜索查询。当请求搜索查询时，首先确定搜索条件，然后进行词干分析，最后使用词根在术语的倒排索引上运行搜索查询。

照片和视频

使用NoSQL数据库
媒体文件（使用文件系统）
数据表格式

Twitter的网络

Twitter的最终详细设计

系统设计：

数据架构：

译文链接： https://mp.weixin.qq.com/s/v08_YF78Im-Z_Qy8iX3yMQ

Elon Musk 在 Twitter 上发中文七步诗

Tue, 02 Nov 2021 19:13:53 CST

“Humankind，煮豆燃豆箕，豆在釜中泣。本是同根生，相煎何太急。”当一首家喻户晓的中国七步诗突然出现在特斯拉首席执行官马斯克（Elon Musk）的推特与微博平台上，人们随即开始对其深意众说纷纭。有网友认为，马斯克是在回应近期被联合国官员“逼捐”一事。有网友表示，马斯克是在暗指近期火热的狗狗币（Dogecoin）和柴犬币（Shiba）（柴犬币市值刚刚超过了狗狗币），该七步诗的内容实则为“煮doge燃doge萁， doge在釜中泣。”上周，联合国世界粮食计划署负责人比斯利（David Beasley）曾呼吁超级富豪帮助解决世界饥饿问题，并公开点名马斯克。“用 60 亿美元来帮助全球 4,200 万人，如果我们不伸出援手，他们就真的会死去。这并不复杂。”马斯克随后在微博和推特两个平台发文回应称，“如果世界粮食计划署（WFP）能准确说明 60 多亿美元将如何解决全球饥荒问题，我会马上卖掉特斯拉的股票，然后去捐款。“但它应该公开账目，让公众清楚地看到这些钱是怎么花的。”马斯克强调。

[分享创造] 开源一个类微博 twitter 的网站

Thu, 23 Jan 2020 21:13:30 CST

网址： https://sserr.net

代码： https://github.com/coyove/iis

之前的发布： https://v2ex.com/t/628871

时隔一个多月，当初的 todo 基本上都清掉了，代码也重构到了开源出去也不会太丢人的程度 XD。

总的来说这是一个类微博的系统，提供了大部分你所熟知的微博功能。时间线合并（ timeline merging ）采用读扩散，所以可以轻松的支持热点用户推文分发至海量 follower 的情况。回复 /@/收藏等则是写扩散。

后端采用纯 KV 形式存储，目前有两种实现（ dynamodb 和基于本地文件系统）。KV 不要求事务支持，所以理论上任何支持 set(k, v)和 get(k)的 IO 都可以用作存储驱动。（ dynamodb 会有 stale read，要解决这个问题需要本地缓存，如 redis ）

由于该架构设计特点，（以 dynamodb 为例）当一个账户 follow 的其他账户数目超过 10000 时合并延迟和性能会受比较大影响。但在另一方面，时间线合并的负担绝大部分在客户端，所以对于后端来说没有任何压力。

FBI希望Facebook和Twitter开发威胁预警工具

Tue, 13 Aug 2019 07:01:13 CST

PingWest品玩8月13日讯，据Gizmodo报道，美国联邦调查局（FBI）希望Facebook和Twitter等科技公司开发一种工具，可以监控其社交平台上的各种威胁。近日，FBI发布了一份“征求建议书”，称该机构希望拥有一款“社交媒体早期预警工具”，帮助他们追踪恐怖分子、犯罪组织等对平台的使用情况。

这份建议书显示，FBI计划拥有一款工具，允许所有FBI总部和外地办事处，或通过FBI发布的移动设备随时接入（这款工具），以监测这些社交平台的动态。

这款工具将允许FBI工作人员访问人们的电子邮件地址、电话号码、IP地址、用户ID和相关帐户。还允许他们创建过滤器和自定义警报，能让他们在社交媒体上发生“任务相关”活动时接收通知。

对此，Twitter发言人向Gizmodo表示，Twitter会积极配合执法部门的调查活动，但禁止将应用程序编程接口（API）用于监视用户活动。

人民日报发布 Twitter 和 Facebook 欢迎 Google 回归

Tue, 07 Aug 2018 13:00:00 CST

刚得到消息，人民日报在 Twitter 和 Facebook 上发文，欢迎 Google 回归中国，不过要遵守中国法律。这是上周 the Intercept 放出消息 Google 将要回归之后，人民日报首次做出的回应，也是非常重要的肯定。
尽管像上篇讲的，国外民众对 Google 的此举非常有意见。但国内政府和 Google 双方都非常有意愿，毕竟各自都有强烈的需求。
国内面对的是 Android 市场的混乱，以及中文搜索的混乱。
而 Google 想要的是国内的巨大市场。
我认为这是双赢的机会，是肯定会发生。去年跟 Google 的朋友交流，就透露出已经开始了各种接触。
以下是人民日报在 Facebook 上发表的长文。用 Google 翻译得到的结果基本看不出来机翻的痕迹。

深度剖析：Twitter怎样支持上亿用户 - 个人文章 - SegmentFault

Mon, 15 Jan 2018 20:09:54 CST

谈到设计Twitter, 我们首先要问一个本质问题：设计Twitter的基本方法论是什么？

其实是我们计算机设计最基本的方法：分治法（Divide and Conquer）。

什么是分治法呢？就是把问题不断的拆解，拆解到你可以解决为止，它的艺术在于，从哪个维度来拆解非常考验我们能力。

你的架构是什么样的呢？

相信你一定不会给出复杂的架构。前端是各种各样的业务逻辑，后端是MySQL数据库，这样就够了。因为这已经解决了当时的问题，满足了一周开发出来的要求。

但随着Twitter的成长，我们会遇到各种各样新的挑战：

MySQL难扩展。
为什么难扩展？因为它把同样的一个数据分成各种关系存在里面，每次取的时候，都要通过Join来进行复杂的操作，这个Join当数据被切分的时候存在更多的服务器上，会变得越来越复杂，所以很难扩展。
小变化也要全部部署。
任何变化都需要部署到所有机器上，因为服务不断升级，就变成了每天不断部署，变成了daily deployment。所以每次部署的时候耽误时间很长。
性能差。
因为所有服务都要部署在一起，造成了它的内存占用率大，而且部分核心模块还因为最初当时的单线程设计成为了各种瓶颈。
架构混乱。
因为所有模块在一起很混乱。
那要怎么破解这些问题？

答案是将问题拆解开来。

第一刀将存储切开。

我们看后台，可以拆成存Tweets，存User，存Timeline，存Social Graph不同内容，Timeline可以拿Redis这样的数据库来保存，而对于其它的数据比如Gizzard其实是一个分布式的MySQL数据库。并不是所有数据都不适合用MySQL分布，我们可以把这些适合的用MySQL来shutting一下，而不适合的用别的数据库来存，就是一个存储切开的方法。

第二刀是将路由、展示、逻辑切开。

我们可以看到又多出了一层，逻辑层。Tweets，User，Timeline它们分别对应后边的各种数据存储。前端会有外部访问的接口，API访问接口，并且它还保存了以前数据的整个架构，用来进行一些小规模的使用。最前面需要有一个Routing，来将不同的请求分布到不同的API上。所以之后Twitter就变成了上百上千个小小的数据模块，包括它的服务模块，他们通过之间的相互调用来完成具体的请求。

如果Lady Gaga发了个推文，会发生什么呢？

首先她发出一个推文，会到达最上面一层的外部模块，负责把推文写出来；接着到了API模块，负责接收这个推文；再往后是Fanout，Fanout将推文的ID推荐给所有订阅这个用户的信息收件箱里，收件箱就是Timeline，比如有400万人订阅了Lady Gaga，就会有400万的收件箱收到这个消息；紧接着由于我们Timeline要发到收件箱里，收件箱必然是一个最复杂的操作，为了优化它的性能，就把它们用分布式的方式存储在Redis里面，Redis是偏向内存的数据库，所以能够很快的存储这些信息；但Redis里存的只是ID，所以当一个用户具体要她推文的时候，实际上要通过Timeline服务去找到这个用户对应的是哪个Redis服务器上存了推文的 Timeline list，接着找到所有ID，然后这个Timeline service把ID的具体内容通过另外的数据库装载进来，最终得到结果反馈给用户。这些保证了我们推整个数据的时候速度最快，能够达到每秒30万次的性能。

虽然有了这样的过程，如何支持搜索呢？

很简单的想法是当我们写入API，它Fanout到每个用户的Timeline list的时候，我们可以拿另外的Ingester把这个推文放到里面，Ingesert最后把它放到Earlybird，就是所谓的倒排索引中。比如有个推文发过来“我喜欢太阳”，就把我，喜欢，太阳，拆成三个词，把这些单词，进行倒排索引，存到Search index里面。这时候实际会用到很多很多Earlybird，这样就能建立很多倒排索引，能够并行的去做。当用户一个请求过来之后，比如搜索“早上吃饭”，就会把morning和eat作为两个关键词发到我的Earlybird集群里，得到结果后Blender会把它组合到一块，并反馈结果。当然很多用户可以并行的向Blender发送请求，从而得到最终结果，这就是我们的搜索服务。

如何通知用户新消息到达呢？

第一个方法是另外再开一个Write API，在有新东西发生以后，我把它放到一个Push的服务里，那所有用户只要都连到这个后台里，HTTP PUSH，就会通知他有新消息产生了。同理对Mobile ，会有Mobile Push，当然大家对不同的信息有不同的对接方法，大家可以去仔细考虑下怎么能做到这个样子。

如何搭建这样的服务呢？

最基本的是开源项目Twitter-Server。

配置服务，IP之类；
管理服务，哪些down了、控制、启动等；
日志服务，运行怎么样，以后出问题找谁等；
生命周期服务，什么时候启，什么时候关，什么时候控制；
监控服务，到底有没有出错，出错以后怎么办，互相报警等
这些东西合到一起，就构成了这样服务的基本架构。

各个服务之间如何交流？

这就是传统的RPC（远程的进程调用），大家能够通讯的不仅是数据，而且可以通讯命令或请求之类的。这时需要开源项目Finagle。

能够提供服务发现，因为有很多服务，所以要找谁发送这个请求呢；
负载均衡，可能有十个人提供服务，先放到谁那儿？
重试，如果失败了怎么办，是否需要重试？
基本的线程池和链接池，大家可以复用，不用每次去创建，浪费资源了；
统计信息的收集；
分布式调试。
如何调用一个服务？

因为从A调用B，大家之间各种远程，写代码上要怎么做呢？可以使用函数来调用（Service as a Function），背后实际上是Function programming的思想。

可以看下这个基本例子：trait Service[Req,Rep]extends(Req=>Future[Rep])

简单理解为：我有一个请求想得到一个Response，就是Request到Response。这里面实际上可以先面向未来实现，之后当它执行的时候，就会得到相对应的结果。

多个服务的调用如何整合在一起？

我们看一看它要如何运行？比如我们有一个请求是得到一个用户的所有Timeline数据。它其实有很多步，第一步是得到User ID；第二步得到User timeline list里的那些消息ID；下一步是针对每一个消息，得到它的每一个具体内容，比如“我早上吃饭”这些内容，这些内容里面可能还有图片，还需要得到图片的数据。这是一个很复杂的过程，但这个箭头表达了它们最基本的执行顺序。

最佳的执行路径是什么？

首先是得到ID，再得到Timeline以后可以并行地读取每个tweet，可能会有的快有的慢，然后又得到一些它的具体信息，比如说图片之类，所以这就是最优策略。

下面我们来看一看代码：

第一行是得到用户ID，用一个面向未来的方程得到一个用户ID。

p其实是后面针对每一个ID执行的函数，这个函数来得到这个ID用户的Timeline list。所以这也是我们Function programming，或者如果用Spark也会经常碰见的函数。

得到每一个ID以后，实际上要针对每个ID执行，所以需要Map。Map每一个ID是做什么的，得到这个Tweet的具体信息。代码第二行就是根据ID得到他的具体内容。

当然如果这个东西有图片，那需要得到图片。

中间一步还需要把这些东西并行起来，大家都去单独得到Tweet，并且把它集合放到一块儿去。整个过程我们就得到了最终的代码。

这其实就是第三刀：切开“做什么”和“怎么做”。在这个代码过程中，所谓面向函数的编程，只是写了想做什么事儿，但具体怎么做，比如从哪个机器找、连接服务器、从谁那儿抓取，怎么并行等都没有写，实际上这些东西都被封装到了一个底层的库里面。所以现在Twitter就可以有两个团队，一个团队负责写代码，“做什么”；另一个团队负责写底层是怎么实现的。这样就能实现并行开发，这也是Function programming的一个好处。

一个服务器的架构长什么样呢？

上方是你的服务，下方就是你的服务器，包括一些集群的管理、内存、Java的虚拟机、操作系统和硬件。

有很多服务如何整合？

结果整合到一起就是很多层，底层都是一样的，但上层跑了不同的服务：HTTP、聚集器、时间timeline服务等。我们所有东西加在一起，系统就会跑上千个不同的小服务器，而且之间会有各种各样的备份。

那如何来统计出现的服务器情况呢？

比如会统计平均延迟，或统计一些信息来验证服务器是不是出问题了，实际上，在这种大规模里面，一个比较好的方法就是不要拿平均值统计，因为特殊情况会拉低所有情况。举个例子，假设北京有一个人，他年收入是100万，另外99个人每个人年收入都是1元。那平均下来每个人收入都是1万块钱，但实际上大多数人是很穷困的。所以不能拿平均数来算，尤其是在服务器的情况下。所以大家一般都会取中位数（median），百分之90的点，百分之99的点和百分之999的点。我们可以看到，下图是一个服务发生故障的前后。在服务故障发生前，百分之99点的平均延迟是100毫秒，但故障发生后变成400毫秒，发现这个问题以后就会去抓。但如果用平均值，很可能就发现不了这个问题。

这样还有一个好处，当我们做到上面整合的架构以后，每一个负责写代码的团队，只负责处理跟它相关的上下层就行，而不用做那么多交互，所以每个人的东西都非常简单，这也是所谓微服务的一个好处。

如何监控一个服务呢？

实际上针对这个服务在整个栈里面用的时间，会有一个图表达出来。

如何监控一个请求呢？

实际上，基于一个请求，会有一个整个运行的最佳策略，这就需要运行的整个过程的图。这就是我们之前讲的，得到一个用户所有Timeline内容信息的锯齿图，Zipkin，这也是一个开源项目。

如何监控系统的运行情况呢？

因为这个时候失败已经成为常事了。举个例子，假设每秒有30万的请求，有99.99%的成功率，那每秒一定会有30个失败的，所以不能说每次失败怎么样，统计失败率会比单独的失败更重要，而且写代码的时候要为这个失败来进行自动重试。大家不用纠结每次的失败，只要大部分过去就行了。

最后做下总结

学好分治法，走遍天下都不怕。
函数式设计切分做什么和怎么做。做什么是由函数式设计来写，而怎么做由底层的语言和编译器来优化。
面向错误让我们使用了统计域监控。99.9%的点出什么问题了，这样就叫做基于统计域的监控方式。

Twitter的实时通知架构

Tue, 27 Jun 2017 22:54:37 CST

Twitter工程经理Sarrabh Pathak在伦敦QCon 2017大会上介绍了Twitter网站的通知系统架构。他主要介绍了Twitter所面临的独特挑战，比如社交网络的双峰（bimodal）性、如何应付尖刺流量以及如何实现实时的通知机制。

Pathak解释说，与一般的社交网络不同，Twitter的用户数据具有不对称性。有些用户有数百万关注者，而有些则只有不到百人。这导致了通知具有双峰性，也给实现实时通知带来了挑战。例如，名人的推文比普通人的推文产生更大的通知负载。

Pathak说，不同类型的用户以及严格的性能需求给架构带来了如下挑战：

延迟：人们要尽可能快地收到通知，毕竟Twitter需要实时地通知用户当下正在发生的事情。
展开（fanout）：一个拥有数百万关注者的用户，他的一个推文会触发数百万个通知，系统必须能够处理这种大型的尖刺流量。
不均衡的调用：有些内部调用，比如访问缓存，只需要几毫秒。而有些外部调用，比如访问Google，可能需要半秒多钟。在进行伸缩时必须考虑到这些情况。
多数据中心：Twitter必须尽可能地具备弹性，即使发生了故障，也要保证用户仍然能够收到通知。

首先，通知分为推送和拉取两种模式。人们在访问Twitter时看到的通知信息流使用的是拉取模式，而短信和邮件则使用推送模式。

Pathak说，对于拉取模式，通知一般是从缓存里获取的，因为信息流的生成是很耗费资源的。Twitter使用了Manhatten，Twitter的实时分布式后端存储，也是Redis的一个分支。通过使用缓存，最小化了延迟，提升了用户体验。与此同时，通知信息流通过异步的方式被复制到多个数据中心，目的是在发生故障时，用户仍然能够看到相同的信息流。

为了应对延迟和尖刺流量问题，Twitter使用了推送通知模式，不仅进行横向伸缩，同时还使用了临时缓存。这解决了同一个用户有数百万个通知事件的问题。

为了解决不均衡调用问题，Twitter使用了优先级队列来防止调用阻塞；名人的推文不会对其他用户的登录造成阻塞。另外，不同类型的调用被分成组，这意味着因外部依赖发生宕机造成的影响是相互隔离的。

最后，Pathak对该架构进行了总结：

尽可能专注在异步操作上，因为它比同步操作更容易伸缩。
在权衡读取时间和写入时间时，考虑只写入不太可能发生过期的数据，比如ID。
确保应用能够支持多数据中心部署。

整个访谈可以在线观看，里面还有一个来自Twitter工程师Gary Lam关于个人定制化通知的访谈。

查看英文原文： Real-Time Notifications at Twitter

评价本文

Twitter数据挖掘及其可视化

Thu, 09 Feb 2017 19:53:43 CST

前阵子有学弟学妹问我毕设做的啥，于是我决定记录一下去年毕设的内容。

主要是基于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’] 个数（名词、动词、副词、代词、形容词)
词典特征（本文使用的情感词典有：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数据挖掘及其可视化，首发于细语呢喃。

哪些人在Twitter上发言的语法最规范？比尔盖茨排第二

Tue, 01 Mar 2016 23:21:24 CST

美国有个诡计的节日，叫国家语法日（National Grammar Day），可能一般人是不知道的，但Grammarly不会忘记。Grammarly是个应用，据说它真正懂英语。大概是要庆祝国家语法日，Grammarly对Twitter上粉丝最多的50个名人最近发的150条推文进行了研究，排除了那些转发的推文，确保研究对象是这些名人自己说的。

随后他们将这些推文放到Grammarly应用里，得出结果后，再让人类二次校对。

Grammarly这款应用官网上是这么描述的：“Grammarly让你成为更好的作者，相比你的文字处理工具，它能找到、纠正超过10倍的错误。”据说它能找到的很多语法错误，是Word完全发现不了的。

这次测试的结果发现，排名第二的是比尔盖茨—— 微软的联合创始人，早年从哈佛退学。然后你肯定很想知道第一名是谁。

这也是一名上过哈佛的同学，而且他是以很优秀的成绩从哈佛毕业的，此人就是Conan O'Brien，著名脱口秀节目主持人，这个人的职业另外还有作家、配音演员等，应该说语法对他而言原本就不是问题。

第三名还是哈佛的高材生，美国总统奥巴马。

接下来，应该会有很多人想知道在语法方面，究竟有哪些名人表现得比较糟糕了。很多看起来跟音乐是相关的，下面这些：Niall Horan、Miley Cyrus、Bruno Mars、Louis Tomlinson、Liam Payne、Ariana Grande。

排在最末尾的是脱口秀主持人Daniel Tosh（第一名和最后一名是一样的职业…）。

Grammarly表示，这次“只看明显错误，比如拼写错误，错误使用标点符号，错误用词，主谓不一致等。我们也忽略了一些风格特色，比如故意拼写错误、首字母缩写、常用俚语、标签错误、外国语言，没写句号，用&替代and，省略号，还有句子不完整。”

从结果来看，20-29岁的名人犯的语法错误是最多的，相比30-39岁组多出两倍的语法错误。

一名Grammarly发言人表示：“虽然我们没有考量表情符号部分，但Grammarly结合了数百万用户的反馈，他们让我们了解人们日常沟通的最新方式。”“和同辈、老师、同事清晰、高效地沟通的需求应该持续。实际上，我要说这种需求比以往都更佳重要，因为英语越来越成为商务语言，并且也是全球很多地方的第二语言。”

查看评论

Twitter的这种信息分类技术，在社交媒体中怎么用最有效？

Mon, 29 Feb 2016 21:14:00 CST

Hasgtag ：“#XX”这种形式的标签，被称作是 hashtag，你可以用它来标注你的 Tweet （即用户发到Twitter上的信息）里面的关键词和话题。hashtag 是推特的用户原创发明，是一种给信息分类的方法。

——Twitter 对 hashtag 的官方解释

2009 年 7 月 2 日推特为推文里出现的所有 hashtag（#XX）都加上了超链接。如果用户直接搜索 hashtag 的词语，就可以得到所有被加上标签的推文。在 2010 年，推特在首页推出了“热门话题”，这块儿地方也成为营销的一块儿肥肉。

除 Twitter 以外，Tumblr、Facebook、Instagram、Google+几乎所有的社交网络都加入了 hashtag 的功能。一个好的 hashtag 将会为你在社交网络上的营销加分不少： 它可以增加品牌的曝光度；调动用户的参与性；作为社交网络上信息分类的一种方式可以让你及时收集到社交网络关于这次 campagin 的反馈。

在海外社交网站利用 hashtag 做社会化营销并不是一件新鲜的事，但它始终不是一件容易的事。Lemore 营销实验室将通过通用技巧、成功案例、实用工具告诉你如何为你的品牌和产品选择一个适合、精准、受欢迎的 hashtag ，让 hashtag 成为你营销的助力。

#1. 了解你的受众正在聊什么

如果要利用社交网络营销，你一定要充分了解社交网络的流行趋势。在确定你的 hashtag 之前，一定要结合你的目标用户做大量的追踪调查，了解他们的兴趣点、他们的痛点。

美国 OTA 网站 Travelocity，他们在之前的营销中发现用户对网站的吉祥物“漫游地精”非常感兴趣。“目的地”与“草本”成为他们此次营销的话题。所以他们选择了 #IWannaGo 作为标签，鼓励用户走进自然，去闻闻花香。在这个标签话题中，用户参与话题告诉 Travelocity 他们最想要去的目的地。

Audi 发现有一个用户用了 #WantAnR8 作为标签来解释自己为什么需要想要一辆奥迪 R8，

奥迪很快抓住这个机会，只要用户发布一条带有#WanAnR8标签的推文，就能获得试驾一天的机会。这无疑是奥迪在社交网络营销中的最佳战役。

推荐工具：

Hastagify.Me

这个网站可以帮你找到关键词下相关的标签，并像思维导图一样展现出来。当你浏览相关标签时，不仅能看到它们如何与主题标签关联起来，也能看到它们的关注度。打开“高级模式”还能找到更多关联内容，如果想看到更加结构化的格式，也可以打开“表格模式”。

#2. 如果你正在策划一个 Campaign，记得要让你的 hashtag 具备独特性。

如果你正在做一个线上的营销活动，那么你的 hashtag 需要和这次活动紧密相关。用一个词语或者短语概述你的活动。这个 hashtag 最好是第一次使用，或者是还没有成为一个大热的标签。做一些调查，在多个社交网站看看你选定的这个 hashtag 是否已经很受欢迎，如果是，那么请果断换一个。

推荐工具： Topsy

Twitter API 不能找到标签什么时候第一次被使用，但 Topsy 却能做到。键入搜索设置，就能找到标签下附带照片、链接和视频推文辑录和相关分析。甚至还能告诉你每个标签的受众是谁。

#3. 简短但有力有话题，让用户更简单地参与

一个很长的 hashtag 或许可以让你的标签更有独特性，也更能概述这个营销活动。但是这会大大增加用户的参与难度，所以你应该让你的 hashtag 在尽量简单的单词、词组中表达出特点，甚至是态度鲜明。在之上难度更高的则是，需要让你的标签具备话题性，它不能因为简短而平淡，所以在用词上要更加精准、更加有力，词组的组合也要更加有趣。

可口可乐在瓶贴上标上 “ Share a Coke With…”, 每个瓶子上有着不同的标签，像是 “ Share a Coke with Mom” 或是 “Share a Coke with Micheal” 。“分享”是一个非常没后的词语，而半开放的标签，又可以让用户加入个人的情感。

消费者把自己的故事分享在 Twitter 的 #ShareCoke 的标签下。这场营销战役不仅收集了数以万计的推文，还给可口可乐展开他们的子战役的机会。找到带有“ Ryan” 的可乐就能有机会和《美国偶像》里的 Ryan Seacrest 一起分享。

可口可乐还在继续生产这种特殊包装的可口可乐，#ShareaCoke 的营销战役还将在接下来这几年持续不断。

推荐工具：Rite Tag

RiteTag 是一个可以告诉你那个标签最可能被用户看到和使用的工具。当你编辑好一个附带标签的推文，它就会用红绿蓝标注出不同关键词告诉你到底这个标签有多大机会被别人发现。甚至还能推荐更可能被关注到的标签主题。

#4. 千万不要忘记了你要推广的产品和品牌

很多时候，太关注与社交网络的趋势和话题的有趣性，反而会忽略 hashtag 和产品、品牌的密切程度。一个好的标签应该是从产品和品牌的调性出发，然后最终应该导向你的产品和品牌。特别是在事件营销当中，hashtag 可以作为用户在社交网络参与整个 campaign 的入口，如果配合有 mini site ，那么在话题的引导下，应该让用户对你的营销活动更有兴趣。 别把 hashtag 当做一个落点，它是营销传播的方式，是制作话题和热点的工具。

红牛在去年采用了 #PutACanOnIt 的标签。这个 hashtag 可以说是兼具产品和有趣性的典范。用户举着红牛的拉罐在汽车前拍照，每一个参与话题的推文都意味着红牛产品的一次露出。

用户拿着红牛拉罐和一辆 Mini Cooper 合影，让这张照片看上去就像是一辆“红牛牌”轿车。

这个趋势迅速演变成大家拿着红牛拉罐摆造型拼创意。

#5. 灵活利用热门话题标签

利用热门的 hashtag 是让品牌增加曝光的有利方式。一个试图在社交网络营销上有所成就的平台应该非常了解社交网络上的热门话题，结合品牌和标签找到契合点，这也是输出品牌价值的一个极好的时机。但是社交网站的热门话题随时都在变化，所以找准时机，尽量精准和快速地参与讨论。

在美国通过同性恋婚姻的当天，#lovewins 这个 hashtag 迅速成为推特热门，这个标签只有两个非常简单的词语。但是不论是 love 还是 win 都具备一种戳中用户痛点的力量，而且鲜明地表达了对同性恋婚姻合法化的态度。LGBTQ 群体逐渐开始得到越来越多人的支持和理解，网络舆论也是撑同志反歧视的走向，这个时候许多品牌都在这个时机加入了 #lovewins 的大军。

可口可乐 #lovewins 推文获得了 31,500 个喜欢。

红牛 #lovewins 推文。

推荐工具：Hashtags.org

包括大量目前正大火的标签清单，在这里可以找到 24 是小时内出现的标签和相关分析。你可以通过这个标签看看目前正流行于社交网络的话题。

#6. 要让你的 hashtag 更加人性化，用户在日常生活中也能用

大牌擅长使用话题标签就在于他们能让标签和受众产生私人联系。这意味着即使是在营销活动结束之后，用户依然会继续使用这一个标签。让自己的标签可以融入到用户的日常生活中不但是品牌深入人心的代表，可以让你更好地通过追踪目标用户生活、习惯、兴趣、爱好。

今年女性小说奖 Twitter 战役直接利用用户定制的标签 #ThisBook 来鼓励读者分享他们心中的最佳小说。这个标签几乎没给胡闹留下什么空间，但清晰的行动呼吁又给有趣的用户生产内容足够的机会。

#7. 增加 hashtag 的曝光

你的阵地不是只有 Twitter ，一个好的 hashtag 可以轻松移植到其他的社交平台，同时可以保持你这次营销活动的统一性。无论是在 Twitter、还是 Tumblr、Instagram，你可以使用同一个 hashtag ，这可以增加它的曝光，让更多的用户参与进来，加深用户对品牌的印象。如果这是一次大型的整合营销，那么在线下推广、Minisite宣传的时，别忘了露出你准备的 hashtag，让用户在社交网络上在掀起一次话题。

奥利奥在去年万圣节在短视频社交网站 Vine 上做了一个 #Oreohorrorstories 的话题，用饼干和牛奶模仿了《闪灵》的经典片段，获得很好的反响。很快他们在 Twitter 继续开展这个活动。知道现在，Twitter 用户还会加上 #Oreohorrorstories 来表达对奥利奥的喜爱。

推荐工具：TagBoard

大多数工具只是适用于 Twitter，但 TagBoard 能帮你同时追踪 Twitter、Facebook、Google+、Instagram 和 Vine 5 个社交平台。如果想在不同平台上营销，TagBorad 就是个好选择，你也可以创建一个你自己的 Tagbord。

HootSuite

一次性在多平台上同时发布内容和标签是 HootSuite 的强项，你不仅可以提前设定发布时间，也能追踪到标签动向。如果竞争者采用同样的多平台策略，这就是一个很好选择。

#8. 一定要盯住你的 hashtag

记住 hashtag 另一个关键的作用，就是他可以给你最迅速的反馈，一旦标签这只猛虎出笼，更要确保监管它并提供快速有效的用户反馈。你可以根据用户的反馈、话题参与的程度及时做出一写调整和有效地引导。积累搜集分析数据，为下一次的营销做准备。

推荐工具：Hashtracking

想要随时追踪事件营销中的标签，Hashtraking 记录谁在参与话题讨论，提供图标和深入分析。

TweetBinder

给特殊标签们创建一个“ Binder ”，就能得到这个标签下的讨论、推文、图片和链接的数据报告，这些数据就能为下一次营销战役提供参考。

TweetReach

使用 TweetReach 是一款可以了解到事件营销中标签有效性的工具，通过它可以了解到你的标签是否能制造讨论或引发其它用户发推文，重要的是，谁看了你的推文。

【作者介绍】LeMore营销实验室，成立于硅谷的智能硬件海外推广与营销平台，发掘有价值的产品和人才，分享最实用的海外营销工具与案例。有兴趣的可关注其微信公号：Lemore_Lab。

Twitter切断了多个备份政客删除帖子的网站API访问

Tue, 25 Aug 2015 20:58:58 CST

Twitter切断了多个备份政客删除的帖子的网站API访问，其中包括Diplotwoops和Politwoops。运营Politwoops和Diplotwoops的组织批评了Twitter的决定，而Twitter的理由是这些网站违反了该公司的隐私政策。运营Politwoops的Open State基金会理事Arjan El Fassed指出，当选政客的公开言论是公共记录的一部分，发表后删除的帖子提供了独特的角度观察政客。他们对Twitter的决定非常失望。

Pokémon Go成为美国史上最受欢迎的手游，活跃用户超过Twitter

Fri, 15 Jul 2016 05:18:56 CST

根据最新的数据，仅仅发布一周的Pokémon Go成为美国史上最受欢迎的手游，每日活跃用户超过了Twitter，使用时长超过了Facebook。美国10.81%的Android手机安装了Pokémon Go，5.92%的Android用户每天使用它。Pokémon Go目前只在美国、澳大利亚、新西兰和德国发布，但其它国家的玩家可以通过VPN绕过地理位置限制或直接下载APK文件安装。中国则出现了一个克隆《城市精灵GO》。本周一，美国的Pokémon Go活跃用户达到了2100万，超过了《糖果粉碎传奇》在2013年创下的记录。在Android平台上，Pokémon Go流行度接近了 Snapchat，有望超过 Google Maps。在使用时间上，iOS用户周一在Pokémon Go上花了33分钟，而Facebook则是22分钟8秒。对于Pokémon Go最近引起关注的隐私问题，美国参议员Al Franken已经致函开发商Niantic的CEO John Hanke（PDF），要求该公司详细解释应用收集的用户数据。

Twitter投资人说：只有具备这些的公司才能拿到风投

Tue, 06 Sep 2016 08:00:00 CST

不论以何种标准考量，迈克·梅普尔斯（Mike Maples）都是一名不折不扣的精英二代。梅普尔斯的父亲曾先后在IBM 和微软公司出任要职，在很小的时候梅普尔斯已经开始跟随父亲四处走访，这段经历使他的见识超过了绝大部分同龄小孩。

由于父亲曾在IBM 供职，梅普尔斯很早就开始接触电脑。在高中阶段，梅普尔斯已经开始为电脑公司编写游戏程序。高中毕业后，他成功考上斯坦福大学（Stanford University），后来还在哈佛大学商学院（Harvard Business School）获得了 MBA 学位。

毕业之后，梅普尔斯先后创立了「Tivoli Systems」和「Motive」两家企业并成功上市，前者甚至还被 IBM 收入了麾下。有了成功的创业经历后，梅普尔斯把目光投向了风险投资领域，并创立了著名的「闸门基金」（Floodgate Fund）。他的投资清单简直让人称羡，包括：Twitter、Digg、Gowalla（已被 Facebook 收购）、BranchOut、Chegg、Formspring（Formstack 的前身）和 Milk（已被 Google 收购）。

下文主要根据梅普尔斯在 Quora 上的回答整理而成，遂以第一人称叙述。

投资 Twitter：「我就知道这家公司会火！」

我曾经在奥斯汀市（Austin）呆过 10 年，并于 2005 年搬到硅谷。最初我希望能在风投机构找到一份工作，然而现实并不如我所愿。后来我投资了一家名为「Odeo」的播客公司，初次体验了身为天使投资人的感受。但很不幸，在我递送支票一周后，苹果公司宣布免费对外提供播客服务，这笔投资很快就宣告失败。

很快，仗义的伊万·威廉姆斯（Evan Williams）就和我取得了联系，他向我坦白了公司经营失败的消息，并提出要将投资金额退还给我。我拒绝了这个提议，因为风险投资本来就是一种具备不确定性的活动，没有人能保证一定获利。但威廉姆斯非常执着，我只好接受了他的提议。

在讨论的过程中，威廉姆斯向我透露了一个名为「Twttr」的产品，原来他一直在业余时间内钻研这款产品。「Twttr 到底能实现什么功能？」我问道。

「你觉得人们在 140 个字符以内可以做些什么呢？」他说道。

「这有什么特别之处？」我反问道。

「这就是这款产品的意义所在。」

「这款产品的路线图是怎样的？」

「我的产品没有这个东西。」

「那盈利模式呢？」

「也没有。」

对话结束后，我不得不感叹：「伊万，你为什么会认为这样的东西能够成其为一款产品？它又怎么能支撑起一项业务呢？」

但他所给出的回答让我铭记于心。他说在他刚发明「Blogger」的时候，用户数量很快就突破了一百万。但播客类产品的发展却要艰难得多，你需要提前录制好音频，并将其放置到播客目录当中。要是反过来，我们尝试打造一款简单易用的微型博客产品，用户又会作何反应呢？博客的用户量会从百万级别上升至千万级别吗？

「至于事实是否如此，我们只能拭目以待了。」威廉姆斯说道。

「好吧，我想要投资 Twttr，但我认为你还是应该把名字所缺失的字母加上。」

威廉姆斯表示到了融资阶段他会让我入股，最终他并没有食言。Twitter 很快就在「西南偏南大会」（SXSW）上崭露头角，尽管 2,000 万美元的估值略微偏高，但我还是参与了投资。

在接下来几年内，我有点担心这家公司会失败，也曾经被管理团队的变动和其他内部问题分散过不少精力。有一天我去接我女儿，她朋友的母亲对我说：「你女儿说你是 Twitter 的第一位投资者，这是真的吗？你是怎么发现这家公司的呢？我刚好从一场脱口秀上得知了这家公司的存在。」

这番对话让我确信 Twitter 一定会大获成功。果不其然，很快 Twitter 的身影就遍布了电视和网络，它完全成为了投资者眼中的「香饽饽」。

寻找企业家身上的光环：「我最看重这 5 个品质！」

进行投资决策时，我会考察企业家身上的 5 个品质。

远见

远见是一种可遇不可求的品质，它是企业家成功的秘密。远见可能源于对新技术的掌握，也可能源于别具一格的见解，甚至是对某个新方案言之切切的爱。倘若缺失远见，你的创业公司和其他公司又有什么区别？远见是企业家强大的武器，也是我希望尽可能保护创业者的初衷。如果企业家缺失远见，生活中的许多奇妙时刻也将消逝。

毅力

我本人最欣赏的谚语是：「唯有当你决定放弃的时候，事情才算告一段落。」

没有哪家创业公司的成功是理所当然的，几乎每家创业公司都有濒临死亡的经历。每一位创业者都曾备受质疑，总会有旁观者武断地认为他们的创意非常愚蠢。但伟大的创业者总会对自己的创意心存深厚的爱意，他们坚信自己的热爱和激情可以排除万难。如果说有什么让我觉得不能释怀的话，那大概是我逗留在董事会的时间比创始人还长吧，有时候企业的创始人会选择中途离开公司。

承诺

创业者能否和身边优秀的同事开展合作，并持之以恒地输出优异的工作表现？这个承诺能否把企业氛围转化成以精英为导向，并吸引优秀的人才参与进来一起奋斗？创业者有过和团队成员同心协力，追求卓越的经历吗？优秀的创业者不会停留在希冀或者寻求的层面，他们会主动创造出这种氛围。

好奇心

我们不妨看一看拉里·佩奇（Larry Page）、比尔·盖茨（Bill Gates）和马克·扎克伯格（Mark Zuckerberg）这些优秀的企业家，他们的成长速度绝对会令人感到诧异。他们可以向海绵一样吸收新资讯，并快速学习如何雇用员工、如何让企业规模实现增长、如何打造企业文化以及如何设计公司的框架和产品。他们的好奇心永远得不到满足，还会追求每一天都有所长进，正是这些优秀的品质造就了一个又一个的商业传奇。

玩味精神

许多人会对这一点感到惊讶，但在我眼里，伟大的创业者或多或少会给人一种童心未泯的感觉。创立了Airbnb 的那帮家伙会在克雷格列表（Craigslist）上发布信息，当然不久后他们便因此而陷入了麻烦；在尚未拥有「DOS」系统之前，比尔盖茨已经敢于将其出售给 IBM 公司，随后他又花费了 50,000 美元从另一个人手上买入了一款操作系统。

我们当然不希望创业者沾染上道德问题，但我们也希望创业者可以灵活应对规则，并在适当的时候合理去打破一些规则以便获取更好的效果。这种玩味精神还可以使创业者避免陷入被过度低估的局面。

融资的技巧：「回答好这 4 个问题就够了！」

但凡涉及融资，你总会收到各种各样的建议。就总体而言，我认为创业者总是容易在回答下列 4 个基础问题时出现偏差：

你的企业是做什么的？

你的业务所坐拥的市场规模有多大？

企业的增长潜力有多大？

你的盈利模式是什么？

你或许会认为这 4 个问题过于简单，但如果创业者能够在 15 分钟内给出得体的答案，我会对他刮目相看。下面我会给出一些回答的范式：

你的企业是做什么的？

你的答案应该尽量简单、直接，你甚至可以假设面前的听众对你的企业一无所知。以Airbnb 为例，得体的回答应该是：「我们是 Airbnb，我们的业务可以让你出租房屋内空余的房间。」

但切记，千万不要回答成：「我们是 Airbnb，是一个专门出租多余空间的集市。」

你的业务所坐拥的市场规模有多大？

不少创业者在回答这个问题时缺少直接性，他们往往不能将问题叙述得简单明晰。正确的回答应该是：「我们是 Chegg，我们出租课本。美国的学生人数高达 2,000 万人，每一年学生在课本上的花销达到 300 亿美元。如果学生能够以相当于售价三分之一的价格租用课本，我们只需覆盖 10% 的学生即可产生 10 亿美元的年收入。」

错误的示范是：「我们是 Recruiting，我们所涉及的市场规模高达 5,000 亿美元，尽管这片市场目前处于支离破碎的状态。」

企业的增长潜力有多大？

如果你正处于种子轮或者 A 论融资，在理想情况下你的月度增长比例应该达到 30% 以上，增长的介质可以是收入或者用户数量。如果企业的增长表现并不客观，那么你应该对融资规模有一个客观的评估，并将投资者的目光转移到团队和日常经营活动上。你可以向他们展示团队的优势以及项目推进的速度，并坚决地表示自己在融资成功之前不会轻言放弃。

你不应该试图掩盖增长缓慢的局面，经验丰富的投资者总是能轻易识破这类小心机，届时整个对话将会变得乏善可陈。

你的盈利模式是什么？

绝对不要试图逃避这个问题，你应该实事求是地进行作答。不论你的盈利模式是广告、虚拟产品还是 B2B 销售模式，你都应该如实作答。如果你打算先让用户基数增长到 1 亿，然后再开展盈利活动，你也应该向投资者说明情况。

回答问题时应该尽可能避免模棱两可的态度，因为这往往表明创业者对于问题并没有作出深入了解，答案的价值也会因此而大打折扣。

提高排序效果，Twitter搜索相关架构解析

Fri, 02 Sep 2016 08:00:00 CST

原文： Search Relevance Infrastructure at Twitter
翻译：KK4SBB
责编：周建丁

每天，全世界几百万的用户都在Twitter上搜索着发生的新鲜事。在重大事件期间，比如刚刚过去不久的 2016欧洲杯，我们观察到在用户前来Twitter查看最新战况时，搜索服务会出现流量的尖峰，并且整体流量随着此事件的推移而稳步上升。Twitter的搜索质量组就是负责给用户返回质量最好的结果。

相比于传统的信息检索产品，Twitter的搜索面临的挑战是绝无仅有的，原因如下：

时效性：我们大部分的搜索请求都对信息的话题性和实时性有着强烈的需求。世界局势瞬息万变，在某些情况下，甚至几分钟前的搜索结果就会显得过时和不相关。推荐的搜索词条，拼写纠正和相关搜索词等，都需要保证新鲜和及时。
文档集合庞大：搜索的候选文档集合非常巨大，每天有几十亿条各种语言的新的Twitter生成。
文档格式：Twitter的文档有其特殊的属性：140个字符的非结构文本文字，但是包含了丰富的实体类别，有“#”符合、“@”符合、图像、视频和站外链接。不同于网站页面，Twitter之间没有超链接，因此类似PageRank的基于链接的算法不能直接拿来用于Twitter的排序。
多种结果类型：搜索的结果页是多种搜索结果的聚合，包括Twitter、其它用户账号、图像、视频、新闻、相关搜索和拼写候选词等。各种类型的结果需要一起参与排序，使得最后聚合的结果页满足用户的搜索意图。
个性化：每一位搜索用户都有自己的社交网络、兴趣爱好、地理位置和语言偏好，因此搜索结果需要个性化定制以满足相关性。

为了在很短的延迟内返回相关的、高质量的搜索结果，我们需要在多个领域解决技术挑战：信息检索、自然语言处理、机器学习、分布式系统、数据科学等等。

在过去几个月中，我们投入了大量精力在搜索相关性的基础框架建设，目的是提高排序效果和实验的效率。这篇博文介绍了一些重点工作。注意，这与我们的召回Twitter的核心索引和检索平台（没有排序）有所区别。

实时信号消化

我们排序模型中用到的信号的变化性和时效性对最终的搜索结果质量有着巨大的影响。而且，当Twitter被建索引之后许多信号都会迅速改变，因此我们需要及时更新它们。我们基于 Heron写了一套新的信号消化器来处理原始信号流，为我们产品的排序模块提供特征。我们添加了灵活的模式动态地对新特征编码和解码，而尽可能少的修改代码。随着Twitter应用的升级，我们可以快速地添加和测试在离线实验中表现出色的新的排序信号。

快速、轻量级实验

我们实现从想法->验证->迭代这个周期的速度越快、代价越小，我们可以验证的想法就越多，产生的创新也越多。我们重度依赖传统的 A/B测试，同时也建立了一个互补的离线实验系统，使得测试效率更高。Twitter的搜索结果和搜索词变化迅速。因此，为了将信号从噪音中分割开来，我们冻结特定的时间节点的世界状态，构建了一个沙盒环境，以至于我们可以根据想要完成的测试来产生稳定的、可重复的结果。为了更好的理解，我们开发了工具来分析和显示的结果之间的差异，并且可以从内部评委处容易地获得他们根据我们的搜索质量判断准则给出的打分标签。一个特别好的优势是，这使我们能够验证庞大的指数级变化，如给检索增加新的索引字段和标识的更新等等，还可以在部署产品之前对结果精细地打磨。

训练和部署机器学习模型

机器学习的模型常用于搜索排名，因为他们提供了一个原则性和自动化的方式来优化特征的权重和整合新的排序特征。为了使它们效果最好，重要的是要正确识别需优化的目标函数，使其与用户最终的满意度相关联。我们建立了一个管道，它可以无缝地收集训练数据集用于模型的训练和验证，并将训练完成的模型部署到生产服务器。数据规模带来了额外的挑战，如搜索排名第一阶段发生在索引碎片，大量与查询词匹配的文档在CPU资源、内存和延迟约束很严格的情况下进行打分。我们与 Twitter Cortex团队创建了一个轻量级的运行系统，它可以支持在这些约束条件下运行模型，并且用我们内部的机器学习平台工具训练得到的排序模型部署到线上使用，如 whetlab。

这些都是支持我们测试的关键模块，并且能够提升搜索的相关性，使搜索更好地为我们的用户服务。在未来的文章中，我们将深入介绍近期正在进行的搜索质量和项目的具体方面。敬请关注！

感谢

搜索质量组的成员有 Tian Wang, Juan Caicedo, Zhezhe Chen, jinliang Fan, Lisa Huang, Gianna Badiali, Yan Xia和 Yatharth Saraf。我们还要感谢搜索架构组、Heron和Cortex团队在各阶段给予的大力帮助。

Twitter推出新方法阻止网络仇恨言论，但它更注重言论自由

Sat, 27 Aug 2016 18:54:57 CST

网络暴力的受害者不仅仅是普通用户，还有社交平台，因为网络暴力导致的用户流失会让社交平台蒙受巨大损失。Twitter 一直以来都面临着这个问题，而这家公司早在几年前就开始了积极地补救。

虽然 Facebook 和 Google 等公司都开始尝试结合人工智能等技术清楚仇恨言论，但 Twitter 目前还没有相关的动作，而是通过外包公司人工管理。

但 Twitter 最近想出了一个去中心化的解决办法，那就是允许用户自己设置屏蔽关键词来阻止仇恨言论。根据彭博社的报道，Twitter 最近将会允许其用户自动拦截推文评论中的仇恨言论。根据报道，Twitter 在过去的一年里一直都在研发这个新功能，它允许用户先发制人地屏蔽到那些自己不希望看到的内容，让他们避免看到这些冒犯性的推文或与网络喷子互动。这种让用户参与屏蔽的方式将极大地提高 Twitter 反仇恨言论的效率。

2015 年 Twitter 首席执行官 Dick Costolo 在一场内部论坛中表示，该公司失去众多用户的原因是其社交平台上存在太多“网络喷子”（troll）。

Costolo 表示他应该为 Twitter 在处理网络仇恨言论上的糟糕表现负责，因为这一问题导致了 Twitter 失去了很多核心用户。“我们在处理仇恨言论和喷子方面非常糟糕，多年以来都是如此，”他说。

在创立之初，Twitter 曾承诺不会审查用户发布的内容。但在网络暴力让用户——特别是拥有巨大影响力的名人纷纷离开 Twitter 平台之后，这家公司开始对仇恨言论和骚扰信息进行了清理。

2015 年 3 月，Twitter 宣布屏蔽报复性色情内容；4 月，该公司宣布开始屏蔽煽动恐怖主义，或以种族、民族、国籍、宗教、性取向、性别、性别认同、年龄或残疾为由攻击他人的言论。

虽然这一系列屏蔽行为针对的都是仇恨言论，但 Twitter 辩解称他们封杀的不是“言论”，而是“仇恨行为”。因此冒犯性的内容仍然允许被发布，但如果仇恨言论指向某个具体的用户就构成了“仇恨行为”。

相比之下，虽然 Facebook 和 Instagram 拥有更多活跃用户，但这两家公司并没有这么费力地想要清楚仇恨言论。因为与 Twitter 相比，Facebook 有更严格的社区准则，但 Twitter 更倾向于言论自由。

Twitter 前法律总顾问 Alexander Macgillivray 曾说“Twitter 是言论自由之翼。”而其前公关总监 Vivian Schiller 则说所谓“言论自由之翼”不仅仅是一句口号，也深深地嵌入了该公司的 DNA 中。

提倡言论自由带来的网络暴力问题不仅在 Twitter 平台上存在。上周拥有上千万粉丝的贾斯汀·比伯也因为粉丝不断在 Instagram 上攻击自己的新女友而删除了自己的 Instagram 账号。

除了科技公司外，政府机构和民间组织也开始了在阻止网络暴力上有所作为。

2915 年 12 月，德国政府要求 Facebook、Google 和 Twitter 等主要社交平台在 24 小时内删除其网站上出现的仇恨言论，以打击德国在难民危机后愈发严重的网络种族主义倾向。

在这项措施中，用户和反种族主义组织可以很方便地将发现的种族仇恨言论提交到这三家公司的审核团队，并让其在审核后删除仇恨言论。

“当言论涉及到犯罪意图的表述、煽动叛乱、煽动实施威胁人身的攻击时，这超出了言论自由的界限，这样的内容应该从网络上删除。我们同意制定一项规则，应该在24小时内删除这些言论。”德国司法部长 Heiko Maas 表示。

今年 1 月，Facebook 承诺为“ 线上公民勇气倡议”组织（Online Civil Courage Initiative，简称 OCCI）提供 100 万欧元的资助。并让该组织帮助 Facebook 打击欧洲网络上存在的仇恨言论和极端内容。

MySQL在Twitter的应用以及Mysos介绍

Wed, 29 Apr 2015 00:22:57 CST

自创立以来，MySQL 一直是 Twitter 使用的关键数据存储技术之一。他们的数据存储在数以百计的模式中，最大的集群有数以千计的节点，每秒为数以百万计的查询提供服务。近日，网站可靠性工程部门高级经理 Pascal Borghino 撰文介绍了 MySQL 在 Twitter 的应用以及正在孵化中的 Mysos 项目。
在 Twitter，MySQL 主要有两个用法：

作为数据服务的一部分：在 Twitter 自己的“分片（sharding）”框架内将 MySQL 用作分布式数据存储的存储节点，这样，既可以在单个存储节点上利用 MySQL 的可靠性和高性能，又可以借助分片框架管理数据分布，实现高可用性。
作为关系型数据存储：利用 MySQL Replication 的容错功能和读可扩展性，使用集群支撑大规模的读操作。

Twitter 不只是从 MySQL 社区获益，他们也向社区贡献了许多补丁。Twitter 还是 WebScaleSQL 项目的发起者之一，该项目刚刚获得了 MySQL 社区 2015 年企业贡献奖]。它的目标是，使 MySQL 社区中大规模使用 MySQL 的成员通力合作，向 MySQL 增加适合于大规模部署的特性。
另外，为了提高 MySQL 集群的可扩展性，他们正在开发一个名为 Mysos 的新框架。Mysos 项目基于 Apache Mesos 构建一个面向 MySQL 的可扩展的数据库服务。Mesos 为 Mysos 提供了调度、监控 MySQL 实例及与之通信的原语，极大的简化了 MySQL 集群的管理。根据设计，它将提供如下特性：

通过多租户实现高效的硬件利用率；
出现故障时保留 MySQL 状态，并可以自动备份到 HDFS 或从 HDFS 恢复，具备高可靠性；
有一个自动化的自助服务选项，可以启动新的 MySQL 集群；
借助 MySQL 主数据库故障自动转移实现高可用性；
允许用户通过更改从数据库实例的数量实现 MySQL 集群的扩展和收缩。

该项目尚处于起步阶段。将来，Twitter 会围绕它构建一个独立的开源社区。

本文链接

Twitter的分布式自增ID算法Snowflake

Thu, 21 Jan 2016 21:00:43 CST

在分布式系统中，需要生成全局UID的场合还是比较多的，twitter的snowflake解决了这种需求，实现也还是很简单的，除去配置信息，核心代码就是毫秒级时间41位机器ID 10位毫秒内序列12位。

10---0000000000 0000000000 0000000000 0000000000 0 --- 00000 ---00000 ---000000000000

在上面的字符串中，第一位为未使用（实际上也可作为long的符号位），接下来的41位为毫秒级时间，然后5位datacenter标识位，5位机器ID（并不算标识符，实际是为线程标识），然后12位该毫秒内的当前毫秒内的计数，加起来刚好64位，为一个Long型。

这样的好处是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和机器ID作区分），并且效率较高，经测试，snowflake每秒能够产生26万ID左右，完全满足需要。

1</pre>

3package com.twitter.service.snowflake

5import com.twitter.ostrich.stats.Stats

6import com.twitter.service.snowflake.gen._

7import java.util.Random

8import com.twitter.logging.Logger

16class IdWorker(val workerId: Long, val datacenterId: Long, private val reporter: Reporter, var sequence: Long = 0L)

17extends Snowflake.Iface {

18 private[this] def genCounter(agent: String) = {

19 Stats.incr("ids_generated")

20 Stats.incr("ids_generated_%s".format(agent))

21 }

22 private[this] val exceptionCounter = Stats.getCounter("exceptions")

23 private[this] val log = Logger.get

24 private[this] val rand = new Random

26 val twepoch = 1288834974657L

28 //机器标识位数

30 private[this] val workerIdBits = 5L

32//数据中心标识位数

33 private[this] val datacenterIdBits = 5L

35//机器ID最大值

36 private[this] val maxWorkerId = -1L ^ (-1L << workerIdBits)

38//数据中心ID最大值

39 private[this] val maxDatacenterId = -1L ^ (-1L << datacenterIdBits)

41//毫秒内自增位

42 private[this] val sequenceBits = 12L

44//机器ID偏左移12位

46 private[this] val workerIdShift = sequenceBits

48//数据中心ID左移17位

49 private[this] val datacenterIdShift = sequenceBits workerIdBits

51//时间毫秒左移22位

52 private[this] val timestampLeftShift = sequenceBits workerIdBits datacenterIdBits

53 private[this] val sequenceMask = -1L ^ (-1L << sequenceBits)

55 private[this] var lastTimestamp = -1L

57 // sanity check for workerId

58 if (workerId > maxWorkerId || workerId < 0) {

59 exceptionCounter.incr(1)

60 throw new IllegalArgumentException("worker Id can't be greater than %d or less than 0".format(maxWorkerId))

61 }

63 if (datacenterId > maxDatacenterId || datacenterId < 0) {

64 exceptionCounter.incr(1)

65 throw new IllegalArgumentException("datacenter Id can't be greater than %d or less than 0".format(maxDatacenterId))

66 }

68 log.info("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",

69 timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId)

71 def get_id(useragent: String): Long = {

72 if (!validUseragent(useragent)) {

73 exceptionCounter.incr(1)

74 throw new InvalidUserAgentError

75 }

77 val id = nextId()

78 genCounter(useragent)

80 reporter.report(new AuditLogEntry(id, useragent, rand.nextLong))

81 id

82 }

84 def get_worker_id(): Long = workerId

85 def get_datacenter_id(): Long = datacenterId

86 def get_timestamp() = System.currentTimeMillis

88 protected[snowflake] def nextId(): Long = synchronized {

89 var timestamp = timeGen()

91 //时间错误

93 if (timestamp < lastTimestamp) {

94 exceptionCounter.incr(1)

95 log.error("clock is moving backwards. Rejecting requests until %d.", lastTimestamp);

96 throw new InvalidSystemClock("Clock moved backwards. Refusing to generate id for %d milliseconds".format(

97 lastTimestamp - timestamp))

98 }

100 if (lastTimestamp == timestamp) {

101//当前毫秒内，则 1

102 sequence = (sequence 1) & sequenceMask

103 if (sequence == 0) {

104//当前毫秒内计数满了，则等待下一秒

105 timestamp = tilNextMillis(lastTimestamp)

106 }

107 } else {

108 sequence = 0

109 }

110

111 lastTimestamp = timestamp

112//ID偏移组合生成最终的ID，并返回ID

113

114((timestamp - twepoch) << timestampLeftShift) |

115 (datacenterId << datacenterIdShift) |

116 (workerId << workerIdShift) |

117 sequence

118 }

119

120//等待下一个毫秒的到来

121

122protected def tilNextMillis(lastTimestamp: Long): Long = {

123 var timestamp = timeGen()

124 while (timestamp <= lastTimestamp) {

125 timestamp = timeGen()

126 }

127 timestamp

128 }

129

130 protected def timeGen(): Long = System.currentTimeMillis()

131

132 val AgentParser = """([a-zA-Z][a-zA-Z\-0-9]*)""".r

133

134 def validUseragent(useragent: String): Boolean = useragent match {

135 case AgentParser(_) => true

136 case _ => false

137 }

138}

转载自： http://blog.sina.com.cn/s/blog_6b7c2e660102vbi2.html#userconsent#

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

Twitter 推出新产品 Moments，这可能是最好用的新闻浏览平台

Wed, 07 Oct 2015 11:19:57 CST

作者：龟途慢慢

时间对于 Twitter—这家正陷入泥沼中的互联网巨头—有多重要，你只需要关注 Jack Dorsey 就知道了。这位 Twitter 公司新任的 CEO 没有耽误一点时间，在他正式上任仅仅一天之后就大张旗鼓地公布了 Twitter 的一款颇受重视的新产品—Moments。

带你追踪大事件

Moments 是一款 Twitter 筹备已久的新产品。简单地说，它就是一个为用户介绍一些重要新闻事件的 Twitter 页面。点击 Moments，你会进入它的主页面，然后你会看到它为你列出的一些重要的、有趣的新闻事件，点击进入具体的某个事件，你就会看到与此事件相关的 Twitter 消息了。更通俗地解释就是：Moments 就是由 Twitter 为你选出的、与该事件相关的重要「微博」的集合。

Moments 目前分为两部分在运营，一部分是 Twitter 自己的团队，另一部分则是与 Twitter 有合作关系的相关媒体，比如：Buzzfeed、纽约时报、Fox 新闻等等，当然这个名单还在进一步扩大之中。

点击 Twitter 主页面上方的标签进入 Moments 主页后，你会发现它主要有 5 个板块，分别是：今天、新闻、体育、娱乐、以及有趣的事 (Today, News, Sports, Entertainment, Fun)。进入默认的「今天」界面之后，你会看到由 Twitter 为你选择的重要新闻事件，排列顺序也并不是按照时间先后，而是 Twitter 为你选择的顺序。点击进入具体的事件页面后，消息的显示顺序也不是按照时间先后，而更像是一个说书人按照「事情发展的顺序」为你讲述事件的来龙去脉。

下面是 Twitter 官方给出的使用说明：

当你点击进入 Moments 的时候，你会看到关于事件的标题和基本介绍；
进入具体的事件之后，你会看到高清的图片、以及自动为你播放的视频和 GIF 图；
只需一次点击就可以完全展开该消息，这样你还可以对具体的消息进行收藏、转发与其他一些相关的操作。而如果双击的话你就可以立刻收藏它；
底部的进度条会为你说明每一个事件还有多少内容要提供；
点击分享按钮可以将你的想法分享给你的好友们。

我们以诺贝尔物理学奖颁奖这个事件为例为你具体介绍一下 Moments。

点击进入页面后，列在事件最前面的消息是诺贝尔奖官方发出的关于日本和加拿大科学家获奖的消息；

之后是《科学》杂志的为你解释两位科学家获奖原因的消息；

再之后则是加拿大总理、去年的诺贝尔物理学奖得主等相关人士发布的消息；

经过这样短短几条消息，用户们就可以对今年诺贝尔物理学奖的情况有一个基本的认知了。

当然，由于这个新产品才刚刚发布，因此目前只有在美国的 Android 及 iPhone 用户可以使用这个功能；在网页端，Moments 也还不支持中文，因此这些功能都必须使用英文版本来阅读，不过相信很快这个新产品会在更广泛的地区发布并支持更多的语言。

欲重整旗鼓，能做到吗？

事实上，Twitter 已经在 Moments 上花费了超过 10 个月的时间，他们想借由这个新产品挽回渐渐流失的用户。

有媒体分析，通过推出 Moments，Twitter 想要达到两个目的。

其一是作为一个社交平台，Twitter 想通过创造更多的内容在新闻发生的过程中扮演更重要的角色。因为当你关注一个新闻事件的时候，Twitter 会暂时性的为你插入有关该事件的消息，即使你并没有关注那个消息源。

其二就是 Twitter 相信这是一个吸引新用户的好办法，比如它可以帮助你更好地找到想要关注的人。因为当你关注一个事件之后，你会发现与该事件有关的重要人物，这可以方便你找到你的关注对象。「一开始使用 Twitter 的时候，你没有关注者也没有被别人关注，Twitter 使用起来当然有些无聊。而 Moments 可以帮你架起一座桥」，负责 Moments 的产品经理 Madhu Muthukumar 如此说道。

Moments 来自 Twitter 公司「闪电计划 (Project Lighting)」，这是 Twitter 公司一个旨在做出一些改变来简化 Twitter 并吸引用户的一个计划。

「闪电计划是一个很好的机会，它可以确保我们用一种连贯的方式为用户显示世界上正在发生的事情」，Dorsey 如此说道。

陷入发展困境的 Twitter 这次的新尝试究竟效果如何，还要静待市场的观察。

本文参考了 Twitter Blog, Recode, 及 Bloomberg 等信息源，头图来自海洛创意。

Twitter 数据分析师独家披露他们的工作内容（上）

Thu, 24 Sep 2015 11:16:10 CST

本文来源： Medium 译文创见首发由 TECH2IPO/创见花满楼编译转载请注明出处

创见干货：

数据分析到底是什么？很多人都在嘴边讨论它们，却没有几个人真正见过它。这是当下科技行业最为火爆的职位，今天就让我们走进 Twitter 的数据分析世界，看看科技公司对于一个数据分析师的要求是什么？他们的实际工作内容究竟是哪些？

到了今年 6 月 17 日，Robert Chang 就在 Twitter 工作两年了。根据他个人的工作经历，Twitter 数据分析（以下简称为 DS）有了下面三个层面的变化：

1.机器学习已经在 Twitter 多个核心产品中扮演越来越重要的角色，而这之前完全是「机器学习」的禁区。最典型的例子就是「当你离开时」这个功能。当用户离开页面或者电脑，去干别的事情后再次返回页面，电脑会立刻给你推送出来某些由你关注的人所发出，而有可能被你错过的「优质内容」。

2.开发工具越来越优秀了。整个团队摆脱了对 Pig 的依赖，全新的数据管道是在 Scalding 中写出来的。

3.从团队组织上而言，Twitter 已经转向了一个嵌入式的模型中。其中数据分析比以往更加紧密地与产品/工程团队发生着联系。

在 Twitter 的工作确实是令人兴奋的，因为你能站在这个平台上，引领目前世界最前沿的数据科技，打造最具竞争力的优势。而同时，人们对于大数据的渴望也一天比一天高。

Dan Ariely 曾经有一句话说得特别好：

「大数据其实有点儿像青少年的性。每一个人都兴致勃勃地谈论它，但是没有任何一个人真的知道该怎么做。每一个人都觉得身边的人都在尝试，为了不落人后，于是每个人都在外面宣城自己也已经有『伴儿』了」

现如今，有太多的人在如何成为一名优秀称职的数据分析师上表达着看法，给出自己的建议。Robert Chang 毫无疑问也是受益者。但是他回过头来再想想大家的讨论，会觉得人们往往更加侧重于去谈「技术」、「工具」、「技能组合」，而在 Chang 看来，那些东西确实很重要，但是让新人们知道数据分析师每一天的生活到底是什么样子的，具体的工作内容都是什么，这也非常重要。

于是，Chang 凭借着自己在 Twitter 工作两年的经历，以自己作为例子，首次打开 Twitter 数据分析师这扇神秘的大门。

A 型数据分析师 VS B 型数据分析师

Chang 在没来 Twitter 之前，总觉得数据分析师一定是在任何领域都能看堪称「独角兽」，不管是数据还是数学专业，都是顶尖人才。除了技术上很牛之外，书面写作和口头交流的能力也会特别强。更重要的是他们能够分清楚当下工作的轻重缓急，领导和管理一个项目团队。是啊，如今本身就是以数据为主导的文化，作为「数据分析师」，当然要给这个文化注入灵魂与活力啊！

在 Chang 加入 Twitter 的几个月后，他逐渐意识到：符合上述形容的「独角兽」确实存在，但是对于大部分人来说，上述的要求未免有点儿太不切实际了。 人们没有办法做到面面俱到。后来，Chang 通过 Quora 中的一篇回答，更深刻地理解了数据分析师的角色。在那篇文章中，数据分析师分成了两种类型：

A 型数据分析师： 他们主要负责「分析」。他们最关心数据背后的意义，往往使用统计等方式探知真相。其实他们的工作有点儿像「统计学家」，但是不一样的地方是，统计学专业涉及的内容他们统统掌握，但是他们还会一些统计学课本里面压根不曾出现的内容：比如数据清洗，如何处理超大数据组，数据视觉化，有关数据层面的报告撰写等等。

B 型数据分析师： B 型负责「建造」。他们跟前一种分析师有着相似的统计学背景，但他们同时还是非常牛叉的程序员，又或者是训练有素的软件工程师 。B 型数据分析师往往感兴趣于「如何利用数据来生产」。他们建立一些能够与用户互动的模型，往往以「推荐/推送」的形式出现，比如「你也许会认识的人」，「广告」，「电影」，「搜索结果」等等功能。

Chang 看到这样清楚的划分，非常后悔如果早几年有这么清楚的概念认识该多好啊。这样他就能够有选择性的发力，择其一方向来继续发展。这是数据分析师职场规划首先要考虑的标准。

Chang 的个人专业背景是「数学」、「运营研究」、「统计学」。所以他更倾向于把自己定位于 A 型数据分析师，但是与此同时他对 B 型分析师能够涉及那么多的工程开发工作而向往不已。

初创公司早期、快速发展的初创公司、以及实现规模化发展的初创公司中的数据分析师职位区别

在选择投身于科技行业的时候，最经常遇到的一个问题就是到底是加入一个大的科技公司好呢？还是加入一个小的科技公司好。在这个话题上已经有很多争论了，但是在「数据分析」上面的争论并不是很多。 所以在本章节要具体谈到的是，不同公司的规模、发展阶段中，数据分析师不同的角色定位。

处于不同发展阶段的科技公司生产数据的量与速度都是不一样的。一个还在尝试着寻找到「产品市场契合点」的初创公司完全不需要 Hadoop，因为公司本身就不存在多少的数据需要处理；而一个处在快速发展中的初创公司往往会遭遇更频密的数据冲击，也许 PostgreSQL 或者 Vertica 更适合这家公司的需要；而像 Twitter 这样的公司如果不借助 Hadoop 或者 Map-Reduce 框架，就完全无法有效地处理所有数据。

Chang 在 Twitter 学到的最有价值的一点内容就是：数据分析师从数据中提取出价值的能力，往往跟公司本身数据平台的成熟度有着密不可分的关系。 如果你想要明白自己从事的是哪种类型的数据分析工作，首先去做做调研，看看你意向中的这家公司的底层系统架构能够在多大程度上支持你的目标，这不仅仅对你好，也对公司好，借此看你个人的职业发展目标是否跟公司的需要契合起来。

在初创公司早期，最主要的分析重点是为了实现 ETL 进程，模块化数据，并且设计基模架构，将数据记录应用到上面。这样数据就能够追踪并存储。此处的目标是打下分析工具的基础，而不是分析本身。，

在快速发展的初创公司的中期，因为公司在快速发展，那么数据也在不断的增长。数据平台需要适应不断发展的新形势，新条件，在已经打好基础的前提下，开始逐渐实现向分析领域的过渡。一般来说，此时的分析工作主要围绕着制定 KPI，推动增长，寻找下一次增长机会等工作展开。

实现了规模增长的公司。当公司实现了规模化增长，数据也开始呈几何倍数的增长。此时公司需要利用数据来创造，或者保持某种竞争性优势，比如更好的搜索结果，更加相关的推荐内容，物流或者运营更加的高效合理。这个时候，诸如 ML 工程师，优化专家，实验设计师都可以参与进来一展拳脚了。

在 Chang 加入 Twitter 的时候，Twitter 已经有了非常成熟的平台以及非常稳定的底层结构。整个数据库内容都是非常干净，可靠的。ETL 进程每天轻松处理着数百个「任务调度」工作。（Map-Reduce）。更重要的是，在数据分析领域的人才都在数据平台、产品分析、用户增长、实验研究等多个领域，多个重点工作齐头并进一起展开。

关于 Chang 本人的经历

他是在用户增长领域安排的第一名专职数据分析师。事实上，这花了他们好几个月来研究产品、工程、还有数据分析到底该如何融合，才能实现这样一个岗位角色。Chang 的工作与产品团队紧密连接，根据这方面的工作经验，他将自己的工作职责划分成为了下面几类内容：

产品分析

数据传输通道

实验（A/B 测试）

建模

下面将会按照排列次序逐一解释

产品分析

对于一家消费级科技公司来说，产品分析意味着利用数据来更好地理解用户的声音和偏好。不管什么时候用户与产品进行着互动，Twitter 都会记录下来最有用的数据，存储好它们，以待未来某一天分析之用。

这个过程被称之为「记录」（logging）或者「工具化」（instrumentation），而且它还不断地自我演进。 通常情况下，数据分析往往很难实现某个具体的分析，因为数据要么是不太对，要么是缺失，要么是格式错误的。在这里，跟工程师保持非常好的关系非常有必要，因为数据分析能够帮助工程师确认 bug 的位置，或者系统中一些非预期的行为。反过来，工程师可以帮助数据分析弥补「数据鸿沟」，使得数据内容变得丰富，彼此相关，更加准确。

下面举出来了 Chang 在 Twitter 展开的几项与产品有关的分析案例：

推送通知分析：有多少用户能用得到「推送通知」？不同类型的推送通知具体的点击率都分别是多少？

SMS 发送率：在不同的数字载体上，Twitter 的 SMS 发送率都是怎么计算的？是不是在发展中国家这个发送率相对比较低？我们该怎样提升这个数字？

多账户：为什么在某些国家，一个人持有多个账户的比例会相对较高？背后是什么动机让一个人持有多个账户？

分析会以多种形式展开。有些时候公司会要求你对一次简单的数据拉取进行最直白的解读，又或者你需要想出一些新的方式方法来机选一个全新，且重要的运营指标。（比如 SMS 发送率），最后你会更加深刻地理解用户的行为。（比如一个人拥有多个账户）

在产品分析中不断研究，得到真知灼见，这是一个不断迭代演进的过程。它需要不断地提出问题，不断地理解商业情境，找出最正确的数据组来回答相应的问题。随着时间的累积，你将成为数据领域的专家，你会正确地估计出来执行一次分析大概得花多长时间。更重要的是，你将逐渐从一个被动响应的状态，逐渐过渡到主动采取行动的状态，这其中会牵连出来很多有趣的分析，这些内容都是产品负责人曾经压根没有考虑过的，因为他们不知道这些数据存在，又或者不同类型的数据以某种特殊的方式组合到一起竟然会得出如此惊人的结论。

此处需要的技能：

保存和工具化：确认数据鸿沟。与工程部门建立良好的协作关系；

有能力引导和确认相关的数据组，知道正确使用它们的方式；

理解不同形式的分析，能够在不同的分析执行之前就正确地估算出难易程度，所需时间长短；

掌握你的查询语言。一般来说是利用 R 或者 Python 来实现数据再加工；

数据管道

即使 A 型数据分析师不太可能自己编写代码，直接应用到用户那里，但是出乎很多人意料的是，包括 Chang 在内的很多 A 型数据分析师确实在给代码库写东西，目的只有一个：为了数据管道处理。

如果你从 Unix 那里听说过「对一系列命令的执行」，那么一个数据管道就意味着多个系列命令的执行，我们能够不断周而复始地自动捕捉，筛选，集合数据。

在来到 Twitter 之前，Chang 的分析绝大部分都是点对点的。在 Chang 的本地机器上，代码执行上一次或者几次。这些代码很少得到审查，也不太可能实现版本控制。但是当一个数据通道出现的时候，一系列的功能就浮出水面：比如「依赖管理」、「调度」、「源头分配」、「监控」、「错误报告」以及「警告」。

下面介绍了创建一个数据管道的标准流程：

你忽然意识到，如果一个数据组能够周而复始地自我重新产出，那么这个世界估计会因此受益；

在确认了需求之后，你开始设计「生产数据组」的「数据架构」；

开始编写你的代码，不管是在 Pig，Scalding，或者 SQL 中。这取决于你的数据环境是什么；

提交代码，进行代码审查（code review），准备后得到回馈，并做相应额外的修改。要么是因为你的设计逻辑不太对，要么是你的代码出于速度和效率的目的并没有优化到位；

应该有一个「测试」和「试运转」的环境，确保所有的运行都在既定的轨道上。

将你的代码融合到主库中

建立「监控」、「错误报告」以及「警告」等功能，以防止未来出现预期之外的状况。

很显然，数据通道比一个点对点的分析工具来说更加复杂，但是优势也非常明显，因为它是自动化运行着的，它所产出的数据能够进一步强化面板，这样更多的用户能够消费你的数据/结果。

另外，更加重要但是往往被人忽略的一点结果是，对于如何打造最优化的工程设计，这是一个非常棒的学习过程。如果你在日后需要开发一个特别定制的数据通道，比如机器学习，之前所做的工作就成为了扎实的基础。

在此处需要用到的技能：

版本控制，目前最流行的就是 Git；

知道如何去做「代码审核」，并且知道如何有效地给予反馈；

知道如何去测试，如何去试运行，当出现错误的时候知道如何「debug」；

「依赖管理，调度，资源分配，错误报告，警告」功能的设置。

接下来的篇章中，我们将谈到除了“产品分析”之外，其余的三种工作内容，它们分别是： 数据传输通道、 实验（A/B 测试）、以及 建模。

Twitter 是如何为硬件故障做准备的

Sat, 02 Jan 2016 11:10:45 CST

在理想的情况下，Twitter 的基础设施与运营总监马兹达克·哈希米（Mazdak Hashemi）可以走到公司的数据中心，然后拔掉其中一台服务器的电源线，这时公司的服务也不会受到影响。虽然他现在还不会这么做，但是他和他的团队一直在研究如何在 Twitter 内部模拟类似的故障，同时确保服务能够维持正常运行。

“在如此大的服务规模之下，我们的基础设施有可能会出现各种各样的问题，我们随时都可能出现断电、机架故障、配置不当或者网络故障。”哈希米说道，“所以我们开始思考，除了面对突如其来的故障以外，检测故障的最佳方式是什么。”

他的工程团队基本上设计了一系列的测试，他们会以可控的方式向系统注入故障，模拟上面提到的情况。这样做的目的是确保所有工作人员可以为各种意外故障做好准备，比如服务器宕机，或者电源线意外脱落导致整个服务器节点离线。

Twitter 会在服务中注入一些小型的故障，测试运行系统和基础设施的反应。它会监控 Twitter 服务的系统健康状况，确保不会有全站规模的故障发生，然后回滚之前注入的故障状态。在整个测试过程当中，这支团队还可以使用一系列的工具来了解系统的情况。他们希望可以监控服务器集群出现断电，或者在写入新配置的时候出现断网的问题。

以上都是 Twitter 内部应急工具的一部分，确保 Twitter 在任何情况之下都不会束手无策。“失败鲸”（Fail Whale）曾经是 Twitter 网站上的常驻吉祥物，不过现在 Twitter 正不遗余力地避免这条鲸鱼再次出现。

最终这个工具有望会被开源，这样就可以让开发者社区找到更多的使用方式，甚至对它进行改进。“Twitter 与其他公司的区别在于——我们的所有东西都是实时的。”哈希米说道，“我们不会说‘你去准备黑色星期五，你去准备超级碗。’其他人想到某些日子将要来临的时候就会做准备，但是对我们来说，每一天都可以是黑色星期五，每一天都可以是超级碗。我们的网站是充满不确定性的，世界这么大，什么事情都有可能发生。”

这些测试的意义当然不止如此。如果仅仅是为了测试的话，他们随时都可以拔掉服务器的网线来测试服务能否继续运行。这些测试的目标是为了确保每个团队都能准备好应对任何级别的真正事故。

“我希望终有一天可以在数据中心里随便拔掉一条电线，然后看看会发生什么事情。”哈希米说道，“我今天会这么做吗？也许不会，不过我现在还不想这么做。我对部分情况还是比较放心的，但是如果故障的层级越高，它所造成的影响也会越大。我们团队的终极考验是，当我们在数据中心随意拔掉各种线缆的时候，系统能否保持安然无恙。”

题图来自：Bryce Durbin

翻译：关嘉伟（ @consideRay）

A Look At One Way Twitter Prepares For Hardware Failures

Hootsuite：7个重要的Twitter分析指标

Wed, 30 Dec 2015 14:35:03 CST

分析，听起来就吓人。

现在我们要展示一些并不吓人的分析。事实上，社交网络确保分析更简单，每个人都能理解，不管是新人还是CEO。

Twitter分析就是一个例子。不管你每天推特一次还是五十次，社交网络都会收集这些信息，以及阅读这些推特的读者的信息。而且还会以复杂但可以理解的方式呈现这些洞察。你得到的是一系列数字，快速展示你的Twitter营销成败与否，以及如何改进。

为了使分析易于理解，我们将Twitter分析洞察细分为七个部分，这些洞察能帮助你短期内快速改善Twitter营销。

如何访问Twitter分析

重中之重：如何找到Twitter分析？自2014年8月分析就对所有用户开放了，你可以点击Twitter页右上角的头像，从下拉菜单中选择“分析”，或访问https://analytics.twitter.com/。你只有先访问分析页，Twitter才会开始向你推送推特数据。

点击分析标签后会链接到一个有更多标签的首页，你需要的大部分信息可以在头三个标签中找到：首页、推特和受众。其他标签可以在你熟悉之后或是发布更复杂的Twitter广告时再使用。

展现量

“展现量”单独并不能提供很多信息，但是，他可以给其他指标提供更多背景信息。如果你的50条推特获得了250条转发，那相当不错。但是如果这些推特获得了50万的展现量又如何呢？说明转发获得了新的传播。展现量随着时间累积会变的更有价值。Twitter已经认识到这一点，根据时间给用户提供展现量两种不同的视图。

首先，你可以在Analytics首页快速浏览你的展现量，就像上图。这个数字展示了过去28天你的推特展现量有多少，但是真正重要的是旁边的百分比，显示了展现量的变化，这样你就可以探究其中的秘诀了。

在快速变化的社交媒体界，展现量变化百分数也许更重要。在推特标签下，Twitter用柱状图和时间线展示了展现量的变化，显示了每天展现量是如何变化的。图表展示了原始展现量以及推特的数量。这个图表绝妙的地方是指出哪天你的营销策略表现最好，让你找到最佳方案。图表还显示了哪类推特能够产生最多展现量。天长日久就能清晰地塑造出推特营销的最佳内容、时机和方式。

参与率

参与率对社交媒体营销人员来说是最重要的指标之一，参与率将若干不同指标整合为一，给你提供一个更综合的洞察，展示人们和你的互动情况。根据Twitter，参与率提供了推特内容获得的参与数量，按照展现量进行划分。参与度按互动方式划分，包括：转发、回复、追随、点赞、链接点击、网卡点击、标签点击、嵌入式媒体点击、用户名点击、资料照片点击、推特传播。

参与率折线图展示过去一个月的进展。图表是互动式的，所以你可以悬停在某一点上收看当天的参与率。和展现量不同，折线图能向你展示参与率峰值，这样就能回溯当天的内容和推广策略，并从中获得更多收获。

点击量

如果非要从众多指标中选一个，那一定是点击量。点击量是一个更具体的社交媒体指标，因为它显示了用户的具体行为。

点击量能帮助你扩展经营目标，而不仅仅是提高品牌知名度。不管你是通过登录页收集潜在客户还是推动应用下载，点击量是你实现这些目标的途径。最可贵的是能追踪你的链接，这样你就能知道什么人通过什么途径点击你的推特导航，并沿着消费者的购买路径追踪他们。

点击量也能在Analytics的推特标签页找到，就在参与率下边。点击量以柱状图展示过去28天的情况。点击量峰值意味着你的推特内容非常有吸引力。找到这些内容，再发送一次。相同的人看到这些相同的信息的几率非常低，因此，这意味着你很可能获得一批新的潜在客户。

受众兴趣

社交媒体是社交工具，给营销人员接触整体受众提供机会。不像传统媒体，社交媒体用户拥有决定权。他们决定阅读什么或忽略什么。作为企业，你需要在适当的时机满足消费者的需求。Twitter提供了保障性的指标：受众的兴趣。

受众的兴趣是分析内容之一，它展示了你的追随者正在活跃讨论的流行话题是什么。Twitter收集了这些信息并强调了你的追随者分享的大部分内容是什么。它以柱状图显示最普遍的话题，以及每个话题感兴趣的追随者的比例。

受众的兴趣之所以重要是因为，品牌希望接触目标消费者，这些兴趣指标让你了解受众正在谈论的内容。如果你能创建适合这些主题的内容，那么，受众阅读、分享和评论这些内容的几率就会大大提升。

兴趣洞察可以在Analytics的“受众”标签下找到，或在生活方式概述部分找到。经常检查受众的兴趣，因为随着受众的参与会不断产生新的流行话题。

学习笔记：Twitter核心数据类库团队的Hadoop优化经验

Fri, 17 Jul 2015 09:49:48 CST

一、来源

Streaming Hadoop Performance Optimization at Scale, Lessons Learned at Twitter

(Data platform @Twitter)

二、观后感
2.1 概要
此稿介绍了Twitter的核心数据类库团队，在使用Hadoop处理离线任务时，使用的性能分析方法，及由此发现的问题和优化手段，对如何使用JVM/HotSpot profile（-Xprof）分析Hadoop Job的方法调用开销、Hadoop配置对象的高开销、MapReduce阶段的排序中对象序列化/反序列的高开销问题及优化等给出了实际可操作的方案。

其介绍了Apache Parquet这一面向列的存储格式，并成功应用于列投影（column project），配合predicated push-down技术，过滤不需要的列，极大提高了数据压缩比和序列化/反序列化的性能。
纯干货。32个赞！

2.2 优化总结
1) Profile！（-Xprofile）性能优化不能靠猜，而应靠分析！
2) 序列化开销很大，但是Hadoop里有许多序列化（操作）！
3) 根据特定（数据）访问模式，选择不同的存储格式（面向行还是面向列）！
4) 使用column projection。
5) 在Hadoop的MR阶段，排序开销很大，使用Raw Comparators以降低开销。
注：此排序针对如Comparator，其会引发序列化/反序列化操作。
6) I/O并不一定就是瓶颈。必要的时候要多I/O换取更少的CPU计算。

JVM/HotSpot原生profile能力（-Xprof），其优点如下：
1) 低开销（使用Stack sampling）。
2) 能揭示开销最大的方法调用。
3) 使用标准输出（Stdout）将结果直接写入Task Logs。

2.3 Hadoop的配置对象

1) Hadoop的Configuration Object开销出人意料的高。
2) Conf的操作看起来就像一个HashMap的操作。

3) 构造函数：读取+解压+分析一个来自磁盘的XML文件

4) get()调用引起正则表达式计算，变量替换。

5) 如果在循环中对上述等方法进行调用，或者每秒一次调用，开销很高.某些(Hadoop)Jobs有30%的时间花在配置相关的方法上！（的确是出人意料的高开销）

总之，没有profile(-Xprof)技术，不可能获取以上洞察，也不可能轻易找到优化的契机和方向，需要使用profile技术来获知I/O和CPU谁才是真正的瓶颈。

2.4 中间结果的压缩

Xprof揭示了spill线程中的压缩和解压缩操作消耗了大量时间。
中间结果是临时的。
使用lz4方法取代lzo level 3，减少了30%多的中间数据，使其能被更快地读取。
并使得某些大型Jobs提速150%。

2.5 对记录的序列化和反序列，会成为Hadoop Job中开销最高的操作！

2.6 对记录的序列化是CPU敏感的，相对比之下，I/O都不算什么了！

2.7 如何消除或者减小序列化/反序列化引起的（CPU）开销？
2.7.1 使用Hadoop的Raw Comparator API（来比较元素大小）
开销分析：如下图所示，Hadoop的MR在map和reduce阶段，会反序列化map结果的keys以在此阶段进行排序。

（反序列化操作）开销很大，特别是对于复杂的、非原语的keys，而这些keys又很常用。

Hadoop提供了一个RawComparator API，用于对已序列化的（原始的）数据（字节级）进行比较：

不幸的是，需要亲手实现一个自定义的Comparator。

现在，假设数据已序列化后的字节流，本身是易于比较的：
Scala有个很拉风的API，Scala还有一些宏可以产生这些API，以用于：
Tuples , case classes , thrift objects , primitives , Strings,等等数据结构。

怎么拉风法呢？首先，定义一个密集且易于比较的数据序列化（字节）格式：

其次，生成一个用于比较的方法，以利用这种数据格式的优势：

下图是采用上述优化手段后的比较开销对比：

提速到150%！
接着优化！

2.7.2 使用column projection
不要读取不需要的列：

1) 可使用Apache Parquet（列式文件格式）。

2) 使用特别的反序列化手段可以在面向行的存储中跳过一些不需要的字段。

面向列的存储中，一整列按顺序存储（而不是向面向行的存储那样，列是分开存储的）：

可以看到，面向列的存储，使得同类型的字段被顺序排在一起（易于压缩）：

采用Lzo + Parquet，文件小了2倍多！

2.7.3 Apache Parquet
1) 按列存储，可以有效地进行列投影（column projection）。
2) 可按需从磁盘上读取列。
3) 更重要的是：可以只反序列化需要的列！

看下效果：

可以看到，列数越少，Parquet的威力越大，到40列时，其效率反而不如Lzo Thrift。

在读取所有列的情况下，Parquet一般比面向行的存储慢。
Parquet是种密集格式，其读性能和模式中列的数目相关，空值读取也消耗时间。
而面向行的格式（thrift）是稀疏的，所以其读性能和数据的列数相关，空值读取是不消耗时间的。

跳过不需要的字段，如下所示：

虽然，没有降低I/O开销
但是，可以仅将感兴趣的字段编码进对象中
相对于从磁盘读取 + 略过编码后字节的开销，在解码字符串时所花的CPU时间要高的多！

看下各种列映射方案的对比：

Parquet Thrift还有很多优化空间；Parquet在选取的列数小于13列之前，是更快的；此模式相对平坦，且大多数列都被生成了。

还可以采用Predicate Push-Down策略，使得Parquet可以跳过一些不满足过滤条件的数据记录。
Parquet存储了一些统计信息，比如记录的chunks，所以在某些场景下，可以通过对这些统计信息进行读取分析，以跳过整个数据块（chunk）。

注：左图为column projection，中图为predicate push-down过滤，右图为组合效果。可以看到很多字段被跳过了，那绝壁可以优化序列化/反序列化的效率。

下图则展示了push-down过滤 + parquet的优化成效：

2.8 结语
感叹：Twitter真是一家伟大的公司！
上述优化手段，集群越大、Hadoop Job越多，效果越明显！

学习笔记：Twitter核心数据类库团队的Hadoop优化经验，首发于博客 - 伯乐在线。

Twitter：被谷歌收购或是最好结局

Wed, 17 Jun 2015 08:52:14 CST

Twitter 首席执行官科斯特罗宣布辞职之后，Twitter 股价一度上涨。不过连日来，华尔街诸多分析师对于 Twitter 纷纷进行了股票降级，并对更换 CEO 之后的 Twitter 前景仍不看好。多位分析师指出，被搜索巨头谷歌并购仍然是 Twitter 最好的出路，此举也将惠及是 Twitter 股票和股东。

在长期下课压力之下，科斯特罗最终宣布 7 月 1 日将离职，Twitter 联合创始人多西将担任临时 CEO，公司将寻找新的 CEO 人选。

不过据美国财经新闻网站“Marketwatch”报道，连日来，华尔街分析师对于 Twitter 前景的负面观点正在涌现，他们认为对于 Twitter 来说，最好的结局就是被谷歌并购。

6 月 16 日，美国 MKM 公司对 Twitter 股票进行了降级，从买入降级到中性。该公司认为在新用户增长以及 CEO 寻找方面，公司面临一系列不确定性。

上述公司相关人士表示，除了谷歌可能收购之外，在未来两个季度中，外界并没有看到 Twitter 业绩和股价能够上升的动力来源。

这位人士表示，从长期来看，Twitter 仍然具有一定的社交网络潜力，如果在用户的交互活跃、以及视频直播工具 Periscope 进展良好，则 Twitter 未来仍然会有利好。

上述公司的分析报告指出，从短期来看，只有来自谷歌的收购要约才能够大幅拉动 Twitter 的股价。

Twitter 曾经是和 Facebook 平起平坐的社交网络巨头，但是如今 Twitter 正在日渐没落。Facebook 在全球市场扩张，并且并购了 Instagram、WhatsApp 等移动端明星产品，已经将 Twitter 远远的甩在了身后。

与此同时，Snapchat、苹果 iMessage、黑莓 BBM 等手机聊天工具受到年轻人的欢迎，在用户增速上已经超过了 Twitter。

行业普遍认为，Twitter 的微型博客产品对于新用户来说过于复杂，许多怪异的符号让新用户敬而远之。产品不具有易用性，导致 Twitter 正在沦为一家小众市场公司。

之前媒体普遍报道，谷歌有意收购 Twitter。在社交网络领域，谷歌 CEO 佩奇曾经重金打造 Google+，希望用模仿的手段赶超 Facebook，但是 Google+ 已经彻底失败。如果能够获得 Twitter，谷歌将能够弥补社交网络产品的短板，并且将 Twitter 海量碎片信息和网页搜索服务紧密整合。

在宣布辞职消息时，科斯特罗也回应了有关其他公司并购 Twitter 的话题。他表示，Twitter 会“认真考虑”其他公司的收购计划，不过他本人认为，Twitter 最好的方式仍然是独立发展。

美国 MKM 公司的分析报告指出，如果 Twitter 面临外部公司的收购，则谷歌是一个水到渠成的并购方。谷歌拥有巨额现金，另外在网络广告上正在面临 Facebook 巨大的竞争压力，此外自行开发的社交网络表现不佳。

对于已经失败的 Google+，谷歌目前正在分拆其有价值功能，比如 Hangouts 聊天、Photos 照片上传分享均已经分拆为独立的安卓软件，不再受到 Google+ 产品的局限。

华尔街分析师指出，从历史上看，谷歌公司对于被收购目标的估值和报价不是很敏感，谷歌更加看重其和谷歌业务未来的协同效应。

迄今为止，谷歌并未证实过将收购 Twitter 公司。

移动互联网的高速发展，也让谷歌陷入了一场不大不小的危机中。手机用户倾向于使用 APP，而不是网页和网站，也逐渐抛弃了传统给出海量结果的网页搜索（信息查询效率太低），这殃及了谷歌最为重要的搜索广告业务。此外，尽管安卓系统已经成为智能手机时代垄断市场的“Windows”，但是由于中国等国家的安卓厂商，删除了谷歌的应用软件和服务，因此免费安卓系统的流行并未能够给谷歌带来直接的营收驱动。

在股票变动方面，Twitter 和谷歌堪称一对难兄难弟。在过去一年时间里，Twitter 的股价表现差于标普 500 指数，而在过去三个月时间里已经暴跌了 27%，过去 12 个月里暴跌 11%。距离辉煌时期相比，谷歌的市值也已经损失了相当大一部分，距离苹果差距越来越远。

Twitter 更换 CEO 的消息，为何未能让华尔街分析师感到兴奋呢？据报道，在 CEO 更替的分析师会议上，临时 CEO 多西曾经表示，不会在公司的战略或者方向上作出重大改革，这一表态让华尔街很是失望。

另外许多分析师批评 Twitter 缺乏长期增长的透明战略。富国银行报告指出，科斯特罗的下课，仍然无法解决 Twitter“令人混淆的市场定位问题”。

SterneAgee 公司表示，Twitter 在二季度用户增长上的模糊表态，可能意味着 Twitter 总体的用户规模可能已经在萎缩。

科斯特罗被迫下课的原因是执掌公司的业绩糟糕透顶，Twitter 长期亏损，虽然是一家年轻的社交网络，但是其用户增速开始下滑。最近，Twitter 报出了有史以来最糟糕的季度营收增幅。

面对 Twitter 的糟糕现状，长期支持 Twitter 的大股东萨卡（ChrisSacca）不久前发表了一篇 8500 字的文章，认为 Twitter 需要进行重大改革，包括更加以产品为中心，拥抱电子商务，制作话题页面等等。萨卡的长篇文章也在美国舆论和华尔街产生了不小的影响。

萨卡在文章中表示，在 Twitter 的愿景和近期发展目标上，外界存在太多的怀疑和误解，这是最让他感到担心的。

本文链接

Twitter创始人向互联网上那些扯淡的统计数据宣战了

Sun, 15 Mar 2015 00:46:17 CST

本文由 Medium 和 Ev Williams 授权《好奇心日报》发布。作者 Ev Williams 是 Twitter 和 Medium 的创始人。

最近有人引用我的话，说我 “一点也不在乎”Instagram 比 Twitter 有更多的用户。要是你看过我的文章就会发现，我说不在乎的前头还有个大大的“如果”二字呢。我的原话如下：

跟 Instagram 相比，Twitter 对世界的影响力可以说是非常巨大的。二者之间至少是苹果与橘子的差别。Twitter 是我们想要其成为的样子。它是实时信息网络，世界上发生的所有事情在 Twitter 上都能看到——要事在 Twitter 上讨论，世界领导人在 Twitter 上对话。如果真是这样，说实话我一点也不在乎 Instagram 上有更多的人看美图。

当然了，我可能小看了 Instagram 对许多人的影响。这款软件制作很精美，能够让人创造并享受艺术，而且还有社交功能，这通常是件好事。但我说上面的话的原因几乎与之无关（跟 Twitter 也无关）。我说这些话是因为，那些报道、投资和建设消费性互联网服务的人在评价网站成功的时候，标准很单一，这让我感到越来越气恼。

哪个矩形更大？

当你问一个初中生，一个长 3 英寸的矩形，和一个长 2.5 英寸的矩形，哪一个比较大时，他们会告诉你这问题没有意义，除非他们知道其他信息——也就是矩形的宽。

但是，当我们说一家公司或服务更“大”时，基本上是基于单一的数字——具体来说就是过去 30 天内的使用者数量。甚至都没细究何为“使用”，这太荒唐了。

以最近的 Instagram/Twitter 对比为例，我看到 Will Oremus 在 Slate 上的文章里就没有再滥用 “更大”这个标题。他很好地解释了为何事情没这么简单。这是一篇很值得读的文章，其中心意思如下:

那么 Instagram 比 Twitter 更大吗？不是——它与 Twitter 有所差别。一个基本上是私人媒体，另一个基本上是公开媒体；一个以图片为中心，另一个则关注想法和理念；它们俩规模都很大，并且都在不断扩展。

上周是 Medium 点击量最大的一周——我们差不多可以这么说。从 Medium.com 的独立访客数量来看，成绩可谓非常棒。而这主要是因为一个高度热门帖子被广泛转发（主要在 Facebook 上）。但是与用户在我们网站上的平均停留时间相比，大多数访问者只停留了一小部分时间，并且几乎没有读什么东西。

这就是为什么在行业内，我们的第一考量是“TTR”，即总阅读时间（total time reading）。用这个指标来衡量人们在文章页面所花费时间是不太完美，但我们觉得它能更好地反应用户是否从 Medium 获得了有价值的信息。就 TTR 而言，Medium 上周的访问量依然是庞大的，然而十月初那一周的 TTR 数据比上周高出了 50%，但是独立访客数量只有上周的 60%（即十月初那周每位访客的实际阅读时间要长许多）。

Mat Honan 在 Wired 上发表了一篇关于当今媒体现状的文章，很准确地指出了如今每个人都身处“注意力角逐战”中的现实。但它用“独立访客数量”来比较了不同媒体在这场战役中的表现：

根据该图表（误导性地使用“阅读量”标签），Buzzfeed 比《纽约时报》的访问量更大。但是从同一个图表中我们可以知道，Medium 上周的访问量比十月份那周的更大。虽然我们只关心关注度——而不是其他重要价值——但这并不能说明太多问题。也许从总量上，BuzzFeed 比《纽约时报》获得了更多的关注，但我们应该停止使用这种指向单一的图表来讨论这类问题。

进一步而言，上面的图表——以及你在媒体上看到的关于网站访问量的比较——主要是基于 ComScore 的数据，并且只包含了美国用户。这就存在两个很大的问题：1. 大部分网站运营商提供的数据与 ComScore 的差距很大。越小的网站越是如此（原因在于它们的取样方法不同）；2. 网络用户总数中只有一小部分在美国。如今每个网站都是全球性的——只是在全球化程度上有所差异。如果没有明示只对美国地区用户感兴趣，那么仅仅披露美国用户的数据就会有很大的误导性。

最后，ComScore 的数据是否包含应用的访问量，这一点尚不清楚。我知道他们在一定范围内跟踪记录应用的使用量，但他们在上表中是否计算了所有《纽约时报》的应用（或者 BuzzFeed 的应用）呢？（如果您知道的话请留言）

我们更关注人们的阅读时间而非 Medium 的访客数量，因为这是一个有着无限资讯内容的世界，在这个世界里，你只要点击，就能获知无数抓人眼球的事物，还有接连不断的消息推送——所以有人在真正地花时间阅读，就是一件意义重大的事情。物以稀为贵嘛。虽然现在人们愿意给予媒体和网络的关注量总体大幅上升——主要是由于到处都可以用手机联网——但它终究是有限的。

同意这一观点的不止我们。Chartbeat 的 Tony Haile 为推广“注意力网站（Attention Web）”这一理念，做了很多非常棒的工作（这个概念与“点击量网站[Click Web]”是相反的）。他希望通过转向衡量注意力，人们能对网站进行改良：

对高质量内容的发布者而言，他们不是简单地基于点击量来给广告定价的，他们依据的是其累积获得的时间和注意力。而这或许正是他们所寻找的生命线。在互联网世界里，时间是稀缺资源，我们会将更多时间花在好的内容上。根据时间和注意力的标准来对给广告定价，意味着与只是靠链接诱饵吸引流量的网站相比，优秀的内容发布者能够向其页面上的广告收取更高的费用。

Upworthy 同样也倡导“时间代表品质”的理念：

我们愿意这么想，因为分享让人们确实觉得有趣又有价值的内容——而不是让人们大量点击的内容，对我们来说很有成就感。虽然以访问人次和页面点击量为标准，我们的绩效可能更好看，但我们很高兴做一点牺牲，因为这是真正衡量客户满意度的指标。

而 Wired 的那篇文章还提及了在广告行业，时间为什么更加宝贵：

你的点击很宝贵，你的关注也很宝贵，但对于广告商而言，最宝贵的还是你的时间——而内容发布者说，他们想要根据读者花费在网站上的时间而不仅仅是页面点击量来收取广告费。所以按照这个逻辑，用户在一个报道上的花的时间更多，相应页面上广告的收费就越高。

但是这里也有个问题，时间实际上并不能真正用来衡量价值。它衡量的是成本，以此作为价值的替代物。

广告主并不是真的想要你的时间——他们想要的是给你留下印象，不管是有意识的还是无意识的（而他们最终想要的，是你的钱）。

我写这篇文章，也不是真的想要你的时间——我是想要影响你的思考方式。如果我的修辞技艺能够让我用更少的时间完成它（为了我自己也为了你），那自然更好。

而 Medium 也不是真的想要任何人的时间。我们是想建立一个平台，让人们在这里表达自我，给其他人留下印象。让人们去思考，去改变人们的思维方式，去教会人们一些东西，或者建立起情感上的联系。而这些都是很难衡量的。

如果 Medium 出现了一些新的内容类别、形式或作者，内容既让人过瘾又非常受欢迎，但是我们认为不具有显著价值或持久的重要性，这种情况该怎么办呢？例如肥皂剧或者 Farmville of Medium 的帖子。我们的 TTR 值可能会高到捅破房顶，可能还会让我们感受到成功的幻觉，并因此很高兴。但是花费用户的时间并不是我们真正的目标，而浪费人们时间则更是与我们的目标背道而驰。

这就是所有单一标准的问题所在。正如 Jonah Peretti 所说，不存在什么“万能标准”：

我觉得如今这个行业里人们到处乱窜，试图找到一个用来衡量内容的万能标准。要么全是关于份额，要么全是关于占用时间，或者全是关于页面点击量，或者全是关于访问人次。问题是你只能优化其中的一项，所以你必须进行选择。如果你想要优化多项标准的话，那你就得做出一系列的妥协。

早些年我在 Google 的时候，记得墙上挂着一个（粉笔画的）图表记着搜索的数量。这看起来似乎是衡量价值的合理办法。实际上，它一度强调让搜索尽可能少占用人们的时间。如果你的服务是提供实用价值，而不是作为媒体的话，这或许是个不错的目标。

（Twitter 既有实用属性又有媒体属性，而它的部分优点在于其极度简洁——此外，跟 Google 一样，它的大部分意图是为了把人们指引向其他地方。所以优化使用时间没什么意义。）

如果你看看其他卓越的高科技公司——例如 Apple——很明显他们的目标不是为了追求用户数量而做优化。虽然网络效应（以及收入）意味着他们也会在意此项数据，但是通过专注于生产最出色的产品，他们已经建立起这个星球上最有价值的企业——实际上，这些企业的战略之一就是生产一系列彼此相互补充的产品，然后尽可能多地把它们（以合适的利润率）卖出去，而且还要让同一位用户买好几款自己的产品。

历史上还有许多其他公司的教训，他们因用户数量的骤增而备受赞誉，但其中的大部分最终又都以惨败告终。

其实如果能够更多地关注深度而非广度的话，大多数网络公司是能够创造出更好的产品和更多价值的。

其实过去有个时期情况就是如此。在互联网时代之初，人们谈论页面点击量的机率至少和谈论访客数量一样多。但是在应用兴起前，这已经变得过时又无意义（跟在那之前的“热点”一样），而应用的兴起只是让它变得更明显了。

2006 年，我写了一篇博客提出了这个观点。

强调页面点击量变得愚蠢，但出于技术原因，强调 MAU/UV（Unique Visitor,访问网站的一台电脑客户端为一个访客）又是有害的。

如果你所关心的——或想要报道的——是对这个世界的影响，这一切就变得很微妙。你不是在测量一个矩形，而是在衡量一个多维度的空间。你必须承认事情很难被完美评估，你只能从多项标准和一些事例中试着去学到尽可能多的东西。

如果你想评估一家公司的价值，理论上可能容易得多。从财务的角度看，一家公司的价值就是它长期盈利的能力。这并不简单，而且对于新公司来说，成长轨道至关重要。但令人惊奇的是，华尔街似乎都认同“用户数量=价值”的公式（Google 和 Apple 这些逆天的例子除外）。当然，这又会渗入到对私人公司估价的过程里，并影响风险投资者以及科技媒体的想法。

如果你是一个创业者（或者上市公司的员工），可别落入这个圈套中。

数量是重要的，用户的数量也是重要的，而其他很多东西也同样重要。不同的服务在以不同的方式创造价值。比起数量，你要同样相信（或者更加相信）自己的直觉。想清楚什么是重要的，然后创造出美好的事物。

本文链接

【产品经理手册】twitter高级PM的产品经

Tue, 06 May 2014 23:29:42 CST

PAUL ROSANIA

Twitter高级PM，2005年他毕业于Dartmouth学院计算机专业，在创办CollegeJobConnect之前他曾做过几年咨询。该项目夭折了，但他这次失败经历让他接到了一位著名的硅谷创始人的电话，这位创始人听过PAUL，他想了解PAUL是否适合加入他们的初创作为首位高级产品经理（Growth Hacker）Paul同意了，于2011年进驻硅谷，并在那里工作了一年，不久他接到了Twitter的来电；他之前成功让初创企业实现10倍增长，搬砖coding、产品战略都很行，但他觉得自己应该做更纯产品的职位，并想在大舞台上施展拳脚。所以他接受了Twitter的邀请，现在已经入职10个月了。

访谈总结

PM跟运动教练有哪些相似之处？

站在用户的角度意味着什么？

成功的产品经理必备三素质；

在Twitter做PM学到的最重要的东西；

问：在进入Twitter之前你的背景非常有意思。能聊聊你这一路是如何走过来的吗？

答：我职业生涯的早期，有点走偏了。在Twitter之前，我在两家初创做程序猿，有家是我自己创办的，我还做过三年的管理咨询。上一家初创，我首次把全部时间花在保持产品增长上。逐渐，我把时间分摊给产品管理、头脑风暴、路标规划、功能优先排序等方面，当然还有Coding。

来Twitter之后，我决定完全投入到产品管理中。Twitter有很多世界顶级的程序猿，我觉得自己能在产品层面贡献更多力量。我虽是一名计算机专业的学生，但我的热情一直都在产品上，并会想尽一切办法设计这些产品并将其上线。进入Twitter，我想要锻炼这些能力，特别是产品领导力、长远规划以及一切能让产品上线的能力。所以我决定在Twitter做PM，从促进产品的增长做起。我的职能在过去的几个月内不断演进，不只是专注于产品的增长，我开始拓宽职能做一些与公司相关的其他事情。

问：你觉得，产品经理的目标和目的是什么？在短期的产品实习期内哪些能力是最值得我们去培养的？

答：产品管理的职能在每个公司都不尽相同。在初创企业，有很多公司都把产品管理和项目管理合并到一个职能中了。也有一些公司把他们拆分为好几块职能。选择拆分的公司一般都有自己的方法在二者间取得平衡。在项目管理中，你的首要任务是确保你做的东西能按时交付。在产品管理中，你的目标是确定你在做对的产品，并结合公司的目标对产品功能进行正确的优先级组合，当然同时也要站在用户的一边。

在Twitter，我们一般会与技术项目经理（Technical Program Manager）协作，他们一般是跨领域的，但更接近项目经理的职能。在我们最大最复杂的项目里，我会和一名技术项目经理合作。其他项目里，我则直接行使项目管理职能。

我觉得有一点对于PM的成功特别重要：为了将产品送到用户手中去做任何事。我工作的大头之一就是去做那些能让事情办妥的脏活累活。也就是说，你得经常写邮件、代表团队出席会议blabla，任何能帮助团队顺利完成项目的事情都得去做。

曾经我有次听某人问另一人：PM职位真的重要吗？虽然，我和很多看似有不错产品感的工程师一起工作过。但如果有工程师问我这个问题，我会反问他：你愿意花所有的时间去打造一款产品吗？或者说你愿意话费所有的精力去做计划和协调吗？PM除了写代码和把控制量外，需要专注于让产品上线。

当你全身心投入到产品开发中时，你不能一直与用户保持直接接触。PM的一部分职责便是保持与产品用户的联系。在Twitter这尤为困难，你有两亿活跃用户，真的很难通过直觉或与朋友交谈就能推断出用户的需求。因为这些都不能代表用户样本。

所以提炼出正确的能设计我们产品的心理框架是比较耗费时间的，但这个心理框架却是PM的重要价值。我觉得你现在炒掉Twitter或任何一家公司的所有产品经理，几个月内产品也不会有太大问题。但接下来你就会发现，你的产品的市场关注度在下降，或是你在发布一些用户根本不关心的新功能。所以必须要有人成天盯着你的用户。而PM就是帮你干这事儿的。

优秀PM最后的一项技能，用个比方来说。PM有点像体育教练。你不直接管理球员或是跟他们谈签约。你所有的影响都是非直接的。你的成就，最后你团队的成就，都靠你自己了。如果你的队员不尊重你，那么这活儿你也甭干了。

优秀的PM总是能领导团队走向成功，尽管他们从未踏上那虚拟的竞技场。他们就是团队的粘合剂，给团队胜利的力量，让团队专注于团队目标。

对于PM应该关注的技能，我觉得有三方面：组织、沟通和思想领导力。

组织能力是成功的关键。话虽然老掉牙，但却是实话。我之前说过PM要做任何能帮助产品上线的事，其中一部分工作就是谨记那些应该被完成任务。找到能组织你的思维、问题和待完成事项的方法。我花了很长时间去建立适合自己的组织机制，而且我在不断改善。最终，我的方法使得我的上级能相信我可以干成事情，他们不需要监督我，而我的团队也明白他们交给我的事情我一定不会忘记或搞砸。

沟通会有直接帮助。作为一名PM，在别人眼里，你就是产品的全权接口。否则，别人会直接去找你的团队成员，这会分散成员的注意力并降低团队效率。最低的要求是你要能对问题有即时、清晰、简洁的回应。（大量的邮件）。再进一步，你要能将产品的中长期目标规划出路标，并向别人阐述清楚。当别人明白你要干嘛且为什么那么干之后，他们才更可能放手让你和你的团队去实现你的愿景。

思想领导力是指你对产品和行业有冷静客观的认识，并对产品未来的走向有一个清晰且饱含热情的蓝图。这貌似是最重要的能力了，但没有组织和沟通能力，你将会得到一份糟糕的领导力，以及一份没人知道或关心的美好产品规划。

问：你说“用户的支持者”是什么意思呢？

答：让我用Twitter的一个具体例子来说明吧。请想一下我们的注册流程。每位Twitter用户都能凭直觉去解释你为什么需要一个用户名。因为没有用户名，别人就找不到你的资料并关注你，也就不能@你了。但是当你和潜在用户交谈时，你会发现有些人就是不明白为什么注册流程是那样的。什么是用户名？我为什么要个用户名？

最终，你开始从用户反馈中去查找这种模式，你就发现你的用户并不像你想的那样去理解你的产品。作为一名PM，找出这些模式是你的职责。随着时间推移，这些模式会在关于用户如何理解你的产品上，形成大量直觉性的东西，那会你就会诧异：我居然能预测用户的反馈？！这就是我说的支持用户了。确保多数用户体验的质量是我的职责。

作为一名新手PM，你的直觉是未经打磨的，但你会随着跟用户的交流而进步。最初，你找到的模式很简单：用户在跟密码纠缠。后来你发现更广度的启发式思维，网页格式千万不能太简单或太直接。你开始将这些启发式思维联系起来，并产生新的认识。经过不断重复和再造，这些启发式思维便形成了你的产品直觉基础。

问：你在Twitter做PM期间，是如何持续做到跟用户一起并感同身受的？

答：虽然有很多策略，但最重要的一点是：跟你的用户交谈。

我们在Twitter有点被宠坏的感觉，因为我们有一只非常优秀的用研团队负责保持我们与用户的联系。我基本一有时间就会扎进他们给出的研究结果。这样的待遇并不是什么好事，因为这种接触是非直接的。作为PM，将用研结果从抽象中解读出来，并把用户看成是几部分占比不同的人群应该是小菜一碟才对。

量化的数据很关键，在同使用你产品的用户真身保持联系时也同样关键。我有时候会志愿帮助别人修修电脑神马的，这期间经常就有人问关于Twitter的问题。即便看着用户做最简单的事，如登录，也是非常有意义的。很多人会犯一些常见错误，如重复输入错误的密码。在尝试了几次后，他们甚至会认为Twitter的登录功能有问题，而不会意识到自己一直在输入错误的密码。

这些都是普通的用户错误，而现场观看他们犯错的过程也是很有用的。不然这件事情感觉起来总是很抽象。我们毕竟还是普通人。

所以我认为“共情”一词较为贴切，但我也不认为你能靠共情能力去搞清楚所有的问题。

我很羡慕那些拥有纯付费用户团队。付费用户要么会高兴地给你反馈，要么会气愤地要求你给出答复。有时候听到这些抱怨你会觉得不爽，但至少他们给了你明白的反馈。但我不能寄希望从两亿用户中找出一小撮，他们就能准确代表庞大的用户群体，我从不认为这样做有很大作用。所以我在理解“普通用户”上有很大的困难。这才是我们的用研团队真正的用武之地。他们用能准确代表大量用户群体的方式，针对各种问题进行各种规模的用户研究。

问：如果你在Twitter做PM时有学到最重要的东西，你觉得是什么？

答：我过去，在知道别人会怎么回答的情况下，仍会经常问别人某些问题。或者我在交付某物时后脑勺总会发麻提醒我说：是不是有啥东西漏掉了？比如，有人问我项目接下来要干嘛，我会写封邮件分条列出，即便在我按下发送按钮时我就知道他们的第一个问题是什么，但我也不会把他们的疑问写进邮件里，这或许是因为懒惰吧。如果我预测没错，他们就会来问那个问题。那时你就会想：擦，我是怎么知道的？nnd我怎么当时没回答它？

在职业生涯前期我经常遇到这样的事，但自从做了PM，我才明白我要从根本去解决这个问题。对于PM来说，这是致命的失败。你确实需要认真解决它。当你或别人在做某事时，你就是那个留意那些未完成工作的人。不然，你到时候职能交出一个A-级的产品。你会打心底里明白它是个A-级别的产品，也就只会有A-的表现。作为一名PM，那是不可接受的。钱在你那里打了水漂。

如果你的产品很逊，你不能指望有人会帮你指明方向。你被招聘过来做一名决策者，其他人甚至不需要知道该问什么问题就最好。（因为所有的问题你都应该考虑和解决）

问：你在Twitter做PM的职责有哪些？

答：我之前说过：组织、沟通和思想领导是要培养的重要能力。这些也是Twitter的PM核心职能的一部分。

勤奋是每位PM的另一项职责。你的产品是你本人和你付出的写照。这意味着你对待自己、团队和工作要实诚（有时甚至需要苛刻一点）。一名优秀的PM想做正确的事，即便那样做可能会比较痛苦。也就是说，多做工作并向自己和他人证明你的产品和你想象的一样棒，你的愿景是正确的。

对我来讲，这种级别的勤奋并不是先天的。每天会发生很多事情让你的大脑过载。我很快意识到我不能试图把每件事都记在脑子里。有那么几次我忘记了别人要我做的事，或当我步入会议室才发现对于我想要说的并不像我想的那样准备充分。

现在，我会记下所有的事情，即便我准备马上做这件事。一些简单任务，我使用Mac电脑上的Things应用来记。当我遇见别人，我会用Evernote记下我们谈话的内容。这样，我再不会忘记要做的事了，也不会忘记跟团队成员的谈话内容。当我有一个产品idea时，我会在相应的项目Google Doc里记下来。这些工具把我的脑子从记事中解脱出来了，使我能够专注于组织和计划。

我还发现书写帮助我保持诚实：有时候想起来很酷的点子文字解释起来却不容易。那表明你的思考并不完善。

最后我要说的是，作为PM，你对你的时间没有完整控制权。你经常要辗转于各种别人的会议、邮件和问题中。你很想反抗，但这些障碍确实就是你工作的一部分。你要清楚的认识到某个会议是否重要，但也要意识到你度过了充满干扰的一天，却为你的团队排除了干扰。（有时候那些会议可以帮助你搜集信息并调整你的产品规划，这能让你关注到正确的目标，从长远来看也是省时间的。）

如果你觉得有点扛不住了，不要害怕腾出时间来做长时思考。当我很忙时，我会在一周的几天中留出1-2小时的时间，以确保我有足够的时间去思考。你需要时间去整合你的思维，如果你自己不预留这些时间，别人就会占用它。

问：我能用python和r编程，但却没有我听过的其他PM那么扎实的开发经验。作为一个有点技术背景的人，我能做些什么来弥补呢？

答：很强的技术背景对于你做PM有两方面好处：

一，它能帮助你与工程师建立良好的关系。如果你能接地气地干活，他们则更愿意相信你做决定时会真正考虑到他们，而不是在哄他们。而且你在向他们描述你想要实现的功能时也不怎么会说错话。

二，很强的技术背景帮助你更好的去评估成本，这能使你觉察到激发团队能力的时机从而让你的团队更优秀。当你跟一支真正优秀的团队工作时，你知道怎么去激发他们，大家都会成长，你的团队，你的公司和你自己都能从中受益。

所以，为了弥补经验的欠缺，集思广益一些方法如：找机会去“黑”一个项目，最好是跟你的团队一起写代码。在Twitter我们每个季度都有黑客周，那对我来说是一个向团队展示我的能力的好时机，也是一种锻炼。

问：我比较担心我刚进公司三个月不能有太大影响力。我想学很多东西，我知道我会学好，但我想表现自己的影响力。你的PM头3个月时怎么度过的？如果重来一次，你会做些什么不同的事呢？

答：我立马就动手表现自己了，我推荐那样做。在Twitter，我们一直在寻找那些内容充实的实习项目，就是那些能让实习生独立负责完成的项目，且要能在他们实习的三个月内能够发布。此外，这些项目都是正式的。不是练手或赶工项目。

你的公司提供这样的机会最好，但如果他们没有那样做，那么请告诉他们。你也许确实没有机会展示自己的影响力。但你一定是有影响力的，在Twitter我见过很多实习生做出一些有影响力的事。一定要确保你做的是一个能在你离开之前发布的正式项目，当你离开后也才能拿出来说说。

问：你在看待一款教育类产品是都有哪些心理标准？换句话说，你在评判一款产品有多成功时会有哪些标准？

答：我对教育软件了解不多，但我可以说点通用的标准：做用户喜欢的产品。与他们交谈，聆听他们的反馈。从用户的角度去清楚、直接地描述你正在解决的问题。将任务细化。专注于更重要的项目。上线发布。

我特别推荐Marty Cagan写的Inspired。这是一本适合快速阅读的书，他会为你在学产品开发时提供一个框架。

问：经常有人建议我在做PM之前应该先去做份技术工作，因为在做了PM后很难再转回技术（代码、设计等）。你怎么看这个建议？一毕业就去做PM好还是先做个一般工作再转PM好？

答：我收到的最好的职业建议是：你做其他的事对于你想做的事来讲没有任何好处。做你喜欢的事。少去担心假设中的职业转换。如果你的热情就在产品管理中，你是不会离开这个职业的。

这个社会很需要优秀的程序员和设计师。如果你要转做这些职位，你也能找到工作。

原文： The Product Manager Handbook（包含了十名国外著名PM关于一些产品职位的问答，该系列文章将持续更新）

本文由Tobbi翻译投稿，转载请注明出处并附带本文链接

系列文章导航

【产品经理手册】如何搞定产品经理职位（五）

【产品经理手册】如何搞定产品经理职位（六）---微软SEAN GABRIEL

【产品经理手册】如何搞定产品经理职务（七）--如何成为出色的非技术pm

您可能也喜欢：
【产品经理手册】如何成为出色的非技术PM	【产品经理手册】产品经理问答-微软SEAN GABRIEL	【产品经理手册】如何搞定产品经理职位2	【产品经理手册】如何搞定产品经理职位3	【产品经理手册】如何搞定产品经理职位4
无觅

（关注更多人人都是产品经理观点，参与微信互动（微信搜索“人人都是产品经理”或“woshipm”）

Twitter的分布式自增ID算法Snowflake

Sat, 09 May 2015 11:52:11 CST

Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统中不同机器产生的id必须不同。

Snowflake算法核心

把 时间戳， 工作机器id， 序列号组合在一起。

除了最高位bit标记为不可用以外，其余三组bit占位均可浮动，看具体的业务需求而定。 默认情况下41bit的时间戳可以支持该算法使用到2082年，10bit的工作机器id可以支持1023台机器，序列号支持1毫秒产生4095个自增序列id。下文会具体分析。

Snowflake – 时间戳

这里时间戳的细度是毫秒级，具体代码如下，建议使用64位linux系统机器，因为有 vdso，gettimeofday()在用户态就可以完成操作，减少了进入内核态的损耗。

uint64_t generateStamp()

{

timeval tv;

gettimeofday(&tv, 0);

return (uint64_t)tv.tv_sec * 1000 + (uint64_t)tv.tv_usec / 1000;

}

默认情况下有41个bit可以供使用，那么一共有T（1llu << 41）毫秒供你使用分配，年份 = T / (3600 * 24 * 365 * 1000) = 69.7年。如果你只给时间戳分配39个bit使用，那么根据同样的算法最后年份 = 17.4年。

Snowflake – 工作机器id

严格意义上来说这个bit段的使用可以是进程级， 机器级的话你可以使用MAC地址来唯一标示工作机器， 工作进程级可以使用IP+Path来区分工作进程。如果工作机器比较少，可以使用配置文件来设置这个id是一个不错的选择，如果机器过多配置文件的维护是一个灾难性的事情。

这里的解决方案是需要一个工作id分配的进程，可以使用自己编写一个简单进程来记录分配id，或者利用Mysql auto_increment机制也可以达到效果。

工作进程与工作id分配器只是在工作进程启动的时候交互一次，然后工作进程可以自行将分配的id数据落文件，下一次启动直接读取文件里的id使用。

PS：这个工作机器id的bit段也可以进一步拆分，比如用前5个bit标记进程id，后5个bit标记线程id之类:D

Snowflake – 序列号

序列号就是一系列的自增id（多线程建议使用atomic），为了处理在同一毫秒内需要给多条消息分配id，若同一毫秒把序列号用完了，则“等待至下一毫秒”。

uint64_t waitNextMs(uint64_t lastStamp)

{

uint64_t cur = 0;

do {

cur = generateStamp();

} while (cur <= lastStamp);

return cur;

}

总体来说，是一个很高效很方便的GUID产生算法，一个int64_t字段就可以胜任，不像现在主流128bit的GUID算法，即使无法保证严格的id序列性，但是对于特定的业务，比如用做游戏服务器端的GUID产生会很方便。另外，在多线程的环境下，序列号使用atomic可以在代码实现上有效减少锁的密度。

结构为：

   0---0000000000 0000000000 0000000000 0000000000 0 --- 00000 ---00000 ---0000000000 00

public class IdWorker {
    private final long        workerId;
    private final static long twepoch            = 1361753741828L;
    private long              sequence           = 0L;
    private final static long workerIdBits       = 4L;
    private final static long maxWorkerId        = -1L ^ -1L << workerIdBits;
    private final static long sequenceBits       = 10L;

    private final static long workerIdShift      = sequenceBits;
    private final static long timestampLeftShift = sequenceBits + workerIdBits;
    private final static long sequenceMask       = -1L ^ -1L << sequenceBits;

    private long              lastTimestamp      = -1L;

    public IdWorker(final long workerId) {
        super();
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format(
                "worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        this.workerId = workerId;
    }

    public synchronized long nextId() {
        long timestamp = this.timeGen();
        if (this.lastTimestamp == timestamp) {
            this.sequence = (this.sequence + 1) & sequenceMask;
            if (this.sequence == 0) {
                System.out.println("###########" + sequenceMask);
                timestamp = this.tilNextMillis(this.lastTimestamp);
            }
        } else {
            this.sequence = 0;
        }
        if (timestamp < this.lastTimestamp) {
            try {
                throw new Exception(String.format(
                    "Clock moved backwards.  Refusing to generate id for %d milliseconds",
                    this.lastTimestamp - timestamp));
            } catch (Exception e) {
                e.printStackTrace();
            }
        }

        this.lastTimestamp = timestamp;
        long nextId = ((timestamp - twepoch << timestampLeftShift))
                      | (this.workerId << workerIdShift) | (this.sequence);
        //  System.out.println("timestamp:" + timestamp + ",timestampLeftShift:"
        //       + timestampLeftShift + ",nextId:" + nextId + ",workerId:"
        //       + workerId + ",sequence:" + sequence);
        return nextId;
    }

    private long tilNextMillis(final long lastTimestamp) {
        long timestamp = this.timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = this.timeGen();
        }
        return timestamp;
    }

    private long timeGen() {
        return System.currentTimeMillis();
    }

    public static void main(String[] args) throws InterruptedException {
        IdWorker worker2 = new IdWorker(2);
        System.out.println(worker2.nextId());
        Thread.sleep(1000L);
        System.out.println(worker2.nextId());
    }
}

Reference:

http://www.lanindex.com/twitter-snowflake/

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

Twitter下一步攻破方向：搜索和群聊

Thu, 04 Sep 2014 18:37:41 CST

9 月 4 日，Twitter 财务官安东尼·诺托（Anthony Noto）透露，Twitter 将优先改进搜索服务，同时还将开发群聊功能。

在花旗全球技术大会上，诺托称，Twitter 新任产品主管丹尼尔·格拉夫（Daniel Graf）把提升搜索功能作为 2015 年工作的首要目标之一。

诺托说：“说起搜索功能，我们拥有一个关于主题 Twitter 消息的信息数据集。搜索的结构层次必须适用于这种分类方法。”他还表示，Twitter 因此需要一种算法，这种算法要展示特定主题内容的深度和广度，并要让内容与用户相关联。

这就与 Twitter 更大的战略目标联系在一起——Twitter 希望更好地组织自己的内容，帮助用户从信息噪音中分离出有趣、及时的 Twitter 信息。Twitter 已经着手改进时间轴功能。时间轴可以展示陌生用户发布的信息，这是它最显著的特点，也是颇具争议的特点。

Twitter 时间轴以相反的时间顺序展示信息，自从八年前上线以来，这项功能就没有变化。一些早期 Twitter 用户甚至将时间轴奉为核心 Twitter 体验。

但诺托表示：“对于用户，它（时间轴）并不是最相关的体验。”举例来说，如果用户没有打开 Twitter 应用，一些及时的 Twitter 信息可能被其他信息淹没，埋藏在时间轴底部。

“如果要更好地组织 Twitter 内容，Twitter 就要把信息及时放到用户眼前。”诺托补充道。

上周六，Twitter 首席执行官迪克·科斯特罗(Dick Costolo)尝试在 Twitter 上解释时间轴信息推送服务的优点。针对用户抱怨的“不速之客类信息”，科斯特罗称用户两次刷新时间轴，时间轴就会展示其他用户喜爱的信息，Twitter 无法连续两次展示新的内容。

“否则，用户的第二次内容请求就会返回空值。我认为，满足用户的请求是一个值得我们努力的目标。”科斯特罗这样解释。

诺托表示，改进将是渐进式的。“我们将有条不紊地加以改进。我们会测试，确保自己了解各种可能性。我们不会妄想用户在某一天早晨醒来，突然发现自己时间轴完全以一种算法推送信息。”他说道。

诺托还暗示，Twitter 可能正在开发群聊功能。Twitter 私信功能历来居于次要地位。公开是 Twitter 服务的本质特性，Twitter 内部一直争论私信功能所扮演的角色。过去一年，随着消息应用的兴起，Twitter 已经让私信功能扮演一个更加突出的角色。诺托认为私信功能可能会更加社交化。

现在，Twitter 用户只能每次向一个帐号发送一条私信。诺托表示：“假如我用 Twitter 发布了一条球赛信息，同学可能会回复这条信息。但是，我不想当着老板和其他用户的面与同学讨论球赛。那么我就会选择私密的交流方式，我可能会选择私信功能。目前，私信功能只支持一对一会话，还不支持一对多会话。因此，这就是一个围绕分享或表达的创新样本。”

本文链接

Twitter信息抓取工具 – TinfoLeak

Tue, 30 Sep 2014 11:20:20 CST

TinfoLeak是一款Python编写的Twitter用户信息抓取软件，主要的抓取的信息有：

1、基础信息包括名字、头像、关注者、所在位置等。

2、Twitter用户所使用的操作系统和设备信息。

3、Twitter用户的应用和社交网络信息。

4、生成形迹图。

5、以GoogleEarth的形式展示用户的推文。

6、下载用户全部推过的图片。

7、Twitter用户使用过的“#话题”，并收集时间和日期。

8、Twitter用户提到过的其他用户，并记录下时间和日期。

9、Twitter用户使用过的主题。

支持用日期和关键字对抓取下的信息进行过滤。

下载地址： http://vicenteaguileradiaz.com/tools/

[参考信息来源： hackersonlineclub ， vicenteaguileradiaz FreeBuf小编嘎巴撰写，转载请注明来自FreeBuf.COM ]

Twitter推移动应用开发工具Fabric 阿里百度已在用

Thu, 23 Oct 2014 18:53:00 CST

Twitter推移动应用开发工具Fabric 阿里百度已在用

【TechWeb报道】10月23日消息，据国外媒体报道，Twitter周三发布了一款免费的移动应用开发者工具包——Fabric，旨在帮助开发者更好地编程以及增加公司收益。

Twitter周三召开了首届面向移动应用开发者的“一对多消息服务”大会，并在会上推出了Fabric平台。Twitter CEO迪克·科斯特罗（Dick Costolo）表示，Fabric是“移动软件开发的未来”。目前，阿里巴巴和百度等中国科技巨头已经开始使用其中的一些工具。

Fabric可支持216个国家或地区的28种语言，它包括许多软件工具，可以用来解决应用程序的分发与稳定、简化用户登录方式以及推送广告等。此举能够使Twitter功能直接到达新开发的手机应用程序，这将大大扩大消息传递平台。

其中Digits功能可方便用户使用电话号码直接登录移动应用。这对于新兴市场的用户非常有用。用户不必使用电子邮件就可直接注册移动应用账号。

Fabric使Twitter成为用户在移动应用的小程序上实时分享评论的核心，并提供一种十分便捷推广的登录方式。

Twitter表示，百度和阿里巴巴都使用该公司的Crashlytics工具对应用崩溃问题进行调试和分析。Twitter的MoPub广告服务也面向中国开发者开放。

在Twitter之前，Facebook已经开始通过软件开发工具与中国的开发者建立联系。Facebook副总裁沃恩·史密斯(Vaughan Smith)今年5月表示，中国有数以千计的应用开发者使用该公司的工具。

IT瘾twitter推荐

聊聊Twitter的架构决策

从0开始设计Twitter系统架构

功能需求

非功能需求

twitter服务的概要设计

twitter服务的详细设计

推文服务（Tweet service）

生成唯一的推文Id

可扩展性设计

社交网络服务（Social graph service）

用户时间线服务（User timeline service）

扇出服务（Fanout Service）

主页时间线服务（Home timeline service）

搜索服务（Search service）

照片和视频

Twitter的网络

Twitter的最终详细设计

Elon Musk 在 Twitter 上发中文七步诗

[分享创造] 开源一个类微博 twitter 的网站

FBI希望Facebook和Twitter开发威胁预警工具

人民日报发布 Twitter 和 Facebook 欢迎 Google 回归

相关报道

深度剖析：Twitter怎样支持上亿用户 - 个人文章 - SegmentFault

Twitter的实时通知架构

Twitter数据挖掘及其可视化

毕设、论文内容

实时热点话题挖掘

LDA模型

Hoffman OLDA

WOLDA

最具有代表性的推文计算

KL-mean

余弦距离

最大熵

情感分析

情感分析方法

预处理

特征提取

特征选择

分类器选择

实验

数据可视化

简单的统计结果可视化

Hashtag统计

地理位置信息的可视化

话题结果可视化

矩形树图

气泡图

旭日图

情感分析的可视化

Twitter数据挖掘平台的设计与实现

系统的总体框架

数据抓取模块

数据存储模块

MongoDB

数据压缩

主题分析模块

情感分析模块

WEB模块

界面展示

总结与展望

主要内容总结

工作展望

热点话题方面

情感分析方面

数据挖掘系统

哪些人在Twitter上发言的语法最规范？比尔盖茨排第二

Twitter的这种信息分类技术，在社交媒体中怎么用最有效？

#1. 了解你的受众正在聊什么

#2. 如果你正在策划一个 Campaign，记得要让你的 hashtag 具备独特性。

#3. 简短但有力有话题，让用户更简单地参与

#4. 千万不要忘记了你要推广的产品和品牌

#5. 灵活利用热门话题标签

#6. 要让你的 hashtag 更加人性化，用户在日常生活中也能用

#7. 增加 hashtag 的曝光

#8. 一定要盯住你的 hashtag

Twitter切断了多个备份政客删除帖子的网站API访问

Pokémon Go成为美国史上最受欢迎的手游，活跃用户超过Twitter

Twitter投资人说：只有具备这些的公司才能拿到风投