라이프로그


Hadoop이 뭐여? 08 Big Data

하둡(Hadoop)이 뭐여?

 http://blog.daum.net/openservice/92


글쓴이: 김선태 kistiman@gmail.com


작성 중...............................................................................................................


과학데이터를 관리하기 위한 시스템을 설계하고 개발하기 위해서 하둡 검토를 시작합니다.

분야별 데이터센터와 국가과학데이터센터의 역할을 중심으로 이슈사항을 검토할 예정입니다.


그럼 시작해 볼까요?


하둡은 2012,02,28 현재 

27 December, 2011: release 1.0.0 available 


하둡의 역사[3, pp.36~38]

- 텍스트 검색 라이브러리 아파치 루씬 창시자 '더그 커팅'에 의해 시작

- 오픈소스 웹 검색엔진 아파치 너치(Apache Nutch)에서 탄생 - 루씬 프로젝트 일부

- 너치는 2002년에 시작되었고, 실행 가능한 크롤러와 검색 시스템을 빠르게 출현 시킴

- 10억 페이지 색인을 위한 시스템 유지비용(하드웨어 매달 3만달러, 기타 약 50만 달러 비용 소요)

- 그러나 너치 아키텍처는 수십억 웹페이지로 확장될 수 없었으며, 때마침 구글에서 GFS라는 구글 분산 파일시스템 아키텍처 논문 공개로 아이디어가 생김

- GFS 같은 분산파일시스템은 웹 크롤과 색인처리 과정에서 생성되는 매우 큰 파일에 대한 스토리지 요구 사항을 해결할 수 있었음. 2004년에 NDSF(Nutch Distributed Filesystem)을 오픈소스로 구현 시작

- 2004년 구글에서 맴리듀스를 소개하는 논문 출판. 2005년 초기 너치 개발자들은 너치에 맴리듀스 구현 시작

- 너치 내부에 NDFS와 맵리듀스 구현은 검색 분야를 뛰어넘어 응용될 수 있었고, 2006년 2월에 NDFS와 맴리듀스는 하둡이라고 명명된 루씬의 독립 서브프로젝트를 구성하기 위하여 너치 밖으로 빠져나왔음

- 비슷한 시기에 더그 커팅은 야후에 합류.

- 2008년 2월. 야후는 그들의 검색 색인 제품이 10,000 코어 하둡 클러스터에서 생성되고 있다고 발표

- 2008년 2월. 아파티 최고 수준의 프로젝트로 등극


하둡의 배경[3]

- 1990년 부터 전형적인 드라이브는 1,370MB의 데이터를 저장할 수 있었고, 4.4MB/s 전송속도

- 20년 지난 지금. 1테라바이트의 드라이브가 일반화. 그러나 전송 속도는 약 100MB/s 수준에 머물러. 결국 디스크로부터 모든 데이터 읽는데 2시간 반이상이 소요 ㅠㅠ


- 파일을 한번 생성하면 Random Write 보다는 Append 가 대부분이며 파일 사이즈가 Giga 단위 이상으로 크다는 점입니다. 또한 대규모의 웹페이지 검색 및 인덱싱 작업을 위하여 엄청난 양의 웹 데이터를 가공하는데 필요한 분산, 병렬처리 작업이 필요합니다. 전통적인 슈퍼컴퓨팅 환경에서는 연산처리 능력향상을 위하여 클러스터가 설계된 반면, 이러한 인터넷용 데이터 가공은 데이터 처리 능력이 클러스터를최적하 합니다. 이러한 점을 보더라도 전통적인 분산/병렬 파일시스템 보다는 인터넷 S/W의 워크로드에 최적화된 파일시스템이 필요하다는 필요성이 나옵니다[4].


- 수 많은 계산노드로 구성되어 있는 클러스터의 효율성을 높이기 위해서는 전체 시스템이 제공하는 리소스를 낭비없이 사용해야 합니다. 하지만 현재의 H/W 발전속도를 고려해 볼때 계산을 위한 CPU 성능에 비하여 노드사이의 I/O 처리 능력은 뒷받침 하고 있지 못합니다[4].

- 이러한 문제를 해결하기 위하여 파일에 대한 메타데이터 정보 (파일 이름, 소유자, 권한, 디렉토리 등)

와 데이터를 담고있는 블록을 구분하여 별개의 노드에 분산시킴으로서 여러개의 클라이언트가 동시에

(동일한 데이터에 대하여 Parallel 하게) 접근할 수 있는 기술이 각광을 받고 있습니다.

파일의 메타정보와 데이터를 저장하는 물리적인 블록정보를 여러 노드로 분산시켜서 병목현상을 해결

하는 방법이죠[4]


하둡의 성공 사례

- 성공사례 1

누가: 뉴욕타임즈

무엇을: 시문에서 스캔한 4테라바이트 문서를 PDF로 고속 변환

어떻게: 아마존 EC2 컴퓨팅 클라우드 사용하여 24시 이내에


- 하둡을 이용한 테라바이트 데이터 정렬

* 2007년 4월 910개 노드 297초 정렬

* 2008년 4월 1테라바이트를 910개 노드 209초 정렬

* 2008년 11월 1테라바이트를 68초에 정렬

* 2009년 5월 야후는 하둡을 사용하여 1테라바이트를 62초에 정렬



하둡의 정의 및 특징

하둡은 안정적인 공유 저장소<HDFS(Hadoop Distributed File System)>와 분석시스템(MapReduce)를 제공한다.

하둡이란 분산 소프트웨어 플랫폼으로서 대량의 데이터를 처리할 수 있는 애플리케이션을 쉽게 제작하고 운영하는 것을 도와준다[1].

Hadoop은 HDFS를 이용해서 MapReduce를 구현[1]


HDFS 정의 및 특징


HDFS 는 저비용 H/W (PC 혹은 1U x86 서버) 에 대용량 데이터 처리를 하기 위하여 개발된 분산파일
시스템 (Distribute File System, 이하 DFS) 입니다[4].

HDFS는 범용 하드웨어로 구성된 글러스터에서 실행되고 데이터 엑세스 패턴을 스트리밍 방식으로 지원하여 매우 커다란 파일들을 저장할 수 있도록 설계된 파일시스템이다[3]. 

HDFS는 안전을 위해 여러개의 데이터 블럭 복사본을 클러스터에 위치한 노드들에 만듭니다. 

- 매우 커다란 파일: 수백 메가바이트, 수백 기가바이트, 수백 테라바이트 크기의 파일을 의미. 요즘 운영되고 있는 하둡 클러스터들은 페타바이트의 데이터를 보유[3]


'스트리밍방식으로 대용량 파일저장이 가능하다'...

대용량 데이터를 생산하는 연구기관, 개별연구자들은 데이터를 어떻게 저장하고 액세스하고 있을까? 이에대한 연구도 필요한듯 


그렇다면 분야별 데이터센터에서 HDFS를 사용하기 위해서는 

- 하드웨어 인프라가 필요하다. 적어도 20~40 노드로 구성된 렉이 몇개는 있어야 겠지?

- 리소스만 있다고 되는겨? 시스템 운영은 누가 하고? 맵태스크와 리듀스태스크는 누가 개발하는겨?

- 결국 전산 전문가가 필요하다는 얘기!!!


그럼 국가과학데이터센터에서 해야하는 일은 뭐지?

- HDFS와 같은 분산파일시스템을 운영하는데 필요한 공통 기술 개발 및 교육

- 맵리듀스 연구를 통한 공통모듈개발 및 분야별 데이터센터 전산전문가 교육

- 분야별 데이터 분석을 위한 기술지원

뭐.... 이런거 아닐까?


HDFS가 잘 맞지않는 응용분야[3]

- 데이터 엑세스에 수십 밀리 초 범위의 빠른 응답시간을 요구하는 응용프로그램은 HDFS와 적합하지 않다.

- 많은 수의 작은 파일


 장애복구(fault-tolerance) 기능[4]
클러스터 기반에서 동작하는 어플리케이션의 특징은 여러개의 노드에서 수행될 수 있도록 프로세스들이
분산되어 있으며 상호간 연결고리를 가지고 있습니다. 만약 특정 노드에 장애가 발생되어서 중단 된다면
그와 연관된 다른 노드의 프로세스들은 다시 재 수행을 해야 합니다. 물론, 프로그래밍 모델에 따라서
이러한 재 수행 시간에 필요한 낭비의 차이가 다릅니다. 전통적인 MPI (Message Passing Interface)
모델에서는 분산된 프로세스간의 통신이 빈번하므로 재 수행에 오랜 시간이 걸리지만, Map/Reduce
모델은 그 반대 입니다.

[참고] 병렬 프로그래밍 모델인 MPI 와 Map/Reduce 모델은 차후에 한번 정리해 볼 생각입니다.
          학부 및 대학원 시절 MPI 에 대해서 매우 재미있게 공부한 기억이 떠오릅니다. 흥미로운 점은
          MPI가 클러스터의 계산능력을 최대로 이끄는 모델이라고 하지만. 데이터의 병렬 처리에는 맞지
          않는 모델이라는 점입니다. 그에 비해 Map/Reduce 모델은 그 반대이네요.   
이러한 문제를 해결하기 위한 가장 좋은 방법은 파일 시스템에서 장애처리를 자동으로 담당하여
어플리케이션 개발자가 장애에 대한 신경을 쓰지 않게 프로그램 개발을 제공하는 것입니다. 특히
방대한 분산작업이 필요하며 중요한 데이터 처리가 핵심이라며하면 어느 시스템이던 I/O 장애에
대한 대비를 제공해야 합니다.

GFS 와 HDFS 는 이러한 장애를 노드간 Replication(복제) 기능을 통해 해결하고 있습니다.


복제(Replication)
Replication(이하 복제) 기능은 용어 그대로 데이터를 중복하여 저장한다는 의미입니다. 여러개의 노드에 동일한 데이터를 복제하여 분산시킴으로서 특정 노드에 장애가 발생하더라도 다른 노드에 저장된 데이터를 통해 관련 어플리케이션은 장애에 영향을 받지 않고 자신의 작업을 수행할 수 있습니다. HDFS는 이러한 복제기능을 각 계산노드의 로컬 디스크에 저장합니다. 특정 노드에서 처리중인 파일은 기본적으로 3개의 다른 노드에 중복되어 저장되며 (랙 내부의 2개 노드 + 다른 랙의 1개 노드) 특정 노드의 장애 발생시 다른 노드가 데이터 I/O 에 대한 역할을 담당합니다. 성능 향상을 위하여 노드간 데이터 복제시 Pipelining 을 통해서 이루어지며 파일의 메타정보를 담당하는 NameNode 데몬이 해당 노드의 장애를 감시하여 데이터의 복제유무를 관장합니다.

맵리듀스 정의 및 특징


클러스터 환경에서 개발자가 고려해야 할 사항[6]

- 네트워크로 묶인 수많은 노드에게 자신의 프로그램을 배포

- 각 노드에서 수행되는 프로세스가 처리해야할 데이터 분배

- 결과를 취합하여 가공하는 방법

- 분산 환경에서의 프로그램 디버깅


결국, 가이드 필요 => 표준 프로그래밍 모델로 제안되고 있음


표준 프로그래밍 모델 종류[6]

- 전통적으로 대규모 컴퓨팅 클러스터의 인프라를 이용하기 위한 다양한 병렬 프로그래밍 모델이 존재. 어플리케이션 개발자는 이러한 모델을 구현한 라이브러리를 이용하여 주어진 서비스 혹은 제품의 기능에 필요한 병렬 소프트웨어를 손 쉽게 개발 할 수 있음. MPI (Message Passing Interface) 가 바로 대표적인 병렬 프로그래밍 모델

- 고속의 컴퓨팅 연산보다는 대규모의 데이터 처리를 위하여 구글에서 제안한 프로그래밍 모델(Map/Reduce)




맵리듀스는 데이터가 한 번 쓰이면서 여러 번 읽게되는 응용프로그램에 적합. 반면 관계형 데이터베이스는 지속적으로 업데이트되는 데이터셋에 적합[3]

- 구조화된 데이터(structured data): XML 문서나 정해진 스키마에 부합하는 데이터베이스 테이블

- 반구조화된 데이터(semi-structured data): 조금 더 자유롭고, 스키마가 있다 해도 종종 무시되기 때문에 데이터 구조에 대한 참조 정도로 사용되기도 함. 스프레드시트는 그리드 형태의 셀들을 데이터 구조로 가지고 있지만, 각 셀에는 어떤 형태의 데이터라도 저장가능

- 비구조화된 데이터(unstructured data): 어떠한 특별한 내부 구조가 없음. 일반 텍스트나 이미지 데이터가 그러함.

맵리듀스는 처리 시간에 데이터를 해석하도록 설계되었기 때문에, 비구조화 또는 반구조화된 데이터에서 잘  작동함. 다른 말로 하면, 맴리듀스를 위한 입력 키와 값들은 데이터의 고유 속성이 아니라 그 데이터를 분석하고자 하는 사람에 의해 선택적이라는 뜻임


따라서, 과학데이터의 메타데이터는 수시로 변경가능하고 지속적으로 업데이터 되기 때문에 RDBMS로 관리하고, 원시데이터(raw data)는 하둡으로 관리하는 것이 효율적인 것으로 판단된다.


맵리듀스는 선형적으로 확장할 수 있는 프로그램밍 모델이다. 플고그래머는 맵과 리듀스라는 두 개의 함수를 작성한다.. 맴과 리듀스 함수 각각은 하나의 키/값 쌍(key-value pairs)을 또 다른 것으로 매핑하는 방식을 정의한다. 이러한 함수들은 데이터 크기나 그들이 동작하는 클러스터 크기와 관계가 없어서 작은 데이터셋이든 큰 데이터셋이든 함수 수정 없이 사용될 수 있다. 좀 더 중요한 것은, 만일 입력데이터 크기가 두 배라면, 작업이 두 배 느리게 수행된다는 것이다. 그러나 클러스터 크기를 두 배 늘리면, 작업은 기존보다 바르게 수행될 것이다. 일반적으로 관계형 데이터베이스의 SQL 쿼링 경우에는 그렇지 못하다[3].


맵리듀스는 계산 노드에 데이터를 함께 배치한다. 따라서 데이터가 로컬에 있기 때문에 데이터 엑세슷가 빠를 수 밖에 없다. '데이터 지역성'이라고 알려진 이러한 특성은 맵리듀스의 핵심이고, 좋은 성능을 낼 수 있는 이유이다. 네트워크 대역폭이 데이터센터환경에서 가장 중요한 자원이라는 것을 인식하자[3, 34p].



MapReduce는 애플리케이션을 많은 작업단위로 나눕니다. 
MapReduce는 어디에 그것이 위치에 있던지 데이터를 처리할 수 있습니다.


- 규모: Hadoop은 안정적으로 페타바이트 단위의 자료를 저장하고 처리할 수 있습니다.
- 경제적이다: 일반적으로 쓰이는 컴퓨터 클러스터들 간에 데이터를 분산하고 처리할 수 있습니다.
- 효율적이다: 데이터를 분산시킴으로써 하둡은 데이터가 위치한 노들들을 병렬적으로 처리할 수 있으며 이것은 매우 빠릅니다.
- 안정적이다: Hadoop은 자동적으로 많은 데이터복사본을 유지합니다. 또한 문제가 생겼을 시에 자동적으로 재배치를 수행합니다.


HDFS 파일 시스템은 순수한 자바 파일시스템입니다[2].


하둡은 분산컴퓨팅을 위한 인프라스트럭처와 그 산하의 관련 서브프로젝트들의 수집품이 되었다[3, p.41].

맵리듀스는 데이터 처리를 위한 프로그래밍 모델이다.



하둡 생태계[3, p.41]


HBase

- 분산 컬럼지향(column-oriented)데이터베이스. 스토리지로 HDFS를 사용


스쿱(Scoop)

- 관계형 데이터베이스와 HDFS 간 데이터를 효율적으로 이동시키기 위한 도구


Reference

[1] Hadoop이란? http://www.hadoop.or.kr/?document_srl=182

[2] HDFS, HBase란 무엇인가?  http://www.hadoop.or.kr/?document_srl=214&mid=tip

[3] Hadoop 완벽가이드 한빛미디어

[4] GFS 및 HDFS 특징 http://nadayyh.springnote.com/pages/6064909 [인용일: 2012.2.28]

[5] 하둡 홈페이지 http://hadoop.apache.org/

[6] Map/Reduce 개념 http://nadayyh.springnote.com/pages/6064905  [인용일: 2012.2.28]




vi 환경세팅 04 기초부터 다시!!

VIM은, BOM(Byte Order Mark) 이 있는 UTF-8 파일은 자동으로 인식하지만, BOM이 없으면 인식하지 못하고 파일 속의 한글이 깨집니다.

이때는 다음과 같이 인코딩을 수동으로 전환해 주면 됩니다.

VI : 인코딩 전환

* 현재 편집중이라면 키보드의 Esc키를 누릅니다. * 콜론(:) 키를 눌러, 명령어 모드로 들어갑니다.

* set enc=utf8 , set enc=utf-8

VI : UTF-8 인코딩 전환

* set tenc=korea * set enc=utf-8

- tenc는 termencoding 값을 설정하는것이고 - enc는 encoding 값을 설정하는 겁니다.

VI : 한글 완성형(euc-kr)으로 인코딩 전환

* set enc=cp949 * set enc=euc-kr

VI : 영문 모드로 인코딩 전환

* set enc=cp437

VI : 인코딩 설정

.vimrc 에서

set fileencodings=utf-8,euc-kr 만 하면 자동으로 utf-8인지 euc-kr인지 자동판별해서

fileencoding 값을 정해 줍니다

저장하면 새파일이면 터미널의 인코딩대로 저장되고 있던파일이면 원래 파일 인코딩대로 저장됩니다. 만약 인코딩을 바꾸려면 :set fileencoding=utf-8:w

하면 utf-8로 바뀌어서 저장됩니다.

[출처] VI 에디터 유니코드(UTF-8)로 인코딩 전환|작성자 슬레이어

그리하여... 난...

set fencs=utf-8,euc-kr.latin1

set encoding=utf-8

set cindent

set visualbell

set fileencoding=utf-8

set ts=4

set st=4

set sw=4

set hlsearch
syntax on
colo 256-jungle



/usr/share/vim/vim73/colors$

http://vimcolorschemetest.googlecode.com/svn/html/index-c.html
http://amix.dk/vim/vimrc.html


Flash Disassembler 01 Hacking


도스형 플래쉬 역어셈 프로그램이다.
조금 복잡하면 잘 되진 않지만, 그래도 나름 유용하다.
패치기능도 있으니 조타~~~~

swf -> flm
flm -> swf

http://www.nowrap.de/flasm.html

출처 : HAKIN9

1 2 3 4 5 6 7 8 9 10 다음