Android路上的人-CSDN博客

原创 HDFS精华文章汇总

前言自2015年下半年起，笔者开始写关于Hadoop的文章（主要集中在HDFS），包括源码分析类的，问题分析解决又或者是内部机制剖析。这些文章目前汇总数量已经达到70+篇。这些文章对于笔者来说是一个宝贵的资料，这些文章见证了笔者从一名Hadoop贡献者成长为Hadoop Committer的过程。同样笔者相信，这些文章对于那些对HDFS感兴趣的人同样是很好的学习资料。因此，笔者觉得是时候写一篇文章来

2017-12-03 11:45:14 6891 2

原创 18大经典数据挖掘算法小结

本文所有涉及到的数据挖掘代码的都放在了我的github上了：https://github.com/linyiqun/DataMiningAlgorithm大概花了将近2个月的时间，自己把18大数据挖掘的经典算法进行了学习并且进行了代码实现，涉及到了决策分类，聚类，链接挖掘，关联挖掘，模式挖掘等等方面。也算是对数据挖掘领域的小小入门了吧。下面就做个小小的总结，后面都是我自己相应算法的博文链接，希

2015-02-27 10:04:01 18980 17

原创 Redis源码分析（三十六）--- Redis中的11大优秀设计

坚持了一个月左右的时间，从最开始的对Redis的代码做分类，从struct结构体分析开始，到最后分析main主程序结束，中间，各大模块的代码逐个击破，学习，总之，收获了非常多，好久没有这么久的耐心把一个框架学透，学习一个框架，会用那只是小小的一部分，能把背后的原理吃透才是真功夫。在这个学习的最后阶段，是时候要来点干货了，我把这1个多月来的一些总结的一些比较好的代码，和设计思想总结出来了，原本想凑成

2014-11-08 10:16:37 21643 8

原创 HDFS PB级数据无感迁移实践

前面文章笔者介绍了比较多关于HDFS RBF如何来解决多集群协调管理的问题，RBF里的Router服务在里面扮演着一个很重要的角色。它能让众多的NN对于client来说完全透明，鉴于这一点，我们可以很好地依托Router服务来做到数据的无感迁移，从而间接达到平衡各个namespace RPC load的效果。本文笔者将要阐述的是我们如何在RBF模式下做到数据的无感迁移。关于大体量数据的迁移，笔者在前年做过一次PB级规模的数据迁移实践(HDFS千万级别文件数/PB规模量级的数据迁移实战总结)，不过这次随着集群

2022-06-12 23:35:54 960 3

原创 HDFS RPC限流方案实践探索

文章目录前言HDFS RPC限流方案分级RPC queue的调参分级RPC queue的insight前言在前面的一篇关于分布式集群下的限流方案文章里，笔者阐述了一种在HDFS集群里的RPC限流架构。其间也提到了很多关于分布式限流架构里的关键要素，包括用户区分，分级队列的概念等等。不过上次文章更多偏向于理论原理篇，本文笔者将结合实际生产环境的特点，来给大家讲讲如何真正将限流方案实施到生产集群，并能够达到预期的效果。HDFS RPC限流方案这里要首先聊聊笔者目前集群所将要采用的HDFS RPC限流

2022-05-22 16:23:53 963

原创 HDFS DataNode高密度存储机型的探索尝试

前言随着公司业务的发展，我们需要存储越来越庞大的数据来支撑公司业务的发展。这里就涉及到了数据存储能力的问题，需要存储的数据越多，其实意味着我们需要更多的机器来扩增HDFS集群存储的总capacity。但是机器数量的变多另外一方面带来的则是机器费用成本的巨大开销。我们如何在保证机器开销前提下，最大程度提升单机器的存储能力，这个就成为了一个集群维护人员需要思考和解决的问题。鉴于这个出发点，笔者最近在研究调研新一代具有更高存储能力的机型，这期间笔者做了大量的场景设置和性能测试来判断此机型是否能达到集群的要求。

2022-04-22 17:13:20 1065 4

原创 HDFS简化版Maintenance state实现

文章目录前言前言在HDFS集群运维过程中，我们经常会遇到机器送修的情况，尤其在集群机器数量比较多的情况，每天因为坏盘或是其它硬件问题导致的机器维修是很常见的。对于集群维护者来说，机器的这种日常损坏我们是无法回避的，我们能做的是如何将这种机器维修的所造成的影响降低到最小。在现有的HDFS中，社区提供了一种叫做Maintenance state的功能来专门处理这种情况的。本文笔者来谈谈这个特殊的功能以及我们内部是如何简化此特性来方便于我们的使用的。Maintenance state DataNode和普

2022-02-08 20:11:23 1160

原创分布式集群下的RPC限流方案

文章目录前言前言如今在大数据时代，面对如今规模数据体量快速增长的一个阶段，HDFS单集群模式已经无法支撑更加平稳高效的数据服务能力。多集群联合模式逐渐成为一种新的架构尝试，笔者所在公司亦是如此。我们内部目前采用了社区的RBF（Router-based Federation ）方案来做统一的数据服务。最近我们在尝试解决一个棘手的问题：多用户的RPC隔离问题。这个问题其实在原始HDFS单集群模式本身也是存在的，但是在多集群模式下这个问题只会变得更为严重。多集群模式下，更多的用户数据被写入到集群，而这也意味

2022-01-03 21:33:54 1785 2

原创 HDFS block access token认证机制

文章目录前言Block access tokenHDFS block access token的原理前言在存储系统中，数据的安全性无疑是十分重要的。在我们常见的文件系统中，最常使用的方式是通过文件目录的权限来做数据访问的控制。在HDFS这样分布式存储系统中，其内部实现同样沿用了这样的方式来做数据访问的控制。但是在HDFS拥有如此海量数据规模的系统中，我们只做文件权限的检查是足够安全的吗？鉴于HDFS的架构设计，权限检查是发生在NameNode端的，这时倘若一个恶意用户绕过了文件权限检查，然后直接访问实

2021-12-28 18:07:56 1866 1

原创 HDFS Multiple Standby的优化实践

在前面的文章中，笔者介绍过一篇关于介绍HDFS Multiple Standby功能的原理文章。从代码改动来看，HDFS Multiple Standby并没有对NameNode的核心机制做大的改动，而是进行了多Standby模式的一个适配。关于Multiple Standby这个功能本身，它确实能够增强NameNode服务的整体可靠性。假设我们使用

2021-12-19 21:17:04 521

原创 HDFS数据跨区域存储分布

文章目录前言跨区域存储和跨rack存储的区别HDFS跨区域存储实现前言在上篇文章HDFS多rack分布的block placement policy设计实现里，笔者探讨了HDFS数据副本跨多rack分布的新placement方案，以此来提高数据的可用性。因为在日常集群运行过程中，是可能存在因为集群的操作维护导致短时间内一整个rack处于停服务状态的。按照HDFS三副本的存放策略，一整个rack离线意味着2/3的拷贝丢失了，这将极大增加数据不可访问的概率。本文我们来继续深入探讨这一话题，既然数据副本已经能

2021-09-19 17:47:35 2334 2

原创 HDFS RBF模式RPC吞吐量瓶颈的优化探索

文章目录前言RBF模式的RPC吞吐量问题原因猜想网络延时的影响Router本身服务处理的影响前言之前笔者介绍过HDFS的RBF方案来解决HDFS NameNode单点瓶颈的问题。目前也是有越来有多的公司采用RBF的方案来做HDFS集群的统一管理。笔者在最近一段时间也是在调研RBF的特性同时也是测测这里面还有没有一些没有被发现的问题。在此期间，我和同事小伙伴发现里面最大的一个问题：上了RBF后，RPC的上限吞吐量比之前直连NN时降了非常之多。之前直连NN测试时，我们可以压到30k+的水准，在RBF模式下

2021-08-08 17:17:31 18195 2

原创 HDFS多rack分布的block placement policy设计实现

文章目录前言HDFS多rack分布的block placement policy多rack分布的policy实现思路旧block placement的到新block placement的迁移前言众所周知，HDFS拥有3副本来保证其数据的高可用性。而且HDFS对着三个副本的位置放置也是有专心设计的，2个副本放在同一个rack（不同节点），另外一个副本放在另外的一个rack上。在这样的放置策略下，这个副本数据能容忍一个节点的crash甚至是一个rack机器的crash。但这里所提及的"rack“的概念是集

2021-07-03 12:55:28 2296

原创 HDFS NN refreshNodes操作的可用性和效率的改进

文章目录前言NN refreshNodes的可用性以及效率问题前言我们知道在HDFS里面有，存着一类白名单和黑名单的列表来控制其下允许进行注册的DN节点。这样可以防止一些外部恶意节点注册到我们的NN上来。在HDFS的概念里，这个黑白名单叫做include file和exclude file。在一般情况下，exclude file的使用范围会更管一些，因为DN的decommission下线需要将待下线机器加到此exclude file中，然后再手动执行dfsadmin的refreshNodes命令进行刷

2021-06-12 17:08:50 3219 3

原创 HDFS Multiple Standby原理分析

文章目录前言HDFS Multiple Standby的实现要素Multiple Standby实现分析前言HDFS在早期实现HA时，是标准的一主一备的服务模式，主的叫Active NameNode，备的叫Standby NameNode。Standby/Active NN间可以互相切换以此达到服务高可用的目的。但是这种双节点的HA模式是否能够满足更高的高可用性的要求呢?在标准的HA模式下，其实只有1个Standby的NN作为bak来使用。假设在极端情况下，Active和Stanby同时出现crash

2021-05-05 14:23:45 865 1

原创 Ozone Upgrade模型框架分析

文章目录前言Ozone Upgrade相关要素关系Ozone Upgrade的过程执行前言最近Ozone社区刚刚发布了Ozone 1.1版本，这也是Ozone发布GA版本以来的第二个版本release了。当越来越多Ozone版本release后，这里就会有个版本升级的问题。可能有同学会好奇：目前Ozone支持版本Upgrade功能吗？据社区目前的进展，这个功能第一阶段实现已经基本完成，预计会在Ozone 1.2版本中和大家见面。在Ozone第一阶段Upgrade功能的实现里，一个基本的Upgrade框

2021-04-26 23:14:02 368

原创 Hadoop RPC Client工作原理分析

文章目录前言Hadoop Client的内部结构组成ClientId和CallIdClient Connection和Connection Call的组织关系Client RPC Call的处理流程相关链接前言对于Hadoop内的RPC处理（比如NameNode里的RPC请求处理），我们往往关注的是实际Server端的RPC处理，但是很少提起对应Client端的行为。Hadoop内部有自己专有的RPC Client实现，本文我们就来说说这个底层RPC Client是如何工作的。这有助于方便了解底层RP

2021-04-17 11:52:44 835

原创 HDFS RBF部署生产环境的难点和挑战

文章目录前言一. Router层面的潜在问题Router的性能测试，对请求延时的影响Router间如何做到本地状态的一致性Router对下游NN的统筹管理前言上篇文章笔者简单介绍了HDFS Federation新方案RBF里的connection管理。RBF虽说在功能上只是帮助client做请求转发的，在角色功能定位上相当于一个代理的角色。但RBF的这个“代理”远比我们平常说的代理服务要复杂许多。RBF的核心服务Router在设计实现上被赋予了远比普通代理服务更为全面，成熟的功能。因此集群维护者需要对

2021-03-27 11:19:22 2794

原创 HDFS RBF的Connection管理

文章目录前言Connection管理的权衡问题RBF的Connection管理前言为了解决HDFS Federation下多集群的维护管理，Hadoop社区实现了Router-Based Federation（HDFS-10467）功能。此功能的强大之处在于它在client和集群NN服务之间新加了一层Router的服务。有了这个Router这个服务后，所有客户端的请求将会由这个Router负责转发给下游的NN节点。这样的话，客户端用户就不需要知道下游有哪些NN节点以及各个NN Namespace里分布

2021-03-16 00:22:25 11661 18

原创 Hadoop Security三板斧

文章目录前言Hadoop Security要解决的问题Hadoop Security三板斧参考资料前言在企业大规模量级的Hadoop集群中，数据的安全性是十分重要的，尤其当集群存储的是一些敏感数据的时候。Hadoop社区在早期release的版本中，并没有完善好其Security部分的功能。但是随着Hadoop系统的不断完善成熟，Security的功能也在不断的完善。那么问题来了，Hadoop的Security到底指的是什么呢？本文笔者来简单聊聊Hadoop Security的三板斧，了解了这三板斧的

2021-03-08 17:36:58 1516 1

原创 Hadoop升级前需要考虑的一些事情

文章目录前言Hadoop升级的目标版本的选择Hadoop升级过程需要做的准备工作前言现今Hadoop版本已经release到了Hadoop 3.x版本了，社区迭代更新的速度还是很快的。新的版本相对旧版本来说，能够给我们带来很多益处，诸如新的功能feature，众多bug fix以及一些大的performance的改进。始终维护运行一个陈旧的系统，意味着后期可能会遇到许多许多社区已fix的bug，这个将会消耗掉系统管理员日常相当多的工作时间。尤其当我们维护的是一个具有庞大规模的分布式系统。所以对于复杂系

2021-02-27 18:07:50 1447 1

原创 Ozone S3 Gateway：S3方式的适配存储

文章目录前言相关背景Ozone的S3方式的存储实现分析Ozone S3的Multipart Upload功能分析参考链接前言Ozone作为对象存储系统而言，在对于用户使用的方式上，我们难免会想到另外一个已经在业界十分成熟的对象存储系统：S3存储。不过本文笔者并不想比较二者系统孰优孰劣，从用户角度出发，在用户已经使用S3接口方式做对象存储时，我们是否有方式能够透明的将底层存储移到Ozone上。换言之来说，Ozone是否能够做到兼容S3接口方式的对象存储，这样客户端就不需要做大的改动了。Ozone在早期r

2021-02-15 18:01:01 1907

原创 Ozone SCM HA模式下的请求处理过程

文章目录前言SCM HA和OM HA的区别SCM HA基于InvocationHandler的请求处理SCM HA请求处理过程图参考链接前言在前面的文章中，笔者阐述过关于Ozone SCM HA的设计原理，目前这个功能社区还没有完全做完，但是大部分的主要功能已经完善。本文笔者来简单聊聊SCM HA模式下的请求处理过程，它和早期实现的Ozone OM HA的实现略有不同（OM HA实现原理可参考此文：Ozone OM服务HA原理分析）。Ozone在已有OM HA下，再实现SCM HA后，Ozone系统整

2021-02-13 12:07:45 603 1

原创 HDFS Standby NameNode Read功能剖析

文章目录前言HDFS Standby Read的背景及功能要求Standby NameNode一致性读的控制实现原理分析代码分析流程分析图参考链接前言HDFS有着一套十分成熟的HA的机制来保证其服务的高可用性。在HA模式下，分别对应有Active和Standby NameNode的服务。Active NameNode用于提供对外数据服务，而Standby NameNode则负责做checkpoint的工作以及随时准备接替变成Active NameNode的角色，假设说当前Active NameNode

2021-02-06 20:33:56 1586

原创一次HDFS Snapshot无法删除的问题排查

文章目录前言背景问题Snapshot的清理Snapshot NPE异常代码层面的分析线下Snapshot问题恢复失败HDFS内部代码改动的重新梳理分析setTimes忽略snapshot diff更新的改动总结参考资料前言众所周知，HDFS有一个十分有用的Snapshot的功能，可以用来保护数据被误删除的情况。可能有人会说了，数据被删除了，我难道不可以从trash目录里把数据再恢复回去吗？HDFS的Snapshot和我们平常说的数据删除进trash目录不太一样，HDFS删除操作进trash目录是一个延

2021-01-30 21:49:28 26812

原创一次HDFS JN lag延时问题的排查分析后续：RM陡增traffic的来源分析

前言在上篇文章（一次HDFS JournalNode transaction lag问题分析排查）中，笔者详细地讲述了一次HDFS JN lag延时问题的分析排查，在文中结尾笔者提到了问题的root cause是因为部署在JN同节点上的RM traffic陡增造成的JN lag影响。不过笔者当时只是发现了与RM traffic陡增的可能因素，并未进一步分析这些增加的RM traffic的真正来源。在后续的时间里，我们对这些RM traffic的组成部分以及为什么做了更加进一步的分析，最终真正找到了问题的

2021-01-25 19:02:45 508

原创一次HDFS JournalNode transaction lag问题分析排查

文章目录前言背景问题追踪排查分析排查一：JN服务本身问题排查二：NN 服务问题排查三：JN机器硬件层面问题推论四：JN受所在机器其它服务的影响总结前言众所周知，在HDFS集群中，NameNode服务是其中的核心服务。NameNode的性能处理效率的高低直接影响着其对外提供的服务能力。鉴于过往笔者已经写过诸多NameNode优化系列的文章，本文笔者来聊聊另外与NameNode相关的服务JournalNode（简称JN）服务。JournalNode是在HDFS HA模式下用来做共享editlog的存储的。

2021-01-17 16:37:36 5562 6

原创 Alluxio的Raft HA实现

文章目录前言基于Raft实现的要点Alluxio Raft HA实现的相关角色类前言Alluxio在HA的实现上，早期实现的方式是基于ZK(用来做领导选举)+shared journal storage(状态同步)的方式来达到其服务高可用性的。这种方式和HDFS目前的HA实现十分类似，不过后来Alluxio社区实现了基于Raft协议的新的HA实现方式，Raft实现库依赖了Raft Java实现库Apache Ratis。作为全新的HA实现，本文笔者结合Alluxio相关代码来简单聊聊里面的一些实现细节

2020-12-30 12:39:51 1625 1

原创 Ozone Streaming方式的写优化

文章目录前言Ozone Streaming的背景Ratis Streaming前言在Ozone目前数据写出的过程，是基于从对象文件的block，再从block到chunk粒度进行数据的写出的。每次Ozone写完一个chunk后，对应着会触发一次write chunk的RPC call。当我们写入的数据文件对象很大的时候，过程中将会涉及到很多次write chunk PRC的操作调用。这个RPC call的频繁调用意味着相应更多的transaction的发生。对于Ozone Datanode里使用Raf

2020-12-24 23:52:37 2020 5

原创 HDFS NameNode fsimage文件corrupt了，怎么办

文章目录前言NameNode fsimage corrupt场景NameNode fsimage corrupt解决办法NN fsimage corrupt的重新行为参考链接前言在如今很多用户使用HDFS做为大数据的底层存储时，我们除了关心HDFS的处理性能外，我们经常还需要关注其中数据高可用的情况，例如不能出现数据损坏的情况，比如missing block，或者文件block corrupt的情况。但是其中我们忽略掉了一种最为极端同时也是最为棘手的情况：HDFS NameNode fsimage文件

2020-12-19 23:06:18 1936 1

原创 Ozone OM Upgrade期间请求一致性处理的保证

前言之前笔者讲过一篇关于Ozone Upgrade相关的文章(HDFS数据In-place Upgrade到Ozone的原型方案)，本文笔者继续围绕Ozone Upgrade这个主题，聊聊在Ozone Upgrade时，OM新旧版本之间，它是如何做到元数据的一致性的。倘若是Upgrade后的版本意为地执行了老版本留下的请求，亦或是老版本执行了新版本下发来的请求，这些都不是预期应该发生的情况。Ozone社区对这块的逻辑做了详细的设计。本文我们来聊聊这块的内容。Ozone OM Upgrade的预期目标

2020-11-29 13:02:48 531

原创 Ozone ReplicationManager工作原理

前言在中心化管理的存储系统中，当系统内的数据出现个别副本损坏的情况时，作为中心控制中心，它需要能够感知系统内的这个情况，并且能够快速的进行副本的拷贝恢复。我们姑且称此类服务为ReplicationManager，或者叫做类似于ReplicationMonitor的服务。此类服务在分布式存储系统中扮演的功能为定期检查系统内所有数据的副本情况，并进行必要的修复工作或者其它类似操作。本文笔者来聊聊Ozone系统中的这个服务，名称就叫做ReplicationManager。Ozone ReplicationM

2020-11-18 00:30:10 776

原创 Ozone Decommission原理过程

前言在大规模的分布式集群节点中，出现机器损坏的现象是十分常见的。但是为了保证数据的高可用性，系统在设计上往往采用多副本的形式来达到冗余的效果。对于那些“损坏”了的机器，正常的逻辑是要总正常下线过程，即decommission流程。Decommission最为核心的一点是，它要保证节点内的数据完好无恙的复制到其它健康的节点上，然后最后将此节点标记为Decommissioned状态，随后就可以从集群中移除了。Decommission过程能够减小因为坏节点下线对于集群产生的不利影响。在我们所熟知的HDFS里面

2020-11-15 23:21:23 511

原创 Ozone基于Block level的EC方案设计

文章目录前言Ozone EC概述Ozone Container Group以及CGI前言在之前文章中，笔者写过一篇关于Ozone EC方案设计的文章(Ozone的Erasure Coding方案设计)，不过当时那篇文章讨论的EC设计方案主要在Container级别以及Block级别做EC实现的方案对比，社区并没有敲定选用哪种最终的具体方案设计。最近社区更新了Ozone EC最新的设计方案，在Block级别做最终的实现方式，本文笔者聊聊此方案的实现细节。Ozone EC概述说到EC以及Ozone的

2020-11-05 22:41:18 734 1

原创 Ozone的S3语义和FS语义

文章目录前言Ozone的S3语义和FS语义Ozone S3语义和FS语义的联合使用引用前言在Ozone中，众所周知，它最开始设计仿照的原型即是S3语义的存储模式：基于volume, bucket, key三层的存储模型，底层的key是实际存储的对象文件。至于里面对于volume, bucket, key级别的API操作，基本也是实现了S3现有支持的API操作。不过Ozone作为同样Hadoop生态圈内的一个项目，它需要与现有别的系统框架能够很好地协调工作。因此，Ozone内部实现了Ozone FS的语

2020-10-12 00:10:11 934

原创 Ozone FS namespace下的全新metadata结构分析

文章目录前言OzoneFileSystem的不足之处Ozone FS namespace的metadata结构Ozone FS基于Dir cache的高效查找引用前言Ozone作为又一个全新的存储系统，它在底层存储结构上和HDFS有着不小的区别，用户往Ozone内读写数据的方式也有所不同。不过为了兼容目前Hadoop FileSystem的读写，Ozone实现了一个叫做OzoneFileSystem的功能。通过使用OzoneFileSystem，用户能够使用往常Hadoop FileSystem的通用

2020-10-04 22:08:25 564

原创 HDFS/Ozone对于存储策略的抽象化提取

文章目录前言存储类别(策略)抽象提炼的意义HDFS的Storage PolicyOzone的Storage Class定义引用前言Ozone作为正在快速迭代开发中的存储系统，相比于HDFS来说，其内部能支持更大规模量级的文件对象存储。不过作为存储系统来说，它同样面临一些数据如何来存储的问题，比如数据存几副本备份，数据replication的策略是什么，数据存储的载体介质是什么等等。本文我们来聊聊Ozone对于这块内容的抽象设计。为什么笔者提到的是抽象设计呢，因为这个功能设计还处在社区讨论中，还未开发完

2020-09-26 16:59:27 819

原创 HDFS千万级别文件数/PB规模量级的数据迁移实战总结

文章目录前言HDFS元数据快速膨胀带来的性能瓶颈问题超大规模数据迁移所面临的挑战和困难DistCp的全面优化提升前言前面时间笔者曾写过一篇关于利用HDFS fastcopy功能来加速DistCp数据拷贝效率的文章(Distcp结合HDFS Fastcopy的性能改造提升)，以及提到了现有DistCp在数据切分时候的一些问题(聊聊Hadoop DistCp的数据切分处理方式)，会导致长尾任务的出现等等。其实在后续的测试过程中，我们还发现并解决了许多大大小小的坑，使得我们整体数据拷贝的耗时达到一个相对短的

2020-09-13 16:00:36 10406 4

原创聊聊Hadoop DistCp的数据切分处理方式

文章目录前言基于文件数/文件Size的数据切分方式前言在如今数据使用场景越来越多的环境下，如何对数据做到更准确，更高效的处理无疑是我们开发者所重点关注以及所期望达成的目标。说到数据的处理，在当今成熟的分布式系统下，我们已经能够达到比较高效的数据并行处理能力了。但是这并不意味着说对此我们没有别的改善空间的余地了。在数据的并行处理过程中，不是所有情况我们都能保证每个并行处理任务都能按照预期顺利执行，中间就可能出现长尾任务现象。这里笔者想抛出的一个关键词：数据切分。在数据切分不均匀的情况下，是极有可能出现任

2020-08-29 20:45:42 4418 10

原创 Distcp结合HDFS Fastcopy的性能改造提升

文章目录前言HDFS的fastcopyDistcp工具支持fastcopy的改造前言在HDFS中，我们经常会碰到跨集群数据拷贝的场景，例如某些任务数据结果计算生成，然后问你启动任务把结果数据导出到另外一个集群中以作后续的分析等这样的用途。Hadoop作为一套成熟完善的系统，也为我们提供了专门的拷贝工具，Distcp，全称Distributed copy，意为分布式的拷贝。说到Distcp工具本身，很多同学估计不会陌生，不过本文笔者来聊聊Distcp基于HDFS fastcopy原理下的性能提升改造。在

2020-08-19 23:57:23 1535 3

空空如也

空空如也