1.实现思想

这两篇论文中都指出需要实现确定性的处理，需要保证

确定的执行逻辑，即相同的输入会有相同的输出，在flamestream^[1]中指出用户定义的逻辑必须是pure function。StreamScope^[2]中提到用户定义的逻辑必须是确定的。
确信的执行顺序
在算子计算逻辑是确定的情况下，需要保证输入顺序是确定的。在保证source输入顺序和传输管道FIFO的情况下，造成算子输入不确定的原因主要是shuffle过程带来的多个上游输入交汇导致交汇后的顺序无法保障，针对这一情况，目前流行的做法是IOP和OOP.
对于有多个流输入的情况，StreamScope和flamescope采用了不同的处理方式，StreamScope采用了IOP（in order process）的方式,，flamestream则采用了OOP(out of order)的方式.

IOP处理
OOP

Streamscope中在有多个上游输入的算子前加入merge算子插入CTI event（CTI event类似low watermark，event类似tuple）的方式，保证收到时间戳在CTI event之前的event，之后按照确定的方式进行排序和处理，从而保证流交汇后的顺序，从而保证处理的确定性。这里和OOP的处理方式类似，也是通过插入punctuation保证元组都收到了。但由于streamscope对buffer的元组进行了确定性排序，以保证数据能被通过确定性的计算恢复，所以我认为算是IOP的处理方式。

进行join的两个输入流在处理之前通过merge算子合并成确定性的顺序
flamestream则是将状态视为流的一部分，使得大部分算子从有状态算子转变成无状态算子，仅grouping算子需要维护状态，grouping算子的作用是将计算状态和item（item类型flink中的tuple）划分到一个窗口为2的item中，使得下游算子处理时能够按照状态和状态对应的算子进行计算。

将状态视为流的一部分
仅grouping算子需要维护状态，grouping算子对于乱序的输入，采用了乐观的修复方式，具体可以参考^[3]。

grouping修复乱序

2.延迟的引入:

Streams延迟主要存在于有多个流输入的算子，需要等待CTI event 到来，从而进行排序和输出，由于下游算子需要满足确定性的顺序，只有有流合并的产生对于有状态和无状态的算子都需要等待CTI event并进行排序。论文认为Because the processing logic of vertices tends to wait for the CTI events in the same way, this solution does not introduce additional noticeable delay 面对deep pipeline时，下游和上游算子等待处理CTI event的方式相同，因此多个级联的merge并不会引入过多的延迟。
flamestream面对流交汇产生的乱序tuple，采用的修复策略。只要在最终输出设置barrier根据接受的tomb过滤无效的算子，因此只会在barrier处引入延迟，。

3.性能

Streamscope尚未开源，没有与其他框架的性能对比实验
flamestream就建立倒排索引与flink进行了对比实验，证明在低吞吐量情况下，flamestream具有比flink更低的延迟，但在吞吐量较高的情况下，flink更为占优。

flink 和 flamstream对比

flink与flamestream的对比
图八来源^[4]

4.疑问和思考

1.flamestream^[1]中提到乱序tombstone仅占所有item的10%。但我觉得可能针对不同的情况有不同结果，可能有不同的性能，比如一个迟到很久的event会导致好重新计算很多的item，对性能造成很大影响，如果对group的输入元组进行一个排序，比如采用 Max determine 的方法^[5],不严格保证顺序，应该能显著降低tombstone的产生。
2.flamestream中只提到基础的map reduce的实现，对于其他算子，如窗口、join等没有进一步说明。
3.flamestream没有提到是否支持event time，但我想如果系统外部输入元组的时间不是有序的，则flamestream不能保证处理所有乱序数据，barrier是按最小运行的元组的global time进行拦截的，若此时外部输出时间小于系统此时记录的最小运行时间，则barrier无法保障拦截所有无效元组。

Kuralenok I E , Trofimov A , Marshalkin N , et al. Deterministic Model for Distributed Speculative Stream Processing[J]. 2018.jiangq ↩ ↩
Wei L, Fan H, Qian Z, et al. STREAMSCOPE: continuous reliable distributed processing of big data streams[C]// Usenix Conference on Networked Systems Design & Implementation. 2016. ↩
https://www.jianshu.com/p/d77048c8ae7d ↩
https://research.jetbrains.org/files/material/5b2459ef42bb9.pdf ↩
Zacheilas N , Kalogeraki V , Nikolakopoulos Y , et al.Maximizing Determinism in Stream Processing Under Latency Constraints[C]// Acm International Conference on Distributed & Event-based Systems. ACM, 2017 ↩