Android路上的人-CSDN博客

原创聊聊副本放置方式对副本持久可用性的影响

前言在过去的很多时间内，人们在分布式数据存储领域研究关注的一点往往是数据的一致性。因为当数据以多副本的形式分散地存储在集群中，我们当然是要确保每份副本上的数据确保一致，然后我们才能读到最新的数据。所以在另一方面，也就是数据的放置位置选择方面就会缺少相对应的关注度。其实在这块领域也是有许多东西可以值得研究的，比如说副本位置的存放策略在一定程度上会影响其未来的可用性，换个更通俗易懂的说法，就是我的副本位

2017-07-02 14:08:08 1884

原创分布式数据库学习--分布式并发控制

前言并发控制理论在分布式计算领域是一块较为重要的内容。了解和掌握好这块理论知识，将有助于我们在工作实践中解决一些复杂的难题。最近笔者学习了分布式数据库系统原理书中的分布式并发控制的相关内容，本文借此机会总结总结。并发控制的目标在往常，我们一提到并发这个词，就会马上联想到多线程这个词。这是因为我们在平时的开发工作中经常有遇到多线程的场景。但是回过头来看这个词，其实并发的场景绝不仅限于多线程操作，另外一

2017-06-11 15:18:56 2620

原创 HDFS新运维工具命令之listOpenFiles命令

前言在运维集群的时候，我们有的时候需要去知道哪些文件存在未被及时关闭的情况。否则会造成一定程度上的资源泄露，比如内存无缘无故就被耗掉了。可能有人会想，好端端的文件，为什么会存在未被关闭的情况呢？答案是有可能的，当发生各种异常写文件的情况时，就有可能发生。这在HDFS内部同样也会发生。对此，社区最近在实现添加一项新的管理员命令-listOpenFiles命令来帮助集群管理者获取这些“打开中的文件”，

2017-05-30 10:28:57 1604

原创聊聊HDFS中的副本放置策略和磁盘选择策略间的选择“矛盾”

前言我们知道，在HDFS里，有2个与文件块写入紧密相连的策略选择类：副本放置策略（BlockPlacementPolicy）和磁盘选择策略（VolumeChoosingPolicy）。这两者有什么作用上的区别呢？前者决定了文件块的目标写入节点，后者决定了目标节点上哪个磁盘目录被写入。之前笔者已经写过相关策略的介绍文章了，感兴趣的同学可以点击此链接：HDFS副本放置策略和DataNode引用计数磁盘

2017-05-14 15:42:26 2317

原创 HDFS的新方向：Ozone对象存储

前言HDFS在近几年中得到了迅速的发展，作为性价比比较高的存储系统，用户、企业只需利用若干台低配廉价的节点机型，就可以构建能够承受TB甚至PB级别的大数据集群，然后在上面做各种类型任务的作业，而且在底层方面，我们完全可以依赖HDFS自身实现的容错机制来应当各种异常情况。但是在当今数据使用场景日益多元化的背景下，HDFS并不是能满足所有的应用需求。如何能够以一种更加高效，方便的方式去存储用户想要保存的

2017-04-30 15:18:12 7295

原创 HDFS副本放置节点选择的优化

前言我们都知道，HDFS在准备写文件块的时候，必须要做的一个步骤是要从集群内数以千计的节点中选择一个有效的节点作为待写入块的目标节点。那么这里何为”有效的节点”呢？指的是此节点内包含有快文件需要的Storage Type（存储类型）。比如说某block要求的类型是SSD，而当前选出的节点所有数据目录都是DISK的话，那这个节点就不是满足要求的节点，此轮选举就会被废弃，将选过的节点加入exclude列

2017-04-16 14:35:02 8463 2

原创 HDFS跨外部存储系统的多层级存储

前言目前大数据和云计算是当下讨论非常火热的2个词，笔者也非常相信在未来的时间内，以Hadoop系统生态圈为代表的大数据工具，将会被更多的企业所使用。在一些更大规模的公司，已经将大数据与云联系在了一起了，举个例子，我们将数据存储在HDFS内，然后在定期同步到云上，相当于云端存储的数据是一个back store。这样做的一个好处是防止本地集群的数据遭到意外的破坏或丢失，至少在云端我们还有备份。

2017-04-03 15:14:06 4756

原创分布式数据库学习--分布式数据库的设计

前言分布式系计算作为一个比较复杂的课题，需要读者具备良好的计算机基础知识。有了这些理论知识的支持，我们才能更好的阅读，学习当前各个主流的分布式系统以及框架。笔者最近饶有兴趣的开始学习起了分布式数据库的知识。因为笔者主要研究的方向是HDFS，也就是分布式存储这块，所以学习了解这块内容对笔者来说能在未来更好地贡献于HDFS。OK，转回正题，最近笔者学习了分布式数据库的设计问题，换句话说，也就是分布式数

2017-03-18 23:52:50 6776

原创聊聊错误注入技巧

前言什么是“错误注入”？错误注入指的是将错误引入到我们的程序中。可能有人会很好奇，这么做有什么目的呢？答案很简单：程序的测试。因为在很多时候，当我们要进行边缘情况测试的时候，往往模拟测试的场景不是非常好造的(尤其是分布式类的程序更是如此)，这个时候，我们需要有快捷的方式将错误注入到程序中，以便在我们需要发生错误时，进行错误的产生。本文笔者将结合HDFS现有的错误注入方法来介绍此部分内容。错误注入技术

2017-02-26 20:00:32 6323 7

原创 Hadoop Erasure Coding结构分析

前言Hadoop-3.0-alpha2版本最近已经发布了，在Hadoop-3.0-alpha2版本中，社区继续fix了许多关于HDFS EC特性相关的issue。而Hadoop EC作为3.0版本中具有重大意义的feature，我们非常有必要去学习，并用好这个特性。在之前的文章中，笔者或多或少介绍过EC技术的原理知（再聊HDFS Erasure Coding）以及EC技术在Hadoop中的运用（Ha

2017-02-19 15:50:13 4727

原创遇见InterruptedException异常，怎么办？

前言在Java语言的开发工作中，我们经常会碰到这样一类异常--InterruptedException（中断异常）。在绝大多数时候，我们的处理方式无非是catch注它，然后再输出异常信息，更或者是干脆直接忽略它了。那么这是否是一种正确的处理方式呢，要想搞清楚这件事，我们又必须要了解什么是InterruptedException，什么情况下会导致此异常的发生呢？本文笔者来简单讲述讲述这方面的内容，了解中断中断异常方面的知识将有助于我们在分布式的程序中处理这样的异常。

2017-02-12 17:57:16 30889 2

原创 HDFS“慢节点”监控分析功能

前言当集群规模在日益变大的时候，往往有的时候出现机器的老化，而这些“老化”的机器又会表现出一些奇怪的特征：“磁盘读写慢”、“网络数据传输慢”等。对于前者，曾经笔者写过一篇 Hadoop节点”慢磁盘”监控的解决方案，当然社区目前已有更好的方案： HDFS-10959 （ Adding per disk IO statistics and metrics in DataNode ）。而对于后

2017-01-31 17:16:32 6444 6

原创 HDFS Maintenance State

前言初一看文章标题，很多人可能比较奇怪“HDFS Maintenance”是什么意思，“HDFS包含”的意思？首先Maintenance这个形似Maintain的单词可不是什么包含的意思，它的解释是维护，维修。那么HDFS Maintenance具体是什么意思呢，HDFS处于维护状态？说起维护状态，我们不禁可以联想到HDFS RollingUpgrad，没错，RollingUpgrade确实与HDF

2017-01-25 22:43:25 2321

原创继续聊聊HDFS BlockManager扩展性问题

前言最近一段时间，笔者在业余时间继续对HDFS的扩展性内容进行学习。一句话来概括，越往里深入，越发现里面可以讲的东西越多，涉及到的点也越多。社区在这个方面确实做了很多的讨论。本文所讲述的主题源自于社区JIRA HDFS-7844(Create an off-heap hash table implementation)，大意是利用堆外内存（off-heap）来进行元数据的存储。之前我们总是提到的Na

2017-01-24 21:36:11 1594

原创 HDFS小文件问题解决方案与启发实践

前言继上文聊聊HDFS BlockManager的服务化改造之后，本文我们继续来讨论HDFS扩展性相关的问题。在本文的阐述过程中，我们将通过一个平时遇到的典型问题-HDFS小文件过多问题作为贯穿全文的一个核心要点。在下文中，笔者将会介绍小文件的缘由，现有解决办法，新的解决方案等等内容。

2017-01-08 14:25:07 10103 1

原创聊聊HDFS BlockManager的服务化改造

前言在现有的HDFS中，NameNode扮演着一个十分重要的角色。它不仅需要处理集群中所有文件相关的操作（此处可理解为INode相关的操作），它还要处理更小粒度级别的操作，也就是block块级别的操作。随着HDFS的快速迭代发展，它所需要执行的操作也越来越重了。另一方面，一旦集群的数据量规模大幅度扩展的时候，相应的INode文件、block块数据信息将会耗掉NameNode大量的内存，这将会大大降低

2017-01-03 12:24:31 1950

原创 DataNode生命线消息

前言在HDFS中，我们都知道DataNode是通过定期发送心跳信息到NameNode，以此证明自己还“活着”。当然心跳信息发送的另一项作用是发送自身的块报告信息给NameNode，以此保证集群数据的更新。然后NameNode会反馈给各DataNode一个回复命令。从这里看出，心跳在这里的所执行的操作还是比较“重”的。

2016-12-24 15:22:24 4648 2

原创 HDFS内副本和块的状态分析

前言在HDFS内，我们通常听到的最频繁的2个名词术语：副本(Replica)和块(Block).几乎可以这么说，HDFS所有涉及到文件的操作都与这两个词相关。但是大家可能对这2个概念的理解还仅仅停留在一个比较浅的层面：比如说就是一个单一的replica或是一个单一的block块。尤其是在对块的层面，一个block块在最终完成后，它会经历哪些状态过程呢？这些细节的内容就是本文所准备阐述的。副本/块的状

2016-12-14 19:06:34 7118 2

原创具有Set属性的Queue

在最近的工作中，遇到了一个特殊的需求：我们需要一个队列来存放某数据对象，但是这个对象的数量是巨大的，如果将这些对象都存入队列的话，很显然内存会爆表，但是这些对象有一个特征是，相同的数据对象类型的数据是可更新的。换句话说，对于同一类数据对象，后面来的对象的值一定比前面的新，是可以完全覆盖前面的。

2016-12-06 20:09:39 4417

原创 HDFS智能化存储管理：Smart Storage Management

前言前段时间无意间看了一则Apache Big Data Europe 2016的回顾，感觉挺有意思的。因为本人一直focus在HDFS这个模块上，所以我特意关注了在此次大会中提到的一个issue：HDFS-7343（HDFS smart storage management）。后来本人花了一定的时间对此issue进行了学习，总结下来一句话：这个issue可以说是一个非常大胆而又具有新意的想法。它的

2016-11-26 22:12:31 3261

原创 DataNode启动优化改进：磁盘检测并行化

前言在本篇文章中，本人打算聊一个大家平常都会遇见到的场景：HDFS中的DataNode启动的问题。DataNode启动不是一件非常迅速的事情吗？这其中能有大问题？看到这里，如果你也是这么想的话，那说明一点：你所运维的集群碰到的异常场景还不太多。本文所要讲述的问题并不是DataNode无法启动的问题，而是它启动有时会过慢的问题。

2016-11-20 10:20:07 3839 2

原创 HDFS ZKFC自动切换原理分析

前言Hadoop社区在HDFS-1623（High Availability Framework for HDFS NN）以及相关JIRA中对NameNode增加了高可用性的支持。但是它的实现需要依赖管理员手动切换NameNode，以此来触发NameNode的切换。这种操作方式有时会带来一些问题，比如说一个NameNode因为非主观原因导致异常，挂了，这个时候怎么办，这个时候我们可能更需要自动切换的

2016-11-13 16:54:54 13185 2

原创 HDFS数据快速拷贝方案：FastCopy

前言我们在使用HDFS的时候，往往有的时候需要做一些临时的数据拷贝操作，如果是在同一个集群中的，我们直接用HDFS内部自带的cp这些命令即可；如果是跨集群的时候或者说待拷贝数据量规模非常大的时候，我们还可以使用DistCp工具。但是这是否意味着我们使用这些工具在拷贝数据的时候依然是高效的呢？答案其实并不是这样的。在许多比较早使用Hadoop的公司，估计都或多或少遇到过拷贝大规模数据效率不高

2016-10-30 11:07:33 13337 4

原创 HDFS升级域：Upgrade Domain

前言在前面的文章HDFS的滚动升级: Rolling Upgrade中，介绍了HDFS滚动升级相关的内容。在HDFS滚动升级的过程中，会涉及到DataNode重启服务的操作。对于这里的DataNode服务重启的操作，其实是有一定讲究的。比如说，我们批量重启部分节点的时候，不能同时重启过多的节点，否则会造成部分块副本所在节点都处于正在重启的机器中，导致数据不可用的情况发生。如果我们想依然保证

2016-10-25 11:11:30 1985

原创 HDFS租约机制

前言在HDFS中，当每次客户端用户往某个文件中写入数据的时候，为了保持数据的一致性，此时其它客户端程序是不允许向此文件同时写入数据的。那么HDFS是如何做到这一点的呢？答案是租约（Lease）。换句话说，租约是HDFS给予客户端的一个写文件操作的临时许可证，无此证件者将不被允许操作此文件。本文我们将要深入分析HDFS内部的租约机制，包括租约的添加、移除、管理操作等等。

2016-10-19 20:27:18 11754 1

原创 HDFS符号链接和硬链接

前言初看这个标题，可能很多人会心生疑问：符号链接和硬链接是什么意思？这些概念不是在Linux操作系统下才有的嘛，HDFS目前也有？当然大家可能还会有其他疑问，没关系，在后面的内容讲述中答案会一一揭晓。归纳起来一句话：不管是符号链接还是硬链接，它们本质上都是一种快捷的链接方式。熟悉Linux系统的同学应该都知道在Linux文件系统下有硬链接和软链接的概念，而HDFS同样作为一套文件系统，它也能支持文件

2016-10-15 15:31:07 12578 1

原创 HDFS数据恢复模式

前言在现有的HDFS中，为了保证元数据的高可用性，我们可以在配置项dfs.namenode.name.dir中配置多个元数据存储目录来达到多备份的作用。这样一来，如果其中一个目录文件损坏了，我们可以选择另外可用的文件。那么问题来了，如果所有备用的元数据都损坏了，不能用了，这个时候怎么办，那么是否就意味着集群就永远启动不起来了呢？这将会是一个多么糟糕的结果啊。在这里，我们就要引出本文的主题：HD

2016-09-28 15:45:21 5706

原创 HDFS Truncate文件截断

前言在linux操作系统的使用中，有的时候我们可能想对某个现有的文件做尾部的截取（比如为了保留头部关键信息），但同时又不想重新写一个新的文件出来，这个时候我们其实可以采用系统提供的truncate命令。单词truncate的本意是“截断”,在这里由于操作的对象是文件，所以此命令的作用就是文件的截断。那么同样作为一套成熟的文件系统，HDFS是否也能支持这样的API方法呢？可能它与linux文

2016-09-25 17:19:43 6540

原创 HDFS HA支持多Standby节点机制

前言在现有的HDFS中，为了保证其高可用性，社区在早些年就已经完成HDFS的HA机制，也就是One Active，One Standby。在此种情况下，HDFS能够容忍其中一个节点出现失败的情况。这套HA机制的实现的确给用户带来了很大的帮助，基于此特性，我们可以做很多集群上的热操作，比如热迁移NameNode，或者滚动升级HDFS等等。可能唯一让人感觉还不是最好的一点是，它不能容忍更多失败

2016-09-22 18:02:59 3620 1

原创 HDFS nnTop统计功能

前言在HDFS的使用过程中，有的时候集群维护者可能想要知道哪些用户使用他们集群的资源比较多，以此有一个全面的了解。在YARN中，衡量用户使用资源的一个指标是container树，而在HDFS中我们可以用什么指标呢？答案是请求数。当然你可能会说，为什么不能用写入写出的总数据量作为指标呢？没错，这的确也是一个可选指标，但是显然它们不易收集以及统计，相比于请求数而言。那么问题又来了，是否我们有

2016-09-19 18:54:55 3679

原创 HDFS NodeLabel特性

前言在集群规模日益增大的背景下,集群内运行的机器类型可能也会变得越来越多,可能一部分机器磁盘读写性能比较好,又可能说那部分机器网络情况较好,还有的是CPU计算资源比较好的机器.面对这么多机型的节点,我们当然不能”一视同仁”,否则对于这些机器来说,就是一种资源浪费.在Job运行的层面(在YARN层面)而言,已经可以支持通过打NodeLabel标签的形式,让application运行在指定no

2016-09-11 10:56:59 4693 4

原创 HDFS异步访问模式

前言在现有HDFS的RPC调用方式上,采用的基本是blocking call的形式,也就是阻塞式的调用方式.阻塞方式的一个明显的缺点是它的请求过程是同步的,也就是说,客户端必须等待当前请求结果的返回,才能接着发送下一次请求.如果此客户端打算在一个线程中发送大量请求的话,阻塞式的RPC调用将会非常耗时.但是如果为了每一次请求调用而专门单独开一个线程的话,系统资源将会被大幅度的使用,显然这也不

2016-09-07 19:32:04 2826

原创 HDFS inotify：Linux inotify机制在HDFS中的实现

前言在文件系统的使用中,在某些场合我们往往会有这样一个需求点:我们想对某个文件/目录进行事件监听,监听的事件包括在目标目录下新增文件了,又或者说是删除了什么文件等等.这其实是对目标文件目录数据的一个比较实时的监控.我们比较传统的方案是去做定期的全盘扫描,然后算出增量值与最新统计值.这种方式的优点是实现简单,但是缺点也很明显,就是太低效了.那么在目前现有的Linux操作系统中,是否有这样的一

2016-09-03 09:56:48 3626 1

原创 HDFS QJM机制分析

前言上周写了一篇译文专门从结构设计的层面来分析HDFS的QJM机制,总体而言,文章偏重理论介绍.本文将继续围绕QJM机制展开分析,但是不同点在于,本文将会从更细粒度的层面来分析这套机制,帮助大家从源代码层面理解QJM的具体实现.本文将从Active/Standby的editlog读写,QJM的RPC调用过程以及JournalNode的同步/恢复三方面进行具体的分析.Active/Standby的ed

2016-08-27 17:45:07 4858 1

翻译 HDFS QJM的架构设计

概述背景HDFS-1623和其他相关的JIRA在现有HDFS的NameNode基础上增加了HA的支持,但是他们需要依赖一个存放editlog文件的共享存储目录.而且这个共享存储必须也是高可用的,它们会被集群中所有NameNodes同时访问.目前对于共享的editlog存储目录,一个推荐的做法是通过一个NAS(Network-attached storage,网络相关联的存储)设

2016-08-20 17:25:23 4575

原创 NameNode热迁移方案

方案目标将现有NameNode迁移到新的节点上,期间保证集群对外提供服务.方案背景随着集群数据量和规模的扩增,需要将NameNode迁移到性能更优的机器上,以此提高NameNode的请求处理效率.传统方案: 冷迁移具体步骤传统方案的做法比较简单,主要步骤如下:1.停止集群服务,关闭NameNode,DataNode.2.将NameNode元数据拷贝到

2016-08-18 19:14:27 6391 6

原创记两次NameNode响应延时问题

前言最近一两周,本人在维护公司内部集群的时候,遇到了一些性能问题,(可能这些问题以前也都存在,只是不容易被发现)表现出来的特征就是NameNode响应请求非常慢,然后导致各种超时,用户体验非常糟糕.因为本人目前使用的版本是2.7.1(社区最新发布版本2.7.2),应该算是非常新的版本了,在这个版本目前已经存在这个问题,那么在往前的一些版本中也肯定存在类似问题.下面是本人在最近集群运维过程中

2016-08-13 19:14:58 31948 3

原创 HDFS Federation机制

前言在上一篇文章HDFS自定义小文件分析功能中，提到了NameNod内存空间使用过高的问题,紧接着提到了其中一个解决方案，就是HDFS Federation.说来也是挺奇怪的,HDFS的Federation机制其实在Hadoop很早的版本中就就有了,可是从日常使用上来看,了解和真正使用这个功能的人并不多.原因可能在于目前对于绝大多数用户的使用场景,一个NameNode或一对HA的NameNode方式

2016-08-06 22:41:07 11725 2

原创 HDFS自定义小文件分析功能

前言看完本文的标题,可能有读者会心想:HDFS为什么会与小文件分析挂钩呢?Hadoop的设计初衷不是偏向于存储单位体量规模较大的文件的吗?设计这样的功能有什么实际用途呢?这背后其实是有很多内容可以讲的,说起HDFS中的小文件,我们并不是关心它到底有多小,而是在于它太多.而文件太多的原因往往在于其外部程序写入单个文件的量太小导致,在同样规模待写入数据量的前提下,单位文件过小显然会造成大批量的

2016-08-02 19:24:46 5934

原创 HDFS的滚动升级: Rolling Upgrade

HDFS Rolling Upgrade实际操作下面我们来重点关注HDFS Rolling Upgrade部分的操作.HDFS Rolling Upgrade部分的操作并不是就几条命令的事情,它还要考虑集群是否是HA配置的,HA里又分为是否为federated cluster和非federated cluster.我们知道在federated cluster会存在多个namespace的,

2016-07-28 19:46:01 7888 4

空空如也

空空如也