cloudera impala试用评测.doc

cloudera impala试用评测 v3cloudera impala试用评测1前言32Cloudera Impala简介43CDH安装54Impala vs Oracle性能比拼65impala的特点10 前言 Cloudera Impala简介 CDH安装 Impala vs Oracle性能比拼 impala的特点1 前言今年可能要上hadoop的项目，所以年前年后花了大约2周左右的时间研究了一下cloudera impala（一个基于Hadoop的实时查询开源项目），并进行了一番测试研究。2 Cloudera Impala简介Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，Impala没有再使用缓慢的Hive+MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。Impala主要由Impalad， State Store和CLI组成，其架构是如下图所示：Abbildung 1 impala_3Cloudera Impala 可以直接为存储在HDFS或HBase中的Hadoop数据提供快速，交互式的SQL查询。除了使用相同的存储平台外， Impala和Apache Hive一样也使用了相同的元数据，SQL语法（Hive SQL），ODBC驱动和用户接口（Hue Beeswax），这就很方便的为用户提供了一个相似并且统一的平台来进行批量或实时查询。它是用来进行大数据查询的补充工具。3 CDH安装Hadoop+impala的系统平台建议选择Linux RHEL6.4 或 CentOS6.4 或 OEL6.4，由于impala和Apache Hive一样也需要将元数据存储在rdbms上，所以可以在linux上再安装mysql或者postgreSQL，jdk的话CDH4.2 需要JDK1.7.0_15+ 而 CDH4需要安装JDK1.6.0_31+，安装cloudera impala前linux系统的相关配置操作在此略，有兴趣的tx可通过官方在线文档了解（注：这些操作在集群中的所有node上都要做），然后就是安装cdh了，比较好的是CDH可以通过cloudera manager安装向导来安装，安装过程可查阅online doc，节省篇幅，详细过程跳过。安装成功后可通过cloudera manager console监控和管理cdh，如下图：4 Impala vs Oracle性能比拼本次试用的重点内容-性能测试。由于条件所限，笔者本次CDH的测试只能在虚拟机上进行，采用了最基本的3nodes集群部署，一个namenode，两个datanode，而oracle则部署在物理服务器上，采用oracle11gR2。以下是本次测试的报告。OracleImpala平台配置Intel(R) Xeon(R) CPU L5420 2.50GHz * 8cores / 9g mem3nodes，for each node：Intel(R) Xeon(R) CPU E5430 2.66GHz * 2cores /4g mem测试素材XXXX明细表F_UNIBA_DXSF_TEST，表记录行：18,286,206，文件大小2.5g表结构主要字段说明：ID（明细流水号，pk），patID（id），sfmonth（年月），outdept（科室），zje（费用金额），indate（日期）oracle 扫描方式 / impala 表存储文件格式全表扫描索引扫描TEXTFILEPARQUETFILE测试用例1：select * from F_UNIBA_DXSF_TEST t WHERE ID=6640241010s0.1s128.6s第二次：24.8s第三次：14.4s11.9s第二次：6.4s测试用例2：select * from F_UNIBA_DXSF_TEST t WHERE patID=0009310222.4s0.1s55s第二次：16.7s7.8s第二次：5.5s测试用例3：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201307 GROUP BY outdept11.2s3.7s68.9s2.7s测试用例4：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201306 and sfdm=a GROUP BY outdept6.5s2.4s17.97s1.8s测试用例5：select outdept,sum(zje) from F_UNIBA_DXSF_TEST where sfmonth=201308 and (sfdm=a or sfdm like z%) GROUP BY outdept12.5s4.8s16s1.5s测试用例6：select outdept,count(distinct patid) from F_UNIBA_DXSF_TEST where brsf=A002 and indate=to_date(20130903,yyyymmdd) GROUP BY outdept9.3s0.3s19.7s2.7s测试用例7：select count(*) from f_uniba_dxsf_TEST4.2s1s24.8s0.5s测试说明：1. oracle的测试分为表扫描、索引扫描；而impala测试主要是针对传统的text文本格式和面向列的PARQUET格式；2. 测试分为两类，一类是单行or 明细查询（用例12），一类是汇总统计（用例37）；3. 限于篇幅，测试工作涉及的建表、数据装载、数据转换等详细操作在此跳过。测试小结：对海量数据进行汇总查询，采用PARQUETFILE格式存储无疑能获得最高效的查询效率。Parquet 是一种面向列的二进制文件格式，设计目标是为 Impala 最擅长的大规模查询类型提供支持。Parquet 对于查询扫描表中特定的列特别有效，例如查询一个包含许多列的宽表，或执行需要处理列中绝大部分或全部的值的如 SUM(),AVG() 等聚合操作。每个数据文件包含行集(行组)的值(Each data file contains the values for a set of rows (the row group)。在数据文件里，每一列的值都被重组，以便他们相邻，从而对这些列的值进行良好的压缩。针对 Parquet 表的查询可以快速并最小 I/O 的从任意列获取并分析这些数据。impala支持的Parquet是hadoop文件格式中的其中一种，除此之外，impala同样支持hadoop的其他各种文件格式，如：Text,Avro,RCFile,SequenceFile，每种格式都有其适用面（更多关于hadoop文件格式的内容可网上查阅资料），以下是各种文件格式所表现的query性能与传统rdbms相比，impala具有更好的扩展性，随着数据量的增加，oracle终究会无法承受日益增加的负荷，而impala可以很轻松的通过添加node至cluster实现计算能力的提升，不仅如此，面向列的存储更容易进行数据压缩，空间的增长也远低于传统rdbms。即使是在数据量不大的情况下，impala也表现出了胜过oracle的性能（在聚合案例中oracle采用索引扫描的效率仍低于impala），要知道老旧的虚拟机环境也限制了impala的性能，如果硬件达标并且数据量突破10亿，我们可以想一想。5 impala的特点笔者在使用中也逐步了解了impala的一些特点，结合自己使用的感受，总结一下：1. Impala没有使用MapReduce进行并行计算，它是一种在Hadoop集群上运行的本地、分布式SQL查询引擎，取代了Hadoop的MapReduce引擎。你仍然可以得到Hadoop的分布式文件系统。 你仍然可以得到其物理的分布式体系结构。 你仍然有可能获得局域数据，因为分布在各节点的数据并没有改变，唯一改变的是查询方式。Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间。2. Impala是在一个基于磁盘的系统，经常受到I/O的限制，而列格式可以减少总I/O量，而且经常可以减少很多，所以存储格式对impala的性能非常重要，而Impala也支持多种存储格式（Parquet, Text, Avro, RCFile, SequeenceFile），选择合适的hadoop数据存储格式可以得到最好的性能（它不是内存数据库，它更像rdbms，一个融合了hadoop+mpp技术的rdbms）3. Impala 性能随主机数而扩展(Impala scales with the number of hosts)。在集群中所有数据节点上安装 Impala 很重要，否则的话，一些节点必须进行远程读取以获得本地读取无法获得的数据。对于 Impala 性能来说，数据本地化(Data locality) 是一个重要的架构方面(architectural aspect)4. Impala在遇到内存放不下数据时，版本1.0.1是直接返回错误，而不会利用外存（从资料上看目前1.2.3仍然不支持溢出的硬盘(spill to disk)，待测）。这使用得Impala目前处理Query会受到一定的限制，可考虑与Hive配合使用（Hive:在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完）。Impala在多个阶段之间利用网络以stream的方式传输数据，在执行过程不会有写磁盘的操作，中间结果也不写磁盘，能最大使用内存。5. 与Hive经常受到CPU的限制不同，Impala更多的是受到I/O的限制，所以Impala方案真正需要的是：“正确的存储格式+更快的存储+够大的内存+高速的网络+更多的节点6. Impala没有维持其自有的缓存，取而代之的是使用OS buffer进行缓存以保证频繁访问的数据保留在内存中，不同于oracle的表缓存技术，它不会显式地将表“钉到内存中”，但它缓存一些表和文件的元数据。尽管因为数据集被缓存到 OS 的缓冲区中，接下来的重复查询可能运行的更快，但Impala 不会明确的控制这些（参见测试用例1，用例2）7. Impala在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误8. 对内存要求高，官方建议每个node至少配置128 GB mem，最好256 GB+9. Impala 使用 SSE4.2 指令。至少需要 Intel 的 Nehalem+ 芯片和 AMD 的 Bulldozer+ 芯片10. Impala 非常适合在大的数据集上，为交互式探索分析执行 SQL。Hive 和 MapReduce 则适合长时间运行的、批处理的任务，例如 ETL。即使MapReduce 停了，Impala 依旧能正常工作，因为Impala 根本不用 MapReduce11. 不支持delete 和 update操作，只能通过删除整个表或分区来批量删除数据，这对于列内容经常变化的增量加载将是不小的麻烦12. 目前暂时不支持分析函数和开窗函数，cloudera计划今年上半年发布的新版本能够支持（咱们的BI啥时也支持哦，喊了这么多年了）13. 暂不支持索引，而Hive已经支持了14. Impala 要求所有包含的 ORDER BY 子句的查询同时包含 LIMIT 子句，每一个 Impala 节点扫描并过滤总数据的一部分，并且对他们自己那部分数据应用 LIMIT。中间结果集都发送回协调节点，在上面执行最终的排序并对最终结果集再次应用 LIMIT 子句。假如你执行查询：select * from giant_table order by some_column limit 1000; 并且你的集群有 50 个节点，然后这 50 个节点每个节点将传递最多 1000 行记录给协调节点。协调节点需要足够的内存进行排序(LIMIT返回行 *集群节点数) ，尽管这时最终的结果集也只需要返回 1000 行15. 由于Impala不支持溢出的硬盘(spill to disk)，所以在构造sql时需要注意的是：a）避免在唯一或高基数(high-cardinality)列上的 GROUP BY 操作。Impala 为 GROUP BY 查询中每一个不同的值分配一些处理结构(handler structures)。成千上万不同的 GROUP BY 值可能超出内存限制；b）查询涉及到非常宽、包含上千个列的表，特别是包含许多 STRIN