big data decode club

Java NIO在整理NIO文档前先介绍下5个I/O模型。在将I/O模型之前还得介绍几个概念： 内核空间和用户空间 数据从磁盘移动到用户进程的内存区域时，要涉及到内核空间和用户空间。用户空间就是常规进程（如JVM）所在区域，_用户空间_是非特权区域，如不能直接访问硬件设备。内核空间是操作系统所在区域，那肯定是有特权啦，如能与设备控制器通讯，控制用户区域的进程运行状态。进程执行I/O操作时，它执行一个系统调用把控制权交由内核。 缓冲区操作 缓冲区操作是所有I/O的基础，进程执行I/O操作，归结起来就是向操作系统发出请求，让它要么把缓冲区里的数据排干（写），要么把缓冲区填满（读） 5种I/O模型IO请求分为两个阶段：1、等待数据就绪。2、从内核缓冲区拷贝数据到进程缓冲区按照请求是否阻塞分为：同步IO和异步IO。Unix存在5种IO模型：（1）阻塞IO:最常用的模型，缺省情况文件操作都是阻塞的。（2）非阻塞IO:用户需要不断主动询问kernel数据是否准备好了，准备好之后通知用户将数据从内核空间copy到用户空间(用户得到通知之后，亲自去内核空间中将数据复制到用户空间) ...

运行或者移动生产环境中的Hadoop时，对很好的掌握HDFS的恢复过程是非常重要的。HDFS中一个重要的设计需求就是要保证在生产部署中持续正确的操作。尤其复杂的是在网络和节点故障的情况下保证写入HDFS的正确性，租约恢复、block恢复和pipeline恢复保证了写的正确性。理解这些恢复操作何时何地被调用，以及做了什么，能帮助用户或者开发者理解HDFS集群的原理。 在这篇博客中，你会对那些恢复流程有个更深入的理解。首先简单介绍下HDFS write pipeline和恢复流程，对block/replica的状态和generation stamps的概念进行解释，然后逐步介绍租约恢复和block恢复。 这系列文章被分为两篇：第一篇介绍租约恢复和block恢复的细节，第二篇主要介绍pipeline恢复。想了解更多的内容，请参考设计文档：Append, Hflush, and Read for implementation details 背景HDFS中，文件被分为块存储。HDFS中的文件可以被多client同时读，但只能被一个client写入。block的多副本存储在不同的dn上保证了 ...

本篇主要记录下HDFS读取文件的流程，流程图如下： 如上图所示， HDFS Client通过FileSystem.get()方法实例化一个FileSystem对象 调用FileSystem.open打开一个文件的数据流FSDataInputStream，open_中会用rpc方法getBlockLocations得到block的locations信息，默认会先得到_prefetchSize(conf.getLong(DFS_CLIENT_READ_PREFETCH_SIZE_KEY, 10 * defaultBlockSize))大小文件的信息。 HDFS Client通过FSDataInputStream流读取离客户端最近的dn上的block，在第2步中得到的block location信息已经将block的副本按照离客户端的网络拓扑距离进行了排序，此过程是在nn端完成的。 读取完当前block的数据后，关闭与当前的DataNode连接，并为读取下一个block寻找最佳的D ...

问题 何时会触发主备选举当active nn的HealthMonitor检测到active状态为_SERVICE_UNHEALTHY_和_SERVICE_NOT_RESPONDING_时，active的ActiveStandbyElector会quitElection，__quitElection就是关闭zk连接（zk关闭连接之后，相应的watcher也失去作用）__，ZKFailoverController会主动删除当前在Zookeeper上建立的临时节点/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock，此时active的zk已经关闭连接，watcher已无法监听到_DeleteNode_事件，standby上的watcher则可以监听到_DeleteNode_事件，会马上再次进入到创建/hadoop-ha/${dfs.nameservices}/ActiveStandbyElectorLock节点的流程，如果创建成功，这个本来处于Standby状态的NameNode 就选举为主NameNode并随后开始切换为Active ...

本篇主要接着上篇介绍Pipeline Recovery。 写Pipeline当HDFS client执行一个写操作时，数据是以序列化的block形式写进去的。其中block又被分为很多packets，将packets发送到由一些dn组成的pipeline中，如下图所示： pipeline分为三个阶段： Pipeline setupclient向pipeline发送一个Write_Block请求，pipeline中的最后一个DataNode往回发送一个ack。client收到ack之后，pipeline就处于setup状态，准备写入数据。 Data streaming数据通过packets发送到pipeline中。client端缓存数据到buffer中，buffer满之后写入packet，等packet满之后，发送packet到pipeline中。如果client调用hflush()，即使当前packet没有被写满，也会发送到pipeline中，并且下一个packet在收到当前packet的ack之前不会发送到pipeline中(上图中的packet2就是调用hflush)。 Cl ...

[上篇](http://bigdatadecode.top/HDFS read解析.html)主要记录了HDFS read打开一个文件流的流程，该篇记录下从打开的文件流里read数据的流程。 HDFS Read之从文件流中read读取文件流中的数据通过文件流FSDataInputStream对象的read方法进行读取，最终调用了DFSInputStream的read方法(可以写个hdfs read file demo 进行debug下就会发现) 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263public synchronized int read(final byte buf[], int off, int len) throws IOException { // ReaderStrategy 将不同的BlockReader进行了封装 // 真正读数据的是BlockReader对象 ...

HDFS由NameNode和DataNode组成，其中NameNode作为Master节点，负责维护整个集群的状态，为了提高响应速度其大部分数据都常驻内存，则NameNode内存的使用尤为重要，一旦NameNode出现故障，整个Hadoop集群就将处于不可服务的状态。 在解析NameNode内存之前先来回顾下HDFS整体架构。 HDFS架构从上图中可以看出HDFS可以分为两层，分别为NameSpace和Block Storage Service，其中Block Storage Service包含Block Management和Storage两部分。 NameSpace和Block Management在NameNode中，Storage在DataNode中。 NameSpace主要存储集群的目录结构和文件所对应的block映射(file->blocks的映射)，是HDFS文件系统实际执行的核心，提供各种增删改查文件操作接口。 Block Management 通过注册和周期性的心跳提供dn集群成员 处理dn的block report，存储在BlocksMap中 提供blo ...

[上篇](http://bigdatadecode.top/YARN源码分析之Fair Scheduler part1.html)介绍了Fair Scheduler中FairShare和SteadyFairShare的计算方法，本篇主要介绍其抢占相关的知识。 抢占在YARN中经常发生，但其在什么时候发生，抢占谁的资源，又将抢占后的资源分配给谁，这篇文章就尝试着去解释这些问题。 本篇主要将在Fair Scheduler调度中发生的抢占。先介绍几个相关配置。 与抢占相关的配置yarn-site.xml yarn.scheduler.fair.preemption Fair调度时是否开启抢占功能。默认为false yarn.scheduler.fair.preemption.cluster-utilization-threshold 集群中使用的资源超过此阈值时，才发生抢占。默认是0.8f 还有几个配置貌似没有开放设置， yarn.scheduler.fair.waitTimeBeforeKill，默认是15000ms。等待时间超过此值时，将抢占队列中的container ...

想看fair Scheduler的源码已经很久了，只是一直没有合适的时间，更没有找到合适的方法去读src，导致每次读一点就不想继续读了，最近实在是太无聊了，也不知道该读点什么，于是就又想起了这个搁置很久的任务。 这次读代码时我直接从fair Scheduler的test类中进行跟读，这样我感觉会比较清晰也容易debug。 环境初始化要想测试Fair Scheduler，首先要虚拟出一个yarn环境，并加载fair相关的配置。下面就来看下TestFairScheduler这个类是怎么对环境进行初始化的。 TestFairScheduler继承自FairSchedulerTestBase，一些公共常用方法被提到FairSchedulerTestBase中，yarn和相关配置环境的初始化在setUp中，代码如下： 123456789101112131415161718192021222324252627282930public void setUp() throws IOException { // new 出一个fair Scheduler实例 scheduler = n ...

给定一个字符串，求最长回文子串(假设字符串中只有唯一的一个最长回文子串)。 注意子串和子序列的区别，子串是连续的，子序列是非连续的例如：字符串”xyzabccbad”, 最长回文为”abccba”字符串”aaa”, 最长回文为”aaa”字符串”bananas”, 最长回文为”anana” 回文就是顺着读和逆着读是一样的。 动态规划算法最长回文子串可见是求最优解，并且可以对将此问题拆分，则观察能否用动态规划去尝试。 要用动态规划首先要找到转移方程， 这里需要注意，假如你发现自己的转移方程的特别繁琐或者需要考虑很多不同的情况更或者是总一些情况无法用转移方程表示时，这时你就应该考虑是否应该重新定义状态，进行重新整理转移方程。 假设：dp[i][j]表示i为开始j为结尾的字符串是否为回文，则转移方程如下：dp[i][j] = true (chars[j] == chars[i] && dp[i+1][j-1]) 初始条件是dp[i][i] = true (0<i<chars.length); dp[i][i+1] = chars[i] == charsi ...