HDFS 저장소에 데이터를 압축해서 저장하면 좋을까?

 

·       Version : HDFS

 

HDFS 클러스터에서 데이터를 저장할때, 압축을 해서 보관하는것이 좋을까? 그냥 저장하는 것이 좋을까? 결론부터 말하면 반은 맞고 반은 틀리다. , 압축의 특성을 이해하고 사용하면 좋지만, 그렇지 못할경우 오히려 HDFS 장점을 활용하지 못할 수도 있다.

 

맵리듀스가 처리할 데이터를 압축하는 방법을 고려할때, 압축 포맷이 분할을 지원하는지 여부를 이해하는것이 중요하다. 예를들어 HDFS 1GB 데이터 파일을 저장한다고 가정한다.  64MB 블록으로 처리할 경우 16개의 블록으로 나뉘어 HDFS 저장된다. 리듀스에서 파일을 입력 데이터로 사용할 경우 16개의 독립적으로 처리되는 입력 분할을 생성할 것이다.

 

 

 

그런데 압축 크기가 1GB 하나의 gzip 압축 파일이 있다고 가정한다. 기존처럼 HDFS 16개의 블록에 저장할 것이다. 그러나 블록에 대한 분할 생성은 gzip 스트림이 특정 위치에서 읽기를 지원하지 않기 때문에 동작을 하지 않을것이다.  , 맵태스크가 나머지 블록의 분할을 개별적으로 읽는것은 불가능하므로 gzip 포맷을 저장하기 위해 DEFLATE 사용하고, DEFLATE 데이터를 일련의 압축된 블록으로 저장한다. 리더가 다음 블록의 시작으로 이동하려면 스트림과 동기화되어 스트림의 특정 지점에 있을 있는 어떤 방법을 지원해야 하는데, DEPLATE 압축 방식은 블록의 시작점을 구분할 없기 때문에  gzip 분할을 지원하지 않는다. 그래서 맵리듀스는 gzip 분할을 지원하지 않는다는 것을 인식하고, 파일을 분할하려고 하지 않을것이다. 그러면 단일 지역으로 데이터가 편향되어 지역성 비용이 증가하게 된다. , 단일 맵이 16개의 HDFS 블록을 처리할 것이고, 블록은 대부분 맵의 로컬에 있지 않을 가능성이 크다. 소수의 맵과 함께 잡은 일반적인 잡보다 세분화 되지 않아 오랫동안 수행될 확률이 크다.

 

압축파일이 bzip2 어떨까? bzip2 파일은 블록 사이에서 동기화 표시가를 제공(파이의 48비트 근사치)하고 결과적으로 분할을 지원한다.

 

ZIP파일은 아카이브 포맷이기 때문에 다중 파일을 단일 ZIP 아카이브로 결합시킬 있다. 파일은 개별적으로 압축되고 아카이브에 있는 모든 파일 위치는 ZIP 파일의 끝에서 중앙 디렉터리에 저장된다. 이러한 속성은 ZIP 파일이 파일 단위로 분할을 지원한다는 것을 의미한다. 그리고 분할은 ZIP 아카이브로부터 하나 이상의 파일들을 포함한다. (zip 지원 여부는 확인이 필요하다.)

 

LZO 파일의 경우 기존의 압축 포맷의 리더가 스트림과 동기화되는 방법을 제공하지 않기 때문에 분할이 불가능하다.

 

아래표는 하둡에서 지원하는 압축 분할 여부이다.

Compression format

Tool

Algorithm

File extention

Splittable

gzip

gzip

DEFLATE

.gz

No

bzip2

bizp2

bzip2

.bz2

Yes

LZO

lzop

LZO

.lzo

Yes if indexed

Snappy

N/A

Snappy

.snappy

No

 

외에도 시퀀스 파일을 사용하거나,  청크 단위로 파일을 나누어서(이때 청크는 HDFS 블록 하나 정도 크기로 생성한다.) 개별적으로 압축을 하여 사용하면 압축 파일 분할 여부와 관계없이 어느정도 효율성을 발휘할 있다.  

 

 

[참고자료]

·       Choosing a Data Compression Format : https://docs.cloudera.com/documentation/enterprise/5-3-x/topics/admin_data_compression_performance.html

·       Data Compression in Hadoop : http://comphadoop.weebly.com/

 

 

 

2020-06-22 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 하둡 파일 압축, 분산 처리, 분산 저장

HDFS 데이터 저장소에는 RAID구성이 필요할까

 

·       Version : HDFS

 

HDFS 클러스터에서 데이터노드 저장소 용도로 RAID(Redundant Array of Independent Disks) 사용하면 이득이 있을까?

결론부터 이야기하면 이득이 없다. HDFS 노드간에 복제하는 기능이 있어 RAID 제공하는 중복성(redundancy) 필요하지 않기 때문이다. 또한 성능 향상을 위해 흔히 사용하는 RAID 0 (Striping) 모든 디스크에 DHFS 블록을 연속적으로 배열하는 HDFS JBOD (Just a Bunch of Disks)방식보다 느리다는 것이 밝혀졌다. 이유는 RAID 0 읽기/쓰기 동작의 경우 RAID 배열에서 가장 느린 디스크의 속도에 의해 제한을 받기 때문이다. 반면 JBOD에서는 디스크 동작들이 독립적이며 이러한 동작들의 평균속도는 가장 느린 디스크보다 빠르다. 실제로 동일한 제조사의 동일 모델의 디스크여도 편차를 보이는 경우가 있다. 또한 JBOD 환경에서는 디스크 하나가 고장날 HDFS 고장난 디스크 없이도 계속해서 동작할 있지만  RAID 하나의 디스크 고장이 전체 디스크 배열을 불능 상태로 만들 있다. 뜻한 RAID 0에서 디스크 한개의 불량이 노드 하나를 통째로 불능 상태로 만들 있다는 뜻이다.

 

그렇다면  HDFS에서 RAID 정말 필요 없을까?  네임노드에는 RAID 1 (Mirroring)으로 구성하여 가용성을 높일 있다.

 

디스크 목록을 dfs.data.dir 매개변수에 전달하면 하둡은 사용 가능한 모든 디스크를 사용한다. 디스크가 오프라인 상태가 되면 사용가능 대상에서 제외한다. 그리고 제외된 디스크가 다시 사용가능한 상태가 되었는지 검사하지는 않는다.

 

Note : 하둡 시스템에 사용하는 메모리는 ECC 메모리를 사용하도록 한다. ECC 메모리가 아닌 경우 하듭 클러스터에서 체크섬 오류가 발생할 있다.

 

 

[참고자료]

 

 

2020-06-07 / Sungwook Kang / http://sungwookkang.com

 

 

Hadoop, Big Data, 하둡, 빅데이터, 데이터분석, HDFS, 하둡 파일 시스템, 하둡 RAID, 분산 처리, 분산 저장

'SW Engineering > Hadoop' 카테고리의 다른 글

Impala Connection refuse Error  (0) 2020.06.12
Hive 데이터 타입  (0) 2020.06.09
HDFS 데이터 저장소에는 RAID구성이 필요할까  (0) 2020.06.08
Hive에서 하둡(dfs)명령 실행  (0) 2020.05.19
ZooKeeper 옵저버와 CLI  (0) 2020.05.19
Hive에서 쉘 명령 실행  (0) 2020.05.18

+ Recent posts