행복한디벨로퍼

Hive external table을 생성하게 되면 테이블을 drop시키더라도 하둡에는 데이터가 남게 되는데요.

이런 이유로 같은 이름으로 테이블을 재생성했을 경우 기존의 데이터가 그대로 들어있는 것을 보실 수 있습니다.

그래서 hdfs명령으로 하둡데이터를 삭제하고 싶은데 권한 문제로 삭제되지 않습니다...

따라서 external 테이블은 drop시키기 전에 alter명령어로  테이블의 external속성을 변경해주고 drop시켜주어야 합니다.

먼저 desc formatted 테이블명 으로 데이터가 하둡어디에 저장되어있는지 확인합니다.

보시면 Location이 하둡에 저장된 데이터 경로입니다.

해당 Table Parameters를 보시면 EXTERNAL옵션이 TRUE로 되어 있는 것을 보실 수 있습니다.

이 상태에서는 아무리 테이블을 drop시켜도 데이터가 남아있게 됩니다.

따라서 alter table specific_pub_and_area set tblproperties('EXTERNAL'='FALSE'); 명령어로 옵션을 변경해주셔야 합니다.

이렇게 변경하고 desc formatted 테이블명 명령어로 보시면 EXTERNAL옵션이 FALSE로 변경된 걸 확인하실 수 있습니다.

이 상태에서 drop table {테이블명} 을 해주시게 되면 하둡에 있는 데이터들도 삭제되는 것을 확인 하실 수 있습니다.

2018년 개발자 라이프 회고 (데이터엔지니어)

앞으로 조금 귀찮고 힘들더라도 개발자로서 한 해를 마무리하는 글과 새해 목표에 대해서 남겨보려고 한다.

크게 전공관련 목표는 네 가지 정도로 세웠던 것 같다.

1. 블로그 꾸준히 운영하기

일년동안 총 56개의 기술포스팅을 진행했다. 목표치에는 부족했지만 꾸준히 쓰려고 노력했다. 예전 포스팅을 너무 잘작성하려는 욕심 때문인지 어느 순간부터 글쓰는데 대한 부담감을 느끼고 한동안 글을 쓰지 않았던 적이 있다. 그 이후로 네이버 블로그에서 티스토리로 넘어오면서는 너무 포스팅을 잘하려고?심도있게 잘 작성해야한다는 압박으로부터 벗어나 간단하게라도 포스팅을 하자라고 생각이 바뀌었다. 포스팅에 대한 부담감을 느끼지 않고 꾸준히 하는것이 중요하다고 생각했기 때문이다. 주로 실무에서 삽질한 경험, 새롭게 알게된 지식, 책 학습을 통한 내용을 포스팅했다. 내년에는 IT기술 및 개발자의 삶 전반에 대한 고찰과 생각들도 글로 써보고 싶다. 

일년동안 3만 명이 넘는 분들이 블로그에 방문해 주셨고 총 4만5천 페이지 뷰가 발생하였다. 아무래도 심도있는 포스팅이 많지 않고 다른 연관관계에 있는 글들이 많지 않아 방문자수에 비해 페이지수가 낮게 집계된 듯 하다. 앞으로는 연관 포스팅에는 링크도 걸고 포스팅의 질도 높여 세션시간과 방문자수 대비 페이지뷰가 더 늘어날 수 있도록 실행해 보아야겠다. 내가 다른 분들의 블로그들을 통해 도움을 받고 지식을 얻듯 다른 분들도 내 블로그를 통해 도움을 받을 수 있다면 좋겠다.

2. 토이프로젝트 운영하고 광고수익 창출하기

실제로 토이프로젝트를 운영해보고 싶다는 생각은 일을 시작하고 2년차쯤부터 계속해서 가지고 있었다. 그 생각이후 2년 후에 실행하게 된데 대해 반성해본다. 지금은 개발자로 일한지 5년차이다. 토이프로젝트로 무엇을 만들어볼까 하다가 2018년 초기 당시 열풍이 불었던 코인정보들을 한데 모아 보여주는 사이트를 운영해보면 재미있을 것 같다는 생각이 들었다. 그렇게 2018년 1월 중순 회사퇴근하고 새벽 2~3시까지 개발을 했고 약 2주 정도에 걸쳐 사이트를 완성하고 오픈하게 되었다. 최대한 페이지 정보를 가리지 않는선에서 광고도 달아보았다. 그렇게 구글 애드센스를 통해 벌어들인 수익은 약 700달러 정도 되었고 중간에 페이지에 배너광고를 달고 싶다는 요청에 30만원을 받고 게재를 해주었다. 

돈의 액수를 떠나 토이프로젝트를 통한 광고 수익이 발생했다는 것에 가장큰 기쁨을 느꼈다. 그리고 사이트를 운영하는 것은 생각보다 더 힘들다는 것과 홍보 및 마케팅 분야에 대한 중요성에 대해서도 느끼게 된 경험이였다. 2018년에는 또 다른 토이프로젝트를 진행해 볼 생각이다.

3. 개발자들을 위한 컨텐츠 제작

외국에는 개발자들을 위한 유머? 컨텐츠들이 많은 것 같은데 국내에서는 많이 보지 못한것 같아 운영해보고 싶다는 생각이 들었다. 그리고 나 자체가 좀 엉뚱한 생각을 많이하기도 하고 내가 괜찮다고 생각이드는 아이디어가 남들에게는 어떻게 반응할지에 대해 궁금하기도 하였다. 인스타 계정 @happydeveloper 을 새로 하나 만들고 현재 계속해서 운영중이다. 욕심 부리지 않고 내 머릿속에 있는 생각들을 조금씩 컨텐츠로 만들어나가도록 해야겠다.

4. Scala, Spark에 대한 심도 있는 학습

사실 제일 아쉬운 부분이 이부분이다ㅎㅎ생각만큼 스칼라공부를 심도 있게 하지 못했고 기존 운영하던 Spark프로젝트를 계속해서 유지보수하고 기능을 추가하였지만 애초 목표였던 java spark -> scala spark으로 프로젝트를 변경해보지 못했다. 일단 이 부분은 업무의 영역과도 관련있기 때문에 내 마음대로 진행하지 못한 점이 크지만 많이 아쉬움으로 남는다. 공부는 끝이 없다....내년에는 scala도 좋지만 원초적인 프로그래밍에 필요한 기본적인 지식들을 좀 더 심도있게 쌓는데 중점을 두고 싶다.

이렇게 2018년도 가고 내일이면 2019년의 시작이다. 2018년 개인적으로 굉장히 다사다난한 일들이 많이 발생했었다. 그럼에도 불구하고 이정도의 실행을 할 수 있었던 건 연초에 목표를 세우고 눈에 보이는 곳에 항상 붙여놓았던 부분이 크다고 생각한다. 2019년 목표도 정리해서 포스팅 할 수 있도록 해야겠다. 

'어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다.'

긴 글 읽어주셔서 감사합니다.

하둡 클러스터를 운영하다보면 데이터 노드마다 데이터 분포의 불균형 상태가 생길 수 있는데 이 때 실행시켜주어야 하는 작업이 '밸런서(balancer)'이다.

밸런서(balancer)에 대한 내용을 포스팅 해보겠다. 해당 내용은 '하둡 완벽 가이드(4판)'을 정리한 내용이다.

[ 하둡 밸런서 ] 

하둡 클러스터는 시간이 지남에 따라 데이터노드 사이의 블록의 분포는 불균형 상태가 될 수 있고 불균형 상태의 클러스터는 맵리듀스의 지역성(locality)에 영향을 받게 되므로 자주 사용되는 데이터노드에 큰 부하를 주게 된다. 따라서 불균형 상태가 되지 않도록 해야 한다.

밸런서란?

밸런서 프로그램은 블록을 재분배하기 위해 사용률이 높은 데이터노드의 블록을 사용률이 낮은 데이터노드로 옮기는 하둡 데몬이다. 블록 복제본을 다른 랙에 두어서 데이터 유실을 방지하는 블록 복제본 배치 정책은 그대로 고수한다. 밸런서는 클러스터가 균형 상태가 될 때까지 블록을 이동시킨다. 여기서 균형 상태란 각 데이터노드의 사용률(노드의 총 가용 공간과 사용된 공간의 비율)이 클러스터의 사용률(클러스터의 총 가용 공간과 사용된 공간의 비율)과 비교하여 지정된 임계치 비율 이내일 때를 의미한다. 

밸런서는 다음과 같이 실행할 수 있다.

-threshold 인자에는 클러스터의 균형 상태를 의미하는 임계치 비율을 지정한다. 이 플래그는 선택사항이며, 지정하지 않으면 임계치는 10%다. 클러스터에는 오직 하나의 밸런서만 실행될 수 있다. 

밸런서는 클러스터가 균형 상태가 될 때까지 수행된다. 더 이상 블록을 이동시킬 수 없거나 네임노드와 통신이 단절될 수 있기 때문에 표준 로그 디렉터리에 로그파일을 생성하고 재분배 작업이 순환될 때마다 기록을 남긴다. 아래는 작은 클러스터에서 아주 짧은 시간 동안 밸런서를 실행한 결과다.

밸런서는 클러스터에 부담을 주는가???

밸런서는 클러스터에 과도한 부하를 주지 않고 클러스터를 사용하는 다른 클라이언트에 방해가 되지 않기 위해 백그라운드로 실행되도록 설계되었다. 밸런서는 한 노드에서 다른 노드로 블록을 복제할 때 필요한 대역폭을 제한할 수 있다. 기본값은 1MB/s지만 hdfs-site.xml 파일의 dfs.datanode.balance.bandwidthPerSec 속성에 바이트 단위로 값을 지정하면 대역폭을 변경할 수 있다. (대역폭을 늘린 순 있겠지만 늘리게 되면 클러스터에 미치는 영향이 커질 수 있음을 주의하자.)

실제로 경험상 밸런서를 실행하면 생각보다 수행시간이 오래걸린다.(20대 하둡 클러스터 기준) 하루 이상은 걸렸던 걸로 기억한다.

읽어 주셔서 감사합니다.

HDFS 네임노드의 파일시스템 이미지와 에디트 로그에 대한 내용은 하둡을 운영하기 위해 기본적으로 알아야 할 내용이기에 정리해본다.

해당 내용은 '하둡 완벽 가이드(4판)'을 정리한 내용이다.

파일시스템 이미지와 에디트 로그

[ 네임노드의 파일시스템 메타데이터 관리 방법 ]

파일시스템의 클라이언트가 쓰기 동작(파일 생성이나 이동)을 하면 일단 에디트 로그에 해당 내역이 기록된다. 네임노드는 파일시스템의 메타데이터를 인메모리(in-memory, 파일과 메모리 양쪽에 데이터를 유지하는 방식)로 관리하는데, 에디트 로그를 먼저 변경한 후 메모리상의 메타데이터도 변경한다. 클라이언트의 읽기 요청에는 인메모리 데이터만 사용된다. 

[ 에디트 로그 ]

에디트 로그는 개념적으로 단일 개체지만 디스크에는 다수의 파일로 관리된다. 각 파일을 세그먼트라고 하며 접두사 edits와 트랜잭션 ID를 의미하는 접미사로 구성되어 있다. 한번에 하나의 파일만 쓰기를 위해 열린다. 네임노드는 쓰기 동작이 끝날 때마다 성공했다는 결과를 클라이언트에 알려주기 전에 에디트 로그를 플러시(flush)하여 동기화시킨다. 네임노드는 여러 개의 디렉터리에 에디트 로그를 기록할 수 있기 때문에 변경 내역을 모든 에디트 로그 복제본 파일에 플러시하고 동기화한 후에 성공했다는 것을 알려주어야 한다. 이는 어떠한 기계적 결함에도 데이터가 손실되지 않도록 하기 위함이다. 

[ fsimage 파일 ]

각각의 fsimage파일은 파일시스템 메타데이터의 완전하고 영속적인 체크포인트다(fsimage 파일의 접미사는 파일시스템 이미지의 마지막 트랜잭션을 나타낸다). 파일시스템에서 쓰기 동작이 있을 때마다 fsimage 파일을 변경하지는 않는데, fsimage 파일이 기가바이트 크기로 커지면 성능이 매우 느려지기 때문이다. fsimage 파일을 바로 갱신하지 않더라도 하둡의 장애복구능력이 저하되는 것은 아니다. 만약 네임노드에 장애가 발생하면 먼저 fsimage를 메모리에 로드하고 에디트 로그파일에서 특정 지점 이후에 발생한 변경 내역들을 메모리에 반영하여 파일시스템의 메타데이터를 최신의 상태로 복원할 수 있기 때문이다. 

각 fsimage 파일은 파일시스템에 존재하는 모든 디렉터리와 파일의 아이노드(inode)정보를 직렬화한 파일이다. 각 아이노드는 파일이나 디렉터리 메타데이터의 내부 구조를 나타내며 파일의 복제 수준, 변경 및 접근 시간, 접근 권한, 블록 크기, 파일을 구성하는 블록 집합과 같은 정보를 가지고 있다. 디렉터리에는 파일과 달리 변경 시간, 권한, 할당 크기와 같은 메타데이터 정보가 저장되어 있다.

블록이 실제 저장된 데이터노드에 대한 정보는 fsimage 파일에 기록되지 않는다. 대신 네임노드는 매핑 정보(어떤 블록이 어느 데이터노드에 저장되어 있는지)를 메모리에서 따로 관리한다. 네임노드는 클러스터에 데이터노드가 추가될 때마다 블록 목록에 대한 정보를 데이터노드에 요청하여 매핑 정보를 구성하며, 주기적으로 네임노듣의 블록 매핑 정보를 최신 상태로 갱신한다. 

읽어주셔서 감사합니다. 포스팅을 마치도록 하겠습니다:)

HDFS에서 데이터가 어떻게 쓰여지는지에 대한 프로세스에 대해서 정리하도록 하겠습니다.

해당 내용은 '하둡 완벽 가이드(4판)'을 정리한 내용입니다.

[ HDFS 파일 쓰기 상세 ]

1. 클라이언트는 DistributedFileSystem의 create()를 호출하여 파일을 생성합니다.

2. DistributedFileSystem은 파일시스템의 네임스페이스에 새로운 파일을 생성하기 위해 네임노드에 RPC 요청을 보냅니다. 이때 블록에 대한 정보는 보내지 않습니다. 네임노드는 요청한 파일과 동일한 파일이 이미 존재하는지, 클라이언트가 파일을 생성할 권한을 가지고 있는지 등 다양한 검사를 수행합니다. 검사를 통과하면 네임노드는 새로운 파일의 레코드를 만들고, 그렇지 않으면 파일 생성은 실패하고 클라이언트의 IOException이 발생합니다. DistributedFileSystem은 데이터를 쓸 수 있도록 클라이언트에 FSDataOutputStream을 반환하고 읽을 때와 마찬가지로 FSDataOutputStream은 데이터노드와 네임노드의 통신을 처리하는 DFSOutputStream으로 래핑됩니다.

3. 클라이언트가 데이터를 쓸 때 DFSOutputStream은 데이터를 패킷으로 분리하고, 데이터 큐라 불리는 내부 큐로 패킷을 보냅니다.  DataStreamer는 데이터 큐에 있는 패킷을 처리하고 먼저 네임노드에 복제본을 저장할 데이터노드의 목록을 요청합니다. 데이터노드 목록에 포함된 노드는 파이프라인을 형성하는데, 복제 수준이 3이면 세 개의 노드가 파이프라인에 속하게 됩니다.

4. Datastreamer는 파이프라인의 첫 번째 데이터노드로 패킷을 전송하고 첫 번째 데이터 노드는 각 패킷을 저장하고 파이프라인의 세 번째(마지막) 데이터노드로 전달합니다.

5. DFSOutputStream은 데이터노드의 승인 여부를 기다리는 ack큐라 불리는 내부 패킷 큐를 유지하고 ack큐에 있는 패킷은 파이프라인의 모든 데이터노드로부터 ack 응답을 받아야 제거됩니다. 

6. 데이터 쓰기를 완료할 때 클라이언트는 스트림에 close() 메서드를 호출합니다. 이 메서드는 데이터노드 파이프라인에 남아 있는 모든 패킷을 플러시(flush)하고 승인이 나기를 기다립니다.

7. 모든 패킷이 완전히 전송되면 네임노드에 '파일 완료' 신호를 보냅니다. 네임노드는 DataStreamer를 통해 블록 할당 요청을 받았기 때문에 파일의 블록이 어떻게 구성되어 있는지 이미 알고 있으며, 최소한의 블록 복제가 완료되기를 기다렸다가 최종적으로 성공 신호를 반환합니다. 

[ 데이터를 쓰는 도중 데이터노드 장애 발생시 ]

1. 파이프라인이 닫히고 ack큐에 있는 모든 패킷은 데이터 큐 앞쪽에 다시 추가됩니다.

2. 이렇게 하면 다운스트림(downstream)노드가 실패해도 패킷이 하나도 유실되지 않고 정상 데이터노드는 네임노드로 부터 새로운 ID를 다시 받습니다.

3. 장애가 발생한 데이터노드가 나중에 다시 복구되면 불완전한 블록은 삭제됩니다. 

4. 장애 데이터노드는 파이프라인에서 제거되고, 정상인 나머지 두 데이터노드로 새로운 파이프라인을 구성하고 블록의 남은 데이터는 파이프라인의 정상 데이터노드로 전송됩니다.

5. 네임노드는 해당 블록이 불완전 복제(under-replicated)라는 것을 인식하고 있으므로 나중에 다른 노드에 복제본이 생성되도록 조치하고 후속 블록을 정상적으로 처리합니다. 

감사합니다. 포스팅을 마치도록 하겠습니다:)

오늘은 하둡 서버 장비를 구성할 때 디스크 RAID를 사용하는 것은 어떤지에 대해 포스팅하도록 하겠습니다.

해당 내용은 '하둡 완벽 가이드(4판)'의 내용을 정리한 것입니다.

[ 하둡(Hadoop) 장비에 RAID를 사용하는 것은 어떨까? ] 

HDFS 클러스터는 데이터노드 저장소로 RAID(Redundant Array of Independent Disks)를 사용하더라도 얻을 수 있는 이익이 거의 없다(메타데이터의 손상을 막기 위해 네임노드의 디스크에 RAID를 사용하는 것은 권장한다). HDFS는 각 블록을 여러 대의 노드에 복제하는 기능을 제공하므로 RAID 장치가 지원하는 중복성(redundancy)은 필요하지 않다.

더욱이 성능 향상을 위해 흔히 사용하는 RAID 스트라이핑(RAID 0) 방식은 HDFS 블록을 모든 디스크에 라운드 로빈(round-robin, 순차 순환) 방식으로 배열하는 HDFS의 JBOD(Just a Bunch Of Disks) 방식보다 더 느리다는 것이 밝혀졌다. 'RAID 0'의  읽기와 쓰기 동작은 RAID 배열의 가장 느린 디스크 속도에 의해 제한받기 때문이다. 반면 JBOD는 각 디스크가 독립적으로 동작하므로 디스크 동작의 평균 속도는 가장 느린 디스크보다 빠르다. 실제 환경에서 디스크의 성능은 같은 기종이라도 종종 큰 편차를 보인다. 야후 클러스터에서 수행한 벤치마크에서 JBOD는 'RAID 0'보다 Gridmix에서는 10%, HDFS 쓰기에서는 30% 정도 빨랐다.

마지막으로, 만약 JBOD 환경에서 디스크 하나가 고장나면 HDFS는 고장난 디스크 없이도 계속 동작할 수 있지만, RAID는 하나의 디스크 고장이 전체 디스크 배열을 불능 상태로 만들 수 있다. 

----------------------------------------------------------------------------------------------------

하둡 장비에서 RAID를 굳이 사용할 필요가 없다고 생각했지만(하둡 내부에서 replication factor를 보통은 3으로 설정 유지하기 때문) RAID 스트라이핑 방식도 더 성능이 안좋다는 것을 인지하게 되었다. 네임노드 서버의 디스크에만 RAID를 구성하면 될 것 같다.

오늘 포스팅도 끝~!!!

오늘은 HDFS로부터 클라이언트가 어떤 프로세스로 데이터를 읽는지에 대해 정리해보겠습니다. 

해당 내용은 '하둡 완벽 가이드(4판)'에 대한 정리 내용입니다.

[ HDFS에서 파일 읽기 ]

1. 클라이언트는 HDFS가 DistributedFileSystem 인스턴스인 FileSystem객체의 open() 메서드를 호출하여 원하는 파일을 엽니다.

2. DistributedFileSystem은 파일의 첫 번째 블록 위치를 파악하기 위해 RPC(Remote Procedure Call)를 사용하여 네임노드를 호출합니다. 네임노드는 블록별로 해당 블록의 복제본을 가진 데이터노드의 주소를 반환하는데 이때 클러스터의 네트워크 위상에 따라 클라이언트와 가까운 순으로 데이터노드가 정렬됩니다. 또한 클라이언트 자체가 데이터노드(예를 들면 맵리듀스 태스크)고 해당 블록의 복제본을 가지고 있으면 클라이언트는 로컬 데이터노드에서 데이터를 읽습니다.

3. 클라이언트는 스트림을 읽기 위해 read() 메서드를 호출합니. 파일의 첫 번째 블록의 데이터노드 주소를 저장하고 있는 DFSInputStream은 가장 가까운(첫 번째) 데이터노드와 연결합니다.

4. 해당 스트림에 대해 read() 메서드를 반복적으로 호출하면 데이터노드에서 클라이언트로 모든 데이터가 전송됩니다.

5. 블록의 끝에 도달하면 DFSInputStream은 데이터노드의 연결을 닫고 다음 블록의 데이터노드를 찾습니다. 클라이언트 관점에서 이러한 과정은 투명하게 전개되며 클라이언트는 단지 연속적인 스트림을 읽는 것처럼 느낍니다. 클라이언트는 스트림을 통해 블록을 순서대로 하나씩 읽고 DFSInputStream은 블록마다 데이터노드와 새로운 연결을 맺습니다. 클라이언트는 다음 블록의 데이터노드 위치를 얻기 위해 네임노드를 호출합니다.

6. 모든 블록에 대한 읽기가 끝나면 클라이언트는 FSDataInputStream의 close() 메서드를 호출합니다.

[ HDFS에서 데이터를 읽다가 데이터노드와의 통신 장애가 발생하는 경우 ]

데이터를 읽는 중에 데이터노드와 통신 장애가 발생하면 DFSInputStream은 해당 블록을 저장하고 있는 다른 데이터노드와 연결을 시도합니다. 이후 블록에 대한 불필요한 재시도를 방지하기 위해 장애가 발생한 데이터노드를 기억해둡니다. DFSInputStream은 데이터노드로부터 전송된 데이터의 체크섬도 검증합니다. 블록이 손상되었으면 DFSInputStream은 다른 데이터노드에 있는 블록의 복제본을 읽으려고 시도합니다. 물론 손상된 블록에 대한 정보는 네임노드에 보고됩니다.

[ HDFS 파일 읽기 설계의 핵심 ]

클라이언트는 데이터를 얻기 위해 데이터노드에 직접적으로 접촉하고, 네임노드는 각 블록에 적합한 데이터노드를 안내해주는 역할을 합니다. 데이터 트래픽은 클러스터에 있는 모든 데이터노드에 고르게 분산되므로 HDFS는 동시에 실행되는 클라이언트의 수를 크게 늘릴 수 있습니다. 한편으로 네임노드는 효율적인 서비스를 위해 메타데이터를 메모리에 저장하고 단순히 블록의 위치 정보 요청만 처리하며, 데이터를 저장하거나 전송하는 역할은 맡지 않으므로 클라이언트가 많아져도 병목현상은 거의 발생하지 않습니다.

포스팅을 마치도록 하겠습니다. 감사합니다:)

오늘은 HDFS 고가용성에 대해서 포스팅 정리~!

해당 내용은 '하둡 완벽 가이드(4판)'에 대한 정리 내용입니다.

[ HDFS 고가용성 ]

데이터 손실을 방지하기 위해 네임노드 메타데이터를 다수의 파일시스템에 복제하는 방식과 보조 네임노드를 사용하여 체크포인트를 생성하는 방식을 조합해서 활용할 수 있다. 그러나 이러한 방법도 파일시스템의 고가용성을 궁극적으로 보장하지는 않는다. 네임노드는 여전히 단일 고장점(SPOF, Single Point Of Failure)이다. 네임노드에 장애가 발생하면 맵리듀스 잡을 포함하여 모든 클라이언트가 파일을 읽거나 쓰거나 조회할 수 없게 된다. 네임노드는 메타데이터와 파일 블록의 매핑 정보를 보관하는 유일한 저장소이기 때문이다. 

[ HDFS 네임노드가 장애났을 경우 새로운 네임노드로 재구동 과정 - HA 구성 아닌 경우 ]

네임노드의 장애를 복구하기 위해 관리자는 파일시스템 메타데이터 복제본을 가진 새로운 네임노드를 구동하고 모든 데이터노드와 클라이언트에 새로운 네임노드를 사용하도록 알려주면 된다. 

1. 새로운 네임노드는 네임스페이스 이미지를 메모리에 로드한다.

2.에디트 로그를 갱신한다.

3.전체 데이터노드에서 충분한 블록 리포트를 받아 안전 모드를 벗어 날 때까지 어떤 요청도 처리하지 못한다.

이러한 과정을 거치는데 많은 파일 블록과 대형 클러스터에서 새로운 네임노드 재구성 까지는 30분 이상 걸리는 경우도 있다. (즉, 이런 장애 복구에 걸리는 시간을 감안할 수 있다면 이것도 하나의 방법이 될 수 있다.) 사실 네임노드의 갑작스런 장애는 거의 발생하지는 않는다. 

[ HDFS 고가용성(HA, High availability) - 하둡 2.x 릴리즈부터 ]

위와 같이 재구성하는데 오래걸리는 문제를 해결하기 위해 하둡 2.x릴리즈부터 hdfs의 고가용성을 지원한다. 

고가용성은 활성대비(active-standby)상태로 설정된 한 쌍의 네임노드로 구현된다. 활성 네임노드(active namenode)에 장애가 발생하면 대기 네임노드(standby namenode)가 그 역할을 이어받아 큰 중단 없이 클라이언트 요청을 처리한다. 이러한 방식을 지원하기 위해 HDFS의 구조를 일부 변경했다.

• 네임노드는 에디트 로그를 공유하기 위해 고가용성 공유 스토리지를 반드시 사용해야 한다. 대기 네임노드가 활성화되면 먼저 기존 활성 네임노드의 상태를 동기화하기 위해 공유 에디트 로그를 읽고, 이어서 활성 네임노드에 새로 추가된 항목도 마저 읽는다.
• 데이터노드는 블록 리포트를 두 개의 네임노드에 보내야 한다. 블록 매핑 정보는 디스크가 아닌 네임노드의 메모리에 보관되기 때문이다.
• 클라이언트는 네임노드 장애를 사용자에게 투명한 방식으로 처리할 수 있도록 구성해야 한다.
• 대기 네임노드는 보조 네임노드의 역할을 포함하고 있으며, 활성 네임노드 네임스페이스의 체크포인트 작업을 주기적으로 수행한다.

고가용성 공유 스토리지를 위해 NFS 필러나 QJM(quorum journal manager) 중 하나를 선택할 수 있다. QJM은 HDFS 전용 구현체로, 고가용성 에디트 로그를 지원하기 위한 목적으로 설계되었고 HDFS의 권장 옵션이다. QJM은 저널 노ㅓ드 그룹에서 동작하며, 각 에디트 로그는 전체 저널 노드에 동시에 쓰여 진다.

활성 네임노드에 장애가 발생하면 대기 네임노드는 매우 빠르게(수십초 이내) 기존 네임노드를 대체할 수 있다. 활성과 대기 네임노드는 모두 최신 에디트 로그와 실시간으로 갱신되는 블록 매핑 정보를 메모리에 유지하고 있기 때문이다. 하지만 실제로 장애 복구 시간을 보면 1분 정도 걸리는데, 시스템이 활성 네임노드에 장애가 발생했다고 판단하는 것은 매우 신중해야 하기 때문이다.