Alluxio

alluxio 【1】是一个分布式文件系统，主要用来做大数据处理，和数据源之间的中间层。

它本身支持内存和SSD，HDD的tiering，但实践中主要感兴趣的是它的内存缓存。

类似Gfs，它有master，workers，和clients。client向master查询数据位置，然后向本地workers提IO请求。workers之间通过Grpc做数据请求。没有复制，读数据在请求节点上也会缓存。

Alluxio本身分为lineage和persistent两个部分。其中lineage部分是可选的。

Cloudera的数据表明，写很重要。34%的用户写的和Input一样多。Alluxio没有复制的原因是这样可以提供更高的写性能。用同步复制不可能提供无损的写性能。用lineage来track文件的历史(先把如何从dataset A构造dataset B的各种参数，程序写入Persistent layer。aka linage log)，而且track jobs，并用checkpoint来保护数据，加上journal，可以重新计算出数据。Alluxio和Haoyuan的贡献是提供了bounded recomputation time. 在一个连续写入的系统中，如果perisistent的速度慢于进入的速度，最终会把recomputation的速度无限延长。Alluxio采用的方法是采用一个叫Edge algorithm的算法做异步本地复制，以及他称为recomputation资源分配的机制来保证QoS。

Recomputation Bound的证明写的很简单，没有详细写（好像表述不严谨，也可能是我理解不了），我用白话翻译一下就是，假设我们总是checkpoint叶子，而且是假设是连续不断的checkpoint，中间不休息。那么时间是连续的，如果一个checkpoint花了时间t，中间可能已经产生几个文件了。不管产生多少文件，还是花了时间t。换句话说，在恢复的时候，也只要花时间t就可以recompue了。作者定义了一个变量M，方便证明bound，M是所有文件中，存checkpoint或者从前一个版本计算的最大值。t肯定小于M。作者用了3M，就是前一个文件checkpoint的时间，加上重新计算到需要文件前一个的时间，加上最后这个文件重计算的时间。我认为其实应该2M就够了，3M可能算上了最后的文件刚刚计算完，但checkpoint没有完的情况。

这个证明有两个问题：1. 这个是回头看，M是在所有已知的文件计算结束后才知道的。所以从系统的角度来说，3M是bound但是M是未知的。2. 没有考虑并行的问题。计算时和恢复时的资源分配是不一样的，所以作者又打了个资源分配的补丁。如果系统dedicate比例c给恢复，3M/c才是bound。

在真实场景中，这个都是小问题。特别是在云环境中，节点也许是可以扩展的，用来恢复数据。注意这个recompute，是在Alluxio中发生的，而不是Spark的lineage。虽然binary和参数都存下来了，但是和上层的对接仍然是个麻烦事，应用需要知道Alluxio，甚至要提供一个专门的用来恢复的program。这些都会影响到Alluxio基于lineage的恢复使用场景。

persistent部分可以使用各种提供复制的可靠存储可选。

数据是如何进入alluxio的呢？一种是从spark存入。另一种从数据源读入。通过mount建立映射关系。然后用alluxio fs load命令把数据载入。

【1】www.alluxio.io