数据模拟完成后的 Kudu 对比性能测试
测试介绍
TPCDS 和 TPCH 是专门为超大数据量设置的测试项目，下面的是Kudu官网上官方用TPCH测试的结果：
我自己做的表格也是模仿的官方的图表格式。
介绍一下这个图表的含义，TPCH测试中含有很多超复杂SQL，用不同的数据库在相同数据下运行了这些语句之后，然后对比运行时间，图表横坐标是SQL的序号，纵坐标是运行时间，官方的运行环境是75节点的，单位是毫秒。
性能对比
下面是我做的测试，三节点下的kudu，机器配置都是64G内存，16核心，系统是Centos 7.4，Kudu版本是1.5，SQL是用impala+Kudu的形式运行的，测试数据量是用TPCDS生成的100G数据。
我的测试相比官方的添加了文本格式的HiveSQL测试，测试下来确实是速度最慢的。
Kudu和parquet各有千秋，和官方的测试结果相差不大。
写入性能
Kudu的写入性能测试的时候没有能够完全发挥出来，短板不在kudu的写入，这边的写入测试是我用脚本统计5分钟内表多出来的行数然后除以600s得到的，这边截取一段（因为是5分钟统计一次，图表的表述可能不够准确）
监测过程中得到的最大写入速度在9.5w/s左右，大部分时候速度在3.5w条到5w条之间。
后来在开启多线程写入kudu的时候，kudu的写入速度很轻松就能达到20w/s，但是可能因为资源不足，kudu的tablet Server容易挂掉，因为impala也是非常吃内存的组件，64G有点捉襟见肘。
kudu写入速度和表格大小的关系
kudu的这个写入速度和表格大小有直接关系。
结论：
kudu导入小表的速度十分快，但是导入大表的时候性能会严重下降。
为了避免测试误差，在用tpcds生成不同大小的测试样本中取相同表格不同大小来测试，避免阻断等等误差，测试结果如下：
根据测试结果基本可以判断，我们测试集群环境下，小表的导入速度明显要比大表大很多。
类似的，我们根据TPCDS生成的不同大小的数据样本，分析数据量大小对kudu的影响（这边的数据来源网易的报告，1T的因为测试集群环境原因没有测试）：
100G:
1T:
根据上面两张折线图可以看出，随着表的数据量变成巨大，kudu和parquet的之间的性能也被拉开了。
10T:
1T的和10T的相差不是特别大
结论：kudu表目前看来不太适合大表，分区能否解决这个问题，还要靠实验
资源使用情况
Impala使用的资源整体上少于Spark，磁盘的读取少于Spark，这对于速度的提高至关重要，这与其语句的优化有关。Impala的CPU一直维持在较低的水平，说明其C++的实现比Java高效。
kudu写入速度
Spark的CPU占用较高，但是维持在50%的水平，可见CPU并没有成为其瓶颈，在使用Oozie多线程写入的时候可能遇到了kudu的瓶颈，Kudu的写入瓶颈是可以通过一些参数进行简单调整的。
目前从集群的写入速度上来分析，初步判断硬盘的写入速度已经成为了瓶颈。
下图以Master节点为例，列出的Kudu TS以6个小时为一个窗口使用磁盘的峰值和平均值：
MiB单位换算成Mbit/s是Mbit/s = MiB/s * 0.1192，图中所示峰值几乎达到了机械硬盘写入极限。