Hadoop

明天咱们将分享社区用户多点 DMALL 的案例。多点 DMALL 是亚洲当先的全渠道数字批发解决方案服务商，目前已与 380 家批发企业达成单干，笼罩 6 个国家和地区。 面对 B 端客户日益增长的企业数据，存算一体的架构显得力不从心。计算资源冗余节约、所依附的CDH发行版技术栈简单、部署运维艰难及计算资源潮汐景象重大等问题，迫使多点启动架构降级的过程。同时，为满足 B 端客户多样化的需要，多点须要构建一个能够在多云环境下更具性价比、可复用的大数据底层基座和平台工具链。基于此，多点的大数据团队开始搭建存算拆散的云原生大数据架构。 本文深刻分析这次革新的架构设计与演进过程，分享多点 DMALL 在此过程中的教训和挑战。值得一提的是，他们利用 JuiceFS 社区版实现了与 Ranger 组件进行权限的对接，心愿此教训能为其余应用 JuiceFS 的企业提供参考。 一、存算一体架构下的痛点和挑战1.1 架构原生存在的痛点存算一体架构带来的老本和运维挑战，是大部分企业在大数据倒退中肯定会面对的问题。 传统的 Hadoop 生态体系中，数据存储角色与计算角色通常会部署在雷同的机器上，一个占据硬盘提供存储，一个利用 CPU 和内存做计算。为此，MapReduce 和 Spark 也适应性的设计了多层级的数据本地化策略，即工作尽可能被调配到存储所需数据的对应节点上做计算，以缩小两头数据交互产生的网络开销和额定的存储压力，晋升整体的大数据利用效率。 可是，随着企业业务的倒退，大数据存储量的增长速率与计算所需节点数量的增长速率很难保持一致。尤其是在“数据就是企业外围资产”的思维下，大量历史数据、冷数据的积攒，导致企业数据存储量的增长诉求远远高于计算资源。最初企业只好一直新增机器存储更多数据，但大量计算资源得不到充分利用造成了闲置与节约。 同样是减少存储资源，存算一体架构下会闲置局部计算资源，存算拆散则不会有这个问题。 此外，数据量的一直增长还带来了 HDFS NameNode 元数据压力、集群节点规模扩张受限等问题。这些问题也时时刻刻牵动着各个大数据团队紧绷的神经。 1.2 多点DMALL 面临的挑战多点DMALL 的大数据体系在构建之初，也是采纳传统 Hadoop 存算一体的技术栈。除了上述企业倒退中架构原生带来的窘境外，面对 To B 多样化的业务场景，多点DMALL 大数据团队面临更多场景化的挑战： 组件多技术栈简单：之前次要依赖 CDH 发行版本，该套架构组件繁多，架构简单，共包含11类服务（存储、计算、运维、监控、平安等），22 种角色类型。并且随着时间推移，很多新技术引入异样麻烦，须要思考十分多兼容性问题。部署简单 & 运维艰难：私有化部署、SaaS 服务模式一度给大数据团队带来了微小的工作量，交付效率不高，包含网络布局、容量布局、私有云机型抉择、破绽修复和多环境日常保护等。计算资源潮汐景象重大：存算一体的架构下大数据集群和业务集群是互相独立的，资源应用有着不同的特点。大数据集群资源应用的顶峰在凌晨，白天只有零散的即席查问占资源不多；业务集群的峰值在白天，早晨流量很少，这也是畛域内陈词滥调的“潮汐景象”，因而计算资源节约和闲置始终没有彻底解决。二、存算拆散的架构设计随着多点DMALL 全面 To B 转型，为越来越多的 B 端客户提供批发全渠道解决方案，须要具备在多云环境下提供更具性价比、可复用的大数据底层基座和平台工具链。多点DMALL 大数据团队联合已有教训和后续业务需要，设计搭建存算拆散、轻量级、可扩大、云中立大数据集群架构。 而存算拆散的第一步，便是要解决数据如何从 HDFS 集群上疾速切换到云服务商存储服务的问题。 2.1 小试牛刀：间接对接对象存储在架构降级探索期，能想到最间接的计划就是通过 API 对接云厂商的对象存储。 ...

1、背景在咱们开发的过程中有这么一种场景， /projectA 目录是 hadoopdeploy用户创立的，他对这个目录有wrx权限，同时这个目录属于supergroup，在这个组中的用户也具备这个目录的wrx权限，对于其他人,不可拜访这个目录。当初有这么一个非凡的用户root，我想root用户能够拜访这个目录，在不批改root用户组和其他人的权限的状况下，还有什么形式能够实现这个性能呢？ 由上图能够，root用户想拜访/projectA目录，在hdfs中能够通过acl来实现。 2、环境筹备# 创立目录[hadoopdeploy@hadoop01 ~]$ hdfs dfs -mkdir /projectA# 列出根目录下的文件夹[hadoopdeploy@hadoop01 ~]$ hdfs dfs -ls /Found 1 itemsdrwxr-xr-x - hadoopdeploy supergroup 0 2023-05-24 20:35 /projectA# 将 /projectA 目录的权限批改成 770, 即其他人没有这个目录的拜访权限[hadoopdeploy@hadoop01 ~]$ hdfs dfs -chmod 770 /projectA# 再次查看发现批改胜利[hadoopdeploy@hadoop01 ~]$ hdfs dfs -ls /Found 1 itemsdrwxrwx--- - hadoopdeploy supergroup 0 2023-05-24 20:35 /projectA[hadoopdeploy@hadoop01 ~]$从上述代码中可知，咱们创立了一个/projecetA的目录，且给这个目录的权限为770，那么其他人 对这个目录应该是没有拜访权限的。 通过上述图片可知，咱们用root用户上传文件，发现没有权限。 3、开启acl权限3.1 批改hdfs-site.xml<!-- 开启acl访问控制权限，默认就开启了 --><property> <name>dfs.namenode.acls.enabled</name> <value>true</value></property>留神： 在低版本的hadoop上默认是禁用的，高版本默认是开启的。 3.2 重启hdfs集群[hadoopdeploy@hadoop01 ~]$ stop-dfs.shStopping namenodes on [hadoop01]Stopping datanodesStopping secondary namenodes [hadoop03][hadoopdeploy@hadoop01 ~]$ start-dfs.shStarting namenodes on [hadoop01]Starting datanodesStarting secondary namenodes [hadoop03][hadoopdeploy@hadoop03 ~]$3.3 应用acl给root用户受权[hadoopdeploy@hadoop01 ~]$ hdfs dfs -setfacl -m user:root:rwx /projectA[hadoopdeploy@hadoop01 ~]$ hdfs dfs -getfacl /projectA# file: /projectA# owner: hadoopdeploy# group: supergroupuser::rwxuser:root:rwxgroup::rwxmask::rwxother::---[hadoopdeploy@hadoop01 ~]$ ...

linux创立文件夹命令mkdir 绝对路径 # 绝对路径写哪里存哪里没问题mkdir -p /test1/test2/test3ll /mkdir 相对路径 # 相对路径都是绝对当前工作门路，当前目录下 `ll` 查看一下也能很清晰看到mkdir -p test4/test5llhadoop创立文件夹命令hadoop fs -mkdir 绝对路径 # hadoop hdfs也是从/登程 仍然是绝对路径写哪里存哪里没问题hadoop fs -mkdir -p /test6/test7/test8hadoop fs -ls /hadoop fs -mkdir 相对路径 # noted: 相对路径会放到 /user/root/下 ！！！hadoop fs -mkdir -p test9/test10hadoop fs -ls /user/roothttps://stackoverflow.com/questions/11714942/

本文将深入探讨 AM 向 RM 申请并取得 Container 资源后，在 NM 节点上如何启动和清理 Container。将详细分析整个过程的源码实现。 一、Container 生命周期介绍Container 的启动由 ApplicationMaster 通过调用 RPC 函数 ContainerManagementProtocol#startContainers() 发动申请，NM 中的 ContainerManagerImpl 组件负责接管并解决该函数发来的申请。Container 启动过程次要分为四个阶段：告诉 NM 启动 Container、资源本地化、启动并运行 Container、资源清理。 资源本地化：次要是指分布式缓存机制实现的工作（详见上一篇《6-3 NodeManager 分布式缓存》）。性能包含初始化各种服务组件、创立工作目录、从 HDFS 下载运行所需的各种资源（比方文本文件、JAR 包、可执行文件）等。Container 启动：由 ContainerLauncher 服务实现，该服务将进一步调用插拔式组件 ContainerExecutor。Yarn 中提供了三种 ContainerExecutor 实现，别离为 DefaultContainerExecutor、LinuxContainerExecutor、DockerContainerExecutor。资源清理：是资源本地化的逆过程，它负责清理各类资源，均由 ResourceLocalizationService 服务实现。 二、Container 生命周期源码剖析一）AM 告诉 NM 启动 Container次要流程如下： AM AMRMClientAsyncImpl 通过 RPC 函数 ApplicationMaster#allocate() 周期性向 RM 申请资源，并将申请到的资源保留在阻塞队列 responseQueue 中。（上面仅截取重要逻辑的源码） private class HeartbeatThread extends Thread { public void run() { while (true) { AllocateResponse response = null; try { // 发心跳。发给 RM 以后的进度，从 RM 支付调配的 Container 及其他信息。 response = client.allocate(progress); } // 将 RM 通过心跳返回的信息放到阻塞队列 responseQueue 中，期待解决 responseQueue.put(response);跟踪 responseQueue，其在 CallbackHandlerThread 进行取出，解决调配到的 Container。 ...

不要跳过这部分常识，对理解 NodeManager 本地目录构造，和相熟 Container 启动流程有帮忙。 一、分布式缓存介绍次要作用就是将用户应用程序执行时，所需的内部文件资源下载缓存到各个节点。YARN 分布式缓存工作流程如下: 客户端将应用程序所需的文件资源 (内部字典、JAR 包、二进制文件) 提交到 HDFS 上。客户端将应用程序提交到 RM 上。RM 将与某个 NM 进行通信，启动应用程序 AM，NM 收到命令后，首先从 HDFS 上下载文件 (缓存)，而后启动 AM。AM 与 RM 通信，以申请和获取计算资源。AM 收到新调配到的计算资源后，与对应的 NM 通信，以启动工作。如果应用程序第一次在该节点上启动工作，NM 首先从 HDFS 上下载文件缓存到本地，而后启动工作。NM 后续收到启动工作申请后，如果文件已在本地缓存，则间接执行工作，否则期待文件缓存实现后再启动。各个节点上的缓存文件由对应的 NM 治理和保护。在 Hadoop 中，分布式缓存并不是将文件缓存到集群中各个节点的内存中，而是将文件缓存到各个节点的磁盘上，以便执行工作时间接从磁盘上读取文件。 二、个性介绍一）资源可见性和分类分布式缓存机制是由各个 NM 实现的，次要性能是将应用程序所需的文件资源缓存到本地，以便后续工作的应用。资源缓存是应用时触发的，也就是第一个用到该资源的工作触发。后续工作无需再进行缓存，间接应用即可。依据可见性，NM将资源分为三类： Public：节点上所有的用户都能够共享该资源，只有有一个用户的应用程序将着这些资源缓存到本地，其余所有用户的所有应用程序都能够应用；Private：节点上同一用户的所有应用程序共享该资源，只有该用户其中一个应用程序将资源缓存到本地，该用户的所有应用程序都能够应用；Application：节点上同一应用程序的所有Container共享该资源。YARN是通过比拟 resource、type、timestamp 和 pattern四个字段是否雷同来判断两个资源申请是否雷同的。如果一个曾经被缓存到各个节点上的文件被用户批改了，则下次应用时会主动触发一次缓存更新，以从新从HDFS上下载文件。分布式缓存实现的次要性能是文件下载，波及大量的磁盘读写，因而整个过程采纳了异步并发模型放慢文件下载速度，以防止同步模型带来的性能开销。 二）分布式缓存实现NodeManager 采纳轮询的调配策略将这三类资源寄存在 yarn.nodemanager.local-dirs 指定的目录列表中，在每个目录中，资源依照以下形式寄存： PUBLIC 资源：寄存在 ${yarn.nodemanager.local-dirs}/filecache/ 目录下，每个资源将独自寄存在以一个随机整数命名的目录中，且目录的拜访权限均为 0755。PRIVATE 资源：寄存在 ${yarn.nodemanager.local-dirs}/usercache/${user}/filecache/ 目录下，每个资源将独自寄存在以一个随机整数命名的目录中，且目录的拜访权限均为 0710。APPLICATION 资源：寄存在 ${yarn.nodemanager.local-dirs}/usercache/${user}/${appcache}/${appid}/filecache/ 目录下，每个资源将独自寄存在以一个随机整数命名的目录中，且目录的拜访权限均为 0710。其中 Container 的工作目录位于 ${yarn.nodemanager.local-dirs}/usercache/${user}/${appcache}/${appid}/${containerid} 目录下，其次要保留 jar 包文件、字典文件对应的软链接。目录构造如下所示： ./nm-local-dir/|-- filecache // PUBLIC资源| `-- 10 // 每个资源将独自寄存在以一个随机整数命名的目录中|-- nmPrivate| |-- application_xxxx_xxx| | |-- container_xxx_xxx_xxx_xx_xxxx| | |-- container_xxx_xxx_xxx_xx_xxxx // 公有目录数据（执行脚本、token文件、pid文件）| | | |-- container_xxx_xxx_xxx_xx_xxxx.pid| | | |-- container_xxx_xxx_xxx_xx_xxxx.tokens| | | `-- launch_container.sh| |-- application_xxxx_xxx| `-- application_xxxx_xxx`-- usercache |-- userXxx | |-- appcache // APPLICATION资源 | `-- filecache // PRIVATE资源 |-- userXxx | |-- appcache | `-- filecache ...

一、简介NodeManager（NM）中的状态机分为三类：Application、Container 和 LocalizedResource，它们均间接或者间接参加保护一个应用程序的生命周期。 当 NM 收到某个 Application 的第一个 container 启动命令时，它会创立一个「Application状态机」来跟踪该应用程序在该节点的状态；每个container都有一个独立的「container状态机」；Application 运行所需资源（jar，文件等）的下载过程则由「LocalizedResource状态机」保护和跟踪。二、三类状态机一）Application 状态机NM 上的 Application 保护的信息是 RM 端 Application 信息的一个子集，这有助于对立治理节点上同一个 Application 的所有 Container（例如记录每个 Application 在该节点上运行的 Container 列表，以及杀死一个 Application 的所有 Container 等）。实现这一性能的类是 nodemanager/containermanager/application/ApplicationImpl，它保护了一个 Application 状态机。须要留神的是，NM 上 Application 的生命周期与 RM 上 Application 的生命周期是统一的。 // 截取 ApplicationImpl 中一部分状态机的代码 private static StateMachineFactory<ApplicationImpl, ApplicationState, ApplicationEventType, ApplicationEvent> stateMachineFactory = new StateMachineFactory<ApplicationImpl, ApplicationState, ApplicationEventType, ApplicationEvent>(ApplicationState.NEW) // Transitions from NEW state .addTransition(ApplicationState.NEW, ApplicationState.INITING, ApplicationEventType.INIT_APPLICATION, new AppInitTransition()) .addTransition(ApplicationState.NEW, ApplicationState.NEW, ApplicationEventType.INIT_CONTAINER, INIT_CONTAINER_TRANSITION) // Transitions from INITING state .addTransition(ApplicationState.INITING, ApplicationState.INITING, ApplicationEventType.INIT_CONTAINER, INIT_CONTAINER_TRANSITION) .addTransition(ApplicationState.INITING, EnumSet.of(ApplicationState.FINISHING_CONTAINERS_WAIT, ApplicationState.APPLICATION_RESOURCES_CLEANINGUP), ApplicationEventType.FINISH_APPLICATION, new AppFinishTriggeredTransition()) .addTransition(ApplicationState.INITING, ApplicationState.INITING, ApplicationEventType.APPLICATION_CONTAINER_FINISHED, CONTAINER_DONE_TRANSITION) .addTransition(ApplicationState.INITING, ApplicationState.INITING, ApplicationEventType.APPLICATION_LOG_HANDLING_INITED, new AppLogInitDoneTransition()) .addTransition(ApplicationState.INITING, ApplicationState.INITING, ApplicationEventType.APPLICATION_LOG_HANDLING_FAILED, new AppLogInitFailTransition()) .addTransition(ApplicationState.INITING, ApplicationState.RUNNING, ApplicationEventType.APPLICATION_INITED, new AppInitDoneTransition()) ...

本篇将对 Yarn 调度器中的资源抢占形式进行探索。剖析当集群资源有余时，占用量资源少的队列，是如何从其余队列中争夺资源的。咱们将深刻源码，一步步剖析争夺资源的具体逻辑。 一、简介在资源调度器中，以 CapacityScheduler 为例（Fair 相似），每个队列可设置一个最小资源量和最大资源量。其中，最小资源量是资源紧缺状况下每个队列需保障的资源量，而最大资源量则是极其状况下队列也不能超过的资源使用量。资源抢占产生的起因，是为了进步资源利用率，资源调度器（包含 Capacity Scheduler 和 Fair Scheduler）会将负载较轻的队列的资源临时调配给负载重的队列。仅当负载较轻队列忽然收到新提交的应用程序时，调度器才进一步将本属于该队列的资源归还给它。但因为此时资源可能正被其余队列应用，因而调度器必须期待其余队列开释资源后，能力将这些资源“完璧归赵”，为了避免应用程序等待时间过长，RM 在期待一段时间后强制回收。 开启容器抢占须要配置的参数 yarn-site.xml： yarn.resourcemanager.scheduler.monitor.enableyarn.resourcemanager.scheduler.monitor.policies二、抢占具体逻辑这里咱们次要剖析如何选出待抢占容器这一过程。整顿流程如下图所示： 接下来咱们深刻源码，看看具体的逻辑：首先 ResourceManager 通过 ResourceManager#createPolicyMonitors 办法创立资源抢占服务： protected void createPolicyMonitors() { // 只有 capacity scheduler 实现了 PreemptableResourceScheduler 接口，fair 是如何实现资源抢占的？ if (scheduler instanceof PreemptableResourceScheduler && conf.getBoolean(YarnConfiguration.RM_SCHEDULER_ENABLE_MONITORS, YarnConfiguration.DEFAULT_RM_SCHEDULER_ENABLE_MONITORS)) { LOG.info("Loading policy monitors"); // 是否配置了 scheduler.monitor.policies // 默认值是 ProportionalCapacityPreemptionPolicy？ 代码中没看到默认值，然而 yarn-site.xml doc 中有默认值 List<SchedulingEditPolicy> policies = conf.getInstances( YarnConfiguration.RM_SCHEDULER_MONITOR_POLICIES, SchedulingEditPolicy.class); if (policies.size() > 0) { for (SchedulingEditPolicy policy : policies) { LOG.info("LOADING SchedulingEditPolicy:" + policy.getPolicyName()); // periodically check whether we need to take action to guarantee // constraints // 此处创立了资源抢占服务类。 // 当此服务启动时，会启动一个线程每隔 PREEMPTION_MONITORING_INTERVAL（默认 3s）调用一次 // ProportionalCapacityPreemptionPolicy 类中的 editSchedule办法， // 【重点】在此办法中实现了具体的资源抢占逻辑。 SchedulingMonitor mon = new SchedulingMonitor(rmContext, policy); addService(mon); }资源抢占服务会启动一个线程每隔 3 秒钟调用配置的抢占规定，这里以 ProportionalCapacityPreemptionPolicy（比例容量抢占规定）为例介绍其中的抢占具体逻辑（editSchedule 办法）： ...

本篇文章将深刻介绍 Yarn 三种调度器。Yarn 自身作为资源管理和调度服务，其中的资源调度模块更是重中之重。上面将介绍 Yarn 中实现的调度器性能，以及外部执行逻辑。 一、简介Yarn 最次要的性能就是资源管理与调配。本篇文章将对资源分配中最外围的组件调度器（Scheduler）进行介绍。调度器最现实的指标是有资源申请时，立刻满足。然而因为物理资源是无限的，就会存在资源如何调配的问题。针对不同资源需求量、不同优先级、不同资源类型等，很难找到一个完满的策略能够解决所有的利用场景。因而，Yarn提供了多种调度器和可配置的策略供咱们抉择。Yarn 资源调度器均实现 ResourceScheduler 接口，是一个插拔式组件，用户能够通过配置参数来应用不同的调度器，也能够本人依照接口标准编写新的资源调度器。在 Yarn 中默认实现了三种调速器：FIFO Scheduler 、Capacity Scheduler、Fair Scheduler。官网对三种调度器的介绍图。看个大略意思就行，随着调度器的不断更新迭代，这个图不再合乎当下的状况。 二、FIFO最简略的一个策略，仅做测试用。用一个队列来存储提交期待的工作，先提交的工作就先分资源，有残余的资源就给后续排队期待的工作，没有资源了后续工作就等着之前的工作开释资源。长处：简略，开箱即用，不须要额定的配置。早些版本的 Yarn 用 FIFO 作为默认调度策略，后续改为 CapacityScheduler 作为默认调度策略。毛病：除了简略外都是毛病，无奈配置你各种想要的调度策略（限度资源量、限度用户、资源争夺等）。 三、CapacityScheduler一）CS 简介Capacity Scheduler（后以 CS 简写代替）以队列为单位划分资源。会给每个队列配置最小保障资源和最大可用资源。最小配置资源保障队列肯定能拿到这么多资源，有闲暇可共享给其余队列应用；最大可用资源限度队列最多能应用的资源，避免适度耗费。队列外部能够再嵌套，造成层级构造。队列内资源默认采纳 FIFO 的形式调配。如下图所示。 长处： 队列最低资源保障，避免小利用饿死；闲暇容量共享，当队列配置资源有闲暇时可共享给其余队列应用毛病： 队列配置繁琐，父队列、子队列都要独自配置优先级、最大资源、最小资源、用户最大资源、用户最小资源、用户权限配置等等。工程中会写个程序，主动生成该配置；二）CS 特色分层队列 (Hierarchical Queues)：反对队列分层构造，子队列可调配父队列可用资源。容量保障 (Capacity Guarantees)：每个队列都会配置最小容量保障，当集群资源缓和时，会保障每个队列至多能分到的资源。弹性 (Elasticity)：当队列配置资源有闲暇时，能够调配给其余有资源需要的队列。当再次须要这些资源时能够争夺回这些资源。安全性 (Security)：每个队列都有严格的 ACL，用于管制哪些用户能够向哪些队列提交应用程序。多租户 (Multi-tenancy)：提供全面的限度以避免单个应用程序、用户和队列从整体上独占队列或集群的资源。优先级调度 (Priority Scheduling)：此性能容许以不同的优先级提交和调度应用程序。同时队列间也反对优先级配置（2.9.0 后反对）。相对资源配置 (Absolute Resource Configuration)：管理员能够为队列指定相对资源，而不是提供基于百分比的值（3.1.0 后反对）。资源池配置：可将 NodeManager 宰割到不同的资源池中，资源池中配置队列，进行资源隔离。同时资源池有共享和独立两种模式。在共享状况下，多余的资源会共享给 default 资源池。三）CS 配置假如队列层级如下： root├── prod└── dev ├── eng └── science能够通过配置 capacity-scheduler.xml 来实现： <configuration> <property> <name>yarn.scheduler.capacity.root.queues</name> <value>prod,dev</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.queues</name> <value>eng,science</value> </property> <property> <name>yarn.scheduler.capacity.root.prod.capacity</name> <value>40</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.capacity</name> <value>60</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.eng.capacity</name> <value>50</value> </property> <property> <name>yarn.scheduler.capacity.root.dev.science.capacity</name> <value>50</value> </property></configuration>除了容量配置外，还能够配置单个用户或者程序可能应用的最大资源数，同时能够运行几个利用，权限ACL管制等，不是本篇重点，不再开展。可参考：cloudera - Capacity Scheduler、Hadoop doc - Capacity Scheduler、Hadoop: Capacity Scheduler yarn容量调度配置。 ...

资源调度器是 YARN 中最外围的组件之一，它是 ResourceManager 中的一个插拔式服务组件，负责整个集群资源的治理和调配。Yarn 默认提供了三种可用资源调度器，别离是FIFO (First In First Out )、 Yahoo! 的 Capacity Scheduler 和 Facebook 的 Fair Scheduler。 本节会重点介绍资源调度器的根本框架，在之后文章中具体介绍 Capacity Scheduler 和 Fair Scheduler。 一、根本架构资源调度器是最外围的组件之一，并且在 Yarn 中是可插拔的，Yarn 中定义了一套接口标准，以不便用户实现本人的调度器，同时 Yarn 中自带了FIFO，CapacitySheduler， FairScheduler三种罕用资源调度器。 一）资源调度模型Yarn 采纳了双层资源调度模型。 第一层中，RM 中的资源调度器将资源分配给各个 AM（Scheduler 解决的局部）第二层中，AM 再进一步将资源分配给它的外部工作（不是本节关注的内容）Yarn 的资源分配过程是异步的，资源调度器将资源分配给一个应用程序后，它不会立即 push 给对应的 AM，而是临时放到一个缓冲区中，期待 AM 通过周期性的心跳被动来取（pull-based通信模型） NM 通过周期心跳汇报节点信息RM 为 NM 返回一个心跳应答，包含须要开释的 container 列表等信息RM 收到的 NM 信息触发一个NODE_UPDATED事件，之后会依照肯定策略将该节点上的资源分配到各个利用，并将调配后果放到一个内存数据结构中AM 向 RM 发送心跳，取得最新调配的 container 资源AM 将收到的新 container 调配给外部工作二）资源示意模型NM 启动时会向 RM 注册，注册信息中蕴含该节点可调配的 CPU 和内存总量，这两个值均可通过配置选项设置，具体如下： ...

作者：京东物流 秦彪工欲善其事必先利其器，在深刻学习大数据相干技术之前，先手动从0到1搭建一个属于本人的本地Hadoop和Spark运行环境，对于持续钻研大数据生态圈各类技术具备重要意义。本文旨在站在研发的角度上通过手动实际搭建运行环境，文中不快人快语过多讲述基础知识，联合Hadoop和Spark最新版本，帮忙大家跟着步骤一步步实际环境搭建。 1. 总体运行环境概览（1） 软件包及应用工具版本介绍表： 技术名称或工具名称版本备注Hadoophadoop-3.3.4.tar.gz VirtualBox6.0.0 r127566虚拟机，举荐CentOScentos7.3 JDKjdk-8u212-linux-x64.tar.gz1.8.0_111Zookeeperzookeeper-3.6.tar.gz FileZillaFileZilla_3.34.0文件传输工具，举荐MobaXtermMobaXterm_Portable_v10.9SSH连贯工具，举荐IdeaIDEA COMMUNITY 2019.1.4代码IDE开发工具，举荐（2）环境部署与散布介绍表： 主机名IP运行的过程master192.168.0.20QuorumPeerMain、NameNode、DataNode、ResourceManager、NodeManager、JournalNode、DFSZKFailoverController、Masterslave1192.168.0.21QuorumPeerMain、NameNode、DataNode、ResourceManager、NodeManager、JournalNode、DFSZKFailoverController、Master、Workerslave2192.168.0.22QuorumPeerMain、NameNode、DataNode、JournalNode、NodeManager、Worker（3）过程介绍：（1示意过程存在，0示意不存在） 过程名含意masterslave1slave2QuorumPeerMainZK过程111NameNodeHadoop主节点110DataNodeHadoop数据节点111ResourceManagerYarn治理过程110NodeManagerYarn 工作过程111JournalNodeNameNode同步过程111DFSZKFailoverControllerNameNode监控过程110MasterSpark主节点110WorkerSpark工作节点1112. 零碎根底环境筹备步骤1： 虚拟机中Linux零碎装置（略） VirtualBox中装置CentOS7操作系统 步骤2： CentOS7根底配置 （1） 配置主机的hostname 命令： vim/etc/hostname （2） 配置hosts， 命令vim /etc/hosts （3） 装置JDK 命令： rpm -qa | grep java 查看是否有通过rpm形式装置的java java -version 查看以后环境变量下的java 版本 1） filezilla上传安装包，tar -zxvf jdk-8u212-linux-x64.tar.gz 解压 2） bin目录的残缺门路： /usr/local/jdk/jdk1.8.0_212/bin 3） vim /etc/profile 配置jdk环境变量 （4） 复制主机： 1）利用VirtualBox复制性能复制两台主机 2）命令：vi /etc/sysconfig/network-scripts/ifcfg-eth0，设置相应的网络信息 3）三台主机IP别离为： 192.168.0.20/21/22 （5） 配置三台主机ssh无明码登录（略） （6） 装置zookeeper ...

在 YARN 中，Application 是指应用程序，它可能启动多个运行实例，每个运行实例由 —个 ApplicationMaster 与一组该 ApplicationMaster 启动的工作组成，它领有名称、队列、优先级等属性，是一个比拟宽泛的概念，能够是一个 MepReduce 作业、一个 DAG 应用程序等。YARN 中 Application 治理波及应用程序的权限治理、启动与敞开、生命周期治理等，本节只介绍最根本的治理内容，比方权限治理、启动与敞开等，而生命周期治理则放到下一节中介绍。 一、ApplicationACLsManagerApplicationACLsManager 负责管理应用程序拜访权限 查看权限 程序根本信息：运行工夫、优先级等批改权限 批改程序优先级、杀死应用程序二、RMAppManagerRMAppManager 负责应用程序启动和敞开。接下来联合源码次要剖析启动和完结两个操作。 1、启动在「4-1 ResourceManager 性能概述」中，提到了 ClientRMService 解决来自客户端各种 RPC 申请，比方提交、终止获取利用运行状态等。ClientRMService 当收到客户端提交的利用后，将调用函数 RMAppManager#submitApplication 创立一个 RMApp 对象，保护应用程序的整个生命周期。 protected void submitApplication() { // 创立 app，并增加到 RMActiveServiceContext.applications RMAppImpl application = createAndPopulateNewRMApp(submissionContext, submitTime, user, false); // 发送 app start event，持续由其余事件处理器解决 this.rmContext.getDispatcher().getEventHandler() .handle(new RMAppEvent(applicationId, RMAppEventType.START));}2、完结当 RMAPP 运行完结后，将向 RMAPPManager 发送一个 RMAPPManagerEventType.APP_COMPLETED 事件。看源码将执行 3 个操作： public void handle(RMAppManagerEvent event) { ApplicationId applicationId = event.getApplicationId(); LOG.debug("RMAppManager processing event for " + applicationId + " of type " + event.getType()); switch(event.getType()) { case APP_COMPLETED: { finishApplication(applicationId); logApplicationSummary(applicationId); checkAppNumCompletedLimit(); } finishApplication() ...

hdfs的实现目标和局限1.实现目标兼容便宜的硬件设施流数据读写大数据集简略的文件模型弱小的跨平台兼容性2.局限不适宜低提早数据拜访无奈高效存储大量小文件不反对多用户写入及任意批改文件namenode和datanode secondaryNameNode的工作状况 hdfs数据出错与复原1. 名称节点出错名称节点保留了所有的元数据信息，其中，最外围的两大数据结构是FsImage和Editlog，如果这两个文件产生损坏，那么整个HDFS实例将生效。因而，HDFS设置了备份机制，把这些外围文件同步复制到备份服务器SecondaryNameNode上。当名称节点出错时，就能够依据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行复原。 2. 数据节点出错每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告本人的状态当数据节点产生故障，或者网络产生断网时，名称节点就无奈收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点下面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O申请这时，有可能呈现一种情景，即因为一些数据节点的不可用，会导致一些数据块的正本数量小于冗余因子名称节点会定期检查这种状况，一旦发现某个数据块的正本数量小于冗余因子，就会启动数据冗余复制，为它生成新的正本HDFS和其它分布式文件系统的最大区别就是能够调整冗余数据的地位 3. 数据出错网络传输和磁盘谬误等因素，都会造成数据谬误客户端在读取到数据后，会采纳md5和sha1对数据块进行校验，以确定读取到正确的数据在文件被创立时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个门路的暗藏文件外面当客户端读取文件的时候，会先读取该信息文件，而后，利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会申请到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有谬误，名称节点会定期检查并且从新复制这个块hdfs读写过程1. 读过程 2. 写过程 NoSQL数据库具备以下几个特点：• （1）灵便的可扩展性• （2）灵便的数据模型• （3）与云计算严密交融 四种常见的NOSQL键值数据库列族数据库文档数据库图形数据库Nosql的三大基石capbase最终一致性云数据库在UMP零碎中，Zookeeper次要施展三个作用：• 作为全局的配置服务器 • 提供分布式锁（选出一个集群的“总管”） • 监控所有MySQL实例 UMP零碎架构 mapreducemapreduce的体系结构1）Client 用户编写的MapReduce程序通过Client提交到JobTracker端用户可通过Client提供的一些接口查看作业运行状态2）JobTracker JobTracker负责资源监控和作业调度JobTracker 监控所有TaskTracker与Job的健康状况，一旦发现失败，就将相应的工作转移到其余节点JobTracker 会跟踪工作的执行进度、资源使用量等信息，并将这些信息通知任务调度器（TaskScheduler），而调度器会在资源呈现闲暇时，抉择适合的工作去应用这些资源3）TaskTracker TaskTracker 会周期性地通过“心跳”将本节点上资源的应用状况和工作的运行进度汇报给JobTracker，同时接管JobTracker 发送过去的命令并执行相应的操作（如启动新工作、杀死工作等）TaskTracker 应用“slot”等量划分本节点上的资源量（CPU、内存等）。一个Task 获取到一个slot 后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的闲暇slot调配给Task应用。slot 分为Map slot 和Reduce slot 两种，别离供MapTask 和Reduce Task 应用4）Task Task 分为Map Task 和Reduce Task 两种，均由TaskTracker 启动yarn的体系结构 YARN的指标就是实现“一个集群多个框架”，为什么？一个企业当中同时存在各种不同的业务利用场景，须要采纳不同的计算框架• MapReduce实现离线批处理• 应用Impala实现实时交互式查问剖析• 应用Storm实现流式数据实时剖析• 应用Spark实现迭代计算这些产品通常来自不同的开发团队，具备各自的资源调度管理机制为了防止不同类型利用之间相互烦扰，企业就须要把外部的服务器拆分成多个集群，别离装置运行不同的计算框架，即“一个框架一个集群”导致问题• 集群资源利用率低• 数据无奈共享• 保护代价高YARN的指标就是实现“一个集群多个框架”• 即在一个集群上部署一个对立的资源调度治理框架YARN，在YARN之上能够部署其余各种计算框架• 由YARN为这些计算框架提供对立的资源调度治理服务，并且可能依据各种计算框架的负载需要，调整各自占用的资源，实现集群资源共享和资源弹性膨胀能够实现一个集群上的不同利用负载混搭，无效进步了集群的利用率• 不同计算框架能够共享底层存储，防止了数据集跨集群挪动

本篇持续对 RM 中治理 NodeManager 的局部进行深刻的解说。次要有三个局部：查看 NM 是否存活；治理 NM 的黑白名单；响应 NM RPC 申请。 一、简介在 RM 的主从构造中，最次要的就是 RM 和 NM 之间的主从构造。RM 作为「管理员」，治理上面多个 NM 节点。如何检测 NM 是否存活，划分黑白名单，以及如何相应 NM RPC 申请，将在上面进行具体介绍。 二、NM 治理次要组成一）NMLivelinessMonitor检测 NM 活性的服务，是否有心跳以后正在运行的 NM 会保留在 RM 的一个数据结构中，NMLivelinessMonitor 就周期遍历，若一个 NM 在肯定工夫（默认10分钟）未汇报心跳，则工作其挂了NM 被认为挂了后，其上的 Container 会主动置为运行失败，并告诉给 AM，由 AM 决定后续解决计划 二）NodesListManager治理 exclude（相似黑名单）和 include（相似白名单）列表启动时，它们别离从yarn.resourcemanager.nodes.include-path 以及 yarn.resourcemanager.nodes.exclude-path中读取黑名单列表中的nodes不可能和RM间接通信（间接抛出RPC异样）能够动静加载，应用命令 yarn rmadmin -refreshNodes 三）ResourceTrackerServiceResourceTrackerService 是 RPC 协定 ResourceTracker 的一个实现，它作为一个 RPC Server 端接管 NodeManager 的 RPC 申请。申请次要蕴含2种信息，1）注册NodeManager。2）解决心跳信息。 注册 NodeManager 解决：ResourceTrackerService#registerNodeManager // ResourceTrackerService#registerNodeManagerpublic RegisterNodeManagerResponse registerNodeManager( RegisterNodeManagerRequest request) throws YarnException, IOException { // nm 节点信息 - ip、端口、资源、版本 NodeId nodeId = request.getNodeId(); String host = nodeId.getHost(); int cmPort = nodeId.getPort(); int httpPort = request.getHttpPort(); Resource capability = request.getResource(); String nodeManagerVersion = request.getNMVersion(); RegisterNodeManagerResponse response = recordFactory .newRecordInstance(RegisterNodeManagerResponse.class); // 查看版本 if (!minimumNodeManagerVersion.equals("NONE")) { if (minimumNodeManagerVersion.equals("EqualToRM")) { minimumNodeManagerVersion = YarnVersionInfo.getVersion(); } if ((nodeManagerVersion == null) || (VersionUtil.compareVersions(nodeManagerVersion,minimumNodeManagerVersion)) < 0) { String message = "Disallowed NodeManager Version " + nodeManagerVersion + ", is less than the minimum version " + minimumNodeManagerVersion + " sending SHUTDOWN signal to " + "NodeManager."; LOG.info(message); response.setDiagnosticsMessage(message); response.setNodeAction(NodeAction.SHUTDOWN); return response; } }解决心跳 ...

上一篇文章对 ResourceManager 整体架构和性能进行了讲述。本篇将对 RM 中治理 Application Master 的局部进行深刻的解说。上面将会介绍 RM 与 AM 整体通信执行流程，并对 RM 中波及的对应服务进行具体解说。为了更好的学习本篇常识，倡议先相熟以下知识点，不理解的局部可翻到后面对应的文章进行学习： RPC（2-2 Yarn 根底库 - 底层通信库 RPC）事件处理器（2-3 Yarn 根底库 - 服务库与事件库）AM 程序执行流程（3-3 Yarn Application Master 编写）一、AM 执行流程客户端提交工作到 RM 后，启动 AM 到工作实现的流程如下所示： 各个步骤具体执行操作请对应上面各服务解说。 二、AM 治理次要组成ApplictionMaster 治理局部次要由三个服务形成，它们独特管理应用程序的 AM 的生存周期。（以下服务均能依据名称找到源码中对应的类，能够看其具体的实现逻辑） 一）ApplicationMasterLauncher「服务&事件处理器」解决 AM 的 LAUNCH 和 CLEANUP 事件从源码中能够看到：EventHandler 的 handle 办法收到 AM 事件后创立 Runnable 对象，之后会放到 masterEvents 阻塞队列中，launcherHandlingThread 一直从队列中取出事件，提交到线程池 launcherPool 中解决。（流程图如下所示） 二）AMLivelinessMonitor查看服务活性（是否有心跳）继承自抽象类 AbstractLivelinessMonitor，在抽象类中曾经实现好 live 查看逻辑，在一段时间内未汇报心跳信息，则工作其挂了。AMLivelinessMonitor 只需定义当 AM 被认为挂了（expire）时，须要解决的逻辑。当失败时会发一个 RMAppAttemptEvent EXPIRE 事件。抽象类 AbstractLivelinessMonitor 简要介绍： ...

集群简介HADOOP集群具体来说蕴含两个集群：HDFS集群和YARN集群，两者逻辑上拆散，但物理上常在一起。HDFS集群负责海量数据的存储，集群中的角色次要有：NameNode、DataNode、SecondaryNameNode。YARN集群负责海量数据运算时的资源调度，集群中的角色次要有：ResourceManager、NodeManager。那mapreduce是什么呢？它其实是一个分布式运算编程框架，是利用程序开发包，由用户依照编程标准进行程序开发，后打包运行在HDFS集群上，并且受到YARN集群的资源调度治理。集群部署形式Hadoop部署形式分三种： 1、Standalone mode（独立模式） 独立模式又称为单机模式，仅1个机器运行1个java过程，次要用于调试。 2、Pseudo-Distributed mode（伪分布式模式） 伪分布模式也是在1个机器上运行HDFS的NameNode和DataNode、YARN的 ResourceManger和NodeManager，但别离启动独自的java过程，次要用于调试。 3、Cluster mode（群集模式）-单节点模式-高可用HA模式集群模式次要用于生产环境部署。会应用N台主机组成一个Hadoop集群。这种部署模式下，主节点和从节点会离开部署在不同的机器上。 本搭建的是集群模式，以三台主机为例，以下是集群布局: hadoop215hadoop214hadoop217HDFSNameNode SecondaryNameNode DataNodeDataNodeDataNodeYARN ResourceManager NodeManagerNodeManagerNodeManager拜访地址HDFS拜访地址: http://hadoop215:9029YARN拜访地址: http://hadoop215:9019

后面几篇文章对 Yarn 根本架构、程序根底库、利用设计办法等进行了介绍。之后几篇将开始对 Yarn 外围组件进行分析。ResourceManager（RM）是 Yarn 的外围治理服务，负责集群治理、任务调度、状态机治理等，本篇将对 RM 总体架构进行介绍。 一、RM 根本职能次要蕴含以下几个性能： Client 交互：解决来自 Client 的申请；治理 ApplicationMaster：启动、治理、重启等；治理 Nodemanager：接管 NM 汇报的资源信息，并下达治理指令；资源管理与调度：接管 AM 的资源申请，并分配资源。 如上图所示，RM 中各组件通过对应 RPC 与各 Client 进行通信： ResourceTrackerProtocol: NodeManager（NM）通过该 RPC 协定向 RM 注册、汇报节点健康状况和 Container 运行状态，并支付 RM 下达的命令。NM 与 RM 之间采纳了「pull模型」，NM 总是周期性地被动向 RM 发动申请（心跳），并支付下达给本人的命令。ApplicationMasterProtocol: 应用程序的 ApplicationMaster 通过该 RPC 协定向 RM 注册、申请资源和开释资源。（AM 与 RM 交互参考上一篇文章「3-3 Yarn Application Master 编写」）ApplicationClientProtocol: 应用程序的客户端通过该 RPC 协定向 ResourceManager 提交应用程序、查问应用程序状态和控制应用程序（比方杀死应用程序）等。（AppClient 与 RM 交互参考文章「3-2 Yarn Client 编写」从以上介绍中能够看出，与 RM 通过 RPC 通信的组件都采纳「Pull 模型」，各个「Client」通过心跳定期向 RM 汇报，在心跳返回值中支付 RM 下达的指令。 ...

一篇文章彻底了解 HDFS 的平安模式1 什么是 HDFS 的平安模式Hdfs 的平安模式，即 HDFS safe mode, 是 HDFS 文件系统的一种非凡状态，在该状态下，hdfs 文件系统只承受读数据申请，而不承受删除、批改等变更申请，当然也不能对底层的 block 进行正本复制等操作。 从实质上将，平安模式 是 HDFS 的一种非凡状态，而 HDFS 进入该非凡状态的目标，是为了确保整个文件系统的数据一致性/不失落数据，从而限度用户只能读取数据而不能改变数据的。 2 什么状况下 HDFS 会进入平安模式HDFS 进入平安模式的状况分为两种，即被动进入与被动进入。 2.1 HDFS 被动进入平安模式管理员出于运维治理等各种起因，能够被动执行命令让 hdfs 进入平安模式，相干的命令有：hdfs dfsadmin -safemode enter/get/leave; 2.2 HDFS 被动进入平安模式HDFS 也可能会被动进入平安模式，这种状况更为常见，是 HDFS 在非凡情况下，为了保障整个文件系统的数据一致性/整个文件系统不失落数据，而被动进入的一种自我爱护状态，底层根本原因又分为两种： HDFS 底层启动胜利并可能跟 namenode 放弃定期心跳的 datanode 的个数没有达到指定的阈值, 阈值通过参数 dfs.namenode.safemode.min.datanodes 指定；HDFS 底层达到了最小正本数要求的 block 的百分比没有达到指定的阈值：最小正本数通过参数 dfs.namenode.replication.min/dfs.namenode.safemode.replication.min 指定，阈值通过参数 dfs.namenode.safemode.threshold-pct 指定；当然如果 HDFS 底层启动胜利并可能跟 namenode 放弃定期心跳的 datanode 的个数没有达到指定的阈值,此时HDFS 底层达到最小正本数要求的 block 的百分比个别也都不会达到指定的阈值；不难理解，失常状况下，HDFS 启动过程中会有一段时间被动进入平安模式并在一段时间后被动退出平安模式，这是由 hdfs 的分本式架构决定的，因为 namenode 启动胜利后，须要期待 datanode 启动胜利并通过心跳汇报 datanode 上存储的 block 的信息（block report），只有在把握了足够的 block 的信息（达到最小正本数要求的 block 占所有 block 的百分比达到指定的阈值），并期待特定工夫后（通过参数 dfs.namenode.safemode.extension 30000管制），才会被动退出平安模式。从现实情况来看，常见的HDFS进入平安模式的间接起因有： ...

本篇文章持续介绍 Yarn Application 中 ApplicationMaster 局部的编写办法。 一、Application Master 编写办法上一节讲了 Client 提交工作给 RM 的全流程，RM 收到工作后，由 ApplicationsManager 向 NM 申请 Container，并依据 Client 提供的 ContainerLaunchContext 启动 ApplicationMaster。本篇代码已上传 Github：Github - MyApplicationMaster 一）整体流程 1&2、启动 NMClient 和 RMClient在 AM 中须要别离启动 NMClient 和 RMClient 进行通信。两个客户端中都注册了咱们自定义的 eventHandler，将会在前面进行介绍。在 amRMClient 中会定义 AM 向 RM 定时发送心跳的距离。（在 RM 中会有心跳容忍工夫，留神不要超过 RM 配置的工夫） // logInformation();Configuration conf = new Configuration();// 1 create amRMClient// 第一个参数是心跳工夫 msamRMClient = AMRMClientAsync.createAMRMClientAsync(1000, new RMCallbackHandler());amRMClient.init(conf);amRMClient.start();// 2 Create nmClientAsyncamNMClient = new NMClientAsyncImpl(new NMCallbackHandler());amNMClient.init(conf);amNMClient.start();3、向 RM 注册 ApplicationMaster// 3 register with RM and this will heart beating to RMRegisterApplicationMasterResponse response = amRMClient .registerApplicationMaster(NetUtils.getHostname(), -1, "");4、申请 Containers首先须要从 response 中确认资源池残余资源，而后再依据需要申请 container ...

本篇学习 Yarn Application 编写办法，将带你更分明的理解一个工作是如何提交到 Yarn ，在运行中的交互和工作进行的过程。通过理解整个工作的运行流程，帮你更好的了解 Yarn 运作形式，呈现问题时能更好的定位。 一、简介本篇将对 Yarn Application 编写流程进行介绍。将一个新的利用程序运行到 Yarn 上，次要编写两个组件 Client 和 ApplicationMaster，组件的具体实现案例将在后两篇文章中介绍。（理论应用中，咱们并不需要实现一个 Yarn Application，间接将工作提交到 MapReduce、Spark、Hive、Flink 等框架上，再由这些框架提交工作即可，这些框架也能够被视为一种特定的 Yarn Application。）其中，Client 次要用于提交应用程序和管理应用程序，ApplicationMaster 负责实现应用程序的工作切分、调度、监控等性能。 一）Application 的提交和启动流程 二）各服务间波及的 protocol 二、组件实现流程一）Client 实现创立并启动 YarnClient;通过 YarnClient 创立 Application;欠缺 ApplicationSubmissionContext 所需内容: 设置 application name;设置 ContainerLaunchContext;（蕴含 app master jar）设置优先级、队列等提交 Application。二）ApplicationMaster实现创立并启动 AMRMClientAsync，用于与 ResourceManager 通信;创立并启动 NMClientAsync ，用于与 NodeManager 通信;向 ResourceManager 注册，之后会向 ResourceManager 发送心跳;向 ResourceManager 申请 Container。在 Container 中运行 task三）Hadoop 实现案例Hadoop 自带的 hadoop-yarn-applications-distributedshell 是个很好的学习案例，能够参考其中的 Client.java 和 ApplicationMaster.java 两个类进行学习。DistributedShell 能够执行用户指定的 Shell 命令或脚本，蕴含了编写一个 YARN Application 的残缺内容。 ...

history server配置:mapred-site.xml <!-- 指定mapreduce运行在yarn上 --> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> <!-- 历史服务器地址 --> <property> <name>mapreduce.jobhistory.address</name> <value>hadoop-4:10020</value> </property> <!-- 历史服务器web端地址 --> <property> <name>mapreduce.jobhistory.webapp.address</name> <value>hadoop-4:19888</value> </property>yarn-site.xml <!--日志汇集--> <property> <name>yarn.log-aggregation-enable</name> <value>true</value> </property><!--日志汇集服务器地址--> <property> <name>yarn.log.server.url</name> <value>http://hadoop-4:19888/jobhistory/logs</value> </property><!--日志保留工夫--> <property> <name>yarn.log-aggregation.retain-seconds</name> <value>6048000</value> </property>启动history servermapred --daemon start historyserverhistory server web端http://hadoop-4:19888/jobhistory

搭建hadoop集群能够参考我之前的几篇文章.我的hadoop集群版本是3.3.3此处记录一下困扰了好几天的问题:我的hadoop集群如下hadoop-4hadoop-5hadoop-6部署实现后,应用start-dfs.sh启动.有个问题.如果我在hadoop-4启动,集群中所有组件都能失常启动,然而datanode只有hadoop-4失常启动.其余的节点不启动datanode.也没有任何的报错信息.如果你遇到了和我一样的问题.你只须要在hadoop-3.3.3/etc/hadoop下找到works文件,将其中的localhost改成你的所有集群节点 hadoop-4hadoop-5hadoop-6就这样重启即可. 注：解决方案参考下文:https://blog.csdn.net/qq_3833...

接手动配置的上文 减少HA配置hdfs-site.xml <!--启用nn故障主动转移--> <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property>core-site.xml <!--指定zkfc连贯的zk地址--> <property> <name>ha.zookeeper.quorum</name> <value>hadoop-4:2181,hadoop-5:2181,hadoop-6:2181</value> </property>如果你用的是root用户执行命令,你须要在start-dfs.sh stop-dfs.sh增加如下配置 HDFS_ZKFC_USER=rootHDFS_JOURNALNODE_USER=rootHDFS_NAMENODE_USER=rootHDFS_SECONDARYNAMENODE_USER=rootHDFS_DATANODE_USER=rootHDFS_DATANODE_SECURE_USER=rootstart-yarn.sh stop-yarn.sh增加 YARN_RESOURCEMANAGER_USER=rootHADOOP_SECURE_DN_USER=yarnYARN_NODEMANAGER_USER=root执行群启脚本start-dfs.sh群停脚本stop-dfs.sh

配置文件core-site.xml <configuration> <!--多个namenode地址组装成一个集群,这里mycluster变量名是供hdfs-site.xml里文件援用的--> <property> <name>fs.defaultFS</name> <value>hdfs://gms-cluster</value> </property> <!--指定hadoop运行时产生文件的存储目录--> <property> <name>hadoop.tmp.dir</name> <value>/usr/local/hadoop-3.3.3/data</value> </property></configuration>hdfs-site.xml <configuration> <!--name node 数据存储目录--> <property> <name>dfs.namenode.name.dir</name> <value>file://${hadoop.tmp.dir}/name</value> </property> <!--data node 数据存储目录--> <property> <name>dfs.datanode.data.dir</name> <value>file://${hadoop.tmp.dir}/data</value> </property> <!--journal node 数据存储目录--> <property> <name>dfs.journalnode.edits.dir</name> <value>${hadoop.tmp.dir}/jn</value> </property> <!--集群名称--> <property> <name>dfs.nameservices</name> <value>gms-cluster</value> </property> <!--集群中的namenode都有哪些--> <property> <name>dfs.ha.namenodes.gms-cluster</name> <value>nn1,nn2,nn3</value> </property> <!--namenode 外部通信rpc地址--> <property> <name>dfs.namenode.rpc-address.gms-cluster.nn1</name> <value>hadoop-4:8020</value> </property> <property> <name>dfs.namenode.rpc-address.gms-cluster.nn2</name> <value>hadoop-5:8020</value> </property> <property> <name>dfs.namenode.rpc-address.gms-cluster.nn3</name> <value>hadoop-6:8020</value> </property> <!--namenode web拜访http地址--> <property> <name>dfs.namenode.http-address.gms-cluster.nn1</name> <value>hadoop-4:9870</value> </property> <property> <name>dfs.namenode.http-address.gms-cluster.nn2</name> <value>hadoop-5:9870</value> </property> <property> <name>dfs.namenode.http-address.gms-cluster.nn3</name> <value>hadoop-6:9870</value> </property> <!--指定namenode 元数据在JournalNode上的寄存地位--> <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://hadoop-4:8485;hadoop-5:8485;hadoop-6:8485/gms-cluster</value> </property> <!--拜访代理:client用于确定哪个namenode是active--> <!-- HA集群中,用户并不知道到底哪一台机器是active的,所以拜访的时候,间接拜访集群名称(gms-cluster),而后申请就会交给上面这个代理类,它会帮咱们找到以后的active并将拜访转发 --> <property> <name>dfs.client.failover.proxy.provider.gms-cluster</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <!--隔离机制(避免脑裂),即同一时刻只能有一个台服务器对外响应--> <property> <name>dfs.ha.fencing.methods</name> <value>sshfence</value> </property> <!--应用隔离机制时,须要ssh登录(主动故障转移的时候会用到)--> <property> <name>dfs.hafencing.ssh.private-key-files</name> <value>/root/.ssh/id_rsa</value> </property> <!--启用nn故障主动转移--> <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property> <!--指定hdfs正本数--> <property> <name>dfs.replication</name> <value>3</value> </property></configuration>启动journal node(三台都启动)hdfs --daemon start journalnode任选一台,格式化name nodehdfs namenode -format启动hdfs --daemon start namenode其余两台,同步主节点的name node数据hdfs namenode -bootstrapStandby其余两台,也启动name nodehdfs --daemon start namenode三台的ip:9870都能失常拜访到hadoop的控制台,并且都是standby状态

一个宏大的分布式系统，各个组件间是如何协调工作的？组件是如何解耦的？线程运行如何更高效，缩小阻塞带来的低效问题？本节将对 Yarn 的服务库和事件库进行介绍，看看 Yarn 是如何解决这些问题的。 一、服务库一）简介对于生命周期较长的对象，Yarn 采纳基于服务的模型对其进行治理，有以下几个特点： 基于状态治理：分为 4 个状态：NOTINITED(被创立)、INITED(已初始化)、 STARTED(已启动)、STOPPED(已进行)。服务状态的变动会触发其余的操作。可通过组合的形式对服务进行组合。二）源码简析源代码地址在 hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/service 的 Service 接口中。其中定义了服务的四个状态，以及须要实现的状态转换、获取信息、注册等办法。 public interface Service extends Closeable { public enum STATE { NOTINITED(0, "NOTINITED"), INITED(1, "INITED"), STARTED(2, "STARTED"), STOPPED(3, "STOPPED"); } void init(Configuration config); void start(); void stop(); void close() throws IOException; void registerServiceListener(ServiceStateChangeListener listener); // ......抽象类 AbstractService 实现了 Service 接口，提供了根底的 Service 实现，非组合服务间接继承这个抽象类再开发即可。 public abstract class AbstractService implements Service { // 以 start 实现为例，执行后会触发其余的操作 public void start() { if (isInState(STATE.STARTED)) { return; } //enter the started state synchronized (stateChangeLock) { if (stateModel.enterState(STATE.STARTED) != STATE.STARTED) { try { startTime = System.currentTimeMillis(); serviceStart(); if (isInState(STATE.STARTED)) { //if the service started (and isn't now in a later state), notify if (LOG.isDebugEnabled()) { LOG.debug("Service " + getName() + " is started"); } notifyListeners(); } } catch (Exception e) { noteFailure(e); ServiceOperations.stopQuietly(LOG, this); throw ServiceStateException.convert(e); } } } } // ......对于组合类的服务如 ResourceManager、NodeManager 等，须要继承 CompositeService。其中会有对组合服务的逻辑解决。 ...

RPC（Remote Procedure Call） 是 Hadoop 服务通信的要害库，撑持下层分布式环境下简单的过程间（Inter-Process Communication, IPC）通信逻辑，是分布式系统的根底。容许运行于一台计算机上的程序像调用本地办法一样，调用另一台计算机的子程序。因为 RPC 服务整体常识较多，本节仅针对对 Yarn RPC 进行简略介绍，具体内容会后续开专栏介绍。 一、RPC 通信模型介绍为什么会有 RPC 框架？在分布式或微服务情境下，会有大量的服务间交互，如果用传统的 HTTP 协定端口来通信，须要消耗大量工夫解决网络数据交换上，还要思考编解码等问题。如下图所示。 客户端通过 RPC 框架的动静代理失去一个代理类实例，称为 Stub（桩）客户端调用接口办法（理论是 Stub 对应的办法），Stub 会结构一个申请，包含函数名和参数服务端收到这个申请后，先将服务名（函数）解析进去，查找是否有对应的服务提供者服务端找到对应的实现类后，会传入参数调用服务端 RPC 框架失去返回后果后，再进行封装返回给客户端客户端的 Stub 收到返回值后，进行解析，返回给调用者，实现 RPC 调用。 二、Hadoop RPC 介绍一）简介Hadoop RPC 是 Hadoop 本人实现的一个 RPC 框架，次要有以下几个特点： 透明性：像调用本地办法一样调用近程办法。高性能：Hadoop 各个系统均采纳 Master/Slave 构造，Master 是一个 RPC Server 用于解决各个 Slave 节点发送的申请，须要有高性能。可控性：因为 JDK 中的 RPC 框架 RMI 重量级过大，且封装度太高，不不便管制和批改。因而实现了本人的 RPC 框架，以保障轻量级、高性能、可控性。框架原理和整体执行流程与第一节介绍的 RPC 框架统一，感兴趣可深刻源码进行理解。 二）总体架构Hadoop RPC 架构底层依附 Java 的 nio、反射、动静代理等性能实现「客户端 - 服务器（C/S）」通信模型。下层封装供程序调用的 RPC 接口。 ...

当多个工作提交到一个队列上时，如果想让后提交的工作优先执行，就须要有工作优先级机制来帮忙。上面介绍如何开启工作优先级配置，以及设置工作优先级。 一、开启工作优先级配置在 resource manager yarn-site.xml 中增加 yarn.cluster.max-application-priority，而后重启 rm。 <property> <name>yarn.cluster.max-application-priority</name> <value>80</value></property>留神： 这个参数是 rm 端参数，无需增加到 nm最大值能够本人设置rm 在 2.8.0 之后才反对此配置 二、设置工作优先级一）MapReduce 工作增加参数 -D mapreduce.job.priority=30测试： hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.8.5.jar wordcount -D mapreduce.job.priority=30 /input /output 二）Hive/Tez 工作增加参数 set tez.am.application.priority=30;三）留神提交工作的客户端须要反对工作优先级配置如 hadoop 提交 mr 程序，须要客户端版本在 2.8.0 以上

理解 Yarn 根底库是前面浏览 Yarn 源码的根底，本节对 Yarn 根底库做总体的介绍。并对其中应用的第三方库 Protocol Buffers 和 Avro 是什么、怎么用做简要的介绍。 一、次要应用的库Protocol Buffers：是 Google 开源的序列化库，具备平台无关、高性能、兼容性好等长处。YARN 将其用到了 RPC 通信中，默认状况 下，YARN RPC 中所有参数采纳 Protocol Buffers 进行序列化 / 反序列化。Apache Avro：是 Hadoop 生态系统中的 RPC 框架，具备平台无关、反对动静模式(无需编译)等长处，Avro 的最后设计动机是解决 YARN RPC 兼容性和扩展性 差等问题。RPC 库：YARN 仍采纳了 MRv1 中的 RPC 库，但其中采纳的默认序列化办法被替换成了 Protocol Buffers。服务库和事件库 :YARN 将所有的对象服务化，以便对立治理(比创立、销毁等)， 而服务之间则采纳事件机制进行通信，不再应用相似 MRv1 中基于函数调用的形式。状态机库：YARN 采纳无限状态机形容一些对象的状态以及状态之间的转移。引入状态机模型后，相比 MRv1， YARN 的代码构造更加清晰易懂。 二、第三方开源库介绍一）Protocol Buffers1、简要介绍Protocol Buffers 是 Google 开源的一个语言无关、平台无关的通信协议，其玲珑、高效和敌对的兼容性设计，使其被宽泛应用。【能够类比 java 自带的 Serializable 库，性能上是一样的。】 Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.外围特点： ...

本文将介绍如何应用 idea 搭建 Hadoop 源码浏览环境。（默认已装置好 Java、Maven 环境） 一、搭建源码浏览环境一）idea 导入 hadoop 工程从 github 上拉取代码。https://github.com/apache/hadoop能够抉择对应的分支 # 如拉取 2.8.5 分支git clone -b branch-2.8.5 [email protected]:apache/hadoop.git在 idea 中点击 File - Open 抉择对应的文件夹目录，进行导入。之后会进入漫长的程序加载过程（看机器配置和网速，可能几十分钟到几小时不等）。 二）配置正文环境为了更不便的在浏览源码过程中记笔记，可在源码根底上创立新的分支用于记录。1、创立新分支 # 如在 branch-2.8.5 根底上创立git checkout -b branch-2.8.5-comment2、在 github 上创立个新的我的项目3、将本地分支 branch-2.8.5-comment 推送到远端。之后能够在本人 github 上看到这个我的项目分支了。 # 删除原来的远端我的项目git remote remove origin# 增加新的我的项目地址git remote add origin <你的我的项目地址># 推送新的分支git push -u origin branch-2.8.5-comment二、源码组织架构一）根目录构造导入工程后，能够看到如下图的目录构造。其中，比拟重要的目录有：hadoop-common-project、hadoop-mapreduce- project、hadoop-hdfs-project 和 hadoop-yarn-project 等。 hadoop-common-project：Hadoop 根底库所在目录，该目录中蕴含了其余所有模块可能会用到的根底库，包含 RPC、Metrics、Counter 等；hadoop-mapreduce-project：MapReduce 框架的实现；hadoop-hdfs-project：Hadoop 分布式文件系统实现；hadoop-yarn-project：Hadoop 资源管理零碎 YARN 实现，是咱们须要重点关注的局部。 ...

一、Yarn 产生的背景Hadoop2 之前是由 HDFS 和 MR 组成的，HDFS 负责存储，MR 负责计算。 一）MRv1 的问题耦合度高：MR 中的 jobTracker 同时负责资源管理和作业控制两个性能，互相制约。可靠性差：治理节点是单机的，有单点故障的问题。资源利用率低：基于 slot 的资源分配模型。机器会将资源划分成若干雷同大小的 slot，并划定哪些是 map slot、哪些是 reduce slot。无奈反对多种计算框架：限定了只能用于 MapReduce 程序。 二）Yarn 的诞生因为之前 Hadoop 资源调度的种种问题，新的资源调度框架产生了 —— YARN（Yet Another Resource Negotiator）。 它是一个通用资源管理零碎，可为下层利用提供对立的资源管理和调度，它的引入为集群在利用率、资源对立治理和数据共享等方面带来了微小益处。 二、Yarn 的根本架构一）Yarn 三大组件ResourceManagerNodemanagerApplicationMaster 在资源架构层面：RM 是 master、NM 是 slave在利用运行期间：AM 是 master、container 是 slave 1、ResourceManagerResourceManager 次要由两个组件形成：调度器( Scheduler）和应用程序管理器（Applications Manager，ASM)。 调度器（Scheduler）： 依据容量、队列等限度条件（如每个队列调配肯定的资源，最多执行肯定数量的作业等），将零碎中的资源分配给各个正在运行的应用程序。应用程序管理器（Applications Manager）： 负责管理整个零碎中所有应用程序，包含应用程序提交、与调度器协商资源以启动 ApplicationMaster、监控 ApplicationMaster 运行状态并在失败时重新启动等。2、NodeManagerNodeManager 是每个节点上的资源和工作管理器。 定时地向 RM 汇报本节点上的资源应用状况和各个 Container 的运行状态；接管并解决来自 AM 的 Container启动/进行等各种申请。 3、ApplicationMasterApplicationMaster 是一个工作最先启动的容器，用于治理当前任务的调度。 与 RM 调度器协商以获取资源（用 Container 示意）；将失去的工作进一步调配给外部的工作；与NM 通信以启动 / 进行工作；监控所有工作运行状态，并在工作运行失败时从新为工作申请资源以重启工作。 ...

本篇文章咱们来模仿一个实在的危险辨认场景，模仿XX平台上可能呈现盗号行为。技术实现计划：（1）通过将xxx平台用户登录时的登录日志发送到kafka（本文代码演示用的socket）；（2）Flink CEP SQL规定引擎中定义好风控辨认规定，接入kafka数据源，比方一个账号在5分钟内，在多个不同地区有登录行为，那咱们认为该账号被盗；（3）Flink CEP将辨认到的危险数据能够进行下发，为数据应用层提供数据服务，如：风控系统，数据大屏，态势感知..... （1）咱们先来定义一个数据生产者，模仿用户登录，产生登录日志： package com.producers;import java.io.BufferedWriter;import java.io.IOException;import java.io.OutputStreamWriter;import java.net.ServerSocket;import java.net.Socket;import java.util.Random;/** * Created by lj on 2022-08-10. */public class Socket_Producer1 { public static void main(String[] args) throws IOException { try { ServerSocket ss = new ServerSocket(9999); System.out.println("启动 server ...."); Socket s = ss.accept(); BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(s.getOutputStream())); String response = "java,1,2"; //每 2s 发送一次音讯 int i = 0; Random r=new Random(); String[] userArr = {"user1","user2","user3","user4","user5","user6","user7","user8","user9"}; String[] loginIP = {"167.234.67.123","219.141.178.14","220.180.239.202","111.73.240.192","123.182.253.242"}; while(true){ Thread.sleep(2000); response= userArr[r.nextInt(userArr.length)] + "," + loginIP[r.nextInt(loginIP.length)] +"\n"; System.out.println(response); try{ bw.write(response); bw.flush(); i++; }catch (Exception ex){ System.out.println(ex.getMessage()); } } } catch (IOException | InterruptedException e) { e.printStackTrace(); } }}（2）在CEP中接入日志数据、定义风控规定 ...

Java装置[root@localhost jdk-11.0.15]# cd /etc/profile.d/[root@localhost profile.d]# vim my_env.sh[root@localhost profile.d]# source /etc/profile机器初始配置因为我这是虚拟机,所以要配置固定ip。如果你也和我一样是本人测试，肯定留神netmask和gateway要更换成本人的。 vim /etc/sysconfig/network-scripts/ifcfg-enp0s3------------------------------------- IPADDR="192.168.0.114"NETMASK="255.255.255.0"GATEWAY="192.168.0.1"DNS1="114.114.114.114"hostname hostnamectl set-hostname hadoop-1cat >> /etc/hosts << EOF192.168.0.114 hadoop-1192.168.0.115 hadoop-2192.168.0.116 hadoop-3EOF集群布局ipname组件192.168.0.114hadoop-1namenode datanode journalnode192.168.0.115hadoop-2namenode datanode journalnode192.168.0.116hadoop-3namenode datanode journalnode配置上传解压等疏忽两个外围配置文件:core-site.xml hdfs-site.xml地位：/usr/hadoop/hadoop-3.3.3/etc/hadoop

简介：本篇内容分享了MaxCompute湖仓一体介绍。 分享人：孟硕 阿里云 MaxCompute产品专家 视频链接：https://developer.aliyun.com/... 注释： 本篇内容将通过两个局部来介绍MaxCompute湖仓一体。 一、什么是 MaxCompute 湖仓一体 二、湖仓一体胜利案例介绍 一、什么是 MaxCompute 湖仓一体湖仓一体的整体架构，次要面向数据分析师，数据科学家以及大数据工程师来应用。次要利用的业务有Machine，非结构化数据分析，Ad-hoc/BI，Reporting和Learning等等。在整体架构中，DataWorks作为数据对立开发治理的平台，次要负责数据安全，开发IDE，任务调度和数据资产治理等综合工作，确保平台稳固运行。 如上图所示，在整体架构中，咱们首先将数据湖集群和MaxCompute数仓集群的网络买通，而后将存储层的数据买通，确保智能Cache，冷热分层，存储优化和性能减速。在计算层，我么实现了DB级元数据的透视，防止数据孤岛。 DataWorks对立了各种数据资产，比方E-MapReduce，CDH HBase，CDH Hive和AnalyticDB for等。岂但能在数据地图中看到全域的数据资产，而且还反对从数据源里抽取元素与信息。 在阿里外部，咱们实现了肯定水平的数据民主化。现如今，阿里团体外部所有的表，员工都可能看到表名称和的元数据信息，以及信息的安全等级。DataWorks作为中台：能够从列表中反对的数据源采集数据，纳入平台管控。 目前，对立的表级、字段级别数据血统就现有的产品能力，只能局限于繁多引擎外部的跨血统。预计明年可能实现跨引擎的数据血统。 在繁多引擎外部，能够挂载多个hadoop集群，实现对立引擎的对接与治理。 DataWorks作为对立的数据开发平台，可能将MC的工作和hadoop工作混编在一个流程中。岂但能够对立长期查问入口，发送给不同的引擎。而且能够将不同的引擎作业混合调度。比方数据集成作业，MaxCompute作业以及Hive作业等。 二、湖仓一体胜利案例介绍某互联网游戏公司的广告算法团队是湖仓一体次要客户，次要利用是机器学习DW+MC+PAI+EAS在线模型服务。该团队的自服务水平高、须要一站式的机器学习平台。而Hadoop集群有多团队共用，应用集群管控较严，无奈短时间撑持大workload的翻新业务。 基于以上需要，咱们通过湖仓一体，将新业务平台与原有数据平台买通，即PAI on MaxCompute+DataWorks。为客户提供了一站式机器学习，模型开发、模型公布，大规模计算等能力，晋升了团队的工作效率。 数禾公司通过引入MaxCompute作为计算引擎的数据中台，岂但让数据湖计算自在流动，而且解决了先前异构计算引擎存储管理，元数据管理和权限治理不同对立的问题。岂但晋升了整体的工作效率，而且升高了运维老本，起到了降本增效的作用。 上图是数禾公司构建的基于MaxCompute+DLF+EMR的湖仓一体架构。底层是OSS数据湖存储，咱们通过DLF构建了元数据管理，数据血统治理，数据权限治理。通过JindoFS+MC的形式，实现了数据的冷热分层和本地缓存。咱们联合MaxCompute和EMR，胜利实现了智能数据构建与数据中台治理。 在将来，湖仓对立开发治理平台，可能实现湖仓数据的一站式治理与治理。OSS的对象存储岂但反对结构化数据，也能反对非机构化数据。整个平台岂但能同步联邦数据源，而且能对立元数据服务和元数据仓库。 原文链接本文为阿里云原创内容，未经容许不得转载。

一、Shuffle机制 1）Map办法之后Reduce办法之前这段处理过程叫Shuffle 2）Map办法之后，数据首先进入到分区办法，把数据标记好分区，而后把数据发送到环形缓冲区；环形缓冲区默认大小100m，环形缓冲区达到80%时，进行溢写；溢写前对数据进行排序，排序依照对key的索引进行字典程序排序，排序的伎俩快排；溢写产生大量溢写文件，须要对溢写文件进行归并排序；对溢写的文件也能够进行Combiner操作，前提是汇总操作，求平均值不行。最初将文件依照分区存储到磁盘，期待Reduce端拉取。 3）每个Reduce拉取Map端对应分区的数据。拉取数据后先存储到内存中，内存不够了，再存储到磁盘。拉取完所有数据后，采纳归并排序将内存和磁盘中的数据都进行排序。在进入Reduce办法前，能够对数据进行分组操作。 关键词：大数据培训

初识hadoopGoogle的“三驾马车“GFSMapReduceBigTableHDFSHDFS是什么？ HDFS是基于流数据拜访模式的分布式文件系统，反对海量数据的存储，容许用户将成千盈百的计算机，组成存储集群。长处：能够解决超大文件、反对流式数据拜访(一次写入，屡次读取)、低成本运行。毛病：不适宜解决低提早的数据拜访，次要解决高数据吞吐量的利用；不适宜解决大量的小文件，这样会节约NameNode内存；不适宜多用户写入及任意批改文件。 HDFS的组成架构 NameNode NameNode即名称节点，是HDFS的管理者。次要性能（三个）：治理和保护 HDFS 的命名空间：命名空间镜像文件( fsimage )，操作日志文件( edits ) fsimage：存储 hadoop 文件系统中的所有目录和文件的序列化信息edits：记录 HDFS 最新状态， HDFS 客户端执行的所有写操作记录在 editlog 中治理 DataNode 上的数据块：在 HDFS 中，一个文件被分成一个或多个数据块，这些数据块存储在 DataNode 中， NameNode 通过“文件名-->数据块”映射或者“数据块-->DataNode”来确定接管客户端的申请DataNode 每个磁盘都有默认的数据块大小，它是磁盘进行读、写的最小单位，HDFS默认数据块大小为128MB。数据块如此大，目标是缩小寻址开销，缩小磁盘一次读取工夫。性能：保留数据块：每个数据块对应一个元数据信息文件，用来形容该数据块属于哪个文件，是第几个数据块运行 DataNode 线程，向 NameNode 定期汇报数据块信息定期向 NameNode 发送心跳信息保持联系SecondaryNameNode 即第二名称节点，主要职责是定期把 NameNode 的 fsimage 和 edits 下载到本地，并将它们加载到内存进行合并，最初将合并后的新的 fsimage 上传回 NameNode ，此过程称为检查点 ( CheckPoint )。定期合并 fsimage 和 edits 文件，使 edits 大小放弃在限度范畴内，缩小重新启动 NameNode 时合并 fsimage 和 edits 消耗的工夫。 HDFS Shell HDFS Shell 命令是用相似于 Linux Shell 的命令，来操作文件系统。如：hdfs dfs -ls，列出文件或目录。HDFS API ...

1、增加白名单 白名单：示意在白名单的主机 IP 地址能够，用来存储数据。 企业中：配置白名单，能够尽量避免黑客歹意拜访攻打。 配置白名单步骤如下： 1）在 NameNode 节点的/opt/module/hadoop-3.1.3/etc/hadoop 目录下别离创立 whitelist 和 blacklist 文件 （1）创立白名单 [atguigu@hadoop102 hadoop]$ vim whitelist 在 whitelist 中增加如下主机名称，如果集群失常工作的节点为 102 103 hadoop102hadoop103 （2）创立黑名单 [atguigu@hadoop102 hadoop]$ touch blacklist 放弃空的就能够 2）在 hdfs-site.xml 配置文件中减少 dfs.hosts 配置参数 <!-- 白名单 --><property> <name>dfs.hosts</name> <value>/opt/module/hadoop-3.1.3/etc/hadoop/whitelist</value></property> <!-- 黑名单 --><property> <name>dfs.hosts.exclude</name> <value>/opt/module/hadoop-3.1.3/etc/hadoop/blacklist</value></property> 3）散发配置文件 whitelist，hdfs-site.xml [atguigu@hadoop104 hadoop]$ xsync hdfs-site.xml whitelist 4）第一次增加白名单必须重启集群，不是第一次，只须要刷新 NameNode 节点即可 [atguigu@hadoop102 hadoop-3.1.3]$ myhadoop.sh stop[atguigu@hadoop102 hadoop-3.1.3]$ myhadoop.sh start 5）在 web 浏览器上查看 DN，http://hadoop102:9870/dfsheal... 6）在 hadoop104 上执行上传数据数据失败 ...

异构存储次要解决，不同的数据，存储在不同类型的硬盘中，达到最佳性能的问题。 Hadoop 的存储类型和存储策略有; 1、查看以后有哪些存储策略能够用 [atguigu@hadoop102 hadoop-3.1.3]$ hdfs storagepolicies-listPolicies2、为指定门路（数据存储目录）设置指定的存储策略 hdfs storagepolicies -setStoragePolicy -pathxxx -policy xxx3、获取指定门路（数据存储目录或文件）的存储策略 hdfs storagepolicies -getStoragePolicy -path xxx4、勾销存储策略；执行改命令之后该目录或者文件，以其下级的目录为准，如果是根目录，那么就是 HOT hdfs storagepolicies -unsetStoragePolicy-path xxx5、查看文件块的散布 bin/hdfs fsck xxx -files -blocks -locations6、查看集群节点 hadoop dfsadmin -report 2、测试环境筹备 1、测试环境形容 服务器规模：5 台 集群配置：正本数为 2，创立好带有存储类型的目录（提前创立） 集群布局： 2、配置文件信息 （1）为 hadoop102 节点的 hdfs-site.xml 增加如下信息 <property> <name>dfs.replication</name> <value>2</value> </property> <property> <name>dfs.storage.policy.enabled</name> <value>true</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>[SSD]file:///opt/module/hadoop-3.1.3/hdfsdata/ssd,[RAM_DISK]file:///opt/module/hadoop-3.1.3/hdfsdata/ram_disk </value></property>（2）为 hadoop103 节点的 hdfs-site.xml 增加如下信息 <property> <name>dfs.replication</name> <value>2</value> </property><property> <name>dfs.storage.policy.enabled</name> <value>true</value> </property><property> <name>dfs.datanode.data.dir</name> <value>[SSD]file:///opt/module/hadoop-3.1.3/hdfsdata/ssd,[DISK]file:///opt/module/hadoop-3.1.3/hdfsdata/disk </value> </property>（3）为 hadoop104 节点的 hdfs-site.xml 增加如下信息 ...

阐明： 1、tracking的数据起源，包含SDK数据、点击上报数据，SDK数据又分为SDK客户端上报和RestAPI上报。 2、RestAPI和SDK客户端上报的数据，都发到阿里云e302服务器。点击上报数据，优先会往阿里云的e302短链服务器发送，e302服务器查看接管到的点击的短链在缓存中不存在，会跳转到s302回源服务器，不论在e302还是s302，找到短链的点击都会跳转到对应的落地页。 3、RestAPI数据间接上报到logserver服务器。 4、SDK客户端和点击上报的数据在往logserver服务器发送过程会被NWS缓存服务器拦挡，先缓存到本地，当nws关上开关时，数据nws往logserver发送；当nws敞开开关时，不发送。（nsw能够缓存100G的数据） 5、logserver接管到数据后，进行数据散发，数据会依据业务需要，发往kafka的不同topic。 6、实时计算的jstorm工作从kafka的topic中取出数据，进行归因解决，解决实现后，对于须要点击透传的点击事件以及归因后须要回调的激活/注册/付费事件，发送到kafka的回调topic。 7、实时计算解决实现后，统计数据会入库hbase，用于归因排重的信息会入库到redis。 8、stat_exporter服务会定时从hbase中导出统计数据并入库到tracking的mysql数据库。 9、logserver日志会定时上传到hdfs集群。 10、zakaban调度平台上配置的离线工作，会对logserver日志进行解决，别离计算设施留存、设施ltv、帐号留存、帐号ltv。 11、离线计算实现后入库到hive。 12、trackv2task服务定期从hive导出前一天的离线计算结果入库到tracking的mysql数据库。 13、callback回调服务会实时从kafka的回调topic中取到须要回调或点击透传的音讯，进行激活/注册/付费回调或点击透传。 14、tracking的web后盾从mysql及hbase中查问数据并展现，实时模块从hbase查。 15、tracking通过OpenAPI向内部（次要是adt）提供api接口查问数据。 16、adt的后端服务定时从tracking的数据库同步数据。

一、虚拟机环境筹备1.    克隆虚拟机                                                       2.    批改克隆虚拟机的动态IP 3.    批改主机名 4.    敞开防火墙 5.    创立atguigu用户 6.    配置atguigu用户具备root权限（详见《尚硅谷大数据技术之Linux》） 7．在/opt目录下创立文件夹 （1）在/opt目录下创立module、software文件夹 [atguigu@hadoop101 opt]$ sudo mkdir module [atguigu@hadoop101 opt]$ sudo mkdir software （2）批改module、software文件夹的所有者cd [atguigu@hadoop101 opt]$ sudo chown atguigu:atguigu module/ software/ [atguigu@hadoop101 opt]$ ll 总用量 8 drwxr-xr-x. 2 atguigu atguigu 4096 1月  17 14:37 module drwxr-xr-x. 2 atguigu atguigu 4096 1月  17 14:38 software 二、 装置JDK1.    卸载现有JDK （1）查问是否装置Java软件： [atguigu@hadoop101 opt]$ rpm -qa | grep java （2）如果装置的版本低于1.7，卸载该JDK： [atguigu@hadoop101 opt]$ sudo rpm -e 软件包 ...

1）防火墙没敞开、或者没有启动YARN INFO client.RMProxy: Connecting to ResourceManager at hadoop108/192.168.10.108:80322）主机名称配置谬误 3）IP地址配置谬误 4）ssh没有配置好 5）root用户和atguigu两个用户启动集群不对立 6）配置文件批改不仔细 7）未编译源码 Unable to load native-hadoop library for your platform... using builtin-java classes where applicable17/05/22 15:38:58 INFO client.RMProxy: Connecting to ResourceManager at hadoop108/192.168.10.108:80328）不辨认主机名称 java.net.UnknownHostException: hadoop102: hadoop102 at java.net.InetAddress.getLocalHost(InetAddress.java:1475) at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:146) at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1290) at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1287) at java.security.AccessController.doPrivileged(Native Method)at javax.security.auth.Subject.doAs(Subject.java:415)解决办法： （1）在/etc/hosts文件中增加192.168.1.102 hadoop102 （2）主机名称不要起hadoop hadoop000等非凡名称 9）DataNode和NameNode过程同时只能工作一个。 10）执行命令不失效，粘贴word中命令时，遇到-和长–没辨别开。导致命令生效 解决办法：尽量不要粘贴word中代码。 11）jps发现过程曾经没有，然而重新启动集群，提醒过程曾经开启。起因是在linux的根目录下/tmp目录中存在启动的过程临时文件，将集群相干过程删除掉，再重新启动集群。 12）jps不失效。 起因：全局变量hadoop java没有失效。解决办法：须要source /etc/profile文件。 13）8088端口连贯不上 [atguigu@hadoop102 桌面]$ cat /etc/hosts 正文掉如下代码 #127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4#::1 hadoop102关键词：大数据培训 ...

1、Hadoop是什么？ 简略来说就是一个文件贮存剖析的技术框架，能够对海量的数据进行贮存于剖析计算。2、为什么用到？ 现阶段一些公司会有大量的文档以及数据，对文档以及数据进行治理与剖析。3、如何应用？ 1。部署Hadoop环境 在Linux零碎中进行解压装置2、在Java我的项目中引入相干Maven Windows零碎的环境配置，如JDK环境配置步骤一样3、用代码对Hadoop进行操作

狭义上的Hadoop是指其整个技术生态体系，包含但不限于以下组件： 图3-1-1：Hadoop技术生态体系 这里抉择几个比拟重要的组件简略介绍一下，之后会作具体介绍： 一、HBase：分布式数据库 HBase是Hadoop的数据库，HBase是一个分布式的、面向列的开源非关系型数据库，它不同于个别的关系数据库，是一个适宜非结构化数据存储的数据库。HBase利用Hadoop的HDFS作为其文件存储系统，利用ZooKeeper作为其协调工具，非常适合用来进行大数据的实时读写。 HBase表是一个稠密多维表，表中的数据是未经解释的字符串，没有数据类型，每一行都有一个行键，表被分组成许多列族汇合，列族反对动静扩大，能够很不便地增加一个列族或列，毋庸当时预约列的数量和类型，所有列都是以字符串的模式存储。 二、Hive：数据仓库工具 Hive是一个基于Hadoop的弱小的数据仓库工具，它能够将结构化的数据文件映射为一张数据库表，并提供简略的SQL查问性能，能够将SQL语句转换为MapReduce工作进行运行。其长处是学习成本低，能够通过类SQL语句疾速实现简略的MapReduce统计，不用开发专门的MapReduce利用，非常适宜数据仓库的统计分析。 三、Kafka：分布式公布订阅音讯零碎 Kafka是一种高吞吐量的分布式公布订阅音讯零碎，它能够解决消费者在网站中的所有动作流数据。对于像Hadoop一样的日志数据和离线剖析零碎，但又要求实时处理的限度，Kafka是一个可行的解决方案。Kafka的目标是通过Hadoop的并行加载机制来对立线上和离线的音讯解决，也是为了通过集群来提供实时的音讯。 四、ZooKeeper：分布式协调服务 ZooKeeper作为一个高可用的分布式服务框架，次要用来解决分布式集群中利用零碎的一致性问题，它能够加重分布式应用程序所承当的协调工作，大数据培训在Hadoop、HBase、Kafka等分布式系统中，ZooKeeper都是作为外围组件应用的。其典型利用场景有：实现HDFS的NameNode高可用HA；实现HBase的HMaster高可用HA. ZooKeeper的部署节点个别为奇数个。 五、Spark：内存分布式计算框架 Spark是一个能够将输入后果保留在内存中的微批处理分布式疾速计算框架，能够批处理和交互式解决，反对多语言（Java, Python, Scala, R等），具备丰盛的API. 其劣势在于能同时实现离线和实时计算。 Spark SQLSpark中解决结构化数据的一个模块，能够应用类SQL语句进行Spark编程。Spark SQL反对很多种结构化数据源，能够跳过简单的读取过程，轻松从各种数据源读取到Row对象。这些数据源包含Hive表、JSON和Parquet文件等。 Spark Streaming为数据流解决而生，相似的还有Storm（准实时）. 其原理是把接管到的数据流分很多小的批次（batches），而后分批解决输入，称为微批处理（非真正的准实时），且其解决计算过程是在内存中实现的，比MapReduce须要利用HDFS磁盘空间的离线批处理效率进步很多： 图3-5-1：Spark Streaming Spark Streaming的数据源能够是Kafka，Flume等，流处理过程中能够应用MLib库进行一些机器学习方面的建模等工作： 图3-5-2：Spark Streaming Spark MLibSpark中能够扩大的机器学习库，它由一系列的机器学习算法和实用程序组成。包含分类、回归、聚类、协同过滤等，还蕴含一些底层优化的办法。 Spark GraphXSaprk的一个分布式图（属性图、社交图、有向图、无向图等）解决框架，次要用于进行以图为外围的计算和分布式计算。它是基于Spark平台提供对图计算和图开掘简洁易用而丰盛的接口，极大的不便了对分布式图解决的需要。

Hadoop 是什么 1) Hadoop 是一个由 Apache 基金会所开发的分布式系统基础架构。 2）次要解决，海量数据的存储和海量数据的剖析计算问题。 3）狭义上来说，Hadoop 通常是指一个更宽泛的概念——Hadoop 生态圈。 Hadoop 倒退历史 1) Lucene 框架是 Doug Cutting 创始的开源软件，用 Java 书写代码，实现与 Google 相似的全文搜寻性能，它提供了全文检索引擎的架构，包含残缺的查问引擎和索引引擎。 Hadoop 创始人 Doug Cutting 2) 2001 年年底 Lucene 成为 Apache 基金会的一个子项目。 3）对于海量数据的场景，Lucene 面对与 Google 同样的艰难，存储数据艰难，检索速度慢。4）学习和模拟 Google 解决这些问题的方法︰微型版 Nutch。 5）能够说 Google 是 Hadoop 的思维之源(Google 在大数据方面的三篇论文) GFS -->HDFS Map-Reduce -—>MR BigTable --->HBase 6) 2003-2004 年，Google 公开了局部 GFS 和 MapReduce 思维的细节，以此为根底 Doug Cutting 等人用了 2 年业余时间实现了 DFS 和 MapReduce 机制，使 Nutch 性能飙升。 ...

从 Hadoop 迁徙到基于云的古代架构（比方 Lakehouse 架构）的决定是业务决策，而非技术决策。咱们在之前的文章中探讨了每一个组织都必须从新评估他们与 Hadoop 的关系的起因。当来自技术、数据和业务的利害关系方决定将企业从 Hadoop 转移进来之后，在开始真正的转变之前，须要思考Top Considerations When Planning Your Migration Off of Hadoop - The Databricks Blog。本文中，咱们将特地关注理论的迁徙过程自身。你将学习胜利迁徙的关键步骤，以及 Lakehouse 架构在激发下一轮数据驱动翻新中所表演的角色。 迁徙步骤坦率的说吧，迁徙从来不是一件简略的事件。不过，能够对迁徙进行结构化，从而最大限度地缩小不利影响，确保业务连续性，并无效地治理老本。为此，咱们倡议将你从 Hadoop 的迁徙分解成以下五个关键步骤： 治理 数据迁徙 数据处理 平安及管治 SQL 和 BI 层 第一步：治理 让咱们从治理的角度回顾一下 Hadoop 中的一些基本概念，以及它们与 Databricks 的比照。 Hadoop 实质上是一个单体分布式存储和计算平台。它由多个节点和服务器组成，每个节点都有本人的存储、CPU 和内存。工作被调配到所有这些节点。通过 YARN 来实现资源管理，它力求确保工作负载可能取得其计算份额。 Hadoop 也包含元数据信息。有一个 Hive 元存储，它蕴含了存储在 HDFS 中的资产的结构化信息。你能够应用 Sentry 或 Ranger 来管制对数据的拜访。从数据拜访的角度来看，用户和应用程序能够间接通过 HDFS（或相应的 CLI/API）或通过 SQL 类型的接口拜访数据。另外，SQL 接口能够通过 JDBC/ODBC 连贯，应用 Hive 来执行通用 SQL（或在某些状况下应用 ETL 脚本），或者在 Impala 或 Tez 上应用 Hive 进行交互式查问。Hadoop 还提供了一个 HBase API 和相干的数据源服务。 ...

作者：幻好 起源：恒生LIGHT云社区 基本概念MapReduce 是一个分布式运算程序的编程框架，通过它能将用户将编写好的程序提交，并发运行在一个 Hadoop 集群上。 MapReduce 外围性能是将用户编写的业务逻辑代码和自带默认组件整合成一个残缺的分布式运算程序。 MapReduce 是一个编程模型，分为两个阶段：Map 和 Reduce。输出的数据会先分块，而后由 Map 进行解决，最初输入到 Reduce 中。 能够将它了解成对数据整顿，而后演绎的一个过程。 外围算法MapReduce 的算法打算通常分三个步骤组成： Map：映射或映射器的工作是解决输出数据。每个工作节点将map 函数利用于本地数据，并将输入写入长期存储。Shuffle：工作节点依据输入键重新分配数据，对数据映射排序、分组、拷贝，目标是属于一个键的所有数据都位于同一个工作节点上。Reduce：工作节点当初并行处理每个键的每组输入数据，并将后果数据存储到HDFS。运行流程MapReduce 通常由以下几个步骤组成： input : 读取零碎中的文本文件；splitting : 将文件依照行进行拆分，能失去的K1 行数，V1 示意对应行的文本内容；mapping : 并行将每一行依照空格进行拆分，拆分失去的List(K2,V2)，其中K2 示意关键词，V2 的值为 1，代表呈现 1 次；shuffling：因为mapping 的操作可能在不同的机器上并行处理的，就得通过shuffling 操作将雷同key 值的数据散发到同一个节点下来合并，这样能力统计出最终的后果，此时失去K2 为主键，List(V2) 为可迭代汇合，V2 就是 Mapping 中的 V2；Reducing : 对于每个工作节点上的K2 键值对进行Reduce() 操作，最终输入。MapReduce 编程模型中 splitting 和 shuffing 操作都是由框架实现的，须要咱们本人编程实现的只有 mapping 和 reducing，这也就是 MapReduce 这个称说的起源。 优缺点长处能将大规模数据分多个节点并行计算，缩小数据计算所需的工夫；将计算挪动到数据的地位进行，升高网络老本；毛病只能进行离线计算，不能进行流式计算和实时计算；过程后果会存到磁盘，减少了I/O的负荷；总结MapReduce 最外围的还是将用户开发的程序，可能发到 Hadoop 上运行并执行，可能动静的去解决提交的工作，通过并行的形式缩小计算工夫，获取最终的计算结果。

Hadoop实战篇（2） 作者 | WenasWei 前言在上一篇的Hadoop实战篇介绍过了Hadoop-离线批处理技术的本地模式和伪集群模式装置，接下来持续学习 Hadoop 集群模式装置; 将从以下几点介绍: Linux 主机部署布局Zookeeper 注册核心装置集群模式装置Hadoop 的目录构造阐明和命令帮忙文档集群动静减少和删除节点一 Linux环境的配置与装置HadoopHadoop集群部署布局: Hadoop须要应用到 Linux 环境上的一些根本的配置须要，Hadoop 用户组和用户增加，免密登录操作，JDK装置 1.1 VMWare中Ubuntu网络配置在应用 VMWare 装置 Ubuntu18.04-Linux 操作系统下时产生系统配置问题能够通过分享的博文进行配置，CSDN跳转链接: VMWare中Ubuntu网络配置 其中蕴含了以下几个重要操作步骤: Ubuntu零碎信息与批改主机名Windows设置VMWare的NAT网络Linux网关设置与配置动态IPLinux批改hosts文件Linux免明码登录1.2 Hadoop 用户组和用户增加1.2.1 增加Hadoop用户组和用户以 root 用户登录 Linux-Ubuntu 18.04虚拟机，执行命令: $ groupadd hadoop$ useradd -r -g hadoop hadoop1.2.2 赋予Hadoop用户目录权限将 /usr/local 目录权限赋予 Hadoop 用户， 命令如下: $ chown -R hadoop.hadoop /usr/local/$ chown -R hadoop.hadoop /tmp/$ chown -R hadoop.hadoop /home/1.2.3 赋予Hadoop用户sodu权限编辑/etc/sudoers文件，在root ALL=(ALL:ALL) ALL下增加hadoop ALL=(ALL:ALL) ALL $ vi /etc/sudoersDefaults env_resetDefaults mail_badpassDefaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"root ALL=(ALL:ALL) ALLhadoop ALL=(ALL:ALL) ALL%admin ALL=(ALL) ALL%sudo ALL=(ALL:ALL) ALL1.2.4 赋予Hadoop用户登录明码$ passwd hadoopEnter new UNIX password: 输出新密码Retype new UNIX password: 确认新密码passwd: password updated successfully1.3 JDK装置Linux装置JDK能够参照分享的博文《Logstash-数据流引擎》-<第三节：Logstash装置>--(第二大节: 3.2 Linux装置JDK进行)装置配置到每一台主机上，CSDN跳转链接: Logstash-数据流引擎 ...

一. 压缩优化设计运行MapReduce程序时，磁盘I/O操作、网络数据传输、shuffle和merge要花大量的工夫，尤其是数据规模很大和工作负载密集的状况下，鉴于磁盘I/O和网络带宽是Hadoop的贵重资源，数据压缩对于节俭资源、最小化磁盘I/O和网络传输十分有帮忙。如果磁盘I/O和网络带宽影响了MapReduce作业性能，在任意MapReduce阶段启用压缩都能够改善端到端解决工夫并缩小I/O和网络流量。压缩是mapreduce的一种优化策略：通过压缩编码对mapper或者reducer的输入进行压缩，以缩小磁盘IO，进步MR程序运行速度，它的优缺点如下：压缩的长处: 缩小文件存储所占空间放慢文件传输效率，从而进步零碎的处理速度升高IO读写的次数压缩的毛病 用数据时须要先对文件解压，减轻CPU负荷，压缩算法越简单，解压工夫越长二. 压缩反对1. 查看Hadoop反对的压缩算法：hadoop checknative 2. Hadoop反对的压缩算法 3. 各压缩算法压缩性能比照压缩算法长处毛病Gzip压缩比在四种压缩形式中较高；hadoop自身反对，在利用中解决gzip格局的文件就和间接解决文本一样；有hadoop native库；大部分linux零碎都自带gzip命令，使用方便不反对splitLzo压缩/解压速度也比拟快，正当的压缩率；反对split，是hadoop中最风行的压缩格局；反对hadoop native库；须要在linux零碎下自行装置lzop命令，使用方便压缩率比gzip要低；hadoop自身不反对，须要装置；lzo尽管反对split，但须要对lzo文件建索引，否则hadoop也是会把lzo文件看成一个一般文件（为了反对split须要建索引，须要指定inputformat为lzo格局）Bzip2反对split；具备很高的压缩率，比gzip压缩率都高；hadoop自身反对，但不反对native；在linux零碎下自带bzip2命令，使用方便缩/解压速度慢；不反对nativeSnappy压缩速度快；反对hadoop native库不反对split；压缩比低；hadoop自身不反对，须要装置；linux零碎下没有对应的命令4. 同样大小的数据对应压缩比 5. 压缩工夫和解压工夫从以上比照能够看出：压缩比越高，压缩工夫越长，该当抉择压缩比与压缩工夫中等的压缩算法 三.Gzip压缩1. 生成Gzip压缩文件1. 需要:读取一般文本文件，将一般文本文件压缩为Gzip格局2. 思路Input读取一般文本文件Map和Reduce间接输入配置Output输出压缩为Gzip格局3.代码实现import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.conf.Configured;import org.apache.hadoop.fs.Path;import org.apache.hadoop.io.LongWritable;import org.apache.hadoop.io.NullWritable;import org.apache.hadoop.io.Text;import org.apache.hadoop.mapreduce.Job;import org.apache.hadoop.mapreduce.Mapper;import org.apache.hadoop.mapreduce.Reducer;import org.apache.hadoop.mapreduce.lib.input.TextInputFormat;import org.apache.hadoop.mapreduce.lib.output.TextOutputFormat;import org.apache.hadoop.util.Tool;import org.apache.hadoop.util.ToolRunner;import java.io.IOException;/** * @ClassName MRWriteGzip * @Description TODO 读取一般文件数据，对数据以Gzip格局进行压缩 */public class MRWriteGzip extends Configured implements Tool { //构建、配置、提交一个 MapReduce的Job public int run(String[] args) throws Exception { //构建Job Job job = Job.getInstance(this.getConf(),this.getClass().getSimpleName()); job.setJarByClass(MRWriteGzip.class); //input：配置输出 Path inputPath = new Path(args[0]); TextInputFormat.setInputPaths(job,inputPath); //map：配置Map job.setMapperClass(MrMapper.class); job.setMapOutputKeyClass(NullWritable.class); job.setMapOutputValueClass(Text.class); //reduce：配置Reduce job.setReducerClass(MrReduce.class); job.setOutputKeyClass(NullWritable.class); job.setOutputValueClass(Text.class); //output：配置输入 Path outputPath = new Path(args[1]); TextOutputFormat.setOutputPath(job,outputPath); return job.waitForCompletion(true) ? 0 : -1; } //程序入口，调用run public static void main(String[] args) throws Exception { //用于治理以后程序的所有配置 Configuration conf = new Configuration(); //配置输入后果压缩为Gzip格局 conf.set("mapreduce.output.fileoutputformat.compress","true"); conf.set("mapreduce.output.fileoutputformat.compress.codec","org.apache.hadoop.io.compress.GzipCodec"); //调用run办法，提交运行Job int status = ToolRunner.run(conf, new MRWriteGzip(), args); System.exit(status); } /** * 定义Mapper类 */ public static class MrMapper extends Mapper<LongWritable, Text, NullWritable, Text>{ private NullWritable outputKey = NullWritable.get(); @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { //间接输入每条数据 context.write(this.outputKey,value); } } /** * 定义Reduce类 */ public static class MrReduce extends Reducer<NullWritable,Text,NullWritable, Text> { @Override protected void reduce(NullWritable key, Iterable<Text> values, Context context) throws IOException, InterruptedException { //间接输入每条数据 for (Text value : values) { context.write(key, value); } } }}2. 读取Gzip压缩文件1. 需要：读取Gzip压缩文件，还原为一般文本文件2. 思路Input间接读取上一步的压缩后果文件Map和Reduce间接输入Output将后果保留为一般文本文件 ...

一.MapReduce性能优化概述1. MapReduce的利用场景Hadoop蕴含了GFS的开源实现HDFS（Hadoop distributed file system)和MapReduce框架的开源实现。Hadoop失去了企业界及学术界关注，Yahoo、Facebook、Cloudera、Twitter、Intel、华为等诸多公司和技术个人对Hadoop给予了大力支持。Cloudera对Apache Hadoop及相干组件的版本兼容性进行了整合、性能优化、功能测试，推出了其企业版的开源Hadoop。Intel推出了高效、平安及易于治理的Hadoop企业版。Hadoop因为其开源性质，已成为目前钻研、优化云计算框架的重要样本和根底。其中MapReduce框架很适宜解决文档剖析、倒排索引建设等类型的利用，然而在列存储、索引建设、连贯计算、迭代计算、科学计算及调度算法方面性能须要进一步优化。 2. 优缺点与需要1. 长处Mapreduce易于编程它简略的实现一些接口，就能够实现一个分布式程序，这个程序能够散布到大量的便宜的pc机器上运行。也就是说你写一个分布式程序，跟写一个简略的串行程序是截然不同的。就是因为这个个性使的Mapreduce编程变得十分风行。良好的扩展性我的项目中当你的计算资源得不到满足的时候，你能够通过简略的通过减少机器来扩大它的计算能力高容错性Mapreduce的设计初衷就是使程序可能部署在便宜的pc机器上，这就要求它具备很高的容错性。比方一个机器挂了，它能够把下面的计算工作转移到另一个节点上运行，不至于这个工作运行失败，而且这个过程不须要人工参加，而齐全是由hadoop外部实现的。适宜PB级以上海量数据的离线解决2. 毛病MapReduce尽管有很多的劣势，然而也有它不善于的。这里的“不善于”，不代表不能做，而是在有些场景下实现的成果差，并不适宜用MapReduce来解决，次要体现在以下后果方面： 实时计算： MapReduce次要解决的数据来自于文件系统，所以无奈像Oracle或MySQL那样在毫米或秒级内返回后果，如果须要大数据量的毫秒级响应，能够思考联合实时存储系统来实现，利用HBase、Kudu等.流计算： 流计算的输出数据是动静的，而MapReduce次要的输出来自于HDFS等文件系统，数据是动态的，不能动态变化，这是因为MapReduce本身的设计特点决定了数据源必须是动态的。如果须要解决流式数据能够用Storm,Spark Steaming、Flink等流计算框架。DGA（有向无环图）计算： 多个应用程序存在依赖关系，后一个应用程序的输出为前一个的输入。在这种状况下，MapReduce并不是不能做，而是应用后，每个MapReduce作业的输入后果都会写入磁盘，会造成大量的词频IO导致性能十分低下，此时能够思考用Spark等迭代计算框架。综合以上问题，MapReduce在解决离线分布式计算的过程中，次要思考如何晋升性能，放慢分布式计算过程。 3. 需要基于整个MapReduce所存在的毛病，因为MapReduce整体构造曾经固定，所以整体的优化计划只能从以下两点来思考实现： 利用列存储思维，优化存储构造列存储在数据仓库、OLAP (on-line analytical processing)联机剖析解决等利用上能够进步查问性能。利用列存储思维对MapReduce框架进行优化，面临正当的数据结构设计及数据压缩等挑战。 利用硬件资源优化连贯算法，进步每个阶段的连贯效率，MapReduce框架解决连贯操作的过程比较复杂，面临数据歪斜、分布式环境数据传输及须要多个MapReduce作业等挑战，优化MapReduce每个阶段中的资源能够充沛的利用硬件资源性能来晋升MapReduce的效率。二. IO性能优化：文件类型1. 优化计划针对HDFS最后是为拜访大文件而开发的, 所以会呈现对大量小文件的存储效率不高问题, MapReduce在读取小文件进行解决时，也存在资源节约导致计算效率不高的问题采纳 SequenceFile和MapFile设计一个 HDFS中合并存储小文件的计划。该计划的次要思维是将小文件序列化存入一个 SequenceFIle/MapFile 容器,合并成大文件, 并建设相应的索引文件, 无效升高文件数目和进步拜访效率. 通过和现有的 Hadoop Archives(HAR files)文件归档解决小文件问题的计划比照, 试验结果表明, 基于SequenceFile或者MapFile的存储小文件计划能够更为无效的进步小文件存储性能和缩小HDFS文件系统的节点内存耗费针对一般按行存储文本文件，MapReduce在解决实现聚合、过滤等性能时，性能绝对较差，针对行式存储的数据处理性能差的问题，能够抉择应用列式存储的计划来实现数据聚合解决，升高数据传输及读写的IO，进步整体MapReduce计算解决的性能2. SequenceFile1. 介绍SequenceFile是hadoop里用来存储序列化的键值对即二进制的一种文件格式。SequenceFile文件也能够作为MapReduce作业的输出和输入，hive和spark也反对这种格局。它有如下几个长处： 以二进制的KV模式存储数据，与底层交互更加敌对，性能更快，所以能够在HDFS里存储图像或者更加简单的构造作为KV对。SequenceFile反对压缩和分片。 当你压缩为一个SequenceFile时，并不是将整个文件压缩成一个独自的单元，而是压缩文件里的record或者block of records（块）。因而SequenceFile是可能反对分片的，即便应用的压缩形式如Snappy, Lz4 or Gzip不反对分片，也能够利用SequenceFIle来实现分片。SequenceFile也能够用于存储多个小文件。因为Hadoop自身就是用来解决大型文件的，小文件是不适宜的，所以用一个SequenceFile来存储很多小文件就能够进步解决效率，也能节俭Namenode内存，因为Namenode只需一个SequenceFile的metadata，而不是为每个小文件创建独自的metadata。因为数据是以SequenceFile模式存储，所以两头输入文件即map输入也会用SequenceFile来存储，能够进步整体的IO开销性能2. 存储特点 sequenceFile文件是Hadoop用来存储二进制模式的[Key,Value]对而设计的一种立体文件(Flat File)。能够把SequenceFile当做是一个容器，把所有的文件打包到SequenceFile类中能够高效的对小文件进行存储和解决。SequenceFile文件并不依照其存储的Key进行排序存储，SequenceFile的外部类Writer提供了append性能。SequenceFile中的Key和Value能够是任意类型Writable或者是自定义Writable。存储构造上，SequenceFile次要由一个Header后跟多条Record组成，Header次要蕴含了Key classname，value classname，存储压缩算法，用户自定义元数据等信息，此外，还蕴含了一些同步标识，用于疾速定位到记录的边界。每条Record以键值对的形式进行存储，用来示意它的字符数组能够一次解析成：记录的长度、Key的长度、Key值和value值，并且Value值的构造取决于该记录是否被压缩。在recourds中，又分为是否压缩格局。当没有被压缩时，key与value应用Serialization序列化写入SequenceFile。当抉择压缩格局时，record的压缩格局与没有压缩其实不尽相同，除了value的bytes被压缩，key是不被压缩的在Block中，它使所有的信息进行压缩，压缩的最小大小由配置文件中io.seqfile.compress.blocksize配置项决定。3. SequenceFile 工具类SequenceFileOutputFormat用于将MapReduce的后果输入为SequenceFile文件SequenceFileInputFormat用于读取SequenceFile文件4. 生成SequenceFile需要:将一般文件转换为SequenceFile文件思路 应用TextInputFormat读取一般文件文件Map阶段对读取文件的每一行进行输入Reduce阶段间接输入每条数据应用SequenceFileOutputFormat将后果保留为SequenceFile代码实现 Driver类import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.conf.Configured;import org.apache.hadoop.fs.Path;import org.apache.hadoop.io.*;import org.apache.hadoop.mapreduce.Job;import org.apache.hadoop.mapreduce.Mapper;import org.apache.hadoop.mapreduce.Reducer;import org.apache.hadoop.mapreduce.lib.input.FileInputFormat;import org.apache.hadoop.mapreduce.lib.input.TextInputFormat;import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;import org.apache.hadoop.mapreduce.lib.output.SequenceFileOutputFormat;import org.apache.hadoop.mapreduce.lib.output.TextOutputFormat;import org.apache.hadoop.util.Tool;import org.apache.hadoop.util.ToolRunner;import java.io.IOException;import java.util.Iterator;/** * @ClassName MrWriteToSequenceFile * @Description TODO 读取文本文件，转换为SequenceFile文件 * @Create By itcast */public class MrWriteToSequenceFile extends Configured implements Tool { //构建、配置、提交一个 MapReduce的Job public int run(String[] args) throws Exception { // 实例化作业 Job job = Job.getInstance(this.getConf(), "MrWriteToSequenceFile"); // 设置作业的主程序 job.setJarByClass(this.getClass()); // 设置作业的输出为TextInputFormat（一般文本） job.setInputFormatClass(TextInputFormat.class); // 设置作业的输出门路 FileInputFormat.addInputPath(job, new Path(args[0])); // 设置Map端的实现类 job.setMapperClass(WriteSeqFileAppMapper.class); // 设置Map端输出的Key类型 job.setMapOutputKeyClass(NullWritable.class); // 设置Map端输出的Value类型 job.setMapOutputValueClass(Text.class); // 设置作业的输入为SequenceFileOutputFormat job.setOutputFormatClass(SequenceFileOutputFormat.class); // 应用SequenceFile的块级别压缩 SequenceFileOutputFormat.setOutputCompressionType(job, SequenceFile.CompressionType.BLOCK); // 设置Reduce端的实现类 job.setReducerClass(WriteSeqFileAppReducer.class); // 设置Reduce端输入的Key类型 job.setOutputKeyClass(NullWritable.class); // 设置Reduce端输入的Value类型 job.setOutputValueClass(Text.class); // 从参数中获取输入门路 Path outputDir = new Path(args[1]); // 如果输入门路已存在则删除 outputDir.getFileSystem(this.getConf()).delete(outputDir, true); // 设置作业的输入门路 FileOutputFormat.setOutputPath(job, outputDir);// 提交作业并期待执行实现 return job.waitForCompletion(true) ? 0 : 1; } //程序入口，调用run public static void main(String[] args) throws Exception { //用于治理以后程序的所有配置 Configuration conf = new Configuration(); int status = ToolRunner.run(conf, new MrWriteToSequenceFile(), args); System.exit(status); }}Mapper类/** * 定义Mapper类 */public static class WriteSeqFileAppMapper extends Mapper<LongWritable, Text,NullWritable, Text>{ private NullWritable outputKey; @Override protected void setup(Context context) throws IOException, InterruptedException { this.outputKey = NullWritable.get(); } @Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { context.write(outputKey, value); } @Override protected void cleanup(Context context) throws IOException, InterruptedException { this.outputKey = null; }}Reduce类/** * 定义Reduce类 */public static class WriteSeqFileAppReducer extends Reducer<NullWritable,Text,NullWritable,Text>{ private NullWritable outputKey; @Override protected void setup(Context context) throws IOException, InterruptedException { this.outputKey = NullWritable.get(); } @Override protected void reduce(NullWritable key, Iterable<Text> value, Context context) throws IOException, InterruptedException { Iterator<Text> iterator = value.iterator(); while (iterator.hasNext()) { context.write(outputKey, iterator.next()); } } @Override protected void cleanup(Context context) throws IOException, InterruptedException { this.outputKey = null; }}5. 读取SequenceFile需要: 将上一步转换好的SequenceFile再解析转换为一般文本文件内容思路: ...

摘要：2021云栖大会云原生企业级数据湖专场，阿里云智能资深技术专家、对象存储 OSS 负责人罗庆超为咱们带来《云湖共生-开释企业数据价值》的分享。本文次要从数据湖存储演进之路、数据湖存储3.0 进化亮点等方面分享了云湖共生带来的企业价值。 摘要：2021云栖大会云原生企业级数据湖专场，阿里云智能资深技术专家、对象存储 OSS 负责人罗庆超为咱们带来《云湖共生-开释企业数据价值》的分享。 本文次要从数据湖存储演进之路、数据湖存储3.0 进化亮点等方面分享了云湖共生带来的企业价值。 以下是精彩视频内容整顿： 数据湖存储演进之路家喻户晓，数据湖是一个存算拆散的架构。这个架构带来的益处是存储和计算是解耦地部署及扩大的，从而实现整体零碎的弹性能力。我回顾了一下数据湖存储1.0时一个客户的状况。他有一个很大的 HDFS 集群，外面存了大量的历史数据，这时候想扩计算了，然而发现计算不能间接 run 在下面，因为会影响到现有集群的稳定性。就要独自扩额定的机器来做计算的集群，扩的时候集群又变宏大了，对运维的稳定性又带来了挑战。所以过后客户就抉择了存算拆散的数据湖技术。益处就是把所有的数据都放到拆散的对象存储下面，就能够持续跑计算集群，run Hadoop 的计算生态。为了兼容对象存储的接口和传统 Hadoop 利用的 HDFS 接口的要求，他还会部署一个 HDFS 的集群，来撑持这样的一个利用。那这个集群，就能够把传统的利用很好的 run 起来，而且他还能够提供性能优化的能力，这是数据湖1.0解决的一个问题。 随着数据湖1.0大量客户的应用，能够看到下面的利用越来越多。从 Hadoop 的利用到计算引擎，不同的计算引擎再到 AI，下面的计算生态越来越多，对存储容量的扩展性就有了更高的要求。基于这个要求，咱们要解决数据的治理能力。就须要把数据全副存到对象存储上，跟1.0相比能够看到，所有的冷热数据，都会存到对象存储里，对象存储就要反对大规模高性能的能力，同样也有一个老的问题要解决。 HDFS 一些专有的接口撑持能力，还须要内部的元数据服务，run 一个元数据服务比方 JindoFS，来把传统利用撑持起来，这样就解决1.0外面的一些问题。 基于2.0咱们深刻的应用，也发现了一些痛点，比方要运维一个内部的元数据集群，同时对于一些存量的数据，你还要做数据导入导出的工作，为此咱们提出了数据湖3.0。这外面存储架构就产生了一个质的变动。把外置的一个元数据集群，内置到对象存储里，把它做成一个服务化，无需占用客户的资源，通过 SDK 就可能拜访，这样能够缩小运维的难题。而且咱们整个元数据对立之后，能够将历史上就已存到对象存储下面的数据疾速迁徙过去，不须要做数据的拷贝。因而数据湖3.0，咱们实现了以对象存储为核心，全兼容、多协定、对立元数据的服务。 数据湖存储3.0 进化亮点基于数据湖3.0，咱们能够看到他有如下一些亮点： 多协定接口，拜访雷同存储空间如图所示，它是一个多协定接口拜访的池子。这个协定能够拜访雷同的数据，这样就能升高利用的门槛，间接对接接口就好，对运维是一个益处 性能加速器，服务端、客户端灵便抉择应用能够在客户端，服务端抉择不同的加速器来进步性能 全服务化状态，升高客户运维难度通过服务化的状态部署，升高了计算机器下面部署更多软件的开销，升高了运维的代价，能够让客户更好的应用 元数据互通，存量数据无缝迁徙底层让对象存储这种平坦的元数据，和基于 HDFS 目录的元数据，相互之间能够互相理解，从而在做存量数据挪动的时候，只做元数据的映射批改，而数据是不必挪动的，这样就能够平滑利用。 冷热分层，极致性价比优化数据湖1.0外面有热数据在 HDFS 外面，冷数据在对象存储外面，当初咱们齐全能够利用对象存储本身提供的，不同规格的存储类型，来实现利用的冷热分层，从而提供极致的性价比 一份数据，多维的元数据形容，零数据拷贝 接口全兼容，疾速实现自建HDFS迁徙OSS数据湖存储100%兼容 HDFS语义计算引擎无感HDFS/对象 一份数据 多协定拜访，元数据互通对象接口反对 毫秒级原子10亿级目录重命名全服务化 升高运维难度，简略易用咱们实现了基于 OSS 构建的数据湖存储3.0.既然提供了百分之百兼容 HDFS 语义的能力，就能够很容易且疾速实现自建HDFS迁徙OSS数据湖存储。因为接口兼容了，咱们能够通过一些工具、软件疾速的把数据从自建的 HDFS 拷贝或者迁徙到数据湖存储外面来，而且将来咱们还会做，对于开源 HDFS NameNode 的一种格局解析形式。做了这个格局之后，咱们能够在后盾主动的做迁徙，升高整个迁徙的难度。那同时数据迁徙到 OSS 之后，咱们基于一些验证过的场景，比方一个目录下寄存10亿的文件，咱们也能提供对象存储级的目录操作的原子接口，能够实现秒级把这个目录实现重命名，大大的进步计算的效率，这个也是通过场景验证的。 OSS数据湖存储与CPFS数据流动，减速AI 业务翻新升高95%计算等待时间,大幅晋升训练效率POSIX 语义兼容,业务利用人造适配CPFS 提供百GB吞吐,高性能共享拜访数据按需流动,多种更新模式，高效治理建完湖之后就要修湖，修湖之后还要拉通、疏通河道，这样才可能让水流到湖外面来。基于 OSS 构建的数据湖，也是同样的情理。咱们欠缺了这个湖之外还买通了跟内部的存储之间的数据流动的通道。 ...

一. 背景在理论的数据库利用中，咱们常常须要从多个数据表中读取数据，这时咱们就能够应用SQL语句中的连贯（JOIN），在两个或多个数据表中查问数据。在应用MapReduce框架进行数据处理的过程中，也会波及到从多个数据集读取数据，进行join关联的操作，只不过此时须要应用java代码并且依据MapReduce的编程标准进行业务的实现。然而因为MapReduce的分布式设计理念的特殊性，因而对于MapReduce实现join操作具备了肯定的特殊性。非凡次要体现在：到底在MapReduce中的什么阶段进行数据集的关联操作，是mapper阶段还是reducer阶段，之间的区别又是什么？整个MapReduce的join分为两类：map side join、reduce side join。 二. reduce side join1. 概述reduce side join，顾名思义，在reduce阶段执行join关联操作。这也是最容易想到和实现的join形式。因为通过shuffle过程就能够将相干的数据分到雷同的分组中，这将为前面的join操作提供了便捷。 基本上，reduce side join大抵步骤如下： mapper别离读取不同的数据集；mapper的输入中，通常以join的字段作为输入的key；不同数据集的数据通过shuffle，key一样的会被分到同一分组解决；在reduce中依据业务需要把数据进行关联整合汇总，最终输入。2. 弊病reduce端join最大的问题是整个join的工作是在reduce阶段实现的，然而通常状况下MapReduce中reduce的并行度是极小的（默认是1个），这就使得所有的数据都挤压到reduce阶段解决，压力颇大。尽管能够设置reduce的并行度，然而又会导致最终后果被扩散到多个不同文件中。并且在数据从mapper到reducer的过程中，shuffle阶段非常繁琐，数据集大时老本极高。 三. MapReduce 分布式缓存DistributedCache是hadoop框架提供的一种机制,能够将job指定的文件,在job执行前,后行散发到task执行的机器上,并有相干机制对cache文件进行治理。DistributedCache可能缓存应用程序所需的文件 （包含文本，档案文件，jar文件等）。Map-Redcue框架在作业所有工作执行之前会把必要的文件拷贝到slave节点上。 它运行高效是因为每个作业的文件只拷贝一次并且为那些没有文档的slave节点缓存文档。 1. 应用形式1. 增加缓存文件能够应用MapReduce的API增加须要缓存的文件。 //增加归档文件到分布式缓存中job.addCacheArchive(URI uri); //增加一般文件到分布式缓存中job.addCacheFile(URI uri);留神：须要散发的文件,必须提前放到hdfs上.默认的门路前缀是hdfs://。 2. 程序中读取缓存文件在Mapper类或者Reducer类的setup办法中，用输出流获取分布式缓存中的文件。 protected void setup(Context context) throw IOException,InterruptedException{ FileReader reader = new FileReader("myfile"); BufferReader br = new BufferedReader(reader); ......}四. map side join1. 概述map side join，其精华就是在map阶段执行join关联操作,并且程序也没有了reduce阶段，防止了shuffle时候的繁琐。实现的要害是应用MapReduce的分布式缓存。 尤其是波及到一大一小数据集的解决场景时，map端的join将会施展出得天独厚的劣势。map side join的大抵思路如下： 首先剖析join解决的数据集，应用分布式缓存技术将小的数据集进行分布式缓存MapReduce框架在执行的时候会主动将缓存的数据散发到各个maptask运行的机器上程序只运行mapper，在mapper初始化的时候从分布式缓存中读取小数据集数据，而后和本人读取的大数据集进行join关联，输入最终的后果。整个join的过程没有shuffle，没有reducer。2. 劣势map端join最大的劣势缩小shuffle时候的数据传输老本。并且mapper的并行度能够依据输出数据量主动调整，充分发挥分布式计算的劣势。 五. MapReduce join案例：订单商品解决1. 需要有两份结构化的数据文件：itheima_goods（商品信息表）、itheima_order_goods（订单信息表）,具体字段内容如下。要求应用MapReduce统计出每笔订单中对应的具体的商品名称信息。比方107860商品对应着：AMAZFIT彩色硅胶腕带 数据结构: itheima_goods 字段：goodsId（商品id）、goodsSn（商品编号）、goodsName（商品名称）itheima_order_goods字段： orderId（订单ID）、goodsId（商品ID）、payPrice（理论领取价格）2. Reduce Side 实现1. 剖析应用mapper解决订单数据和商品数据，输入的时候以goodsId商品编号作为key。雷同goodsId的商品和订单会到同一个reduce的同一个分组，在分组中进行订单和商品信息的关联合并。在MapReduce程序中能够通过context获取到以后解决的切片所属的文件名称。依据文件名来判断以后解决的是订单数据还是商品数据，以此来进行不同逻辑的输入。join解决完之后，最初能够再通过MapReduce程序排序功能，将属于同一笔订单的所有商品信息汇聚在一起。 ...

一. 背景常识通常组织会应用关系型数据来存储业务相干的数据，但随着数据的规模越来越大，尤其是像MySQL这种，在单表超过5千万条记录时，只管对表应用了特定的存储引擎和索引优化，但仍然不可避免的存在性能降落问题。此时，咱们**能够通过应用MapReduce从MySQL中定期迁徙应用频率较低的历史数据到HDFS中，一方面能够升高对MySQL的存储和计算负载，另一方面，通过分布式计算引擎能够更加高效的解决过来的历史数据。 对于MapReduce框架来说，应用inputform进行数据读取操作，读取的数据首先由mapper解决，而后交给reducer解决，最终应用outputformat进行数据的输入操作。默认状况下，输入输出的组件实现都是针对文本数据处理的，别离是TextInputFormat、TextOutputFormat。为了不便 MapReduce 间接拜访关系型数据库（Mysql,Oracle），Hadoop提供了DBInputFormat和DBOutputFormat两个类。其中DBInputFormat负责从数据库中读取数据，而DBOutputFormat负责把数据最终写入数据库中。 二. 读取数据库操作1. 需要在mysql中itcast_shop数据库下创立表itheima_goods并加载数据到表中。要求应用MapReduce程序将表中的数据导出寄存在指定的文件下。数据库:链接：https://pan.baidu.com/s/1ImrI... 提取码：pz9b 因为波及到java操作mysql，因而须要在pom依赖中额定增加mysql-jdbc驱动。 <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.32</version> </dependency>2. DBInputFormat类InputFormat类用于从SQL表读取数据。DBInputFormat底层一行一行读取表中的数据，返回<k,v>键值对。其中k是LongWritable类型，表中数据的记录行号，从0开始，v是DBWritable类型，示意该行数据对应的对象类型。 此外还须要应用setInput办法设置SQL查问的语句相干信息。 3. 代码实现1. 编写GoodsBean类定义GoodsBean的实体类，用于封装查问返回的后果（如果要查问表的所有字段，那么属性就跟表的字段一一对应即可）。并且须要实现序列化机制Writable。此外，从数据库读取/写入数据库的对象应实现DBWritable。 DBWritable与Writable类似，区别在于write（PreparedStatement）办法采纳PreparedStatement，而readFields（ResultSet）采纳ResultSet。 package com.uuicon.sentiment_upload.db;import org.apache.hadoop.io.Writable;import org.apache.hadoop.mapred.lib.db.DBWritable;import java.io.DataInput;import java.io.DataOutput;import java.io.IOException;import java.sql.PreparedStatement;import java.sql.ResultSet;import java.sql.SQLException;public class GoodsBean implements Writable, DBWritable { private Long goodsId; private String goodsSn; private String goodsName; private Double marketPrice; private Double shopPrice; private Long saleNum; @Override public String toString() { return goodsId + "\t" + goodsSn + '\t' + goodsName + "\t" + marketPrice + "\t" + shopPrice + "\t" + saleNum; } public Long getGoodsId() { return goodsId; } public void setGoodsId(Long goodsId) { this.goodsId = goodsId; } public String getGoodsSn() { return goodsSn; } public void setGoodsSn(String goodsSn) { this.goodsSn = goodsSn; } public String getGoodsName() { return goodsName; } public void setGoodsName(String goodsName) { this.goodsName = goodsName; } public Double getMarketPrice() { return marketPrice; } public void setMarketPrice(Double marketPrice) { this.marketPrice = marketPrice; } public Double getShopPrice() { return shopPrice; } public void setShopPrice(Double shopPrice) { this.shopPrice = shopPrice; } public Long getSaleNum() { return saleNum; } public void setSaleNum(Long saleNum) { this.saleNum = saleNum; } public GoodsBean() { } public GoodsBean(Long goodsId, String goodsSn, String goodsName, Double marketPrice, Double shopPrice, Long saleNum) { this.goodsId = goodsId; this.goodsSn = goodsSn; this.goodsName = goodsName; this.marketPrice = marketPrice; this.shopPrice = shopPrice; this.saleNum = saleNum; } public void set(Long goodsId, String goodsSn, String goodsName, Double marketPrice, Double shopPrice, Long saleNum) { this.goodsId = goodsId; this.goodsSn = goodsSn; this.goodsName = goodsName; this.marketPrice = marketPrice; this.shopPrice = shopPrice; this.saleNum = saleNum; } @Override public void write(DataOutput out) throws IOException { out.writeLong(goodsId); out.writeUTF(goodsSn); out.writeUTF(goodsName); out.writeDouble(marketPrice); out.writeDouble(shopPrice); out.writeLong(saleNum); } @Override public void readFields(DataInput in) throws IOException { this.goodsId = in.readLong(); this.goodsSn = in.readUTF(); this.goodsName = in.readUTF(); this.marketPrice = in.readDouble(); this.shopPrice = in.readDouble(); this.saleNum = in.readLong(); } @Override public void write(PreparedStatement ps) throws SQLException { ps.setLong(1, goodsId); ps.setString(2, goodsSn); ps.setString(3, goodsName); ps.setDouble(4, marketPrice); ps.setDouble(5, shopPrice); ps.setLong(6, saleNum); } @Override public void readFields(ResultSet resultSet) throws SQLException { this.goodsId = resultSet.getLong(1); this.goodsSn = resultSet.getString(2); this.goodsName = resultSet.getString(3); this.marketPrice = resultSet.getDouble(4); this.shopPrice = resultSet.getDouble(5); this.saleNum = resultSet.getLong(6); }}2. 编写Mapper类package com.uuicon.sentiment_upload.db;import org.apache.hadoop.io.LongWritable;import org.apache.hadoop.io.Text;import org.apache.hadoop.mapreduce.Mapper;import java.io.IOException;public class ReadDBMapper extends Mapper<LongWritable, GoodsBean, LongWritable, Text> { Text outValue = new Text(); @Override protected void map(LongWritable key, GoodsBean value, Context context) throws IOException, InterruptedException { outValue.set(value.toString()); context.write(key, outValue); }}3. 创立程序驱动类package com.uuicon.sentiment_upload.db;import com.uuicon.sentiment_upload.covidtopn.CovidTopNDriver;import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.fs.Path;import org.apache.hadoop.io.LongWritable;import org.apache.hadoop.io.Text;import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;import org.apache.hadoop.mapred.lib.db.DBConfiguration;import org.apache.hadoop.mapred.lib.db.DBInputFormat;import org.apache.hadoop.mapreduce.Job;import java.io.File;import java.io.IOException;public class ReadDBDriver { public static void main(String[] args) throws IOException, InterruptedException, ClassNotFoundException { Configuration conf = new Configuration(); //数据库信息 DBConfiguration.configureDB(conf, "com.mysql.jdbc.Driver", "jdbc:mysql://localhost:3306/itcast_goods", "root", "root" ); // 创立作业类 Job job = Job.getInstance(conf, ReadDBDriver.class.getSimpleName()); //设置mr 驱动类 job.setJarByClass(ReadDBDriver.class); //设置mapper 类 job.setMapperClass(ReadDBMapper.class); job.setOutputKeyClass(LongWritable.class); job.setOutputValueClass(Text.class); // todo 设置输出组件 FileOutputFormat.setOutputPath(job, new Path("E:\\ml\\hadoop\\mysqlout")); //设置Reducer 类 ,todo 本例不须要reduce ,操作形式是将tasknumber 设置为 0 job.setNumReduceTasks(0); // todo 设置输出组件 job.setInputFormatClass(DBInputFormat.class); //增加读取数据库相干参数 DBInputFormat.setInput( job, GoodsBean.class, "select goodsId ,goodsSn,goodsName,marketPrice ,shopPrice , saleNum from itheima_goods", "select count(goodsId) from itheima_goods" ); boolean b = job.waitForCompletion(true); System.exit(b ? 0 : 1); }}4. 运行程序间接在驱动类中右键运行main办法，应用MapReduce的本地模式执行。也能够将程序应用maven插件打包成jar包，提交到yarn上进行分布式运行。 ...

一. 计数器概述执行MapReduce程序的时候,控制台输入信息中通常有上面所示片段内容：输入信息中的外围词是counters，中文叫做计数器,Hadoop内置的计数器性能收集作业的次要统计信息，能够帮忙用户了解程序的运行状况，辅助用户诊断故障。 二. MapReduce内置计数器Hadoop为每个MapReduce作业保护一些内置的计数器，这些计数器报告各种指标，例如和MapReduce程序执行中每个阶段输入输出的数据量相干的计数器，能够帮忙用户进行判断程序逻辑是否失效、正确。 Hadoop内置计数器依据性能进行分组。每个组包含若干个不同的计数器，别离是：MapReduce工作计数器（Map-Reduce Framework）、文件系统计数器（File System Counters）、作业计数器（Job Counters）、输出文件工作计数器（File Input Format Counters）、输入文件计数器（File Output Format Counters）。 须要留神的是，内置的计数器都是MapReduce程序中全局的计数器，跟MapReduce分布式运算没有关系，不是所谓的每个部分的统计信息。 1. Map-Reduce Framework Counters计数器名称阐明MAP_INPUT_RECORDS所有mapper已解决的输出记录数MAP_OUTPUT_RECORDS所有mapper产生的输入记录数MAP_OUTPUT_BYTES所有mapper产生的未经压缩的输入数据的字节数MAP_OUTPUT_MATERIALIZED_BYTESmapper输入后的确写到磁盘上字节数COMBINE_INPUT_RECORDS所有combiner(如果有）已解决的输出记录数COMBINE_OUTPUT_RECORDS所有combiner（如果有）已产生的输入记录数REDUCE_INPUT_GROUPS所有reducer已解决分组的个数REDUCE_INPUT_RECORDS所有reducer曾经解决的输出记录的个数。每当某个reducer的迭代器读一个值时，该计数器的值减少REDUCE_OUTPUT_RECORDS所有reducer输入记录数REDUCE_SHUFFLE_BYTESShuffle时复制到reducer的字节数SPILLED_RECORDS所有map和reduce工作溢出到磁盘的记录数CPU_MILLISECONDS一个工作的总CPU工夫，以毫秒为单位，可由/proc/cpuinfo获取PHYSICAL_MEMORY_BYTES一个工作所用的物理内存，以字节数为单位，可由/proc/meminfo获取VIRTUAL_MEMORY_BYTES一个工作所用虚拟内存的字节数，由/proc/meminfo获取2. File System Counters Counters文件系统的计数器会针对不同的文件系统应用状况进行统计，比方HDFS、本地文件系统： 计数器名称阐明BYTES_READ程序从文件系统中读取的字节数BYTES_WRITTEN程序往文件系统中写入的字节数READ_OPS文件系统中进行的读操作的数量（例如，open操作，filestatus操作）LARGE_READ_OPS文件系统中进行的大规模读操作的数量WRITE_OPS文件系统中进行的写操作的数量（例如，create操作，append操作）3. Job Counters 计数器名称阐明Launched map tasks启动的map工作数，包含以“揣测执行”形式启动的工作Launched reduce tasks启动的reduce工作数，包含以“揣测执行”形式启动的工作Data-local map tasks与输人数据在同一节点上的map工作数Total time spent by all maps in occupied slots (ms)所有map工作在占用的插槽中破费的总工夫（毫秒）Total time spent by all reduces in occupied slots (ms)所有reduce工作在占用的插槽中破费的总工夫（毫秒）Total time spent by all map tasks (ms)所有map task破费的工夫Total time spent by all reduce tasks (ms)所有reduce task破费的工夫4. File Input|Output Format Counters ...

简介： 本文介绍了Cloudera Manager 的常见术语和架构 Cloudera Manager 术语为了无效地应用Cloudera Manager，您应该首先理解其术语。 术语之间的关系如下所示，其定义如下： 有时，术语服务和角色用于同时指代类型和实例，这可能会造成混同。Cloudera Manager 和本节有时对类型和实例应用雷同的术语。例如，Cloudera Manager 治理控制台的“主页” >“状态”选项卡和“集群” >“ ClusterName” 菜单列出了服务实例。这相似于编程语言中的常规，其中“字符串”一词可能示意类型（java.lang.String）或该类型的实例（“ hi there”）。在须要辨别类型和实例的中央，单词“ type”被附加以批示类型，而单词“ instance”被附加以显式批示实例。 部署Cloudera Manager 及其治理的所有集群的配置。 动静资源池在 Cloudera Manager 中，这是资源的命名配置，以及用于在池中运行的 YARN 应用程序或 Impala 查问之间调度资源的策略。 集群蕴含 HDFS 文件系统并对该数据运行 MapReduce 和其余过程的一组计算机或计算机机架。在 Cloudera Manager 中，是一个逻辑实体，蕴含一组主机，在主机上安装的单个版本的 Cloudera Runtime 以及在主机上运行的服务和角色实例。一台主机只能属于一个集群。Cloudera Manager 能够治理多个集群，然而每个集群只能与一个 Cloudera Manager Server 关联。主机在 Cloudera Manager 中，是运行角色实例的物理或虚拟机。一台主机只能属于一个集群。 机架在 Cloudera Manager 中，是一个物理实体，蕴含一组通常由同一交换机提供服务的物理主机。 服务在尽可能可预测的环境中运行在/etc/init.d/定义的 System V 初始化脚本的 Linux 命令 ，删除大多数环境变量并将当前工作目录设置为/。Cloudera Manager 中的托管性能类别，能够在集群中运行，有时称为服务类型。例如：Hive、HBase、HDFS、YARN 和 Spark。服务实例在 Cloudera Manager 中，是在集群上运行的服务的实例。例如：“ HDFS-1”和“yarn”。服务实例逾越许多角色实例。 ...

一. MapReduce 并行度机制1. MapTask 并行度机制1. 概念MapTask的并行度指的是map阶段有多少个并行的task独特解决工作。map阶段的工作解决并行度，势必影响到整个job的处理速度。那么，MapTask并行实例是否越多越好呢？其并行度又是如何决定呢？ 2. 原理机制一个MapReducejob的map阶段并行度由客户端在提交job时决定，即客户端提交job之前会看待解决数据进行逻辑切片。切片实现会造成切片布局文件（job.split），每个逻辑切片最终对应启动一个maptask。逻辑切片机制由FileInputFormat实现类的getSplits() 办法实现。FileInputFormat中默认的切片机制： 简略地依照文件的内容长度进行切片切片大小，默认等于block大小切片时不思考数据集整体，而是一一针对每一个文件独自切片比方待处理数据有两个文件：file1.txt 320Mfile2.txt 10M 通过FileInputFormat的切片机制运算后，造成的切片信息如下： file1.txt.split1—0M~128Mfile1.txt.split2—128M~256Mfile1.txt.split3—256M~320Mfile2.txt.split1—0M~10M 3. 相干参数 优化在FileInputFormat中，计算切片大小的逻辑：Math.max(minSize, Math.min(maxSize, blockSize)); 切片次要由这几个值来运算决定：minsize：默认值：1配置参数： mapreduce.input.fileinputformat.split.minsizemaxsize：默认值：Long.MAXValue配置参数：mapreduce.input.fileinputformat.split.maxsizeblocksize因而，默认状况下，split size=block size,在hadoop 2.x中为128M。然而，不论怎么调参数，都不能让多个小文件“划入”一个split。还有个细节就是：当bytesRemaining/splitSize > 1.1不满足的话，那么最初所有残余的会作为一个切片。从而不会造成例如129M文件布局成两个切片的场面。 2. ReduceTask 并行度机制reducetask并行度同样影响整个job的执行并发度和执行效率，与maptask的并发数由切片数决定不同，Reducetask数量的决定是能够间接手动设置：job.setNumReduceTasks(4);如果数据分布不平均，就有可能在reduce阶段产生数据歪斜。留神： reducetask数量并不是任意设置，还要思考业务逻辑需要，有些状况下，须要计算全局汇总后果，就只能有1个reducetask。 二. MapReduce工作流程详解1. MapTask 工作机制1. 流程图 2. 执行步骤整个Map阶段流程大体如上图所示。简略概述：input File通过split被逻辑切分为多个split文件，通过Record按行读取内容给map（用户本人实现的）进行解决，数据被map解决完结之后交给OutputCollector收集器，对其后果key进行分区（默认应用hash分区），而后写入buffer，每个map task都有一个内存缓冲区，存储着map的输入后果，当缓冲区快满的时候须要将缓冲区的数据以一个临时文件的形式寄存到磁盘，当整个map task完结后再对磁盘中这个map task产生的所有临时文件做合并，生成最终的正式输入文件，而后期待reduce task来拉数据。 具体步骤: 首先，读取数据组件InputFormat（默认TextInputFormat）会通过getSplits办法对输出目录中文件进行逻辑切片布局失去splits，有多少个split就对应启动多少个MapTask。split与block的对应关系默认是一对一。将输出文件切分为splits之后，由RecordReader对象（默认LineRecordReader）进行读取，以\n作为分隔符，读取一行数据，返回<key，value>。Key示意每行首字符偏移值，value示意这一行文本内容。读取split返回<key,value>，进入用户本人继承的Mapper类中，执行用户重写的map函数。RecordReader读取一行这里调用一次。map逻辑完之后，将map的每条后果通过context.write进行collect数据收集。在collect中，会先对其进行分区解决，默认应用HashPartitioner。MapReduce提供Partitioner接口，它的作用就是依据key或value及reduce的数量来决定以后的这对输入数据最终应该交由哪个reduce task解决。默认对key hash后再以reduce task数量取模。默认的取模形式只是为了均匀reduce的解决能力，如果用户本人对Partitioner有需要，能够订制并设置到job上。接下来，会将数据写入内存，内存中这片区域叫做环形缓冲区，缓冲区的作用是批量收集map后果，缩小磁盘IO的影响。咱们的key/value对以及Partition的后果都会被写入缓冲区。当然写入之前，key与value值都会被序列化成字节数组。环形缓冲区其实是一个数组，数组中寄存着key、value的序列化数据和key、value的元数据信息，包含partition、key的起始地位、value的起始地位以及value的长度。环形构造是一个抽象概念。缓冲区是有大小限度，默认是100MB。当map task的输入后果很多时，就可能会撑爆内存，所以须要在肯定条件下将缓冲区中的数据长期写入磁盘，而后从新利用这块缓冲区。这个从内存往磁盘写数据的过程被称为Spill，中文可译为溢写。这个溢写是由独自线程来实现，不影响往缓冲区写map后果的线程。溢写线程启动时不应该阻止map的后果输入，所以整个缓冲区有个溢写的比例spill.percent。这个比例默认是0.8，也就是当缓冲区的数据曾经达到阈值（buffer size spill percent = 100MB 0.8 = 80MB），溢写线程启动，锁定这80MB的内存，执行溢写过程。Map task的输入后果还能够往剩下的20MB内存中写，互不影响。当溢写线程启动后，须要对这80MB空间内的key做排序(Sort)。排序是MapReduce模型默认的行为，这里的排序也是对序列化的字节做的排序。如果job设置过Combiner，那么当初就是应用Combiner的时候了。将有雷同key的key/value对的value加起来，缩小溢写到磁盘的数据量。Combiner会优化MapReduce的两头后果，所以它在整个模型中会屡次应用。那哪些场景能力应用Combiner呢？从这里剖析，Combiner的输入是Reducer的输出，Combiner绝不能扭转最终的计算结果。Combiner只应该用于那种Reduce的输出key/value与输入key/value类型完全一致，且不影响最终后果的场景。比方累加，最大值等。Combiner的应用肯定得谨慎，如果用好，它对job执行效率有帮忙，反之会影响reduce的最终后果。每次溢写会在磁盘上生成一个临时文件（写之前判断是否有combiner），如果map的输入后果真的很大，有屡次这样的溢写产生，磁盘上相应的就会有多个临时文件存在。当整个数据处理完结之后开始对磁盘中的临时文件进行merge合并，因为最终的文件只有一个，写入磁盘，并且为这个文件提供了一个索引文件，以记录每个reduce对应数据的偏移量。至此map整个阶段完结。 2. ReduceTask 工作机制1. 流程图 2. 执行步骤Reduce大抵分为copy、sort、reduce三个阶段，重点在前两个阶段。copy阶段蕴含一个eventFetcher来获取已实现的map列表，由Fetcher线程去copy数据，在此过程中会启动两个merge线程，别离为inMemoryMerger和onDiskMerger，别离将内存中的数据merge到磁盘和将磁盘中的数据进行merge。待数据copy实现之后，copy阶段就实现了，开始进行sort阶段，sort阶段次要是执行finalMerge操作，纯正的sort阶段，实现之后就是reduce阶段，调用用户定义的reduce函数进行解决。具体步骤: Copy阶段，简略地拉取数据。Reduce过程启动一些数据copy线程(Fetcher)，通过HTTP形式申请maptask获取属于本人的文件。Merge阶段。这里的merge如map端的merge动作，只是数组中寄存的是不同map端copy来的数值。Copy过去的数据会先放入内存缓冲区中，这里的缓冲区大小要比map端的更为灵便。merge有三种模式：内存到内存；内存到磁盘；磁盘到磁盘。默认状况下第一种模式不启用。当内存中的数据量达到肯定阈值，就启动内存到磁盘的merge。与map 端相似，这也是溢写的过程，这个过程中如果你设置有Combiner，也是会启用的，而后在磁盘中生成了泛滥的溢写文件。第二种merge形式始终在运行，直到没有map端的数据时才完结，而后启动第三种磁盘到磁盘的merge形式生成最终的文件。对排序后的键值对调用reduce办法，键相等的键值对调用一次reduce办法，每次调用会产生零个或者多个键值对，最初把这些输入的键值对写入到HDFS文件中。 二. MapReduce Shuffle 机制Shuffle的本意是洗牌、混洗的意思，把一组有规定的数据尽量打乱成无规则的数据。而在MapReduce中，Shuffle更像是洗牌的逆过程，指的是将map端的无规则输入按指定的规定“打乱”成具备肯定规定的数据，以便reduce端接管解决。shuffle是Mapreduce的外围，它散布在Mapreduce的map阶段和reduce阶段。个别把从Map产生输入开始到Reduce获得数据作为输出之前的过程称作shuffle。 ...

一.MapReduce mapReduce Patition Combiner1. Partition分区1.默认状况在默认状况下，不论map阶段有多少个并发执行task,到reduce阶段，所有的后果都将有一个reduce来解决，并且最终后果输入到一个文件中。默认状况下MapReduce 执行流程: 2. 批改ReduceTask个数在MapReduce程序的驱动类中，通过job提供的办法，能够批改reducetask的个数。 应用api批改reducetask个数之后，输入后果文件的个数和reducetask个数对应。也就是说有几个ReduceTask,最终输入文件就是几个,比方设置为6个，此时的输入后果如下所示： 此时，MapReduce的执行流程如下所示： 3. Partition数据分区概念默认状况下，MapReduce是只有一个reducetask来进行数据的解决。这就使得不论输出的数据量多大，最终的后果都是输入到一个文件中。当扭转reducetask个数的时候，作为maptask就会波及到数据分区的问题：MapTask输入的后果如何调配给各个ReduceTask来解决。 4. partition默认规定MapReduce默认分区规定是HashPartitioner。跟map输入的数据key无关。 5. partition注意事项reducetask个数的扭转导致了数据分区的产生，而不是有数据分区导致了reducetask个数扭转。数据分区的外围是分区规定。即如何调配数据给各个reducetask。默认的规定能够保障只有map阶段输入的key一样，数据就肯定能够分区到同一个reducetask，然而不能保证数据均匀分区。reducetask个数的扭转还会导致输入后果文件不再是一个整体，而是输入到多个文件中。2. Combiner 规约1.数据规约的含意数据归约是指在尽可能保持数据原貌的前提下，最大限度地精简数据量。 2. MapReduce 弊病MapReduce是一种具备两个执行阶段的分布式计算程序，Map阶段和Reduce阶段之间会波及到跨网络数据传递。每一个MapTask都可能会产生大量的本地输入，这就导致跨网络传输数据质变大，网络IO性能低。比方WordCount单词统计案例，如果文件中有1000个单词，其中999个为hello,这将产生999个<hello,1>的键值对在网络中传递，性能及其低下。3. Combiner 组件概念Combiner中文叫做数据规约，是MapReduce的一种优化伎俩。Combiner的作用就是对map端的输入先做一次部分合并，以缩小在map和reduce节点之间的数据传输量。4. Combiner 组件应用Combiner是MapReduce程序中除了Mapper和Reducer之外的一种组件，默认状况下不启用。Combiner实质就是Reducer，combiner和reducer的区别在于运行的地位：combiner是在每一个maptask所在的节点本地运行，是部分聚合；reducer是对所有maptask的输入后果计算，是全局聚合。具体实现步骤：自定义一个CustomCombiner类，继承Reducer，重写reduce办法job.setCombinerClass(CustomCombiner.class)5. Combiner 应用注意事项Combiner可能利用的前提是不能影响最终的业务逻辑，而且，Combiner的输入kv应该跟reducer的输出kv类型要对应起来。下述场景禁止应用Combiner，因为这样不仅优化了网络传输数据量，还扭转了最终的执行后果业务和数据个数相干的。业务和整体排序相干的。Combiner组件不是禁用，而是慎用。用的好进步程序性能，用不好，改变程序后果且不易发现。二. MapReduce 编程指南1. MapReduce 编程技巧概述MapReduce执行流程了然于心，可能晓得数据在MapReduce中流转过程。业务需要解读精确，即须要明确做什么。牢牢把握住key的抉择，因为MapReduce很多行为跟key相干，比方：排序、分区、分组。学会自定义组件批改默认行为，当默认的行为不满足业务需要，能够尝试自定义规定。通过画图梳理业务执行流程，确定每个阶段的数据类型。2. MapReduce执行流程梳理 1. Map阶段执行过程第一阶段是把输出目录下文件依照肯定的规范一一进行逻辑切片，造成切片布局。默认状况下，Split size = Block size。每一个切片由一个MapTask解决。（getSplits）第二阶段是对切片中的数据依照肯定的规定解析成<key,value>对。默认规定是把每一行文本内容解析成键值对。key是每一行的起始地位(单位是字节)，value是本行的文本内容。（TextInputFormat）第三阶段是调用Mapper类中的map办法。上阶段中每解析进去的一个<k,v>，调用一次map办法。每次调用map办法会输入零个或多个键值对。第四阶段是依照肯定的规定对第三阶段输入的键值对进行分区。默认是只有一个区。分区的数量就是Reducer工作运行的数量。默认只有一个Reducer工作。第五阶段是对每个分区中的键值对进行排序。首先，依照键进行排序，对于键雷同的键值对，依照值进行排序。比方三个键值对<2,2>、<1,3>、<2,1>，键和值别离是整数。那么排序后的后果是<1,3>、<2,1>、<2,2>。如果有第六阶段，那么进入第六阶段；如果没有，间接输入到文件中。第六阶段是对数据进行部分聚合解决，也就是combiner解决。键相等的键值对会调用一次reduce办法。通过这一阶段，数据量会缩小。本阶段默认是没有的。2. Map阶段执行过程第一阶段是Reducer工作会被动从Mapper工作复制其输入的键值对。Mapper工作可能会有很多，因而Reducer会复制多个Mapper的输入。第二阶段是把复制到Reducer本地数据，全副进行合并，即把扩散的数据合并成一个大的数据。再对合并后的数据排序。第三阶段是对排序后的键值对调用reduce办法。键相等的键值对调用一次reduce办法，每次调用会产生零个或者多个键值对。最初把这些输入的键值对写入到HDFS文件中。1. key 的重要性体现在MapReduce编程中，外围是牢牢把握住每个阶段的输入输出key是什么。因为mr中很多默认行为都跟key相干。 排序：key的字典序a-z 正序分区：key.hashcode % reducetask 个数分组：key雷同的分为一组最重要的是，如果感觉默认的行为不满足业务需要，MapReduce还反对自定义排序、分区、分组的规定，这将使得编程更加灵便和不便。三.美国新冠疫情Covid-19 病例统计现有美国2021-1-28号，各个县county的新冠疫情累计案例信息，包含确诊病例和死亡病例，数据格式如下所示： 2021-01-28,Juneau City and Borough,Alaska,02110,1108,32021-01-28,Kenai Peninsula Borough,Alaska,02122,3866,182021-01-28,Ketchikan Gateway Borough,Alaska,02130,272,12021-01-28,Kodiak Island Borough,Alaska,02150,1021,52021-01-28,Kusilvak Census Area,Alaska,02158,1099,32021-01-28,Lake and Peninsula Borough,Alaska,02164,5,02021-01-28,Matanuska-Susitna Borough,Alaska,02170,7406,272021-01-28,Nome Census Area,Alaska,02180,307,02021-01-28,North Slope Borough,Alaska,02185,973,32021-01-28,Northwest Arctic Borough,Alaska,02188,567,12021-01-28,Petersburg Borough,Alaska,02195,43,0字段含意如下：date（日期）,county（县）,state（州）,fips（县编码code）,cases（累计确诊病例）,deaths（累计死亡病例）。 ...

一. HDFS客户端外围代码1. ConfigurationConfiguration提供对配置参数的拜访，通常称之为配置文件类。次要用于加载或者设定程序运行时相干的参数属性。 1. Configuration加载默认配置首先加载了静态方法和动态代码块，其中在动态代码块中显示默认加载了两个配置文件：core-default.xml以及core-site.xml 2. Configuration 加载用户设置通过conf.set设置的属性也会被加载。 1. FileSystemFileSystem类是一个通用的文件系统的形象基类。具体来说它能够实现为一个分布式的文件系统，也能够实现为一个本地文件系统。所有的可能会应用到HDFS的用户代码在进行编写时都应该应用FileSystem对象。代表本地文件系统的实现是LocalFileSystem，代表分布式文件系统的实现是DistributedFileSystem。当然针对其余hadoop反对的文件系统也有不同的具体实现。因而HDFS客户端在进行读写操作之前，须要创立FileSystem对象的实例。 1. 获取FileSystem 实例 FileSystem对象是通过调用getInternal办法失去的。 首先在getInternal办法中调用了createFileSystem办法，进去该办法：FileSystem实例是通过反射的形式取得的，具体实现是通过调用反射工具类ReflectionUtils的newInstance办法并将class对象以及Configuration对象作为参数传入最终失去了FileSystem实例。 二. HDFS通信协议1. 简介HDFS作为一个分布式文件系统，它的某些流程是非常复杂的（例如读、写文件等典型流程），经常波及数据节点、名字节点和客户端三者之间的配合、互相调用能力实现。为了升高节点间代码的耦合性，进步单个节点代码的内聚性， HDFS将这些节点间的调用形象成不同的接口。HDFS节点间的接口次要有两种类型：Hadoop RPC接口：基于Hadoop RPC框架实现的接口；流式接口：基于TCP或者HTTP实现的接口； 2. Hadoop RPC 接口1. RPC 介绍RPC 全称 Remote Procedure Call——近程过程调用。就是为了解决近程调用服务的一种技术，使得调用者像调用本地服务一样不便通明。 通信模块: 传输RPC申请和响应的网络通信模块，能够基于TCP协定，也能够基于UDP协定，能够是同步，也能够是异步的。客户端Stub程序： 服务器和客户端都包含Stub程序。在客户端，Stub程序体现的就像本地程序一样，但底层却会将调用申请和参数序列化并通过通信模块发送给服务器。之后Stub程序期待服务器的响应信息，将响应信息反序列化并返回给申请程序。 服务器端Stub程序： 在服务器端，Stub程序会将近程客户端发送的调用申请和参数反序列化，依据调用信息触发对应的服务程序，而后将服务程序返回的响应信息序列化并发回客户端。 申请程序： 申请程序会像调用本地办法一样调用客户端Stub程序，而后接管Stub程序返回的响应信息。 服务程序： 服务器会接管来自Stub程序的调用申请，执行对应的逻辑并返回执行后果。 Hadoop RPC调用使得HDFS过程可能像本地调用一样调用另一个过程中的办法，并且能够传递Java根本类型或者自定义类作为参数，同时接管返回值。如果近程过程在调用过程中出现异常，本地过程也会收到对应的异样。目前Hadoop RPC调用是基于Protobuf实现的。 Hadoop RPC接口次要定义在org.apache.hadoop.hdfs.protocol包和org.apache.hadoop.hdfs.server.protocol包中，外围的接口有：ClientProtocol、ClientDatanodeProtocol、DatanodeProtocol。 2. ClientProtocolClientProtocol定义了客户端与名字节点间的接口，这个接口定义的办法十分多，客户端对文件系统的所有操作都须要通过这个接口，同时客户端读、写文件等操作也须要先通过这个接口与Namenode协商之后，再进行数据块的读出和写入操作。 ClientProtocol定义了所有由客户端发动的、由Namenode响应的操作。这个接口十分大，有80多个办法，外围的是：HDFS文件读相干的操作、HDFS文件写以及追加写的相干操作。 读数据相干的办法ClientProtocol中与客户端读取文件相干的办法次要有两个： getBlockLocations（）和reportBadBlocks()客户端会调用ClientProtocol.getBlockLocations）办法获取HDFS文件指定范畴内所有数据块的地位信息。这个办法的参数是HDFS文件的文件名以及读取范畴，返回值是文件指定范畴内所有数据块的文件名以及它们的地位信息，应用LocatedBlocks对象封装。每个数据块的地位信息指的是存储这个数据块正本的所有Datanode的信息，这些Datanode会以与以后客户端的间隔远近排序。客户端读取数据时，会首先调用getBlockLocations（）办法获取HDFS文件的所有数据块的地位信息，而后客户端会依据这些地位信息从数据节点读取数据块。客户端会调用ClientProtocol.reportBadBlocks（）办法向Namenode汇报谬误的数据块。当客户端从数据节点读取数据块且发现数据块的校验和并不正确时，就会调用这个办法向Namenode汇报这个谬误的数据块信息。写、追加数据相干办法在HDFS客户端操作中最重要的一部分就是写入一个新的HDFS文件，或者关上一个已有的HDFS文件并执行追加写操作。ClientProtocol中定义了8个办法反对HDFS文件的写操作： create（）、 append（）、 addBlock（）、 complete（）， abandonBlockO），getAddtionnalDatanodes（）、updateBlockForPipeline()和updatePipeline()。create（）办法用于在HDFS的文件系统目录树中创立一个新的空文件，创立的门路由src参数指定。这个空文件创建后对于其余的客户端是“可读”的，然而这些客户端不能删除、重命名或者挪动这个文件，直到这个文件被敞开或者租约过期。客户端写一个新的文件时，会首先调用create办法在文件系统目录树中创立一个空文件，而后调用addBlock办法获取存储文件数据的数据块的地位信息，最初客户端就能够依据地位信息建设数据流管道，向数据节点写入数据了。 当客户端实现了整个文件的写入操作后，会调用complete（）办法告诉Namenode。这个操作会提交新写入HDFS文件的所有数据块，当这些数据块的正本数量满足系统配置的最小正本系数（默认值为1），也就是该文件的所有数据块至多有一个无效正本时， complete（）办法会返回true，这时Namenode中文件的状态也会从构建中状态转换为失常状态；否则， complete会返回false，客户端就须要反复调用complete操作，直至该办法返回true ClientDatanodeProtocol客户端与数据节点间的接口。ClientDatanodeProtocol中定义的办法次要是用于客户端获取数据节点信息时调用，而真正的数据读写交互则是通过流式接口进行的。ClientDatanodeProtocol中定义的接口能够分为两局部：一部分是反对HDFS文件读取操作的，例如getReplicaVisibleLength（）以及getBlockLocalPathInfo）；另一部分是反对DFSAdmin中与数据节点治理相干的命令。咱们重点关注第一局部。getReplicaVisibleLength客户端会调用getReplicaVisibleLength（）办法从数据节点获取某个数据块正本实在的数据长度。当客户端读取一个HDFS文件时，须要获取这个文件对应的所有数据块的长度，用于建设数据块的输出流，而后读取数据。然而Namenode元数据中文件的最初一个数据块长度与Datanode理论存储的可能不统一，所以客户端在创立输出流时就须要调用getReplicaVisibleLength（）办法从Datanode获取这个数据块的实在长度。getBlockLocalPathInfoHDFS对于本地读取，也就是Client和保留该数据块的Datanode在同一台物理机器上时，是有很多优化的。Client会调用ClientProtocol.getBlockLocalPathInfo）办法获取指定数据块文件以及数据块校验文件在以后节点上的本地门路，而后利用这个本地门路执行本地读取操作，而不是通过流式接口执行近程读取，这样也就大大优化了读取的性能。DatanodeProtocol数据节点通过这个接口与名字节点通信，同时名字节点会通过这个接口中办法的返回值向数据节点下发指令。留神，这是名字节点与数据节点通信的惟一形式。这个接口十分重要，数据节点会通过这个接口向名字节点注册、汇报数据块的全量以及增量的存储状况。同时，名字节点也会通过这个接口中办法的返回值，将名字节点指令带回该数据块，依据这些指令，数据节点会执行数据块的复制、删除以及复原操作。能够将DatanodeProtocol定义的办法分为三种类型： Datanode启动相干、心跳相干以及数据块读写相干。 2. 基于TCP/HTTP流式接口HDFS除了定义RPC调用接口外，还定义了流式接口，流式接口是HDFS中基于TCP或者HTTP实现的接口。在HDFS中，流式接口包含了基于TCP的DataTransferProtocol接口，以及HA架构中Active Namenode和Standby Namenode之间的HTTP接口。 ...

一. Trash垃圾回收1. 背景DFS自身也是一个文件系统，那么就会波及到文件数据的删除操作。默认状况下，HDFS中是没有回收站垃圾桶概念的，删除操作的数据将会被间接删除 2. 性能概述Trash机制，叫做回收站或者垃圾桶。Trash就像Windows操作系统中的回收站一样。它的目标是避免你无心中删除某些货色。默认状况下是不开启的。启用Trash性能后，从HDFS中删除某些内容时，文件或目录不会立刻被革除，它们将被挪动到回收站Current目录中(/user/${username}/.Trash/current)。 .Trash中的文件在用户可配置的时间延迟后被永恒删除。也能够简略地将回收站里的文件挪动到.Trash目录之外的地位来复原回收站中的文件和目录。 1. Trash Checkpoint检查点仅仅是用户回收站下的一个目录，用于存储在创立检查点之前删除的所有文件或目录。如果你想查看回收站目录，能够在/user/${username}/.Trash/{timestamp_of_checkpoint_creation}处看到: 最近删除的文件被挪动到回收站Current目录，并且在可配置的工夫距离内，HDFS会为在Current回收站目录下的文件创建检查点/user/${username}/.Trash/<日期>，并在过期时删除旧的检查点。 3. 性能开启1. 敞开HDFS集群在node1节点上，执行一键敞开HDFS集群命令：stop-dfs.sh。 2. 批改core-site.xml 文件在node1节点批改core-site.xml文件,增加上面两个属性: vim /export/server/hadoop-3.1.4/etc/hadoop/core-site.xml<property> <name>fs.trash.interval</name> <value>1440</value> </property> <property> <name>fs.trash.checkpoint.interval</name> <value>0</value> </property>fs.trash.interval： 分钟数，当超过这个分钟数后检查点会被删除。如果为零，Trash回收站性能将被禁用。fs.trash.checkpoint.interval： 检查点创立的工夫距离(单位为分钟)。其值应该小于或等于fs.trash.interval。如果为零，则将该值设置为fs.trash.interval的值。每次运行检查点时，它都会从以后版本中创立一个新的检查点，并删除在数分钟之前创立的检查点。 3. 同步集群配置文件scp -r /export/server/hadoop-3.1.4/etc/hadoop/core-site.xml node2:/export/server/hadoop-3.1.4/etc/hadoop/scp -r /export/server/hadoop-3.1.4/etc/hadoop/core-site.xml node3:/export/server/hadoop-3.1.4/etc/hadoop/4. 启动HDFS集群在node1节点上，执行一键启动HDFS集群命令：start-dfs.sh。 4. 性能应用1. 删除文件到Trash开启Trash性能后，失常执行删除操作，文件理论并不会被间接删除，而是被挪动到了垃圾回收站。Trash回收站上面查看： 2. 删除文件调过Trash有的时候，咱们心愿间接把文件删除，不须要再通过Trash回收站了，能够在执行删除操作的时候增加一个参数：-skipTrash. hadoop fs -rm -skipTrash /smallfile1/3.txt 3. 从Trash中复原文件回收站外面的文件，在到期被主动删除之前，都能够通过命令复原进去。应用mv、cp命令把数据文件从Trash目录下复制挪动进去就能够了。 hadoop fs -mv /user/root/.Trash/Current/smallfile1/* /smallfile1/ 4. 清空Trash除了fs.trash.interval参数管制到期主动删除之外，用户还能够通过命令手动清空回收站，开释HDFS磁盘存储空间。首先想到的是删除整个回收站目录，将会清空回收站,这是一个抉择。此外。HDFS提供了一个命令行工具来实现这个工作： hadoop fs -expunge该命令立刻从文件系统中删除过期的检查点。 Snapshot 快照1. 快照介绍和作用HDFS snapshot是HDFS整个文件系统，或者某个目录在某个时刻的镜像。该镜像并不会随着源目录的扭转而进行动静的更新。能够将快照了解为拍照片时的那一瞬间的投影，过了那个工夫之后，又会有新的一个投影。HDFS快照的核心作用包含：数据恢复、数据备份、数据测试。 1. 数据恢复能够通过滚动的形式来对重要的目录进行创立snapshot的操作，这样在零碎中就存在针对某个目录的多个快照版本。当用户误删除掉某个文件时，能够通过最新的snapshot来进行相干的复原操作。 2. 数据备份能够应用snapshot来进行整个集群，或者某些目录、文件的备份。管理员以某个时刻的snapshot作为备份的起始结点，而后通过比拟不同备份之间差异性，来进行增量备份。 3. 数据测试在某些重要数据上进行测试或者试验，可能会间接将原始的数据毁坏掉。能够长期的为用户针对要操作的数据来创立一个snapshot，而后让用户在对应的snapshot上进行相干的试验和测试，从而防止对原始数据的毁坏。 2. HDFS 快照的实现在理解HDFS快照性能如何实现之前，首先有一个基本的准则须要记住：快照不是数据的简略拷贝，快照只做差别的记录。 这一准则在其余很多零碎的快照概念中都是实用的，比方磁盘快照，也是不保留实在数据的。因为不保留理论的数据，所以快照的生成往往十分迅速。 ...

一. HDFS 架构分析1. HDFS 整体概述HDFS是Hadoop Distribute File System 的简称，意为：Hadoop分布式文件系统。是Hadoop外围组件之一，作为大数据生态圈最底层的分布式存储服务而存在。HDFS解决的问题就是大数据如何存储,它是横跨在多台计算机上的文件存储系统并且具备高度的容错能力。 HDFS集群遵循主从架构。每个群集包含一个主节点和多个从节点。在外部，文件分为一个或多个块，每个块依据复制因子存储在不同的从节点计算机上。主节点存储和治理文件系统名称空间，即无关文件块的信息，例如块地位，权限等。从节点存储文件的数据块。主从各司其职，互相配合，独特对外提供分布式文件存储服务。当然外部细节对于用户来说是通明的。 2.角色介绍1. 概述HDFS遵循主从架构。每个群集包含一个主节点和多个从节点。其中：NameNode是主节点，负责存储和治理文件系统元数据信息，包含namespace目录构造、文件块地位信息等；DataNode是从节点，负责存储文件具体的数据块。两种角色各司其职，独特协调实现分布式的文件存储服务。SecondaryNameNode是主角色的辅助角色，帮忙主角色进行元数据的合并。 2. NamenodeNameNode是Hadoop分布式文件系统的外围，架构中的主角色。它保护和治理文件系统元数据，包含名称空间目录树结构、文件和块的地位信息、拜访权限等信息。基于此，NameNode成为了拜访HDFS的惟一入口。 外部通过内存和磁盘两种形式治理元数据。其中磁盘上的元数据文件包含Fsimage内存元数据镜像文件和edits log（Journal）编辑日志。 3. DatanodeDataNode是Hadoop HDFS中的从角色，负责具体的数据块存储。DataNode的数量决定了HDFS集群的整体数据存储能力。通过和NameNode配合保护着数据块。 4. Secondarynamenode除了DataNode和NameNode之外，还有另一个守护过程，它称为secondary NameNode。充当NameNode的辅助节点，但不能代替NameNode。当NameNode启动时，NameNode合并Fsimage和edits log文件以还原以后文件系统名称空间。如果edits log过大不利于加载，SecondaryNameNode就辅助NameNode从NameNode下载Fsimage文件和edits log文件进行合并。 3. HDFS重要个性1. 主从架构HDFS采纳master/slave架构。个别一个HDFS集群是有一个Namenode和肯定数目的Datanode组成。Namenode是HDFS主节点，Datanode是HDFS从节点，两种角色各司其职，独特协调实现分布式的文件存储服务。 2. 分块机制HDFS中的文件在物理上是分块存储（block）的，块的大小能够通过配置参数来规定，参数位于hdfs-default.xml中：dfs.blocksize。默认大小是128M（134217728）。 3. 正本机制为了容错，文件的所有block都会有正本。每个文件的block大小（dfs.blocksize）和正本系数（dfs.replication）都是可配置的。应用程序能够指定某个文件的正本数目。正本系数能够在文件创建的时候指定，也能够在之后通过命令扭转。默认dfs.replication的值是3，也就是会额定再复制2份，连同自身总共3份正本。 4. NameSpaceHDFS反对传统的档次型文件组织构造。用户能够创立目录，而后将文件保留在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统相似：用户能够创立、删除、挪动或重命名文件。 Namenode负责保护文件系统的namespace名称空间，任何对文件系统名称空间或属性的批改都将被Namenode记录下来。 HDFS会给客户端提供一个对立的形象目录树，客户端通过门路来拜访文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。 5. 元数据管理在HDFS中，Namenode治理的元数据具备两种类型： 文件本身属性信息文件名称、权限，批改工夫，文件大小，复制因子，数据块大小。文件块地位映射信息记录文件块和DataNode之间的映射信息，即哪个块位于哪个节点上6. 数据库存储文件的各个block的具体存储管理由DataNode节点承当。每一个block都能够在多个DataNode上存储。 2. HDFS Web Interfaces1. Web Interfaces介绍除了命令行界面之外，Hadoop还为HDFS提供了Web用户界面。用户能够通过Web界面操作文件系统并且获取和HDFS相干的状态属性信息。 HDFS Web地址是http://nn_host:port/,默认端口号9870。 2. 模块功能模块OverviewOverview是总揽模块，默认的主页面。展现了HDFS一些最外围的信息。 Summary NameNode Journal Status NameNode Storage DFS Storage Types DatanodesDatanodes模块次要记录了HDFS集群中各个DataNode的相干状态信息Datanode Volume Failures此模块记录了DataNode卷故障信息。SnapshotSnapshot模块记录HDFS文件系统的快照相干信息，包含哪些文件夹创立了快照和总共有哪些快照。Satartup progressStartup Progress模块记录了HDFS集群启动的过程信息，执行步骤和每一步所做的事和用时。UtilitiesUtilities模块算是用户应用最多的模块了，外面包含了文件浏览、日志查看、配置信息查看等外围性能。 Browse the file system该模块能够说是咱们在开发应用HDFS过程中应用最多的模块了，提供了一种Web页面浏览操作文件系统的能力，在某些场合下，比应用命令操作更加直观不便。 ...

一.介绍HDFS滚动降级容许降级单个HDFS守护程序。例如，能够独立于NameNodes降级DataNodes。也能够独立于其余NameNodes降级独自NameNode。也能够独立于DataNodes和journal nodes降级NameNodes。 二. 降级在Hadoop v2中，HDFS反对NameNode高可用（HA）和线路兼容性（wire compatibility）。这两个性能使降级HDFS变得可行，且不会导致HDFS停机。为了在不停机的状况下降级HDFS群集，必须应用HA设置群集。如果新软件版本中启用了任何新性能，则降级后可能无奈与旧软件版本一起应用。 在这种状况下，应依照以下步骤进行降级。禁用新性能、降级集群、启用新性能。请留神，仅从Hadoop-2.4.0起才反对滚动降级。 1. 不停机降级在HA群集中，有两个或多个NameNode（NN），许多DataNode（DN），一些JournalNode（JN）和一些ZooKeeperNode（ZKN）。JN绝对稳固，在大多数状况下，降级HDFS时不须要降级。滚动降级过程中，仅针对NNs和DNs，JNS和ZKNs都没有。降级JN和ZKN可能会导致群集停机。 降级非联邦集群假如有两个名称节点NN1和NN2，其中NN1和NN2别离处于Active和StandBy状态。以下是降级HA群集的步骤： 筹备滚动降级 运行hdfs dfsadmin -rollingUpgrade prepare 以创立用于回滚的fsimage 运行hdfs dfsadmin -rollingUpgrade query 以查看回滚fsimage的状态。期待 并从新运行命令，直到显示Proceeding with Rolling Upgrade信息。降级Active和standBy NN 敞开并降级NN2。 启动NN2成为StandBy状态通过-rollingUpgrade started选项。 从NN1到NN2的故障转移，以便NN2变为活动状态，而NN1变为待机状态。 敞开并降级NN1。 启动NN1成为StandBy状态通过-rollingUpgrade started选项。降级DN 抉择一小部分DN节点（例如，特定机架下的所有数据节点）。 运行hdfs dfsadmin -shutdownDatanode <DATANODE_HOST：IPC_PORT> upgrade 以敞开所选的DN。 运行hdfs dfsadmin -getDatanodeInfo <DATANODE_HOST：IPC_PORT>进行查看，而后期待DN敞开。 降级并重启DN节点。 对子集中的所有选定DN节点并行执行以上步骤。 反复上述步骤，直到降级群集中的所有DN节点。实现滚动降级 运行hdfs dfsadmin -rollingUpgrade finalize实现滚动降级。降级联邦集群 在联邦集群中，有多个名称空间以及每个名称空间的一对Active和StandBy NN。降级联结群集的 过程相似于降级非联邦群集的过程，不同之处在于 为每个命名空间筹备滚动降级 降级每个命名空间的Active和StandBy NN 降级DN 实现每个命名空间的滚动降级2. 停机降级对于非HA群集，无奈在没有停机的状况下降级HDFS，因为它须要重新启动NN。然而，DN仍能够滚动形式降级。 降级非HA集群在非HA群集中，有一个NameNode（NN），SecondaryNameNode（SNN）和许多DataNodes（DN）。降级非HA群集的过程与降级HA群集的过程相似，不同之处在于，将降级非HA集群中的第2步“降级流动和备用NN降级”更改为以下内容： 降级NN和SNN 敞开SNN 敞开并降级NN。 应用-rollingUpgrade started 选项启动NN。 降级并重新启动SNN三. 降级和回滚如果不心愿应用降级版本，或者在某些不太可能的状况下，降级失败（因为较新版本中的谬误），管理员能够抉择将HDFS降级到降级前版本，或将HDFS回滚到降级前版本和降级前的状态。请留神，降级能够滚动形式进行，但不能回滚。回滚要求集群停机。还请留神，只有在开始滚动降级之后且终止降级之前，才能够进行降级和回滚。能够通过实现，降级或回滚来终止降级。因而，可能无奈在实现或降级之后执行回滚，或者在实现后无奈执行降级。 ...

一. 以后HDFS体系架构1. 简介 以后的HDFS架构有两个次要的层： 命名空间(namespace)HDFS体系结构中的命名空间层由文件，块和目录组成。该层反对与名称空间相干的文件系统操作，例如创立，删除，批改和列出文件和目录。块存储层(Block Storage)块存储层包含两个局部:块治理： NameNode执行块治理。块治理通过解决注册和定期心跳来提供DataNode群集成员身份。它解决块报告并反对与块相干的操作，如创立，删除，批改或获取块地位。它还保护块的地位，正本地位。为未复制的块治理块复制，并在已复制的块中删除。存储: DataNode通过在本地文件系统上存储块并提供读/写访问权限来治理存储空间。2.局限性当下的HDFS体系结构仅容许单个NameNode保护文件系统名称空间。留神HA体系中尽管说容许多个NameNode，然而他们所保护的是同一套文件系统名称空间。这种体系目前存在着一些弊病和局限性： DataNode磁盘存储空间不够减少节点，NameNode内存不够是否能够有限扩容。一种是DataNode横向扩大机器减少节点，一种是纵向扩大单机加内存。因为名称空间和存储层的严密耦合，NameNode的代替实现很艰难。这限度了其余服务间接应用块存储。惟一的NameNode成了惟一入口。文件系统的操作还限于NameNode一次解决的工作数。因而，群集的性能取决于NameNode吞吐量。同样，因为应用单个名称空间，因而应用群集的占用者组织之间没有隔离。二. HDFS Federation架构1. 简介Federation中文意思为联邦,联盟，是NameNode之间的Federation,也就是集群中会有多个NameNode。多个NameNode的状况意味着有多个namespace。留神，这区别于HA模式下的多NameNode，HA中它们是领有着同一个namespace。Federation体系中多个namenode之间互相独立且不须要相互协调，各自分工，治理本人的区域。 每个DataNode要向集群中所有的namenode注册，且周期性地向所有namenode发送心跳和块报告，并执行来自所有namenode的命令。上图中，有多个NameNode，别离示意为NN1，NN2，.. NNn。NS1，NS2等是由它们各自的NameNode治理的多个名称空间。每个名称空间都有其本人的块池（block pool）（NS1具备Pool1，NS2具备Pool2，依此类推）。每个DataNode存储集群中所有块池的块。HDFS Federation体系结构中的块池是属于单个名称空间的块的汇合。每个块池彼此独立地进行治理。在删除NameNode或名称空间时，DataNode中存在的相应块池也将被删除。在降级群集时，每个名称空间卷都作为一个单元进行降级。 2. 长处命名空间可伸缩性应用Federation，能够程度扩大名称空间。这对大型群集或蕴含太多小文件的群集无利，因为向群集增加了更多的NameNode。性能因为文件系统操作不受单个NameNode吞吐量的限度，因而能够进步文件系统的性能。隔离因为有多个名称空间，它能够为应用集群的占用者组织提供隔离。3. HDFS Federation配置示例core-site.xml <configuration><property><name>fs.defaultFS</name><value>viewfs:///</value></property><property><name>fs.viewfs.mounttable.default.link./bi</name><value>hdfs://bi/</value></property><property><name>fs.viewfs.mounttable.default.link./dt</name><value>hdfs://dt/</value></property><!-- 指定hadoop长期目录 --><property><name>hadoop.tmp.dir</name><value>/home/hadoop/apps/hdpdata/</value></property><!-- 指定zookeeper地址 --><property><name>ha.zookeeper.quorum</name><value>mini5:2181,mini6:2181,mini7:2181</value></property></configuration>hdfs-site.xml<configuration><!--指定hdfs的nameservice为bi，须要和core-site.xml中的保持一致 --><property><name>dfs.nameservices</name><value>bi,dt</value></property><!-- bi上面有两个NameNode，别离是nn1，nn2 --><property><name>dfs.ha.namenodes.bi</name><value>nn1,nn2</value></property><property><name>dfs.ha.namenodes.dt</name><value>nn3,nn4</value></property><!-- bi的RPC通信地址 --><property><name>dfs.namenode.rpc-address.bi.nn1</name><value>mini1:9000</value></property><!-- nn1的http通信地址 --><property><name>dfs.namenode.http-address.bi.nn1</name><value>mini1:50070</value></property><!-- nn2的RPC通信地址 --><property><name>dfs.namenode.rpc-address.bi.nn2</name><value>mini2:9000</value></property><!-- nn2的http通信地址 --><property><name>dfs.namenode.http-address.bi.nn2</name><value>mini2:50070</value></property><!-- dt的RPC通信地址 --><property><name>dfs.namenode.rpc-address.dt.nn3</name><value>mini3:9000</value></property><!-- nn1的http通信地址 --><property><name>dfs.namenode.http-address.dt.nn3</name><value>mini3:50070</value></property><!-- nn2的RPC通信地址 --><property><name>dfs.namenode.rpc-address.dt.nn4</name><value>mini4:9000</value></property><!-- nn2的http通信地址 --><property><name>dfs.namenode.http-address.dt.nn4</name><value>mini4:50070</value></property><!-- 指定NameNode的edits元数据在JournalNode上的寄存地位 --><!--一下property项的配置，不能都配 --><!-- 在bi名称空间的两个namenode中用如下配置 --><property><name>dfs.namenode.shared.edits.dir</name><value>qjournal://mini5:8485;mini6:8485;mini7:8485/bi</value></property><!-- 在dt名称空间的两个namenode中，用如下配置--><property><name>dfs.namenode.shared.edits.dir</name><value>qjournal://mini5:8485;mini6:8485;mini7:8485/dt</value></property><!-- 指定JournalNode在本地磁盘存放数据的地位 --><property><name>dfs.journalnode.edits.dir</name><value>/home/hadoop/apps/hdpdata/journaldata</value></property><!-- 开启NameNode失败主动切换 --><property><name>dfs.ha.automatic-failover.enabled</name><value>true</value></property><!-- 配置失败主动切换实现形式 --><property><name>dfs.client.failover.proxy.provider.bi</name><value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value></property><property><name>dfs.client.failover.proxy.provider.dt</name><value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value></property><!-- 配置隔离机制办法，多个机制用换行宰割，即每个机制暂用一行--><property><name>dfs.ha.fencing.methods</name><value>sshfenceshell(/bin/true)</value></property><!-- 应用sshfence隔离机制时须要ssh免登陆 --><property><name>dfs.ha.fencing.ssh.private-key-files</name><value>/home/hadoop/.ssh/id_rsa</value></property><!-- 配置sshfence隔离机制超时工夫 --><property><name>dfs.ha.fencing.ssh.connect-timeout</name><value>30000</value></property></configuration>mapred-site.xml<configuration><!-- 指定mr框架为yarn形式 --><property><name>mapreduce.framework.name</name><value>yarn</value></property></configuration> 4.yarn-site.xml <configuration><!-- 开启RM高可用 --><property><name>yarn.resourcemanager.ha.enabled</name><value>true</value></property><!-- 指定RM的cluster id --><property><name>yarn.resourcemanager.cluster-id</name><value>yrc</value></property><!-- 指定RM的名字 --><property><name>yarn.resourcemanager.ha.rm-ids</name><value>rm1,rm2</value></property><!-- 别离指定RM的地址 --><property><name>yarn.resourcemanager.hostname.rm1</name><value>mini3</value></property><property><name>yarn.resourcemanager.hostname.rm2</name><value>mini4</value></property><!-- 指定zk集群地址 --><property><name>yarn.resourcemanager.zk-address</name><value>mini5:2181,mini6:2181,mini7:2181</value></property><property><name>yarn.nodemanager.aux-services</name><value>mapreduce_shuffle</value></property></configuration>4.Federation初始化步骤先启动zookeeper集群再在5/6/7上启动journalnodehadoop-daemon.sh start journalnode在bi下nn1上 hdfs namenode -format –clusterID itcasthdfs zkfc -formatZK拷贝元数据目录到standby(nn2)在dt下nn3上 hdfs namenode -format –clusterID itcast ###clusterID必须与bi的雷同hdfs zkfc -formatZK拷贝元数据目录到standby(nn4)在bi下nn1上sbin/start-dfs.sh在resoucemanager配置的主机上启动yarnsbin/start-yarn.sh

一. High Availability背景常识1. 单点故障、高可用单点故障（英语：single point of failure，缩写SPOF）是指零碎中某一点一旦生效，就会让整个零碎无奈运作，换句话说，单点故障即会整体故障。 高可用性（英语：high availability，缩写为 HA），IT术语，指零碎无中断地执行其性能的能力，代表零碎的可用性水平。是进行零碎设计时的准则之一。高可用性零碎意味着零碎服务能够更长时间运行，通常通过进步零碎的容错能力来实现。 高可用性或者高牢靠度的零碎不会心愿有单点故障造成整体故障的情景。个别能够透过冗余的形式减少多个雷同机能的部件，只有这些部件没有同时生效，零碎（或至多局部零碎）仍可运作，这会让牢靠度提高。 2. 高可用的实现主备集群解决单点故障，实现零碎服务高可用的外围并不是让故障永不产生，而是让故障的产生对业务的影响降到最小。因为软硬件故障是难以避免的问题。当下企业中成熟的做法就是给单点故障的地位设置备份，造成主备架构。艰深形容就是当主挂掉，备份顶上，短暂的中断之后持续提供服务。常见的是一主一备架构，当然也能够一主多备。备份越多，容错能力越强，与此同时，冗余也越大，浪费资源。Active、Standby Active：主角色。沉闷的角色，代表正在对外提供服务的角色服务。任意工夫有且只有一个active对外提供服务。Standby：备份角色。须要和主角色保持数据、状态同步，并且时刻筹备切换成主角色（当主角色挂掉或者呈现故障时），对外提供服务，放弃服务的可用性。3. 可用性评判规范—x个9在零碎的高可用性里有个掂量其可靠性的规范——X个9，这个X是代表数字3-5。X个9示意在零碎1年工夫的应用过程中，零碎能够失常应用工夫与总工夫（1年）之比。 3个9：(1-99.9%)36524=8.76小时，示意该零碎在间断运行1年工夫里最多可能的业务中断工夫是8.76小时。4个9：(1-99.99%)36524=0.876小时=52.6分钟，示意该零碎在间断运行1年工夫里最多可能的业务中断工夫是52.6分钟5个9：(1-99.999%)36524*60=5.26分钟，示意该零碎在间断运行1年工夫里最多可能的业务中断工夫是5.26分钟。能够看出，9越多，零碎的可靠性越强，可能容忍的业务中断工夫越少，然而要付出的老本更高 4. HA 零碎设计外围问题脑裂问题脑裂(split-brain)是指“大脑决裂”,本是医学名词。在HA集群中，脑裂指的是当分割主备节点的"心跳线"断开时(即两个节点断开分割时)，原本为一个整体、动作协调的HA零碎，就决裂成为两个独立的节点。因为互相失去了分割，主备节点之间像"裂脑人"一样，使得整个集群处于混乱状态。脑裂的严重后果： 集群无主：都认为对方是状态好的，本人是备份角色，结果是无服务；集群多主：都认为对方是故障的，本人是主角色。互相争抢共享资源，后果会导致系统凌乱，数据损坏。此外对于客户端拜访也是一头雾水，找谁呢？防止脑裂问题的外围是：放弃任意时刻零碎有且只有一个主角色提供服务。 数据同步问题 主备切换保障服务继续可用性的前提是主备节点之间的状态、数据是统一的，或者说准统一的。如果说备用的节点和主节点之间的数据差距过大，即便实现了主备切换的动作，那也是没有意义的。数据同步常见做法是：通过日志重演操作记录。主角色失常提供服务，产生的事务性操作通过日志记录，备用角色读取日志重演操作。 二. HDFS NAMENODE单点故障问题在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个群集只有一个NameNode，如果该计算机或过程不可用，则整个群集在整个NameNode重新启动或在另一台计算机上启动之前将不可用。NameNode的单点故障从两个方面影响了HDFS群集的总可用性： 如果产生意外事件（例如机器解体），则在重新启动NameNode之前，群集将不可用。打算内的保护事件，例如NameNode计算机上的软件或硬件降级，将导致群集停机工夫的缩短。HDFS高可用性解决方案：在同一群集中运行两个（从3.0.0起，超过两个）冗余NameNode。这样能够在机器解体的状况下疾速故障转移到新的NameNode，或者出于打算保护的目标由管理员发动的失常故障转移。单点部署:高可用部署 三. HDFS HA解决方案—QJMQJM全称Quorum Journal Manager，由cloudera公司提出，是Hadoop官网举荐的HDFS HA解决方案之一。QJM中，应用zookeeper中ZKFC来实现主备切换；应用Journal Node（JN）集群实现edits log的共享以达到数据同步的目标。 1. QJM—主备切换、脑裂问题解决ZKFailoverController(zkfc)Apache ZooKeeper是一款高可用分布式协调服务软件，用于保护大量的协调数据。 Zookeeper的下列个性性能参加了HDFS的HA解决方案中： 长期znode 如果一个znode节点是长期的，那么该znode的生命周期将和创立它的客户端的session绑定。客户端断开连接session完结，znode将会被主动删除。Path门路唯一性 zookeeper中维持了一份相似目录树的数据结构。每个节点称之为Znode。Znode具备唯一性，不会重名。也能够了解为排他性。监听机制 客户端能够针对znode上产生的事件设置监听，当事件产生触发条件，zk服务会把事件告诉给设置监听的客户端。ZKFailoverController（ZKFC）是一个新组件，它是一个ZooKeeper客户端。运行NameNode的每台计算机也都运行ZKFC，ZKFC的主要职责： 监督和治理NameNode衰弱状态 ZKFC通过命令定期ping本地负责监督的NameNode节点。维持和ZooKeeper集群分割 如果本地NameNode运行状况良好，并且ZKFC看到以后没有其余节点持有锁znode，它将本人尝试获取该锁。如果胜利，则表明它“博得了选举”，并负责运行故障转移以使其本地NameNode处于Active状态。如果曾经有其余节点持有锁，zkfc选举失败，则会对该节点注册监听，期待下次持续选举。Fencing 隔离机智 故障转移过程也就是俗称的主备角色切换的过程，切换过程中最怕的就是脑裂的发送。因而须要Fencing机制来防止，将先前的Active节点隔离，而后将本地NameNode转换为Active状态。Hadoop公共库中对外提供了两种fenching实现，别离是sshfence和shellfence（缺省实现），其中sshfence是指通过ssh登陆指标节点上，应用命令fuser将过程杀死（通过tcp端口号定位过程pid，该办法比jps命令更精确），shellfence是指执行一个用户当时定义的shell命令（脚本）实现隔离。 2. QJM—主备数据同步问题解决Journal Node（JN）集群是轻量级分布式系统，次要用于高速读写数据、存储数据。通常应用2N+1台JournalNode存储共享Edits Log（编辑日志）。任何批改操作在 Active NN上执行时，JournalNode过程同时也会记录edits log到至多半数以上的JN中，这时 Standby NN 监测到JN 外面的同步log发生变化了会读取JN外面的edits log，而后重演操作记录同步到本人的目录镜像树外面，当产生故障Active NN挂掉后，Standby NN 会在它成为Active NN 前，读取所有的JN外面的批改日志，这样就能高牢靠的保障与挂掉的NN的目录镜像树统一，而后无缝的接替它的职责，保护来自客户端申请，从而达到一个高可用的目标。 4. HA环境搭建HA集群搭建的难度次要在于配置文件的编写，心细，心细，心细！ 1. 集群根底环境筹备批改Linux 主机名 /etc/hostname批改IP /etc/sysconfig/network-scripts/ifcfg-ens33批改主机名和Ip映射关系敞开防火墙ssh免密登陆装置JDK,配置环境变量等 /etc/profile集群工夫同步配置主备NN之间的互相免密登录2. HA集群布局node1 namenode zkfc datanode zookeeper journal nodenode2 namenode zkfc datanode zookeeper journal nodenode3 datanode zookeeper journal node93. 装置配置zookeepe上传zookeeper 至linux ...

HDFS 优化计划1. 短路本地读取：Short Circuit Local Reads1.背景在HDFS中，不论是Local Reads（DFSClient和Datanode在同一个节点）还是Remote Reads（DFSClient和Datanode不在同一个节点），底层解决形式都是一样的，都是先由Datanode读取数据，而后再通过RPC（基于TCP）把数据传给DFSClient。这样解决是比较简单的，然而性能会受到一些影响，因为须要Datanode在两头做一次直达。尤其Local Reads的时候，既然DFSClient和数据是在一个机器下面，那么很天然的想法，就是让DFSClient绕开Datanode本人去读取数据所谓的“短路”读取绕过了DataNode，从而容许客户端间接读取文件。显然，这仅在客户端与数据位于同一机器的状况下才可行。短路读取为许多利用提供了显着的性能晋升。 2. 短路本地读取在HDFS-2246这个JIRA中，工程师们的想法是既然读取数据DFSClient和数据在同一台机器上，那么Datanode就把数据在文件系统中的门路，从什么中央开始读(offset)和须要读取多少(length)等信息通知DFSClient，而后DFSClient去关上文件本人读取。想法很好，问题在于配置简单以及平安问题。首先是配置问题，因为是让DFSClient本人关上文件读取数据，那么就须要配置一个白名单，定义哪些用户领有拜访Datanode的数据目录权限。如果有新用户退出，那么就得批改白名单。须要留神的是，这里是容许客户端拜访Datanode的数据目录，也就意味着，任何用户领有了这个权限，就能够拜访目录下其余数据，从而导致了安全漏洞。因而，这个实现曾经不倡议应用了。 3. 短路本地读取安全性改良在HDFS-347中，提出了一种新的解决方案，让短路本地读取数据更加平安。Unix Domain Socket是一种过程间的通信形式，它使得同一个机器上的两个过程能以Socket的形式通信。它带来的另一大益处是，利用它两个过程除了能够传递一般数据外，还能够在过程间传递文件描述符。 假如机器上的两个用户A和B，A领有拜访某个文件的权限而B没有，而B又须要拜访这个文件。借助Unix Domain Socket，可以让A关上文件失去一个文件描述符，而后把文件描述符传递给B，B就能读取文件外面的内容了即便它没有相应的权限。在HDFS的场景外面，A就是Datanode，B就是DFSClient，须要读取的文件就是Datanode数据目录中的某个文件。这个计划在平安上就比上一个计划上好一些，至多它只容许DFSClient读取它须要的文件 4. 短路本地读取配置libhadoop.so因为Java不能间接操作Unix Domain Socket，所以须要装置Hadoop的native包libhadoop.so。在编译Hadoop源码的时候能够通过编译native模块获取。能够用如下命令来查看native包是否装置好。 hadoop checknative hdfs-site.xml<property> <name>dfs.client.read.shortcircuit</name> <value>true</value> </property> <property> <name>dfs.domain.socket.path</name> <value>/var/lib/hadoop-hdfs/dn_socket</value> </property>dfs.client.read.shortcircuit是关上短路本地读取性能的开关，dfs.domain.socket.path是Datanode和DFSClient之间沟通的Socket的本地门路。 2. HDFS Block负载平衡器：Balancer1. 背景HDFS数据可能并不总是在DataNode之间均匀分布。一个常见的起因是向现有群集中增加了新的DataNode。HDFS提供了一个Balancer程序，剖析block搁置信息并且在整个DataNode节点之间均衡数据，直到被视为均衡为止。平衡器无奈在单个DataNode上的各个卷之间进行均衡。 2. 命令行配置和运行命令: hdfs balancer --help设置均衡数据传输带宽命令： hdfs dfsadmin -setBalancerBandwidth newbandwidth默认运行 balancer命令: hdfs balancer此时将会以默认参数进行数据块的均衡操作。 批改阈值运行balancer命令: hdfs balancer -threshold 5Balancer将以阈值5％运行（默认值10%），这意味着程序将确保每个DataNode上的磁盘使用量与群集中的总体使用量相差不超过5％。例如，如果集群中所有DataNode的总体使用率是集群磁盘总存储容量的40％，则程序将确保每个DataNode的磁盘使用率在该DataNode磁盘存储容量的35％至45％之间。 3.磁盘均衡器：HDFS Disk Balancer1. 背景绝对于集体PC,服务器个别能够通过挂载对块磁盘来扩充单机的存储能力在Hadoop HDFS中，DataNode负责最终数据block的存储，在所在机器上的磁盘之间调配数据块。当写入新block时，DataNodes将依据抉择策略（循环策略或可用空间策略）来抉择block的磁盘（卷）。循环策略: 它将新block均匀分布在可用磁盘上。默认此策略。可用空间策略： 此策略将数据写入具备更多可用空间（按百分比）的磁盘然而，在长期运行的群集中采纳循环策略时，DataNode有时会不平均地填充其存储目录（磁盘/卷），从而导致某些磁盘已满而其余磁盘却很少应用的状况。产生这种状况的起因可能是因为大量的写入和删除操作，也可能是因为更换了磁盘。另外，如果咱们应用基于可用空间的抉择策略，则每个新写入将进入新增加的空磁盘，从而使该期间的其余磁盘处于闲暇状态。这将在新磁盘上创立瓶颈。因而，须要一种Intra DataNode Balancing（DataNode内数据块的均匀分布）来解决Intra-DataNode偏斜（磁盘上块的不均匀分布），这种偏斜是因为磁盘更换或随机写入和删除而产生的。因而，Hadoop 3.0中引入了一个名为Disk Balancer的工具，该工具专一于在DataNode内散发数据。 2. HDFS Disk Balancer简介HDFS disk balancer是Hadoop 3中引入的命令行工具，用于均衡DataNode中的数据在磁盘之间散布不平均问题。 这里要特地留神，HDFS disk balancer与HDFS Balancer是不同的： HDFS disk balancer针对给定的DataNode进行操作，并将块从一个磁盘挪动到另一个磁盘,是DataNode外部数据在不同磁盘间均衡；HDFS Balancer均衡了DataNode节点之间的散布。 ...

一. HDFS数据迁徙解决方案数据迁徙指的是一种大规模量级的数据转移，转移的过程中往往会跨机房、跨集群 ，数据迁徙规模的不同会导致整个数据迁徙的周期也不尽相同 。 在HDFS中，同样有许多须要数据迁徙的场景，比方冷热数据集群之间的数据转化， 或者HDFS数据的双机房备份等等 。因为波及跨机房 、跨集群，所以数据迁徙不会是一个简略的操作。 1. 数据迁徙应用场景冷热集群数据同步、分类存储集群数据整体搬迁 当公司的业务迅速的倒退,导致以后的服务器数量资源呈现长期缓和的时候,为了更高效的利用资源,会将原A机房数据整体迁徙到B机房的,起因可能是B机房机器多,而且B机房自身开销较A机房成本低些等；数据的准实时同步数据准实时同步的目标在于数据的双备份可用,比方某天A集群忽然宣告不容许再应用了,此时能够将线上应用集群间接切向B的同步集群,因为B集群实时同步A集群数据,领有完全一致的实在数据和元数据信息,所以对于业务方应用而言是不会受到任何影响的。 2. 数据迁徙因素考量Bandwidth-带宽带宽用的多了,会影响到线上业务的工作运行,带宽用的少了又会导致数据同步过慢的问题。Performance-性能是采纳简略的单机程序?还是多线程的性能更佳的分布式程序?Data-Increment-增量同步当TB,PB级别的数据须要同步的时候,如果每次以全量的形式去同步数据,后果肯定是十分蹩脚。如果仅针对变动的增量数据进行同步将会是不错的抉择。能够配合HDFS快照等技术实现增量数据同步。Syncable-数据迁徙的同步性数据迁徙的过程中须要保障周期内数据是肯定可能同步完的,不能差距太大.比方A集群7天内的增量数据,我只有花半天就能够齐全同步到B集群,而后我又能够等到下周再次进行同步.最可怕的事件在于A集群的7天内的数据,我的程序花了7天还同步不完,而后下一个周期又来了,这样就无奈做到准实时的一致性.其实7天还是一个比拟大的工夫,最好是能达到按天同步数据在指定周期内还没有同步完,下一个周期就开始了,这样就无奈做到准实时的一致性 3. HDFS分布式拷贝工具:DistCp1. DistCp 介绍:DistCp是Apache Hadoop中的一种风行工具，在hadoop-tools工程下，作为独立子工程存在。其定位就是用于数据迁徙的，定期在集群之间和集群外部备份数据。（在备份过程中，每次运行DistCp都称为一个备份周期。）只管性能绝对较慢，但它的遍及水平曾经越来越高。DistCp底层应用MapReduce在群集之间或并行在同一群集内复制文件。执行复制的MapReduce只有mapper阶段。它波及两个步骤： 构建要复制的文件列表（称为复制列表）运行MapReduce作业以复制文件，并以复制列表为输出。2. DistCp劣势个性带宽限流DistCp能够通过命令参数 bandwidth 来为程序进行带宽限流。避免拷贝数据占用大量带宽导致集群性能降落增量数据同步在DistCp中能够通过update 、append 和diff 这3个参数实现增量同步 参数性能Update只拷贝不存在的文件或者目录Append追加写指标门路下已存在的文件Diff通过快照的Diff比照信息来同步源门路与指标门路Update解决了新增文件、目录的同步。Append解决己存在文件的增量更新同步。Diff解决删除或重命名类型文件的同步。 高效的性能:分布式个性DistCp底层应用MapReduce执行数据同步，MapReduce自身是一类分布式程序。 3. DistCp 命令$ hadoop distcpusage: distcp OPTIONS [source_path...] <target_path> -append //拷贝文件时反对对现有文件进行追加写操作 -async //异步执行distcp拷贝工作 -bandwidth <arg> //对每个Map工作的带宽限速 -delete //删除绝对于源端,指标端多进去的文件 -diff <arg> //通过快照diff信息进行数据的同步 -overwrite //以笼罩的形式进行拷贝，如果指标端文件曾经存在，则间接笼罩 -p <arg> //拷贝数据时,扩大属性信息的保留，包含权限信息、块大小信息等等 -skipcrccheck //拷贝数据时是否跳过cheacksum的校验 -update //拷贝数据时,只拷贝绝对于源端 ，指标端不存在的文件数据命令: hadoop distcp hdfs://nnl:8020/foo/a hdfs://nn2:8020/bar/foo下面的命令示意从nnl集群拷贝／foo/a 门路下的数据到nn2集群的／bar/foo 门路下。 二. HDFS NAMENODE 平安模式1. 平安模式概述Hadoop中的平安模式safe mode是NameNode的保护状态，在此状态下NameNode不容许对文件系统进行任何更改，能够承受读数据申请。在NameNode启动过程中，首先会从fsimage和edits日志文件加载文件系统状态。而后，期待DataNodes汇报可用的block信息。在此期间，NameNode放弃在平安模式。随着DataNode的block汇报继续进行，当整个零碎达到平安规范时，HDFS主动来到平安模式。在NameNode Web主页上会显示平安模式是关上还是敞开。如果HDFS处于平安模式下，不容许HDFS客户端进行任何批改文件的操作,包含上传文件，删除文件，重命名，创立文件夹,批改正本数等操作。 ...

一.背景在Hadoop中，个别存储着十分大的文件，以及在存储HDFS块或运行MapReduce工作时，Hadoop集群中节点之间的存在大量数据传输。 如果条件容许时，尽量减少文件大小，这将有助于缩小存储需要以及缩小网络上的数据传输。 二. Hadoop反对的压缩算法Haodop对文件压缩均实现org.apache.hadoop.io.compress.CompressionCodec接口，所有的实现类都在org.apache.hadoop.io.compress包下 1. 压缩算法比拟有不少的压缩算法能够利用到Hadoop中，但不同压缩算法有各自的特点。存放数据到HDFS中，能够抉择指定的压缩形式，在MapReduce程序读取时，会依据扩展名主动解压。例如：如果文件扩大名为.snappy，Hadoop框架将主动应用SnappyCodec解压缩文件。整体排序如下：Snappy < LZ4 < LZO < GZIP < BZIP2，但压缩比越高，压缩的工夫也会更长。以下是局部参考数据 2. HDFS压缩如何抉择既然压缩可能节俭空间、而且能够晋升IO效率，那么是否将所有数据都以压缩格局存储在HDFS中呢？例如：bzip2，而且文件是反对切分的。 如果文件是不可切分的，只有一个CPU在解决所有的文件，其余的CPU都是闲暇的。如果HDFS中的block和文件大小差不多还好，一个文件、一个块、一个CPU。如果是一个很大的文件就会呈现问题了bzip2在压缩和解压缩数据方面实际上均匀比Gzip差3倍，这对性能是有肯定的影响的。如果咱们须要频繁地查问数据，数据压缩肯定会影响查问效率如果不关怀查问性能（没有任何SLA）并且很少抉择此数据，则bzip2可能是不错的抉择。最好是对本人的数据进行基准测试，而后再做决定。

一. 传统零碎常见文件存储格局在Windows有很多种文件格式，例如：JPEG文件用来存储图片、MP3文件用来存储音乐、DOC文件用来存储WORD文档。每一种文件存储某一类的数据，例如：咱们不会用文原本存储音乐、不会用文原本存储图片。windows上反对的存储格局是十分的多。 1. 文件系统块大小在服务器/电脑上，有多种块设施（Block Device），例如：硬盘、CDROM、软盘等等每个文件系统都须要将一个分区拆分为多个块，用来存储文件。不同的文件系统块大小不同2. Hadoop 中文件存储格局在Hadoop中，没有默认的文件格式，格局的抉择取决于其用处。而抉择一种优良、适宜的数据存储格局是十分重要的。应用HDFS的应用程序（例如MapReduce或Spark）性能中的最大问题、瓶颈是在特定地位查找数据的工夫和写入到另一个地位的工夫，而且治理大量数据的解决和存储也很简单（例如：数据的格局会一直变动，原来一行有12列，前面要存储20列）抉择适合的文件格式可能会带来一些显著的益处： 能够保障写入速度能够保障读取速度文件是可被切分的对压缩反对敌对反对schema的更改每种格局都有长处和毛病，数据处理的不同阶段能够应用不同的格局才会更有效率。通过抉择一种格局，最大水平地施展该存储格局的劣势，最小化劣势。 3. BigData File Viewer工具1. 介绍一个跨平台（Windows，MAC，Linux）桌面应用程序，用于查看常见的大数据二进制格局，例如Parquet，ORC，AVRO等。反对本地文件系统，HDFS，AWS S3等 github地址：https://github.com/Eugene-Mar...2. 性能介绍关上并查看本地目录中的Parquet，ORC和AVRO，HDFS，AWS S3等将二进制格局的数据转换为文本格式的数据，例如CSV反对简单的数据类型，例如数组，映射，构造等反对Windows，MAC和Linux等多种平台代码可扩大以波及其余数据格式4. Hadoop丰盛的存储格局1. Text File简介: 文本文件在非Hadoop畛域很常见，在Hadoop畛域也很常见。 数据一行一行到排列，每一行都是一条记录。以典型的UNIX形式以换行符【\n】终止,文本文件是能够被切分的，但如果对文本文件进行压缩，则必须应用反对切分文件的压缩编解码器，例如BZIP2。因为这些文件只是文本文件，压缩时会对所有内容进行编码。能够将每一行成为JSON文档，能够让数据带有构造利用场景: 仅在须要从Hadoop中间接提取数据，或间接从文件中加载大量数据的状况下，才倡议应用纯文本格式或CSV长处: 简略易读、轻量级毛病: 读写速度慢不反对块压缩，在Hadoop中对文本文件进行压缩/解压缩会有较高的读取老本，因为须要将整个文件全副压缩或者解压缩。不反对块压缩，在Hadoop中对文本文件进行压缩/解压缩会有较高的读取老本，因为须要将整个文件全副压缩或者解压缩。2. Sequence File简介Sequence最后是为MapReduce设计的，因而和MapReduce集成很好,在Sequence File中，每个数据都是以一个key和一个value进行序列化存储,Sequence File中的数据是以二进制格局存储，这种格局所需的存储空间小于文本的格局。与文本文件一样，Sequence File外部也不反对对键和值的构造指定格局编码利用场景通常把Sequence file作为两头数据存储格局。例如：将大量小文件合并放入到一个SequenceFIle中构造长处: 与文本文件相比更紧凑，反对块级压缩 压缩文件内容的同时,反对将文件切分序列文件在Hadoop和许多其余反对HDFS的我的项目反对很好，例如：Spark它是让咱们解脱文本文件迈出第一步它能够作为大量小文件的容器毛病: 对具备SQL类型的Hive反对不好，须要读取和解压缩所有字段不存储元数据，并且对schema扩大中的惟一形式是在开端增加新字段3. Avro File简介Apache Avro是与语言无关的序列化零碎，由Hadoop创始人 Doug Cutting开发,vro是基于行的存储格局，它在每个文件中都蕴含JSON格局的schema定义，从而进步了互操作性并容许schema的变动（删除列、增加列）。 除了反对可切分，反对压缩,Avro是一种自描述格局，它将数据的schema间接编码存储在文件中，能够用来存储简单构造的数据。Avro能够进行疾速序列化，生成的序列化数据也比拟小利用场景 适宜于一次性须要将大量的列（数据比拟宽）、写入频繁的场景,随着更多存储格局的倒退，罕用于Kafka和Druid中构造 间接将一行数据序列化在一个block中长处: 如果只须要对数据文件中的多数列进行操作，行式存储效率较低,例如：咱们读取15列中的2列数据，基于行式存储就须要读取数百万行的15列。而列式存储就会比行式存储形式高效列式存储因为是将同一列（类）的数据存储在一起，压缩率要比形式存储高4. RCFile简介: RCFile是为基于MapReduce的数据仓库零碎设计的数据存储构造。它联合了行存储和列存储的长处，能够满足疾速数据加载和查问，无效利用存储空间以及适应高负载的需要。RCFile是由二进制键/值对组成的flat文件，它与sequence file有很多相似之处,在数仓中执行剖析时，这种面向列的存储十分有用。当咱们应用面向列的存储类型时，执行剖析很容易利用场景罕用在Hive中构造 RCFile可将数据分为几组行，并且在其中将数据存储在列中RCFile首先将行程度划分为行拆分（Row Group），而后以列形式垂直划分每个行拆分（Columns）。RCFile将行拆分的元数据存储为record的key，并将行拆分的所有数据存储value作为行存储，RCFile保障同一行中的数据位于同一节点中作为列存储，RCFile能够利用列数据压缩，并跳过不必要的列读取长处 基于列式的存储，更好的压缩比利用元数据存储来反对数据类型反对Split毛病: RC不反对schema扩大，如果要增加新的列，则必须重写文件，这会升高操作效率5. ORC File简介Apache ORC（Optimized Row Columnar，优化行列）是Apache Hadoop生态系统面向列的开源数据存储格局，它与Hadoop环境中的大多数计算框架兼容,ORC代表“优化行列”，它以比RC更为优化的形式存储数据，提供了一种十分无效的形式来存储关系数据，而后存储RC文件。ORC将原始数据的大小最多缩小75％，数据处理的速度也进步了利用场景罕用在Hive中构造长处'比TextFile,Sequence File 和 RCFile 具备更好的性能列数据独自存储带类型的数据存储格局,应用类型专用的编码器轻量级索引毛病 与RC文件一样，ORC也是不反对列扩大的 6. Parquet File简介Parquet File是另一种列式存储的构造，来自于Hadoop的创始人Doug Cutting的Trevni我的项目,基于列的二进制存储格局，能够存储嵌套的数据结构,当指定要应用列进行操作时，磁盘输出/输入操效率很高,Parquet与Cloudera Impala兼容很好，并做了大量优化,反对块压缩,与RC和ORC文件不同，Parquet serdes反对无限的schema扩大。在Parquet中，能够在构造的开端增加新列 ...

一. HDFS简介HDFS（Hadoop Distributed File System）是 Apache Hadoop 我的项目的一个子项目，它的设计初衷是为了可能反对高吞吐和超大文件读写操作HDFS是一种可能在一般硬件上运行的分布式文件系统，它是高度容错的，适应于具备大数据集的应用程序，它十分适于存储大型数据 (比方 TB 和 PB)HDFS应用多台计算机存储文件, 并且提供对立的拜访接口, 像是拜访一个一般文件系统一样应用分布式文件系统二. HDFS倒退历史Doug Cutting 在做 Lucene 的时候, 须要编写一个爬虫服务, 这个爬虫写的并不顺利, 遇到 了一些问题, 诸如: 如何存储大规模的数据, 如何保障集群的可伸缩性, 如何动静容错等2013年的时候, Google 公布了三篇论文, 被称作为三驾马车, 其中有一篇叫做 GFSGFS是形容了 Google 外部的一个叫做 GFS 的分布式大规模文件系统, 具备弱小的可伸缩性和容错Doug Cutting起初依据 GFS 的论文, 发明了一个新的文件系统, 叫做 HDFS三.HDFS设计指标HDFS集群由很多的服务器组成，而每一个机器都与可能会呈现故障。HDFS为了可能进行故障检测、疾速复原等。HDFS次要适宜去做批量数据进去，绝对于数据申请时的反应时间，HDFS更偏向于保障吞吐量。典型的HDFS中的文件大小是GB到TB，HDFS比拟适宜存储大文件HDFS很多时候是以： Write-One-Read-Many来利用的，一旦在HDFS创立一个文件，写入完后就不须要批改了四.HDFS利用场景1. 适宜的利用场景存储十分大的文件：这里十分大指的是几百M、G、或者TB级别，须要高吞吐量，对延时没有要求基于流的数据拜访形式: 即一次写入、屡次读取，数据集常常从数据源生成或者拷贝一次，而后在其上做很多剖析工作 ，且不反对文件的随机批改。正因为如此，HDFS适宜用来做大数据分析的底层存储服务，并不适宜用来做网盘等利用，因为，批改不不便，提早大，网络开销大，老本太高。运行于商业硬件上: Hadoop不须要特地贵的机器，可运行于一般便宜机器，能够处节约老本须要高容错性为数据存储提供所需的扩大能力2. 不适宜的利用场景低延时的数据拜访不适宜采纳HDFS。HDFS是为高吞吐数据传输设计的,因而可能就义延时大量小文件:小文件的元数据保留在NameNode的内存中， 整个文件系统的文件数量会受限于NameNode的内存大小。 教训而言，一个文件/目录/文件块个别占有150字节的元数据内存空间。如果有100万个文件，每个文件占用1个文件块，则须要大概300M的内存。因而十亿级别的文件数量在现有商用机器上难以反对多方读写，须要任意的文件批改 HDFS采纳追加（append-only）的形式写入数据。不反对文件任意offset的批改，HDFS适宜用来做大数据分析的底层存储服务，并不适宜用来做.网盘等利用，因为，批改不不便，提早大，网络开销大，老本太高。五.HDFS重要个性1. 主从架构HDFS采纳master/slave架构。个别一个HDFS集群是有一个Namenode和肯定数目的Datanode组成。Namenode是HDFS主节点，Datanode是HDFS从节点，两种角色各司其职，独特协调实现分布式的文件存储服务。 2.分块机制HDFS中的文件在物理上是分块存储（block）的，块的大小能够通过配置参数来规定，参数位于hdfs-default.xml中：dfs.blocksize。默认大小是128M（134217728） 3.正本机制为了容错，文件的所有block都会有正本。每个文件的block大小（dfs.blocksize）和正本系数（dfs.replication）都是可配置的。应用程序能够指定某个文件的正本数目。正本系数能够在文件创建的时候指定，也能够在之后通过命令扭转。默认dfs.replication的值是3，也就是会额定再复制2份，连同自身总共3份正本。 4.NamespaceHDFS反对传统的档次型文件组织构造。用户能够创立目录，而后将文件保留在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统相似：用户能够创立、删除、挪动或重命名文件。Namenode负责保护文件系统的namespace名称空间，任何对文件系统名称空间或属性的批改都将被Namenode记录下来。HDFS会给客户端提供一个对立的形象目录树，客户端通过门路来拜访文件，形如：hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。 5.元数据管理在HDFS中，Namenode治理的元数据具备两种类型： 文件本身属性信息文件名称、权限，批改工夫，文件大小，复制因子，数据块大小。文件块地位映射信息记录文件和DataNode之间的映射信息,即哪个块位于哪个节点上 6.数据块存储文件的各个block的具体存储管理由DataNode节点承当。每一个block都能够在多个DataNode上存储。 六.微博HDFS 案例1. 背景微博有大量的用户数据，为了剖析微博用户的行为。咱们能够将微博的数据上传到HDFS，而后供其余大规模文本、情感分析程序来解决。 2. HDFS目录布局以后咱们的HDFS集群中应该是空洞无物。因为咱们并没有做任何的文件操作。为了不便咱们未来治理文件系统，咱们也对HDFS须要有一个目录布局，就像Linux一样。 目录阐明/source用于存储原始采集数据/common用于存储公共数据集,例如:IP库,省份信息等/workspace工作空间,存储各团队计算出来的后果数据/tem存储长期数据,须要定时清理/warehouse存储hive数据仓库中的数据3. HDFS操作-shell客户端HDFS是存取数据的分布式文件系统，那么对HDFS的操作，就是文件系统的基本操作，比方文件的创立、批改、删除、批改权限等，文件夹的创立、删除、重命名等。对HDFS的操作命令相似于Linux的shell对文件的操作，如ls、mkdir、rm等。 1.语法格局Hadoop提供了文件系统的shell命令行客户端，应用办法如下： Usage: hdfs [SHELL_OPTIONS] COMMAND [GENERIC_OPTIONS] [COMMAND_OPTIONS]选项: ...

一. Hadoop集群简介HADOOP集群具体来说蕴含两个集群：HDFS集群和YARN集群，两者逻辑上拆散，但物理上在一起。HDFS集群负责海量数据的存储，集群中的角色次要有：NameNode、DataNode、SecondaryNameNodeYARN集群负责海量数据运算时的资源调度，集群中的角色次要有：ResourceManager、NodeManagermapreduce 是一个分布式运算编程框架,是利用程序开发包,由用户依照编程标准进行程序开发,后打包运行在HDFS集群上，并且受到YARN集群的资源调度治理。 二 . 集群部署形式Hadoop部署形式分三种： 独立模式(standalone mode) 独立模式又称为单机模式，仅1个机器运行1个java过程，次要用于调试。 伪分布式模式(Pseudo-Distributed mode) 伪分布模式也是在1个机器上运行HDFS的NameNode和DataNode、YARN的 ResourceManger和NodeManager，但别离启动独自的java过程，次要用于调试。 群集模式(Cluster mode) 集群模式次要用于生产环境部署。会应用N台主机组成一个Hadoop集群。这种部署模式下，主节点和从节点会离开部署在不同的机器上 三 . Hadoop集群装置1. 集群布局以三台主机为例，以下是集群布局: 批改各服务器的主机名(三台) vim /etc/hostname将主机名批改为本人布局的主机名: Host 映射(3台)vim /etc/hosts 敞开防火墙systemctl stop firewalld.service #敞开防火墙systemctl disable firewalld.service #禁止防火墙开启自启ssh 免密登陆生成公钥和私钥ssh-keygen -t rsa （间接Enter）默认在 ~/.ssh目录生成两个文件：id_rsa ：私钥id_rsa.pub ：公钥 导入公钥到认证文件导入本机 cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys导入要免明码登录的服务器 scp ~/.ssh/id_rsa.pub xxx@host:/home/id_rsa.pub将公钥导入到认证文件(这一步的操作在服务器上进行) cat /home/id_rsa.pub >> ~/.ssh/authorized_keys在服务器上更改权限: chmod 700 ~/.sshchmod 600 ~/.ssh/authorized_keys同步三台机器的工夫yum -y install ntpdatentpdate ntp4.aliyun.com2. 解压Hadoop安装包上传解压hadoop 3.1.4安装文件 解压tar -xvzf hadoop-3.1.4.tar.gz -C ../server# 在每个节点中创立用于存放数据的data目录# NameNode数据mkdir -p /export/server/hadoop-3.1.4/data/namenode# DataNode数据mkdir -p /export/server/hadoop-3.1.4/data/datanode3 . 筹备装置环境上传解压hadoop 3.1.4安装文件cd /export/softwarerz解压tar -xvzf hadoop-3.1.4.tar.gz -C ../server# 在每个节点中创立用于存放数据的data目录# NameNode数据mkdir -p /export/server/hadoop-3.1.4/data/namenode# DataNode数据mkdir -p /export/server/hadoop-3.1.4/data/datanode4. 编辑配置文件1. 配置NameNode（core-site.xml）cd /export/server/hadoop-3.1.4/etc/hadoopvim core-site.xml--------------------------------在第19行下增加以下内容：<property> <name>fs.defaultFS</name> <value>hdfs://node1.uuicom.cn:9820</value> <description>配置NameNode的URL</description></property>2. 配置HDFS门路（hdfs-site.xml）vim hdfs-site.xml--------------------------------<property> <name>dfs.namenode.name.dir</name> <value>/export/server/hadoop-3.1.4/data/namenode</value> <description>NameNode存储名称空间和事务日志的本地文件系统上的门路</description></property><property> <name>dfs.datanode.data.dir</name> <value>/export/server/hadoop-3.1.4/data/datanode</value> <description>DataNode存储名称空间和事务日志的本地文件系统上的门路</description></property>3. 配置YARN（yarn-site.xml）vim yarn-site.xml--------------------------------在第18行下增加以下内容：<property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property><property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>512</value> <description>为每个容器申请调配的最小内存限度资源管理器（512M）</description></property><property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>4096</value> <description>为每个容器申请调配的最大内存限度资源管理器（4G）</description></property><property> <name>yarn.nodemanager.vmem-pmem-ratio</name> <value>4</value> <description>虚拟内存比例，默认为2.1，此处设置为4倍</description></property>4. 配置MapReduce（mapred-site.xml）vim mapred-site.xml----------------------------------在第20行下增加以下内容：vim mapred-site.xml----------------------------------在第20行下增加以下内容：<property> <name>mapreduce.framework.name</name> <value>yarn</value> <description>执行MapReduce的形式：yarn/local</description></property><property> <name>yarn.app.mapreduce.am.env</name> <value>HADOOP_MAPRED_HOME=${HADOOP_HOME}</value></property><property> <name>mapreduce.map.env</name> <value>HADOOP_MAPRED_HOME=${HADOOP_HOME}</value></property><property> <name>mapreduce.reduce.env</name> <value>HADOOP_MAPRED_HOME=${HADOOP_HOME}</value></property>5. workers文件vim /export/server/hadoop-3.1.4/etc/hadoop/workers----------------------------------# 删除第一行localhost，而后增加以下三行node1.uuicon.cnnode2.uuicon.cnnode3.uuicon.cn6.批改hadoop.env环境变量hadoop.env文件vim /export/server/hadoop-3.1.4/etc/hadoop/hadoop-env.sh 批改第54行为：export JAVA_HOME=/export/server/jdk1.8.0_2417. 配置环境变量vim /etc/profileexport HADOOP_HOME=/export/server/hadoop-3.1.4export PATH=$PATH:${HADOOP_HOME}/bin:${HADOOP_HOME}/sbin:source /etc/profile

一. 为什么要编译hadoop因为appache给出的hadoop的安装包没有提供带C程序拜访的接口，所以咱们在应用本地库（本地库能够用来做压缩，以及反对C程序等等）的时候就会出问题,须要对Hadoop源码包进行从新编译 二. 下载Hadoop源码hadoop官网下载抉择须要下载的版本,抉择 Source download 下载源码 三. linux 编译装置1. 在linux创立长期寄存源码文件夹mkdir export/server2.装置编译相干依赖1、yum install gcc gcc-c++2、yum install autoconf automake libtool curl3、yum install lzo-devel zlib-devel openssl openssl-devel ncurses-devel4、yum install snappy snappy-devel bzip2 bzip2-devel lzo lzo-devel lzop libXtst3.手动装置cmake官网下载下载cmake,下载完后将安装包传到linux中新建的目录 export/server下 #解压tar zxvf cmake-3.13.5.tar.gz#编译装置cd /export/server/cmake-3.13.5./configuremake && make install#验证[root@node4 ~]# cmake -version cmake version 3.13.54. 手动装置snappy下载地址 #卸载曾经装置的cd /usr/local/librm -rf libsnappy*#上传解压tar zxvf snappy-1.1.3.tar.gz #编译装置cd /export/server/snappy-1.1.3./configuremake && make install#验证是否装置[root@node4 snappy-1.1.3]# ls -lh /usr/local/lib |grep snappy-rw-r--r-- 1 root root 511K Nov 4 17:13 libsnappy.a-rwxr-xr-x 1 root root 955 Nov 4 17:13 libsnappy.lalrwxrwxrwx 1 root root 18 Nov 4 17:13 libsnappy.so -> libsnappy.so.1.3.0lrwxrwxrwx 1 root root 18 Nov 4 17:13 libsnappy.so.1 -> libsnappy.so.1.3.0-rwxr-xr-x 1 root root 253K Nov 4 17:13 libsnappy.so.1.3.05.装置配置JDK下载地址 ...

一.hadoop 简介Apache Hadoop是一款反对数据密集型分布式应用程序并以Apache 2.0许可协定公布的开源软件框架。它反对在商用硬件构建的大型集群上运行的应用程序。Hadoop是依据谷歌公司发表的MapReduce和Google文件系统的论文自行实现而成。所有的Hadoop模块都有一个根本假如，即硬件故障是常见状况，应该由框架主动解决。外围组件有： HDFS（分布式文件系统）：解决海量数据存储YARN（作业调度和集群资源管理的框架）：解决资源任务调度MAPREDUCE（分布式运算编程框架）：解决海量数据计算狭义上来说，Hadoop通常是指一个更宽泛的概念——Hadoop生态圈。hadoop次要框架: 框架用处HDFS文件散布零碎MapReduce分布式运算Zookeeper分布式协调服务根底组件HIVE基于Hadoop的分布式数据仓库FLUME日志数据采集框架oozie流程调度框架Sqoop数据导入导出工具Impala基于Hive的实时SQL查问剖析Mahout分布式框架机器学习算法库Hadoop 倒退:Hadoop是Apache Lucene创始人 Doug Cutting 创立的。最早起源于Nutch，它是Lucene的子项目。Nutch的设计指标是构建一个大型的全网搜索引擎，包含网页抓取、索引、查问等性能，但随着抓取网页数量的减少，遇到了重大的可扩展性问题：如何解决数十亿网页的存储和索引问题。2003年Google发表了一篇论文为该问题提供了可行的解决方案。论文中形容的是谷歌的产品架构，该架构称为：谷歌分布式文件系统（GFS）,能够解决他们在网页爬取和索引过程中产生的超大文件的存储需要。2004年 Google发表论文向全世界介绍了谷歌版的MapReduce零碎。同期间，以谷歌的论文为根底，Nutch的开发人员实现了相应的开源实现HDFS和MAPREDUCE，并从Nutch中剥离成为独立我的项目HADOOP，到2008年1月，HADOOP成为Apache顶级我的项目，迎来了它的疾速发展期。2006年Google发表了论文是对于BigTable的，这促使了起初的Hbase的倒退。因而，Hadoop及其生态圈的倒退离不开Google的奉献。 Hadoop个性长处: 扩容能力:Hadoop是在可用的计算机集群间调配数据并实现计算工作的，这些集群可用不便的扩大到数以千计的节点中。绝对成本低:Hadoop通过一般便宜的机器组成服务器集群来散发以及解决数据，以至于老本很低。高效率:通过并发数据，Hadoop能够在节点之间动静并行的挪动数据，使得速度十分快。可靠性:能主动保护数据的多份复制，并且在工作失败后能主动地重新部署（redeploy）计算工作。所以Hadoop的按位存储和解决数据的能力值得人们信赖。Hadoop架构:Hadoop 3.x的版本架构和模型介绍 因为Hadoop 2.0是基于JDK 1.7开发的，而JDK 1.7在2015年4月已进行更新，这间接迫使Hadoop社区基于JDK 1.8从新公布一个新的Hadoop版本，即hadoop 3.0。Hadoop 3.0中引入了一些重要的性能和优化，包含HDFS 可擦除编码、多Namenode反对、MR Native Task优化、YARN基于cgroup的内存和磁盘IO隔离、YARN container resizing等。Apache hadoop 项目组最新消息，hadoop3.x当前将会调整计划架构，将Mapreduce 基于内存+io+磁盘，独特解决数据。扭转最大的是hdfs,hdfs 通过最近block块计算，依据最近计算准则，本地block块，退出到内存，先计算，通过IO，共享内存计算区域，最初疾速造成计算结果，比Spark快10倍。Hadoop 3.0新个性: 通用性: 精简Hadoop内核，包含剔除过期的API和实现，将默认组件实现替换成最高效的实现。Classpath isolation：以避免不同版本jar包抵触Shell脚本重构： Hadoop 3.0对Hadoop的治理脚本进行了重构，修复了大量bug，减少了新个性HDFSHadoop3.x中Hdfs在可靠性和反对能力上作出很大改观 HDFS反对数据的擦除编码，这使得HDFS在不升高可靠性的前提下，节俭一半存储空间多NameNode反对，即反对一个集群中，一个active、多个standby namenode部署形式。注：多ResourceManager个性在hadoop 2.0中曾经反对HDFS纠删码在Hadoop3.X中，HDFS实现了Erasure Coding这个新性能。Erasure coding纠删码技术简称EC，是一种数据保护技术.最早用于通信行业中数据传输中的数据恢复，是一种编码容错技术.它通过在原始数据中退出新的校验数据，使得各个局部的数据产生关联性。在肯定范畴的数据出错状况下，通过纠删码技术都能够进行复原。hadoop-3.0之前，HDFS存储形式为每一份数据存储3份，这也使得存储利用率仅为1/3，hadoop-3.0引入纠删码技术(EC技术)，实现1份数据+0.5份冗余校验数据存储形式。与正本相比纠删码是一种更节俭空间的数据长久化存储办法。规范编码(比方Reed-Solomon(10,4))会有1.4 倍的空间开销；然而HDFS正本则会有3倍的空间开销。反对多个NameNodes最后的HDFS NameNode high-availability实现仅仅提供了一个active NameNode和一个Standby NameNode；并且通过将编辑日志复制到三个JournalNodes上，这种架构可能容忍零碎中的任何一个节点的失败。然而，一些部署须要更高的容错度。咱们能够通过这个新个性来实现，其容许用户运行多个Standby NameNode。比方通过配置三个NameNode和五个JournalNodes，这个零碎能够容忍2个节点的故障，而不是仅仅一个节点。 MapReduceHadoop3.X中的MapReduce较之前的版本作出以下更改： Tasknative优化：为MapReduce减少了C/C++的map output collector实现（包含Spill，Sort和IFile等），通过作业级别参数调整就可切换到该实现上。对于shuffle密集型利用，其性能可进步约30%。Hadoop3.0中通过内存参数主动推断,防止设置内存参数繁琐,设置不当造成资源重大节约的状况,将会晋升30%以上的性能其余默认端口批改: 在hadoop3.x之前，多个Hadoop服务的默认端口都属于Linux的长期端口范畴（32768-61000）。这就意味着用户的服务在启动的时候可能因为和其余应用程序产生端口抵触而无奈启动当初这些可能会产生抵触的端口曾经不再属于长期端口的范畴，这些端口的扭转会影响NameNode, Secondary NameNode, DataNode以及KMS。与此同时，官网文档也进行了相应的扭转YARN 资源类型 比方集群管理员能够定义诸如 GPUs、软件许可证（software licenses）或本地附加存储器（locally-attached storage）之类的资源。YARN 工作能够依据这些资源的可用性进行调度。

download：Hadoop 零碎入门+外围精讲package com.zzger.model; import java.util.ArrayList;import java.util.Collections;import java.util.List;import java.util.concurrent.CountDownLatch; import com.zzger.module.queue.UrlQueue;import com.zzger.util.HttpUtils;import com.zzger.util.RegexUtils; public class WebSite { /** * 站点url */private String url; /** * 需要爬行的url队列 */private UrlQueue urls = new UrlQueue<>(); /** * 已爬行过的页面url */private List exitUrls = Collections.synchronizedList(new ArrayList<>()); private static final int TOTAL_THREADS = 12; private final CountDownLatch mStartSignal = new CountDownLatch(1); private final CountDownLatch mDoneSignal = new CountDownLatch(TOTAL_THREADS); public WebSite(String url){ this.url = url; urls.offer(url);//把网站首页加入需要爬行的队列中} public void guangDu(){ new Thread(new Runnable() { @Override public void run() { paxing(HttpUtils.httpGet(url)); } }).start();} public void paxing(String html){ if(html.lastIndexOf("下一页")<0) return ; ...

摘要：Hadoop Streaming 应用 MapReduce 框架，该框架可用于编写应用程序来解决海量数据。本文分享自华为云社区《Hadoop Streaming：用 Python 编写 Hadoop MapReduce 程序》，作者：Donglian Lin。 随着数字媒体、物联网等倒退的呈现，每天产生的数字数据量呈指数级增长。这种状况给创立下一代工具和技术来存储和操作这些数据带来了挑战。这就是 Hadoop Streaming 的用武之地！上面给出的图表描述了从2013年起寰球每年产生的数据增长状况。IDC预计，到 2025年，每年产生的数据量将达到180 Zettabytes！ IBM 示意，每天有近 2.5 千万字节的数据被创立，其中 90% 的世界数据是在过来两年中创立的！存储如此宏大的数据量是一项具备挑战性的工作。Hadoop 能够比传统的企业数据仓库更无效地解决大量结构化和非结构化数据。它跨分布式计算机集群存储这些宏大的数据集。Hadoop Streaming 应用 MapReduce 框架，该框架可用于编写应用程序来解决海量数据。 因为 MapReduce 框架基于 Java，您可能想晓得如果开发人员没有 Java 教训，他/她如何工作。好吧，开发人员能够应用他们喜爱的语言编写 mapper/Reducer 应用程序，而无需把握太多 Java 常识，应用Hadoop Streaming而不是切换到 Pig 和 Hive 等新工具或技术。 什么是 Hadoop 流？Hadoop Streaming 是 Hadoop 发行版附带的实用程序。它可用于执行大数据分析程序。Hadoop 流能够应用 Python、Java、PHP、Scala、Perl、UNIX 等语言执行。该实用程序容许咱们应用任何可执行文件或脚本作为映射器和/或化简器来创立和运行 Map/Reduce 作业。例如： $HADOOP_HOME/bin/hadoop jar $HADOOP_HOME/hadoop-streaming.jar-input myInputDirs-输入我的输入目录-文件夹/垃圾箱/猫-减速器/bin/wc参数阐明： Python MapReduce 代码：mapper.py#!/usr/bin/pythonimport sys#Word Count Example# input comes from standard input STDINfor line in sys.stdin:line = line.strip() #remove leading and trailing whitespaceswords = line.split() #split the line into words and returns as a listfor word in words:#write the results to standard output STDOUTprint'%s %s' % (word,1) #Emit the word ...

简介： B 站抉择 Flink + Hudi 的数据湖技术计划，以及针对其做出的优化。本文作者喻兆靖，介绍了为什么 B 站抉择 Flink + Hudi 的数据湖技术计划，以及针对其做出的优化。次要内容为： 传统离线数仓痛点数据湖技术计划Hudi 工作稳定性保障数据入湖实际增量数据湖平台收益社区奉献将来的倒退与思考 一、传统离线数仓痛点1. 痛点之前 B 站数仓的入仓流程大抵如下所示： 在这种架构下产生了以下几个外围痛点： 大规模的数据落地 HDFS 后，只能在凌晨分区归档后能力查问并做下一步解决；数据量较大的 RDS 数据同步，须要在凌晨分区归档后能力解决，并且须要做排序、去重以及 join 前一天分区的数据，能力产生出当天的数据；仅能通过分区粒度读取数据，在分流等场景下会呈现大量的冗余 IO。总结一下就是: 调度启动晚；合并速度慢；反复读取多。2. 痛点思考调度启动晚思路：既然 Flink 落 ODS 是准实时写入的，有明确的文件增量概念，能够应用基于文件的增量同 步，将荡涤、补维、分流等逻辑通过增量的形式进行解决，这样就能够在 ODS 分区未归档的时 候就解决数据，实践上数据的提早只取决于最初一批文件的解决工夫。 合并速度慢思路：既然读取曾经能够做到增量化了，那么合并也能够做到增量化，能够通过数据湖的能力结 合增量读取实现合并的增量化。 反复读取多思路：反复读取多的次要起因是分区的粒度太粗了，只能准确到小时/天级别。咱们须要尝试一 些更加细粒度的数据组织计划，将 Data Skipping 能够做到字段级别，这样就能够进行高效的数 据查问了。 3. 解决方案: Magneto - 基于 Hudi 的增量数据湖平台以下是基于 Magneto 构建的入仓流程： Flow应用流式 Flow 的形式，对立离线和实时的 ETL Pipline Organizer数据重组织，减速查问反对增量数据的 compaction Engine计算层应用 Flink，存储层应用 Hudi Metadata提炼表计算 SQL 逻辑标准化 Table Format 计算范式 ...

一、装置VM二、装置centos8.4三、装置hadoop1.创立用户①切换root用户 su②减少用户 useradd -m hadoop -s /bin/bash③明码 passwd hadoop④为用户减少管理员权限 vim /etc/sudoers 或者 visudo找到 root ALL=(ALL) ALL 这行，按i，进入插入模式，在这行上面减少一行内容hadoop ALL=(ALL) ALL，按ESC 键，而后输出":wq" ，再按回车退出编辑(空格为tab键)⑤后面减少管理员账号后，须要用sudo能力执行管理员权限，为了不便间接更改/opt/下文件的权限 chmod -R 777 /opt/ ⑥/opt/下创立文件夹用于贮存数据用于贮存软件 mkdir soft用于贮存数据 mkdir datas用于贮存hadoop等装置 mkdir modules2.SSH①查看是否装置SSH rpm -qa | grep ssh②[hadoop@my ~]$ cd ~/.ssh/[hadoop@my .ssh]$ ssh-keygen -t rsa始终按回车[hadoop@my .ssh]$ cat id_rsa.pub >> authorized_keys[hadoop@my .ssh]$ chmod 600 ./authorized_keys3.装置jdk①查问是否装置JAVA环境 rpm -qa | grep java②若有JAVA环境，则卸载 rpm -e --nodeps [各个JAVA]③将文件解压到目录 tar -zxvf jdk-7u80-linux-x64.tar.gz -C /opt/modules/ ④配置JVAV环境变量 vim /etc/profileexport JAVA_HOME=/opt/modules/jdk1.8.0_301export PATH=$PATH:$JAVA_HOME/bin强制刷新配置文件 source /etc/profile4.装置hadoop①解压文件 tar -zxvf hadoop-3.3.1.tar.gz -C /opt/modules/ ② 批改etc/hadoop/hadoop-env.shexport JAVA_HOME=/opt/modules/jdk1.8.0_301③创立文件目录 [hadoop@my hadoop-3.3.1]$ mkdir data[hadoop@my hadoop-3.3.1]$ cd data[hadoop@my data]$ mkdir tmp批改etc/hadoop/core-site.xml ...

依赖环境首先须要java反对这里下载1.8版本的jdk地址:https://blog.csdn.net/qq_2118...下载完解压，并且在环境变量里申明JAVA_HOME JAVA_HOME=/usr/local/java/jdk1.8.0_161iPATH=$PATH:$HOME/bin:$JAVA_HOME/bin:export JAVA_HOMEexport PATH保留后应用 source 命令使环境变量失效 下载hadoop文件https://mirrors.cnnic.cn/apac... 这里抉择2.10版本同java程序一样解压到想搁置的目录 执行 XXX(这里是解压完的目录地址)/bin/hadoop version能呈现版本号阐明解压正确了 进行单机版本的配置1./etc/hadoop下，须要批改2个配置文件core-site.xml和hdfs-site.xml。 这个是core-site.xml <configuration> <property> <name>hadoop.tmp.dir</name> <value>/usr/local/hadoop/tmp</value> <description>Abase for other temporary directories.</description> </property> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property></configuration>这个是hdfs-site.xml <configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/usr/local/hadoop/tmp/dfs/name</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/usr/local/hadoop/tmp/dfs/data</value> </property></configuration>注:dfs.replication就是指备份的份数；dfs.namenode.name.dir和dfs.datanode.data.dir别离指名称节点和数据节点存储门路 2.执行初始化 回到Hadoop主目录，执行 ./bin/hdfs namenode -format 初始化完结最初这样证实胜利了 18/08/20 11:07:16 INFO namenode.NNStorageRetentionManager: Going to retain 1 images with txid >= 018/08/20 11:07:16 INFO namenode.NameNode: SHUTDOWN_MSG:/************************************************************SHUTDOWN_MSG: Shutting down NameNode at phenix/127.0.1.1************************************************************/3.手动增加JAVA_HOME 在 XXX/etc/hadoop/hadoop-env.sh 这个文件里配置JAVA_HOME门路 ...

简介： 本文作者关涛是大数据系统畛域的资深专家，在微软（互联网/Azure云事业群）和阿里巴巴（阿里云）经验了大数据倒退20年过程中的后15年。本文试从零碎架构的角度，就大数据架构热点，每条技术线的倒退脉络，以及技术趋势和未解问题等方面做一概述。作者 | 阿里云计算平台研究员关涛、阿里巴巴项目管理专家王璀 任何一种技术都会经验从下里巴人到下里巴人的过程，就像咱们对计算机的了解从“戴着鞋套能力进的机房”变成了随处可见的智能手机。在后面20年中，大数据技术也经验了这样的过程，从已经居高临下的 “火箭科技（rocket science）”，成为了人人普惠的技术。 回首来看，大数据倒退初期涌现了十分多开源和自研零碎，并在同一个畛域开展了相当长的一段“红海”竞争期，例如Yarn VS Mesos、Hive VS Spark、Flink VS SparkStreaming VS Apex、Impala VS Presto VS Clickhouse等等。经验强烈竞争和淘汰后，胜出的产品逐步规模化，并开始占领市场和开发者。 事实上，近几年，大数据畛域曾经没有再诞生新的明星开源引擎（Clickhouse@2016年开源，PyTorch@2018年开源），以Apache Mesos等我的项目进行保护为代表，大数据畛域进入“后红海”时代：技术开始逐渐收敛，进入技术普惠和业务大规模利用的阶段。 本文作者关涛是大数据系统畛域的资深专家，在微软（互联网/Azure云事业群）和阿里巴巴（阿里云）经验了大数据倒退20年过程中的后15年。本文试从零碎架构的角度，就大数据架构热点，每条技术线的倒退脉络，以及技术趋势和未解问题等方面做一概述。 值得一提的是，大数据畛域依然处于发展期，局部技术收敛，但新方向和新畛域层出不穷。本文内容和个人经历相干，是集体的视角，不免有缺失或者偏颇，同时限于篇幅，也很难全面。仅作抛砖引玉，心愿和同业独特探讨。 一、当下的大数据体系热点BigData概念在上世纪90年代被提出，随Google的3篇经典论文（GFS，BigTable，MapReduce）奠基，曾经倒退了将近20年。这20年中，诞生了包含Google大数据体系，微软Cosmos体系，阿里云的飞天零碎，开源Hadoop体系等优良的零碎。这些零碎一步步推动业界进入“数字化“和之后的“AI化”的时代。 海量的数据以及其蕴含的价值，吸引了大量投入，极大的推动大数据畛域技术。云（Cloud）的衰亡又使得大数据技术对于中小企业唾手可得。能够说，大数据技术倒退正过后。 从体系架构的角度看，“Shared-Everything”架构演进、湖仓技术的一体化交融、云原生带来的根底设计降级、以及更好的AI反对，是当下平台技术的四个热点。 1.1 零碎架构角度，平台整体向Shared-Everything架构演进泛数据畛域的零碎架构，从传统数据库的Scale-up向大数据的Scale-out倒退。从分布式系统的角度，整体架构能够依照Shared-Nothing（也称MPP）, Shared-Data, Shared-Everything 三种架构。 大数据平台的数仓体系最后由数据库倒退而来，Shared-Nothing（也称MPP）架构在很长一段时间成为支流。随云原生能力加强，Snowflake为代表的Shared-Data逐步倒退起来。而基于DFS和MapReduce原理的大数据体系，设计之初就是Shared-Everything架构。 Shared-Everything架构代表是GoogleBigQuery和阿里云MaxCompute。从架构角度，Shared-Everything架构具备更好的灵活性和后劲，会是将来倒退的方向。 （图：三种大数据体系架构） 1.2 数据管理角度，数据湖与数据仓库交融，造成湖仓一体数据仓库的高性能与治理能力，与数据湖的灵活性，仓和湖的两套体系在互相借鉴与交融。在2020年各个厂商别离提出湖仓一体架构，成为当下架构演进最热的趋势。但湖仓一体架构有多种状态，不同状态尚在演进和争执中。 (图：数据湖与数据仓库借鉴交融) 1.3 云架构角度，云原生与托管化成为支流随着大数据平台技术进入深水区，用户也开始分流，越来越多的中小用户不再自研或自建数据平台，开始拥抱全托管型（通常也是云原生）的数据产品。Snowflake作为这一畛域的典型产品，失去广泛认可。面向未来，后续仅会有大量超大规模头部公司采纳自建（开源+改良）的模式。 (图：snowflake的云原生架构） 1.4 计算模式角度，AI逐步成为支流，造成BI+AI双模式BI作为统计分析类计算，次要是面向过来的总结；AI类计算则具备越来越好的预测将来的能力。在过来五年中，算法类的负载从不到数据中心总容量的5%，晋升到30%。AI曾经成为大数据畛域的一等公民。 二、大数据体系的畛域架构在前文(#1.1)介绍的Shared-Nothing、Shared-Data、Shared-Everything 三种架构中，笔者经验过的两套体系（微软Cosmos/Scope体系，和阿里云MaxCompute）均为Shared-Everything架构，因而笔者次要从Shared-Everything架构角度，将大数据畛域分成6个叠加的子畛域、3个横向畛域，共9个畛域，具体如下图。 (图：基于 Shared-Everything 大数据体系下的畛域架构) 通过多年的倒退，每个畛域都有肯定的停顿和积淀，上面各个章节将概述每个子畛域的演进历史、背地驱动力、以及倒退方向。 2.1 分布式存储向多层智能化演进分布式存储，本文特指通用大数据海量分布式存储，是个典型的带状态（Stateful）分布式系统，高吞吐、低成本、容灾、高可用是外围优化方向。（注：下述分代仅为了论述不便，不代表严格的架构演进。） 第一代，分布式存储的典型代表是谷歌的GFS和Apache Hadoop的HDFS，均为反对多备份的Append-only文件系统。因HDFS晚期NameNode在扩展性和容灾方面的短板不能充沛满足用户对数据高可用的要求，很多大型公司都有自研的存储系统，如微软的Cosmos（起初演进成Azure Blob Storage），以及阿里巴巴的Pangu零碎。HDFS作为开源存储的奠基，其接口成为事实标准，同时HDFS又具备反对其余零碎作为背地存储系统的插件化能力。 第二代，基于上述底盘，随海量对象存储需要激增（例如海量的照片），通用的Append-only文件系统之上，封装一层反对海量小对象的元数据服务层，造成对象存储（Object-based Storage），典型的代表包含AWS S3，阿里云OSS。值得一提的是，S3与OSS均可作为规范插件，成为HDFS的事实存储后端。 第三代，以数据湖为代表。随云计算技术的倒退，以及（2015年之后）网络技术的提高，存储计算一体的架构逐步被云原生存储（存储托管化）+ 存储计算拆散的新架构取代。这也是数据湖体系的终点。同时因存储计算拆散带来的带宽性能问题并未齐全解决，在这个细分畛域诞生了Alluxio等缓存服务。 第四代，也是当下的趋势，随存储云托管化，底层实现对用户通明，因而存储系统有机会向更简单的设计方向倒退，从而开始向多层一体化存储系统演进。由繁多的基于SATA磁盘的零碎，向Mem/SSD+SATA (3X备份)+SATA (1.375X为代表的EC备份)+冰存储（典型代表AWS Glacier）等多层零碎演进。 如何智能/通明的将数据存储分层，找到老本与性能的Trade-off，是多层存储系统的要害挑战。这畛域起步不久，开源畛域没有显著好的产品，最好的程度由几个大厂的自研数仓存储系统引领。 (图：阿里巴巴 MaxCompute 的多层一体化存储体系) 在上述零碎之上，有一层文件存储格局层（File Format layer），与存储系统自身正交。 ...

一、HDFS 简介HDFS（Hadoop Distributed File System）是Hadoop 我的项目的外围子项目，在大数据开发中通过分布式计算对海量数据进行存储与治理。 HDFS 是一个典型的主/从架构的分布式系统。一个HDFS 集群由一个元数据节点（NameNode）和一些数据节点（DataNode）组成。 举个例子，咱们能够把NameNode 设想成一个仓库管理员，治理仓库中的商品；DataNode 设想成是一个仓库，用于存储商品，而商品就是咱们所说的数据。 HDFS 命令行操作命令行接口如下： $ bin/hadoop fs -命令 文件 门路或者 $ bin/hdfs dfs -命令 文件门路ls应用ls命令能够查看HDFS零碎中的目录和文件。 $ hadoop fs -ls /操作演示： [root@centos01 ~]# hadoop fs -ls /Found 2 itemsdrwxr-xr-x - hadoop supergroup 0 2021-07-10 08:58 /inputdrwx------ - hadoop supergroup 0 2021-07-10 08:38 /tmp递归列出HDFS 文件系统根目录下的所有目录和文件： [root@centos01 ~]# hadoop fs -ls -R /drwxr-xr-x - hadoop supergroup 0 2021-07-10 08:58 /input-rw-r--r-- 2 hadoop supergroup 83 2021-07-10 08:58 /input/wc.txtdrwx------ - hadoop supergroup 0 2021-07-10 08:38 /tmpdrwx------ - hadoop supergroup 0 2021-07-10 08:38 /tmp/hadoop-yarndrwx------ - hadoop supergroup 0 2021-07-10 08:38 /tmp/hadoop-yarn/stagingdrwx------ - hadoop supergroup 0 2021-07-10 08:38 /tmp/hadoop-yarn/staging/hadoopdrwx------ - hadoop supergroup 0 2021-07-10 08:49 /tmp/hadoop-yarn/staging/hadoop/.stagingput应用put 命令能够将本地文件上传到HDFS零碎中。如将本地文件a.txt 上传到 HDFS 文件系统根目录 input 文件夹中，命令如下： ...

HadoopHadoop - 集群装置Hadoop - 集群装置（高可用） HDFSHDFS - 文件越来越多怎么办HDFS - HDFS的四个角色HDFS - NameNode的高可用HDFS - 平安模式是什么HDFS - NameNode如何感知到DataNode的HDFS - 什么是元数据HDFS - 双缓冲机制如何保障对元数据的高并发申请HDFS - CheckPoint机制是怎么实现的HDFS - 写数据的那些事 HDFS源码思维导图NameNode启动DataNode启动元数据管理-客户端元数据管理-服务端元数据管理-standby读取Journalnode数据元数据管理-checkpoint写数据流程-create写数据流程-write写数据流程-队列解决写数据流程-DataNode解决

之前也提过，客户端须要写数据的时候，就会跟NameNode说他筹备把文件上传到某个目录，NameNode就会开始进行元数据的更新。因为元数据的更新是十分重要的，所以客户端会在肯定条件内重试，直至胜利。元数据更新胜利后，Client就会创立两个队列，一个是dataQueue，一个是ackQueue。这两个队列的作用下文会讲。客户端写入的时候，是一个个chunk写的，每一个chunk的大小是512byte，chunk的校验和chunksum是4byte，这个校验和是对块的内容进行校验用的，所以每写入一个chunk的大小就是516byte。这些chunk写满后，就会寄存在一个叫做packet的东东外面，这个packet有64k的大小，所以就是65535byte，相当于127个chunk。每次写满一个packet或者写满128M（就是block的大小），就会创立一个新的packet给chunk写入。曾经写满的packet，就是放在下面提到的dataQueue。客户端有其余线程，会监控dataQueue，此时他发现了dataQueue有数据了，他就开始向NameNode申请block信息。NameNode会依据负载平衡以及机架感知，把计算后的DataNode的信息给到客户端。失去DataNode信息后的客户端，就开始与其中一个DataNode建设数据管道，这个DataNode又会与其余DataNode建设数据管道。建设数据管道的作用，就是把通过socket把数据传过来，客户端这里并没有间接和三个DataNode建设数据管道，这是因为DataNode个别是同一个机房的，所以他们外部通信的速度会比拟快。管道建设胜利后，客户端就会把dataQueue队列的头部packet拿进去，通过socket传给DataNode，另外也会把packet放入到ackQueue。放入ackQueue的起因是为了避免packet传输给DataNode失败，如果失败了，就会把packet队列的packet放回到dataQueue，这样监听dataQueue队列的线程就会从新把她拿进去进行传输。如果传输胜利了，会把ackQueue的packet移除。DataNode接管到数据后，会把数据写入ackQueue队列，而后再把packet传输给上游，最初才写入磁盘。这个ackQueue队列的作用跟下面一样，是为了避免传输失败，如果传输胜利，就会把ackQueue队列中的packet移除，如果失败，就会持续传输。如果DataNode不是最初一个节点，那就会反复下面的操作。

HDFS - 什么是元数据咱们提到了CheckPoint机制，次要就是合并多个edits文件，NameNode的压力曾经很大了，所以合并的事件，并不是NameNode来做的，而是SecondaryNamenode来反对的，如果在高可用集群或者联邦集群，那合并的事件，就是有standby节点的NameNode来做的。 SecondaryNamenodeHDFS - 什么是元数据中提到了磁盘中的元数据包含fsimage、edits_inprogress、edits、seen_txid、VERSION这些文件。刚开始的时候，是没有edits文件的。当NameNode运行一段时间后，就开始缓缓的生成多个edits文件，文件名格局是edits_数字-数字（数字是19位的，我这里画图写了4位），并且是递增的。后面的文章说过，NameNode重启的时候，就会加载edits_inprogress、edits、以及fsimage这几个文件，因为这几个文件合起来就是残缺的元数据。因为edits会越来越多，所以就须要进行合并，进步启动的速度，然而NameNode的压力曾经很大了，所以须要SecondaryNamenode来做。SecondaryNamenode会隔一段时间就去申请NameNode获取fsimage和edits文件，如果两次CheckPoint的工夫曾经超过1个小时或者两次CheckPoint的操作记录曾经超过10w条，那NameNode就会生成一个空的edits.new文件，同时把edits文件以及fsimage文件发送给SecondaryNamenode。SecondaryNamenode就会在本地把edits文件和fsimage文件进行合并，生成一个新的fsimage.ckpt文件。生成后的fsimage.ckpt就会发给NameNode，NameNode就会把这个文件笼罩原来的fsimage，fsimage_0006此时前面的数字，对应着edits_0001到edits_0006的元数据汇合。此时就会把旧的edits删除，并且把edits.new文件重命名edis文件。有时候咱们会看到fsimage会有两个，这个是为了最新fsimage不可用的时候，能回滚之前的元数据状态，当然新增的元数据就失落了。 集群如果非集群的话，元数据的长久化是写入磁盘，如果是集群的话，元数据除了写入磁盘，还会写入JournalNode。所以刚开始的时候，active节点的NameNode和JournalNode的元数据是一样的。standby节点的NameNode，每隔60秒，就会去JournalNode读取元数据信息。当CheckPoint触发的时候，就会把edits文件和fsimage文件，合并生成新的fsimage文件。而后standby节点的NameNode就会把新的fsimage发送给active节点的NameNode。active节点的NameNode替换旧的fsimage，就会把edits文件删除。至此，实现了edits文件和fsimage的合并。

[TOC] 上一份工作次要负责大数据平台的建设，在这个过程中积攒了一些Hadoop生态组件的搭建和应用笔记，因为工夫关系，不打算去批改其中的错别字和排版问题，间接释出原始笔记。前置条件我所在的集群有三台服务其，对应的host别离为master,slave1,slave2。hadoop服务的装置分部为 | 机器host| 组件状况| | :-------- | --------:| | master| namenode、datanode、journalnode、resourcemanager、nodemanager、jobhistoryserver| | slave1| namenode、datanode、journalnode、resourcemanager、nodemanager| |slave2 | datanode、journalnode、nodemanager| kerberos相干首先咱们要装置好kerberos，kerberos的装置搭建参考链接https://www.cnblogs.com/nices... 给hadoop各组件创立kerberos账号进入kerberos的admin.local后，顺次执行下述命令 //组件web服务的princialaddprinc -randkey HTTP/master@TEST.COMaddprinc -randkey HTTP/slave1@TEST.COMaddprinc -randkey HTTP/slave2@TEST.COM//namenode的princialaddprinc -randkey nn/master@TEST.COMaddprinc -randkey nn/slave1@TEST.COM//datanode的princialaddprinc -randkey dn/master@TEST.COM addprinc -randkey dn/slave1@TEST.COMaddprinc -randkey dn/slave2@TEST.COM//journalnode的princialaddprinc -randkey jn/master@TEST.COM addprinc -randkey jn/slave1@TEST.COMaddprinc -randkey jn/slave2@TEST.COM//resourcemanager 的princialaddprinc -randkey rm/master@TEST.COMaddprinc -randkey rm/slave1@TEST.COM//nodemanager的principaladdprinc -randkey nm/master@TEST.COM addprinc -randkey nm/slave1@TEST.COMaddprinc -randkey nm/slave2@TEST.COM//job hisotry server的princialaddprinc -randkey jhs/master@TEST.COM将这些账号做成keytab同样是在admin.local中，将上述账号认证信息做成keytab ktadd -k /opt/keytab_store/http.service.keytab HTTP/master@TEST.COMktadd -k /opt/keytab_store/http.service.keytab HTTP/slave1@TEST.COMktadd -k /opt/keytab_store/http.service.keytab HTTP/slave2@TEST.COMktadd -k /opt/keytab_store/nn.service.keytab nn/master@TEST.COMktadd -k /opt/keytab_store/nn.service.keytab nn/slave1@TEST.COMktadd -k /opt/keytab_store/dn.service.keytab dn/master@TEST.COM ktadd -k /opt/keytab_store/dn.service.keytab dn/slave1@TEST.COMktadd -k /opt/keytab_store/dn.service.keytab dn/slave2@TEST.COMktadd -k /opt/keytab_store/jn.service.keytab jn/master@TEST.COM ktadd -k /opt/keytab_store/jn.service.keytab jn/slave1@TEST.COMktadd -k /opt/keytab_store/jn.service.keytab jn/slave2@TEST.COMktadd -k /opt/keytab_store/rm.service.keytab rm/master@TEST.COMktadd -k /opt/keytab_store/rm.service.keytab rm/slave1@TEST.COMktadd -k /opt/keytab_store/nm.service.keytab nm/master@TEST.COM ktadd -k /opt/keytab_store/nm.service.keytab nm/slave1@TEST.COMktadd -k /opt/keytab_store/nm.service.keytab nm/slave2@TEST.COMktadd -k /opt/keytab_store/jhs.service.keytab jhs/master@TEST.COM多个账号能够做到一个keytab中去，上述的命令做了多个文件，不同组件角色的独自放到了一个keytab文件中。其实外部网络，能够把所有的hadoop相干组件做成一个大的keytab文件，升高配置复杂性。 ...

元数据文件上传到HDFS服务器的时候，会分成多个块，并以多个正本的模式存储在服务器下面，那咱们怎么晓得这个文件的文件名是什么呢？这个文件被分成了多少块？每个块又存储在哪几个服务呢？所以HDFS在上传文件的时候，除了上传文件，还会另外保留这些信息，这些信息叫做元数据。元数据的在HDFS中有两种模式，一个是磁盘，一个是内存，两种模式的数据是齐全截然不同的。存磁盘是为了数据的长久化，存内存是为了进步读写的性能。在HDFS中，咱们读写文件的时候，目录相似于Linux的目录构造，所以元数据也会保留目录树结构。比方下图，INodeDirectory是目录，INodeFile是文件，一个目录下能够有多个目录和多个文件。所以元数据包含： 目录树结构。文件与block之间的关系block与DataNode的关系元数据文件的组成咱们之前搭建Hadoop集群以及高可用集群的时候，都会有个格式化的操作，这个操作就会在磁盘目录上生成一个fsimage文件，而这个文件就是用来寄存元数据的信息的。当NameNode启动的时候，会依据配置信息读取到fsimage目录的fsimage文件，把它加载到内存中。NameNode对外提供服务的时候，就有客户端上传文件的申请，就会把元数据加到内存的fsimage中，为了保证数据不失落，也会把元数据长久化磁盘中，写入磁盘的文件是edits_inprogress。此时内存中的fsimage=磁盘的fsimage+edits_inprogress。当edits_inprogress文件数据越来越多，或者隔一段时间后，edits_inprogress文件就会重命名为edits0000000N-edits0000000M文件，并且用新的edits_inprogress文件从新写入数据。如此重复，就有很多很多个edits文件。此时内存中的fsimage=磁盘的fsimage+edits_inprogress+所有的edits。当NameNode重启的时候，此时就会把磁盘的fsimage+edits_inprogress+所有的edits都读入缓存，合并为内存的fsimage。咱们能够预测的到，在元数据有限增量的状况下，edits文件就会越来越多，每次NameNode重启所加载的工夫也会越来越多，所以就有了CheckPoint机制，简略的说，就是把历史的edits文件合并到fsimage，那下次重启的时候，咱们就只加载合并后的fsimage文件、edits_inprogress文件以及大量的edits文件，大大提高了NameNode的启动工夫。为了记录每次CheckPoint的TXID，就会有seen_txid文件进行记录。另外还有一个文件，叫VERSION，这里寄存着HDFS集群的信息。综上，元数据文件包含fsimage、edits_inprogress、edits、seen_txid、VERSION。

注册在HDFS - HDFS的四个角色提到了NameNode启动的时候，会开启RPC服务，叫做ServiceRpcServer，这个Server有很多个协定，其中一个叫做DatanodeProtocol协定，用来响应DataNode的申请，比方注册、心跳、block报文解决等。DataNode启动的时候，会依据NameNode的地址，把本人的IP地址、端口、主机名等信息，发送给NameNode进行注册，为了使注册胜利，DataNode会始终重试，直至胜利。NameNode接管到申请后，他会验证一下本人是否曾经启动实现，如果曾经胜利就把DataNode的信息退出到内存DatanodeManager.datanodeMap实现注册，并且加到HeartbeatManager.datanodes，HeartbeatManager次要是用于治理心跳的。这些都实现后，就会判断是否进入平安模式，平安模式上章节曾经讲了。 心跳注册胜利后，DataNode每隔三秒中就会给NameNode发送心跳。NameNode接管到心跳申请后，也会先判断本人是否曾经启动。因为注册的时候，会把DataNode的信息保留在DatanodeManager.datanodeMap中，所以发送心跳的时候，会先验证是否在这个内存中，如果不在，阐明没有注册过。如果曾经注册过，会通过HeartbeatManager更新最初一次的心跳工夫。咱们留神到，每次心跳NameNode都会返回一些指令，在Hadoop中，NameNode并没有发送指令给DataNode，须要通过DataNode发送心跳后，返回指令给DataNode。 剔除当NameNode发现一个DataNode曾经长时间没有发送心跳信息了，就会把他剔除下线。HeartbeatManager中有一个线程，默认每5分钟会查看一次，这个工夫由dfs.namenode.heartbeat.recheck-interval设置的。HeartbeatManager查看的时候，会遍历所有的datanodes，判断每个datanode是否曾经死亡，如果曾经死亡，就把他从内存中删除掉。剔除掉后，就会判断是否进入平安模式。判断是否死亡的工夫是由上面的公式计算的，heartbeatRecheckInterval 默认5福州，heartbeatIntervalSeconds就是心跳的工夫，默认3秒，所以就是10分钟+30秒，也就是说，DataNode在630秒后还是没有发送心跳信息，NameNode就当作他曾经死亡了，并且从内存中剔除。 2 heartbeatRecheckInterval + 10 1000 * heartbeatIntervalSeconds

HDFS - NameNode的高可用提到了NameNode有active状态和standby状态，他还有另外一个状态，就是safemode，平安模式。在平安模式下，HDFS不接管对元素批改的申请，只容许对元数据的读申请。以下是几种进入平安模式的形式： 可用空间当NameNode启动的时候，会获取文件所在的磁盘分区里真正能够应用的存储空间，而后跟duReserved进行比照，如果存储空间大于duReserved，则返回true，如果小于，则返回false，返回值赋值给返回值给hasResourcesAvailable。duReserved默认为100M，能够通过dfs.namenode.resource.du.reserved进行配置。hasResourcesAvailable为false的时候，阐明可用存储空间有余100M，此时进入平安模式。 block个数NameNode启动的时候，会从磁盘fsimage加载元数据，加载后他就晓得了总共有多少个block，然而他不晓得这些block在DataNode中是否失常，所以进入平安模式，期待DataNode上报本人的block信息，当上报的block个数达到肯定阈值的时候，就会退出平安模式，上面是具体的计算过程。在HDFS中，block的状态包含正在构建的和complete两种状态，所以咱们要获取到complete的block个数，就须要先获取所有的block，而后减去正在构建的block，这样就能够获取到complete的block个数。threshold参数，比方为0.9，阐明block数量为100的状况下，只有存在90个失常的block就能够了，因为HDFS集群的文件数量是相当多的，他的默认值是0.999，代表1000个block至多要999个是失常的，能够通过dfs.namenode.safemode.threshold-pct进行配置。complete的block个数乘以threshold，这个值就是要保障HDFS失常写申请的最低数据量，如果datanode汇报过去的block个数blockSafe比最低数据量还小，那就要进入平安模式。 datanode的存活个数datanode的存活个数datanodeThreshold默认为0，代表的不启用，如果有设置，那就要与DataNode的个数进行判断，如果存活的DataNode个数小于设置的值，那须要进入平安模式。 命令除了下面三种主动进入平安模式外，咱们还能够通过命令让HDFS进入平安模式： 命令形容hdfs dfsadmin -safemode get查看平安模式的状态hdfs dfsadmin -safemode enter进入平安模式hdfs dfsadmin -safemode wait进入平安模式hdfs dfsadmin -safemode leave来到平安模式enter和wait都是进入平安模式，区别是enter是肯定进入平安模式的，wait是期待HDFS进入平安模式，就如同在java中执行gc命令，并不会间接执行gc命令一样。

高可用咱们曾经晓得了，读取文件、上传文件，都须要通过NameNode，如果NameNode宕机了，那客户端就不晓得往哪里读写数据，整个集群就不可用了。Hadoop的高可用是通过zookeeper来实现的，Hadoop - 集群装置（高可用），这篇文章也提到了zookeeper的作用，实际上对于大数据的各个组件来说，很多高可用都是通过zookeeper来做的，咱们上面看看zookeeper是如果实现Hadoop的高可用。在zookeeper中实现master选举的，能够看之前的文章zookeeper之master选举，这里不做细节补充。高可用个别都是通过冗余的形式，部署多个节点，其中一个作为流动的节点，对外提供服务，残余的节点作为处于待机状态，当流动节点不能够的时候，顶替成为流动节点。在高可用的Hadoop中，NameNode的节点数量是2个，并且每个NameNode都有zkfc，用于和zookeeper进行通信。当其中一个NameNode胜利的在zookeeper创立一个节点后，他就成了active节点，另外一个就是standby节点。active节点对外提供服务，standby节点监听zookeeper的节点，当发现active节点不能够的时候，就去zookeeper上创立节点，变成active节点。DataNode须要定时的给NameNode发送心跳，NameNode就会在内存中记录每个DataNode最初发送心跳的工夫，作为DataNode存活的根据，那此时是有两个NameNode的，如果仅仅把心跳发送到active节点下面，那故障转移的时候，新的active是不晓得哪些DataNode是存活的，为了疾速的实现故障转移，所以DataNode发送心跳的时候，就会获取到两个NameNode的地址和端口，一起发送本人的心跳信息。NameNode内存中除了保留DataNode的心跳信息，还保留了元数据信息。为了让两个NameNode的元数据也同步，每次元数据有变更的时候，active节点也会把数据发送到journalnode集群，standby节点就会定期的从journalnode集群读取元数据信息。为了保障NameNode的高可用，HDFS引入了zookeeper和journalnode，如果这两个不是高可用的，那也会影响到NameNode的高可用，所以这两个也要是高可用的。 联邦集群高可用的NameNode也是有他的瓶颈，比方所有的拜访都要通过active节点的NameNode，高可用的NameNode并没有缩小active节点的压力，另外一个瓶颈就是元数据的治理，元数据会始终增长，NameNode的内存总有被耗费完的一天，并且始终加内存会导致每次加载元数据过多让启动变得异样慢，并且full gc的工夫也很长。为了解决这两个问题，HDFS推出了联邦集群。既然一个NameNode有瓶颈，那就多几个NameNode来分单压力，如图下所示，有三组的NameNode，每组的NameNode都有active节点和standby节点。他们和zookeeper以及journalnode的关系跟高可用一样。那这些NameNode是怎么治理元数据和DataNode的呢？联邦集群里引入了块池的概念，比方咱们有三组的NameNode，那就有三个块池，每个DataNode就会划分成多个逻辑概念的块。比方下图，假如每个DataNode分为三块，每个块都有对应的块池，第一组的NameNode往块池1读写数据，并保留对应的元数据信息。第二组的NameNode往块池2读写数据，并保留对应的元数据信息。第三组的NameNode往块池3读写数据，并保留对应的元数据信息。假如元数据原先为600G，那此时每个NameNode只有治理200G的元数据就好了。另外在读写上，也升高为原来的三分之一，大大减少了NameNode的压力。

在上一篇曾经晓得了HDFS是把文件切成块后，再存储在多个服务器中，并且为了数据的安全性，都做了多个正本进行冗余存储。那在HDFS中，是谁对文件进行切块？是谁决定了块存储在哪里？是谁治理存储的文件？在HDFS中，有这几种角色： NameNode： 负责解决Client的申请、元数据管理等其余性能。DataNode：次要就是存储文件块的。Client：客户端，与NameNode、DataNode交互。SecondaryNamenode：分担NameNode的压力，次要是元数据的合并。 Client上传文件的时候，Client会把一个大文件切成一个个块，在新近的版本中，每个块是64M的，前面的版本是128M每个块，这个能够依据零碎的应用进行调整。切成块后，再询问NameNode他每个块要寄存哪里，等拿到NameNode的回复后，就开始把块的数据上传到DataNode中。如果是读文件的话，就会询问NameNode每个块在哪里，而后依据NameNode的回复，从相应的DataNode读取文件，最初把块拼接合并成文件。除了读写文件外，Client也会通过其余的命令来和NameNode以及DataNode交互。 NameNodeNameNode有一个50070端口的HttpServer，提供各种性能，比方咱们用50070拜访网页的时候，就是这个服务提供的性能。这个HttpServer服务还有一个提供了imagetransfer性能，用于元数据合并。除了Http服务，NameNode也提供了两个RPCServer，一个是ClientRpcServer一个是ServiceRpcServer。ClientRpcServer是用来响应Client的读写申请以及其余申请。ServiceRpcServer是用来响应DataNode的申请，比方注册、心跳。NameNode负责解决Client的申请，因为他晓得块的每个正本要怎么存储，每个正本曾经存储在哪里，那他怎么晓得的呢？比方上图的文件，被分成4块，读取的时候，咱们怎么晓得把哪些块读取进去合并成，还原到原来的文件？咱们又怎么晓得要读取的块寄存在哪个DataNode？这些信息都是元数据来记录的，NameNode会在硬盘和内存中存储一个叫元数据的货色，一个文件被分成多个块，那这个文件和每个块的对应关系是记录在元数据里的。每个块又存储在多个DataNode，这些信息也是记录在元数据里的。 DataNodeDataNode是实际上读写文件的中央，他存储着所有的文件，每个DataNode都不能保障不出故障，所以咱们文件是以多正本的模式存储在DataNode中。和NameNode一样，DataNode也提供了HttpServer和RPCServer。HttpServer用于解决NameNode和其余DataNode的申请。RPCServer用于解决Client和其余DataNode的申请。当Client要上传文件的时候，NameNode须要告知Client上传到哪个DataNode，这些DataNode必须是失常的，为了让NameNode晓得本人是失常的，NameNode会定期的发送心跳信息给NameNode。

随着业务的倒退，服务器寄存的文件就越来越多，初期的时候，咱们会间接通过扩容来解决这个问题。然而硬盘不可能寄存将来所有增量的文件，并且硬盘不可能有限扩容，当硬盘调配完后，要么加硬盘，要么加服务器。加硬盘可能是比拟快的形式，只有在程序中判断在某个工夫节点的文件，写入和读取都在指定的盘符就能够了，然而每个机器的接口无限，而且机架能够寄存硬盘的地位也无限，当接口或者地位都占用了，空间有余要怎么办？所以能够用很多很多个服务器来寄存并治理这些文件。因为服务器呈现问题是不可避免的，比方咱们软件的bug、操作系统的bug、硬盘故障、忽然断电甚至自然灾害等，所以为了保证数据的安全性，就须要用冗余的方法来存储，也就是说一个文件寄存在多个服务器中，比方下图寄存2个服务器，这样当服务器1呈现问题的时候，咱们还能够从服务器2读取文件。冗余的正本越多，数据就越平安，当然存储的服务器老本也越高。当寄存一段时间后，服务器的状况如下，文件的大小咱们是不能管制的，所以每次上传文件的时候，还须要晓得这个文件是否大于待上传服务器的可用空间。另外大小不一的文件也不好治理。所以个别是把文件分成固定的大小块，比方64M或者128M，而后再上传到服务器。比方下图，把文件分成4块，而后存储在4个服务器中，每个块的正本是3个。如果说服务器1不可用了，文件1、文件2、文件4在其余服务器还是存在正本的，文件还是平安的。

Hadoop实战篇（1） 作者 | WenasWei 前言在后面介绍过了Hadoop-离线批处理技术的整体架构，接下来便开始学习装置配置并应用 Hadoop ; 将从以下几点介绍: Linux 环境的配置与装置 HadoopHadoop 的三种装置模式介绍本地模式装置伪集群模式装置一 Linux环境的配置与装置HadoopHadoop须要应用到 Linux 环境上的一些根本的配置须要，Hadoop 用户组和用户增加，免密登录操作，JDK装置 1.1 VMWare中Ubuntu网络配置在应用 VMWare 装置 Ubuntu18.04-Linux 操作系统下时产生系统配置问题能够通过分享的博文进行配置，CSDN跳转链接: VMWare中Ubuntu网络配置 其中蕴含了以下几个重要操作步骤: buntu零碎信息与批改主机名Windows设置VMWare的NAT网络Linux网关设置与配置动态IPLinux批改hosts文件Linux免明码登录1.2 Hadoop 用户组和用户增加1.2.1 增加Hadoop用户组和用户以 root 用户登录 Linux-Ubuntu 18.04虚拟机，执行命令: $ groupadd hadoop$ useradd -r -g hadoop hadoop1.2.2 赋予Hadoop用户目录权限将 /usr/local 目录权限赋予 Hadoop 用户， 命令如下: $ chown -R hadoop.hadoop /usr/local/$ chown -R hadoop.hadoop /tmp/$ chown -R hadoop.hadoop /home/1.2.3 赋予Hadoop用户sodu权限编辑/etc/sudoers文件，在root ALL=(ALL:ALL) ALL下增加hadoop ALL=(ALL:ALL) ALL $ vi /etc/sudoersDefaults env_resetDefaults mail_badpassDefaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"root ALL=(ALL:ALL) ALLhadoop ALL=(ALL:ALL) ALL%admin ALL=(ALL) ALL%sudo ALL=(ALL:ALL) ALL1.2.4 赋予Hadoop用户登录明码$ passwd hadoopEnter new UNIX password: 输出新密码Retype new UNIX password: 确认新密码passwd: password updated successfully1.3 JDK装置Linux装置JDK能够参照分享的博文《Logstash-数据流引擎》-<第三节：Logstash装置>--(第二大节: 3.2 Linux装置JDK进行)装置配置到每一台主机上，CSDN跳转链接: Logstash-数据流引擎 ...

相干常识 Hadoop由Apache基金会开发的分布式系统基础架构，是利用集群对大量数据进行分布式解决和存储的软件框架。用户能够轻松地在Hadoop集群上开发和运行解决海量数据的应用程序。Hadoop有高牢靠，高扩大，高效性，高容错等长处。Hadoop 框架最外围的设计就是HDFS和MapReduce。HDFS为海量的数据提供了存储，MapReduce为海量的数据提供了计算。此外，Hadoop还包含了Hive，Hbase，ZooKeeper，Pig，Avro，Sqoop，Flume，Mahout等我的项目。 Hadoop的运行模式分为3种：本地运行模式，伪散布运行模式，齐全散布运行模式。（1）本地模式（local mode）这种运行模式在一台单机上运行，没有HDFS分布式文件系统，而是间接读写本地操作系统中的文件系统。在本地运行模式（local mode）中不存在守护过程，所有过程都运行在一个JVM上。单机模式实用于开发阶段运行MapReduce程序，这也是起码应用的一个模式。 （2）伪分布模式这种运行模式是在单台服务器上模仿Hadoop的齐全分布模式，单机上的分布式并不是真正的分布式，而是应用线程模仿的分布式。在这个模式中，所有守护过程(NameNode，DataNode，ResourceManager，NodeManager，SecondaryNameNode)都在同一台机器上运行。因为伪散布运行模式的Hadoop集群只有一个节点，所以HDFS中的块复制将限度为单个正本，其secondary-master和slave也都将运行于本地主机。此种模式除了并非真正意义的分布式之外，其程序执行逻辑齐全相似于齐全分布式，因而，罕用于开发人员测试程序的执行。本次试验就是在一台服务器上进行伪散布运行模式的搭建。 （3）齐全分布模式这种模式通常被用于生产环境，应用N台主机组成一个Hadoop集群，Hadoop守护过程运行在每台主机之上。这里会存在Namenode运行的主机，Datanode运行的主机，以及SecondaryNameNode运行的主机。在齐全分布式环境下，主节点和从节点会离开。 零碎环境Linux Ubuntu 20.04 工作内容在只装置Linux零碎的服务器上，装置Hadoop3.2.2伪分布模式。 工作步骤 1.创立一个用户，名为lijiawen，并为此用户创立home目录，此时会默认创立一个与lijiawen同名的用户组。 sudo useradd -d /home/lijiawen -m lijiawen 为zhangyu用户设置明码，执行上面的语句 sudo passwd lijiawen 按提醒音讯，输出明码以及确认明码即可，此处明码设置为123456 将lijiawen用户的权限，晋升到sudo超级用户级别 sudo usermod -G sudo lijiawen 后续操作，咱们须要切换到zhangyu用户下来进行操作。 su - lijiawen 2.首先来配置SSH免明码登陆 SSH免明码登陆须要在服务器执行以下命令，生成公钥和私钥对 ssh-keygen -t rsa 此时会有多处揭示输出在冒号后输出文本，这里次要是要求输出ssh明码以及明码的搁置地位。在这里，只须要应用默认值，按回车即可。 此时ssh公钥和私钥曾经生成结束，且搁置在~/.ssh目录下。切换到~/.ssh目录下 cd ~/.ssh 能够看到~/.ssh目录下的文件 lijiawen@DESKTOP-F0G7R99:~/.ssh$ ll总用量 24drwx------ 2 lijiawen lijiawen 4096 5月 13 15:34 ./drwxr-xr-x 8 lijiawen lijiawen 4096 5月 27 08:32 ../-rw-r--r-- 1 lijiawen lijiawen 1156 5月 13 15:20 authorized_keys-rw------- 1 lijiawen lijiawen 2610 5月 6 17:27 id_rsa-rw-r--r-- 1 lijiawen lijiawen 578 5月 6 17:27 id_rsa.pub-rw-r--r-- 1 lijiawen lijiawen 444 5月 13 15:35 known_hosts上面在~/.ssh目录下，创立一个空文本，名为authorized_keys ...

在信息爆炸的大数据时代，如何以更低成本来解决海量数据的存储问题，已成为企业大数据业务中的重要一环。UCloud自研的新一代对象存储服务US3，在过来一段时间，针对大数据业务场景推出了计算存储拆散和大数据备份解决方案。 这背地的次要起因包含： 1、因为网络技术的高速倒退，使得网络传输性能不再是大数据场景下高吞吐业务需要的瓶颈；2、Hadoop技术栈中的HDFS存储解决方案运维简单且老本昂扬；3、云平台基于海量存储资源池构建的对象存储服务US3具备按需应用、操作简略、牢靠稳固、价格便宜的劣势，是替换HDFS的最佳存储计划抉择。因而，为了让用户可能更加不便的在Hadoop场景下，应用US3实现计算存储拆散和大数据备份解决方案，US3自研了US3Hadoop适配器、US3Vmds、US3Distcp三个组件。 本文次要介绍US3Hadoop适配器在研发设计过程中的一些思路和问题解决。 总体设计思路 Hadoop生态里对存储的操作基本上都是通过一个通用的文件系统基类FileSystem来进行的。US3Hadoop适配器(简称:适配器)是通过US3FileSystem实现该基类来操作US3。相似于HDFS实现的DistributedFileSystem和基于AWS S3协定实现的S3AFileSystem。适配器间接把IO和索引都申请发给US3，架构如下图所示： 这里的索引操作次要是不波及读写数据的API，如: HEADFile, ListObjects, Rename, DeleteFile, Copy(用于批改metadata)；IO操作的API，如GetFile，PutFile(小于4M文件)曾经分片上传相干的4个API: InitiateMultipartUpload，UploadPart，FinishMultipartUpload，AbortMultipartUpload。US3有了这些API后，怎么跟FileSystem的成员办法能对应起来，能够看下FileSystem须要重写哪些办法。结合实际需要和参考DistributedFileSystem、S3AFileSystem的实现，咱们确定了须要重写的次要办法：initialize、create、rename、getFileStatus、open、listStatus、mkdirs、setOwner、setPermission、setReplication、setWorkingDirectory、getWorkingDirectory、getSchem、getUri、getDefaultBlockSize、delete。同时对一些难以模仿的办法，重写为异样不反对，如Append成员办法。 其实从下面FileSystem的成员办法阐明来看，其语义和单机文件系统引擎的接口语义相似，基本上也是以目录树结构来组织治理文件系统。US3提供的ListObjects API刚好也提供了目录树拉取的一种形式，当Hadoop调用listStatus办法时，就能够通过ListObjects循环拉取到当前目录(前缀)下所有子成员从而返回对应的后果。 设置文件所属用户/组，操作权限等相干操作则利用了US3的元数据性能，把这些信息都映射到文件的KV元数据对上。写入文件流则会优先缓存在内存中最多4MB数据，再依据后续的操作来决定采纳PutFile还是分片上传的API来实现。 读取文件流则通过GetFile返回流实例来读取期待的数据。尽管这些办法实现看上去很直白，然而潜在着很多值得优化的中央。 getFileStatus的时空博弈通过剖析FileSystem的调用状况，能够晓得索引操作在大数据场景中占比达70%以上，而getFileStatus在索引操作重占比最高，所以有必要对其进行优化。那优化点在哪里呢？ 首先因为US3中的“目录”(对象存储是KV存储，所谓目录只是模仿而已)是以‘/’结尾的Key，而FileSystem的对文件的操作是通过Path构造进行，该构造的门路都不会以‘/’结尾，所以通过Path拿到的Key去US3中进行HeadFile时，有可能因为该Key在US3中是目录，HeadFile就会返回404, 必须通过第二次用“Key/”去US3中Head能力确认。如果这个Key目录还是不存在，就会导致getFileStatus时延大大增加了。 因而US3适配在创立目录时做了以下两件事:1．向US3写入mime-type为“file/path”, 文件名为“Key”的空文件;2．向US3写入mime-type为“application/x-director”, 文件名为“Key/”的空文件; 而一般文件mime-type为“application/octet-stream”。这样在getFileStatus中通过一次HeadFile API就判断以后Key到底是文件还是目录，同时当该目录下为空时，也能在US3控制台展现出该目录。而且因为Hadoop场景写入的次要是大文件，减少一次空文件索引的写入耗时在ms级别，时延根本可疏忽。 此外，getFileStatus在Hadoop的应用中具备显著的“时空局部性”特色，在具体的FileSystem实例中最近被getFileStatus操作的Key，在短时间会被屡次操作。利用这个特点，US3FileSystem在实现过程中，getFileStatus失去对应的后果在FileStatus返回之前，会把有3s生命周期的FileStatus插入到Cache中。那后续3秒内对该Key的操作就会复用Cache中该Key的FileStatus信息，当然delete操作会在US3中删除完Key后，间接把Cache中的无效FileStatus标记为有3s生命周期的404 Cache，或者直接插入一个有3s生命周期的404 Cache。如果是rename，会复用源的Cache来结构目标Key的Cache，并删除源，这样就能缩小大量跟US3的交互。Cache命中(us级别)会缩小getFileStatus上百倍的时延。 当然这会引入肯定的一致性问题，但仅限于在多个Job并发时至多有一个存在“写”的状况，如delete和rename的状况下，如果仅仅只有读，那么无影响。不过大数据场景根本属于后者。 ListObjects一致性问题 US3的ListObjects接口跟其余对象存储计划相似，目前都只能做到最终一致性（不过US3后续将推出强一致性保障的ListObjects接口），因而其余对象存储实现的适配器也都会存在写入一个文件，而后立刻调用listStatus时会偶然呈现这个文件不存在的状况。其余对象存储计划有时会通过引入一个中间件服务(个别是数据库)，当写入一个文件会向这个中间件写入这个文件索引，当listStatus时会跟中间件的索引信息进行合并，这样的确缓解了这种状况，进一步提高了一致性。 但还不够，比方写入对象存储胜利，但写入中间件时程序奔溃了，这样就导致不统一的问题，又回到了最终一致性的问题。 US3Hadoop适配器的实现绝对更加简略无效，不须要借助额定的服务，能提供索引操作级别的Read-Your-Writes一致性，而该一致性级别在Hadoop大部分场景根本等同于强一致性。US3Hadoop适配器不像S3AFileSystem的实现，在create或者rename、delete后立马返回，而是在外部调用ListObjects接口做了一次“对账”，直到“对账”后果合乎预期则返回。 当然这里也是有优化空间的，比方delete一个目录时，对应会把这个目录下所有文件先拉进去，而后顺次调用DeleteFile API去删除，如果每次DeleteFile API删除都“对账”一次，那么整个时延会翻倍。US3Hadoop适配器的做法是只对最初一次索引操作进行“对账”，这是因为索引的oplog是按时序同步到列表服务中，如果最初一条索引“对账”胜利，那么后面的oplog肯定在列表服务中写入胜利。 Rename的深度定制 后面提到的rename也是US3的一个重要优化点，其余对象存储计划的实现个别通过Copy的接口会先把文件复制一遍，而后再删除源文件。能够看出如果rename的文件很大，那么rename的整个过程势必导致时延很高。 US3依据该场景的需要，专门开发了Rename的API接口，因而US3Hadoop适配器实现rename的语义绝对比拟轻量，而且时延放弃在ms级别。 保障read高效稳固 读是大数据场景的高频操作，所以US3Hadoop适配器的读取流实现，不是对http响应的body简略封装，而是思考了多方面的优化。例如，对读取流的优化，通过退出预读Buffer，缩小网络IO零碎调用频率，升高read操作的期待时延，特地是大批量程序读的IO晋升成果显著。 另外，FileSystem的读取流具备seek接口，也就是须要反对随机读，这里又分两种场景： 1、seek到已读流地位的前置地位，那么作为Underlay Stream的Http响应的body流就要作废敞开掉，须要从新发动一个从seek的地位开始分片下载的GetFile API，取得其Http响应的body流来作为新的Underlay Stream。然而理论测试过程中发现，很多seek操作过后不肯定会进行read操作，有可能间接敞开，或者seek回到已读取流地位的后置地位，所以在seek产生时，US3Hadoop适配器的实现是只做seek地位标记，在read的时候依据理论状况对Underlay Stream做提早敞开关上解决。此外如果seek的地位还在Buffer中，也不会从新关上Underlay Stream，而是通过批改Buffer的生产偏移。 2、随机读的另一种场景就是，seek到已读流地位的后置地位。这里同样跟后面一样采纳提早流关上，然而在确定要做实在的seek操作时，不肯定会通过敞开老的Underlay Stream，从新在指标地位关上新的Underlay Stream来实现。因为以后已读的地位跟seek的后置地位可能间隔很近，假如只有100KB间隔，说不定这段距离齐全在预读Buffer的范畴中，这时也能够通过批改Buffer的生产偏移来实现。 事实上US3Hadoop适配器的确也是这么做的，不过目前的规定是seek的后置地位到以后已读流地位的间隔小于等于预读Buffer残余空间加上16K的和，则间接通过批改预读Buffer的生产偏移和生产Underlay Stream中的数据来定位到seek的后置地位上。之所以还加了16K是思考到TCP接管缓存中的数据。当然后续确定从一个ready的Underlay Stream中生产N字节数据的工夫老本大抵等于从新发动一个GetFile API并在筹备传输该Http响应body之前的工夫老本，也会思考把这N字节的因素计入偏移计算过程中。 最初流的优化还要思考到Underlay Stream异样的状况，比方HBase场景长时间持有关上的流，却因为其余操作导致长时间没有操作该流，那么US3可能会被动敞开开释Underlay Stream对应的TCP连贯，后续对在Underlay Stream上的操作就会报TCP RST的异样。为了提供可用性，US3Hadoop适配器的实现是在曾经读取地位点上进行Underlay Stream的从新关上。 写在最初 US3Hadoop适配器的实现在借鉴开源计划下，进一步优化了相干外围问题点，晋升了Hadoop拜访US3的可靠性与稳定性，并在多个客户案例中施展着买通Hadoop与US3的重要桥梁作用，帮忙用户晋升大数据场景下的存储读写效率。 但US3Haoop适配器还存在很多可晋升的空间，相比于HDFS，索引、IO的时延还有差距，原子性保障上也绝对比拟弱，这些也是咱们接下来要思考解决的问题。目前推出的US3Vmds解决了索引时延的大部分问题，使得通过US3Hadoop适配器操作US3的性能失去大幅晋升，并在局部场景靠近原生HDFS的性能。具体数据能够参考官网文档(https://docs.ucloud.cn/ufile/... 将来，US3产品会不断改进优化大数据场景下的存储解决方案，在升高大数据存储老本的同时，进一步晋升用户在大数据场景下的US3应用体验。

Hadoop - 集群装置曾经介绍了如何装置一个Hadoop集群，然而这个集群的NameNode呈现故障，那这个集群是不能够用的。咱们须要借助zookeeper来装置一个高可用集群，当于Active状态的NameNode产生故障，还有Standby状态的NameNode及时切换，成为Active状态的NameNode对外提供服务。zookeeper集群见之前的，这里的配置是bigdata01、bigdata02、bigdata03是zookeeper节点，bigdata04作为集群的observer角色。其余步骤跟之前的集群装置一样，区别是几个配置文件的批改。 配置文件hdfs-site.xml这里配置2个namenode的相干信息。 <configuration> <!-- 指定正本数 --> <property> <name>dfs.replication</name> <value>3</value> </property> <!--定义nameservice的名称为hadoopdajun--> <property> <name>dfs.nameservices</name> <value>hadoopdajun</value> </property> <!-- 定义hadoopdajun两个NameNode的名称：nn1，nn2 --> <property> <name>dfs.ha.namenodes.hadoopdajun</name> <value>nn1,nn2</value> </property> <!-- nn1的RPC通信地址，rpc用来和datanode通信 --> <property> <name>dfs.namenode.rpc-address.hadoopdajun.nn1</name> <value>bigdata01:9000</value> </property> <!-- nn1的http通信地址，用于web客户端 --> <property> <name>dfs.namenode.http-address.hadoopdajun.nn1</name> <value>bigdata01:50070</value> </property> <!-- nn2的RPC通信地址，rpc用来和datanode通信 --> <property> <name>dfs.namenode.rpc-address.hadoopdajun.nn2</name> <value>bigdata02:9000</value> </property> <!-- nn2的http通信地址，用于web客户端 --> <property> <name>dfs.namenode.http-address.hadoopdajun.nn2</name> <value>bigdata02:50070</value> </property> <!-- edits元数据的共享存储地位 --> <property> <name>dfs.namenode.shared.edits.dir</name> <value>qjournal://bigdata01:8485;bigdata02:8485;bigdata03:8485/hadoopdajun</value> </property> <!-- 本地磁盘存放数据的地位 --> <property> <name>dfs.journalnode.edits.dir</name> <value>/home/bigdata/data/journaldata</value> </property> <!-- 开启NameNode失败主动切换 --> <property> <name>dfs.ha.automatic-failover.enabled</name> <value>true</value> </property> <!-- 配置失败主动切换的代理类 --> <property> <name>dfs.client.failover.proxy.provider.hadoopdajun</name> <value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value> </property> <!-- 配置隔离机制办法，多个机制用换行宰割，即每个机制暂用一行--> <property> <name>dfs.ha.fencing.methods</name> <value> sshfence shell(/bin/true) </value> </property> <!-- 应用sshfence隔离机制时须要ssh免登陆 --> <property> <name>dfs.ha.fencing.ssh.private-key-files</name> <value>/home/bigdata/.ssh/id_rsa</value> </property> <!-- 配置sshfence隔离机制超时工夫 --> <property> <name>dfs.ha.fencing.ssh.connect-timeout</name> <value>30000</value> </property> <property> <name>dfs.webhdfs.enabled</name> <value>true</value> </property> </configuration>core-site.xml这里配置zookeeper的相干信息，并且fs.defaultFS配置的是nameservice的名称，而不是之前的地址。 ...

环境筹备我这里筹备四个虚拟机，ip别离为： # bigdata01192.168.11.100# bigdata02192.168.11.101# bigdata03192.168.11.102# bigdata04192.168.11.103主机命批改主机名批改为bigdata01、bigdata02、bigdata03、bigdata04。 # 进入文件vi /etc/hostname# 批改文件，这里依据不同的服务器批改bigdata01新建账户新建账户为bigdata，并设置明码，设置权限，bigdata的权限等同于root # 进入文件vi /etc/sudoers# 新增配置bigdata ALL=(ALL) ALL敞开防火墙/敞开Selinux# 敞开防火墙systemctl disable firewalld敞开selinux # 进入文件vi /etc/selinux/config# 批改配置SELINUX=disabled域名映射# 进入文件vi /etc/hosts# 新增配置192.168.11.100 bigdata01 192.168.11.101 bigdata02 192.168.11.102 bigdata03 192.168.11.103 bigdata04置SSH免密登录bigdata用户登录，在每个虚拟机执行ssh-keygen命令，始终enter上来，直至id_rsa.pub和id_rsa两个文件生成。生成后，每个虚拟机执行以下命令发送公钥文件： ssh-copy-id bigdata01ssh-copy-id bigdata02ssh-copy-id bigdata03ssh-copy-id bigdata04发送后通过ssh验证，比方以后在bigdata01服务器，ssh bigdata02看看能不能免密登录到bigdata02服务器，如果能够，就阐明设置胜利。如果设置了还不行，就须要留神设置文件夹和文件的权限。因为sshd为了平安，对属主的目录和文件权限有所要求。如果权限不对，则ssh的免明码登陆不失效。 chmod 700 /home/bigdatachmod 700 /home/bigdata/.sshchmod 600 /home/bigdata/.ssh/authorized_keys编译我这边装置的是2.7.7版本。编译之前除了下载相应版本的源码包，还须要查看官网的BUILDING.txt文件，这个文件形容了以后版本的编译须要的依赖项，以及依赖项的装置、配置。上面是官网的截图，比方Unix零碎，须要JDK1.7+、Maven3.0等。以上软件都装置实现后，就能够通过maven对源码进行编译，编译后，咱们就能够在target生成一个hadoop-2.7.7.tar.gz文件，至此编译实现。 编译后把生成的文件解压到制订目录，比方我这里是/home/bigdata/apps/hadoop-2.7.7。 配置文件参考官网配置之前，咱们的布局是这样的,4个节点，3个正本： 节点名称HDFSYARNbigdata01NameNodeNodeManagerbigdata02DataNode + SecondaryNamenodeNodeManagerbigdata03DataNodeNodeManagerbigdata04DataNodeResourceManagerhadoop-env.sh配置Hadoop守护过程环境，门路：etc/hadoop/hadoop-env.sh。 参数形容必选JAVA_HOMEJAVA_HOME的门路是HADOOP_PID_DIRHADOOP的PID文件门路否HADOOP_LOG_DIRHADOOP的日志文件门路否HADOOP_HEAPSIZE应用的最大堆大小，以MB为单位，默认1000M否core-site.xml门路：etc/hadoop/core-site.xml。这个是xml文件，配置在configuration节点上面。 参数形容参数值fs.defaultFSNameNode的URLhdfs://bigdata01:9000io.file.buffer.sizeequenceFiles中应用的读/写缓冲区的大小。131072hadoop.tmp.dir集群相干的数据存储目录/home/bigdata/data/hadoopdatahdfs-site.xml配置NameNode和DataNode信息，门路：etc/hadoop/hdfs-site.xml。这个是xml文件，配置在configuration节点上面。 参数形容参数值dfs.namenode.name.dir本地文件系统上的门路，NameNode在其中长久化存储命名空间和事务日志，如果用逗号隔开，那每个目录都冗余存储/home/bigdata/data/hadoopdata/namedfs.blocksizeHDFS块大小比方268435456，即256MBdfs.datanode.data.dirdatanode的数据存储目录，如果用逗号隔开，那每个目录都冗余存储/home/bigdata/data/hadoopdata/datadfs.replication正本个数3dfs.secondary.http.addresssecondarynamenode运行节点的信息bigdata02:50090yarn-site.xml配置yarn的ResourceManager和NodeManager信息。门路：etc/hadoop/yarn-site.xml。这个是xml文件，配置在configuration节点上面。 参数形容参数值yarn.resourcemanager.hostname主节点的地位bigdata04yarn.nodemanager.aux-servicesMapReduce利用须要的shuffle服务mapreduce_shuffle/mapred-site.xml配置MapReduce利用。门路：etc/hadoop/mapred-site.xml。这个是xml文件，配置在configuration节点上面。 参数形容参数值mapreduce.framework.name执行框架设置为Hadoop YARNyarnSlaves文件配置slave节点，门路：etc/hadoop/slaves。内容如下： bigdata01bigdata02bigdata03bigdata04散发各环境scp -r hadoop-2.7.7 bigdata02scp -r hadoop-2.7.7 bigdata03scp -r hadoop-2.7.7 bigdata04环境变量每个环境都执行以下命令 # 进入文件vim ~/.bashrc# 新增配置export HADOOP_HOME=/home/bigdata/apps/hadoop-2.7.7 export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin运行集群初始化，执行以下命令，留神仅第一次的时候须要。 ...

Hadoop-离线批处理技术 作者 | WenasWei 一 HadoopHadoop是一个由Apache基金会所开发的分布式系统基础架构。充分利用集群的威力进行高速运算和存储。 Hadoop的框架最外围的设计就是：HDFS1和MapReduce2。HDFS为海量的数据提供了存储，而MapReduce则为海量的数据提供了计算。 Apache Hadoop软件库是一个框架，该框架容许应用简略的编程模型跨计算机集群对大型数据集进行分布式解决。它旨在从单个服务器扩大到数千台机器，每台机器都提供本地计算和存储。库自身不依赖于硬件来提供高可用性，而是被设计用来检测和解决应用程序层的故障，因而能够在计算机集群的顶部提供高可用性服务，每台计算机都容易呈现故障。 二 Hadoop特点Hadoop 是一个可能对大量数据进行分布式解决的软件框架, 反对C++,Java开发语言,其带有用Java语言编写的框架,因而运行在 Linux 生产平台上是十分现实的。 2.1 Hadoop的长处1.高可靠性: Hadoop按位存储和解决数据的能力值得人们信赖, 假如计算元素和存储会失败，它保护的多个工作数据正本，确保可能针对失败的节点从新散布解决。2.高扩展性: Hadoop是在可用的计算机集簇间调配数据并实现计算工作的，这些集簇能够不便地扩大到数以千计的节点中。3.高效性: Hadoop可能在节点之间动静地挪动数据，并保障各个节点的动态平衡，因而处理速度十分快，且并行的形式工作，通过并行处理放慢处理速度。4.高容错性: Hadoop可能主动保留数据的多个正本，并且可能主动将失败的工作重新分配。5.低成本:与一体机、商用数据仓库以及其余的数据集市相比，hadoop是开源的，我的项目的软件老本因而会大大降低。2.2 Hadoop的毛病1、不能做到低提早: 高数据吞吐量做了优化，就义了获取数据的提早。2、不适宜大量的小文件存储。3、文件批改效率低: 不反对任意批改文件和不反对多人同时进行写操作, HDFS 适宜一次写入，屡次读取的场景。三 Hadoop的意义Hadoop 曾经不只是一个大数据框架，它逐步演变成为 Hadoop 生态系统。Hadoop 生态系统中涵盖了各种各样的大数据处理技术，包含Hadoop、Storm、Spark、Hive、Zookeeper、Flume、Kafka等一系列技术和框架，未然成为大数据处理的事实标准。 Hadoop的分布式架构，将大数据处理引擎尽可能的凑近存储数据，对例如像 ETL3 这样的批处理操作绝对适合，因为相似这样操作的批处理后果能够间接走向存储。Hadoop 的 MapReduce 性能实现了将单个工作打碎，并将碎片工作(Map)发送到多个节点上，之后再以单个数据集的模式加载(Reduce)到数据仓库里。 hadoop次要的性能就是用来解决大数据: 首先，大数据能够对顾客群体细分而后对每个群体因地制宜般的采取独特的口头。第二点，使用大数据模仿实境，挖掘新的需要和进步投入的回报率。当初越来越多的产品中都装有传感器，汽车和智能手机的遍及使得可收集数据出现爆炸性增长。第三点，进步大数据成绩在各相干部门的分享水平，进步整个治理链条和产业链条的投入回报率。大数据能力强的部门能够通过云计算、互联网和外部搜索引擎把大数据成绩和大数据能力比拟单薄的部门分享，帮忙他们利用大数据发明商业价值。第四点，进行商业模式产品和服务的翻新。大数据技术使公司能够增强已有的产品和服务，发明新的产品和服务，甚至打造出全新的商业模式。四 Hadoop的整体架构4.1 Hadoop的外围组件Hadoop的外围组件别离是： MapReduce: 分布式计算框架HDFS：hadoop的数据存储工具YARN4：Hadoop 的资源管理器Common 工具: 封装的一些罕用底层工具 (1) MapReduce-分布式计算框架MapReduce 编程模型借鉴了 "分而治之" 的思维,将一个大而简单的计算问题分解成多个小的计算问题，由多个map()函数对这些合成后的小问题进行并行计算，输入两头计算结果，而后由 reduce() 函数对 map() 函数的输入后果进行进一步合并，得出最终的计算结果。 注: 一篇具体MapReduce介绍: 跳转链接(2) HDFS-数据存储工具Hadoop分布式文件系统(HDFS)是指被设计成适宜运行在通用硬件(commodity hardware)上的分布式文件系统。而且是一个高度容错性的零碎，适宜部署在便宜的机器上。HDFS能提供高吞吐量的数据拜访，非常适合大规模数据集上的利用。HDFS放宽了一部分POSIX束缚，来实现流式读取文件系统数据的目标。 HDFS采纳Java语言开发，因而任何反对Java的机器都能够部署Namenode或Datanode。 HDFS采纳master/slave架构, 即主从模式。一个HDFS集群是由一个Namenode和肯定数目的Datanodes组成。Namenode是一个核心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的拜访。集群中的Datanode个别是一个节点一个，负责管理它所在节点上的存储。HDFS裸露了文件系统的名字空间，用户可能以文件的模式在下面存储数据。从外部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作，比方关上、敞开、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责解决文件系统客户端的读写申请。在Namenode的对立调度下进行数据块的创立、删除和复制。 (3) YARN-资源管理器YARN-资源调度框架是从Hadoop2.0版本开始引入的, 引入之前, MapReduce框架的外围 Job Tracker(作业跟踪者), JobTracker 须要与集群中的机器定时通信 (heartbeat), 须要治理哪些程序应该跑在哪些机器上，须要治理所有 job 失败、重启等操作，还须要和数据元数据中心通信，理解数据分布等等, 既当爹又当妈的意思，即既做资源管理又做任务调度/监控。Task Tracker资源划分过粗放，二大部分工作是能够高度一致的监控工作。 ...

Hadoop和Spark都是目前支流的大数据框架，然而随着Spark在速度和易用性方面体现出的劣势，一些国内外专家逐步推崇Spark技术，并且认为Spark才是大数据的将来。本文将会浅析Hadoop生态的倒退历程及其中局部组件的技术原理，最终就Hadoop是否会被Spark取代给出论断。 一、Hadoop的外围组件在对Hadoop外围组件进行介绍之前，咱们须要先理解Hadoop解决了什么问题。Hadoop次要就是解决了大数据（大到一台计算机无法进行存储，一台计算机无法在要求的工夫内进行解决）的牢靠存储和解决。 Hadoop的外围组件次要有三个，别离是：HDFS、YARN和MapReduce。HDFS是是google三大论文之一的GFS的开源实现，是一个高度容错性的零碎，适宜部署在便宜的机器上的，适宜存储海量数据的分布式文件系统。而YARN是Hadoop的资源管理器，能够视为一个分布式的操作系统平台。相比于HDFS和YARN，MapReduce能够说是Hadoop的外围组件，以下会就MapReduce进行重点探讨。 MapReduce，通过简略的Mapper和Reducer的形象提供一个编程模型，能够在一个由几十台上百台的PC组成的不牢靠集群上并发地，分布式地解决大量的数据集，而把并发、分布式（如机器间通信）和故障复原等计算细节暗藏起来。而Mapper和Reducer的形象，又是各种各样的简单数据处理都能够合成为的根本元素。这样，简单的数据处理能够合成为由多个Job（蕴含一个Mapper和一个Reducer）组成的有向无环图（DAG）,而后每个Mapper和Reducer放到Hadoop集群上执行，就能够得出后果。 在MapReduce中，Shuffle是一个十分重要的过程，正是有了看不见的Shuffle过程，才能够使在MapReduce之上写数据处理的开发者齐全感知不到分布式和并发的存在。 狭义的Shuffle是指图中在Map和Reuce之间的一系列过程。 二、Hadoop的局限和改良只管Hadoop提供了解决海量数据的能力，然而Hadoop的外围组件——MapReduce的应用问题还是始终困扰着Hadoop的倒退，MapReduce的局限次要能够总结为以下几点： 抽象层次低，须要手工编写代码来实现，应用上难以上手只提供两个操作，Map和Reduce，表达力欠缺一个Job只有Map和Reduce两个阶段（Phase），简单的计算须要大量的Job实现，Job之间的依赖关系是由开发者本人治理的解决逻辑暗藏在代码细节中，没有整体逻辑两头后果也放在HDFS文件系统中ReduceTask须要期待所有MapTask都实现后才能够开始时延高，只实用Batch数据处理，对于交互式数据处理，实时数据处理的反对不够对于迭代式数据处理性能比拟差比如说，用MapReduce实现两个表的Join都是一个很有技巧性的过程，如下图所示： 因而，在Hadoop推出之后，呈现了很多相干的技术对其中的局限进行改良，如Pig，Cascading，JAQL，OOzie，Tez，Spark等，上面就对一些重要技术进行重点的探讨。 1.Apache PigApache Pig是Hadoop框架中的一部分，Pig提供类SQL语言（Pig Latin）通过MapReduce来解决大规模半结构化数据。而Pig Latin是更高级的过程语言，通过将MapReduce中的设计模式形象为操作，如Filter，GroupBy，Join，OrderBy，由这些操作组成有向无环图（DAG）。例如如下程序就形容了数据处理的整个过程。 visits = load ‘/data/visits’ as (user, url, time);gVisits = group visits by url;visitCounts = foreach gVisits generate url, count(visits);urlInfo = load ‘/data/urlInfo’ as (url, category, pRank);visitCounts = join visitCounts by url, urlInfo by url;gCategories = group visitCounts by category;topUrls = foreach gCategories generate top(visitCounts,10);store topUrls into ‘/data/topUrls’;而Pig Latin又是通过编译为MapReduce，在Hadoop集群上执行的。上述程序被编译成MapReduce时，会产生如下图所示的Map和Reduce： Apache Pig解决了MapReduce存在的大量手写代码，语义暗藏，提供操作品种少的问题。相似的我的项目还有Cascading，JAQL等。 2.Apache TezApache Tez，Tez是HortonWorks的Stinger Initiative的的一部分。作为执行引擎，Tez也提供了有向无环图（DAG），DAG由顶点（Vertex）和边（Edge）组成，Edge是对数据的挪动的形象，提供了One-To-One，BroadCast，和Scatter-Gather三种类型，只有Scatter-Gather才须要进行Shuffle。 ...

公开音讯示意，Apache 软件基金会在短短 11 天内发表归档（attic）19个开源我的项目，与大数据无关的有 13 个，其中 10 个我的项目属于 Hadoop 生态系统，包含 Sentry、Tajo 和 Falcon 等。 从整体上看，这次的行为无疑是一个“行业的分水岭”，能为从业者以及行业观察者提供一些趋势类的剖析与察看。与大数据无关的已报废的 Apache 我的项目包含如下： Apex：这个对立的平台面向大数据流和批处理，基于 Hadoop YARN。Chukwa：这个数据收集零碎用于监控大型分布式系统，基于 Hadoop 分布式文件系统（HDFS）。Crunch，它提供了一套框架，用于编写、测试和运行 MapReduce（包含 Hadoop MapReduce）管道。Eagle：这种剖析解决方案用于立刻发现大数据平台（包含 Hadoop）的平安和性能问题。Falcon：这种面向 Hadoop 的数据处理和治理解决方案，为数据挪动、数据管道协调、生命周期治理和数据发现而设计。Hama：这种用于大数据分析的框架在 Hadoop 上运行，基于 Bulk Synchronous Parallel 范式。Lens：提供对立剖析界面，将 Hadoop 与传统数据仓库集成起来，如同一个整体。Marmotta：一种面向链接数据的开放平台。Metron：专一于实时大数据安全。PredictionIO：这种机器学习服务器用于治理和部署生产就绪的预测服务。Sentry：这种零碎用于对 Apache Hadoop 中的数据和元数据执行细粒度受权。Tajo：Hadoop 上的大数据仓库零碎。Twill：应用 Hadoop YARN 的分布式性能以及相似运行中线程的编程模型。Apache Hadoop —— “过气的宠儿”依据行业媒体的表述，“Apache Hadoop 作为今日大数据畛域的宠儿，早已过气。” 十年前，入世两年的 Hadoop 顺利通过孵化器成为了 Apache 顶级我的项目，同年，第一个 Hadoop 商业化公司 Cloudera 成立；数年前，几乎就是 Hadoop 的主场，社区一直建设的新组件来扩大 Hadoop 的利用场景和可用性，其中有很多组件都胜利脱离 Hadoop 成为了 Apache 顶级我的项目，例如 HBase、Hive、ZooKeeper 等。 这也让 Hadoop 成为近十年来大数据畛域的典型代表。它陈腐，它开源，它催生出整个产品与供应商市场。 ...

Hadoop学习笔记—Yarn@(Hadoop)[hadoop, yarn] [TOC] 上一份工作次要负责大数据平台的建设，在这个过程中积攒了一些Hadoop生态组件的搭建和应用笔记，因为工夫关系，不打算去批改其中的错别字和排版问题，间接释出原始笔记。一些基本知识ResourceManager 的复原当ResourceManager 挂掉重启后，为了使之前的工作可能继续执行，而不是从新执行。势必须要yarn记录利用运行过程的状态。 运行状态能够存储在 ZooKeeperFileSystem 比方hdfsLevelDB应用zookeeper做为状态存储的典型配置为 <property> <description>Enable RM to recover state after starting. If true, then yarn.resourcemanager.store.class must be specified</description> <name>yarn.resourcemanager.recovery.enabled</name> <value>true</value> </property> <property> <description>The class to use as the persistent store.</description> <name>yarn.resourcemanager.store.class</name> <value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value> </property> <property> <description>Comma separated list of Host:Port pairs. Each corresponds to a ZooKeeper server (e.g. "127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002") to be used by the RM for storing RM state. This must be supplied when using org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore as the value for yarn.resourcemanager.store.class</description> <name>hadoop.zk.address</name> <value>127.0.0.1:2181</value> </property>Resource Manager的HA基于zookeeper实现active 和standby 的多个ResourceManager之间的主动故障切换。 active Resource Manager只能有一个，而standby 能够有多个 ...

[TOC] 上一份工作次要负责大数据平台的建设，在这个过程中积攒了一些Hadoop生态组件的搭建和应用笔记，因为工夫关系，不打算去批改其中的错别字和排版问题，间接释出原始笔记。搭建装置三个外围组件一个hadoop根本集群,关涉三个组件: hdfs 负责分布式的文件存储yarn 负责分布式的资源管理mr 负责分布式计算 装置配置环境变量配置etc/hadoop/hadoop-env.sh、etc/hadoop/hadoop-env.sh、etc/hadoop/yarn-env.sh 这三个脚本来配置三个组件执行的环境变量当然，机器特定的环境变量能够放在 /etc/profile.d 中 最重要的是在上述三个shell脚本的最初，配置JAVA_HOME。上述三个shell中，有大量环境变量KEY能够配置，他们个别见名知意。能够应用一些带OPTS后缀的配置，去笼罩那些特定配置。带OPTS的后缀有 比方HADOOP_HEAPSIZE_MAX=1g 能够被HADOOP_NAMENODE_OPTS="-Xmx5g" 所笼罩 配置各上述三组件守护过程的相干属性上述环境变量配置好后，就要配置hdfs, yarn, mr三者的过程，即程序执行的行为属性。其别离对应的配置文件为 etc/hadoop/core-site.xml 、etc/hadoop/hdfs-site.xml 用于给hdfs配置etc/hadoop/yarn-site.xml 用于给yarn配置etc/hadoop/mapred-site.xml 用于给mr配置具体看文档即可，这里对一些有意思的配置单列阐明hdfs的配置 dfs.namenode.name.dir namenode的数据存储门路，多个文件，示意数据存多份，进步冗余yarn的配置 yarn.log-aggregation-enable 启动log aggregation，这会将yarn集群中执行利用的本地日志，复制到hdfs集群中进行高可用治理启停能够针hdfs，mr，yarn三个组件的各角色进行启动。 其中Hdfs的各角色，能够应用etc/hadoop/workers配置，通过$HADOOP_HOME/sbin/start-dfs.sh批量启动。 具体启停看文档 监控和性能Hadoop Rack AwarenessHadoop Rack Awareness，启用该个性，让Hadoop集群感知物理存储拓扑，从而更好的进步数据分片性能，具体看文档 yarn的NodeManagers监控能够指定一些监控nodeManager状态的脚本给NodeManager, NodeManager会周期性的调用，查看本人的状态，yarn则会收集该状态，而后不会将程序散发到这些异样NodeManager上执行 命令文档地址：https://hadoop.apache.org/doc... hdfs的命令如果hadoop操作的是hdfs,那么上面两种命令格局等效 bin/hadoop fs <args>hdfs dfs <args>hadoop fs的相干命令反对多种文件系统 hdfs hadoop本人的分布式文件系统Local FS 本地文件系统，即为以后机器的文件系统WebHDFSS3 FS 亚马逊的分布式文件系统hadoop fs命令个别操作的文件系统门路格局URI为scheme://authority/path，比方hdfs举例hdfs://namenodehost/parent/child appendToFile将本地单个文件或多个文件，或则本机的规范输出中的内容，拷贝到指标文件系统用法：hadoop fs -appendToFile <localsrc> ... <dst> hadoop fs -appendToFile localfile /user/hadoop/hadoopfilehadoop fs -appendToFile localfile1 localfile2 /user/hadoop/hadoopfilehadoop fs -appendToFile localfile hdfs://nn.example.com/hadoop/hadoopfilehadoop fs -appendToFile - hdfs://nn.example.com/hadoop/hadoopfile Reads the input from stdin.Returns 0 on success and 1 on error. ...

在安卓手机装置应用 hadoop 遇到的问题因为新的 termux 在安卓 10 装置不了 Java ，所以在 termux 里装置了 fedora 零碎。还有问题，更换了 debian 零碎。 筹备在 debian 中应用 apt 装置 java useradd hadoop # 新建用户并给予明码passwd hadoop# apt install sudo # 可先项# vi /etc/sudoers# echo "hadoop ALL=(ALL) ALL" >> /etc/sudoersalias pk="apt install -y"pk openjdk-11-jdkpk ssh pdsh # ssh 登陆用su - hadoop# 配置变量vi ~/.bashrc # ~/.zshenv or ~/.zshrc or ~/.profile.d 备选装置 zshexport JAVA_HOME=/usr/lib/jvm/java-11-openjdk-arm64export PATH=$JAVA_HOME/bin:$PATH:wq或间接下载 openjdk 版的 javaJAVA_HOME 是解压后的根目录配置 ssh# pk ssh pdshexport PDSH_RCMD_TYPE=ssh # 配置变量，不配置会呈现问题pdsh -q -w localhost | grep Rcmd # 查看是否 ssh 默认的如同是 rsh ，下面一个命令用来批改# 配置免明码登陆 ssh ，密钥登陆ssh-keygenecho ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys# ssh-copy-id# sed -i 's/^Port/Port 8222/' /etc/ssh/sshd_configvi /etc/ssh/sshd_config # 批改 sshd 端口 因为手机里不能用 22 端口，也防止与 termux 的 8022 抵触Port 8222PubkeyAuthentication yes:wq# root 用户启动 sshd/usr/sbin/sshd # ***容易出问题的中央# 测试免明码登陆ssh localhost -p 8222# pkill sshd 配置 /root/.bashrc 主动启动 sshd[[ -n $SSH_CONNECTION ]] && /usr/sbin/sshd下载 hadoop 源码并解压hadoop download ...

一、hadoop 简介hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户能够在不理解分布式底层细节的状况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。 龙芯3A2000上运行Hadoophadoop实现了一个分布式文件系统（hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来拜访应用程序的数据，适宜那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，能够以流的模式拜访（streaming access）文件系统中的数据。 hadoop的框架最外围的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。 hadoop是一个可能对大量数据进行分布式解决的软件框架, 它以一种牢靠、高效、可伸缩的形式进行数据处理。保护多个工作数据正本，确保可能针对失败的节点从新散布解决。并行工作形式，进步处理速度,之处解决PB级数据。hadoop是一个可能让用户轻松架构和应用的分布式计算平台。用户能够轻松地在hadoop上开发和运行解决海量数据的应用程序。它次要有以下几个长处： 高可靠性: hadoop按位存储和解决数据的能力值得人们信赖。高扩展性: hadoop是在可用的计算机集簇间调配数据并实现计算工作的，这些集簇能够不便地扩大到数以千计的节点中。高效性: hadoop可能在节点之间动静地挪动数据，并保障各个节点的动态平衡，因而处理速度十分快。高容错性:hadoop可能主动保留数据的多个正本，并且可能主动将失败的工作重新分配。低成本: 与一体机、商用数据仓库以及QlikView、Yonghong Z-Suite等数据集市相比，hadoop是开源的，我的项目的软件老本因而会大大降低。 本文次要波及以下内容：hadoop源码编译，hadoop在分布式计算云存储系统中的部署和利用,同时也将记录hadoop搭建过程的FAQ和绝对解决方案。hadoop 集群(cluster) 反对如下3种操作模式： Local/Standalone Mode： 实现下载后，默认状况下hadoop 被配置为Standalone 模式，作为单个JavaPseudo Distributed Mode此种模式下,每个hadoop 守护过程,如hdfs,yarn,MapReduce 等分布式部署在不同的机器上，别离作为独立的Java 过程，这种模式有助于开发。Fully Distributed Mode齐全分布式部署，须要至多2台机器，作为一个集群，稍后进行详解。二、移植环境首先给出本机的软硬件信息，软件环境：(1)loongnix1.0 零碎（2016.8.10版本）。下载地址 www.loongnix.org(2)内核版本:3.10.84-all(3)JDK版本:1.8.0_25-rc16-b17 or later(4)MAVEN:3.2.2 or later 硬件环境:(1)开发板类型: Loongson-3B-780E-2w-V0.2-demo(2)固件版本: loongson-PMON-V3.3.0 本例中应用的hadoop的版本为2.7.2, hadoop 源码下载地址，参见附录中的”hadoop downloads” 链接。hadoop 编译依赖findbugs和cmake软件包，倡议在编译前通过yum 命令进行主动装置,装置形式如下: [hadoop@localhost log]$ sudo yum -y install java-1.8.0-openjdk-devel java-1.8.0-openjdk-headless \ java-1.8.0-openjdk findbugs cmake protobuf-compiler实现装置后，须要设置如下环境变量，倡议将以下内容追加到/et c/profile文件,并用source 命令使其失效。 export FINDBUGS_HOME=/usr/share/findbugsexport MAVEN_HOME=/usr/share/mavenexport MAVEN_OPTS="-Xms256m -Xmx512m"export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-5.rc16.fc21.loongson.mPATH=/usr/lib64/ccache:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/hexport PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/binBuild From Scratch：首先解压源码到自定义目录(本例采纳/usr/local)利用mvn ...

本文源码：GitHub || GitEE 一、Sqoop概述Sqoop是一款开源的大数据组件，次要用来在Hadoop(Hive、HBase等)与传统的数据库(mysql、postgresql、oracle等)间进行数据的传递。 通常数据搬运的组件基本功能：导入与导出。 鉴于Sqoop是大数据技术体系的组件，所以关系型数据库导入Hadoop存储系统称为导入，反过来称为导出。 Sqoop是一个命令行的组件工具，将导入或导出命令转换成mapreduce程序来实现。mapreduce中次要是对inputformat和outputformat进行定制。 二、环境部署在测试Sqoop组件的时候，起码要具备Hadoop系列、关系型数据、JDK等根底环境。 鉴于Sqoop是工具类组件，单节点装置即可。 1、上传安装包安装包和版本：sqoop-1.4.6 [root@hop01 opt]# tar -zxf sqoop-1.4.6.bin__hadoop-2.0.4-alpha.tar.gz[root@hop01 opt]# mv sqoop-1.4.6.bin__hadoop-2.0.4-alpha sqoop1.4.62、批改配置文件文件地位：sqoop1.4.6/conf [root@hop01 conf]# pwd/opt/sqoop1.4.6/conf[root@hop01 conf]# mv sqoop-env-template.sh sqoop-env.sh配置内容：波及hadoop系列罕用组件和调度组件zookeeper。 [root@hop01 conf]# vim sqoop-env.sh# 配置内容export HADOOP_COMMON_HOME=/opt/hadoop2.7export HADOOP_MAPRED_HOME=/opt/hadoop2.7export HIVE_HOME=/opt/hive1.2export HBASE_HOME=/opt/hbase-1.3.1export ZOOKEEPER_HOME=/opt/zookeeper3.4export ZOOCFGDIR=/opt/zookeeper3.43、配置环境变量[root@hop01 opt]# vim /etc/profileexport SQOOP_HOME=/opt/sqoop1.4.6export PATH=$PATH:$SQOOP_HOME/bin[root@hop01 opt]# source /etc/profile4、引入MySQL驱动[root@hop01 opt]# cp mysql-connector-java-5.1.27-bin.jar sqoop1.4.6/lib/5、环境查看 关键点：import与export 查看帮忙命令，并通过version查看版本号。sqoop是一个基于命令行操作的工具，所以这里的命令上面还要应用。 6、相干环境此时看下sqoop部署节点中的相干环境，根本都是集群模式： 7、测试MySQL连贯sqoop list-databases --connect jdbc:mysql://hop01:3306/ --username root --password 123456这里是查看MySQL数据库的命令，如图后果打印正确： 三、数据导入案例1、MySQL数据脚本CREATE TABLE `tb_user` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键id', `user_name` varchar(100) DEFAULT NULL COMMENT '用户名', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';INSERT INTO `sq_import`.`tb_user`(`id`, `user_name`) VALUES (1, 'spring');INSERT INTO `sq_import`.`tb_user`(`id`, `user_name`) VALUES (2, 'c++');INSERT INTO `sq_import`.`tb_user`(`id`, `user_name`) VALUES (3, 'java'); ...

背景工夫：2021年02月26日13:58:26 简要步骤： 确定命令是什么？确定命令的地位是是哪里？确定命令执行的主类是哪一个？依照执行流程查看例子：发现hdfs dfsadmin -report存储指标和hdfs dfs -du -h /后果不统一，须要查看两张的统计逻辑的区别 确定命令的地位，which is hdfs[ops@m-onedata bin]$ which is hdfs/usr/bin/hdfs 查看脚本，cat /usr/bin/hdfsexec /usr/.../hadoop-hdfs/bin/hdfs.distro "$@" 发现理论执行的脚本地位，持续查看执行脚本 elif [ "$COMMAND" = "dfs" ] ; then CLASS=org.apache.hadoop.fs.FsShell HADOOP_OPTS="$HADOOP_OPTS $HADOOP_CLIENT_OPTS"elif [ "$COMMAND" = "dfsadmin" ] ; then CLASS=org.apache.hadoop.hdfs.tools.DFSAdmin HADOOP_OPTS="$HADOOP_OPTS $HADOOP_CLIENT_OPTS"elif [ "$COMMAND" = "haadmin" ] ; then CLASS=org.apache.hadoop.hdfs.tools.DFSHAAdmin CLASSPATH=${CLASSPATH}:${TOOL_PATH} HADOOP_OPTS="$HADOOP_OPTS $HADOOP_CLIENT_OPTS"elif [ "$COMMAND" = "fsck" ] ; then CLASS=org.apache.hadoop.hdfs.tools.DFSck HADOOP_OPTS="$HADOOP_OPTS $HADOOP_CLIENT_OPTS"elif [ "$COMMAND" = "balancer" ] ; then CLASS=org.apache.hadoop.hdfs.server.balancer.Balancer HADOOP_OPTS="$HADOOP_OPTS $HADOOP_BALANCER_OPTS" ...

在上一次我进行了超万亿规模的Hadoop NameNode问题的排查，通过为时四天的致力，终于解决了Hadoop2.6.0版本的瓶颈问题，然而生存往往就是墨菲定律，你所竭力防止的那些最坏的可能兴许终将会产生。 为了避免遇到NameNode的第二次瓶颈，我决定将以后集群由Hadoop2.6.0版本升级到Hadoop3.2.1版本，且启用联邦模式。然而在降级之后，咱们还是遇到了很多动向不到的问题，尽管最终通过一系列的排查还是解决了这些问题，然而我认为这次集群的降级教训可能帮忙一些同学少走弯路。 上面，enjoy： 一、降级前的筹备在进行Hadoop集群降级，尤其是相似本次案例中这样上千节点的超大集群的降级，首先须要明确两点： 第一，是否的确有必要进行集群的降级，以目前的数据增长量级是否会涉及以后版本的瓶颈。 首先须要申明一点，像本次案例中这样的超大规模的Hadoop集群，降级自身的难度就极大，须要耗费十分多的人力物力去批改数据库底层源码，仅仅对于咱们产品LSQL的源码批改就破费了咱们小组整整两周工夫。更无需说我下文中会列明的在降级后会遇到的一系列问题的排查和解决，更是须要投入极大的工夫精力。 本次咱们抉择进行Hadoop集群降级的次要起因是因为原先2.6.0版本过老，可能会存在其余未发现的问题。同时客户每天有近千亿条的数据增长，如不进行降级，很快还是会遇到NameNode的第二次瓶颈。如果客户在以后版本零碎可能稳固运行，并且将来的数据体量不会有大幅增长，咱们也不会采取降级集群的计划。 第二，是否做足了降级前的筹备工作，以及是否有应答降级呈现的各类问题的应急计划。 在本次降级前咱们就做了大量的后期筹备工作。咱们进行了屡次的降级演练，确保能应答在降级过程中呈现的各类突发状况。同时鉴于客户数十万亿的生产零碎的个性决定了在降级过程中决不能呈现失落数据或者服务长时间进行的状况。为此，咱们制订了一旦降级呈现问题就会采取的零碎回退计划，遭逢数据失落的挽回计划，以及在降级后的功能性验证等。 二、  降级后所呈现的问题&解决1.Hadoop跨多个联邦后，速度不快反慢实践上，Hadoop升级成跨联邦机制，读写申请会别离平衡到三个不同的NameNode上，升高NameNode负载，晋升读写性能，然而事实是NameNode负载岂但没有升高，相同变得十分十分慢。 对于目前集群的卡顿水平，是必定无奈满足生产零碎的运行需要的。而此时降级曾经进行了三天了，如果卡顿问题不能失去解决，哪怕咱们心有不甘也只能立刻启动回退计划。然而毕竟咱们都为这次降级筹备了许久，而且客户也很期待降级后所带来的性能晋升，我微微抚了抚头顶那沉睡多年的毛囊，一狠心决定连夜奋战。 首先须要做的就是定位造成卡顿的起因，我先从堆栈动手，发现次要问题还是NameNode卡顿，生产零碎曾经不能持续考察上来了，如果不想回退零碎，就得让零碎可用，那就只能从咱们最相熟的中央下手---批改录信LSQL，给所有申请NameNode文件的中央加上缓存，只有申请过的文件，就缓存下来，防止二次申请NameNode。 录信LSQL批改后NameNode状态有十分大的改善，零碎根本可用。但具体为何降级到联邦后NameNode的吞吐量不升反降，咱们没能给出正当的解释，只能初步判定是因为历史数据还在一个联邦上，导致数据的散布不平衡，心愿之后能随着新数据的逐渐导入，从新造成一个较为平衡的态势。 2.降级联邦后数据库稳定性升高，极易挂掉在进行降级之后，咱们发现简直每隔几天咱们的数据库系统LSQL就会挂掉一次。 察看录信LSQL的宕机日志，发现有大量的如下输入，证实Hadoop NameNode常常位于standby模式，导致Hadoop服务整体不可用，从而引起录信LSQL数据库宕机。 进一步剖析NameNode发现Hadoop的NameNode并未宕机，active与standby都活着。联合Zookeeper日志剖析发现，期间产生了NameNode的activer与standby的切换。 这里波及两个问题，一是为什么产生了主备切换，二是切换过程中是否会导致服务不可用。 针对主备切换的起因，通过比照切换产生的工夫，发现切换时NameNode做了比拟大的负载申请，如删除快照，或者业务进行了一些负载较大的查问。这很有可能是因为NameNode负载较高，导致的Zookeeper链接超时。具体为什么NameNode负载很高，这个咱们在前面论述。 至于切换过程中是否会导致服务不可用，咱们做了测试。第一次测试，间接通过Hadoop 提供的切换命令切换，后果切换对服务没有影响。第二次测试，间接将其中的Active NameNode给kill掉，问题复现了。可见在Hadoop 3.2.1版本里，active 与standby的切换，在切换过程中，是存在服务不可用的问题的。咱们针对报错地位进一步剖析如下： 看RouterRpcClient类的设计实现，应该是存在failover的逻辑。相干配置参数key值如下： 最终剖析RouterRpcClient.java这个类，发现其设计逻辑是有问题的，尽管预留了下面那些参数，但没有失效，NameNode在主备切换过程中，存在两个NameNode同时处于Standby的过程。并且这个阶段，会间接报错，导致因报错而服务不可用。 咱们具体浏览了该类的实现，发现该类尽管预留了重试的逻辑，然而这些重试的逻辑并没失效，存在BUG，故咱们对此进行了修复。修复后录信LSQL的宕机问题不再呈现，如下是波及源码的剖析过程： 如下是修复版本后，router重试过程中记录的日志： 3.数据库查问呈现间接性卡顿Hadoop降级到3.2.1版本后，录信LSQL会呈现间歇性的卡顿情景，导致业务查问页面总是在“转圈圈”。 到现场后第二天遇到了该景象，通过了一系列的排查和追踪，最终定位在Hadoop 的NameNode卡顿（是不是很相熟的感觉，没错它又来了......）。具体体现在进行一次ls操作，会卡顿20~30秒的工夫。进入NameNode节点的机器察看负载状况，发现CPU的负载占用在3000%高低。 后通过屡次抓取jstack，发现导致NameNode卡顿的堆栈的地位点如下： 没错，是addBlock，也就是写数据的写锁会阻塞所有的查问。依照以往的教训，咱们认为是上图中的锁引起的，故咱们进行了去锁操作。 因为NameNode主备切换的问题曾经解决，所以咱们能够在生产零碎通过热切的形式来验证咱们的问题。去锁后的后果十分蹩脚，卡顿景象岂但没有缩小，相同变得更重大，整台NameNode的负载岂但没有升高，反而间接飙升到全满。 没方法，咱们只好持续排查起因，仔细分析该类的相干实现，最终发现如下问题： 联合下面的起因，咱们略微改了下代码实现。 经剖析发现每进行一次addBlock的申请，这里就会产生一次循环，这是一个机架上的所有机器。这意味着每调用一次addBlock办法，NameNode就要对一个机架内的设施进行一次循环，集群设施上千台，就是循环上千次，那这CPU使用率还了得！之前加锁状态，因为有锁的限度，只是会导致写入慢，查问还算可用。当初把锁去掉了，罗唆CPU飚满，更是查不动了。而后jstack发现卡顿的中央变了，如下图所示： 咱们长期调整NameNode的日志级别，调整为DEBUG级别，看到了如下的输入，更是进一步的验证了咱们的想法。 同时咱们比照了下Hadoop2.8.5版本的源码，发现这个中央的逻辑在Hadoop3.2.1中做了较大的变更。存在设计不当的问题，这种循环形式会消耗很多CPU。设计的本意是随机抽取节点，却要遍历一个机架下的所有节点，挨个加一遍锁。为了一次addBlock，平白无故加了几百次锁，哪能这样设计呢？咱们仿照2.8.5的一些写法，从新修改了一下，针对这里的随机形式进行了从新革新。 改变结束后，再持续抓jstack，解体的是，这块的逻辑的确抓不到了，但又在别的中央呈现了，一样有个相似的循环。具体看代码发现Hadoop3.2.1的这个类外面，这样的循环太多了，在生产零碎上改不起，也不敢改了。只能转变思路来解决，如果是因为这个循环的问题导致的NameNode卡顿，为何不是始终卡顿，而是间歇性卡顿，理分明这个思路，兴许就关上了一扇窗。 （1）SSD机器的Xreceiver引发的血案 咱们剖析了循环里的IP列表（DataNode的IP），并且联合现场日志的设施，发现了一个法则，这些循环外面的IP，均是SSD设施的IP，并非是SATA设施的IP。现场设施分为六组，每组一个机架，SATA和SSD各占一半。从IP的法则上来看，这些IP均是SSD设施。进一步剖析，什么状况下这些DN会被退出到这个循环外面，从日志和源码剖析，咱们最终定位在Exclude上，也就是说Hadoop认为这些设施是坏了的，是应该被排除掉的设施。 难道是咱们的SSD设施全都宕机了，或者他们的网络有问题？但通过排查，咱们排除了这些问题。问题又回归到了源码层面，通过了大概1天的追踪定位，发现如下逻辑： Hadoop在抉择写入DN的时候，会思考到DN的负载状况，如果DN负载比拟高，它会将这个节点退出到Execude外面，从而排除掉这个节点，以此判断一个DN负载高下的就是Xreceiver的链接数量。默认状况下，只有Xreceiver的链接数量超过了整个集群连贯数量的2倍，就会排除掉这个节点。而LSQL自身采纳了异构的个性，意味着咱们会优先从SSD盘读取数据，而SSD盘设施的性能好，数量又绝对较少，导致这些SSD设施的机器连接数远高于SATA盘的链接数。SATA盘冷数据偏多，简直很少有人去查问。针对这一状况，就会呈现在一瞬间，因为连接数的问题，导致所有的或大多数的SSD设施被排除掉的情景。 ...