SQL on Hadoop最新进展2-转载

标签: 转载文章 | 发表时间:2013-10-23 12:06 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
原文:http://yanbohappy.sinaapp.com/?p=407

上篇主要讨论了Hive, Stinger/Tez, Impala, Shark这些SQL on Hadoop产品,这篇接着讨论Phoenix, Hadapt, Hawq。

Phoenix

Salesforce开源的基于HBase的SQL查询系统,建立在HBase client API, coprocessors, custom filter的基础之上。基本原理是将一个对于HBase client来说比较复杂的查询转换成一系列Region Scan,结合create table时hook的coprocessor和custom  filter在多台Region Server上进行并行查询, 汇总各个Scan结果输出给调用程序的ResultSet。说白了就是看大家用HBase client API开发程序太麻烦了,就弄了个JDBC包装,这样对于software engineer来说降低了开发成本,同时对于简单单表查询性能损失不大。
   
种种迹象表明,Phoenix应该不是个优化的OLAP系统,更像是一个用于简单单表查询,过滤,排序,检索的OLTP系统。

优点:

  • HBase默认存储的数据类型都是字符串,但Phoenix支持更多的数据类型(int, float, char, varchar, time, date)
  • 使用JDBC操作数据,而不是HBase client API
  • 在RegionServer端通过coprocessor过滤where条件,执行aggregation函数。Hive on HBase把SQL转化成MapReduce去查询HBase;Impala on HBase把SQL转化成PlanFragment执行计划去查询HBase; Phoenix把SQL转化成对HBase client API和coprocessor的调用,这三者的架构是相似的。不同点就是Hive on HBase和Impala on HBase都没有把coprocessor利用好,都是通过HBase client API把数据读到他们自己进程的内存之后才进行的filter, aggregation等操作。所以理论上讲前两种架构设计的产品性能不可能超过直接调用HBase Client的方式。
  • 从查询的角度来看HBase的column主要分为两类:primary key(row key column)和other columns。主要的不同是row key column能够利用HBase Region Server的index, filter, sort等特性,而other columns没有这些特性,只能通过二级索引辅助做一些优化。Phoenix能够在HBase上创建二级索引用于优化non row key columns的条件查询(目前只支持在static table上建二级索引,一个更通用的HBase二级索引实现方法可以参考华为开源的这个实现https://github.com/Huawei-Hadoop/hindex)。
  • salting of row keys to evenly distribute write load
  • 如果是row key column上的IN/OR/LIKE条件,可以通过Region Server的skip scan filter优化。
  • Dynamic columns支持(跟RDBMS的dynamic schema change类似),也就是用户不需要在create table的时候指定所有的column,后面什么时候需要随时添加。这个功能主要依赖于HBase的动态添加column的功能。
  • AutoCommit=false时(默认是false)把所有操作先缓存在客户端,只有你显示commit时才一次批量提交到HBase,SQL解析优化全是在客户端做,这个有点事务的意思。

缺点:

  • 不支持JOIN,考虑到HBase的设计初衷是尽量用冗余数据减少复杂的JOIN操作,实际上可以把相关数据都放在同一个表里,而不需要为了减少数据冗余,拆分到多个表中,所以很大程度也可以认为这不是一个缺点。
  • 从架构上看也仅是把SQL转成HBase Client的API和coprocessor的调用,而且coprocessor还不适合大规模数据的传输,所以如果中间结果的数据量还是比较大的话性能问题还是很明显的。
  • 这个缺点是所有的基于HBase的SQL系统都有的(包括Hive on HBase和Impala on HBase)。不管什么请求到HBase Region Server这边都得通过RegionScanner,这个接口不是面向OLAP型应用优化的存储文件读取接口。例如RegionScanner的实现里好多条件比较,是不利于全表扫描的。所以全表扫描的应用不如一个一个地读HFile,当然前提是得离线把memstore的数据都dump到hfile。目前coprocessor也是走的RegionScanner。这部分要想改得改Region Server代码了,那就是Apache HBase社区的事了。
  • 还有个问题就是coprocessor的问题了,由于coprocessor和HBase Region Server是在一个JVM里面,所以当coprocessor计算逻辑非常复杂,中间结果数据量很大的时候会占用大量内存。同时coprocessor不是流式地读取数据,某些节点数据积累过多也会造成内存不够用的问题。

RoadMap:

  • JOIN支持,虽然有点不符合设计初衷,但是大家都支持,就我不支持,太out of fashion了吧。
  • Transaction支持,通过参考https://github.com/yahoo/omid的方法。
  • Online Schema Evolution,动态改变column的类型,rename等。https://github.com/forcedotcom/phoenix/wiki

Hadapt/HadoopDB

http://hadapt.com/product/
http://db.cs.yale.edu/hadoopdb/hadoopdb.pdf

架构和Hive相似,底层存储引擎有两种:HDFS和RDBMS(PostgreSQL),一个DataNode节点上有一个RDBMS节点。提供两种接口:SQL和MapReduce,SQL也是解析成MapReduce job来执行的,所以总的来说执行引擎都是MR。
   
把多个MapReduce任务,转换成单node上的SQL+一个MR(data shuffle),这个跟水平压缩,垂直压缩类似,尽量减少SQL解析出的MR task个数,减少任务之间写HDFS的IO数据量。把一个SQL拆解成两部分:适合SQL做的用单机SQL,不适合的用MR(data shuffle)
   
和Hive的不同点在于Hive只能操控HDFS上的数据,而Hadapt可以操控HDFS和RDBMS两种数据来源。对于RDBMS这个数据源来说,数据被预先load到分布式的RDBMS节点中,有统一的Catalog管理所有RDBMS中的数据。例如Map中的有些执行逻辑直接通过一个在RDBMS上执行的SQL来获得(修改InputFormat),然后使用MapReduce来做JOIN/Group By。而且如果在数据被load到分布式PostgreSQL节点上时分布情况正好符合group by/order by的条件,那么还省得通过MapReduce的shuffle来做了。
   
Hadapt的本质还是把SQL解析成MR任务来做,不是MPP的思想,所以Hive具备的有些缺点(启动时间长,JOIN效率较低)它也是具有的。还有如果想要join/group by/order by能够在RDBMS数据源之间高效执行,还得考虑数据预分布的问题。
   
需要统一的元数据和数据一致性服务用于管理HDFS上的数据导入分布式PostgreSQL以及分区。
   
在执行多个Query的时候,后面的query能够利用前面query的查询结果(已经把前面Query的查询结果可以写到RDBMS中,有点类似于数据仓库中的物化视图的概念),从而可以提高查询的性能。
   
Combine structured and unstructured data in single query。现在很多公司为了统一计算平台,把放到RDBMS中的数据也放到HDFS上存一份,要不没法和HDFS中的非结构化数据做JOIN。在Hadapt这里用户通过一个Query可以操控两种数据,不用分两个步骤走了。
   
现在企业级应用大多使用的方案(ebay使用的是Hadoop+Teradata)是Hadoop+MPP/open source+commercial software的方式,即通过Hadoop批处理unstructured data(进行ETL操作)然后通过connector导入MPP进行structure data的query操作。但是这只是临时的替代方案,Hadapt说invisible loading(http://hadapt.com/blog/2012/09/05/invisible-loading-a-new-paradigm-for-loading-from-unstructured-to-structured-storage/ )才是最合理的,这样企业就有了一个unified analytic platform。但是用户把数据load到RDBMS之后就失去了在HDFS上存储的robust和scalable的特征,需要这个系统提供维护数据一致性相关的功能。

Hawq

a relational database that runs atop of HDFS (EMC发布Hadoop发行版Pivotal HD)

原来Greenplum Database中的存储是本地磁盘,现在改成HDFS,原来Greenplum Database的单节点的RDBMS只充当execution engine的功能,不再充当storage功能。
   
Query执行通过Greenplum Database的parallel execution engine(不再使用MR),每次查询开始把数据从HDFS中导入到Greenplum database,执行过程中通过内存交换数据而非MapReduce那样每次任务结束都写磁盘。
   
Hawq提供一个Universal Catalog Service管理分布在各个RDBMS节点的数据。

GP特有的cost-based parallel query optimizer and planner是它的一大优势,也是目前其他大多数的产品中没有的。它能够帮用户选出该SQL最高效的执行顺序。

使用Greenplum Database充当执行引擎的好处:标准SQL兼容(correlated sub query, window functions, rollups, cube, scalar and aggregate function);支持ACID事务;JDBC/ODBC支持;JOIN顺序优化和索引支持(查询优化器);支持row/column两种存储格式。

GPXF (Greenplum Extension Framework) 使得Hawq能够读取存储在HDFS上的任何格式的数据(delimited text, sequence files, protobuf and avro)以及存储在Cassandra, Mongodb, Isilon, Atom, MapR, Lustre, GPFS中的数据,无非就是多开发个读取接口。EMC是存储出身,肯定是希望这个analytic stack能够接入更多的存储产品,特别是他们卖的东西。
   
底层的HDFS需要支持trancate语义(https://issues.apache.org/jira/browse/HDFS-3107)和native C interface(不是JNI的,JNI的不适合大规模并行查询,所以应该hawq自己实现了一个基于C的RPC通信接口,与NameNode和DataNode直接通信)。所以说Hawq底层的HDFS跟Apache版本的到底有多大区别,我也不知道。

支持In-Database analytics ( http://madlib.net/ )

可以在Hawq内执行除了Query以外的分析任务,例如analytic functions(standard deviation, variance等)和off-the-shelf analytic package

支持数据挖掘算法:principal components analysis (PCA), enhanced support vector machines (SVM), linear models

性能相关:

Scott Yara(Greenplum老大) 公开承认hawq比pure Greenplum database要慢。这么做的目的无非就是更好的利用HDFS的可扩展性,统一存储管理。和其他sql on hadoop产品的性能对比方面,hawq在group by和join操作上与其他方案相比优势明显,前提是数据量不是特别大。(是不是因为数据导入的时候partition做的好呢,是不是拿load的时间换group by/join的时间呢?)

http://www.dataintoresults.com/2013/09/big-data-benchmark-impala-vs-hawq-vs-hive/

不过hawq和hadapt都说明了一个问题:就是unified analytic platform的重要性。

从商业产品来看,大数据分析产品主要有:

  • Teradata/Aster Data
  • EMC/Greenplum/Hawq
  • HP/Vertica 列存数据仓库
  • SAP/HANA 内存分析
  • Google/BigQuery 典型的Analysis as a Service
  • Amazon/Redshif 和AWS结合比较紧密

而传统软件厂商IBM, Oracle, Microsoft也都有产品,不过从技术的角度对后面这些公司的产品了解不多。

说完数据仓库相关产品,我们也顺便看看机器学习相关产品。机器学习不像SQL那么普遍,但是非常重要。我所知道的目前互联网公司做机器学习的系统是这样的:

(1) twitter基于pig做Machine Learning

http://www.umiacs.umd.edu/~jimmylin/publications/Lin_Kolcz_SIGMOD2012.pdf

    在Hadoop/MapReduce基础上,通过Pig扩展,使该平台具有机器学习处理能力
    特征抽取通过UDF实现
    单个学习单元的内部循环封装在Pig Storage Function中
    预测是根据学习训练的模型,结合UDF实现

(2) 不过目前互联网公司大多使用Hadoop做feature selection,然后对于不同的问题采用两种思路:

    采样数据,然后跑单机模型。因为很多机器学习算法是非常不容易并行化的,所以在全量数据的子集上面跑单机模型。基于MPI开发大规模并行的机器学习算法。

(3) Spark是个非常适合迭代型机器学习算法的计算模型和框架

     Ecosystem非常完备(Shark,BlinkDB,MLbase)。特别是基于Spark的机器学习算法库MLbase(http://www.cs.berkeley.edu/~ameet/mlbase.pdf)更是给机器学习算法大规模应用提供了帮助。

由于Mahout是MR上的machine learning库,但是底层的MR天然不适合密集迭代计算的机器学习算法,导致Mahout的应用并不是很广泛。但是Spark却是非常适合迭代机器学习算法,那么MLbase的重要性就非常明显了。目前Berkeley的教授们已经搞了一个公司叫databricks来做Spark/Shark的商业化,我是非常看好Spark的前途的。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [sql on hadoop] 推荐:

SQL on Hadoop最新进展-转载

- - 人月神话的BLOG
原文:http://yanbohappy.sinaapp.com/?p=381. 为什么非要把SQL放到Hadoop上. 那为什么非得基于Hadoop呢. 目前SQL on Hadoop产品主要有以下几种:Hive, Tez/Stinger, Impala, Shark/Spark, Phoenix, Hawq/Greenplum, HadoopDB, Citusdata等.

SQL on Hadoop最新进展2-转载

- - 人月神话的BLOG
原文:http://yanbohappy.sinaapp.com/?p=407. 上篇主要讨论了Hive, Stinger/Tez, Impala, Shark这些SQL on Hadoop产品,这篇接着讨论Phoenix, Hadapt, Hawq. Salesforce开源的基于HBase的SQL查询系统,建立在HBase client API, coprocessors, custom filter的基础之上.

Hadoop Hive sql语法详解5--HiveQL与SQL区别

- - SQL - 编程语言 - ITeye博客
1.hive内联支持什么格式. 3.hive中empty是否为null. 4.hive是否支持插入现有表或则分区中. 5.hive是否支持INSERT INTO 表 values(). 1、Hive不支持等值连接 . •SQL中对两表内联可以写成:. •分号是SQL语句结束标记,在HiveQL中也是,但是在HiveQL中,对分号的识别没有那么智慧,例如:.

Greenplum Pivotal HD结合了SQL和Hadoop的优势

- - InfoQ cn
EMC Greenplum宣布了一个新的Hadoop发行版本—— Pivotal HD,其中包含一个完全运行于HDFS之上的MPP数据库,兼容SQL,而且速度“比Hive快数百倍”. Pivotal HD支持标准Hadoop发型版本的常用特性(包括HDFS、Pig、Hive、Mahout和Map-Reduce等),但又加入了一些其他的组件,具体如下面结构图所示: .

盘点SQL on Hadoop中用到的主要技术

- - 奔跑的兔子
自hive出现之后,经过几年的发展,SQL on Hadoop相关的系统已经百花齐放,速度越来越快,功能也越来越齐全. 本文并不是要去比较所谓“交互式查询哪家强”,而是试图梳理出一个统一的视角,来看看各家系统有哪些技术上相通之处. 考虑到系统使用的广泛程度与成熟度,在具体举例时一般会拿Hive和Impala为例,当然在调研的过程中也会涉及到一些其他系统,如Spark SQL,Presto,TAJO等.

PL/SQL动态SQL(原创)

- - ITeye博客
使用动态SQL是在编写PL/SQL过程时经常使用的方法之一. 很多情况下,比如根据业务的需要,如果输入不同查询条件,则生成不同的执行SQL查询语句,对于这种情况需要使用动态SQL来完成. 再比如,对于分页的情况,对于不同的表,必定存在不同的字段,因此使用静态SQL则只能针对某几个特定的表来形成分页.

Derby SQL 分页

- - ITeye博客
    之前在网上看到有人问 Derby SQL 分页实现的问题,网上有人给出这样的解决方案,SQL 如下:. 其实,这样的分页查询,性能不理想,我试过在 300W 数据量中采用这种分页方式,需要 20~30秒之久;其实 Derby 10.6 以上版本有更好的分页支持,直接给出 SQL 实现如下:.

SQL Server--索引

- - CSDN博客推荐文章
         1,概念:  数据库索引是对数据表中一个或多个列的值进行排序的结构,就像一本书的目录一样,索引提供了在行中快速查询特定行的能力..             2.1优点:  1,大大加快搜索数据的速度,这是引入索引的主要原因..                             2,创建唯一性索引,保证数据库表中每一行数据的唯一性..

MySql动态SQL

- - SQL - 编程语言 - ITeye博客
13.7. 用于预处理语句的SQL语法. MySQL 5.1对服务器一方的预制语句提供支持. 如果您使用合适的客户端编程界面,则这种支持可以发挥在MySQL 4.1中实施的高效客户端/服务器二进制协议的优势. 候选界面包括MySQL C API客户端库(用于C程序)、MySQL Connector/J(用于Java程序)和MySQL Connector/NET.

sql优化

- - 数据库 - ITeye博客
是对数据库(数据)进行操作的惟一途径;. 消耗了70%~90%的数据库资源;独立于程序设计逻辑,相对于对程序源代码的优化,对SQL语句的优化在时间成本和风险上的代价都很低;. 可以有不同的写法;易学,难精通. 固定的SQL书写习惯,相同的查询尽量保持相同,存储过程的效率较高. 应该编写与其格式一致的语句,包括字母的大小写、标点符号、换行的位置等都要一致.