Enter the dragon

http://www.cs.utah.edu/~hal/index.html

Hal Daumé III 라는 분인데 꽤 유명한 분인가 봅니다.
Machine learning 분야에서 말입니다.
본사에 오신다고 하는데...
궁금한거 있으면 메일 보내라고 하는데
뭐 아는게 있어야 메일을 보내지말입니다.-ㅁ-

bayesian prediction과 self-learning쪽이 전문인가 본데.
살짝 생소하네요.
얼굴도 잘생겼고 젊습니다. (오옷 -ㅁ-)
불공평하다고 생각합니다.

갑자기 통계에 필이 꽂혀서 밤12시에 고감자군에게 전화해서 추천해달라고 한 책입니다.
일단 감자군이 선택한 책을 선택하면 최소한 손해는 안본다는 거.
묻어가기 모드라고나 할까나요...'ㅡ';;

- R활용통계학
- R을 이용한 통계 프로그래밍 기초

낼름 주문 했습니다.
오면 열공 모드로...
당장 돌입하지는 않겠지만
수집해 두면 언젠가는 보게 되드라는 말이지요.

http://www.kdnuggets.com/polls/2008/data-mining-software-tools-used.htm

SPSS 관련 자료를 찾다가 이런걸 발견했습니다.
데이터마이닝 소프트웨어 사용 순위 뭐 그런거 인가봅니다.
RapidMiner나 Weka 정도는 받아서 사용해 보는 것이 좋다는 생각이 듭니다.
사실 Weka는 많이 알려져 있어서 알고 있었지만 RapidMiner는 조금 생소했습니다.

http://twit88.com/blog/2009/03/14/open-source-text-analytics/

위 링크는 Text Mining에 소프트웨어에 대해 설명해 놓은 것이 있습니다.

몇개는 생소한데...
여튼.. 참조자료로 괜찮을 것 같아서 걸어둡니다.

그런데 Matlab이 데이터 마이닝 툴이었던가요? 뭐 뭐든 가능하긴 하겠지만...
(실제로 알아보니 상당히 많은 분들이 Matlab으로 Machine learning과 Data mining을...)

그리고 오늘 알았는데 SPSS 제품군들은 죄다 PASW 어쩌구리로 이름이 바뀌었더군요.
SPSS에서 제품군 이름을 새로 개명하나 봅니다.
그래서 Clementine(오 마이 달링...클레멘타인)도 없더군요.

왜 그랬는지...

Classifier의 training-set 개수가 - 학습용 데이터의 개수가 - feature수에 비해 상대적으로 적을 경우 classifier의 성능이 떨어진다.
바꿔 말하면 feature의 수가 많아질 수록 품질을 확보하기 위해서 필요한 training-set의 개수가 기하급수적으로 늘어나게 되는데
이것을 차원의 저주라고 말한다.
이는 training-set이 충분하지 않을 때는 가능하면 가장 효과적인 feature들을 선택하여 feature의 수를 줄여주는 것이 일반적으로 유리함을 뜻한다.
다른 관점에서 말하면 classifier에서 사용하는 feature의 수가 많거나 classifier가 복잡하게 설계되어 있다면 더 많은 training-set을 마련해야 함을 말하는데 현실적으로 이는 많은 비용문제를 야기시키게 되고 feature의 개수를 줄이는 것은 training-set의 부족함으로 인해 차원의 저주를 피할 수는 있지만 feature의 수가 적음으로 인해서 충분한 판별능력을 가지지 못하여 classifier의 성능 저하를  발생시킬 수도 있다.

적절한 feature를 선택하는 것, 잘 선택하는 것은 대부분 이 계통의 공부가 깊으신 분들이 공통적으로 하는 말씀들이다.
경험상 대부분의 심각한 성능 문제는 feature와 관계되어 있는 경우가 많았다.
복잡한 알고리즘, 멋진 알고리즘 보다는 적절하고 다양한 알고리즘을 선택해서 비교해 보고
복잡한 feature, 대량의 feature보다는 적절한 feature를 선택해야 한다.
쉬우면서도 매우 어려운 문제이고 언제나 잘 안된다.

feature를 선택할 때는 언제나 아주 많은 고민을 해야하고 반복된 시행착오를 많이 해 봐야 한다고 생각한다.

내용 추가.
내가 적어 놓고도 뭔 말인지 잘...
일단 feature를 잘 선택하면 반은 먹고 들어간다는 말이고
선택을 잘 못하면 본전도 못 건진다는 개인적인 경험에서 나온 얘기다.
오해 및 태클은 사양.

귀찮아서..적어 놓고 붙여 쓰기

HADOOP_CMDS="cat cp du dus ls mkdir mv put rm rmr get put chmod"

alias h='hadoop'
alias hdfs='hadoop dfs'
alias hfs='hadoop fs'
for HADOOP_CMD in $HADOOP_CMDS; do
    eval "alias h${HADOOP_CMD}='hadoop dfs -${HADOOP_CMD}'"
done

전체 gateway에 한꺼번에 push해서 사용하자.

hadoop 0.20

어째서? 어째서?
0.18에서 바로 0.20으로 간 것일까?
이계통의 일들이 다 그렇지만 안정성에 치명적인 타격을 입을 것을 알고도 그렇게 했다는 것은 뭔가 중요한 이유가 있는 것이다.
오해의 소지가 있을지 몰라서 하는 말이지만 hadoop의 version이 하나를 건너 뛰었다는 말을 하는 것은 아니다.
내가 사용하는 환경이 0.18에서 0.19를 건너 뛰고 아직 정식 relase도 아닌 0.20으로 바뀌었다는 말이다.

schduler 때문이라고 얼핏 본 것 같다.
그래서 이 버전에서 당장 크게 변한점은 scheduler부분이다.
hod allocate가 사라졌다.
user는 더 이상 job allocation을 할 수 없다.
다시 말하면 안해도 된다 (할 수도 없고..)
새로운 scheduler가 모 보험회사 광고처럼 "알아서 다 해 줄 것이다"

scheduler가 이런 방식으로 바뀐 것은 다음과 같은 문제 때문이다.
일부 user가 hod allcation을 한 후에 deallocate를 하지 않거나 해서 node가 idle상태로 남아 있게 되고 그로 인해 자원이 낭비되면서 다른 user에게 자원을 할당하지 못하는 문제를 해결할 수 있다.
또 hod allocation을 하기 위해서 기다렸던 대기시간을 대폭 단축시켜준다.
아직은 task자체가 unlimit이기 때문에 대용량을 수행해도 최대한의 task를 할당받아서 아주 빠른시간에 수행이 가능하다.
(복잡한 작업이 아니라면 70000개쯤 순식간에...)
또 일부 개념없는 user의 필요이상의 allocation으로 인해 자원이 낭비되는 부분도 해결된다.
왜냐하면 알아서 해 주니까.
이젠 더 이상
"나도 일좀하게 deallocation 해주지 않을래?"
라는 다른 user들의 메신저 메시지는 이제 안 받아도 된다.

두서없는 정리

문자열의 토막난 단위들을 token이라고 부르기로 하고
document에서 추출한 token을 이용해서 뭔가 그럴듯한 데이터를 마이닝하거나 가지고 놀아 보려고 한다면.
그러니까 topic을 만들어 본다거나 tag를 추출한다거나 topic을 clustering 한다거나 하는 경우등이다.
특별한 이유로 구체적으로 예시를 들 수는 없지만.
여튼 경험상 아래와 같은 것들을 고려해야 한다는 것을 알 수 있었으므로 정리해 두고자 한다.

1. 우선 형태소분석기의 상태를 잘 점검해야 한다.
형분기는 종류별로 기본 작동원리가 다를 수 있고 세부 구현에 따라 결과물이 달라질 수 있으므로 어떤 원리로 작동하는지 어느 정도 선까지는 파악하고 있어야 한다.
어떤 기능까지 이용할 수 있는지 파악해 두어야 한다.
이상한 소리 같긴 하지만 그렇다고 해두자. 그리고 직접 만든 경우가 아니고 구현체를 가져다 쓰는 경우에 그렇다는 말이다.
그리고 기능이고 뭐고 아주 단순한 형분기라면 별 상관 없는 얘기가 되겠다.

2. 형분기의 기본상태만으로는 해결이 안되는 문제가 반드시 발생한다.
text data processing이 다 그러하듯이 우선 dictionary 문제가 무조건적으로 발생한다.
(경험상 거의 발생했다는 얘기일뿐. 확대해석 금지)
natural language 종류와 상관없이 거의 다 그렇지 않겠냐는 것이 나의 추측이다.
(한국어라면 복합명사와 기타의 문제로...)
여튼 dictionary는
형분기가 사용하는 dictionary들이든 전처리, 후처리에 사용하는 dictionary든 해당 domain에 적합한지 직감적으로 파악할 수 있어야하고 없다면 만들어 낼 수 있는 source 정도는 확보해 두는 것이 좋다.
물론 그 source는 실비가 소요될 수 있다. (실비 소요하지 않고 얻을 수 있는 것은 없다고 보는 것이 정신건강상 이롭다. 그리고 dictionary는 품질이 보장 되야하는 것이 기본이다.)
dictionary의 source문제 뿐만 아니라 dictionary를 효과적으로 이용하기 위해서는 각종 고속 알고리즘을 섞어써야 하는 경우가 많다. 고속 알고리즘을 선택적으로 섞어써야 하는 이유는 순전히 대용량 처리때문이고 그게 아닌 경우라면 qps나 tps따위에 민감한 time critical한 경우를 고려해야 하는 경우다.
그런 것이 아니라면 저속 알고리즘을 우선 써도 되겠지만 결국 나중에 가서는 못쓰게 된다.
고속 알고리즘을 섞어 쓴다함은 한 두가지의 단순한 자료구조 알고리즘이 아니라 적절한 요소에서의 적절한 고급 알고리즘을 섞어 쓰는 것을 말한다.(당연한 얘기겠지만..쿨럭)
이는 dictionary의 구성 형태에 따라 달라지기도 한다.
즉 one token dictionary인지 phrase dictionary인지 pattern dictionary인지 meta 정보를 포함한 복잡한 dictionary인지에 따라 다소 다르다.
사실 hash table, b-tree, trie, TST, FSA 등등이 뭐가 좋고 안좋고는 중요하지 않다. 단지 어느것이 어느부분에 더 적합한지 원하는 만큼의 충분한 결과가 나오는지가 쬐끔 중요하다.
사실 요즘 하드웨어가 좋아져서 대충 써도 어지간한 것은 성능을 비교하기도 힘들다.
(그래도 많이 하면 성능차가 조금은 나기 때문에 가능하면 좋은게 좋은거라는...)

3. 분산처리를 고려하자.
졸라 빠른 것을 쓰더라도 일을 졸라 많이 해야하는 경우라면 결국 마지막의 time taken을 찍어보면 졸라 느려지는 것이 기본이다.
분산처리를 하기 위해서 적절하게 심플하고 독립성 있는 구조로 구현체를 마련해 두어야 한다.
분산환경과 single machine 환경을 따로 구분해서 작업하기에는 상황이 너무 cloud 환경쪽으로 심하게 가고 있고
또 처리해야 하는 데이터양도 심하게 많아지고 있다.

4. 그외의 수학적 알고리즘
보통의 공학적 알고리즘은 품질보다는 속도와 관련된 성능문제에 많이 관계되어있지만 수학적 알고리즘들은 품질과 큰 관련이 있다. 수학적 알고리즘은 적절한지 아닌지도 구분하기 힘들만큼 사용하는 방식이나 응용에 따라 차이가 많을 수 있다.  여러가지 방법론을 알아보고 빠르게 비교해서 선택할 수 있어야 한다.