flink理论干货笔记(1)

1. flink用同一种底层技术实现流处理和批处理 

2. 除了低延迟和高吞吐,优秀的流处理技术还应该能在系统崩溃后重新启动,并且产生准确的结果。即可以容错以及保证exactly-once 

3. 好的容错应该在没有数据错误的情况下没有太大的开销 

4. 思考:flink能处理乱序事件流?怎么处理?还能够准确替换流数据?那不就是篡改数据? 

5. 对比storm,尽管storm能低延迟,但难以实现高吞吐,且正确性无法满足需求,即不能保证exactly-once,开销也很大

6. 对比spark streaming,spark streaming将连续事件的流数据分割成一系列微小的批量作业(微批处理),能实现准实时(仅有几秒或几亚秒的延迟),且能实现exactly-once,以及失败重新运行

7. 注意,Strom Trident是对storm的延伸,它的底层引擎基于微批处理方法,也实现了exactly-once,但无法满足低延迟

8. 通过批处理来模拟流处理,会导致开发和运维相互交错,而且这种技术的潜在问题是,时间由系统中生成小批量作业的那一部分全权控制,spark streaming也不能完全避免,而且有糟糕的用户体验,说到底还是无法做到真实时,代码之外还需要大量性能调优。微批处理的灵活性和表现力都缺乏,开发速度慢,运维成本高 

9. flink能解决微批处理的各种弊端,能按照连续事件高效处理数据。能同时满足高吞吐、低延迟、在压力下保持正确(即exactly-once)、操作简单/表现力好、时间正确/语义化窗口 

10. lambda架构既保证了低延迟,又保证了正确性,它同时使用了mapreduce和storm,前者用于批处理,后者用于流处理。总体上说它还不够好,因为它有一个数小时的时间窗口,在这个窗口内,由于实时任务失败产生的不准确结果会一直存在。同时,需要两套API切换,难以维护。 

11. flink将批处理(即处理有限的静态数据)看做一种特殊的流处理 

12. flink runtime执行引擎是容错性数据流,是flink的核心构造。它是一个分布式系统,能够接受数据流程序并在一台或多台机器上以容错的方式执行。flink runtime可以跑在yarn或mesos上,当然单机也行,特别是调试的时候。 

13. flink runtime之上是datastream api和dataset api,它们是面向用户的api,分别用于流处理和批处理。 

14. datastream api之上是table api和cep api,分别用于处理结构化流数据,和复杂事件数据 

15. dataset api之上是flinkml和gelly,分别用于机器学习和图计算 

16. 问题:dataset api上能处理结构化流数据吗?或者说,table api是否也基于dataset api? 

17. dataset api先于datastream api被开发出来,因为工业界一开始对无限流处理的需求不大 

18. flink项目的架构一般包含两部分,消息传输层和流处理层,前者是kafka等,后者就是flink 

19. 消息传输层是作为流处理层上游的安全队列,相当于缓冲区,能防止数据处理发生中断。kafka具有持久性、高性能,以及支持消息重播。这就允许flink对事件流的某一部分进行重播和再计算。 

20. 消息传输层还支持从多个源(生产者)收集数据,并使这些数据给多个应用程序ÿ

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值