流式计算典型系统技术分析|学习笔记

开发者学堂课程【分布式计算入门：流式计算典型系统技术分析】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/375/detail/4706

流式计算典型系统技术分析

目录：

一、业界典型系统技术概要分析

一、业界典型系统技术概要分析

1. Twitter Strom

（1）Twitter 内部使用、开源，被广泛使用的一套流计算系统

核心概念

（2）异或^

a^a=0  成对出现的一组数异或后都得0

a^b^a^b=0 与成对出现的顺序无关

Strom 很巧妙地利用了这个特性来跟踪整个数据数。也就是说它在任何一个 bolt 做处理的时候，先生成一个随机数。将这个随机数汇报到 acker。Acker 把那个数跟原来的那个数进行异或操作，然后 strom 将这个异或值传递到子节点。子节点在处理完成以后，将这个传递下来的数发给 acker 进行异或处理，同时迭代刚才那个过程。所以如果没有任何问题的话，那么任何的节点这个值都会成对出现，那最终这批数据处理完后， acker 将会异或成0。如果没有异或成0，将视为发生了故障，将会从源头重播这个数据。

acker 针对每个数据都进行这样的操作，所以在实战中会发现当 bench 的数据设置的非常小的时候，那么整个 acker 的数据，将会和本身数据量同等量级，这将会极大地影响整个系统的吞吐和性能。

这也是 storm  acker 机制非常致命的弱点。

（3）Nimbus-Zookeeper-Supervisor

系统单点（无状态）

负责接受 Topology ，进行资源调度

将调度信息记录到 Zookeeper 中

定期检查  Zookeeper 中各个 Supervisor  的心跳信息

根据心跳状态，决定是否重新调度

每台物理机上启动一个（无状态）

轮询 Zookeeper  中的调度任务信息，启动、删除  Task

定期将心跳信息写入 Zookeeper

容错

数据→发送→处理→ Acker 成功容易出现数据丢失 重复

那么在流式计算中间，其实要保证数据的完全的精确，所面临的问题要比离线和批量计算要复杂。因为整个数据是一个有状态的计算，所以整个数据到发送到处理结点到 acker 成功整个过程并不是原子操作。所以很容易出现数据的丢失、数据重复等问题。那么数据的丢失，可以被利用重播机制来解决，但是重播机制无法解决数据 onlyonce 的语义，也就是说数据多不少只被处理一次。

（4）Transactional Topology

需要跟踪整个源头数据的所有子孙消息

如何解决消息被重复处理的问题

注：用户代码利用唯一的 Batch ID 进行去重

storm 在 spout 上将源头消息串行的划分成一个一个的 bench ，将每个 bench 赋予一个完全递增的一个 ID ，记录在 ronkeep 中。那么利用 acker 机制来跟踪整个 bench 的数据是不是未完全处理，超时和节点异常情况下 spout 会种整体重播这个 bench 内的所有消息，影响中间状态的操作可以被并罚执行。用户可以有机会利用唯一的 bench 进行驱虫，也就是说假设你进行了一个加法操作，实际上用户这部分代码，整个计算是有状态计算。所以用户可能把这批的数据进行了加法操作。所以有可能计算成功，但是 acker 回去失败。

那么做一个有状态的计算，他不可能说把这个数据再重新全部去计算一遍，那么这个计算的结果会被累加，会被重复计算。所以 storm 给一个机会，给你分配了一个唯一的 id ，让用户代码自己去实践驱虫逻辑。

限制

整个 Topology 同一时刻只能有一个 Batch 正在执行

当然 stormy 要让用户使用这个唯一的id去做驱虫，它就有一个很强的约束，节点计算可以分布式计算，但是真正去提交到持久化状态的时候，整个拓扑同一时刻只能有一个 bench 的印象。正在执行这个提交操作。

（5）优点

消息在框架内不落地，处理非常高效

保证了消息至少被处理

Transactional Topology 为消息去重提供了可能

调度模式简单，扩展能力强

社区资源丰富

Transactional Topology 对 Batch 串行执行方式，性能下降严重

成本高

（6）动态调整并发度

自主调用 SplitShard\MergeShard

2.Google MillWheel

Bigtable 持久化中间结果

将每个节点的计算输出消息进行持久化