Hello大家好，最近JD VS. 美团的外卖大战看的不亦乐乎。也有很多同学们在讨论这个问题。
充分竞争的市场对打工人是有利的，两家都在招兵买马，期望有更多的公司参与进来，能够给就业市场带来充分的活力。
今天我们分享的是，我们大数据提高班的同学面试京东的面试题，这位同学已经拿到offer。
我们挑其中问的有质量的三个问题分析一下，希望给大家带来帮助。
Spark的调优经验，举例说明
这个问题是一个老生常谈的问题了。你可以在历史文档中找到：
当然如果你对Spark3.0和4.0够了解，那么还可以谈一谈：
好的，重点来了。上面这些内容够不够回答这个问题呢？明显是不够的，因为这些内容已经是老掉牙的八股文了。
你需要从「具体的业务场景入手」，意思就是说你的表达最好从真实的业务场景入手，而不是机械的记忆这些「八股文」，告诉面试官你在什么业务场景遇到了什么问题？如何定位的？最终选择的技术方案是什么？你还知道哪些优化的策略？这样的表达就足够拿到满分了。
2. Flink如何保证精确一次消费？生产环境怎么用的？
这也是一个老生常谈的问题。你可以参考这里：
那么这个答案有什么问题吗？注意面试官后面带的问题是「生产环境你们怎么用的？」。
时至今日，在实际生产环境，极少场景会用「精确一次」。 所以你要特别注意回答这个问题，中大公司有经验的面试官会根据你的回答判断你的真实水平。
为什么我们很少用「精确一次」？原因是真正实现精确一次成本极高，仅仅靠Flink和sink端的能力是不可靠的。一般需要借助外部存储实现。所以我们绝大多数场景是保障「At-least Once」，如果你需要去重，那么在你的数据消费侧要自己去做去重消费。
3. Paimon异步合并怎么实现的，为什么要用异步合并？你们生产环境怎么用的？
这个问题也很有水平，因为基本所有的湖框架都会遇到小文件问题。Paimon异步合并是为了避免阻塞正常的数据写入流程。
当有新数据写入 Paimon 表时，系统不会立即对这些数据进行合并处理。而是将数据写入到临时文件中，这些临时文件会按照一定规则组织，例如按照数据的分区、排序键等进行划分，方便后续的合并操作。临时文件会被存储在指定的存储位置，如文件系统或对象存储。
Paimon 会依据预设条件触发合并任务，这些条件可以基于时间（如每隔一段时间执行一次合并）、文件数量（如某个分区内的临时文件数量达到一定阈值）或文件大小（如临时文件的总大小超过一定值）等。
异步合并三个显著优势：
提升写入性能；异步合并将合并操作放在后台执行，数据写入操作无需等待合并完成，可继续快速处理新的数据写入请求，从而显著提高系统的写入吞吐量。
节省资源；异步合并将合并任务放在线程池中异步执行，可以更灵活地利用系统资源。在系统资源空闲时，线程池可以并行处理多个合并任务，提高资源利用率；而在系统资源紧张时，合并任务可以适当降低执行频率，避免与其他关键任务竞争资源。
保证数据一致；异步合并过程中，数据的写入和合并操作是分离的，数据写入操作不会受到合并操作的影响，保证了数据写入的及时性和一致性。同时，Paimon 通过原子性的元数据更新机制，确保在合并操作完成后，表的元数据能够准确反映数据的最新状态，进一步保证了数据的一致性。
上面这一大堆就是异步合并的原理了，在生产环境我们采取的是「异步合并」。
当 Paimon与Flink集成时，Flink作业主要负责数据的读写操作，而异步合并任务由Paimon自行管理，二者相互配合，无需额外开发Flink任务用于合并。
但是其他的湖框架例如Hudi就需要用户启动一个单独的Flink任务进行小文件的合并了。
好了今天的分享就到这里，红马褂已备好，我们可以准备冲一下JD外卖了。😄
最后，欢迎加入我们的知识星球小圈子：
《300万字！全网最全大数据学习面试社区等你来》。
如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！
扫一扫
647
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
