机架感知
Kudu可以知道每个Tablet Server处于哪个数据中心的哪个机架上,副本的负载均衡策略就可以考虑更全面,避免一个tablet的多个副本负载在同一机架,防止机架故障时tablet不可用。
上图中，L0-L2是三个机架，TS0 -TS5是5台Tablet Server，有两张表：
A表(副本因子=3)，包含A0-A3四个tablets
B表(副本因子=5)，包含B0-B2三个tablets
如果Kudu配置了机架感知，它就会发现上面的tablet分布违背了相关规则：
副本A0.0和A0.1构成了大多数副本（三分之二），并且位于相同的位置/ L0中，一旦L0机架电源或者交换机故障，将只有L1上的A0.2一个tablet副本可用且无法选择出leader（根据Raft协议必须 n/2+1 个副本正常才可以选举，n=总副本数）
B表的大多数副本集中在TS0-TS4，而TS5非常空闲，在即考虑机架分布式由考虑负载均衡的前提下，需要把B表的相关副本往TS5挪一挪
经过手工负载均衡，负载可能会变成如下样子
透明分层存储管理方案
- 存储选择方法
Kudu是为快速数据上的快速分析场景而生的，但是Kudu的成本并不低，且扩展性并没有那么好（tserver的个数不能太多）
HDFS旨在以低成本实现无限的可扩展性。它针对数据不可更改的面向批处理的场景进行了优化，当使用Parquet文件格式，可以以极高的吞吐量和效率访问结构化数
对于数据比较小且不断变化的数据（例如维表）通常全部存放到Kudu当数据不会超过Kudu的扩展范围限制，且能够从Kudu的独特功能中受益时（快速变化、快速分析），通常作为大表保存在Kudu
当数据量非常大，面向批处理且基本不太可能变更的情况下首选以Parquet格式将数据存储在HDFS中（冷数据）
2.基于滑动窗口的透明存储管理方案
当您需要两个存储层的优势时，滑动窗口模式是一个有用的解决方案。该方案的主要思路是：
使用Impala创建2张表：Kudu表和Parquet 格式的HDSF表这两张表都是按照时间分区的表，分区粒度取决于数据在Kudu表和HDSF表之间迁移的频率，一般是按照年或者月或者日分区，特殊情况下可以更细粒度在Impala另外创建一个统一视图，并使用where字句定义一个边界，由该边界决定哪些数据该从哪个表读取Kudu中变冷的数据分区会定期的被刷写到HDFS（Parquet ）数据刷写之后，在HDFS表新增分区、使用原子的ALTER VIEW 操作把视图的边界往前推移
优点;
流式数据可立即查询
可以更新迟到的数据或进行手动更正
HDFS中存储的数据具有最佳大小，可提高性能并防止小文件降低成本
- 数据从Kudu迁到HDFS的过程
数据从Kudu迁移到HDFS需要经过下面两个步骤，该过程需要定时自动调度
数据迁移在第一阶段，将现在不变的数据从Kudu复制到HDFS。 即使将数据从Kudu复制到HDFS，在视图中定义的边界也将阻止向用户显示重复数据。 此步骤应该包含检查机制，以确保成功完成数据的迁移和卸载。
元数据修改
在第二阶段，既然已将数据安全地复制到HDFS，则更改元数据以调整如何显示卸载的分区。 这包括向前移动边界，添加下一个时间窗口的新的Kudu分区以及删除旧的Kudu分区。
索引跳跃式扫描优化
CREATE TABLE metrics (
host STRING,
tstamp INT,
clusterid INT,
role STRING,
PRIMARY KEY (host, tstamp, clusterid)
);
Kudu在内部会创建主键索引（B-tree），跟上表类似，索引数据按所有主键列的组合排序。当用户查询包含第一主键列（host）时，Kudu将使用索引（因为索引数据主要在第一个主键列上排序）
如果用户查询不包含第一个主键列而仅包含tstamp列怎么办？tstamp虽然在固定host下是有序的，但全局是无须的，所以无法使用主键索引。在关系型数据库中一般采用二级索引，但是Kudu并不支持二级索引
tstamp之前的列为“prefix column”，列的具体值为“prefix
key”，在咱们的例子中host就是prefix column。在索引中首先按照prefix key排序，相同的prefix key在按照剩余列的值排序，因此可以使用索引跳转到具有不同prefix key且tstamp满足条件的行上
SELECT clusterid FROM metrics WHERE tstamp = 100，其余的是跳过的。Tablet Server使用索引（ prefix key (host =
helium)+tstamp = 100）跳过不匹配的行直接到达第三行并逐步扫描直到不匹配tstamp = 100，就通过下一个prefix key (host = ubuntu)+tstamp = 100继续跳过不匹配的行。其余prefix key采用相同的做法，这就叫做Index Skip Scan优化
性能
索引跳跃式扫描优化的性能与前缀列（prefix column）的基数（prefix key去重后的数量）负相关
host的基数越低，跳跃扫描性能越高，反之则性能越差。
前缀列基数很高时，索引跳跃式扫描优化就不可取了
在每个tablet一千万行的数据规模下，当【前缀列host基数>sqrt(number_of_rows_in_tablet)】时，索引跳跃式扫描性能开始下降。 为了解决这个问题：
Kudu目前在【跳跃次数>sqrt(number_of_rows_in_tablet)】时自动禁用跳跃扫描优化
资源规划
在做资源规划是重点考虑的是tserver，master负载要小很多，回顾已知tserver相关的建议和限制如下
选项 最佳性能(建议值) 限制
tablet server数 不超过100 300+
tablet数/tablet server（含副本） 1000+ 4000+
tablet数/表/tablet server（含副本） 60+ 60+
单台tablet server存储数据（含副本，压缩后） 8TB+ 10TB+
单tablet存储数据（超过会性能下降、合并失败、启动慢） 10G 50G
单tablet对应CPU核心数（不考虑副本，不考虑小表） 1 多对1
tablet server内存 16G以上最佳 不低于4G
集群规模
Master 必须是奇数，3或者5台为佳，7台就多
Tablet Server 取决于数据规模，但最多不超过1000台的规模，以300以内性能最佳
这里有一个预估tserver服务器数量的公式供参考：t=d/(k∗(1-p))∗r
t:tserver数量
d: 以Parquet格式存储的数据总量（可以将一段时间的数据以Parquet格式存储到HDFS上做预估）
k: 每个Tablet Server的最大磁盘容量（建议8T）
p: 余量，一般0.25
r:tablet副本因子，一般为3
示例：
d=120T
K=8T
p=25%
r=3
t=(120 / (8 * (1 - 0.25)))*3 = 60
内存和CPU
磁盘
跟HDFS不一样，Kudu针对SSD做了特别优化，推荐使用SSD
| 角色 | OS | WAL | metadata | data |
|---|---|---|---|---|
| master | 2*512 SSD RAID 1 | 共享OS | 共享OS | 共享OS |
| tablet server | 2*512 SSD RAID 1 | 12TM.2接口(NVMe协议)SSD | 共享WAL | 7*2T SSD，用于存储数据 |
WAL、metadata、data 配置目录
–fs_wal_dir
–fs_metadata_dir
–fs_data_dirs
网卡
Master和Tablet Server和 2块千兆网卡绑定
性能调优
硬件层面优化
tserver的WAL采用M.2接口(NVMe协议) SSD,Kudu的每一次写入都会先写WAL，WAL是确保数据不丢失的关键，所以一般都会同步写磁盘（顺序写），为了提高性能建议tserver采用M.2接口（NVMe协议）SSD来存储WAL，至少也得是普通SD（master读写压力小，跟操作系统共享SSD即可）
–fs_wal_dir=/data/kudu/tserver/wal
数据存储多SSD
tserver负责数据的读写和复制，压力比较大，建议采用多SSD分散读写IO。
fs_data_dirs=/disk1/kudu/tserver/data,/disk2/kudu/tserver/data,/disk3/kudu/tserver/data
操作系统层面优化
操作系统会控制每个用户使用的文件描述符和线程数，Kudu作为数据库肯定比一般应用需要更多文件描述符和线程数
如果Kudu使用的线程数超过OS的限制，你会在日志中看到如下报错：
pthread_create failed: Resource temporarily unavailable
降低或者禁用swap使用交换区会导致性能下降，建议降低swap的使用
sudo su -
echo ‘vm.swappiness=10’>> /etc/sysctl.conf
exit
上面参数重启才能生效，可以同时搭配如下命令避免重启：
sudo sysctl vm.swappiness=10
cat /proc/sys/vm/swappiness
检查当前是否生效
cat /proc/sys/vm/swappiness
配置调优
tserver内存限制
Tablet Server能使用的最大内存量，tablet Server在批量写入数据时并非实时写入磁盘，而是先Cache在内存中，在flush到磁盘。这个值设置过小时，会造成Kudu数据写入性能显著下降。对于写入性能要求比较高的集群，建议设置更大的值 ：
–memory_limit_hard_bytes
还有两个软限制：
Cgroup 内存软限制，这个限制并不会阻止进程使用超过限额的内存，只是在系统内存不足时，会优先回收超过限额的进程占用的内存，使之向限定值靠拢,当进程试图占用的内存超过了cgroups的限制，会触发out of memory，导致进程被kill掉
–memory_limit_soft_percentage=80
tserver维护管理器线程数
Kudu后台对数据进行维护操作，如写入数据时的并发线程数，一般设置为4，建议的是数据目录的3倍
–maintenance_manager_num_threads=6
调大tserver block cache容量,分配给Kudu Tablet Server块缓存的最大内存量，建议是2-4G
–block_cache_capacity_mb=2048
避免磁盘耗尽,为避免磁盘空间耗尽，应该保留一部分空间：#默认-1，表示保留1%的磁盘空间，自己配置是必须大于0
–fs_data_dirs_reserved_bytes
容忍磁盘故障
如果某个tablet的数据分散到更多的磁盘，则数据会更加分散，这个值越小每个tablet的数据会更加集中，不过受磁盘故障影响就越小。
#每个tablet的数据分散到几个目录
fs_target_data_dirs_per_tablet=3
扫一扫
5035
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
