2016年09月_Android路上的人

原创 HDFS数据恢复模式

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

2016-09-28 15:45:21 5707

原创 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 3621 1

原创 HDFS nnTop统计功能

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

2016-09-19 18:54:55 3680

原创 HDFS NodeLabel特性

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

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

原创 HDFS异步访问模式

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

2016-09-07 19:32:04 2827

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

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

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

走在前往架构师的路上