self study

Shuffle job log 분석

- FIle Output Format Counters

Bytes Written - output의 데이터 크기

- Map-Reduce FrameWork

Reduce input groups - 리듀스에 도착한 그룹들을 말하며, 하나의 그룹은 하나의 키로 이루어진 그룹을 말함

Reduce input records - 리듀스에 도착한 그룹으로 볼 수 있으나, 키는 같아도 value값에 따라 나누어진 record이기 때문에 input group보다 수가 많거나 같을 수 있다.

ex)  a    4                                

b    5                        -> 각 스플릿 결과에 따라 나온 결과들이기 때문에 키가 같을 수 있다. Reduce input records는 4가 되고, 이를 키들로 

c    6                            묶게 되면 Reduce input groups가 된다.

a    2

Spilled Records - shuffle&sort  후 버퍼에 남아있거나 버퍼 임계값이 넘쳐 local disk에 쓰여진 temporary output으로 각 map task들이 스플릿을 처리한 output의 record들의 수를 말함.(어찌보면 Reduce input records와 수가 같다.)

Physical Memory (bytes) snapshot - ?

Virtual Memory (bytes) snapshot - ?

매우 단순할 것 같다 ? 답은...하지만 왜이리 찾기가 힘드노...

우연히 여기 방문하셔서 보신다면 댓글 부탁점....

1. 맵리듀스가 무엇인가?

 - 분산된 수많은 노드에 대용량 데이터 처리를 수행함으로써 배치 작업, 관리하는 프레임워크이다. 

2. 맵리듀스 이전 데이터 처리 방식의 한계

 - 데이터를 분석하는데 병렬로 수행한다고 가정한다면 이러한 문제점이 있다.(맵리듀스 사용하지 않을 경우)

  1) 파일크기에 따라서 몇몇 프로세스 처리가 빠른 경우가 있고 느린 경우가 있을 것이다. 빠른 경우엔 추가로 다른 일을 할 순 있겠지만 결국엔 가장 큰 파일에 의해 처리 수행속도가 판가름 날 것이다.

  2) 결과를 조합하는데 있어서 더 많은 처리가 필요할 수 있다. 예를들면 연도별로 데이터를 나누는데 이를 정렬시키고 조합시키는데 처리가 더 필요하다는 것이다.

  3) 단일 서버의 처리 능력은 한계가 있다.

3. 맵리듀스 이해

 1) 간략한 맵리듀스 동작

그림 1) 맵리듀스 동작

(http://withfriendship.com/user/mithunss/mapreduce.php)

 - 위 그림은 맵리듀스를 이해하는데 있어 좋은 예제인 것 같아 퍼오게 되었다. 먼저 맵함수에 들어가기전에 각각 다른 모양과 색깔을 가진 도형들이 있다. 맵함수에서는 같은 도형의 수와 서로다른 도형들을 분류 및 정렬한다. 그리고 맵함수에 출력물을 가지고 리듀스함수에 입력에 사용하여 결과를 나타낸다. 

 헷갈리신다면 도형들을 한 문장으로 생각해도 좋다. 예를 들어 '나의 성격은 나의 행위의 결과이다.'의 문장을 도형의 묶음으로 보고 나의, 성격은, 나의, 행위의, 결과이다 각각 단어를 하나의 도형으로 보면 된다. 구글에서는 이를 이용해서 엄청난 양의 데이터를 처리하여 서비스 한다. 그만큼 맵리듀스는 분산환경 및 대용량 데이터를 처리하는데 효과적인 프레임워크라고 생각한다.

깊은 내용은 각자 서치로^^

 2) 데이터 흐름

 - 두가지 유형 노드

   (1) 잡 트래커 : 태스크트래커들이 수행할 태스크들을 스케줄링하여 시스템 전체에 모든 잡들이 수행되도록 조절함

   (2) 태스크트래커 : 태스크들을 수행하고 각 잡의 전체 경과를 하나의 레코드로 유지하는 경과 보고서를 잡트래커에 보낸다.

그림 2) 다중 리듀스 태스크의 맵리듀스 데이터 흐름

(http://ypshin.com/2690309)

 - 하둡은 맵리듀스의 잡의 입력을 스플릿이라 불리는 고정 크기 조각들로 나눈다. 하둡은 각 스플릿마다 하나의 맵 태스크를 생성하고, 그 스플릿에 있는 각 레코드를 사용자 정의 맵 함수로 처리한다.

 - 맵 태스크의 결과는 HDFS가 아닌 로컬 디스크에 저장된다. 이유는 맵의 결과는 중간결과물일 뿐 잡이 완료되면 맵의 결과는 필요가 없어지기 때문이다. 그리고 만약 맵 태스크를 실행하는 노드가 리듀스에 의해 맵의 결과를 사용하다 실패하면 하둡은 다시 맵 태스크를 또 다른 노드로 전달하여 맵의 출력을 재생성한다.

 - 리듀스 태스크는 맵함수의 출력으로 입력을 받는다. 리듀스의 출력에 대한 각 HDFS 블록은 첫 복제본이 로컬 노드에 저장되고, 그 이외의 복제복은 자신이 속해있지 않은 곳에 저장된다.(이래서 지워야할 해당 데이터들을 찾기가 어렵다는 뜻인가...)

1. 분산 코디네이터

1) 분산 락이나 동기화 문제

• 접근방법
  (1) NFS 같은 파일 공유 서비스 이용 : 모든 서버에 특정 디렉토리를 마운트 시키고 파일 락을 이용
  (2) DB 이용 : 레코드 락을 이용하여 락을 획득한 서버만 자원에 접근하게 함
  

• 단점
  둘 다 락 요청이 많아지면 서버에 부하가 집중되어 SPOF(Single Point Of Failure)가 될 수 있다.

2) 이중화

 - 고가용성을 위해 서버를 이중화 구성을 많이 한다. Active-Active, Active-Standby로 구성된다. 영어 단어처럼 활동하는 서버, 대기 서버라고 보면 된다.

3) 주키퍼(야후의 분산 코디네이터)

 - 분산 환경에서 코디네이터 서비스를 제공하는 아파치 오픈소스이다.

 - 네임 서비스, 환경설정, 그룹 멤버십, Double Barriers, 우선순위 큐, 공유 락 제어, 두 단계 커밋, 리더 선출 

 - 위와 같은 기능을 제공하는 것이 아니라 이런 기능을 쉽게 만들 수 있도록 메카니즘을 제공

 - 하둡과는 연관이 없음

 - 구글의 처비를 많이 참고했다고 알려짐

그림 1) 주키퍼 시스템 구성

(http://creatorw.tistory.com/tag/%EC%A3%BC%ED%82%A4%ED%8D%BC)

 - 주키퍼 서버는 데이터를 파일 트리노드와 같이 계층적으로 저장하고, 저장된 데이터는 주키퍼 서버들 사이에 복제되어 일부 서버가 장애를 발생해도 서비스를 계속해서 할 수 있음(데이터는 서버상태, 락 정보, 환경설정 정보 등과 같은 크기가 작은 메타데이터를 주로 저장)

 - 클러스터는 항상 3대 이상의 서버로 구성되야 함(분산시스템 시간에 배웠는데 까먹었다....) 아마 장애 발생 관련 이유일 것이다...

그림 2) 주키퍼 데이터 모델

(http://creatorw.tistory.com/53)

 - 파일 시스템은 로컬에 저장되어 있거나 마운트 되어 있는 파일과 디렉토리에 대한 접근을 수행하지만, 주키퍼는 클라이언트 라이브러리를 이용하여 네임스페이스에 대한 조회, 노드에 저장된 데이터를 원격 클라이언트에서도 접근할 수 있는 분산 시스템이다. 또한 데이터는 메모리에 존재하나 로그와 스냅샷 파일은 로컬 디스크에 저장된다. zoo.cfg에서 로그와 스냅샷을 로컬 어디에 저장할지 설정할 수 있다.

4) 주키퍼 예제

- zookeeper라이브러리 하나만 추가를 했는데 에러가 났다. 그래서 thrift때 사용하던 라이브러리 몇개를 추가시키니 실행이 되었다. log4j, slf4j-api, slf-log4j......

5) 정합성(Consistency)

 - DB는 정합성을 만족해야 한다.

  정합성이란? 모든 클라이언트는 항상 동일한 데이터를 보장받는 것을 의미한다.

  하지만 분산 서버에 데이터가 저장된 후 처리결과를 보내는 강한 정합성(빠르게 처리결과를 보여줌)이 아닌 이벤추얼(Eventual) 정합성을 갖고 있다. 이벤추얼 정합성은 수밀리 초내로 처리결과를 보여주는 것이 아니라 시간은 조금 늦으나 결과는 같아져 동일한 데이터를 보장할 수 있도록 하는 개념이다.

6) 크롤링이란? 최신 상태의 페이지를 유지하기 위해 웹을 탐색하는 것을 말한다.

http://v.daum.net/link/16695860

Avro로 하나 까는데 2시간 삽질.........
버전업이 되서 .txt 파일을 읽어봐도 도무지 답이 없고

build.sh은 에러 났다고만 하고........

해결방법은

build.sh에서 svn으로 시작되는 부분 주석 제거......

maven 설치 http://maven.apache.org/guides/development/guide-building-m2.html

./build.sh dist

안된다면 과감히 댓글이나 이메일 주세요!

1. 분산 어플리케이션 서버를 효율적으로 구축하기 위한 방안

1) RPC(Remote Procedure Call) : 한 컴퓨터가 프로그램을 실행하기 위해 거리에 상관없이 특정 컴퓨터에 서브프로그램을 불러내는 기술을 말한다. 객체지향 개념적으로 보면 멀리 떨어진 컴퓨터에 특정 객체를 불러오는 행위를 말한다.

그림 1) RPC 개념(http://www.cs.fsu.edu/~xyuan/cop5611/lecture2.html)

 컴파일된 클라이언트 측에서 사용하는 코드를 이를 stub이라 부르고, 컴파일된 서버 측에서 사용하는 코드를 skeleton이라 부른다. 그리고 스텁이 서버에 접근하기 위해 인터페이스를 사용한다.

 - 단점 : 인터페이스 변경 시 매번 IDL을 컴파일해야 함.

2) IDL(Interface Definition Language) :  서로 다른언어로 구현된 프로그램 or 객체가 통신을 하기 위해서 통신을 할 수 있도록 지원하는 언어이다. 이 책에서는 Thrift, Avro를 다뤘다.

개념정리 : http://www.cyworld.com/uchi000/3175980

3) 데이터 타입 : 원격 메소드를 호출 시 주고 받는 데이터(파라미터, 반환값 등)가 int, char[]과 같이 대부분의 프로그래밍 언어에서 제공하는 기본 데이터 타입만을 제공하는 방식과 struct, class와 같은 사용자 정의 데이터 타입을 제공하는 방식으로 구분할 수 있다.

4) 플랫폼(언어) 의존성 : RPC 솔루션이 동일 언어만 가능한지 아닌지 고려해야 한다.

5) 결론

- 가장 이상적인 RPC 구현은 IDL이 없고 사용자 정의 데이터 타입을 자유롭게 사용하고, 다양한 프로그래밍 언어를 사용하는 것이다.  하지만 현실적으로 어려워 RPC 지원 솔루션 중 시스템 요구 사항에 적합한 솔루션을 선택하는 것이 중요하다.

2. Thrift

정의 : 다양한 언어를 지원하는 RPC 서버와 이 서버에서 제공하는 서비스를 호출하는 클라이언트 코드를 생성해주는 소프트웨어 프레임워크이다.  Thrift 개발자는 프로그래밍 언어별 소켓 서버에 대한 구현을 알 필요 없으며 RPC기반이기 때문에 함수 호출 형태로 원격 서버에서 제공하는 서비스를 호출할 수 있고, 사용자 정의 데이터 타입을 이용할 수 있다.

그림 2)  IDL개념도

http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=%2Fcom.ibm.cics.ts31.doc%2Fdfhpj%2Ftopics%2Fdfhpjfe.htm

 개발자가 작성한 IDL 파일을 Thrift에서 제공하는 코드 생성기를 이용해 코드로 생성하면 서버측 개발자와 클라이언트 측 개발자가 모두 사용할 수 있는 코드로 만들어진다. 서버 측 개발자는 생성된 코드를 이용해 Thrift에서 제공하는 서버 측 데몬 프로그램 라이브러리를 이용하여 프로그램을 만들고, 클라이언트 개발자는 생성된 코드와 Thrift에서 제공하는 라이브러리를 이용해 서버 측 프로그램을 호출하는 코드를 작성한다.

3.  thrift 예제 helloServer

- 너무 고생했다. 책에서는 0.5 버전인데 지금은 0.8버전으로 쓰려다보니 THsHaServer에서 생성자가 정의되지 않았다고 난리를 치는 바람에 구글링 한시간만에 다른코드로 대체해서 결국 돌렸다. ㅡㅡ 오랜만에 다시하는거다 보니 생소하다. 하지만 첫번째 예제 끝!

그림 3) helloServer 동작

그림 4) hellClient동작

코드설명 : 서버는 thrift에 변수 나이, 이름을 선언하고 컴파일?하여 몇 천줄의 helloService.java 파일을 만들어 주었다.(이름은 제 마음대로) 이 클래스는 소켓프로그래밍 할 수 있도록 인터페이스를 제공하게 해주었다. 그리고 thrift에서 제공한 라이브러리를 가지고 API사용하여 소켓프로그래밍을 구현했다. Client는 API사용하고 인자 4가지 호스트(루프백), 포트번호, 이름, 나이를 인자로 받아 보내는 역할을 한다.

4. 데이터 직렬화란?

- 파일의 데이터를 읽어올 때나 네트워크를 통해 전송시 스트림 형태로 전송을 하는것을 말함.(일렬로 쭈욱~~~ 나열)

  왜냐하면 외부 프로세스와 통신을 하거나 데이터를 파일로 저장하려면 직렬화를 해야하기 때문이다.

  Thrift는 RPC(Remote Procedure Call) 요청을 안정적으로 처리하면서 이기종 간 RPC호출을 지원하는 개념이고,

  Avro는 데이터 직렬화를 기본 개념으로 하여 RPC 호출을 이기종 간에 가능하게 하는 개념으로 접근한다.