大数据面试题

1.核心技术

1.1linux

1.相关命令，比如磁盘使用情况？

2.awk,sed,cut,sort？

3.写过那些shell脚本怎么实现的？

4. 公司是物理机还是云主机？

     回答说自己以前的公司是云主机还是物理机的时候，最好说云主机，这样至少在面试甲方的时候比较可信，说物理机可能不好圆。

1.2 Hive

    1）hive中的内部表和外部表的区别, 什么场景用内部表，什么场景用外部表，各有什么优势？

    2）如何把服务器中的数据上传到hive表里面

    3.）hive中的一个表分区的数据怎么导入到另一个表中的分区中。

   4） 如果一个字段 不为空，取空值，如果字段为空，取默认值

   5） udf, udtf使用场景

   6)    hive sql的执行流程

    

         解析器（SQL Parser）：将SQL字符串转换成抽象语法树AST，这一步一般都用第三方工具库完成，比如antlr；对AST进行语法分析，比如表是否存在、字段是否存在、SQL语义是否有误。

（2）编译器（Physical Plan）：将AST编译生成逻辑执行计划。

（3）优化器（Query Optimizer）：对逻辑执行计划进行优化。

（4）执行器（Execution）：把逻辑执行计划转换成可以运行的物理计划。对于Hive来说，就是MR/Spark。

   

     Hive通过给用户提供的一系列交互接口，接收到用户的指令(SQL)，使用自己的Driver，结合元数据(MetaStore)，将这些指令翻译成MapReduce，提交到Hadoop中执行，最后，将执行返回的结果输出到用户交互接口。

   7)分桶表和分区表的区别，分桶表的设计未来解决什么问题

    

         分区提供一个隔离数据和优化查询的便利方式。不过，并非所有的数据集都可形成合理的分区。对于一张表或者分区，Hive 可以进一步组织成桶，也就是更为细粒度的数据范围划分。

分桶是将数据集分解成更容易管理的若干部分的另一个技术。

分区针对的是数据的存储路径；分桶针对的是数据文件。

    

   1) reduce的个数设置为-1,让Job自行决定需要用多少个reduce或者将reduce的个数设置为大于等于分桶表的桶数

（2）从hdfs中load数据到分桶表中，避免本地文件找不到问题

  

  

   

1.3 Flink

1.Flink的三种时间语义？

2.Flink的checkpoint 和Spark的checkpoint的区别？

3.Flink的优化？

4.Flink的运行架构是怎么样的？

5.你们公司的Flink部署模式是啥样的，作业是怎么提交的？

6.在项目中遇到那些问题，发生了什么事情，问题怎么解决的？(高频)

7.Flink的数据一致性？

     关于flink的数据一致性，可以从端到端的一致性，检查点算法，checkpoint机制等介绍。

    

CDC

1.FlinkCDC有了解吗，执行过程？

1.4 Spark

     1) spark的提交参数有那些命令

      2)spark rdd, dataframe, dataSe解释一下

1.5 clickchouse

   1) clickhouse怎么建表的，什么是分表

     

2.数据仓库部分

2.1 数仓做了那些事情

1）如何进行增量同步？

2）ods到dwd层做了那些事情？

3）数仓每一层做了那些事情，为什么这么做？    

2.2 数据量

 1） 公司的数据量有多大？ 服务器的配置，台数。

2.2 业务问题

1）描述一下你遇到一个需求后，如何进行开发的，整个过程？

2）公司的数据量有多大？

3）在大表join小表的时候，发生了数据倾斜类似的问题，导致sql跑不动，你是怎么解决的，又遇到过吗？（超高频）

(进一步提问：对于关联过程中正常的大量异常值，如何解决的)

4）公司用到的监控工具？

5）项目中为什么使用orc和snappy？ 对比其他的存储算法，有什么好处

6）你们是自己做运维的吗，集群中出现一些问题，该如何解决。

7）拉链表的制作场景？

2.3 项目中遇到的问题 ，怎么发现的，如何解决的。   90%概率

1）Flume零点漂移

        描述对应场景，怎么遇到的，怎么解决的，解决之后的现象

2）Flume挂掉及优化

      组件参数优化。

    1.flume监控，挂掉

     采用Ganglia监控器，监控到Flume尝试提交的次数远远大于最终成功的次数，说明Flume运行比较差。主要是内存不够导致的。

    2.flume增加内存

     1）自身：默认内存是20m，考虑增加flume内存，在flume-env.sh配置文件中修改flume内存为 4-6g

（2）找朋友：增加服务器台数

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

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

   3.提高吞吐量

1. 调整taildir source的batchSize大小可以控制吞吐量，默认大小100个Event。
2. 吞吐量的瓶颈一般是网络带宽。

3）Datax空值、调优

    1.空值问题

    

   解决该问题的方案有两个：

（1）修改DataX HDFS Writer的源码，增加自定义null值存储格式的逻辑，可参考记Datax3.0解决MySQL抽数到HDFSNULL变为空字符的问题_datax nullformat-CSDN博客。

（2）在Hive中建表时指定null值存储格式为空字符串（''），例如：

DROP TABLE IF EXISTS base_province;

CREATE EXTERNAL TABLE base_province

(

    `id`         STRING COMMENT '编号',

    `name`       STRING COMMENT '省份名称',

    `region_id`  STRING COMMENT '地区ID',

    `area_code`  STRING COMMENT '地区编码',

    `iso_code`   STRING COMMENT '旧版ISO-3166-2编码，供可视化使用',

    `iso_3166_2` STRING COMMENT '新版IOS-3166-2编码，供可视化使用'

) COMMENT '省份表'

    ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'

    NULL DEFINED AS ''

    LOCATION '/base_province/';

2）Hive（\N） =>  MySQL （null）

"reader": {

       "name": "hdfsreader",

       "parameter": {

              "defaultFS": "hdfs://hadoop102:8020",

              "path": "/base_province",

              "column": [

                     "*"

              ],

              "fileType": "text",

              "compress": "gzip",

              "encoding": "UTF-8",

              "nullFormat": "\\N",

              "fieldDelimiter": "\t",

       }

}

2.参数调优

1）关键优化参数如下：

参数	说明
job.setting.speed.channel	总并发数
job.setting.speed.record	总record限速
job.setting.speed.byte	总byte限速
core.transport.channel.speed.record	单个channel的record限速，默认值为10000（10000条/s）
core.transport.channel.speed.byte	单个channel的byte限速，默认值1024*1024（1M/s）

2）生效优先级：

（1）全局Byte限速 / 单Channel Byte限速

（2）全局Record限速 / 单Channel Record限速

两个都设置，取结果小的

（3）上面都没设置，总Channel数的设置生效

3）项目配置

只设置 总channel数=5，基本可以跑满网卡带宽。

1.7.3 内存调整

建议将内存设置为4G或者8G，这个也可以根据实际情况来调整。

调整JVM xms xmx参数的两种方式：一种是直接更改datax.py脚本；另一种是在启动的时候，加上对应的参数，如下：

python datax/bin/datax.py --jvm="-Xms8G -Xmx8G" /path/to/your/job.json

4）HDFS小文件处理         60%概率

   数仓当中多大的文件定义为小文件：

           小于hdfs设置的块大小就为小文件，比如设置为128m，那么小于这个就是小文件，如果设置的是256m那么小于这个就是小文件。

1.会有什么影响

       （1）存储层面

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

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

       （2）计算层面

              每个小文件都会起到一个MapTask，1个MapTask默认内存1G。浪费资源。

2.怎么解决

 （1）采用har归档方式，将小文件归档

 （2）采用CombineTextInputFormat

 （3）自己写一个MR程序将产生的小文件合并成一个大文件。如果是Hive或者Spark有merge功能自动帮助我们合并。

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

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

5）Kafka挂掉

6）Kafka丢失

7）Kafka数据重复

8）Kafka消息数据积压

9）Kafk乱序

10）Kafka顺序

11）Kafka优化（提高吞吐量）

12）Kafka底层怎么保证高效读写

13）Kafka单条日志传输大小

14）Hive优化（Hive on Spark）   50%概率

     

1.分组聚合

一个分组聚合的查询语句，默认是通过一个MapReduce Job完成的。Map端负责读取数据，并按照分组字段分区，通过Shuffle，将数据发往Reduce端，各组数据在Reduce端完成最终的聚合运算。

分组聚合的优化主要围绕着减少Shuffle数据量进行，具体做法是map-side聚合。所谓map-side聚合，就是在map端维护一个Hash Table，利用其完成部分的聚合，然后将部分聚合的结果，按照分组字段分区，发送至Reduce端，完成最终的聚合。

相关参数如下：

--启用map-side聚合，默认是true

set hive.map.aggr=true;

--用于检测源表数据是否适合进行map-side聚合。检测的方法是：先对若干条数据进行map-side聚合，若聚合后的条数和聚合前的条数比值小于该值，则认为该表适合进行map-side聚合；否则，认为该表数据不适合进行map-side聚合，后续数据便不再进行map-side聚合。

set hive.map.aggr.hash.min.reduction=0.5;

--用于检测源表是否适合map-side聚合的条数。

set hive.groupby.mapaggr.checkinterval=100000;

--map-side聚合所用的hash table，占用map task堆内存的最大比例，若超出该值，则会对hash table进行一次flush。

set hive.map.aggr.hash.force.flush.memory.threshold=0.9;

2. Map Join

Hive中默认最稳定的Join算法是Common Join。其通过一个MapReduce Job完成一个Join操作。Map端负责读取Join操作所需表的数据，并按照关联字段进行分区，通过Shuffle，将其发送到Reduce端，相同key的数据在Reduce端完成最终的Join操作。

优化Join的最为常用的手段就是Map Join，其可通过两个只有Map阶段的Job完成一个join操作。第一个Job会读取小表数据，将其制作为Hash Table，并上传至Hadoop分布式缓存（本质上是上传至HDFS）。第二个Job会先从分布式缓存中读取小表数据，并缓存在Map Task的内存中，然后扫描大表数据，这样在map端即可完成关联操作。

注：由于Map Join需要缓存整个小标的数据，故只适用于大表Join小表的场景。

相关参数如下：

--启动Map Join自动转换

set hive.auto.convert.join=true;

--开启无条件转Map Join

set hive.auto.convert.join.noconditionaltask=true;

--无条件转Map Join小表阈值，默认值10M，推荐设置为Map Task总内存的三分之一到二分之一

set hive.auto.convert.join.noconditionaltask.size=10000000;

3. Reduce并行度

Reduce端的并行度，也就是Reduce个数，可由用户自己指定，也可由Hive自行根据该MR Job输入的文件大小进行估算。

Reduce端的并行度的相关参数如下：

--指定Reduce端并行度，默认值为-1，表示用户未指定

set mapreduce.job.reduces;

--Reduce端并行度最大值

set hive.exec.reducers.max;

--单个Reduce Task计算的数据量，用于估算Reduce并行度

set hive.exec.reducers.bytes.per.reducer;

Reduce端并行度的确定逻辑如下：

若指定参数mapreduce.job.reduces的值为一个非负整数，则Reduce并行度为指定值。否则，Hive自行估算Reduce并行度，估算逻辑如下：

假设Job输入的文件大小为totalInputBytes

参数hive.exec.reducers.bytes.per.reducer的值为bytesPerReducer。

参数hive.exec.reducers.max的值为maxReducers。

    

需要说明的是：若使用Tez或者是Spark引擎，Hive可根据计算统计信息（Statistics）估算Reduce并行度，其估算的结果相对更加准确。

4. 小文件合并

若Hive的Reduce并行度设置不合理，或者估算不合理，就可能导致计算结果出现大量的小文件。该问题可由小文件合并任务解决。其原理是根据计算任务输出文件的平均大小进行判断，若符合条件，则单独启动一个额外的任务进行合并。

相关参数为：

--开启合并map only任务输出的小文件

set hive.merge.mapfiles=true;

--开启合并map reduce任务输出的小文件

set hive.merge.mapredfiles=true;

--合并后的文件大小

set hive.merge.size.per.task=256000000;

--触发小文件合并任务的阈值，若某计算任务输出的文件平均大小低于该值，则触发合并

set hive.merge.smallfiles.avgsize=16000000;

5. 谓词下推

谓词下推（predicate pushdown）是指，尽量将过滤操作前移，以减少后续计算步骤的数据量。开启谓词下推优化后，无需调整SQL语句，Hive就会自动将过滤操作尽可能的前移动。

相关参数为：

--是否启动谓词下推（predicate pushdown）优化

set hive.optimize.ppd = true;

6. 并行执行

Hive会将一个SQL语句转化成一个或者多个Stage，每个Stage对应一个MR Job。默认情况下，Hive同时只会执行一个Stage。但是某SQL语句可能会包含多个Stage，但这多个Stage可能并非完全互相依赖，也就是说有些Stage是可以并行执行的。此处提到的并行执行就是指这些Stage的并行执行。相关参数如下：

--启用并行执行优化，默认是关闭的

set hive.exec.parallel=true;      

   

--同一个sql允许最大并行度，默认为8

set hive.exec.parallel.thread.number=8;

7. CBO优化

CBO是指Cost based Optimizer，即基于计算成本的优化。

在Hive中，计算成本模型考虑到了：数据的行数、CPU、本地IO、HDFS IO、网络IO等方面。Hive会计算同一SQL语句的不同执行计划的计算成本，并选出成本最低的执行计划。目前CBO在Hive的MR引擎下主要用于Join的优化，例如多表Join的Join顺序。

相关参数为：

--是否启用cbo优化

set hive.cbo.enable=true;

8. 列式存储

采用ORC列式存储加快查询速度。

            id   name   age

            1    zs     18

            2    lishi  19

        行：1    zs     18   2    lishi  19

        列：1 2  zs   lishi   18 19

        select name from user

9.压缩

压缩减少磁盘IO：因为Hive底层计算引擎默认是MR，可以在Map输出端采用Snappy压缩。

Map（Snappy ） Reduce

10. 分区和分桶

（1）创建分区表  防止后续全表扫描

（2）创建分桶表  对未知的复杂的数据进行提前采样

11. 更换引擎

     1）MR/Tez/Spark区别：

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

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

15）Hive解决数据倾斜方法     80%概率

     场景：    记一次hive中遇到的坑 - 简书

     

数据倾斜问题，通常是指参与计算的数据分布不均，即某个key或者某些key的数据量远超其他key，导致在shuffle阶段，大量相同key的数据被发往同一个Reduce，进而导致该Reduce所需的时间远超其他Reduce，成为整个任务的瓶颈。以下为生产环境中数据倾斜的现象：

Hive中的数据倾斜常出现在分组聚合和join操作的场景中，下面分别介绍在上述两种场景下的优化思路。

1）分组聚合导致的数据倾斜

前文提到过，Hive中的分组聚合是由一个MapReduce Job完成的。Map端负责读取数据，并按照分组字段分区，通过Shuffle，将数据发往Reduce端，各组数据在Reduce端完成最终的聚合运算。若group by分组字段的值分布不均，就可能导致大量相同的key进入同一Reduce，从而导致数据倾斜。

由分组聚合导致的数据倾斜问题，有如下解决思路：

（1）判断倾斜的值是否为null

若倾斜的值为null，可考虑最终结果是否需要这部分数据，若不需要，只要提前将null过滤掉，就能解决问题。若需要保留这部分数据，考虑以下思路。

（2）Map-Side聚合

开启Map-Side聚合后，数据会现在Map端完成部分聚合工作。这样一来即便原始数据是倾斜的，经过Map端的初步聚合后，发往Reduce的数据也就不再倾斜了。最佳状态下，Map端聚合能完全屏蔽数据倾斜问题。

相关参数如下：

set hive.map.aggr=true;

set hive.map.aggr.hash.min.reduction=0.5;

set hive.groupby.mapaggr.checkinterval=100000;

set hive.map.aggr.hash.force.flush.memory.threshold=0.9;

（3）Skew-GroupBy优化

Skew-GroupBy是Hive提供的一个专门用来解决分组聚合导致的数据倾斜问题的方案。其原理是启动两个MR任务，第一个MR按照随机数分区，将数据分散发送到Reduce，并完成部分聚合，第二个MR按照分组字段分区，完成最终聚合。

相关参数如下：

--启用分组聚合数据倾斜优化

set hive.groupby.skewindata=true;

2）Join导致的数据倾斜

若Join操作使用的是Common Join算法，就会通过一个MapReduce Job完成计算。Map端负责读取Join操作所需表的数据，并按照关联字段进行分区，通过Shuffle，将其发送到Reduce端，相同key的数据在Reduce端完成最终的Join操作。

如果关联字段的值分布不均，就可能导致大量相同的key进入同一Reduce，从而导致数据倾斜问题。

由Join导致的数据倾斜问题，有如下解决思路：

（1）Map Join

使用Map Join算法，Join操作仅在Map端就能完成，没有Shuffle操作，没有Reduce阶段，自然不会产生Reduce端的数据倾斜。该方案适用于大表Join小表时发生数据倾斜的场景。

相关参数如下：

set hive.auto.convert.join=true;

set hive.auto.convert.join.noconditionaltask=true;

set hive.auto.convert.join.noconditionaltask.size=10000000;

（2）Skew Join

若参与Join的两表均为大表，Map Join就难以应对了。此时可考虑Skew Join，其核心原理是Skew Join的原理是，为倾斜的大key单独启动一个Map Join任务进行计算，其余key进行正常的Common Join。原理图如下：

相关参数如下：

--启用skew join优化

set hive.optimize.skewjoin=true;

--触发skew join的阈值，若某个key的行数超过该参数值，则触发

set hive.skewjoin.key=100000;

3）调整SQL语句

若参与Join的两表均为大表，其中一张表的数据是倾斜的，此时也可通过以下方式对SQL语句进行相应的调整。

假设原始SQL语句如下：A，B两表均为大表，且其中一张表的数据是倾斜的。

hive (default)>

select

    *

from A

join B

on A.id=B.id;

其Join过程如下：

 

图中1001为倾斜的大key，可以看到，其被发往了同一个Reduce进行处理。

调整之后的SQL语句执行计划如下图所示：

    

调整SQL语句如下：

hive (default)>

select

    *

from(

    select --打散操作

        concat(id,'_',cast(rand()*2 as int)) id,

        value

    from A

)ta

join(

    select --扩容操作

        concat(id,'_',1) id,

        value

    from B

    union all

    select

        concat(id,'_',2) id,

        value

    from B

)tb

on ta.id=tb.id;

       

19）疑难指标编写（7天内连续3次活跃、1 7 30指标、路径分析 、用户留存率、最近7/30日各品牌复购率、最近30天发布的优惠券的补贴率、 同时在线人数）    90%概率、

   

20）DS任务挂了怎么办？

（1）运行成功或者失败都会发邮件、发钉钉、集成自动打电话。

（2）最主要的解决方案就是，看日志，解决问题。

（3）报警网站睿象云，睿象云-智能运维管理平台-智能运维系统-自动化运维性能监控平台

（4）双11和618活动需要24小时值班

21）DS故障报警

   看日志报错原因：直接重启，资源不够增加资源在重启

       1.我一般回回答数据倾斜，以及零点漂移问题。当然还有更多的问题我没记住。

        参考数据倾斜场景：

        零点漂移问题：kafka到flume数据采集时。

      

3.笔试题部分

3.1 简答题

1. spark和mapreduce的区别是什么，spark计算原理

2.大数据量的计算速度慢，原因以及如何解决

3.hadoop常见的数据存储格式，优点以及缺点

4.hadoop产生小文件原因，以及如何解决

5.hive sql如何优化

6.数据库和数据仓库的区别。

3.2 选择题

1.hdfs,yarn组件的原理问题

4. SQL面试题

4.1.求用户最大连续登录天数 （超高频）

        以下为实例字段

        uid, login_time

        1     2019-08-10

4.2.分组topN

5.算法题

5.1 考察时间复杂度

     1.某数组如[1,1,2,3,3,4,5,5,5] 这种， 求这个数组的出现种出现两次的字符统计，请选择最小的时间复杂度的方法来做？ ——这是一道算法题。

6.场景题

 1. 逻辑题

    1.哥哥周一，二，三说真话， 弟弟四，五，六说真话，哥哥弟弟周日都说真话， 假如哥哥弟弟在某个周几都说：前一天说了假话，请问这个周几是哪天？

  2.情景题

  1.  假如我是刚来的，如果我做的任务不是很好，领导和下级觉得我做的不是很满意，我该怎么办。

   2.工作中遇到过最失败的地方，从中收获了那些内容？（知识，成长，技能）

  3.在工作中，与同事有歧义的地方，发生矛盾，如何在开展工作的时候，与对方沟通，

既能保持工作进展，又能跟对方更好的关系。

4.你与那些人对接工作。 在碰到一些工作上的问题时，你是跟他们怎么进行处理的

5.你一直保持做的一件事情是什么，从中遇到过那些问题，怎么解决的，收获了什么。

面试常见客套话

1.常见问题：

1.1 在面试官的职业范围内，问应聘者有什么想问的？   99%概率

答：

1.以您对我的了解来看，我多久能够适应公司的工作？（这个问题可以不用问，虽然是要评价，）

      另一种问法：入职3-6个月之后，给公司解决什么问题？另一种方式要评价。

2.问公司用到的技术栈，工作流程是怎样的？

3.问技术栈，一些问题他们怎么处理的？

4.贵公司的技术栈和我所掌握的技术栈相符么有什么区别么？

5. 再一个比如公司的业务是什么样的，了解业务的话大概需要多久？

6.如果面试成功，那么我这个岗位在公司中当前的项目做哪部分工作呢？

7）、公司的数据团队的大概规模是多少，是怎么划分的，是按业务线划分还是按实时、离线分组划分的？
8）、公司招的这个岗位的主要工作内容？
9）、如果说是做离线，可以问下主要用哪些技术组件？
10）、可以简单了解一下公司的成长晋升渠道？

1.2 离职原因是什么？ 100%概率

  答：因为在上一家工作3年多了，待的太久了，工作上也没有太大的进步，就准备换个工作机会提升自己。

1.3 对未来的职业规划？

 答：1）希望自己在技术这条路上有所积累，成为某一领域的专家。

        2）对业务更加理解，早点转型成为管理型人材。

2.面试官给的建议：

1.java 和sql都很重要，需要更加的进一步学习

2.flink这种东西，还需要再继续学习学习，一个写着工作几年的人，对于flink的部署模式，提交流程，flink的api都不清楚。