hdfs元数据实时采集

这篇具有很好参考价值的文章主要介绍了hdfs元数据实时采集。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、背景及问题

0.Hdfs元数据管理

hdfs元数据,hdfs,hadoop,大数据

 

1.背景介绍

当前在数据资产管理平台上,需要展示每张hive表及分区的热力情况(文件数、存储量、更新时间等信息)。目前热力数据包含两部分内容:热力元数据和审计日志,其中审计日志可以直接消费kafka得到,而热力元数据暂时没有可以直接获取的地方,需要我们这边主动采集。

目前已经完成一版采集方案,为离线定时同步采集(T+1),因实时性不满足需求,所以需要再寻找更加实时的采集方案。

2.面临的问题与挑战

问题与挑战:

量大
(1) 集群的目录和文件数(节点)多,Top20的集群目录和文件数均上亿(大部分在1-3亿个目录和文件),对存储有很大的挑战

(2)EditLog量大,Top20集群的EditLog的qps均在100以上,部分集群的qps在1000以上,对处理有很大的挑战

顺序性依赖
EditLog的日志处理逻辑需要依赖顺序,即一条消息处理完成,才能处理下一条消息,因此无法并行处理EditLog,只能串行处理,这就导致无法通过增加机器或cpu来提高处理能力。

近实时
业务上需要近实时的收集数据,延迟不能太大,目前可接受分钟级别的延迟。

二、解决思路及技术选型

1.探索的方案及遇到的问题

方案

方案描述

方案优势

方案问题

备注

离线同步(T+1) 通过每天拉取一次FsImage,解析FsImage,得到FsImage生成时的Hdfs集群情况信息 方案实现简单,目前平台已实现并将结果写入到hive表中,我们只需直接读取hive表即可

1.方案延迟大,无法满足实时性需求

2.不同集群的FsImage生成时间差距较大

基于内存的实时同步方案(nna)
 
对于每个集群,部署一个特殊的NameNode节点,此节点不参与集群事务性的操作,只是进行元数据收集工作,元数据存储到内存中 可以实现实时采集

1.消耗的内存资源非常大,每个Hdfs集群均需要部署一台分析机器,并且元数据均存储在内存中,对于Top20的集群,每台机器的内存均需要上百G。

2.后期很难维护,公司现有八十多个Hdfs集群,就意味着我们也要申请八十多个机器与其对应

因资源问题,此方案pass
基于ElasticSearch的实时同步方案(nna的改版) 与nna类似,对于每个集群,同样部署一个特殊的NameNode节点,但是元数据不存储到内存中,而是存储到ES中 可以节省内存资源

ES性能跟不上,消息处理不过来

因性能问题,此方案pass
基于RocksDB+ElasticSearch的实时同步方案 不再每个集群部署一台机器,而是统一拉取FsImage和EditLog,并且将元数据存储到RocksDB中,来降低内存开销以及提高性能,最终将聚合的结果数据批量写入到ES

1.可以满足近实时采集需求

2.不需要消耗大量的内存

3.可以满足性能要求

方案难度较大,实施过程中遇到很多坑

2.技术选型

(1) 数据存储 -> RocksDB

Hdfs集群元数据量大(上亿数据),性能要求高(每秒顺序读写上千次),内存资源有限。基于以上要求,现有的大部分数据库都很难满足,尤其是有网络开销的数据库,很难达到性能要求,而内存资源又有限,因此最好的选择是基于磁盘的单机数据库。

RocksDB 是由 Facebook 基于 LevelDB 开发的一款提供键值存储与读写功能的 LSM-tree 架构引擎。用户写入的键值对会先写入磁盘上的 WAL (Write Ahead Log),然后再写入内存中的跳表(SkipList,这部分结构又被称作 MemTable)。LSM-tree 引擎由于将用户的随机修改(插入)转化为了对 WAL 文件的顺序写,因此具有比 B 树类存储引擎更高的写吞吐。

(2) 数据序列化 -> Protobuf

因Hdfs集群元数据量大,因此即使存储到磁盘上,存储开销依然很大,并且RocksDB为了提高写入和查询性能,会将部分数据放到内存中,因此单条数据越小,对内存和磁盘的开销越小,因此需要找一个在性能和序列化后数据量均较好的序列化方案。

Protobuf具备了优秀的序列化协议的所需的众多典型特征:

1、标准的IDL和IDL编译器,这使得其对工程师非常友好。

2、序列化数据非常简洁,紧凑,与XML相比,其序列化之后的数据量约为1/3到1/10。

3、解析速度非常快,比对应的XML快约20-100倍。

4、提供了非常友好的动态库,使用非常简介,反序列化只需要一行代码。

(3) 状态同步 -> Zookeeper

方案在实现过程中,会涉及到producer、consumer、loader三种角色,不同角色之间会有协同工作(例如loader下载完FsImage后,producer才能开始拉取EditLog等),如何协同不同角色?此处选择用Zookeeper的监听机制实现,当一个角色完成事件后,另一个角色可以立即监听到并做后续事情。

三、方案介绍

1.整体设计

hdfs元数据,hdfs,hadoop,大数据

 

FsImage Loader:从Hdfs上Download FsImage到本地,解析后进行后续处理,写入RocksDB
EditLog Loader:每隔1分钟拉取一次EditLog,写入kafka
EditLog Consumer:消费kafka中的EditLog消息,写入RocksDB,及聚合后写入ES
状态同步:同步FsImage Loader、EditLog Loader、EditLog Consumer三者之间的协同
2.详细设计

总体流程如下

hdfs元数据,hdfs,hadoop,大数据

 

hdfs内部的元数据同步流程如下所示,以mkdir为例

hdfs元数据,hdfs,hadoop,大数据

 

从图中可以看到元数据会写一份到JournalNode,同时standy的节点可以访问这部分数据,拉取元数据主要就是根据这部分来进行的。

(1)FSImage加载及解析流程

先下载faimage文件,然后根据这个文件启动一个FsNameSystem,然后加载数据。原来的数据是加载到内存中的,是一个树,如下所示:

hdfs元数据,hdfs,hadoop,大数据

 

每个节点都会有个节点id,现在主要就是加载了file和Directory,其他的没怎么加载,暂时没有发现问题,后面发现问题了再改。为了少占用内存,我们是加载到rocksDb中的,其中最重要的就是treeIndex和detail两个库,里面节点的定位是以节点id来定位的。加载过程中会涉及到启停kafka的consumer和producer。这个过程会写es和rocksDb

(2)EditLog加载及解析流程

editlog加载是采用定期拉取远程Journal的editlog文件方式,一旦producer启动起来后,就会根据zk中的txid去Journal node拉取editlog文件,并将下一个txid写入到zk中,拉取的数据经过处理后会发送到kafka。

consumer端获取到数据后处理,这里获取的是op,op不会带节点的id,里面都是些绝对路径,所以就借用到了之前加载时库中的节点id,通过路径解析出id,然后进行目录的聚合等操作,然后再写会rocksDb,并写出到es。

(3)状态含义及管理

现在状态是各个角色分开管理的,loader、consumer、producer。主要是借用的zk的节点监控来回调触发各种操作的。虽然比之前用mysql来管理要方便了,但仍然感觉有些繁杂,后面可以优化成RPC,和选主一并实现。

(4)RocksDB及ES存储结构

RocksDB

RocksDb数据存储到本地磁盘中,通过不同的目录,存储不同的数据(此处称之为库),目前对于一个集群,会创建4个库:detail、treeIndex、txidIdempotent、middleData,每个库(目录)下存储RocksDB的数据文件,存储位置及结构如下:

hdfs元数据,hdfs,hadoop,大数据

 

detail库:key是节点id(Long类型,Hdfs集群生成),value是由type、fileSize等组成的信息,通过Protobuf序列化后存储。detail库中每条数据存储一个节点的明细信息,包括文件和目录。

treeIndex库:key是parentId|type|curPath,value是节点id,根据treeIndex库,可以快速的由Hdfs目录或文件全路径(path)找到对应的id。下面会详细介绍此索引。

txidIdempotent库:用于幂等判断,因为方案中使用了kafka,实现消息的ExactlyOnce比较难,因此此处加了幂等判断,即使用kafka AtLeastOnce。幂等库key是txid(hdfs集群生成),value为1,代表已处理过。

middleData库:为FsImage加载过程中存储临时数据使用,FsImage加载完成后删除。

ElasticSearch

ElasticSearch存储最终的结果数据,用于DAM后端查询使用。当前是每个集群创建一个索引,索引ID由hdfs的path拼接而成。FsImage和EditLog的数据,在处理完成后,经过聚合,得到对应Path的数据,先在内存中缓存一段时间(10s),然后批量写入到ElasticSearch中。

(5)树形结构索引

由上文可知,处理的数据均存储到detail库中,但detail库的key是id,而很多EditLog消息中并不会有id(例如OP_TIMES、RENAME等),这就需要根据Path能够快速获取到id,而treeIndex库就是为了此目的。

索引结构:

hdfs元数据,hdfs,hadoop,大数据

 

上图为索引结构示例图,索引数据最终以KV结构存储到rocksdb中,对于每条editlog中的path,通过索引可以查询到对应id,从而可以从detail库中取出具体数据进行操作。

(6)增量计算及数据聚合

1、新增文件op(op_close):detail插入一条,同时treeIndex也加入一条,同时对其所有的递归父目录,修改文件数和文件num

2、删除文件:和新增类似

3、rename文件或者目录:先删除再新增,是目录时需要递归调用

(7)数据序列化及反序列化

序列化和反序列化使用Protobuf,先写一个proto文件,然后安装一个proto程序生成一个java类,然后就可以调用里面得方法对java对象进行序列化和反序列化了
 文章来源地址https://www.toymoban.com/news/detail-701204.html

到了这里,关于hdfs元数据实时采集的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 大数据开发之Hadoop(HDFS)

    1、HDFS产生背景 随着数据量越来越大,在一个操作系统存不下所有的数据,那么就分配到更多的操作系统管理的磁盘中,但是不方便管理和维护,迫切需要一种系统来管理多台机器上的文件,这就是分布式文件管理系统。HDFS只是分布式文件管理系统中的一种。 2、HDFS定义 H

    2024年01月20日
    浏览(56)
  • Hadoop理论及实践-HDFS读写数据流程(参考Hadoop官网)

    主节点和副本节点通常指的是Hadoop分布式文件系统(HDFS)中的NameNode和DataNode。 NameNode(主节点):NameNode是Hadoop集群中的一个核心组件,它负责管理文件系统的命名空间和元数据。它记录了文件的目录结构、文件的块分配信息以及每个文件块所在的DataNode等关键信息。NameNo

    2024年02月14日
    浏览(45)
  • HDFS 跨集群数据同步(hive,hadoop)

    两个不同的HDFS 集群数据迁移( A集群的数据 - B 集群) 采用的是 SHELL 脚本  按表进行; 日期分区进行; #!/bin/bash ##################### #创建人:DZH #创建日期: 2020-04 #内容: 数据迁移 ##################### ##################################### [ \\\"$#\\\" -ne 0 ] FILE=$1 path=$(cd `dirname $0`; pwd) ############## 获取执

    2024年04月27日
    浏览(56)
  • 0201hdfs集群部署-hadoop-大数据学习

    下面我们配置下单namenode节点hadoop集群,使用vmware虚拟机环境搭建。vmware虚拟机的配置,在下面链接2有,或者自行查阅文档。hadoop安装包可到官网下载,当前相关软件环境如下: 软件 版本 说明 hadoop 3.3.4 jar包 vmware 15.5 虚拟机 centos 7.6 服务器操作系统 xshell 6 远程连接 jdk 1.8

    2024年02月11日
    浏览(45)
  • 大数据技术之Hadoop(HDFS)——超详细

    1.1 HDFS产出背景及定义 1)HDFS产生背景 先给大家介绍一下什么叫HDFS,我们生活在信息爆炸的时代,随着数据量越来越大,在一个操作系统存不下所有的数据,那么就分配到更多的操作系统管理的磁盘中,但是不方便管理和维护,迫切需要一种系统来管理多台机器上的文件,这

    2024年02月03日
    浏览(53)
  • 尚硅谷大数据技术Hadoop教程-笔记03【Hadoop-HDFS】

    视频地址: 尚硅谷大数据Hadoop教程(Hadoop 3.x安装搭建到集群调优) 尚硅谷大数据技术Hadoop教程-笔记01【大数据概论】 尚硅谷大数据技术Hadoop教程-笔记02【Hadoop-入门】 尚硅谷大数据技术Hadoop教程-笔记03【Hadoop-HDFS】 尚硅谷大数据技术Hadoop教程-笔记04【Hadoop-MapReduce】 尚硅谷

    2023年04月08日
    浏览(93)
  • Hadoop HDFS:海量数据的存储解决方案

    在大数据时代,数据的存储与处理成为了业界面临的一大挑战。Hadoop的分布式文件系统(Hadoop Distributed File System,简称HDFS)作为一个高可靠性、高扩展性的文件系统,提供了处理海量数据的有效解决方案。本文将深入探讨HDFS的设计原理、架构组成、核心功能以及实际应用场

    2024年04月23日
    浏览(41)
  • hadoop之hdfs生产数据块损坏修复方法

    1、手动修复 检查数据块丢失情况 hdfs fsck / 修复指定路径的hdfs文件,尝试多次 hdfs debug recoverLease -path 文件位置 -retries 重复次数 删除所有损坏的块的数据文件 hdfs fsck / -delete 2、自动修复 hdfs会自动修复损坏的数据块,当数据块损坏后, DN节点执行directoryscan(datanode进行内村和

    2023年04月11日
    浏览(61)
  • 一百零八、Kettle采集Kafka数据到HDFS(踩坑,亲测有效)

    Kafka到HDFS,除了用Kafka API和flume之外,还可以用kettle,最大优点是不用写代码! 版本:Kettle版本:8.2、Hadoop版本:3.1.3 前提:    详情请看鄙人的一百零一、Kettle8.2.0连接Hive3.1.2(踩坑,亲测有效) http://t.csdn.cn/mWfOC http://t.csdn.cn/mWfOC 前提一、Hadoop系列配置文件已复制到kettle路径

    2024年02月15日
    浏览(36)
  • 0202hdfs的shell操作-hadoop-大数据学习

    以下命令执行默认配置了hadoop的环境变量,且使用新命令。 一键启停脚本 独立进程启停 2.1 HDFS文件系统基本信息 HDFS作为分布式存储的文件系统,有其对数据的路径表达式。如果熟悉Linux文件系统,可以对比学习。 HDFS同Linux系统一样,均是以/作为根目录的组织形式 如何区分

    2024年02月10日
    浏览(51)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包