转自:https://blog.csdn.net/maobaolong/article/details/79337538
京东大数据平台
规模
集群规模
服务器规模30000台+,离线集群总规模18000+ , 用户6000+
计算能力
离线数据日处理40PB+,日运行Job数100万+
存储能力
总数据量400PB+,日增数据量500TB+
业务能力
业务主题40+,数据模型450+
大数据平台架构
Alluxio介绍
Alluxio(之前的Tachyon)。是世界上第一个以内存速度统一不同存储系统的系统。在大数据生态中,Alluxio位于计算框架和各种存储系统之间。此外,Alluxio存储为中心的架构,使数据访问速度的数量级比现有解决方案快得多。
Alluxio社区的优势
Alluxio社区的以下优势使得Alluxio越来越多的被很多知名企业所应用,也吸引越来越多的贡献者。
活跃开源社区
开源是大势所趋。800多Contributor,1723次fork。6000多次PR。社区Maintainer活跃度高,提出的PR很快就有回复
创始人为华人
华人contributor特别多,中文文档资料特别多。加入门槛底,还有新手教程,对于新contributor非常友好。
CI完备
alluxio-bot(PR title)、 AmplabJenkins作为PR builder(License header\Checkstyle\findbugs\test)
Alluxio in JD
Alluxio在京东的应用主要在JDPresto、Kylin、HDFS。本文主要介绍JDPresto在京东的应用。
JDPresto on Alluxio
Alluxio作为可插拔的容错组件应用于京东体系内诸多计算框架。
利用Alluxio优秀的缓存能力提供对ADHOC, 实时流计算天生的支撑,降低集群对于网络消耗的依赖。
JDPresto on Alluxio已经带来了10倍平均性能提升。Alluxio作为可插拔的优化组件,当Alluxio服务不可用时,JDPresto可以直接访问HDFS。我们的工作是扩展Alluxio,增强Alluxio和HDFS的一致性。
Alluxio已经在我们的生产环境运行1年多了。
优势
可插拔
容错
增强本地性
架构和流程介绍
下图可以看出用Alluxio与不用Alluxio的Presto集群增加了隔离性和本地性
下图可以看出Presto会优先读取本地的缓存,如果读取Alluxio异常,则会直接读HDFS
下图是部署图
下图为使用JDPresto、JDPresto on alluxio、 JDPresto混合模式的对比图
下图是测试5次Presto读时间用Alluxio和不用Alluxio的对比
对比测试——sql查询速度
下图是在Presto的交互终端执行sql查询
下图是在Presto的Web界面看到sql的执行情况
通过上边的查询结果可以看出采用Alluxio进行缓存,由于增加了本地性减少网络消耗以及使用内存进行存储减少IO,所以查询sql速度提升显著。需要说明的是采用Alluxio进行缓存,第一次查询需要从底层文件系统读取数据内容并缓存到Alluxio的Worker中,并且当时测试的版本Alluxio为1.4版本,采用的是同步缓存,所以速度反而会慢,1.5版本以后的Alluxio已经采用异步缓存,优化了第一次读取的速度。
性能压测——转发线上一天查询请求
我们开发了性能压测工具,转发线上sql到两个presto集群,一个使用Alluxio,为测试,另一个不使用Alluxio为对照。两个Presto集群在同一个HDFS集群中。
通过上图可以看出,红色线(使用Alluxio)在40分钟时已经执行完所有sql,而绿色线在60分钟也没有执行完。
我们的工作
为了让Alluxio在JD更好的发挥其作用,我们在Alluxio、Presto以及on Yarn方面做的工作如下图所示:
京东的贡献
ItemCount
PMC1
Contributor6
PR53
Merged PR50
Merged Commit221
Additions / Deletions+4153 / -2254
新界面
基于ui-grid
支持排序、分页、过滤
可以指定位置显示文件或文件夹内容
很遗憾,新界面Patch没有合并到主分支了,需要的话,可以自行打PATCH。ALLUXIO-2557
一致性检查
启动检查:在启动的时候进行一致性检查,将不一致的文件或文件夹重新加载元数据
每次访问都检查:每次访问文件或文件夹时,都会与底层文件系统进行比对,不一致则更新元数据。已经演变成目前的指纹(FingerPrint)功能。
基于水位的空间置换策略
当Alluxio存储空间不足时,需要采用一定的空间回收策略进行回收。同步回收是旧版的回收实现。它当客户请求比当前在worker上可用空间更多空间时启动回收程序释放足够的空间来满足要求。 这导致许多小的回收尝试,并不高效。而采用基于高低水位的异步空间回收器,当空间空闲达到高水位时,进行空间释放,释放到空间空闲达到低水位时停止释放空间。
JVM暂停监视器
这是一个监视JVM暂停情况的服务。该服务建立一个简单的线程。在此线程中,在循环中运行sleep一段时间方法,如果sleep花费的时间比传递给sleep方法的时间长,就意味着JVM或者宿主机已经出现了停顿处理现象,可能会导致其它问题,如果这种停顿被监测出来达到一定的阈值,线程会打印相应级别的消息。还可以把额外sleep的时间进行metrics统计,外部的监控系统可以监控Alluxio的健康状态以及进行报警。
Shell命令
由于现有的Shell命令不能满足我们的需求,于是改进了现有的命令以及实现了一些新的实用的shell命令。
整合CopyFromLocal、CopyToLocal、Cp
ls命令增加 -h 参数显示带单位的文件大小,默认显示字节大小,与标准的文件系统命令实用习惯一致。
修改bin/alluxio,支持-debug参数开启的时候,增加ALLUXIO_USER_DEBUG_JAVA_OPTS环境变量的值到JVM参数中,该环境变量可以定位成远程调试参数,例如ALLUXIO_SHELL_DEBUG_JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5603"
修改load命令,增加--local参数,如果该文件已经存在在Alluxio中,设置了--local选项,并且有本地worker,则数据将移动到该worker上。原有的逻辑如果其它worker已经存在该文件,则不会将文件load在本地worker。
修改rm命令,增加-alluxioOnly参数只删除Alluxio的元数据和缓存数据,并不会删除底层文件系统内容。
动态修改日志级别
日志库将日志分为5 个级别,分别为DEBUG、INFO、WARN、ERROR 和FATAL。这5 个级别对应的日志信息重要程度不同,它们的重要程度由低到高依次为DEBUG < INFO < WARN < ERROR < FATAL。日志输出规则为:只输出级别不低于设定级别的日志信息。比如,级别设定为INFO,则INFO、WARN、ERROR和FATAL 级别的日志信息都会被输出,但级别比INFO 低的DEBUG 则不会被输出。
我们有时希望在不重启服务的情况下动态设置某个Logger的日志级别。
所以,我们实现了Alluxio shell的一个logLevel命令,可以在特定实例上获取或更改特定类的日志级别。
语法是alluxio logLevel --logName = NAME [--target = ] [--level = LEVEL],其中logName表示日志的名称,target列出了需要设定的Alluxio master或worker列表 。 如果提供了参数level,则命令更改日志级别,否则将获取并显示当前日志级别。
例如,以下命令将foo.Bar类的日志级别在master和192.168.100.100:30000的worker上设置为调试级别。
alluxio logLevel --loggerName = foo.Bar --target = master,192.168.100.100:30000--level = DEBUG
1
以下命令获取foo.Bar类的所有worker的日志级别
alluxio logLevel --loggerName = foo.Bar --target = workers
1
问题修复
修改了若干问题,不一一列举。
未来工作
跟踪Alluxio社区PATCH,向Alluxio提高代码
完善压测工具
完善监控和预警
稳定性提升
可调试支持
扩展其他框架使用
Fix Bug