大数据面试题汇总（含数仓）

最新推荐文章于 2024-07-21 13:36:52 发布

x我有辣条跟我走。

最新推荐文章于 2024-07-21 13:36:52 发布

阅读量942

点赞数

分类专栏：大数据阶段-知识点总结文章标签： 1024程序员节

本文链接：https://blog.csdn.net/XIAOMO__/article/details/109244540

版权

本文主要汇总了大数据面试中的关键知识点，包括HDFS小文件处理、Hadoop的MapReduce操作（Map端与Reduce端的Join）、LZO压缩、Zookeeper的节点管理、选举机制、负载均衡以及数据仓库的分层与设计。此外，还涉及了Flume拦截器、Kafka的分区策略、数据可靠性与幂等性、Hive的函数应用以及数据可视化工具Superset的安装配置等。内容覆盖了大数据处理的多个重要方面。

摘要由CSDN通过智能技术生成

10月16-17日

日志数据：通过sdk做数据采集（js采集,java代码），所谓的sdk就是开发的一些工具，采集用户与前端交互数据（点击，浏览，点赞，广告。错误日志），采集方式是通过监控事件的方式，采集对数据进行加密，压缩，转码，采用实时发送，定时发送，还可能根据网络情况发送，发给后端日志服务器

报表系统：把指标给决策层的人看;

业务数据：记录在数据库中的数据，这些数据基于事务机制记录每个业务过程的数据。

风险控制：支付宝的花呗

kylin预计算 kylin和presto差不多

数据量大的话容易崩溃

正向代理：指定具体执行人；反向代理：不指定具体执行人

业务数据占日志2%-10%，业务数据通常40g50g数据。

10月19日

你们选的服务器是什么，用的什么版本

服务器的价格多少钱一台，后面的配置怎么配的

人员配置怎么配置的，你公司有多少人，分别负责什么岗位，例如ofo,快手一类的组长什么有多少人，及其分配

10月20日（HDFS）

1.HDFS的小文件处理

https://blog.csdn.net/XIAOMO__/article/details/109185479

2.全埋点镜像埋点

3.sdk

4.json必须会:要求会写数据和读数据

5.日志级别：fatal,error,warn,info,debug,trace,all

6.lockbasck的使用：

https://blog.csdn.net/XIAOMO__/article/details/109184126

10月21日（hadoop）

1.map端的join和reduce端的join有什么不同？

map端的join原理

MapReduce提供了表连接操作其中包括Map端join、Reduce端join还有单表连接，现在我们要讨论的是Map端join，Map端join是指数据到达map处理函数之前进行合并的，效率要远远高于Reduce端join，因为Reduce端join是把所有的数据都经过Shuffle，非常消耗资源。

1.Map端join的使用场景：一张表数据十分小、一张表数据很大。

Map端join是针对以上场景进行的优化：将小表中的数据全部加载到内存，按关键字建立索引。大表中的数据作为map的输入，对map()函数每一对<key,value>输入，都能够方便地和已加载到内存的小数据进行连接。把连接结果按key输出，经过shuffle阶段，reduce端得到的就是已经按key分组并且连接好了的数据。

为了支持文件的复制，Hadoop提供了一个类DistributedCache，使用该类的方法如下：

（1）用户使用静态方法DistributedCache.addCacheFile()指定要复制的文件，它的参数是文件的URI（如果是HDFS上的文件，可以这样：hdfs://namenode:9000/home/XXX/file，其中9000是自己配置的NameNode端口号）。JobTracker在作业启动之前会获取这个URI列表，并将相应的文件拷贝到各个TaskTracker的本地磁盘上。

（2）用户使用DistributedCache.getLocalCacheFiles()方法获取文件目录，并使用标准的文件读写API读取相应的文件。

2.本实验Map端Join的执行流程

（1）首先在提交作业的时候先将小表文件放到该作业的DistributedCache中，然后从DistributeCache中取出该小表进行join连接的 <key ,value>键值对，将其解释分割放到内存中（可以放大Hash Map等等容器中）。

（2）要重写MyMapper类下面的setup()方法，因为这个方法是先于map方法执行的，将较小表先读入到一个HashMap中。

（3）重写map函数，一行行读入大表的内容，逐一的与HashMap中的内容进行比较，若Key相同，则对数据进行格式化处理，然后直接输出。

（4）map函数输出的<key,value >键值对首先经过一个suffle把key值相同的所有value放到一个迭代器中形成values，然后将<key,values>键值对传递给reduce函数，reduce函数输入的key直接复制给输出的key，输入的values通过增强版for循环遍历逐一输出，循环的次数决定了<key,value>输出的次数。

reduce端的join原理

原理

在Reudce端进行Join连接是MapReduce框架进行表之间Join操作最为常见的模式。

1.Reduce端Join实现原理

（1）Map端的主要工作，为来自不同表（文件）的key/value对打标签以区别不同来源的记录。然后用连接字段作为key，其余部分和新加的标志作为value，最后进行输出。

（2）Reduce端的主要工作，在Reduce端以连接字段作为key的分组已经完成，我们只需要在每一个分组当中将那些来源于不同文件的记录（在map阶段已经打标志）分开，最后进行笛卡尔只就ok了。

2.Reduce端Join的使用场景

Reduce端连接比Map端连接更为普遍，因为在map阶段不能获取所有需要的join字段，即：同一个key对应的字段可能位于不同map中，但是Reduce端连接效率比较低，因为所有数据都必须经过Shuffle过程。

3.本实验的Reduce端Join代码执行流程：

（1）Map端读取所有的文件，并在输出的内容里加上标识，代表数据是从哪个文件里来的。

（2）在Reduce处理函数中，按照标识对数据进行处理。

（3）然后将相同的key值进行Join连接操作，求出结果并直接输出。

2.LZO介绍

LZO 是一个用 ANSI C 语言编写的无损压缩库。他能够提供非常快速的压缩和解压功能。解压并不需要内存的支持。即使使用非常大的压缩比例进行缓慢压缩出的数据，依然能够非常快速的解压。LZO遵循GNU 的GPL 使用许可。

LZO 非常适合进行数据的实时压缩解压处理，这就是说他更关心操作速度，而不是压缩比例。

LZO 使用 ANSI C 语言编写，并且压缩后的数据也被设计为可以跨平台使用的格式。

LZO 拥有如下的特点：

解压速度很快，并且很简单；

解压时不需要内存支持；

压缩的速度还不错；

压缩时只需要 64 KiB 的内存支持；

压缩比例可以根据需要调节，而这并不影响解压的效率，提高压缩比例自然会降低压缩速度；

压缩包含了很多的压缩级别，提供很多选择；

提供只需要 8 KiB 内存支持的压缩级别；

提供线程安全；

提供无损压缩

3.你知道哪些压缩格式？那个最好，为什么？

hadoop本身并不支持lzo压缩，故需要使用twitter提供的hadoop-lzo开源组件。常用的压缩方式有两种:一种就是lzo，snappy；lzo好处是支持切片，先创建索引，否则就不支持切片

10月22日

1.zookeeper中尽可能多的创建节点好吗？

每个节点都会存储东西，如果太多节点就会使它的它的性能不好。

2.zookeeper的一个节点上默认存储多少的数据？

3.在你接触的项目里面，你的zookeeper在哪些地方使用了？

hadoop 的HA，其他的一些HA场景

Kafka ，hbase，spark streaming与kafka整合

还有一些场景：配置文件管理（例），负载均衡，动态上下线...

4.zookeeper是怎样进行监听的？

某分布式系统中，主节点可以有多台，可以动态上下线，任意一台客户端都能实时感知到主节点服务器的上下线。

（有人一改数据zookeeper就会通知：这个就是监听）

5.zookeeper的负载均衡指的什么？

负载均衡就是：把数据分配平均，访问节点上的数据，将访问的ip，访问的页面按顺序累加排序，找出排名最低的和排名最高的，将最多的放些到最少的累加排序，可以保证每台服务器都一样，不过也会损耗性能；也可以随机调用。

6.zookeeper的节点类型有哪些？

7.zookeeper的选举机制（面试重点）

（1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。

（2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

（3）以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。

（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；

（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING

（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

（5）服务器5启动，同4一样当小弟。

8.zookeeper中的 Paxos算法用过吗？是什么？

Paxos算法一种基于消息传递且具有高度容错特性的一致性算法。

分布式系统中的节点通信存在两种模型：共享内存（Shared memory）和消息传递（Messages passing）。基于消息传递通信模型的分布式系统，不可避免的会发生以下错误：进程可能会慢、被杀死或者重启，消息可能会延迟、丢失、重复，在基础 Paxos 场景中，先不考虑可能出现消息篡改即拜占庭错误的情况。Paxos 算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性。