云海Insight HD V4.6.5技术白皮书

云海InsightHDV4.6.5技术白皮书浪潮（北京）电子信息产业有限公司2020年5月云海InsightHDV4.6.5规格指标产品概述需求及背景当前，新一代信息技术正在快速改变着我们的生活方式，数据已经成为组织和企业的核心资产，数字经济正在驱动新一轮的社会变革，政府和企业的数字化转型已经成为大数据时代的一种趋势。为了应对行业转型和产业升级的需要，越来越多的用户开始向大数据运营模式转型。Hadoop技术经过多年的蓬勃发展，使大数据技术真正承托起一大批企业的数据基础架构。大数据平台需要建设成为一个高可靠性、高安全性、高性能、可扩展性、容错性俱全的先进系统；用来对数据进行存储、计算、检索、分析、查询和管理等操作。开源的大数据生态体系中，各个组件更新升级频繁，组件之间存在兼容性、稳定性问题，也缺乏技术支持，距离落地为企业级产品仍然有较大差距。浪潮基于丰富的行业大数据实践经验，选择符合主流技术发展方向的开源组件，并进行功能增强、性能优化、统一管理、安全保障等，发布了企业级大数据平台云海InsightHD。云海InsightHD提供了多源数据的高效集成、异构超媒体数据的海量存储、场景丰富的计算框架、海量数据的实时分析挖掘、统一的平台化管理监控、便捷易用的数据操作、立体化的数据安全等能力。能够使用户可以在生产中可靠地使用Hadoop，同时又可以从开源社区借助到持续无穷创新的最佳方案。产品定位企业级大数据平台云海InsightHD是浪潮面向多源异构超媒体数据融合构建数据生态的核心平台，也是浪潮“云数智”技术堆栈中的重要组成部分。云海InsightHD内置了大数据生态中的20多种常用组件，提供统一的平台化管理运维能力，实现了重点功能深度增强和性能优化；提供PB级别数据的多源采集、统一存储和多引擎计算、数据高效处理、任务编排、安全管理等全过程治理能力。作为业界领先的企业级分布式大数据处理环境，云海InsightHD除了包含业界流行的基于开源Hadoop及其生态组件构建的核心，还包含了很多为支撑企业级业务的高级管理特性。借助于云海InsightHD成熟的整体方案，政府或企业可以放心将数据整合在云海InsightHD进行数据创新，进而专注于自己的业务能力。产品价值浪潮云海InsightHD，被广泛应用在海量文本实时搜索、多维数据交互分析式挖掘和比对碰撞、统一平台的数据开放共享、流数据实时计算、海量数据挖掘分析等行业业务场景中；同时也是浪潮企业云、政务云平台中分布式计算服务（托管Hadoop服务、流式计算服务、数据科学探索服务等）的核心技术组件。用户可以基于云海InsightHD产品快速搭建起安全可靠、高效智能的数据湖平台，实现传统产业数字化、智能化的转型。从宏观层面，政府数据及互联网数据的开发利用已进入新的阶段，产品将推动政府数据社会化流通、市场化运营，助力数字经济建设及大数据产业发展。数据运营将进一步整合政府数据、社会数据、互联网数据，建立起安全可靠、快速精准、高效满意的政府数据社会化利用的纽带和桥梁，服务于社会治理、公共安全、企业经营等领域，充分挖掘数据价值，激发创新创业活力，推动数字经济的发展。产品特性云海Insight加强版将Hadoop生态系统的力量带给客户，产品具有如下关键特性：灵活性可以存储任意类型的数据并可以使用多种不同的处理框架对数据进行处理，如批处理、交互式SQL、文本查询、机器学习和统计分析计算。集成化快速建立并快速运行于一个完整的包装好的基于ApacheHadoop的系统。安全性方便处理和控制敏感的数据，提供多租户的运行保护机制。可扩展为广泛的应用提供运行设施，并随着业务成长支持灵活弹性扩展。高可用可以应对多任务高负载的应用场景，保证集群的稳定。兼容性扩充和利用现有的基础架构，保护投资。开放性受益于高速的创新，并且无需受制于专有供应商的锁定。产品应用场景大数据的典型应用场景主要有：批处理(ETL)在线服务实时数据分析全文检索不同的应用场景，所用到的组件及架构有些差异，具体分析如下：批处理ETL批处理的特点是处理时间窗口比较长，通常输入输出的数据量都比较大，诸如数据的装载、转换以及清洗等等。批处理的数据源一般会来自于传统的OLTP系统、数据仓库、客户关系库或是一些线上的应用服务器。可以通过Flume或者Sqoop导入到HDFS上，作为原始数据存放。如果合适，可以将这部分原始数据转载成列式存储的文件格式。之后可以借助一些图形化的配置工具或者脚本来定义ETL的处理流程，调用Hive来完成数据处理。执行引擎可以选择MapReduce或者是Spark。处理完之后生成的中间结果，建议采用列式存储。在线服务应用与传统的在线应用相比，基于HBase的方案优势在于：良好的水平可扩展性、高可靠性及高并发性。在线应用的数据源主要有两种：一种是存量数据，来源于DW或者一些备份库上；还有一种来自于线上系统实时产生的数据。对于存量数据可以先导入到HDFS上，然后通过批处理引擎加载进HBase库。数据先加载进HDFS，有几个原因：1）可以减少对其他系统的依赖；2）提高加载的性能（如果从其他系统直接加载入HBase，系统之间的数据访问性能得不到保障）；3）载入的HDFS数据可以用于OLAP的应用。对于实时数据可以通过Flume或者Kafka采集进来，借助于SparkStreaming对实时数据做一些过滤或者统计（这个处理过程可选），然后载入HBase，通过HBase的API或者SQL前端（如ApachePhoenix）进行在线数据查询。实时数据分析实时数据分析的时间窗口一般都在秒级，如实时的文本搜索、实时推荐引擎等。这种分析的数据源一般都来自线上系统，或是外部捕获的实时数据。获取的数据可以通过Flume和Kafka加载入Hadoop平台，数据一方面可以存入HDFS，其中保存了全量数据，可以对数据做全量的或者批量的分析；另一方面数据可以经过SparkStreaming引擎，它只是对一个很小的时间窗口数据进行分析。在HDFS上的数据可用于建模，模型可以存入分布式数据库，并做定期的模型修正。实时处理模块可以从分布式数据库中获取相应的模型，并对实时数据使用模型计算出实时的结果，这些结果可以用于线上系统的实时展现。全文检索基于ElasticSearch的全文搜索解决方案，用于在企业内部构建实时的大数据搜索引擎。可以将离线数据批量导入到ElasticSearch存储中，再通过Kafka、在线应用等实时数据管道接入最新数据。开箱即用的高适用性配置，支持多种文本分词技术索引数据，功能强大的查询表达式（QueryDSL）使开发者无需了解底层架构就可以开发出高效的搜索引擎。

总体架构架构图组件说明InsightHD包含Manager和众多组件，分别提供功能如下：Manager为InsightHD提供高可靠、安全、容错、易用的集群管理能力，支持大规模集群的安装部署、监控、告警、用户管理、权限管理、审计、服务管理、健康检查、问题定位、升级、补丁等。Hue提供了图形化用户Web界面。支持展示多种组件。Flume一个分布式、可靠和高可用的海量日志聚合系统，支持在系统中定制各类数据发送方，用于收集数据；此外它提供了对数据进行简单处理和写入各种数据接收方的能力。Hive建立在Hadoop之上的数据仓库，提供类似于SQL的HQL语言、操作结构化数据存储服务和基本的数据分析服务。MapReduce提供快速并行处理海量数据的能力，是一种分布式数据处理模式。Spark基于内存的大规模数据处理的快速通用引擎。Solr一个高性能，基于Lucene的全文检索服务器。Solr对Lucene进行了扩展，提供了比Lucene更为丰富的查询语言，同时实现了可配置、可扩展，并对查询性能进行了优化。提供了一个完善的功能管理界面，是一款非常优秀的全文检索引擎。Oozie提供了对Hadoop组件的任务编排、执行的功能。以JavaWeb应用程序的形式运行在Javaservlet容器（如：Tomcat）中，并使用数据库来存储工作流定义当前运行的工作流实例（含实例的状态和变量）。Kafka一个分布式的、分区的、多副本的实时消息发布和订阅系统。提供可扩展、高吞吐、低延迟、高可靠的消息分发服务。YARN资源管理系统，它是一个通用的资源模块，可以为各类应用程序进行资源管理和调度。HDFSHadoop分布式文件系统，提供高吞吐量的数据访问，适合大规模数据集方面的应用。HBase提供海量数据存储功能，是一种构建在HDFS之上的分布式、面向列的存储系统。Zeppelin基于网络的笔记本，支持交互式数据分析。能够使用SQL、Scala等工具生成交互协作文档。ZooKeeper提供分布式、高可用性的协调服务能力。帮助系统避免单点故障，从而建立可靠的应用程序。Tez是一个支持DAG作业的计算框架，可以将多个有依赖的作业转换为一个作业从而大幅提升DAG作业的性能。SqoopHadoop和结构化数据存储（如关系数据库）之间的数据交换工具。Storm是一个分布式实时计算系统，可以简单、可靠地处理大量的数据流。可以集成队列和数据库系统，主要用例有：实时分析、在线机器学习、分布式RPC和ETL等。Ranger是一个跨Hadoop平台的管理和监控数据安全的框架。提供对Hadoop组件的授权和审计服务。Phoenix是HBase的SQL驱动，它使得HBase支持通过JDBC的方式进行访问，并将Sql查询转换成HBase的扫描和相应的动作。Kerberos是一种应用对称密钥体制进行密钥管理的系统。采用客户端/服务器结构与DES加密技术，并且能够进行相互认证，即客户端和服务器端均可对对方进行身份认证。可以用于防止窃听、防止replay攻击、保护数据完整性等场合。ElasticSearch基于Lucene的分布式、高扩展、高实时的搜索与数据分析引擎，具备存储、搜索、快速实时分析大量数据等特性。OpenTSDB基于HBase的分布式、可伸缩的时间序列数据库。DataSpaceDataSpace是一个简单易用的大数据集群资源管理系统。用户可以轻松通过界面或RestAPI创建自己的数据空间，并将数据空间中的资源共享给其他用户使用。ML适合各水平开发人员利用和学习机器学习技术的Web工具。用户可通过界面的引导操作完成机器学习模型的创建，并提供结果预测。RedisRedis提供一个内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。

NiFi 一个易用、强大、可靠的系统，用于处理和分发数据。LogSerach 提供日志聚合、分析和可视化服务。

产品功能Manager功能描述为InsightHD提供高可靠、安全、容错、易用的集群管理能力，支持大规模集群的安装部署、监控、告警、用户管理、权限管理、审计、服务管理、健康检查、问题定位、升级、补丁等。解决Hadoop生态系统部署Hadoop部署时，组件间有依赖，包括配置、版本、启动顺序、权限配置等问题。Manager能够进行部署过程跟踪，展示部署过程中每个步骤的状态及相关信息。随着集群规模的不断增加，机器出问题概率也会增加，在部署或更新中可能会出现故障。Hadoop及其组件需要允许机器的故障，同时需要防止不兼容版本组件给系统带来的影响。Manager部署服务时，能够容忍某些组件启动、更新失败。配置管理可以将默认配置写入stack中，在开启时Manager读取stack中各个版本的config文件，在使用blueprint创建集群部署Hadoop时，直接生成command-json文件。服务状态展示、监控，报警预先配置好关键的运维指标（metrics），可以直接查看HadoopCore（HDFS和MapReduce）及相关组件（如HBase、Hive和HCatalog）的健康状况。支持作业与任务执行的可视化与分析，能够更好地查看依赖和性能。通过一个完整的RESTfulAPI把监控信息暴露出来，集成了现有的运维工具。用户界面非常直观，用户可以轻松有效地查看信息并控制集群。架构原理在Manager-server开放的RestAPI中分为主要的两大类API，其中一类为Manager-web提供监控管理服务，另一类用于与Manager-agent交互，接受Manager-agent向Manager-server发送的心跳请求。Master模块接受API和AgentInterface的请求，完成Manager-server的集中式管理监控，而每个agent节点只负责所在节点的状态采集及维护工作。Agent内部架构：Agent是一个无状态的，其功能分两部分：采集所在节点的信息并且汇总发送心跳报告给server；处理server的执行请求。因此它有两种队列：消息队列MessageQueue，或称为ResultQueue。包括节点状态信息（包括注册信息）和执行结果信息，并且汇总后通过心跳发送给server。操作队列ActionQueue。用于接收server发送过来的状态操作，然后交给执行器调用puppet或Python脚本等模块执行任务。Manager-server内部架构：LiveClusterState：集群现有状态，各个节点汇报的状态信息会改变该状态;DesiredState：用户希望该节点所处状态，是用户在页面进行了一系列的操作，需要更改某些服务的状态，这些状态还没有在节点上产生作用;ActionState：操作状态，是状态改变时的请求状态，也可以看作是一种中间状态，这种状态可以辅助LiveClusterState向DesiredState状态转变。Manager-server的HeartbeatHandler模块用于接收各个agent的心跳请求（心跳请求里面主要包含两类信息：节点状态信息和返回的操作结果），把节点状态信息传递给FSM状态机去维护该节点的状态，并且把返回的操作结果信息返回给ActionManager去做进一步的处理。Coordinator模块又可以称为APIhandler，主要在接收WEB端操作请求后，会检查它是否符合要求，stageplanner会分解成一组操作，最后提供给ActionManager去完成执行操作。因此，从上图就可以看出，Manager-Server的所有状态信息的维护和变更都会记录在数据库中，用户更改服务的操作都会在数据库上有相应的记录，同时，agent通过心跳来获得数据库的变更历史。特性与平台无关该系统体系结构支持多种硬件和操作系统，如RHEL，SLES，Ubuntu，Windows等。可插拔组件该架构不限定具体的工具和技术，任何具体的工具和技术都可以通过可插拔的组件封装。版本管理和升级各个节点上运行Manager组件支持多个版本的协议，该协议支持组件的独立升级。任何Manager的组件的升级不影响集群状态。可扩展性可以轻松添加新的服务，组件和API。

扩展性也意味着易于为Hadoop栈修改任何配置或provisioning步骤。故障恢复能够从任何元件故障恢复到一致的状态，恢复后应尽量完成挂起操作。如果错误是不可恢复的，那么应该使系统处于一致状态。安全认证和Manager用户（包括API和WebUI）的基于角色的授权、安装、管理和监控Hadoop的堆栈，通过Kerberos授权，以及认证和加密Manager组件之间的通信。错误跟踪能够提供错误跟踪的能力，并且提供错误分析信息方便用户排错。操作的准实时反馈对于需要一段时间才能完成操作，系统需要能够及时（准实时）向用户提供反馈当前正在运行的任务的进展，操作完成的百分比，操作日志的链接等。企业级增强一键式安装Manager的WebUI提供向导式的集群安装步骤，用户根据界面引导可一步步完成集群安装。无人值守安装Manager提供智能无人值守安装模式，按照最新RA架构，可以最大化的利用集群性能，自动分配各节点适合安装的组件。此模式，只需简单配置好网络，设置必要参数，即可自动快速部署高可用集群。完善的告警体系Manager为用户提供界面化的系统运行环境自动检查服务，帮助用户实现一键式系统运行健康度巡检和审计，保障系统的正常运行，降低系统运维成本。用户查看检查结果后，还可导出检查报告用于存档及问题分析。系统可靠性所有组件的管理节点均实现HA。Hadoop开源版本的数据、计算节点已经是按照分布式系统进行设计的，单节点故障不影响系统整体运行；而以集中模式运作的管理节点可能出现的单点故障，就成为整个系统可靠性的短板。InsightHD产品对所有业务组件的管理节点都提供了类似的双机机制，包括HDFSNameNode、HiveServer、HBaseHMaster、YARNResourcesManager、KerberosServer等，全部采用主备或负荷分担配置，有效避免了单点故障场景对系统可靠性的影响。数据可靠性InsightHD通过对节点硬件（特别是硬盘）、操作系统、进程的监控，及时发现相关部件的异常状况，缩短了对应部件的故障检测时间和修复时间，从而提高了整体系统的可靠性。ZooKeeper功能描述ZooKeeper可为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册等功能。其目标是封装复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。它主要提供以下功能:数据订阅/发布发布者将数据发布到ZooKeeper的一个或一系列节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，从而实现配置信息的集中式管理和数据的动态更新。负载均衡分布式系统具有对等性，为了保证系统的高可用性，通常采用副本的方式来对数据和服务进行部署。对消费者而言，则需要在这些对等的服务提供方中选择一个来执行相关的业务逻辑，ZooKeeper则很好的解决了这个问题。命名服务在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些都可以统称为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZooKeeper提供的创建节点的API，能够创建一个全局唯一的path，这个path就可以作为一个Name。集群管理客户端如果对ZooKeeper的一个数据节点注册Watcher监听，那么当该数据节点的内容或时其子节点的列表发生变更时，ZooKeeper服务器就会向订阅的客户端发送变更通知。而对在ZooKeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么该临时节点也就被自动清除。分布式锁有了ZooKeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。对于第一类，将ZooKeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建/distribute_lock节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock节点就释放出锁。对于第二类，/distribute_lock已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除。ZooKeeper与HDFS的关系ZKFC（ZKFailoverController），用来监控NameNode的状态信息。ZKFC仅仅部署在NameNode中，ActiveNameNode和StandbyNameNode节点中均部署ZKFC进程。HDFSNameNode连接到ZooKeeper，把主机名等信息保存到ZooKeeper中，即“/Hadoop”下的znode目录里。先创建znode目录的NameNode节点为主节点，另一个为备份节点。HDFSNameNodeStandBy通过ZooKeeper定时读取NameNode信息。当主节点进程异常结束时，HDFSNameNodeStandBy通过ZooKeeper感知“/Hadoop”目录下发生了变化，NameNode会进行主备切换。ZooKeeper与YARN的关系YARN采用了基于ZooKeeper的ActiveStandbyElector实现Active节点的选取，不需要像HDFS那样需要单独的ZKFC进程。在系统启动时，ResourceManager会尝试把state信息写入ZooKeeper,第一个成功把state信息写入ZooKeeper的ResourceManager被选举为ActiveResourceManager，其他的为StandByResourceManager。StandByResourceManager定时去ZooKeeper读取信息。ResouceManager的state信息保存在ZooKeeper中，发生故障转移时，新选取的ResouceManager从ZooKeeper中读取RMstate信息进行恢复。ZooKeeper和HBase的关系HRegionServer把自己以Ephemeral方式注册到ZooKeeper中。其中ZooKeeper存储HBase的如下信息：HBase元数据、HMaster地址。HMaster通过ZooKeeper随时感知各个HRegionServer的健康状况，以便进行控制管理。HBase也可以通过部署多个HMaster，类似HDFSNameNode，当HMaster主节点出现故障时，HMaster备用节点会通过ZooKeeper获取整个集群的状态信息。即通过ZooKeeper实现避免HBase单点故障问题。架构原理ZooKeeper中的角色主要有三种，如下表所示：角色描述领导者（Leader）领导者进行投票的发起和决议，更新系统状态学习（Learner）跟随者（Follower）Follower用于接收客户请求并向客户端返回结果，在选主过程中参与投票观察者（Observer）Observer可以接收客户端连接，将写请求转发给leader节点。但Observer不参加投票过程，只同步leader的状态。Observer的目的是为了扩展系统，提高读取速度客户端（Client）请求发起方系统模型如图所示：一个ZooKeeper集群通常由一组机器组成，一般3-5台机器就可以组成一个可用的ZooKeeper集群了。组成ZooKeeper集群的每台机器都会在内存中维护当前服务器状态，并且每台机器之间都保持着通信。只要集群中存在超过一半的机器能够正常工作，那么整个集群就能正常对外服务。ZooKeeper的客户端程序会选择和集群中任意一台机器共同创建一个TCP连接，一旦客户端和某台ZooKeeper服务器之间的连接断开后，客户端会自动连接到集群中的其他机器。特性1.高可用在ZooKeeper集群中，读可以从任意一个ZooKeeperServer读，写的请求会先提交到Leader，然后由Leader来通过ZooKeeper中的原子广播协议，将请求广播给所有的Follower，Leader收到一半以上的写成功的ACK后，就认为该写操作成功了，就会将该写操作进行持久化，并告诉客户端写成功了。2.WAL和Snapshot对于每一个更新操作，ZooKeeper都会先写WAL,然后再对内存中的数据做更新，然后向Client通知更新结果。另外，ZooKeeper还会定期将内存中的目录树进行Snapshot，保存到磁盘上。这么做的主要目的，一是数据的持久化，二是加快重启之后的恢复速度。3.有序ZooKeeper使用时间戳来记录导致状态变更的事务性操作，也就是说，一组事务通过时间戳来保证有序性。基于这一特性。ZooKeeper可以实现更加高级的抽象操作，如同步等。HDFS功能描述Hadoop分布式文件系统（HadoopDistributedFileSystem）能提供高吞吐量的数据访问，适合大规模数据集方面的应用，为海量数据提供存储。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。HDFS具有高容错性的特点，并且设计用来部署在低廉的硬件上。HDFS放宽了POSIX的要求，这样可以实现流的形式访问文件系统中的数据。此外HDFS提供了高可用架构（HA）保证了集群的可用性。快照快照支持在一个特定时间存储一个数据拷贝，快照可以将失效的集群回滚到之前一个正常的时间点上。HDFS已经支持元数据快照。数据块HDFS的设计是用于支持大文件的。运行在HDFS上的程序也是用于处理大数据集的。这些程序仅写一次数据，一次或多次读数据请求，并且这些读操作要求满足流式传输速度。HDFS支持文件的一次写多次读操作。HDFS中典型的块大小是128MB，一个HDFS文件可以被被切分成多个128MB大小的块，如果需要，每一个块可以分布在不同的数据节点上。流水式复制当客户端写数据到HDFS文件中时，数据首先被写入本地文件中，假设HDFS文件的复制因子是3，当本地文件堆积到一块大小的数据，客户端从NameNode获得一个数据节点的列表。这个列表也包含存放数据块副本的数据节点。当客户端刷新数据块到第一个数据节点。第一个数据节点开始以4kb为单元接收数据，将每一小块都写到本地库中，同时将每一小块都传送到列表中的第二个数据节点。第二个数据节点将小块数据写入本地库中同时传给第三个数据节点，第三个数据节点直接写到本地库中。一个数据节点在接前一个节点数据的同时，还可以将数据流水式传递给下一个节点，所以，数据是流水式地从一个数据节点传递到下一个。HDFS与HBase的关系HDFS作为HBase的文件存储系统，为其提供了高可靠的底层存储支持。HBase中的数据文件可以存储在HDFS文件系统上。HDFS与MapReduce的关系在MapReduce程序中计算的数据可以来自多个数据源，如LocalFile、HDFS、数据库等。最常用的是HDFS，可以利用HDFS的高吞吐性能读取大规模的数据进行计算。同时在计算完成后，也可以将数据存储到HDFS。架构原理HDFS是一个的主从结构，一个HDFS集群是由一个NameNode节点和一些DataNode节点组成。NameNode是一个管理文件命名空间和调节客户端访问文件的主服务器。DataNode通常是一个节点一个机器，它来管理对应节点的存储。HDFS对外开放文件命名空间并允许用户数据以文件形式存储。内部机制是将一个文件分割成一个或多个块，这些块被存储在一组DataNode中。NameNode用来操作文件命名空间的文件或目录操作，如打开，关闭，重命名等等。它同时确定块与DataNode的映射。DataNode负责来自文件系统客户的读写请求。DataNode同时还要执行块的创建，删除，和来自NameNode的块复制指令。NameNode和DataNode都是运行在普通的机器之上，机器都是GNU/Linux，HDFS是用java编写的，任何支持java的机器都可以运行NameNode或DataNode，利用java语言的轻便特性，很容易将HDFS部署到大范围的机器上。典型的部署是由一个专门的机器来运行NameNode，集群中的其他每台机器运行一个DataNode实例。集群中只有一个NameNode极大地简单化了系统的体系结构。NameNode是仲裁者和所有HDFS元数据的仓库，用户的实际数据不经过NameNode。HDFSHA架构HA即为高可用性，定义为系统对外正常提供服务时间的百分比。HDFS由NameNode和DataNode两类节点组成，由于NameNode只有1个，且负责整个HDFS文件系统的管理和控制，因此当NameNode不能提供正常服务时，会直接导致HDFS不能对外正常服务，因此NameNode的可靠性是影响HDFS可靠性的重要因素。因此在一个HDFSHA中，通常由两个NameNode组成，一个处于Active状态，一个处于Standby状态。一旦ActiveNameNode出现问题，Standby状态的NameNode就会迅速切换至Active状态并继续提供服务。特性处理超大文件这里的超大文件通常是指百GB、甚至数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。运行于廉价的X86服务器上Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。流式数据访问HDFS的设计建立在更多地响应"一次写入、多次读写"任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。高吞吐比关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐。高可用提供对高可用性的支持，当活动NameNode失效，备用NameNode就会接管它的任务并开始服务于来自客户端的请求，而不会有任何明显的中断。数据安全支持对存储在HDFS上的数据进行加密，保证数据的安全存储。企业级增强HDFS的元数据信息，包括文件信息，块信息等，都存储在NameNode中，一般当存储的文件数大于1亿时，NameNode就成为瓶颈。通过增强，每次扩容一对NameNode，保障可靠性，从而突破文件存储数量的限制，最终可达到10亿以上的文件。这是HDFS的联邦特性。HDFS纠删码简介Erasurecoding纠删码技术简称EC，是一种数据保护技术。最早用于通信行业中数据传输中的数据恢复，是一种编码容错技术。它通过在原始数据中加入新的校验数据，使得各个部分的数据产生关联性。在一定范围的数据出错情况下，通过纠删码技术都可以进行恢复。因此可以使用纠删码(ErasureCoding)来代替多副本的方式，它使用更少的存储却可以保证相同级别的容错。在典型配置下，与三副本300%的存储开销相比，EC策略的存储开销约为150%。目前HDFSEC已经在HDP3中发布。应用场景HDFSEC在数据容错与存储效率中具有显著的优势，以下是一些常用的应用场景：适用于PB级、EB级数据量极大的场景；结合HDFS高吞吐量的优势，EC更适应于需求高写入效率的场景；适合一次写入，多次读取的应用场景；适用于多节点（九节点以上），高网络带宽的应用场景；适用于存有大量冷数据的集群，EC提供了高存储效率的数据存储模式，可减少冷数据的存储空间。功能特性主要功能特性如下所示：（1）处理超大文件与HDFS传统的存储策略相比，当存储GB、TB、PB级超大文件时，EC策略可极大的缩短写入时间。（2）低存储开销相比传统的三副本存储方案，EC可以将存储开销降低约50%。（3）高容错EC主要通过利用纠删码算法将原始的数据进行编码得到校验，并将数据和校验一并存储起来以达到容错的目的。EC可以保证与三副本相同甚至更高级别的容错。（4）EC策略多样性HDFSEC在存储方式上提供给用户更多的策略选择，用户可根据数据热度、集群节点数等信息选择多样化的存储方案。（5）条带化布局条带化布局可以提供比连续布局更好的I/O吞吐量，因为它可以并行的更好的利用多个磁盘。并且，条带式布局的cell大小通常为64KB-1MB，因此可以同时实现小文件和大文件存储空间的节省。（6）操作简单HDFSEC是在目录级别指定EC策略，可通过shell指令完成策略启用、设置、删除等操作，整体操作简单易执行。局限性HDFSEC在具有众多优势的同时，存在着一些弊端和待解决问题，其局限性如下所示：（1）EC会造成两大资源的消耗网络带宽的消耗，因为数据需要去读其他的数据块和校验块；CPU资源的消耗，存入数据时，EC需要进行编码计算，恢复数据时需要进行解码计算。（2）操作限制以EC方式存储的文件，不能执行hflush，hsync和append操作。（3）转换繁琐当目录设置EC策略后，该目录下已有文件不会自动转换为EC策略的存储模式，只有新写入该目录的文件会按照EC策略存储。（4）本地化特性EC条带式的存储布局会导致强依赖数据本地化特性的MapReduce作业消耗大量的网络资源，其工作性能会有所下降。（5）节点及机架数量要求高EC条带式的存储布局虽然具有更好的存储效率，但对集群中的节点和机架数量有更高的要求。以RS-6-3-1024k策略为例，其Datanode节点数应为一个条带上数据块与校验块之和，即9个Datanode。基本概念在存储系统中，纠删码技术主要是通过利用纠删码算法将原始的数据进行编码得到校验块，并将数据块和校验块一并存储起来，以达到容错的目的。其基本思想是将k块原始的数据元素通过一定的编码计算，得到m块校验元素。对于这k+m块元素，当其中任意的m块元素出错（包括数据和校验出错），均可以通过对应的重构算法恢复出原来的k块数据，其存储开销为（k+m）/k。生成校验的过程被成为编码（encoding），恢复丢失数据块的过程被称为解码（decoding）。EC策略EC策略为了适应异构的工作负载，它允许HDFS集群中的文件和目录具有不同EC策略。每个EC策略封装了编码/解码器，其策略由以下信息定义：（1）EC模式：这包括EC组（例如6+3）中的数据和奇偶校验块的数量，以及编解码器算法（例如Reed-Solomon，XOR）。（2）条带化单元的大小：这确定了条带读取和写入的粒度，包括缓存大小和编码工作。（3）策略被命名为：编码/解码器—数据块数—奇偶校验块数—块单元大小。当前，支持五种纠删码策略：RS-3-2-1024k，RS-6-3-1024k，RS-10-4-1024k，RS-LEGACY-6-3-1024k，XOR-2-1-1024k。各个EC策略的编码/解码器、数据容错与存储开销如下表所示。表EC策略详解EC策略编码/解码器数据容错存储开销RS-3-2-1024kRS_NATIVE,RS_JAVA2166%RS-6-3-1024kRS_NATIVE,RS_JAVA3150%RS-10-4-1024kRS_NATIVE,RS_JAVA4140%RS-LEGACY-6-3-1024kRS-LEGACY_JAVA3150%XOR-2-1-1024kXOR_NATIVE,XOR_JAVA1150%条带式布局存储为了管理非常大的文件，分布式存储系统通常将文件划分为固定大小的逻辑块。然后将这些逻辑块映射到集群上的存储块，这反映了集群上数据的物理布局。条带式块布局将逻辑块分成更小的存储单元（通常称为cells），并在一组存储块中以轮询的方式写入单元条带(stripesofcells)。在条形布局下，数据被依次写入条的各个单元中，当条被写满之后就写入下一个条，一个条的不同单元位于不同的数据块中，如下图所示。读取带有条带布局的文件需要查询逻辑块的存储块集，然后从存储块集中读取单元条带。图RS(3,2)条带式布局HDFSEC架构HDFSEC的架构设计同样遵从主从结构，有一个中心的管理对象(ECManager)，然后有对应的worker对象(ECWorker)，这两大角色类有明确的分工。HDFS通过ECPolicy进行控制，每个EC策略对应一种ECSchema参数配置的EC算法。同时这些ECPolicy策略对象被ErasureCodingPolicyManager对象所掌管，如下图所示。图EC策略关系HDFSEC架构主要包含三部分：图HDFSEC架构设计图1.NameNode扩展条带化HDFS文件在逻辑上由块组组成，每个块组包含一定数量的内部块。为了减少这些附加块的NameNode内存消耗，引入了新的分层块命名协议。可以从其任何内部块的ID推断出块组的ID。这允许在块组而不是块的级别进行管理。2.客户端扩展客户端读取和写入路径得到了增强，可以并行处理块组中的多个内部块。在输出/写入路径上，DFSStripedOutputStream管理着一组数据流，每个数据节点一个，在当前块组中存储一个内部块。协调器负责整个块组的操作，包括结束当前块组，分配新的块组等等。在输入/读取路径上，DFSStripedInputStream将请求的逻辑字节数据范围转换为存储在DataNode上的内部块。然后，它并行发出读取请求。发生故障时，它将发出其他读取请求以进行解码。3.DataNode扩展DataNode运行附加的ErasureCodingWorker（ECWorker）任务，用于对失败的EC块进行后台恢复。NameNode检测到失败的EC块，然后NameNode选择一个DataNode进行恢复工作。恢复任务作为心跳响应传递。此过程类似于失败时如何重新复制复制的块。重建执行三个关键任务：（1）从源节点读取数据：使用专用线程池从源节点并行读取输入数据。基于EC策略，它计划对所有源目标提出读取请求，并仅读取最少数量的输入块以进行重建。（2）解码数据并生成输出数据：从输入数据解码新数据和奇偶校验块。所有丢失的数据和奇偶校验块一起解码。（3）将生成的数据块传输到目标节点：解码完成后，恢复的块将传输到目标DataNode。常用操作HDFS提供了一个ec命令来执行与纠删码有关的管理命令。hdfsec[genericoptions][-setPolicy-path<path>[-policy<policyName>]][-getPolicy-path<path>][-unsetPolicy-path<path>][-listPolicies][-addPolicies-policyFile<file>][-listCodecs][-enablePolicy-policy<policyName>][-disablePolicy-policy<policyName>][-help[cmd...]]以下是每条指令的操作细节：[-setPolicy-path<path>[-policy<policyName>]]在指定路径的目录上设置擦除编码策略。path：HDFS中的目录。这是必填参数。设置策略仅影响新创建的文件，而不影响现有文件。policyName：用于此目录下文件的EC策略。如果设置了“node.ec.system.default.policy”配置，则可以省略此参数。路径的EC策略将在配置中设置为默认值。[-getPolicy-path<path>]获取指定路径下文件或目录的EC策略的详细信息。[-unsetPolicy-path<path>]取消设置先前对目录上调用setPolicy所设置的EC策略。如果目录从上级目录继承了EC策略，则unsetPolicy是NOOP（无操作）。注意，在没有明确EC策略设置的目录上取消EC策略将不会返回错误。[-listPolicies]列出在HDFS中注册（启用，禁用和删除状态下）的所有EC策略。只有启用的策略才能够与setPolicy命令一起使用。[-addPolicies-policyFile<file>]添加EC策略列表。请参阅etc/hadoop/user_ec_policies.xml.template获取示例策略文件。最大单元大小在属性“node.ec.policies.max.cellsize”中定义，默认值为4MB。当前，HDFS允许用户总共添加64个策略，并且添加的策略ID在64到127之间。如果已经添加了64个策略，添加策略将失败。[-listCodecs]获取系统中支持的EC解码器和编码器的列表。编码器是编解码器的一种实现。编解码器可以具有不同的实现，因此可以具有不同的编解码器。[-removePolicy-policy<policyName>]删除擦除编码策略。[-enablePolicy-policy<policyName>]启用擦除编码策略。[-disablePolicy-policy<policyName>]禁用擦除编码策略。操作示例一般情况下，设置指定目录的EC策略具体流程如下图所示。图EC策略操作流程查看EC策略列表hdfsec-listPolicies可以看到所有支持的EC策略与其启用状态，默认情况下只有RS-6-3-1024k处于启用状态。查看EC编码/解码器hdfsec-listCodecs启用EC策略hdfsec-enablePolicy-policyRS-3-2-1024k设置EC策略在特定目录上设置EC策略：hdfsec-setPolicy-path/test/dir1-policyRS-6-3-1024k输入指令查看指定目录是否应用了EC策略：hdfsec-getPolicy-path/test/dir1查看EC策略制定目录的块状态hdfsfsck/test/dir1更改EC策略修改/test/dir1目录EC策略：hdfsec-setPolicy-path/test/dir1-policyRS-3-2-1024k修改后提示，/test/dir1路径下已有的文件不会因EC策略修改而自动转换策略，但新写入的文件会按照重新设置的EC策略进行编码。取消EC策略设置hdfsec-unsetPolicy-path/test/dir1纠删码增强ISA-L概述ISA-L全称Intelstorageaccelerationlibrary（Intel存储加速库），包括两个大类：加密和非加密。非加密的有crc、izip、erase-code，加密的包括sha512、sha256、md5、sha1等。核心技术是使用Intelsse/avx/avx2/avx256的扩展指令，并行运算多个流的方法，以实现存储加速。单线程而言，比openssl快2-8倍。纠删码作为ISA-L库所提供的功能之一，其性能是目前业界最佳。需要注意的是Intel采用的性能测试方法与学术界常用的方式略有出入，其将数据块与校验块的大小之和除以总耗时作为吞吐速率，而一般的方法是不包含校验块的。另外，ISA-L未对vandermonde矩阵做特殊处理，而是直接拼接单位矩阵作为其编码矩阵，因此在某些参数下会出现编码矩阵线性相关的问题。但是，ISA-L提供了cauchy矩阵作为第二方案。ISA-L编解码速度快是因为它将整体矩阵运算迁移到汇编中进行，并且实现了增量编码。另外，ISA-L支持的指令集扩展丰富，下至SSSE3，上到AVX512，平台适应性强。在Insight产品中，ISA-L可增强纠删码中的RS编/解码器，提升纠删码文件的IO性能。ISA-L配置在Insight集群中，ISA-L以动态链接库的形式存放在native库。HDFS纠删码默认优先调用native库中的编解码器，因此无需配置就可使用ISA-L。但在一些特殊应用场景中，不适用ISA-L的编解码器，则需进行一些配置。HDFS纠删码中涉及ISA-L的编码解码操作为RS编码算法，其中配置编解码器的使用需在core-site.xml中修改下列属性。<property><name>io.erasurecode.codec.rs.rawcoders</name><value>rs_native,rs_java</value></property>例如，关闭RS算法的ISA-L增强，修改如下：<property><name>io.erasurecode.codec.rs.rawcoders</name><value>rs_java</value></property>上层应用及指令支持上层应用支持根据EC存储现状，上层服务使用EC存在一定的限制，例如EC文件不适用与append()操作等。因此，对于各服务适用EC存储的HDFS目录有着严格的限定，具体适用HDFS目录如下表所示。上层服务HDFS目录存储数据用途HBase/apps/hbase/data/.tmp建表等临时目录/apps/hbase/data/archive归档目录/apps/hbase/data/data表数据目录Hive/warehouse默认存放表数据目录若在HBase、Hive服务中将上述表格外的目录使用EC策略，将导致业务运行失败。指令支持distcp指令当使用distcp的源文件有EC文件时，需要针对不同的需求，添加不同的参数。如果在拷贝过程中，按照目标目录的EC策略将文件重新写入目标目录，则需要在distcp时加入参数：-p和-skipcrccheck。如果在拷贝过程中，按照目标目录的副本策略将文件重新写入目标目录，则需要在distcp时加入参数：-pugp和-skipcrccheck。fsck指令fsck指令通常用于查看副本文件的块信息，对于EC文件fsck指令仍然有效。fsck指令结果中，添加了对于EC文件的块信息报告，如下图所示。其中，包含EC文件的块组数、平均块组大小、块组的健康状态等。HDFS异构存储简介最初HDFS被设计用于同构的硬件环境，然而随着集群硬件的迭代更新，存储介质的硬件异构特性愈发明显。为了充分利用高性能存储介质，提升HDFS的数据访问性能，HDFS实现了异构存储。在异构存储的第一阶段中将数据节点存储模型从单个存储策略更改为存储策略的集合（对应于多个物理存储介质），每种存储策略都对应于一个物理存储介质。添加了存储类型DISK、SSD、ARCHIVE、RAM_DISK的概念，其中DISK是默认存储类型。ARCHIVE具有很高的存储密度（PB级存储），但计算能力却很小，可用于支持归档存储。RAM_DISK以支持在内存中写入单个副本文件。存储策略主要有以下六种：HOT：用于存储和计算。常用数据将以该策略保存。当策略启用时，其所有副本都存储在DISK中。COLD：仅适用于计算量有限的存储。不再使用的数据或需要归档的数据从HOT移动到COLD。当块处于冷状态时，所有副本都存储在ARCHIVE中。WARM：部分热和部分冷。当一个块变热时，其某些副本存储在DISK中，其余副本存储在ARCHIVE中。All_SSD：用于将所有副本存储在SSD中。One_SSD：用于将副本之一存储在SSD中，其余副本存储在DISK中。Lazy_Persist：用于在内存中写入具有单个副本的块。首先将副本写入RAM_DISK，然后将其延迟保存在DISK中。该策略与执行写入操作的客户端相关，第一副本会优先选择客户端所在的DataNode节点，若客户端所在节点未配置RAM_DISK，则会写入所在节点的DISK磁盘。（RAM_DISK不支持Kerberos模式下使用，不支持append操作，例如限制SSM压缩功能使用）存储策略由以下字段组成：策略编号策略名称块放置的存储类型列表用于文件创建的后备存储类型列表用于副本的后备存储类型列表以下是典型的存储策略表：Policy

IDPolicy

NameBlockPlacement

(n

replicas)Fallbackstorages

forcreationFallbackstorages

forreplication15Lazy_PERSISTRAM_DISK:1,DISK:

n-1DISKDISK12All_SSDSSD:

nDISKDISK10One_SSDSSD:1,DISK:

n-1SSD,DISKSSD,DISK7Hot(default)DISK:

n<none>ARCHIVE5WarmDISK:1,ARCHIVE:

n-1ARCHIVE,DISKARCHIVE,DISK2ColdARCHIVE:

n<none><none>注：副本及DataNode数需大于等于2。配置流程HDFS异构存储配置前，需要集群已有其他的存储介质作为支持。配置过程中，将DataNode下存储目录分别挂载至不同存储介质，从而实现异构存储。SSD、ARCHIVE的目录挂载操作与传统磁盘目录挂载相似。RAM_DISK作为内存存储，目录挂载前对系统配置有一定要求。具体配置流程如下所示。配置DISK\SSD\ARCHIVE磁盘分区与格式化对于初装集群而言，需要对每个节点的磁盘设备依次进行分区与格式化操作。以某节点的sdb磁盘设备为例，具体操作如下：fdisk/dev/sdbfdisk操作中应根据需求选择分区表类型、磁盘分区号、磁盘分区起始位置与结束位置等。分区完毕后，进行对应分区的格式化操作：mkfs.xfs/dev/sdb1-f该节点的其他磁盘设备操作相同，重复上述步骤即可。完成磁盘分区与格式化后，即可挂载。挂载DISK\SSD\ARCHIVE目录将完成分区与格式化的磁盘设备挂载至DataNode目录。以挂载三个磁盘设备与目录为例，具体操作如下所示：mkdir-p/hadoop/hdfs/data1mkdir-p/hadoop/hdfs/data2mkdir-p/hadoop/hdfs/data3mount/dev/sdb1/hadoop/hdfs/data1mount/dev/sdc1/hadoop/hdfs/data2mount/dev/sdd1/hadoop/hdfs/data3即完成挂载。配置RAM_DISK修改limits.conf文件Linux对于每个用户限制其使用的内存数，挂载目录前，需先修改各个DataNode节点hdfs用户的内存使用数。其中内存数为bytes，此例以1GB为例：（RAM_DISK不支持Kerberos模式下使用）vim/etc/security/limits.conf挂载RAM_DISK目录首先在配置RAM_DISK的DataNode节点上创建目录，然后使用tmpfs实现内存存储挂载。需保证挂载tmpfs大小与memlock一致：mkdir/hadoop/hdfs/data4sudomount-ttmpfs-osize=1024mtmpfs/hadoop/hdfs/data4挂载完成后，可用df-h查看挂载。注意：RAM_DISK配置与副本数相关，建议RAM_DISK挂载操作只在一个DataNode上操作。修改hdfs-site.xml修改DataNode目录打开Insight管理页面，选择HDFS-配置参数-SETTINGS，修改DataNode目录。其中对于每个data目录前，添加“[]”以指定存储介质：添加dfs.datanode.max.locked.memory属性打开Insight管理页面，选择HDFS-配置参数-ADVANCED-自定义hdfs-site，添加属性以确定专用于存储在内存中的副本内存量。同样的，该属性大小应于小于已挂载的RAM_DISK磁盘空间大小：最后，保存设置重启HDFS即可。常用操作存储策略指令HDFS提供了storagepolicies命令来执行与存储策略相关的管理命令。hdfsstoragepolicies[genericoptions][-setStoragePolicy-path<path>-policy<policy>][-getStoragePolicy-path<path>][-unsetStoragePolicy-path<path>][-listPolicies][-help[cmd...]]以下是每条指令的操作细节：[-setStoragePolicy-path<path>-policy<policy>]在指定路径的目录上设置存储策略。path：HDFS中的目录，这是必填参数。设置策略仅影响新创建的文件，而不影响现有文件。policyName：用于指定此目录下文件的存储策略。注意：该指令是目录级别的设定，其子目录将继承父目录的存储策略。[-getStoragePolicy-path<path>]获取指定路径下文件或目录的存储策略的详细信息。[-unsetStoragePolicy-path<path>]取消设置先前对目录上调用setStoragePolicy所设置的存储策略。如果目录从上级目录继承了存储策略，则unsetStoragePolicy是NOOP（无操作）。注意，在没有明确存储策略设置的目录上取消存储策略将不会返回错误。[-listPolicies]列出在HDFS中所有的存储策略，包括具体的策略ID、策略名称、块放置策略等。Mover指令Mover是HDFS支持的数据迁移工具，它会扫描HDFS中的文件，以检查块放置是否满足存储策略。对于违反存储策略的块，它将副本移动到其他存储类型，以满足存储策略要求。其操作如下所示。hdfsmover[-p<files/dirs>|-f<localfile>]其中，-p<files/dirs>指定要迁移的HDFS文件/目录。-f<localfile>指定一个本地文件，该文件包含要迁移的HDFS文件/目录列表。注意：存储类型RAM_DISK较为特殊，Mover工具迁移时会忽略存储在RAM_DISK中的副本，Mover操作对于Lazy_Persist策略而言为NOOP（无操作）。Mover使用过程中，涉及到Mover进程相关的可调参数，均可在hdfs-site.xml中进行设置。主要参数如下表所示。参数描述默认值dfs.mover.movedWinWidth一个块可以再次移动到另一个位置的最小时间间隔，以毫秒为单位。5400000dfs.moverThreads配置Mover的线程池大小。1000dfs.mover.retry.max.attemptsMover迁移失败后的最大重试次数。10操作示例HDFS中默认的存储策略是HOT策略，本例以修改指定目录存储策略为ONE_SSD为例，假设该目录下已存有文件，其具体操作如下所示。修改存储策略将指定目录存储策略修改为ONE_SSD，新写入该目录的文件将以ONE_SSD策略存储。hdfsstoragepolicies-setStoragePolicy-path/test-policyONE_SSD查看文件存储策略存储策略修改前，/test目录下已存有文件test_io_0。策略修改后，该文件不会自动转换为新的存储策略，需要使用Mover工具进行数据迁移。首先，查看该文件的存储策略。hdfsstoragepolicies-getStoragePolicy-path/test/test_io_0从查看的存储策略信息可知，文件虽然显示已为ONE_SSD策略存储，但实际并未转换，利用fsck查看块信息即可验证。hdfsfsck/test/test_io_0-files-blocks-locations迁移数据利用Mover工具将test_io_0文件迁移至新策略存储。hdfsmover-p/test/test_io_0迁移后，再使用fsck查看文件块信息，实现数据迁移。日志介绍日志描述HDFS相关日志的默认存储路径为“/var/log/hadoop/”。HDFS的日志启动了自动备份归档功能，默认情况下，当日志大小超过256MB的时候（此日志文件大小可进行配置），会自动备份，备份后的日志文件名规则为：“<原有日志名>.log.yyyy-mm-dd”。备份文件保留个数可以在Insight界面中配置。表HDFS日志列表日志类型日志文件名描述运行日志hadoop-(USER)-namenode-(hostname).logHDFS中namenode的系统日志，记录namenode运行时所产生的日志。hadoop-(USER)-datanode-(hostname).logHDFS中datanode的系统日志，记录datanode运行时所产生的日志。hadoop-(USER)-namenode-(hostname).out记录namenode标准输出和标准错误日志.hadoop-(USER)-datanode-(hostname).out记录datanode标准输出和标准错误日志.hadoop-(USER)-namenode-(hostname).out.(number)系统保留的5个namenodeout日志。hadoop-(USER)-datanode-(hostname).out.(number)系统保留的5个datanodeout日志。gc.log-(DATA)记录Java垃圾回收日志。审计日志hdfs-audit.logHDFS操作审计日志（例如：文件增删改查）。SecurityAuth.auditHDFS安全审计日志。日志级别日志库将日志分为5个级别，分别为DEBUG、INFO、WARN、ERROR和FATAL。这5个级别对应的日志信息重要程度不同，它们的重要程度由低到高依次为DEBUG<INFO<WARN<ERROR<FATAL。日志输出规则为：只输出级别不低于设定级别的日志信息。比如，级别设定为INFO，则INFO、WARN、ERROR和FATAL级别的日志信息都会被输出，但级别比INFO低的DEBUG则不会被输出。修改日志级别通过http://<namenode:50070>/logLevel在线修改NameNode的日志级别。如下所示：输入“org.apache.hadoop.hdfs.StateChange”，通过“GetLogLevel”可查看日志级别：

输入”org.apache.hadoop.hdfs.StateChange”，通过“SetLogLevel”可设置日志级别：Results显示设置日志级别成功。注：重启NameNode后该设置失效，需重新设置。修改默认日志级别Hadoop的默认日志级别为INFO，对于百台以上的集群，如果文件操作频繁的话，NameNode会输出较多日志，对性能会有一定的影响。因此，可以通过Insight界面，配置默认日志级别，具体流程如下所示。（1）进入“HDFS”-“配置参数”-“ADVANCED”中配置：（2）配置hadoop-env中的日志级别设置，可将“INFO”修改为“WARN”，“hadoop-env.template”中可根据需求进一步配置：（3）配置hdfs-log4j中的“hadooprootlogger”，如“WARN”：（4）配置完成后，保存并重启服务即可。日志格式HDFS的日志格式如下所示：表HDFS日志格式日志类型格式示例运行日志（yyyy-MM-ddHH:mm:ss,SSS）+（LogLevel）+（产生该日志的线程名字）+（log中的message）+（日志事件的发生位置）2019-11-1113:56:50,437INFOBlockStateChange(BlockManager.java:computeReplicationWorkForBlocks(1651))-BLOCK*neededReplications=0,pendingReplications=0.审计日志（yyyy-MM-ddHH:mm:ss,SSS）+（LogLevel）+（产生该日志的线程名字）+（log中的message）+（日志事件的发生位置）2019-11-1113:57:32,826INFOFSNamesystem.audit:allowed=trueugi=spark(auth:SIMPLE)ip=/1cmd=createsrc=/spark2-history/.a94cd4c9-996d-4dc6-b11a-5cfd29290ad2dst=nullperm=spark:hadoop:rw-r—r—proto=rpcHDFS重点参数调优操作场景在真实的业务场景中，HDFS承担着重要的存储角色。根据工作负载的不同，某些配置参数的默认值可能会导致集群性能不佳，甚至作业失败。本章针对该问题对HDFS重点参数进行说明，具体配置需依据应用场景进行调整。操作步骤大多数参数可在Insight管理平台中直接查看得到，便于修改。如有需要，同样可以在自定义配置中添加参数的配置，以添加参数至hdfs-site.xml为例，具体操作步骤如下所示：（1）进入Insight管理平台页面，选择“HDFS”-“配置参数”-“ADVANCED”；（2）选择“自定义hdfs-site”-“添加属性”；（3）将需要添加的键值填入后，选择添加即可。最后保存设置重启集群后，配置即可生效。重点参数表HDFS重点参数参数描述默认值来源dfs.replication默认块副本数。创建文件时，可以指定实际的副本数。如果在创建时未指定副本数，则使用默认值。注意：默认块副本数需小于或等于集群DataNode数量。3node.handler.count侦听客户端请求的NameNodeRPC服务线程数。当集群工作负载较高、集群规模较大时，应增大NameNode处理RPC服务的线程数。100hdfs-site.xmldfs.datanode.handler.countDataNodeRPC的服务线程数。当集群工作负载较高、集群规模较大时，应增大DataNode处理RPC服务的线程数。需要注意的是，每添加一个线程，内存将会增加。4096hdfs-site.xmldfs.datanode.du.reserved每个卷的保留空间（字节）。要注意留足够的空间给非HDFS文件使用。对于有异构存储的集群，该属性后可以跟相应的存储类型[ssd]/[disk]/[archive]/[ram_disk]。例如，dfs.datanode.du.reserved.ssd为配置ssd存储的保留空间。建议保留磁盘容量的5%或者50GB以上。409164185600hdfs-site.xmlipc.maximum.data.length表示服务器可以接收的最大IPC消息长度（字节）。大于此值的消息将立即被拒绝，以避免可能的OOM错误。该值需大于等于块大小。134217728core-site.xmlHADOOP_NAMENODE_OPTS设置NameNodeJVM的堆内存（MB）。NameNode堆大小取决于许多因素，例如文件数、块数和系统负载。具体堆内存大小需参考集群文件数进行配置，不恰当的堆内存会导致HDFS崩溃。3072hadoop-env.shYARN功能描述YARN是一种Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度。YARN对可伸缩性、可靠性和集群利用率进行了提升。YARN实现这些需求的方式是，把JobTracker的两个主要功能（资源管理和作业调度/监控）分成了两个独立的服务程序——全局的资源管理（RM）和针对每个应用的应用Master（AM）。架构原理YARN是Hadoop中的资源管理系统，包括两个独立的服务：一个全局的资源管理器ResourceManager和每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配，而ApplicationMaster负责单个应用程序的管理。YARN是Master/Slave结构，在整个资源管理框架中，ResourceManager为Master，NodeManager为Slave，ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时，需要提供一个用以跟踪和管理这个程序的ApplicationMaster，它负责向ResourceManager申请资源，并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上，因此它们之间不会相互影响。下图描述了YARN的基本组成结构，YARN主要由ResourceManager、NodeManager、ApplicationMaster（图中给出了MapReduce和MPI两种计算框架的ApplicationMaster，分别为MRAppMstr和MPIAppMstr）和Container等几个组件构成。ResourceManager（RM）RM是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（ApplicationsManager，ASM）。调度器调度器根据容量、队列等限制条件（如每个队列分配一定的资源，最多执行一定数量的作业等），将系统中的资源