flink 与sparkstreaming structstreaming 的对比
运行模型
struct streaming 是持续不断地生成小批量dataset 然后交给sparkSQL 进行处理。与原有的sparksql 相比增加了状态处理的功能。
Flink 中的执行图可以分成四层：StreamGraph-> JobGraph -> ExecutionGraph -> 物理执行图。
时间
process_time ingest_Time event_time
flink 全部支持
structstreaming 只支持两种
join
flink 支持的join 更多
structstreaming 支持的join 有比较多的限制
异步io 和维表join
Structured Streaming不直接支持与维表的join操作，但是可以使用map、flatmap及udf等来实现该功能，所有的这些都是同步算子，不支持异步IO操作。但是Structured Streaming直接与静态数据集的join，可以也可以帮助实现维表的join功能，当然维表要不可变。
Flink也不支持与维表进行join操作，除了map，flatmap这些算子之外，flink还有异步IO算子，可以用来实现维表，提升性能。
状态管理
flink 有MapState ListState ReducingState ,AggressionState
ss 只有mapGroupState 和FlatMapGroupState
触发模型
ss 由于是批量需要定时触发才会执行
flink 没有触发的概念
flink vs sparkstreaming
sparkstreaming是mini batch 计算。如图所示，Spark 根据 RDD 依赖关系中的 shuffle dependency 进行作业的 Stage 划分，每个 Stage 根据 RDD 的 partition 信息切分成不同的分片；在实际执行的时候，只有当每个分片对应的计算结束之后，整个 Stage 才算计算完成。
Flink 是为真正的流式计算而设计的（并且把批处理抽象成有限流的数据计算），上游数据是持续发送到下游的，这样就避免了某个长尾分片导致其他分片计算“空闲”的情况，而是持续在处理数据，这在一定程度上提高了计算资源的利用率，降低了延迟
minibatch 的RDD 在数据丢失的时候在异常需要恢复的时候只要通过依赖关系重放上游的数据就能实现，效率比较高。
而flink 恢复则需要停止整个"流水线"上的算子，并从 Checkpoint 恢复和重放数据；虽然 Flink 对这一点有一些优化，比如可以配置 failover strategy 为 region 来减少受影响的算子，不过相比于 Spark 只需要从上个 Stage 的数据恢复受影响的分片来讲，代价还是有点大
flink的序列化效率比spark 相对较高。
spark 采用的kyro 和java 原生的序列化框架，但是依然比flink的序列化效率低
主要是
因为在一个 Flink 作业 DAG 中，上游和下游之间传输的数据类型是固定且已知的，所以在序列化的时候只需要按照一定的排列规则把“值”信息写入即可（当然还有一些其他信息，比如是否为 null
本文由 妖言君 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Feb 25, 2021 at 03:33 pm