秋招｜快手大数据开发一二面视频面求过

　　mysql的查询如何优化, 我问: 是不是从大方面来讲那, 小姐姐让我尽情发挥

　　先从多表模式来看, 做范式和非范式的权衡，然后的单表的优化, 选择合适的存储引擎, 合适的索引类型, 给合适的列加合适的索引，然后是具体的sql优化, 查询服务器上的具体慢sql 定位性能瓶颈,排查具体的sql性能问题 , 比如索引的利用问题, 子查询和表连接权衡问题, 多表连接顺序问题

　　手写一道题: n个m长的排序数组, 返回一个n*m长的新数组 写完后问复杂度 是说O(n^2) 他说不对是 O(n*n*m) , 我说有道理

　　然后让优化下, 我就给优化了下 加了一个FinishSet 记录下哪个数组已经遍历到头了, 能少几次比较, 但是整体性能还是这样 木有空间了,

　　前面的两部都是类似的, 比如sql语法词法解析 calcite用了javaCC catalyst用了anltr4 ,巴拉巴拉 然后是逻辑计划的生成, 然后是逻辑计划的优化, 属于基于关系型代数来对sql语法进行同义替换的过程, 然后到了具体的物理执行计划的时候 才有各自的区别, 比如hive是把相关的逻辑计划翻译成map reduce等操作, spark sql是把他翻译成rdd直接的操作 其实整体来看 殊途同归

　　功能的原理是一样的, 只是目的不同, 一个是自动的备份, 另一个是手动的保持状态, 用做版本升级/服务重启等

　　理想情况下, checkpoint是最好可以把输入流停掉, 然后保持这一时刻 所有分区的快照

　　但是这样在工程上不合理, 所以用了Chandy-Lamport算法 做一个分布式的快照

　　第二部分是: kafka写入数据时候的可靠性, 通过多个副本来保证数据的有效性

　　使用高级消费者API其实也是可以保证的, 就是使用WAL 额外再管理一次offset相关的信息, 只是这样性能较差

　　使用directAPI更加合适, 这两者主要区别就是offset的管理, 除此之外体现在RDD执行计划的生成上还有一个不同之处,

　　下一步就是通知所有的operator，告诉它们checkpoint已成功完成。这便是两阶段提交协议的第二个阶段：commit阶段。该阶段中JobManager会为应用中每个operator发起checkpoint已完成的回调逻辑。

　　快照发生时，flink会在某些有状态的operator上对data record进行对齐操作（alignment），目的是避免失败恢复时重复消费数据。这个过程也是exactly once的保证。通常对齐操作的时间仅是毫秒级的。但是对于某些极端的应用，在每个operator上产生的毫秒级延迟也不能允许的话，则可以选择降级到at least once，即跳过对齐操作，当失败恢复时可能发生重复消费数据的情况。

作者：admin

抖音快手 站点 QQ交谈