流处理基础概念 - 延迟和吞吐

在批处理场景中，我们主要通过一次计算的总耗时来评价性能。在流处理场景，数据源源不断地流入系统，大数据框架对每个数据的处理越快越好，大数据框架能处理的数据量越大越好。衡量流处理的“快”和“量”两方面的性能，一般用延迟（Latency）和吞吐（Throughput）。

1、延迟

延迟表示一个事件被系统处理的总时间，一般以毫秒为单位。根据业务不同，我们一般关心平均延迟（Average Latency）和分位延迟（Percentile Latency）。假设一个食堂的自助取餐流水线是一个流处理系统，每个就餐者前来就餐是它需要处理的事件，从就餐者到达食堂到他拿到所需菜品并付费离开的总耗时，就是这个就餐者的延迟。如果正赶上午餐高峰期，就餐者极有可能排队，这个排队时间也要算在延迟中。例如，99 分位延迟表示对所有就餐者的延迟进行统计和排名，取排名第 99%位的就餐者延迟。一般商业系统更关注分位延迟，因为分位延迟比平均延迟更能反映这个系统的一些潜在问题。还是以食堂的自助餐流水线为例，该流水线的平均延迟可能不高，但是在就餐高峰期，延迟一般会比较高。如果延迟过高，部分就餐者会因为等待时间过长而放弃排队，用户体验较差。通过检查各模块分位延迟，能够快速定位到哪个模块正在“拖累”整个系统的性能。

延迟对于很多流处理系统非常重要，比如欺诈检测系统、告警监控系统等。Flink 可以将延迟降到毫秒级别。如果用 mini-batch 的思想处理同样的数据流，很可能有分钟级到小时级的延迟，因为批处理引擎必须等待一批数据达到才开始进行计算。

2、吞吐

吞吐表示一个系统最多能处理多少事件，一般以单位时间处理的事件数量为标准。需要注意的是，吞吐除了与引擎自身设计有关，也与数据源发送过来的事件数据量有关，有可能流处理引擎的最大吞吐量远小于数据源的数据量。比如，自助取餐流水线可能在午餐时间的需求最高，很可能出现大量排队的情况，但另外的时间几乎不需要排队等待。假设一天能为 1 000 个人提供就餐服务，共计 10 小时，那么它的平均吞吐量为 100 人/小时；仅午间 2 小时的高峰期就提供了 600 人，它的峰值吞吐量是 300 人/小时。比起平均吞吐量，峰值吞吐量更影响用户体验，如果峰值吞吐量低，会导致就餐者等待时间过长而放弃排队。排队的过程被称作缓存（Buffering）。如果排队期间仍然有大量数据进入缓存，很可能超出系统的极限，就会出现反压（Backpressure）问题，这时候就需要一些优雅的策略来处理类似问题，否则会造成系统崩溃，用户体验较差。

延迟与吞吐其实并不是相互孤立的，它们相互影响。如果延迟高，那么很可能吞吐较低，系统处理不了太多数据。为了优化这两个指标，首先提高自助取餐流水线的行进速度，加快取餐各个环节的进程。当用户量大到超过流水线的瓶颈时，需要再增加一个自助取餐流水线。这就是当前大数据系统都在采用的两种加速方式，第一是优化单节点内的计算速度，第二是使用并行策略，分而治之地处理数据。如果一台计算机做不了或做得不够快，那就用更多的计算机一起来做。

延迟和吞吐是衡量流处理引擎的重要指标。如何保证流处理系统保持高吞吐和低延迟是一项非常有挑战性的工作。