1. 背景 presto将event log存储到内存之中。以下两种情况下无法通过web获取SQL历史查询信息： 重启presto coordinator，内存清空，无法通过Web查询历史SQL执行信息。 presto内存只保存100条最新的event log，100条之前的SQL执行记录会被清除。 这大大增加了业务检查SQL执行情况的门槛。为此，需要将Presto的event log持久化。
1. 背景 在https://blog.51cto.com/u_15327484文章中，介绍了Alluxio的架构。本文基于此，介绍Alluxio文件读写流程。Alluxio读写流程几乎和HDFS一致，只是Worker多了一个从UFS读写的选项，本文会省略部分流程，只介绍重点。 2. Alluxio写流程 客户端向Alluxio写数据时，可以指定是否就Alluxio中的数据写到UFS中。写UFS数
1. 背景 对于Hadoop集群而言，将长期没有访问的冷数据放到DataNode中的磁盘存储成本较高，可以将这部分冷数据存储到S3中。这就引入一个问题，虽然Hadoop支持s3a的方式访问s3文件系统，但是访问时需要携带aksk，一旦用户拿到aksk，他们就有随意操控整个S3数据的权限，整个S3数据就不安全了。 为了解决这个安全问题，可以将S3文件系统挂载到Alluxio文件系统中，Alluxio
1. 背景 在alluxio1.8中，alluxio master只支持单节点部署，一旦挂掉，整个集群将不可用。alluxio 2.x后，提供了高可用方案：Alluxio组件中嵌入Apache Ratis代码，由Ratis负责选举leader，Alluxio的各个master在同步edit log时，由Ratis提供edit log的一致性传输。 Ratis服务基于Raft共识算法，该算法保证分布
29. 1. 背景 在https://blog.51cto.com/u_15327484/8260931文章中，详细介绍了通过抓取Yarn web页面的方式获取task级别的进度，并且将task进度通过纵向的历史进度进行预测对比检查作业进度是否符合预期。 对于task级别的进度，不仅可以用作纵向对比，还可以进行横向对比。当多次发生某个节点上执行的task比其他节点节点上执行的task时间高时，就认为该
1. 背景 对于Hadoop集群监控，有基于Linux的硬件告警，比如磁盘，内存，网络带宽告警；有基于组件的告警，例如OOM报警、RPC告警。这些告警能反应个体机器的运行状况，不能反映整个集群的运行状况；同时，这些告警都是在已知的故障指标，但是对于未知的指标，可能已经发生并且对系统产生较大影响，由于没有告警不能及时介入，造成严重的故障。 为了解决上述问题，本文介绍一种基于MapTask进度和Red
1. 背景 在离线集群中，有些冷数据集群专用于存放HDFS数据，很少用来提供计算操作，这些机器的计算资源都浪费了，它们的典型特征是：只启动datanode服务，不启动nodemanager服务。为了提高这些机器的资源利用率，希望在其他计算集群需要资源的时候，resourcemanager可以在冷数据集群中启动NodeManager服务，最大化利用计算资源。 2. 整体设计 如下所示，通过NodeM
1. 背景 众所周知，Hadoop2.6.0版本bug非常多，依次大部分公司都将Hadoop升级为Hadoop3。但是，有些实时flink集群由于作业复杂敏感难以迁移，依然使用Hadoop2.6.0集群作为checkpoint存储路径。 如下所示，实时集群中经常出现Non DFS Used非常高，导致可用磁盘空间非常低的情况： 登入机器中，可以发现磁盘只用了20GB： 因此，可以认为这是HDF
1. 背景 在部署Hadoop集群时，作为集群运维人员，往往需要了解集群性能。即集群能够处理数据的上限，集群的瓶颈等信息。特别是在上线一批尚未使用过的机型、磁盘时，更需要了解这些硬件上的变更是否会对集群整体性能有影响。本文介绍当DataNode挂载juicefs情况下，集群的性能表现；并且和只挂载Disk磁盘时的性能进行对比。 2. HDFS压测工具介绍 Terasort：基于MapReduce
1. 背景 在HDFS中，默认是通过setacl和getacl命令的方式增加和查询hdfs的acl信息。为了了解acl信息，需要亲自登陆机器执行hdfs命令，对于没有机器权限的业务人员非常不友好；同时，运维人员无法浏览HDFS所有acl信息，对于管理来说也不透明。 为了解决该问题，引入了Ranger组件，将acl信息存放到Ranger组件中。HDFS在鉴权时，会从Ranger组件获取相关权限，Na
1. 背景 在执行HDFS命令时，通常会设置环境变量，在执行具体操作。例如： export HADOOP_CONF_DIR=/home/hadoop/conf/cluster1 hdfs dfs -ls hdfs://cluster1/data/xxx 在执行脚本时，我往往会有两个疑问： hdfs命令如果加载HADOOP_CONF_DIR配置的，加载后发生了什么。 Java如果解析-ls操作，
1. 背景 在HDFS分布式系统中，经常会上线新的datanode以环境集群容量不足的问题。但是往往旧datanode水位较高，甚至爆满无法写入，新datanode非常空闲，导致旧机器无法写入数据，集群的流量集中到新datanode中，造成新datanode网络延迟。 为了解决上述问题，可以通过Balancer工具定时讲高水位datanode的block迁移到低水位的datanode中。 bala
1. 背景 一般情况下，用户会以项目为维度提交作业。因为项目用户的拥有项目下的所有权限。如下所示，个人用户bob将在project_sa项目空间下提交作业，HDFS会通过project_sa进行鉴权并访问： 上述方案有一个问题，如果HDFS中的auditlog中记录的操作用户是project_us，无法分辨具体由哪个用户提交的作业。如果能够在auditlog中增加真实提交的用户，在作业相关问题时
1. 背景 https://blog.51cto.com/u_15327484/8193991介绍了海外Hadoop集群一般将冷数据放入到AWS S3或者存放到Google gcs对象存储中。这些对象存储都提供了各自的客户端进行访问，例如aws s3的客户端命令就是aws s3；gcs的客户端命令是gsutil。这些命令一般需要直接登陆到授权机器中执行，比较麻烦。 为了解决这个问题，AWS S3和
1. 背景 对于HDFS集群而言，不可避免会将一个集群中的数据迁移到另外一个集群中。一般以下几种情况需要进行迁移： hadoop2集群中的项目数据迁移到hadoop3中。 hadoop rbf的一个子集群block数量在2亿～3亿，需要将大项目迁移到其他空闲子集群。 海外项目数据由于历史原因存放到国内集群，根据政策原因，需要迁移到海外。 在数据迁移时，可以使用HDFS提供的distcp工具进行
1. 背景 HDFS存储的数据，一般情况下，创建时间越新的数据，访问次数越频繁；创建时间越久远的数据，访问频次越低。在HDFS集群中，默认情况下，所有数据都存放在同一类型介质中，大量访问频次低的数据没有被访问，浪费磁盘的性能。 为了合理的降低成本，可以将访问次数频繁的数据存放在高速存储介质中，这样用户访问这部分数据很快；将访问频率低的数据存放到低速存储介质中，即使读取速度慢，但是频次低，对业务使用
1. 背景 在Hadoop2.8版本之前，HDFS只支持Federation。在https://blog.51cto.com/u_15327484/8133284文章中介绍过，Federation + ViewFS可以降低用户使用门槛。但是由于需要在客户端的mountTable.xml文件中维护viewFS到HDFS的路径映射，容易产生安全性和难以维护的问题。viewfs Based Federa
1. 背景 在https://blog.51cto.com/u_15327484/8153877文章中，介绍了在Java中，客户端通过JAAS框架向AS认证获取TGT，再通过GSSAPI on SASL获取service ticket并向服务端进行认证。 Hadoop中整合Kerberos安全认证机制，当HDFS客户端访问NameNode服务端时，HDFS客户端先获取TGT，再获取service
1. 背景 https://blog.51cto.com/u_15327484/8153877文章中，详细介绍了Hadoop中使用kerberos机制进行认证。在客户端初次访问服务端时，通过JAAS获取TGT，再通过GSSAPI on SASL获取service ticket完成认证。 在用户向Yarn提交作业时，如果作业有上万个container，每个container都会访问HDFS的NameNod
1. 背景 客户端登陆服务端时，一般要进行认证。认证是指用户将自己的密码信息放到服务端，客户端访问服务端时，服务端检测到传输过来的密码和保存的密码一致，就认为用户有权访问服务端。如果不一致，那么用户无法通过密码证明自己的身份，就无权访问服务端。 这种传统的认证方式有以下问题： 服务端要额外进行任务工作，增加了服务端的代码复杂度。 客户端在网络中传输账号密码容易泄漏。 Kerberos认证系统就
1. 背景 在Hadoop2.0之前，一个Hadoop集群只支持一对主备NameNode。如下所示，集群中的数据接近2.2亿block，会导致NameNode内存中的文件系统树过大，占用较多内存；同时NameNode crash后启动时，由于需要加载过多的block，导致启动时间过长。 集群 每日写入block 每日净增block 每日数据净增长 当前block数 空间使用率 集群A
1. 背景 在Hadoop2.0前，NameNode存在单点问题，造成服务稳定性差。Hadoop2.0后，引入HA机制，通过zk选举的方式选举active节点提供服务。 在https://blog.51cto.com/u_15327484/7850359一文中，介绍过resourmanager高可用过程。NameNode HA在选举流程上和resourmanager一致，但是，为了降低复杂度，同时
1. 背景 在Hadoop2.x之前，只有一台NameNode负责对外提供服务，另外一台secondary NameNode只用于合并fsimage，不提供对外元数据服务。因此NameNode和secondary NameNode都存在单点问题。 为了解决secondary NameNode单点问题，HDFS引入多个JournalNode服务存储操作日志，取代单台secondary NameNod
1. 背景 文件内容的变更往往意味着block信息的变更，在datanode中，变更的block会发送给namenode，namenode会更新block信息。本文将介绍datanode心跳流程和block块汇报流程。 2. DataNode心跳线程模型 在Hadoop Federation架构中，一般由一对Active/Standby NameNode为一组作为一个namespace，每个nam
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读文件流程来说相对简单
1. 背景 在https://blog.51cto.com/u_15327484/8023493和https://blog.51cto.com/u_15327484/8089923两篇文章中，分别详细介绍了客户端和Namenode在HDFS写流程的处理逻辑。本文将介绍DataNode接收数据的流程，本文省略与NameNode交互细节，专注于数据的发送与接收。 2. DataNode事件处理线程模型
1. 背景 在https://blog.51cto.com/u_15327484/8023493文章中，介绍了HDFS创建文件时，客户端执行的操作。对于NameNode而言，在创建文件的过程中，它会接受客户端以下rpc请求： create addBlock complete 本文将详细介绍这三个RPC在NameNode端的处理流程，同时扩展介绍Namenode相关架构。 2. NameNode
1. 背景 在Hadoop Yarn中，App、AppAttempt、Container、Node都有自己的生命周期，因此Yarn实现了一套状态机进行管理。通过状态机的管理后，用户可以直观看到App、AppAttempt、Container、Node的状态，其状态切换也更规范。但是状态机也导致Yarn的代码可能性很差，无法很好调试。 在HDFS中就不需要维护状态机，对于HDFS的操作，只有成功和失
1. HDFS起源：GFS 1.1 分布式文件系统起源 在1990年前，信息技术不够普及，对于文件的存储，往往都是一整个文件存储到单台机器。随着互联网技术的发展，互联网也可以将成千上万的计算机作为存储连接在一起。 同时，对于企业而言，其文件越来越大，越来越多，导致单台机器没有空间存储这种大文件；同时，这种大文件读取和写入变得非常耗时。 分布式文件系统的提出就是为了解决这类问题： 将大文件条带化地
1. 背景 一般离线Hadoop集群和在线Hadoop集群都是分开部署的，他们的计算资源互相隔离。离线集群一般0:00~08:00作业较多，集群压力大，其他时间段集群较为空闲。实时集群高峰期一般为10:00~20:00，其他时间段较为空闲。空闲时资源利用率低，是对资源的浪费，而离线/实时集群在高峰期资源紧张时，往往选择通过加机器来实现扩容，又增加成本。 传统的集群部署方式，不仅没有利用空闲下来的资
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
