面试官，您好！我叫 xxx , xxxx 年 x 月结业于 xxx 校园，xx 学历，现在上任于 xxx 公司 xxx 部分，职位为：大数据开发工程师，首要从事于 xxx 组件、渠道的开发作业。
作业以来，我先后参加了 xxx 项目、xxx 项目以及 xxx 项目，积累了丰厚的项目经历，一起，这 x 个项目都得到了领导的共同好评。
我对 Flink 组件有着稠密的爱好，作业之余常常研究技能、例如：Flink 四大柱石、Flink 内核运用提交流程、Flink 调度战略等。
好的，那我要点介绍一下 流核算渠道。该渠道对标阿里云的实时核算 Flink，是一个 一站式、高功能的大数据核算、剖析渠道，底层依据Flink完结，渠道供给多种中心功用，支撑多种 source、sink 插件，内置一致的元数据办理，支撑 一键提交、运用办理、断点调试、监控告警、Ranger 鉴权等多个中心模块。
我首要担任对该渠道的Flink版别晋级、从原先的Flink 1.11.0 晋级到 1.14.0,一起对渠道进行架构重构及代码优化，并参加中心模块运用办理、Ranger 鉴权模块的开发作业。
首要处理了多部分提交 Flink 使命需求很多开关装备问题， 版别晋级后的 SQL 语法校验、运用提交报错问题，以及 Ranger 鉴权问题。
首要该流核算渠道底层依据 Flink 完结，在鉴权方面，由于编写的 SQL 在提交过程中需求走 Flink SQL 提交流程，所以在鉴权时直接经过 SQL 解析，校验 拿到 对应的 operation 类型，一起为了和流核算渠道更适配，满意更多事务场景需求，才终究选用 Flink SQL 鉴权，其有用 Hive SQL 也是能够鉴权的。
（1） 调用parse 办法，将 sql 转为 未经校验的 AST 笼统语法树（sqlNode) ，在解析阶段首要用到词法解析和语法解析。
词法解析将 sql 句子转为一组 token，语法解析对 token 进行递归下降语法剖析。
（2）调用validate 办法，将 AST 笼统语法树转为经过校验的笼统语法树（SqlNode）.在校验阶段首要校验 两部分：
（3）调用rel 办法，将 笼统语法树 SqlNode 转为 联系代数树 RelNode(联系表达式) 和 RexNode(行表达式) ，在这个过程中，DDL 不履行 rel 办法，由于 DDL 实践是对元数据的修正，不触及杂乱查询。
分区取舍便是关于分区表或许分区索引来说，优化器能够主动从 from 和 where 中依据分区键直接提取出需求拜访的分区，然后防止扫描一切的分区，下降了 IO 恳求。
分区取舍能够细分为静态分区取舍和动态分区取舍，其间静态分区取舍发生在 sql 句子编译阶段，而动态分区取舍则发生在 sql 句子履行阶段，关于分区键是常量值优化器在会走静态分区取舍的，假如分区键是变量方式优化器只会走动态分区取舍。
在 spark 中，shuffle 前后的分区不同，假如分区数太少，那么每个分区处理的数据巨细或许非常大，导致大分区处理时需求落盘，查询功率太低，假如分区过多，导致每个分区处理数据较少，这也会导致 IO 恳求增多下降查询功率。
动态兼并 shuffle 的意义便是 当 map 端的两个分区 经过 shuffle 操作后，原本发生五个分区的，但由于有两个分区数据过小，所以直接对其进行兼并，终究输出 3 个分区。
所以当 两张表 join 时，假如 A 表的数据量大于 播送巨细的阈值，此刻不能挑选 broadcast hash join ,但刚好能够经过 filter 条件 将 A 表无用数据过滤掉，且 B 表不包括 无用数据，这时候 过滤掉后的 A 表数据量小于 播送巨细的阈值，此刻就能够挑选 broadcast hash join。
有遇到过，checkpoint 失利一般都和反压相结合。导致 checkpoint 失利的原因有两个：
咱们知道， Flink checkpoint 机制是依据 barrier 的, 在数据处理过程中， barrier 也需求像一般数据相同，在 buffer 中排队，等候被处理。当 buffer 较大或许数据处理较慢时，barrier 需求好久才干够抵达算子，触发 checkpoint。尤其是当存在反压时，barrier 需求在 buffer 中活动数个小时，然后导致 checkpoint 履行时刻过长，超过了 timeout 还没有完结，然后导致失利。
当算子需求 barrier 对齐时，假如一个输入的 barrier 现已抵达，那么该输入的 barrier 后边的数据会被阻塞住，不能被处理，需求比及其他输入 barrier 抵达之后，才干持续处理。在 barrier 对齐过程中，其他输入数据处理都要暂停，将严峻导致运用实时性，然后让 checkpoint 履行时刻过长，超过了 timeout 还没有完结， 导致履行失利。
当状况数据过大，会影响每次 checkpoint 的时刻，并且在 chackpoint 时 IO 压力也会很大，履行时刻过长，导致超时还没有履行成功，然后导致履行失利。
关于 barrier 对齐问题。社区提出 FLIP-76 Unaligned Checkpoint。其处理思路是 关于实时性要求很好，但数据重复性要求低的，可采用 barrier 不对齐形式，当还有其他流的 barrier 还没抵达时，为了不影响功能，不必理睬，直接处理 barrier 之后的数据。比及一切流的 barrier 的都抵达后，就能够对该 Operator 做 CheckPoint 了。
FLIP-158 提出通用的增量快照计划，其间心思维是依据 state changelog, changelog 能够细粒度地记载状况数据的改变。详细描绘如下：
独立于 checkpoint 之外，state table 周期性上传，这些上传到耐久存储中的数据被成为物化状况。
Flink 支撑的窗口包括两个重要特点(窗口长度size和滑动距离interval)，经过窗口长度和滑动距离来区别翻滚窗口和滑动窗口。
LRU 被称作最近最少运用算法，是一种页面置换算法。其间心思维是将最近最久未运用的页面予以筛选。便是一种缓存筛选算法。
LRU 缓存机制能够经过哈希表 + 双向链表完结，咱们用一个哈希表和一个双向链表保护一切在缓存中的键值对。
双向链表依照被运用的次序存储了这些键值对，接近头部的键值对是最近运用的，而 接近尾部的键值对是最久未运用的 。
这样以来，咱们首要运用哈希表进行定位，找出缓存项在双向链表中的方位，随后将其移动到双向链表的头部，即可在 O(1) 的时刻内完结 get 或许 put 操作。
