初级web前端面试题(初级web前端面试题库及答案)
此套面试题来自于各大厂的真实面试题及常问的知识点，如果能理解吃透这些问题，你的大数据能力将会大大提升，进入大厂指日可待！
此套面试题来自于各大厂的真实面试题及常问的知识点，如果能理解吃透这些问题，你的大数据能力将会大大提升，进入大厂指日可待！
本文目录：
一、Hadoop
二、Hive
三、Spark
四、Kafka
五、HBase
六、Flink
七、Clickhouse
八、Doris
九、数据仓库
九、数据湖
九、必备SQL题
八、必备算法
九、大数据算法设计题
Hadoop
Hadoop中常问的就三块，第一：分布式存储(HDFS)；第二：分布式计算框架(MapReduce)；第三：资源调度框架(YARN)。
1. 请说下HDFS读写流程
这个问题虽然见过无数次，面试官问过无数次，还是有不少面试者不能完整的说出来，所以请务必记住。并且很多问题都是从HDFS读写流程中引申出来的。
这个问题虽然见过无数次，面试官问过无数次，还是有不少面试者不能完整的说出来，所以请务必记住。并且很多问题都是从HDFS读写流程中引申出来的。
HDFS写流程：
Client客户端发送上传请求，通过RPC与NameNode建立通信，NameNode检查该用户是否有上传权限，以及上传的文件是否在HDFS对应的目录下重名，如果这两者有任意一个不满足，则直接报错，如果两者都满足，则返回给客户端一个可以上传的信息；
展开全文
Client根据文件的大小进行切分，默认128M一块，切分完成之后给NameNode发送请求第一个block块上传到哪些服务器上；
NameNode收到请求之后，根据网络拓扑和机架感知以及副本机制进行文件分配，返回可用的DataNode的地址；
注：Hadoop在设计时考虑到数据的安全与高效, 数据文件默认在HDFS上存放三份, 存储策略为本地一份，同机架内其它某一节点上一份, 不同机架的某一节点上一份。
注：Hadoop在设计时考虑到数据的安全与高效, 数据文件默认在HDFS上存放三份, 存储策略为本地一份，同机架内其它某一节点上一份, 不同机架的某一节点上一份。
客户端收到地址之后与服务器地址列表中的一个节点如A进行通信，本质上就是RPC调用，建立pipeline，A收到请求后会继续调用B，B在调用C，将整个pipeline建立完成，逐级返回Client；
Client开始向A上发送第一个block（先从磁盘读取数据然后放到本地内存缓存），以packet（数据包，64kb）为单位，A收到一个packet就会发送给B，然后B发送给C，A每传完一个packet就会放入一个应答队列等待应答；
数据被分割成一个个的packet数据包在pipeline上依次传输，在pipeline反向传输中，逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipelineack发送给Client；
当一个block传输完成之后, Client再次请求NameNode上传第二个block，NameNode重新选择三台DataNode给Client。
HDFS读流程：
Client向NameNode发送RPC请求。请求文件block的位置；
NameNode收到请求之后会检查用户权限以及是否有这个文件，如果都符合，则会视情况返回部分或全部的block列表，对于每个block，NameNode都会返回含有该block副本的DataNode地址；这些返回的DataNode地址，会按照集群拓扑结构得出DataNode与客户端的距离，然后进行排序，排序两个规则：网络拓扑结构中距离 Client 近的排靠前；心跳机制中超时汇报的DataNode状态为STALE，这样的排靠后；
Client选取排序靠前的DataNode来读取block，如果客户端本身就是DataNode,那么将从本地直接获取数据(短路读取特性)；
底层上本质是建立Socket Stream（FSDataInputStream），重复的调用父类DataInputStream的read方法，直到这个块上的数据读取完毕；
当读完列表的block后，若文件读取还没有结束，客户端会继续向NameNode 获取下一批的block列表；
读取完一个block都会进行checksum验证，如果读取DataNode时出现错误，客户端会通知NameNode，然后再从下一个拥有该block副本的DataNode 继续读；
read方法是并行的读取block信息，不是一块一块的读取；NameNode只是返回Client请求包含块的DataNode地址，并不是返回请求块的数据；
最终读取来所有的block会合并成一个完整的最终文件；
客户端读取完DataNode上的块之后会进行checksum验证，也就是把客户端读取到本地的块与HDFS上的原始块进行校验，如果发现校验结果不一致，客户端会通知NameNode，然后再从下一个拥有该block副本的DataNode继续读。
3. HDFS在上传文件的时候，如果其中一个DataNode突然挂掉了怎么办
客户端上传文件时与DataNode建立pipeline管道，管道的正方向是客户端向DataNode发送的数据包，管道反向是DataNode向客户端发送ack确认，也就是正确接收到数据包之后发送一个已确认接收到的应答。
当DataNode突然挂掉了，客户端接收不到这个DataNode发送的ack确认，客户端会通知NameNode，NameNode检查该块的副本与规定的不符，NameNode会通知DataNode去复制副本，并将挂掉的DataNode作下线处理，不再让它参与文件上传与下载。
4. NameNode在启动的时候会做哪些操作
NameNode数据存储在内存和本地磁盘，本地磁盘数据存储在fsimage镜像文件和edits编辑日志文件。
首次启动NameNode：
格式化文件系统，为了生成fsimage镜像文件；
启动NameNode：
读取fsimage文件，将文件内容加载进内存
等待DataNade注册与发送block report
读取fsimage文件，将文件内容加载进内存
等待DataNade注册与发送block report
启动DataNode：
向NameNode注册
发送block report
检查fsimage中记录的块的数量和block report中的块的总数是否相同
向NameNode注册
发送block report
检查fsimage中记录的块的数量和block report中的块的总数是否相同
对文件系统进行操作（创建目录，上传文件，删除文件等）：
此时内存中已经有文件系统改变的信息，但是磁盘中没有文件系统改变的信息，此时会将这些改变信息写入edits文件中，edits文件中存储的是文件系统元数据改变的信息。
此时内存中已经有文件系统改变的信息，但是磁盘中没有文件系统改变的信息，此时会将这些改变信息写入edits文件中，edits文件中存储的是文件系统元数据改变的信息。
第二次启动NameNode：
读取fsimage和edits文件；
将fsimage和edits文件合并成新的fsimage文件；
创建新的edits文件，内容开始为空；
启动DataNode。
Secondary NameNode是合并NameNode的edit logs到fsimage文件中；
它的具体工作机制：
Secondary NameNode询问NameNode是否需要checkpoint。直接带回NameNode是否检查结果；
Secondary NameNode请求执行checkpoint；
NameNode滚动正在写的edits日志；
将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode；
Secondary NameNode加载编辑日志和镜像文件到内存，并合并；
生成新的镜像文件fsimage.chkpoint；
拷贝fsimage.chkpoint到NameNode；
NameNode将fsimage.chkpoint重新命名成fsimage；
所以如果NameNode中的元数据丢失，是可以从Secondary NameNode恢复一部分元数据信息的，但不是全部，因为NameNode正在写的edits日志还没有拷贝到Secondary NameNode，这部分恢复不了。
6. Secondary NameNode不能恢复NameNode的全部数据，那如何保证NameNode数据存储安全
这个问题就要说NameNode的高可用了，即 NameNode HA。
一个NameNode有单点故障的问题，那就配置双NameNode，配置有两个关键点，一是必须要保证这两个NameNode的元数据信息必须要同步的，二是一个NameNode挂掉之后另一个要立马补上。
元数据信息同步在 HA 方案中采用的是“共享存储”。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志，以便进行主备切换。
监控NameNode状态采用zookeeper，两个NameNode节点的状态存放在zookeeper中，另外两个NameNode节点分别有一个进程监控程序，实施读取zookeeper中有NameNode的状态，来判断当前的NameNode是不是已经down机。如果Standby的NameNode节点的ZKFC发现主节点已经挂掉，那么就会强制给原本的Active NameNode节点发送强制关闭请求，之后将备用的NameNode设置为Active。
如果面试官再问HA中的 共享存储 是怎么实现的知道吗？
可以进行解释下：NameNode 共享存储方案有很多，比如Linux HA, VMware FT, QJM等，目前社区已经把由Clouderea公司实现的基于QJM（Quorum Journal Manager）的方案合并到HDFS的trunk之中并且作为默认的共享存储实现。
基于QJM的共享存储系统主要用于保存EditLog，并不保存FSImage文件。FSImage文件还是在NameNode的本地磁盘上。
QJM共享存储的基本思想来自于Paxos算法，采用多个称为JournalNode的节点组成的JournalNode集群来存储EditLog。每个JournalNode保存同样的EditLog副本。每次NameNode写EditLog的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向JournalNode集群之中的每一个JournalNode发送写请求，只要大多数的JournalNode节点返回成功就认为向JournalNode集群写入EditLog成功。如果有2N+1台JournalNode，那么根据大多数的原则，最多可以容忍有N台JournalNode节点挂掉。
如果面试官再问HA中的 共享存储 是怎么实现的知道吗？
可以进行解释下：NameNode 共享存储方案有很多，比如Linux HA, VMware FT, QJM等，目前社区已经把由Clouderea公司实现的基于QJM（Quorum Journal Manager）的方案合并到HDFS的trunk之中并且作为默认的共享存储实现。
基于QJM的共享存储系统主要用于保存EditLog，并不保存FSImage文件。FSImage文件还是在NameNode的本地磁盘上。
QJM共享存储的基本思想来自于Paxos算法，采用多个称为JournalNode的节点组成的JournalNode集群来存储EditLog。每个JournalNode保存同样的EditLog副本。每次NameNode写EditLog的时候，除了向本地磁盘写入 EditLog 之外，也会并行地向JournalNode集群之中的每一个JournalNode发送写请求，只要大多数的JournalNode节点返回成功就认为向JournalNode集群写入EditLog成功。如果有2N+1台JournalNode，那么根据大多数的原则，最多可以容忍有N台JournalNode节点挂掉。
假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFailoverController 进程发生了“假死”现象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑，NameNode2 会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active 状态正常运行，这样 NameNode1 和 NameNode2 都处于 Active 状态，都可以对外提供服务。这种情况称为脑裂。
假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFailoverController 进程发生了“假死”现象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑，NameNode2 会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active 状态正常运行，这样 NameNode1 和 NameNode2 都处于 Active 状态，都可以对外提供服务。这种情况称为脑裂。
脑裂对于NameNode这类对数据一致性要求非常高的系统来说是灾难性的，数据会发生错乱且无法恢复。zookeeper社区对这种问题的解决方法叫做 fencing，中文翻译为隔离，也就是想办法把旧的 Active NameNode 隔离起来，使它不能正常对外提供服务。
在进行 fencing 的时候，会执行以下的操作：
首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态。
如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施，Hadoop 目前主要提供两种隔离措施，通常会选择 sshfence：
sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死；
shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离。
sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死；
shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离。
Hadoop上大量HDFS元数据信息存储在NameNode内存中,因此过多的小文件必定会压垮NameNode的内存。
每个元数据对象约占150byte，所以如果有1千万个小文件，每个文件占用一个block，则NameNode大约需要2G空间。如果存储1亿个文件，则NameNode需要20G空间。
显而易见的解决这个问题的方法就是合并小文件,可以选择在客户端上传时执行一定的策略先合并,或者是使用Hadoop的CombineFileInputFormat\<K,V\>实现小文件的合并。
9. 请说下HDFS的组织架构
Client：客户端
切分文件。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行存储
与NameNode交互，获取文件的位置信息
与DataNode交互，读取或者写入数据
Client提供一些命令来管理HDFS，比如启动关闭HDFS、访问HDFS目录及内容等
切分文件。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行存储
与NameNode交互，获取文件的位置信息
与DataNode交互，读取或者写入数据
Client提供一些命令来管理HDFS，比如启动关闭HDFS、访问HDFS目录及内容等
NameNode：名称节点，也称主节点，存储数据的元数据信息，不存储具体的数据
管理HDFS的名称空间
管理数据块（Block）映射信息
配置副本策略
处理客户端读写请求
管理HDFS的名称空间
管理数据块（Block）映射信息
配置副本策略
处理客户端读写请求
DataNode：数据节点，也称从节点。NameNode下达命令，DataNode执行实际的操作
存储实际的数据块
执行数据块的读/写操作
存储实际的数据块
执行数据块的读/写操作
Secondary NameNode：并非NameNode的热备。当NameNode挂掉的时候，它并不能马上替换NameNode并提供服务
辅助NameNode，分担其工作量
定期合并Fsimage和Edits，并推送给NameNode
在紧急情况下，可辅助恢复NameNode
辅助NameNode，分担其工作量
定期合并Fsimage和Edits，并推送给NameNode
在紧急情况下，可辅助恢复NameNode
简单概述：
inputFile通过split被切割为多个split文件，通过Record按行读取内容给map（自己写的处理逻辑的方法） ，数据被map处理完之后交给OutputCollect收集器，对其结果key进行分区（默认使用的hashPartitioner），然后写入buffer，每个map task 都有一个内存缓冲区（环形缓冲区），存放着map的输出结果，当缓冲区快满的时候需要将缓冲区的数据以一个临时文件的方式溢写到磁盘，当整个map task 结束后再对磁盘中这个maptask产生的所有临时文件做合并，生成最终的正式输出文件，然后等待reduce task的拉取。
详细步骤：
读取数据组件 InputFormat (默认 TextInputFormat) 会通过 getSplits 方法对输入目录中的文件进行逻辑切片规划得到 block，有多少个 block就对应启动多少个 MapTask。
将输入文件切分为 block 之后，由 RecordReader 对象 (默认是LineRecordReader) 进行读取，以 \n 作为分隔符, 读取一行数据, 返回 <key，value>， Key 表示每行首字符偏移值，Value 表示这一行文本内容。
读取 block 返回 <key,value>, 进入用户自己继承的 Mapper 类中，执行用户重写的 map 函数，RecordReader 读取一行这里调用一次。
Mapper 逻辑结束之后，将 Mapper 的每条结果通过 context.write 进行collect数据收集。在 collect 中，会先对其进行分区处理，默认使用 HashPartitioner。
接下来，会将数据写入内存，内存中这片区域叫做环形缓冲区(默认100M)，缓冲区的作用是 批量收集 Mapper 结果，减少磁盘 IO 的影响。我们的 Key/Value 对以及 Partition 的结果都会被写入缓冲区。当然，写入之前，Key 与 Value 值都会被序列化成字节数组。
当环形缓冲区的数据达到溢写比列(默认0.8)，也就是80M时，溢写线程启动，**需要对这 80MB 空间内的 Key 做排序 (Sort)**。排序是 MapReduce 模型默认的行为，这里的排序也是对序列化的字节做的排序。
合并溢写文件，每次溢写会在磁盘上生成一个临时文件 (写之前判断是否有 Combiner)，如果 Mapper 的输出结果真的很大，有多次这样的溢写发生，磁盘上相应的就会有多个临时文件存在。当整个数据处理结束之后开始对磁盘中的临时文件进行 Merge 合并，因为最终的文件只有一个写入磁盘，并且为这个文件提供了一个索引文件，以记录每个reduce对应数据的偏移量。
简单描述：
Reduce 大致分为 copy、sort、reduce 三个阶段，重点在前两个阶段。
copy 阶段包含一个 eventFetcher 来获取已完成的 map 列表，由 Fetcher 线程去 copy 数据，在此过程中会启动两个 merge 线程，分别为 inMemoryMerger 和 onDiskMerger，分别将内存中的数据 merge 到磁盘和将磁盘中的数据进行 merge。待数据 copy 完成之后，copy 阶段就完成了。
开始进行 sort 阶段，sort 阶段主要是执行 finalMerge 操作，纯粹的 sort 阶段，完成之后就是 reduce 阶段，调用用户定义的 reduce 函数进行处理。
详细步骤：
Copy阶段：简单地拉取数据。Reduce进程启动一些数据copy线程(Fetcher)，通过HTTP方式请求maptask获取属于自己的文件（map task 的分区会标识每个map task属于哪个reduce task ，默认reduce task的标识从0开始）。
Merge阶段：在远程拷贝数据的同时，ReduceTask启动了两个后台线程对内存和磁盘上的文件进行合并，以防止内存使用过多或磁盘上文件过多。
merge有三种形式：内存到内存；内存到磁盘；磁盘到磁盘。默认情况下第一种形式不启用。当内存中的数据量到达一定阈值，就直接启动内存到磁盘的merge。与map端类似，这也是溢写的过程，这个过程中如果你设置有Combiner，也是会启用的，然后在磁盘中生成了众多的溢写文件。内存到磁盘的merge方式一直在运行，直到没有map端的数据时才结束，然后启动第三种磁盘到磁盘的merge方式生成最终的文件。
合并排序：把分散的数据合并成一个大的数据后，还会再对合并后的数据排序。
对排序后的键值对调用reduce方法：键相等的键值对调用一次reduce方法，每次调用会产生零个或者多个键值对，最后把这些输出的键值对写入到HDFS文件中。
shuffle阶段分为四个步骤：依次为：分区，排序，规约，分组，其中前三个步骤在map阶段完成，最后一个步骤在reduce阶段完成。
shuffle 是 Mapreduce 的核心，它分布在 Mapreduce 的 map 阶段和 reduce 阶段。一般把从 Map 产生输出开始到 Reduce 取得数据作为输入之前的过程称作 shuffle。
Collect阶段：将 MapTask 的结果输出到默认大小为 100M 的环形缓冲区，保存的是 key/value，Partition 分区信息等。
Spill阶段：当内存中的数据量达到一定的阀值的时候，就会将数据写入本地磁盘，在将数据写入磁盘之前需要对数据进行一次排序的操作，如果配置了 combiner，还会将有相同分区号和 key 的数据进行排序。
MapTask阶段的Merge：把所有溢出的临时文件进行一次合并操作，以确保一个 MapTask 最终只产生一个中间数据文件。
Copy阶段：ReduceTask 启动 Fetcher 线程到已经完成 MapTask 的节点上复制一份属于自己的数据，这些数据默认会保存在内存的缓冲区中，当内存的缓冲区达到一定的阀值的时候，就会将数据写到磁盘之上。
ReduceTask阶段的Merge：在 ReduceTask 远程复制数据的同时，会在后台开启两个线程对内存到本地的数据文件进行合并操作。
Sort阶段：在对数据进行合并的同时，会进行排序操作，由于 MapTask 阶段已经对数据进行了局部的排序，ReduceTask 只需保证 Copy 的数据的最终整体有效性即可。
Shuffle 中的缓冲区大小会影响到 mapreduce 程序的执行效率，原则上说，缓冲区越大，磁盘io的次数越少，执行速度就越快。
缓冲区的大小可以通过参数调整, 参数：mapreduce.task.io.sort.mb 默认100M
Shuffle 中的缓冲区大小会影响到 mapreduce 程序的执行效率，原则上说，缓冲区越大，磁盘io的次数越少，执行速度就越快。
缓冲区的大小可以通过参数调整, 参数：mapreduce.task.io.sort.mb 默认100M
在shuffle阶段，可以看到数据通过大量的拷贝，从map阶段输出的数据，都要通过网络拷贝，发送到reduce阶段，这一过程中，涉及到大量的网络IO，如果数据能够进行压缩，那么数据的发送量就会少得多。
hadoop当中支持的压缩算法：
gzip、bzip2、LZO、LZ4、Snappy，这几种压缩算法综合压缩和解压缩的速率，谷歌的Snappy是最优的，一般都选择Snappy压缩。谷歌出品，必属精品。
14. 在写MR时，什么情况下可以使用规约
规约（combiner）是不能够影响任务的运行结果的局部汇总，适用于求和类，不适用于求平均值，如果reduce的输入参数类型和输出参数的类型是一样的，则规约的类可以使用reduce类，只需要在驱动类中指明规约的类即可。
15. YARN集群的架构和工作原理知道多少
YARN的基本设计思想是将MapReduce V1中的JobTracker拆分为两个独立的服务：ResourceManager和ApplicationMaster。
ResourceManager负责整个系统的资源管理和分配，ApplicationMaster负责单个应用程序的的管理。
ResourceManager：RM是一个全局的资源管理器，负责整个系统的资源管理和分配，它主要由两个部分组成：调度器（Scheduler）和应用程序管理器（Application Manager）。
调度器根据容量、队列等限制条件，将系统中的资源分配给正在运行的应用程序，在保证容量、公平性和服务等级的前提下，优化集群资源利用率，让所有的资源都被充分利用应用程序管理器负责管理整个系统中的所有的应用程序，包括应用程序的提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启它。
ApplicationMaster：用户提交的一个应用程序会对应于一个ApplicationMaster，它的主要功能有：
与RM调度器协商以获得资源，资源以Container表示。
将得到的任务进一步分配给内部的任务。
与NM通信以启动/停止任务。
监控所有的内部任务状态，并在任务运行失败的时候重新为任务申请资源以重启任务。
与RM调度器协商以获得资源，资源以Container表示。
将得到的任务进一步分配给内部的任务。
与NM通信以启动/停止任务。
监控所有的内部任务状态，并在任务运行失败的时候重新为任务申请资源以重启任务。
NodeManager：NodeManager是每个节点上的资源和任务管理器，一方面，它会定期地向RM汇报本节点上的资源使用情况和各个Container的运行状态；另一方面，他接收并处理来自AM的Container启动和停止请求。
Container：Container是YARN中的资源抽象，封装了各种资源。一个应用程序会分配一个Container，这个应用程序只能使用这个Container中描述的资源。不同于MapReduceV1中槽位slot的资源封装，Container是一个动态资源的划分单位，更能充分利用资源。
当jobclient向YARN提交一个应用程序后，YARN将分两个阶段运行这个应用程序：一是启动ApplicationMaster;第二个阶段是由ApplicationMaster创建应用程序，为它申请资源，监控运行直到结束。具体步骤如下:
用户向YARN提交一个应用程序，并指定ApplicationMaster程序、启动ApplicationMaster的命令、用户程序。
RM为这个应用程序分配第一个Container，并与之对应的NM通讯，要求它在这个Container中启动应用程序ApplicationMaster。
ApplicationMaster向RM注册，然后拆分为内部各个子任务，为各个内部任务申请资源，并监控这些任务的运行，直到结束。
AM采用轮询的方式向RM申请和领取资源。
RM为AM分配资源，以Container形式返回。
AM申请到资源后，便与之对应的NM通讯，要求NM启动任务。
NodeManager为任务设置好运行环境，将任务启动命令写到一个脚本中，并通过运行这个脚本启动任务。
各个任务向AM汇报自己的状态和进度，以便当任务失败时可以重启任务。
应用程序完成后，ApplicationMaster向ResourceManager注销并关闭自己。
在Yarn中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。
Apache版本的hadoop默认使用的是Capacity Scheduler调度方式。CDH版本的默认使用的是Fair Scheduler调度方式
FIFO Scheduler（先来先服务）：
FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞，比如有个大任务在执行，占用了全部的资源，再提交一个小任务，则此小任务会一直被阻塞。
Capacity Scheduler（能力调度器）：
对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
Fair Scheduler（公平调度器）：
在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。
比如：当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，在Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
Hive1. Hive内部表和外部表的区别
未被external修饰的是内部表，被external修饰的为外部表。
区别：
内部表数据由Hive自身管理，外部表数据由HDFS管理；
内部表数据存储的位置是hive.metastore.warehouse.dir（默认：/user/hive/warehouse），外部表数据的存储位置由自己制定（如果没有LOCATION，Hive将在HDFS上的/user/hive/warehouse文件夹下以外部表的表名创建一个文件夹，并将属于这个表的数据存放在这里）；
删除内部表会直接删除元数据（metadata）及存储数据；删除外部表仅仅会删除元数据，HDFS上的文件并不会被删除。
Hive支持索引（3.0版本之前），但是Hive的索引与关系型数据库中的索引并不相同，比如，Hive不支持主键或者外键。并且Hive索引提供的功能很有限，效率也并不高，因此Hive索引很少使用。
索引适用的场景：
索引适用的场景：
适用于不更新的静态字段。以免总是重建索引数据。每次建立、更新数据后，都要重建索引以构建索引表。
Hive索引的机制如下：
Hive索引的机制如下：
hive在指定列上建立索引，会产生一张索引表（Hive的一张物理表），里面的字段包括：索引列的值、该值对应的HDFS文件路径、该值在文件中的偏移量。
Hive 0.8版本后引入bitmap索引处理器，这个处理器适用于去重后，值较少的列（例如，某字段的取值只可能是几个枚举值） 因为索引是用空间换时间，索引列的取值过多会导致建立bitmap索引表过大。
注意：Hive中每次有数据时需要及时更新索引，相当于重建一个新表，否则会影响数据查询的效率和准确性，Hive官方文档已经明确表示Hive的索引不推荐被使用，在新版本的Hive中已经被废弃了。
扩展：Hive是在0.7版本之后支持索引的，在0.8版本后引入bitmap索引处理器，在3.0版本开始移除索引的功能，取而代之的是2.3版本开始的物化视图，自动重写的物化视图替代了索引的功能。
3. 运维如何对Hive进行调度
将hive的sql定义在脚本当中；
使用azkaban或者oozie进行任务的调度；
监控任务调度页面。
ORC和Parquet都是高性能的存储方式，这两种存储格式总会带来存储和性能上的提升。
Parquet:
Parquet支持嵌套的数据模型，类似于Protocol Buffers，每一个数据模型的schema包含多个字段，每一个字段有三个属性：重复次数、数据类型和字段名。
重复次数可以是以下三种：required(只出现1次)，repeated(出现0次或多次)，optional(出现0次或1次)。每一个字段的数据类型可以分成两种：group(复杂类型)和primitive(基本类型)。
Parquet中没有Map、Array这样的复杂数据结构，但是可以通过repeated和group组合来实现的。
由于Parquet支持的数据模型比较松散，可能一条记录中存在比较深的嵌套关系，如果为每一条记录都维护一个类似的树状结可能会占用较大的存储空间，因此Dremel论文中提出了一种高效的对于嵌套数据格式的压缩算法：Striping/Assembly算法。通过Striping/Assembly算法，parquet可以使用较少的存储空间表示复杂的嵌套格式，并且通常Repetition level和Definition level都是较小的整数值，可以通过RLE算法对其进行压缩，进一步降低存储空间。
Parquet文件是以二进制方式存储的，是不可以直接读取和修改的，Parquet文件是自解析的，文件中包括该文件的数据和元数据。
ORC:
ORC文件是自描述的，它的元数据使用Protocol Buffers序列化，并且文件中的数据尽可能的压缩以降低存储空间的消耗。
和Parquet类似，ORC文件也是以二进制方式存储的，所以是不可以直接读取，ORC文件也是自解析的，它包含许多的元数据，这些元数据都是同构ProtoBuffer进行序列化的。
ORC会尽可能合并多个离散的区间尽可能的减少I/O次数。
ORC中使用了更加精确的索引信息，使得在读取数据时可以指定从任意一行开始读取，更细粒度的统计信息使得读取ORC文件跳过整个row group，ORC默认会对任何一块数据和索引信息使用ZLIB压缩，因此ORC文件占用的存储空间也更小。
在新版本的ORC中也加入了对Bloom Filter的支持，它可以进一 步提升谓词下推的效率，在Hive 1.2.0版本以后也加入了对此的支 持。
星形模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；
c. 以事实表为核心，维表围绕核心呈星形分布。
2. 雪花模型
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能比星型模型要低。
3. 星座模型
星座模型
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
数仓建模详细介绍可查看：通俗易懂数仓建模
6. 为什么要对数据仓库分层？
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据。
如果不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
数据仓库详细介绍可查看：万字详解整个数据仓库建设体系
7. 使用过Hive解析JSON串吗
Hive处理json数据总体来说有两个方向的路走：
将json以字符串的方式整个入Hive表，然后通过使用UDF函数解析已经导入到hive中的数据，比如使用LATERAL VIEW json_tuple的方法，获取所需要的列名。
在导入之前将json拆成各个字段，导入Hive表的数据是已经解析过的。这将需要使用第三方的 SerDe。
详细介绍可查看：Hive解析Json数组超全讲解
8. sort by 和 order by 的区别
order by 会对输入做全局排序，因此只有一个reducer（多个reducer无法保证全局有序）只有一个reducer，会导致当输入规模较大时，需要较长的计算时间。
sort by不是全局排序，其在数据进入reducer前完成排序. 因此，如果用sort by进行排序，并且设置mapred.reduce.tasks>1， 则sort by只保证每个reducer的输出有序，不保证全局有序。
9. 数据倾斜怎么解决
数据倾斜问题主要有以下几种：
空值引发的数据倾斜
不同数据类型引发的数据倾斜
不可拆分大文件引发的数据倾斜
数据膨胀引发的数据倾斜
表连接时引发的数据倾斜
确实无法减少数据量引发的数据倾斜
以上倾斜问题的具体解决方案可查看：Hive千亿级数据倾斜解决方案
注意：对于 left join 或者 right join 来说，不会对关联的字段自动去除null值，对于 inner join 来说，会对关联的字段自动去除null值。
小伙伴们在阅读时注意下，在上面的文章（Hive千亿级数据倾斜解决方案）中，有一处sql出现了上述问题（举例的时候原本是想使用left join的，结果手误写成了join）。此问题由公众号读者发现，感谢这位读者指正。
10. Hive 小文件过多怎么解决1. 使用 hive 自带的 concatenate 命令，自动合并小文件
使用方法：
#对于非分区表
altertableA concatenate;
#对于分区表
altertableB partition(day=20201224) concatenate;
注意：
1、concatenate 命令只支持 RCFILE 和 ORC 文件类型。
2、使用concatenate命令合并小文件时不能指定合并后的文件数量，但可以多次执行该命令。
3、当多次使用concatenate后文件数量不在变化，这个跟参数 mapreduce.input.fileinputformat.split.minsize=256mb 的设置有关，可设定每个文件的最小size。
注意：
1、concatenate 命令只支持 RCFILE 和 ORC 文件类型。
2、使用concatenate命令合并小文件时不能指定合并后的文件数量，但可以多次执行该命令。
3、当多次使用concatenate后文件数量不在变化，这个跟参数 mapreduce.input.fileinputformat.split.minsize=256mb 的设置有关，可设定每个文件的最小size。
设置map输入合并小文件的相关参数（执行Map前进行小文件合并）：
在mapper中将多个文件合成一个split作为输入（CombineHiveInputFormat底层是Hadoop的CombineFileInputFormat方法）：
sethive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 默认
每个Map最大输入大小（这个值决定了合并后文件的数量）：
setmapred.max.split.size=256000000; -- 256M
一个节点上split的至少大小（这个值决定了多个DataNode上的文件是否需要合并）：
setmapred.min.split.size.per.node=100000000; -- 100M
一个交换机下split的至少大小(这个值决定了多个交换机上的文件是否需要合并)：
setmapred.min.split.size.per.rack=100000000; -- 100M
3. 减少Reduce的数量
reduce 的个数决定了输出的文件的个数，所以可以调整reduce的个数控制hive表的文件数量。
hive中的分区函数 distribute by 正好是控制MR中partition分区的，可以通过设置reduce的数量，结合分区函数让数据均衡的进入每个reduce即可：
#设置reduce的数量有两种方式，第一种是直接设置reduce个数
setmapreduce.job.reduces=10;
#第二种是设置每个reduce的大小，Hive会根据数据总大小猜测确定一个reduce个数
sethive.exec.reducers.bytes.per.reducer=5120000000; -- 默认是1G，设置为5G
#执行以下语句，将数据均衡的分配到reduce中
setmapreduce.job.reduces=10;
insertoverwrite tableA partition(dt)
select* fromB
distributebyrand;
对于上述语句解释：如设置reduce数量为10，使用 rand， 随机生成一个数 x % 10 ， 这样数据就会随机进入 reduce 中，防止出现有的文件过大或过小。
4. 使用hadoop的archive将小文件归档
Hadoop Archive简称HAR，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个HAR文件，这样在减少namenode内存使用的同时，仍然允许对文件进行透明的访问。
#用来控制归档是否可用
sethive.archive.enabled=true;
#通知Hive在创建归档时是否可以设置父目录
sethive.archive.har.parentdir.settable=true;
#控制需要归档文件的大小
sethar.partfile.size=1099511627776;
使用以下命令进行归档：
ALTERTABLEA ARCHIVEPARTITION(dt='2021-05-07', hr='12');
对已归档的分区恢复为原文件：
ALTERTABLEA UNARCHIVE PARTITION(dt='2021-05-07', hr='12');
注意:
归档的分区可以查看不能 insert overwrite，必须先 unarchive
注意:
归档的分区可以查看不能 insert overwrite，必须先 unarchive
Hive 小文件问题具体可查看：解决hive小文件过多问题
11. Hive优化有哪些1. 数据存储及压缩：
针对hive中表的存储格式通常有orc和parquet，压缩格式一般使用snappy。相比与textfile格式表，orc占有更少的存储。因为hive底层使用MR计算架构，数据流是hdfs到磁盘再到hdfs，而且会有很多次，所以使用orc数据格式和snappy压缩策略可以降低IO读写，还能降低网络传输量，这样在一定程度上可以节省存储，还能提升hql任务执行效率；
2. 通过调参优化：
并行执行，调节parallel参数；
调节jvm参数，重用jvm；
设置map、reduce的参数；开启strict mode模式；
关闭推测执行设置。
3. 有效地减小数据集将大表拆分成子表；结合使用外部表和分区表。4. SQL优化
大表对大表：尽量减少数据集，可以通过分区表，避免扫描全表或者全字段；
大表对小表：设置自动识别小表，将小表放入内存中去执行。
大表对大表：尽量减少数据集，可以通过分区表，避免扫描全表或者全字段；
大表对小表：设置自动识别小表，将小表放入内存中去执行。
Hive优化详细剖析可查看：Hive企业级性能优化
12. Tez引擎优点？
Tez可以将多个有依赖的作业转换为一个作业，这样只需写一次HDFS，且中间节点较少，从而大大提升作业的计算性能。
Mr/tez/spark区别：
Mr引擎：多job串联，基于磁盘，落盘的地方比较多。虽然慢，但一定能跑出结果。一般处理，周、月、年指标。
Spark引擎：虽然在Shuffle过程中也落盘，但是并不是所有算子都需要Shuffle，尤其是多算子过程，中间过程不落盘 DAG有向无环图。兼顾了可靠性和效率。一般处理天指标。
Tez引擎：完全基于内存。 注意：如果数据量特别大，慎重使用。容易OOM。一般用于快速出结果，数据量比较小的场景。
Doris1. Doris的应用场景有哪些？
首先 Doris 是一个有着MPP架构的分析型数据库产品。对于PB数量级、结构化数据可以做到亚秒级查询响应。使用上兼容MySQL协议，语法是标准的SQL。Doris本身不依赖任何其他系统，相比Hadoop生态产品更易于运维。
应用场景包括：固定历史报表分析、实时数据分析、交互式数据分析等。
一般情况下，用户的原始数据，比如日志或者在事务型数据库中的数据，经过流式系统或离线处理后，导入到Doris中以供上层的报表工具或者数据分析师查询使用。
2. Doris的架构介绍下
Doris 的架构很简洁，只设 FE（Frontend）、BE（Backend）两种角色、两个进程。
以数据存储的角度观看，FE 存储、维护集群元数据；BE 存储物理数据，数据的可靠性由 BE 保证，BE 会对整个数据存储多副本。
以查询处理的角度观看，FE 节点接收、解析查询请求，规划查询计划，调度查询执行，返回查询结果；BE 节点依据 FE 生成的物理计划，分布式地执行查询。
以数据存储的角度观看，FE 存储、维护集群元数据；BE 存储物理数据，数据的可靠性由 BE 保证，BE 会对整个数据存储多副本。
以查询处理的角度观看，FE 节点接收、解析查询请求，规划查询计划，调度查询执行，返回查询结果；BE 节点依据 FE 生成的物理计划，分布式地执行查询。
FE 主要有有三个角色，一个是 Leader，一个是 Follower，还有一个 Observer。Leader 跟 Follower，主要是用来达到元数据的高可用，保证单节点宕机的情况下，元数据能够实时地在线恢复，而不影响整个服务。Observer 只是用来扩展查询节点，就是说如果在发现集群压力非常大的情况下，需要去扩展整个查询的能力，那么可以加 Observer 的节点。Observer 不参与任何的写入，只参与读取。
在使用接口方面，Doris 采用 MySQL 协议，高度兼容 MySQL 语法，支持标准 SQL，用户可以通过各类客户端工具来访问 Doris，并支持与 BI 工具的无缝对接。
3. Doris 的数据模型
Doris 的数据模型主要分为3类:
Aggregate 聚合模型
Uniq 唯一主键模型
Duplicate 模型
Aggregate 聚合模型
Uniq 唯一主键模型
Duplicate 模型
Aggregate 聚合模型：
聚合模型需要用户在建表时显式的将列分为 Key 列和 Value 列。该模型会自动的对 Key 相同的行，在 Value 列上进行聚合操作。
当我们导入数据时，对于 Key 列相同的行会聚合成一行，而 Value 列会按照设置的 AggregationType 进行聚合。AggregationType 目前有以下四种聚合方式：
SUM：求和，多行的 Value 进行累加。
REPLACE：替代，下一批数据中的 Value 会替换之前导入过的行中的 Value。
MAX：保留最大值。
MIN：保留最小值。
SUM：求和，多行的 Value 进行累加。
REPLACE：替代，下一批数据中的 Value 会替换之前导入过的行中的 Value。
MAX：保留最大值。
MIN：保留最小值。
例如：
CREATETABLEIFNOTEXISTSexample_db.expamle_tbl
(
`user_id`LARGEINT NOTNULLCOMMENT"用户id",
`date`DATENOTNULLCOMMENT"数据灌入日期时间",
`city`VARCHAR(20) COMMENT"用户所在城市",
`age`SMALLINTCOMMENT"用户年龄",
`sex`TINYINTCOMMENT"用户性别",
`last_visit_date`DATETIME REPLACEDEFAULT"1970-01-01 00:00:00"COMMENT"用户最后一次访问时间",
`cost`BIGINTSUMDEFAULT"0"COMMENT"用户总消费",
`max_dwell_time`INTMAXDEFAULT"0"COMMENT"用户最大停留时间",
`min_dwell_time`INTMINDEFAULT"99999"COMMENT"用户最小停留时间"
)
AGGREGATEKEY(`user_id`, `date`, `city`, `age`, `sex`)
... /* 省略 Partition 和 Distribution 信息 */
;
Unique 唯一主键模型:
在某些多维分析场景下，用户更关注的是如何保证 Key 的唯一性，即如何获得 Primary Key 唯一性约束。因此，我们引入了 Unique 的数据模型。该模型本质上是聚合模型的一个特例，也是一种简化的表结构表示方式。我们举例说明。
这是一个典型的用户基础信息表。这类数据没有聚合需求，只需保证主键唯一性。（这里的主键为 user_id + username）。那么我们的建表语句如下：
CREATETABLEIFNOTEXISTSexample_db.expamle_tbl
(
`user_id`LARGEINT NOTNULLCOMMENT"用户id",
`username`VARCHAR(50) NOTNULLCOMMENT"用户昵称",
`city`VARCHAR(20) COMMENT"用户所在城市",
`age`SMALLINTCOMMENT"用户年龄",
`sex`TINYINTCOMMENT"用户性别",
`phone`LARGEINT COMMENT"用户电话",
`address`VARCHAR(500) COMMENT"用户地址",
`register_time`DATETIME COMMENT"用户注册时间"
)
UNIQUEKEY(`user_id`, `user_name`)
... /* 省略 Partition 和 Distribution 信息 */
;
而这个表结构，完全同等于以下使用聚合模型描述的表结构：
CREATETABLEIFNOTEXISTSexample_db.expamle_tbl
(
`user_id`LARGEINT NOTNULLCOMMENT"用户id",
`username`VARCHAR(50) NOTNULLCOMMENT"用户昵称",
`city`VARCHAR(20) REPLACECOMMENT"用户所在城市",
`age`SMALLINTREPLACECOMMENT"用户年龄",
`sex`TINYINTREPLACECOMMENT"用户性别",
`phone`LARGEINT REPLACECOMMENT"用户电话",
`address`VARCHAR(500) REPLACECOMMENT"用户地址",
`register_time`DATETIME REPLACECOMMENT"用户注册时间"
)
AGGREGATEKEY(`user_id`, `user_name`)
... /* 省略 Partition 和 Distribution 信息 */
；
即 Unique 模型完全可以用聚合模型中的 REPLACE 方式替代。其内部的实现方式和数据存储方式也完全一样。这里不再继续举例说明。
Duplicate 模型:
在某些多维分析场景下，数据既没有主键，也没有聚合需求。因此，我们引入 Duplicate 数据模型来满足这类需求。
例如：
CREATETABLEIFNOTEXISTSexample_db.expamle_tbl
(
`timestamp`DATETIME NOTNULLCOMMENT"日志时间",
`type`INTNOTNULLCOMMENT"日志类型",
`error_code`INTCOMMENT"错误码",
`error_msg`VARCHAR(1024) COMMENT"错误详细信息",
`op_id`BIGINTCOMMENT"负责人id",
`op_time`DATETIME COMMENT"处理时间"
)
DUPLICATEKEY(`timestamp`, `type`)
... /* 省略 Partition 和 Distribution 信息 */
；
这种数据模型区别于 Aggregate 和 Uniq 模型。数据完全按照导入文件中的数据进行存储，不会有任何聚合。即使两行数据完全相同，也都会保留。而在建表语句中指定的 DUPLICATE KEY，只是用来指明底层数据按照那些列进行排序。
4. 介绍下Doris的ROLLUP
ROLLUP
ROLLUP 在多维分析中是“上卷”的意思，即将数据按某种指定的粒度进行进一步聚合。
在 Doris 中，我们将用户通过建表语句创建出来的表称为 Base 表（Base Table）。在 Base 表之上，我们可以创建任意多个 ROLLUP 表。这些 ROLLUP 的数据是基于 Base 表产生的，并且在物理上是独立存储的。
ROLLUP 表的基本作用，在于在 Base 表的基础上，获得更粗粒度的聚合数据。
Duplicate 模型中的 ROLLUP
因为 Duplicate 模型没有聚合的语意。所以该模型中的 ROLLUP，已经失去了“上卷”这一层含义。而仅仅是作为调整列顺序，以命中前缀索引的作用。
5. Doris的前缀索引了解吗？
不同于传统的数据库设计，Doris 不支持在任意列上创建索引。Doris 这类 MPP 架构的 OLAP 数据库，通常都是通过提高并发，来处理大量数据的。
本质上，Doris 的数据存储在类似 SSTable（Sorted String Table）的数据结构中。该结构是一种有序的数据结构，可以按照指定的列进行排序存储。在这种数据结构上，以排序列作为条件进行查找，会非常的高效。
在 Aggregate、Uniq 和 Duplicate 三种数据模型中。底层的数据存储，是按照各自建表语句中，AGGREGATE KEY、UNIQ KEY 和 DUPLICATE KEY 中指定的列进行排序存储的。
而前缀索引，即在排序的基础上，实现的一种根据给定前缀列，快速查询数据的索引方式。
在建表时，正确的选择列顺序，能够极大地提高查询效率。
ROLLUP 调整前缀索引
因为建表时已经指定了列顺序，所以一个表只有一种前缀索引。这对于使用其他不能命中前缀索引的列作为条件进行的查询来说，效率上可能无法满足需求。因此，我们可以通过创建 ROLLUP 来人为的调整列顺序，以获得更好的查询效率。
6. 讲下Doris的物化视图
物化视图是将预先计算（根据定义好的 SELECT 语句）好的数据集，存储在 Doris 中的一个特殊的表。
物化视图的出现主要是为了满足用户，既能对原始明细数据的任意维度分析，也能快速的对固定维度进行分析查询。
使用场景（物化视图主要针对Duplicate明细模型做聚合操作）
分析需求覆盖明细数据查询以及固定维度查询两方面。
查询仅涉及表中的很小一部分列或行。
查询包含一些耗时处理操作，比如：时间很久的聚合操作等。
查询需要匹配不同前缀索引。
分析需求覆盖明细数据查询以及固定维度查询两方面。
查询仅涉及表中的很小一部分列或行。
查询包含一些耗时处理操作，比如：时间很久的聚合操作等。
查询需要匹配不同前缀索引。
优势
对于那些经常重复的使用相同的子查询结果的查询性能大幅提升。
Doris自动维护物化视图的数据，无论是新的导入，还是删除操作都能保证base 表和物化视图表的数据一致性。无需任何额外的人工维护成本。
查询时，会自动匹配到最优物化视图，并直接从物化视图中读取数据。
对于那些经常重复的使用相同的子查询结果的查询性能大幅提升。
Doris自动维护物化视图的数据，无论是新的导入，还是删除操作都能保证base 表和物化视图表的数据一致性。无需任何额外的人工维护成本。
查询时，会自动匹配到最优物化视图，并直接从物化视图中读取数据。
在没有物化视图功能之前，用户一般都是使用 Rollup 功能通过预聚合方式提升查询效率的。但是 Rollup 具有一定的局限性，他不能基于明细模型做预聚合。
物化视图则在覆盖了 Rollup 的功能的同时，还能支持更丰富的聚合函数。所以物化视图其实是 Rollup 的一个超集。
物化视图的局限性
物化视图的聚合函数的参数不支持表达式仅支持单列，比如：sum(a+b)不支持。
如果删除语句的条件列，在物化视图中不存在，则不能进行删除操作。如果一定要删除数据，则需要先将物化视图删除，然后方可删除数据。
单表上过多的物化视图会影响导入的效率：导入数据时，物化视图和 base 表数据是同步更新的，如果一张表的物化视图表超过10张，则有可能导致导入速度很慢。这就像单次导入需要同时导入10张表数据是一样的。
相同列，不同聚合函数，不能同时出现在一张物化视图中，比如：select sum(a), min(a) from table 不支持。
物化视图针对 Unique Key数据模型，只能改变列顺序，不能起到聚合的作用，所以在Unique Key模型上不能通过创建物化视图的方式对数据进行粗粒度聚合操作
推荐数仓建设好文，建议读一读：万字详解整个数据仓库建设体系
1. ODS层采用什么压缩方式和存储格式？
压缩采用Snappy，存储采用orc，压缩比是100g数据压缩完10g左右。
2. DWD层做了哪些事？
数据清洗
空值去除
过滤核心字段无意义的数据，比如订单表中订单id为null，支付表中支付id为空
对手机号、身份证号等敏感数据脱敏
对业务数据传过来的表进行维度退化和降维。
将用户行为宽表和业务表进行数据一致性处理
空值去除
过滤核心字段无意义的数据，比如订单表中订单id为null，支付表中支付id为空
对手机号、身份证号等敏感数据脱敏
对业务数据传过来的表进行维度退化和降维。
将用户行为宽表和业务表进行数据一致性处理
清洗的手段
Sql、mr、rdd、kettle、Python（项目中采用sql进行清除）
Sql、mr、rdd、kettle、Python（项目中采用sql进行清除）
DWS层有3-5张宽表（处理100-200个指标 70%以上的需求）
具体宽表名称：用户行为宽表，用户购买商品明细行为宽表，商品宽表，购物车宽表，物流宽表、登录注册、售后等。
哪个宽表最宽？大概有多少个字段？最宽的是用户行为宽表。大概有60-100个字段
事实表有：事务事实表、周期快照事实表、累积快照事实表、⾮事实事实表。
1） 事务事实表
事务事实表记录的是事务层⾯的事实，保存的是最原⼦的数据，也称“原⼦事实表”。事务事实表中的数据在事务事件发⽣后产⽣，数据的粒度通常是每个事务记录⼀条记录。
2） 周期快照事实表
以具有规律性的、可预⻅的时间间隔来记录事实。它统计的是间隔周期内的度量统计，每个时间段⼀条记录，是在事务事实表之上建⽴的聚集表。
3）累积快照事实表
累积快照表记录的不确定的周期的数据。代表的是完全覆盖⼀个事务或产品的⽣命周期的时间跨度，通常具有多个⽇期字段，⽤来记录整个⽣命周期中的关键时间点。
4）⾮事实型事实表
这个与上⾯三个有所不同。事实表中通常要保留度量事实和多个维度外键，度量事实是事实表的关键所在。
⾮事实表中没有这些度量事实，只有多个维度外键。⾮事实型事实表通常⽤来跟踪⼀些事件或说明某些活动的范围。
第⼀类⾮事实型事实表是⽤来跟踪事件的事实表。例如：学⽣注册事件
第⼆类⾮事实型事实表是⽤来说明某些活动范围的事实表。例如：促销范围事实表。
5. 星型模型和雪花模型的区别 1) 星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；
星型模式
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用
雪花模式
3．星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
星座模型 6. 数据漂移如何解决? 1) 什么是数据漂移？
通常是指ods表的同⼀个业务⽇期数据中包含了前⼀天或后⼀天凌晨附近的数据或者丢失当天变更的数据，这种现象就叫做漂移，且在⼤部分公司中都会遇到的场景。
2) 如何解决数据漂移问题？
通常有两种解决⽅案：
多获取后⼀天的数据，保障数据只多不少
通过多个时间戳字段来限制时间获取相对准确的数据
第⼀种⽅案⽐较暴⼒，这⾥不做过多解释，主要来讲解⼀下第⼆种解决⽅案。（这种解决⽅案在⼤数据之路这本书有体现）。
第⼀种⽅案⾥，时间戳字段分为四类：
数据库表中⽤来标识数据记录更新时间的时间戳字段（假设这类字段叫 modified time ）。
数据库⽇志中⽤来标识数据记录更新时间的时间戳字段·（假设这类宇段叫 log_time）。
数据库表中⽤来记录具体业务过程发⽣时间的时间戳字段 （假设这类字段叫 proc_time）。
标识数据记录被抽取到时间的时间戳字段（假设这类字段extract time）。
理论上这⼏个时间应该是⼀致的，但往往会出现差异，造成的原因可能为：
数据抽取需要⼀定的时间，extract_time往往晚于前三个时间。
业务系统⼿动改动数据并未更新modfied_time。
⽹络或系统压⼒问题，log_time或modified_time晚于proc_time。
通常都是根据以上的某⼏个字段来切分ODS表，这就产⽣了数据漂移。具体场景如下：
根据extract_time进⾏同步。
根据modified_time进⾏限制同步， 在实际⽣产中这种情况最常⻅，但是往往会发⽣不更新 modified time⽽导致的数据遗漏，或者凌晨时间产⽣的数据记录漂移到后天 。由于⽹络或者系统压⼒问题， log_time 会晚proc_time ，从⽽导致凌晨时间产⽣的数据记录漂移到后⼀天。
根据proc_time来限制，会违背ods和业务库保持⼀致的原则，因为仅仅根据proc_time来限制，会遗漏很多其他过程的变化。
第⼆种解决⽅案：
⾸先通过log_time多同步前⼀天最后15分钟和后⼀天凌晨开始15分钟的数据，然后⽤modified_time过滤⾮当天的数据，这样确保数据不会因为系统问题被遗漏。
然后根据log_time获取后⼀天15分钟的数据，基于这部分数据，按照主键根据log_time做升序排序，那么第⼀条数据也就是最接近当天记录变化的。
最后将前两步的数据做全外连接，通过限制业务时间proc_time来获取想要的数据。
通常数据建模有以下⼏个流程：
概念建模：即通常先将业务划分多个主题。
逻辑建模：即定义各种实体、属性和关系。
物理建模：设计数据对象的物理实现，⽐如表字段类型、命名等。
那么范式建模，即3NF模型具有以下特点：
原⼦性，即数据不可分割。
基于第⼀个条件，实体属性完全依赖于主键，不能存在仅依赖主关键字⼀部分属性。即不能存在部分依赖。
基于第⼆个条件，任何⾮主属性不依赖于其他⾮主属性。即消除传递依赖。
基于以上三个特点，3NF的最终⽬的就是为了降低数据冗余，保障数据⼀致性；同时也有了数据关联逻辑复杂的缺点。
⽽维度建模是⾯向分析场景的，主要关注点在于快速、灵活，能够提供⼤规模的数据响应。
常⽤的维度模型类型主要有：
星型模型：即由⼀个事实表和⼀组维度表组成，每个维表都有⼀个维度作为主键。事实表居中，多个维表呈辐射状分布在四周，并与事实表关联，形成⼀个星型结构。
雪花模型：在星型模型的基础上，基于范式理论进⼀步层次化，将某些维表扩展成事实表，最终形成雪花状结构。
星系模型：基于多个事实表，共享⼀些维度表。
狭义来讲就是⽤来描述数据的数据。
⼴义来看，除了业务逻辑直接读写处理的业务数据，所有其他⽤来维护整个系统运转所需要的数据，都可以较为元数据。
定义：元数据metadata是关于数据的数据。在数仓系统中，元数据可以帮助数据仓库管理员和数据仓库开发⼈员⽅便的找到他们所关⼼的数据；元数据是描述数据仓库内部数据的结构和建⽴⽅法的数据。按照⽤途可分为：技术元数据、业务元数据。
技术元数据
存储关于数据仓库技术细节的数据，⽤于开发和管理数据仓库使⽤的数据。
数据仓库结构的描述，包括数据模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容。
业务系统、数据仓库和数据集市的体系结构和模式。
由操作环境到数据仓库环境的映射，包括元数据和他们的内容、数据提取、转换规则和数据刷新规则、权限等。
业务元数据
从业务⻆度描述了数据仓库中的数据，他提供了介于使⽤者和实际系统之间的语义层，使不懂计算机技术的业务⼈员也能读懂数仓中的数据。
企业概念模型：表示企业数据模型的⾼层信息。整个企业业务概念和相互关系。以这个企业模型为基础，不懂sql的⼈也能做到⼼中有数
多维数据模型。告诉业务分析⼈员在数据集市中有哪些维、维的类别、数据⽴⽅体以及数据集市中的聚合规则。
业务概念模型和物理数据之间的依赖。业务视图和实际数仓的表、字段、维的对应关系也应该在元数据知识库中有所体现。
主题
主题是在较⾼层次上将数据进⾏综合、归类和分析利⽤的⼀个抽象概念，每⼀个主题基本对应⼀个宏观的分析领域。在逻辑意义上，它是对企业中某⼀宏观分析领域所涉及的分析对象。
⾯向主题的数据组织⽅式，就是在较⾼层次上对分析对象数据的⼀个完整并且⼀致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。
主题是根据分析的要求来确定的。
主题域
从数据⻆度看（集合论）
主题语通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定由最终⽤户和数仓设计⼈员共同完成。
从需要建设的数仓主题看（边界论）
主题域是对某个主题进⾏分析后确定的主题的边界。
数仓建设过程中，需要对主题进⾏分析，确定主题所涉及到的表、字段、维度等界限。
确定主题内容
数仓主题定义好以后，数仓中的逻辑模型也就基本成形了，需要在主题的逻辑关系中列出属性和系统相关⾏为。此阶段需要定义好数据仓库的存储结构，向主题模型中添加所需要的信息和能充分代表主题的属性组。
10. 在处理大数据过程中，如何保证得到期望值
保证在数据采集的时候不丢失数据，这个尤为重要，如果在数据采集的时候就已经不准确，后面很难达到期望值
在数据处理的时候不丢失数据，例如sparkstreaming处理kafka数据的时候，要保证数据不丢失，这个尤为重要
前两步中，如果无法保证数据的完整性，那么就要通过离线计算进行数据的校对，这样才能保证我们能够得到期望值
数仓建设中，最重要的是数据准确性，数据的真正价值在于数据驱动决策，通过数据指导运营，在一个不准确的数据驱动下，得到的一定是错误的数据分析，影响的是公司的业务发展决策，最终导致公司的策略调控失败。
12. 数据仓库建模怎么做的
数仓建设中最常用模型--Kimball维度建模详解
13. 数据质量怎么监控
单表数据量监控
一张表的记录数在一个已知的范围内，或者上下浮动不会超过某个阈值
SQL结果：var 数据量 = select count（*）from 表 where 时间等过滤条件
报警触发条件设置：如果数据量不在[数值下限, 数值上限]， 则触发报警
同比增加：如果((本周的数据量 -上周的数据量)/上周的数据量*100)不在 [比例下线，比例上限]，则触发报警
环比增加：如果((今天的数据量 - 昨天的数据量)/昨天的数据量*100)不在 [比例下线，比例上限]，则触发报警
报警触发条件设置一定要有。如果没有配置的阈值，不能做监控 日活、周活、月活、留存（日周月）、转化率（日、周、月）GMV（日、周、月） 复购率（日周月）
单表空值检测
某个字段为空的记录数在一个范围内，或者占总量的百分比在某个阈值范围内
目标字段：选择要监控的字段，不能选“无”
SQL结果：var 异常数据量 = select count(*) from 表 where 目标字段 is null
单次检测：如果(异常数据量)不在[数值下限, 数值上限]，则触发报警
单表重复值检测
一个或多个字段是否满足某些规则
目标字段：第一步先正常统计条数；select count(*) form 表；
第二步，去重统计；select count(*) from 表 group by 某个字段
第一步的值和第二步的值做减法，看是否在上下线阀值之内
单次检测：如果(异常数据量)不在[数值下限, 数值上限]， 则触发报警
跨表数据量对比
主要针对同步流程，监控两张表的数据量是否一致
SQL结果：count(本表) - count(关联表)
阈值配置与“空值检测”相同
数据商业分析的目标是利用大数据为所有职场人员做出迅捷，高质，高效的决策提供可规模化的解决方案。商业分析是创造价值的数据科学。
数据商业分析中会存在很多判断：
观察数据当前发生了什么？
比如想知道线上渠道A、B各自带来了多少流量，新上线的产品有多少用户喜欢，新注册流中注册的人数有多少。这些都需要通过数据来展示结果。
理解为什么发生？
我们需要知道渠道A为什么比渠道B好，这些是要通过数据去发现的。也许某个关键字带来的流量转化率比其他都要低，这时可以通过信息、知识、数据沉淀出发生的原因是什么。
预测未来会发生什么？
在对渠道A、B有了判断之后，根据以往的知识预测未来会发生什么。在投放渠道C、D的时候，猜测渠道C比渠道D好，当上线新的注册流、新的优化，可以知道哪一个节点比较容易出问题，这些都是通过数据进行预测的过程。
商业决策
所有工作中最有意义的还是商业决策，通过数据来判断应该做什么。这是商业分析最终的目的。
大数据算法设计题1. TOP K 算法
有 10 个⽂件，每个⽂件 1G，每个⽂件的每⼀⾏存放的都是⽤户的 query，每个⽂件的query 都可能重复。要求你按照 query 的频度排序。
解答：
1）⽅案 1：
顺序读取 10 个⽂件，按照 hash(query)%10 的结果将 query 写⼊到另外 10 个⽂件（记为）中。这样新⽣成的⽂件每个的⼤⼩⼤约也 1G（假设 hash 函数是随机的）。找⼀台内存在 2G 左右的机器，依次对⽤hash_map(query, query_count)来统计每个query 出现的次数。利⽤快速/堆/归并排序按照出现次数进⾏排序。将排序好的 query 和对应的 query_cout 输出到⽂件中。这样得到了 10 个排好序的⽂件（记为）。对这 10 个⽂件进⾏归并排序（内排序与外排序相结合）。
2）⽅案 2：
⼀般 query 的总量是有限的，只是重复的次数⽐较多⽽已，可能对于所有的 query，⼀次性就可以加⼊到内存了。这样，我们就可以采⽤ trie 树/hash_map等直接来统计每个 query出现的次数，然后按出现次数做快速/堆/归并排序就可以了。
3）⽅案 3：
与⽅案 1 类似，但在做完 hash，分成多个⽂件后，可以交给多个⽂件来处理，采⽤分布式的架构来处理（⽐如MapReduce），最后再进⾏合并。
2. 不重复的数据
在2.5亿个整数中找出不重复的整数，注，内存不⾜以容纳这2.5亿个整 数。
解答：
1）⽅案 1：采⽤ 2-Bitmap（每个数分配 2bit，00 表示不存在，01 表示出现⼀次，10 表示多次，11 ⽆意义）进⾏，共需内存 2^32 * 2 bit=1 GB 内存，还可以接受。然后扫描这 2.5亿个整数，查看 Bitmap 中相对应位，如果是 00 变 01，01 变 10，10 保持不变。所描完事后，查看 bitmap，把对应位是 01 的整数输出即可。
2）⽅案 2：也可采⽤与第 1 题类似的⽅法，进⾏划分⼩⽂件的⽅法。然后在⼩⽂件中找出不重复的整数，并排序。然后再进⾏归并，注意去除重复的元素。
陕ICP备2021009819号