Alluxio : 开源分布式内存文件系统
Alluxio : 开源分布式内存文件系统
Alluxio is a memory speed virtual distributed storage system.Alluxio是一个开源的基于内存的分布式存储系统，现在成为开源社区中成长最快的大数据开源项目之一。
公司简介：
-
由项目的创建者李浩源以及来自UC Berkeley, Google, CMU, Palantir, Stanford, Yahoo等不同公司和学校的项目核心开发者组成。
-
完成750万 dollars 的A轮融资，由Andreessen Horowitz投资（硅谷最著名的VC之一，主要成员为网景公司创始人之一）。
背景介绍：
-
2012年诞生于UC Berkeley AMPLab，此前这个实验室孵化了Apache Mesos和Apache Spark等著名开源项目。
-
2013年4月开源，现在由最初的Tachyon改名为Alluxio，基于Apache License 2.0开源标准，最新版本为Version 1.0 (Feb 23rd, 2016)。
-
在分布式系统的开源项目中，相比于同级别项目，Alluxio的增长非常迅速
-
吸引了来自超过50个组织的200+个contributors。
主要特性：
-
数据存储与计算分离，两部分引擎可以进行独立的扩展。计算引擎(如Hadoop, Spark)可以访问不同数据源(Amazon S3, HDFS)中的数据。
问题：与Redis，Memcached等分布式in-memory key-value缓存的的区别：
-
答：（1） Alluxio可以同时管理多个底层文件系统，将不同的文件系统统一在同一个名称空间下，让上层客户端可以自由访问统一名称空间内的不同路径，不同存储系统的数据。（2）Alluxio提供文件接口，并存储且维护文件的metadata（比如记录文件分成哪几个block， 每一个block在哪台server上）。并提供fault tolerance的metadata服务。而Redis/Memcached为Nosql的key-value分布式缓存，并不提供文件接口。
内存与硬盘比较
硬盘内存增长率曲线：
因此，充分利用内存，成为趋势，而Memory locality成为影响相应时间最重要的因素之一。硬盘内存价格曲线：
Alluxio with Spark
-
Spark是一种基于内存的运算框架。
-
在JVM的内存中存储一份，以保证较少的网络通信和读写。
-
记录存储数据的世代(lineage)，当数据丢失时，基于世代将job重新运行，得到相应数据。
Issue 1：数据分享(Data Sharing)在analytics pipeline中成为瓶颈。
在Spark中，如果job2需要Job1运算的数据，Job1首先需要将数据写入到HDFS的block中，会产生硬盘甚至跨网络的读写，同时在HDFS中默认数据需要写三份，因此造成性能的损失。
Issue 1 的解决方案：内存数据在不同的job和framework中进行分享。
Alluxio在HDFS/ Amazon S3和计算引擎中间提供了中间层，Spark的Job1不需要写到HDFS中，而只需要写到Alluxio的内存中，Job2可以从内存中读取相应数据。
Issue 2: 当计算引擎的进程损坏，Cache 丢失，Spark只能重新启动并计算恢复数据。
Issue 2 解决方案：
当计算引擎损坏，由于中间由Alluxio存储数据，可以保证内存中的数据安全。
问题1：因为在传统计算引擎中，数据存储在同一个JVM中，而基于Alluxio的中间件将数据存到了不同的JVM中，跨JVM读写会不会影响性能？
答：跨JVM读写会影响性能，在Alluxio中，使用了RamDisk来模拟本地文件系统的方式。
问题2：如果Alluxio crash，怎么保证数据安全？
答：在Alluxio中，数据不是保存在JVM中，而是保存在RamDisk中，RamDisk为独立的进程，因此可以保证数据安全。
问题3：Alluxio是否可以支持随机读写？
答：可以进行随机读，给定一个offset。新创立的文件一旦关闭，就会变成immutable
Issue 3: 内存数据的重复和Java的垃圾回收。Issue 3 解决方案：
由于计算引擎与存储引擎共享同一个进程，而不是放在自己的JVM中，可以减少垃圾回收和数据重复。
Alluxio 架构: Memory-centric storage architecture
核心思想：将世代（lineage）由计算引擎放到了数据层处理。
1，存储架构:
master节点负责管理worker节点，数据存储在worker节点中。
对于每一个worker，worker daemon为一个JVM，负责管理Ramdisk，数据存储在Ramdisk中。
如果有高可用性的需求，可以设置standby master和zookeeper来容错，这里会有性能损耗。
2，世代(Lineage) 保证数据的Reliability
1，当数据E丢失后，通过世代找到相应的之前数据，重新部署一个Job将数据重新计算。
2，将数据在底层文件系统中备份。
问题：HDFS中每个数据块会默认有多个备份， 从而在极端情况下会有更大的读取带宽。 在Alluxio中，由于数据存储在同一份内存中，如何处理多个Job同时读取同一份数据的情况。
答： Alluxio的数据在内存当中，本身可以提供更大的本地读取带宽。另外Alluxio也允许让用户绕过Alluxio直接从底层的持久化文件系统读取数据。
3，分层存储（Tiered Storage）：
当数据大小超过内存容量，如何处理？
Alluxio不仅仅管理内存，同样可以管理SSD，HDD等系统资源。保证Alluxio可以正常运行。
One Large Scale deployment：
某公司实现了1000 workder 的Alluxio部署，每个机器几G-几十个G的内存 。
4，可插拔的数据管理（Pluggable Data Management）
基于每一个worker，暂时没有跨worker。对于计算机系统来说，长期以来人们在不同的场景下反复使用两个经典但行之有效的方案：
1，cache。
2，增加一个中间层（比如增加一层指针，如virtual memory）
Q: Alluxio 有没有全局的分层存储的allocation/eviction管理?
A: 目前Alluxio的cache策略是基于每一个worker单独的决策，暂时没有实现跨worker的分层存储的协作。
5，Pin Data
对于重要的数据，可以通过Pin来显示的把数据“挂”在内存层
问题：对于Pin的data，怎么保证底层数据修改之后上层数据的更新。
答：给用户提供命令去主动更新数据。
6，透明命名（Transparent Naming）
Alluxio可以提供将创建，重命名和删除文件等操作从Alluxio映射到底层存储层（比如上图中的HDFS 或者S3)的对象中，从而实现将底层存储系统中的文件与其Alluxio自身管理的文件系统的完全同步。
7，统一命名空间（Unified Namespace）
Alluxio可以挂载多个不同的文件系统到一个统一的命名空间当中，如不同的文件系统A和文件系统B可以同时挂载到Alluxio上面的不同目录当中。
在不同的数据文件系统中可以共享数据。
此操作可以on the fly，被管理员进行操作。
Alluxio Case Study:
百度：
性能提升：30x
框架: SparkSQL
存储系统: Baidu’s File System
存储媒介: MEM+HDD
节点数量： 100+
空间管理大小：1PB+
Q: 为什么可以提供30x的性能提升？
A: 百度的一项业务采用计算和存储分离的架构：比如计算集群在一个城市，而数据存储集群在另一个城市。数据存储集群计算资源较少，而计算集群没有足够存储资源。百度将Alluxio部署到了计算集群中。从而将数据存储在了Alluxio中，从而使计算集群可以在本地完成读写。
去哪儿网：
框架：Spark Streaming
存储系统：HDFSS
存储媒介：MEM+HDD
节点数量：200+
Barclays：
框架：SparkSQL
存储系统：None
存储媒介： Memory
某石油公司：
框架： Spark
存储数据：ClusterFS
存储媒介：MEM only
性能提升：在传统文件系统中使用Spark进行数据处理。
某SAAS公司：
框架：Impala
存储系统： S3
存储媒介： MEM+SSD
性能提升：15x
Alluxio新特性：
- Alluxio Key-value (Alpha)
- Native Swift Integration(Openstack下面的文件系统)
- Alibaba Object Storage Service Integration
- Users/Groups in File System
- ACL Permission
- Read/Write Location Preference Policy
- Improved Yarn and Mesos Integration
注：本文系2016年2月29日太阁三人行“一起聊聊Alluxio”的总结分享，感谢Menglei Sun的整理，Dr Bin Fan的校注
