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. 消息传输层还支持从多个源(生产者)收集数据,并使这些数据给多个应用程序ÿ