2.3 大数据存储技术

2.3.1 相关概念

1. 列存储

传统的关系型数据库行存储（Row Storage）的方式，存储的下一个对象是同条记录的下一个属性通常采用。传统的行存储数据排列方式如表2-1所示，传统的关系型数据库，如DB2、Oracle、Sybase、SQLServer、Greenplum、Netezza和Teradata等都采用行存储。

Vertica的公司进行了颠覆性的改变，把行转90°，变成列，用列存储的方式存储数据。列储数据排列方式如表2-2所示。

在列存储方式下，存储空间中的下一个对象就从同一条记录的下一个属性转变为下一条记录的同一属性。虽然这种旋转了90°的存储方式并没有减少数据量，但会带来以下好处：

（1）大数据应用往往需要批量访问列数据（当用户主要关心同一属性的统计特性时），这时列存储方式的优势就会体现出来，列存储方式对属性的访问比行存储方式快很多，据有关报道，它的读取速度比行存储方式要快50～100倍。

（2）有利于提高数据的压缩比，同类数据存储在一起有助于提高数据之间的相关性，从而有利于实施高效压缩算法（如行程压缩算法等）。

两种存储方式的数据都是从上至下、从左向右排列的。行是列的组合，行存储方式以一行记录为单位，列存储方式以列数据集合为单位，或称为列簇（Column Family）。行存储方式的读写过程是一致的，都是从第一列开始，到最后一列结束的。列存储方式的读取是列数据集中的一段或者全部数据，在写入时，一行记录被拆分为多列，每一列数据都追加到对应列的末尾。

但是，两种存储方式各自的特性都决定了它们都不可能是完美的解决方案。如果首要考虑的是数据的完整性和可靠性，那么行存储方式是不二的选择，列存储方式只有在增加磁盘并改进软件设计后才能接近这样的目标。如果以保存数据为主，则行存储方式的写入性能比列存储方式高很多。在需要频繁读取单列数据的应用中，列存储方式是最合适的。如果每次读取多列数据，则两个方案可酌情选择：采用行存储方式时，设计中应考虑减少或避免冗余列；采用列存储方式时，为保证读写效率，每列数据应尽可能分别保存在不同的磁盘上，多个线程并行读写各自的数据，这样就可避免磁盘竞用的同时提高读写效率。无论选择哪种存储方式，将相同属性的数据存放在一起都是必需的，可减少磁头在磁盘上的移动，提高数据的读写效率。

正是由于存储方式的转变，数据仓库产品的性能提升了50倍。表2-3给出了行存储方式与列存储方式的比较。

业界对两种存储方式有很多争执，争执的焦点是谁能够更有效地处理海量数据，且兼顾安全、可靠、完整性。列存储方式以列为单位来存储数据，适合对某一列进行随机查询处理。采用列存储方式的数据库系统具有高扩展性，即使数据增加也不会降低处理速度，因此，列存储方式主要适合需要处理大量数据的情况。

在已知的几种大数据处理软件中，Hadoop的HBase采用列存储方式；MongoDB采用文档型的行存储方式；Lexst采用二进制型的行存储方式。行存储方式不适合用在联机事务处理（OLTP）或更新操作，尤其是插入、删除操作比较频繁的场合。

2. Key-Value存储

Google在其分布式数据库技术产品BigTable中，为了存储Web页面，创造性地提出了Key-Value这种Map数据结构，并广泛应用到Google的多种应用中。

键值（Key-Value，KV）存储数据库是一种NoSQL（非关系型数据库）模型，其数据按照键值对的形式进行组织、索引和存储。KV存储数据库非常适合不涉及过多数据关系、业务关系的数据，同时能有效减少读写磁盘的次数，比SQL数据库存储拥有更好的读写性能。

这里以BigTable为例，介绍Key-Value数据结构。

BigTable采用Key-Value数据结构，Key由行关键字、列关键字、时间戳组成，Value为对应的数据内容。行关键字和列关键字都是字符串数据类型；时间戳是一个64位的长整数，可精确到毫秒。这三个属性在一个数据库中是唯一的。由Key和Value构成的Key-Value数据结构称为一个数据项。考虑到分布式数据库的多复本的特性，数据项会按照时间戳进行排序，并对于过期的数据项进行过期回收。BigTable中的Key-Value数据结构如图2-6所示。

Key-Value数据结构本质上就是一个映射，Key是查找数据地址的唯一关键字，而Value则是实际存储的内容。Key-Value数据结构使用哈希函数实现关键字到值的快速映射，这种数据结构可以提高数据的存储能力和并发读写能力，适合通过主键快速查询。

目前有很多用于大数据处理的免费KV存储数据库，例如Memcached、Redis。Redis是一个高性能的KV存储数据库，和Memcached类似，它支持存储的Value类型相对更多，包括String（字符串）、List（链表）、Set（集合）和Zset（有序集合）。与Memcached一样，为了保证效率，数据都在内存中缓存，区别的是Redis会周期性地把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现主从同步。Redis的出现，在很大程度上补偿了Memcached这类KV存储数据库的不足，在部分场合可以对关系型数据库起到很好的补充作用。Redis提供了Python、Ruby、Erlang、PHP客户端，使用很方便。

3. NoSQL（Not only SQL）数据库

随着NoSQL数据库的日益成熟，其在企业和组织信息管理系统中的应用已逐步深入。

NoSQL数据库泛指非关系型的数据库，其兴起的原因是传统的关系型数据库应对大规模、高并发数据的能力有限，NoSQL数据库能够弥补传统的关系型数据库在这方面的不足。相比于传统的关系型数据库，以云平台为基础的NoSQL数据库系统具有以下特点：

• NoSQL数据库去掉了传统的关系型数据库的关系特征，易于扩展；
• 由于NoSQL数据库结构简单，所以在大数据中的读写性能很好；
• NoSQL数据库可以随时存储自定义的数据格式；
• NoSQL数据库可以方便地实现高可用性的架构。

这些特点使得NoSQL数据库在金融行业具有较广泛的应用研究前景。金融行业主要包括两类系统需求：一类是以事务处理为主的高一致性的系统需求，如银行的核心信息系统；另一类是面向分析的系统需求，如反欺诈、反洗钱、客户关系管理系统等。NoSQL数据库在面向分析的系统中有一定的潜在技术优势。例如，在传统联机分析系统中，为了支撑对各种统计查询的高速响应，需要对各种属性组合进行预计算，这就需要对大量的中间计算结果进行存储，在属性量比较大和属性值比较多的情况下，所需的计算资源往往大大超过单机所具备的存储能力。为此，金融行业在构建联机分析系统时需要投入大量资源。

由于NoSQL数据库采用高度并行的系统和列存储方式的数据管理结构，其数据查询具有弹性查扩展的特点，在响应大规模聚集查询时相对于传统的关系型数据库具有较大的优势。随着NoSQL数据库的事务处理能力越来越强，其应用范围将越来越广。

常见的几类NoSQL数据库如下。

（1）KV存储数据库（如Memcached、Redis）。这类NoSQL数据库在互联网中应用范围最广。Memcached提供具备LRU淘汰策略的KV内存存储；而Redis提供支持复杂结构（如List、Hash等）的内存及持久化存储。Redis适用于数据变化快且数据库大小可预见（适合内存容量）的应用程序，如股票价格、数据分析、实时数据收集、实时通信。

（2）列存储型数据库（如HBase、Cassandra）。HBase是基于列存储方式的分布式数据库集群系统。由于列存储方式以列为单位来存储数据，适合对某一列进行随机查询处理。采用列存储方式的数据库具有高扩展性，即使数据增加也不会降低处理速度，因此，采用列存储方式的数据库主要适合应用于需要处理大量数据的情况。

HBase是Hadoop大数据应用生态系统中的重要一员，实现了对海量数据的随机实时读写访问。从逻辑上讲，HBase将数据按照表、行和列进行存储。HBase的主要目标是依靠横向扩展，通过不断增加廉价的商用服务器来增加计算和存储能力。HBase提供了命令行管理和丰富的API接口，通过调用这些接口，可以使用多种程序语言对HBase进行访问。

HBase适用于偏好BigTable，并且需要对大数据进行随机实时访问的场合，如Facebook的消息数据库。HBase是一个写快读慢的系统（当然，这里的慢是相对于写而言的）。对于读数据比较多的情况，可对HBase进行读优化，主要方法是增强系统的IO能力（HDFS层面）、增大BlockCache、调整主压缩（Major Compaction）策略等。若随机读较多，还可以减小BlockSize。

Cassandra也是基于列存储方式的开源分布式NoSQL数据库，它最初是由Facebook开发的，用于存储收件箱等简单格式数据，集Google BigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身。Facebook于2008年将Cassandra开源，Cassandra具有分布式、基于行的结构化及高伸展性特性。Cassandra本质上是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的写操作会被复制到其他节点上，对Cassandra的读操作也会被路由到某个节点上。对于一个Cassandra集群来说，扩展性能是比较简单的事情，在集群里面添加节点即可。Cassandra是一个混合型的非关系型数据库，类似于Google BigTable，是一个网络社交云计算方面理想的数据库。使用Cassandra可以像文档存储那样不必提前解决记录中的字段。Cassandra可以在系统运行时随意添加或移除字段，这是一个惊人的效率提升。Cassandra是纯粹意义上的水平扩展，为给集群添加更多容量，可以指向另一台计算机，不必重启任何进程即可改变应用查询或手动迁移数据；可以调整节点布局来避免某一个数据中心出问题，备用的数据中心至少有每条记录的完全复制；支持范围查询，采用列表数据结构，在混合模式可以将超级列添加到5维，对于每个用户的索引，这是非常方便的；采用分布式写操作，可以在任何地方任何时间读写数据，并且不会有任何单点失败。

（3）文档存储型数据库（如MongoDB、CouchDB）。文档存储数据库不需要定义表结构，存储格式多样化，适合存储非结构化的数据。它可以通过复杂的查询条件来获取数据，是非常容易使用的NoSQL数据库。CouchDB的最佳应用场景是：适用于数据变化较少，执行预定义查询，进行数据统计的应用程序；适用于需要支持数据版本的应用程序，如CRM和CMS系统。

MongoDB的最佳应用场景是：需要动态查询；需要使用索引而不是MapReduce功能；对数据库有性能要求；需要使用CouchDB，但因为数据改变太频繁而占满内存的应用程序。

4. 图存储数据库

图存储数据库是基于图理论构建的，使用节点、属性和边的概念。节点代表实体，属性用来保存与节点相关的信息，边用来表示实体之间的关系。图存储数据库在存储某些数据集时速度非常快，可以把图直接映射到面向对象的应用程序中。

在Web2.0时代，随着互联网及移动互联网的发展，NoSQL数据库在互联网行业中的重要性与日俱增。在大型互联网应用中，为应对大规模、高并发的数据访问，大多都引入了NoSQL数据库，其中Memcached、Redis以其高成熟度、高性能、高稳定性得到了广泛使用。例如，微博平台具备了千台规模的NoSQL数据库集群，微博核心的Feed业务、关系业务也都依赖Memcached及Redis提供高性能服务。

2.3.2 分布式存储系统

在当前数据呈爆炸式增长的形势下，单台计算机无论从存储还是从计算能力上都不能满足实际的需求。云计算的一大优势就是能够快速、高效地处理海量数据。为了保证数据的高可靠性，云计算通常采用分布式存储技术，将数据存储在不同的物理设备中。这种模式不仅摆脱了硬件设备的限制，同时扩展性变得更好，能够快速响应用户需求的变化。

分布式存储与传统的网络存储并不完全一样，传统的网络存储系统通过集中的存储服务器存放所有数据，存储服务器成为系统性能的瓶颈，不能满足大规模存储应用的需要。分布式存储系统采用可扩展的系统结构，利用多台存储服务器分担存储的负荷，利用位置服务器定位存储信息，它不但可提高系统的可靠性、可用性和存取效率，还易于扩展。在当前的云计算领域，Google的GFS和Hadoop的HDFS是比较流行的两种云计算分布式存储系统。下面以Hadoop的HDFS为例，对海量数据的分布式存储进行介绍。

1. HDFS

Hadoop的出现解决了传统的单机处理模式受内存、计算能力限制的问题，利用集群的存储和计算能力为海量数据提供可靠的存储和处理。

Hadoop是由Apache基金会开发的一个开源的分布式系统基础架构，提供了一系列数据并行处理工具和应用解决方案，并具有高度可伸缩性，可以根据数据规模和需求来动态地增加或删除节点。用户可以在不了解其底层细节的情况下，方便地在普通硬件上架设大规模的集群系统，开发分布式程序，从而充分地利用集群系统的能力进行高速运算和存储。

HDFS设计思路有以下几点。

（1）硬件异常是常态。在一个大数据环境下，HDFS集群由大量物理机器构成，每台机器由很多硬件组成，因为某一个硬件异常而使HDFS集群出错的概率是很高的，因此HDFS集群的一个核心设计目标就是能够快速检测硬件异常并快速从异常中恢复工作。

（2）访问流式数据。在HDFS集群上运行的应用要求访问流式数据，为适用于批处理而非交互式处理，因此在设计HDFS集群时更加强调高吞吐量而非低延迟。

（3）大数据集。在HDFS中，典型的文件大小是GB级甚至TB级的，因此HDFS设计的重点是支持大文件，并且可以通过扩展物理机器的数量来支持更大的集群。

（4）简单的一致性模型。HDFS提供的访问模型是一次写入多次读取的模型。文件在完成写入操作后就不需要再修改了，采用这种简单的一致性模型，可以支持更高的吞吐量，以及文件追加。

（5）移动计算比移动数据的代价更低。HDFS利用了计算机系统的数据本地化原理，认为数据离CPU越近，性能更高。HDFS提供的接口可以让应用感知到数据的物理存储位置。

（6）异构软硬件平台兼容。HDFS集群应该被设计成能够方便地从一个平台迁移到另外一个平台。

按如上思路设计的HDFS是可扩展的分布式文件系统，适用于大型的、分布式的、对大量数据进行访问的场景。Hadoop运行于廉价的普通硬件上，具有高容错性与高吞吐量。大部分ICT厂商，包括Yahoo、Intel的云计划采用的都是Hadoop平台的HDFS数据存储技术。

如图2-7所示，HDFS集群由一个Master（NameNode）和多个Slave（DataNode）组成。

在HDFS内部，一个文件中的数据是按照某种固定大小（如128 MB）的块（Block）来存储的，每个块可以按照用户指定的副本量存储在不同的机器上。NameNode维护系统的命名空间，包括文件到块的映射关系、访问日志等属性，以及元数据都存储在NameNode中。文件的基础信息存储在NameNode中，采用集中式存储方案。NameNode定期通过心跳消息与每一个DataNode通信，给DataNode发送指令并收集其状态。在HDFS集群中只能有一个NameNode，但是可以设置一个备份的Secondory NameNode来保证系统的可靠性、容错性。

DataNode提供文件内容的存储、操作功能。文件数据块本身存储在不同的DataNode中，DataNode可以分布在不同机架上。DataNode定期与NameNode通信，给NameNode发送状态并接收NameNode发送的指令。DataNode启动之后会扫描本地文件系统中块的个数，并将对应的块信息发送给NameNode。

虽然HDFS集群采用主从结构，但客户端可以分别访问NameNode和DataNode，以获取文件的元数据及内容。HDFS集群的客户端可直接访问NameNode和DataNode，相关数据直接从NameNode或者DataNode传送到客户端。

综合上述的设计假设和架构分析，HDFS特别适合以下场景：

（1）要求顺序访问的场景，如提供流媒体服务等大文件存储。

（2）要求大文件全量访问的场景，如要求对海量数据进行全量访问、OLAP等。

（3）整体预算有限的场景，想利用分布式计算的便利，但又不打算购买昂贵的HPC（高性能计算机群）、高性能小型机等。

但是，HDFS在如下场景中的性能还是不尽如人意。

（1）要求低延迟数据访问的场景。低延迟数据访问意味着要求快速定位数据，如10 ms级的响应，系统若忙于响应此类要求，则有悖于快速返回大量数据的假设。

（2）存在大量小文件的场景。大量小文件将占用大量的块，不仅会造成较大的浪费，对NameNode也是严峻的挑战。Hadoop适用于较大的文件，原因在于Map任务每次会处理一个输入的小文件（FileInputFormat通常是被分割的文件）。如果文件太小（这里指的是小于HDFS的块大小），并且有很多这样的小文件，那么就会增加打开文件的性能开销；同时，大量的小文件也会增加NameNode元数据的存储开销。

（3）多用户进行并发写入的场景。并发写入违背数据一致性模型，数据可能会出现不一致。

（4）要求实时更新的场景。HDFS支持文件追加（Append），但实时更新会降低数据吞吐量，以及增加维护数据一致的模型代价。

2. 分布式内存文件存储

“内存为王”这句话现在很流行，大数据处理对速度的追求是无止境的。由于内存的速度和磁盘的速度不是一个数量级，同时，内存的价格越来越低、内存的容量越来越大，这就使得数据存储在内存中有了可行性。伴随着这种趋势，大量的基于内存的计算框架也研制出来了，如Spark，就是优秀的基于内存的计算框架。但是，现有的计算框架还面临一些挑战。Tachyon的出现解决了内存中的垃圾回收（Garbage Collection，GC）开销大、缓存数据丢失等问题。

Tachyon是一个分布式内存文件系统，可以在集群里以访问内存的速度来访问存储在Tachyon里的文件。Tachyon是安装在底层的分布式文件存储和上层的各种计算框架之间的一种中间件，主要职责是将那些不需要存储到HDFS中的文件存储到分布式内存文件系统中，以此实现共享内存，从而大幅提高访问效率。Tachyon可以在不同的计算框架内共享内存，同时可以减少内存冗余和基于JVM（Java虚拟机）内存计算框架的GC时间。

Tachyon采用传统的主从结构，和Hadoop类似。在Tachyon中，Master里的WorkflowManager是Master进程，为了防止单点问题，可以部署多台Standby Master（备用主机）。Slave是由Worker Daemon（工作守护进程）和Ramdisk（内存盘）构成的，Worker Daemon是基于JVM的，Ramdisk是一个Off Heap Memory（堆外内存）。Master和Worker之间的通信协议是Thrift。

图2-8所示为Tachyon的应用模式。

Tachyon也有类似RDD（Resilient Distributed Dataset，弹性分布式数据集）的血统概念，输入文件和输出文件都会有血统关系，从而达到容错的目的。同时，Tachyon也利用血统关系来异步实现检查点的操作。在文件丢失的情况下，可利用两种资源分配策略来优先计算丢失掉的资源。

2.3.3 数据库（HBase）与数据仓库（Hive）

1. HBase

HBase（Hadoop Database）是一个高可靠、高性能、基于列存储方式、可伸缩的分布式存储系统，利用HBase技术可在廉价计算机上搭建起大规模的结构化存储集群。

HBase适合存储大表数据（表的规模可以达到数十亿行和数百万列），对大表数据的读写可以达到实时级别。HBase采用HDFS作为文件存储系统。在典型的大数据系统中，利用Spark和Hadoop的MapReduce来处理HBase中的海量数据，利用ZooKeeper作为协同服务。HBase集群由主备Master进程和多个RegionServer进程组成。HBase集群的系统结构如图2-9所示。

表2-4列出了HBase集群中各组件的功能说明。

（1）HBase的查询过程。在HDFS中，HBase上的数据是以HFlie二进制的形式存储在Block中的，所以对于HDFS来说，HBase是完全透明的。HBase的数据访问流程如图2-10所示。

HBase的响应速度快是因为其特殊的存储模型和访问机制，HBase中有两张表：Meta表和Root表，Meta表记录了用户的Region信息，包含了多个Region及其所在的RegionServer服务器地址，Root表则记录了Meta表的Region信息。因此，Root只有一个Region。图2-10中，客户端可以快速定位到要查找的数据所在的Region Server。当要对HBase进行增删改查等数据操作时，HBase的客户端首先访问分布式协调服务器ZooKeeper，通过ZooKeeper可以访问Root表的地址，因为Root表里面记录了Meta表的地址，通过Meta表就可以找到数据所在的位置，并将数据操作命令发送给RegionServer，该RegionServer接收并执行该命令从而完成本次数据操作。

（2）基于HBase的二级索引机制。HBase具有扩展性强、实时查询效率高等特点，在大数据实时处理中应用十分广泛。但是，因为HBase的Key-Value存储特性，所以只支持少量的SQL查询操作，不支持二级索引。对于非主键的查询，只能通过全表扫描和过滤的方式获取数据，效率非常低，使得HBase存在很大的局限性。即使通过Hive、Pig等组件对全表进行MapReduce计算，依然会占用大量的资源，也会大大增加延迟。

如果在HBase存储的基础上对表中一列的Value进行索引，而主键RowKey作为该索引的值，则通过对Value的索引可快速定位到符合要求的RowKey，再通过RowKey进行二次查找即可将结果数据取出来。虽然这种方式会损失部分查询效率，但能保证实时性，而且可以极大地提高查询的便捷性，这就是HBase二次索引机制的基本思想。

（3）ITHBase拓展项目。ITHBase（Indexed Transactional HBase）是在HBase 0.19.3版本中的第三方带索引的独立拓展项目。在HBase写入数据时，如果MemStore写满后发出写磁盘的请求，则ITHBase会拦截请求并为MemStore中的数据创建索引，索引会在表中以列簇（Column Family，CF）的形式存在，而且ITHBase只支持Region级别的操作。当ITHBase读取数据时，会通过表中的索引列来加速扫描数据。

ITHBase对HBase的源码进行了修改拓展，并在其基础上重新设计了HBase中的RegionServer模块，而Client只负责处理逻辑。HBase版本更新迅速，但ITHBase的源码几年未更新，是否具有工业强度的稳定性成为用户选择它的主要障碍。

（4）Phoenix项目。Phoenix起源于Saleforce社区的一个开源项目，后来发展成为Apache的顶级项目。Phoenix是为了解决HBase SQL查询有限、不支持二级索引等问题开发的一个Java中间层，并提供可嵌入的JDBC（Java Database Connectivity）驱动供客户端使用。通过发送JDBC请求给HBase，Phoenix自定义的HBase协处理器将查询语言转化为多个HBase扫描操作和服务器端过滤，Phoenix带来了更快的开发效率。

Phoenix会将一个聚合查询分成多个扫描操作，然后将扫描操作分配给Phoenix自定义的HBase协处理器，进行扫描操作并执行生成JDBC标准的查询结果。这些协处理器可以在服务器中并行工作，从而提高查询性能。平衡地拆分表是Phoenix能否获得高效查询的最重要因素之一，例如，将相等大小的分区平均分配到不同的RegionServer上，表中的数据在各个RegionServer上均匀分布可以保证每一个Phoenix线程处理的数据量相当，这样就可以减少查询的等待时间。

Phoenix对于大数据集的查询可以达到毫秒级性能。当查询条件同时存在RowKey主键索引和二级索引时，会自动选择最优的索引。Phoenix维护一个系统表（System Table）作为Scheme元数据的存储，支持对多列进行动态索引的创建、删除和修改，并且不限制列数。当索引可变时，列数越多，写入速度受影响就越大；当索引不可变时，不影响写入速度，且Phoenix提供了对RowKey分析的特性，可以让数据均匀分布在各个RegionServer上。Phoenix还具备其他值得关注的特性，例如，通过客户端（Client）批处理可支持有限的事务、支持版本化的模式仓库、优化扫描等。目前，Phoenix对HBase的支撑比较完善，包括索引更新、增量识别等功能。

2. Hive

Hive是基于HDFS和MapReduce架构的数据仓库，提供了类似SQL的HiveQL语言来操作结构化数据，其基本原理是将HiveQL语言自动转换成MapReduce任务，从而对Hadoop集群中存储的海量数据进行查询和分析。图2-11所示为Hive的系统架构。

Hive支持海量结构化数据分析汇总，可将复杂的MapReduce任务简化为SQL语句，具有灵活的数据存储格式，支持JSON、CSV、TEXTFILE、RCFILE、SEQUENCEFILE几种存储格式。

Hive采用HDFS作为文件存储系统。Hive数据库中的所有数据文件都可以存储在HDFS中，Hive所有的数据操作也都是通过HDFS的接口进行的。

Hive所有的数据计算都依赖于MapReduce。在进行数据分析时，Hive会将用户提交的HiveQL语句解析成相应的MapReduce任务并提交给MapReduce执行。

Hive的MetaStore可用来处理Hive的数据库、表、分区等结构和属性信息，这些信息需要存放在一个关系型数据库（如MySQL）中，从而对MetaStore进行维护和处理。表2-5给出了Hive中各个组件的说明。

Hive提供了一系列的工具，可以用来进行数据提取、转化、加载（Extraction Transformation Loading，ETL），这是一种可以存储、查询和分析存储在Hadoop中大规模数据的机制。Hive也允许熟悉MapReduce的开发者实现自定义的Mapper和Reducer来处理内建Mapper和Reducer无法完成的复杂分析工作。

Hive将所有的数据都存储在Hadoop兼容的文件系统（如Amazon S3、HDFS）中。在加载数据过程中，Hive不会对数据进行任何修改，只是将数据移动到HDFS中Hive设定的目录下，因此，Hive不支持对数据的改写和添加，所有的数据都是在加载时确定的。Hive的设计特点如下：

• 支持索引，可加快数据查询；
• 支持不同的存储类型，如纯文本文件、HBase中的文件；
• 可将元数据保存在关系型数据库中，大大减少了在查询过程中执行语义检查的时间；
• 可以直接使用存储在HDFS中的数据；
• 内置大量用户函数（UDF）来操作时间、字符串和其他的数据挖掘工具，支持用户扩展UDF函数来完成内置函数无法实现的操作；
• 类似于SQL的查询方式，将SQL查询转换为MapReduce任务后在Hadoop集群上执行，Hive与SQL相似促使其成为Hadoop与其他BI工具结合的理想交集。

由于Hive构建在基于静态批处理的Hadoop上，Hadoop通常都有较高的延迟，并且在作业提交和调度时需要大量的开销，因此，Hive并不能够在大规模数据集上实现低延迟、快速的查询。例如，Hive在几百兆字节的数据集上执行查询一般有分钟级的延迟，因此，Hive并不适合那些需要低延迟的应用，如联机事务处理（OLTP）。Hive查询操作过程严格遵守MapReduce的模型，Hive将用户的HiveQL语句转换为MapReduce任务并提交到Hadoop集群上，Hadoop集群监控作业的执行过程，然后返回执行结果给用户。Hive并不是为联机事务处理而设计的，Hive不提供实时的查询和基于行级的数据更新操作。Hive的最佳使用场合是大数据集的批处理作业，如网络日志分析。

根据业务系统和大数据系统的功能划分，大数据系统的存储系统至少要支持三种存储方式：一是行存储方式，用于数据由传统数据库向大数据系统数据库过渡；二是基于键值对的存储方式，用于大体量、高并发数据的实时查询；三是分布式内存存储方式，用于对交互式数据进行分析和挖掘，可通过构建分布式Cube加速性能，也可部分使用固态硬盘（Solid State Disk，SSD）替代，程序自动选择存储层。