第七讲流计算
如果应用有如下特征
使用批处理框架会面临挑战– 数据量太大以至于存不下全部数据（Volume）
– 数据到来太快以至于用批处理的方式来不及处理（Velocity）
– 使用批处理框架达到所需性能的成本太高
大规模实时应用
Twitter  – 平均每秒6000个tweets，每天约5亿
– 对这些tweets及相关的点击进行统计
每一个新发tweet的处理是否需要前面所有的数据？
如果问题的属性符合如下条件
F(X +ΔX)= F(X)op H(ΔX)
那么我们在计算F(X +ΔX) 的时候不需要对全部数据集X +ΔX进行计算，只需要将X之前的某种处理结果保留下来，并和增量的ΔX处理结果再进行处理后即可
这种处理方式可以看做数据不断以增量的方式流入系统并处理，改变系统状态并输出结果。我们把这种方式叫做流计算
Twitter Analytics
输入X：每一条tweet的log和每一次点击的log
– <url1, click>
F(X): 基于时间窗口的累加结果
– 包含某个URL的tweet数
– 对每一个URL的点击数
<url1, 20>
对一条新的log（ΔX）
– 不需要处理过去的所有log
– 只需要统计结果F（X）
       <url1,21>
流处理的目标
• 实时性/可扩展性
• 容错
– 数据的错误
– 系统的故障
• 可编程性

实时性/可扩展性
• 批处理任务
– 一般对固定规模数据进行处理
– 执行时间可以长达几十小时
• 流处理
– 数据到达速率变化很大
– 要么能够处理所有数据
– 要么预先定义好降级处理方法
容错
• 批处理任务
– 数据错误通常由数据清洗阶段完成
– 系统故障有重算或检查点设置等机制
• 流计算
– 数据错误必须实时处理
– 系统故障时的容错机制必须是低开销的，而且还能满足实时性
可编程性
• 描述自然
• 表达力强
• 无需关注（或少关注）容错机制和负载平衡
流计算的一种实现 – WORKER + QUEUEWorker + Queue
• Worker：处理单元
• Queue ：缓冲 + 路由
Queue
• 匹配生产者与消费者
– 匹配速率
– 接口匹配
– 持久化保存
– 性能优化