随着云计算大数据的发展，有越来越多的场景需要借助于实时数据处理技术，为此有很多公司开发了自己的实时处理系统，Facebook就是其中的一员，他们构建的实时数据处理生态系统每秒钟能够处理数百GB的数据。本文介绍了Facebook在设计该系统时从易用性、性能、容错、可伸缩性以及正确性等方面考虑所做的重要设计决策，这些决策和系统如何满足秒级的延迟需求，以及在构建该系统的过程中Facebook所总结的经验教训。
Facebook认为在设计一个实时数据处理系统的时候首先要想清楚下面5个问题：
易用性：处理需求有多复杂？SQL是否足够？是否必须要使用C++或者Java这样的编程语言？用户编写、测试和部署一个新的应用程序需要多长时间？
性能：允许多长时间的延迟，毫秒级，秒级，还是分钟级？单机或者总体需要多大的吞吐量？
容错能力：可以容忍哪些类型的错误？数据处理或输出的次数通过什么语义来保证？系统如何存储和恢复内存状态？
可伸缩性：数据是否支持分片从而进行并行处理？系统是否能够容易地随着数据量的变化进行调整？是否可以重新处理之前的有价值的老数据？
正确性：是否需要ACID特性？作为输入的所有数据是否都需要被处理并在最终的结果中出现？
针对这些问题，Facebook提出了5个设计决策：语言范式、数据传输、处理语义、状态保存机制以及数据再处理。下面的图表展示了每一个设计决策对数据质量属性的影响：
以及不同的流处理系统所做的设计决策：
语言范式决定了编写应用程序的难易程度以及开发者对性能的操控程度。基本有三种选择：声明式，函数式以及过程式编程语言。对于Facebook而言，单一的某种语言无法满足所有的用例，因此他们开发了三种不同的流处理系统。
数据传输对流处理系统的容错性、性能和可伸缩性都有非常大的影响，传统的数据传输方式包括：直接消息传输、基于代理的消息传输和基于持久化存储的消息传输。Facebook使用Scribe，一种持久化的消息总线，来连接不同的处理节点。
处理语义包括状态语义（每一个输入事件最少被计数一次、最多被计数一次还是只被计数一次？）和输出语义（给定的输出值在输出流中最少出现一次、最多出现一次还是只出现一次？）。其中无状态的处理器只有输出语义，而有状态的处理器这两种语义都有。Facebook对不同的应用通常有不同的状态和输出语义需求，因而开发了Puma、Stylus和Swift三个支持不同语义的系统。
状态保存机制的实现方式有很多，包括复制副本、本地数据库持久化、远程数据库持久化、上游备份以及全局一致性快照等。Facebook实现了两种状态保存机制，其中Puma实现了远程数据库存储，而Stylus则实现了本地和远程数据库存储。
再处理的方式有三种：仅使用流处理；维护两个单独的系统，一个用于流处理，一个用于批处理；开发一个能够在批处理环境中运行的流处理系统。Facebook采用了一种与Spark Streaming以及Flink都不同的处理方式，他们使用标准的MapReduce框架从Hive中读取数据并在批处理环境中运行流处理应用程序。Puma应用可以运行在Hive环境中，而Stylus则提供了三种类型的处理器：无状态的处理器，通用的有状态的处理器和一个居中的流处理器。
在系统建设方面，Facebook的主要设计目标是秒级的延迟，每秒钟能够处理几百GB的数据，为此他们通过一个持久化消息总线将所有的处理组件连接起来进行数据传输，同时也将数据的处理和传输解耦，实现容错、可伸缩、易用性和正确性。整个系统的架构图如下：
该图阐述了Facebook实时处理系统的数据流，数据从左侧的移动和Web产品中产生，然后被送入Scribe（一个分布式数据传输系统），而Puma、Stylus和Swift等实时流处理系统则从Scribe中读取数据并将处理结果写入Scribe。Puma、Stylus和Swift可以根据需要通过Scribe连接成一个复杂的DAG（有向无环图）。
接下来是使用该实时处理系统的一个示例应用，该应用识别一个输入事件流中的趋势事件，以5分钟为单位对这段时间内产生的话题按事件数排序。每个事件包含一个事件类型，一个维度ID（用于获取事件的维度信息，例如使用的编程语言）和一个文本（用于分类事件主题，例如电影或者婴儿）。该应用有4个处理节点，每一个都可以并行执行，整体流程图如下：
