SQL on Hadoop 的真相(1)

这是一组系列博文,目的是详尽介绍 SQL-on-Hadoop 。本系列的第一篇会介绍 Hadoop 系统的存储引擎和在线事务处理(简称 OLTP );第二篇将介绍在线分析处理(简称 OLAP );第三篇将介绍对 Hadoop 引擎的改进以及在相关替代产品中如何选型等话题。

SQL on Hadoop 是一个既令人兴奋又令人困扰的话题;

几乎每周都有一个新的 SQL on Hadoop 支持项目似乎抓住过社区注意力,哪怕只是一个短暂的瞬间;

在这个系列中,我们会讨论 Hadoop 系统上支持的每一类 SQL 解决方案,并对它们的架构,用例以及其他做出诚实的讨论。

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公司等。

1 收藏 评论

关于作者:王公仆

西电通信工程本硕;熟悉监控设备SDK和流媒体服务器;原MySQL/NTSE内核组开发人员,熟悉MySQL内核与架构以及运维调优;现杭州某公司数据架构师,参与分布式数据库相关开发;微博:<a href="//weibo.com/307721933”">@王公仆射<... 个人主页 · 我的文章 · 10

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部