Skip to content

댓글 데이터를 활용한 분석

소셜 미디어 댓글에는 컨텐츠에 대한 구독자들의 반응을 찾아볼 수 있는 구체적인 정보들이 숨어있다. 댓글 분석 기술의 연구 분야로 Short Text Analysis는 최근 많은 연구가 진행되는 연구 분야 중 하나 이다. 최근 웹에서 생성되는 텍스트 중 높은 비율로 댓글과 같은 Short Text가 차지하고 있기 때문이며, 실제 서비스에 적용되는 사례가 많기 때문이다.

Short Text 분석은 기존에 사용하던 단어 빈도수 기반의 분석 기술로는 깊은 인사이트를 찾기 힘들다.

검색엔진 기반의 분석 기술들은 단어의 발생 빈도와 문서 간의 유사성을 활용해 키워드의 중요성 및 연관성을 추론한 후 해당 텍스트를 시각화 하거나 검색 어플리케이션을 활용해 결과값을 출력한다. 이 방법을 사용하기 위해서는 다음과 같은 가정이 필요하다

  • 문서 간의 연관성을 구할 수 있으며 연관성이 충분히 Reliable 해야 한다.
  • 중요한 키워드는 텍스트상에 반복적으로 많이 발생해야 한다.
  • 문맥과 고려하지 않고 분석을 하더라도 충분해야 한다.

만일 비교사학습(Unstructured Machine Learning) 방법을 사용한 클러스터링 기술을 사용한다 하더라도 유사한 문제가 발생할 수 있다. 결국 클러스터링 기법을 사용하기 위해서도 데이터의 양이 매우 중요해지기 때문이다.

Short Text의 특징을 정리하면 다음과 같다.

  • 단어들의 발생 빈도가 Sparcity 하다.
    • Sparcity함은 짧은 텍스트간의 연관도를 추론하기 어렵게 한다.
  • 분석 텍스트의 문맥을 파악하기 힘들다.
    • Short Text 자체적으로 문맥을 유추할 수 없다.
  • 분석 타겟 데이터만으로 텍스트를 이해하기 어렵다.
    • Short Text에 포함된 텍스트는 해당 도메인과 연결된 의미로 사용되는 단어들이 많아 그 자체적으로 의미성을 부여하기 어렵다.

Short Text를 분석하는 최신 연구

  • 지식베이스 활용
    • 짧은 텍스트에 관한 정보를 잘 만들어진 기존 지식기반의 데이터를 학습해 미리 이해할 수 있도록 한다.
  • Distributed Representation
    • 문서 빅데이터를 활용해 단어의 의미(Sematic)를 보유한 벡터로 표현할 수 있도록 학습한다.

Short Text 분석 관련 어플리케이션과 어플리케이션의 해결방법

  • 챗봇 – 사용자의 짧은 요청을 이해하는 솔루션
    • 사용자의 지난 요청을 함께 분석해 문맥을 유추한다.
    • 사용자에게 요청방법을 가이드한다.
  • 분류기
    • 사용자의 텍스트를 사전 학습한 데이터를 활용해, 분류 결과를 출력한다.
    • 도메인 별로 별도의 학습데이터를 활용한다.

 

그렇다면 댓글을 분석하기 위해서는 다음과 같은 부분이 필요하다.

  • 도메인에 대한 이해
  • 사전 학습데이터 구축
  • 어플리케이션에 적합한 기술의 조합

결국 댓글 분석은 분석 기법의 문제라기 보다 도메인별 데이터, 그리고 어플리케이션에 적합한 학습 모델 구축이 중요한 시사점이 되는 것이다.

파이썬 서버 셋업하기(Python Server Setup) feat. CentOS7, Anaconda2, Supervisor, Nginx

파이썬 서버를 간단하게 셋팅하는 방법을 공유합니다. 데이터 분석용 모듈을 다수 포함하고 있는 Anaconda2 버전의 파이썬을 사용하였고, 프로세스 관리를 위해 Supervisor를 사용 하였습니다. 그리고 웹서버로 Nginx를 사용하였습니다. 본 셋팅은 가장 기초적인 상태의 셋팅이지만, 향후 다양하게 운영할 수 있는 여지를 포함하고 있기 때문에 소규모의 상용 서비스에도 활용이 가능합니다.

  1. Build new VM
    1. AWS 기준으로 EC2 Market Place에서 CentOS 검색하시면 CentOS7이 가장 상위에 검색됩니다.
    2. 본 포스팅은 nano 사이즈(ssd 8GiB)로 테스트시 잘 동작하였습니다.
    3. 기본적인 AWS 셋팅은 생략하겠습니다. (ssh key, security group등)
    4. Connect to server
      chmod 500 key_filename.pem 
      ssh centos@00.00.00.00 -i key_filename.pem
  2. Install Anaconda2 (version 4.3.0 64bit)
    1. Install bzip2
      sudo yum install bzip2
    2. Download Anaconda2 Installer
      curl -O https://repo.continuum.io/archive/Anaconda2-4.3.0-Linux-x86_64.sh
    3. Install Anaconda
      bash Anaconda2-4.3.0-Linux-x86_64.sh
      1. 기본셋팅은 계속 Enter 치셔도 됩니다.
      2. 경로가 존재할 경우 설치되지 않습니다.
      3. 마지막에 경로설정 할때 yes 하셔야 정상적으로 경로가 지정됩니다. (엔터로 넘기시면 아나콘다버전으로 경로지정이 자동으로 되지 않습니다.)
    4. Reconnect to server for adopting PATH
      1. 파이썬 경로 설정 적용을 위해 재접속 합니다.
    5. Anaconda version update
      1. Anaconda 버전 최신화를 위해 업데이트 합니다.
        conda update anaconda
  3. Install Supervisor
    conda install -c anaconda supervisor
  4. Install Nginx
    1. Install Nginx
      sudo yum install epel-release
      sudo yum install nginx
    2. Registering proxy_pass on configuration file of Nginx
      1. Edit configuration file
        sudo vi /etc/nginx/nginx.conf
        location / {
            proxy_pass http://127.0.0.1:5000/;
        }
    3. Starting Nginx Server
      sudo systemctl start nginx.service
    4. Open the inner proxy network settings
      sudo setsebool -P httpd_can_network_connect true
  5. Install Git
    sudo yum install git
  6. Download python source code
    1. Git 으로 소스코드를 받아오기
      git clone "path of git repository"
    2. Install packages of python project
      python setup.py install
  7. Run python server using Supervisor
    1. Configuration
      1. Use sample configuration file
        1. Copy sample file
          cp anaconda2/lib/python2.7/site-packages/supervisor/skel/sample.conf \
          supervisord.conf
        2. edit file paths
          1. log, pid, etc..
    2. Supervisor에 서비스 등록하기
      1. Edit configuration file
        [program:sample]
        directory=/home/centos/sample
        command=python sample.py
        autostart=true
        autorestart=true
      2. Start supervisord daemon
        supervisord -c supervisord.conf
      3. Terminate supervisor for restart
        ps -ef | grep supervisord | grep -v grep \
        | awk '{print $2}' | xargs kill -9

 

cron scheduling format (cron 표현법) for spring @Schedule

@Scheduled(cron = "0 0 0 0 0 0")

위와 같은 방식으로 사용할 때 cron 표현법을 사용한다.

6개의 표현과 띄어쓰기로 이루어진 표현 – “0 0 0 0 0 0”

순서대로 설명해보자.

첫째 : 초를 표현한다. * – 매초, */5 – 5초마다, 0 – 0초에

둘째 : 분을 표현한다. * – 매분, */5 – 5분마다, 0 – 0분에

셋째 : 시를 표현한다. * – 매시, */5 – 5시간마다, 0 – 0시에

넷째 : 한달 중에 날짜를 표현한다. * – 매일, */5 – 5,10,15,20,25,30일에, 1 – 1일에, 1-10 1일에서 10일사이에

다섯째 : 달을 표현한다. * – 매달, */2 – 2월, 4월…12월(짝수달), 12 – 12월

여섯째 : 요일을 표현한다. * – 매일, MON-TUE – 월요일에서 화요일

 

이제 예시를 들어보자

5분마다 실행하기 : 0 */5 * * * *

업무일 (월 – 금) 의 점심시간 (12pm) 마다 실행하기 : 0 0 12 * * MON-FRI

매일 아침 9시부터 9시30분까지 5분간격으로 실행하기 : 0 0-30/5 9 * * *

 

  • Tip: 스프링에서 CronSequenceGenerator 를 쓰면 더 쉬울 수 있다.

Tips for Class Connection Representation using PlantUML

Distinguishing connecting representation.

Extension <|-- extension symbol
Composition *-- composition symbol
Aggregation o-- aggregation symbol

Normaly developers used to 3 types of line such as Extension, Composition and Aggregation for representing connectivity of classes.

For detail, let me explain each ones.

Extension is most simple. If you extend class using some interface or some abstract class then use Extension line that directed to upper interface or class.

Composition and Aggregation is little bit similar but I can explain differencies few point. Composition is used when class was directly used inside of directed class, that means that class has the property of other class. Aggregation is used when class was used to arguments of some functions or constructors. Aggregation doesn’t used for declaring inside of targeted class.

Let me show with examples.

Extension

class A2 extends A {
}

A2 -|> A

Composition

class A {
    B b = new B();
    B get(){
        return this.b;
    }
}

B -* A

Aggregation

class A {
    void use(B b){
        b.use();
    }
}

B -o A

Three types of connectivity can be explanin most of case the class structure, but if we need to some extended explaination, use note representation. That will be more clear then use other type of connection representation.

AWS S3 를 활용한 데이터 파일 관리 with Java Source Code

Spring Configuration File

@Configuration
@EnableContextResourceLoader
@EnableContextCredentials(
        accessKey = "",
        secretKey = "",
        instanceProfile = true)
@EnableContextRegion(region = "us-east-1")
public class AWSConfig {
}

 

Upload using InputStream

TransferManager tm = new TransferManager(amazonS3);
ObjectMetadata metadata = new ObjectMetadata();
byte[] contentBytes = IOUtils.toByteArray(inputStream);
Long contentLength = Long.valueOf(contentBytes.length);
metadata.setContentLength(contentLength);
Upload upload = transferManager.upload(bucketName, filename,
        new ByteArrayInputStream(contentBytes), metadata);
return upload.waitForUploadResult();

 

비용

40GB 당 약 $1 – 여러 아마존 통합기능을 고려했을 때, 충분히 저장소로 고려해볼 만한 비용

Java Spring DDD (Domain Driven Design) 설계 방법론 (2) – Project Packaging

프로젝트를 페키징 하는 것은 향후 유지보수화 소수 가독성을 위해 잘 고려될 필요가 있다. 각 레이어별 기능을 정의하는데 Package 단위로 정의하게될 가능성이 높기 때문이다.

일반적으로 스프링 프레임워크를 사용해 자바 프로젝트의 프로젝트 패키지를 설계할 때, 도메인 레이어의 핵심 비즈니스 로직을 포함하는 domain, 핵심 서비스 기능을 구현하는 application, domain과 application 패키지의 백업 기능을 구현하는 infrastructure, API 등 핵심 서비스 인터페이스를 구현하는 interfaces 로 구분할 수 있다.

예제 1.

  • domain
    • model
    • service
  • infrastructure
    • config
    • service-name-on-domain
  • interfaces
    • controller
    • facade
  • application

domain 패키지 부터 보면, 크게 저장 데이터를 제어하는 model 패키지와 기능을 제어하는 service 패키지로 나누어 볼 수 있다. model 같은 경우 @Entity 와 같은 hibernate class를 직접 넣어주거나, Domain class를 넣어 domain 기능을 class에 넣어주고 실제 디비 데이터는 infrastructure에서 저장해주는 방법을 쓸 수 있다. service 패키지는 DDD 설계중 서비스 파트 Interface들이 들어갈 수 있다.

infrastructure 패키지에서는 spring의 @Configuration 파일들을 넣어주고, Spring의 Injection 기능을 사용해 domain layer나 application layer에 존재하는 Interface의 실제 구현체들을 넣어주고, 해당 구현체 기능을 구현한다. 이때 패키지명을 각 service나 application의 이름을 활용해 infrastructure에서 구현하는 interface가 어떤 것인지 패키지명으로 확인할 수 있도록 하면 좋다.

interfaces 패키지에는 스프링의 controller와 각동 데이터 제어를 위한 facade를 패키지명으로 사용할 수 있다. controller의 기능인 validation 이나 view mapping, object converting 등을 interfaces 패키지에 넣어주자.

마지막으로 application 패키지의 구조는 각 기능에 맞게 다양한 형태로 설계 가능하다.

이렇게 크게 4가지 패키지로 나누었는데 이 포스트에서 제시한 방법은 수년간 DDD 설계로 서비스를 구현하면서, 복잡도 측면이나 기능측면에서 효율적인 형태라고 생각한 방법이다.

호그댁 공략 (4) – 클래시 로얄(Clash Royale)

  1. 왜 호그댁인가
  2. 호그댁의 공격 메커니즘
  3. 호그댁 조합법
  4. 상대 댁별 상대법

이 포스트에서는 대표적인 상대 댁별 호그댁 상대법을 설명한다. 주요 수비 및 공격 패턴을 알려줘 어떤점을 주의하고 할 때 승률이 올라가는지 이 포스트를 통해 확인할 수 있다.

이 포스트에서 설명할 상대 댁은 자이언트댁, 로자댁, 광부댁, 라바댁이다.

1. 자이언트 댁

자이언트 댁은 상성상 호그댁이 6:4 정도로 유리하다고 볼 수 있다. 기본적으로 타임어텍시 자이언트는 타워에 붙는 속도가 느리기 때문에 호그가 먼저 타워를 때릴 수 있기 때문이다.

자이언트댁을 상대하는 기본 매커니즘은 선공격 후수비 이다. 일단 자이언트를 들고 있다면 함께 들어갈 수 있는 프린스, 머스킷, 미니언 등을 함께 댁에 준비하고 있을 텐데, 방타가 없다면 호그찌르기를 막기 쉽지 않다. 일단 호그로 먼저 상대 타워에 딜을 넣어주면 상대가 유닛을 활용해 막고 자이언트를 앞세워 들어올 것이다. 이때 얼음골램등으로 맷집을 넣어주고 방타를 활용해 천천히 적 유닛을 잡으면 된다. 가장 효과적인 방타는 대포이며, 자이언트는 속도가 느리기 때문에 방타에 취약하다.

주의해야할 점은 마법을 섣불리 사용하지 말아야 한다는 점이다. 자이언트댁을 저코스트로 막을 수 있는 이유중에 하나가 마법을 사용해 함께 들어오는 유닛들을 처리할 수 있다는 점인데, 마법이 빠졌을때 상대의 한타를 막을 수 없어지는 상황이 올 수 있다.

팁 중 하나는 자이언트 댁에 속도가 비슷한 바바리안을 같이 쓰는 경우가 많은데, 이때 찌르기시 바바리안을 예측해 마법을 넣어줄 경우 상대에게 큰 피해를 줄 수도 있다.

2. 로자 댁

로자 댁은 기본적으로 자이언트 댁과 비슷하나, 방타 사용을 잘해야 한다. 로자는 먼곳에서 공격해 방타를 취약하게 만드는 경우가 많기 때문에, 로자라는 것을 인지했을 경우 모든 신경을 로자 막는데 써야한다.

로자댁을 상대하는 기본 매커니즘은 선 로자방어 후 역습이다. 로자를 잡으면서 남은 유닛과 호그를 함께 투입해 적 타워를 공략한다.

주의해야할 점은 항상 로자 뒤에 들어오는 미니언, 얼법등을 항상 고려해 맷집용 수비병력을 넣어주거나 마법으로 뒤에 들어오는 유닛을 끈어주는게 좋다는 점이다. 섣불리 미니페카같은 유닛을 내었는데, 미니언등에의해 정리되고 타워는 타워대로 공격당하고 하면 역습이 불가능해 진다.

3. 광부 댁

소개할 상대 댁 중에 가장 까다로운 댁이다. 저코스트인 광부로 타워를 공략하고 수비에 효율적인 카드를 사용해 호그를 막아주는 전략을 많이 사용하기 때문에 상대적으로 타워를 공략하기 힘들다.

광부댁을 상대하는 기본 매커니즘은 광부에 타워공략을 당하지 않는 것이다. 최대한 광부의 도착위치를 예측해 타워 대미지를 최소화하면 게임을 용이하게 가져갈 수 있다. 공격 방법은 광부 수비 후  공격을 기본으로 생각하면 된다. 고려해야할 점은 상대가 광부를 사용했을 지라도, 코스트가 충분한 상황이기 때문에 수비할 병력 사용이 용이하다는 점을 고려해야한다. 조합을 갖춰 찌르는 것을 항상 고려하자.

주의해야할 점은 광부 짤짤이를 무시하면 안된다는 점이다. 마지막에 로켓등으로 마무리 되면 너무 안타가워진다.

4. 라바 댁

라바 댁은 상대하기 가장 단순한 댁중 하나이다. 호그와 상관없이 라바만 잘 막으면 된다. 일단 상대가 라바를 사용하는 순간 호그를 사용해 찌르자. 라바 막는 것은 얼음골램, 감전, 미니페카, 머스킷 등으로 쉽게 제압할 수 있다.

기본 매커니즘은 라바에 공략당하지 않는 것이다. 호그로 일단 찌르고, 라바를 최대한 효율적으로 막자. 이 과정의 반복이고, 어느순간 적 타워는 없고 내 타워는 멀쩡한 모습을 볼 수 있다.

주의해야할 점은 라바를 수비하기 위해 유닛을 몰아 넣었다가 번개나 파볼에 다 죽으면 타워도 함께 날아간다. 적 마법을 항상 함께 고려해 수비하자.

 

호그댁은 어느댁을 상대하든 불리하진 않다. 운영만 잘하면 비슷한 레벨은 어떤 댁이 와도 이길 수 있다. 포기하지 말고 상대댁 수비 방법을 잘 고민해 호그로 승리를 쟁취하자.