每日一博 | 谈谈大数据的文件存储

上一次我们谈到了各种类型的数据库，今天我们来谈谈在大数据，尤其是Hadoop栈下的数据和文件的存储。

我们知道为了解决大数据的存储和处理问题，google最先设计了推出了Map/Reduce的算法，而hadoop就是Google的map/reduce的开源实现。Hadoop主要由分布式的文件系统HDFS（参考Google的GFS）和Map/Reduce计算这两块。但随着Spark等更强大的计算引擎的出现，很少再有人使用Hadoop的Map/Reduce来做计算了，但是对于海量数据/文件的存储，除了HDFS，还真没有更多更好的选择。所以我们就来看看在Hadoop下，文件存储的各种选项。

原始文本文件

首先，我们什么都不需要做，HDFS提供分布式的文件存储，那么我们就直接把原始的文本文件存储在HDFS上就好了。通常我们会使用诸如txt，csv，json，xml等文本格式的文件存储在HDFS上，然后由各种计算引擎加载，计算。

HDFS是按照块来存储文件的，缺省的设置一个块的大小是64M，那么假定我的文本文件是1G，它会被分成16个分区，由计算引擎（Spark，Map/Reduce）来并行的处理，计算。

使用文本格式的主要问题是：

1. 占用空间大
2. 处理时有额外的序列化反序列化的开销，例如把日志中的文本‘12’转化为数字的12

所以这里就引入了两个解决方案：

1. 压缩。
   压缩是使用计算资源来换取存储/IO的资源。因为压缩后的体积小，存储和传输的效率就变高了，当然，压缩和解压缩都会消耗系统的计算资源。常见的压缩算法有：snappy，gzip，bzip，LZO，zlib等

   压缩方式	压缩效率	压缩速度	是否可分割
   Gzip	中高	中	否
   bzip2	高	慢	是
   Snappy	低	快	否
   LZO	低	快	是(但是要求建立索引)
   Zlib	低	快	是

2. 使用二进制的序列化格式
   使用二进制的序列化格式，本身就占存储空间比文本小，而且也有比较好的序列化和反序列化的支持。

支持压缩的SequenceFile

为了解决文本文件存储和传输效率不高的问题，Hadoop提供了SequenceFile格式， SequenceFile是Hadoop API 提供的一种二进制文件, 它将数据（Key/Value形式）序列化到文件中。这种二进制文件内部使用Hadoop 的标准的Writable 接口实现序列化和反序列化。 支持三种记录存储方式，无压缩，记录压缩和块压缩。SequenceFile只支持Java, SequenceFile一般用来作为小文件的容器使用, 防止小文件占用过多的NameNode内存空间来存储其在DataNode位置的元数据。

语言无关的序列化文件

SequenceFile虽然解决了本文文件的空间占用问题，但是它支持Java，而我们程序员都觉得PHP才是最好的语言，于是我们需要与语言无关的序列化文件格式。Facebook推出了thrift，用于实现跨语言提供服务和接口, 满足跨平台通信. 但是Thrift不支持分片, 且缺少MapReduce的原生支持。

 

Apache Arrow

Apache Arrow是用于内存数据的跨语言开发平台。它为平面和分层数据指定了一种与语言无关的标准化列式存储格式，该格式组织用于在现代硬件上进行有效的分析操作。它还提供计算库和零复制流式消息传递和进程间通信。当前支持的语言包括C，C ++，C＃，Go，Java，JavaScript，MATLAB，Python，R，Ruby和Rust。

简而言之，它促进了许多组件之间的通信，例如，使用Python Pandas 读取Parquet文件并转换为Spark数据框，Falcon Data Visualization或Cassandra，而无需担心转换。

CarbonData

 

Apache CarbonData是带有多维索引的列式数据格式，用于在大数据平台上进行快速分析。

CarbonData是华为开源，将使您能够使用单个副本访问整个数据。 查询处理中的挑战是我们有不同类型的查询：

• OLAP查询和详细查询。
• 大扫描查询和小扫描查询：您可能有需要比较大扫描的查询，也可能有在较小区域内扫描的查询。
• 点查询：消耗大表的很少部分。

因此，统一的文件格式使您可以拥有不同类型的查询（导致不同类型的数据访问）。

CarbonData文件格式是基于列式存储的，并存储在HDFS之上；其包含了现有列式存储文件格式的许多优点，比如：可分割、可压缩、支持复杂数据类型等。CarbonData为了解决前面提到的几点要求，加入了许多独特的特性，主要概括为以下四点：
（1）数据及索引：在有过滤的查询中，它可以显著地加速查询性能，减少I/O和CPU资源；CarbonData的索引由多级索引组成，计算引擎可以利用这些索引信息来减少调度和一些处理的开销；扫描数据的时候可以仅仅扫描更细粒度的单元（称为blocklet），而不再是扫描整个文件；
（2）可操作的编码数据：通过支持高效的压缩和全局编码模式，它可以直接在压缩或者编码的数据上查询，仅仅在需要返回结果的时候才进行转换，更好的查询下推；
（3）列组：支持列组，并且使用行格式进行存储，减少查询时行重建的开销；
（4）多种使用场景：顺序存取、随机访问、类OLAP交互式查询等。

一个CarbonData文件是由一系列被称为blocklet组成的，除了blocklet，还有许多其他的元信息，比如模式、偏移量以及索引信息等，这些元信息是存储在CarbonData文件中的footer里。
当在内存中建立索引的时候都需要读取footer里面的信息，因为可以利用这些信息优化后续所有的查询。

每个blocklet又是由许多Data Chunks组成。Data Chunks里面的数据可以按列或者行的形式存储；数据既可以是单独的一列也可以是多列。文件中所有blocklets都包含相同数量和类型的Data Chunks。CarbonData文件格式如下图所示。

每个Data Chunk又是由许多被称为Pages的单元组成。总共有三种类型的pages：
（1）Data Page：包含一列或者列组的编码数据；
（2）Row ID Page：包含行id的映射，在Data Page以反向索引的形式存储时会被使用；
（3）RLE Page：包含一些额外的元信息，只有在Data Page使用RLE编码的时候会被使用。

在一些给出的测试报告中，CarbonData的查询性能要优与Parquet和Orc （作为列村格式一起比较）。

CarbonData的问题是它对于Spark的依赖比较重。

Apache Kudu

Apache Kudu是一种数据存储技术，可以对快速数据进行快速分析。 Cloudera启动了该项目，但它是完全开源的。 Kudu提供快速插入和更新功能以及快速搜索功能，以加快分析速度。 它位于带有Parquet的HBase和Impala之间，试图消除快速扫描和快速随机访问之间的折衷。

我们直到列存储对于分析优化，而HBase之类的数据库是对随机访问优化，Kudu希望在这两者中取得折衷，当然折衷的结果也可能是两者都不是最优。

像传统的关系数据库模型一样，Kudu需要在表上使用主键。 表具有列和原始数据类型，并支持更新。 如果要将关系数据库迁移到Hadoop集群，维护更新/删除可能是一个挑战。 这是由于"数据库"工具直接位于HDFS之上。 由于HDFS是一次写入的架构，因此更新行可能会很困难，因为您必须通过重写基础数据来复制此功能。

它不使用HDFS。 但是，它可以与HDFS在同一群集上共存。 您可以在Kudu常见问题解答页面上找到做出此设计决定的多种原因。

每个表必须具有一个唯一的主键。 这充当索引，以允许快速访问更新和删除。 表由平板电脑组成，就像分区一样。 平板电脑可跨多个节点复制，以实现弹性。 数据以列形式存储。 这意味着由于每个列中的所有数据都按顺序存储，因此列式聚合更快。 这也意味着可以更轻松地对数据进行矢量化和压缩，因为每列的所有数据都是同一类型。

尽管Kudu位于HDFS之外，但它仍然是Hadoop集群上的"好公民"。 它可以与HDFS节点共享数据磁盘，并且占用的内存很少。 它还允许您透明地将Kudu表与Hadoop中其他位置（包括HBase表）存储的数据连接在一起。

总结

在你的大数据应用中，文件存储是不可少的部分，如何选择最适合的存储格式是很重要的。

1. 为了节省存储空间和I/O，你需要考虑支持压缩和二进制的序列化的格式，同时需要考虑是否有多语言和Schema的支持。这里Avro是不错的选择。
2. 为了更好的支持分析类的查询，使用列存储格式例如Parquet，Orc。你也可以选择CarbonData和Apache Kudu
3. Apache Arrow能有效的在计算系统之间交换数据

谢谢阅读，欢迎和我交流相关的话题。