【面经】阿里数据研发二面面经

最新推荐文章于 2024-05-20 00:10:00 发布

和风与影

最新推荐文章于 2024-05-20 00:10:00 发布

阅读量450

点赞数 2

文章标签：大数据

本文链接：https://blog.csdn.net/weixin_45545090/article/details/126866702

版权

二面没有做题。

简历上没有提到实时，但也考了 Flink。

欢迎点击此处关注公众号。

1.自我介绍

2.Flink 的 watermark

Watermark 是 Flink 为了处理 EventTime 窗口计算提出的一种机制, 本质上是一种时间戳。一般来讲 Watermark 经常和 Window 一起被用来处理乱序事件。

3.Flink 如何保证 Exactly-once

Flink 通过实现两阶段提交和状态保存来实现端到端的一致性语义。分为以下几个步骤：

开始事务（beginTransaction）创建一个临时文件夹，来写把数据写入到这个文件夹里面。
预提交（preCommit）将内存中缓存的数据写入文件并关闭。
正式提交（commit）将之前写完的临时文件放入目标目录下。这代表着最终的数据会有一些延迟。
丢弃（abort）丢弃临时文件。
若失败发生在预提交成功后，正式提交前。可以根据状态来提交预提交的数据，也可删除预提交的数据。

4.什么情况下产生数据倾斜

MapReduce 框架下，数据被分成多个片段发送到不同计算节点上计算。某个计算节点的数据量远超其他节点，其他节点都已经计算完成，该节点还在计算，产生长尾效应，此时就是数据倾斜。

数据发送到不同节点上时，根据 hash 值进行划分。如果有一个 key 的数据量远超其他 key，即 key 分布不均，比如有大量的空值 key，这些 key 全部发送到一个计算节点，就会发生数据倾斜。

5.怎么处理数据倾斜

给不均衡的 key 加随机数打散。
开启自适应执行 adaptive：spark.sql.adaptive，动态 shuffle，检测到倾斜时会自动优化，对倾斜的 partition 进行拆分由多个 task 来进行处理，最后通过 union 进行结果合并。
开启推测执行：推测拖后腿的任务，启动备份任务同时处理。
开启数据倾斜时的负载均衡 set hive.groupby.skewindata=true。
- 思想：就是先随机分发并处理，再按照key group by来分发处理。
- 操作：当选项设定为true，生成的查询计划会有两个MRJob。
- 第一个MRJob 中，Map的输出结果集合会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的GroupBy Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；
- 第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中（这个过程可以保证相同的原始GroupBy Key被分布到同一个Reduce中），最后完成最终的聚合操作。
- 点评：它使计算变成了两个mapreduce，先在第一个中在 shuffle 过程 partition 时随机给 key 打标记，使每个key 随机均匀分布到各个 reduce 上计算，但是这样只能完成部分计算，因为相同key没有分配到相同reduce上。
- 所以需要第二次的mapreduce,这次就回归正常 shuffle,但是数据分布不均匀的问题在第一次mapreduce已经有了很大的改善，因此基本解决数据倾斜。因为大量计算已经在第一次mr中随机分布到各个节点完成。

6.系统设计题一

问题：设计一个完整的系统，能记录一个 web 页面上一个菜单的点击次数，并能做成图表展示。

典型的大数据全链路设计。

在这里插入图片描述

前端埋点产生用户行为日志→日志服务器解析→Flume→Kafka→HDFS→Hive分层建模→MySQL、ES、CH 等→ECharts 等前端可视化。

7.系统设计题二

问题：设计一个外卖系统。站在架构师的角度，包括业务、管理、薪资、调度、用户等各种模块。

8.电脑访问 taobao.com 会发生什么

1.DHCP 配置主机信息

假设主机最开始没有 IP 地址以及其它信息，那么就需要先使用 DHCP 来获取。
主机生成一个 DHCP 请求报文，并将这个报文放入具有目的端口 67 和源端口 68 的 UDP 报文段中。
该报文段则被放入在一个具有广播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 数据报中。
该数据报则被放置在 MAC 帧中，该帧具有目的地址 FF: FF: FF: FF: FF: FF，将广播到与交换机连接的所有设备。
连接在交换机的 DHCP 服务器收到广播帧之后，不断地向上分解得到 IP 数据报、UDP 报文段、DHCP 请求报文，之后生成 DHCP ACK 报文，该报文包含以下信息：IP 地址、DNS 服务器的 IP 地址、默认网关路由器的 IP 地址和子网掩码。该报文被放入 UDP 报文段中，UDP 报文段有被放入 IP 数据报中，最后放入 MAC 帧中。
该帧的目的地址是请求主机的 MAC 地址，因为交换机具有自学习能力，之前主机发送了广播帧之后就记录了 MAC 地址到其转发接口的交换表项，因此现在交换机就可以直接知道应该向哪个接口发送该帧。
主机收到该帧后，不断分解得到 DHCP 报文。之后就配置它的 IP 地址、子网掩码和 DNS 服务器的 IP 地址，并在其 IP 转发表中安装默认网关。

2.ARP 解析 MAC 地址

主机通过浏览器生成一个 TCP 套接字，套接字向 HTTP 服务器发送 HTTP 请求。为了生成该套接字，主机需要知道网站的域名对应的 IP 地址。
主机生成一个 DNS 查询报文，该报文具有 53 号端口，因为 DNS 服务器的端口号是 53。
该 DNS 查询报文被放入目的地址为 DNS 服务器 IP 地址的 IP 数据报中。
该 IP 数据报被放入一个以太网帧中，该帧将发送到网关路由器。
DHCP 过程只知道网关路由器的 IP 地址，为了获取网关路由器的 MAC 地址，需要使用 ARP 协议。
主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文，将该 ARP 查询报文放入一个具有广播目的地址（FF: FF: FF: FF: FF:FF）的以太网帧中，并向交换机发送该以太网帧，交换机将该帧转发给所有的连接设备，包括网关路由器。
网关路由器接收到该帧后，不断向上分解得到 ARP 报文，发现其中的 IP 地址与其接口的 IP 地址匹配，因此就发送一个 ARP 回答报文，包含了它的 MAC 地址，发回给主机。

3.DNS 解析域名

知道了网关路由器的 MAC 地址之后，就可以继续 DNS 的解析过程了。
网关路由器接收到包含 DNS 查询报文的以太网帧后，抽取出 IP 数据报，并根据转发表决定该 IP 数据报应该转发的路由器。
因为路由器具有内部网关协议（RIP、OSPF）和外部网关协议（BGP）这两种路由选择协议，因此路由表中已经配置了网关路由器到达 DNS 服务器的路由表项。
到达 DNS 服务器之后，DNS 服务器抽取出 DNS 查询报文，并在 DNS 数据库中查找待解析的域名。
找到 DNS 记录之后，发送 DNS 回答报文，将该回答报文放入 UDP 报文段中，然后放入 IP 数据报中，通过路由器反向转发回网关路由器，并经过以太网交换机到达主机。

4.HTTP 请求页面

有了 HTTP 服务器的 IP 地址之后，主机就能够生成 TCP 套接字，该套接字将用于向 Web 服务器发送 HTTP GET 报文。
在生成 TCP 套接字之前，必须先与 HTTP 服务器进行三次握手来建立连接。生成一个具有目的端口 80 的 TCP SYN 报文段，并向 HTTP 服务器发送该报文段。
HTTP 服务器收到该报文段之后，生成 TCP SYN ACK 报文段，发回给主机。
连接建立之后，浏览器生成 HTTP GET 报文，并交付给 HTTP 服务器。
HTTP 服务器从 TCP 套接字读取 HTTP GET 报文，生成一个 HTTP 响应报文，将 Web 页面内容放入报文主体中，发回给主机。
浏览器收到 HTTP 响应报文后，抽取出 Web 页面内容，之后进行渲染，显示 Web 页面。