# Facebook 的新实时分析系统：HBase 每天处理 200 亿个事件 > 原文： [http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html](http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html)  Facebook 再次这样做。 他们建立了另一个系统，能够对大量的实时数据流进行有用的处理。 上次我们看到 Facebook 发布其[新的实时消息系统：HBase 每月存储 135 亿条消息](http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)。 这次，它是一个实时分析系统，每天处理*超过 200 亿个事件（每秒 200,000 个事件），时延不到 30 秒*。 Facebook 工程经理 Alex Himel [解释了他们构建的](http://www.facebook.com/note.php?note_id=10150103900258920)（[[视频](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments)）以及所需的规模： > 在过去的一年中，社交插件已成为数百万网站的重要且不断增长的流量来源。 上周，我们发布了新版本的“网站洞察”，以使网站所有者可以更好地分析人们如何与其内容进行互动，并帮助他们实时优化网站。 为此，我们必须设计一个系统，每天处理 200 亿个事件（每秒 200,000 个事件），而延迟不到 30 秒。 亚历克斯在演讲中做得很好。 强烈推荐。 但是让我们更深入地了解发生了什么... Facebook 通过通过[社交插件](http://developers.facebook.com/docs/plugins/)的病毒传播，将非 Facebook 网站重新绑定到 Facebook 中，并将 Facebook 网站重新绑定到 Facebook 中，从而实现了这种强大的分析系统的需求，这是 Facebook 出色的计划，旨在实现全球网络统治 非 Facebook 网站。 基本上，人们可以做的任何事情都会被 Facebook 捕获并反馈，而 Facebook 上所做的任何事情都可以显示在您的网站上，从而在两者之间建立更紧密的联系。 Facebook 的社交插件是 Roman Empire Management101。您不必征服所有人就可以建立帝国。 您只要控制每个人，使他们意识到自己可以被征服的威胁，同时使他们意识到，哦，与罗马友好可以赚很多钱。 我记得这一策略已经工作了很长时间。 毫无疑问，您在网站上看到了社交插件。 社交插件可让您查看朋友喜欢，在网络上的站点上评论或共享的内容。 想法是将社交插件放在网站上，使内容更具吸引力。 您的朋友可以看到您喜欢的东西，而网站可以看到每个人都喜欢的东西。 引人入胜的内容为您带来更多点击，更多喜欢和更多评论。 对于企业或品牌甚至个人而言，内容越具有吸引力，人们看到的内容就越多，新闻源中出现的内容就越多，从而将其吸引到网站的流量也就越大。 以前的孤狼网是内容猎人无声无息地跟踪着网站的地方，如今已变成一个迷人的小村庄，每个人都知道您的名字。 这就是社交的力量。 例如，此处有关 HighScalability 的帖子现在具有 [Like 按钮](http://developers.facebook.com/docs/reference/plugins/like/)。 TechCrunch 已使用 Facebook 的评论系统移至[。 立即辩论集中在评论系统本身的质量上，但这并不是重点，重点是使 TechCrunch 更深入地投入到 Facebook 的 500+百万用户的生态系统中。 其他插件包括：推荐，活动源，登录，注册，Facepile 和实时流。](http://techcrunch.com/2011/03/01/facebook-rolls-out-overhauled-comments-system-try-them-now-on-techcrunch/) 除非您能理解所有这些数据，否则它们意义不大，并且还向内容提供商证明了社交插件确实确实使他们的网站更具吸引力。 这就是 Facebook 的[洞察系统](http://www.allfacebook.com/facebook-rolls-out-expanded-insights-for-domains-2011-03)出现的地方。这是一个分析系统，可让您访问所收集的所有多汁数据。 它提供统计信息，例如“赞”按钮分析，“评论”框分析，“热门页面”，“受众特征”和“自然共享”。 想象一下，数百万个网站和数十亿个页面以及数百万的人通过这些社交插件不断地流式传输数据。 您如何实时理解所有这些数据？ 这是一个具有挑战性的问题。 ## 价值主张 借助 Insights System，内容生产者可以看到人们喜欢的东西，这将使内容生产者能够产生更多人们喜欢的东西，从而提高网络的内容质量，从而为用户提供更好的 Facebook 体验。 ## 系统目标 * 以非常可靠的方式为人们提供实时计数器，这些计数器涉及许多不同的指标，并解决了数据偏差问题。 * 提供匿名数据。 您无法弄清这些人是谁。 * 展示为什么插件很有价值。 您的业​​务从中获得什么价值？ * 使数据更具可操作性。 帮助用户采取行动，使其内容更具价值。 * 新的 UI 隐喻。 使用漏斗的想法。 * 有多少人看到了该插件，有多少人对此采取了行动，以及有多少人转化为访问您网站的流量。 * 使数据更及时。 * 他们实时进行。 从 48 小时转向 30 秒。 * 消除了多个故障点以实现此目标。 ## 挑战性 * **许多事件类型** * 跟踪 100 多个指标。 * 插件印象。 * 喜欢 * 新闻提要印象 * 新闻订阅源点击 * 客层 * **大量数据** * 每天 200 亿个事件（每秒 200,000 个事件） * **数据偏斜-密钥分布不均** * 喜欢遵循类似幂律分布的方法。 长尾巴很少有人喜欢，但有些资源却得到大量喜欢。 * 这带来了热区，热键和锁争用的问题。 ## 实现了一堆不同的原型 * **MySQL 数据库计数器** * 排有一把钥匙和一个柜台。 * 导致大量数据库活动。 * 统计信息每天存储在桶中。 每天午夜时分，统计数据都会累积。 * 当达到过渡期时，这将导致对数据库的大量写入，从而导致大量的锁争用。 * 尝试通过考虑时区来分散工作。 * 试图以不同的方式分割事物。 * 高写入率导致锁争用，很容易使数据库超载，必须不断监视数据库，并且必须重新考虑其分片策略。 * 解决方案不适合该问题。 * **内存中计数器** * 如果您担心 IO 中的瓶颈，则将其全部放入内存中。 * 没有规模问题。 计数器存储在内存中，因此写入速度快并且计数器易于分片。 * 由于未说明的原因，感觉到内存中的计数器并不像其他方法那样准确。 甚至只有 1％的失败率也是不可接受的。 Analytics（分析）可以赚钱，所以计数器必须非常准确。 * 他们没有实现这个系统。 这是一个思想实验，准确性问题导致他们继续前进。 * **MapReduce** * 将 Hadoop / Hive 用于先前的解决方案。 * 灵活。 易于运行。 可以处理大量写入和读取的 IO。 不必知道他们将如何提前查询。 数据可以存储然后查询。 * 不是实时的。 许多依赖项。 很多失败点。 复杂的系统。 不够可靠，无法达到实时目标。 * **卡桑德拉** * 基于可用性和写入率，HBase 似乎是一个更好的解决方案。 * 写速度是要解决的巨大瓶颈。 ## 获胜者：HBase + Scribe + Ptail + Puma * 在高层次上： * HBase 在分布式计算机上存储数据。 * 使用尾部架构，新事件存储在日志文件中，并且尾部有日志。 * 系统汇总事件并将其写入存储。 * UI 会拉出数据并将其显示给用户。 * 数据流 * 用户在网页上单击“赞”。 * 向 Facebook 发送 AJAX 请求。 * 使用 Scribe 将请求写入日志文件。 * 编写极其精简的日志行。 日志行越紧凑，则可以在内存中存储的越多。 * 抄写员处理文件翻转之类的问题。 * Scribe 建立在 Hadoop 建立在同一个 HTFS 文件存储上。 * 尾巴 * 使用 Ptail 从日志文件读取数据。 Ptail 是一个内部工具，用于聚合来自多个 Scribe 存储的数据。 它拖尾日志文件并提取数据。 * Ptail 数据分为三个流，因此最终可以将它们发送到不同数据中心中自己的群集。 * 插件印象 * 新闻提要印象 * 动作（插件+新闻源） * 彪马 * 批处理数据可减少热键的影响。 尽管 HBase 每秒可以处理大量写入操作，但它们仍要批处理数据。 热门文章会产生大量的印象和新闻提要印象，这将导致巨大的数据偏斜，从而导致 IO 问题。 批处理越多越好。 * 批量平均 1.5 秒。 想要批处理更长的时间，但是它们具有太多的 URL，以至于在创建哈希表时它们用尽了内存。 * 等待上一次刷新完成以开始新批处理，以避免锁争用问题。 * UI 渲染数据 * 前端都是用 PHP 编写的。 * 后端是用 Java 编写的，并且 Thrift 用作消息传递格式，因此 PHP 程序可以查询 Java 服务。 * 缓存解决方案用于使网页显示更快。 * 效果因统计信息而异。 计数器可以很快回来。 在域中查找顶级 URL 可能需要更长的时间。 范围从 0.5 到几秒钟。 * 缓存的数据越长越长，实时性就越差。 * 在 Memcache 中设置不同的缓存 TTL。 * MapReduce * 然后将数据发送到 MapReduce 服务器，以便可以通过 Hive 查询。 * 这也可以用作备份计划，因为可以从 Hive 恢复数据。 * 一段时间后，原始日志将被删除。 * HBase 是分发列存储。 * Hadoop 的数据库接口。 Facebook 的内部人员在 HBase 上工作。 * 与关系数据库不同，您不在表之间创建映射。 * 您不创建索引。 您拥有主行键的唯一索引。 * 通过行键，您可以拥有数百万个稀疏列的存储。 非常灵活。 您不必指定架构。 您定义列族，可以随时向其中添加键。 * WAL 预写日志是可伸缩性和可靠性的关键功能，它是应该执行的操作的日志。 * 根据密钥，数据将分片到区域服务器。 * 首先写给 WAL。 * 数据被存入内存。 在某个时间点，或者如果已经积累了足够的数据，则将数据刷新到磁盘。 * 如果机器出现故障，您可以从 WAL 重新创建数据。 因此，不会永久丢失数据。 * 结合使用日志和内存存储，它们可以可靠地处理极高的 IO 率。 * HBase 处理故障检测并自动跨故障路由。 * 当前，HBase 重新分片是手动完成的。 * 自动热点检测和重新分片在 HBase 的路线图上，但还没有。 * 每个星期二，有人查看密钥并决定对分片计划进行哪些更改。 * **模式** * 在每个 URL 上存储一堆计数器。 * 行键是唯一的查找键，是反向域的 MD5 哈希 * 选择适当的密钥结构有助于扫描和分片。 * 他们遇到的问题是将数据正确分片到不同的计算机上。 使用 MD5 哈希值可以更容易地说出该范围在此处，该范围在该位置。 * 对于 URL，它们会执行类似的操作，此外还会在其上添加一个 ID。 Facebook 中的每个 URL 都有一个唯一的 ID，该 ID 用于帮助分片。 * 使用反向域，例如 *com.facebook /* ，以便将数据聚集在一起。 HBase 确实擅长扫描集群数据，因此，如果他们存储数据以便集群在一起，则它们可以有效地计算整个域的统计信息。 * 将每行 URL 和每个单元格视为一个计数器，就可以为每个单元格设置不同的 TTL（生存时间）。 因此，如果每小时进行一次计数，则没有必要永久保留每个 URL，因此他们将 TTL 设置为两周。 通常按每个列族设置 TTL。 * 每个服务器每秒可处理 10,000 次写入。 * 从日志文件读取数据时，检查点用于防止数据丢失。 * 裁缝将日志流检查点保存在 HBase 中。 * 在启动时重播，因此不会丢失数据。 * 用于检测点击欺诈，但没有内置欺诈检测。 * **泰勒热点** * 在分布式系统中，系统的一个部分可能比另一个部分更热。 * 一个示例是区域服务器可能很热，因为以这种方式定向了更多的密钥。 * 一个尾巴也可能落后于另一个。 * 如果一个拖尾落后一个小时，而其他拖尾已经更新，那么您将在 UI 中显示哪些数字？ * 例如，展示次数比操作要高得多，因此点击率在过去一小时中要高得多。 * 解决方案是找出最新的拖尾，并在查询指标时使用。 * **未来方向** * **热门列表** * 对于 YouTube 这样的域名，很难找到最喜欢的 URL（最受欢迎的 URL），因为这些 URL 可以快速共享数百万个 URL。 * 需要更多创新的解决方案来保持内存中的排序并随着数据的变化而保持最新。 * **不同的用户计数** * 一个时间窗中**上有多少人喜欢某个 URL。 在 MapReduce 中很容易做到，而在幼稚的计数器解决方案中很难做到。** * **适用于社交插件**以外的应用程序 * **移至多个数据中心** * 当前是单个数据中心，但希望迁移到多个数据中心。 * 当前的后备计划是使用 MapReduce 系统。 * 备份系统每晚都会进行测试。 比较针对 Hive 和此新系统的查询，以查看它们是否匹配。 * **项目** * 花了大约 5 个月的时间。 * 首先有两名工程师开始从事该项目。 然后添加了 50％的工程师。 * 前端有两个 UI 人员​​。 * 看起来大约有 14 个人从工程，设计，PM 和运营中从事了该产品的工作。 当我们查看消息传递系统和此分析系统时，我们注意到两个系统的共同点：大量，HBase，实时。 以可靠，及时的方式处理大量写入负载的挑战是这些问题的共同基础。 Facebook 专注于 HBase，Hadoop，HDFS 生态系统，并指望稍后解决的操作问题。 其他人之所以选择 Cassandra，是因为他们喜欢 Cassandra 的可伸缩性，多数据中心功能以及易于使用的功能，但它并不适合整个分析堆栈。 这对您意味着什么？ 即使您不是 Facebook，该体系结构也足够简单，并且由足够多的现成工具组成，甚至可以用于许多小型项目。 ## 相关文章 * [Medialets 体系结构-击败艰巨的移动设备数据洪水](http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html)-分析平台的另一种表现。 * [Twitter 的计划分析 1000 亿条推文](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) * [扩展分析解决方案技术讲座（3/2/11）[HQ]](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments) 这是一个很棒的文章。 如何在不同的时间范围内进行汇总？ 每个<计数器和时间窗口>对都有单独的单元格吗？ 好消息是，即使您不是 Facebook 人士，也没有整个工程师团队来构建您的分析平台，您仍然可以使用现有的带有 [OpenTSDB](http://opentsdb.net) 的开源软件来构建类似的平台。 在 StumbleUpon，我们仅使用 20 个节点群集中的 3 个即可轻松地[每秒处理 200,000 个事件](https://issues.apache.org/jira/browse/HBASE-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008872#comment-13008872)，因此，大概您还可以使用更多节点轻松地将其扩展为每天数十亿个事件。 当 Facebook 工程师在 6 个月前启动该项目时，Cassandra 没有分布式计数器，该计数器现在已提交到主干中。 Twitter 正在 Facebook 上投入大量资金用于实时分析（请参阅 Rainbird）。 由于计数器写入分散在多个主机上，因此写入速率对于 Cassandra 来说应该不是瓶颈。 对于 HBase，每个计数器仍然受单个区域服务器性能的约束吗？ 两者的性能比较将很有趣。 一个简单的问题-如果您拖尾的日志文件可能以不同的速率写入，那么您如何知道从头到尾有多少行？ 尾巴-跟随什么？ 但是，如何将其传送到另一个程序？ 谢谢 HBase 表中的主键不是索引。 由于行以排序顺序存储，因此查找速度很快。 这些家伙在做什么只是在计数在线中/事件中的事件.....没什么好说的，这全都取决于一个人可以计数的速度...... 我认为他们也使它变得复杂 只是为了计算这些点击/事件