Kudu节点数规划

南墨2年前技术文章642

一、概述

由于Kudu是Hadoop生态的一部分(虽然它不依赖于Hadoop生态系统),因此大多数实际应用场景需要的不仅仅是Kudu;为了输入数据,可能需要Kafka、StreamSets或Spark Streaming;对于机器学习和数据处理,可能需要Spark;对于交互式SQL,我们也肯定想要Impala。实际上,Kudu和Hadoop生态系统紧密低集成正是其优势之一,因此我们很少单独使用Kudu,所以,在讨论Kudu集群规划时,一般不仅仅是考虑到Kudu。

举个例子:Kudu经常与Impala一起使用,Impala依赖Hive,而Hive依赖于HDFS,这就意味着我们将Kudu与Impala放在一起使用,而且还要配上Hive和HDFS。根据以往经验:Kudu和HDFS很容易和谐共存,甚至可以共享磁盘,但是我们要正确配置它们。

二、资源规划

1、Master

Master服务器负责存储元数据信息(客户端应用程序定位数据的位置时需要用到它们),一般不会频繁操作master,可以在小服务器(硬件)上安装;一般3台即可(与复制因子数相同,为奇数)

2、Tablet

Tablet的作用是执行所有与数据相关的操作:存储、访问、编码、压缩、compaction和复制,且tablet还负责将数据复制到其他tablet服务器上,工作较为繁重,是我们需要可扩展性的地方。

规划建议与限制

选项

最佳性能(建议值)

限制

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

三、集群规模

1、节点数

Master 必须是奇数,3或者5台为佳,7台就多

Tablet Server 取决于数据规模,但最多不超过1000台的规模,以300以内性能最佳

2、tserver服务器数量 公式

t=d/(k*(1-p))*r

t

tserver数量

d

以Parquet格式存储的数据总量(可以将一段时间的数据以Parquet格式存储到HDFS上做预估)

k

每个Tablet Server的最大磁盘容量(建议8T)

p

余量,一般0.25

r

tablet副本因子,一般为3

eg.

d=120T
K=8T
p=25%
r=3
t=(120 / (8 * (1 - 0.25)))*3 = 60

四、内存和CPU

角色

内存

CPU

说明

Master

16G

8C

Master不保存用户数据,对于内存,CPU占用资源bitserver要少很多

Tablet Server

64G

2*12C

考虑跟Impala混合部署场景(有datanode和nodemanager会更大)

五、磁盘

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*2TSSD,用于存储数据

注:

1)这里NVMe是一种非常快速的PCIe闪存适配器(考虑到负载,最好为WAL规划配置快速SSD NVMe),特别是对于大型生产环境,不建议将WAL设置到专门的HDD上,这样会影响写入性能和故障的恢复时间。

性能对比:

存储介质

IOPS

吞吐率(MB/s)

HDD

55~180

50~180

SSD

3000~40000

300~2000(SAS最大能达到2812MB/s)

NVMe PCIe闪存

150000~1000000以上

最大为6400(6.4GB/s)

2)WAL、metadata、data 配置目录
–fs_wal_dir
–fs_metadata_dir
–fs_data_dirs

3)对于Kudu上的用户数据,在服务器上提供尽可能多的HDD(SSD更好!);另外对于已经部署了HDFS的集群,与Kudu公用节点时,不必专门分开磁盘,将他们共用数据盘即可。

六、网卡

Master和Tablet Server和 2块万兆网卡绑定

参考:

https://kudu.apache.org/docs/known_issues.html


相关文章

Ldap高可用部署

Ldap配置高可用两个节点上均执行mkdir /data/ldapcd /data/ldap1.1. 添加mod_syncprov.ldif文件vi mod_syncprov.ldif 内容如下:ob...

Kafka优化参数

一、配置文件Kafka的配置文件为 config/server.properties,在此文件中进行 Kafka 的基础配置,例如端口、日志目录、Zookeeper 信息和 Broker ID 等还可...

企业级大数据安全架构(一)

前言1.企业级大数据平台安全隐患目前企业级大数据平台面临的一些安全隐患,只要将这些安全隐患全部解决之后才可以部署到生产环境去使用,因此安全性是大数据平台必备的能力之一。1.1缺乏统一的访问控制机制大数...

ES运维(五)聚合分析流程及精准度

ES运维(五)聚合分析流程及精准度

1、 概述ES是一个近实时的搜索引擎,提供近实时海量数据的聚合分析功能,但这个海量数据聚合分析是会损失一定的精准度来满足实时性能需要的。 2、 分布式系统的近似统计算法如下图,在分布式数据分...

oracle安装gi执行root.sh报错:PRCR-1079 : Failed to start resource ora.cvu

1、具体报错如下:安装gi执行root.sh报错:PRCC-1014 : LISTENER_SCAN1 was already runningPRCR-1004 : Resource ora.LIST...

MySQL 复制延迟是如何计算的?

MySQL 复制延迟是如何计算的?

前言日常运维中总会收到 MySQL 备库延迟告警,一般数据库监控只读实例延迟都是采集 Seconds_Behind_Master 值,我们都知道它在某些场景下不可靠,今天一起探索 MySQL 是如何计...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。