5.1 数仓概念总结
1）数据仓库的输入数据源和输出系统分别是什么？ 输入系统：埋点产生的用户行为数据、JavaEE后台产生的业务数据。 输出系统：报表系统、用户画像系统、推荐系统
5.2 项目需求及架构总结
5.2.1 集群规模计算
5.2.2 框架版本选型
1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员） 2）CDH：国内使用最多的版本，但CM不开源，但其实对中、小公司使用来说没有影响（建议使用） 3）HDP：开源，可以进行二次开发，但是没有CDH稳定,国内使用较少
5.2.3 服务器选型
服务器使用物理机还是云主机？ 1）机器成本考虑： （1）物理机：以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，单台报价4W出头，需考虑托管服务器费用。一般物理机寿命5年左右 （2）云主机，以阿里云为例，差不多相同配置，每年5W 2）运维成本考虑： （1）物理机：需要有专业的运维人员 （2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松
5.3 数据采集模块总结
5.3.1 Linux&Shell相关总结
1）Linux常用命令
2）Shell常用工具awk、sed、cut、sort
5.3.2 Hadoop相关总结
1）Hadoop默认不支持LZO压缩，如果需要支持LZO压缩，需要添加jar包，并在hadoop的cores-site.xml文件中添加相关压缩配置。（建表时候安装）
2）Hadoop常用端口号
3）Hadoop配置文件以及简单的Hadoop集群搭建
4）HDFS读流程和写流程
5）MapReduce的Shuffle过程及Hadoop优化（包括：压缩、小文件、集群优化）
6）Yarn的Job提交流程
7）Yarn的默认调度器、调度器分类、以及他们之间的区别
8）HDFS存储多目录9）Hadoop参数调优
5.3.3 Zookeeper相关总结
1）选举机制
半数机制
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<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最好设置一致，减少内存抖动带来的性能影响，如果设置不一致容易导致频繁full gc。
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的日志保存时间
7天
4）Kafka的硬盘大小
每天的数据量*7天
5）Kafka监控
公司自己开发的监控器； 开源的监控器：KafkaManager、KafkaMonitor
6）Kakfa分区数
分区数并不是越多越好，一般分区数不要超过集群机器数量。分区数越多占用内存越大（ISR等），一个节点集中的分区也就越多，当它宕机的时候，对系统的影响也就越大。 分区数一般设置为：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 每秒多少数据量：2.3M-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事务