1. hive系列面试分享
1.hive sql连续登录问题：
2.行转列 列转行
3.四种by的区别
4.row_number、 rank 、dense_rank的区别
5. 常用的sql面试题：
6. hivesql转成mapreduce 的过程
1）首先解析器antlr根据定义SQL的语法规则，完成SQL词法，语法解析，将SQL转化为抽象语法树AST Tree
2）遍历AST Tree，抽象出查询的基本组成单元QueryBlock （QueryBlock是一条SQL最基本的组成单元，包括三个部分：输入源，计算过程，输出。简单来讲一个QueryBlock就是一个子查询）
3）遍历QueryBlock，翻译为执行操作树OperatorTree
4）逻辑层优化器进行OperatorTree变换，合并不必要的ReduceSinkOperator，减少shuffle数据量
5）遍历OperatorTree，翻译为MapReduce任务
6）物理层优化器进行MapReduce任务的变换，生成最终的执行计划
2.数仓建模面试分享
1.数仓构建流程
参加上汽的数据分层主要有三层ods层 edw层和app层。 ods是各系统采集的关键的经销商和经销商人员的行为清单，edw主要是明细事实表和维度表等，app主要是一些计算的指标表和宽表。
1.首先 确定业务过程，这个需要和业务部门以及需求方一起一起讨论，要解决这个需求设计到哪些业务线，涉及到哪些业务表，将来也都是要导入数仓ods层，以及从业务数据满足什么样的业务需求。我们之前这些都是需要反复讨论和确定的 。从各系统采集的关键的经销商和经销商人员的行为清单。
2.这些需求以及业务线确定之后也就确定了数据域，然后基于业务进行维度减慢。构建事实表和维度表，
构建事实表首先明确出整个业务的一个流程，确定事实的情况，确定事实的粒度，最好以最细粒度进行划分。比如给上汽做的事实明细表就基于整个卖车从线索到卖车的一整个流程：他们这边事实表也就基于整个营销场景流程，主要是线索的下发、线索的跟进、跟进结果、用户意向、建卡、到店、试驾、成交、战败等等事实明细表，同时对这些实时表进行维度退化，将客户、渠道、经销商、大区、小区等的一些重要维度退化到事实表中。维度主要就是这些维度表的一个信息。
3.进一步就是基于这些事实表和维度表进行构建宽表和指标数据表。比如是包括经销商客户的行为事实进行统计分析
比如用户建卡、交车、试驾、经销商的登录成交情况等的统计以及用户的一个统计和地域分布，其次就是各个渠道的转换率等的指标计算。
不同渠道的线索方面主要有天猫渠道线索、网商渠道线索、展厅自然客流线索、经销商主动开拓线索等；
2.范式建模和维度建模的区别
范式建模主要在于减少数据冗余
维度建模采用事实维度建模 将维度冗余到事实中，可以极大的增加统计分析的效率。
一般ods层从源数据（关系型数据库）同步过来 遵循范式，ods之上都是维度建模了（因为要基于分析）
3.维度建模的具体实现方式：
结合业务场景回答：
选择业务过程-声明粒度-确认维度-确认事实
比如上汽业务过程在于 用户对于车等一系列行为的营销闭环 业务过程
粒度 最细度的行为
维度 用户维度 和导购 社区 等维度
4.维度建模中星型模型和雪花模型的区别
区别在于维度表是否进行了降维，数据冗余的区别。 工作中主要还是星型模型
5.数据库的三范式是什么？
[第一范式（1NF）：原子性（存储的数据应该具有“不可再分性”）
[第二范式（2NF）：唯一性 (消除非主键部分依赖联合主键中的部分字段)（一定要在第一范式已经满足的情况下）]
[第三范式（3NF）：独立性，消除传递依赖(非主键值不依赖于另一个非主键值)]
6.数仓分层方式
3.spark系列面试分享
3.1 mr和spark shuffle 的异同点
这是一道常见的面试题，回答时可以从 IO、shuffle与排序、资源、部署模式、内存管理策略等各个方面来回答。
- MR基于磁盘的分布式计算引擎，频繁的磁盘IO。spark基于内存进行计算，DAG计算模型，大大减少了磁盘IO。
- spark多线程运行，MR多进程运行。
- spark粗粒度资源申请，MR细粒度资源申请。
- spark支持多种部署模式，MR只支持yarn**上部署。
- shuffle与排序；MR有reducer必排序，一般会经过3次排序，Spark Shuffle**数据的排序操作不是必须的。spark有多种shuffle类型,spark不一定会发生shuffle,MR一定会发生shuffle。
- spark具有灵活的内存管理策略。
详细说明：
Spark多任务之间通信是基于内存，而Hadoop是基于磁盘；
消除了冗余的读写：Hadoop每次shuffle操作后，必须要写到磁盘，Spark在shuffle后不一定要落盘，可以cache到内存中；MR基于磁盘的分布式计算引擎，频繁的磁盘IO。spark基于内存进行计算，DAG计算模型，大大减少了磁盘IO。
消除了冗余的MR阶段：Hadoop每次shuffle操作一定连着完整的MR操作，Spark基于RDD提供了丰富的算子，且reduce操作产生的shuffle数据，可以缓存到内存中；Spark 可以将多个任务组合为一个 DAG，在一个计算流程中同时处理多个任务，优化了计算时间。而MapReduce 每次只能执行一个任务。MR有reducer必排序，一般会经过3次排序，Spark Shuffle数据的排序操作不是必须的。Spark有多种 shuffle 类型,Spark不一定会发生shuffle,MR一定会发生shuffle。
JVM的优化：Spark启动采用了 fork 线程的方式，每次的MR操作都是基于线程的；而Hadoop采用的是创建线程的方式，启动Task便会启动一次JVM。
Hadoop 每次 MapReduce 操作，启动一个 Task 便会启动一次 JVM，基于进程的操作。而 Spark 每次MapReduce操作是基于线程的，只在启动 Executor 时启动一次JVM，内存的Task操作是在线程复用的。每次启动JVM的时间可能就需要几秒甚至十几秒，那么当Task多了，这个时间Hadoop不知道比Spark慢了多少。
3.2 spark的几种shuffle
1.spark shuffle是基于 mr shuffle发展而来的，mr shuffle map task写出对数据标记分区写入到缓冲区，达到80% 对数据快排 溢写到磁盘，多个溢出文件会被合并成大的溢出文件(归并排序算法)，在溢出过程中，及合并的过程中，都要调用partitoner进行分组和针对key进行排序；
reducetask根据自己的分区号，去各个maptask机器上取相应的结果分区数据，拉取的数据先存储在内存中，内存不够了，再存储到磁盘。
reducetask会取到同一个分区的来自不同maptask的结果文件，reducetask会将这些文件再进行合并（归并排序）
合并成大文件后，shuffle的过程也就结束了，后面进入reducetask的逻辑运算过程（从文件中取出一个一个的键值对group，调用用户自定义的reduce()方法）
- sparkshuffle 主要分为两种 hash shuffle 和sort shuffle
hash shuffle 又分为普通机制的shuffle 和基于合并的shuffle
1）普通shuffle 有个缺点 下游有多少了shuffle read，每个shuffle write就会产生多少个磁盘文件小文件。而spark中 sparksql 默认并发度200，也就是说每个shuffle write task 之后会产生200个小文件， 生成 w * r 个小文件对文件系统会产生比较大的压力。
2）而合并机制 基于上面做了优化 基于exector构建了shuffle file group; 使在该exector 上的shuffle wrilte 共用r(reducer)个磁盘文件。
在shuffle write过程中，上游stage的task就不是为下游stage的每个task创建一个磁盘文件了。此时会出现shuffleFileGroup的概念，每个shuffleFileGroup会对应一批磁盘文件，磁盘文件的数量与下游stage的task数量是相同的。一个Executor上有多少个CPU core，就可以并行执行多少个task。而第一批并行执行的每个task都会创建一个shuffleFileGroup，并将数据写入对应的磁盘文件内。当Executor的CPU core执行完一批task，接着执行下一批task时，下一批task就会复用之前已有的shuffleFileGroup，包括其中的磁盘文件。也就是说，此时task会将数据写入已有的磁盘文件中，而不会写入新的磁盘文件中。因此，consolidate机制允许不同的task复用同一批磁盘文件，这样就可以有效将多个task的磁盘文件进行一定程度上的合并，从而大幅度减少磁盘文件的数量，进而提升shuffle write的性能。
sort shuffle 分为普通机制的sort shuffle 和by pass shuffle
普通机制shuffle基本和mr的shuffle 过程是一样。spark每个shuffle write task会 写入缓冲区排序然后生成的多个磁盘文件然后进行合并 并生成一个索引文件;shuffle read task 再拉取数据。
bypass 机制 默认当shuffle write 次数小于200开启该机制。优化点在于：减少从缓冲区到磁盘排序和一个过程；每个shuffle write task 只分区不排序。 另外spark shuffle这些task都是基于线程；而mr是基于进程。
3.3 spark 数据倾斜解决方案
3.4 spark的一个执行流程
4.spark 算子
5.spark sql的源码
4.yarn系列面试分享
4.1yarn 有哪些比较重要的进程?
在 YARN（Yet Another Resource Negotiator，又一资源协调器）中，有两个主要的进程扮演关键角色。这些进程负责集群资源的协调、管理和监控。它们分别是 ResourceManager 和 NodeManager。
- ResourceManager (RM)： ResourceManager 是 YARN 集群中的主要进程，负责整个集群资源的管理和调度。ResourceManager 主要完成以下任务：
- 管理集群资源：ResourceManager 根据集群中每个节点的可用资源（如内存、CPU 等），维护整个集群的资源信息。
- 应用程序调度：ResourceManager 负责接收用户提交的应用程序请求，并根据调度策略（如公平调度器、容量调度器等）为应用程序分配资源。
- 监控应用程序生命周期：ResourceManager 跟踪应用程序的状态，例如应用程序的启动、运行和结束等。
- NodeManager (NM)： NodeManager 是 YARN 集群中每个节点上运行的守护进程，负责管理单个节点的资源和任务。NodeManager 主要完成以下任务：
- 管理节点资源：NodeManager 负责监控其所在节点的资源使用情况（如内存、CPU 等），并定期向 ResourceManager 报告节点资源信息。
- 管理容器：NodeManager 根据 ResourceManager 的指示，在本地节点上启动和管理容器。容器是 YARN 中用于封装任务的执行环境，每个容器都拥有一定的资源配额。
- 监控任务执行：NodeManager 负责监控运行在本地节点上的任务，如果任务失败，NodeManager 会向 ResourceManager 报告失败信息。
- ApplicationMaster (AM)： ApplicationMaster 是每个 YARN 应用程序的管理实体，负责协调 ResourceManager 和 NodeManager 以执行应用程序。每个 YARN 应用程序都有一个专门的 ApplicationMaster 实例。它主要负责以下任务：
- 资源协调：ApplicationMaster 根据应用程序的需求向 ResourceManager 申请资源，并将资源分配给应用程序的任务。
- 任务监控：ApplicationMaster 监控应用程序中任务的执行状态，如果任务失败，它将重新调度任务以确保应用程序的正常运行。
- 报告应用程序状态：ApplicationMaster 定期向 ResourceManager 报告应用程序的运行状态。
- Timeline Server（很少见到启用的）： Timeline Server 是 YARN 的一个可选组件，负责收集和存储 YARN 应用程序的历史数据。Timeline Server 可以帮助用户查询和分析应用程序的运行状况和性能。它的主要功能如下：
- 收集应用程序数据：Timeline Server 接收来自 ApplicationMaster 和 NodeManager 的应用程序数据，如任务进度、资源使用情况等。
- 存储历史数据：Timeline Server 将收集到的数据存储在持久化存储中，以便用户在以后可以查询和分析这些数据。
- 提供查询接口：Timeline Server 提供 REST API，允许用户查询和分析应用程序的历史数据。
4.2 appMaster的主要作用
ApplicationMaster（AM）在 YARN 应用程序中扮演了非常关键的角色。它是 YARN 应用程序的主要协调者，负责管理应用程序的资源分配和任务执行。以下是 ApplicationMaster 的主要作用：
- 资源申请：AM 负责向 ResourceManager 申请资源。当应用程序启动时，AM 会向 ResourceManager 请求资源，以便运行任务。AM 需要根据应用程序的需求和可用资源，调整资源申请，以确保高效且公平的资源分配。
- 任务调度：AM 负责将任务调度到集群中的节点上。这意味着它需要根据任务的需求、可用资源和集群拓扑等因素来决定在哪个节点上运行任务。任务调度的目标是最大限度地提高集群资源利用率，同时保持任务性能和可靠性。
- 容器管理：AM 负责管理任务执行的容器。这包括启动、监控和停止容器。在任务执行过程中，AM 需要监控容器的状态，以确保任务正常运行。如果容器失败，AM 需要决定是否重新启动容器，以便完成任务。
- 任务监控和状态报告：AM 负责收集任务的执行状态和进度信息，并将这些信息报告给 ResourceManager。这样，用户可以通过 ResourceManager Web UI 或其他工具实时了解应用程序的运行状况。
- 应用程序完成和清理：当应用程序完成时，AM 负责通知 ResourceManager，以便释放资源。此外，AM 还需要执行清理操作，如删除临时文件和目录等。
总之，ApplicationMaster 是 YARN 应用程序的核心协调者，负责管理应用程序的资源分配、任务调度和执行。它在整个应用程序的生命周期中发挥着关键作用，确保应用程序能够高效且可靠地运行。 任务监控主要由 ApplicationMaster 进程负责，但它依赖于 NodeManager 提供的容器状态信息。这种分布式监控体系确保了 YARN 集群能够高效且可靠地运行各种应用程序。
4.3 yarn三种调度器有何异同
fifo调度器：只支持单队列提交任务 队列只支持fifo调度
capcity调度器支持 1.多队列多用户提交任务，队列支持fifo调度，通过时间和优先级来进行任务调度，每个队列设置资源容量和最大集群资源容量； 2.如果一个队列资源不足，可以之间共享其他有空闲资源的调度队列，等队列执行完任务释放资源再归还給空闲队列（弹性队列）。
fair调度器：1.多队列多租户提交作业，队列支持fifo、fair或者drf调度策略。fair调度主要基于队列的权重和已分配的资源量计算出每个队列应该获得的资源份额；2.支持资源抢占 当空闲队列的资源被共享給其他队列时，当该队列有新的任务提交过来，调度器要为它回收资源，调度器采用先等待再强制回收的策略；等待一段时间资源还没有回收就会杀死超额使用资源队列的任务来回收资源。 3.drf调度策略 进行作业分配不仅考虑内存还考虑cpu
