蚂蚁金服实时数据岗位一面面经

2、sql中实现join 的算法；在mr或者spark中如何实现sort merge join；单partition内如何保证有序？

三种join：outer join／inner join／cross join join算法：sort merge join／hash join／nested loop join

mr join实现： 1）hash join：小表与大表join

经历三步：

确定Build Table以及Probe Table：这个概念比较重要，Build Table使用join key构建Hash Table，而Probe Table使用join key进行探测，探测成功就可以join在一起。通常情况下，小表会作为Build Table，大表作为Probe Table。此事例中item为Build Table，order为Probe Table；

构建Hash Table：依次读取Build Table（item）的数据，对于每一行数据根据join key（item.id）进行hash，hash到对应的Bucket，生成hash table中的一条记录。数据缓存在内存中，如果内存放不下需要dump到外存；

探测：再依次扫描Probe Table（order）的数据，使用相同的hash函数映射Hash Table中的记录，映射成功之后再检查join条件（item.id = order.i_id），如果匹配成功就可以将两者join在一起。

分布式中hash join的两种优化

1.broadcast hash join：适合一张较小的表和一张大表进行join

流程：

a. broadcast阶段：将小表广播分发到大表所在的所有主机。广播算法可以有很多，最简单的是先发给driver，driver再统一分发给所有executor；要不就是基于bittorrete的p2p思路；

b. hash join阶段：在每个executor上执行单机版hash join，小表映射，大表试探；

2.Shuffle Hash Join：左表数据量大于brodcoast的阈值

流程： a.对两张表分别按照join keys进行重分区，即shuffle，目的是为了让有相同join keys值的记录分到对应的分区中

b. 对对应分区中的数据进行join，此处先将小表分区构造为一张hash表，然后根据大表分区中记录的join keys值拿出来进行匹配

sort merge join:两张大表join
shuffle阶段：将两张大表根据join key进行重新分区，两张表数据会分布到整个集群，以便分布式并行处理；

sort阶段：对单个分区节点的两表数据，分别进行排序；

merge阶段：对排好序的两张分区表数据执行join操作。join操作很简单，分别遍历两个有序序列，碰到相同join key就merge输出，否则取更小一边

3、流式数据如何实现join；为什么要进行union操作？union之后的数据存到哪？

1）维度表与流实时join：将数据量较小或者变动小的数据作为维度表，例如用户表

维度表支持两种数据刷新策略：缓存和实时刷新

实时刷新：对于每次的join，都去从维度表中实际查询，保证数据严格的一致性。

缓存：初始启动时一次性载入维度表的所有数据，并按照join条件分配到不同的partition中进行缓存，用户可设置缓存时间。当每次进行join查询时，系统首先从缓存中获取数据，如果获取到数据，并且该数据是有效的（没有超过失效时间），则使用该数据执行join操作；如果缓存中没有获取对应的条件的数据，或者缓存中获得的数据已经失效，则从维度表中查询，并将结果缓存在系统中，同时设置失效时间。

2）双流join：需要数据有时间戳的属性，join之前需将数据进行union操作，根据join 条件创建window窗口，将union之后的数据流经该窗口。之后的数据就会有了边界，可以当作table来处理。 union之后的数据会存到内存中，当超过某个阈值时，则会将数据spill到磁盘中。

4、flink中如何保证exactly once

checkpoint机制。在数据源阶段，jobmanager会为每一条数据加上barrierid属性。当下游算子收到上游input channel中的barrierid时会触发一次snapshaot操作；异步场景下，当下游算子收到某个input channel中的barrierid时会一直等待，等到上游所有input channel的barrierid时才继续往下游算子发送数据；当datasink中收到该barrierid的所有数据时认为此次snapshot完成。

5、flink中watermark和window机制；watermark怎么影响window的；slider window中一条数据如果出现在多个窗口的情况是怎么解决

window：slider／tumble／session

tumble window：滚动窗口分配器将每个元素分配给指定窗口大小的窗口。滚动窗口具有固定的大小并且不重叠。

slider window：滑动窗口分配器将元素分配给固定长度的窗口。类似于滚动窗口分配器，窗口的大小由窗口大小参数配置。另外一个参数控制滑动窗口的启动频率。因此，如果频率小于窗口尺寸，滑动窗可以重叠。 对于同一条数据出现在多个窗口时的场景，

根据不同的时间戳概念：process time／event time／ingestion time

每个partition都会存在水位的概念，将小于该水位的数据丢掉（没有latency的话），大于该水位的数据保留，形成新的水位值；水位的生成有两种方式：a.实时更新 b.设置间隔时间，每200ms触发生成新的水位值

满足水位条件的数据都会流经到满足条件的窗口中，窗口中不存数据具体信息，实际存储在 Key/Value State 中，key为Window，value为元素集合（或聚合值） 窗口常用的组件：

Window Assigner ：决定某个元素被分配到哪个/哪些窗口中去。

Trigger ： 触发器，进行窗口的处理或清除，每个窗口都会拥有一个的Trigger。

Evictor ： “驱逐者”，类似filter作用。在Trigger触发之后，window被处理前，EVictor用来处理窗口中无用的元素。

6、flink生成operatorchain的条件；chain策略

在jobgraph转换为jobgraph时会将满足条件的operator合成operatorchain，从而使得在同一个线程中执行，减少数据传输中的消耗； 1）上下游的并行度一致 2）下游节点的入度为1 （也就是说下游节点没有来自其他节点的输入） 3）上下游节点都在同一个 slot group 中（下面会解释 slot group） 4）下游节点的 chain 策略为 ALWAYS（可以与上下游链接，map、flatmap、filter等默认是ALWAYS） 5）上游节点的 chain 策略为 ALWAYS 或 HEAD（只能与下游链接，不能与上游链接，Source默认是HEAD） 6）两个节点间数据分区方式是 forward（参考理解数据流的分区） 7）用户没有禁用 chain

chain策略：always、head、never

7、flink任务执行机制；彼此的优劣势；和storm的区别；和sparkstreaming的不同；flink是下个算子往上游算子去pull数据的吗？

8、如何找到cpu资源利用率最高的java代码

https://blog.csdn.net/lsziri/article/details/78179716?locationNum=10&fps=1

9、full gc如何定位（产生原因，gc算法及原理，如何排查，参数调优）

10、技术上有什么规划

11、平时在哪接触技术文章、论坛