KUDU(五)kudu优化

机架感知

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挪一挪
经过手工负载均衡,负载可能会变成如下样子
在这里插入图片描述

透明分层存储管理方案

  1. 存储选择方法
    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中存储的数据具有最佳大小,可提高性能并防止小文件降低成本

  1. 数据从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

角色OSWALmetadatadata
master2*512 SSD RAID 1共享OS共享OS共享OS
tablet server2*512 SSD RAID 112TM.2接口(NVMe协议)SSD共享WAL7*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

©️2020 CSDN 皮肤主题: 技术工厂 设计师:CSDN官方博客 返回首页