Hadoop Metrics体系架构分析

本文基于Hadoop 0.20.XX版本分析,和现在的Metrics2稍有不同

1:概述

Hadoop Metrics用来统计集群运行数据,比如接口调用次数,响应时间,队列长度等等,现阶段(0.19版本)支持为数不多的几个层级的数据,分别是dfs,jvm,rpc,mepred等。这些数据收集之后可以sink(通过context)到不同的目的地,比如文件,ganglia,等,也可以自己实现一个context去sink这些数据到你指定的地方。
2:架构
基本上由四个部分构成:
1、context,context是用来sink收集的数据的。而所有需要sink的数据存放在context内的一个map来保存所有put进来的metricsRecord中,然后startmonitor之后启动一个timer来定时将map中所有的record通过调用update函数来将调用context实现类的emitRecords发送出去。
    • context一般不直接实例化,而是从ContextFactory中get出来,首先ContextFactory的实例通过静态方法getFactory()来实例化,在getFactory()的实例化过程中,会读取hadoop-metrics.properties配置,然后依据传入的context名在配置中找到对应的构建方法进行构建,构建完了之后,立即进行初始化。
    MetricsUtil类负责上从ContextFactory实例中获取context实例,并且startmonitor。在startmonitor中启动一个timer,这个timer定时类里边,首先调用updater.doUpdates(),然后调用emitRecords();将context中的所有metricsRecord全部通过调用各个context的emitRecord->emitMetrics发送出去
    • 从上面也能看出一个context中包含有多个updater(通过Set<Updater>来保存,在updater构造函数中将自己注册到相应的context中),也包含多个Record(通过Map<String,RecordMap> bufferedData->RecordMap extends HashMap<TagMap,MetricMap>->TagMap extends TreeMap<String,Object> : MetricMap extends TreeMap<String,Number>)
    • 现有的context包括Filesystem,Ganglia,Nullcontext,当然也可以自己实现一个来达到自己的目的
    • 收集到自己所有的数据之后,还需要到hadoop-metrics.properties中去配置一个context,然后让数据(Record在构建函数中绑定context)随这个context而sink出去。
    • ganglia中,每个图的命名由contextname.recordname.metricsname组成
2、metricsRecord可以看成一个map容器,内面存放了各种string:number的刻度值,作为一个信息的载体被context发送出去
    • 数据存放在Map<String,MetricValue> metricTable结构,MetricValue保存数值型数据,并且标识出该数据是绝对值还是相对值
    • 比较操蛋的是,Record中不会保留过去的数值,只保留最近一次数据(即使是相对数据),所以Record中有个update方法,在这个方法内调用context的update方法,Record中的数值更新到context中对应的Record中去(相对值则会加上context中的老数据)
    • 每个Record都有一个RecordName,所以context中即使有多个RecordMap也能通过名字表示出来,然后存放到bufferData中去。
    • 在构造函数中,每个Record绑定一个context,通过context将数据sink出去。
3、Updater这个是重头戏,如果要实现自己的收据收集,这个是比不可少的。updater的本义就是为了将过程中收集的数据更新到update对应的Record中。然后在调用Record的update(内部调context的update,见前述)将数据更新到context的Recordmap中。
    • 这个类目的是为了将过程中收集数据更新到信息载体中去,准备发布了,但是谁来发起这个更新呢,如前所述是由context中的timer定时调用的,先更新,后sink。
    • 在构造函数中首先获取对应的context,然后创建一个Record(同时将该Record加入到context的Recordmap中去),最后将自己注册到context中。
    • 有一个结构为Map<String, MetricsBase> metricsList的来保存这个updater类中所有的统计数据,在update方法中将metricList(MetricsRegistry registry )中所有的metrics更新到Record中去。
    • 基本上每一类需要统计的数据都有一个对应的updater来完成上述的操作
    • 在程序运行过程中,需要进行数据统计的时候,就会从updater的
    • metrics可以动态添加(RpcMetrics)到metricList(MetricsRegistry registry )中,也可以预先定义好(NamenodeMtrics),视场景而定。
4、MetricsBase,基类,过程中收集数据的时候,依赖这个类来做数据收集,现阶段有三个类型的数据收集
    • 时间累积型,一直做累加操作
    • 时间值型,只看某个时间的数据值,不叠加任何数据
    • 时间率型,时间作为分母,如速率,平均响应时间等。
 
3:叠加所有的东西
    1. 数据需要统计数据时,首先实现好updater,在update中定义需要收集的数据(metircList),最后数据sink的地方(context),这些数据的名称及存放载体(MetricRecord)等等。 
    2. 在程序需要数据统计的地方,通过update来获取对应统计项[通过mericsList(动态),或预先定义的名字(静态)]进行数据叠加或者统计
    3. 通过context的定时程序将Updater中数据定时sink出去。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Hadoop体系架构是一个分布式系统,包括HDFS、MapReduce、YARN等组件。其中,HDFS是Hadoop分布式文件系统,是Hadoop体系架构中的核心组件之一。在使用Hadoop体系架构时,安全问题是非常重要的,特别是围绕HDFS的安全问题。以下是对HDFS安全问题进行分析: 1. 访问控制:HDFS默认情况下没有访问控制,任何人都可以访问其中的文件。因此,需要对HDFS进行访问控制,限制只有授权用户才能访问HDFS中的文件。可以使用Kerberos认证,将用户身份验证和授权结合起来,确保只有授权用户才能访问HDFS。 2. 数据加密:HDFS中的数据在传输和存储过程中需要进行加密,以保护数据的机密性。可以使用SSL/TLS协议对数据进行加密,确保数据传输过程中不会被窃听或篡改。同时,还可以使用AES或DES等加密算法对数据进行加密,确保数据在存储过程中不会被非法访问。 3. 安全审计:HDFS中的文件访问和操作都需要进行审计,以便及时发现安全问题。可以使用Hadoop审计日志,记录所有的文件访问和操作,包括用户身份、时间、访问方式等信息,以便对HDFS进行安全审计。 4. 防止拒绝服务攻击:HDFS中的数据节点可以被攻击者利用进行拒绝服务攻击,导致HDFS无法正常工作。因此,需要对HDFS进行防火墙设置,限制对HDFS的访问,并使用入侵检测系统对HDFS进行实时监控,及时发现和阻止攻击行为。 总之,HDFS作为Hadoop体系架构的核心组件,安全问题是非常重要的。需要对HDFS进行访问控制、数据加密、安全审计和防止拒绝服务攻击等措施,确保HDFS的安全性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值