hadoophdfs处于最底层(Kudu和性能比较指南)

hadoophdfs处于最底层(Kudu和性能比较指南)(1)

Apache Kudu是一个开源的列式存储引擎。 它保证了低等待时间的随机访问和分析查询的有效执行。 kudu存储引擎支持通过Cloudera Impala,spark以及Java,C 和Python API进行访问。

本文的目的是记录我在探索Apache Kudu方面的经验,了解它的局限性,并进行一些实验以比较Apache Kudu存储与HDFS存储的性能。

使用Cloudera Manager安装Apache Kudu

以下是Cloudera Manager Apache Kudu文档的链接,可用于在Cloudera Manager管理的集群上安装Apache Service。

通过Impala访问Apache Kudu

可以使用Impala在kudu存储表中创建,更新,删除和插入。 好的文档可以在这里cloudera/documentation/kudu/5-10-x/topics/kudu_impala.html找到。

创建一个新表:

CREATE TABLE new_kudu_table(id BIGINT, name STRING, PRIMARY KEY(id))PARTITION BY HASH PARTITIONS 16STORED AS KUDU;

对数据执行插入,更新和删除:

--insert into that table INSERT INTO new_kudu_table VALUES(1, "Mary"); INSERT INTO new_kudu_table VALUES(2, "Tim"); INSERT INTO new_kudu_table VALUES(3, "Tyna");--Upsert when insert is meant to override existing row UPSERT INTO new_kudu_table VALUES (3, "Tina");--Update a Row UPDATE new_kudu_table SET name="Tina" where id = 3;--Update in Bulk UPDATE new_kudu_table SET name="Tina" where id<3;--Delete DELETE FROM new_kudu_table WHERE id = 3;

也可以使用CREATE TABLE DDL从现有的Hive表创建kudu表。 在下面的示例脚本中,如果已经存在桌面电影,则可以如下创建Kudu支持的表:

CREATE TABLE movies_kudu PRIMARY KEY (`movieid`) PARTITION BY HASH(`movieid`) PARTITIONS 8 STORED AS KUDU AS SELECT movieId, title, genres FROM movies;

创建Kudu表时的限制:

不支持的数据类型:如果表具有VARCHAR(),DECIMAL(),DATE和复杂数据类型(MAP,ARRAY,STRUCT,UNION),则从现有配置单元表创建表时,则在kudu中不支持这些数据类型。 任何选择这些列并创建kudu表的尝试都将导致错误。 如果使用SELECT *创建Kudu表,那么不兼容的非主键列将被删除到最终表中。

主键:必须首先在表模式中指定主键。 从另一个主键列不在第一位的现有表中创建Kudu表时-在create table语句中的select语句中对列进行重新排序。 另外,主键列不能为空。

通过Spark访问Kudu

在您的spark项目中添加kudu_spark允许您创建一个kuduContext,可用于创建Kudu表并将数据加载到其中。 请注意,这仅在Kudu中创建表,并且如果您要通过Impala查询此表,则必须创建一个外部表,并按名称引用此Kudu表。

以下是使用Kudu spark通过spark在Kudu中创建表的简单演练。 让我们从添加依赖关系开始,

<properties> <jdk.version>1.7</jdk.version> <spark.version>1.6.0</spark.version> <scala.version>2.10.5</scala.version> <kudu.version>1.4.0</kudu.version></properties><dependency> <groupId>org.apache.kudu</groupId> <artifactId>kudu-spark_2.10</artifactId> <version>${kudu.version}</version> </dependency>

接下来,如下所示创建KuduContext。 由于SparkKudu的库是用Scala编写的,因此我们必须应用适当的转换,例如将JavaSparkContext转换为与Scala兼容的

import org.apache.kudu.spark.kudu.KuduContext; JavaSparkContext sc = new JavaSparkContext(new SparkConf()); KuduContext kc = new KuduContext("<master_url>:7051", JavaSparkContext.toSparkContext(sc));

如果我们有一个要存储到Kudu的数据框,则可以执行以下操作:

import org.apache.kudu.client.CreateTableOptions; df = … // data frame to load to kudu primaryKeyList = .. //Java List of table's primary keysCreateTableOptions kuduTableOptions = new CreateTableOptions(); kuduTableOptions.addHashPartitions( <primaryKeyList>, <numBuckets>);// create a scala Seq of table's primary keys Seq<String> primary_key_seq = JavaConversions.asScalaBuffer(primaryKeyList).toSeq();//create a table with same schema as data frame kc.createTable(<kuduTableName>, df.schema(), primary_key_seq, kuduTableOptions);//load dataframe to kudu table kc.insertRows(df, <tableName>);

通过Spark使用Kudu时的限制:

不支持的数据类型:Kudu不支持某些复杂的数据类型,并且在通过Spark加载时会使用异常来创建表以使用它们。 Spark确实设法将VARCHAR()转换为弹簧类型,但是其他类型(ARRAY,DATE,MAP,UNION和DECIMAL)将不起作用。

如果要通过Impala访问,则需要创建外部表:使用上述示例在Kudu中创建的表仅驻留在Kudu存储中,并且不反映为Impala表。 要通过Impala查询表,我们必须创建一个指向Kudu表的外部表。

CREATE EXTERNAL TABLE IF NOT EXISTS <impala_table_name> STORED AS KUDU TBLPROPERTIES('kudu.table_name'='<kudu_table_name>');

Apache Kudu和HDFS性能比较

实验目的

该实验的目的是在加载数据和运行复杂的分析查询方面比较Apache Kudu和HDFS。

实验设置

· 使用的数据集:TPC Benchmark™H(TPC-H)是决策支持基准,它模拟典型的业务数据集和一组复杂的分析查询。 可以在github/hortonworks/hive-testbench上找到生成此数据集并将其加载到配置单元的好资源。 该数据集有8个表,并且可以从2 Gb开始以不同的比例生成。 为了该测试的目的,生成了20Gb的总数据。

· 群集设置:群集具有4个Amazon EC2实例,其中1个主实例(m4.xlarge)和3个数据节点(m4.large)。 每个群集具有1个大小为150 Gb的磁盘。 集群通过Cloudera Manager进行管理。

数据加载性能:

表1.显示了使用Apache Spark加载到Kudu与Hdfs之间的时间(以秒为单位)。 Kudu表使用主键进行哈希分区。

hadoophdfs处于最底层(Kudu和性能比较指南)(2)

> Table 1. Load times for the tables in the benchmark dataset

观察结果:从上表中可以看到,小型Kudu表的加载速度几乎与Hdfs表一样快。 但是,随着大小的增加,我们确实看到加载时间变成了Hdfs的两倍,最大的表格行项目占用的加载时间是加载时间的4倍。

分析查询效果:

TPC-H Suite包含一些基准分析查询。 使用Impala针对HDFS Parquet存储表,Hdfs逗号分隔存储和Kudu(主键上的16和32 Bucket Hash分区)运行查询。 记录了每个查询的运行时,下面的图表以秒为单位显示了这些运行时间的比较。

将Kudu与HDFS Parquet进行比较:

hadoophdfs处于最底层(Kudu和性能比较指南)(3)

> Chart 1. Running Analytical Queries on Kudu and HDFS Parquet

观察结果:图1比较了在Kudu和HDFS Parquet存储的表上运行基准查询的运行时。 我们可以看到,Kudu存储表的性能几乎与HDFS Parquet存储表一样好,除了一些查询(Q4,Q13,Q18)外,与后者相比,它们花费的时间要长得多。

比较Kudu与HDFS逗号分隔的存储文件:

hadoophdfs处于最底层(Kudu和性能比较指南)(4)

> Chart 2. Running Analytical Queries on Kudu and HDFS Comma Separated file

观察结果:图2将kudu运行时(与图1相同)与HDFS逗号分隔存储进行了比较。 在这里我们可以看到,与Kudu相比,在HDFS逗号分隔存储上运行查询所花的时间要长得多,Kudu(16个存储桶存储)的运行时间平均快5倍,而Kudu(32个存储桶存储)的运行速度要好7倍。 平均。

随机访问性能:

Kudu自夸访问随机行时的延迟要低得多。 为了测试这一点,我使用了相同TPC-H基准测试的客户表,并在一个循环中按ID进行了1000次随机访问。 这些时间是针对Kudu 4、16和32桶分区数据以及HDFS Parquet存储的数据进行测量的。 下图显示了以秒为单位的运行时间。 1000随机访问证明了Kudu在随机访问选择方面确实是赢家。

hadoophdfs处于最底层(Kudu和性能比较指南)(5)

> Chart 3. Comparing time for Random Selections

Kudu更新,插入和删除性能

由于Kudu支持这些附加操作,因此本节将比较这些运行时。 该测试的设置类似于上面的随机访问,其中循环运行了1000个操作,并测量了运行时间,可以在下面的表2中看到:

hadoophdfs处于最底层(Kudu和性能比较指南)(6)

> Table 2. Measuring Runtime for Various Operations

结论

只是根据我的探索和实验,写下我对Apache Kudu的想法。

就可访问性而言,我认为有很多选择。 可以通过Impala访问该文件,该文件允许创建kudu表并对其进行查询。 SparkKudu可在Scala或Java中用于将数据加载到Kudu或从Kudu读取数据作为数据帧。 此外,还提供Java,Python和C 形式的Kudu客户端API(本博客未涵盖)。

Kudu支持的数据类型有一些限制,如果用例需要为列(例如Array,Map等)使用复杂类型,那么Kudu并不是一个好的选择。

此博客中的实验是用来衡量Kudu在性能方面如何与HDFS相抗衡的测试。

从测试中,我可以看到,尽管与HDFS相比,最初将数据加载到Kudu所需的时间更长,但是在运行分析查询时,它的性能几乎相等,并且对于随机访问数据的性能更好。

总的来说,我可以得出结论,如果对存储的要求与对HDFS的分析查询一样好,并且具有更快的随机访问和RDBMS功能(如更新/删除/插入)的额外灵活性,那么Kudu可以被视为潜在的候选清单。

(本文翻译自Kruti Vanatwala的文章《Guide to Using Apache Kudu and Performance Comparison with HDFS》,参考:blog.clairvoyantsoft/guide-to-using-apache-kudu-and-performance-comparison-with-hdfs-453c4b26554f)

,

免责声明:本文仅代表文章作者的个人观点,与本站无关。其原创性、真实性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容文字的真实性、完整性和原创性本站不作任何保证或承诺,请读者仅作参考,并自行核实相关内容。文章投诉邮箱:anhduc.ph@yahoo.com

    分享
    投诉
    首页