4-2 选题最终方案

邀请了老师参加会议，以确定最终的选题方案

会议记录

老师：为什么使用rust？

举例：drovebox重写使用rust，之前有一些尝试： 1. C++语言 gc复杂，较复杂，2.go gc机制，性能波动 3.rust没有gc，性能稳定

只考虑spark的性能瓶颈，原因来自哪里，哪里适合优化，高性能访问的点适合rust重写

老师：建议放到编译原理

老师：和系统的接口，较难实现。是否可以优化？不一定。文件读写性能读写不一定可以用rust优化。

分布式文件系统的评价标准，找瓶颈，很多不在文件系统本身上，而在于文件访问的流程。

rdma kernelbypassing，还有内存，cache，

infinity band，标准接口，底层封装

老师：已有CEPH做过，

老师：这不就是spark🐎，批流一体化这一块很成熟。

大厂已经投入较大的研发力量，竞争激烈，很难做出彩。

需要好的切入点。

老师：这个很有意思。

可以做分布式计算，轻量式，多个节点时钟上同步，多余路系统，融合

偏应用，捷联惯导，星光导航，单节点较难实现，但多节点可以

然而和分布式计算关系不大，更多是融合计算的问题

老师：不建议，很容易实现，不复杂

是否有二级索引的需求？网络端和数据库端都进行负载均衡。

更偏分布式数据库，查询为主，多余路，多备份，写需要考虑。目前没有使用是有考量的。

spark模块的优化，可以考虑。但需要找到瓶颈，找到优化点，同时spark已经出现比较久了，比较难出彩。

导航系统：单机导航不准，多机导航是否可以准确？两个节点是否在同一个位置，还是有一个已知的距离。但这个和操作系统关系不大，更多是应用的方面。

分布式文件系统，魔改，存储和访问可以用rust来写，内核级指令集，直接调用kernel bypassing(eBPF)模块，bypass，直接到CPU cache。直接调用指令。

文件系统不建议使用GFS，很难看到效果。要找性能低的。在cache中锁定区域是可以使用rust的。可行性需要调研。针对java语言支持的文件系统。

基于Rust语言对Apache Spark性能瓶颈的优化

[ ] spark 论文调研，原生实现，了解使用方式 - 闫泽轩

[ ] rust重写spark可行性 - 罗浩铭，汤皓宇

[ ] rust语言优点调研 - 徐航宇，李牧龙