flink 学习备忘录-面试重点问题（2）

批流是怎样统一的?

Batch和streaming会有两个不同的ExecutionEnvironment,不同的ExecutionEnvironment会将不同的API翻译成不同的JobGgrah
JobGraph 之上除了 StreamGraph 还有 OptimizedPlan. OptimizedPlan 是由 Batch API 转换而来的.
StreamGraph 是由 Stream API 转换而来的,JobGraph 的责任就是统一 Batch 和 Stream 的图.

Flink JobManagerHA ?

与Storm不同的是，知道Storm在遇到异常的时候是非常简单粗暴的，比如说有发生了异常，可能用户没有在代码中进行比较规范的异常处(至少执行一次)的语义，比如说一个网络超时的异常对他而言影响可能并没有那么大。
但是Flink不同的是他对异常的容忍度是非常的苛刻的，那时候就考虑的是比如说会发生节点或者是网络的故障。
那JobManager单点问题可能就是一个瓶颈，JobManager那个如果挂掉的话，那么可能对整个作业的影响就是不可恢复的，所以考虑了做HA。zookeeper实现

Kappa架构

用来解决lambda架构的不足,即更多的开发和运维工作
lambda架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考
Flink流处理引擎出现后,为了解决两套代码的问题,Kappa架构出现

Kappa架构介绍

  1. Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）
  2. 在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。
  3. Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
    调研:flink可以保证计算的准确性,但是有一个前提是数据是准时到达的.
    卡口过车数据 设备会因为网络延迟迟到几个小时,所以 Kappa架构不适合我们

引用flink面试题整理
建议次日凌晨使用离线计算统计前天数据,替换实时表数据

Lambda架构

Lambda 架构用定期运行的批处理作业来实现应用程序的持续性，并通过流处理器获得预警。流处理器实时提供近似结果；批处理层最终会对近似结果予以纠正。
批处理架构很难解决乱序事件流问题
批处理作业的界限不清晰,写死了 假设需要根据产生数据的时间段(如从用户登录到退出)生成
聚合结果，而不是简单地以小时为单位分割数据

  • 产生原因 solr单表数据量太大(50亿/65字段/25索引字段) 并发查询时,垃圾回收不及时
  • 影响: solr查询慢,flink 任务进行CPU争夺 数据滞后
  • 解决方式: 数据分表 分为实时表和历史表 实时表保持在20亿左右,数据定期删除

Chandy-Lamport算法

  1. 将流计算看作成一个流式的拓扑,定期在这个拓扑的头部source点开始插入特殊的barriers(栅栏)
  2. 从上游开始不断向下游广播这个Barriers.
  3. 每一个节点收到所有的barriers,会将state做一次snapshot(快照)
  4. 当每个节点都做完Snapshot之后,整个拓扑就算做完一次checkpoint
  5. 接下来不管出现任何故障,都会从最近的checkpoint进行恢复
posted @ 2021-04-12 18:24  foola  阅读(112)  评论(0)    收藏  举报