来源
CIKM 2012
CCF B类会议
总结：相当于设计了自己的存储格式，设计了三层索引以及时空数据，利用Mapreduce 构建HDFS块和更新索引，并且周期性在后台更新自己的块设计，减轻出现小数据的影响
Abstract
面对时空数据，主要是避免在提供数据服务时检索全部的数据库
设计了一个紧凑的存储结构
提出了一个可扩展的批量加载算法，增量的新数据添加到系统中
Introduction
主要针对的还是 taxi数据
根据我们对数据查询工作负载的分析，我们发现几乎所有查询都有位置和时间的范围谓词，我们将其称为时空范围查询（spatio-temporal range queries），或简称为范围查询。
我们发现大多数范围查询要么仅限于一辆出租车，要么与所有出租车相关。因此，我们分别将这些查询称为单对象查询和全对象查询。(查询出了时空特性之外，还有各个用户的ID属性)
Hadoop 和Hbase 不支持有效的多维范围扫描。
在本文中，设计了Clost，主要贡献
- 我们提出了一种新的数据模型，能够优化时空属性的系统实现；但它足够简单，可以应用于非常大的数据集。据我们所知，CloST 是第一个使用此数据模型的系统。
- 我们描述了一种三级分层分区方法，以便能够高效并行处理具有任何可能范围的所有对象查询，即数据分区的有效性不依赖于空间谓词是否比时间谓词更具选择性，反之亦然。
- 我们描述了一种节省空间的文件格式，用于在 HDFS 上实际存储数据。在这种文件中，来自同一对象的记录被分组在一起，然后按列存储。数据分别在列级和组级压缩两次。与文本格式的原始数据文件相比，CloST 可以将存储大小减少一个数量级。
- 我们描述了使用 MapReduce 执行全对象查询、初始数据加载和增量数据加载的并行算法。实验结果表明，这些算法在处理非常大的数据集时具有可扩展性和效率
2. Hadoop Background
简单介绍了一下Mapreduce 和 Hadoop的基本概念
3. The Design AND Implementation of Clost
Clost 由Hadoop构建，同时添加了一部分组件来管理他们，包括：
- metadata mananger
- data loader
- storage optimizer
- Query processor
[外链图片转存中…(img-PNDIDWlC-1720510295546)]
3.1 Data model
为了支持时空范围查询，在CloST中使用新数据模型
该数据模型针对的是与 GPS 日志数据具有相似特征的超大时空数据集。
它将时空数据存储在表中。表的模式形式为 (Oid、Loc、Time、A1、…、An)。
前三个属性称为核心属性，其中 Oid 是对象 ID，Loc 是空间点，Time 是时间戳。CloST 数据模型最重要的特征是核心属性是强制性的，并且是任何表的预定义属性。因此，基于此数据模型的存储系统可以特别针对核心属性进行优化。与核心属性相反，A1 到 An 由用户定义，称为公共属性。
3.2 Storage Structures
下面介绍 CloST 中数据如何分区、存储和索引。我们要求存储结构能够处理单对象查询和全对象查询。为了清楚起见，我们分别使用 Q(I, S, T) 和 Q(S, T) 表示单对象查询和全对象查询**，其中 S 表示空间范围**，T 表示时间范围，I 表示对象 ID
3.2.1 Hierarchical Partitioning
为了能够高效处理 Q1 和 Q2，CloST 使用所有核心属性对数据进行分层分区。如图 2 所示，首先根据 Oid 的哈希值和时间的粗略范围将数据划分为多个 1 级分区。然后，根据 Loc 上的空间索引将每个 1 级分区划分为多个 2 级分区（三级索引，第一级索引根据Oid对不同的出租车司机进行分类，第二级对空间区域进行分类，第三级则对区域中的不同时间来索引）。最后，根据更精细的时间范围将每个 2 级分区进一步划分为一系列 3 级分区。3 级分区包含实际记录，更高级别的分区用作 3 级分区的索引。所有记录和索引都作为常规文件存储在 HDFS 上。==在下文中，我们将 1 级分区称为存储桶，2 级分区称为区域，3 级分区称为块，==相应的文件称为块文件。
1 级分区将非常大的数据集粗略地分成相对较小的存储桶。因此，每个存储桶可以独立执行查询处理、数据加载和存储优化。**此外，在并行处理的背景下，桶的数量是回答全对象查询时的最小并行度。**因此，即使范围很小，我们也总是可以并行化全对象查询。二级和三级分区的本质是先进行空间分区，然后进行时间分区。我们使用四叉树将桶划分为区域，然后使用一维范围分区将区域划分为块。
3.2.2 Block File Layout
受 RCFile [6] 启发，我们设计了一种高效紧凑的存储布局来实际存储记录。图 3 显示了块文件内部结构的示例。我们按 Oid 对记录进行分组，并将每组存储在文件部分中。块内索引位于文件开头，用于将 Oid 映射到相应的部分位置。对于每个部分，记录首先按时间排序，然后以列存储方式组织，即连续存储来自同一属性的值。为了节省空间，我们不将 Oid 存储在部分中，因为我们可以从块内索引推断出它。
图中一个Oid，这一行存储多个Time，多个Loc位置，存储多个A1，A2，紧邻存储
（有效压缩行数据）
为了提高存储效率，CloST 首先在列级压缩数据，然后在部分级压缩数据。对于列级压缩，数值通过增量编码或运行长度编码进行编码 [3]。当值随时间缓慢变化或保持稳定时，它们可以显著减少存储大小，这在许多时空数据集中很常见。对于非数字值（例如字符串），我们只需使用 gzip（GNU zip）库进行通用压缩即可。在列级压缩之后，部分内的所有数据都会再次使用 gzip 进行压缩，以进一步减少数据大小。实验结果表明，我们的两级压缩方案可以将存储大小减少一个数量级
3.3 Metadata Management
表的元数据包括通用属性的定义、压缩方案、从存储桶到区域以及从区域到块的映射等。CloST 将表元数据与数据存储在 HDFS 上以表名命名的同一目录中。
这意味着元数据存储会自动复制和分发。与使用集中式元数据存储相比，使用 HDFS 有两个主要好处。首先，查询处理器直接从 HDFS 读取元数据，因此它不依赖于元数据管理器的运行实例。其次，元数据访问不太可能成为并发查询处理的瓶颈。许多单对象查询和几个全对象查询同时发出是很常见的。幸运的是，对元数据的密集访问分散到了实际存储元数据文件的 HDFS 数据节点。此外，当系统因并发读取元数据而超载时，我们可以轻松增加元数据文件的复制级别
3.4 Query Processing
对于单对象查询 Q(I, S, T)，CloST 使用表元数据和块内索引来定位记录。我们首先根据一级分区参数找出关于 I 和 T 的桶。然后，我们根据二级分区索引在上述桶中找出与 S 相交的区域。在这些区域中，我们进一步根据三级分区索引找出时间范围与 T 相交的块。对于涉及的每个块文件，我们读取块内索引，获取与 I 对应的节位置，查找该位置并将整个节读入内存。
我们在解压节数据后组装所有记录，并使用 S 和 T 执行最后的过滤。对于对象查询 Q(S, T)，CloST 利用 MapReduce 并行执行查询。首先，我们找出时空范围与 S 和 T 相交的所有块文件。接下来，我们为每个涉及的块文件启动一个 map 任务。每个map任务依次扫描对应的block文件，解压数据并组装记录，然后根据S和T对每条记录进行过滤，最后输出结果。
3.5 Data Loading
CloST 数据加载器是针对分析应用中的典型场景而设计的：已经存在大量数据，并且定期添加更多数据
3.5.1 Initial Data Loading
初始数据加载由 n + 1 个 MapReduce 作业执行，其中 n 是存储桶的数量。第一个作业将记录划分到存储桶中，并为每个存储桶生成索引。接下来的每个作业将存储桶的记录划分为区域，然后划分块（block，对应Hadoop的Block）并最终创建块文件。
具体来说，第一个作业的 map 函数为从原始数据中提取的每个记录发出对 hbucket_id、recordi，其中 bucket_id 是根据表架构中指定的一级分区策略计算的。
在 Reduce 阶段，记录按 bucket_id 分组，Reduce 函数将一组的所有记录写入单独的输出文件。同时，它在内存中维护一个组的样本，以启发式地创建用于对存储桶进行分区的索引。索引在空间和时间维度上创建大致均匀的分区，因为此时没有查询日志来指示优化的分区。对于每个存储桶，我们执行 MapReduce 作业来创建最终的块文件。
（在执行Mapreduce的过程中，实现了索引的构建（n+1中的1），以及相关的块构建（n+1中的n））
map 函数为存储桶中的每条记录发出对 hblock_id、recordi。按key分组后，reduce函数接收属于同一个block的所有记录，然后以CloST block文件格式写入HDFS，数据加载过程通过通知元数据管理器将block文件和索引文件移动到表目录（table directory）中完成。
3.5.2 Incremental Data Loading
（首先一个点是，Hadoop块不能支持追加操作）
在初始数据加载之后，CloST 在新数据到达时执行增量数据加载。我们首先执行 MapReduce 作业，使用现有索引将新记录划分为块。这些块称为增量块。然后，另一个 MapReduce 作业将增量块与当前块合并。具体而言，==如果增量块文件与现有块共享相同的时空范围，则将增量块文件与现有块文件合并。最后，元数据管理器用合并后的块文件替换当前块文件（本质还是构建一个新块）==并直接添加未与现有块文件合并的增量块文件。**具体而言，与大时空数据相关的一个常见假设是数据按时间顺序到达。在此假设下，增量块不能与任何现有块共享相同的时空范围。**在这种情况下，我们的增量数据加载机制非常高效，因为完全消除了合并块的成本。实验结果表明，CloST 的增量数据加载速度比对比系统快 20 倍。
3.6 Storage Optimizaiton
（周期性移动块存储）
为了优化块文件的大小，CloST 将最近的查询保存到每个表中，并根据查询日志定期调整空间和时间分区。对于每个块文件 b，存储优化器计算利用率 (b)，该利用率定义为块 b 中对查询结果有贡献的记录的平均比例。如果 (b) 小于阈值且块文件的大小大于最小大小的两倍，则存储优化器将通过分割其时间范围来分割块文件或对包含块文件的区域进行空间重新分区。
另一个问题是，如果只加载少量数据，增量数据加载可能会导致大量的小块文件。为了解决这个问题，存储优化器会在每次增量数据加载后自动执行以合并小块文件。（周期性合并）