深圳宝安住房和建设局网站,wordpress the,官网seo是什么意思,房地产企业网站开发HIVE面试题
内部表和外部表的区别
未被external修饰的是内部表#xff0c;被external修饰的是外部表#xff1b;
内部表数据由Hive自身管理#xff0c;外部表由HDFS管理#xff1b;
删除内部表会直接删除元数据及存储数据#xff0c;删除外部表#xff0c;仅仅会删除…HIVE面试题
内部表和外部表的区别
未被external修饰的是内部表被external修饰的是外部表
内部表数据由Hive自身管理外部表由HDFS管理
删除内部表会直接删除元数据及存储数据删除外部表仅仅会删除元数据数据文件不会删除。
分区和分桶的区别
分区是按照分区字段在HDFS上建立子文件夹分区内的数据存放在子文件夹内查询时不需要全局扫描只扫描对应分区文件夹的数据。
而分桶是按分桶字段对数据取hash值值相同的放在同一个分桶文件里分桶生成的是分桶文件分区对应的是子文件夹
分区和分桶最大的区别是
首先分桶是随机的分割数据分区是非随机的分割数据分桶是按照分桶字段取哈希函数相对比较均匀分区表按照分区字段的值进行分割容易产生数据倾斜。
其次分桶对应的是不同的文件分区对应的是HDFS上的目录桶表对应的是目录里的文件。
hive的文件存储格式
TextFile:hive的默认存储格式行存储数据不做压缩需结合GZip/BZip2压缩加载数据速度最快但磁盘开销较大查询效率较低SequenceFile:行存储压缩文件可分割和合并查询效率较高但存储空间消耗较大。RcFile:数据按行分块每块再按照列存储查询效率较高压缩快快速列存取存储空间较小不支持implala查询引擎OrcFile:数据按行分块每块再按列存储压缩快快速列存取效率比RcFile更快是Rcfile的改良不支持impala查询引擎Parquet:列存储相对于RC格式压缩比较低查询效率较低但是支持impala、Presto等查询引擎及Spark计算引擎支持Hadoop生态中其它组件的结合
附加:Hive压缩格式:gzib,bzip2,lzo,snappy,其中snappy的压缩比和压缩速度及解压缩速度最快我司用parquet存储snappy压缩格式
Hive执行一段sql后会经过什么步骤
语法解析:将sql语句转换为抽象的语法树语义解析:遍历语法树抽象出查询的基本组成单元QueryBlock生成逻辑执行计划:遍历QueryBlock生成操作树优化逻辑执行计划:生成物理执行计划:遍历操作树编译成MR任务优化物理执行计划:对MR任务进行转换,生成最终执行计划
HiveSQL调优
尽量减少使用distinct改用group by ,distinct 只使用一个reduce处理一个Reduce处理数据量太大容易产生数据倾斜null值容易产生数据倾斜可以对null值先过滤处理然后再与其它数据union,也可以对null值采用字符串拼接随机数字的方式让null值数据分散在不同的reduce处理对于多次查询使用的sql通过with语法放到内存中多次使用减少重复计算多个union all 的情况下放在最后再使用group by 操作这样减少MR作业数列裁剪编写sql时只查询需要的列多使用分区信息in/exists 改成left semi join 更高效
Hive小文件是如何产生的原因、影响和解决方案
产生原因:
1.动态分区插入数据产生大量的小文件从而导致map数量剧增。
2.reduce数量越多小文件也越多(reduce的个数和输出文件是对应的)。
3.数据源本身就包含大量的小文件。
过多小文件问题的影响
1.从Hive的角度看小文件会开很多map一个map开一个JVM去执行,所以这些任务的初始化启动执行会浪费大量的资源严重影响性能。
2.在HDFS中每个小文件对象约占150byte如果小文件过多会占用大量内存这样NameNode内存容量严重制约了集群的扩展。
小文件问题的解决方案
从小文件产生的途经就可以从源头上控制小文件数量
1.使用ORC或Parquet格式作为表存储格式不要用textfile在一定程度上可以减少小文件。
2.减少reduce的数量(可以使用参数进行控制)。
3.少用动态分区用时记得按distribute by分区。
4.使用hadoop archive命令把小文件进行归档。
5.开启map端小文件合并
Hive参数调优
合理控制Map和Reduce数量 Map: 合并小文件,减少map个数set hive.merge.mapredfiles true; --开启小文件合并增加map个数:当文件很小小于128M,但是数据量有几千万行放到一个map中执行很慢可以通过自定义map个数增加map数:set mapred.map.tasks10;
Reduce: reduce的个数设定极大影响任务执行效率不指定reduce个数的情况下Hive会根据默认配置计算reduce个数.
reduce个数的计算公式Min(每个job最大reduce数,总输入数据量/每个reduce处理的数据量)
hive.exec.reducers.bytes.per.reducer每个reduce任务处理的数据量默认为1000^31G
hive.exec.reducers.max每个任务最大的reduce数默认为999 手动指定reduce个数set mapred.reduce.tasks 15;
哪些情况下不管数据量多的不管如何配置参数只有一个reduce
1.没使用group by, select count()
2.用了order by
3.有笛卡尔集
(这些情况都是全局的)
开启本地执行: set hive.exec.mode.local.autotruel; 数据量较小的查询直接在本地节点查询开启fetch执行:set hive.fetch.task.conversionmore; 一些全局查询、字段查询、limit查找都不走mapRecuce开启map端聚合:set hive.map.aggr true;有数据倾斜时进行负载均衡:set hive.groupby.skewindata true;开启并行执行:
set hive.exec.paralleltrue; //打开任务并行执行 set hive.exec.parallel.thread.number16; //同一个sql允许最大并行度默认为8。
JVM的重用:开启推测执行:因为程序Bug、负载不均衡或者资源分布不均等原因会造成同一个作业的多个任务之间运行速度不一致有些任务的运行速度可能明显慢于其他任务比如一个作业的某个任务进度只有50%而其他所有任务已经运行完毕则这些任务会拖慢作业的整体执行进度。为了避免这种情况发生Hadoop采用了推测执行Speculative Execution机制它根据一定的法则推测出“拖后腿”的任务并为这样的任务启动一个备份任务让该任务与原始任务同时处理同一份数据并最终选用最先成功运行完成任务的计算结果作为最终结果。
数据倾斜怎么解决
空值引发的数据倾斜
解决方案
第一种可以直接不让null值参与join操作即不让null值有shuffle阶段
第二种因为null值参与shuffle时的hash结果是一样的那么我们可以给null值随机赋值这样它们的hash结果就不一样就会进到不同的reduce中
不同数据类型引发的数据倾斜
解决方案
如果key字段既有string类型也有int类型默认的hash就都会按int类型来分配那我们直接把int类型都转为string就好了这样key字段都为stringhash时就按照string类型分配了
不可拆分大文件引发的数据倾斜
解决方案
这种数据倾斜问题没有什么好的解决方案只能将使用GZIP压缩等不支持文件分割的文件转为bzip和zip等支持文件分割的压缩方式。
所以我们在对文件进行压缩时为避免因不可拆分大文件而引发数据读取的倾斜在数据压缩的时候可以采用bzip2和Zip等支持文件分割的压缩算法。
数据膨胀引发的数据倾斜
解决方案
在Hive中可以通过参数 hive.new.job.grouping.set.cardinality 配置的方式自动控制作业的拆解该参数默认值是30。表示针对grouping sets/rollups/cubes这类多维聚合的操作如果最后拆解的键组合大于该值会启用新的任务去处理大于该值之外的组合。如果在处理数据时某个分组聚合的列有较大的倾斜可以适当调小该值。
表连接时引发的数据倾斜
解决方案
通常做法是将倾斜的数据存到分布式缓存中分发到各个Map任务所在节点。在Map阶段完成join操作即MapJoin这避免了 Shuffle从而避免了数据倾斜。
确实无法减少数据量引发的数据倾斜
解决方案
这类问题最直接的方式就是调整reduce所执行的内存大小。
调整reduce的内存大小使用mapreduce.reduce.memory.mb这个配置。
Spark面试题
Spark的执行原理流程
SparkContext向资源管理器注册并申请资源 ----
资源管理器根据资源情况分配Executor,然后启动Executor --
Executor启动后发送心跳至资源管理器 ---
SparkContext根据RDD之间依赖关系构建DAG运行图 ---
然后将DAG图分解成多个Stage ---
把Stage发送给StageScheduler --
每个stage包含一个或多个task任务StageScheduler将Task发放给Executor运行,同时SparkContext将应用程序代码发给Executor ---
Task在Executor上运行运行完毕释放所有资源
Stage划分依据Stage划分的依据是宽依赖遇到窄依赖就加入本stage,遇到宽依赖进行Stage切分
何时产生宽依赖reduceByKey, groupByKey等算子会导致宽依赖的产生。
Spark on Yarn Yarn-cluster模式和Yarn-client 模式的区别:
Yarn-Cluster模式下Driver运行在Application Master上Application Master 同时负责从Yarn申请资源并监督作业的运行情况,用户提交作业之后客户端就可以关闭作业会继续在Yarn上运行。
Yarn-clinet模式下Driver是运行在客户端Applicatiion Master仅仅向Yarn请求Executor,然后有client跟containner通信调度工作所以client不能关闭。
Job、Stage、task的概念:
Spark中的数据都是抽象为RDD的RDD分为transformation算子和action算子转换算子不会被真正执行只有遇到行动算子时任务才会被执行提交一个Job每遇到有一个Action算子生成一个job;每个Job包含一个或多个Stage而Stage是由RDD之间的宽窄依赖决定的遇到宽依赖就会进行shuffle进行Stage的拆分遇到窄依赖就加入到该Stage中Stage继续往下拆解就是Task,Task是Spark执行的最小单元Task的数量其实就是Stage的并行度
Spark的shuffle 和 Hadoop的shuffle的联系和区别:
联系:两者都是将Mapper端的输出数据按key进行Partition,不同的Partition送到不同的reduce进行处理;Spark中的很多计算是作为MR计算框架的一种优化实现。
区别:
从逻辑角度来看:
shuffle 就是一个GroupByKey的过程两者没有本质区别。只是MR有多次排序Spark尽量避免了MR shuffle中的多余的排序
从实现角度看:
MR将处理流程划分出明显的几个阶段:map,splil,merge,shuffle,sort,reduce等每个阶段各司其职按串行的方式实现每个阶段的功能; 在Spark中没有这样功能明确的阶段只有不同的Stage和一系列的transformation操作所以splil,merge,aggregate等操作都包含着Transformation中
从数据流角度看:
Mr 只能从一个map stage接受数据Spark可以从多个Map stage shuffle数据宽依赖可以有多个数据源
从数据粒度角度:
Spark的粒度更细可以更及时的获取到record 与HashMap中相同的records进行合并
从性能优化角度:
Spark考虑的更全面Spark针对不同类型的操作、不同类型的参数会使用不同类型的shuffle
哪些算子涉及到shuffle操作 sortBykey,groupBykey、reduceBykey、join、countBykey、cogroup等聚合操作的算子
Spark的资源参数调优 num-executors --执行器个数 executor-memory --每个Executor的内存大小 一般 所有Executor的总内存占用量不要超过 Yarn 的内存资源的 50% executor-cores --每个Executor的并行执行的task个数 一般情况下总核数不要超过 Yarn 队列中 Cores 总数量的 50。 driver-memory --driver内存大小一般默认1g spark.default.parallelizm: --每个Stage的默认Task数量
Spark数据倾斜 shuffle操作问题解决
原理数据倾斜就是进行shuffle的时候,必须将各个节点上相同的key拉取到某个节点上的一个task来进行处理,此时如果某个key对应的数据量特别大的话,就会发生数据倾斜。
数据倾斜问题发现和定位通过spark web ui 来查看当前运行的stage各个task分配的数据量, 从而进一步确定是不是task分配的数据不均匀导致了数据倾斜,知道数据倾斜发生在哪个stage之后,我们就需要根据stage划分原理,推算出来发生倾斜的那个stage对应代码中的哪一部分,这部分代码中肯定会有一个shuffle类型的算子,通过countByKey查看各个key的分布.
数据倾斜的解决方案
过滤少数导致倾斜的key提高shuffle操作的并行度如果是聚合类算子,使用局部聚合和全聚合的方式。 方案实现思路这个方案的核心实现思路就是进行两阶段聚合。第一次是局部聚合先给每个key都打上一个随机数比如10以内的随机数此时原先一样的key就变成不一样的了比如(hello, 1) (hello, 1) (hello, 1) (hello, 1)就会变成(1_hello, 1) (1_hello, 1) (2_hello, 1) (2_hello, 1)。接着对打上随机数后的数据执行reduceByKey等聚合操作进行局部聚合那么局部聚合结果就会变成了(1_hello, 2) (2_hello, 2)。然后将各个key的前缀给去掉就会变成(hello,2)(hello,2)再次进行全局聚合操作就可以得到最终结果了比如(hello, 4)。
如果是join类型的算子,则使用随机前缀和扩容RDD进行join(因为是由于RDD中有大量的key导致数据倾斜的)
方案实现思路将含有较多倾斜key的RDD扩大多倍与相对分布均匀的RDD配一个随机数。
为什么Spark比Hive(MR)执行快
Spark和MapReduce的计算都发生在内存中区别在于MapReduce通常需要将计算的中间结果写入磁盘然后还要读取磁盘从而导致了频繁的磁盘IO。Spark则不需要将计算的中间结果写入磁盘这得益于Spark的RDD和DAG有向无环图其中DAG记录了job的stage以及在job执行过程中父RDD和子RDD之间的依赖关系。中间结果能够以RDD的形式存放在内存中且能够从DAG中恢复大大减少了磁盘IO。Spark vs MapReduce Shuffle的不同Spark和MapReduce在计算过程中通常都不可避免的会进行Shuffle两者至少有一点不同MapReduce在Shuffle时需要花费大量时间进行排序排序在MapReduce的Shuffle中似乎是不可避免的 Spark在Shuffle时则只有部分场景才需要排序支持基于Hash的分布式聚合更加省时MapReduce采用了多进程模型而Spark采用了多线程模型。多进程模型的好处是便于细粒度控制每个任务占用的资源但每次任务的启动都会消耗一定的启动时间。就是说MapReduce的Map Task和Reduce Task是进程级别的而Spark Task则是基于线程模型的就是说mapreduce 中的 map 和 reduce 都是 jvm 进程每次启动都需要重新申请资源消耗了不必要的时间。Spark则是通过复用线程池中的线程来减少启动、关闭task所需要的开销。
简述Spark的宽窄依赖以及Spark如何划分stage每个stage又根据什么决定task个数?
窄依赖:父RDD的一个分区只会被子RDD的一个分区依赖。
宽依赖:父RDD的一个分区会被子RDD的多个分区依赖(涉及到shuffle)
Stage是如何划分的呢
根据RDD之间的依赖关系的不同将Job划分成不同的Stage遇到一个宽依赖则划分一个Stage。
每个stage又根据什么决定task个数?
Stage是一个TaskSet将Stage根据分区数划分成一个个的Task。
