工作中用到了kudu。以前随便用用现在没事准备好好学习下。
1.指定分区
为什么要指定好分区呢？一般来说习惯将kudu与hbase进行比较。两者区别在哪里？
翻译:kudu目前没有办法对已经分好区的tablet在进行切分!!!
hbase存储数据实际时region，但是随着数据的不断增大，region还会水平切分，然后根据集群的负载会分布到不同的regionserver里。
kudu呢？kudu以hash分区=4为例，kudu会有4个tablet，然后数据根据主键进行hash后分不到不同的tablet，随着数据的增加 也不会再切分。
所以提前分好区是很重要的，特别是range分区。就好像hbase的rowkey设计一样。
2.kudu和impala什么关系
简单理解 kudu是真正存储数据的数据库。
impala只是个查询引擎，可以兼容hive kudu。
如何做到kudu和impala关联的。两种办法。
一种是通过kudu api 建立表a。 然后impala 建立外表b与之关联，我们再impala上对表b进行增删改查也是对kudu进行操作
CREATE EXTERNAL TABLE test.cc_test_kudu2 STORED AS KUDU
TBLPROPERTIES(
'kudu.table_name' = 'test.cc_test_kudu',
'kudu.master_addresses' = 'master.data.com:7051,node02.data.com:7051,node03.data.com:7051'
)
第二种是直接在impala上创建kudu表，此时是内表，一损俱损，一荣俱荣
CREATE TABLE my_first_table1
(
id BIGINT,
name STRING,
PRIMARY KEY(id)
)
PARTITION BY HASH PARTITIONS 16
STORED AS KUDU
还有其他的创建方式就不举例了。官网啥都有
2.kudu和impala
如果在impala上创建了一个内部的kudu表 也就是我们的说的第二种方式。那么要注意在kudu和impala是有点不一样的。
4注意关键词
这几个关键词都是hive的 分区 文件位置，每一行分隔符
5.sql 优化
整段话说了啥意思？就是说kudu对于谓词也就是 = > 这些来说，kudu计算的，然后返回对应的结果，这种事比较好的。
但是如果是like和 != 这些事impala支持的，kudu会返回所有结果，然后由impala计算。
6 分区hash 还是range
如果是range分区，如果主键是单调递增的，那么最后一个分区会比其他分区都大，数据不均衡，而且这种数据很容易出现 批量对单独一个分区进行数据的插入，对tablet的压力也会较大。
那么就用hash分区么。
hash分区是很大程度上可以将数据均匀分布，但是会有另外一个问题，如果我要查where name like ‘cc%’ 有cc1 cc2 ...cc10但是他们hash不同，所以我有可能要去10个tablet里找数据。
总结下 range分区 插入性能差，但是查询性能好。
hash分区 插入性能好，但是查询性能差。
有人可能会问了，都有好坏 那我用啥？看具体情况。而且还有一种，我两个都用不就好了？
7 不同的分区策略
这两个分区有啥区别，暂时未知。。。
8批量插入
批量插入有三种常用方式。都有自己的优势和劣势。
1.多个insert单条sql，优点：简单易于实现，缺点，效率低，因为与Kudu的插入性能相比，Impala的查询启动成本很高，高延迟和低吞吐
2.insert into table values(),()....() 默认是1024条。如果你想插入更多，需要set batch_size=10000
这种方式比第一种更高效，因为降低了impala的启动成本，但是对impala的memory要求会更高。
3.insert into table select * from table2这种方式经常是最好的，就是比较麻烦，需要建个中间表
通过java api插入的数据在impala上是可以实时查看的不需要refresh invalidate metadata。如果用impala使用hive的小伙伴应该都知道是啥意思。
9.upsert
insert 一个存在的主键不会报错。但是也不会改变。
但是upsert类似insert没有成功就upsert ，只有在impala上操作kudu表的时候才有upsert
10 delete
删除表，第一句很正常。第二句语法有点吊。 同样只能在impala上操作kudu的时候这么用
后面有时间会专门搞下impala的官网学习