it개발자스터디공간

『 Maven 리포지토리에 없는 jar파일 추가 』

​

​

● /src/main/webapp/WEB-INF/lib/ 이하에 직접 추가

​

​ 

< Spring MVC 개발 >

* Spring MVC 처리 Flow

​* 파일 구성

​* 설정 파일 준비

​

(*) Pom.xml

​- Web Library

​- Logger Library

​- Tag Library

​- Spring Framework

​- Json Library

​- Maven 리포지토리에 없는 jar 파일 추가

(*) Web.xml

(*) 공통 Spring Bean 설정 파일

(*) Spring MVC 용 설정파일

『 명령 대상 』

​

​

​명령 대상은 명령이 실행될 객체로 명령 소스에서 그 대상을 명시적으로

​

설정할 수 있으며 대상이 정의 되지 않은 경우에는 키보드의 포커스가

​

위치한 요소가 명령 대상이 됩니다 위의 예제를 생각해 본다면 명령

​

대상은 당연히 TextBox 가 되겠지요..! 하지만 저는 명령 소스에서 명령

​

대상을 따로 설정하지 않았으므로 키보드의 포커스가 TextBox에 올라

​

갔을때 명령 대상이 TexBox가 되는 것이지요

​

이렇게 명시적으로 명령 대상을 설정하지 않았을 경우에는 개발자가

​

명령 대상을 따로 관리하지 않고 같은 명령 소스를 사용하여 포커를 

​

옮겨 다니며 여러 대상에게 명령을 호출 시킬수 있는 장점이있습니다

​

INVERTED INDEX V3

Version3 - Partitioner

Partition시 WordID에서 Word만 보고하도록 구현

Version 3- GroupingComparator

- 같은 리듀서로 모인 키/밸류페어들을 그룹핑할 때 쓰이는 Comparator로 역시 여기서는 Word만 보고 그룹핑이 이뤄져야한다.

Version3- SortingComparator

- 같은 키로 묶인 밸류들을 소팅할때 쓰이는 Comparator로 여기서는 DocID를 보고 소팅해야한다. 여기서는 그냥 WordID의 Comparator에게 비교를 맡긴다.

Version3의 문제

- 이 방식은 MapReduce 프레임웍의 힘을 이용해서 문제를 해결하기에 메모리에러등의 가능성은 적지만 대신 네트웍 통신양은 Version 2에 비해 크다.

- 하둡의 병목중의 하나는 바로 네트웍

* Map출력물의 압축이 반드시 필요

Version 3

- 여기서 시도할 방식은 흔히 Secondary Sorting이라는 것이다.

- 보통 reducer로 넘어오는 밸류 리스트는 특별한 순서가 없이 랜덤하다. 앞에서 보았던 SortingComparator를 보면 키값 비교를 위해 단순히 키만 비교하기 때문

- 만일 밸류리스트에 순서를 줄 수 있다면 이 문제를 reducer단에서 해결가능!

* 즉 같은 단어를 갖는 DocID의 리스트를 소팅된 상태로 받을 수 있다면 간단하게 같은 DocID에서 넘어온 단어들을 한번만 출력가능

* 또한 Inverted index의 문서 리스트가 ID로 소팅이 되기때문에 다른 연산 (AND연산등)이 간단해진다.

Version 3 - 새타입사용

- Secondary sorting을 하려면 커스텀타입이 키로 사용되어서 밸류가 키로 들어가야함

* 그래야 나중에 GroupingComparator가 그룹핑시 밸류는 무시하고 SortingComparator는 소팅시 밸류를 염두에 둘수 있다.

- WordID라는 타입을 정의

* WritableComparable에서 계승

* 다음 2개의 멤버변수를 가짐

Version 3 - main

- partitoner, SortingComparator, GroupComparator를 모두 커스텀클래스로 교체

Version 2

- 앞에서 설명했듯이 이 버전은 Mapper에서 단순무식하게 (word.docID)쌍을 출력하는 것이 아니라 HashSet을 이용한 unique한 (word.docID)쌍을 내보낸다.

- StringTokenizer를 이용해 파싱이 끝나면 루프를 돌면서 단어들을 HashSet에 집어넣은 다음에 HashSet을 iteration하면서 나온 단어들과 해당문서의 docID를 Reducer로 넘긴다.

Version2 -map

Version2의 문제

- 버전 2는 버전1에 비해 Mapper에서 Reducer로 넘어가는 데이터의 크기가 훨씬작음

- 하지만 아주 큰 텍스트를 가진 문서들이 많은 경우 HashSet의 크기가 커져 역시 메모리에러의 가능성 존재

- 다른 방식은 Version 1 처럼 Mapper/Reducer를 구현하고 중간의 Shuffling/Sorting 방법을 바꿔보는 것이다.

INVERTED INDEX V1

이번에는 앞서 보았던 데이터파일중의 하나인 2M.ID.CONTENTS파일을 이용해 Inverted Index를 만들어봅니다.

예를들어 hadoop이란 단어가 들어간 문서들의 리스트를 모아보는 것인데 이를 모든 단어들에 대해 수집합니다.

기본적으로 텍스트검색엔진이 수행하는 일이 이것인데 보다 자세한 랭킹을 위해 단어가 나타난 위치 등등..의 세세 정보를 기록합니다.

V1 (Version 1)

- V1은 아무런 최적화작업없이 WordCount를 조금 바꾼 형태로 구현됩니다.

- WordCount에서는 텍스트부분을 파싱한 다음에 만들어진 토큰들에 대해 다음과 같이 reducer로의 출력쌍을 만들었습니다.

* context.write(word, new LongWritable(1));

- InvertedIndex에서는 context.write(word,new Text(docID));

- 위와같이 단어키에 대해 docID를 밸류로 내보낸다.

- Reducer 부분에서는 그냥 넘어오는 docID를 계속해서 스트링버퍼에 append한 후 결과물로 내보낸다.

Version1 -reduce

- Map 부분은 앞서 본 프로그램과 너무 비슷해서 건너뜁니다.

Version 1의 문제

실행해보면 아마도 Heap memory 에러와 같은 것을 볼 수 있을 것입니다.

이유는 특정 단어의 경우 한 문서에도 여러번 나오는등 빈도수가 아주 큰데 지금의 구현은 한 문서에 어떤 단어가 여러번 나올 경우 그 수만큼 반복하기 때문이다.

채결책!

JVM의 메모리 증가. 디폴트로 태스크마다 할당되는 JVM은 200M의 메모리를 사용. mapred-site.xml의 mapred.child.java.opts파라미터을 이용해 증가 (아래예는 1GB로 증가)

Mapper단에서 HashSet을 구현하여 같은 단어들이 여러번 나오더라도 한번만 emit하던지 아니면 빈도수를 문서 ID와 함께 내보냅니다.

JOIN ID AND TITLE V2

MyMapper.setup (2)

실행결과

- JoinlDtitle과 같은 결과를 내겠지만 속도라는 측면에서 훨씬 더 빠르게 수행된다.