spark-alluxio生产环境的应用与实践

来源:互联网 发布:python交互式编程导论 编辑:程序博客网 时间:2024/06/05 21:55

 一、Alluxio由来起因

    Alluxio(之前名为Tachyon)是世界上第一个以内存为中心的虚拟的分布式存储系统。它统一了数据访问的方式,为上层计算框架和底层存储系统构建了桥梁。 应用只需要连接Alluxio即可访问存储在底层任意存储系统中的数据。此外,Alluxio的以内存为中心的架构使得数据的访问速度能比现有常规方案快几个数量级。    

    在大数据生态系统中,Alluxio介于计算框架(如Apache Spark,Apache MapReduce,Apache Flink)和现有的存储系统(如Amazon S3,GlusterFS,HDFS等等)之间。

    Alluxio与Hadoop是兼容的。这意味着已有的Spark和MapReduce程序可以不修改代码直接在Alluxio上运行的。

    Alluxio可以是独立的集群(推荐)。同时,Alluxio与yarn,mesos目前也是兼容的。这也意味着Alluxio可以作为一个普通的App运行在yarn或者mesos上面,这种方式是方便管理的,但是就实用性方面还是不足,定制集群的选择空间太窄,不容易使用。

二、Alluxio在spark中应用主要场景

    Spark 的运行以 JVM 为基础,所以 Spark 的 Job 需要将数据存入 JVM 堆中。随着计算的迭代,JVM 堆中存放的数据会迅速增大。第一、对于 Spark 而言,计算引擎(堆)跟存储引擎(堆外。注意:和off-heap不是一个概念)都处在 JVM 中,所以会有重复的 GC 开销。这就响应了实时系统的低延时特性。其二,当 JVM 崩溃时,缓存在 JVM 堆中的数据也会丢失。这里 Spark 就不得不根据数据的 Lineage,重新计算丢失的数据。其三,当 Spark 需要跟 Hadoop 的 MapReduce 共享数据时,就必须通过第三方来共享,比如 HDFS。因为要借助第三方,就必须面对额外的开销,例如 HDFS 的 Disk IO。

    随着基于内存计算框架的发展,以及以上的问题,促进了内存分布式文件系统的出现,也就是 Alluxio。对于 Spark 而言,计算数据存放于 Alluxio(内存中) 之中,首先会减少 Spark 的 GC 开销。再而当 Spark 的 JVM 进程奔溃时,存放在 Alluxio的数据不会受影响。如果 Spark 需要跟别的计算框架进行数据共享时,只要通过 Alluxio的 Client 就可以做到了,并且延迟远低于 HDFS 等文件系统。

三、Alluxio的设计原理

       1. Alluxio的基本架构:

        Alluxio是主从架构的Master(master-slaves),一个主节点(AlluxioMaster),多个从节点Worker(AlluxioWorker)。

            

        当 Alluxio的 Worker 节点启动之后,Worker 会向 Master 注册。注册成功之后,Master 会和 Worker 之间维护一个心跳。Alluxio会将内存映射为 Block 设备,也就是 RamDisk。然后,Alluxio会将数据存放于每个 Worker 的 Ramdisk,也就是内存中。Alluxio可以以内存的速度去读写 Ramdisk 中存放的数据。Master 是存放媒体信息的,例如文件的大小,以及文件在哪个 Worker。这里的设计其实类似于 HDFS 得 NameNode 和 DataNode。Worker 会在心跳中将数据信息传递给 Master,Master 会更新数据的媒体信息。对于一个集群来说,内存总是有限的,因此 Alluxio还需要支持硬盘的文件系统,这里称之为 UnderFS。Alluxio会将一些持久性的文件存在 UnderFS 中。这里的 UnderFS 可以是 OS 的文件系统,也可以是 HDFS、GlusterFS、S3 之类的分布式文件系统。

      2. Alluxio的HA高级架构:(常用推荐)

       Alluxio的容错通过多master实现。同一时刻,有多个master进程运行。其中一个被选举为leader,作为所有worker和 client的通信首选。其余master进入备用状态,和leader共享日志,以确保和leader维护着同样的文件系统元数据并在 leader失效时迅速接管leader的工作。当前leader失效时,自动从可用的备用master中选举一个作为新的leader,Alluxio继续正常运行。但在切换到备用 master时,客户端会有短暂的延迟或瞬态错误。

            

从架构图看以看出要实现一个容错的Alluxio集群需要两方面的准备:

  • ZooKeeper
  • 用于存放日志的可靠的共享底层文件系统。

Alluxio使用Zookeeper实现容错和leader选举,可以保证在任何时间最多只有一个leader。

Alluxio使用共享底层文件系统存放日志。共享文件系统必须可以被所有master访问,可以选择 HDFS(笔者使用)Amazon S3或 GlusterFS作为共享文件系统。leader master将日志写到共享文件 系统,其它(备用) master持续地重播日志条目与leader的最新状态保持一致。

    3.Alluxio在yarn环境的部署

       Alluxio在yarn上部署的架构图:

       简述:具体的架构解释可以根据yarn本身使用的架构原理相比较。

注意的地方:如果要使用在yarn环境下面的部署,不能用之前部署使用的二进制tar包,必须先停止之前独立模式的Alluxio集群,指定Hadoop(yarn)的版本重新编译Alluxio,编译时指定”yarn”配置文件(以便Alluxio包含YARN client 和ApplicationMaster)。具体方法,见官网。(笔者不推荐使用这种方法,实际也没有测试过)

四、Alluxio在大数据生态系统的地位

        由于Alluxio的设计以内存为中心,并且是数据访问的中心,所以Alluxio在大数据生态圈里占有独特地位,它居于传统大数据存储(如:Amazon S3,HDFS)和大数据计算框架(如Spark,Hadoop Mapreduce)之间。对于用户应用和计算框架,无论其是否运行在相同的计算引擎之上,Alluxio都可以作为底层来支持数据的访问、快速存储,以及多任务的数据共享和本地化。

    因此,Alluxio可以为那些大数据应用提供一个数量级的加速,同时它还提供了通用的数据访问接口。对于底层存储系统,Alluxio连接了大数据应用和传统存储系统之间的间隔,并且重新定义了一组面向数据使用的工作负载程序。因Alluxio对应用屏蔽了底层存储系统的整合细节,所以任何底层存储系统都可以支撑运行在Alluxio之上的应用和框架。此外Alluxio可以挂载多种底层存储系统,所以它可以作为统一层为任意数量的不同数据源提供服务。

Stack

五、Alluxio集群部署

    独立模式:

   1、Alluxio local模式。

         因为官方网站上面用的是local模式,加上网上有很多local的模式,部署也相当的简单,这里就不多介绍了。官方网址:http://www.alluxio.org/docs/master/cn/Running-Alluxio-Locally.html

   2、Alluxio cluster模式(HA)。

        这里默认使用者已经部署了Hadoop,spark的集群环境。并且对Linux各种操作命令也有一定的了解。

所以直接部署Alluxio的集群环境。在搭建Alluxio的环境的时候,最重要部署三个组件的配置:master,worker,client。

        第一步:下载二进制包和JDK8版本(以后只支持JDK8),(如果有特殊的需要可以重新下载源码包maven打包编译)

            wget http://downloads.alluxio.org/downloads/files/1.3.0/alluxio-1.3.0-cdh5-bin.tar.gz

                  访问官网下载地址:http://www.alluxio.org/download,选择你想下载的对应版本。如果使用的Hadoop环境是CDH的,那么下载相应的CDH版本就好。这样兼容性更好。(笔者一直使用的CDH5版本)

                

第二步:安装好JDK8,解压Alluxio并配置环境变量。

    export JAVA_HOME=/opt/core/jdk1.8.0_102

    export ALLUXIO_HOME=/opt/core/alluxio

    export  PATH=.:$JAVA_HOME/bin:$ALLUXIO_HOME/bin:$PATH

第三步:配置alluxio配置文件。

     1)在目录$ALLUXIO_HOME/conf的目录下面找到配置文件alluxio-env.sh

        编辑以及更改一下配置项:

                ALLUXIO_RAM_FOLDER=/opt/data/ramdisk

                解释:内存映射到磁盘下目录(读取文件的时候读的是内存,内存!!不是磁盘。)                ALLUXIO_UNDERFS_ADDRESS=hdfs://serviceName/alluxio

                解释:Alluxio底层存储的文件系统,可以是s3以及其他的文件系统,这里用HDFS。(官方配置的是namenode的地址和服务端口,这里直接用的serviceName,目的是支持多个Namenode HA的情况)

                ALLUXIO_WORKER_MEMORY_SIZE=90GB

                解释:这个是每台机器上面的worker节点所占用的内存大小,根据需求自动调整。

                ALLUXIO_JAVA_OPTS="-Dalluxio.zookeeper.enabled=true -Dalluxio.zookeeper.address=zk1:2181,zk2:2181,zk3:2181 -Dalluxio.master.journal.folder=hdfs://serviceName/alluxio/journal"

                解释:启用Alluxio高可用的配置项,启动用户必须有权限在HDFS上面写数据。这个配置项是全局的,也就是在master,worker,client上面都起作用 。

 ALLUXIO_USER_JAVA_OPTS="-Dalluxio.zookeeper.enabled=true -Dalluxio.zookeeper.address=zk1:2181,zk2:2181,zk3:2181"

                解释:配置客户端的配置项,全局已经配置,这里可以省略。

2)更加高级的配置项可以在$ALLUXIO_HOME/conf/alluxio-site.properties定制化配置。

        如:启用多个存储策略(目前支持mem,SSD,disk),也可以定制存储的算法。                                    

                同时也可以配置用户的权限。

其他的配置项目可以参考官方网址:

第四步:把hadoop下面的core-site.xml,hdfs-site.xml拷贝到$ALLUXIO_HOME/conf/的目录下面。若没有拷贝可能造成解析不了hdfs的serviceName,最后把worker的配置文件配置你想要配置的worker节点。

第五步:启动master,worker节点。

        alluxio-start.sh master

        alluxio-start.sh worker

完成现在可以正常使用了。

第六步:集成spark,在$SPARK_HOME/conf/spark-defaults.conf配置中加上配置项,同步worker节点重启spark集群。

spark.driver.extraClassPath $ALLUXIO_HOME/core/client/target/alluxio-core-client-1.3.0-jar-with-dependencies.jar

        基本可以使用的,如果在使用的过程中有权限的问题还请读者根据自己的环境配置下面的几个配置项。

alluxio.security.login.username=
alluxio.security.authorization.permission.umask=
alluxio.security.authorization.permission.supergroup=