走在前往架构师的路上

文章目录前言HDFS RPC限流方案分级RPC queue的调参分级RPC queue的insight前言在前面的一篇关于分布式集群下的限流方案文章里，笔者阐述了一种在HDFS集群里的RPC限流架构。其间也提到了很多关于分布式限流架构里的关键要素，包括用户区分，分级队列的概念等等。不过上次文章更多偏向于理论原理篇，本文笔者将结合实际生产环境的特点，来给大家讲讲如何真正将限流方案实施到生产集群，并能够达到预期的效果。HDFS RPC限流方案这里要首先聊聊笔者目前集群所将要采用的HDFS RPC限流

前言随着公司业务的发展，我们需要存储越来越庞大的数据来支撑公司业务的发展。这里就涉及到了数据存储能力的问题，需要存储的数据越多，其实意味着我们需要更多的机器来扩增HDFS集群存储的总capacity。但是机器数量的变多另外一方面带来的则是机器费用成本的巨大开销。我们如何在保证机器开销前提下，最大程度提升单机器的存储能力，这个就成为了一个集群维护人员需要思考和解决的问题。鉴于这个出发点，笔者最近在研究调研新一代具有更高存储能力的机型，这期间笔者做了大量的场景设置和性能测试来判断此机型是否能达到集群的要求。

文章目录前言前言在HDFS集群运维过程中，我们经常会遇到机器送修的情况，尤其在集群机器数量比较多的情况，每天因为坏盘或是其它硬件问题导致的机器维修是很常见的。对于集群维护者来说，机器的这种日常损坏我们是无法回避的，我们能做的是如何将这种机器维修的所造成的影响降低到最小。在现有的HDFS中，社区提供了一种叫做Maintenance state的功能来专门处理这种情况的。本文笔者来谈谈这个特殊的功能以及我们内部是如何简化此特性来方便于我们的使用的。Maintenance state DataNode和普

文章目录前言Block access tokenHDFS block access token的原理前言在存储系统中，数据的安全性无疑是十分重要的。在我们常见的文件系统中，最常使用的方式是通过文件目录的权限来做数据访问的控制。在HDFS这样分布式存储系统中，其内部实现同样沿用了这样的方式来做数据访问的控制。但是在HDFS拥有如此海量数据规模的系统中，我们只做文件权限的检查是足够安全的吗？鉴于HDFS的架构设计，权限检查是发生在NameNode端的，这时倘若一个恶意用户绕过了文件权限检查，然后直接访问实

文章目录前言跨区域存储和跨rack存储的区别HDFS跨区域存储实现前言在上篇文章HDFS多rack分布的block placement policy设计实现里，笔者探讨了HDFS数据副本跨多rack分布的新placement方案，以此来提高数据的可用性。因为在日常集群运行过程中，是可能存在因为集群的操作维护导致短时间内一整个rack处于停服务状态的。按照HDFS三副本的存放策略，一整个rack离线意味着2/3的拷贝丢失了，这将极大增加数据不可访问的概率。本文我们来继续深入探讨这一话题，既然数据副本已经能

文章目录前言RBF模式的RPC吞吐量问题原因猜想网络延时的影响Router本身服务处理的影响前言之前笔者介绍过HDFS的RBF方案来解决HDFS NameNode单点瓶颈的问题。目前也是有越来有多的公司采用RBF的方案来做HDFS集群的统一管理。笔者在最近一段时间也是在调研RBF的特性同时也是测测这里面还有没有一些没有被发现的问题。在此期间，我和同事小伙伴发现里面最大的一个问题：上了RBF后，RPC的上限吞吐量比之前直连NN时降了非常之多。之前直连NN测试时，我们可以压到30k+的水准，在RBF模式下

文章目录前言HDFS多rack分布的block placement policy多rack分布的policy实现思路旧block placement的到新block placement的迁移前言众所周知，HDFS拥有3副本来保证其数据的高可用性。而且HDFS对着三个副本的位置放置也是有专心设计的，2个副本放在同一个rack（不同节点），另外一个副本放在另外的一个rack上。在这样的放置策略下，这个副本数据能容忍一个节点的crash甚至是一个rack机器的crash。但这里所提及的"rack“的概念是集

文章目录前言NN refreshNodes的可用性以及效率问题前言我们知道在HDFS里面有，存着一类白名单和黑名单的列表来控制其下允许进行注册的DN节点。这样可以防止一些外部恶意节点注册到我们的NN上来。在HDFS的概念里，这个黑白名单叫做include file和exclude file。在一般情况下，exclude file的使用范围会更管一些，因为DN的decommission下线需要将待下线机器加到此exclude file中，然后再手动执行dfsadmin的refreshNodes命令进行刷

文章目录前言HDFS Multiple Standby的实现要素Multiple Standby实现分析前言HDFS在早期实现HA时，是标准的一主一备的服务模式，主的叫Active NameNode，备的叫Standby NameNode。Standby/Active NN间可以互相切换以此达到服务高可用的目的。但是这种双节点的HA模式是否能够满足更高的高可用性的要求呢?在标准的HA模式下，其实只有1个Standby的NN作为bak来使用。假设在极端情况下，Active和Stanby同时出现crash

文章目录前言Hadoop Client的内部结构组成ClientId和CallIdClient Connection和Connection Call的组织关系Client RPC Call的处理流程相关链接前言对于Hadoop内的RPC处理（比如NameNode里的RPC请求处理），我们往往关注的是实际Server端的RPC处理，但是很少提起对应Client端的行为。Hadoop内部有自己专有的RPC Client实现，本文我们就来说说这个底层RPC Client是如何工作的。这有助于方便了解底层RP

文章目录前言一. Router层面的潜在问题Router的性能测试，对请求延时的影响Router间如何做到本地状态的一致性Router对下游NN的统筹管理前言上篇文章笔者简单介绍了HDFS Federation新方案RBF里的connection管理。RBF虽说在功能上只是帮助client做请求转发的，在角色功能定位上相当于一个代理的角色。但RBF的这个“代理”远比我们平常说的代理服务要复杂许多。RBF的核心服务Router在设计实现上被赋予了远比普通代理服务更为全面，成熟的功能。因此集群维护者需要对

文章目录前言Connection管理的权衡问题RBF的Connection管理前言为了解决HDFS Federation下多集群的维护管理，Hadoop社区实现了Router-Based Federation（HDFS-10467）功能。此功能的强大之处在于它在client和集群NN服务之间新加了一层Router的服务。有了这个Router这个服务后，所有客户端的请求将会由这个Router负责转发给下游的NN节点。这样的话，客户端用户就不需要知道下游有哪些NN节点以及各个NN Namespace里分布

文章目录前言Hadoop Security要解决的问题Hadoop Security三板斧参考资料前言在企业大规模量级的Hadoop集群中，数据的安全性是十分重要的，尤其当集群存储的是一些敏感数据的时候。Hadoop社区在早期release的版本中，并没有完善好其Security部分的功能。但是随着Hadoop系统的不断完善成熟，Security的功能也在不断的完善。那么问题来了，Hadoop的Security到底指的是什么呢？本文笔者来简单聊聊Hadoop Security的三板斧，了解了这三板斧的

文章目录前言Hadoop升级的目标版本的选择Hadoop升级过程需要做的准备工作前言现今Hadoop版本已经release到了Hadoop 3.x版本了，社区迭代更新的速度还是很快的。新的版本相对旧版本来说，能够给我们带来很多益处，诸如新的功能feature，众多bug fix以及一些大的performance的改进。始终维护运行一个陈旧的系统，意味着后期可能会遇到许多许多社区已fix的bug，这个将会消耗掉系统管理员日常相当多的工作时间。尤其当我们维护的是一个具有庞大规模的分布式系统。所以对于复杂系

文章目录前言HDFS Standby Read的背景及功能要求Standby NameNode一致性读的控制实现原理分析代码分析流程分析图参考链接前言HDFS有着一套十分成熟的HA的机制来保证其服务的高可用性。在HA模式下，分别对应有Active和Standby NameNode的服务。Active NameNode用于提供对外数据服务，而Standby NameNode则负责做checkpoint的工作以及随时准备接替变成Active NameNode的角色，假设说当前Active NameNode

文章目录前言背景问题Snapshot的清理Snapshot NPE异常代码层面的分析线下Snapshot问题恢复失败HDFS内部代码改动的重新梳理分析setTimes忽略snapshot diff更新的改动总结参考资料前言众所周知，HDFS有一个十分有用的Snapshot的功能，可以用来保护数据被误删除的情况。可能有人会说了，数据被删除了，我难道不可以从trash目录里把数据再恢复回去吗？HDFS的Snapshot和我们平常说的数据删除进trash目录不太一样，HDFS删除操作进trash目录是一个延

前言在上篇文章（一次HDFS JournalNode transaction lag问题分析排查）中，笔者详细地讲述了一次HDFS JN lag延时问题的分析排查，在文中结尾笔者提到了问题的root cause是因为部署在JN同节点上的RM traffic陡增造成的JN lag影响。不过笔者当时只是发现了与RM traffic陡增的可能因素，并未进一步分析这些增加的RM traffic的真正来源。在后续的时间里，我们对这些RM traffic的组成部分以及为什么做了更加进一步的分析，最终真正找到了问题的

文章目录前言背景问题追踪排查分析排查一：JN服务本身问题排查二：NN 服务问题排查三：JN机器硬件层面问题推论四：JN受所在机器其它服务的影响总结前言众所周知，在HDFS集群中，NameNode服务是其中的核心服务。NameNode的性能处理效率的高低直接影响着其对外提供的服务能力。鉴于过往笔者已经写过诸多NameNode优化系列的文章，本文笔者来聊聊另外与NameNode相关的服务JournalNode（简称JN）服务。JournalNode是在HDFS HA模式下用来做共享editlog的存储的。

文章目录前言NameNode fsimage corrupt场景NameNode fsimage corrupt解决办法NN fsimage corrupt的重新行为参考链接前言在如今很多用户使用HDFS做为大数据的底层存储时，我们除了关心HDFS的处理性能外，我们经常还需要关注其中数据高可用的情况，例如不能出现数据损坏的情况，比如missing block，或者文件block corrupt的情况。但是其中我们忽略掉了一种最为极端同时也是最为棘手的情况：HDFS NameNode fsimage文件

文章目录前言HDFS元数据快速膨胀带来的性能瓶颈问题超大规模数据迁移所面临的挑战和困难DistCp的全面优化提升前言前面时间笔者曾写过一篇关于利用HDFS fastcopy功能来加速DistCp数据拷贝效率的文章(Distcp结合HDFS Fastcopy的性能改造提升)，以及提到了现有DistCp在数据切分时候的一些问题(聊聊Hadoop DistCp的数据切分处理方式)，会导致长尾任务的出现等等。其实在后续的测试过程中，我们还发现并解决了许多大大小小的坑，使得我们整体数据拷贝的耗时达到一个相对短的

文章目录前言基于文件数/文件Size的数据切分方式前言在如今数据使用场景越来越多的环境下，如何对数据做到更准确，更高效的处理无疑是我们开发者所重点关注以及所期望达成的目标。说到数据的处理，在当今成熟的分布式系统下，我们已经能够达到比较高效的数据并行处理能力了。但是这并不意味着说对此我们没有别的改善空间的余地了。在数据的并行处理过程中，不是所有情况我们都能保证每个并行处理任务都能按照预期顺利执行，中间就可能出现长尾任务现象。这里笔者想抛出的一个关键词：数据切分。在数据切分不均匀的情况下，是极有可能出现任

文章目录前言HDFS的fastcopyDistcp工具支持fastcopy的改造前言在HDFS中，我们经常会碰到跨集群数据拷贝的场景，例如某些任务数据结果计算生成，然后问你启动任务把结果数据导出到另外一个集群中以作后续的分析等这样的用途。Hadoop作为一套成熟完善的系统，也为我们提供了专门的拷贝工具，Distcp，全称Distributed copy，意为分布式的拷贝。说到Distcp工具本身，很多同学估计不会陌生，不过本文笔者来聊聊Distcp基于HDFS fastcopy原理下的性能提升改造。在

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

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

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

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

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

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

文章目录前言Nfly link模式的由来前言在多集群模式下，为了保证数据的一定冗余性要求，我们有时会跨集群或跨data center去备份一些重要的数据。这样可以避免某天一旦一个cluster或者data center处于不可用状态时，从而影响集群正常的数据服务。如果在不额外实现此功能代码的情况下，我们可以采用简单直接的Distcp工具来做集群间的数据拷贝。不过这种方式无法做到实时的数据re...

文章目录前言Hadoop ViewFs的问题痛点Hadoop ViewFs的重载hdfs schema方式ViewFs的mount point中心化管理问题引用前言在大数据时代，随着业务的迅速扩张，很多大公司往往内部会有多cluster模式来支撑其内部的数据体量。在这期间就会涉及到一个多集群管理协调的问题，比如典型的HDFS的多集群管理。社区在早期实现的ViewFs以及后来的Router-b...

文章目录前言HDFS Block副本storage location的移除逻辑HDFS Block的last stored location的优化HDFS Missing Block lastStoredLocationd的测试前言在存储系统中，数据的安全性无疑是最top priority的事情，因此当数据发生丢失的时候，如何快速找到这些数据的位置并且快速地对他们进行恢复是最最要紧的事情。本...

文章目录前言HDFS DFSClient现有DeadNode监测DFSClient共享DeadNode的监测和恢复引用前言在大规模集群中，节点挂掉的现象是十分常见。当节点挂掉的时候，上面所跑的任务或者发送到这个节点的请求将会失败。按照分布式系统的正常处理方法，它会选择另外的节点进行重新的数据请求。这种重试机制在一定程度上可以解决因为节点意外挂掉导致的请求失败情况，但是这种方式并不是高效的。假...

从今天开始，本人将会开始对另一项技术的学习，就是当下炙手可热的Hadoop分布式就算技术。目前国内外的诸多公司因为业务发展的需要，都纷纷用了此平台。国内的比如BAT啦，国外的在这方面走的更加的前面，就不一一列举了。但是Hadoop作为Apache的一个开源项目，在下面有非常多的子项目，比如HDFS，HBase,Hive，Pig,等等，要先彻底学习整个Hadoop，仅仅凭借一个的力量，是远远不够的。

因为本人最近最近一段时间 都在学习Hadoop，接触了比较多的理论，但是想要深入的去学习Hadoop整个平台，那就必须实战的训练，首先第一步，当然是先搭建好一个Hadoop平台为先。但是比较坑爹的是，Hadoop是要求安装在Linux环境下的，在Windows下是不能直接运行的。所以只能在Windows下搞个Cygwin，然后把Hadoop安装包往里面扔了。我对Cygwin的印象一直不是很好，以前

继前段时间分析Redis源码一段时间之后，我即将开始接下来的一段技术学习的征程，研究的技术就是当前非常火热的Hadoop，但是一个Hadoop生态圈是非常庞大的，所以首先我的打算是挑选其中的一部分模块，去学习，研究，我就选中了MapReduce。MapReduce最早是由Google公司在04年发布的论文中提出的一种思想，后来被人实现出来，才有了后面的Hadoop的诞生。学习MapReduce的打

上篇我刚刚学习完，Spilt的过程，还算比较简单的了，接下来学习的就是Map操作的过程了，Map和Reduce一样，是整个MapReduce的重要内容，所以，这一篇，我会好好的讲讲里面的内部实现过程。首先要说，MapTask，分为4种，可能这一点上有人就可能知道了，分别是Job-setup Task，Job-cleanup Task，Task-cleanup和Map Task。前面3个都是辅助性质

昨天经过几个小时的学习，把MapReduce的第一个阶段的过程学习了一下，也就是最最开始的时候从文件中的Data到key-value的映射，也就是InputFormat的过程。虽说过程不是很难，但是也存在很多细节的。也很少会有人对此做比较细腻的研究，学习。今天，就让我来为大家剖析一下这段代码的原理。我还为此花了一点时间做了几张结构图，便于大家理解。在这里先声明一下，我研究的MapReduce主要研

Partition的中文意思就是分区，分片的意思，这个阶段也是整个MapReduce过程的第三个阶段，就在Map任务的后面，他的作用就是使key分到通过一定的分区算法，分到固定的区域中，给不同的Reduce做处理，达到负载均衡的目的。他的执行过程其实就是发生在上篇文章提到的collect的过程阶段，当输入的key调用了用户的map函数时，中间结果就会被分区了。虽说这个过程看似不是很重要，但是也有值

MapReduce五大过程已经分析过半了，上次分析完Map的过程，着实花费了我的很多时间，不过收获很大，值得了额，这次用同样的方法分析完了Reduce的过程，也算是彻底摸透了MapReduce思想的2个最最重要的思想了吧。好，废话不多，切入正题，在学习Reduce过程分析的之前，我特意查了书籍上或网络上相关的资料，我发现很大都是大同小异，缺乏对于源码的参照分析，所以我个人认为，我了可以在某些细节上

花了大约1周的时间，终于把MapReduce的5大阶段的源码学习结束掉了，收获不少，就算本人对Hadoop学习的一个里程碑式的纪念吧。今天花了一点点的时间，把MapReduce的最后一个阶段，输出OutputFormat给做了分析，这个过程跟InputFormat刚刚好是对着干的，二者极具对称性。为什么这么说呢，待我一一分析。            OutputFormat过程的作用就是定义数