Kudu在使用过程中的各种限制（官方）

Kudu在使用过程中有各种限制，或者说叫注意事项，我结合官方文档和自己的经验进行了如下总结。

Schema

主键

• 表创建后，主键不能修改。必须删除重建表指定新的主键。
• 主键列必须在非主键列之前
• 主键列的值不能使用UPDATE函数修改。如果要修改主键的值只能删除该行重新插入。
• DOUBLE、FLOAT或BOOL类型的列不能作为主键，此外，主键列必须为NOT NULL。
• 不支持自动生成的主键（如自增列）
• 组合主键的所有列在编码后，大小不能大于16K

列

• 不支持CHAR、VARCHAR、DATE和数组等复杂类型。
• 不能通过ALTER TABLE更改现有列的类型和是否可为空属性
• DECIMAL类型列的精度和规模不能通过ALTER TABLE进行修改（Kudu 1.7+才支持decimal类型）
• 表最多可以有300列。

表

• 表的副本数必须为奇数，最多为7。
• 副本数在建表时指定，之后无法更改。

单元格

• 单个单元格的值在编码或压缩前不能大于64KB。

其他使用限制

• kudu主要是为分析用例设计的，如果单行中包含多个千字节的单元格，则可能会遇到问题。
• 不支持二级索引。
• 不支持多行事物。
• 不支持外键等关系特性。
• 表名和列名必须为有效的UTF-8字符串，最大长度为256个字符。
• 删除列并不会立即释放空间，compaction运行后才会释放。
• 无法手动执行compaction，但是删表会立即释放空间。

分区限制

• 表必须使用简单或复合主键手动分区。目前不支持自动分区。
• Range 分区可以在建表后添加或删除。
• 表中已有的数据无法重新自动分区。有一种解决方案，创建一个新表并制定新的分区，然后将旧表的数据插入新表。
• 失去大部分副本的tablet（比如三个副本中的一个）需要人工干预才能恢复。

集群管理

• 不支持机架感知。
• 不支持多数据中心。
• 不支持滚动重启。

服务器管理

• 生产部署时应该为tablet server分配至少4G内存，在接近数据和tablet的限制时，最好配置大于16G的内存。
• 预写日志（WAL）只能存储在磁盘上。
• 磁盘故障是无法容忍的，一旦检测到磁盘故障，tablet server就会崩溃。
• 无法恢复数据的磁盘需要格式化该tablet server的所有Kudu数据，然后才能重新启动。
• 无法添加或删除数据目录，必须对所有目录进行重新格式化以更改目录集。
• Tablet servers不能优雅地退役。
• 不能更改tablet servers的地址和端口。
• Kudu对时钟同步有严格的要求，一旦时钟不同步，Kudu的master和tablet server就会崩溃。
• Kudu发行版只在NTP中进行过测试，其他时钟同步程序不保证能正常工作。

规模

• 建议tablet server最多为100台。
• 建议master最多为3个。
• 建议的最大数据存储量为，复制和压缩后，每个tablet server 8TB。
• 建议每个tablet server管理的tablet为2000，包含tablet的副本。
• 在创建表时，每个Tablet server的每个表的最大tablet数为60。

基于以上限制，可以推测出一下内容：

•  Kudu中存储的总数据量建议为：tablet server总数*单个tablet server的数据量=100*8TB=800TB，即Kudu不适用于存储PB级数据。
• 单个tablet的数据量建议为：单个tablet server的数据量/每个tablet server中tablet的总数=8TB/2000=4G。Kudu支持的压缩方式有LZ4, Snappy，或zlib。鉴于各种压缩算法的压缩比一般不超过50%，则每个tablet中的数据量在压缩前的大小建议应小于2G。

复制和备份

• kudu目前没有任何内置备份和恢复功能。建议用户在必要的时候使用spark或impala等工具导入或导出表。

其他已知的问题

• 如果Kudu master配置了-log_force_fsync_all选项、 tablet servers和客户端将经常超时，集群可能变得不可用。
• 如果一个tablet server 有大量的tablet，启动可能需要几分钟。建议将每台服务器的平板电脑数量限制在100或更少。在预拆分表时，请考虑这个限制。如果您注意到启动时间较慢，您可以在web UI中监视每个服务器的tablet数量。
• Kerberos身份验证在主机名中包含大写字母的主机上不能正常运行。
• 如果在krb5.conf中配置rdns = false，Kerberos身份验证将不能正常工作。