（图片来源于网络，侵删）
总结
1）数仓概念总结
【1】数据仓库的输入数据源和输出系统分别是什么？
输入系统：埋点产生的用户行为数据、JavaEE 后台产生的业务数据
输出系统：报表系统、用户画像系统、推荐系统
2）项目需求及架构总结
【1】集群规模计算
【2】框架版本选型
1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，
有专业的运维人员）（建议使用）
2）CDH：国内使用最多的版本，但 CM 不开源，但其实对中、小公司使用来说没有影
响
3）HDP：开源，可以进行二次开发，但是没有 CDH 稳定,国内使用较少
【3】服务器选型
3）数据采集模块总结
【1】Linux&Shell 相关总结
1）Linux 常用高级命令
2）Shell 常用工具
awk、sed、cut、sort
【2】Hadoop 相关总结
1）Hadoop 默认不支持 LZO 压缩，如果需要支持 LZO 压缩，需要添加 jar 包，并在 hadoop
的 cores-site.xml 文件中添加相关压缩配置。需要掌握让 LZO 文件支持切片
2）Hadoop 常用端口号，50070,8088,19888,8020
3）Hadoop 配置文件以及简单的 Hadoop 集群搭建。8 个配置文件
4）HDFS 读流程和写流程
5）MapReduce 的 Shuffle 过程及 Hadoop 优化（包括：压缩、小文件、集群优化）
6）Yarn 的 Job 提交流程
7）Yarn 的默认调度器、调度器分类、以及他们之间的区别
8）HDFS 存储多目录
9）Hadoop 参数调优
10）项目经验之基准测试
【3】Zookeeper 相关总结
1）选举机制
半数机制，安装奇数台
10 台服务器几台：3 台
20 台服务器几台：5 台
100 台服务器几台：11 台
不是越多越好，也不是越少越好。 如果多，通信时间长，效率低；如果太少，可靠性差
2）常用命令
ls、get、create
【4】Flume 相关总结
1）Flume 组成，Put 事务，Take 事务
Source 到 Channel 是 Put 事务
Channel 到 Sink 是 Take 事务
Taildir Source：断点续传、多目录。Flume1.6 以前需要自己自定义 Source 记录每次读取
文件位置，实现断点续传
File Channel：数据存储在磁盘，宕机数据可以保存。但是传输速率慢。适合对数据传
输可靠性要求高的场景，比如，金融行业
Memory Channel：数据存储在内存中，宕机数据丢失。传输速率快。适合对数据传输可
靠性要求不高的场景，比如，普通的日志数据
Kafka Channel：减少了 Flume 的 Sink 阶段，提高了传输效率
2）Flume 拦截器
（1）拦截器注意事项
项目中自定义了：ETL 拦截器和区分类型拦截器。
采用两个拦截器的优缺点：优点，模块化开发和可移植性；缺点，性能会低一些
（2）自定义拦截器步骤
a）实现 Interceptor
b）重写四个方法
- initialize 初始化
- public Event intercept(Event event) 处理单个 Event
- public List intercept(List events) 处理多个 Event，在这个
方法中调用 Event intercept(Event event) - close 方法
c）静态内部类，实现 Interceptor.Builder
3）Flume Channel 选择器
4）Flume 监控器
Ganglia
5）Flume 采集数据会丢失吗?
不会，Channel 存储可以存储在 File 中，数据传输自身有事务
6）Flume 内存
开发中在 flume-env.sh 中设置 JVM heap 为 4G 或更高，部署在单独的服务器上（4 核 8
线程 16G 内存）
-Xmx 与-Xms 最好设置一致，减少内存抖动带来的性能影响，如果设置不一致容易导
致频繁 fullgc
-Xms 表示 JVM Heap(堆内存)最小尺寸，初始分配；-Xmx 表示 JVM Heap(堆内存)最
大允许的尺寸，按需分配。如果不设置一致，容易在初始化时，由于内存不够，频繁触发 fullgc
7）FileChannel 优化
通过配置 dataDirs 指向多个路径，每个路径对应不同的硬盘，增大 Flume 吞吐量
官方说明如下：
Comma separated list of directories for storing log files. Using
multiple directories on separate disks can improve file channel peformance
checkpointDir 和 backupCheckpointDir 也尽量配置在不同硬盘对应的目录中，保证
checkpoint 坏掉后，可以快速使用 backupCheckpointDir 恢复数据
8）Sink：HDFS Sink 小文件处理
（1）HDFS 存入大量小文件，有什么影响？
元数据层面：每个小文件都有一份元数据，其中包括文件路径，文件名，所有者，所属
组，权限，创建时间等，这些信息都保存在 Namenode 内存中。所以小文件过多，会占用
Namenode 服务器大量内存，影响 Namenode 性能和使用寿命
计算层面：默认情况下 MR 会对每个小文件启用一个 Map 任务计算，非常影响计算性
能。同时也影响磁盘寻址时间
（2）HDFS 小文件处理
官方默认的这三个参数配置写入 HDFS 后会产生小文件，hdfs.rollInterval、hdfs.rollSize、
hdfs.rollCount
基于以上 hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0 几个参数综
合作用，效果如下：
（1）文件在达到 128M 时会滚动生成新文件
（2）文件创建超 3600 秒时会滚动生成新文件
【5】Kafka 相关总结
1）Kafka 压测
Kafka 官方自带压力测试脚本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。
Kafka 压测时，可以查看到哪个地方出现了瓶颈（CPU，内存，网络 IO）。一般都是网
络 IO 达到瓶颈
2）Kafka 的机器数量
Kafka 机器数量=2*（峰值生产速度*副本数/100）+1
3）Kafka 的日志保存时间
3 天
4）Kafka 的硬盘大小
每天的数据量*3 天
5）Kafka 监控
公司自己开发的监控器
开源的监控器：KafkaManager、KafkaMonitor
6）Kakfa 分区数
（1）创建一个只有 1 个分区的 topic
（2）测试这个 topic 的 producer 吞吐量和 consumer 吞吐量。
（3）假设他们的值分别是 Tp 和 Tc，单位可以是 MB/s。
（4）然后假设总的目标吞吐量是 Tt，那么分区数=Tt / min（Tp，Tc）
例如：producer 吞吐量=10m/s；consumer 吞吐量=50m/s，期望吞吐量 100m/s；
分区数=100 / 10 =10 分区
分区数一般设置为：3-10 个
7）副本数设定
一般我们设置成 2 个或 3 个，很多企业设置为 2 个
8）多少个 Topic
通常情况：多少个日志类型就多少个 Topic。也有对日志类型进行合并的
9）Kafka 丢不丢数据
Ack=0，producer 不等待 kafka broker 的 ack，一直生产数据
Ack=1，leader 数据落盘就发送 ack，producer 收到 ack 才继续生产数据
Ack=-1，ISR 中的所有副本数据罗盘才发送 ack，producer 收到 ack 才继续生产数据
10）Kafka 的 ISR 副本同步队列
ISR（In-Sync Replicas），副本同步队列。ISR 中包括 Leader 和 Follower。如果 Leader
进程挂掉，会在 ISR 队列中选择一个服务作为新的 Leader。有 replica.lag.max.messages（延
迟条数）和 replica.lag.time.max.ms（延迟时间）两个参数决定一台服务是否可以加入 ISR 副
本队列，在 0.10 版本移除了 replica.lag.max.messages 参数，防止服务频繁的进去队列。
任意一个维度超过阈值都会把 Follower 剔除出 ISR，存入 OSR（Outof-Sync Replicas）
列表，新加入的 Follower 也会先存放在 OSR 中
11）Kafka 分区分配
Range 和 RoundRobin
12）Kafka 中数据量计算
每天总数据量 100g，每天产生 1 亿条日志， 10000 万/24/60/60=1150 条/每秒钟
平均每秒钟：1150 条
低谷每秒钟：400 条
高峰每秒钟：1150 条*（2-20 倍）=2300 条-23000 条
每条日志大小：0.5k-2k（取 1k）
每秒多少数据量：2.0M-20MB
13） Kafka 挂掉
（1）Flume 记录
（2）日志有记录
（3）短期没事
14）Kafka 消息数据积压，Kafka 消费能力不足怎么处理？
（1）如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消
费组的消费者数量，消费者数=分区数。（两者缺一不可）
（2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉
取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压
15）Kafka 幂等性
Kafka0.11 版本引入了幂等性，幂等性配合 at least once 语义可以实现 exactly once 语义。
但只能保证单次会话的幂等。
16）Kafka 事务
Kafka0.11 版本引入 Kafka 的事务机制，其可以保证生产者发往多个分区的一批数据的
原子性。
都看到这里了，点赞评论一下吧！！！
