채현님의 블로그

Combine input records가 Map output records보다 많은 이유

xlos — Thu, 16 Feb 2012 01:08:07 +0900

팀 매니저님께서 결과를 보시며 의문을 표하시기에, 조사해봄.

일단 Hadoop Definite Guide 책에서 Combiner Function에 대해 찾아보면,

Many MapReduce jobs are limited by the bandwidth available on the cluster, so it pays to minimize the data transferred between map and reduce tasks. Hadoop allows the user to specify a combiner function to be run on the map output—the combiner function’s output forms the input to the reduce function.
from Hadoop Definite Guide 2nd edition, Ch2. MapReduce

이렇게 나와 있다. 대충 정리해보면, map output에 대해 combiner를 적용한 다음, 이 결과가 reduce의 input으로 쓰이며, combiner를 적용함으로써, map에서 reduce로 전송되는 데이터 양을 줄일 수 있다라고 설명하고 있다.

이렇게만 보면, map의 output이 combiner의 input으로 사용되는 것처럼 보이므로, map output records와 combine input records가 일치해야 하는 것처럼 보인다. 그러나 실제로는 combine input records가 더 큰 경우가 많다. (항상 많은지는 모르겠음) 왜 그럴까?

천신만고 끝에 찾은 힌트 하나

After the shuffle each reducer will have one input for each map. The reducer needs to merge these inputs in order to begin processing. It is not efficient to merge too many inputs simultaneously. Thus, if the number of inputs exceeds a certain value, the data will be merged and rewritten to disk before being given to the reducer. During this merge the combiner will be applied in an attempt to reduce the size of the input data.
from Oreilly

나는 지금까지 combiner는 mapper에서만 동작하는지 알았는데, 실제로는 reducer에서 data를 shuffle하는 단계 (정확히는 merge)에서도 combiner가 동작을 한다!

좀 더 자세히 설명을 하면,

from Hadoop Definite Guide 2nd edition, Ch6. How MapReduce Works

map의 output을 memory에 쓰다가, 할당된 memory buffer (기본은 100 MB)의 일정 비율 (기본은 80%)을 넘어서면, 현재 memory에 저장된 map의 output을 mapper node의 local file로 쓴다. (이 과정을 spill이라고 함)
실제 file로 쓰기 전에, 해당 data가 전송될 reducer 단위로 partitioning을 하고, 각각의 partition에 대해 백그라운드 thread가 in-memory sorting을 수행한 다음, sort의 output에 대해 combine 함수가 실행된다.
memory buffer가 spill threashold에 다다르면, 새로운 spill file이 생성되며, 실제 map task가 수행되는 동안, 이러한 spill file이 여러 개 생성된다. map task 가 끝나기 전에, 여러 개의 spill file들을 하나의 파일로 합치게 되는데, 이렇게 하나의 파일로 merge를 하는 단계에서도 combine 함수가 실행된다.
mapper의 결과가 reducer로 copy된 다음, reducer에서 여러 mapper에서 온 결과들을 sort하는 과정을 거치는데, 이 때 각각의 merge 단계에서도 combine 함수가 실행된다.

요약하면, mapper 뿐만이 아니라, reducer 단계에서도 combine 함수가 적용될 수 있으므로, Combine input records의 수가 Map output records의 수 보다 클 수도 있다.

※ 여기서 개발자들이 combiner를 사용할 때 유의해야 할 점은, combiner의 input으로 항상 map의 output이 들어온다 라고 가정을 하면 안 된다는 점이다. 위 설명에서도 알 수 있듯이, combiner의 output이 다시 combiner의 input으로 들어올 수 있다. 그러므로, combiner의 input은 map의 output format 뿐만 아니라, combiner의 output format도 적절히 처리할 수 있어야 한다.

KT 인터넷으로 변경

xlos — Thu, 09 Feb 2012 09:07:50 +0900

여차저차 해서 집 인터넷을 SK 브로드밴드에서 KT로 변경하였다. 변경하면서 몇 가지 느낀 점을 적어보면,

SKB는 내 기억에 설치 기사님께서 방문 약속 하루 전에 직접 전화를 주셨고, 시간 약속을 잡았었다. 그런데 KT는 직접 100 고객센터로 전화해서 시간 약속을 잡으려고 했지만, 2월 7일 오전에 설치 일정이 이미 잡혀 있고, 설치 기사님이 사전에 연락을 줄 거라고만 안내 해 줬다.
7일 오전에 설치 예정이면 6일에는 연락이 왔어야 하는데, 당일 오전 9시에 전화가 와서 지금 설치하러 온다고 말하는 기사님의 센스에 당황했다. ㅡ.ㅡ; 당연히 나는 이미 출근을 했기 때문에 8일 오전 9시로 다시 약속을 잡았다.
SKB는 설치 전 날 휴대폰 문자 메시지를 통해 xx일 오전 xx 시에 기사님 방문 예정이라고 알려줬던 걸로 기억하는데, KT는 그런 거 없다.
아무래도 직장인이다 보니, 오전 8시나 오후 6시 이후에 설치 받는 것을 선호한다. SKB는 기사님이 오후 7시까지 근무하기 때문에 오후 6시 반에 오셔서 인터넷 설치를 해 주셨었다. 그런데 KT는 무조건 오전 9시부터 시작하고 마지막 설치 타임은 5시라고.. 평일에 시간 안 맞으면 주말에 설치하란다. –_-;
물론 내가 KT 기사님더러 오전 9시부터 오후 7시까지 근무 해 달라는 요구는 하는 것은 아니다. 한 지역에 설치 기사님이 여러 분 계실 경우, 한 분은 오전 8시~ 오후 5시까지, 다른 분은 오전 10시 ~ 오후 6시까지 탄력적으로 근무를 시키는 방법도 있지 않을까? 설사 지역에 기사님이 한 분 밖에 없더라도, 설치 일정에 따라 오전 8시~ 오후 5시 근무, 오전 10시 ~ 오후 7시 근무처럼 그날 그날 설치 일정에 따라 탄력근무제를 도입하면 충분히 해결 가능할 듯 한데.. 하여간 KT..
하여간 오전 9시에 설치하러 온다기에, 계속 기다리고 있었는데, 9시 5분쯤 전화가 왔다. 지금 설치하러 갈 예정인데, 시간 되시냐고.. 언제쯤 도착하시냐고 물어봤더니, 10분 쯤 걸린단다. 그러고는 또 연락이 없길래, 9시 25분쯤 전화를 드렸더니, 아래에서 작업하고 계시단다. 그리고 실제 집에 방문한 시각은 9시 반쯤? “9시에 설치하러 온다”의 의미가 9시에 본인 회사에서 출발한다라는 의미일 줄이야.. 덕분에 난 지각.
안 그래도 이미지 안 좋은 KT가 더 싫어졌지만, KT에 좋은 얘기도 좀 해주면, SKB에 비해 해외 사이트 접속 시 확실한 속도 차이를 느낄 수 있다. 지메일 속도가 확연히 빨라진 것은 물론이고, SKB에서는 YouTube 동영상 시청 시 360p 화질에서도 끊길 때가 많았는데, KT는 720p 화질도 거의 끊김 없이 한 번에 볼 수 있다. (물론 3년 약정 시, SKB는 2.7만원, KT는 3.4만원 정도로, 가격도 7천원 정도 비싸다는 단점이 있기는 하지만)

총평 : KT가 전반적으로 SKB에 비해 서비스는 구리지만, 해외 사이트(gmail, YouTube 등) 접속 시 훨씬 쾌적하게 인터넷을 쓸 수 있음.

남이 짠 코드 고치기

xlos — Wed, 08 Feb 2012 21:25:10 +0900

요즘 회사에서 하고 있는 일이 남이 짠 코드를 읽고, 해석하고, 개선 사항이 있으면 찾아서 고치는 일이다. 그렇게 완전 발로 짠 코드는 아닌데, 그래도 이 업계 특성 상, 외주 개발자가 적당히 개발해 놓은 코드라.. 코드를 읽으면서 그렇게 기쁘지는 않다 T_T

다행이 코드 상단에는 이 클래스가 하는 역할이 무엇이다 정도는 주석이 달려 있는데, 문제는 코드 구석에 달려 있는 알 수 없는 부분들.. 예컨대, hashCode()를 override를 해 놨는데, 그냥 단순히 a << 4 + b 이런 식으로 hash code를 계산해 놓았다. 뭔가 일반적인 케이스가 아닌 듯 하여, 일단 코드를 바꿔 놓고 다시 한참을 보다보니, 다른 코드에서는 또 hash code를 a << 8 + b 이런 식으로 계산하고 있다. 뭔가 data에 특성과 hadoop cluster의 규모를 고려하여 최적화를 시켜 놓은 건가.. 해서 다시 아까 고친 코드를 원래대로 돌려 놓으면서도 알 수 없는 이 찝찝함이란.. 그냥 개발자가 생각 없이 박아 놓은 코드인지, 아니면 최적화를 위한 고민의 산물인지 알 수 없는 코드들. 그런데 그런 부분들에는 주석이 없다. 에휴 –_-

그리고 또 문제는 테스트 케이스가 전혀 없으므로, 코드를 고쳐도 제대로 고쳤는지 확인할 방법이 없다는 것. 그래서 일단 기존 코드에서 돌아가는 테스트 케이스를 먼저 만들고, 코드를 고친 다음, 아까 만든 테스트 케이스가 제대로 동작하는지 일일이 확인하면서 고쳐 나가고 있다. 정답 없는 문제에 내가 정답 케이스를 만들고, 그 정답 케이스에 맞춰서 문제를 조금씩 수정해 나가는 이 오묘한 감정이란.. ㅋㅋ

버스카드 실시간 환승의 비밀

xlos — Mon, 06 Feb 2012 23:03:40 +0900

지난 번 번개 회식에서 논쟁 아닌 논쟁이 되었던 주제가 바로 버스 카드였다. 당시 논쟁의 이슈는,

버스의 도착 예정 시각을 알 수 있는 것으로 보아, 각각의 버스는 중앙 서버와 통신을 하고 있을 것이다.
버스 카드는 “아마도” read-only 매체일 것이다. (write가 가능 하려면 전원이 필요한텐데, 버스카드나 신용 카드를 electric charge를 한 적이 없으므로)
버스에서 하차를 한 다음, 10초 안에 다른 버스를 탑승하더라도 단말기는 정상적으로 환승을 인식한다.
실시간 환승을 처리하기 위해서는, 버스카드 단말기도 중앙 서버와 통신을 하는 것일까?
설사 통신을 한다고 하더라도, 실시간 통신은 말이 안 된다. 3G bandwidth를 생각해보면..
그나저나 버스랑 중앙 서버는 뭘로 통신을 하는 거지? 3G? 2G? 별도 통신망?

그날 번개 회식에서 내가 막내(..) 였던 이유로 다음날까지 조사를 하기로 해서 열심히 구글링을 해 봤다. 그냥 버리기는 아까워서 아래와 같이 정리를 해 보았음.

Q) 버스는 어떻게 중앙 서버와 통신을 하나?
A) 자치단체 별로 다르다. 서울(에어미디 무선데이터망), 울산 (에어미디어 무선데이터망 –> SKT CDMA), 순천 (WCDMA), 대구 (CDMA) 등등 다양하다. 그 외에 Beacon 방식도 있다고 하니 참고. 그리고 비용은 버스 한 대당 1만원~1.5만원 정도라고.

Q) 버스의 교통카드 단말기는 언제 중앙 서버와 통신하나?
A) 버스에 장착된 터미널은 기본적으로 오프라인 결재형 터미널이다. 즉, 실시간으로 결재 이력을 서버로 보내지 않는다. 버스가 종점에 도착하면, 한 번에 거래된 데이터를 모아서 서버로 전송한다고 한다. 아래는 자세한 설명.

출처 : 전자지불시스템의 개념 정의, 시스템 구성 및 구성요소 설명

Q) 그렇다면 실시간 환승 처리는 대체 어떻게 하는 건가?
A) 교통IC카드는 단순히 단방향 통신 매체가 아닌, 소형컴퓨터 시스템으로, 카드의 잔액 및 환승 여부 등을 처리한다고 한다. (아,, 문화적 충격)

출처 : 전자지불시스템의 개념 정의, 시스템 구성 및 구성요소 설명

교통카드나 교통카드 기능이 담긴 신용카드는 단말기에 갖다 대기만 하면 버스나 지하철에 탈 수 있어 매우 편리하다. 교통비로 얼마가 나갔는지, 카드에 금액이 얼마나 남았는지, 환승했는지 여부 등 다양한 정보를 처리하는 저장하는 작업은 교통카드에 내장된 IC(Integrated Circuit, 집적회로)칩이 담당하고 있다. IC칩은 데이터를 저장할 뿐만 아니라 연산도 가능해 결제에 사용하거나 계좌 접근확인 등 다양한 기능을 수행할 수 있다. 교통카드 외에도 신용카드, 선불?직불카드 등에도 IC칩이 사용된다. 다만 신용카드로 결제하거나 ATM을 이용할 때 카드와 기계를 직접 접촉하는 것과 달리 교통카드는 단말기에 가까이 가져만 가도 동작한다. 이는 RFID 기술을 이용해 라디오 전파로 데이터를 주고받기 때문이다. 단말기에서 요금 정보를 교통카드로 보내면 IC칩이 남은 잔액을 파악하고 요구된 교통비를 뺀 후 지불이 완료됐다는 신호를 단말기에 전달한다.
”교통카드, 대기만 하면 인식하는 건…” ebuzz 김도형 기자

Q) 그럼 도대체 카드의 전원은 누가 공급하냐!!
A) 세상에.. 무선 충전이라니.. 아래 참고.

전파를 보내려면 전력이 필요하지만 교통카드는 따로 건전지가 달려있지 않다. 대신 카드 모서리에 전선이 여러 번 겹쳐 감긴 코일이 내장됐다. 교통카드 단말기는 일정한 주기로 세기가 변하는 자기장을 내보내고 있다. 여기에 교통카드를 가까이 대면 내부에 코일이 반응해 전파를 보내기 충분한 전력을 얻게 된다. 참고로 자기장 변화에 의해 전류가 흐르는 현상을 전자기 유도라 한다. 전자기 유도는 교통카드 뿐 아니라 무선 충전이나 인덕션레인지 등에도 활용되고 있다.
”교통카드, 대기만 하면 인식하는 건…” ebuzz 김도형 기자

덕분에 식견이 많이 넓어졌음.

[리뷰] 부러진 화살을 보고

xlos — Sun, 05 Feb 2012 14:43:07 +0900

예전부터 궁금했던 점이 HR 사람들은 누가 평가하는가? 하는 점이었다. 물론 나 같은 팀원들이야 팀 목표에 align되어, 팀장님들이 평가하는 경우가 대부분이지만, 팀장급 이상이 되면 목표 설정 자체가 그리 호락호락하지 않다. (정치적인 팀장들은 상대적으로 쉬운 목표를 설정하고, 어려운 목표로 포장한다) 결국 정량적으로 성과를 파악하기 어려운 대부분의 부서의 경우, 결국 누군가 정성적인 판단을 해야 할 수 밖에 없고, 이때 HR 부서가 힘을 발휘한다. 문제는 HR 부서의 목표는 누가 정해주는가 하는 점이다. (이건 뭐 고양이 목에 방울달기?)

부러진 화살이라는 영화를 보고, 비슷한 생각이 들었다. 사법부 (특히나 판사, 검사)들이 피해자, 혹은 피의자가 되었을 때, 누가 합리적인 판단을 내려줄 것인가? 사법고시 합격생들 대부분이 특정 대학에 편중되어 있고, 거기다 사법연수원이라는 곳에서 2년 동안 함께 고생을 하며, 알게모르게 그들만의 카르텔이 쌓인 상황에서, 과연 그들 사이에게 합리적인 법적 판단을 기대할 수 있을까?

피의자는 감히 사법부에 '테러'를 가했다고 의심되는 상황이고, 한 다리 건너면 아는 사이인 동료가 피해자인데다, 자신의 인사권을 쥐고 있는 윗사람들도 다들 한 마디씩 할텐데, 이런 상황에서 피의자와 피해자 사이에 공정한 재판을 기대한다? 누가봐도 무리인 상황아닌가?

영화는 영화일뿐, 픽션으로 받아들여야 하겠지만, 사법부 구성원이 포함되는 사건에 대해서는 적어도 현재와 같은 시스템에서 사법부가 단독으로 재판을 진행하고, 법적 판단을 내려서는 안된다는 생각을 가지게 해 준 것만으로도 이 영화는 충분히 역할을 했다고 본다.

대중교통수단으로 알아보는 시간의 가치

xlos — Wed, 18 Jan 2012 00:20:10 +0900

예전부터 시간은 금이라는 얘기를 많이 들었지만, 실제 한시간이 어느 정도의 가치를 가지는지에 대한 직관적인 감이 없어서 시간을 낭비하는 경우가 많았다. (정말? ㅎㅎ) 이번에 오랜만에 기차를 타면서 시간에 대한 가치에 대한 insight를 얻어, 간단히 정리해보았다.

평일 오후, 서울에서 부산으로 이동하는 교통수단 별 소요시간과 운임을 이용하여, 시간에 대한 가치를 분석해보자.

우선 가장 보편적인 교통 수단 중 하나인 고속버스는 서울에서 부산까지 약 4시간 30분이 걸리며, 운임은 32,800원이다.

만약 평일에 KTX를 탄다고 가정하면, 서울에서 부산까지 약 2시간 30분이 걸리며, 운임은 53,300원이다. 즉, 약 2시간을 단축시키기 위한 비용은 53,300 – 32,800 = 20,500원이며, 시간 당 비용은 대략 1만원 정도로 볼 수 있다.

여기서 재미있는 점은, 수원을 경유하는 KTX를 탈 경우인데, 이 때 소요시간은 약 3시간 30분으로 고속버스에 비해 1시간이 적고, 경유를 하지 않는 KTX에 비해 1시간이 많다. 그렇다면 운임은 얼마일까? 운임은 정확하게 43,200원으로, 고속버스에 비해 10,400원 많고, 경유하지 않는 KTX보다 10,100원이 적다.

슬슬 감이 잡히는가? 마지막으로 한 가지 더 찾아보면, 구포를 경유하는 KTX의 소요시간은 약 3시간 정도이며, 운임은 49,200원이다. 수원을 경유할 때 보다 시간은 30여분이 단축되는 대신, 운임은 6천원이 오르고, 경유하지 않을 때 보다는 시간이 30여 분 더 걸리고, 운임은 4,100원 싸진다.

그렇다면 비행기를 타고 하늘을 날아가는 경우는 어떨까? 비행기의 경우, 비행시간만 따지면 55분이고, 운임은 대한항공 평일 기준으로 62,400원이다. 김포공항의 접근성과 티켓팅 시간을 고려하여 비행시간에 30분 정도의 소요시간을 더해주면, 가장 빠른 KTX와의 시간 차이는 약 1시간이 되고, 운임 차이는 9,100원이 된다.

정리해보면, 우리나라에서 운송수단을 제공하는 회사들이 책정한 국민들의 시간의 가치는 약 1시간에 1만원 정도로, 남들보다 1시간 빨리 도착하고 싶다면, 1만원을 더 쓰면 된다.

시간을 낭비하고 있는가? 그렇다면, 당신은 지금 한 시간에 만원씩 버리는 셈이다. :) 열심히 살자!

평일을 기준으로, 서울에서 부산으로 이동하는 교통수단 별 소요시간 및 요금 정리

교통수단	소요시간	요금	시간차	요금차
누리로	5시간 20분	28,600
새마을	5시간 00분	42,600	20분	14,000
고속버스	4시간 30분	32,800	30분	-9,800
KTX수원경유	3시간 30분	43,200	1시간	10,400
KTX구포경유	3시간 00분	49,200	30분	6,000
KTX직통	2시간 30분	53,300	30분	4,100
비행기	1시간 30분	62,400	1시간	9,100

ps) KTX의 경우, 중간에 정차역에 몇 곳이냐에 따라 소요시간이 5~10분 정도 차이가 난다. 가장 빠른 열차의 경우, 서울에서 대전, 동대구만 거쳐서 부산에 도착하며, 소요시간은 2시간 25분이다. 느린 경우, 중간에 5~6곳 정도 정차하며, 소요시간이 2시간40분이 넘는 경우도 있다.


소요시간	2시간 25분	2시간 45분

ps2) 항공사의 경우, 출발시각에 따라 운임 할인이 적용되기도 하지만, KTX도 사전 예매에 따른 할인이 가능하므로, 일단 무시하고 표준 요금으로 계산하였다.

ps3) 가장 엽기적인 것은, 새마을호인데 고속버스에 비해 시간은 30분이 더 걸리는 주제에 요금은 9,800원 더 비싸다. 대체 무슨 배짱인가..

조직개편

xlos — Thu, 12 Jan 2012 23:30:28 +0900

#1. 회사에서 조직개편이 있었다. 우리 회사 (옮긴지 세 달이 넘었는데, 아직도 왜 이렇게 어색하다냐)는 조직 개편 이후에, 구성원들에게 팀을 이동할 수 있는 기회를 준다. 물론 아무나 막 할 수 있는 건 아니고, 특정 조건을 만족시키면, (한 분야에서 3년 이상 일했다던가) 조직 개편 후, 일정 기간 동안 다른 팀에 공식적으로 지원을 할 수 있다. 물론 경력채용 된 나는, 3년인가 5년인가 우리 팀에 묶여 있어야 하므로, 딴 나라 얘기이긴 하다.

#2. 팀 회의를 하고 있는데, 팀장님께 쪽지가 왔다. 팀명을 지금 정해서 보내야 한단다 –_-; 그래서 약 5분 간의 논의 끝에 팀명을 정했다. 그 후 10분 쯤 뒤에 다시 팀장님께 걸려온 전화 한 통.. 원장님께서 이름이 맘에 안 드셨는지, 다시 팀장님이랑 열심히 전화로 논의를.. 개인적으로 난 별로 였던, 뭔가 굉장히 긴, 무려 세 단어로 이루어진 팀명이 정해졌다. 그리고 다시 오늘 공식적으로 발표가 났는데, 세 단어 중에서 중간 단어가 빠진 이름이 최종 낙점. 뭔가 우리 회사 좀 즉흥적인 거 같애;;

#3. 이건 약간 다른 얘긴. 오늘 신문에 30대 대기업 초봉에 관한 기사가 나왔다. 내가 겪었던 N모사와 친구에게 들었던 K모사는 대략 맞는 것 같고, 여기 신입공채로 들어온 우리 팀 매니저 분께 물어보니 S사 초봉도 인센 포함하면 비슷한 거 같다고.. 그런데 또 다른 S사는 절대 저 연봉이 아닌데,, 하면서 출처를 확인해 보니,

12일 머니투데이가 국내 시총 상위 30대 기업들과 해당 기업의 최근 입사자 등을 상대로 지난해 1월 입사한 대졸 사무직 신입사원의 지난해 기본급과 상여금, 각종 수당, 연말 성과급을 모두 합친 세전 연봉을 조사한 결과, 이 같이 나타났다.

그냥 기자들 인맥 총동원해서 기사 썼나 보다 ㅡ.ㅡ;;

HDFS Federation

xlos — Thu, 12 Jan 2012 00:16:42 +0900

Hug - March - HDFS Federation

View more presentations from Yahoo! Developer Network

Hadoop World 2011에서 발표되었던 HDFS Federation 요약

video를 보고 이해한 거 + 대략적인 소스 분석을 토대로 한 거라 틀린 부분이 있을 수도 있음

한 마디로 요약하면? 하나의 cluster에서 여러 namespace (namenode)를 쓸 수 있도록 한 것! 왜 이런 걸 했는지, 어떻게 했는지, 그리고 앞으로는 어떻게 발전할 것인지에 대해 소개함.

현재 HDFS Architecture에 대한 요약 : 자세한 내용은 여기 참조
1. Namespace와 Block Storage의 조합
2. Namespace : directory, file, block으로 구성 / file 및 directory에 대한 create, delete, modify, list를 지원
3. Block Storage : Datanode membership 관리 / block에 대한 create, delete, modify, get 을 지원 / 복제 계수 관리
4. 현재는 cluster 전체에 하나의 Namespace Volume이 존재, namespace는 하나의 namenode에 올라감
  1. 전체 namespace는 namenode의 메모리에 올라가며, block file들은 datanode의 local file system에 저장됨
무엇이 문제인가?
1. Scalability : datanode만 추가하면, 용량은 쉽게 증가하지만, namespace자체는 그렇지 않음
  1. 메모리의 한계로, namespace의 file와 directory 개수에 제한이 있음
    1. 64 GB 메모리에 약 2억 5천 만개의 파일과 block들이 저장
  2. 여전히 매우 큰 클러스터라고 할 수 있지만.. (Facebook은 약 70 PB를 저장함)
2. Performance : namenode가 하나이므로, 당연히 throughput에 제약이 있음 (한 대가 아무리 좋아 봐야 몰리면.. 뭐..)
  1. 120,000 read ops / sec & 6,000 write ops / sec (write를 할 때는 file로 edit log를 떨궈야 하기 때문에 느림)
  2. 코드 최적화를 통해 20,000 write ops / sec 정도까지는 쉽게 올릴 수 있음
  3. 아무리 최적화를 하더라도, 한 대로 서비스를 하면 bottleneck이 생길 수 밖에 없음
3. Poor Isolation : 모든 사람/application이 하나의 namespace를 쓰는 문제
  1. 최적화가 덜된 실험적인 job과 상용 job이 하나의 namespace를 사용하는 것은 문제
  2. production cluster에서 하나의 테스트 job이 파일을 어마어마하게 생산하고 지우는 무식한 작업을 한다면, 다른 중요한 job들이 실행되는데도 영향을 끼침
4. Tight Coupling : 따지고 보면, Namespace와 Block 관리는 서로 다른 분리된 서비스들임. 그런데 엮여 있다 보니 scaling하기 복잡함.
  1. 현재는 모두 namenode 관련 코드로 묶여있음
  2. 두 가지를 분리하여, block 관리도 단순화하고, namespace도 단순화하자!
  3. 궁극적으로 Block Storage 서비스를 일반화 하자.
    1. 이 경우, namespace는 block storage를 사용하는 하나의 어플리케이션이 되는 것
    2. 그 외 HBase 등도 block storage 서비스를 사용할 수 있음
사실 scaling 보다는 isolation이 더 문제임
1. namenode에 64 GB 메모리만 꼽으면, 대부분의 cluster에서는 큰 문제가 안됨 (HDFS 특성 상 2억 개를 넘는 file을 저장할 일이 있을까?)
2. 하지만, 다른 종류의 application들에게 독립적인 namespace를 제공해주는 것은 cluster의 크기가 작더라도 필요함
HDFS Federation
1. 하나의 cluster에 여러 개의 독립된 namenode들과 namespace volume이 존재
2. Block Storage는 일반적인 storage service 처럼 사용됨
  1. 1423 번 block에 xxx~~라는 내용을 저장하고, 이 block을 세 개 정도 안전하게 복사해주세요!
  2. 가장 가까이 있는 서버에서 2698 번 block을 읽고 싶어요!
  3. 이런 느낌?
3. Block Pool
  1. 하나의 namespace는 하나의 block pool을 가짐
  2. 이전에는 datanode에게 1234 번 block에 저장해주세요~ 라고 요청했다면, 이제는 9876번 block pool (namespace 별로 unique하게 생성됨)에 1234번 block에 저장해주세요~ 라고 변경됨
    1. 즉, namenode와 datanode 사이에 block pool이라는 layer가 하나 더 생긴 것
  3. 기존의 block은 block id (long)로 구분되지만, block pool에서 사용되는 ExtendedBlock은 pool id (string)와 block id (long)로 구분됨
    1. pool id는 "BP-" + rand + "-"+ ip + "-" + System.currentTimeMillis(); 와 같이 생성되며 (NNStorage.java의 newBlockPoolID() 참조), 하나의 namespace가 고유의 block pool id를 가짐
  4. datanode들은 모든 namenode의 namespace에 소속되며, (몇 개의 datanode가 하나의 namenode에 종속되는 개념이 아님) 모든 namespace의 block들을 독립적으로 저장.
    1. 이전 : /dfs/data/current/blk_-291620265307745070 와 같이 저장
    2. 0.23이후 : /dfs/current/block_pool_id/current/blk_-291620265307745070 와 같이 저장 (수정필요)
좋은 점은?
1. 분산된 namespace : 여러 개의 namenode들로 분산됨
  1. 독립된 master (namenode)구조이므로 단순하고 robust함
  2. namenode code는 거의 고치지 않았으므로, 이전의 namenode 안정성을 그대로 유지
2. Block Pool이 하나의 일반적인 storage service로 제공됨
  1. 각각의 namespace volume은 독립적임 (하나의 namenode가 죽어도, 다른 namenode에는 영향이 없음)
  2. 새로운 innovation와 빠른 발전을 가져올 것임
    1. 예컨대, 다양한 garbarge collection scheme이 적용된 tmp storage 라던가
    2. 좀 더 효율적인 distributed cache 라던가
    3. small object storage 등등..
좀 더 상세한 사항
1. Namenode code는 거의 안 고치고, 대부분 datanode code와 config, tool code들이 수정됨
2. core 개발은 4개월 만에 끝남
3. namespace와 block management는 여전히 namenode에 남아 있음
  1. 미래에는 block management 부분은 namenode 밖으로 나갈 수도 있음
4. 현존하는 cluster 배포에도 큰 영향이 없도록, 예전 설정으로도 동작이 가능함
5. Cluster Web UI가 multi namespace를 지원할 수 있도록 수정됨
6. 각종 tool들이 수정됨
  1. datanode들이 여러 namespace에서 decommission이 가능하도록 변경
  2. balancer가 여러 namespace에서 동작하도록 변경
    1. datanode들의 저장용량 뿐만 아니라, block pool storage에서도 balancing 이 가능
7. federated cluster에서 namenode를 추가/삭제할 때, 전체 cluster 재시작 없이 가능
8. 하나의 설정 파일로 namenode와 datanode 모두에 적용
Namespace 관리
1. /data/test.txt 파일은 어느 namespace를 봐야 할까?
2. global namespace는 존재하지 않음
3. client에 mount table이 존재함
  1. e.g.) /data/ –> NS1
    /project/ –> NS2
    /home/ –> NS3
    위와 같은 mount table이 설정 파일로 존재
Next Step
1. namespace와 block management layer의 완전한 분리
2. 좀 더 나은 scalability를 위해 namespace에서 부분적인 내용 (e.g. 자주 access되는 file)만 memory에 올리고 나머지는 파일로 저장
3. 실제 data copy (datanode들 사이의 block copy)없이 하나의 namespace를 다른 namespace로 이동

좀 더 많은 사항이 궁금하신 분들을 위해.. 아래의 HDFS 상위 설계서 일독을 추천합니다.

https://issues.apache.org/jira/secure/attachment/12453067/high-level-design.pdf

요즘 만들고 있는 것

xlos — Mon, 09 Jan 2012 23:32:45 +0900

2012년 회사에서 나의 목표를 정하다가, 팀장님께 내가 하고 싶은 걸 말씀 드릴 기회가 있었다. 이런 저런 얘기를 하다가 내가 말한 item 중에 하나가 어찌어찌 변형되어서, 팀장님께서 평소에 필요로 하시던 tool을 만드는 것이 되어 버렸다.

의외로 공수가 별로 안들 것 같기도 하고, 마침 평소에 생각하고 있던 idea의 feasibilty도 볼 겸해서, 뚝딱뚝딱 prototyping 중이다. rough하게 말해서 php로 만든 hdfs explorer + filtering tool 정도가 되려나? (당근 hadoop에 기본으로 포함된 hdfs web viewer보다는 훨씬 더 편하고 이쁘다 ㅎ)

jquery랑 jquery ui, jqgrid까지 붙여놓으니 꽤 그럴듯한 툴이 되긴 했는데, 처음엔 간단했던 요구사항에 점점 추가사항이 붙고 있어서 낭패.. 적당한 선에서 끊고, 얼른 다른 것을 해야겠다. 흐흐

딱 30분만 자야지

xlos — Sun, 08 Jan 2012 17:35:00 +0900

나른한 일요일 오후. 간만에 주말임에도 불구하고 일찍 일어난 덕에, 오후 두 시가 되니 끝없이 졸리기 시작했다. 그런데 난 낮에 자 버리면 밤에 잠을 잘 못 자기 때문에.. 정확히 30분만 자고 일어날 계획을 세웠다.

그런데 고전적인 방법대로 알람을 30분 뒤에 맞춰놓고 자려니, 내가 정확히 지금 잠들 거라는 보장이 없다. 기껏 20분 뒤에 잠들었는데, 10분 뒤에 깨 버린다면?! 휴대폰을 던져버리고 싶을 거야 –_-a

정확히 잠들기 직전에 알람을 맞춰놓고 잔다면 그게 가장 이상적이겠지만, 그게 어디 맘처럼 쉽나.. 그래서 나온 절충안 :

스마트폰의 Tango 앱(영상통화 앱)을 통해 여친이랑 연결을 한다.
여친이 TV를 보면서 5분 간격으로 내가 자고 있나를 확인한다. (“오빠 자~?”) (“아니”)
내가 잠든 것이 확인 된 후 30분 뒤에 나를 깨운다.

덕분에 정확히 30분 잘 잤음 ^^v 스마트한 시대의 유용한 스마트폰 활용법이라고 자랑하고 싶지만, TV보면서 뒹굴거리는 여친이 있어야 가능한 방법이기에.. 나중에 시간이 나면 앱으로 만들어볼까 한다. ㅋㅋ