7-5下黒
16873 ワード
1.何度ですか。
ハドゥは2006年にヤフーのダグカットで「nutch」という検索エンジンを開発した過程で、
従来のRDB技術では、大量の非構造化データを処理することは困難であることが認識される.
新しい技術を探している間に、Googleが発表したGFSとMapReduceに関する論文を参考にしました.
その後apache財団のオープンソースとして公開された.
Haduは性能の良いコンピュータを使用してデータを処理しない.
複数の適切なパフォーマンスの汎用コンピュータをクラスタ化し、クラスタ上で大量のデータを並列に処理します.
分散処理のオープンソースフレームワークは、処理速度を速めることを目的としています.
2.河豆の構成要素
1) Hadoop Common
下図の他のモジュールをサポートする汎用コンポーネントモジュール
2) Hadoop HDFS
分散型ストレージの処理に使用されるモジュール
複数のサーバを1台のサーバに組み合わせてデータを格納
ファイルの保存方法
データがある程度蓄積されたときに記憶する
リアルタイムではなくバッチに特化した設計
3) Hadoop YARN
並列処理のためのクラスタリソースの管理とスケジューリング
4) Hadoop Mapreduce
分散ストレージのデータを並列に処理する分散処理モジュール
3.河豆のメリットとデメリット
長所
オープンソースのライセンスコストが低い
システムを中断することなくデバイスを追加
一部のデバイスに障害が発生しても、システム全体の可用性には影響しません(障害許容)
データ処理速度が速く、導入コストが低い
オフラインバッチの最適化
短所
HDFSに格納されているデータは変更できません
リアルタイムデータ分析など、迅速な処理が必要なタスクには適していません.
多くのバージョンと信頼性の低いサブタイトル
設置が困難である.
4.河豆の進化過程
1)下黒v 1
分散ストレージ、並列処理フレームワークの定義
分散型ストレージ(HDFS)
名前ノード、データノードで処理
へいれつしょり
捕獲者、タスク追跡者処理.
クラスタあたり最大4,000ノードの登録
タスクをスロット単位で処理
分割マップ、タイルスロットによる処理
2)下黒v 2
2012年に正式に発表されたHaduv 2は、v 1のサーカスボトルネックを解消するためにYARNアーキテクチャを導入した.
クラスタ管理
アセットマネージャ、ノードマネージャ
タスク管理
アプリケーションのメインノード、コンテナ
MRに加えて、Spark、Hive、Pigなどの他の分散処理モデルを実行することもできる.
クラスタごとに1万以上のノードを登録できます
コンテナ単位でタスクを処理する
3)下黒v 3
レーザエンコーディングの導入
従来のブロックコピーに代わることでHDFSの使用を減らす
YARN時間軸サービスv 2の導入
従来のタイムラインサービスよりも多くの情報を提供
わかりやすい形式でスクリプトを再作成および変更
古いスクリプトを再作成してエラーを修正
JAVA 8サポート
ネイティブ・コードの最適化
複数の名前ノードをサポートし、高可用性を実現
複数の追加可能な代替ノードをサポート
Ozoneの追加
オブジェクトリポジトリの追加
5. HDFS
HDFS(Hadoop Distributed File System)は高価なハードディスクではありません.
ターゲットは、障害復旧性のある分散ファイルシステムです.
HDFSは、リアルタイム処理ではなくバッチ処理のために設計されている.
これは、高速なデータ応答時間を必要とするタスクには適していません.
また,名前ノードは単一の障害(SPOF)となるため,名前ノードの管理が重要である.
1)特徴
(1)ブロック単位の保存
HDFSはブロック単位でデータを格納する.
ブロックサイズより小さいファイルを既存のファイルのサイズとして保存し、
データファイルはブロック単位で格納されるため、単一のディスク上のデータよりも大きなファイルを格納できます.
ブロック単位が256 MBの場合、1 Gファイルは4つのブロックに分けられ、10 MBファイルは1つのブロックに分けられる.
(2)ブロックコピーによるフェイルオーバ
HDFSは、フェイルオーバのために各ブロックをコピーして格納する.
ブロックのデフォルトコピー単位は3です.1つのブロックを3つのブロックにコピーします.
同じラックのサーバと別のラックのサーバにコピーして保存します.
ブロックに問題が発生した場合は、コピーした他のブロックを使用してデータを復元します.
1 Gbデータを格納する場合、データはコピーされ、3 Gbの格納スペースが必要となります.
(3)読解中心
HDFSは、1回の書き込み時に複数回データを読み出すことを目標としている.したがって、ファイルの変更はサポートされていません.
ファイルの変更を制限することで、操作を簡素化し、データの読み取り速度を向上させることができます.
(4)データ領域性
マップリフレッシュはHDFSのデータ領域性を利用して処理速度を速める.
処理アルゴリズムが存在する場所にデータを移動しません.
データが存在する位置でアルゴリズムを処理することで,ネットワークを介して大量のデータを移動するコストを低減できる.
2)構造
HDFSは、1つの名前ノードと複数のデータノードからなるプライマリ依存構造である.
名前ノードにはメタデータがあり、データはブロック単位でデータノードに格納されます.
ユーザーは、名前ノードを使用してデータの書き込みと読み取りを行うことができます.(1) 네임노드
메타데이터 관리와 데이터노드를 관리
메타데이터는 파일이름, 파일크기, 파일생성시간, 파일접근권한, 파일 소유자 및 그룹 소유자, 파일이 위치한 블록의 정보 등으로 구성됩니다.
각 데이터노드에서 전달하는 메타데이터를 받아서 전체 노드의 메타데이터 정보와 파일 정보를 묶어서 관리합니다.
메타데이터는 사용자가 설정한 위치(dfs.name.name.dir)에 보관됩니다.
네임노드가 실행 될 때 파일을 읽어서 메모리에 보관합니다.
운영중에 발생한 수정사항은 네임노드의 메모리에는 바로 적용되고, 데이터의 수정사항을 다음 구동시 적용을 위해서 주기적으로 Edist 파일로 저장합니다.
메타데이터 파일 종류
Fsimage 파일
네임스페이스와 블록 정보
Edits 파일
파일의 생성, 삭제에 대한 트랜잭션 로그
메모리에 저장하다가 주기적으로 생성
(2) 데이터 노드
데이타노드는 파일을 저장하는 역할
파일은 블록단위로 저장됩니다. 데이타노드는 주기적으로 네임노드에 하트비트와 블록리포트를 전달합니다.
하트비트는 데이타노드의 동작여부를 판단하는데 이용됩니다.
네임노드는 하트비트가 전달되지 않는 데이터노드는 동작하지 않는 것으로 판단하여 더이상 데이터를 저장하지 않도록 설정합니다.
블록리포트로 블록의 변경사항을 체크하고, 네임노드의 메타데이터를 갱신합니다.
블록 파일 저장형태
사용자가 설정한 위치(dfs.data.dir)에 저장됩니다.
[1] 데이터 노드 상태
ㄱ. 활성상태
활성 상태는 데이터노드가 Live 상태인지 Dead 상태인지를 나타냅니다.
데이터노드가 하트비트를 주기적으로 전달하여 살아 있는지 확인되면 Live 상태입니다.
데이터노드에 문제가 발생하여 지정한 시간동안(dfs.namenode.stale.datanode.interval)하트비트를 받지 못하면
네임노드는 데이터노드의 상태를 Stale 상태로 변경합니다. 이후 지정한 시간동안 응답이 없으면 Dead 노드로 변경합니다.
ㄴ. 운영 상태
운영 상태는 데이터노드의 업그레이드, 패치 같은 작업을 하기 위해 서비스를 잠시 멈추어야 할 경우 블록을 안전하게 보관하기 위해 설정하는 상태
NORMAL: 서비스 상태
DECOMMISSIONED: 서비스 중단 상태
DECOMMISSION_INPROGRESS: 서비스 중단 상태로 진행 중
IN_MAINTENANCE: 정비 상태
ENTERING_MAINTENANCE: 정비 상태로 진행 중
[2] 파일 읽기/쓰기
HDFS의 파일에 접근하는 가장 간단한 방법은 HDFS 명령행 인터페이스를 이용하는 것입니다.
또한 Java, C API를 제공하여 이를 구현해서 접근하면 됩니다.
ㄱ. 파일 읽기
네임노드에 파일이 보관된 블록 위치 요청
네임노드가 블록 위치 반환
각 데이터 노드에 파일 블록을 요청
노드의 블록이 깨져 있으면 네임노드에 이를 통지하고 다른 블록 확인
ㄴ. 파일 쓰기
네임노드에 파일 정보를 전송하고, 파일의 블록을 써야할 노드 목록 요청
네임노드가 파일을 저장할 목록 반환
데이터 노드에 파일 쓰기 요청
데이터 노드간 복제가 진행
3)コマンド
https://hadoop.apache.org/docs/r3.2.2/hadoop-project-dist/hadoop-common/FileSystemShell.html (1) 사용자
hdfs dfs -[서브명령어] or hadoop fs -[서브명령어]
자주 사용하는 서브 명령어
ls 안에 내용물 확인
rm -r 삭제
mkdir 디렉토리만들기
cat 내용물보기
mv 이동
cp 복사
du hdfs내부의 특정 file이나 디렉토리의 사이즈를 보여줌
du -s : 각각의 파일의 size의 sum값을 보여줌
-stat %b 용량을 바이트 단위로 본다
-stat %o 차지한 블록사이즈 보기(실제 용량과 블록사이즈는 다를 수 있음)
-stat %r 복사본이 몇개있나 확인
copyFromLocal 로컬에서 하둡으로 업로드
copyToLocal 하둡에서 로컬로
hdfs dfs -get /user/data1.txt ./ # 파일을 로컬에 복사
hdfs dfs -get -f /user/data1.txt ./ # 파일을 로컬에 복사, 동일한 파일이 있으면 덮어 씀.
hdfs dfs -put ./data1.txt /user/ # 로컬 파일을 hdfs에 복사
hdfs dfs -put -f ./data1.txt /user/ # 로컬 파일을 hdfs에 복사, 동일한 파일이 있으면 덮어 씀.
(2)管理者[1] Rack Awareness
블록을 저장할 때 2개의 블록은 같은 랙에, 나머지 하나는 다른랙에 저장하도록 구성
[2] HDFS 세이프모드
데이터의 저장 및 삭제가 불가능한 상태, 읽기 전용 상태
네임노드에 문제가 생겨서 정삭적인 동작을 할 수 없을 때 자동으로 세이프 모드로 전황
관리자가 설정할 수도 있고 복구할 수도 있음
[3] 커럽트 블록
HDFS는 하트비트를 통해 전달받은 리포트로 자동으로 복구하지만 모든 복제 블록에 문제가 생겨 복구하지 못하게되면 커럽트 상태가 됨, 파일 복구 불가
hadoop fsck 명령으로 확인 가능
[4] 휴지통
HDFS는 삭제 시 바로 영구적으로 삭제하지 않고 휴지통 기능을 이용할 수 있음
[5] 이용량 제한 설정
특정 디렉토리의 용량 제한을 설정할 수 있음
[6] 밸런스
서로 다른 사양의 컴퓨터로 데이터 노드들을 구성하면
한 쪽에는 용량이 남고 한 쪽에는 용량이 부족한 일이 발생할 수 있음
이 때 밸런스를 조절해서 사용
6.Haduにデータを転送するコマンド
パスを先に設定する必要があります@@
PATH=$PATH:/opt/hadoop-3.2.2/bin
次にhdfs dfs,mkdir ls rmを加える
hdfs dfs -mkdir/dir
hdfs dfs -ls/
@@ls/スペース/im
HDfs dfs-put「保存するファイル」/「保存するパス」/
HDfs dfs-ls/dir保存確認
ウォーカーで
/data/hdfs/datanodeまたは
cd/tmp/hadoop-hdfs/dfs/data/current/を使用して、格納されたデータを表示
root@worker1:/tmp/hadoop-hdfs/dfs/data/current# ls
これでファイルが分散して表示されます
hdfs dfs -ls/dir2
「私の奮闘」ip:9870にアクセスするHaduのWebサイトでUtilitiesをクリックします.
ディレクトリが何なのかは見えますが、xをよく使います
7.マップのタイリング
Googleが発表したアルゴリズム
2つのタスクに分けられます:大マッピングタスクにリダイレクト
マッピング:成果物の集約
データをインポートしてキー値を合わせる
げんすい
バンドルされたデータを必要なキーと値に再結合します.
1)勤務先
Hadu v 1の作業単位はJob,Hadu v 2の作業単位はアプリケーション(アプリケーション)である.
YARNアーキテクチャを導入すると、名前は変更されましたが、管理方法は同じです.하둡 잡이 생성되면 아이디가 job_xxx_xxx 로 생성됩니다.
이 아이디로 잡의 상태, 로그를 확인할 수 있습니다. YARN에서는 application_xxx_xxx 로 확인할 수 있습니다.
접두어는 다르지만 같은 작업입니다.
잡에서 생성되는 맵태스크와 리듀스태스크는 아이디가 attempt_xxx_xxx_m_000000_0으로 생성됩니다.
맵태스크는 중간아이디가 m으로 생성되고, 리듀스 태스크는 r로 생성됩니다.
2)処理段階입력
데이터를 입력하는 단계
텍스트, csv, gzip 형태의 데이터를 읽어서 맵으로 전달
@@ 중요
맵(Map)
입력을 분할하여 키별로 데이터를 처리
컴바이너(Combiner)
네트워크를 타고 넘어가는 데이터를 줄이기 위하여 맵의 결과를 정리
로컬 리듀서라고도 함
컴바이너는 작업의 설정에 따라 없을 수도 있음
파티셔너(Partitoner)
맵의 출력 결과 키 값을 해쉬 처리하여 어떤 리듀서로 넘길지를 결정
셔플(Shuffle)
각 리듀서로 데이터 이동
정렬(Sort)
리듀서로 전달된 데이터를 키 값 기준으로 정렬
@@ 정렬과 셔플은 둘 중 하나만 있어도 됨
@@ 중요
리듀서(Reduce)
리듀서로 데이터를 처리하고 결과를 저장
출력
리듀서의 결과를 정의된 형태로 저장
3) YARN하둡1에서는 잡트래커가 애플리케이션의 라이프 사이클 관리와 클러스터 리소스 관리를 모두 담당하여 병목 현상이 발생하였습니다.
잡트래커 한대가 클러스터의 모든 노드를 관리해야 하고, 모든 애플리케이션의 관리 하였기 때문에
잡트래커에 많은 메모리를 할당 해야 했고, 최대 4000대의 노드까지 관리 할 수 있었습니다.
잡트래커는 슬롯 단위로 리소스를 관리하여 시스템의 전체 자원을 효율적으로 사용할 수 없었습니다.
슬롯 단위 리소스 관리는 클러스터의 메모리, CPU 자원을 분할하여 슬롯단위로 구분합니다.
예를 들면 100GB의 메모리를 가지는 클러스터를 1G로 구분하여 100개의 슬롯을 만들고, 60개의 맵 슬롯, 40개의 리듀서 슬롯으로 구분합니다.
슬롯은 각각의 역활에 맞게 동작할 수 있습니다.
따라서 맵 슬롯이 동작하는 동안 리듀서 슬롯은 대기하게 됩니다.
맵 슬롯에 더 많은 일을 하게 되더라도 리듀서 슬롯은 대기하게 됩니다.
잡 트래커의 애플리케이션은 맵리듀스 작업만 처리할 수 있어서 유연성이 부족하였습니다.
맵리듀스 API를 구현한 작업만 처리할 수 있었기 때문에 SQL 기반 작업의 처리나, 인메모리 기반의 작업의 처리에 어려움이 있었습니다.
이런 단점을 극복하기 위하여 YARN 아키텍처가 도입되었습니다.
(1) YARN 구성
YARN은 잡트래커의 기능을 분리하여 자원 관리는 리소스 매니저와 노드매니저가 담당
애플리케이션 라이프 사이클 관리 기능은 애플리케이션 마스터와 컨테이너가 담당하도록 하였습니다.
(2) YARN App
YARN에서는 맵리듀스로 구현된 프로그램 외에도 다양한 애플리케이션을 실행할 수 있습니다.
리듀스, 피그, 스톰, 스파크 등 하둡 에코시스템의 다양한 데이터 처리 기술을 이용할 수 있습니다.
4)マップのリフレッシュ例텍스트 파일을 하둡에 보내놓기
ex) file1이라는 파일안에 아무거나 적어 놓고 하둡안에 dir2안에 보내기
hdfs dfs -put file1 /dir2
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount [HDFS에 있는 대본 파일] /result
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount /dir2/file1 /result
dir2/file1의 wordcount를 한뒤 /result에 저장한다.
地図と平和舗装が一番下のように表示されると成功します
part-r-0000にデータを含める
catで確認すると、写真のように1文字3回使っていました
hadoop fs-get/result/part-r-0000を使用してローカルインポートを行います.
ローカルで-lsコマンドで検証可能
@Wordcountエラー解決方法
1)民秀の優しさ:メモリ不足
yarn-site.xml<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.resourcemanager.hostname</name>
<value>master</value>
</property>
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>1024</value> ----- 이부분의 메모리를 늘려준다.
</property>
<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>1</value>
</property>
<property>
<name>yarn.nodemanager.env-whitelist</name>
<value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
</property>
</configuration>
修正しましたstop all.shそして再開
2)PATH設定エラー
パスが解放されたか、設定が変更されました.
PATH=$PATH:/opt/hadoop-3.2.2/bin
3) hadoop java.net.connectexception:接続が拒否されました
stop all.shそして再開
4)Jaeryの場合、Hadoop:ResourceManagerへの接続に失敗しました
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:07 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 0 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:08 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 1 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:09 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 2 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
hadoop jar hadoop-mapreduce-examples-2.2.0.jar wordcount someFile.txt/out
このコマンドの後にjpsチェックを使用すると、ResourceManagerは消えます.
解決策:独自のメモリ容量を増やすことでこの問題を解決
5)Pythonコードで作成してみる
(1) mapper.py
#!/usr/bin/env python
import sys
for line in sys.stdin:
sys.stdin-複数行入力を受信します.
words = line.strip().split()
行間.strip()によるスペースの削除
行間.split()でスペースを基準に区切ります.
最終的にはスペースで区切られるので、単語単位で
for word in words:
print('{}\t{}'.format(word, 1))
単語と1の形式で印刷
(2) reducer.py
#!/usr/bin/env python
import sys
def print_output(word, count):
print('{}\t{}'.format(word, count))
word, count = None, 0
for line in sys.stdin:
fields = line.strip().split('\t')
split(t)-タブ間隔を基準に分割されます.タブがマッピングされている可能性があります.
if fields[0] != word:
if word is not None:
print_output(word, count)
word, count = fields[0], 0
count += 1
print_output(word, count)
Reference
この問題について(7-5下黒), 我々は、より多くの情報をここで見つけました
https://velog.io/@kst5137/7-5-하둡
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
1) Hadoop Common
下図の他のモジュールをサポートする汎用コンポーネントモジュール
2) Hadoop HDFS
分散型ストレージの処理に使用されるモジュール
複数のサーバを1台のサーバに組み合わせてデータを格納
ファイルの保存方法
データがある程度蓄積されたときに記憶する
リアルタイムではなくバッチに特化した設計
3) Hadoop YARN
並列処理のためのクラスタリソースの管理とスケジューリング
4) Hadoop Mapreduce
分散ストレージのデータを並列に処理する分散処理モジュール
3.河豆のメリットとデメリット
長所
オープンソースのライセンスコストが低い
システムを中断することなくデバイスを追加
一部のデバイスに障害が発生しても、システム全体の可用性には影響しません(障害許容)
データ処理速度が速く、導入コストが低い
オフラインバッチの最適化
短所
HDFSに格納されているデータは変更できません
リアルタイムデータ分析など、迅速な処理が必要なタスクには適していません.
多くのバージョンと信頼性の低いサブタイトル
設置が困難である.
4.河豆の進化過程
1)下黒v 1
分散ストレージ、並列処理フレームワークの定義
分散型ストレージ(HDFS)
名前ノード、データノードで処理
へいれつしょり
捕獲者、タスク追跡者処理.
クラスタあたり最大4,000ノードの登録
タスクをスロット単位で処理
分割マップ、タイルスロットによる処理
2)下黒v 2
2012年に正式に発表されたHaduv 2は、v 1のサーカスボトルネックを解消するためにYARNアーキテクチャを導入した.
クラスタ管理
アセットマネージャ、ノードマネージャ
タスク管理
アプリケーションのメインノード、コンテナ
MRに加えて、Spark、Hive、Pigなどの他の分散処理モデルを実行することもできる.
クラスタごとに1万以上のノードを登録できます
コンテナ単位でタスクを処理する
3)下黒v 3
レーザエンコーディングの導入
従来のブロックコピーに代わることでHDFSの使用を減らす
YARN時間軸サービスv 2の導入
従来のタイムラインサービスよりも多くの情報を提供
わかりやすい形式でスクリプトを再作成および変更
古いスクリプトを再作成してエラーを修正
JAVA 8サポート
ネイティブ・コードの最適化
複数の名前ノードをサポートし、高可用性を実現
複数の追加可能な代替ノードをサポート
Ozoneの追加
オブジェクトリポジトリの追加
5. HDFS
HDFS(Hadoop Distributed File System)は高価なハードディスクではありません.
ターゲットは、障害復旧性のある分散ファイルシステムです.
HDFSは、リアルタイム処理ではなくバッチ処理のために設計されている.
これは、高速なデータ応答時間を必要とするタスクには適していません.
また,名前ノードは単一の障害(SPOF)となるため,名前ノードの管理が重要である.
1)特徴
(1)ブロック単位の保存
HDFSはブロック単位でデータを格納する.
ブロックサイズより小さいファイルを既存のファイルのサイズとして保存し、
データファイルはブロック単位で格納されるため、単一のディスク上のデータよりも大きなファイルを格納できます.
ブロック単位が256 MBの場合、1 Gファイルは4つのブロックに分けられ、10 MBファイルは1つのブロックに分けられる.
(2)ブロックコピーによるフェイルオーバ
HDFSは、フェイルオーバのために各ブロックをコピーして格納する.
ブロックのデフォルトコピー単位は3です.1つのブロックを3つのブロックにコピーします.
同じラックのサーバと別のラックのサーバにコピーして保存します.
ブロックに問題が発生した場合は、コピーした他のブロックを使用してデータを復元します.
1 Gbデータを格納する場合、データはコピーされ、3 Gbの格納スペースが必要となります.
(3)読解中心
HDFSは、1回の書き込み時に複数回データを読み出すことを目標としている.したがって、ファイルの変更はサポートされていません.
ファイルの変更を制限することで、操作を簡素化し、データの読み取り速度を向上させることができます.
(4)データ領域性
マップリフレッシュはHDFSのデータ領域性を利用して処理速度を速める.
処理アルゴリズムが存在する場所にデータを移動しません.
データが存在する位置でアルゴリズムを処理することで,ネットワークを介して大量のデータを移動するコストを低減できる.
2)構造
HDFSは、1つの名前ノードと複数のデータノードからなるプライマリ依存構造である.
名前ノードにはメタデータがあり、データはブロック単位でデータノードに格納されます.
ユーザーは、名前ノードを使用してデータの書き込みと読み取りを行うことができます.(1) 네임노드
메타데이터 관리와 데이터노드를 관리
메타데이터는 파일이름, 파일크기, 파일생성시간, 파일접근권한, 파일 소유자 및 그룹 소유자, 파일이 위치한 블록의 정보 등으로 구성됩니다.
각 데이터노드에서 전달하는 메타데이터를 받아서 전체 노드의 메타데이터 정보와 파일 정보를 묶어서 관리합니다.
메타데이터는 사용자가 설정한 위치(dfs.name.name.dir)에 보관됩니다.
네임노드가 실행 될 때 파일을 읽어서 메모리에 보관합니다.
운영중에 발생한 수정사항은 네임노드의 메모리에는 바로 적용되고, 데이터의 수정사항을 다음 구동시 적용을 위해서 주기적으로 Edist 파일로 저장합니다.
메타데이터 파일 종류
Fsimage 파일
네임스페이스와 블록 정보
Edits 파일
파일의 생성, 삭제에 대한 트랜잭션 로그
메모리에 저장하다가 주기적으로 생성
(2) 데이터 노드
데이타노드는 파일을 저장하는 역할
파일은 블록단위로 저장됩니다. 데이타노드는 주기적으로 네임노드에 하트비트와 블록리포트를 전달합니다.
하트비트는 데이타노드의 동작여부를 판단하는데 이용됩니다.
네임노드는 하트비트가 전달되지 않는 데이터노드는 동작하지 않는 것으로 판단하여 더이상 데이터를 저장하지 않도록 설정합니다.
블록리포트로 블록의 변경사항을 체크하고, 네임노드의 메타데이터를 갱신합니다.
블록 파일 저장형태
사용자가 설정한 위치(dfs.data.dir)에 저장됩니다.
[1] 데이터 노드 상태
ㄱ. 활성상태
활성 상태는 데이터노드가 Live 상태인지 Dead 상태인지를 나타냅니다.
데이터노드가 하트비트를 주기적으로 전달하여 살아 있는지 확인되면 Live 상태입니다.
데이터노드에 문제가 발생하여 지정한 시간동안(dfs.namenode.stale.datanode.interval)하트비트를 받지 못하면
네임노드는 데이터노드의 상태를 Stale 상태로 변경합니다. 이후 지정한 시간동안 응답이 없으면 Dead 노드로 변경합니다.
ㄴ. 운영 상태
운영 상태는 데이터노드의 업그레이드, 패치 같은 작업을 하기 위해 서비스를 잠시 멈추어야 할 경우 블록을 안전하게 보관하기 위해 설정하는 상태
NORMAL: 서비스 상태
DECOMMISSIONED: 서비스 중단 상태
DECOMMISSION_INPROGRESS: 서비스 중단 상태로 진행 중
IN_MAINTENANCE: 정비 상태
ENTERING_MAINTENANCE: 정비 상태로 진행 중
[2] 파일 읽기/쓰기
HDFS의 파일에 접근하는 가장 간단한 방법은 HDFS 명령행 인터페이스를 이용하는 것입니다.
또한 Java, C API를 제공하여 이를 구현해서 접근하면 됩니다.
ㄱ. 파일 읽기
네임노드에 파일이 보관된 블록 위치 요청
네임노드가 블록 위치 반환
각 데이터 노드에 파일 블록을 요청
노드의 블록이 깨져 있으면 네임노드에 이를 통지하고 다른 블록 확인
ㄴ. 파일 쓰기
네임노드에 파일 정보를 전송하고, 파일의 블록을 써야할 노드 목록 요청
네임노드가 파일을 저장할 목록 반환
데이터 노드에 파일 쓰기 요청
데이터 노드간 복제가 진행
3)コマンド
https://hadoop.apache.org/docs/r3.2.2/hadoop-project-dist/hadoop-common/FileSystemShell.html (1) 사용자
hdfs dfs -[서브명령어] or hadoop fs -[서브명령어]
자주 사용하는 서브 명령어
ls 안에 내용물 확인
rm -r 삭제
mkdir 디렉토리만들기
cat 내용물보기
mv 이동
cp 복사
du hdfs내부의 특정 file이나 디렉토리의 사이즈를 보여줌
du -s : 각각의 파일의 size의 sum값을 보여줌
-stat %b 용량을 바이트 단위로 본다
-stat %o 차지한 블록사이즈 보기(실제 용량과 블록사이즈는 다를 수 있음)
-stat %r 복사본이 몇개있나 확인
copyFromLocal 로컬에서 하둡으로 업로드
copyToLocal 하둡에서 로컬로
hdfs dfs -get /user/data1.txt ./ # 파일을 로컬에 복사
hdfs dfs -get -f /user/data1.txt ./ # 파일을 로컬에 복사, 동일한 파일이 있으면 덮어 씀.
hdfs dfs -put ./data1.txt /user/ # 로컬 파일을 hdfs에 복사
hdfs dfs -put -f ./data1.txt /user/ # 로컬 파일을 hdfs에 복사, 동일한 파일이 있으면 덮어 씀.
(2)管理者[1] Rack Awareness
블록을 저장할 때 2개의 블록은 같은 랙에, 나머지 하나는 다른랙에 저장하도록 구성
[2] HDFS 세이프모드
데이터의 저장 및 삭제가 불가능한 상태, 읽기 전용 상태
네임노드에 문제가 생겨서 정삭적인 동작을 할 수 없을 때 자동으로 세이프 모드로 전황
관리자가 설정할 수도 있고 복구할 수도 있음
[3] 커럽트 블록
HDFS는 하트비트를 통해 전달받은 리포트로 자동으로 복구하지만 모든 복제 블록에 문제가 생겨 복구하지 못하게되면 커럽트 상태가 됨, 파일 복구 불가
hadoop fsck 명령으로 확인 가능
[4] 휴지통
HDFS는 삭제 시 바로 영구적으로 삭제하지 않고 휴지통 기능을 이용할 수 있음
[5] 이용량 제한 설정
특정 디렉토리의 용량 제한을 설정할 수 있음
[6] 밸런스
서로 다른 사양의 컴퓨터로 데이터 노드들을 구성하면
한 쪽에는 용량이 남고 한 쪽에는 용량이 부족한 일이 발생할 수 있음
이 때 밸런스를 조절해서 사용
6.Haduにデータを転送するコマンド
パスを先に設定する必要があります@@
PATH=$PATH:/opt/hadoop-3.2.2/bin
次にhdfs dfs,mkdir ls rmを加える
hdfs dfs -mkdir/dir
hdfs dfs -ls/
@@ls/スペース/im
HDfs dfs-put「保存するファイル」/「保存するパス」/
HDfs dfs-ls/dir保存確認
ウォーカーで
/data/hdfs/datanodeまたは
cd/tmp/hadoop-hdfs/dfs/data/current/を使用して、格納されたデータを表示
root@worker1:/tmp/hadoop-hdfs/dfs/data/current# ls
これでファイルが分散して表示されます
hdfs dfs -ls/dir2
「私の奮闘」ip:9870にアクセスするHaduのWebサイトでUtilitiesをクリックします.
ディレクトリが何なのかは見えますが、xをよく使います
7.マップのタイリング
Googleが発表したアルゴリズム
2つのタスクに分けられます:大マッピングタスクにリダイレクト
マッピング:成果物の集約
データをインポートしてキー値を合わせる
げんすい
バンドルされたデータを必要なキーと値に再結合します.
1)勤務先
Hadu v 1の作業単位はJob,Hadu v 2の作業単位はアプリケーション(アプリケーション)である.
YARNアーキテクチャを導入すると、名前は変更されましたが、管理方法は同じです.하둡 잡이 생성되면 아이디가 job_xxx_xxx 로 생성됩니다.
이 아이디로 잡의 상태, 로그를 확인할 수 있습니다. YARN에서는 application_xxx_xxx 로 확인할 수 있습니다.
접두어는 다르지만 같은 작업입니다.
잡에서 생성되는 맵태스크와 리듀스태스크는 아이디가 attempt_xxx_xxx_m_000000_0으로 생성됩니다.
맵태스크는 중간아이디가 m으로 생성되고, 리듀스 태스크는 r로 생성됩니다.
2)処理段階입력
데이터를 입력하는 단계
텍스트, csv, gzip 형태의 데이터를 읽어서 맵으로 전달
@@ 중요
맵(Map)
입력을 분할하여 키별로 데이터를 처리
컴바이너(Combiner)
네트워크를 타고 넘어가는 데이터를 줄이기 위하여 맵의 결과를 정리
로컬 리듀서라고도 함
컴바이너는 작업의 설정에 따라 없을 수도 있음
파티셔너(Partitoner)
맵의 출력 결과 키 값을 해쉬 처리하여 어떤 리듀서로 넘길지를 결정
셔플(Shuffle)
각 리듀서로 데이터 이동
정렬(Sort)
리듀서로 전달된 데이터를 키 값 기준으로 정렬
@@ 정렬과 셔플은 둘 중 하나만 있어도 됨
@@ 중요
리듀서(Reduce)
리듀서로 데이터를 처리하고 결과를 저장
출력
리듀서의 결과를 정의된 형태로 저장
3) YARN하둡1에서는 잡트래커가 애플리케이션의 라이프 사이클 관리와 클러스터 리소스 관리를 모두 담당하여 병목 현상이 발생하였습니다.
잡트래커 한대가 클러스터의 모든 노드를 관리해야 하고, 모든 애플리케이션의 관리 하였기 때문에
잡트래커에 많은 메모리를 할당 해야 했고, 최대 4000대의 노드까지 관리 할 수 있었습니다.
잡트래커는 슬롯 단위로 리소스를 관리하여 시스템의 전체 자원을 효율적으로 사용할 수 없었습니다.
슬롯 단위 리소스 관리는 클러스터의 메모리, CPU 자원을 분할하여 슬롯단위로 구분합니다.
예를 들면 100GB의 메모리를 가지는 클러스터를 1G로 구분하여 100개의 슬롯을 만들고, 60개의 맵 슬롯, 40개의 리듀서 슬롯으로 구분합니다.
슬롯은 각각의 역활에 맞게 동작할 수 있습니다.
따라서 맵 슬롯이 동작하는 동안 리듀서 슬롯은 대기하게 됩니다.
맵 슬롯에 더 많은 일을 하게 되더라도 리듀서 슬롯은 대기하게 됩니다.
잡 트래커의 애플리케이션은 맵리듀스 작업만 처리할 수 있어서 유연성이 부족하였습니다.
맵리듀스 API를 구현한 작업만 처리할 수 있었기 때문에 SQL 기반 작업의 처리나, 인메모리 기반의 작업의 처리에 어려움이 있었습니다.
이런 단점을 극복하기 위하여 YARN 아키텍처가 도입되었습니다.
(1) YARN 구성
YARN은 잡트래커의 기능을 분리하여 자원 관리는 리소스 매니저와 노드매니저가 담당
애플리케이션 라이프 사이클 관리 기능은 애플리케이션 마스터와 컨테이너가 담당하도록 하였습니다.
(2) YARN App
YARN에서는 맵리듀스로 구현된 프로그램 외에도 다양한 애플리케이션을 실행할 수 있습니다.
리듀스, 피그, 스톰, 스파크 등 하둡 에코시스템의 다양한 데이터 처리 기술을 이용할 수 있습니다.
4)マップのリフレッシュ例텍스트 파일을 하둡에 보내놓기
ex) file1이라는 파일안에 아무거나 적어 놓고 하둡안에 dir2안에 보내기
hdfs dfs -put file1 /dir2
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount [HDFS에 있는 대본 파일] /result
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount /dir2/file1 /result
dir2/file1의 wordcount를 한뒤 /result에 저장한다.
地図と平和舗装が一番下のように表示されると成功します
part-r-0000にデータを含める
catで確認すると、写真のように1文字3回使っていました
hadoop fs-get/result/part-r-0000を使用してローカルインポートを行います.
ローカルで-lsコマンドで検証可能
@Wordcountエラー解決方法
1)民秀の優しさ:メモリ不足
yarn-site.xml<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.resourcemanager.hostname</name>
<value>master</value>
</property>
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>1024</value> ----- 이부분의 메모리를 늘려준다.
</property>
<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>1</value>
</property>
<property>
<name>yarn.nodemanager.env-whitelist</name>
<value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
</property>
</configuration>
修正しましたstop all.shそして再開
2)PATH設定エラー
パスが解放されたか、設定が変更されました.
PATH=$PATH:/opt/hadoop-3.2.2/bin
3) hadoop java.net.connectexception:接続が拒否されました
stop all.shそして再開
4)Jaeryの場合、Hadoop:ResourceManagerへの接続に失敗しました
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:07 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 0 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:08 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 1 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:09 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 2 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
hadoop jar hadoop-mapreduce-examples-2.2.0.jar wordcount someFile.txt/out
このコマンドの後にjpsチェックを使用すると、ResourceManagerは消えます.
解決策:独自のメモリ容量を増やすことでこの問題を解決
5)Pythonコードで作成してみる
(1) mapper.py
#!/usr/bin/env python
import sys
for line in sys.stdin:
sys.stdin-複数行入力を受信します.
words = line.strip().split()
行間.strip()によるスペースの削除
行間.split()でスペースを基準に区切ります.
最終的にはスペースで区切られるので、単語単位で
for word in words:
print('{}\t{}'.format(word, 1))
単語と1の形式で印刷
(2) reducer.py
#!/usr/bin/env python
import sys
def print_output(word, count):
print('{}\t{}'.format(word, count))
word, count = None, 0
for line in sys.stdin:
fields = line.strip().split('\t')
split(t)-タブ間隔を基準に分割されます.タブがマッピングされている可能性があります.
if fields[0] != word:
if word is not None:
print_output(word, count)
word, count = fields[0], 0
count += 1
print_output(word, count)
Reference
この問題について(7-5下黒), 我々は、より多くの情報をここで見つけました
https://velog.io/@kst5137/7-5-하둡
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
1)下黒v 1
分散ストレージ、並列処理フレームワークの定義
分散型ストレージ(HDFS)
名前ノード、データノードで処理
へいれつしょり
捕獲者、タスク追跡者処理.
クラスタあたり最大4,000ノードの登録
タスクをスロット単位で処理
分割マップ、タイルスロットによる処理
2)下黒v 2
2012年に正式に発表されたHaduv 2は、v 1のサーカスボトルネックを解消するためにYARNアーキテクチャを導入した.
クラスタ管理
アセットマネージャ、ノードマネージャ
タスク管理
アプリケーションのメインノード、コンテナ
MRに加えて、Spark、Hive、Pigなどの他の分散処理モデルを実行することもできる.
クラスタごとに1万以上のノードを登録できます
コンテナ単位でタスクを処理する
3)下黒v 3
レーザエンコーディングの導入
従来のブロックコピーに代わることでHDFSの使用を減らす
YARN時間軸サービスv 2の導入
従来のタイムラインサービスよりも多くの情報を提供
わかりやすい形式でスクリプトを再作成および変更
古いスクリプトを再作成してエラーを修正
JAVA 8サポート
ネイティブ・コードの最適化
複数の名前ノードをサポートし、高可用性を実現
複数の追加可能な代替ノードをサポート
Ozoneの追加
オブジェクトリポジトリの追加
5. HDFS
HDFS(Hadoop Distributed File System)は高価なハードディスクではありません.
ターゲットは、障害復旧性のある分散ファイルシステムです.
HDFSは、リアルタイム処理ではなくバッチ処理のために設計されている.
これは、高速なデータ応答時間を必要とするタスクには適していません.
また,名前ノードは単一の障害(SPOF)となるため,名前ノードの管理が重要である.
1)特徴
(1)ブロック単位の保存
HDFSはブロック単位でデータを格納する.
ブロックサイズより小さいファイルを既存のファイルのサイズとして保存し、
データファイルはブロック単位で格納されるため、単一のディスク上のデータよりも大きなファイルを格納できます.
ブロック単位が256 MBの場合、1 Gファイルは4つのブロックに分けられ、10 MBファイルは1つのブロックに分けられる.
(2)ブロックコピーによるフェイルオーバ
HDFSは、フェイルオーバのために各ブロックをコピーして格納する.
ブロックのデフォルトコピー単位は3です.1つのブロックを3つのブロックにコピーします.
同じラックのサーバと別のラックのサーバにコピーして保存します.
ブロックに問題が発生した場合は、コピーした他のブロックを使用してデータを復元します.
1 Gbデータを格納する場合、データはコピーされ、3 Gbの格納スペースが必要となります.
(3)読解中心
HDFSは、1回の書き込み時に複数回データを読み出すことを目標としている.したがって、ファイルの変更はサポートされていません.
ファイルの変更を制限することで、操作を簡素化し、データの読み取り速度を向上させることができます.
(4)データ領域性
マップリフレッシュはHDFSのデータ領域性を利用して処理速度を速める.
処理アルゴリズムが存在する場所にデータを移動しません.
データが存在する位置でアルゴリズムを処理することで,ネットワークを介して大量のデータを移動するコストを低減できる.
2)構造
HDFSは、1つの名前ノードと複数のデータノードからなるプライマリ依存構造である.
名前ノードにはメタデータがあり、データはブロック単位でデータノードに格納されます.
ユーザーは、名前ノードを使用してデータの書き込みと読み取りを行うことができます.(1) 네임노드
메타데이터 관리와 데이터노드를 관리
메타데이터는 파일이름, 파일크기, 파일생성시간, 파일접근권한, 파일 소유자 및 그룹 소유자, 파일이 위치한 블록의 정보 등으로 구성됩니다.
각 데이터노드에서 전달하는 메타데이터를 받아서 전체 노드의 메타데이터 정보와 파일 정보를 묶어서 관리합니다.
메타데이터는 사용자가 설정한 위치(dfs.name.name.dir)에 보관됩니다.
네임노드가 실행 될 때 파일을 읽어서 메모리에 보관합니다.
운영중에 발생한 수정사항은 네임노드의 메모리에는 바로 적용되고, 데이터의 수정사항을 다음 구동시 적용을 위해서 주기적으로 Edist 파일로 저장합니다.
메타데이터 파일 종류
Fsimage 파일
네임스페이스와 블록 정보
Edits 파일
파일의 생성, 삭제에 대한 트랜잭션 로그
메모리에 저장하다가 주기적으로 생성
(2) 데이터 노드
데이타노드는 파일을 저장하는 역할
파일은 블록단위로 저장됩니다. 데이타노드는 주기적으로 네임노드에 하트비트와 블록리포트를 전달합니다.
하트비트는 데이타노드의 동작여부를 판단하는데 이용됩니다.
네임노드는 하트비트가 전달되지 않는 데이터노드는 동작하지 않는 것으로 판단하여 더이상 데이터를 저장하지 않도록 설정합니다.
블록리포트로 블록의 변경사항을 체크하고, 네임노드의 메타데이터를 갱신합니다.
블록 파일 저장형태
사용자가 설정한 위치(dfs.data.dir)에 저장됩니다.
[1] 데이터 노드 상태
ㄱ. 활성상태
활성 상태는 데이터노드가 Live 상태인지 Dead 상태인지를 나타냅니다.
데이터노드가 하트비트를 주기적으로 전달하여 살아 있는지 확인되면 Live 상태입니다.
데이터노드에 문제가 발생하여 지정한 시간동안(dfs.namenode.stale.datanode.interval)하트비트를 받지 못하면
네임노드는 데이터노드의 상태를 Stale 상태로 변경합니다. 이후 지정한 시간동안 응답이 없으면 Dead 노드로 변경합니다.
ㄴ. 운영 상태
운영 상태는 데이터노드의 업그레이드, 패치 같은 작업을 하기 위해 서비스를 잠시 멈추어야 할 경우 블록을 안전하게 보관하기 위해 설정하는 상태
NORMAL: 서비스 상태
DECOMMISSIONED: 서비스 중단 상태
DECOMMISSION_INPROGRESS: 서비스 중단 상태로 진행 중
IN_MAINTENANCE: 정비 상태
ENTERING_MAINTENANCE: 정비 상태로 진행 중
[2] 파일 읽기/쓰기
HDFS의 파일에 접근하는 가장 간단한 방법은 HDFS 명령행 인터페이스를 이용하는 것입니다.
또한 Java, C API를 제공하여 이를 구현해서 접근하면 됩니다.
ㄱ. 파일 읽기
네임노드에 파일이 보관된 블록 위치 요청
네임노드가 블록 위치 반환
각 데이터 노드에 파일 블록을 요청
노드의 블록이 깨져 있으면 네임노드에 이를 통지하고 다른 블록 확인
ㄴ. 파일 쓰기
네임노드에 파일 정보를 전송하고, 파일의 블록을 써야할 노드 목록 요청
네임노드가 파일을 저장할 목록 반환
데이터 노드에 파일 쓰기 요청
데이터 노드간 복제가 진행
3)コマンド
https://hadoop.apache.org/docs/r3.2.2/hadoop-project-dist/hadoop-common/FileSystemShell.html (1) 사용자
hdfs dfs -[서브명령어] or hadoop fs -[서브명령어]
자주 사용하는 서브 명령어
ls 안에 내용물 확인
rm -r 삭제
mkdir 디렉토리만들기
cat 내용물보기
mv 이동
cp 복사
du hdfs내부의 특정 file이나 디렉토리의 사이즈를 보여줌
du -s : 각각의 파일의 size의 sum값을 보여줌
-stat %b 용량을 바이트 단위로 본다
-stat %o 차지한 블록사이즈 보기(실제 용량과 블록사이즈는 다를 수 있음)
-stat %r 복사본이 몇개있나 확인
copyFromLocal 로컬에서 하둡으로 업로드
copyToLocal 하둡에서 로컬로
hdfs dfs -get /user/data1.txt ./ # 파일을 로컬에 복사
hdfs dfs -get -f /user/data1.txt ./ # 파일을 로컬에 복사, 동일한 파일이 있으면 덮어 씀.
hdfs dfs -put ./data1.txt /user/ # 로컬 파일을 hdfs에 복사
hdfs dfs -put -f ./data1.txt /user/ # 로컬 파일을 hdfs에 복사, 동일한 파일이 있으면 덮어 씀.
(2)管理者[1] Rack Awareness
블록을 저장할 때 2개의 블록은 같은 랙에, 나머지 하나는 다른랙에 저장하도록 구성
[2] HDFS 세이프모드
데이터의 저장 및 삭제가 불가능한 상태, 읽기 전용 상태
네임노드에 문제가 생겨서 정삭적인 동작을 할 수 없을 때 자동으로 세이프 모드로 전황
관리자가 설정할 수도 있고 복구할 수도 있음
[3] 커럽트 블록
HDFS는 하트비트를 통해 전달받은 리포트로 자동으로 복구하지만 모든 복제 블록에 문제가 생겨 복구하지 못하게되면 커럽트 상태가 됨, 파일 복구 불가
hadoop fsck 명령으로 확인 가능
[4] 휴지통
HDFS는 삭제 시 바로 영구적으로 삭제하지 않고 휴지통 기능을 이용할 수 있음
[5] 이용량 제한 설정
특정 디렉토리의 용량 제한을 설정할 수 있음
[6] 밸런스
서로 다른 사양의 컴퓨터로 데이터 노드들을 구성하면
한 쪽에는 용량이 남고 한 쪽에는 용량이 부족한 일이 발생할 수 있음
이 때 밸런스를 조절해서 사용
6.Haduにデータを転送するコマンド
パスを先に設定する必要があります@@
PATH=$PATH:/opt/hadoop-3.2.2/bin
次にhdfs dfs,mkdir ls rmを加える
hdfs dfs -mkdir/dir
hdfs dfs -ls/
@@ls/スペース/im
HDfs dfs-put「保存するファイル」/「保存するパス」/
HDfs dfs-ls/dir保存確認
ウォーカーで
/data/hdfs/datanodeまたは
cd/tmp/hadoop-hdfs/dfs/data/current/を使用して、格納されたデータを表示
root@worker1:/tmp/hadoop-hdfs/dfs/data/current# ls
これでファイルが分散して表示されます
hdfs dfs -ls/dir2
「私の奮闘」ip:9870にアクセスするHaduのWebサイトでUtilitiesをクリックします.
ディレクトリが何なのかは見えますが、xをよく使います
7.マップのタイリング
Googleが発表したアルゴリズム
2つのタスクに分けられます:大マッピングタスクにリダイレクト
マッピング:成果物の集約
データをインポートしてキー値を合わせる
げんすい
バンドルされたデータを必要なキーと値に再結合します.
1)勤務先
Hadu v 1の作業単位はJob,Hadu v 2の作業単位はアプリケーション(アプリケーション)である.
YARNアーキテクチャを導入すると、名前は変更されましたが、管理方法は同じです.하둡 잡이 생성되면 아이디가 job_xxx_xxx 로 생성됩니다.
이 아이디로 잡의 상태, 로그를 확인할 수 있습니다. YARN에서는 application_xxx_xxx 로 확인할 수 있습니다.
접두어는 다르지만 같은 작업입니다.
잡에서 생성되는 맵태스크와 리듀스태스크는 아이디가 attempt_xxx_xxx_m_000000_0으로 생성됩니다.
맵태스크는 중간아이디가 m으로 생성되고, 리듀스 태스크는 r로 생성됩니다.
2)処理段階입력
데이터를 입력하는 단계
텍스트, csv, gzip 형태의 데이터를 읽어서 맵으로 전달
@@ 중요
맵(Map)
입력을 분할하여 키별로 데이터를 처리
컴바이너(Combiner)
네트워크를 타고 넘어가는 데이터를 줄이기 위하여 맵의 결과를 정리
로컬 리듀서라고도 함
컴바이너는 작업의 설정에 따라 없을 수도 있음
파티셔너(Partitoner)
맵의 출력 결과 키 값을 해쉬 처리하여 어떤 리듀서로 넘길지를 결정
셔플(Shuffle)
각 리듀서로 데이터 이동
정렬(Sort)
리듀서로 전달된 데이터를 키 값 기준으로 정렬
@@ 정렬과 셔플은 둘 중 하나만 있어도 됨
@@ 중요
리듀서(Reduce)
리듀서로 데이터를 처리하고 결과를 저장
출력
리듀서의 결과를 정의된 형태로 저장
3) YARN하둡1에서는 잡트래커가 애플리케이션의 라이프 사이클 관리와 클러스터 리소스 관리를 모두 담당하여 병목 현상이 발생하였습니다.
잡트래커 한대가 클러스터의 모든 노드를 관리해야 하고, 모든 애플리케이션의 관리 하였기 때문에
잡트래커에 많은 메모리를 할당 해야 했고, 최대 4000대의 노드까지 관리 할 수 있었습니다.
잡트래커는 슬롯 단위로 리소스를 관리하여 시스템의 전체 자원을 효율적으로 사용할 수 없었습니다.
슬롯 단위 리소스 관리는 클러스터의 메모리, CPU 자원을 분할하여 슬롯단위로 구분합니다.
예를 들면 100GB의 메모리를 가지는 클러스터를 1G로 구분하여 100개의 슬롯을 만들고, 60개의 맵 슬롯, 40개의 리듀서 슬롯으로 구분합니다.
슬롯은 각각의 역활에 맞게 동작할 수 있습니다.
따라서 맵 슬롯이 동작하는 동안 리듀서 슬롯은 대기하게 됩니다.
맵 슬롯에 더 많은 일을 하게 되더라도 리듀서 슬롯은 대기하게 됩니다.
잡 트래커의 애플리케이션은 맵리듀스 작업만 처리할 수 있어서 유연성이 부족하였습니다.
맵리듀스 API를 구현한 작업만 처리할 수 있었기 때문에 SQL 기반 작업의 처리나, 인메모리 기반의 작업의 처리에 어려움이 있었습니다.
이런 단점을 극복하기 위하여 YARN 아키텍처가 도입되었습니다.
(1) YARN 구성
YARN은 잡트래커의 기능을 분리하여 자원 관리는 리소스 매니저와 노드매니저가 담당
애플리케이션 라이프 사이클 관리 기능은 애플리케이션 마스터와 컨테이너가 담당하도록 하였습니다.
(2) YARN App
YARN에서는 맵리듀스로 구현된 프로그램 외에도 다양한 애플리케이션을 실행할 수 있습니다.
리듀스, 피그, 스톰, 스파크 등 하둡 에코시스템의 다양한 데이터 처리 기술을 이용할 수 있습니다.
4)マップのリフレッシュ例텍스트 파일을 하둡에 보내놓기
ex) file1이라는 파일안에 아무거나 적어 놓고 하둡안에 dir2안에 보내기
hdfs dfs -put file1 /dir2
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount [HDFS에 있는 대본 파일] /result
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount /dir2/file1 /result
dir2/file1의 wordcount를 한뒤 /result에 저장한다.
地図と平和舗装が一番下のように表示されると成功します
part-r-0000にデータを含める
catで確認すると、写真のように1文字3回使っていました
hadoop fs-get/result/part-r-0000を使用してローカルインポートを行います.
ローカルで-lsコマンドで検証可能
@Wordcountエラー解決方法
1)民秀の優しさ:メモリ不足
yarn-site.xml<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.resourcemanager.hostname</name>
<value>master</value>
</property>
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>1024</value> ----- 이부분의 메모리를 늘려준다.
</property>
<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>1</value>
</property>
<property>
<name>yarn.nodemanager.env-whitelist</name>
<value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
</property>
</configuration>
修正しましたstop all.shそして再開
2)PATH設定エラー
パスが解放されたか、設定が変更されました.
PATH=$PATH:/opt/hadoop-3.2.2/bin
3) hadoop java.net.connectexception:接続が拒否されました
stop all.shそして再開
4)Jaeryの場合、Hadoop:ResourceManagerへの接続に失敗しました
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:07 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 0 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:08 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 1 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:09 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 2 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
hadoop jar hadoop-mapreduce-examples-2.2.0.jar wordcount someFile.txt/out
このコマンドの後にjpsチェックを使用すると、ResourceManagerは消えます.
解決策:独自のメモリ容量を増やすことでこの問題を解決
5)Pythonコードで作成してみる
(1) mapper.py
#!/usr/bin/env python
import sys
for line in sys.stdin:
sys.stdin-複数行入力を受信します.
words = line.strip().split()
行間.strip()によるスペースの削除
行間.split()でスペースを基準に区切ります.
最終的にはスペースで区切られるので、単語単位で
for word in words:
print('{}\t{}'.format(word, 1))
単語と1の形式で印刷
(2) reducer.py
#!/usr/bin/env python
import sys
def print_output(word, count):
print('{}\t{}'.format(word, count))
word, count = None, 0
for line in sys.stdin:
fields = line.strip().split('\t')
split(t)-タブ間隔を基準に分割されます.タブがマッピングされている可能性があります.
if fields[0] != word:
if word is not None:
print_output(word, count)
word, count = fields[0], 0
count += 1
print_output(word, count)
Reference
この問題について(7-5下黒), 我々は、より多くの情報をここで見つけました
https://velog.io/@kst5137/7-5-하둡
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
(1) 네임노드
메타데이터 관리와 데이터노드를 관리
메타데이터는 파일이름, 파일크기, 파일생성시간, 파일접근권한, 파일 소유자 및 그룹 소유자, 파일이 위치한 블록의 정보 등으로 구성됩니다.
각 데이터노드에서 전달하는 메타데이터를 받아서 전체 노드의 메타데이터 정보와 파일 정보를 묶어서 관리합니다.
메타데이터는 사용자가 설정한 위치(dfs.name.name.dir)에 보관됩니다.
네임노드가 실행 될 때 파일을 읽어서 메모리에 보관합니다.
운영중에 발생한 수정사항은 네임노드의 메모리에는 바로 적용되고, 데이터의 수정사항을 다음 구동시 적용을 위해서 주기적으로 Edist 파일로 저장합니다.
메타데이터 파일 종류
Fsimage 파일
네임스페이스와 블록 정보
Edits 파일
파일의 생성, 삭제에 대한 트랜잭션 로그
메모리에 저장하다가 주기적으로 생성
(2) 데이터 노드
데이타노드는 파일을 저장하는 역할
파일은 블록단위로 저장됩니다. 데이타노드는 주기적으로 네임노드에 하트비트와 블록리포트를 전달합니다.
하트비트는 데이타노드의 동작여부를 판단하는데 이용됩니다.
네임노드는 하트비트가 전달되지 않는 데이터노드는 동작하지 않는 것으로 판단하여 더이상 데이터를 저장하지 않도록 설정합니다.
블록리포트로 블록의 변경사항을 체크하고, 네임노드의 메타데이터를 갱신합니다.
블록 파일 저장형태
사용자가 설정한 위치(dfs.data.dir)에 저장됩니다.
[1] 데이터 노드 상태
ㄱ. 활성상태
활성 상태는 데이터노드가 Live 상태인지 Dead 상태인지를 나타냅니다.
데이터노드가 하트비트를 주기적으로 전달하여 살아 있는지 확인되면 Live 상태입니다.
데이터노드에 문제가 발생하여 지정한 시간동안(dfs.namenode.stale.datanode.interval)하트비트를 받지 못하면
네임노드는 데이터노드의 상태를 Stale 상태로 변경합니다. 이후 지정한 시간동안 응답이 없으면 Dead 노드로 변경합니다.
ㄴ. 운영 상태
운영 상태는 데이터노드의 업그레이드, 패치 같은 작업을 하기 위해 서비스를 잠시 멈추어야 할 경우 블록을 안전하게 보관하기 위해 설정하는 상태
NORMAL: 서비스 상태
DECOMMISSIONED: 서비스 중단 상태
DECOMMISSION_INPROGRESS: 서비스 중단 상태로 진행 중
IN_MAINTENANCE: 정비 상태
ENTERING_MAINTENANCE: 정비 상태로 진행 중
[2] 파일 읽기/쓰기
HDFS의 파일에 접근하는 가장 간단한 방법은 HDFS 명령행 인터페이스를 이용하는 것입니다.
또한 Java, C API를 제공하여 이를 구현해서 접근하면 됩니다.
ㄱ. 파일 읽기
네임노드에 파일이 보관된 블록 위치 요청
네임노드가 블록 위치 반환
각 데이터 노드에 파일 블록을 요청
노드의 블록이 깨져 있으면 네임노드에 이를 통지하고 다른 블록 확인
ㄴ. 파일 쓰기
네임노드에 파일 정보를 전송하고, 파일의 블록을 써야할 노드 목록 요청
네임노드가 파일을 저장할 목록 반환
데이터 노드에 파일 쓰기 요청
데이터 노드간 복제가 진행(1) 사용자
hdfs dfs -[서브명령어] or hadoop fs -[서브명령어]
자주 사용하는 서브 명령어
ls 안에 내용물 확인
rm -r 삭제
mkdir 디렉토리만들기
cat 내용물보기
mv 이동
cp 복사
du hdfs내부의 특정 file이나 디렉토리의 사이즈를 보여줌
du -s : 각각의 파일의 size의 sum값을 보여줌
-stat %b 용량을 바이트 단위로 본다
-stat %o 차지한 블록사이즈 보기(실제 용량과 블록사이즈는 다를 수 있음)
-stat %r 복사본이 몇개있나 확인
copyFromLocal 로컬에서 하둡으로 업로드
copyToLocal 하둡에서 로컬로
hdfs dfs -get /user/data1.txt ./ # 파일을 로컬에 복사
hdfs dfs -get -f /user/data1.txt ./ # 파일을 로컬에 복사, 동일한 파일이 있으면 덮어 씀.
hdfs dfs -put ./data1.txt /user/ # 로컬 파일을 hdfs에 복사
hdfs dfs -put -f ./data1.txt /user/ # 로컬 파일을 hdfs에 복사, 동일한 파일이 있으면 덮어 씀.
[1] Rack Awareness
블록을 저장할 때 2개의 블록은 같은 랙에, 나머지 하나는 다른랙에 저장하도록 구성
[2] HDFS 세이프모드
데이터의 저장 및 삭제가 불가능한 상태, 읽기 전용 상태
네임노드에 문제가 생겨서 정삭적인 동작을 할 수 없을 때 자동으로 세이프 모드로 전황
관리자가 설정할 수도 있고 복구할 수도 있음
[3] 커럽트 블록
HDFS는 하트비트를 통해 전달받은 리포트로 자동으로 복구하지만 모든 복제 블록에 문제가 생겨 복구하지 못하게되면 커럽트 상태가 됨, 파일 복구 불가
hadoop fsck 명령으로 확인 가능
[4] 휴지통
HDFS는 삭제 시 바로 영구적으로 삭제하지 않고 휴지통 기능을 이용할 수 있음
[5] 이용량 제한 설정
특정 디렉토리의 용량 제한을 설정할 수 있음
[6] 밸런스
서로 다른 사양의 컴퓨터로 데이터 노드들을 구성하면
한 쪽에는 용량이 남고 한 쪽에는 용량이 부족한 일이 발생할 수 있음
이 때 밸런스를 조절해서 사용パスを先に設定する必要があります@@
PATH=$PATH:/opt/hadoop-3.2.2/bin
次にhdfs dfs,mkdir ls rmを加える
hdfs dfs -mkdir/dir
hdfs dfs -ls/
@@ls/スペース/im
HDfs dfs-put「保存するファイル」/「保存するパス」/
HDfs dfs-ls/dir保存確認
ウォーカーで
/data/hdfs/datanodeまたは
cd/tmp/hadoop-hdfs/dfs/data/current/を使用して、格納されたデータを表示
root@worker1:/tmp/hadoop-hdfs/dfs/data/current# ls
これでファイルが分散して表示されます
hdfs dfs -ls/dir2
「私の奮闘」ip:9870にアクセスするHaduのWebサイトでUtilitiesをクリックします.
ディレクトリが何なのかは見えますが、xをよく使います
7.マップのタイリング
Googleが発表したアルゴリズム
2つのタスクに分けられます:大マッピングタスクにリダイレクト
マッピング:成果物の集約
データをインポートしてキー値を合わせる
げんすい
バンドルされたデータを必要なキーと値に再結合します.
1)勤務先
Hadu v 1の作業単位はJob,Hadu v 2の作業単位はアプリケーション(アプリケーション)である.
YARNアーキテクチャを導入すると、名前は変更されましたが、管理方法は同じです.하둡 잡이 생성되면 아이디가 job_xxx_xxx 로 생성됩니다.
이 아이디로 잡의 상태, 로그를 확인할 수 있습니다. YARN에서는 application_xxx_xxx 로 확인할 수 있습니다.
접두어는 다르지만 같은 작업입니다.
잡에서 생성되는 맵태스크와 리듀스태스크는 아이디가 attempt_xxx_xxx_m_000000_0으로 생성됩니다.
맵태스크는 중간아이디가 m으로 생성되고, 리듀스 태스크는 r로 생성됩니다.
2)処理段階입력
데이터를 입력하는 단계
텍스트, csv, gzip 형태의 데이터를 읽어서 맵으로 전달
@@ 중요
맵(Map)
입력을 분할하여 키별로 데이터를 처리
컴바이너(Combiner)
네트워크를 타고 넘어가는 데이터를 줄이기 위하여 맵의 결과를 정리
로컬 리듀서라고도 함
컴바이너는 작업의 설정에 따라 없을 수도 있음
파티셔너(Partitoner)
맵의 출력 결과 키 값을 해쉬 처리하여 어떤 리듀서로 넘길지를 결정
셔플(Shuffle)
각 리듀서로 데이터 이동
정렬(Sort)
리듀서로 전달된 데이터를 키 값 기준으로 정렬
@@ 정렬과 셔플은 둘 중 하나만 있어도 됨
@@ 중요
리듀서(Reduce)
리듀서로 데이터를 처리하고 결과를 저장
출력
리듀서의 결과를 정의된 형태로 저장
3) YARN하둡1에서는 잡트래커가 애플리케이션의 라이프 사이클 관리와 클러스터 리소스 관리를 모두 담당하여 병목 현상이 발생하였습니다.
잡트래커 한대가 클러스터의 모든 노드를 관리해야 하고, 모든 애플리케이션의 관리 하였기 때문에
잡트래커에 많은 메모리를 할당 해야 했고, 최대 4000대의 노드까지 관리 할 수 있었습니다.
잡트래커는 슬롯 단위로 리소스를 관리하여 시스템의 전체 자원을 효율적으로 사용할 수 없었습니다.
슬롯 단위 리소스 관리는 클러스터의 메모리, CPU 자원을 분할하여 슬롯단위로 구분합니다.
예를 들면 100GB의 메모리를 가지는 클러스터를 1G로 구분하여 100개의 슬롯을 만들고, 60개의 맵 슬롯, 40개의 리듀서 슬롯으로 구분합니다.
슬롯은 각각의 역활에 맞게 동작할 수 있습니다.
따라서 맵 슬롯이 동작하는 동안 리듀서 슬롯은 대기하게 됩니다.
맵 슬롯에 더 많은 일을 하게 되더라도 리듀서 슬롯은 대기하게 됩니다.
잡 트래커의 애플리케이션은 맵리듀스 작업만 처리할 수 있어서 유연성이 부족하였습니다.
맵리듀스 API를 구현한 작업만 처리할 수 있었기 때문에 SQL 기반 작업의 처리나, 인메모리 기반의 작업의 처리에 어려움이 있었습니다.
이런 단점을 극복하기 위하여 YARN 아키텍처가 도입되었습니다.
(1) YARN 구성
YARN은 잡트래커의 기능을 분리하여 자원 관리는 리소스 매니저와 노드매니저가 담당
애플리케이션 라이프 사이클 관리 기능은 애플리케이션 마스터와 컨테이너가 담당하도록 하였습니다.
(2) YARN App
YARN에서는 맵리듀스로 구현된 프로그램 외에도 다양한 애플리케이션을 실행할 수 있습니다.
리듀스, 피그, 스톰, 스파크 등 하둡 에코시스템의 다양한 데이터 처리 기술을 이용할 수 있습니다.
4)マップのリフレッシュ例텍스트 파일을 하둡에 보내놓기
ex) file1이라는 파일안에 아무거나 적어 놓고 하둡안에 dir2안에 보내기
hdfs dfs -put file1 /dir2
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount [HDFS에 있는 대본 파일] /result
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount /dir2/file1 /result
dir2/file1의 wordcount를 한뒤 /result에 저장한다.
地図と平和舗装が一番下のように表示されると成功します
part-r-0000にデータを含める
catで確認すると、写真のように1文字3回使っていました
hadoop fs-get/result/part-r-0000を使用してローカルインポートを行います.
ローカルで-lsコマンドで検証可能
@Wordcountエラー解決方法
1)民秀の優しさ:メモリ不足
yarn-site.xml<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.resourcemanager.hostname</name>
<value>master</value>
</property>
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>1024</value> ----- 이부분의 메모리를 늘려준다.
</property>
<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>1</value>
</property>
<property>
<name>yarn.nodemanager.env-whitelist</name>
<value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
</property>
</configuration>
修正しましたstop all.shそして再開
2)PATH設定エラー
パスが解放されたか、設定が変更されました.
PATH=$PATH:/opt/hadoop-3.2.2/bin
3) hadoop java.net.connectexception:接続が拒否されました
stop all.shそして再開
4)Jaeryの場合、Hadoop:ResourceManagerへの接続に失敗しました
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:06 INFO client.RMProxy: Connecting to ResourceManager at/0.0.0.0:8032
13/12/14 20:12:07 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 0 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:08 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 1 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
13/12/14 20:12:09 INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:8032. Already tried 2 time(s); retry policy is RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1 SECONDS)
hadoop jar hadoop-mapreduce-examples-2.2.0.jar wordcount someFile.txt/out
このコマンドの後にjpsチェックを使用すると、ResourceManagerは消えます.
解決策:独自のメモリ容量を増やすことでこの問題を解決
5)Pythonコードで作成してみる
(1) mapper.py
#!/usr/bin/env python
import sys
for line in sys.stdin:
sys.stdin-複数行入力を受信します.
words = line.strip().split()
行間.strip()によるスペースの削除
行間.split()でスペースを基準に区切ります.
最終的にはスペースで区切られるので、単語単位で
for word in words:
print('{}\t{}'.format(word, 1))
単語と1の形式で印刷
(2) reducer.py
#!/usr/bin/env python
import sys
def print_output(word, count):
print('{}\t{}'.format(word, count))
word, count = None, 0
for line in sys.stdin:
fields = line.strip().split('\t')
split(t)-タブ間隔を基準に分割されます.タブがマッピングされている可能性があります.
if fields[0] != word:
if word is not None:
print_output(word, count)
word, count = fields[0], 0
count += 1
print_output(word, count)
Reference
この問題について(7-5下黒), 我々は、より多くの情報をここで見つけました
https://velog.io/@kst5137/7-5-하둡
テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol
하둡 잡이 생성되면 아이디가 job_xxx_xxx 로 생성됩니다.
이 아이디로 잡의 상태, 로그를 확인할 수 있습니다. YARN에서는 application_xxx_xxx 로 확인할 수 있습니다.
접두어는 다르지만 같은 작업입니다.
잡에서 생성되는 맵태스크와 리듀스태스크는 아이디가 attempt_xxx_xxx_m_000000_0으로 생성됩니다.
맵태스크는 중간아이디가 m으로 생성되고, 리듀스 태스크는 r로 생성됩니다.입력
데이터를 입력하는 단계
텍스트, csv, gzip 형태의 데이터를 읽어서 맵으로 전달
@@ 중요
맵(Map)
입력을 분할하여 키별로 데이터를 처리
컴바이너(Combiner)
네트워크를 타고 넘어가는 데이터를 줄이기 위하여 맵의 결과를 정리
로컬 리듀서라고도 함
컴바이너는 작업의 설정에 따라 없을 수도 있음
파티셔너(Partitoner)
맵의 출력 결과 키 값을 해쉬 처리하여 어떤 리듀서로 넘길지를 결정
셔플(Shuffle)
각 리듀서로 데이터 이동
정렬(Sort)
리듀서로 전달된 데이터를 키 값 기준으로 정렬
@@ 정렬과 셔플은 둘 중 하나만 있어도 됨
@@ 중요
리듀서(Reduce)
리듀서로 데이터를 처리하고 결과를 저장
출력
리듀서의 결과를 정의된 형태로 저장하둡1에서는 잡트래커가 애플리케이션의 라이프 사이클 관리와 클러스터 리소스 관리를 모두 담당하여 병목 현상이 발생하였습니다.
잡트래커 한대가 클러스터의 모든 노드를 관리해야 하고, 모든 애플리케이션의 관리 하였기 때문에
잡트래커에 많은 메모리를 할당 해야 했고, 최대 4000대의 노드까지 관리 할 수 있었습니다.
잡트래커는 슬롯 단위로 리소스를 관리하여 시스템의 전체 자원을 효율적으로 사용할 수 없었습니다.
슬롯 단위 리소스 관리는 클러스터의 메모리, CPU 자원을 분할하여 슬롯단위로 구분합니다.
예를 들면 100GB의 메모리를 가지는 클러스터를 1G로 구분하여 100개의 슬롯을 만들고, 60개의 맵 슬롯, 40개의 리듀서 슬롯으로 구분합니다.
슬롯은 각각의 역활에 맞게 동작할 수 있습니다.
따라서 맵 슬롯이 동작하는 동안 리듀서 슬롯은 대기하게 됩니다.
맵 슬롯에 더 많은 일을 하게 되더라도 리듀서 슬롯은 대기하게 됩니다.
잡 트래커의 애플리케이션은 맵리듀스 작업만 처리할 수 있어서 유연성이 부족하였습니다.
맵리듀스 API를 구현한 작업만 처리할 수 있었기 때문에 SQL 기반 작업의 처리나, 인메모리 기반의 작업의 처리에 어려움이 있었습니다.
이런 단점을 극복하기 위하여 YARN 아키텍처가 도입되었습니다.
(1) YARN 구성
YARN은 잡트래커의 기능을 분리하여 자원 관리는 리소스 매니저와 노드매니저가 담당
애플리케이션 라이프 사이클 관리 기능은 애플리케이션 마스터와 컨테이너가 담당하도록 하였습니다.
(2) YARN App
YARN에서는 맵리듀스로 구현된 프로그램 외에도 다양한 애플리케이션을 실행할 수 있습니다.
리듀스, 피그, 스톰, 스파크 등 하둡 에코시스템의 다양한 데이터 처리 기술을 이용할 수 있습니다.텍스트 파일을 하둡에 보내놓기
ex) file1이라는 파일안에 아무거나 적어 놓고 하둡안에 dir2안에 보내기
hdfs dfs -put file1 /dir2
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount [HDFS에 있는 대본 파일] /result
hadoop jar /opt/hadoop-3.2.2/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.2.2.jar wordcount /dir2/file1 /result
dir2/file1의 wordcount를 한뒤 /result에 저장한다.<configuration>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
<property>
<name>yarn.resourcemanager.hostname</name>
<value>master</value>
</property>
<property>
<name>yarn.nodemanager.resource.memory-mb</name>
<value>1024</value> ----- 이부분의 메모리를 늘려준다.
</property>
<property>
<name>yarn.nodemanager.resource.cpu-vcores</name>
<value>1</value>
</property>
<property>
<name>yarn.nodemanager.env-whitelist</name>
<value>JAVA_HOME,HADOOP_COMMON_HOME,HADOOP_HDFS_HOME,HADOOP_CONF_DIR,CLASSPATH_PREPEND_DISTCACHE,HADOOP_YARN_HOME,HADOOP_MAPRED_HOME</value>
</property>
</configuration>Reference
この問題について(7-5下黒), 我々は、より多くの情報をここで見つけました https://velog.io/@kst5137/7-5-하둡テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol