spark 小伙伴 alluxio 的测试报告

alluxio 是一款来着 UC Berkeley 的分布式内存文件系统， 主要处理场景就是衔接不同的处理过程， 比如有依赖的 两个 spark job 之间的数据就不用输出磁盘了，少了一次磁盘io，  第一个 job 输出结果到内存中的alluxio 中， 第二个 spark job 直接从内存中读取， 或者 spark job 和 map reduce job  或者flink job 之间有依赖， 也可以使用这种方式。

几个特性

• 提供命令行工具， 调用命令行操作文件系统跟hdfs 差不多
• 文件系统API， 可以控制读写的一些策略， 有只写内存策略， 有同步写内存和底层存储系统策略， 还有写内存异步刷到底层存储系统策略。定位策略是确定应该选择哪个Worker来存储文件数据块
• 世系关系（Lineage）API，这个就是记录原始数据， 和处理过程， 如果后面的数据损坏， 可以根据处理过程重放来恢复数据， 就跟数据库的 redo 日志一样
• 分层存储， 分为内存， SSD， 和 HDD 层， 可以指定定在内存中， 也可以指定数据回收策略， 比如 贪心回收策略 LRU 回收策略等，
• 统一命名空间， 就是可以把 hdfs ， 本地文件系统， s3 文件系统， 挂载到 alluxio 不同的目录中， 使这些文件有一个统一的命名空间
• 跟一些常见的大数据组件做了适配， 比如 hdfs  mapreduce  spark hbase hive flink 等等

测试环境， 硬件  32core  192G 物理机 10台

软件，  hdfs 版本 2.7(主从HA)，  spark 版本 2.1， yarn 版本2.7  alluxio 版本1.4

测试下来得到的一些结论

• 默认分配的是 LocalFirstPolicy ， 0k ~ 4m 之间小文件 往本机写，单线程 200M左右，  单机20个线程 1.5 ~2 G 左右， 并发再高吞吐量下降， 200m ~ 1g文件， ，单线程 400M左右，  单机20个线程 2 G ~ 3G 左右
• 默认是 MUST_CACHE， 数据被同步地写入到Alluxio的Worker。但不会被写入到底层存储系统。这是默认写类型。只写一份， 没有研究出哪个配置可以写多份， 只有一份副本 ， kill 掉文件所在的worker ， 文件不能访问， 但文件不会丢， 启动worker 可以继续访，  如果同步或者异步的刷到底层存储， 则不受影响，在Alluxio中，数据不是保存在JVM中，而是保存在RamDisk中，RamDisk为独立的进程，因此可以保证数据安全。如果机器宕机， 则这种策略下， 数据丢失
• spark 读写 alluxio 数据 比 读写 hdfs 数据 大约快一个数量级
• LocalFirstPolicy 策略下， 在 集群上的node 写数据， 默认写本机， 远程写， 随机找一个点写，  只往同一个点上写， 如果不pin 在内存，等写满了之后，  会淘汰老数据， 如果pin在内存中会导致空间不足会报错， 重启客户端程序， 还是那个点， 同样会报错，
• 跟 spark 结合比较好， 只需要改一下文件系统的 scheme，把 hdfs 改为 alluxio 就好了， 文件系统操作接口也比较类似，

总体评估下来， 感觉没有吹的那么牛x，  比hdfs 读写大约快一个数量级，主要是写内存和写磁盘的差距， 最大的缺点就是数据是单副本的， 如果宕机或者重启某个点， 容易导致数据丢失。