행복한디벨로퍼

오늘은 파티셔닝에 대해서 포스팅 해보도록 하겠습니다. 실제로 파티셔닝으로 테이블을 설계해 보지 않아서 대략적인 의미만 알고 있었기에 한 번 정리할겸 책에서 학습한 내용을 정리해 봅니다. 해당 내용은 '관계형 데이터베이스 실전 입문'을 참고하였습니다. 

파티셔닝(Partitioning)이란?

파티셔닝에는 일반적으로 수평 파티셔닝(행으로 파티션을 나누는 방식)과 수직 파티셔닝(컬럼별로 파티셔닝을 나누는 방법, 특정 컬럼만을 고속 스캔할 때 유용) 두 가지 방법이 있다. 보통 일반적으로 수평 파티셔닝(행으로 파티션을 나누는) 방식을 대부분 사용하고 해당 포스팅에서도 수평 파티셔닝에 대해서만 정리하도록 하겠습니다.

인덱스는 임의의 키 값에 따라서 행 데이터의 위치를 식별하는데 사용하는 기능인 반면 파티셔닝은 테이블을 여러 개의 파티션으로 분할하고 키의 값에 따라 어떤 파티션에 속하는 행인지 배분하는 역할을 합니다. 

파티션은 각각 같은 구조(schema)를 가진 테이블이며 인덱스도 파티션마다 존재합니다.

출처 : 관계형 데이터베이스 실전 입문

위의 그림에서는 세 개의 파티션이 정의되어 있고 날짜에 따라 저장될 파티션이 나뉘게 됩니다. 어떤 파티션에 속할 것인지 정하는 키(파티션 키)를 검색 조건으로 지정하면 해당 파티션만 검색하면 되므로 검색 효율이 향상됩니다. 

위의 그림에서 검색조건이 '2014-04-01'이므로 p3 파티션에 원하는 행이 있다는 사실을 알 수 있습니다. 이처럼 검색 대상 파티션을 좁혀가는 동작을 파티션 프루닝(Partition Pruning)이라고 합니다. -> Pruning은 가지치기란 뜻입니다.

파티셔닝이 적합한 경우

파티셔닝을 사용할지의 가장 큰 판단 기준은 파티션 프루닝을 할 수 있는 검색 조건을 포함한 쿼리의 실행빈도입니다. 파티션 프루닝이 유효한 쿼리가 대부분일 때는 파티셔닝에 의한 처리 전체의 효율화가 기대됩니다. (일반적으로 날짜를 기준으로 최신 데이터를 항상 참조할 경우)

그러나 파티셔닝이 적합하다고 판단될 때도 인덱스를 붙이는 것만으로 충분할 때가 대부분입니다. 파티셔닝을 사용하는 이유는 단일 INSERT나 혹은 단일 Select, 범위 Select의 아주 빠른 처리가 필요할 경우 혹은 이력 데이터의 효율적인 관리가 필요한 경우 입니다. (불필요해진 데이터를 백업 & 삭제하는 작업이 상당히 고부하 작업이기 때문)

추가로 새로운 데이터를 차례로 추가하는 응용프로그램이며 과거의 데이터에 그다지 접근하지 않을 때는 레인지 파티셔닝을 수행해 엑세스되는 대상의 데이터 국소성을 최대한 활용할 수 있다. 파티셔닝을 사용하면 파티셔닝별로 인덱스가 작성되기 때문이다.  최신 데이터가 항상 검색 대상이라면 p3(그림)만 엑세스 대상이 될 것이고 엑세스의 국소성이 있다면 캐시의 효율이 매우 향상된다. 따라서 대부분 검색이 메모리만으로 처리되고 디스크 I/O를 줄여서 성능 향상을 실현 할 수 있다. 

파티셔닝의 단점

데이터를 입력받았을 경우 어디에 넣어야 하는지에 대한 연산 오버헤드가 발생 할 수 있고 인덱스만으로도 해결되는 부분 파티셔닝을 무분별하게 파티셔닝을 적용했을 때는 오히려 성능이 나빠질 수 있음에 유의.

결론

파티셔닝을 적용할 때는 적용하지 않았을 때와 비교해 확실한 성능의 이점이 생기는지 꼭 확인해보자!!!!

Heap Dump를 볼 일이 생겨서 Eclipse Memory Analyzer(MAT) 설치 후 실행을 하려고 하는데 다음과 같은 에러가 발생하였다.

'An error has occurred. See the log file~~~'

그래서 해당 위치에 가서 log파일을 열어 보니 다음과 같은 에러가 발생한 상태였다...

구글링 결과 zip압축파일을 푼 실행파일의 위치를 Applications폴더로 이동시켜주어 해결했다는 글을 발견!!!

이에 바로 Documents폴더에서 Applications폴더로 이동 후 실행하니 정상적으로 실행되었다~

혹시나 같은 문제가 발생하시는 분들은 폴더 이동시켜서 실행해보세요:)

인텔리제이에서 gradle프로젝트를 import해서 build하는데 자꾸 에러메세지 발생 및 자바코드를 프로젝트내에서 정상적으로 

소스코드로 인식하지 못하는 문제가 있었다.

일반적으로는 intellij의 gradle플러그인을 통해 기본적으로 프로젝트의 소스코드 path를 잡아주어야 하지만 소스코드도 잡지 못하고 

gradle dependency도 정상적으로 로드하지 못해 소스코드도 다 에러가 발생하는 상황.,,..

 이런식으로 소스코드를 인식하지 못한경우 주황색(일반텍스트)파일로 인식한다. 

정상적으로 인식을 했다면   이렇게 파란색으로 클래스파일로 인식을 하여야 정상.

문제의 원인은 intellij 2018.01 버전을 사용하고 있었는데 해당 버전과 gradle최신 버전 사용시 버그가 존재했던 것 같다.

intellij의 버전을 2018.3으로 업데이트 해주니 정상적으로 소스코드도 path도 잘찾아 인식하고 dependency도 잘불러오는 것을 확인했다.......

intellij 버전에 관련된 첫 삽질이라....기록 남겨본다.

정상적으로 intellij에서 gradle프로젝트로 import했다면 gradle창에서 다음과 같이 'Source Sets, Tasks, Run configurations' 디렉토리를 확인할 수 있다.

업데이트 전에는 manager.ectr이외에 그 하위 디렉토리가 보이지 않았다.....

혹시나 intellij(인텔리제이) 사용시 gradle 프로젝트가 정상적으로 import되지 않는다면 inteelij 버전에 맞는 gradle의 버전을 사용하고 있는지 

intellij의 버전이 너무 낮지 않은지 확인해보길 바란다.

자바 프로젝트 내부에서 jdbc드라이버를 연결하는 도중 다음과 같은 에러가 발생하였다.

[ 소스코드 ] 

DriverManger.getConnection하는 과정에서 발생

final private static String url = "jdbc:mysql://10.111.eee.xxx:5555/db?characterEncoding=utf8";
final private static String usr = "vuser";
final private static String pwd = "pwd11111";

Class.forName("com.mysql.jdbc.Driver");
conn = DriverManager.getConnection(url, usr, pwd);
Statement stmt = conn.createStatement();

[ 문제해결 ] 

mysql-connector-java 버전 5.1.X 이후 버전부터 KST타임존을 인식하지 못하는 이슈가 있다고 한다.

따라서 url에 serverTimezone을 추가해준다!

"&serverTimezone=UTC"

String url = "jdbc:mysql://10.111.eee.xxx:5555/adflat?characterEncoding=utf8&serverTimezone=UTC";

이렇게 하면 손쉽게 해결할 수 있다~아니면 mysql-connector-java버전을 낮추거나~

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대 하둡 클러스터 기준) 하루 이상은 걸렸던 걸로 기억한다.

읽어 주셔서 감사합니다.

• 사람들은 셰익스피어가 대작만 집필했을 것이라고 착각하지만, 그가 쓴 작품은 200편에 육박하고 그중 인정받는 작품은 10편이 안 된다. 심지어 작품성이 떨어져 수준 미달이라고 평가 받는 작품도 있다.
• 피카소 작품은 1만 점이 훌쩍 넘어가지만, 소수의 작품만이 인정을 받았다. 에디슨 역시 손대는 것마다 대박 발명이 된 것이 아니다. 1,000개가 넘는 특허를 등록했지만 실용적인 특허는 몇 개 되지 않는다. 
• 일을 할 때 '양'적인 부분이 결국에는 '질'적인 부분으로 연결된다는 사실을 빨리 깨닫는 다면 자신의 실력이 문제가 아니라 시도가 부족했다는 사실을 깨닫고 가열찬 도전을 이어 나갈 수 있을 것이다.
• 어떤 부부가 행복한 부부가 될까요? 우선 개인이 불행한데 행복한 부부란 있을 수 없습니다. 그건 거짓말입니다. 개인이 꼭 행복해야 합니다. 그러면 어떤 사람이 행복합니까? 꿈을 이루는 사람이 행복한 사람입니다. 결과적으로 행복한 부부가 되려면 서로가 서로의 꿈을 이룰 수 있도록 가장 완벽한 조력자가 되어야 합니다. 그게 신랑과 신부가 결혼을 해서 꼭 해야 할 일입니다. 서로의 꿈을 이룰 수 있도록 도와주는 일입니다.
• 시작의 마무리에 마침표를 찍는 일은 펜을 잡는 일보다 어렵다. 마무리 하나 잘못하면 모든 일은 망치지만, 마무리 하나만 잘해도 망친 일도 다시 살릴 수 있다. 그만큼 마무리는 중요하고 또 어렵다. 일단 일을 시작하면 성공 여부와는 상관없이 끝까지 가 보는 마음가짐과 습관을 갖는 것이 중요하다. 그리고 이 말을 기억하라. "시작을 했다면 경험이 되지만, 마무리까지 잘했다면(심지어 실패했더라도) 경력이 된다."

• 소셜 미디어의 대중화가 사람들이 나만 힘들다고 생각하게끔 만드는 경향이 있다.

실제 많은 사회과학 실험 결과가 소셜 미디어에서 친구가 많으면 행복감이 떨어진다는 상관관계를 보여 준다.

사람들은 모두 행복한 순간만 자랑하고 힘든 것은 감춘다.

• 오해 

오 : 오지게

해 : 해롭다

• 니체 : 나를 죽이지 못한 고통은 나를 더 강하게 만들 뿐이다.

피할 수 없는 고통이라면 고통 그 이후를 떠올리려고 노력한다. 인생을 돌아보면 고통 후의 ‘성장’은 아픈 만큼 고귀했다.

그 경험은 더 튼튼한 ‘자아’가 되었다. 굴복하지 않은 고통은 ‘선물’이 되었다. 이 세상을 떠나기까지 고통은 언제든 찾아올 것이다.

그러니 고통에 호들갑 떨 필요가 없다. 이 녀석은 어차피 인생의 동반자이니까. 행복 연구의 대가 조지 베일런트는 이렇게 말했다.

“고통을 어떻게 바라보는가가 행복을 결정한다.”

• 디테일이 티가 나는 순간은 경쟁이 치열해지면서다. 상위 레벨로 가면 갈수록 디테일의 중요성은 점점 부각된다.

보통 일의 성과는 처음에는 노력한 만큼 올라간다. 하지만 어느 순간이 되면 성과의 포화 구간에 진입하게 된다. 노력을 해도 딱히 성과가 나지 않는다.

자세히 들여다보면 작은 정도라도 성과가 올라간다. 그 작은 성과가 디테일이다. 디테일은 아주 사소해 보이지만 엄청난 노력이 필요한 결과물이다.

대부분 일을 잘 못하는 사람은 디테일의 탄생 과정을 이해하지 못하고 그것이 왜 중요한지 알지 못한다. 디테일을 챙기는 것은 매우 피곤한 일이지만 관심을 가질수록 내공의 깊이가 확연히 달라진다는 점을 잊지 말자. 

• 어떤 직종에 종사하건 간에 세상은 더 빠르게 변할 것이다. 

• 일을 잘한다는 것은 새로운 상황에 빠르게 적응한다는 말이다. 

• 비교

비교를 통해 얻을 수 있는 긍정적인 부분은 사실 거의 없습니다. 그런데 우리는 계속 비교합니다. 우리가 만약 비교를 해야 한다면 그 대상은 단 하나입니다. 바로 어제의 나 자신입니다. 어제의 나 자신보다 내가 성장했는지, 어제의 우리 부부보다 부부로서 더 성숙했는지, 그렇게 끊임없이 비교한다면 그건 더 이상 비교가 아닙니다. 그건 반성이고 성찰입니다.

• 입사는 스펙으로 가능하지만, 퇴사는 오직 실력으로만 가능하다.
• 나는 독서할 때는 스마트폰을 비행기 모드로 해 두는 편이다. 

• 대한민국은 그 어떤 나라보다 고도의 압축 성장을 경험한 나라다.

• 메타 인지란 내가 뭘 알고 모르는지, 내가 하는 행위가 어떠한 결과를 낼지 아는 것을 말한다. 실제로 상위 1퍼센트 학습자와 잘나가는 비지니스맨은 일반인보다 메타 인지가 상대적으로 높은 것으로 나온다. 

• 창의적인 사람은 아이디어의 질이 높다기보다 양이 압도적으로 많다. 이는 도전도 많이 하고 실패도 많이 한다는 뜻이다. 이들은 실패에 지지 않는다. 
• 감사는  행복한 감정의 가장 세련된 표현일 것이다.

느낀점

뼈있는 아무말 대잔치를 읽으며 그동안 나의 행동방식과 사고방식에 대해 되돌아보게 되었다. 이 책을 읽는 시간 동안 나는 정말 많은 것을 생각하고 공감했고 내 꿈에 대해 구체적인 그림을 그려보는 시간을 가졌다. 2018년 남은 시간을 잘 마무리하고 오는 2019년에는 좀 더 구체적인 계획과 실행력으로 내 자신이 발전하는 좀 더 의미있는 시간을 가져야 겠다. '읽을 줄은 알지만 읽지 않는 것', '할 줄 알지만 하지 않는 것'과 같은 나태함에서 벗어나 더 능동적인 내가 되어보자.

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)라는 것을 인식하고 있으므로 나중에 다른 노드에 복제본이 생성되도록 조치하고 후속 블록을 정상적으로 처리합니다. 

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