[NSDI 2021]MilliSort and MilliQuery Large-Scale Data-Intensive Computing in Milliseconds

MilliSort and MilliQuery: Large-Scale Data-Intensive Computing in Milliseconds

动机

希望讨论在拥有无限多，但随时会被回收的资源条件下一毫秒最多能执行多少任务。文章定义了MilliSort和MilliQuery作为benchmarks，来判断算法的优劣。

背景

现在，大数据集上的应用基本都是秒级或者分钟级内实现的。这是因为分配和协调服务器集群需要不少耗时。而MapReduce或者Spark这些传统框架，为了平摊网络延迟，往往会一次性处理非常大的一组数据，这也导致了他们很难实现实时任务。而那些可以处理流任务的框架，如Flink，Spark Streaming等，需要牺牲可同时处理的数据量。

现有的一些serverless平台，比如AWS, Lambda， Azure Cloud Functions和Google Cloud Functions可以调度运行一些短时的任务。但这些平台都只能运行一些个人函数，难以调用多台服务器来处理单个问题。

本文探究的是serverless计算上拓展的可能性：节省时间、提高规模。而实现的基础也是明确的，就是利用flash burst，说白了就是随时都可能被回收的算力边角料。

文章要回答三个问题：

• flash bursts至少需要运行多少时间
• 在这段时间内可以调用多大数量的服务器
• 当前系统的哪些方面限制了flash bursts的速度和规模

基本的几个限制：

• 每个服务器的网络带宽导致的数据量限制
• 协调任务带来的消耗
• 多通信消耗(CPU传输消耗)
• 团队通信消耗

几个已经实现的团队通信：

• Broadcast:对所有服务器同步信息
• Gather:从不同服务器获取信息
• All-gather:安排每个服务器都有一个数据的副本
• Shuffle:每台服务器初始信息为每一台其他服务器上的信息，需要从其他特定服务器上做数据传输

团队通信的两个好处：

• 并发，加快通信
• 打包小数据，传输大数据，提高效率

两个Benchmark

• MillSort:分布式地排序100-byte的记录
• MilliQuery:三个有代表性的查询：Q1：平行扫描聚合查询，根据语言统计维基文章的浏览量；Q2：重新洗牌后再做聚合，找到有top-10的维基作者数量的IP地址；Q3：需要多次洗牌的分布联合操作，复杂的github数据分析。
  需要说明的是，所有数据都已经事先存到了内存中

MillSort

分布式排序最大的挑战就是任何一个记录都有可能在任意一个服务器上结束，这会导致数据流非常混乱。
该算法的四个基本步骤：

• 本地排序：每个服务器对它自己的初始数据进行排序
• 分区：在各服务器结束排序后，确定他们的范围
• 洗牌：每个服务器把他们的记录传给目标服务器
• 重新排序：对传到的数据进行整合排序

其中，分区步骤并不能非常理想化地实现，因为一台服务器没法足够快地完成某个具体地排序问题，因为不同的序列会有不同的最优排序法。解决方法自然就是对所有序列分配多台服务器，哪个最快用哪个。

基本的样本分区排序机制。在各服务器排序好自己本地的数据后，会平行地采样各自数据的key。那些样本被叫做pivots。这些pivots被拼接后根据key被整块排序，再被均分分割

多层的分区案例

实验