第 1 章 HDFS — トラブルシューティング
1.1 クラスタ セキュリティ モード
1) セキュリティ モード:ファイル システムはデータの読み取り要求のみを受け入れますが、削除、変更、およびその他の変更要求は受け入れません。
2) セーフモードのシーンに入る
NameNode は、イメージの読み込み中およびログの編集中にセーフモードになります
NameNode がDataNode の登録を再度受け取ると、セーフ モードになります
3) セーフモード条件を終了する
dfs.namenode.safemode.min.datanodes: 利用可能なデータノードの最小数、デフォルト 0;
dfs.namenode.safemode.threshold-pct: システム内のブロックの総数に対する最小数のレプリカを持つブロックの割合。デフォルトは 0.999f です。
dfs.namenode.safemode.extension: 安定時間。デフォルト値は 30000 ミリ秒、つまり 30 秒です。
4) 基本文法
クラスターはセーフ モードであり、重要な操作 (書き込み操作) を実行できません。クラスタの起動が完了すると、セーフ モードは自動的に終了します。
bin/hdfs dfsadmin -safemode get #(功能描述:查看安全模式状态)
bin/hdfs dfsadmin -safemode enter #(功能描述:进入安全模式状态)
bin/hdfs dfsadmin -safemode leave #(功能描述:离开安全模式状态)
bin/hdfs dfsadmin -safemode wait #(功能描述:等待安全模式状态)
1.2 NameNode のトラブルシューティング
1) 要件:
NameNode プロセスがハングし、保存されたデータが失われます。NameNode を復元する方法
2) 故障シミュレーション
(1) kill -9 NameNode プロセス
[atguigu@hadoop102 current]$ kill -9 NameNode的进程号
(2) NameNode に格納されたデータを削除 (/opt/module/hadoop-3.1.3/data/tmp/dfs/name)
[atguigu@hadoop102 hadoop-3.1.3]$ rm -rf /opt/module/hadoop-3.1.3/data/dfs/name/*
3) 問題解決
(1) SecondaryNameNode のデータを元の NameNode 格納データディレクトリにコピーする
[atguigu@hadoop102 dfs]$ scp -r atguigu@hadoop104:/opt/module/hadoop-3.1.3/data/dfs/namesecondary/* ./name/
(2) NameNode を再起動する
[atguigu@hadoop102 hadoop-3.1.3]$ hdfs --daemon start namenode
(3) クラスタにファイルをアップロードする
1.3 まとめ
1.3.1 メタデータの損失
NN のすべてのメタデータを削除します (edits、edits_inprogress、fsimage)
NNを停止してNNを再起動したところ、起動できないことが判明。
緊急復旧 (HA が使用されるため、本番環境では発生しません) 2NN の編集内容と fsimage を NN にコピーします。
データの一部のみを復元できます。また、セーフモードのままになります。
データ クラスターのその部分を気にせず、通常に戻したい場合:
hdfs dfsadmin -safemode forceExit
1.3.2 ブロックロス
3 つのノードで 2 つのブロックを削除して NameNode を再起動すると、セーフ モードになります。
通常の操作では、セーフモードを終了します
NameNode を再起動しても、セーフ モードに入ります (欠落しているブロックのメタデータ (コマンドによって、またはページ上で削除された) がセーフ モードにとどまらない場合を除きます)。
第 2 章 HDFS — 複数のディレクトリ
2.1 DataNode マルチディレクトリ構成
1) DataNode は複数のディレクトリに構成でき、各ディレクトリに格納されるデータは異なります (データはコピーではありません)。
2) 具体的な構成は以下の通り
次のコンテンツを hdfs-site.xml ファイルに追加します。
<property>
<name>dfs.datanode.data.dir</name>
<value>file://${hadoop.tmp.dir}/dfs/data,
file://${hadoop.tmp.dir}/dfs/data2
</value>
</property>
3) 結果を見る
[atguigu@hadoop102 dfs]$ ll
总用量 12
drwx------. 3 atguigu atguigu 4096 4月 4 14:22 data
drwx------. 3 atguigu atguigu 4096 4月 4 14:22 data2
drwxrwxr-x. 3 atguigu atguigu 4096 12月 11 08:03 name1
drwxrwxr-x. 3 atguigu atguigu 4096 12月 11 08:03 name2
4) ファイルをクラスターにアップロードし、2 つのフォルダーの内容を再度観察して、矛盾していることを確認します (一方には番号があり、もう一方には番号がありません)。
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -put wcinput/word.txt /
2.2 クラスタデータバランスのためのディスク間のデータバランス
運用環境では、ハードディスクの空き容量が不足しているため、ハードディスクの追加が必要になることがよくあります。新たに搭載したハードディスクにデータがない場合、ディスクデータバランスコマンドを実行できます。(Hadoop3.x の新機能)。
(1) バランスの取れた計画を生成します(ディスクは 1 つしかなく、計画は生成されません)。
hdfs diskbalancer -plan hadoop102
(2) バランスの取れた計画を実行する
hdfs diskbalancer -execute hadoop102.plan.json
(3) 現在の残高タスクの実行状況を表示する
hdfs diskbalancer -query hadoop102
(4)バランスタスクのキャンセル
hdfs diskbalancer -cancel hadoop102.plan.json
第 3 章 HDFS — クラスターの拡張と縮小
3.1 新しいサーバーのサービス
1) 需要
会社のビジネスの成長に伴い、データの量はますます大きくなり、元のデータ ノードの容量ではデータを格納するニーズを満たすことができなくなり、データ ノードに基づいて新しいデータ ノードを動的に追加する必要があります。オリジナルクラスター。
2) 環境整備
(1) hadoop100 ホストで別の hadoop105 ホストのクローンを作成します。
(2) IPアドレスとホスト名を変更する
[root@hadoop105 ~]# vim /etc/sysconfig/network-scripts/ifcfg-ens33
[root@hadoop105 ~]# vim /etc/hostname
(3) hadoop102 の/opt/moduleディレクトリと/etc/profile.d/my_env.shをhadoop105 にコピーします。
[atguigu@hadoop102 opt]$ scp -r module/*atguigu@hadoop105:/opt/module/
[atguigu@hadoop102 opt]$ sudo scp /etc/profile.d/my_env.shroot@hadoop105:/etc/profile.d/my_env.sh
[atguigu@hadoop105 hadoop-3.1.3]$ source /etc/profile
(4) hadoop105上のHadoopの履歴データ、データ、ログデータを削除する
[atguigu@hadoop105 hadoop-3.1.3]$ rm -rf data/ logs/
(5) hadoop102 と hadoop103 を hadoop105 ssh 非シークレット ログインに設定します。
[atguigu@hadoop102 .ssh]$ ssh-copy-id hadoop105
[atguigu@hadoop103 .ssh]$ ssh-copy-id hadoop105
3) 新しいノードを提供するための具体的な手順
DataNode を直接起動して、クラスタに関連付けます
[atguigu@hadoop105 hadoop-3.1.3]$ hdfs --daemon start datanode
[atguigu@hadoop105 hadoop-3.1.3]$ yarn --daemon start nodemanager
3.2 サーバー間のデータバランス
1) 企業経験:
エンタープライズ開発において、Hadoop102 と Hadoop104 でタスク投入が多く、コピー数が 2 の場合、データ局所性の原則により、Hadoop102 と Hadoop104 にデータがありすぎて、Hadoop103 に格納されるデータの量が減少します。小さくなります。
もう 1 つの状況は、新しいサーバーのデータ量が比較的少なく、クラスター バランス コマンドを実行する必要がある場合です。
2) データバランスコマンドを有効にする
[atguigu@hadoop105 hadoop-3.1.3]$ sbin/start-balancer.sh -threshold 10
パラメーター 10 の場合、クラスター内の各ノードのディスク容量使用率が 10% を超えないことを意味します。これは、実際の状況に応じて調整できます。
3) データバランスコマンドを停止する
[atguigu@hadoop105 hadoop-3.1.3]$ sbin/stop-balancer.sh
注: HDFS はリバランス操作を実行するために別の RebalanceServer を起動する必要があるため、NameNode で start-balancer.sh を実行しないようにしてください。ただし、比較的アイドル状態のマシンを見つけてください。
3.3 ホワイトリストの追加
ホワイトリスト: ホワイトリストのホスト IP アドレスを使用してデータを保存できることを示します。
企業内: ホワイトリストを構成して、ハッカーによる悪意のあるアクセス攻撃を防ぎます。
ホワイトリストを構成する手順は次のとおりです。
1) NameNode ノードの /opt/module/hadoop-3.1.3/etc/hadoop ディレクトリに、ホワイトリスト ファイルとブラックリスト ファイルをそれぞれ作成します。
(1) ホワイトリストの作成
[atguigu@hadoop102 hadoop]$ vim whitelist
# 在whitelist中添加如下主机名称,假如集群正常工作的节点为102 103 :
hadoop102
hadoop103
(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) 配布構成ファイルのホワイトリスト、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/dfshealth.html#tab-datanode)。
6) ホワイトリストを 2 回変更し、hadoop104 を追加します。
[atguigu@hadoop102 hadoop]$ vim whitelist
修改为如下内容
hadoop102
hadoop103
hadoop104
hadoop105
7) NameNode を更新する
[atguigu@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes
ノードをリフレッシュしました
8) Web ブラウザーで DN を表示します ( http://hadoop102:9870/dfshealth.html#tab-datanode)。
3.4 廃止されたサーバーのブラックリスト登録
ブラックリスト: ブラックリストのホスト IP アドレスがデータの保存を許可されていないことを示します。
企業内: ブラックリストを構成してサーバーを廃止します。
ブラックリストの設定手順は次のとおりです。
1) /opt/module/hadoop-3.1.3/etc/hadoop ディレクトリにあるブラックリスト ファイルを編集します。
[atguigu@hadoop102 hadoop] vim blacklist
添加如下主机名称(要退役的节点)
hadoop105
注: ホワイトリストに構成がない場合は、dfs.hosts 構成パラメーターを hdfs-site.xml 構成ファイルに追加する必要があります。
<!-- 黑名单-->
<property>
<name>dfs.hosts.exclude</name>
<value>/opt/module/hadoop-3.1.3/etc/hadoop/blacklist</value>
</property>
2) 配布構成ファイルのブラックリスト、hdfs-site.xml
[atguigu@hadoop104 hadoop]$ xsync hdfs-site.xml blacklist
3) ブラックリストを初めて追加するには、クラスタを再起動する必要があります。初回ではなく、NameNode ノードを更新するだけです。
[atguigu@hadoop102 hadoop-3.1.3]$ hdfs dfsadmin -refreshNodes
Refresh nodes successful
4) Web ブラウザーを確認します。廃止されたノードのステータスは、廃止が進行中 (廃止) であり、データ ノードが他のノードにブロックをコピーしていることを示しています。
5) 廃止されたノードのステータスが廃止される (すべてのブロックがコピーされた) のを待ち、ノードとノード リソース マネージャーを停止します。注: レプリカの数が 3 で、稼働中のノードの数が 3 以下の場合、廃止は成功しません。廃止する前に、レプリカの数を変更する必要があります。
[atguigu@hadoop105 hadoop-3.1.3]$ hdfs --daemon stop datanode
stopping datanode
[atguigu@hadoop105 hadoop-3.1.3]$ yarn --daemon stop nodemanager
stopping nodemanager
6) データのバランスが取れていない場合は、コマンドを使用してクラスターを再調整できます
[atguigu@hadoop102 hadoop-3.1.3]$ sbin/start-balancer.sh -threshold10
第 4 章 Hadoop エンタープライズ最適化
4.1 MapReduce の最適化方法
MapReduce 最適化手法は、主に6 つの側面を考慮します。データ入力、Map フェーズ、Reduce フェーズ、IO 送信、データ スキュー、および一般的に使用されるチューニング パラメータです。
データ入力
小さいファイルを結合する: MR タスクを実行する前に小さいファイルを結合します.多数の小さいファイルは多数の MapTask を生成し、MapTask の読み込み回数が増加します.タスクの読み込みには時間がかかり、MR の動作が遅くなります.
入力側で多数の小さなファイル シナリオを解決するには、 CombineTextInputFormat を入力として使用します。
マップステージ
Spills の数を減らす: mapreduce.task.io.sort.mb および mapreduce.map.sort.spill.percent パラメーター値を調整することにより、 Spills をトリガーするメモリ制限を増やし、Spills の数を減らし、ディスク IO を減らします。
マージの回数を減らす (Merge) : mapreduce.task.io.sort.factor パラメータを調整することで、 Merge ファイルの数を増やし、Merge の数を減らすことで、MR 処理時間を短縮します。
Map の後、ビジネス ロジックに影響を与えることなく、最初に Combime 処理を実行してIO を削減します。
ステージを減らす
Map と Reduce の数を合理的に設定します。設定が少なすぎたり、多すぎたりすることはありません。少なすぎると Task が待機して処理時間が長くなり、多すぎると Map タスクと Reduce タスクの間でリソースの競合が発生し、処理のタイムアウトやその他のエラーが発生します。
Map と Reduce を共存させる: mapreducejob.reduce.slowstart.completedmaps パラメーターを調整して、Map がある程度実行された後、Reduce も実行を開始し、Reduce の待機時間を短縮します。
Reduce の使用を避ける: Reduce を使用してデータ セットを接続すると、大量のネットワーク消費が発生するためです。
Reduce 側の Buffer を適切に設定します。デフォルトでは、データがしきい値に達すると、Buffer 内のデータがディスクに書き込まれ、Reduce はディスクからすべてのデータを取得します。つまり、BufferとReduceは直接関係なく、ディスクへの書き込み→ディスクの読み込みを途中で何度も繰り返すデメリットがあるので、パラメータでBufferのデータの一部を読み込めるように設定することができます。 IO オーバーヘッドを削減するには、mapreduce.reduce.input.buffer.percent を指定します。デフォルトは 0.0 です。値が 0 より大きい場合、指定された割合のメモリが確保され、Buffer 内のデータが読み取られ、Reduce に直接使用されます。このように、バッファの設定にはメモリ、データの読み込みにはメモリ、リデュース計算にはメモリが必要となるため、ジョブの実行状況に応じて調整する必要があります。
I/O 传输
データ圧縮方法を使用する: ネットワーク IO の時間を短縮します。Sappy および LZO 圧縮エンコーダーをインストールします。
SequenceFile バイナリ ファイルを使用します。
データの偏りの問題
データの偏りの問題
データスキュー現象:
データ頻度の偏り - 特定の領域のデータ量が他の領域よりもはるかに多い。
データサイズの偏り - 一部のレコードのサイズは平均よりもはるかに大きくなっています。
データの偏りを減らす方法
サンプリングと範囲分割: 元のデータをサンプリングして得られた結果セットを通じて、分割境界値を事前設定できます。
カスタム パーティショニング: 出力キーの背景知識に基づいてカスタム パーティショニングを実行します。たとえば、Map 出力キーに本の単語が含まれているとします。そして、それらのいくつかはより専門的な語彙を持っています. 次に、パーティションをカスタマイズして、これらの専門用語を Reduce インスタンスの固定部分に送信できます。そして残りを残りのReduceインスタンスに送ります。
コンバイナー:コンバイナーを使用すると、データの偏りを大幅に減らすことができます。Combimner の目的は、可能な場合にデータを集約および圧縮することです。
Map Join を使用し、Reduce Join を回避してください。
共通のチューニング パラメータ
1) リソース関連のパラメータ
(1) 以下のパラメーターは、ユーザー独自の MR アプリケーション ( mapred-default.xml )での構成後にのみ有効になります。
設定パラメータ |
パラメータ 説明 |
mapreduce.map.memory.mb |
MapTask が使用できるリソースの上限 (単位: MB)。デフォルトは 1024 です。MapTask が実際に使用するリソースの量がこの値を超えると、強制的に kill されます。 |
mapreduce.reduce.memory.mb |
ReduceTask が使用できるリソースの上限 (単位: MB)。デフォルトは 1024 です。ReduceTask が実際に使用するリソースの量がこの値を超えると、強制的に kill されます。 |
mapreduce.map.cpu.vcores |
各 MapTask で使用できる CPU コアの最大数、デフォルト値: 1 |
mapreduce.reduce.cpu.vcores |
各 ReduceTask で使用できる CPU コアの最大数、デフォルト値: 1 |
mapreduce.reduce.shuffle.parallelcopies |
Map からデータをフェッチするための各 Reduce の並列数。デフォルト値は 5 です |
mapreduce.reduce.shuffle.merge.percent |
ディスクへの書き込みを開始するバッファ内のデータの割合。デフォルト値は 0.66 です |
mapreduce.reduce.shuffle.input.buffer.percent |
Reduce の使用可能なメモリのパーセンテージとしてのバッファ サイズ。デフォルト値 0.7 |
mapreduce.reduce.input.buffer.percent |
データをバッファに格納するために使用するメモリ量を指定します。デフォルト値は 0.0 です。 |
(2) YARN が有効になる前に、サーバーの構成ファイルで構成する必要があります ( yarn-default.xml )
設定パラメータ |
パラメータ 説明 |
yarn.scheduler.minimum-allocation-mb |
アプリケーションコンテナに割り当てられる最小メモリ、デフォルト値: 1024 |
yarn.scheduler.maximum-allocation-mb |
给应用程序Container分配的最大内存,默认值:8192 |
yarn.scheduler.minimum-allocation-vcores |
每个Container申请的最小CPU核数,默认值:1 |
yarn.scheduler.maximum-allocation-vcores |
每个Container申请的最大CPU核数,默认值:32 |
yarn.nodemanager.resource.memory-mb |
给Containers分配的最大物理内存,默认值:8192 |
(3)Shuffle性能优化的关键参数,应在YARN启动之前就配置好(mapred-default.xml)
配置参数 |
参数说明 |
mapreduce.map.maxattempts |
每个Map Task最大重试次数,一旦重试次数超过该值,则认为Map Task运行失败,默认值:4。 |
mapreduce.reduce.maxattempts |
每个Reduce Task最大重试次数,一旦重试次数超过该值,则认为Map Task运行失败,默认值:4。 |
mapreduce.task.timeout |
Task超时时间,经常需要设置的一个参数,该参数表达的意思为:如果一个Task在一定时间内没有任何进入,即不会读取新的数据,也没有输出数据,则认为该Task处于Block状态,可能是卡住了,也许永远会卡住,为了防止因为用户程序永远Block住不退出,则强制设置了一个该超时时间(单位毫秒),默认是600000(10分钟)。如果你的程序对每条输入数据的处理时间过长(比如会访问数据库,通过网络拉取数据等),建议将该参数调大,该参数过小常出现的错误提示是:“AttemptID:attempt_14267829456721_123456_m_000224_0 Timed out after 300 secsContainer killed by the ApplicationMaster.”。 |
4.2 Hadoop小文件优化方法
4.2.1 Hadoop小文件弊端
HDFS上每个文件都要在NameNode上创建对应的元数据,这个元数据的大小约为150byte,这样当小文件比较多的时候,就会产生很多的元数据文件,一方面会大量占用NameNode的内存空间,另一方面就是元数据文件过多,使得寻址索引速度变慢。
小文件过多,在进行MR计算时,会生成过多切片,需要启动过多的MapTask。每个MapTask处理的数据量小,导致MapTask的处理时间比启动时间还小,白白消耗资源。
4.2.2 Hadoop小文件解决方案
1)小文件优化的方向:
(1)在数据采集的时候,就将小文件或小批数据合成大文件再上传HDFS。
(2)在业务处理之前,在HDFS上使用MapReduce程序对小文件进行合并。
(3)在MapReduce处理时,可采用CombineTextInputFormat提高效率。
(4)开启uber模式,实现jvm重用
2)Hadoop Archive
是一个高效的将小文件放入HDFS块中的文件存档工具,能够将多个小文件打包成一个HAR文件,从而达到减少NameNode的内存使用
3)CombineTextInputFormat
CombineTextInputFormat用于将多个小文件在切片过程中生成一个单独的切片或者少量的切片。
4)开启uber模式,实现JVM重用。
默认情况下,每个Task任务都需要启动一个JVM来运行,如果Task任务计算的数据量很小,我们可以让同一个Job的多个Task运行在一个JVM中,不必为每个Task都开启一个JVM。
开启uber模式,在mapred-site.xml中添加如下配置:
<!-- 开启uber模式 -->
<property>
<name>mapreduce.job.ubertask.enable</name>
<value>true</value>
</property>
<!-- uber模式中最大的mapTask数量,可向下修改 -->
<property>
<name>mapreduce.job.ubertask.maxmaps</name>
<value>9</value>
</property>
<!-- uber模式中最大的reduce数量,可向下修改 -->
<property>
<name>mapreduce.job.ubertask.maxreduces</name>
<value>1</value>
</property>
<!-- uber模式中最大的输入数据量,默认使用dfs.blocksize 的值,可向下修改 -->
<property>
<name>mapreduce.job.ubertask.maxbytes</name>
<value></value>
</property>
第5章 Hadoop扩展
5.1 集群间数据拷贝
1)scp实现两个远程主机之间的文件复制
scp -r hello.txt root@hadoop103:/user/atguigu/hello.txt # 推push
scp -r root@hadoop103:/user/atguigu/hello.txt hello.txt #拉pull
scp -r root@hadoop103:/user/atguigu/hello.txtroot@hadoop104:/user/atguigu #是过本地主机中转实现两个远程主机的文件复制;如果在两个远程主机之间ssh没有配置的情况下可以使用该方式。
采用distcp命令实现两个Hadoop集群之间的递归数据复制
hadoop distcp [在集群1中的文件路径] [在集群2中的文件路径]
[atguigu@hadoop102 hadoop-3.1.3]$
hadoop distcp hdfs://hadoop102:8020/user/atguigu/hello.txt hdfs://hadoop105:8020/user/atguigu/hello.txt
5.2 小文件存档
1)案例实操
(1)需要启动YARN进程
[atguigu@hadoop102 hadoop-3.1.3]$ start-yarn.sh
(2)归档文件
把/user/atguigu/input目录里面的所有文件归档成一个叫input.har的归档文件,并把归档后文件存储到/user/atguigu/output路径下。
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop archive -archiveName input.har-p /user/atguigu/input /user/atguigu/output
(3)查看归档
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -ls har:///user/atguigu/output/input.har
(4)解归档文件
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -cp har:/// user/atguigu/output/input.har/* /user/atguigu
5.3 回收站
开启回收站功能,可以将删除的文件在不超时的情况下,恢复原数据,起到防止误删除、备份等作用。
1)回收站参数设置及工作机制
2)启用回收站
修改core-site.xml,配置垃圾回收时间为1分钟。
<property>
<name>fs.trash.interval</name>
<value>1</value>
</property>
3)查看回收站
回收站目录在hdfs集群中的路径:/user/atguigu/.Trash/….
4)通过程序删除的文件不会经过回收站,需要调用moveToTrash()才进入回收站
Configuration conf = new Configuration();
//设置HDFS的地址
conf.set("fs.defaultFS","hdfs://hadoop102:8020");
//因为本地的客户端拿不到集群的配置信息 所以需要自己手动设置一下回收站
conf.set("fs.trash.interval","1");
conf.set("fs.trash.checkpoint.interval","1");
//创建一个回收站对象
Trash trash = new Trash(conf);
//将HDFS上的/input/wc.txt移动到回收站
trash.moveToTrash(new Path("/input/wc.txt"));
5)通过网页上直接删除的文件也不会走回收站。
6)只有在命令行利用hadoop fs -rm命令删除的文件才会走回收站。
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -rm -r /user/atguigu/input
7)恢复回收站数据
[atguigu@hadoop102 hadoop-3.1.3]$ hadoop fs -mv /user/atguigu/.Trash/Current/user/atguigu/input /user/atguigu/input