SQL on Hadoop系统的最新进展

转自:http://yanbohappy.sinaapp.com/?p=381


为什么非要把SQL放到Hadoop上? SQL易于使用。
那为什么非得基于Hadoop呢?the robust and scalable architecture of Hadoop

目前SQL on Hadoop产品主要有以下几种:
Hive, Tez/Stinger, Impala, Shark/Spark, Phoenix, Hawq/Greenplum, HadoopDB, Citusdata等。本文主要讨论Hive, Tez/Stinger, Impala, Shark以及传统开源数据仓库brighthouse的特点和最新进展;下一篇文章会讨论Phoenix, Hadapt/HadoopDB, Hawq/Greenplum。

在互联网企业中一般的基于Hadoop的数据仓库的数据来源主要有以下几个:
1,通过Flume/Scribe/Chukwa这样的日志收集和分析系统把来自Apache/nginx等Server cluster的日志收集到HDFS上,然后通过Hive创建Table时指定SerDe把非结构化的日志数据转化成结构化数据。
2,通过Sqoop这样的工具把用户和业务维度数据(一般存储在Oracle/MySQL中)定期导入Hive,那么OLTP数据就有了一个用于OLAP的副本了。
3,通过ETL工具从其他外部DW数据源里导入的数据。

目前所有的SQL on Hadoop产品其实都是在某个或者某些特定领域内适合的,没有silver bullet。像当年Oracle/Teradata这样的满足几乎所有企业级应用的产品在现阶段是不现实的。所以每一种SQL on Hadoop产品都在尽量满足某一类应用的特征。
典型需求:
1,  interactive query (ms~3min)
2,data analyst, reporting query (3min~20min)
3,data mining, modeling and large ETL (20 min ~ hr ~ day)
4,机器学习需求(通过MapReduce/MPI/Spark等计算模型来满足)

Hive
Hive是目前互联网企业中处理大数据、构建数据仓库最常用的解决方案,甚至在很多公司部署了Hadoop集群不是为了跑原生MapReduce程序,而全用来跑Hive SQL的查询任务。

对于有很多data scientist和analyst的公司,会有很多相同table的查询需求。那么显然每个人都从hive中查数据速度既慢又浪费资源。我们在online的数据库系统部署的时候都会在DB前面部署Redis或者memcache用于缓存用户经常访问的数据。那么OLAP应用也可以参考类似的方法,把经常访问的数据放到内存组成的集群中供用户查询。
Facebook针对这一需求开发了Presto,一个把热数据放到内存中供SQL查询的系统。这个设计思路跟Impala和Stinger非常类似了。使用Presto进行简单查询只需要几百毫秒,即使是非常复杂的查询,也只需数分钟即可完成,它在内存中运行,并且不会向磁盘写入。Facebook有超过850名工程师每天用它来扫描超过320TB的数据,满足了80%的ad-hoc查询需求。

目前Hive的主要缺点:
1,data shuffle时网络瓶颈,Reduce要等Map结束才能开始,不能高效利用网络带宽
2,一般一个SQL都会解析成多个MR job,Hadoop每次Job输出都直接写HDFS,性能差
3,每次执行Job都要启动Task,花费很多时间,无法做到实时
4,由于把SQL转化成MapReduce job时,map,shuffle和reduce所负责执行的SQL功能不同。那么就有Map->MapReduce或者MapReduce->Reduce这样的需求。这样可以降低写HDFS的次数,从而提高性能。

目前Hive主要的改进(主要是体现在 hive 0.11版本上):

1,同一条hive sql解析出的多个MR任务的合并。
由Hive解析出来的MR jobs中有非常多的Map->MapReduce类型的job,可以考虑把这个过程合并成一个MRjob。https://issues.apache.org/jira/browse/HIVE-3952

2,Hive query optimizer(查询优化器是Hive需要持续不断优化的一个topic)

http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/optimize-joins.html

  • Joins where one side fits in memory
  • Star schema join的改进,就是原来一个大表和多个小表在不同column匹配的条件下join需要解析成多个map join + MR job,现在可以合并成一个MR job

这个改进方向要做的就是用户不用给太多的hint,hive可以自己根据表的大小、行数等,自动选择最快的join的方法(小表能装进内存的话就用map join,Map join能和其他MR job合并的就合并)。这个思路跟cost-based query optimizer有点类似了,用户写出来的SQL在翻译成执行计划之前要计算那种执行方式效率更高。

3,ORCFile
ORCFile是一种列式存储的文件,对于分析型应用来说列存有非常大的优势。 http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.0.2/ds_Hive/orcfile.html
原来的RCFile中把每一列看成binary blob,没有任何语义,所以只能用通用的zlib,LZO,Snappy等压缩方法。
ORCFile能够获取每一列的类型(int还是string),那么就可以使用诸如dictionary encoding, bit packing, delta encoding, run-length encoding等轻量级的压缩技术。这种压缩技术的优势有两点:一是提高压缩率;二是能够起到过滤无关数据的效果
现在ORCFile中主要有三种编码:

  • bit编码,所有数据类型都可以用。Google’s protocol buffers and uses the high bit to represent whether this byte is not the last and the lower 7 bits to encode data
  • run-length encoding(行程长度压缩算法),int类型专用。
  • dictionary encoding,string类型专用。同时这个dictionary还能帮助过滤查询中的predicate条件。

Run length Encoding对某些列压缩会减少存储3-4个数量级,对内存提升也有2-3个数量级,Dictionary Encoding一般对磁盘空间减少大概20倍,对内存空间大概减少5倍,根据Google PowerDrill的实验,在常见的聚合查询中这些特殊的编码方式会对查询速度有2-3个数量级的提升.

Predicate Pushdown:原来的Hive是把所有的数据都读到内存中,然后再判断哪些是符合查询需求的。在ORCFile中数据以Stripe为单元读取到内存,那么ORCFile的RecordReader会根据Stripe的元数据(Index Data,常驻内存)判断该Stripe是否满足这个查询的需求,如果不满足直接略过不读,从而节省了IO。

关于ORCFile的压缩效果,使用情况和性能可以参考hortonworks的博客

http://hortonworks.com/blog/orcfile-in-hdp-2-better-compression-better-performance/

未来ORCFile还会支持轻量级索引,就是每一列中以1W行作为一组的最大值和最小值。

通过对ORCFile的上述分析,我想大家已经看到了brighthouse的影子了吧。都是把列数据相应的索引、统计数据、词典等放到内存中参与查询条件的过滤,如果不符合直接略过不读,大量节省IO。关于brighthouse大家可以参考下面的分析。

4,HiveServer2的Security和Concurrency特性

http://blog.cloudera.com/blog/2013/07/how-hiveserver2-brings-security-and-concurrency-to-apache-hive/

HiveServer2能够支持并发客户端(JDBC/ODBC)的访问。
Cloudera还搞了个Sentry用于Hadoop生态系统的的安全性和授权管理方面的工作。
这两个特点是企业级应用Hadoop/Hive主要关心的。

5,HCatalog Hadoop的统一元数据管理平台
目前Hive存储的表格元数据和HDFS存储的表格数据之间在schema上没有一致性保证,也就是得靠管理员来保证。目前Hive对列的改变只会修改 Hive 的元数据,而不会改变实际数据。比如你要添加一个column,那么你用hive命令行只是修改了了Hive元数据,没有修改HDFS上存储的格式。还得通过修改导入HDFS的程序来改变HDFS上存储的文件的格式。而且还要重启Hive解析服务,累坏了系统管理员。

  • Hadoop系统目前对表的处理是’schema on read’,有了HCatlog就可以做到EDW的’schema on write’。
  • HCatlog提供REST接口提供元数据服务,有利于不同平台(HDFS/HBase/Oracle/MySQL)上的不同数据(unstructured/semi-structured/structured)共享。能够把Hadoop和EDW结合起来使用。
  • HCatlog对用户解耦了schema和storage format。举个例子吧,在写MR任务的时候,目前是把所有的行数据都当成Text来处理,Text一点点解析出各个Column需要编程人员来控制。有个HCatlog之后编程人员就不用管这事了,直接告诉它是哪个Database->Table,然后schema可以通过查询HCatlog来获得。也省得数据存储格式发生变化之后,原来的程序不能用的情况发生。

6,Windowing and Analytics Functions的支持。

  • 支持Windowing functions : lead, lag, first_value, last_value
  • 支持over clause : partition by, order by, window frame
  • 支持analytics functions : rank, row_number, dense_rank, cume_dist, percent_rank, ntile

https://cwiki.apache.org/confluence/display/Hive/LanguageManual+WindowingAndAnalytics

https://issues.apache.org/jira/browse/HIVE-4197

Tez/Stinger(升级版的Hive)

Tez是一种新的基于YARN的DAG计算模型,主要是为了优化Hive而设计的。目前Tez/Stinger主要是Hortonworks在搞,他们希望以后把Hive SQL解析成能够在Tez上跑的DAG而不是MapReduce,从而解决计算实时性的问题。Tez的主要特点有:

  • 底层执行引擎不再使用MR,而是使用基于YARN的更加通用的DAG执行引擎
  • MR是高度抽象的Map和Reduce两个操作,而Tez则是在这两个操作的基础上提供了更丰富的接口。把Map具体到Input, Processor, Sort, Merge, Output,而Reduce也具体化成Input, Shuffle, Sort, Merge, Processor, Output。在MR程序里,编程人员只需编写对应的Processor逻辑,其他的是通过指定几种具体实现来完成的;而在Tez里面给我们更大的自由度。其实这个跟Spark有点类似了,都是提供更丰富的可操作单元给用户。
  • 传统的Reduce只能输出到HDFS,而Tez的Reduce Processor能够输出给下一个Reduce Processor作为输入。
  • Hot table也放到内存中cache起来
  • Tez service:预启动container和container重用,降低了每次Query执行计划生成之后Task启动的时间,从而提高实时性。
  • Tez本身只是YARN框架下得一个library,无需部署。只需指定mapreduce.framework.name=yarn-tez

http://dongxicheng.org/mapreduce-nextgen/apache-tez-newest-progress/

Tez/Stinger还有一个最重要的feature : Vectorized Query Execution (该feature在HDP 2.0 GA中会提供)

https://issues.apache.org/jira/browse/HIVE-4160

  • 目前Hive中一行一行的处理数据,然后调用lazy deserialization解析出该列的Java对象,显然会严重影响效率。
  • 多行数据同时读取并处理(基本的比较或者数值计算),降低了一行一行处理中过多的函数调用的次数,提高了CPU利用率和cache命中率
  • 需要实现基于向量的vectorized scan, filter, scalar aggregate, group-by-aggregate, hash join等基本操作单元。

未来工作方向:
Cost-based optimizer,基于统计选择执行策略,例如多表JOIN时按照怎样的顺序执行效率最高。
统计执行过程中每个中间表的Row/Column等数目,从而决定启动多少个MR执行

Impala
Impala可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的混合体。

https://github.com/cloudera/impala

Dremel论文: http://research.google.com/pubs/pub36632.html

优点:

  • 目前支持两种类型的JOIN:broadcast join和partition join。对于大表JOIN时由于内存限制,装不下时就要dump部分数据到磁盘,那样就会比较慢
  • Impala各个任务之间传输数据采用的是push的方式(MR采用的是pull的方式),也就是上游任务计算完就会push到下游,这样能够分散网络压力,提高job执行效率。
  • Parquet列存格式,同时能够处理嵌套数据。通过嵌套数据以及扩展的SQL查询语义,在某些特定的场景上避开了JOIN从而解决了一部分性能的bottleneck。(Impala目前支持LZO Text, Sequence, Avro, RCFile, Parquet, 不支持ORCFile。但是未来支持多种存储文件格式是个趋势,所以Impala读取文件这部分功能也需要尽快插件化。)
  • Cloudera Manager 4.6以后会有slow query的分析功能
  • Runtime Code Generation http://blog.cloudera.com/blog/2013/02/inside-cloudera-impala-runtime-code-generation/
  • impala可以直接使用硬盘上的数据而不经过hdfs

缺点:

  • impala不会按照group by的列排序
  • 目前不支持UDF,impala 1.2即将支持Hive UDFs(Java写的)和Impala native UDFs and UDAs(接口类似PosgreSQL)
  • 不支持像Hive的Serializer/Deserializer,从而使得它做从非结构化到结构化数据的ETL工作比较麻烦。所以本质上讲Impala适合MR配合做ETL之后的查询工作。
  • 由于Impala的设计初衷是short query,所以不支持fault tolerance。如果参与查询的某个node出错,Impala将会丢弃本次查询。
  • 安全方面的支持还比较差。impalad之间传输的数据没有加密,不支持表或者列级别的授权。
  • 每个PlanFragment执行尽量并行化,但是有的时候并不是很容易。例如Hash Join需要等到其中一个表完全Scan结束才能开始。

虽然有这么多缺点,但是很多公司还是开始尝试Impala了。以百度为例,百度尝试把MySQL接入Impala的后端作为存储引擎,同时实现相应操作对应的PlanFragment,那么用户来的query还是按照原来的解析方法解析成各种PlanFragment,然后直接调度到对应的节点(HDFS DataNode/HBase RegionServer/MySQL)上执行。会把某些源数据或者中间数据放到MySQL中,用户的query涉及到使用这部分数据时直接去MySQL里面拿。

Shark/Spark

  • 由于数据能放到内存尽量放到内存,使用内存非常aggressive。优点是做JOIN时会比较快,缺点是占用内存太大,且自行管理内存,占用内存后不会释放。
  • 由于Shark借用了Hive的codebase,所以在SQL,SerDes,UDF支持方面和Hive是完全兼容的。
  • 支持fault tolerance

性能:
特别简单的select…where查询,shark性能的提升不明显。(因为hive也不怎么费时间)
但是如果查询比较复杂select…join…where…group by,hive的job数目会比较多,读写HDFS次数增多,时间自然会变长。当内存还足够大的时候shark性能是最好的,如果内存不够装下所有的数据时性能会下降,但还是会比Hive好很多。

SQL on Hadoop产品需要向传统数据仓库学习的地方
以开源数据仓库brighthouse(基于MySQL的数据仓库存储引擎)为例。
VLDB 2008 论文 <>

brighthouse的SQL解析用的是MySQL的代码,开发了brighthouse专用的optimizer,executor以及storage engine
brighthouse的数据存储通过三层来组织:Data Pack, Data Pack Node, Knowledge Node

  • DP(Data Pack):brighthouse是列存储的,每个DP存储一列中64K个单元的数据。
  • DPN(Data Pack Node):DPN和DP是一对一的关系,DPN中记录每个DP数据对应的一些统计值(max,min,count,sum)
  • KN(Knowledge Node):DP的更详细的数据信息和DP之间关系的信息

KN又分为一下三个部分:

  • HISTs(Histograms):数值类型列的统计直方图,能够快速判断这个DP是否符合查询条件。
  • CMAPs(Character Maps):文本类型的位图,用于快速查找字符。(优化关键字like)
  • Pack-To-Pack:等值JOIN操作时产生的两个列(DP)之间关系的位图。

DPN和KN相当于DP的一些统计信息,占整个DP的1%的存储空间,所以可以轻松装入内存。他们是为了快速定位哪些DP是跟这个query相关(relevant)的,哪些是不相关(irrelevant)的,哪些是可能相关(suspect)的。从而减小IO读取的数据量,提高性能。

性能测试:http://www.fuchaoqun.com/tag/brighthouse/
从这个性能测试中可以看出:
1,压缩率:infobright比MyISAM/tar.gz的压缩率都要高很多
2,查询性能:跟建了索引的MyISAM表相比,查询速度也要快3-6倍

总之,大家都缺少的是:
1,workload management or query optimization
多个表的JOIN如何执行,例如3个表的JOIN会有6种执行策略,那么哪一种才是效率最高的呢。显然要通过计算每种执行顺序的开销来获得。在传统数据库或者数据仓库领域(Oracle/Teradata/PostgreSQL)都有非常好的查询优化器,而在分布式系统中该如何衡量这些指标(磁盘IO,网络带宽,内存)与最后查询效率之间的关系是个需要认真研究的问题。
2,关联子查询correlated sub-queries还是没有谁能够实现。
在TPC-H中又很多关联子查询的例子,但是现在的SQL on Hadoop产品都不支持。听Impala的人说,他们客户对这个的需求不是很强烈,大部分关联子查询可以转化成JOIN操作。但是目前的商业产品像Hawq/Greenplum都是支持关联子查询的。

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

  • 原来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/ )
  1. 可以在Hawq内执行除了Query以外的分析任务,例如analytic functions(standard deviation, variance等)和off-the-shelf analytic package
  2. 支持数据挖掘算法: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的前途的。



你可能感兴趣的:(hadoop相关)