Answers 是 Twitter 的移动 APP 分析业务，它现在可以一天处理 50 亿次的会话。Ed Solovey 是推特的软件工程师，他描述了他们的系统是如何工作以提供“可靠、实时和可行动”的数据，这些数据是基于亿万个移动设备每秒发送的百万次的事件。
如 Solovey 所讲述，Answers 涉及的主要职责包括：
- 接收事件 ;
- 收集归档这些事件 ;
- 进行离线和实时的计算 ;
- 合并这些计算结果并产生相关性的信息
负责从设备接收事件的服务是用 Go 语言写的，并且它使用了亚马逊的弹性负载均衡器（ Amazon Elastic Load Balancer ）。它将每个消息负荷放入到持久化的 Kafka 队列中。Kafka 可以存储大量的事件，但这里的存储应仅仅被用作一种临时性的缓存，它可以保存几个小时有价值的数据。而接下来 Storm 会传输数据到 Amazon S3 中完成存储。
当数据存储到 S3 中后， Amazon Elastic MapReduce 就会对数据进行批次性计算处理。计算的结果会存储到 Cassandra 数据库集群中，可以通过 API 来查询使用。
到这里，故事只讲了一半。剩下比较确切的是 Answers 可以实时性地处理数据。在这个目标中，Kafka 存储的内容被输送到 Storm，在 Storm 中这些数据会被像 Bloom Filters 和 HyperLogLog 这样的统计算法处理以提供及时性的结果， 代价是“可忽略的精确度损失”。计算结果会被 Cassandra 数据库再次保存起来。
所以处理结束后，Cassandra 既保存了批处理计算结果，也保存了实时计算的结果。查询 API 负责合并这两种计算流，并基于查询参数给出一致性的视图。当它们都可用时，批处理计算的结果更优先一些，因为它们更准确，如果批处理计算结果不可用时，就会优先使用实时性计算结果。
按 Solovey 所说，描述的这种架构在故障处理的情况下也是有效的，这要归功于连接 Answers 组件时使用了持久化的队列。这也保证了一个组件的任何中断不会影响其它的组件。所以，这种架构可以保证从故障中恢复，并且假设系统能在给定时间内恢复正常，那么就能保证数据不被丢失。
