# Twitter 计划分析 1000 亿条推文 > 原文： [http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) 如果 Twitter 是某些人认为的“网络神经系统”，那么从神经系统来的所有这些信号（推文）的大脑究竟是什么呢？ 大脑就是 Twitter 分析系统，而 Twitter 的分析负责人 Kevin Weil 是负责计算超过 1000 亿条 Tweet（约等于人脑中神经元数量）含义的单元。 目前，Twitter 仅占预期的 1000 亿条推文的 10％，但始终要做好计划。 Kevin 在 [Hadoop Meetup](http://www.meetup.com/hadoop/) 上的 Twitter 上发表了 [Hadoop 和协议缓冲区的演讲，解释了 Twitter 如何计划使用所有数据来回答关键业务问题。](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) Twitter 有兴趣回答哪种类型的问题？ 帮助他们更好地了解 Twitter 的问题。 像这样的问题： 1. 一天我们要处理多少个请求？ 2. 平均延迟时间是多少？ 3. 一天有多少次搜索？ 4. 多少个唯一查询，多少个唯一用户，他们的地理分布是什么？ 5. 作为用户的推文，我们能告诉我们什么？ 6. 谁转发了更多？ 7. 移动用户的用法有何不同？ 8. 同时出了什么问题？ 9. 哪些功能使用户着迷？ 10. 用户的声誉是什么？ 11. 转推的深度有多深？ 12. 哪些新功能有效？ 还有更多。 这些问题可以帮助他们理解 Twitter，其分析系统可以帮助他们更快地获得答案。 ## Hadoop 和 Pig 用于分析 您能想到的任何问题都需要分析大数据来寻找答案。 1000 亿是很多推文。 这就是 Twitter 使用 [Hadoop 和 Pig](http://www.slideshare.net/kevinweil/hadoop-pig-and-twitter-nosql-east-2009) 作为其分析平台的原因。 Hadoop 提供：在分布式文件系统上的键值存储，水平可伸缩性，容错性以及用于计算的 map-reduce。 Pig 是一种查询机制，可以在 Hadoop 之上编写复杂的查询。 说您正在使用 Hadoop 仅仅是故事的开始。 故事的其余部分是使用 Hadoop 的最佳方法是什么？ 例如，如何在 Hadoop 中存储数据？ 这似乎是一个奇怪的问题，但答案却有很大的后果。 在关系数据库中，您不存储数据，数据库存储您，或者，它为您存储数据。 API 以行格式移动数据。 Hadoop 并非如此。 Hadoop 的键值模型意味着由您决定如何存储数据。 您的选择与性能，可以存储多少数据以及对将来的变化做出反应的敏捷程度有很大关系。 每个推文都有 12 个字段，其中 3 个具有子结构，并且随着新功能的添加，这些字段可以并且会随着时间而变化。 存储此数据的最佳方法是什么？ ## 数据存储在协议缓冲区中以保持数据的高效和灵活 Twitter 认为 CSV，XML，JSON 和协议缓冲区是可能的存储格式。 协议缓冲区*是一种以有效但可扩展的格式对结构化数据进行编码的方法。 Google 几乎所有内部​​RPC 协议和文件格式*都使用协议缓冲区。 BSON（二进制 JSON）尚未进行评估，但可能因为它没有 IDL（接口定义语言）而无法使用。 [Avro](http://hadoop.apache.org/avro/) 是他们将来会考虑的一种潜在选择。 创建了一个评估矩阵，该矩阵宣布 Protocol Buffers 为获胜者。 赢得协议缓冲区是因为它允许将数据拆分到不同的节点上。 它不仅可用于推文（日志，文件存储，RPC 等），还可用于其他数据； 它有效地解析； 可以添加，更改和删除字段，而无需更改已部署的代码； 编码很小； 它支持层次关系。 所有其他选项均未通过这些条件中的一个或多个。 ## IDL 用于 Codegen 出乎意料的是，效率，灵活性和其他神圣的怪胎指标并不是 Twitter 喜欢协议缓冲区的唯一原因。 通常被视为弱点的是，协议缓冲区使用 IDL 来描述数据结构，实际上被 Twitter 视为大赢家。 必须定义数据结构 IDL 通常被视为浪费时间。 但是作为构建过程的一部分，它们从 IDL 中生成所有与 Hadoop 相关的代码：协议缓冲区 InoutFOrmats，OutputFormats，Writables，Pig LoadFuncs，Pig StoreFuncs 等。 以前为每个新数据结构手动编写的所有代码现在都可以从 IDL 中自动自动生成。 这样可以节省大量精力，并且代码的错误少得多。 IDL 实际上节省了时间。 某一时刻，模型驱动的自动生成是许多项目的通用策略。 然后，时尚开始产生一切。 Codegen 似乎还不够敏捷。 一旦生成了所有内容，您就开始真正担心语言的冗长性，这使每个人都转向了更加动态的语言，具有讽刺意味的是，DSL 仍然经常被列为 Ruby 之类的语言的优势。 手编码的另一个后果是周炎的框架。 框架有助于平息认为必须从头开始编写所有内容而造成的损害。 很高兴看到代码生成再次流行。 使用声明性规范，然后编写高效的，特定于系统的代码生成器，功能非常强大。 数据结构是低挂的果实，但是也可以自动化更大，更复杂的过程。 总体而言，这是一次非常有趣和有益的演讲。 我喜欢看到基于想要的内容和原因对不同选项进行的仔细评估。 令人耳目一新的是，这些明智的选择如何协同作用，并构成了一个更好，更稳定的系统。 ## 相关文章 1. [Twitter 上的 Hadoop 和协议缓冲区](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) 2. [Twitter 背后的窥视](http://borasky-research.net/2010/02/17/a-peek-under-twitters-hood)-Twitter 的开源页面上线了。 3. [Hadoop](http://hadoop.apache.org/) 4. [协议缓冲区](http://code.google.com/p/protobuf/) 5. [Hadoop 湾区用户组-2 月 17 日在 Yahoo! -RECAP](http://developer.yahoo.net/blogs/hadoop/2010/02/hadoop_bay_area_user_group_feb.html) 6. [Twitter 说](http://blog.twitter.com/2010/02/measuring-tweets.html)“今天，我们每天看到 5000 万条推文，平均每秒 600 条推文。” > 这就是为什么 Twitter 使用 Hadoop 和 Pig 作为分析平台的原因 has a broken url 谢谢。 似乎所有 URL 由于某种原因都被转义。 现在应该修复。 所有这些推文中有 99％是垃圾。 他们究竟将如何分析其中的任何内容？ 从理论上讲，每条推文都是一种人类思想或一种交流意识。 分析大量数据将意味着识别人脑在各个方面的功能-例如给定的时间，星期几，地理位置，文化，趋势等-因此，了解这种人类行为就构成了识别人的大脑。 在线大众。 （仅限于 Twitter）。 最后，它是所有统计信息-一定比例的网络将为这种现象数据做出贡献。 希望我们能更多地了解人的思想链是如何运作的，并希望这有助于神经科学家作为研究工具。 我的$ 0.02 〜Vj 几个月前，奇怪的 Twitter Twitter Tweet ID 泛滥成灾，他们怎么可能拥有 1000 亿条 Tweet？ 我会用“神经系统”代替“神经系统”，“神经系统”将这些信号/推文发送给我们的外行贿赂者，改为“突触发射”，其中指出推文更恰当地是*大脑*内部的信号。 它是对信号触发或重推的分析，我们发现了模式，并且在这些模式中有意义。 有关 Synaptic 网站的更多信息，请访问： http://synapticweb.pbworks.com/ @khrisloux 我要说的是 [Vivisimo 的 Velocity 搜索引擎](http://vivisimo.com/)可以为他们提供很多帮助。 有趣的帖子，托德。 您的帖子中有一些复制错误： “ 5.作为用户，我们可以从他们的推特中获得什么？” | 可能应该是：我们能告诉用户什么... “ 8.如果同时出错怎么办？” | 怎么了... “ 11.转发的深度有多深？” | 有多深... 不是要分析什么，而是要服务于什么业务目的。 无论如何，tweet 中的 URI 可以为用户分析提供更多的价值。 “ Protocol Buffers 之所以获奖，是因为它允许将数据拆分到不同的节点上；它不仅可以用于推文（日志，文件存储，RPC 等），而且还可以重用；它可以高效地解析；可以添加，更改和删除字段而无需 更改已部署的代码；编码很小；它支持层次关系。所有其他选项都无法通过其中一个或多个条件。” 只需用纯文本替换 Protocol Buffer 并享受相同的方法即可：)严重的是，我没有得到 PB 选择背后的基本原理，但最终还是要随心所欲。 除非您在 hdfs 的顶部构建 HBase 之类的东西，否则当您运行冗长的批处理作业时，内部存储格式并不重要。 “今天，我们每天看到 5000 万条推文，平均每秒 600 条推文。” 什么！？ 每秒 600 条推文！？ ... 哇...我真是令人难以置信地不知所措...我的意思是我觉得 Twitter 可以解决所有这些可扩展性问题，因为它们每秒有成千上万甚至数十万条推文。 天哪，如果他们用 C 编写 Twitter 系统，就可以轻松地通过单个服务器处理“所有”流量。 无论哪种方式，我仍然认为 Twitter 是一个好主意，他们应该得到应有的荣誉，他们在 Twitter 的整个软件包和声誉方面都做得很好。 但是，为什么不聘请 C 程序员来重写他们的堆栈并降低成百上千的成本呢？ @罗伯特·古尔德（Robert Gould）：我也为如此低的数量感到惊讶。 虽然据我了解，问题不在于处理传入的 tweet，而是将它们发送给所有订户。 请记住，某些用户有数千个（或数百万个）关注者。 用 C 重写对可伸缩性没有多大帮助。 它将使系统稍微快一些，但不超过一个数量级，以可维护性，稳定性和开发速度为代价。 我认为经过大量分析，并从大型 Twitter 数据库中获取了大量数据之后，我们会发现我们的逻辑性不如我们想像的那样，而且实际上是可预测的。 模式将得出结论，就像地球上所有其他生物一样，我们受到重力，季节，夜晚和白天的影响，x 类型的人更有可能鸣叫 x 等。我认为这一实验肯定会证实人类是 习惯的生物。