『 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 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과 같은 결과를 내겠지만 속도라는 측면에서 훨씬 더 빠르게 수행된다.

 

JOIN ID AND TITLE V2

 

main 함수

 

- org.apache.hadoop.filecache.Distributed Cache를 임포트 한다.

 

- doclDFreq로 HDFS상의 Top Citation파일의 위치를 저장한 다음에 (main 함수의 실행인자로 받아들이게 구현) 다음함수를 호출해서 DistributedCache에 등록

(이 함수는 여러번 호출되어도 무방)

* DistributedCache.addCacheFile(new URI(doclDFreq), conf);

 

MyMapper.setup(1)

 

- Mapper의 setup메소드에서는 다음 함수를 호출하여 distributed cache로 등록된 파일들의 위치정보를 받는다(이젠 모두 로컬파일시스템의 path!)

 

localFiles=DistributedCache.qetLocalCacheFiles(context.getConfiguration());

 

- 이때 리턴되는 값은 Path의 배열인데 이 경우 우린 첫번째 원소만 필요하다. 그걸 String으로 바꿔서 Java의 File I/O stream을 이용해 한줄씩 읽어서 해쉬맵에 저장

 

다음글에서 계속 공부할께요 ^-^

 

 

+ Recent posts