1. 背景-什么是流计算
在传统的数据处理流程中，总是先收集数据，然后将数据放到数据库中，当人们需要的时候通过查询对应的数据进行处理。这样看起来没什么大问题，但是当我们遇到以下场景的时候就有问题了。比如：金融风控，双十一抢购，推荐系统等，这类系统有一个共同的特点，就是对时效性要求非常高。
所谓“时光一逝不复返，往事只能回味“。我们举一个简单的例子，当前你的余额宝账户有3000块，你去商场消费了2000。这时候触发支付宝结算，假设支付宝处理这笔数据需要10秒，而10秒之内，你接着又消费了2000，这时候应该提示你余额不足了，但由于结算程序还在处理，实际上余额还有3000，那么你这2000又结结实实可以消费了。10秒后支付宝反应过来了，这时候钱已经扣了，找谁还钱去啊，这样引发了很大的金融风险。
其实还有一个简单的办法，支付宝在结账的时候（10秒钟之内）禁止消费，又带来的问题是交易量下跌，这样的损失更加接受不了，所以这就对数据的实时处理要求非常高，这1秒的数据这1秒就要处理完，下一秒的数据可能又是其它的情况了。数据就像流水一样不断变化，我们需要实时的处理数据。
2. 流式计算优化之拓扑排序
2.1 流式计算
流式计算就是实时查询并且对数据进行计算，假设我们遇到了如下计算场景：
A = D + B
B = C + E
C = D + E我们需要计算得到 A 的值，如何才能最快的计算出结果呢？我们可以从以下几个方面来分析问题。
2.2 单线程
如果是单线程的情况，我们只能线性的去执行任务，最开始计算 a = d + b，先计算 d，然后计算 b，而 b = c + e，只能再去计算 c，而 c = d + e。先计算出 d 和 e 相加得出 c，然后计算 c 加 e 得出 b，最后计算 d 加 b 得出 a。最后我们统计计算 a，一共做了多少次计算：
d 2次
e 2次
c 1次
b 1次
a 1次这里显而易见，我们做了2次重复计算。有2种方法去解决这个问题：一种是加缓存，一种是拓扑排序。
- 缓存
增加缓存的方法如下，计算 a 的时候先计算 d 和 b，计算 d 之后把 d 先缓存，然后计算 b，由于 b=c+e，那么需要先计算 c，而 c=d+e，最后需要计算 d+e，而 d 已经缓存了直接从内存取出，再接着计算 e，放入缓存，这样计算 b=c+e 的时候只需要计算 c，e 直接从内存取出。缓存虽然可以解决上面的问题，但也有缺点，首先缓存需要占用内存空间，其次缓存都有淘汰机制。
- 拓扑排序
我们可以根据上述的关系，得到如下的依赖图：
拓扑关系依赖图
实际上我们得到了一个 DAG 的图，可以看出如果要计算 a，我们需要先计算 d 和 b，而计算 b 需要计算 c 和 e，而计算 c 又需要计算 d 和 e，即一件事情依赖另外的一件。这样的例子在生活中有很多，比如早晨起来，你必须先穿袜子才能穿鞋子，而穿鞋子之前你必须得先穿上裤子。这些问题都可以用拓扑排序来解决，思路就是深度优先遍历，优先找出最底层的节点，然后找出次底层的，依次得出结果。最后我们会得到如下的顺序：d e c b a，即按照如下顺序计算，每个节点只需要计算一次，在不产生顺序冲突的同时，得出最短的计算时间。
2.2 多线程
上面是单线程的情况，如果是多线程的情况，当然只要我们有足够的资源，多线程肯定是理论上计算时间最短的。但导致的一个问题就是重复计算，浪费计算资源，下面是多线程执行流程图：
并发线程时序图
即如果开启6个线程执行，那么最终执行的时间可能是 （这里假定 d 的执行时间比 e 长） d c b a，我们把 e 的计算时间给节省掉了，多线程的情况对缓存来说可以说是灾难性的后果，比如计算 a 开始的时候就开始计算 d 了，而计算 c 的时候 d 如果没有计算完，c 也取不到 d 的缓存，导致缓存可以说是没有太大用处。如果缓存可以取到，才可以节省计算资源。
如果我们按照如下思路，还可以进一步节省计算资源，在上面拓扑排序的基础上，加入层级的概念，比如：
层次划分的拓扑关系依赖图
加入层级之后，比如 d 和 e 的层数都是4，那么 d 和 e 可以并行计算，而 c,b,a 的层级分别是3,2,1，进行串行计算。这里很明显，如果层数相同的则进行并行计算，层数不同则串行计算，好处是：1.节省计算资源 2.是节省了计算时间。
3. 流式计算优化之IO合并
流式计算还有一种优化是对内存操作和 IO 操作做区分，并进行优化，比如上述情况，如果 d 和 e 开启并行计算，c,b,a 线性计算，从计算的角度来看待，确实是最优的计算方式。但是考虑到计算分为内存计算和 IO 计算，而且 IO 计算的延时比内存计算高几倍到十几倍，因此我们主要的策略就是对 IO 计算做优化，一个比较好的优化思路就是对 IO 做合并，或者对 IO 计算做缓存，下面主要讲述对 IO 计算合并。
根据层次关系的拓扑依赖图，我们计算的顺序可以按照如下方式进行：先从简单点的情况，然后扩展到复杂的情况。
- IO合并
首先我们假设 d 和 e 都是 IO 计算，如果按照之前介绍的拓扑排序然后再并发的思路，那么我们会同时启动2个线程，分别计算 d 和 e。虽然多线程不会增加时间，但是多了一次 IO 操作，带来的影响就是 IO 是有瓶颈的，如果系统的 IO 操作变多，会导致系统抖动和延时，假如我们可以把 d 和 e 做 IO 合并，即一次就可以把 d 和 e 都读取出来，那么系统 IO 的容量就可以提高1倍（实际不到1倍的提升）。
- IO不能合并
有2种情况：
1. 如果 d 和 e 是访问的不同的数据库，那么我们的 IO 不能做合并，我们就只能读取2次。
2. 接着我们增加下 IO 合并的复杂程度，比如现在有 d,e,c 这3个节点是 IO 计算，d 和 e 可以做 IO 合并，而 c 需要等待 d 和 e 做 join 操作之后，才能确定读取哪些 IO，这样我们做 IO 合并的时候只能先把 d 和 e 做合并，而不能把 c 做合并，因为在 d 和 e 做 join 操作之后，我们才知道 c 要去查什么数据，因此也做不了合并。不过上述问题也是可以优化的，这一部分的优化可以通过分支预测和预取操作来解决。2个数据做 join 操作就是找到2个数据集的合集部分，比如一个数据集是数学成绩，一个数据集是地理成绩，下面我们需要找出数学成绩大于60分，而且地理成绩大于90的学生，那么我们就是找到2个数据集的交集部分，即2个数据集做 join 操作。
4. 流式计算优化之分支预测
- 假设计算场景：
if ( isWeekend) {
readIO(A);
} else {
readIO(B);
}可以看到，如果今天是周末，则读取 A，如果今天不是周末，则读取 B。由于 A 和 B 都是 IO 操作，比较耗时，如果 A 和 B 能够合并读取，那么我们当然很开心，我们只需要读取一次就可以了。假如 A 和 B 不能够做 IO 合并，那么遇到的问题是，我们需要先判断是否是周末才能够明白到底去读取哪个 IO，假如我们引入分支预测机制。
- 分支预测机制
上述条件，假设进入 A 条件的概率是80%，而进入 B 条件的概率是20%，如果采用分支预测，我们会直接跳过判断，直接去读取 A，然后再去计算判断条件，如果条件判断错误，再回过头去读取 B，这样带来的好处是如果判断正确，那么节省了大量的判断时间，如果判断错误，那么就会重新读取 B，时间反而变长了。前提是预测的足够准确，会提高计算的效率。
- 预取缓存策略
对应的计算还有预取操作。还是上面的例子，要计算上面的语句，可以根据统计学来判断，哪些数据有很大的概率需要去取的，优先把这些数据放进缓存，下次计算直接去内存取数据，而不需要从 IO 取数据，这一部分就是热点数据，很多时候会把这部分热点数据保存在分布式的缓存中，能够很大的提高效率。当然预取的机制，缓存的一致性和缓存淘汰的机制对数据命中的效率影响非常大，另外在机器重新启动后，缓存没有建立起来之前，系统面临着没有缓存的情况，导致在启动阶段会有大量延时的情况，这些都是需要考虑的问题。
