流处理
传递事件流
消息系统(ACK)
-
直接从生产者传递给消费者
-
常见形式
- UDP组播
- 无代理的消息库
- StatsD，使用UDP收集网络中所有机器的的指标并对其进行监控，只有收到所有消息，才认为计数器指标是正确的
- HTTP或RPC请求
-
存在问题
- 容错能力差，即使有消息重传机制，当消费者或生产者崩溃时，仍会丢失数据
-
-
消息代理(消息队列)
- 容忍客户端连接的上线、崩溃
- 带来异步与消息延迟问题
-
消息代理与数据库对比
- 数据库中的记录需要显式删除，而消息代理当消息消费完成后即自动删除
- 当消息代理缓存过多数据导致存储从内存溢出到磁盘时，性能会下降
- 数据库支持二级索引及多种查询方式，而消息代理一般只持按某种模式匹配主题
- 消息代理没有数据库是快照的概念
-
多个消费者
- 负载均衡模式–多个消费者轮流或按一定分配策略消费
- 扇出模式–多个消费者同时收到同一消息
-
确认与重新交付
-
重复消费
- 为确保消息不丢失，在消费时采用ACK机制。如果消息已经消费完毕，但ACK数据包在网络丢失，导致代理在规定时间内没收到ACK，如果此时消息被转发至另一消费者，则可能会出现重复消费的问题
-
消费顺序打乱
- 先收到的消息由于消费者崩溃而导致消息排队到后续消息之后，在外部看来产生了消息消费的顺序打乱的问题
-
分区日志(OFFSET)
-
使用日志进行消息存储
- 解决由于消息无持久化而导致的消息不能被重新运算的问题
- 为了提高吞吐，可以创建多个分区，每个分区有独立的日志文件，独立的offset
-
日志与传统消息相比
-
基于日志（OFFSET）可使用消费者组进行消费
-
单线程消费分区中的所有消息
- 消费者工作节点数最多等于分区数
- 如果某条消息消费缓慢，则会阻塞后续消息的消费
-
如果消息处理代价高昂，允许并行处理数据对数据处理顺序无要求的情况下，使用AMQP/JMS风格（基于ACK）的代理的可行的；如果要求高吞吐与顺序消费，基于日志方法（基于OFFSET）表现得非常好
-
-
消费者偏移量
- 顺序消费模式中，所有小于当前offset的消息均被消费，大于的未被消费
- 顺序消费模式中，如果消费者发生了崩溃，分区将会指派给另一消费者，如果崩溃前消息的OFFSET没有更新，则消息有可能会消费2次
-
磁盘空间使用
- 日志文件通常分段存放，不时地将旧文件进行删除或归档
- 如果消费速率跟不上生产速率，由于旧文件会不时清理，可能会错过一些数据。实际上，基于日志的系统会在磁盘上开辟环形缓冲区进行消息存储
- 消息传递系统在内存队列太长之后才会向磁盘写入消息，当队列很短时，写入速度很快，而写入磁盘后速率会慢得多；相比之下，基于日志的系统消息写入方式不变，吞吐量稳定
-
当消费者跟不上生产者时
- 可以提示报警，在由于落后太多超出缓冲区范围前进行修复
- 单个消费者落后太多不会影响其它消费乾的消费过程
-
重播旧信息
- 相比AMQP/JMS系统在确认会删除队列中的消息，基于日志的系统只进行只读操作，因此可对历史数据进行回放重复消费，应用在某些需要进行历史数据修复的场景
流与数据库
保持系统同步
-
系统中OLTP提供用户服务，缓存加速请求，全文搜索处理搜索查询，数仓用于分析，各数据存储间需要保证数据一致性
-
实现方式
-
单写
- 周期性地从主数据库（如OLTP）的数据副本中执行同步进程。如数据仓库，可以周期性地执行ETL进程更新数据。缺点是转储过程缓慢。
-
双写
-
即由应用层代码同时在多个数据存储中执行写入
-
由于多个请求的竞争，可能会导致数据不一致
-
一个成功，一个失败同样也会导致数据不一致
-
-
-
变更数据捕获
-
变更数据捕获的实现
- 常见方式：触发器、基于binlog的同步工具
- 特点：异步，记录数据不会等消费者应用变更再提交
-
初始快照
- 从某个时间所对应的位置建立快照，并在之后的同步过程使用增量变更实现
-
日志压缩
- 在消息传递给下游之前，先将数据进行压缩（如借助Kafka的日志压缩功能，只保存KEY的最新VALUE值）
-
变更流的API支持
- RethinkDB允许查询订阅通知，当查询结果变更时获得通知【36】，Firebase 【37】和CouchDB 【38】基于变更流进行同步，该变更流同样可用于应用。而Meteor使用MongoDB oplog订阅数据变更，并改变了用户接口【39】。
- VoltDB允许事务以流的形式连续地从数据库中导出数据【40】
- Kafka Connect
事件溯源
- 从事件日志中派生出当前状态
- 命令和事件
- 状态，流和不变性
- 不可变事件的优点
- 从同一事件日志中派生多个视图
- 并发控制
- 不变性的限制
流处理
与批处理的区别：由于数据无界，没有排序的概念，因此无法使用排序合并联接；出错后也不能像批处理从头进行运算
流处理的应用
-
复合事件处理
- 算子是固定的，流经不同的数据生成不同的结果
-
流分析
- 基于流事件计算统计聚合指标
- 如：Apache Storm，Spark Streaming，Flink，Concord，Samza和Kafka Streams 【74】。托管服务包括Google Cloud Dataflow和Azure Stream Analytics
-
维护物化视图
- 维护缓存，搜索索引和数据仓库与主数据库的一致性
-
在流上搜索
- 固定查询搜索算子，当有数据FEED时，直接输出结果
-
消息传递和RPC
- Actor框架主要是管理模块通信的并发和分布式执行的一种机制，而流处理主要是一种数据管理技术。
- Actor之间的交流往往是短暂的，一对一的；而事件日志则是持久的，多订阅者的。
- Actor可以以任意方式进行通信（允许包括循环的请求/响应），但流处理通常配置在无环流水线中，其中每个流都是一个特定作业的输出，由良好定义的输入流中派生而来。
时间推理
-
事件时间与处理时间
- 由于网络延迟，消息达到顺序不一定是发生顺序
- 基于事件时间或处理时间来进行统计，可能会得到不一样的结果
-
知道什么时候准备好了
- 无法确定窗口里的事件是否已经收集全
- 对于滞留的事件，可以忽略这些事件；或者发布更正，这需要重新计算，回收之前窗口计算的值
-
你用的是谁的时钟？
- 对于设备端，离线脱机事件的缓存在设备端时钟不准确的情况下，其时钟需要校准
-
窗口的类型
- 滚动窗口（非重叠）
- 滑动窗口（重叠）
- 跳动窗口（重叠但窗之前间隔不连续）
- 会话窗口
流式连接
-
流流连接（窗口连接）
- 对于前后相继的两个事件A与B，且先有A事件才有可能发生B事件，如果他们同属于同一会话，且B滞后A的时间不确定（几秒或几周不等），则计算B发生的条件概率时，一般考虑两事件时间间隔小于一定时间时，才连接两个事件
-
流表连接（流扩展）
- 即为流数据从数据库中添加关联数据，可通过在流处理中远程查询数据库再拼接数据实现，可能会较慢，导致数据库过载；另一种方法是在本地建立数据副本，但需要保证主数据与副本的及时同步
-
表表连接（维护物化视图）
- 通过流处理的方式将表与表之间的数据变更进行处理
-
连接的时间依赖性
- 当时间相近的流的事件，不同的处理顺序会产生不同的结果。比如对于流表连接，如果表内容发生了更新，需要考虑事件究竟和更新前的数据关联还是更新后的数据关联
容错
-
微批量与存档点
- 微批量即将流划分小块，每次处理一个块。如spark streaming
- Flink基于Chandy-Lamport算法（用于做分布式快照）实现了检查点机制
- 微批与存档点均实现了恰好一次语义
-
原子提交再现
- 在流处理框架同时管理状态变更与消息传递来内化事务
-
幂等性
- 可借助外部数据库实现。如消费kafka 数据时，将消费后的值连同OFFSET一同写入数据库，避免重复消费
- 重启一个失败的任务必须以相同的顺序重放相同的消息（基于日志的消息代理能做这些事），处理必须是确定性的，没有其他节点能同时更新相同的值
- 当消费出现故障转移时，需要加防护(fence)以防止被假死节点干扰
-
失败后重建状态
- 可以采取本地或远端保存状态的策略。如Flink将状态存在HDFS，当状态是由时间非常短的窗口聚合而成时，甚至可以直接从流中恢复