1.背景 presto将eventlog存储到内存之中。以下两种情况下无法通过web获取SQL历史查询信息： 重启prestocoordinator，内存清空，无法通过Web查询历史SQL执行信息。 presto内存只保存100条最新的eventlog，100条之前的SQL执行记录会被清除。 这大大增加了业务检查SQL执行情况的门槛。为此，需要将Presto的eventlog持久化。 2.Presto持久化入口 在PrestoServer启动时，会调用PluginManager的loadPlugins方法： injector.getInstance(PluginManager.class)...

1.背景 众所周知，Hadoop2.6.0版本bug非常多，依次大部分公司都将Hadoop升级为Hadoop3。但是，有些实时flink集群由于作业复杂敏感难以迁移，依然使用Hadoop2.6.0集群作为checkpoint存储路径。 如下所示，实时集群中经常出现NonDFSUsed非常高，导致可用磁盘空间非常低的情况： 登入机器中，可以发现磁盘只用了20GB： 因此，可以认为这是HDFS的一个BUG。 2.NonDFSUsed计算逻辑 datanode向namenode上报心跳时，调用FsDatasetImplgetStorageReports方法： publicStorageRepor...

1.背景 在离线集群中，有些冷数据集群专用于存放HDFS数据，很少用来提供计算操作，这些机器的计算资源都浪费了，它们的典型特征是：只启动datanode服务，不启动nodemanager服务。为了提高这些机器的资源利用率，希望在其他计算集群需要资源的时候，resourcemanager可以在冷数据集群中启动NodeManager服务，最大化利用计算资源。 2.整体设计 如下所示，通过NodeMananger资源管理平台，执行集群的扩容命令，空闲节点会根据集群匹配对应的集群NodeMananger配置，启动NodeMananger产生对于集群的心跳： 3.功能与流程设计 NodeManange...

1.背景 对于Hadoop集群监控，有基于Linux的硬件告警，比如磁盘，内存，网络带宽告警；有基于组件的告警，例如OOM报警、RPC告警。这些告警能反应个体机器的运行状况，不能反映整个集群的运行状况；同时，这些告警都是在已知的故障指标，但是对于未知的指标，可能已经发生并且对系统产生较大影响，由于没有告警不能及时介入，造成严重的故障。 为了解决上述问题，本文介绍一种基于MapTask进度和ReduceTask进度进行更细粒度的进度检查，引入了HoltWinters时序预测算法按照不同频度对这些进度进行预测，实时对比作业进度和预测进度，计算异常进度。异常进度一般表示由于某些异常导致作业产生延迟，...

1.背景 在https://blog.51cto.com/u_15327484/8260931文章中，介绍了通过抓取Yarnweb页面的方式获取task级别的进度，并且将task进度通过纵向的历史进度进行预测对比检查作业进度是否符合预期。 对于task级别的进度，不仅可以用作纵向对比，还可以进行横向对比。当多次发生某个节点上执行的task比其他节点节点上执行的task时间高时，就认为该节点是慢节点，应该经过一系列硬件检查以及环境信息检查，甚至下线。 2.异常节点比较算法 由于map下所有task都属于同一类型，它们执行相同的逻辑，正常情况下map下的所有tasks应到同时执行完，如果有task...

1.背景 在alluxio1.8中，alluxiomaster只支持单节点部署，一旦挂掉，整个集群将不可用。alluxio2.x后，提供了高可用方案：Alluxio组件中嵌入ApacheRatis代码，由Ratis负责选举leader，Alluxio的各个master在同步editlog时，由Ratis提供editlog的一致性传输。 Ratis服务基于Raft共识算法，该算法保证分布式集群中只有一个leadermaster对外提供服务，其他standbymaster在leadermaster退出时再竞争成为master。 本文会先后介绍Raft算法框架，不会详解琢磨细节，同时介绍Raft在A...

1.背景 对于Hadoop集群而言，将长期没有访问的冷数据放到DataNode中的磁盘存储成本较高，可以将这部分冷数据存储到S3中。这就引入一个问题，虽然Hadoop支持s3a的方式访问s3文件系统，但是访问时需要携带aksk，一旦用户拿到aksk，他们就有随意操控整个S3数据的权限，整个S3数据就不安全了。 为了解决这个安全问题，可以将S3文件系统挂载到Alluxio文件系统中，Alluxio的客户端可以通过Alluxio统一命名空间和接口来访问多个独立的存储系统，S3就是Alluxio的UFS(UnderFileSystem)。这样，只有Alluxio服务会访问S3文件，Alluxio服务...

1.背景 在https://blog.51cto.com/u_15327484文章中，介绍了Alluxio的架构。本文基于此，介绍Alluxio文件读写流程。Alluxio读写流程几乎和HDFS一致，只是Worker多了一个从UFS读写的选项，本文会省略部分流程，只介绍重点。 2.Alluxio写流程 客户端向Alluxio写数据时，可以指定是否就Alluxio中的数据写到UFS中。写UFS数据时，还可以指定是同步写入还是异步写入。Alluxio有四种写数据的模式： MUST_CACHE：数据只写到AlluxioWorker中。 CACHE_THROUGH：数据写到AlluxioWoker中...

1.背景 在https://blog.51cto.com/u_15327484/8023493文章中，介绍了HDFS创建文件时，客户端执行的操作。对于NameNode而言，在创建文件的过程中，它会接受客户端以下rpc请求： create addBlock complete 本文将详细介绍这三个RPC在NameNode端的处理流程，同时扩展介绍Namenode相关架构。 2.NameNode文件系统实现及其class 在NameNode服务端中，有三个类最重要： NameNodeRpcServer：负责处理rpc请求，根据请求对FSNamesystem进行增删改查。 FSNamesyste...

1.背景 在https://blog.51cto.com/u_15327484/8023493和https://blog.51cto.com/u_15327484/8089923两篇文章中，分别详细介绍了客户端和Namenode在HDFS写流程的处理逻辑。本文将介绍DataNode接收数据的流程，本文省略与NameNode交互细节，专注于数据的发送与接收。 2.DataNode事件处理线程模型 在DataNode启动时，会创建TcpPeerServer这个SocketServer，传递给DataXceiverServer进行处理： publicclassDataNodeextendsRecon...

1.背景 在https://blog.51cto.com/u_15327484/8023493、https://blog.51cto.com/u_15327484/8089923和https://blog.51cto.com/u_15327484/8095971三篇文章中，介绍了HDFS写文件在client、NameNode、DataNode组件侧的行为逻辑。 对于HDFS读文件流程来说相对简单： 获取HDFS文件起始的的block信息。 选择离客户端最近的datanode读取block。 当block读取完毕，ClientProtocol.getBlockLocations()读取下一个b...

1.背景 文件内容的变更往往意味着block信息的变更，在datanode中，变更的block会发送给namenode，namenode会更新block信息。本文将介绍datanode心跳流程和block块汇报流程。 2.DataNode心跳线程模型 在HadoopFederation架构中，一般由一对Active/StandbyNameNode为一组作为一个namespace，每个namenode有独属的blockpool，blockpool是该命名空间下block的集合。不同的namespace可以共用相同的datanode进行存储，在datanode中，每个namespace对于不同的目...

1.背景 需求一 当前线上集群A还是使用fairscheduler，当调度请求量大时，经长发生pending： 观察队列使用情况，发现队列并没有用满，这说明是调度性能问题。 CapacityScheduler由于使用了细粒度锁、异步调度等特性，吞吐量能够提升5-10倍。因此希望集群能够升级调度器为CapacityScheduler。 需求二 对于运行在AWS上的nodemanager，为了节省成本，选择了不定期回收的机器类型。在这些节点上运行的作业会失败重试，对于一些重要作业而言，这种行为不可接受。而CapacityScheduler提供NodeLabel节点标签功能，可以给一些不可回收节点...

1.背景 在Hadoop2.x之前，只有一台NameNode负责对外提供服务，另外一台secondaryNameNode只用于合并fsimage，不提供对外元数据服务。因此NameNode和secondaryNameNode都存在单点问题。 为了解决secondaryNameNode单点问题，HDFS引入多个JournalNode服务存储操作日志，取代单台secondaryNameNode。JournalNode引入了Quorum机制：ActiveNameNode写EditLog时，除了向NameNode本地磁盘写操作日志，还会向所有JournalNode发送写请求。对于2N+1台JN组成的集...

1.背景 在Hadoop2.0前，NameNode存在单点问题，造成服务稳定性差。Hadoop2.0后，引入HA机制，通过zk选举的方式选举active节点提供服务。 在https://blog.51cto.com/u_15327484/7850359一文中，介绍过resourmanager高可用过程。NameNodeHA在选举流程上和resourmanager一致，但是，为了降低复杂度，同时也为了规避选举过程对namenode的服务稳定性影响。HDFS讲NameNode选举流程独立到zkfc进程中。如下是NameNodeHA架构图： 2.NameNode启动时状态分析 在NameNode启...

1.背景 在Hadoop2.0之前，一个Hadoop集群只支持一对主备NameNode。如下所示，集群中的数据接近2.2亿block，会导致NameNode内存中的文件系统树过大，占用较多内存；同时NameNodecrash后启动时，由于需要加载过多的block，导致启动时间过长。 集群 每日写入block 每日净增block 每日数据净增长 当前block数 空间使用率 集群A 500-600W 60W-70W 100TB+ 2.2亿 71.93% 最简单的解决方法就是通过distcp工具将该集群中的项目迁移到另一个空闲的集群，但是ditscp工具有自身的缺陷：迁移过程耗...

1.背景 客户端登陆服务端时，一般要进行认证。认证是指用户将自己的密码信息放到服务端，客户端访问服务端时，服务端检测到传输过来的密码和保存的密码一致，就认为用户有权访问服务端。如果不一致，那么用户无法通过密码证明自己的身份，就无权访问服务端。 这种传统的认证方式有以下问题： 服务端要额外进行任务工作，增加了服务端的代码复杂度。 客户端在网络中传输账号密码容易泄漏。 Kerberos认证系统就完美解决上述问题。 2.Kerberos认证系统介绍 2.1Kerberos的账号和密码表示形式 Kerberos系统中的账号和密码不同与传统认证方式。如下所示： 为了避免服务端进行额外的认证工作，K...

1.背景 https://blog.51cto.com/u_15327484/8153877文章中介绍了Hadoop中使用kerberos机制进行认证。在客户端初次访问服务端时，通过JAAS获取TGT，再通过GSSAPIonSASL获取serviceticket完成认证。 在用户向Yarn提交作业时，如果作业有上万个container，每个container都会访问HDFS的NameNode，那么就有两个问题： 要将keytab文件发送给每一个container，让每个container进行认证，这容易造成keytab文件泄漏，产生安全风险。 每个container访问NameNode前，都...

1.背景 在https://blog.51cto.com/u_15327484/8153877文章中，介绍了在Java中，客户端通过JAAS框架向AS认证获取TGT，再通过GSSAPIonSASL获取serviceticket并向服务端进行认证。 Hadoop中整合Kerberos安全认证机制，当HDFS客户端访问NameNode服务端时，HDFS客户端先获取TGT，再获取serviceticket并向NameNode进行认证。 本文不会继续深究Kerberos自身的机制，而是探索Hadoop封装Kerberos进行通信的框架逻辑。 2.Hadoop封装Kerberos类 Hadoop中，将K...

1.背景 在HadoopYarn中，App、AppAttempt、Container、Node都有自己的生命周期，因此Yarn实现了一套状态机进行管理。通过状态机的管理后，用户可以直观看到App、AppAttempt、Container、Node的状态，其状态切换也更规范。但是状态机也导致Yarn的代码可能性很差，无法很好调试。 在HDFS中就不需要维护状态机，对于HDFS的操作，只有成功和失败。因此，在代码分析上，更容易对代码进行阅读。 通过https://blog.51cto.com/u_15327484/7995505文章了解到HDFS是GFS之上进行了一些简化，本文在此基础上，分析客户...