背景：现有的流处理系统例如flink主要用来处理在数据流上一直跑某个单独的查询，并且这些查询都经过优化 以及单独执行。Astream¹提出的框架主要针对的场景是ad-hoc查询。这种场景下，流不仅使用长时间运行的查询进行处理，而且还使用数千个短期运行的临时查询进行处理。 为了有效地支持这一点，必须在多用户环境中共享资源和用于流临时查询的计算。Astream采用了一些共享的operator从而避免一些冗余计算。AJoin²在Astream基础上，又进一步做了一些优化，例如减小共享operator的代价、运行时查询计划重优化、运行时scale-up和scale-out等。

例如以下场景：

V={vID, length, geo, lang, time} 用户墙上显示的影片流

W={usrID, vID, duration, geo, time} 用户的影片观看流

C={usrID, comment, length, photo, emojis, time} 用户评价流

R={usrID, reaction, time} 用户反馈流

Q1：机器学习模块用于学习获取用户喜好，该查询得到德国用户喜欢看的英文电影

Q2：是编辑组用来发现网络操作组织(水军)，这个查询用来检测来自美国的用户，这些用户在看完电影10s以内就发表评论，而且评论长度大于5.

Q3：是质量保证组用来分析用户对推荐影片的反馈，这个查询用来分析欧洲用户给予负面反馈的影片，并且评论里面至少有一个表情。

这是其中一个实验图，可以看到同一时间查询比较多的时候（关注紫色的部分），Ajoin的性能优势非常明显。

背景：当前用于高速流上的数据并行，增量处理和视图维护的系统隔离了独立查询的执行。在存在并发的增量维护查询的情况下，这会造成不必要的冗余和开销：每个查询必须在相同的输入流上独立维护相同的索引状态，并且新查询必须从头开始构建此状态，然后才能开始发出其第一个结果。本文³介绍了共享的安排：维护状态的索引视图，该视图使并发查询可以重用相同的内存状态，而不会影响数据并行性能和扩展性。我们在现代流处理器中实施共享安排，并针对高吞吐量流进行增量，交互式查询，显示了查询响应时间和资源消耗的数量级改进。

前面AJoin工作属于Multi-Query-Optimization(MQO)，它会对共同的子表达式共享状态和处理，而shared arrangements是共享历史索引，它允许事后共享：新查询可以立即附加到现有查询的内存安排中，并迅速开始生成反映所有先前事件的正确输出。

增量处理：与一般的 SQL 查询不同，在增量 SQL 查询中，当一个表的内容改变， 我们希望这些表将内容的修改表示成包含增加的行和减少的行的增量表(Delta Table)的形式，这些增量表将会被送入上层算子进行处理，flink中的SQL都是增量SQL。

上图是一个实验结果图，跑的是TPC-H测试，最左边是查询延迟分布，中间是更新处理的时延，右边是内存的使用。可以看到该研究有效提升性能以及减少内存的使用。中间的图是互补累积分布图，意思是延迟超过某一时间的查询的累积分布。

另外还有一篇相关工作⁴。

背景：现代流处理引擎（SPE）在严格的延迟约束下处理大量数据。许多SPE使用在无共享架构上传递的消息来执行处理pipline，并应用基于分区的横向扩展(Scale out )策略来处理高速输入流。此外，许多最新的SPE都依靠Java虚拟机来实现平台独立性，并通过从底层硬件中进行抽象来加速系统开发，但是不能充分利用现有的高性能硬件资源。本文⁵主要考虑Scale out带来的数据传输和同步开销 ，提出充分利用高性能硬件使得Scale up作为扩容的另一种选择。Saber⁶就是一个例子，它利用了GPU资源来进行计算加速。本文比较全面地分析了现有的流处理系统可以做哪些优化来适应现有的一些硬件发展。

• 现有硬件发展：
  • CPU：多Socket的CPU的每个socket有多个核以及自己的内存控制器，跨socket访问内存延时会更长（NUMA）
  • 内存：容量增长（上TB的内存）
  • 网络：访问速度增快，甚至比内存还快。因此出现远程内存访问技术RDMA
• 本文工作：
  • 对比C++和Java性能：如RDMA访问（数据摄取）、队列访问（数据交换）
  • 提出两种并行化策略：Upfront Partitioning(UP，广泛用于现有的Scale out架构如flink)、以及两个用于Scale up的并行化策略Late Local Merge (LM)与Late Global Merge (GM)
  • 实现无锁窗口机制：最小化工作线程之间的冲突

上面是文中的几个实验图，YSB、LRB、NYT分别对应不同的benchmark，UP、LM、GM分别对应不同的并行化策略，可以看到基于c++实现的方法能更好的利用内存，接近内存带宽，基于java的要逊色许多。并且，作者提出的GM策略也在单机情况下表现最优。

这篇文章⁷是关于RDMA的全局内存管理。

上图是个扩展实验图，这是在1Gbs的网络状况下的结果，像网络密集型的benchmark如YSB在4个节点以上时性能就不再提升了。这篇文章⁸显示，当网络带宽增快时，CPU又会成为瓶颈，apache spark和flink需要系统的更改。

背景：本文主要工作是对滑动窗口的流数据建立索引，来提升窗口连接的性能。传统的索引结构无法满足流数据动态变化的特性，本文⁹提出分区内存合并树结构的索引，并且为其又提出了一些并发控制的机制，使得该索引支持在多线程下频繁更新。在此基础上，本文还设计了一个算法来实现基于索引的并行流连接，从而利用多核处理器的计算能力。下图是文中提出的PIM-Tree与IM-Tree与B+Tree的对比，纵轴是吞吐，横轴是窗口大小。右边是采用多线程进行join的吞吐提升。

? 传统的连接顺序优化只要基于动态规划或者启发式方法（Zig-Zag、QuickPick-1000等）。当成本模型为非线性时（例如有内存限制、复用物化等条件），这些方法得到的解往往是次优的。本文¹⁰将连接排序问题表示为马尔可夫决策过程（MDP），然后构建了一个使用深度 Q 网络（DQN）的优化器，用来有效地对连接进行排序。本文基于 Join Order Benchmark（专门用于压力测试连接优化）对提出的方法进行了评估。基于强化学习的深度优化器的执行计划成本比所有目前的成本模型最优解决方案改进了 2 倍，比当前最好的启发式方法改进最多可达 3 倍。

上图实验对比了DQ（本文提出的方法）在三种代价模型下，相较于其他的一些方法的表现对比。其中通过暴力求解得到的解作为baseline，其他都是相对于这个baseline的性能。三个代价模型，第一个是数据全部在内存中，第二个是考虑内存限制，超过内存溢写磁盘，第三个考虑复用上游操作建立的hash表。可以看到，随着代价模型变得附加，DQ的相对表现也更加优秀。

上图是随着join关系的数量增长，优化器本身的延迟变化，纵轴是取了log。可以看到在join的关系增多时，DQ的优势就更加明显。如果采用GPU或者TPU加速，它会表现更大的优势。

流处理系统的工作负载以及共享的云环境有着很高的可变性以及不可预测性。再加上很大的参数空间以及不同的SLO，使得流处理系统很难静态的去调整。本文¹¹提出了一个可扩展、可编程的一个分布式流处理系统控制面板，它支持连续监控以及反馈、动态重新配置。Chi利用在数据平面通道嵌入控制平面消息，以实现流的处理系统的低等待时间和灵活的控制平面。Chi引入了新的响应式编程模型和设计机制来异步执行控制策略，从而避免了全局同步。

上图是动态扩容的实验，在t=40s的时候，数据的摄取速度增加了一倍，然后分别采用各个系统的策略进行扩容。在Flink中，它会调用一个SavePoint，然后重启这个数据流。flink由于savepoint机制会导致整个停下来，在右图中的那个地方吞吐会降到零，几秒后才能恢复。Chi的峰值增加的比较少，并且以更快的速度恢复到稳定状态，大概是flink的6倍。

系统每10s会进行一次checkpoint，在35s已经做一次checkpoint，然后40s的时候让一个虚拟机挂掉，然后分别采用三个系统的恢复机制。由于flink它需要上一个checkpoint来重新部署数据流，因此吞吐又掉到0了，而Chi的吞吐没有降低，并且延迟更快的回到稳定状态，速度大概是flink的3倍。

滑动窗口聚合在流处理系统应用中很常见，部分算子如sum、mean类型的，对数据到达的顺序没有要求，来一个可以聚合一个，因此时间复杂度是O(1)。但是某些算子如max、min等，对流到达顺序要求是有序的。然而很多时候如网络抖动、批处理、失败恢复等都会导致一些延迟，使得数据并不是按序到达。这个时候主要有两种策略，一种是等数据到达，再排个序，然后再做聚合；另一种是每来一个数据都将它聚合到一个数据结构中，以备随时查询，目前有名的方法是使用增强的红黑树去做，复杂度为O(Logn)，其中n是窗口大小。本文¹²提出一个finger B-tree aggregator 的算法，可以在有序情况下达到O(1)复杂度、轻微的乱序可以达到接近O(1)的复杂度，极端情况下也最多只有O(logn)的复杂度。

从图中可以看出，flink在乱序场景下的聚合性能是比较差的。

1. B?ttcher, Jan, et al. “Scalable garbage collection for in-memory MVCC systems.” Proceedings of the VLDB Endowment 13.2 (2019): 128-141.
2. Sun, Yihan, et al. “On supporting efficient snapshot isolation for hybrid workloads with multi-versioned indexes.” Proceedings of the VLDB Endowment 13.2 (2019): 211-225.

1. Zois, Vasileios, Vassilis J. Tsotras, and Walid A. Najjar. “Efficient main-memory top-K selection for multicore architectures.” Proceedings of the VLDB Endowment 13.2 (2019): 114-127.

Schiavio, Filippo, Daniele Bonetta, and Walter Binder. “Dynamic speculative optimizations for SQL compilation in Apache Spark.” Proceedings of the VLDB Endowment 13.5 (2020): 754-767.

1. Sun, Ji, and Guoliang Li. “An end-to-end learning-based cost estimator.” Proceedings of the VLDB Endowment 13.3 (2019): 307-319.
2. Li, G., et al. (2019). “Qtune: A query-aware database tuning system with deep reinforcement learning.” Proceedings of the VLDB Endowment 12(12): 2118-2130.
3. Tan, J., et al. (2019). “ibtune: Individualized buffer tuning for large-scale cloud databases.” Proceedings of the VLDB Endowment 12(10): 1221-1234.
4. Van Aken, D., et al. (2017). Automatic database management system tuning through large-scale machine learning. Proceedings of the 2017 ACM International Conference on Management of Data.
5. Zhu, Y., et al. (2017). Bestconfig: tapping the performance potential of systems via automatic configuration tuning. Proceedings of the 2017 Symposium on Cloud Computing.
6. Zhang, J., et al. (2019). An End-to-End Automatic Cloud Database Tuning System Using Deep Reinforcement Learning. Proceedings of the 2019 International Conference on Management of Data - SIGMOD '19: 415-432.

---

1. Karimov, J., et al. (2019). Astream: Ad-hoc shared stream processing. Proceedings of the 2019 International Conference on Management of Data.

2. Karimov, J., et al. (2019). “AJoin: ad-hoc stream joins at scale.” Proceedings of the VLDB Endowment 13(4): 435-448.

3. McSherry, F., et al. (2020). “Shared Arrangements: practical inter-query sharing for streaming dataflows.” Proceedings of the VLDB Endowment 13(10): 1793-1806.

4. Rehrmann, Robin, et al. “Oltpshare: the case for sharing in OLTP workloads.” Proceedings of the VLDB Endowment 11.12 (2018): 1769-1780.

5. Zeuch, S., et al. (2019). “Analyzing efficient stream processing on modern hardware.” Proceedings of the VLDB Endowment 12(5): 516-530.

6. A. Koliousis, M. Weidlich, R. Castro Fernandez, A. L. Wolf, P. Costa, and P. Pietzuch. Saber: Window-based hybrid stream processing for heterogeneous architectures. In SIGMOD, pages 555–569. ACM, 2016.

7. Cai, Qingchao, et al. “Efficient distributed memory management with RDMA and caching.” Proceedings of the VLDB Endowment 11.11 (2018): 1604-1617.

8. A. Trivedi, P. Stuedi, J. Pfefferle, R. Stoica, B. Metzler, I. Koltsidas, and N. Ioannou. On the [ir]relevance of network performance for data processing. In USENIX Workshop on Hot Topics in Cloud Computing (HotCloud 16). USENIX

9. Shahvarani, A. and H.-A. Jacobsen (2020). Parallel index-based stream join on a multicore cpu. Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data.

10. Krishnan, Sanjay, et al. “Learning to optimize join queries with deep reinforcement learning.” arXiv preprint arXiv:1808.03196 (2018).

11. Mai, Luo, et al. “Chi: a scalable and programmable control plane for distributed stream processing systems.” Proceedings of the VLDB Endowment 11.10 (2018): 1303-1316.

12. Tangwongsan, Kanat, Martin Hirzel, and Scott Schneider. “Optimal and general out-of-order sliding-window aggregation.” Proceedings of the VLDB Endowment 12.10 (2019): 1167-1180.
    l, and Scott Schneider. “Optimal and general out-of-order sliding-window aggregation.” Proceedings of the VLDB Endowment 12.10 (2019): 1167-1180.