batchsize和数据量设置比例_1. 项目涉及技术

1.1 Linux&Shell相关总结

1.1.1 Linux常用命令

序号命令命令解释

1top查看内存

2df -h查看磁盘存储情况

3iotop查看磁盘IO读写(yum install iotop安装)

4iotop -o直接查看比较高的磁盘读写程序

5netstat -tunlp | grep 端口号查看端口占用情况

6uptime查看报告系统运行时长及平均负载

7ps -aux查看进程

1.1.2 Shell常用工具及写过的脚本

1)awk、sed、cut、sort

2)用Shell写过哪些脚本

(1)集群启动，分发脚本

(2)数仓与mysql的导入导出

(3)数仓层级内部的导入

1.1.3 Shell中提交了一个脚本，进程号已经不知道了，但是需要kill掉这个进程，怎么操作?

ssh $i “ps -ef | grep file-flume-kafka | grep -v grep |awk ‘{print \$2}’ | xargs kill”

1.1.4 Shell中单引号和双引号区别

1)在/home/atguigu/bin创建一个test.sh文件

[atguigu@hadoop102 bin]$ vim test.sh

在文件中添加如下内容

#!/bin/bash

do_date=$1

echo ‘$do_date’

echo “$do_date”

echo “‘$do_date'”

echo ‘”$do_date”‘

echo `date`

2)查看执行结果

[atguigu@hadoop102 bin]$ test.sh 2019-02-10

$do_date

2019-02-10

‘2019-02-10’

“$do_date”

2019年 05月 02日 星期四 21:02:08 CST

3)总结：

(1)单引号不取变量值

(2)双引号取变量值

(3)反引号`，执行引号中命令

(4)双引号内部嵌套单引号，取出变量值

(5)单引号内部嵌套双引号，不取出变量值

1.2 Hadoop相关总结

1.2.1 Hadoop常用端口号

hadoop2.xHadoop3.x

访问HDFS端口500709870

访问MR执行情况端口80888088

历史服务器1988819888

客户端访问集群端口90008020

1.2.2 Hadoop配置文件以及简单的Hadoop集群搭建

(1)配置文件：

Hadoop2.x core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml   slaves

Hadoop3.x core-site.xml、hdfs-site.xml、mapred-site.xml、yarn-site.xml   workers

(2)简单的集群搭建过程：

JDK安装

配置SSH免密登录

配置hadoop核心文件:

格式化namenode

1.2.3 HDFS读流程和写流程

1.2.4 HDFS小文件处理

1)会有什么影响

(1)1个文件块，占用namenode多大内存150字节

1亿个小文件*150字节

1 个文件块 * 150字节

128G能存储多少文件块？   128 * 1024*1024*1024byte/150字节 = 9亿文件块

2)怎么解决

(1)采用har归档方式，将小文件归档

(2)采用CombineTextInputFormat

(3)有小文件场景开启JVM重用；如果没有小文件，不要开启JVM重用，因为会一直占用使用到的task卡槽，直到任务完成才释放。

JVM重用可以使得JVM实例在同一个job中重新使用N次，N的值可以在Hadoop的mapred-site.xml文件中进行配置。通常在10-20之间

mapreduce.job.jvm.numtasks

10

How many tasks to run per jvm,if set to -1 ,there is

no limit

1.2.5 Shuffle及优化

1、Shuffle过程

2、优化

1)Map阶段

(1)增大环形缓冲区大小。由100m扩大到200m

(2)增大环形缓冲区溢写的比例。由80%扩大到90%

(3)减少对溢写文件的merge次数。(10个文件，一次20个merge)

(4)不影响实际业务的前提下，采用Combiner提前合并，减少 I/O。

2)Reduce阶段

(1)合理设置Map和Reduce数：两个都不能设置太少，也不能设置太多。太少，会导致Task等待，延长处理时间；太多，会导致 Map、Reduce任务间竞争资源，造成处理超时等错误。

(2)设置Map、Reduce共存：调整slowstart.completedmaps参数，使Map运行到一定程度后，Reduce也开始运行，减少Reduce的等待时间。

(3)规避使用Reduce，因为Reduce在用于连接数据集的时候将会产生大量的网络消耗。

(4)增加每个Reduce去Map中拿数据的并行数

(5)集群性能可以的前提下，增大Reduce端存储数据内存的大小。

3)IO传输

采用数据压缩的方式，减少网络IO的的时间。安装Snappy和LZOP压缩编码器。

压缩：

(1)map输入端主要考虑数据量大小和切片，支持切片的有Bzip2、LZO。注意：LZO要想支持切片必须创建索引；

(2)map输出端主要考虑速度，速度快的snappy、LZO；

(3)reduce输出端主要看具体需求，例如作为下一个mr输入需要考虑切片，永久保存考虑压缩率比较大的gzip。

4)整体

(1)NodeManager默认内存8G，需要根据服务器实际配置灵活调整，例如128G内存，配置为100G内存左右，yarn.nodemanager.resource.memory-mb。

(2)单任务默认内存8G，需要根据该任务的数据量灵活调整，例如128m数据，配置1G内存，yarn.scheduler.maximum-allocation-mb。

(3)mapreduce.map.memory.mb ：控制分配给MapTask内存上限，如果超过会kill掉进程(报：Container is running beyond physical memory limits. Current usage:565MB of512MB physical memory used；Killing Container)。默认内存大小为1G，如果数据量是128m，正常不需要调整内存；如果数据量大于128m，可以增加MapTask内存，最大可以增加到4-5g。

(4)mapreduce.reduce.memory.mb：控制分配给ReduceTask内存上限。默认内存大小为1G，如果数据量是128m，正常不需要调整内存；如果数据量大于128m，可以增加ReduceTask内存大小为4-5g。

(5)mapreduce.map.java.opts：控制MapTask堆内存大小。(如果内存不够，报：java.lang.OutOfMemoryError)

(6)mapreduce.reduce.java.opts：控制ReduceTask堆内存大小。(如果内存不够，报：java.lang.OutOfMemoryError)

(7)可以增加MapTask的CPU核数，增加ReduceTask的CPU核数

(8)增加每个Container的CPU核数和内存大小

(9)在hdfs-site.xml文件中配置多目录

(10)NameNode有一个工作线程池，用来处理不同DataNode的并发心跳以及客户端并发的元数据操作。dfs.namenode.handler.count=20 * log2(Cluster Size)，比如集群规模为10台时，此参数设置为60。

1.2.6 Yarn工作机制

1.2.7 Yarn调度器

1)Hadoop调度器重要分为三类：

FIFO 、Capacity Scheduler(容量调度器)和Fair Sceduler(公平调度器)。

Apache默认的资源调度器是容量调度器；

CDH默认的资源调度器是公平调度器。

2)区别：

FIFO调度器：支持单队列 、先进先出   生产环境不会用。

容量调度器：支持多队列，保证先进入的任务优先执行。

公平调度器：支持多队列，保证每个任务公平享有队列资源。

3)在生产环境下怎么选择？

大厂：如果对并发度要求比较高，选择公平，要求服务器性能必须OK；

中小公司，集群服务器资源不太充裕选择容量。

4)在生产环境怎么创建队列？

(1)调度器默认就1个default队列，不能满足生产要求。

(2)按照框架：hive /spark/ flink 每个框架的任务放入指定的队列(企业用的不是特别多)

(3)按照业务模块：登录注册、购物车、下单、业务部门1、业务部门2

5)创建多队列的好处？

(1)因为担心员工不小心，写递归死循环代码，把所有资源全部耗尽。

(2)实现任务的降级使用，特殊时期保证重要的任务队列资源充足。

业务部门1(重要)=》业务部门2(比较重要)=》下单(一般)=》购物车(一般)=》登录注册(次要)

1.2.8 项目经验之基准测试

搭建完Hadoop集群后需要对HDFS读写性能和MR计算能力测试。测试jar包在hadoop的share文件夹下。

1.2.9 Hadoop宕机

1)如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb(单个任务可申请的最多物理内存量，默认是8192MB)

2)如果写入文件过快造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。例如，可以调整Flume每批次拉取数据量的大小参数batchsize。。

1.2.10 Hadoop解决数据倾斜方法

1)提前在map进行combine，减少传输的数据量

在Mapper加上combiner相当于提前进行reduce，即把一个Mapper中的相同key进行了聚合，减少shuffle过程中传输的数据量，以及Reducer端的计算量。

如果导致数据倾斜的key大量分布在不同的mapper的时候，这种方法就不是很有效了。

2)导致数据倾斜的key大量分布在不同的mapper

(1)局部聚合加全局聚合。

第一次在map阶段对那些导致了数据倾斜的key 加上1到n的随机前缀，这样本来相同的key 也会被分到多个Reducer中进行局部聚合，数量就会大大降低。

第二次mapreduce，去掉key的随机前缀，进行全局聚合。

思想：二次mr，第一次将key随机散列到不同reducer进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀，按原key进行reduce处理。

这个方法进行两次mapreduce，性能稍差。

(2)增加Reducer，提升并行度

JobConf.setNumReduceTasks(int)

(3)实现自定义分区

根据数据分布情况，自定义散列函数，将key均匀分配到不同Reducer

1.2.11 集群资源分配参数(项目中遇到的问题)

集群有30台机器，跑mr任务的时候发现5个map任务全都分配到了同一台机器上，这个可能是由于什么原因导致的吗？

解决方案：yarn.scheduler.fair.assignmultiple 这个参数 默认是开的，需要关掉

1.3 Zookeeper相关总结

1.3.1 选举机制

半数机制：2n+1，安装奇数台

10台服务器：3台

20台服务器：5台

100台服务器：11台

台数多，好处：提高可靠性；坏处：影响通信延时

1.3.2 常用命令

ls、get、create

1.3.3 Paxos算法(扩展)

注意：暂时先不用看。如果后期准备面今日头条，需要认真准备，其他公司几乎都不问。

Paxos算法一种基于消息传递且具有高度容错特性的一致性算法。

分布式系统中的节点通信存在两种模型：共享内存(Shared memory)和消息传递(Messages passing)。基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复，在基础Paxos场景中，先不考虑可能出现消息篡改即拜占庭错误的情况。Paxos算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性。

1.3.4 讲一讲什么是CAP法则？Zookeeper符合了这个法则的哪两个？(扩展)

CAP法则：强一致性、高可用性、分区容错性；

Zookeeper符合强一致性、高可用性！

1.4 Flume相关总结

1.4.1 Flume组成，Put事务，Take事务

1)taildir source

(1)断点续传、多目录

(2)哪个flume版本产生的？Apache1.7、CDH1.6

(3)没有断点续传功能时怎么做的？ 自定义

(4)taildir挂了怎么办？

不会丢数：断点续传

重复数据：

(5)怎么处理重复数据？

不处理：生产环境通常不处理，因为会影响传输效率

处理

自身：在taildirsource里面增加自定义事务

找兄弟：下一级处理(hive dwd sparkstreaming flink布隆)、去重手段(groupby、开窗取窗口第一条、redis)

(6)taildir source 是否支持递归遍历文件夹读取文件？

不支持。  自定义  递归遍历文件夹 +读取文件

2)file channel /memory channel/kafka channel

(1)file channel

数据存储于磁盘，优势：可靠性高；劣势：传输速度低

默认容量：100万event

注意：FileChannel可以通过配置dataDirs指向多个路径，每个路径对应不同的硬盘，增大Flume吞吐量。

(2)memory channel

数据存储于内存，优势：传输速度快；劣势：可靠性差

默认容量：100个event

(3)kafka channel

数据存储于Kafka，基于磁盘；

优势：可靠性高；

传输速度快 kafka channel》memory channel+kafka sink  原因省去了sink阶段

(4)kafka channel哪个版本产生的？

flume1.6 版本产生=》并没有火；因为有bug

topic-start 数据内容

topic-event 数据内容    ture  和false 很遗憾，都不起作用。

增加了额外清洗的工作量。

flume1.7解决了这个问题，开始火了。

(5)生产环境如何选择

如果下一级是kafka,优先选择kafka channel

如果是金融、对钱要求准确的公司，选择file channel

如果就是普通的日志，通常可以选择memory channel

每天丢几百万数据   pb级   亿万富翁，掉1块钱会捡？

3)HDFS sink

(1)时间(1小时-2小时) or 大小128m、event个数(0禁止)

具体参数：hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0

4)事务

Source到Channel是Put事务

Channel到Sink是Take事务

1.4.2 Flume拦截器

1)拦截器注意事项

项目中自定义了：ETL拦截器。

采用两个拦截器的优缺点：优点，模块化开发和可移植性；缺点，性能会低一些

2)自定义拦截器步骤

(1)实现 Interceptor

(2)重写四个方法

initialize 初始化

public Event intercept(Event event) 处理单个Event

public List intercept(List events) 处理多个Event，在这个方法中调用Event intercept(Event event)

close 方法

(3)静态内部类，实现Interceptor.Builder

3)拦截器可以不用吗？

可以不用；需要在下一级hive的dwd层和sparksteaming里面处理

优势：只处理一次，轻度处理；劣势：影响性能，不适合做实时推荐这种对实时要求比较高的场景。

1.4.3 Flume Channel选择器

1.4.4 Flume监控器

1)采用Ganglia监控器，监控到flume尝试提交的次数远远大于最终成功的次数，说明flume运行比较差。

2)解决办法？

(1)自身：增加内存flume-env.sh   4-6g

-Xmx与-Xms最好设置一致，减少内存抖动带来的性能影响，如果设置不一致容易导致频繁fullgc。

(2)找朋友：增加服务器台数

搞活动 618  =》增加服务器=》用完在退出

日志服务器配置：8-16g内存、磁盘8T

1.4.5 Flume采集数据会丢失吗?(防止数据丢失的机制)

如果是FileChannel不会，Channel存储可以存储在File中，数据传输自身有事务。

如果是MemoryChannel有可能丢。

1.5 Kafka相关总结

1.5.1 Kafka架构

生产者、Broker、消费者、ZK；

注意：Zookeeper中保存Broker id和消费者offsets等信息，但是没有生产者信息。

1.5.2 Kafka的机器数量

Kafka机器数量=2*(峰值生产速度*副本数/100)+ 1

1.5.3 副本数设定

一般我们设置成2个或3个，很多企业设置为2个。

副本的优势：提高可靠性；副本劣势：增加了网络IO传输

1.5.4 Kafka压测

Kafka官方自带压力测试脚本(kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh)。Kafka压测时，可以查看到哪个地方出现了瓶颈(CPU，内存，网络IO)。一般都是网络IO达到瓶颈。

1.5.5 Kafka日志保存时间

默认保存7天；生产环境建议3天

1.5.6 Kafka中数据量计算

每天总数据量100g，每天产生1亿条日志， 10000万/24/60/60=1150条/每秒钟

平均每秒钟：1150条

低谷每秒钟：50条

高峰每秒钟：1150条*(2-20倍)=2300条-23000条

每条日志大小：0.5k-2k(取1k)

每秒多少数据量：2.0M-20MB

1.5.7 Kafka的硬盘大小

每天的数据量100g*2个副本*3天/70%

1.5.8 Kafka监控

公司自己开发的监控器；

开源的监控器：KafkaManager、KafkaMonitor、KafkaEagle

1.5.9 Kakfa分区数

1)创建一个只有1个分区的topic

2)测试这个topic的producer吞吐量和consumer吞吐量。

3)假设他们的值分别是Tp和Tc，单位可以是MB/s。

4)然后假设总的目标吞吐量是Tt，那么分区数=Tt / min(Tp，Tc)

例如：producer吞吐量=20m/s；consumer吞吐量=50m/s，期望吞吐量100m/s；

分区数=100 / 20 =5分区

分区数一般设置为：3-10个

1.5.10 多少个Topic

通常情况：多少个日志类型就多少个Topic。也有对日志类型进行合并的。

1.5.11 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中。

1.5.12 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 分区

第一步：将所有主题分区组成TopicAndPartition列表，然后对TopicAndPartition列表按照hashCode进行排序，最后按照轮询的方式发给每一个消费线程。

1.5.13 Kafka挂掉

1)Flume记录

2)日志有记录

3)短期没事

1.5.14 Kafka丢不丢数据

Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。

Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。

Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。

1.5.15 Kafka数据重复

幂等性+ack-1+事务

Kafka数据重复，可以再下一级：SparkStreaming、redis或者hive中dwd层去重，去重的手段：分组、按照id开窗只取第一个值；

1.5.16 Kafka消息数据积压，Kafka消费能力不足怎么处理？

1)如果是Kafka消费能力不足，则可以考虑增加Topic的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。(两者缺一不可)

2)如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间

1.5.17 Kafka参数优化

1)Broker参数配置(server.properties)

1、日志保留策略配置

# 保留三天，也可以更短 (log.cleaner.delete.retention.ms)

log.retention.hours=72

2、Replica相关配置

default.replication.factor:1 默认副本1个

3、网络通信延时

replica.socket.timeout.ms:30000 #当集群之间网络不稳定时,调大该参数

replica.lag.time.max.ms= 600000# 如果网络不好,或者kafka集群压力较大,会出现副本丢失,然后会频繁复制副本,导致集群压力更大,此时可以调大该参数

2)Producer优化(producer.properties)

compression.type:none

#默认发送不进行压缩，推荐配置一种适合的压缩算法，可以大幅度的减缓网络压力和Broker的存储压力。

3)Kafka内存调整(kafka-server-start.sh)

默认内存1个G，生产环境尽量不要超过6个G。

export KAFKA_HEAP_OPTS=”-Xms4g -Xmx4g“

1.5.18 Kafka高效读写数据

1)Kafka本身是分布式集群，同时采用分区技术，并发度高。

2)顺序写磁盘

Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。

3)零复制技术

1.5.19 Kafka支持传输

kafka对于消息体的大小默认为单条最大值是1M但是在我们应用场景中, 常常会出现一条消息大于1M，如果不对kafka进行配置。则会出现生产者无法将消息推送到kafka或消费者无法去消费kafka里面的数据, 这时我们就要对kafka进行以下配置：server.properties

replica.fetch.max.bytes: 1048576  broker可复制的消息的最大字节数, 默认为1M

message.max.bytes: 1000012   kafka 会接收单个消息size的最大限制， 默认为1M左右

注意：message.max.bytes必须小于等于replica.fetch.max.bytes，否则就会导致replica之间数据同步失败。

1.5.20 Kafka过期数据清理

保证数据没有被引用(没人消费他)

日志清理保存的策略只有delete和compact两种

log.cleanup.policy=delete启用删除策略

log.cleanup.policy=compact启用压缩策略

1.5.21 Kafka可以按照时间消费数据

Map startOffsetMap = KafkaUtil.fetchOffsetsWithTimestamp(topic, sTime, kafkaProp);

1.5.22 Kafka消费者角度考虑是拉取数据还是推送数据

拉取数据

1.5.23 Kafka中的数据是有序的吗

单分区内有序；多分区，分区与分区间无序；

1.6 Hive总结

1.6.1 Hive的架构

1.6.2 Hive和数据库比较

Hive 和数据库除了拥有类似的查询语言，再无类似之处。

1)数据存储位置

Hive 存储在 HDFS 。数据库将数据保存在块设备或者本地文件系统中。

2)数据更新

Hive中不建议对数据的改写。而数据库中的数据通常是需要经常进行修改的，

3)执行延迟

Hive 执行延迟较高。数据库的执行延迟较低。当然，这个是有条件的，即数据规模较小，当数据规模大到超过数据库的处理能力的时候，Hive的并行计算显然能体现出优势。

4)数据规模

Hive支持很大规模的数据计算；数据库可以支持的数据规模较小。

1.6.3 内部表和外部表

元数据、原始数据

1)删除数据时：

内部表：元数据、原始数据，全删除

外部表：元数据 只删除

2)在公司生产环境下，什么时候创建内部表，什么时候创建外部表？

在公司中绝大多数场景都是外部表。

自己使用的临时表，才会创建内部表；

1.6.4 4个By区别

1)Order By：全局排序，只有一个Reducer；

2)Sort By：分区内有序；

3)Distrbute By：类似MR中Partition，进行分区，结合sort by使用。

4) Cluster By：当Distribute by和Sorts by字段相同时，可以使用Cluster by方式。Cluster by除了具有Distribute by的功能外还兼具Sort by的功能。但是排序只能是升序排序，不能指定排序规则为ASC或者DESC。

在生产环境中Order By用的比较少，容易导致OOM。

在生产环境中Sort By+ Distrbute By用的多。

1.6.5 系统函数

1)date_add、date_sub函数(加减日期)

2)next_day函数(周指标相关)

3)date_format函数(根据格式整理日期)

4)last_day函数(求当月最后一天日期)

5)collect_set函数

6)get_json_object解析json函数

7)NVL(表达式1，表达式2)

如果表达式1为空值，NVL返回值为表达式2的值，否则返回表达式1的值。

1.6.6 自定义UDF、UDTF函数

1)在项目中是否自定义过UDF、UDTF函数，以及用他们处理了什么问题，及自定义步骤？

(1)用UDF函数解析公共字段；用UDTF函数解析事件字段。

(2)自定义UDF：继承UDF，重写evaluate方法

(3)自定义UDTF：继承自GenericUDTF，重写3个方法：initialize(自定义输出的列名和类型)，process(将结果返回forward(result))，close

2)为什么要自定义UDF/UDTF？

因为自定义函数，可以自己埋点Log打印日志，出错或者数据异常，方便调试。

1.6.7 窗口函数

1)Rank

(1)RANK() 排序相同时会重复，总数不会变

(2)DENSE_RANK() 排序相同时会重复，总数会减少

(3)ROW_NUMBER() 会根据顺序计算

2) OVER()：指定分析函数工作的数据窗口大小，这个数据窗口大小可能会随着行的变而变化

(1)CURRENT ROW：当前行

(2)n PRECEDING：往前n行数据

(3) n FOLLOWING：往后n行数据

(4)UNBOUNDED：起点，UNBOUNDED PRECEDING 表示从前面的起点， UNBOUNDED FOLLOWING表示到后面的终点

(5) LAG(col,n)：往前第n行数据

(6)LEAD(col,n)：往后第n行数据

(7) NTILE(n)：把有序分区中的行分发到指定数据的组中，各个组有编号，编号从1开始，对于每一行，NTILE返回此行所属的组的编号。注意：n必须为int类型。

3)手写TopN

1.6.8 Hive优化

1)MapJoin

如果不指定MapJoin或者不符合MapJoin的条件，那么Hive解析器会将Join操作转换成Common Join，即：在Reduce阶段完成join。容易发生数据倾斜。可以用MapJoin把小表全部加载到内存在map端进行join，避免reducer处理。

2)行列过滤

列处理：在SELECT中，只拿需要的列，如果有，尽量使用分区过滤，少用SELECT *。

行处理：在分区剪裁中，当使用外关联时，如果将副表的过滤条件写在Where后面，那么就会先全表关联，之后再过滤。

3)列式存储

4)采用分区技术

5)合理设置Map数

mapred.min.split.size: 指的是数据的最小分割单元大小；min的默认值是1B

mapred.max.split.size: 指的是数据的最大分割单元大小；max的默认值是256MB

通过调整max可以起到调整map数的作用，减小max可以增加map数，增大max可以减少map数。

需要提醒的是，直接调整mapred.map.tasks这个参数是没有效果的。

6)合理设置Reduce数

Reduce个数并不是越多越好

(1)过多的启动和初始化Reduce也会消耗时间和资源；

(2)另外，有多少个Reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；

在设置Reduce个数的时候也需要考虑这两个原则：处理大数据量利用合适的Reduce数；使单个Reduce任务处理数据量大小要合适；

7)小文件如何产生的？

(1)动态分区插入数据，产生大量的小文件，从而导致map数量剧增；

(2)reduce数量越多，小文件也越多(reduce的个数和输出文件是对应的)；

(3)数据源本身就包含大量的小文件。

8)小文件解决方案

(1)在Map执行前合并小文件，减少Map数：CombineHiveInputFormat具有对小文件进行合并的功能(系统默认的格式)。HiveInputFormat没有对小文件合并功能。

(2)merge

// 输出合并小文件

SET hive.merge.mapfiles = true; — 默认true，在map-only任务结束时合并小文件

SET hive.merge.mapredfiles = true; — 默认false，在map-reduce任务结束时合并小文件

SET hive.merge.size.per.task = 268435456; — 默认256M

SET hive.merge.smallfiles.avgsize = 16777216; — 当输出文件的平均大小小于16m该值时，启动一个独立的map-reduce任务进行文件merge

(3)开启JVM重用

set mapreduce.job.jvm.numtasks=10

9)开启map端combiner(不影响最终业务逻辑)

set hive.map.aggr=true；

10)压缩(选择快的)

设置map端输出、中间结果压缩。(不完全是解决数据倾斜的问题，但是减少了IO读写和网络传输，能提高很多效率)

set hive.exec.compress.intermediate=true –启用中间数据压缩

set mapreduce.map.output.compress=true –启用最终数据压缩

set mapreduce.map.outout.compress.codec=…; –设置压缩方式

11)采用tez引擎或者spark引擎

1.6.9 Hive解决数据倾斜方法

1)数据倾斜长啥样？

2)怎么产生的数据倾斜？

(1)不同数据类型关联产生数据倾斜

情形：比如用户表中user_id字段为int，log表中user_id字段既有string类型也有int类型。当按照user_id进行两个表的Join操作时。

后果：处理此特殊值的reduce耗时；只有一个reduce任务

默认的Hash操作会按int型的id来进行分配，这样会导致所有string类型id的记录都分配到一个Reducer中。

解决方式：把数字类型转换成字符串类型

select * from users a

left outer join logs b

on a.usr_id = cast(b.user_id as string)

(2)控制空值分布

在生产环境经常会用大量空值数据进入到一个reduce中去，导致数据倾斜。

解决办法：

自定义分区，将为空的key转变为字符串加随机数或纯随机数，将因空值而造成倾斜的数据分不到多个Reducer。

注意：对于异常值如果不需要的话，最好是提前在where条件里过滤掉，这样可以使计算量大大减少

3)解决数据倾斜的方法？

(1)group by

注：group by 优于distinct group

解决方式：采用sum() group by的方式来替换count(distinct)完成计算。

(2)mapjoin

(3)开启数据倾斜时负载均衡

set hive.groupby.skewindata=true;

思想：就是先随机分发并处理，再按照key group by来分发处理。

操作：当选项设定为true，生成的查询计划会有两个MRJob。

第一个MRJob中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；

第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中(这个过程可以保证相同的原始GroupBy Key被分布到同一个Reduce中)，最后完成最终的聚合操作。

点评：它使计算变成了两个mapreduce，先在第一个中在shuffle过程partition时随机给 key打标记，使每个key随机均匀分布到各个reduce上计算，但是这样只能完成部分计算，因为相同key没有分配到相同reduce上。

所以需要第二次的mapreduce，这次就回归正常shuffle，但是数据分布不均匀的问题在第一次mapreduce已经有了很大的改善，因此基本解决数据倾斜。因为大量计算已经在第一次mr中随机分布到各个节点完成。

1.6.10 Hive里边字段的分隔符用的什么？为什么用\t？有遇到过字段里边有\t的情况吗，怎么处理的？

hive 默认的字段分隔符为ascii码的控制符\001(^A),建表的时候用fields terminated by ‘\001’。注意：如果采用\t或者\001等为分隔符，需要要求前端埋点和javaEE后台传递过来的数据必须不能出现该分隔符，通过代码规范约束。一旦传输过来的数据含有分隔符，需要在前一级数据中转义或者替换(ETL)。

1.6.11 Tez引擎优点？

Tez可以将多个有依赖的作业转换为一个作业，这样只需写一次HDFS，且中间节点较少，从而大大提升作业的计算性能。

Mr/tez/spark区别：

Mr引擎：多job串联，基于磁盘，落盘的地方比较多。虽然慢，但一定能跑出结果。一般处理，周、月、年指标。

Spark引擎：虽然在Shuffle过程中也落盘，但是并不是所有算子都需要Shuffle，尤其是多算子过程，中间过程不落盘  DAG有向无环图。 兼顾了可靠性和效率。一般处理天指标。

Tez引擎：完全基于内存。  注意：如果数据量特别大，慎重使用。容易OOM。一般用于快速出结果，数据量比较小的场景。

1.6.12 MySQL

1)MySQL之元数据备份(项目中遇到的问题)

元数据备份(重点，如数据损坏，可能整个集群无法运行，至少要保证每日零点之后备份到其它服务器两个复本)

Keepalived或者用mycat

2)MySQL utf8超过字节数问题

MySQL的utf8编码最多存储3个字节，当数据中存在表情号、特色符号时会占用超过3个字节数的字节，那么会出现错误 Incorrect string value: ‘\xF0\x9F\x91\x91\xE5\xB0…’

解决办法：将utf8修改为utf8mb4

首先修改库的基字符集和数据库排序规则

再使用 SHOW VARIABLES LIKE ‘%char%’; 命令查看参数

确保这几个参数的value值为utf8mb4 如果不是使用set命令修改

如：set character_set_server = utf8mb4;

1.6.13 Union与Union all区别

1)union会将联合的结果集去重，效率较union all差

2)union all不会对结果集去重，所以效率高

1.7 Sqoop

1.7.1 Sqoop参数

/opt/module/sqoop/bin/sqoop import \

–connect \

–username \

–password \

–target-dir \

–delete-target-dir \

–num-mappers \

–fields-terminated-by   \

–query   “$2” ‘ and $CONDITIONS;’

1.7.2 Sqoop导入导出Null存储一致性问题

Hive中的Null在底层是以“\N”来存储，而MySQL中的Null在底层就是Null，为了保证数据两端的一致性。在导出数据时采用–input-null-string和–input-null-non-string两个参数。导入数据时采用–null-string和–null-non-string。

1.7.3 Sqoop数据导出一致性问题

场景1：如Sqoop在导出到Mysql时，使用4个Map任务，过程中有2个任务失败，那此时MySQL中存储了另外两个Map任务导入的数据，此时老板正好看到了这个报表数据。而开发工程师发现任务失败后，会调试问题并最终将全部数据正确的导入MySQL，那后面老板再次看报表数据，发现本次看到的数据与之前的不一致，这在生产环境是不允许的。

官网：http://sqoop.apache.org/docs/1.4.6/SqoopUserGuide.html

Since Sqoop breaks down export process into multiple transactions, it is possible that a failed export job may result in partial data being committed to the database. This can further lead to subsequent jobs failing due to insert collisions in some cases, or lead to duplicated data in others. You can overcome this problem by specifying a staging table via the –staging-table option which acts as an auxiliary table that is used to stage exported data. The staged data is finally moved to the destination table in a single transaction.

–staging-table方式

sqoop export –connect jdbc:mysql://192.168.137.10:3306/user_behavior –username root –password 123456 –table app_cource_study_report –columns watch_video_cnt,complete_video_cnt,dt –fields-terminated-by “\t” –export-dir “/user/hive/warehouse/tmp.db/app_cource_study_analysis_${day}” –staging-table app_cource_study_report_tmp –clear-staging-table –input-null-string ‘\N’

1.7.4 Sqoop底层运行的任务是什么

只有Map阶段，没有Reduce阶段的任务。默认是4个MapTask。

1.7.5 Sqoop一天导入多少数据

100万日活=》10万订单，1人10条，每天1g左右业务数据

Sqoop每天将1G的数据量导入到数仓。

1.7.6 Sqoop数据导出的时候一次执行多长时间

每天晚上00:30开始执行，Sqoop任务一般情况40 -50分钟的都有。取决于数据量(11:11，6:18等活动在1个小时左右)。

1.7.7 Sqoop在导入数据的时候数据倾斜

Sqoop 抽数的并行化主要涉及到两个参数：num-mappers：启动N个map来并行导入数据，默认4个；split-by：按照某一列来切分表的工作单元。

通过ROWNUM() 生成一个严格均匀分布的字段，然后指定为分割字段

1.7.8 Sqoop数据导出Parquet(项目中遇到的问题)

Ads层数据用Sqoop往MySql中导入数据的时候，如果用了orc(Parquet)不能导入，需转化成text格式

(1)创建临时表，把Parquet中表数据导入到临时表，把临时表导出到目标表用于可视化

(2)Sqoop里面有参数，可以直接把Parquet转换为text

(3)ads层建表的时候就不要建Parquet表

1.8 Azkaban

1.8.1 每天集群运行多少指标?

每天跑100多个指标，有活动时跑200个左右。

1.8.2 任务挂了怎么办？

运行成功或者失败都会发邮件、发钉钉、集成自动打电话(项目中遇到的问题)

最主要的解决方案就是重新跑。

1.9 Scala

1.9.1 开发环境

要求掌握必要的Scala开发环境搭建技能。

1.9.2 变量和数据类型

掌握var和val的区别

掌握数值类型(Byte、Short、Int、Long、Float、Double、Char)之间的转换关系

1.9.3 流程控制

掌握if-else、for、while等必要的流程控制结构，掌握如何实现break、continue的功能。

1.9.4 函数式编程

掌握高阶函数、匿名函数、函数柯里化、函数参数以及函数至简原则。

1.9.5 面向对象

掌握Scala与Java继承方面的区别、单例对象(伴生对象)、特质的用法及功能。

1.9.6 集合

掌握常用集合的使用、集合常用的计算函数。

1.9.7 模式匹配

掌握模式匹配的用法

1.9.8 异常

掌握异常常用操作即可

1.9.9 隐式转换

掌握隐式方法、隐式参数、隐式类，以及隐式解析机制

1.9.10 泛型

掌握泛型语法

已是最后文章

下一篇: (二)项目涉及技术