先说一些废话
总结一下Hive面试宝典，不便读者疾速过一遍Hive面试所须要的知识点
Hive的介绍
Hive和Hadoop的关系
- Hive利用hdfs存储数据，利用MapReduce查问数据
- Hive的数据存储在hdfs上，简略的说Hive就是hdfs的简略一种映射，比方：Hive的一张表映射hdfs上的一个文件，Hive的一个数据库就映射为hdfs上的文件夹
- Hive是一个计算框架，他是MapReduce的一种封装，实际上他的底层还是MR，Hive就是用人们相熟的sql对数据进行剖析的
- Hive执行程序是运行在Yarn上的
Hive的特点
- Hive能够自在的扩大集群的规模，个别状况下不须要重启服务（世界上最大的Hadoop集群在Yahoo!，2009年的规模在4000台节点左右）
- Hive反对用户自定义函数，用户能够依据本人的需要来实现本人的函数（可能会引申自定义函数）
- 良好的容错性，节点呈现问题SQL仍可实现执行（可能会拓展数据歪斜相干问题，或者间接问你你工作中有没有遇到这样的问题）
Hive的毛病
- Hive的HQL表达能力无限。迭代式算法无奈表白；数据挖掘方面不善于
- Hive的效率比拟低。Hive主动生成的MapReduce作业，通常状况下不够智能化；Hive调优比拟艰难，粒度较粗
Hive执行提早
- Hive 在查问数据的时候，因为没有索引，须要扫描整个表，因而提早较高
- 另外一个导致 Hive 执行提早高的因素是 MapReduce框架，因为MapReduce 自身具备较高的提早，因而在利用MapReduce 执行Hive查问时，也会有较高的提早
- 绝对的，数据库的执行提早较低。当然，这个低是有条件的，即数据规模较小，当数据规模大到超过数据库的解决能力的时候，Hive的并行计算显然能体现出劣势
Hive常见的利用场景
日志剖析：大部分互联网公司应用Hive进行日志剖析，包含百度、淘宝等
- 统计网站一个时间段内的pv、uv
- 多维度数据分析
- 海量结构化数据离线剖析
Hive和mysql的区别
- Hive采纳了类SQL的查询语言HQL（hive query language），除了HQL之外，其余无任何类似的中央，Hive是为了数据仓库设计的
- 存储地位：Hive在Hadoop上；mysql将数据存储在设施或本地零碎中
- 数据更新：Hive不反对数据的改写和增加，是在加载的时候就曾经确定好了；数据库能够CRUD
- 索引：Hive无索引，每次扫描所有数据，底层是MR，并行计算，实用于大数据量；mysql有索引，适宜在线查问数据
- 执行：Hive底层是MarReduce；mysql底层是执行引擎
- 可扩展性：Hive：大数据量，缓缓扩去吧；mysql:绝对就很少了
Hive的架构
# Hive架构繁难示意Meta Store -> Client (CLI/JDBC/WebGUI + Driver/驱动 + SQL Parser/解析器 + Physical Plan/编译器 + QueryOptimizer/优化器 + Execution/执行器) ->MapReduce ->HDFS用户接口：Hive 对外提供了三种服务模式，即 Hive 命令行模式（CLI），Hive 的 Web 模式（WUI），Hive 的近程服务（Client）
- 其中最罕用的是 CLI shell 命令行，CLI 启动的时候，会同时启动一个Hive正本
- WUI 是通过浏览器拜访 Hive，默认端口是9999
- Client 是Hive的客户端，，在启动 Client模式 的时候，须要指出 Hive Server 所在节点，并且在该节点启动 Hive Server
- JDBC/ODBC用 JAVA 实现，与传统数据库 JDBC 相似
元数据存储：通常是存储在关系数据库如 mysql , derby中
- Hive中的元数据包含表的名字，表的列和分区及其属性，表的属性（是否为内部表等），表的数据所在目录等
解释器、编译器、优化器、执行器
- 解释器、编译器、优化器实现 HQL 查问语句从词法剖析、语法分析、编译、优化以及查问打算的生成
- 生成的查问打算存储在 HDFS 中，并在随后有 MapReduce 调用执行（留神！！！蕴含的查问，比方select from tbl不会生成MapRedcue工作）
- ===============================================================
- 解析器（parser）：将查问字符串转化为解析树表达式
- ===============================================================
- 编译器（physical plan）：分为
语义分析器（semantic analyzer）和逻辑策略生成器（logical plan generator） - 语义分析器（semantic analyzer）：将解析树表达式转换为基于块（block-based）的外部查问表达式
- 逻辑策略生成器（logical plan generator）：将外部查问表达式转换为逻辑策略，这些策略由逻辑操作树组成
- ===============================================================
- 优化器（optimizer）：通过逻辑策略结构多路径并以不同形式重写
Hive的数据
Hive的数据模型
- Hive中所有的数据都存储在hdfs中，没有专门的数据存储格局（可反对TextFile，SequenceFile，ParquetFile，RCFILE等）
- 只须要在创立表的时候通知Hive数据中的列分隔符和行分隔符，Hive就能够解析数据
Hive中蕴含以下数据模型：DB、Table、External Table、Partition、Bucket
- DB：在hdfs中体现为
${hive.metastore.warehouse.dir}目录下一个文件夹 - Table：在hdfs中体现所属db目录下一个文件夹，一般表删除表后，hdfs上的文件都删了
- External Table：内部表, 与table相似，不过其数据寄存地位能够在任意指定门路，内部表删除后，hdfs上的文件没有删除，只是把文件删除了
- Partition：在hdfs中体现为table目录下的子目录
- Bucket：桶在hdfs中体现为同一个表目录下依据hash散列之后的多个文件，会依据不同的文件把数据放到不同的文件中
- DB：在hdfs中体现为
Hive的底层如何存储Null值
- Null在Hive底层默认是用'\N'来存储的
- 可能通过
alter table test SET SERDEPROPERTIES('serialization.null.format' = 'a');来批改
Hive中元数据metadata和元数据商店metastore的作用
- metadata即元数据，元数据蕴含用Hive创立的database、tabel等的元信息，元数据存储在
关系型数据库(RDBMS)中，如derby、mysql等 - metastore的作用是：客户端连贯metastore服务，metastore再去连贯mysql数据库来存取元数据，
有了metastore服务，就能够有多个客户端同时连贯，而且这些客户端不须要晓得mysql数据库的用户名和明码，只须要连贯metastore服务即可
Hive有哪些保留元数据metadata的形式
- 内嵌模式：将元数据保留在本地内嵌的derby数据库中，内嵌的derby数据库每次只能拜访一个数据文件，也就意味着它不反对多会话连贯，实用于用来试验，不适用于生产环境
- 本地模式：将元数据保留在本地独立的数据库中（个别是mysql），这能够反对多会话连贯
- 近程模式：把元数据保留在近程独立的mysql数据库中，防止每个客户端都去装置mysql数据库
- 须要留神的是： 内存数据库derby，装置小，然而数据存在内存，不稳固。mysql数据库，数据存储模式能够本人设置，长久化好，查看不便
Hive元数据存储形式中，本地模式和近程模式的区别
- 本地元存储和近程元存储都采纳内部数据库来存储元数据
- 本地元存储不须要独自起metastore服务，用的是跟Hive在同一个过程里的metastore服务
- 近程元存储须要独自起metastore服务，而后每个客户端都在配置文件里配置连贯到该metastore服务，近程元存储的metastore服务和Hive运行在不同的过程
Hive的数据类型
根本数据类型，因为Hive的底层是用java开发，所以根本数据类型和java保持一致
- 整型 tinyint(字节整型) / smallint(短整型) / int(整型) / bigint(长整型)，别离占用1/2/4/8个字节，等价于java的 byte/short/int/long
- 浮点型 float(浮点型) / double(双精度浮点型)，别离占用4/8个字节，等价于java的 float/double
- 字符型 string，等价于数据库的 varchar，可变字符串，实践上能够存储2GB的字节
- 布尔型 boolean，等价于java的 boolean
简单数据类型
- array/map，等价于java的array/map
- struct，等价于c语言中的struct
类型转换
- Hive 的原子数据类型是能够进行隐式转换的，相似于 Java 的类型转换
- 例如某表达式应用 int 类型，tinyint 会主动转换为 int 类型
- 然而 Hive 不会进行反向转化，例如，某表达式应用 tinyint 类型，int 不会主动转换为 tinyint 类型，它会返回谬误，除非应用 CAST 操作
- ===============================================================
- 能够应用 CAST 操作显示进行数据类型转换
- 例如 CAST('1' AS INT) 将把字符串'1' 转换成整数 1
- 如果强制类型转换失败，如执行 CAST('X' AS INT)，表达式返回空值 NULL
Hive的隐式类型转换规定
- 任何整数类型都能够隐式地转换为一个范畴更广的类型，如 tinyint 能够转换成 int，int 能够转换成 bigint
- 所有整数类型、float 和 string 类型都能够隐式地转换成 double
- tinyint、smallint、int 都能够转换为 float
- boolean 类型不能够转换为任何其它的类型
Hive数据存储所应用的文件格式
默认是TextFile文件格式
- 文本格式，Hive的默认格局，数据不压缩，磁盘开销大、数据解析开销大
- 对应的Hive API为：
org.apache.hadoop.mapred.TextInputFormat和org.apache.hive.ql.io.HiveIgnoreKeyTextOutputFormat; - 可联合Gzip、Bzip2应用(零碎主动查看，执行查问时主动解压)，然而应用这种形式，hive不会对数据进行切分，从而无奈对数据进行并行操作
RCFile文件格式
- RCFile是一种行列存储相结合的存储形式，先将数据按行进行分块再按列式存储，保障同一条记录在一个块上，防止读取多个块，有利于数据压缩和疾速进行列存储
- 对应Hive API为：
org.apache.hadoop.hive.ql.io.RCFileInputFormat和org.apache.hadoop.hive.ql.io.RCFileOutputFormat;
ORCFile文件格式
- 数据按行分块，每块依照列存储，不是真正意义上的列存储，能够了解为分段列存储
- 用于升高Hadoop数据存储空间和减速Hive查问速度
- ORCfile特点是压缩比比拟高，压缩快，疾速列存取，是RCfile的改进版本，相比RCfile可能更好的压缩，更快的查问
- 须要留神的是ORC在读写时候须要耗费额定的CPU资源来压缩和解压缩，当然这部分的CPU耗费是非常少的
长处：
每个task只输入单个文件，缩小namenode负载；反对各种简单的数据类型，比方：datetime，decima以及简单类型struct、list、map；文件中存储了一些轻量级的索引数据；基于数据类型的块模式压缩：integer类型的列用行程长度编码，string类型的列应用字典编码；用多个互相独立的recordReaders并行读雷同的文件无需扫描markers即可宰割文件绑定读写所需内存metadata存储用protocol buffers，反对增加和删除列
SequenceFile文件格式
- Hadoop提供的二进制文件，Hadoop反对的标准文件
- 数据间接序列化到文件中，SequenceFile文件不能间接查看，能够通过Hadoop fs -text查看
- SequenceFile具备使用方便、可宰割、可压缩、可进行切片，压缩反对NONE、RECORD、BLOCK（优先）
- 对应Hive API：
org.apache.hadoop.mapred.SequenceFileInputFormat和org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat;
Parquet文件格式
- 二进制存储，面向剖析性的存储格局
- 可能很好的压缩，同时缩小大量的表扫描和反序列化的工夫，有很好的查问性能，反对无限的模式演进，然而写速度通常比较慢
- Parquet文件是以二进制形式存储的，所以是不能够间接读取的，文件中包含该文件的数据和元数据，因而Parquet格式文件是自解析的
总结
- TextFile 存储空间耗费比拟大，并且压缩的text无奈宰割和合并查问的效率最低，能够间接存储，加载数据的速度最高
- SequenceFile 存储空间耗费最大，压缩的文件能够宰割和合并，查问效率高
- ORCFile / RCFile 存储空间最小，查问的效率最高，加载的速度最低
- Parquet 格局是列式存储，有很好的压缩性能和表扫描性能
- SequenceFile / ORCFile / RCFile 格局的表不能间接从本地文件导入数据，数据要先导入到TextFile格局的表中，
而后再从TextFile表中导入到SequenceFile/ORCFile/RCFile表中
Hive中应用的压缩算法
- 咱们原始数据应用的是LZO的压缩格局，因为原始数据比拟大，所以抉择了反对切割的LZO压缩
- 荡涤过的数据存到DWD层，咱们在DWS中须要对荡涤后的数据进行剖析，所以咱们DWD层应用的存储格局是Parquet，压缩格局是Snappy
- 之前咱们压缩还遇到过一个问题，过后之前的我的项目中应用的是Snappy+ORC存储，起初我发现应用Snappy+ORC 存储比ORC独自存储还多占用了近一半的空间
- 起初我又对各个压缩格局及存储格局的联合做了一个测试，最终独自应用ORC存储节俭了大量的空间
Snappy压缩格局
- 其中压缩比bzip2 > zlib > gzip > deflate > snappy > lzo > lz4，在不同的测试场景中，会有差别，这仅仅是一个大略的排名状况
- bzip2、zlib、gzip、deflate能够保障最小的压缩，但在运算中过于耗费工夫
- 从压缩性能上来看：lz4 > lzo > snappy > deflate > gzip > bzip2，其中lz4、lzo、snappy压缩和解压缩速度快，压缩比低
- 所以个别在生产环境中，常常会采纳lz4、lzo、snappy压缩，以保障运算效率
什么是数据可宰割
- 在思考如何压缩那些将由MapReduce解决的数据时，思考压缩格局是否反对宰割是很重要的。
思考存储在HDFS中的未压缩的文件，其大小为1GB，HDFS的块大小为64MB，所以该文件将被存储为16块。
将此文件用作输出的MapReduce作业会创立1个输人分片（split，也称为“分块”。对于block，咱们对立称为“块”。）
每个分片都被作为一个独立map工作的输出独自进行解决 - 当初假如，该文件是一个gzip格局的压缩文件，压缩后的大小为1GB。和后面一样，HDFS将此文件存储为16块。
然而，针对每一块创立一个分块是没有用的，因为不可能从gzip数据流中的任意点开始读取，map工作也不可能独立于其余分块只读取一个分块中的数据。
gzip格局应用DEFLATE来存储压缩过的数据，DEFLATE将数据作为一系列压缩过的块进行存储。
问题是，每块的开始没有指定用户在数据流中任意点定位到下一个块的起始地位，而是其本身与数据流同步。
因而，gzip不反对宰割(块)机制。 - 在这种状况下，MapReduce不宰割gzip格局的文件，因为它晓得输出是gzip压缩格局的(通过文件扩展名得悉)，而gzip压缩机制不反对宰割机制。
因而一个map工作将解决16个HDFS块，且大都不是map的本地数据。
与此同时，因为map工作少，所以作业宰割的粒度不够细，从而导致运行工夫变长。
对于压缩模式阐明
压缩模式评估：
可应用以下三种规范对压缩形式进行评估：压缩比：压缩比越高，压缩后文件越小，所以压缩比越高越好。压缩工夫：越快越好。曾经压缩的格式文件是否能够再宰割：能够宰割的格局容许繁多文件由多个Mapper程序处理，能够更好的并行化。压缩模式比照
BZip2有最高的压缩比但也会带来更高的CPU开销，Gzip较BZip2次之。如果基于磁盘利用率和I/O思考，这两个压缩算法都是比拟有吸引力的算法。LZO和Snappy算法有更快的解压缩速度，如果更关注压缩、解压速度，它们都是不错的抉择。 LZO和Snappy在压缩数据上的速度大抵相当，但Snappy算法在解压速度上要较LZO更快。Hadoop的会将大文件宰割成HDFS block(默认64MB)大小的splits分片，每个分片对应一个Mapper程序。在这几个压缩算法中 BZip2、LZO、Snappy压缩是可宰割的，Gzip则不反对宰割。
Hive的装置与应用
以后版本请浏览以下参考资料，前期再行欠缺
- hive的装置和应用
- Hive入门及罕用指令
- 更多进阶内容请自行百度拓展查阅
如何在Hive中集成HBase
- 将Hbase的客户端
jar拷贝至Hive/lib目录下 批改
hive/conf下的hive-site.xml配置文件，增加如下属性：<poperty> <name>hbase.zookeeper.quorum</name> <value>hadoop</value></poperty>- 启动Hive，创立表治理表
hbase_table_1，指定数据存储在Hbase表中，次要是通过stored by HBaseStorageHandler类来实现 - 往Hive表
hbase_table_1表中插入数据
如何通过 HiveSQL 来间接读写 HBase
以后版本请浏览以下参考资料，前期再行欠缺
- 如何整合hive和hbase
- HiveHbase集成实际
- 更多进阶内容请自行百度拓展查阅
Hive的分区和分桶
Hive的分辨别桶都是数据存储和组织的策略，分区相似文件的分类归档，分桶相似于传统数据库的索引
什么是Hive分区
- Hive中数据库，表，及分区都是在HDFS存储的一个形象
- Hive中的一个分区对应的就是HDFS的一个目录，目录名就是分区字段
- 申明分区表
PARTITIONED BY (name string)，分区键不能和任何列重名 - 申明数据要导入的分区
PARTITION(name="fx67ll") - 查看分区
SHOW PARTITIONAS - 依据分区查问
WHERE name = "fx67ll" 指定切分格局
ROW FORMAT DELIMITED# 每个字段之间由[ , ]宰割FIELDS TERMINATED BY ','# 字段是Array模式，元素与元素之间由[ - ]宰割COLLECTION ITEMS TERMINATED BY '-'# 字段是K-V模式，每组K-V对外部由[ : ]宰割MAP KEYS TERMINATED BY ':';
Hive分区的长处
- 如果一个表中有大量的数据，咱们全副拿进去做查词的性能，耗时比拟长，查问较慢，
应用了分区，就能够做到用到了那个分区就拿那个分区中的数据不便了查问，进步了查词的效率 - 横向调配数据，使得负载更为平衡
Hive分区的毛病
- 容易造成过多的小分区，过多的目录
- 如果分区策略不佳，容易导致分区数据不平衡，造成数据歪斜
什么是Hive分桶
- 分桶是绝对分区进行更细粒度的划分，分桶将整个数据内容依照某列属性值得hash值进行辨别，相似于关系型数据的索引
- 如要装置id属性分为3个桶，就是对id属性值的hash值对3取摸，依照取模后果对数据分桶，
如取模后果为0的数据记录寄存到一个文件，取模为1的数据寄存到一个文件，取模为2的数据寄存到一个文件 - 分桶之前要执行命令
set hive.enforce.bucketing = true - 申明分桶表
CLUSTERED BY(id) INTO 3 BUCKETS
对于Hive索引的阐明
即从3.0开始索引曾经被移除，有一些可代替的计划可能与索引相似：
- 具备主动重写的物化视图能够产生十分类似的后果，Hive2.3.0减少了对物化视图视图的反对
- 应用列式文件格式（(Parquet、ORC）–他们能够进行选择性扫描；甚至能够跳过整个文件/块。很显然，例如咱们创立表时应用的ORC格局就曾经具备了索引的性能
Hive为什么删除了索引：
- 因为Hive是针对海量数据存储的，创立索引须要占用大量的空间，最次要的是Hive索引无奈主动进行刷新，也就是当新的数据退出时候，无奈为这些数据主动退出索引
Hive分桶的长处
- 分桶字段须要依据业务进行设定，能够解决数据歪斜问题，次要是在关联join的时候通过map端更快的连贯
- 可能提供相似的哈希的疾速响应，比分区更快
Hive分桶的毛病
- 须要在建表时布局好分桶策略，须要手动加载数据到分桶表
- 实质是空间换工夫，工夫换效率，所以在加载数据到表的时候有空间和工夫上的耗费
Hive中动态分区和动静分区的区别
- 动态分区与动静分区的次要区别在于动态分区是手动指定，而动静分区是通过数据来进行判断
- 具体来说，动态分区的列切实编译期间，通过用户传递来决定的；动静分区只有在SQL执行时能力决定
- 查问和写入的时候，动态分区键要用
<static partition key> = <value>指定分区值；动静分区只须要给出分出分区键名称<dynamic partition key> - 一张表可同时被动态和动静分区键分区，只是动静分区键须要放在动态分区建的前面，因为HDFS上的动静分区目录下不能蕴含动态分区的子目录
Hive动静分区的参数设定
开启动静分区
# 开启动静分区性能，默认false set hive.exec.dynamic.partition = true # 容许所有分区都是动静的，否则必须有动态分区字段，默认strict set hive.exec.dynamic.partition.mode = nonstrict动静分区参数调优
# 每个mapper或reducer能够容许创立的最大动静分区个数，默认是100，超出则会报错 set hive.exec.max.dynamic.partitions.pernode = 1000# 一个动静分区语句能够创立的最大动静分区个数，默认是1000，超出报错set hive.exec.max.dynamic.partitions = 10000 # 全局能够创立的最大文件个数，默认是10000，超出报错 set hive.exec.max.created.files =100000
Hive的外部表和内部表
什么是Hive的外部表和内部表
- 没有
external润饰，表数据保留在Hive默认的门路下，数据齐全由Hive治理，删除表时元数据(metadata)和表数据都会一起删除 - 有
external润饰，表数据保留在HDFS上，该地位由用户指定，删除表时，只会删除表的元数据(metadata)
Hive外部表和内部表的区别是什么
- 外部表数据由Hive本身治理，内部表数据由HDFS治理
- 外部表数据存储的地位是
hive.metastore.warehouse.dir，默认是/user/hive/warehouse - 内部表数据的存储地位由本人制订，如果没有LOCATION，Hive将在HDFS上的
/user/hive/warehouse文件夹下以内部表的表名创立一个文件夹，并将属于这个表的数据寄存在这里 - 删除外部表会间接删除元数据(metadata)及存储数据
- 删除内部表仅仅会删除元数据(metadata)，HDFS上的文件并不会被删除
- 对外部表的批改会将批改间接同步给元数据(metadata)，而对外部表的表构造和分区进行批改，则须要修复
MSCK REPAIR TABLE table_name
生产环境中为什么倡议应用内部表
- 因为内部表不会加载数据到Hive，缩小数据传输，数据还能共享
- Hive不会批改数据，所以无需放心数据的损坏
- 删除表时，只删除表构造，不删除数据
Hive SQL
Hive中的SQL如何转化成MapReduce工作的
Antlr定义SQL的语法规定，实现SQL词法，语法解析，将SQL转化为形象语法树- 遍历形象语法树形象出查问的根本组成单元
QueryBlock - 遍历
QueryBlock，翻译为执行操作树OperatorTree - 逻辑层优化器进行
OperatorTree变换，合并不必要的ReduceSinkOperator，缩小shuffle数据量 - 遍厉
OperatorTree，翻译为MapReduce工作 - 物理层优化器进行
MapReduce工作的变换，生成最终的执行打算
什么状况下Hive不走MapReduce工作
Hive中如何查问A表中B表不存在的数据
题目：A、B两表，找出ID字段中，存在A表，然而不存在B表的数据。A表总共13w数据，去重后大概3W条数据，B表有2W条数据，且B表的ID字段有索引
select * from Bwhere (select count(1) as num from A where A.ID = B.ID) = 0Hive中有哪些连贯查问以及如何应用
以后版本请浏览以下参考资料，前期再行欠缺
- Hive——join的应用
- 更多进阶内容请自行百度拓展查阅
Hive中左连贯和内连贯的区别
- 内连贯：连贯的键匹配上就连贯，没有匹配上就过滤掉
- 左连贯：以左表为基准，与右表做关联，关联上则连贯，右表关联不上的则为null
Hive中左连贯的底层原理
参考上面Hive查问的时候on和where有什么区别的了解二
Hive查问的时候 ON 和 WHERE 有什么区别
共同点
- on先执行，where后执行
并且where是对连贯之后的后果进行的查问条件
第一种了解形式
- 条件不为主表条件的时候，放在on和where的前面一样
条件为主表条件的时候，放在on前面，后果为主表全量，放在where前面的时候为主表条件筛选过后的全量
- select * from a left join b on a.id = b.id and a.dt=20181115;
- select * from a left join b on a.id = b.id and b.dt=20181115;
- select * from a join b on a.id = b.id and a.dt=20181115;
select * from a left join b on a.id = b.id where a.dt=20181115;
sql1: 如果是left join 在on上写主表a的条件不会失效，全表扫描。
sql2: 如果是left join 在on上写副表b的条件会失效，然而语义与写到where 条件不同
sql3: 如果是inner join 在on上写主表a、副表b的条件都会失效
sql4: 倡议这么写，大家写sql大部分的语义都是先过滤数据而后再join，所以在不理解join on+条件的状况下，条件尽量别写在on后，
间接写到where后就ok了，如果where条件后写b表的过滤条件，就变成了先left join出后果再依照b条件过滤数据on是在生成连贯表的起作用的，where是生成连贯表之后对连贯表再进行过滤- 当应用
left join时，无论on的条件是否满足，都会返回左表的所有记录，对于满足的条件的记录，两个表对应的记录会连接起来，对于不满足条件的记录，那右表字段全副是null - 当应用
right join时，相似，只不过是全副返回右表的所有记录 当应用
inner join时，性能与where完全相同通过亲测后，更加深了对on和where的了解，得出以下论断：1.ON后的条件如果有过滤主表的条件，则后果对于不合乎该条件的主表数据也会原条数保留，只是不匹配右表数据而已。对于on前面对右表的过滤条件，连贯时会用该条件间接过滤右表数据后再和右边进行左连贯。总之，对于不满足on前面的所有条件的数据，左表会在后果数据中原条数保留数据，只是不匹配右表数据而已。不满足条件的右表数据各字段会间接以NULL连贯主表。2.ON后对左表的筛选条件对于后果行数会被疏忽，但会影响后果中的匹配右表数据，因为只有合乎左表条件的数据才会去和符合条件的右表数据进行匹配，不符合条件的左表数据会保留在最初后果中，但匹配的右表数据都是NULL.因而，对于须要过滤左表数据的话，须要把过滤条件放到where前面。3.ON后的左表条件（独自对左表进行的筛选条件）对于后果行数无影响，还是会返回所有左表的数据，但和右表匹配数据时，零碎只会拿左表符合条件（ON后的对左表过滤条件）的数据去和右表符合条件（ON后的对右表过滤条件）的数据进行匹配抓取数据，而不符合条件的左表数据还是会呈现在后果列表中，只是对应的右表数据都是NULL。4.ON后的右表条件（独自对右表进行的筛选条件）会先对右表进行数据筛选后再和左表做连贯查问，对后果行数有影响（当左表对右表是一对多时），但不会影响左表的显示行数，而后拿符合条件的右表数据去和符合条件的左表数据进行匹配。5.Where还是对连贯后的数据进行过滤筛选，这个无异议。6.匹配数据时无论左右表，都是拿合乎ON后的过滤条件去做数据匹配，不合乎的会保留左表数据，用NULL填充右表数据。综上得出，ON前面对于左表的过滤条件，在最初后果行数中会被疏忽，并不会先去过滤左表数据再连贯查问，然而ON后的右表条件会先过滤右表数据再连贯左表进行查问。连贯查问时，都是用合乎ON后的左右表的过滤条件的数据进行连贯查问，只有合乎左右表过滤条件的数据能力正确匹配，剩下的左表数据会失常呈现在后果集中，但匹配的右表数据是NULL。因而对于左表的过滤条件切记要放到Where后，对于右表的过滤条件要看状况了。如果须要先过滤右表数据就把条件放到ON前面即可。
Hive 函数
对于 UDF/UDAF/UDTF 的发问
- 如何应用UDF/UDAF/UDTF
- 为什么应用UDF/UDAF/UDTF
- 你写过什么样的UDF/UDAF/UDTF
- Hive自定义函数实现了什么函数
上述四个问题自行 参考资料 并联合工作中理论场景来作答，没有标准答案
Hive中如何去重
第一种形式：应用 DISTINCT
- 对select 前面所有字段去重，并不能只对一列去重
- 当
DISTINCT利用到多个字段的时候，DISTINCT必须放在结尾，其利用的范畴是其前面的所有字段，而不只是紧挨着它的一个字段，而且DISTINCT只能放到所有字段的后面 DISTINCT对NULL是不进行过滤的，即返回的后果中是蕴含NULL值的聚合函数中的
DISTINCT,如count()会过滤掉为NULL第二种形式：应用
GROUP BY对
GROUP BY前面所有字段去重，并不能只对一列去重第三种形式：应用
ROW_NUMBER() OVER窗口函数- 参考资料一：一种奇妙的hive sql数据去重办法
- 参考资料二：Hive--数据去重及row_number()
- 参考资料三：Hive(十一)--数据去重及row_number()
Hive中排序函数的应用形式及区别
order by会对输出做全局排序，为保障全局的排序，因而只有一个reducer，会导致当输出规模较大时，须要较长的计算工夫。sort by不是全局排序，其在数据进入reducer前实现排序。因而，如果用sort by进行排序，则sort by只保障每个reducer的输入有序，不保障全局有序。distribute by 字段依据指定的字段将数据分到不同的reducer，且散发算法是hash散列，罕用sort by联合应用，Hive要求distribute by语句要写在sort by语句之前。cluster by 字段除了具备distribute by的性能(既能够把数据分到不同的reduce)外，还会对该字段进行排序。然而排序只能是倒序排序，不能指定排序规定为asc或者desc因而：
- 当数据量规模较大时，不应用
order by，应用用distribute by + sort by - 如果
distribute by和sort by字段是同一个时，此时，cluster by = distribute by + sort by
- 当数据量规模较大时，不应用
Hive中局部高频函数 ———— split / coalesce / collect list / collect set
- Hive ———— split
- Hive ———— coalesce
- Hive ———— collect list/collect set
Hive罕用函数
- Hive罕用的函数总结
- Hive函数大全
Hive 运维
如何监控一个提交后的Hive状态
- 应用java代码提交Hive，通过HiveStatement获取日志数据并解析出
application_id - 就能够通过
application_id去yarn上查看运行状态
Hive 优化
该模块请参考我对于Hive优化的文章
- 点击拜访 ————> Hive在工作中的调优总结
- 点击拜访 ————> HiveSQL工作实战总结
我是 fx67ll.com，如果您发现本文有什么谬误，欢送在评论区探讨斧正，感谢您的浏览！
如果您喜爱这篇文章，欢送拜访我的 本文github仓库地址，为我点一颗Star，Thanks~ :)
转发请注明参考文章地址，非常感谢！！！