不生产博客，只是官网的搬运工
https://docs.cloudera.com/documentation/enterprise/5-16-x/topics/kudu_schema_design.html
column设计
非主键可为空，支持如下类型
8、16、32、64位整数
timestamp(64位)
float(32位)
double(64位)
decimal
string(utf-8，最大为压缩前64k)
binary(最大为压缩前64k)
与hbase不同的是，kudu不提供version或timestamp字段来track row的修改，如果需要，schema应该包括一个显式的version或timestamp字段(咋指定呢?)
decimal类型
位数最多为38，
位数9以下4字节，10到18 8字节，18以上，16字节
列编码
主键设计
kudu创表得指定主键，插入已经存在的主键会报错，一旦表被创建，主键不能更改，kudu不支持自增id，但是可以用uuid，删除和更新数据必须指定完整的主键，kudu不支持range删除or更新(疑问？删除必须指定主键？那我们在impala执行delete from table的时候，是impala把所有主键交给kudu然后删除吗，不支持range？那批量的时候也是impala把所有主键交给kudu？)
当数据插入后，主键的值不能被更新，但是可以删掉，然后重新插入
主键索引
类似关系型数据库，kudu的主键用的是clustered索引，所有的行按主键排序，scan kudu表时，使用= or range是非常高效的
backfill插入的注意事项
讨论主键是timestamp的情况，或者主键中第一个字段是timestamp，每次插入一行数据，kudu都会在主键索引中检测是否存在。担心翻译的扯淡，将原文粘过来
In the typical case where data is being inserted at the current time as it
arrives from the data source, only a small range of primary keys are "hot".
So, each of these "check for presence" operations is very fast. It hits
the cached primary key storage in memory and doesn’t require going to disk
数据被插入当它从数据源到达kudu的时候，仅仅一小部分主键是"hot"，（意思这部分主键在内存中），所以每次检测主键是否存在是非常快的，它hit(类似指示标明的意思吧)，那部分主键是在内存中的，不需要在磁盘检查.
有时候，需要load历史数据，叫做backfill，插入的每一行可能都在"cold'区域，导致更多的磁盘seek，例如，正常insert，可能每秒百万级，backfill可能几千
如何解决backfill?
1.使主键有更好的压缩性
例如主键的第一个字段是32位的随机Id(uuid吗？),缓存1亿条至少需要32G内存，也就是如果是8位的话放的更多，命中率更高
2.使用ssd固态
3.更改主键结构，使得backfill写入能命中连续的主键
(不知道啥意思，怎么能命中连续的主键？还有就是怎么让主键都缓存在内存里，后面得测试下，
1种是表里有数据，然后往里upsert或insert，一种是空表，往里insert，瞅瞅到底多大差别)
分区，
目标，写入可以分布在多个分区上，对于short scan如果可以只扫描一个分区，可以提高性能
range分区
分区键必须是主键的子集
range分区一般分区键都是基于时间的，所以可以动态添加删除而不影响别的分区
range分区对scan有优势，可以通过分区裁剪不对某些分区scan,但写的时候会有热点问题，只向某个分区写入
第一种是无边界range分区，第二种是有边界分区，两种分区可能都有热点问题，但第二种更加灵活，可以将未来的数据添加到新建的分区，而第一种，以后的数据都会在最后一个分区
hash分区
写入的时候不会有热点问题，与范围分区一样，分区键是主键的子集
当数据量不断增加时，可能单分区会很大，影响并行度
两种分区的比较
可以看到range分区写会有“热点”问题，而scan的话，可以修建掉更多分区，不止有=，还有range谓词，当表不断增大时，可以通过添加新分区
而hash分区，写会写到所有分区，scan只有=可以来修建分区(待我测试完再来更新这)，分区可能会很大
多级(mulitilevel)分区
既有range、也有hash分区，中和两种分区优缺点
以上示例，如果写入2017年的数据，会有4个并行度，写到4个分区种
分区修剪
很重要，担心翻译的扯，贴出来
Kudu scans will automatically skip scanning entire partitions when it can
be determined that the partition can be entirely filtered by the scan
predicates. To prune hash partitions, the scan must include equality
predicates on every hashed column. To prune range partitions, the scan must
include equality or range predicates on the range partitioned columns.
Scans on multilevel partitioned tables can take advantage of partition
pruning on any of the levels independently.
scan将自动跳过整个分区当kudu可以确定该分区可以被全部过滤通过scan谓词(hash分区怎么跳过呢?)，为了修建hash分区,scan必须包括=谓词在每个hash分区键上（看来只能=，别的都不会skip）
为了修建range分区，scan必须包括=or range谓词(between，大于，小于应该都是吧)。scan多级分区，可以都是用两种分区的修建
修改schema
1.rename table
2.rename 主键
3.rename、添加、删除非主键
4.添加、删除range分区