最近在研读有关在线聚集的论文，粘出一些自己的理解和大家分享，有理解不当之处，还请各位指正。本文是对Online Aggregation for Large MapReduce Job文章的理解。
背景知识
Mapreduce模型是大数据处理的一个重要模型，它处理速度快，节点可伸缩，但仍然有其缺陷。一般认为它只适合线下任务，不适合线上任务。因为其只有在处理完全部数据之后才能得到最终结果，用户是无法得到中间结果的。后来有人提出了改进策略HOP，但是reduce需要将接收到的数据重新计算一边来产生中间结果，造成资源浪费。这篇论文就是为了改进mapreduce这种缺陷，提出了将OLA用在mapreduce中的想法。OLA是在线聚集计算，其结果往往随着时间的增加而越来越精确。其中间结果和最终结果存在着某些关系。因为这些关系的存在可以大大减少资源浪费。
OLA没有被采纳的原因：需要扩展内核，人们对资源消耗不那么重视了
然而随着数据库系统的发展（大规模数据需要处理，数据库日新月异），内核不能扩展理论在逐渐变地不重要。随着最终用户的转移，且10%的时间成本能带来90%的准确率，时间和计算资源越来越看重。这预示着属于OLA的新时代到来了。
这篇论文考虑在无共享的环境中提供OLA的问题。首先要保证的一点是，计算的任何一点上看到的数据集是一个随机的子集合，这样才能够用部分近似替代整体。但是在大规模分布式计算环境中运行时间变得很重要。在这种环境下，每个数据单元都有成百万数据。
相关工作
OLA曾经在经典数据库和点对点系统中被研究。在分布式背景下的研究只有HOP（Hadoop在线原型系统）HOP能够输出运行的中间结果。
论文的工作
提出一个适用于大规模分布式MapReduce的OLA系统模型；更仔细地描述如何在Hyracks（一个mapreduce框架）上运行该模型；讨论模型地贝叶斯估计框架和可信的bounds；用实验结果证明模型产生可信的结果并且能迅速估计
模型
1、假设数据被分为‘blocks’这样的存储单元。块是系统中数据的任意一个子集，允许块的大小随机。该模型同样适用于数据分布不均匀的情况（块的大小不均匀，块内数据不均匀）。当然在数据分布均匀情况下，每个块的聚合值的方差会小一点，模型会更加适用（很快达到很高的精度）比起不均匀情况。
2、OLA计算开始时，所有的块被随机排序到一个队列里。只能用GetNext()来取下一个块。在mapreduce中，我们定义了一个central scheduler ，它的工作是创建mappers和reducers，并和数据结合在一起，并在物理系统硬件上进行调度。当scheduler发现物理硬件有足够的资源去处理下一个块，调用GetNext()去获取一个块。GetNext()一定是按照队列顺序获取一个块。经过一些延迟，块被加载入mapper并且被处理完。这个处理包括块从磁盘读入到传送到网络的时间以及块中每个字节的处理时间。
运行模型
Hyracks 是一个开源项目支持map和reduce操作，分配map任务到一个给定的块，使用分离函数新建可配置的reduce任务的数量，这些任务被分配给特定的组。
该论文在两个方面修改了hyracks的实现。
关于map阶段的修改：创建了一个包含输入数据中块的队列，用一个标准的Java库决定队列的顺序。当hyraks执行map调度任务时，它会在队列的最前端分配一个当前块。Map任务的执行时间分为三部分：数据载入、数据计算、数据输出。
Reduce阶段：在reduce任务的shuffle阶段进行估计。在shuffle阶段，reduce任务时持续接收map的输出。Map任务的输出包括一个分配给reduce任务的数据文件和一个元数据文件（包含时间和位置信息）。如果map输出不包含给定reduce任务的组，那么将提供一个空数据文件和完整的元数据文件。元数据文件包括块标识符、调度块所需要的时间与映射任务执行相关的块位置、map任务的IP地址，开始时间和结束时间。最后，我们收集估计器在reduce任务上被调用的时间。当reduce任务收到一个map任务的输出时，它开始执行estimator。当评估器被调用时，所有data file 和meta file 被给出。这时候就得到评估结果啦。
实验
研究块随机的重要性；研究考虑检验悖论的重要性（处理时间和聚合价值的关系）