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