[论文解读] Fast Data in the Era of Big Data: Twitter's Real-Time Related Query Suggestion Architecture

Gilad Mishne, Jeff Dalton+3 more|arXiv (Cornell University)|Oct 27, 2012

Cloud Computing and Resource Management参考文献 50被引用 8

一句话总结

本文介绍了推特的实时相关查询推荐与拼写纠错系统，该系统从基于Hadoop的批处理架构演进为自研的内存流处理引擎，以满足突发新闻事件下亚10分钟延迟的要求。核心贡献在于一项实用案例研究，表明Hadoop在低延迟、实时数据处理方面并不适用，并倡导采用统一平台同时处理‘大数据’与‘快数据’。

ABSTRACT

We present the architecture behind Twitter's real-time related query suggestion and spelling correction service. Although these tasks have received much attention in the web search literature, the Twitter context introduces a real-time "twist": after significant breaking news events, we aim to provide relevant results within minutes. This paper provides a case study illustrating the challenges of real-time data processing in the era of "big data". We tell the story of how our system was built twice: our first implementation was built on a typical Hadoop-based analytics stack, but was later replaced because it did not meet the latency requirements necessary to generate meaningful real-time results. The second implementation, which is the system deployed in production, is a custom in-memory processing engine specifically designed for the task. This experience taught us that the current typical usage of Hadoop as a "big data" platform, while great for experimentation, is not well suited to low-latency processing, and points the way to future work on data analytics platforms that can handle "big" as well as "fast" data.

研究动机与目标

• 为解决在突发新闻事件发生后数分钟内提供实时相关查询建议的挑战，这是传统网络搜索所不具备的要求。
• 调查基于Hadoop的批处理为何无法满足实时查询建议与拼写纠错的低延迟需求。
• 设计并部署一个自研内存处理引擎，支持动态、快速演化的查询关联关系在10分钟以内的响应时间。
• 突出Hadoop在速度驱动工作负载中的架构与性能局限，并倡导采用统一平台同时处理‘大数据’（体量）与‘快数据’（速度）工作负载。
• 分享构建该系统两个迭代版本的实践经验，强调在生产规模系统中实时数据处理的关键教训。

提出的方法

• 最初使用基于Hadoop的分析栈，结合Pig对推特日志数据进行批处理，以计算查询共现模式。
• 将Hadoop流水线替换为专为低延迟、实时查询建议与拼写纠错设计的自研内存流处理引擎。
• 实现有状态的流处理架构，实时维护并更新新推文到达时的查询关系评分。
• 利用内存数据结构实现亚秒级更新，支持高吞吐、低延迟的推文流处理。
• 设计系统以检测并响应查询量突然激增（如突发新闻）的情况，实现在数分钟内动态调整相关查询建议。
• 结合实时事件处理与增量计算，保持查询关系的实时更新，而无需全量重新处理。

实验结果

研究问题

• RQ1 当应用于实时、低延迟查询建议系统时，基于Hadoop的批处理在性能与延迟方面存在哪些限制？
• RQ2 如何设计系统，以在突发新闻事件发生后10分钟内提供相关且准确的查询建议？
• RQ3 批处理（Hadoop）与流处理（内存引擎）在实时数据分析中存在哪些架构权衡？
• RQ4 现有流处理引擎（如Storm、S4）在多大程度上能够同时支持实时处理与长时间跨度的大规模历史分析？
• RQ5 构建一个统一数据处理平台，以高效处理‘大数据’（体量）与‘快数据’（速度）工作负载，需要哪些设计原则？

主要发现

• 初始的基于Hadoop的实现无法满足突发新闻事件下10分钟延迟的目标，导致其在生产环境中无效。
• Hadoop的批处理设计——特别是其对磁盘I/O的依赖与长作业周期——从根本上不适用于低延迟、实时数据处理。
• 自研内存处理引擎成功将延迟降低至10分钟以内，使重大新闻事件中能及时提供相关查询建议。
• 从Hadoop转向内存流引擎的必要性源于批处理系统与实时数据需求之间的架构不匹配。
• 现有流处理引擎（如Storm、S4）缺乏对长期历史分析和大规模数据量上复杂即席查询的原生支持。
• 需要一个统一的数据处理平台，结合批处理分析（Hadoop）与流处理（内存引擎）的优势，才能有效处理‘大数据’与‘快数据’。