字节大数据一二三面面经（已意向书）

    作者：顺顺利利毕业
    链接：https://www.nowcoder.com/discuss/702730?source_id=discuss_experience_nctrack&channel=-1
    来源：牛客网

    发面经，求offer （一面到offer就整整一星期，字节效率真滴恐怖！！！）
    增加各个问题答案以及大数据规划（ing）

    ————————一面——————————- 8.10 45min（小姐姐）
    1. Flink Checkpoint
    面试官是说到checkpoint作用，然后我就开始拓展
    项目中开启了checkpoint相关配置给用户使用，说到一些配置信息
    之后我自己对ck还挺了解的，所以引申到Chandy-Lamport论文，这篇论文基本思想就是marker n一到进程就保存进程状态，但是进程状态到最终快照状态n的差距还需要链路状态来弥补
    而flink的ABS其实简化了里面思想，但是这种简化思想导致的就是barrier需要对齐，而barrier对齐那么导致ck时效性受到影响，反压更加加剧这种情况。所以flink 1.11阿里提出了unalignCheckpoint机制 ，这个机制具体怎么做看直接flink文档吧

    说到配置，C-L论文，ABS，barrier对齐，对齐缺点，阿里的不对齐
    2. 端到端的exactly-once：
    端到端要说三部分，源+数据处理+sink
    比如kafka，源主要是offset由ck保存到快照里了，所以offset交给自己去管控（assign/seek）而非kafka
    数据处理自然就是ck
    sink：要么外部支持幂等性，要么外部支持事务，kafka这种就是事务了，大概原理就是在barrier n来时preCommit事务n-1，开启事务n，在notifyCheckpointComplete时commit 事务n-1 （后续传个图上来）

    3.Ck恢复，拓扑图修改后如何恢复？
    这个其实只要理解快照中各个算子对应的state（keyedState+OperatorState）都是算子id—->State形式，而如果不指定算子id，那么算子默认id和其前后算子有关，所以一旦拓扑图改变，那么必然算子id改变，状态对不上，从ck或者savepoint中恢复失败
    不太会，我说指定算子id

    1. stateBackend用过哪些
      直接说RocksDB不太会 😂 这里感觉如果知道hbase，可以说一说

    2. Spark stage、task划分
      这个典中典了，反向创建，反向submitMissingTask(先父stage再子stage)

    3. Spark提交流程
      典中典了
      算法：
      礼物的最大价值（dp）
      栈序列是否合法（stack模拟即可）

    ————————-二 面————————- 8.12 1h
    1. 进程线程区别
    3部分吧
    资源、调度单元
    通信方式
    切换代价

    1. 进程通信方式、最常用是哪种
      管道、消息队列、共享变量、socket、信号量、信号 socket

    2. socket通信涉及哪些方面（很发散感觉答的不好）
      3个部分吧
      scoket使用和TCP各个阶段对应
      最后可以说到I/O多路复用，然后举Kafka网络模型的例子，岂不美哉？？？

    3. Java HashMap和ConcurrentHashMap 说了很久很久
      典中典了
      HashMap：桶集合+链表/红黑树
      为什么桶集合选择数组啊？
      为什么使用拉链法解决冲突啊？
      什么时候resize() 啊？
      什么时候树化？恢复？
      ConcurrentHashMap ：1.7/1.8区别，然后size和get无法强一致性之类的

    4. Kafka理解 说了很久很久
      kafka这个可以先说为什么使用kafka：回溯消费啦、上下游解耦啦… 全部怼上去
      然后kafka总结下来真的就高吞吐、高可靠、高可用三点
      高吞吐：生产者异步、压缩、批量发送啦、网络模型I/O多路复用高效啦、写入pageCache啦、顺序I/O啦、baseOffset形成跳表啦、零拷贝啦、批量拉取啦，一条龙整上，爽歪歪
      高可靠：如何做到不重不漏不乱序？典中典了
      高可用：Controller HA、PartitionHA（可以说到ISR、ISR概念，为什么设定ISR、如何保证消费一致性啦………….）

    我从高吞吐、高可靠、高可用三点回答的，但是说的太多了，面试官到最后要求用三句话说明高可靠

    1. 两数之和

    2. 10TB 日志数据类似统计谁访问了哪些域名，访问了多少次，给出解决方案
      我只会用mapreduce思想，想请教大佬解答下

    算法
    最大连续子数组之和（具体数组）
    设定start，end
    大于max时不断更新end，nums[i]+dp[i-1] < nums[i] 更新start

    ————————三面————————- 8.16 40min
    1. 说说MR（介绍的很不好）
    告辞！

    1. 主动说Spark的shuffle 过程
      三种shuffleWrite（名字可能有错，源码好久没看了）
      BypassMergeSortedShuffleWriter
      SortedBaseShuffleWriter
      UnsafeShuffleWriter
      每一种都有自己使用范围，第一种就是分区数<200(可配置)，不排序，不聚合 最后生成两个文件blockFile+index ，sortedBaseShuffleWriter解决了第一种过渡消耗内核缓存区缺点，那么最终要按pid分组，那只能对pid进行排序了，额外的可以选择对key进行排序与聚合（如果可以，说说里面的sizeTrackingAppendOnlyMap，Array[2*cap] 存放了 ，使用线性探测解决冲突之类的）；unsafeshufflewriter主要涉及到较新的spark内存管理有关了，申请memoryBlock为page，然后数据序列化到page中，设立一个类似索引的page，最后溢写磁盘对索引的page进行 排序之类的，可以看看网上博文

    reduce只有BlockStoreShuffleReader
    基本流程就是获取mapStatus，解析获取blockManagerId，然后从对应BlockManager拉取map输出的blockFile对应pid数据，然后边拉取可以边聚合之类的

    1. flink中ck超时原因（这checkpoint功能似乎字节面试官很看重，感觉得好好准备）
      1. 反压 毕竟包含barrier的event buffer一直不到 ，subtaskCheckpointCoordinator做不了ck，当然超时
      2. 面试官说： 算子执行外部请求能否导致超时？当时没想出来，太紧张了【裂开】
      后面三面过了后，通过hr给面试官转发了消息：
      MailBoxProcessor中的线程也就是数据处理(subtask)线程，该线程每次会pollNext从InputChannel中拿取buffer，如果是event buffer(barrier)并且barrier对齐了，那么此时执行performCheckpoint方法(之后就是保存快照逻辑)

    如果直接在某个userFunction去请求数据，那么使用的是就是当前数据处理线程（比如请求MySQL数据，耗费大量时间），必然影响当前线程处理barrier，导致checkpoint超时
    而比如在open方法中去初始个线程池比如RichAsyncFunction#open方法中初始化线程池然后去查询，便不会影响正常数据处理线程

    必然超时呀！！！

    当时脑瓜子嗡嗡的，只说了反压，面试官叫我回去试试算子执行外部请求能否导致超时（东扯西扯，扯到同步快照保存，异步快照保存，都没啥用，最后尬住了。。。）

    1. flink和spark区别（spark streaming不太会）
      说了flink中subtask和spark中task数据处理区别
      这个其实就是数据如何流通还有上游主动推到下游还是下游拉取上游之类的？

    2. spark 3.0特性 gg
      真不会xdm

    3. 反问
      问着问着就又变成面试官问我了【裂开】，数据倾斜怎么处理
      1. 暴力加并行度
      2. 两阶段聚合
      3. join里面广播变量 + 采样复制（和面试官争论了一波）
      可以看一波美团技术， https://tech.meituan.com/2016/05/12/spark-tuning-pro.html
      平时怎么看源码的

    感谢各位观看，如果有需要讨论的可以在帖子下面回复，能不能厚个脸皮求个关注、求个赞😂感谢感谢！