Spark Kudu 结合

Kudu的背景

Hadoop中有不少组件，为了实现复杂的功能一般都是使用混合架构，

• Hbase：实现快速插入和修改，对大量的小规模查询也很迅速
• HDFS/Parquet + Impala/Hive：对超大的数据集进行查询分析，对于这类场景， Parquet这种列式存储文件格式具备极大的优点。
• HDFS/Parquet + Hbase:这种混合架构须要每隔一段时间将数据从hbase导出成Parquet文件，而后用impala来实现复杂的查询分析 
  以上的架构没办法把复杂的实时查询集成在Hbase上

Kudu的设计

• Kudu是对HDFS和HBase功能上的补充，能提供快速的分析和实时计算能力，而且充分利用CPU和I/O资源，支持数据原地修改，支持简单的、可扩展 
  的数据模型。
• Kudu的定位是提供”fast analytics on fast data”，kudu指望本身既可以知足分析的需求（快速的数据scan)，也可以知足查询的需求（快速的随机访问）。它定位OLAP和少许的OLTP工做流，若是有大量的random accesses，官方建议仍是使用HBase最为合适

Kudu的结构

其实跟Hbase是有点像的

Kudu的使用

1：支持主键（相似 关系型数据库） 
2：支持事务操做，可对数据增删改查数据 
3：支持各类数据类型 
4：支持 alter table。可删除列（非主键） 
5：支持 INSERT, UPDATE, DELETE, UPSERT 
6：支持Hash，Range分区 
进入Impala-shell -i node1ip 
具体的CURD语法能够查询官方文档，我就不一一列了 
http://kudu.apache.org/docs/kudu_impala_integration.html 
建表 
Create table kudu_table (Id string,Namestring,Age int, 
Primary key(id,name) 
)partition by hash partitions 16 
Stored as kudu; 
插入数据 
Insert into kudu_table 
Select * from impala_table; 
注意 
以上的sql语句都是在impala里面执行的。Kudu和hbase同样都是nosql查询的，Kudu自己只提供api。impala集成了kudu。 

Kudu Api

奉上个人Git地址： 
https://github.com/LinMingQiang/spark-util/tree/spark-kudu

Scala Api

pom.xml

<dependency> <groupId>org.apache.hive</groupId> <artifactId>hive-metastore</artifactId> <version>1.1.0</version> </dependency> <dependency> <groupId>org.apache.hive</groupId> <artifactId>hive-jdbc</artifactId> <version>1.1.0</version> </dependency> <dependency> <groupId>org.apache.hive</groupId> <artifactId>hive-service</artifactId> <version>1.1.0</version> <exclusions> <exclusion> <artifactId>servlet-api</artifactId> <groupId>javax.servlet</groupId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.apache.kudu</groupId> <artifactId>kudu-client</artifactId> <version>1.3.0</version> </dependency> <dependency> <groupId>org.apache.spark</groupId> <artifactId>spark-sql_2.10</artifactId> <version>1.6.0</version> </dependency> <dependency> <groupId>org.kududb</groupId> <artifactId>kudu-spark_2.10</artifactId> <version>1.3.1</version> </dependency> <dependency> <groupId>org.apache.kudu</groupId> <artifactId>kudu-mapreduce</artifactId> <version>1.3.1</version> <exclusions> <exclusion> <artifactId>jsp-api</artifactId> <groupId>javax.servlet.jsp</groupId> </exclusion> <exclusion> <artifactId>servlet-api</artifactId> <groupId>javax.servlet</groupId> </exclusion> </exclusions>

val client = new KuduClientBuilder("master2").build() val table = client.openTable("impala::default.kudu_pc_log") client.getTablesList.getTablesList.foreach { println } val schema = table.getSchema(); val kp = KuduPredicate.newComparisonPredicate(schema.getColumn("id"), KuduPredicate.ComparisonOp.EQUAL, "1") val scanner = client.newScanTokenBuilder(table) .addPredicate(kp) .limit(100) .build() val token = scanner.get(0) val scan = KuduScanToken.deserializeIntoScanner(token.serialize(), client) while (scan.hasMoreRows()) { val results = scan.nextRows() while (results.hasNext()) { val rowresult = results.next(); println(rowresult.getString("id")) } }

Spark Kudu Api

val sc = new SparkContext(new SparkConf().setMaster("local").setAppName("Test")) val sparksql = new SQLContext(sc) import sparksql.implicits._ val a = new KuduContext(kuduMaster, sc) def getKuduRDD() { val tableName = "impala::default.kudu_pc_log" val columnProjection = Seq("id", "name") val kp = KuduPredicate.newComparisonPredicate(new ColumnSchemaBuilder("id", Type.STRING).build(), KuduPredicate.ComparisonOp.EQUAL, "q") val df = a.kuduRDD(sc, tableName, columnProjection,Array(kp)) df.foreach { x => println(x.mkString(",")) } } def writetoKudu() { val tableName = "impala::default.student" val rdd = sc.parallelize(Array("k", "b", "a")).map { n => STU(n.hashCode, n) } val data = rdd.toDF() a.insertRows(data, tableName) } case class STU(id: Int, name: String)

小结

• Kudu简单来讲就是增强版的Hbase，除了像hbase同样能够高效的单条数据查询，他的表结构是类型关系型数据库的。集合impala能够达到复杂sql的实时查询。适合作OLAP（官方也是这么定位的）
• Kudu本质上是将性能的优化，寄托在以列式存储为核心的基础上，但愿经过提升存储效率，加快字段投影过滤效率，下降查询时CPU开销等来提高性能。而其余绝大多数设计，都是为了解决在列式存储的基础上支持随机读写这样一个目的而存在的。好比类Sql的元数据结构，是提升列式存储效率的一个辅助手段，惟一主键的设定也是配合列式存储引入的定制策略，至于其余如Delta存储，compaction策略等都是在这个设定下为了支持随机读写，下降latency不肯定性等引入的一些Tradeoff方案。 官方测试结果上，若是是存粹的随机读写，或者单行的检索请求这类场景，因为这些Tradeoff的存在，HBASE的性能吞吐率是要优于Kudu很多的（2倍到4倍），kudu的优点仍是在支持类SQL检索这样常常须要进行投影操做的批量顺序检索分析场合。目前kudu还处在Incubator阶段，而且尚未成熟的线上应用（小米走在了前面，作了一些业务应用的尝试），在数据安全，备份，系统健壮性等方面也还要打个问号，因此是否使用kudu，什么场合，什么时间点使用，是个须要好好考量的问题 ；）