1.1 数仓概念总结
1）数据仓库的输入数据源和输出系统分别是什么？
输入系统：埋点产生的用户行为数据、JavaEE后台产生的业务数据。
输出系统：报表系统、用户画像系统、推荐系统
1.2 项目需求及架构总结
1.2.1 集群规模计算
1.2.2 框架版本选型
1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）
2）CDH：国内使用最多的版本，但CM不开源，但其实对中、小公司使用来说没有影响（建议使用）
3）HDP：开源，可以进行二次开发，但是没有CDH稳定,国内使用较少
1.2.3 服务器选型
服务器使用物理机还是云主机？
1）机器成本考虑：
（1）物理机：以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，单台报价4W出头，需考虑托管服务器费用。一般物理机寿命5年左右
（2）云主机，以阿里云为例，差不多相同配置，每年5W
2）运维成本考虑：
（1）物理机：需要有专业的运维人员
（2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松
1.3 数据采集模块总结
1.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
1.3.2 Hadoop相关总结
1）Hadoop默认不支持LZO压缩，如果需要支持LZO压缩，需要添加jar包，并在hadoop的cores-site.xml文件中添加相关压缩配置。
2）Hadoop常用端口号
- 1，namenode http端口：50070
- 2，datanode http端口：50075
- 3，secondaryNameNode 节点http端口号：50090
- 4，datanode后端访问端口号：50010
- 5，fs 端口号：9000
- 6，yarn http端口号：8088
- 7，历史服务器web访问端口号：19888
3）Hadoop配置文件以及简单的Hadoop集群搭建
- 4个site.xml文件和 3个env.sh文件和1个slave文件
-
- 1,core-site.xml
- 2,hdfs-site.xml
- 3,mapred-site.xml
- 4,yarn-site.xml
- 5,hadoop-env.sh
- 6,mapred-env.sh
- 7,yarn-env.sh
- 8,slaves
4）HDFS读流程和写流程
- hdfs读数据流程
- 1，客户端通过Distributed FileSystem 向namenode请求下载文件，namenode 通过查找元数据，返回文件块所在datanode的地址。
- 2，客户端挑选一台datanode（按照就近原则，返回的块地址根据网络拓扑图排序，距离客户端进的排在前面）服务器，建立连接，请求读取数据；如果dn异常，则从第二优先的dn读取数据，并且标记该dn异常，后续读取块的数据直接跳过该dn。
- 3，datanode开始传输数据给客户端（从磁盘读取数据输入流，以packet为单位来做校验），如果块读取完毕，则关闭和datanode的连接。
- 4，客户端以packet为单位接收数据，先在本地缓存下来，然后写入目标文件。
- hdfs写数据流程
-
- 1，客户端向nn请求上传文件，nn检查该文件和父目录是否存在。
- 2，nn返回响应给客户端，是否可以上传文件。
- 3，客户端向nn请求上传第一个块的dn的信息。
- 4，nn根据副本原则，返回给客户端块上传的dn节点信息。
- 5，客户端和dn1建立连接，请求上传数据，dn1接着和dn2建立连接，dn2和dn3建立连接，通信管道就建立完成。
- 6，dn1，dn2，dn3 逐级返回应答给客户端。
- 7，客户端开始从磁盘以packet为单位读取数据上传到dn1，dn1收到packet后，会传给dn2，dn2收到packet后传给dn3.
- 8，当一个packet传输完成后，客户端在次和nn请求上传第二个块的dn服务器。重复执行3-7步。
5）MapReduce的Shuffle过程及Hadoop优化（包括：压缩、小文件、集群优化）
6）Yarn的Job提交流程
7）Yarn的默认调度器、调度器分类、以及他们之间的区别
8）HDFS存储多目录
9）Hadoop参数调优
10）项目经验之基准测试
1.3.3 Zookeeper相关总结
1）选举机制
半数机制
2）常用命令
ls、get、create
1.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<Event> intercept(List<Event> 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。
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，hdfs.roundValue=10，hdfs.roundUnit= second几个参数综合作用，效果如下：
（1）tmp文件在达到128M时会滚动生成正式文件
（2）tmp文件创建超10秒时会滚动生成正式文件
举例：在2018-01-01 05:23的时侯sink接收到数据，那会产生如下tmp文件：
/hadoop/20180101/hadoop.201801010520.tmp
即使文件内容没有达到128M，也会在05:33时滚动生成正式文件
1.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的日志保存时间
7天
4）Kafka的硬盘大小
每天的数据量*7天
5）Kafka监控
公司自己开发的监控器；
开源的监控器：KafkaManager、KafkaMonitor
6）Kakfa分区数。
分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大（ISR等），一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。
分区数一般设置为：3-10个
7）副本数设定
一般我们设置成2个或3个，很多企业设置为2个。
8）多少个Topic
通常情况：多少个日志类型就多少个Topic。也有对日志类型进行合并的。
9）Kafka丢不丢数据
Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。
Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。
Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。
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分区分配策略
在 Kafka内部存在两种默认的分区分配策略：Range和 RoundRobin。
Range是默认策略。Range是对每个Topic而言的（即一个Topic一个Topic分），首先对同一个Topic里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。然后用Partitions分区的个数除以消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。
例如：我们有10个分区，两个消费者（C1，C2），3个消费者线程，10 / 3 = 3而且除不尽。
C1-0 将消费 0, 1, 2, 3 分区
C2-0 将消费 4, 5, 6 分区
C2-1 将消费 7, 8, 9 分区
RoundRobin：前提：同一个Consumer Group里面的所有消费者的num.streams（消费者消费线程数）必须相等；每个消费者订阅的主题必须相同。
第一步：将所有主题分区组成TopicAndPartition列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。
12）Kafka中数据量计算
每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟
平均每秒钟：1150条
低谷每秒钟：400条
高峰每秒钟：1150条*（2-20倍）=2300条-23000条
每条日志大小：0.5k-2k
每秒多少数据量：2.3M-20MB
13） Kafka挂掉
（1）Flume记录
（2）日志有记录
（3）短期没事
14） Kafka消息数据积压，Kafka消费能力不足怎么处理？
（1）如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）
（2）如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。