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。
实验设置
· 使用的数据集: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表使用主键进行哈希分区。
> 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进行比较:
> Chart 1. Running Analytical Queries on Kudu and HDFS Parquet
观察结果:图1比较了在Kudu和HDFS Parquet存储的表上运行基准查询的运行时。 我们可以看到,Kudu存储表的性能几乎与HDFS Parquet存储表一样好,除了一些查询(Q4,Q13,Q18)外,与后者相比,它们花费的时间要长得多。
比较Kudu与HDFS逗号分隔的存储文件:
> 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在随机访问选择方面确实是赢家。
> Chart 3. Comparing time for Random Selections
Kudu更新,插入和删除性能
由于Kudu支持这些附加操作,因此本节将比较这些运行时。 该测试的设置类似于上面的随机访问,其中循环运行了1000个操作,并测量了运行时间,可以在下面的表2中看到:
> 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)
,