linux + shell
常用的高级命令
top iotop df -h grep sed awk netstat halt ps
查看进程、查看端口号、查看磁盘使用情况
top ps netstat df -h
常用工具
sed awk cut sort
写过哪些shell 脚本
- 集群启动停止脚本（zk.sh kf.sh xcall.sh myjps.sh xsync.sh）
#! /bin/bash
case $1 in
"start") {
for I in hadoop102 hadoop103 hadoop104
do
ssh $I "绝对路径 start"
done
};;
"stop") {
};;
esac
- 数仓层级导入 ods -> dwd -> dws 5步
#!/bin/bash
定义变量
hive/opt/module/hive/bin/hive
APP=gmall
定义时间
sql="
遇到表，前面加上数据库名称；
遇到时间，$do_date
"
hive -e "$sql"
- 数仓与mysql 的导入和导出
– 主要sqoop
二、Hadoop
入门
- 端口号：
2.x hadoop访问50070 yarn8088 19888 9000
3.x hadoop访问9870 yarn8088 19888 8020 - 需要的配置文件
2.x core-site.xml hdfs-site.xml yarn-site.xml mapreduce.xml 3个env.sh salves(不能有空行、不能有空格)
3.x core-site.xml hdfs-site.xml yarn-site.xml mapreduce.xml 3个env.sh workers
HDFS
- 读写流程（笔试题）只要有原理图
- 小文件
– 危害：nn的内存不够，128G内存能够存128g * 1024m * 1024kb * 1024byte / 150字节（一个文件块占用150字节） = 9亿；计算：一个文件对应一个切片 -> maptask
– 解决办法：har归档【重点】、自定义Inputformat -> 减少nn 内存
– CombineTextInputformat -> 减少切片数 -> 减少maptask
– jvm 重用：开始 - 块大小、副本数
MapReduce [shuffle + 优化]
map 方法之后，reduce 方法之前
128G 内存，给nodemanager100g内存
128m的数据，应该分配1g内存
kafka
Kafka 介绍
Kafka是采用了生产、消费模式，基于topic主题来实现的，即生产者向指定topic生产数据；消费者从topic消费数据。1为了方便拓展并提高吞吐量，一个topic可分为多个partition分区；2配合分区的设计，提出消费者组的概念，组内每个消费者并行消费；3为提高可用性，为每个partition增加若干副本，类似NameNode HA
基础
- 组成：
kafka部署多少台：2 * （峰值生产速度 * 副本 / 100） + 1 = 3 台 - 副本：
-> 2/3个，2个居多；作用：越多可提高可靠性；副作用：增加磁盘IO，降低网络性能 - 压测：
2 * （峰值生产速度 * 副本 / 100） + 1 = 3 台，峰值生产速率小于等于 50m/s - 数据量：
100万日活：每人一天100条，100万 * 100条 = 1亿；1条日志多大 = 0.5~2k，一般取 1K；kafka 平均每秒多少条日志：1亿 / (24*3600s) = 1150条/s，大致一天 1m/s - 什么时候达到高峰？
8~12点，周末，高峰是平时是20倍，20m/s，不要超过 50m/s - 保存时间
默认保存7天；生产环境保存3天 （oppo) 6个小时 - 磁盘大小
100g * 副本2 * 3天/0.7 = - 监控
Kafka eagle，比kafka monitor更友好。自己写的？怎么办？夸他 - 多少topic
满足下一级所有消费者。一张表一个topic
– 小程序 -》 小程序topic
– 公众号 -》公众号topic -》 kafka -》SparkStreaming/Flink解析 -》 kafka
– pc网站 -》pctopic -》 hive dwd 解析 - isr：
leader挂了谁当老大； 在isr队列里面的都有机会；旧版本：延迟时间、延迟条数； 新版本：延迟时间 - 分区数（作用：提高并发度）
先设置一个分区：压测Tp，Tc
总的目标吞吐量和Tt，那么分区数 = Tt / min(Tp, Tc)
例如：producer 吞吐量 = 20m/s； consumer吞吐量=50m/s，期望吞吐量100m/s；分区数 = 100 / 20 = 5分区 - 分区分配策略
Range 默认 和RoundRobin
Range：10个分区，3个消费线程（可能存在数据热点）
1 2 3 4
5 6 7
8 9 10
RoundRobin 所有的分区采用hash 随机打散，轮询方式
挂了
段时间内 flume channel 可以抗一段；
日志服务器还保存30天的日志；
丢数据
- ack
0 发送过来，没有应答；传输速度最快；可靠性最差；在生产环境几乎不用；
1 发送过来，leader应答； 传输速度，较快；可靠性可以；
-1 发送过来，leader + follower应答；传输速度慢；可靠性最高； - 在生产环境怎么选择？
0 在生产环境几乎不用
1 如果就是普通的日志，对可靠性要求不是特别高，一般选择1，大多数企业都选择1
-1 一般应用到金融或者钱相关的领域
数据重复了
- 幂等性 + 事务 + ack = -1
kafka 事务保证
kafka下游处理 - hive 的dwd层、sparkstreaming、redis
开窗取第一条、分组 - 幂等性：单分区、在一个会话内，效率高
- 事务：整个kafka内部，全局维护id，效率低
数据积压了
- 自身：增加分区，比如从2个分区增加至10个分区；提高下游处理速度sparkstreaming cpu/flink 并行度；消费者也得跟着提高并发度
- 找兄弟：增加消费者消费的条数，增加消费的速度；batchsize 1000/s -> 2000/s、3000/s
Kafka优化
- partiton数目是consumer数目的整数倍
Kafka 为什么快？高效读取数据原因？
- kafka本身就是集群、分区
- 顺序读写 600m/s，如果是随机读写100m/s
Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到到600M/s，而随机写只有100m/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。 - 零拷贝
Kafka 可以按照时间消费数据
KafkaUtil.fetchOffsetsWithTimestamp(topic, sTime, kafkaProp);
Kafka 消费者角义考虑是拉取数据还是推送数据
拉取数据，每个消费者自己拉取自己想要的数据
Kafka 中的数据是有序的吗？
单分区内有序；多分区，分区与分区间无序; 也可以设置一个分区
Kafka 的 Follower与Leader同步消息是如何进行的？
Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。Kafka根据Ack机制来，当Ack=-1时，完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下如果Follower都复制完都落后于Leader，而如果Leader突然宕机，则会丢失数据。而Kafka的这种使用 ISR 的方式则很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。
Kafka 的ISR中有follower落后，怎么处理？
leader收到数据，所有follower都开始同步数据，但有一个follower，因为某种故障，迟迟不能与leader进行同步，那leader就要一直等下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？
Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数（默认10秒）设定。Leader发生故障之后，就会从ISR中选举新的leader。
Ack设置
0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；
1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；
-1（all）：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。【producer发送失败后，会重试】