지밍이 블로그

리딩을 해주신 김승일님 자료

http://whydsp.org/263

# Unsupervised Learing / Clusgtering

# 계층적 군집화

1. 유사도가 가장 가까운 한 쌍을 찾는다.

2. 찾은 한 쌍을 하나의 그룹으로 만들고, 그룹의 위치는 두 쌍의 중심(무게중심)

3. 위 과정을 1개의 그룹만 남을 때까지 반복

: 팩토리얼계산으로 2^3알고리즘

# 계통도

: tree의 깊이가 깊은 것 보다, 깊지않은 쪽의 거리가 가까움

# 세로줄 군집화

: 데이터를 단순히 rotation 시켜줌

ex. 마트에서는 어떤 물건을 함께 진열하면 좋을까? 기저귀와 맥주

# 계층적 군집화 기법의 단점

: 뚜렷한 그룹으로 쪼개지 못하고, 계산량이 많음(알고리즘 대박...)

=> K-means Clustering

# K-means Clustering

1. 임의의 k점을 initial centroid로 잡기

2. 각 centroid에서 가까운 node들을 하나의 그룹으로 만듬

3. Centroid Update. 각 그룹의 무게중심으로 중심을 잡기

4. 더 이상 그룹에 변화가 없을때까지 위 과정을 반복

# 선호도 군집

: Zebo.com, 사람들이 가지고 싶은 물건 목록을 만드는 사이트

# Tanamoto Coefficient

: 책이 잘못나온거 같음

타니모토 알고리즘이 맞음

군집화 할 때, 합집합분의 교집합으로 계산

4. 검색과 랭킹

...

06. 유입 링크 사용하기

기존 - 페이지 내용에 기반한 점수 지표

검색품질향상 - 다른 사람들이 그 페이지에 등록한 정보를 적용,
                        의심스러운 값을 가진 페이지나 스패머들이 생성했을 법한 페이지 색인에 효과적

(이런 페이지들은 실제 내용을 가진 페이지에 비해 연결될 가능성이 적기때문)

# 단순계산

유입링크를 사용하는 가장 간단한 방법

> 각 페이지의 유입링크 개수를 세고,

> 링크 전체 개수를 페이지에 대한 지표로 사용

예, 학술눈문

: 인용논문수로 논문의 중요도가 평가

####코드

- 페이지들이 단순 리턴, 해당 페이지의 유입 링크 개수만을 의존하여 랭킹

예, "Programming language"페이지가 "Python"페이지보다 많은 유입링크를 갖지만

정말 찾는 것이 "Python"이라면 결과에서 제일 먼저 나타나야 함

유입 링크 기반지표와 다른 지표들 중 하나와 결합하여 검색능력과 랭킹에 적합도를 결합할 수 있다. (검색능력향상)

# 페이지랭크 알고리즘

"Google"을 만든 세르게이 브린과 래리 페이지가 대학원생 때 쓴 논문 "The Anatomy of a Large-Scale Hypertextual Web Search Engine"에서 발표

개요

- 검색엔진의 품질 향상을 목적

- 웹기반에서의 검색엔진은 인덱스만으론 부족

: 검색된 페이지수는 엄청난 성장으로 방대하나, 사람들의 수용능력은 느리게 성장

         -> 결국 필요한 페이지만 골라서 읽어야 할 필요가 있음

- 관련이 있는 페이지만을 도출하자

- 하이퍼텍스트 정보를 사용하여 웹 페이지간의 연결 관계를 판단, "링크구조 및 링크달린 텍스트"

알고리즘 소개

- 기존 : 특정 페이지를 인용하는 다른 페이지가 얼마나 많이 있느냐를 세는 방식

- PageRank : 다른 페이지에서 오는 링크를 같은 비중으로 세지 않고, 페이지에 걸린 링크 숫자를 "정규화(normalize)"하여 사용

-> 하이퍼링크를 가지는 문서에서 상대적 중요도에 따라 가중치를 부여하는 방법을 가진 알고리즘

PR(A) = (1-d) + d(PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))

PR : PageRack

PR(A) : A페이지의 페이지랭크 값

T1, T2,... : 그 페이지를 가리키는 다른 페이지들

PR(T1) : T1 페이지의 페이지랭크 값

C(T1) ; T1 페이지가 가지고 있는 총 링크의 갯수

> d(Dampen Factor)는 아직 생각하지 않기(d=1로 가정)

> A페이지를 가리키는 다른 페이지들의 페이지랭크 값을 평균화하여 다 더한 값

> 즉 A페이지랭크 값은 그 페이지를 인용하고 있는 다른 페이지들의 페이지랭크 값을 "정규화" 시킨 값

> "정규화"라는 말의 의미... 페이지랭크 값은 단순 합산이 아님. 

예. T1의 페이지랭크가 높아도, T1페이지를 가리키는 링크가 많다면(C(T1)) 그 페이지가 기여하는 비중은 낮아짐

A : 페이지

T1, T2, T3, T4, T5 : A를 가리키는 페이지

- 재귀적 호출 알고리즘

T1, T2, T3, T4, T5 의 페이지랭크값을 정규화하여 합한 값으로 A의 페이지랭크 값을 계산

A의 페이지랭크값도 다른 페이지의 페이지랭크값을 구하는데 사용

제한조건이 필요

- Dampen Factor

: 어떤 마구잡이로 웹서핑을 하는 사람이 그 페이지에 만족을 못하고 다른 페이지로 가는 링크를 클릭할 확률 - 논문

PR(A) = (1-d) + d(PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))

d=1, 수식 그대로가 A의 PageRank 값

d=0, 모든 페이지가 1이 되므로 의미가 없어짐

d는 0~1 사이값

보통.. d는 85%, 0.85 

논문에 따르면, "모든 웹페이지의 페이지랭크 값을 합산하면 1이된다."고 하는데..

수식에 모순이 있음

d=1일때, 하나의 페이지에 대한 페이지랭크가 최대 1이 될 수 있으므로, 전체 페이지에 대한 페이지랭크값은 N.

위키피디아에서 수식을 정정

PR(A) = (1-d)/N + d(PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))    // 전체 페이지수로 한번 나눔

출처 https://sungmoon.files.wordpress.com/2012/08/screen-shot-2012-08-25-at-4-46-19-am.png

책에서는,

dampen Factor를 85%로 계산(0.85)

PR(A) = 0.15 + 0.85 * ( PR(B) / link(B) + PR(C) / link(C) + PR(D) / link(D) )

PR(A) = 0.15 + 0.85 * ( 0.5 / 4 + 0.7 / 5 + 0.2 / 1 )        // 페이지랭크는 C가 젤 높은데, 링크는 A 한군데만 하기때문에 기여도가 젤 높음

PR(A) = 0.15 + 0.85 * ( 0.125 + 0.14 + 0.2 )

PR(A) = 0.15 + 0.85 * 0.465

PR(A) = 0.54425

함정,

페이지링크 값을 가지지않은 모든 페이지들의 페이지랭크 값들은??

> 모든 페이지랭크 값을 초기에 임의의 값으로 지정한 후 여러 번 반복 계산

> 반복을 할 때마다 각 페이지랭크값은 실제 페이지랭크값에 점점 가까워 지게됨

> 약 20회 정도

페이지랭크는 시간이 많이 걸림, 검색어와 상관없이 진행이 됨.

> 모든 URL에 대한 페이지 랭크를 사전에 계산

> 이 값을 테이블에 저장하는 함수 생성

calculatepagerank(x, y)

: 매번 수행될 때 모든 페이지랭크를 재계산

> 모든 페이지에 대한 페이지랭크값을 1로 초기화

> 모든 페이지URL에 대해 루프를 돌며 모든 유입링크에 대한 페이지랭크 값과 전체 링크 수를 얻는다.

>  예제 Database에서 어떤 페이지가 가장 높은 페이지랭크 값을 가지는지 확인하려면 데이터베이스에 직접 쿼리

>  "Main Page"가 젤 높은 페이지랭크를 가짐

> 정규화 함수 부분 추가

> weights 리스트를 수정하여 페이지랭크를 포함시키면 좀 더 향상된 결과를 얻을 수 있음

# 링크텍스트 활용

: 페이지의 링크들의 텍스트를 사용하여 페이지의 적합도를 판단

-> 링크를 가진 페이지 자체보다 페이지에 대한 링크에 대한 설명등을 참조(개발자들이 링크하려는 것들에 대한 간략한 설명을 링크에 넣기 떄문)

코드

> 검색 수행 시, 제공된 단어 ID들의 목록을 새로운 인자로 가짐

linktextscore(x,y,z)를 searccher안에 추가

> wordids 안에 있는 모든 단어들에 대해 루프를 돌면서 이 단어들의 링크를 찾기

> 링크의 목적지가 검색결과 안에 있다면, 링크소스의 페이지랭크 값을 목적지 페이지의 최종 점수에 더하기

검색 단어를 포함하고 있는 중요한 페이지로부터 링크를 많은 받은 페이지가 더 높은 점수를 가짐

검색 결과 내의 대부분의 페이지들의 경우 정확한 텍스트를 가진 링크가 없어 점수0을 가짐

> 링크 텍스트 랭킹을 반영하기 위해 weights 리스트에 코드를 추가

(1.0, selt.linktextscore(row, wordids))

모든 지표들의 표준 가중치는 없음. 

주요 검색 사이트들도 검색 결과 랭킹방법은 수시로 바꿈

: 사용할 지표와 제공할 가중치는 구축하려는 응용에 따라 크게 달라짐

Spring 2.5

- OS에 디펜던시가 큼

- AIX(IBM), ADF와 함께 쓸 때, 오동작을 일으키기도 함

싱글톤, 멀티쓰레드 환경에서 시리얼라이제이션을쓰면 ... ?

시리얼라이제이션

: 분산처리할때

serialized UI 라는 객체가 있음

- 자바에서 시리얼라이즈라하면,

Stream(byte화하는 것) 중 I/O계열에 있는 애들중

ByteArrayInputStream 등등 많은데, ObjectStream이란놈이있는데, 

- 엔드포인트에서 데이터 In/out할때 serialization 

=> 자바에서 Stream으로 데이터를 보낸때, DTO로 매번 감싸는 것도 문제이므로 오브젝트 자체에 Serial ID를 부여한다. 이런 방식을 일반적으로 자바에선 Serialize이라고 한다.

(de-Serialize, static변수는 적용할 수 없음)

- 스프링의 싱글톤과 VM측면에서의 싱글톤은 다른 의미이다.

# Stress 

1. 이용자수 (회원수) 100%

2. 동접자수 10%

3. 동시사용자수 10%

: 회원수가 100명일때, 동접자수가 10%인 10명이고, 동시사용자수가 10%인 10명일때, 처리시간이 1초정도? 

# 좋은도구, 시스템, 

코드 스니핏 - 이클립스에서 개발환경을 자동화해준다(자바 리플렉션, 인트로스펙션)

인트로스펙션 : 자바소스를 완변하게 분석해주는 툴 -> AST (Abstract Syntax Tree, AST view)

소스코드를 추상화 트리로 만들어 줘서 자바소스를 완벽하게 분해를 한다. 

클래스 정보를 로드를하면 메소드, 변수, 모든 정보를 알아낸다.(인트로스펙션)

문자열로부터 자바객체로 만들어낸다 (리플렉션)

# LRCP , 2PC

자바의 XA드라이버를 사용하지 않아도 요즘에나오는 WAS들은 2PC를 제공해주면서(WAS의 고급기술)분산트랜젝션을 제공할 수 있음

# 인프라개발자

EA - 

BA : domain, 비지니스아키텍트

TA : 테크니컬 아키텍트, System 구성

DA : Data 아키텍트, 

AA > SA : 소프트웨어 아키텍트, 

(AA가 더 넓은 영역을 커버하고있음, 가령 서울시를 설계한다면, SA는 건물의 내부를 설계)

XaaS -     

IaaS 

PaaS

SaaS

DaaS

인프라개발자 ...... 하드웨어 개발, 시스템 관련한 개발, 

: 레드햇 등에서 하드웨어 플러그인등 미들단에서 OS를 풍부하게해주는 개발을 하는데, 완전 인프라단은 아니지만, 인프라 개발자 범주에 들 수 있음.

----------------------------------------------

java 엔지니어 공부순서

1. 자바패턴,

2, 스프링소스까기(2달정도만 해도.. 스프링 고수가됨)

3. JDK소스까고, JavaDOC 보기

# 애플리케이션

: EPOT(e-portal:온라인포털)

$ 아키텍처 설계

> 레이어 - 각 레이어 별 적용 기술 요소 매핑

> 프로그래밍 규약

- 컴포넌트 : 스스로 동작할 수 있는 최소한의 단위

- 유틸리티 : 유틸리티 성 비지니스, 공통적으로 사용, 달력같은...

- 기능분류 : 퍼사드... 

- domain = DO = TO ...

> 코드 컨변션

- 이클립스 > preference > java > code style

  a. organize imports 

  b. code templates

  c. 카피라이트 자동화

...

> 개발표준, 메소드 접두어 명명규칙

# 컴포넌트 설계/분류

# 컴포넌트 분류

# 웹서비스 설계

# intel DPDkP의 해결책

# Linaro ODP

: LNG에서 플랫폼에 상관없는 네트워킹 데이터 평면에 API를 제공하기 위해 오픈소스로 공개

- 사용자단에서 한개의 프로세서로 동작, 최소한의 API를 호출

- ODP API : 커널의오버헤드를 야기하지 않고, 가용한 하드웨어의 특성을 사용하여 DPA를 실현하고자 함

  (= SDK API)

- 하드웨어 의존적인 SDK API 호출을 배제하지 않음, 플랫폼에 상관없는 소스레벨의 호환성을 제공해주지 못할 수 있음

- 데이터 플레인 응용을 지원하는 플랫폼

- 리눅스 API를 사용하는 리눅스 사용자 평면제어 또는 관리평면 기능을 구현한 응용프로그램과 병렬처리 가능

# Linaro ODP 추상화된 논리적 패킷처리 구조

SW - 소프트웨어 블록

HW - 대부분 하드웨어 블록에 의해 수행되는 부분으록 간주하지만, 소프트웨어에서 수행될수도 있음

빗금 - 낮은 액세스 지연을 가지는 펌웨어와 같은 하드웨어에서 아주 가까운 소프트웨어에 의해 수행되는 기능

1. Packet Input 블럭 - 물리적 입력단의 패킷 포트를 추상화

2. Pre-Processing - 물리 인터페이스와 동일한 속도로 처리, 버퍼 풀의 선택 및 첫번째레벨의 congestion 제어를 위한 패킷분류 수행

3. Input Classification - 구별된 트래픽 플로우 분석 및 분류, 큐에 배정, 분석결과 메타데이터를 추가

4. Ingress Queuing - 실제 페이로드에 대한 메타에이터(descriptor)들의 큐를 제공, 큐에대한 descriptor들은 HW장비 또는 SW에서 도착

5. Delivery/Scheduling - 동기화된 SW/HW 인터페이스, 동작 스케줄링과 한일 수신점에 대한 다수개의 프로세서 코어에 대한 로드밸런싱 수행

* 스케줄러큐 - 우선순위 설정, 큐의 상태, CPU상태를 참조

6. Accelerator - 비동기적 큐기반의 인터페이스에 대해 암호화 또는 압축등 특수 목적 처리를 수행

7. Co-processors - Accelerator과 유사, SW에 대한 동기화된 인터페이스를 가지고 빠른 동작을 수행

8. Egress Queueing - 출력 포트를 향해 동기화된 인터페이스를 제공

* 각각의 큐는 논리적으로 매핑, 설정된 QoS기능을 선택적으로 수행

9. Post Processing - 패ㅣㅅ을 출력포트를 위해 스케줄링, 패킷이 나가면 패킷 버퍼를 해제, 패킷 checksum등 inline가속 기능 제공

10. Packet Output - 물리 출력 포트에대한 인터페이스 제공