kudu规范使用

kudu规范使用

1.kudu设计和使用规范，为数据研发、数据设计人员提供设计的基础参考。

2. Schema设计

Kudu表和关系型数据库的表相似，都有着结构化的数据模型。对于最佳性能和操作的稳定性来讲，schema的设计至关重要。没有哪一种schema能够适用于所有的表。

创建Kudu表时，涉及到列设计、主键设计和分区设计。对于传统的非分布式关系型数据库来讲，只有分区是新概念。

3. 优雅的schema

优雅的schema应该具备以下条件：

数据的读写均匀分布到每个tablet server，这一点主要受到分区的影响。

tablet能够以稳定、可预测的速率增加，加载的数据保证全天候可用，这主要受到分区的影响。

扫描时读取最少的数据量，这一点主要受主键设计的影响，但分区也会起到重要作用。

好的shema设计依赖于数据特征、对数据操作什么以及集群的拓扑结构。Schema设计对于kudu集群性能最大化来说是最重要的事情。

4. Column设计

4.1. 数据类型Kudu表包含多个列，每个类都有类型，非主键列可以为null。支持的列类型有：

布尔8位有符号整数16位有符号整数32位有符号整数64位有符号整数unixtime_micros（Unix时代以来的64位微秒）单精度（32位）IEEE-754浮点数双精度（64位）IEEE-754浮点数十进制（详见十进制类型）UTF-8编码字符串（最多64KB未压缩）二进制（最多64KB未压缩）Kudu利用强类型列和列式磁盘存储格式来提供高效的编码和序列化。为了充分利用这些功能，应将列指定为适当的类型，而不是使用字符串或二进制列来模拟“无模式”表。除了编码之外，Kudu还允许在每列的基础上指定压缩。

//没有版本和时间戳列 ,同hbase不同，kudu没有提供version和timestamp列来跟踪行的变化。如果需要的话，需要自行设计一列。

4.2. Decimal类型该类型是具有固定标度和精度适合于金融等算术运算，float与double的不精确表示和舍入行为比较不切实际。该decimal类型对于大于int64的整数和主键中具有小数值的情况也很有用。

精度：表示列可以表示的总位数，无论小数点的位置如何。此值必须介于1和38之间，并且没有默认值。例如，精度为4表示最大值为9999的整数值，或者表示最多99.99的值，带有两个小数位。您还可以表示相应的负值，而不会

对精度进行任何更改。例如，-9999到9999的范围仍然只需要4的精度。

刻度：表示小数位数。该值必须介于0和精度之间。刻度为0会产生整数值，没有小数部分。如果精度和刻度相等，则所有数字都在小数点后面。例如，精度和刻度等于3的小数可以表示介于-0.999和0.999之间的值。

性能考虑：Kudu将每个值存储在尽可能少的字节中，具体取决于decimal指定的精度。因此，为方便起见，不建议尽可能使用最高精度。这样做可能会对性能，内存和存储产生负面影响。

在编码和压缩之前：

精度为9或更小的十进制值以4个字节存储。

精度为10到18的十进制值以8个字节存储。

精度大于18的十进制值以16个字节存储。

alter命令不能修改的列的精度和刻度

4.3. 列编码可以根据列的类型进行编码。

列类型

编码

默认

int8, int16, int32

plain, bitshuffle, run length

bitshuffle

int64, unixtime_micros

plain, bitshuffle, run ength

bitshuffle

float, double, decimal

plain, bitshuffle

bitshuffle

bool

plain, run length

run length

string, binary

plain, prefix, dictionary

dictionary

4.3.1. Plain encoding数据以其自然格式存储。例如，int32 值存储为固定大小的32位little-endian整数。

4.3.2. Bitshuffle编码重新排列一个值块以存储每个值的最高有效位，然后是第二个最高有效位，依此类推。最后，结果进行LZ4压缩。 如果值重复的比较多，或者按主键排序时值的变化很小，Bitshuffle编码是一个不错的选择。

4.3.3. 运行长度编码对连续的重复值采用压缩存储，主要是通过只存储值和个数。该编码对按主键排序时具有许多连续重复值的列有效。

4.3.4. 字典编码创建一个字典存放所有的值，每个列值使用索引进行编码存储。如果值的个数较少，这种方式比较有效。反之Kudu将透明地回退到该行集的纯编码。这在flush期间进行评估计算。

4.3.5. 前缀编码在连续的列值中对公共前缀进行压缩。对于有公共前缀的值或主键的第一列或许有效，因为tablet中的行是通过对主键排序存储的。

4.3.6. 列压缩Kudu允许列使用压缩LZ4、Snappy或zlib压缩编解码器。默认情况下，不进行压缩。如果减少存储空间比原始扫描性能更重要，请考虑使用压缩。

每个数据集的压缩方式都不同，但一般来说LZ4是性能最佳的编解码器，而zlib空间压缩比较大。Bitshuffle编码的列自动使用LZ4压缩，因此不建议在此编码之上应用其他的压缩。

5. 主键设计

主键列必须是非可空的，并且不可以是boolean，float或double类型。

表创建指定主键后，就不能更改。

与RDBMS不同，Kudu不提供列的自增，因此应用程序必须提供完整的主键。

删除和更新时必须指定完整主键。Kudu本身不支持范围删除或更新。即都是通过主键完成操作。

主键值无法修改。但是，可以删除后重新插入曲线救国。

5.1. 主键索引与许多传统的关系数据库一样，Kudu的主键是聚簇索引。tablet中的所有行都按主键排序的。 扫描Kudu行时，在主键列上使用相等或范围过滤可以有效地查找行。

5.2. 回填插入的考量这里考虑主键是时间戳或主键的第一列是时间戳的情况。每次插入，kudu都会主键索引存储区域中查找主键看主键是否存在，如果存在，就返回主键重复错误。如果以数据产生的时间作为主键存储，则热点数据就比较少，执行存在性检查时就会比较快，在内存中就可以命中，不需要走磁盘。

如果是离线的历史数据，每次插入都可能会预冷（主键无法在内存中定位），就会访问磁盘，有时甚至是多个磁盘。正常情况下，kudu可以达到每秒几百万次插入，但是如果是回填数据的话，每秒只能维持几千的插入量。

回填数据的性能优化：

使主键更易压缩使用固态盘改变主键结构，使回填主键位于连续的范围中。

6. 分区设计

kudu中的表被分成很多tablet分布在多个tserver上。每一行属于一个tablet。行划分到哪个tablet有分区决定，分区是在表创建期间设置的。

写入频繁时，考虑将写入动作平衡到所有tablet之间能够有效降低单个tablet的压力，对于小范围扫描操作比较多的情况，如果所扫描的数据都为一个tablet上则可以提高性能。

kudu没有默认分区，建表时，kudu不提供默认的分区策略。建议读写都较重的table可以设置和tserver服务器数量相同的分区数。

kudu提供两种类型的分区：范围分区和哈希分区。表可以有多级分区，组合使用范围和哈希或者多个哈希组合使用。

6.1. 范围分区Kudu允许在运行时动态添加和删除范围分区，而不会影响其他分区的可用性。删除分区将删除属于该分区中包含的数据。后续插入到已删除的分区中将失败。可以添加新分区，但它们不得与任何现有范围分区重叠。Kudu允许在单个事务更改表操作中删除和添加任意数量的范围分区。

动态添加和删除范围分区对于时间序列特别有用。随着时间的推移，可以添加范围分区以覆盖即将到来的时间范围。例如，存储事件日志的表可以在每个月开始之前添加月份分区，以便保存即将发生的事件。可以删除旧范围分区，以便根据需要有效地删除历史数据。

6.2. 哈希分区哈希分区按哈希值将行分配到存储桶中的一个。在单级散列分区表中，每个桶只对应一个tablet。在表创建期间设置桶的数量。通常，主键列用作要散列的列，但与范围分区一样，可以使用主键列的任何子集。

当不需要对表进行有序访问时，散列分区是一种有效的策略。散列分区对于在平板电脑之间随机写入非常有效，这有助于缓解热点和不均匀的平板电脑大小。

6.3. 多级分区Kudu允许表在单个表上组合多个级别的分区。零个或多个哈希分区可以与范围分区组合。除了各个分区类型的约束之外，多级分区的唯一附加约束是多级哈希分区不能散列相同的列。

如果使用正确，多级分区可以保留各个分区类型的好处，同时减少每个分区类型的缺点。多级分区表中的平板电脑总数是每个级别中分区数的乘积。

6.4. 修剪分区当通过扫描条件能够完全确定分区的时候，kudu就会自动跳过整个分区的扫描。要确定哈希分区，扫描条件必须包含每个哈希列的等值判定条件。多级分区表的扫描可以单独利用每一级的分区界定。

7. schema修改

您可以通过以下方式更改表结构：

重命名表重命名主键列重命名，添加或删除非主键列添加和删除范围分区可以在单个事务操作中组合多个更改步骤。

8. 已知限制

Kudu目前有一些已知的局限性可能会影响到架构设计。

列数默认情况下，Kudu不允许创建超过300列的表。我们建议使用较少列的架构设计以获得最佳性能。

cell大小在编码或压缩之前，单个单元不得大于64KB。在Kudu完成内部复合密钥编码之后，构成复合密钥的单元限制为总共16KB。插入不符合这些限制的行将导致错误返回给客户端。

行的大小虽然单个单元可能高达64KB，而Kudu最多支持300列，但建议单行不要大于几百KB。

有效标识符表名和列名等标识符必须是有效的UTF-8序列且不超过256个字节。

主键不可变Kudu不允许更新主键列。

不可更改的主键Kudu不允许您在创建表后修改主键列。

不可更改的分区除了添加或删除范围分区之外，Kudu不允许您在创建后更改表的分区方式。

不可改变的列类型Kudu不允许更改列的类型。

分区拆分创建表后，无法拆分或合并分区。

9. 存储限制

kudu单台tablet_server 分区不能超过1500.多台tablet_server 超过1500 则需要进行评估扩容。

tablet server 22台master 5台最大数据存储量为，复制和压缩后，每个tablet server 24TB。每个tablet server管理的tablet为1500，包含tablet的副本。在创建表时，每个Tablet server的每个表的最大tablet数为60。

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

Kudu中存储的总数据量建议为：tablet server总数单个tablet server的数据量=2224TB=528TB/3 =176TB单个tablet的数据量为：单个tablet server的数据量/每个tablet server中tablet的总数=24TB/1500=16G。Kudu支持的压缩方式有LZ4, Snappy，或zlib。鉴于各种压缩算法的压缩比一般不超过50%，则每个tablet中的数据量在压缩前的大小建议应小于8G。kudu单表存储最大数量：8亿

10. 生命周期规范

常规表SUBS层：所有系统的采集数据必须进SUBS层，原则上数据永久存储，可根据实际情况调整（数据量非常大，例如一天数据量大于100 GB），kudu表数据保留12个月(根据实际情况定义),12个月以上的可以转储到hive。

基于kudu存储的数据，根据业务实际需求按照以下定义保留

ODS、DW、DM、ADS层：

当3个月内的最大访问跨度小于或等于4天时，建议将保留天数设为7天。当3个月内的最大访问跨度小于或等于12天时，建议将保留天数设为15天。当3个月内的最大访问跨度小于或等于30天时， 建议将保留天数设为33天。当3个月内的最大访问跨度小于或等于90天时，建议将保留天数设为93天。当3个月内的最大访问跨度小于或等于180天时， 建议将保留天数设为183天。当3个月内的最大访问跨度小于或等于365天时，建议将保留天数设为368天。以上生命周期定义为业界通用定义，可以根据业务实际情况调整。

根据数据域的不同要求存储，配套相应的冷热数据分离存储方案。

对于时间分区表，根据其数据内容的生命周期，定期删除超出生命周期的分去表

中间表根据实际情况设置存储周期，原则上存储周期不大于结果表。

备份表根据实际备份需要设置存储周期。

临时表临时表的最大生命周期为10天，针对临时表生命周期，应配套相应的检测工具和手段，并在删除前做好相关提示。

11 建表规范

1.hash分区最大不能超过60分区

2.Kudu hash分区创建表例子

CREATE TABLE IF NOT EXISTS [db_name.]table_name ( id BIGINT PRIMARY KEY COMMENT '注释', agent STRING COMMENT '注释', ... PRIMARY KEY ( uuid ) ) PARTITION BY HASH (id) PARTITIONS 4 COMMENT '注释' stored AS kudu;

kudu-混合分区例子：

CREATE TABLE cust_behavior_1 ( id BIGINT, sku STRING, salary STRING, edu_level INT, usergender STRING, group STRING, city STRING, postcode STRING, last_purchase_price FLOAT, last_purchase_date BIGINT, category STRING, rating INT, fulfilled_date BIGINT, PRIMARY KEY (id, sku) ) PARTITION BY HASH (id) PARTITIONS 4, RANGE (sku) ( PARTITION VALUES < ‘g’, PARTITION ‘g’ <= VALUES < ‘o’, PARTITION ‘o’ <= VALUES < ‘u’, PARTITION ‘u’ <= VALUES ) STORED AS KUDU TBLPROPERTIES( ‘kudu.table_name’ = ‘cust_behavior_1 ‘,’kudu.master_addresses’ = ‘hadoop5:7051’);

时间分区例子：

CREATE TABLE IF NOT EXISTS k_ods_collect_dw_yarn_apps_resource_ds( app_id string comment'任务ID', use_type string comment'资源使用类别', name string comment'资源名称', ds string comment'日汇总', resource_type string comment'资源类别', maximum_allocation bigint comment'最大分配', minimum_allocation bigint comment'最小分配', shorthand_representation string comment'快速描述', units string comment'单位', value bigint comment'值', collect_time bigint comment'采集时间', PRIMARY KEY (app_id,use_type,name,ds)) partition by hash(app_id,use_type,name,ds) partitions 4, RANGE (ds) ( PARTITION '20201112' <= VALUES < '20210101', PARTITION '20210101' <= VALUES < '20210201', PARTITION '20210201' <= VALUES < '20210301', PARTITION '20210301' <= VALUES < '20210401', PARTITION '20210401' <= VALUES < '20210501', PARTITION '20210501' <= VALUES < '20210601', PARTITION '20210601' <= VALUES < '20210701', PARTITION '20210701' <= VALUES < '20210801', PARTITION '20210801' <= VALUES < '20210901', PARTITION '20210901' <= VALUES < '20211001', PARTITION '20211001' <= VALUES < '20211101', PARTITION '20211101' <= VALUES < '20211201', PARTITION '20211201' <= VALUES < '20220101' ) COMMENT 'k_ods_collect_dw_yarn_apps_resource_ds' stored as kudu;

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。