하둡 완벽 가이드 3장 하둡 분산 파일시스템

3장 하둡 분산 파일시스템
HDFS 블록은 기본적으로 64MB로 디스크 블록에 비해 큰데 이는 탐색 시간을 최소화하기 위함이다.

네임 노드가 장애복구 능력을 갖추기 위해 갖는 두 가지 매커니즘
1. 파일시스템 메타데이터의 지속 상태를 보완해주는 파일을 백업한다.
2. secondary namenode를 운영한다. 주기적으로 네임스페이스 이미지를 에디트 로그와 병합하고, 주 네임노드가 실패했을 때 사용될 병합된 네임스페이스 이미지 복제본을 유지한다.

하둡2.x 릴리즈부터 한 쌍의 네임노드를 active-standby로 구성하여 HDFS high availability를 지원한다.
이를 통해 하나의 네임노드에 장애가 발생해도 중단 없이 다른 네임노드가 활성화된다.
데이터노드는 블럭에 대한 정보를 두 개의 네임노드에 모두 내보내야 한다.

hadoop fs -copyFromLocal path/file path/file
hadoop fs -mkdir prac

HTTP 기반으로 HDFS로 액세스하는 두 가지 방법
1. HDFS 데몬이 클라이언트 HTTP 요청을 직접적으로 처리
2. 범용 DFS API를 사용하여 클라이언트의 HDFS에 대한 요청을 proxy로 간접적으로 처리. 이 경우 더 엄격한 방화벽과 대역폭-제한 정책이 사용될 수 있다.

HDFS 구조는 클라이언트가 데이터를 얻기 위해 데이터노드에 직접 접근해야하므로 전반적으로 퍼져 있는 데이터노드들에게 골고루 로드가 분배되고 다수 클라이언트가 동시에 사용하기 용이하다.
네임노드는 단순히 블록 위치 정보 요청을 서비스하고 병목 현상이 생길 작업은 하지 않는다.

네임노드가 복제본을 저장할 데이터노드를 배치할 때 첫 번째 복제본은 클라이언트와 같은 노드에 배치하고, 두 번째와 세 번째는 다른 외부 랙에 서로 다른 노드에 복제된다.

HDFS는 FSDataOutputStream의 sync() 메소드를 통해 모든 버퍼가 네임노드에 동기화되도록 강제하는 메소드를 제공한다.
어느 정도 오버헤드가 있기 때문에 robustness와 throughput 사이에서 협상해야 한다.

Apache Flume: 대규모 스트리밍 데이터를 HDFS로 이동하는 시스템
Apache Sqoop: 관계형 데이터베이스와 같이 구조화된 데이터 저장소로부터 HDFS로 대량의 데이터를 임포트할 수 있도록 설계됨

distcp: 병렬도 다량의 데이터를 하둡 파일시스템으로부터 복사하기 위한 프로그램
hadoop distcp hdfs://namenode1/foo hdfs://namenode2/bar
맵리듀스 잡으로 구현되어 있고 클러스터 전반에 걸쳐 병렬로 수행되는 맵으로 복사 작업이 이루어진다.
맵은 노드 당 20개를 주는 것이 좋을 수 있다.
다른 버전에서 운영 중인 두 HDFS 클러스터 간에 distcp를 사용하려고 hdfs 프로토콜을 쓴다면 RPC 시스템이 서로 호환되지 않기 때문에 복사에 실패할 것이다.
이를 위해서는 HTTP 기반의 HFTP 파일 시스템을 사용한다.
hadoop distcp hftp://namenode1:50070/foo hdfs://namenode2/bar

하둡 아카이브(HAR)은 더 효율적으로 파일을 HDFS 블록으로 묶기 위한 파일 아카이빙 기능으로 네임노드의 메모리 사용량을 감소시킬 수 있다.
맵리듀스의 입력으로 사용될 수 있다.
확장자명 .har을 의무적으로 사용해야한다.
파일들을 아카이빙하면 두 개의 인덱스 파일과 하나의 part파일이 생기는데 part 파일에는 합쳐진 다수의 원본 파일의 내용이 있고 각 인덱스 파일은 part 파일이 포함된 파일의 오프셋, 길이 등을 나타낸다.


댓글

댓글 쓰기

이 블로그의 인기 게시물

논문 정리 - MapReduce: Simplified Data Processing on Large Clusters

Abstract 맵리듀스는 큰 데이터 셋을 다루는 프로그래밍 모델이다 . 사용자는 map 함수를 통해서 키 / 밸류 쌍을 이용하여 intermediate key/value pair 를 만들고 reduce 함수를 통해서 그 intermediate pair 들을 같은 key 별로 합쳐준다 . 많은 일들이 이런 모델을 통해 표현될 수 있다 . 이 모델은 분산 시스템이나 병렬 시스템에 대한 경험이 부족하더라도 분산 시스템의 자원을 쉽게 사용할 수 있게 해준다 . 1. introduction 데이터가 많아지면서 reasonable time 안에 작업을 끝내기 위해 수백 혹은 수천대의 기계에 분산되어야 했다 . 이 때 어떻게 연산을 병렬화하고 , 데이터를 분산하고 , 실패 작업을 어떻게 처리할지가 이슈가 되었다 . 이런 복잡한 문제들을 해결하기 위해 병렬화의 세세한 부분들은 숨기고 fault tolerance 하며 데이터를 분산시켜주고 로드 밸런싱을 해주는 라이브러리를 통해서 연산을 맵과 리듀스로 간단히 표현하도록 했다 . 2. Programming Model 사용자가 직접 만드는 맵 함수는 입력으로 key/value pairs 를 받아서 intermediate key/value pairs 를 만든다 . 그러면 intermediate key/value pairs 에 대해서 맵리듀스 라이브러리가 같은 key 별로 value 들을 묶어서 리듀스 함수로 보내준다 . 마찬가지로 사용자가 직접 만드는 리듀스 함수는 이 데이터를 받아서 key 별로 묶인 value 들을 합쳐서 표현한다 . 리듀스 함수에 전달되는 intermediate 데이터는 iterator 의 형태로 전달되기 때문에 메모리에 다 안 들어갈 정도로 큰 데이터도 처리할 수 있다 . 예를 들어서 , 어떤 문서에 있는 각 단어들이 몇 번 나왔는지 세는 프로그램을 생각해보자 . 그렇다면 맵 함수는 입력으로 < 문서 이름 , 문서 내용 > 의...
자세한 내용 보기

논문 정리 - The Google File System

The Google File System 1. Introduction 새로운 관점 component failure 은 예외가 아니라 일반적인 상황이다 . 그래서 constant monitoring, error detection, fault tolerance, automatic recovery 가 필요하다 . 파일의 크기가 커졌다 . I/O 작업이나 block 크기 등이 고려되어야 한다 . 원래 있는 데이터에 덮어쓰는 작업보다는 새로운 데이터를 추가한다 . 따라서 appending 이 성능 최적화에 중요해졌다 . 2. Design Overview 2.1 assumptions 시스템은 잘 고장나는 저렴한 장비들로 구성되어 있다 . 시스템은 큰 파일이 있다 . 작은 파일들도 있지만 optimizing 할 때는 고려하지 않는다 . 로드는 주로 큰 스트리밍 읽기와 작은 랜덤 읽기로 구성되어 있다 . 로드는 또한 파일에 데이터를 추가하는 많은 sequential write 가 있다 . 같은 파일에 여러 사용자가 동시에 데이터를 추가하는 경우도 잘 고려해야 한다 . 빠른 반응 속도 보다는 high sustained bandwidth 가 더 중요하다 . 대부분의 타겟 애플리케이션은 데이터 뭉텅이를 빠른 시간 내에 처리하는 것을 중요하게 여긴다 . 2.2 Interface 파일은 hierarchically , 디렉토리에 정렬돼있고 path name 으로 구분된다 . 또한 GFS 는 snapshot 과 record append 기능이 있다 . snapshot 은 파일이나 디렉토리 트리를 복사한다 . record append 는 다수 클라이언트가 데이터를 하나의 파일에 동시에 추가할 수 있도록 해준다 . 각 append 의 atomicity 를 보장하면서 . 2.3 Architecture 하나의 마스터와 여러개의 chunkserver 로 구성되어 있다 . 그리고 다수의...
자세한 내용 보기

kazoo: Using zookeeper api with python

``` pip3 install kazoo ``` https://kazoo.readthedocs.io/en/latest/basic_usage.html https://kazoo.readthedocs.io/en/latest/api/client.html ### 접속 ``` from kazoo.client import KazooClient zk = KazooClient(hosts='127.0.0.1:2181') zk.start() ``` 호스트에 접속할 때 default port는 2181이다. ### 상태 Listener zookeeper의 상태가 변하는 것을 알 수 있다. ``` from kazoo.client import KazooState def my_listener(state):     if state == KazooState.LOST:         # Register somewhere that the session was lost     elif state == KazooState.SUSPENDED:         # Handle being disconnected from Zookeeper     else:         # Handle being connected/reconnected to Zookeeper zk.add_listener(my_listener) ``` LOST CONNECTED SUSPENDED 의 state를 가질 수 있다. 가능한 상태 변화 - LOST -> CONNECTED - CONNECTED -> SUSPENDED - CONNECTED -> LOST - SUSPENDED -> LOST - SUSPENDED -> CONNECTED ### CRUD - `zk.create("/my/favorite/node", b"a value")` `create(path...
자세한 내용 보기