Android路上的人-CSDN博客

原创 Alluxio与底层存储系统之间的元数据同步机制

文章目录前言Alluxio内部的元数据同步行为基于给定时间，Path粒度的UFS Status Cache前言Alluxio作为一套构建于底层存储系统之上的中间层，它必不可少的会涉及到于底层系统之间metadata之间的同步问题。外部client请求访问Alluxio系统，然后Alluxio再从底层系统中(为称呼方便，后面都简称为Underlying FileSystem, UFS)查询真实的元数据信息，然后再返回给client。当然为了减少对于UFS的压力，我们当然不会每次都去查UFS。本文我们来聊

2020-08-11 23:44:42 2280

原创 Hadoop服务配置热替换框架的设计实现

文章目录前言服务热替换更新需要解决的问题点前言在分布式系统中，根据不同的运行情况进行服务配置项的更新修改，重启是一件司空见惯的事情了。但是如果说需要重启的服务所需要的cost非常高的时候，配置更新可能就不能做出频繁非常高的操作行为了。比如某些分布式存储系统比如HDFS NameNode重启一次，要load元数据这样的过程，要花费小时级别的启动时间，当其内部存储了亿级别量级的文件数的时候。那很显然对于这种高cost重启的服务来说，我们不能每次依赖重启做快速的配置更新，使得系统服务能使用新的配置值进行服务

2020-08-08 17:11:39 1048

原创 Scheme覆盖式的ViewFileSystem设计实现

文章目录前言Scheme覆盖式的ViewFileSystemViewFileSystemOverloadScheme的实现引用前言在多HDFS集群模式中，我们为了使得多集群对于client端的透明使用，一般可以采用的是ViewFs的方案。当然后来社区实现的HDFS RBF功能无疑是更佳的选择，但是在RBF出现，ViewFs实现的更早且方案更为简单，因此ViewFs是通过在client端实现的一个请求解析以及转发。但是本文我们来讨论一个ViewFs使用的痛点问题：ViewFs高成本的配置更新问题以及更为t

2020-08-02 17:40:30 931 1

原创关于小概率锁碰撞的细粒度锁方案

文章目录前言锁的细粒度级别基于小概率锁碰撞的lock pool实现方案前言在分布式系统中，我们常常使用锁来保证操作的一致性控制。但是锁的存在则意味着必然存在着锁竞争的情况。而且这种竞争会随着外部请求量的激增而变得更为的激烈。因此我们改进的一个方向是改变锁的粗细力度，从较为简单的粗粒度锁变为更细粒度的锁。细粒度锁相较于粗粒度锁来说，毫无疑问，它能减缓激烈的锁竞争的情情况，但是它在实现上会增加额外的复杂度。这个很好理解，在server端原先只需要维护一把锁就行了，现在则要可能维护一定规模量的小锁。本文笔者

2020-07-23 00:11:24 1159 1

原创记录一次HDFS RPC返回Response过程慢导致的性能问题

文章目录前言NameNode请求处理慢的场景RPC返回response的Handler处理慢问题HDFS RPC call异步response改造前言众所周知，在HDFS NameNode中，一直都有一个老生常谈的难题就是其扩展性的问题，而很多时候我们说HDFS的扩展性问题时我们很多时候都在谈的点在于里面全局锁的问题。一个很通常的场景是NameNode在高并发请求处理下存在着激烈的锁竞争，进而使得用户感觉到他们的请求被处理的有点慢。不过本文笔者不聊关于全局锁优化的问题，最近笔者遇到了另外一种NameN

2020-07-18 11:21:24 29720 1

原创 Alluxio基于冷热数据分离的元数据管理策略

文章目录前言Alluxio内部元数据管理架构Alluxio的支持异步写出功能的自定义Cache实现前言上篇文章末尾，笔者聊到了一种叫做分层元数据管理模式。它主张的思想是将元数据进行分级对待，比如Cache+Persist层2种，cache拿来用于热点数据的访问，而persist层即持久层则存储那些冷的访问不频繁的数据，以此达到元数据的强扩展性和一个较好的访问性能。当今存储系统Alluxio就是使用了这种分层级对待的元数据管理模式。本文我们就来简单聊聊Alluxio的tier layer的元数据管理。

2020-07-05 15:10:25 1982 1

原创存储系统元数据管理演变升级

文章目录前言初代元数据管理内存式元数据管理分区元数据管理分层级元数据管理引用前言我们知道在一个存储系统中，不光光只有它所存储的数据文件重要，它的存储系统的元数据管理同样十分的重要。因为涉及到存储系统数据访问操作时，会经过存储系统元数据的查询或更新操作，如果元数据这边的操作出现性能瓶颈，同样会导致用户访问数据的行为出现缓慢的情况。本文我们来聊聊存储系统一般是如何做高效的元数据管理的，这里面会涉及到多种不同的元数据管理方式。初代元数据管理首先我们来看最简单原始的初代存储系统元数据管理方式，此时元数据

2020-07-02 23:48:25 947 1

原创 HDFS Rolling Upgrade的实现要点分析

文章目录前言HDFS NameNode端针对Rolling Upgrade的调整HDFS DataNode端针对Rolling Upgrade的调整引用前言我们知道HDFS Rolling Upgrade功能在几年前比较早的时间早已实现，但是我们往往只注意怎么去做HDFS Rolling Upgrade这个事情本身，但是对于HDFS如何实现Rolling Upgrade这个功能可能了解的会比较少。本文笔者来聊聊其中部分要点的设计实现，为了做到Rolling Upgrade的快速和安全性，社区在这块实现

2020-06-28 17:31:02 1402

原创 Ozone的Erasure Coding方案设计

文章目录前言EC技术以及EC下的存储效率的提升Ozone下的EC方案设计Container Level的EC实现Block Level的EC实现引用前言众所周知，在当下存储系统中为了存储效率的提升，Erasure Coding(纠删码)技术在扮演着一个越来越重要的角色。比如说目前Hadoop HDFS中，它就已经能够支持EC功能了。在EC模式下，HDFS 可以不必存储多打3份这样的冗余副本数来为了容灾保护。存储效率的提高意味着存储海量数据所需要的存储节点资源的减少。不过本文并不是聊HDFS的EC实现的

2020-06-25 16:10:45 1114

原创关于分布式系统升级，你需要了解的几点

文章目录前言分布式系统升级的状态转化关于Upgrade需要注意的点关于Downgrade需要注意的点引用前言对于一个系统来说，进行定期的升级维护是一件比较常见的事情。但是对于复杂分布式系统的升级，系统管理员系统考虑更多的因素来做升级这个事情。同时对于分布式系统开发者来说，他们也要考虑系统升级的前后兼容性，避免升级后部分老的功能无法使用或是升级回退后之前写出的数据无法使用等等类似的情况。本文笔者来简单聊聊关于分布式系统的升级，你需要了解和注意的那些事。分布式系统升级的状态转化在介绍本文主要内容前，

2020-06-13 11:04:49 1692

原创基于RPC Call延时返回的HDFS异步editlog原理

文章目录前言现有HDFS的RPC正常请求处理前言前面文章笔者介绍过Hadoop社区为了增加内部RPC的throughput，通过延时返回response的调整来提早释放Server端的Handler资源，以此尽可能的把Handler的处理能力用在真正的RPC请求上。HDFS目前所使用的异步editlog机制正是使用了这个优化改进。这里所说的HDFS异步editlog写出并不是大家所简单的认为NameNode完全异步化写出editlog到其JournalNode服务中，然后直接返回结果给client。那

2020-06-04 23:43:07 1131 1

原创 HDFS和Ozone的数据删除原理对比思考

文章目录前言现有HDFS删除操作的性能问题HDFS删除操作的brainstorm改进想法相关设计：Ozone系统内的删除操作处理前言前段时间笔者一直在折腾HDFS大目录删除的性能问题，也尝试了很多不同的方案来降低大目录删除所带来的性能影响，包括改INodeDirectly内部child list结构，或者是在Snapshot层面做改进优化等等（详见此文章：HDFS大目录文件删除方案的实践思考）。不过后续笔者在对比HDFS的删除操作和新一代存储Ozone系统内部的删除操作时，发现二者还是存在不少区别的，

2020-05-31 17:17:59 1274 1

原创提高RPC Server throughput的请求延时回复处理

文章目录前言前言在一套完整的分布式系统中，client端向server端发起一个请求，然后client等待此请求被server端处理完毕，然后接受到serve的返回结果。自此一个请求就算作是被处理完了。这种block等待处理结果的请求处理行为在我们日常的系统中十分的常见。但是这种处理方式的一个明显弊端是，未处理完成的请求势必会占住server端的处理资源。因此一般常见的改进做法是提高server端的Handler数量，来提高服务端的请求并发处理能力，这种做法是比较简单直接的。但其实这里还有另外一个方向

2020-05-24 23:40:18 957

原创分布式系统内部RetryCache机制

前言在分布式系统的运行过程中，出现网络不稳定（例如网络超时)导致的client请求回复超时是时有发生的事。在这种低概率发生的情况下时，client端其实是无法感知它的请求是不是真正的被处理了，它只能是基于坏的情况（即请求没被server处理的情况)，然后执行重试操作。问题就出现在这里，对于某些非幂的操作而言，操作重试是会返回不同的结果的。这个时候，其实server端不应该执行client端发起的第二次请求的，假设server已经成功处理了client的第一次请求。本文我们就来聊聊针对非幂等操作处理的Re

2020-05-17 10:28:15 959 2

原创 HDFS federation集群间的数据Balance工具方案

文章目录前言粗粒度的federation Balance方案系统化的federation Balance工具方案引用前言在目前单一大HDFS集群越来越无法支撑我们的业务场景时，越来越多的公司开始考虑采用HDFS federation方案来做。这里就自然会衍生出一个问题：新federation出来的Namespace，我如何将数据从原集群（NameNode）同步出来呢？而且在这个过程中，还会有每天增量数据的写入在老集群内。假若只是静态的数据，我们启动一个distcp任务就可以做这部分跨namespace

2020-05-09 11:49:24 1240

空空如也

空空如也