大家好，今天我们分享的内容是关于一个面试的部分内容复盘(部分个人信息脱敏)。
本文的内容是关于我们之前辅导的一个同学在面试过程中遇到的几个问题，整个面试过程比较顺利。
当前阶段的面试，部分公司的部分岗位对数据湖相关的技能是有要求的。
当然客观的说，也不是所有公司都有这个诉求，很多公司的业务场景也用不到数据湖的内容。
我们站在一个求职者的角度去看待这个问题，积极去准备没错👍。
以下是问题列表分析，问题本身并不难，我们从中看一下面试官的思路。
1.数据湖项目要解决什么问题？
2.数据湖项目中使用flink完成mysql->hudi过程中为什么一定要使用row_number去重？直接写入Hudi/Paimon主键表不可以嘛？
3.数据湖项目中如何解决row_number引入的回撤流放大问问题以及回撤流是什么？
4.数据湖链路中链路中可以做哪些架构优化，解决维护复杂性的问题？
5.数据湖链路中读写有哪些最佳实践？
问题1，数据湖项目要解决什么问题？
所有的业务场景中引入一个新的组件都是为了解决具体的业务问题，不是为了引入而引入。所以你看到，面试官第一个关心的就是引入Hudi/Paimon需要解决什么问题？
我们拿Paimon举例，这个组件有自己的特性，例如支持流批读写，分钟级的数据新鲜度，主键和非主键表，此外Paimon还有维度表能力，列更细能力等。
那么我们的业务场景就是为了利用这些特性解决问题。你可以结合自己实际的业务场景去回答，只要言之有理即可。
问题2，数据湖项目中使用Flink完成mysql->hudi过程中为什么一定要使用row_number去重？直接写入Hudi/Paimon主键表可以嘛？
在Flink入湖的过程中，我们非常建议在ODS层处理数据的乱序问题，也就是面试官提到的「使用row_number去重」。这是防止乱序问题最直接有效的方式。
因此在大多数的场景中，我们都强烈建议在ODS做好数据的乱序处理，尤其是下游是主键表的情况，如果不做这种处理很容易导致最终的结果是错误的。
在选择表模型的过程中，主键表和非主键表需要根据需要灵活选择，如果你不需要感知数据中间的变化过程，那么即可选择主键表，否则就选择非主键表。
问题3，数据湖项目中如何解决row_number引入的回撤流放大问问题以及回撤流是什么？
一些基本的原理性质问题需要用「自己的话表达出来」即可，下面的内容也是来自官方，可以参考：
「回撤流」是流处理中用于表示数据变更的一种机制，通过 "+"（插入）和 "-"（删除） 符号来表达数据的增量变化。这是实时数据变更的核心机制之一，出现在聚合、排序、Join等场景。
「回撤流」会带来实时处理性能上的挑战，包括带宽、资源、状态膨胀等挑战。一般来讲我们有两类手段解决这个问题。聚合算子的回撤用于聚合状态的更新，Sink算子的回撤则更多的是应用于CDC场景。
在开发层面，可以通过合理partition by、预聚合等方式减少产生，但是不能根除； 其次在引擎侧，很多公司和云平台上的产品会针对性的做一些优化，例如：产生回撤信息最根本的一个原因是不断地向下游多次发送更新结果，所以为了减少更新的频率并降低并发，可以把更新结果累计一部分之后再发送出去；针对Sink节点优化，可以在AGG节点和Sink节点之间做一个Cache，以此减轻Sink节点的压力。当回撤消息在Cache中再做聚合，当达到Cache的触发条件时，统一将更新后的数据发送到Sink节点。
问题4，数据湖链路中链路中可以做那些架构优化，解决维护复杂性的问题？
这个问题也是一个开放性问题，我们提供一些入湖任务在架构上的优化的思路供大家参考。例如统一接入，强制数据格式校验、元数据统一管理、存储层统一等，可以加入个人的一些理解来回答，最好结合业务场景即可。
问题5，数据湖链路中读写有哪些最佳实践？
这也是半开放性质的问题，大家可以从我之前发过的一些文章中提炼一些关键点回答即可，这些回答最好结合自己真实的场景，避免假大空。
以上就是我们本次的分享内容，可以看到这些问题本身是非常接地气，而且都是生产环境常见的问题，大家可以根据个人情况学习了解。
最后，给自己打个广告。如果你有面试陪跑、在职提升诉求，欢迎联系(vx:whispererrr)，行业最专业有深度的一线大厂面试官小团队贴身保驾护航！
最后，欢迎加入我们的知识星球小圈子：
《300万字！全网最全大数据学习面试社区等你来》。
