01.05第一篇之总结

第5 章总结

5.1 数仓概念总结

1）数据仓库的输入数据源和输出系统分别是什么？

输入系统：埋点产生的用户行为数据、JavaEE 后台产生的业务数据。

输出系统：报表系统、用户画像系统、推荐系统

5.2 项目需求及架构总结

5.2.1 集群规模计算

5.2.2 框架版本选型

1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）（建议使用）

2）CDH：国内使用最多的版本，但CM 不开源，但其实对中、小公司使用来说没有影响。离线

3）HDP：开源，可以进行二次开发，但是没有CDH 稳定,国内使用较少

5.2.3 服务器选型

5.3 数据采集模块总结

5.3.1 Linux&Shell 相关总结

1）Linux常用高级命令

序号	命令	命令解释
1	top	查看内存
2	df -h	查看磁盘存储情况
3	iotop	查看磁盘IO读写(yum install iotop安装）
4	iotop -o	直接查看比较高的磁盘读写程序
5	netstat -tunlp | grep 端口号	查看端口占用情况
6	uptime	查看报告系统运行时长及平均负载
7	ps aux	查看进程

2）Shell 常用工具

awk、sed、cut、sort

5.3.2 Hadoop 相关总结

1**）Hadoop 默认不支持**LZO 压缩，如果需要支持****LZO 压缩，需要添加****jar 包，并在hadoop的****cores-site.xml 文件中添加相关压缩配置。需要掌握让****LZO 文件支持切片。

2）Hadoop 常用端口号，50070,8088,19888,9000

3）Hadoop 配置文件以及简单的Hadoop 集群搭建。8 个配置文件

4）HDFS 读流程和写流程（笔试题，有朋友）

5）MapReduce 的Shuffle 过程及Hadoop 优化（包括：压缩、小文件、集群优化）

6）Yarn 的Job 提交流程

7）Yarn 的默认调度器、调度器分类、以及他们之间的区别

8）HDFS 存储多目录

9）Hadoop 参数调优

10）项目经验之基准测试

5.3.3 Zookeeper 相关总结

1）选举机制

半数机制，安装奇数台

10 台服务器几台：3 台

20 台服务器几台：5 台

100 台服务器几台：11 台

不是越多越好，也不是越少越好。如果多，通信时间长，效率低；如果太少，可靠性差。

2）常用命令

ls、get、create

5.3.4 Flume 相关总结

1）Flume 组成，Put 事务，Take 事务

Taildir Source：断点续传、多目录。Flume1.6 以前需要自己自定义Source 记录每次读取文件位置，实现断点续传。

File Channel：数据存储在磁盘，宕机数据可以保存。但是传输速率慢。适合对数据传输可靠性要求高的场景，比如，金融行业。

Memory Channel：数据存储在内存中，宕机数据丢失。传输速率快。适合对数据传输可靠性要求不高的场景，比如，普通的日志数据。

Kafka Channel：减少了Flume 的Sink 阶段，提高了传输效率。

Source 到Channel 是Put 事务

Channel 到Sink 是Take 事务

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 秒时会滚动生成新文件

举例：在2018-01-01 05:23 的时侯sink 接收到数据，那会产生如下tmp 文件：

5.3.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 天 (默认7天)

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 中数据量计算

每天日活用户100万，每人日均100条：100万*100条= 1 亿条日志

每天总数据量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 的事务机制，其可以保证生产者发往多个分区的一批数据的原子性。

c 的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）

（2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

15）Kafka 幂等性

Kafka0.11 版本引入了幂等性，幂等性配合at least once 语义可以实现exactly once 语义。但只能保证单次会话的幂等。

16）Kafka 事务

Kafka0.11 版本引入Kafka 的事务机制，其可以保证生产者发往多个分区的一批数据的原子性。