Hadoop 系统的存储引擎和在线事务处理

Hadoop 引擎上的 SQL 有许多广泛的应用领域：

• 数据处理与在线分析处理（OLAP）
• 改进优化
• 在线事务处理（OLTP）

存储引擎:

今天 Hadoop 主要有三个存储引擎：分别是 Apache HBase、Apache Hadoop HDFS 和 Hadoop Accumulo。Apache Accumlo与 Hbase 非常相似，但它本是由 NSA 组织创建的项目，历史上特别看重系统的安全性，尤其在授权认证方面；在我们看来，HBase 现在已经将安全特性方面的工作加入到项目中了，这样的话后面就不再进一步讨论 Accumulo 了。

HBase 是一个分布式键值存储系统，数据是通过排好序的 map 形式存储，也就是说数据都是经过对 key 列排序的，就像我们下面要描述的那样，HBase 典型的用例是 OLTP 应用，HDFS 是一个文件系统并能够以分布式的方式存储极大容量的数据集合；

HBase 在 HDFS 里存储的数据是以 HFile 格式存入的，这种格式不可配置。当不使用 HBase 而直接使用 HDFS 时，用户是必须要选择一种文件格式；

当进行文件格式选择时是有许多要点需要考虑的，比如，

• 主要的读取模式是怎样的？是读取所有行呢，还是只读取所有行数据的一个子集；
• 数据是不是还可能含有非 ASCII 码的文本内容？
• 哪些工具会读写这些数据呢（Apache Hive,  Spark ?）；

广义上说有两种文件格式与 HDFS 一起使用，它们是 Columnar 和 row-wise。Columnar 格式例如 RCFILE、ORC 和 Apache Parquet等，这些类型能提供极致的压缩性能（通过类似行程编码的多种编码方式进行压缩），同时在只读取行内少量列的场景下，也能提供较高的读性能；比如你一行数据有五十到一百个列却只需读取七八个列的场合；

row-wise 格式，比如有受限定的文本格式、Sequence 文件格式以及 Apache Avro 格式，这些格式虽不提供有效的压缩特性，但比较适合那些需要读取表中大多数列的业务场景，也适合那种数据是以流的方式，每次小批量地导进表中的业务场景；

我们建议排除文本格式，RCfile 和 Sequence 文件这几种格式，因为他们都是历史遗留的文件格式，另外不推荐也是因为集成历史系统数据时它们有潜在的异常问题。我们不建议使用这些格式是因为他们容易发生文本冲突（如非 ASCII 码文本），性能差，还有除了文本方式之外很少有工具可以读取它们；

一旦我们回答了选 columnar 还是 row-wise 的问题，并排除了历史遗留的那些文件格式，最重要的问题就变成了哪一个工具和引擎能够读取和写入这些数据，大量的 Hadoop 生态链工具和引擎已经集成了 Avro 和 Parquet 项目，其中 ORC 是性能最好的 Apache Hive 文件格式。

在线事务处理

Apache HBase 项目提供 OLTP 类型的操作并极具扩展性，HBase 是唯一一个通常用于在线用户数据存储的Hadoop子模块，但是 HBase 项目的目标并不是做一个关系型数据库管理系统，而且它也不是为了替换 MySQL、Oracle 或者 DB2 这类关系型数据库的，实际上 HBase 自己并不提供任何 SQL 接口，而且用户还必须用 Java, Python, 或者 Ruby 编程来存储和检索数据；

Apache Phoenix 项目目标是基于 Apache HBase 提供 OLTP 类型的 SQL，Phoenix 允许用户基于 HBase 数据模型执行插入更新和删除操作，但是就像前面提到的一样，HBase 数据模型从根本上就不同于传统关系型数据库，这样的话 HBase 加 Phoenix 也仍然不是关系型数据库的替代者；

HBase （以及Phoenix） 项目对于那些基于 RDBMS 之上，在应用扩展过程中遇到麻烦的业务场景非常有用；传统关系型数据库领域里的一个传统解决方案是进行水平分区，但这种解决方案跑起来却常遭受以下缺陷的困扰：

• 跨分片事务没有得到支持
• 增加机器进行水平扩容时需要复杂且昂贵的再分片过程，

就像经过分片的数据库一样，HBase 并不支持事务，但增加机器进行水平扩展和在HBase内部做负载再均衡，HBase 系统就要容易得多；

新的节点可以被加入到 HBase 集群中，HBase 能够自动分配数据分片到不同节点，如果假定分片数据库和 HBase 都缺少事务支持的话，HBase 就会因提供易于增加机器水平扩展的能力而胜出，有一些公司已经在做底层使用 HBase 架构基础而上层增加事务 SQL 支持的产品，比如 Splice Machine公司等。