FUSE(FileSystem in User Space) 对算法的价值

前言

MLSQL 有一段时间致力于融合大数据平台和算法平台，实现 【同一个平台，同一个语言。】。事实上我们通过各种方式做到了,通过整合Spark ML,Spark ML周边，以及Python的支持（环境使用Conda）来完成，但是依然不够完美。为什么呢？

大数据和算法的计算模型的不一致性

大数据的框架通常是把数据做切分，然后每个数据集我们叫partition,一个partition通常是用一个iterator进行表示。这个iterator有个特点就是一次性使用，否则每次都要触发产生这个iterator的计算，成本是很高的。当然你也可以cache住，这样就可以反复使用。

而算法框架根据算法的是否能够分布式，有两种模式：

1. 第一种这个算法只能支持单机。所有的数据需要汇总到一个节点，然后反复拿这个数据进行计算（为了收敛），最后得到一个模型。
2. 第二种是这个算法支持分布式，每个算法节点需要的是partiton数据，同样的，需要反复拿这个数据进行计算（为了收敛），并且通常是all reduce模式，all reduce 就是all-or-nothing结果。并行的任务要么全部成功，要么全部失败。但是大数据处理并不是这样的，只要重新计算失败的task即可。

所以我们看到，通常的大数据处理框架，算法要求的如下几点没办法满足：

1. 数据需要全量汇总到一个或者多个节点。
2. 数据需要反复计算（几十次甚至上百次）
3. map-reduce 和 all reduce并不是匹配。
4. 大数据主要工程语言是scala/java，而算法是C/C++/Python，不同语言需要序列化反序列化，通过socket进行跨进程衔接。

FUSE解决了什么

对于1,2两部分，MLSQL目前的做法是一旦发生数据和算法的衔接，就以分布式存储为中转，先将处理好的数据写入到HDFS,然后再将数据全量拉到启动算法的节点上或者是将数据按分区拉到N个节点上（这是透明的，根据算法要求采用不同策略）。这个过程就对local磁盘有了很大的要求（比如你的local disk,通常是tmp要求很大），并且内部实现复杂。如果能通过FUSE将分布式存储挂在到本地磁盘，那就意味着，每个算法节点天然就可以看到所有数据，然后他可以处理所有数据，或者选择一部分数据（是否是分布式算法）。而算法实现着看起来就像在操作本地磁盘一样。这对使用Python做算法开发的同学特别有价值。

而且，通过FUSE,我们可以实现非常高效的数据缓存策略（local磁盘或者内存）。

【先看看分布式算法】

假设一个分布式算法在A,B,C三个节点启动，他们都会读取HDFS的文件，然后这些文件会被FUSE缓存住（Cache）,后续第二次，第三次使用（迭代），就不用走网络了，从而越来越快。

【再看非分布式算法】

假设一个非分布式算法，我们探索他的3个组合的参数，其中，1，2在A节点，3在B节点，那么1,2可以共享数据缓存（都是全量数据）。

【元数据缓存】

我们知道，很多情况下，我们使用分布式存储，光罗列一个文件列表就挺慢的，通过FUSE可以透明在本地缓存分布式存储元数据。

所以FUSE可以实现开发的高效，以及性能上的高效。我们也知道很多算法的瓶颈其实取数据不够快。而通过FUSE可以透明的做掉很多东西。

Others

对于前面提到的第三点，Spark通过引入Barrier API 来解决，第四点也有非常好的框架来比如apache Arrow来缓解对应的问题。

总结

我发现Rust去实现这个会是一个好的选择，HDFS 提供C API,Rust 已经有库分别wrap 该C API以及FUSE API，我们只要实现两者的衔接即可（这里也会是逻辑最复杂的部分，涉及到如何进行高效的缓存）。