摘要:Spark,强大的迭代计算框架,在内存数据计算上无可匹敌。Cassandra,优异的列式存储NoSQL,在写入操作上难逢敌手。自本期《问底》,许鹏将结合实际实践,带大家打造一个由Spark和Cassandra组成的大数据分析平台。
3. 利用Spark强化Cassandra的实时分析功能
在Cassandra数据模型一节中,讲述了通过数据冗余和反范式设计来达到快速高效的查询效果。
但如果对存储于cassandra数据要做更为复杂的实时性分析处理的话,使用原有的技巧无法实现目标,那么可以通过与Spark相结合,利用Spark这样一个快速高效的分析平台来实现复杂的数据分析功能。
3.1 整体架构
利用spark-cassandra-connector连接Cassandra,读取存储在Cassandra中的数据,然后就可以使用Spark RDD中的支持API来对数据进行各种操作。
3.2 Spark-cassandra-connector
在Spark中利用datastax提供的spark-cassandra-connector来连接Cassandra数据库是最为简单的一种方式。
目前spark-cassandra-connector 1.1.0-alpha3支持的Spark和Cassandra版本如下
- Spark 1.1
- Cassandra 2.x
如果是用sbt来管理scala程序的话,只需要在build.sbt中加入如下内容即可由sbt自动下载所需要的spark-cassandra-connector驱动
datastax.spark" %% "spark-cassandra-connector" % "1.1.0-alpha3" withSources() withJavadoc()
由于有的时候在github.com/datastax/spark-cassandra-connector官方站点上的文档不一定准确,要想确切知道有哪些版本可以由sbt自动下载的话,可以通过maven的仓库来查看,具体查看地址是
http://mvnrepository.com/artifact/com.datastax.spark
3.2.1 driver的配置
使用spark-cassandra-connector的时候需要编辑一些参数,比如指定Cassandra数据库的地址,每次最多获取多少行,一个线程总共获取多少行等。
这些参数即可以硬性的写死在程序中,如
val conf = new SparkConf()
conf.set(“spark.cassandra.connection.host”, cassandra_server_addr)
conf.set(“spark.cassandra.auth.username”, “cassandra”)
conf.set(“spark.cassandra.auth.password”,”cassandra”)
硬编码的方式是发动不灵活,其实这些配置参数完全可以写在spark-defaults.conf中,那么上述的配置可以写成
spark.cassandra.connection.host 192.168.6.201
spark.cassandra.auth.username cassandra
spark.cassandra.auth.password cassandra
3.2.2 依赖包的版本问题
sbt会自动下载spark-cassandra-connector所依赖的库文件,这在程序编译阶段不会呈现出任何问题。
但在执行阶段问题就会体现出来,即程序除了spark-cassandra-connector之外还要依赖哪些文件呢,这个就需要重新回到maven版本库中去看spark-cassandra-connector的依赖了。
总体上来说spark-cassandra-connector严重依赖于这几个库
- cassandra-clientutil
- cassandra-driver-core
- cassandra-all
另外一种解决的办法就是查看$HOME/.ivy2目录下这些库的最新版本是多少
find ~/.ivy2 -name “cassandra*.jar”
取最大的版本号即可,就alpha3而言,其所依赖的库及其版本如下
com.datastax.spark/spark-cassandra-connector_2.10/jars/spark-cassandra-connector_2.10-1.1.0-alpha3.jar
org.apache.cassandra/cassandra-thrift/jars/cassandra-thrift-2.1.0.jar
org.apache.thrift/libthrift/jars/libthrift-0.9.1.jar
org.apache.cassandra/cassandra-clientutil/jars/cassandra-clientutil-2.1.0.jar
com.datastax.cassandra/cassandra-driver-core/jars/cassandra-driver-core-2.1.0.jar
io.netty/netty/bundles/netty-3.9.0.Final.jar
com.codahale.metrics/metrics-core/bundles/metrics-core-3.0.2.jar
org.slf4j/slf4j-api/jars/slf4j-api-1.7.7.jar
org.apache.commons/commons-lang3/jars/commons-lang3-3.3.2.jar
org.joda/joda-convert/jars/joda-convert-1.2.jar
joda-time/joda-time/jars/joda-time-2.3.jar
org.apache.cassandra/cassandra-all/jars/cassandra-all-2.1.0.jar
org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.7.2.jar
3.3 Spark的配置
程序顺利通过编译之后,准备在Spark上进行测试,那么需要做如下配置
3.3.1 spark-default.env
Spark-defaults.conf的作用范围要搞清楚,编辑driver所在机器上的spark-defaults.conf,该文件会影响到driver所提交运行的application,及专门为该application提供计算资源的executor的启动参数
只需要在driver所在的机器上编辑该文件,不需要在worker或master所运行的机器上编辑该文件
举个实际的例子
spark.executor.extraJavaOptions -XX:MaxPermSize=896m
spark.executor.memory 5g
spark.serializer org.apache.spark.serializer.KryoSerializer
spark.cores.max 32
spark.shuffle.manager SORT
spark.driver.memory 2g
上述配置表示为该application提供计算资源的executor启动时, heap memory需要有5g。
这里需要引起注意的是,如果worker在加入cluster的时候,申明自己所在的机器只有4g内存,那么为上述的application分配executor是,该worker不能提供任何资源,因为4g<5g,无法满足最低的资源需求。
3.3.2 spark-env.sh
Spark-env.sh中最主要的是指定ip地址,如果运行的是master,就需要指定SPARK_MASTER_IP,如果准备运行driver或worker就需要指定SPARK_LOCAL_IP,要和本机的IP地址一致,否则启动不了。
配置举例如下
export SPARK_MASTER_IP=127.0.0.1
export SPARK_LOCAL_IP=127.0.0.1
3.3.3 启动Spark集群
第一步启动master
<span style="color:#333333">$SPARK_HOME/sbin/start-master.sh</span>
第二步启动worker
$SPARK_HOME/bin/spark-class org.apache.spark.deploy.worker.Worker spark://master:7077
将master替换成MASTER实际运行的ip地址
如果想在一台机器上运行多个worker(主要是用于测试目的),那么在启动第二个及后面的worker时需要指定—webui-port的内容,否则会报端口已经被占用的错误,启动第二个用的是8083,第三个就用8084,依此类推。
$SPARK_HOME/bin/spark-class org.apache.spark.deploy.worker.Worker spark://master:7077
–webui-port 8083
这种启动worker的方式只是为了测试是启动方便,正规的方式是用$SPARK_HOME/sbin/start-slaves.sh来启动多个worker,由于涉及到ssh的配置,比较麻烦,我这是图简单的办法。
用$SPARK_HOME/sbin/start-slave.sh来启动worker时有一个默认的前提,即在每台机器上$SPARK_HOME必须在同一个目录。
注意:
使用相同的用户名和用户组来启动Master和Worker,否则Executor在启动后会报连接无法建立的错误。
我在实际的使用当中,遇到”no route to host”的错误信息,起初还是认为网络没有配置好,后来网络原因排查之后,忽然意识到有可能使用了不同的用户名和用户组,使用相同的用户名/用户组之后,问题消失。
3.3.4 Spark-submit
spark集群运行正常之后,接下来的问题就是提交application到集群运行了。
Spark-submit用于Spark application的提交和运行,在使用这个指令的时候最大的困惑就是如何指定应用所需要的依赖包。
首先查看一下spark-submit的帮助文件
$SPARK_HOME/bin/submit --help
有几个选项可以用来指定所依赖的库,分别为
- --driver-class-path driver所依赖的包,多个包之间用冒号(:)分割
- --jars driver和executor都需要的包,多个包之间用逗号(,)分割
为了简单起见,就通过—jars来指定依赖,运行指令如下
$SPARK_HOME/bin/spark-submit –class 应用程序的类名 \
--master spark://master:7077 \
--jars 依赖的库文件 \
spark应用程序的jar包
3.3.5 RDD函数使用的一些问题
collect
如果数据集特别大,不要贸然使用collect,因为collect会将计算结果统统的收集返回到driver节点,这样非常容易导致driver结点内存不足,程序退出
repartition
在所能提供的core数目不变的前提下,数据集的分区数目越大,意味着计算一轮所花的时间越多,因为中间的通讯成本较大,而数据集的分区越小,通信开销小而导致计算所花的时间越短,但数据分区越小意味着内存压力越大。
假设为每个spark application提供的最大core数目是32,那么将partition number设置为core number的两到三倍会比较合适,即parition number为64~96。
/tmp目录问题
由于Spark在计算的时候会将中间结果存储到/tmp目录,而目前linux又都支持tmpfs,其实说白了就是将/tmp目录挂载到内存当中。
那么这里就存在一个问题,中间结果过多导致/tmp目录写满而出现如下错误
No Space Left on the device
解决办法就是针对tmp目录不启用tmpfs,修改/etc/fstab,如果是archlinux,仅修改/etc/fstab是不够的,还需要执行如下指令:
systemctl mask tmp.mount
3.4 Cassandra的配置优化
3.4.1 表结构设计
Cassandra表结构设计的一个重要原则是先搞清楚要对存储的数据做哪些操作,然后才开始设计表结构。如:
- 只对表进行添加,查询操作
- 对表需要进行添加,修改,查询
- 对表进行添加和修改操作
一般来说,针对Cassandra中某张具体的表进行“添加,修改,查询”并不是一个好的选择,这当中会涉及到效率及一致性等诸多问题。
Cassandra比较适合于添加,查询这种操作模式。在这种模式下,需要先搞清楚要做哪些查询然后再来定义表结构。
加深对Cassandra中primary key及其变种的理解有利于设计出高效查询的表结构。
create test ( k int, v int , primary key(k,v))
上述例子中primary key由(k,v)组成,其中k是partition key,而v是clustering columns,如果k相同,那么这些记录在物理存储上其实是存储在同一行中,即Cassandra中常会提及的wide rows.
有了这个基础之后,就可以进行范围查询了
select * from test where k = ? and v > ? and v < ?
当然也可以对k进行范围查询,不过要加token才行,但一般这样的范围查询结果并不是我们想到的
select * from test where token(k) > ? and token(k) < ?
Cassandra中针对二级索引是不支持范围查询的,一切的一切都在主键里打主意。
3.4.2 参数设置
Cassandra的配置参数项很多,对于新手来说主要集中于对这两个文件中配置项的理解。
- cassandra.yaml Cassandra系统的运行参数
- cassandra-env.sh JVM运行参数
在cassandra-env.sh中针对JVM的设置
JVM_OPTS="$JVM_OPTS -XX:+UseParNewGC"
JVM_OPTS="$JVM_OPTS -XX:+UseConcMarkSweepGC"
JVM_OPTS="$JVM_OPTS -XX:+CMSParallelRemarkEnabled"
JVM_OPTS="$JVM_OPTS -XX:SurvivorRatio=8"
JVM_OPTS="$JVM_OPTS -XX:MaxTenuringThreshold=1"
JVM_OPTS="$JVM_OPTS -XX:CMSInitiatingOccupancyFraction=80"
JVM_OPTS="$JVM_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
JVM_OPTS="$JVM_OPTS -XX:+UseTLAB"
JVM_OPTS="$JVM_OPTS -XX:ParallelCMSThreads=1"
JVM_OPTS="$JVM_OPTS -XX:+CMSIncrementalMode"
JVM_OPTS="$JVM_OPTS -XX:+CMSIncrementalPacing"
JVM_OPTS="$JVM_OPTS -XX:CMSIncrementalDutyCycleMin=0"
JVM_OPTS="$JVM_OPTS -XX:CMSIncrementalDutyCycle=10"
如果nodetool无法连接到Cassandra的话,在cassandra-env.sh中添加如下内容
JVM_OPTS="$JVM_OPTS -Djava.rmi.server.hostname=ipaddress_of_cassandra"
在cassandra.yaml中,注意memtable_total_space_in_mb的设置,不要将该值设的特别大。将其配置成为JVM HEAP的1/4会是一个比较好的选择。如果该值设置太大,会导致不停的FULL GC,那么在这种情况下Cassandra基本就不可用了。
3.4.3 nodetool使用
Cassandra在运行期间可以通过nodetool来看内部的一些运行情况。
如看一下读取的完成情况
nodetool -hcassandra_server_address tpstats
检查整个cluster的状态
nodetool -hcassandra_server_address status
检查数据库中每个表的数据有多少
nodetool -hcassandra_server_address cfstats