《Realtime Data Processing at Facebook》

最近读到了一篇关于在facebook如何构建流式分布式处理系统的paper。感觉系统设计折中的思路总结非常好。在数据应用领域，我觉得任何已经确认效果的方法都会尝试提高时效性来获得更好的收益

一. Facebook实际使用流处理的应用场景

• 用户使用产品行为的埋点数据
• mobile app运行埋点数据 for developer
• facebook页面统计数据（eg. trend）
• 总的设计目标：秒级别的延迟，每秒处理百GB级别的吞吐量

二. 设计的思考

系统设计对比图

1. 支持的语言

主要思考点：编写应用的难易程度，应用实际运行的performance
选择：

• Declarative: 比如：SQL，这类比较容易实现功能，但是可控的部分比较少
• Functional: 这类也比较容易实现
• Procedural：比如：c++ java python 可控程度最高，性能最好

Facebook的选择：
线上有3套流式处理架构（Puma，Stylus, Swift），支持Declarative和Procedural方式。puma实现简单，适合调研需求。stylus复杂，开发测试周期相对更长，适合确定的复杂的任务

2. 数据流传输的方式

这个选择确定了后面的容错性，性能和可扩展性

• 直接传输：比如：RPC或者zeromq。这类的好处是ms级别的延迟，速度快
• 使用broker中转：这类好处是网络都经过broker可控性更好
• 使用持久化队列：比如：scribe和kafka。这类的优点是：读写异步，失败恢复快，流量的重发易于debug
  Facebook的选择：
  使用基于scribe的持久化队列的方案，满足秒级别延迟的业务需求。同时收获了
• 更好的容错性
  某些node失败重新启动即可
• 更好的debug
  node不符合预期，重放流量调试即可
• 更好的监控
  监控队列的长度
• 支持不同的流式处理工具
  可以某些node使用puma而某些node使用Stylus，node组件化可以快速复用

3. node处理的语义

这部分主要是思考是否需要在特定条件下牺牲部分性能来保证100%准确性
node主要做的工作

• 处理input events：查询外部系统，更新内存中数据结构
• 产出output： 处理完input数据后，产出output 供下游node使用
• 存储checkpoints：存储内存中数据结构，存储input的offset，存储output值
  选择：
• at-least-once: 至少处理一次，先处理，后update offset，需要下游兼容重复的情况
• at-most-once: 至多处理一次，先update offset，后处理
• exactly-once: 需要支持事务操作，有操作代价
  Facebook的选择：
  根据业务场景一般使用at-least-once和at-most-once。3个流式架构支持不同的级别的语义

4. 状态存储的机制

选择：

• 多副本冗余：使用多1倍的机器冗余每个node, 代价高
• 本地数据库存储
• 远程分布式数据库存储
• 上游消息队列备份
• 全局分布式snapshot
  Facebook的选择：
• 支持本地数据存储
  优点：没有网络开销，更加快速。支持hdfs备份数据。

本地数据库存储

• 支持远程数据库存储
  优点：支持append only 提高吞吐，降低延迟。merge的时机很重要。

  
  
  

  远程数据库存储

5. 数据回放的支持

在某些场景，数据回放十分有用

• 验证一个新的流处理application是否正确
• 增加了新的统计信息的维度，需要补充数据
• debug application
  选择：
• 只通过流式： 通过缓存消息队列实现，很难支持很长时间
• 通过流式和批量处理： 支持2个存储系统，短时间的通过缓存的消息队列。长时间的通过分布式存储，如：hive。
• 通过支持批量处理的流式处理：比如：spark streaming
  Facebook的选择：
• 通过scribe支持短期数据的回放
• 通过mapreduce on hive 实现长期数据的处理
• 工具支持1套代码2处都能运行

三. 总体系统架构

流式处理系统架构图

• Scribe
  系统总体输入的源头，数据流先进入scribe队列。黄色箭头表示数据流。node从scribe读取数据处理完成后写入scribe
• Puma
  puma支持filter 和 aggregation。使用DSL编写。针对于长久运行，固定需求的查询优化（比如：最热门的话题top10）。filter的使用:如只关注处理#超级碗相关话题的post
• Stylus
  更底层的支持DAGnode结构的流处理框架
• Laser
  基于RocksDB的kv系统。适用于写少读多的场景。用于共享流处理产出的数据
• Scuba
  提供类似数据库查询的实时查询
• Hive
  存储全量数据，按天分表。基于Presto支持sql查询