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

二面没有做题。

简历上没有提到实时，但也考了 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 页面。