分析Twitter的实时信息分析服务Answers的架构

Twitter于2014年发布了Answers，到目前为止，移动社区已经产生了惊人的使用量，让Twitter感到兴奋。现在Answers每天处理50亿次会话，而且这个数字还在不断增加。数亿设备每秒向Answers端点发送数以百万计的请求。在此期间，Answers后台收到并处理了1000万次分析事件。挑战是如何利用这些信息为移动开发者提供可靠、实时、有价值的洞察力（视角）来了解他们的移动应用程序。在高层，Twitter依靠组件解耦、异步通信、优雅服务降级等原则来帮助架构决策。Twitter使用Lambda架构将数据完整性与实时数据更新相结合。在实践中，Twitter需要设计一个系统，可以接收和保存事件，执行离线和实时计算，并将上述两个计算结果集成到相关信息中。所有这些行为都应该以每秒数百万次的规模执行。让Twitter从第一个挑战开始：接受和处理这些事件。在设计设备-服务器通信时，Twitter的目标是减少对电池和网络使用的影响；确保数据的可靠性；接近实时获取数据。Twitter批量发送分析数据，并在发送前压缩数据，以减少对设备的影响。为了确保这些宝贵的数据始终能够到达Twitter服务器，设备将在传输失败后随机退出，设备存储达到上限时重新传输。为了确保数据尽快到达服务器，Twitter设置了多个触发器，使设备尝试发送：当程序在前台运行时，事件触发器每分钟触发一次；消息数量触发器和程序转移到后台触发器。这种通信协议导致设备每秒发送数以万计压缩的有效载荷。每个载荷都包含几十个事件。接收事件的服务必须极其简单，才能以可靠、易于线性伸缩的方式处理载荷。该服务采用GO语言编写，该服务采用亚马逊弹性负载平衡器（ELB），并将每个消息负载放入一个持久的Kafka队列。存储Kafka是一个持久的存储器，因为它将收到的信息写入磁盘，每个信息都有多个冗余。因此，一旦Twitter知道信息到达Kafka队列，Twitter就可以通过延迟处理和再处理来容忍下游延迟和下游失败。然而，Kafka并不是Twitter历史数据的永久真理来源——根据上面提到的速度，Twitter只需要几天的数据来存储数百个box。因此，Twitter将Kafka集群配置为将消息只保留几个小时(这足以让Twitter处理意想不到的重大故障)，并尽快将数据存储在永久存储-亚马逊简单存储服务(AmazonS3)中。Twitter广泛使用Storm进行实时数据处理。第一个相关的Topology是从Kafka读取信息并存储在AmazonS3上。一旦这些数据存储在S3上，Twitter可以使用亚马逊弹性Mapreduce（AmazonEMR）计算Twitter数据可以计算的任何东西。这不仅包括在客户仪表盘上显示的数据，还包括Twitter为开发新功能而开发的实验性任务。Twitter使用Cascading框架编写，AmazoneMR执行Mapreduce程序。Amazonemr将Twitter存储在S3上的数据作为输入，然后将结果存储在S3中。Twitter通过在Storm上运行的调度topology来探测程序的执行情况，并将结果灌入Cassandra集群，使结果能够用于亚秒级查询API。到目前为止，Twitter描述了一个持久的容错框架，可以执行分析和计算。然而，有一个显著的问题——这个框架不是实时的。有些计算每小时计算一次，有些计算需要一整天的数据作为输入。计算时间从几分钟到几个小时不等，将S3上的输出导入服务层需要这么多时间。因此，在最佳情况下，Twitter的数据总是拖延几个小时，显然不能满足实时和可操作的目标。为实现实时目标，Twitter在数据涌入后存档，同时对数据进行流式计算。就像Twitter存储Topology读取数据一样，一个独立的StormTopology实时从Kafkatopic中读取数据，然后进行实时计算。计算逻辑与Mapreduce任务相同。为了实时查询，这些实时计算结果被放置在另一个独立的Cassandra集群中。为了弥补Twitter在时间和资源方面可能存在的不足，Twitter在实时计算层中没有使用一些概率算法，如布隆过滤器HyperLogLog(也有自己开发的算法)。与那些蛮力替代品相比，这些算法在空间和时间复杂性方面具有数量级优势，只有精度损失可以忽略不计。合并现在Twitter有两个独立生产的数据集(批处理和实时处理)。Twitter如何合并两者才能获得一致的结果？在API逻辑中，Twitter根据特定情况使用两个数据集，然后合并它们。Twitter的API总是倾向于使用批量生成的数据，因为批量计算是可重现的，而且比实时计算更容易。比如API收到了一个30天时间序列的日活跃用户数据请求，首先会在批量数据Cassandra集群中查询全范围数据。如果是历史数据检索，已经获得了所有数据。然而，查询请求更有可能包含大部分结果，只有近一两天的数据才会被实时数据填充。错误处理让Twitter复习几个失败的场景，看看这样的架构如何避免在处理错误时停机或丢失数据，从而优雅地降级。Twitter在上面讨论了设备上的回退重试策略。当设备端网络中断，服务器端短时间无服务时，重试确保数据最终到达服务器。随机返回确保设备不会在某个区域网络中断或后端服务器短时间不可用后被压垮(DDOS攻击)。当实时处理层失效时会发生什么？待命的Twitter工程师将被通知并解决问题。由于实时处理层的输入存储在持久的Kafka集群中，因此没有数据丢失；实时处理恢复后，将赶上停机期间应处理的数据。由于实时处理和批处理完全解耦，批处理层根本不会受到影响。因此，唯一的影响是在实时处理层失效期间实时更新数据点的延迟。如果批处理层出现问题或严重延迟，会发生什么？Twitter的API将无缝获取更多的实时处理数据。查询时间序列数据可能只需要一天的实时处理结果，但现在需要查询两到三天的实时处理结果。由于实时处理和批处理是完全解耦的，实时处理不会影响继续运行。与此同时，Twitter的待命工程师也会得到消息，解决批处理层的问题。一旦批处理层恢复正常，它将执行延迟的数据处理任务，API将无缝切换到批处理的结果。Twitter系统的后端架构由四个组件组成：事件接收、事件存储、实时计算和批量计算。各组件之间的持久队列确保任何组件的故障不会扩散到其他组件，并且可以从中断中恢复。当计算层延迟或失效时，API可以无缝优雅地降级，服务恢复后再次恢复；这些都是由API内部的检索逻辑保证的。Answer的目标是创建一个仪表板，它可以使了解您的用户群非常简单。因此，你可以把时间花在创建惊人的用户体验上，而不是挖掘数据。