ML in Action.. Ch. 1

올해 6월에 쓰고는 처음 포스팅이네요. 그간 직장을 옮기고, 자바 / 클로져 공부하고, 빅데이터 좀 파보고.. 300 줄 이내의 안드로이드 앱 하나 만드니 반년이 갔네요..

12월부터는 머신 러닝 살짝 파보려고 합니다.

매닝의 인 액션 시리즈..  참 좋은 것 같네요..

Part 1   Classification

이 책의 첫 두 파트는 supervised learning.  관리된 러닝은 목표 변수를 규정하고 데이터로부터 배우도록 지시한다.
목표 값의 두 경우.  노미널 : 참/거짓, 물고기, 포유류, 식물 …
실수 : 이 경우 ‘회기’ 라고 불림.  이것은 파트 2 에서 공부한다.
첫번째 파트는 분류 .. 에 촛점을 맞춘다.

7장의 분류 불균형으로 마무리. 다른 클래스들보다 한 클래스의 데이터가 더 많을 경우… 실세계의 문제.

Ch. 1 … Machine learning basics

머신 러닝의 여러 사례. 스팸 필터, 제품 추천, 얼굴 인식..

파이썬 : 머신러닝에 적합.  NumPy : 매트릭스 연산 등 제공.

1.1   What is ML ?

스팸 메일을 제목의 한 단어만 갖고 판단하기는 힘들다. 하지만, 여러 단어의 조합을 보고, 메일 전체의 길이 등 여러 요소를 같이 보면 더 잘 판단할 수 있다. 머신 러닝은 데이터를 정보로 바꾼다.

머신러닝은 컴퓨터 공학, 엔지니어링, 통계, 기타 다른 분야 등의 교차점에 놓여있다. 정치학, 지질학에 적용되기도 한다.

머신러닝은 통계학을 사용한다. 통계학은 회사가 소비자를 속이기 위해 악용되기도 한다.
인간의 동기는 모델링하기 어렵다.  사회 과학에서 60% 가 맞으면 성공적으로 간주된다. 사람 행동의 60%만 예측하면 잘 한 것이다.
항상 맞을 수는 없나?

완전한 모델링이 불가능한 예. 인간은 행복을 최대화 하기 위해 행동하지 않는가? 이것에 근거해 행동을 예측할 수 있는가?  아마도,  하지만 모든 사람의 행복은 다르기 때문에 어렵다.  그러므로, 사람의 행복을 극대화하는 것에 대한 가정이 옳을 지라도 행복의 정의는 너무 복잡하다.
인간 행동을 결정론적으로 모델링하기 어려운 다른 예들이 많다. 이런 문제에 대해서 통계의 몇몇 도구를 사용할 필요가 있다.

1.1.1 Sensors and the data deluge

웹에는 인간으로 부터의 데이터가 있는데, 요즘은 그 외의 데이터가 더 쌓이고 있다. 센서의 기술은 새롭지 않지만, 그것을 웹에 연결하는 것은 새롭다.

지진의 예.  센서.. 핸드폰..  의 3축 magnetometers.  지진 예측에 사용 가능.. 최소 비용.

1.1.2 ML will be more important in the future

향후 10년간 가장 매력적인 직업은 ‘통계학자’ 일 것이다.

1.2   Key terminology

새 분류 시스템. 엑스퍼트 시스템.    분류..

알고리즘을 만들고는.. 훈련시켜야..  또는 배우는 것을 허락해야..  이를 위해 training set 이라는 데이터를 먹여야 한다.
분류에서 타겟 변수는 노미널 값을 받고 회기 작업에서 값은 연속적일 수 있다.
트레이닝 셋트에서 타겟은 알려져 있다. 기계는 특징과 타겟 변수사이의 관계를 찾음으로 학습한다.
타겟 변수는 ‘종’ 이고 노미널 값을 취함으로 이것을 줄일 수 있다.
분류에서 타겟 값은 classes 로 불리고 유한한 개수의 클래스가 있다고 가정한다.

보통은 트레이닝 셋트와 별개의 테스트 세트가 있다. 초기엔 트레이닝 예제가 먹여진다. 이것이 기계학습이 일어날 때이다.
다음에 테스트 셋을 적용한다.  알고리즘이 얼마나 정확한지 추정.

새 분류작업을 한 후 기계가 뭘 학습했는지 알 수 있나?  이것이 knowledge representation 이다.
답은 ‘경우에 따라 다름’ 이다. 어떤 알고리즘은 사람이 읽기 더 좋은 KR 을 갖는다. 이것은 몇개의 법칙으로 표현될 수 있다.
어떤 것은 가능성의 분포 또는 트레이닝 세트로부터의 예 일 수도 있다.
어떤 경우 우리는 엑스퍼트 시스템을 만드는 것 보다 오직 ‘인지 표현’ 에만 관심이 있을 수도 있다.

1.3   Key tasks of ML

이전 예제는 ‘분류’ 에 관한 것.  인스턴스가 어떤 클래스에 들어갈 것이냐.  기계학습의 다른 분야는 ‘회기’ 임.
이것은 수치 예측이다.  이 두가지는 감독된 학습의 예임. 뭘 예측할 지 주어지기 때문에 ‘감독’ 된 것임.
이 반대는 ‘비감독 학습’.  여기선 데이터에 주어진 라벨이나 목표 값이 없다.
비슷한 아이템을 그루핑하는 작업은 ‘클러스터링’ 이라 한다.  비감독 학습에서 데이터를 설명하는 통계학적 값을 찾길 원할 수 있다.
이것은 density estimation 으로 알려져 있다.
다른 예는 많은 특성에서 데이터를 단순화시켜 2, 3차원 형태로 시각화하는 것이다.

1.4  How to choose the right algorithm

노미널, 목표값?. missing value 가 있나? outliers ?  needle in a haystack. ..

1.5  Steps in developing a ML application

> Collect data.
> Prepare the input data.
> Analyze the input data
> Human involvement
> Train and algorithm.  ML
> Test the algorithm
> Use it.

1.6   Why Python?

clear syntax. easy text manipulation

1.6.1 Executable pseudo-code

풍부한 기본 자료형, 객체 지향, procedual, 함수형 형태로 가능.  정규식 없이 텍스트 다루기.  …

1.6.2 Python is popular

NumPy, SciPy, Matplotlib ==>  Pylab

1.6.3 What Python has that other languages don’t have

Matlab, Mathmatica .. expensive.  Java, C … too many ceremony.

1.6.4 Drawbacks

Not as fast as Java or C.
Boost C++ library,  Python, PyPy.

1.7  Getting started with the NumPy library

Machine Learning in Action Ch. 1, 2, 3

Part 1 CLASSIFICATION

1. Machine learning basics

Numpy, matrix, array etc

2. Classifying with k-Nearest Neighbors

숫자 인식.. 스킵.

3. Splitting datasets one feature at a time : decision trees

스무고개 ?  예/아니오 만 가능.
가장 보편적인 등급화 기법.  조사 결과 가장 많이 사용되는 ‘기법’.
이메일 분류.. 직원, 하키(친구) 기타는 스팸으로 분류.
콘택 렌즈 분류..

3.1 Tree construction

D. trees
Pro : 싸다, 결과를 사람이 인지하기 쉽다. 값이 빠져도 OK, 상관없는 특성들을 다룰 수 있다.
Cons : Prone to overfitting
숫자 값, niminal values 에 사용.

Information theory ..

데이터를 나눌 첫번째 결정을 설정해야..

createBranch .. 재귀적..
어떻게 데이터셋을 나눌 것인가.  [10/27]

General approach to decision trees
1. Collect : Any method.
2. Prepare :  ~~~

 

 

 

MongoDB & Python Niall O’Higgins Ch 3, 4

Ch 3. Common MongoDB and Python Patterns

A Uniquely Document-Oriented Pattern : Embedding

RDBMS 의 join 과 같은 역할.
임베디드 다큐도 다큐와 똑같이 작업 가능.
한 키의 다수의 임베디드 다큐는 특히 유용. 즉, 값이 어레이인 속성. ;; 문법에 맞고 매우 유용한 구조.
일-다 관계 표현하는 자연스런 방식. 또는 부모-자식 관계.
한 유저의 ‘여러’ 이메일.. 일반디비에서는 2개의 테이블. 그리고, ‘조인’
몽고에서는 키와 상응하는 이메일들의 어레이..
[.] 기호를 통해 하위 값 가져오기 가능.  즉, dbh.users.find_one( { “emails.email” : “abc@kin.com” } ) .. 이런식.

이 외에도 $pull, $push .. 제공.. atomic append, removal of  sub – documents…
어떤 이메일이 더이상 유효하지 않을 때.. 다큐를 찾아서, 고쳐서, 업데이트 .. 해야하지만,  번거롭고 레이스를 불러올 수 있음.
섭-다큐의 3가지 주 작업 : 삭제, 삽입, 수정..

dbh.users.update ( { “username” : “thename” } ,
{ “$pull” : { “emails” : { “email” : “erse@the.com” } } } , safe=True)

이 소스는 다큐를 찾아내서 어레이에서 atomic fashion 으로 제거하여 레이스 원천봉쇄.
쿼리로 $pull 을 이용 가능.  예를 들어 어떤 조건이 맞는 모든 섭-다큐를 지울 때..
즉.. dbh.users.update ( {“username” : “thename”},
{ “$pull” : { “emails” : { “primary” : { “$ne” : True }}}, safe=True)

atoms 를 갖는 어레이에 적용 가능.  임베디드 다큐 ‘만’ 갖고는 작동 안함.

푸쉬는 어레이에 요소 atomically 추가할 때 사용. 끝에 추가하는 것만 가능.  <어레이의 처음에 추가하거나 임의의 장소에 넣는 업데이트 기능은 없음>
조건문이 없어서 간단함.

new_email = {“email”:”fooemail4@exmaple4.com”, “primary”:False}
dbh.users.update({“username”:”foouser”},
{“$push”:{“emails”:new_email}}, safe=True)
==> # 기존의 섭 다큐를 업데이트..  => positional operator [ $ ] 를 통해 가능.
예 :: {“$set”:{“emails.$.primary”:False}}, safe=True)
>>*<< 업서트 에서 사용 불가, first matched element 에서만 가능.

__ Page 29 __
<1> 임베딩 관련 작업 시, 다큐, 섭-다큐의 성능을 아는 것이 중요. 쿼리에 의해 다큐먼트가 불려오면 섭 다큐 등 모두가 메모리에 로딩됨.
즉, 임베디드 데이터를 가져오는 데 추가의 자원이 필요 없다.. (인코딩 cpu 같은 거 제외하고)
최상위 다큐먼트가 가용상태면 섭-다큐는 즉시 가용함.  이것을 ‘조인’에서는 여러 테이블을 읽으므로 성능이 떨어짐.
<2> 몽고에는 크기 제한이 있지만, 버전 따라 커지고 있음. 1.8 은 16메가.  시간에 따라 커지는 데이터가 아니고서는 충분함.
댓글을 다는 경우.. 한 다큐에 있을 때.
__ To embed , or not to embed. _ _ _ _ _ ^^
임베딩의 대안 >> 다큐를 분리된 컬렉션에 저장.  어플에서 조인하는 코드 구성.
보통 >>> 다 : 다  관계는 이렇게 조인..
보통 >>> 일 : 다  관계는 임베드.

Fast Lookups : Using Indexes in MongoDB [p31]

인덱스의 역할은 관계형디비와 크게 다르지 않음.  두가지 제공 : Btree indexes & geospatial indexes.
Btree 는 MySQL 등과 유사.  관계형 시스템에서는 빨리 찾기 위해 인덱스 이용, 몽고에서는 의미상 인덱스를 컬렉션의 특정 속성에 사용.
몽고는 여러 필드로 인덱스 확장 가능. (a.k.a. compound indexes)  한개 이상의 속성에 기반하여 쿼링하는 것을 미리 알고 있을 경우에 유용.
예 > 성, 이름으로 쿼링할 때.
몽고에서 비트리 인덱스는 “방향”을 가질 수 있음.  컴파운드 인덱스에서만 유용. 성능을 위해 쿼리와 소팅의 방향이 매칭되야 함.
비트리 인덱스는 데이터에 앞서 인덱스를 업데이트해야 하므로 쓰기 퍼포먼스에 타격. 인덱스를 조심히 선택해야 함.
Superfluous indexes를 피할 것.
인덱스는 스토리지도 차지함.   메모리 역시.   전형적인 <시간 대 공간 트레이드 오프> 시나리오임..
비트리는 컬렉션에 특별한 제한을 가할 때도 사용.
비트리는 값이 어레이인 경우도 지원. 어레이의 각 아이템은 인덱스에 적당히 저장되서 다큐의 빠른 조사가 가능. 태깅 기능에 유용.
비트리는 임베디드 다큐도 지원.   예> 이메일을 섭 다큐로 지정하고 인덱스로 사용할 때.
서버 쪽 소팅 퍼포먼스에도 중요. 4메가 이상의 결과에 대해 소팅하려고 할 대 소트 키에 인덱스를 지정해야 함.  개발시에는 예상치 못한 거대한 실제 데이터에 대해 쿼리할 때 예외를 발견하는 것을 간과하기 쉽다.

파이 몽고 드라이버로 인덱스 생성.
Collection.create_index()  # method  single-key OR compound (튜플) indexes 생성.
dbh.users.create_index([(“first_name”, pymongo.ASCENDING), (“last_name”, pymongo.ASCENDING)]) # 리스트로 인덱스 생성 예.
인덱스에는 자동 이름이 붙지만 커스텀 네이밍 가능
dbh.users.create_index([(“first_name”, pymongo.ASCENDING), (“last_name”, pymongo.ASCENDING)], name = “myIndex_name”) # 커스텀 이름.

인덱스를 만들면 기본으로 디비를 ‘잠군다’. 큰 컬렉션에서 시간이 걸리므로. 백그라운드에서 생성 가능. 당연히 시간은 좀 더 걸리지만 디비가 ‘가용’ 상태.
dbh.user.create_index(“username”, background-True)

Unique constraint..  unique=True
유니크 옵션은 몽고에서는 관계디비와는 다름.  첫번째를 제외하고 중복 요소 제거.. dropDups = True

인덱스 제거는 쉽다. drop_index() method.

Collection.index_information() # Python .. 인덱스 조사.   Dictionary 리턴.  인덱스 이름 = 키, 밸류 = 또다른 딕셔너리.
이 딕셔너리는 key ..로 불리는 ‘키’ 를 포함. 인덱스 방향 포함한 원래 인덱스 specifier.   create_index에 넘겨진 것.   옵션들도 포함.

Location-based Apps with MongoDB : GeoSpatial Indexing [p33]

Points of interest (POI)

몽고는 Gustavo Niemeyer 가 개발한 geohasing 알고리즘 사용.
현재로서는 포인트-베이스 쿼링만 가능.
$near $within $box $circle $polygon (MongoDB v 1.9)
GPS 좌표만 가능 (-180 ~ 180 )
파이썬 딕셔너리는 순서가 없으므로 bson.SON 을 이용할 것.

인덱스는 하나의 위치인덱스만 포함 가능.. 다른 것과 같이 컴파운드 인덱싱 가능.

$near :: 기본으로 100개 결과 리턴. 최대값 지정 (5도 정도가 적당) 1도 = 69마일.
$nearSphere $centerSphere :: radian.

Code Defensively to Avoid KeyErrors and Other Bugs [p37]

Update-or-Insert: Upserts in MongoDB

save() : _id 없이 실행하면 새로운 다큐 삽입, _id 가 있으면 업데이트.  ;; 업서트 ..

업데이트는 두가지 경우를 각각 수행함. 문서가 있으면 업데이트 하고, 없으면 새로 만든 후에 업데이트를 실행함.

Atomic Read-Write-Modify : MongoDB’s findAndModify [p40]

업데이트 결과를 가져올 때.. 레이스 컨디션 회피 명령어.

Fast Accounting pattern

점수, 랭킹 계산의 경우.. 데이터 크고, 빠르게 계산 필요.

 

 

Ch 4. MongoDB with Web Frameworks

Pylons 1.x and MongoDB

WSGI-based web frameworks. 2005 09.  v1.0 at 2010
“one-size-fits-all”  < — > Pylon
So modular.. easy to add MongoDB

Pyramid and MongoDB

Pylons 2.0 ..
scaffold ..

Django and MongoDB

Mango..
10gen .. sample app.

2013. 2. 23.