大数据技术概述（二）——流处理

1.5流处理基础概念

1.5.1延迟和吞吐

在流处理场景，数据源源不断地流入系统，大数据框架对每个数据的处理越快越好，大数据框架能处理的数据量越大越好。衡量流处理处理的“快”和“量”两方面的性能，一般用延迟（Latency）和（Throughput）这两个指标。

1.5.1.1延迟

延迟表示一个事件被系统处理的总时间，一般以毫秒为单位。根据业务不同，我们一般关心平均延迟（Average Latency）和分位延迟（Percentile Latency）。99分位延迟表示对所有事件的延迟进行统计和排名，取排名第99%位的事件延迟。一般商业系统更关注分位延迟，因为分位延迟比平均延迟更能反映这个系统的一些潜在问题。通过检查各模块分位延迟，能够快速定位到哪个模块正在“拖累”整个系统的性能。

1.5.1.2吞吐

吞吐表示一个系统最多能处理多少事件，一般以单位时间处理的事件数量为标准。吞吐除了与引擎自身设计有关，也与数据源发送过来的事件数据量有关，有可能流处理引擎的最大吞吐量远小于数据源的数据量。引擎处理事件时，峰值吞吐量过低，事件则需排队等待处理。排队的过程被称作缓存（Buffering）。如果排队期间仍然有大量数据进入缓存，很有可能超出系统的极限，就会出现反压（Back pressure）问题，这时候就需要一些优雅的策略来处理类似问题，否则会造成系统崩溃。

1.5.1.3延迟与吞吐

延迟与吞吐并不相互孤立。如果延迟高，那么很可能吞吐较低，系统处理不了太多数据。当前大数据系统采用两种加速方式，第一是优化单节点内的计算速度，第二是使用并行策略，分而治之地处理数据。

1.5.2窗口与时间

1.5.2.1不同窗口模式

常见的窗口形式：滚动窗口、滑动窗口、会话窗口。
滚动窗口（Tumbling Window）模式一般定义一个固定的窗口长度，长度是一个时间间隔，比如小时级的窗口或分钟级的窗口。窗口像车轮一样，滚动向前，任意两个窗口之间不会包含同样的数据。

滑动窗口（Sliding Window）模式也设有一个固定的窗口长度。当窗口的长度大于滑动的间隔，可能会导致两个窗口之间包含同样的事件。滚动窗口模式中滑动的间隔正好等于窗口的大小。

会话（Session）本身是一个用户交互概念，常常出现在互联网应用上，一般指用户在某App或某网站上短期内产生的一系列行为。

会话窗口（Session Window）模式的窗口长度不固定，而是通过一个间隔来确定窗口，这个间隔被称为会话间隔（Session Gap）。当两个事件之间的间隔大于会话间隔，则两个事件被划分到不同的窗口中；当事件之间的间隔小于会话间隔，则两个事件被划分到同一窗口。

1.5.2.2时间语义

1.Event Time和Processing Time
Event Time：事件实际发生的时间。
Processing Time：事件被流处理引擎处理的时间。
对于一个事件，自其发生起，Event Time就已经确定不会改变。因各类延迟、流处理引擎各个模块先后处理顺序等因素，不同节点、系统内不同模块、同一数据不同次处理都会产生不同的Processing Time。

2.Watermark
如果要统计一分钟内的实时数据，考虑到事件的延迟，设置合理的等待时间，以等待一分钟内所有的事件都达到服务器。设置等待时间时，流处理与批处理在准确性上有差距，因为批处理一般以更长的一段时间为一个批次，一个批次内延迟上报的数据比一个流处理时间窗口内延迟上报的数据相对更少。数据的实时性和准确性二者不可兼得，Watermark是一种折中解决方案，它假设某个时间点上，不会有比这个时间点更晚的上报数据。当流处理引擎接收到一个Watermark后，它会假定之后不会在接收到这个时间窗口的内容，然后会出发对当前时间窗口的计算。比如，一种Watermark策略等待延迟上报的时间非常短，这样能保证延迟，但是会导致错误率上升。

1.5.3状态与检查点

状态是流处理区别于批处理的特有概念。如果我们对一个文本数据流进行处理，把英文大写字母都改成英文小写字母，这种处理是无状态的，即系统不需要记录额外的信息。如果我们想统计这个数据流一分钟内的单词出现次数，一方面要处理每一瞬间新流入的数据，另一方面要保存之前一分钟内已经进入系统的数据，额外保存的数据就是状态。
检查点（Checkpoint）机制广泛存在与各类计算任务上，主要作用是将中间数据保存下来。当计算任务出现问题，重启后可以根据Checkpoint中保存的数据重新恢复任务。在流处理中，Checkpoint主要保存状态数据。

1.5.4数据一致性保障

At-Most-Once：每个事件最多被处理一次，也就是说，有可能某些事件直接被丢弃，不进行任何处理。这种投递保障最不安全，因为一个流处理系统完全可以把接收到的所有事件都丢弃。
At-Least-Once：无论遇到何种状况，流处理引擎能够保证接收到的事件至少被处理一次，有些事件可能被处理多次。
Exactly-Once：无论是否有故障重启，每个事件只被处理一次。Exactly-Once意味着事件不能有任何丢失，也不能被多次处理。比起前两种保障，Exactly-Once的实现难度非常高。如遇故障重启，Exactly-Once就必须确认哪些事件已经被处理、哪些还未被处理。