반응형


HDFS 설계 특성에 대해 정리해보도록 하겠습니다.


해당 포스팅은 '하둡 완벽 가이드' 내용을 정리한 것입니다. 공부하고 밑줄 쳐놓고 아까워 한 번 더 복습겸 포스팅해 봅니다.



HDFS 설계 특성

1. 매우 큰 파일  

'매우 큰'의 의미는 수백 메가바이트, 기가바이트 또는 테라바이트 크기의 파일을 의미한다. 최근에는 페타바이트 크기의 데이터를 저장하는 하둡 클러스터도 있다.'

기본적으로 하둡은 대용량 데이터를 처리하기 위해 설계되었다.


2. 스트리밍 방식의 데이터 접근

HDFS는 '가장 효율적인 데이터 처리 패턴은 한 번 쓰고 여러 번 읽는 것' 이라는 아이디어에서 출발했다. 데이터셋은 생성되거나 원본으로부터 복사된다. 그리고 시간이 흐르면서 다양한 분석을 수행할 수 있다. 분석이 전부는 아니지만 첫 번째 레코드를 읽는 데 걸리는 지연 시간보다 전체 데이터셋을 모두 읽을 때 걸리는 시간이 더 중요하다.


3. 범용 하드웨어

하둡은 고가의 신뢰도 높은 하드웨어만을 고집하지는 않는다. 하둡은 노드 장애가 발생할 확률이 높은 범용 하드웨어(여러 업체에서 제공하는 쉽게 구할 수 있는 하드웨어)로 구성된 대형 클러스터에서 문제없이 실행되도록 설계되었다. HDFS는 이러한 장애가 발생하더라도 사용자가 장애가 발생했다는 사실조차 모르게 작업을 수행하도록 설계되었다.


HDFS가 잘 맞지 않는 응용 분야

1. 빠른 데이터 응답 시간

데이터 접근에 수십 밀리초 수준의 빠른 응답 시간을 요구하는 애플리케이션은 HDFS와 맞지 않다. HDFS는 높은 데이터 처리량을 제공하기 위해 최적화되어 있고 이를 위해 응답 시간을 희생했다. 빠른 응답 시간을 원한다면 현재로서는 HBase가 하나의 대안이 될 수 있다.


2. 수많은 작은 파일

네임노드는 파일시스템의 메타데이터를 메모리에서 관리하기 때문에 저장할 수 있는 파일 수는 네임노드의 메모리 용량에 좌우된다. 경험상으로 파일, 디렉터리, 블록은 각각 150바이트 정도의 메모리가 필요하다. 따라서 파일 수가 백만 개고 각 파일의 블록이 하나면 적어도 300MB의 메모리가 필요하다. 물론 수백만 개의 파일은 괜찮겠지만 수십억 개의 파일은 하드웨어 용량을 넘어서게 된다.


3. 다중 라이터와 파일의 임의 수정

HDFS는 단일 라이터로 파일을 쓴다. 한 번 쓰고 끝나거나 파일의 끝에 덧붙이는 것은 가능하지만 파일에서 임의 위치에 있는 내용을 수정하는 것은 허용하지 않으며 다중 라이터도 지원하지 않는다. (하둡 3.0부터는 다중 라이터를 지원한다.


이상으로 포스팅을 마치도록 하겠습니다 :)

반응형

+ Recent posts