01大数据集群节点规划
1.HDFS集群节点规划
假如业务系统数据量每天增量 50T，保留周期为 30 天，那么 HDFS 存储 容量为 50T * 30 天 * 3 副本 * 2 倍（数据源+清晰加工） = 9000T = 8.79P 。假如每个机器的磁盘是 4T * 10 = 40T, 每台机器的可用存储容量为 40T * 0.75 = 30T， 节点预估数量= 9000T / 30 = 300 节点，所以 datanode 的节 点最小数量为 300 个。
2.YARN集群节点规划
根据任务量和性能评估 YARN 的节点数是很难的，难以评估，所以 NodeManager节点数可以和datanode节点数保持一致，如果算力负载过高， 根据实际情况再扩容即可。
3.HBase集群节点规划
HBase 节点规划：一般开始搭建是根据 HDFS 存储公式计算即可，如果从增加并发的考虑，一般一个 RegionSever 并发为 5000 ~2 万（优化后并发更高）， 可以根据业务实际并发估计节点数量。
4.Kafka集群节点规划
Kafka 节点规划：一般开始搭建是根据类似 HDFS 存储公式计算，一般1个 broker 并发为 5 万（优化后并发更高），可以根据业务实际并发估计节点数量。
5.Zookeeper集群节点规划
Zookeeper 节点规划：集群开始搭建时3节点就够用了，如果发现 zookeeper 负载过高或有超时现象时可以考虑扩展到 5 节点。
6.大数据集群厂商选择
集群中的每个组件要做高可用，一般国企会用 CDH，互联网公司会用开源社区版演化自己平台。
02大数据集群硬件规划
1.磁盘阵列概念
RAID：磁盘阵列（Redundant Arrays of Independent Disks，RAID），有"数块独立磁盘构成具有冗余能力的阵列”之意。
RAID0 是把多个(最少2个)硬盘合并成1个逻辑盘使用，数据读写时对各硬盘同时操作，不同硬盘写入不同数据，速度快。
RAID1是通过磁盘数据镜像实现数据冗余，在成对的独立磁盘上产生互为备份的数据。当原始数据繁忙时，可直接从镜像拷贝中读取数据，因此RAID 1可以提高读取性能。RAID 1是磁盘阵列中单位成本最高的，但提供了很高的数据安全性和可用性。当一个磁盘失效时，系统可以自动切换到镜像磁盘上读写，而不需要重组失效的数据。
Raid5是把硬盘设备的数据奇偶校验信息保存到其他硬盘设备中，“parity”部分存放的就是数据的奇偶校验信息，换句话说，Raid5技术实际上没有备份磁盘中的真实数据，而是当硬盘设备出现问题后，通过奇偶校验技术来尝试重建损坏的数据。Raid5这样的技术特性 “妥协”的兼顾了硬盘设备的读写速度、数据安全性与存储成本问题。
Raid10是Raid1和Raid0的组合体，Raid10技术至少需要4块硬盘来组建，其中先分别两两制成Raid1磁盘阵列，以保证数据的安全性。然后再对两个Raid1磁盘按阵列实施Raid0技术，进一步提高硬盘设备的读写速度。
2.HDFS集群硬件规划
内存：NameNode 内存一般 100 万个 block 对应 1G 的堆内存，比如我们最大的一个集群的 block 达到了 9000 万，会占内容 90G，NameNode 的内存不止存放 block，我们产线环境配置的是 200G+。
磁盘：主节点NameNode主要 CPU/内存配置高些，系统盘做 RAID1，hdfs要安装在系统盘上，如果有其他的数据盘，可以做 RAID5，容量所需不大，500G~ 1T 即可。
从节点 datanode 内存/CPU/磁盘都有要求，我们产线存储每服务器 4T*10=40T 台
备注：DataNode对磁盘要求比较高。
3.YARN集群硬件配置
主节点 ResourceManager 主要 CPU/内存配置高些，系统盘做 RAID1，yarn要安装在系统盘上，如果有其他的数据盘，可以做 RAID5，容量所需不大， 500G~1T 即可。
备注：因为ResourceManager要做调度，所以CPU可以分配多一点，内存不用太大。
从节点 NodeManager 对 CPU 和内存都有要求。
备注：NodeManager一般与DataNode共用节点，对内存要求不是很高，主要是计算。
4.HBase集群硬件配置
主节点 Master CPU 内存中配就行。
从节点 RegionServer 内存可以大些。
备注：RegionServer对内存要求较高，blockcache和Memstore都需要占用内存。
5.Kafka集群硬件配置
03大数据集群目录规划
1.管理节点的系统盘与数据盘
OS磁盘建议RAID1，建议200G以上，并且做LVM（逻辑卷），这样可以动 态调整OS空间大小，安装包需要安装在OS盘，namenode的fsimage/editlog、jouralnode的/editlog、zookeeper的数据日志都放在OS盘（RAID1）。
管理节点的数据盘做RAID5，管理节点的数据盘如下所示：
2.数据节点的数据盘
数据节点的数据盘做RAID0（一块盘做RAID0，硬件RAID）作为数据盘，文件格式为xfs，并配置noatime，不做LVM，最好是同构。数据节点的数据盘：
备注：数据盘大小建议一致，避免数据不均衡；磁盘不能做LVM，避免影响存储性能。
04Kafka Topic分区规划
1.Kafka磁盘规划
- 步骤1：评估数据量：要求研发提前评估所有topic 一个周期全量的数据大小。
- 步骤2：计算磁盘总存储：如一块盘 825g，一个节点 20 块盘，10 个节点。那
么磁盘总存储就是 165000g。
- 步骤3：预估实际数据存储占比：Topic:一个周期全量数据大小占磁盘总存储的百分比，超过百分之六十，即要求研发减少存储周期。
- 步骤4：计算磁盘总块数：一个节点 20 块盘，10 个节点，总磁盘块数 200 个。
2.Kafka Topic分区方式1
合理预分区：所有分区数量为磁盘总数的整数倍。如所有的 topic 总数据量为 50000g，磁盘个数为 200，那么就可以设置总分区数为 200/400/600.具体多少分区数视业务决定。若分区数为 400，那么一个分区的大小约 125g。
案例1：
某一个 topic：cbss001 的预估数据量是 210g，那么通过计算（每个分区：125g）可以将其分成两个分区。这样根据 kafka 副本落盘策略，各个主机磁盘就能保证最大限度的存储均衡。
案例2：
如果我们建立了一个非常大的 topic（100个分区），那么此 topic 的分区数量应该是磁盘数的整数倍；如果说我们还有建立一个小的 topic（如10个分区），那么此 topic 的每个分区大小应该跟之前的大的 topic 分区的大小保持一致。
3.Kafka Topic分区方式2
确定分区数量的方法：
（1）创建一个只有1个分区的topic
（2）测试这个topic的producer吞吐量和consumer吞吐量。
（3）假设他们的值分别是Tp和Tc,单位可以是MB/s.
（4）然后假设总的目标吞吐量是Tt,那么分区数=Tt/min（Tp,Tc）
kafka性能基准测试：
（1）Kafka Producer压力测试
bin/kafka-producer-perf-test.sh --topic test --record-size 100 --num-records 100000 --throughput -1 --producer-props bootstrap.servers=hadoop1:9092,hadoop2:9092,hadoop3:9092
说明：
record-size是一条信息有多大，单位是字节。
num-records是总共发送多少条信息。
throughput 是每秒多少条信息，设成-1，表示不限流，可测出生产者最大吞吐量。
（2）Kafka Consumer压力测试
bin/kafka-consumer-perf-test.sh --broker-list hadoop1:9092,hadoop2:9092,hadoop3:9092 --topic test --fetch-size 10000 --messages 10000000 --threads 1
参数说明：
--zookeeper 指定zookeeper的链接信息
--topic 指定topic的名称
--fetch-size 指定每次fetch的数据的大小
--messages 总共要消费的消息个数
05HBase 表Region规划
1.业务场景
每天写入5亿+条数据
每天写入176G+数据量
region分裂大小为10G
TTL为20天
rowkey为手机号
2.预建分区个数
预建分区的个数=最终保有的数据量/每个regin配置的大小
（1）Region最大值推荐10-20Gb, 最优值推荐5-10Gb。
（2）数据总量=176*20=3520G
3.预分区实现
方法一：
admin.createTable(tabledesc,startkey,endkey,numRegion)
方法二：
admin.createTable(tableDesc ,splitKeys);
