빅데이터 분석에 오픈 소스 활용 시 예상 문제점

[Architecting 측면]
    1) 다양한 오픈 소스, 상용 솔루션이 존재하여 기반 기술이 복잡하며 요구 사항에 대한 아키텍처 선정이 어렵다.
    2) 적절한 하둡 버전 선택 및 최적화가 어렵다.
    3) 요구 사항에 적합한 오픈 소스 선정이 어렵다.
        – FlumeOG vs. FlumeNG
        – 검색 플랫폼 (katta, solr, elasticsearch)
        – NoSQL (HBase, Cassandra, MongoDB)

[기술 재재화 측면]
    1) 자체 개발 역량으로 오픈 소스에 대한 분석 및 노하우 축적이 필요하다. (숙련된 개발자 필요)

[데이터 수집적인 측면]
    1) 기본 제공 데이터 수집 모듈 기능이 부족해서 필요 모듈을 직접 개발해서 사용해야 한다.
    2) 데이터 수집 관리 시 직관적이지 않고 기본 제공되는 UI 또한 관리하기 어렵다.
    3) Flume의 데이터 중복이나 Chef의 설정 파일 sync 문제 등 수집 플랫폼 운영에 취약점이 존재한다.
    4) 하나의 데이터 소스로 다양하게 활용할 수 없다.
    5) 외부 데이터 수집 기능이 제공되지 않아서 소스 별 추가 개발이 필요하다.

[데이터 분석 및 활용적인 측면]
    1) 저장된 데이터를 이용한 실시간 분석 취약하여 Storm 등 오픈 소스 라이브러리를 활용하여 직접 개발이 필요하다.
    2) 오픈소스에서 기본 제공되는 UI로는 운영이 매우 어렵다. 필요한 관리 UI 개발이 필요하다.
    3) 로그와 같은 대용량 데이터는 과거 데이터 검색 시 비용이 증가하며 검색 시스템 구성 또한 어렵다.
    4) 많은 메모리 사용으로 데이터 손실이 발생하기도 하며, BI/DW 처리 데이터의 정합성 보다는 대용량 트랜드 분석에 적합하다.

[관리적인 측면]
    1) 각 오픈 소스별로 독립적인 관리 기능이 제공된다.
    2) 장애, 서버 상태 등에 따른 알람 체계가 부족하다.

카테고리: 빅데이터 플랫폼 | 댓글 남기기

ElasticSearch in hadoop

Hadoop 기반의 저장소 (HDFS)에서의 검색 plug-in으로 ElasticSearch를 이용할 수 있다.

하지만, 데이타가 많아 지면서 검색으로 인해서 서버에 load가 발생하게 되고 이를 해결하기 위해서 실시간 검색을 위한 index과 전체 검색을 위한 index 두 개의 cluster를 유지해야 한다.

  • 실시간 검색 – 기본 ElasticSearch를 사용하며 최신 데이터에 대해서  정의하고 관리한다.
  • 전체 데이터 검색 – 읽기 전용으로 HDFS를 통해서 검색한다.

 

카테고리: 빅데이터 플랫폼 | 댓글 남기기

Flume 기본 모듈의 취약점 보완 plug-in

서비스 사용성 분석을 위해서 로그 수집으로써 Flume을 많이 사용하고 있지만, 실제 기본 모듈 이용 시 예상하지 못한 문제들이 많이 발생하게 된다. 이를 보완하기 위한 Plug-in들을 정리하면 다음과 같다.

  • Checkpoint tailer: agent 재시작 시 데이터 중복 전송방지
  • ContextChangeListener: Agent 설치된 서버의 Web Context의 변경 사항 모니터링
  • RegExpDecorator: Regexp 기반의 파싱
  • WebLog Decorator: 일반적인 표준 웹 로그에 대한 파싱 처리
  • PipelineSinkDecorator: 하나의 로그 Event에 대해 여러 개의 Sink를 pipeline으로 처리하게 하면서 master/slaves sink 지정
  • HDFS Rolling Sink: 시간 주기 또는 레코드 건수 단위로 Hadoop File을 rolling 하면서 저장하는 Sink
  • HBase/Hive/ElasticSearch Sink: HBase/Hive/ElasticSearch 등으로 로그 데이터를 저장하는 Sink
카테고리: 빅데이터 플랫폼 | 댓글 남기기

채팅 앱의 4가지 특징

분석해 본 4가지 채팅 앱 (즐톡, Intalk, 채팅매니아, 1Km)의 공통점은 1:1 대화 기반으로 서비스 되며, 다음과 같이 각기 다른 방법을 이용해서 1:1 대화를 유도하고 있다.
   1) 지역별 대화
   2) 관심사 기준 추천 기반의 대화
   3) 사용자 중심의 대화
   4) 거리 기반의 대화

 

1. 즐톡

“즐톡”은 예전 천리안이나 나우누리에서 채팅하던 기억이 난다.
지역별로 몇개의 대화방이 존재하고 선택해서 Join할 수 있다. 하지만 Join해서 보면 PC기반의 채팅과는 많이 다른 느낌이다. PC처럼 화면이 넓지 않기 때문에 대화방은 입력하지 않는다. 지역별로 제공된 대화방에 Join하면 Join한 사용자 대화명이 Listup되고 대화명을 보고 쪽지나 대화 신청을 통해서 1:1 대화를 한다.

그리고 재밌는 점은 서비스에서 제공하는 “장터”이다. “기타”를 포함해서 12가지 Category를 제공하고 사용자가 등록해서 쪽지를 통해서 Contact 한다. 정말 재미있고 다양한 물품이 많이 등록된다.

2. InTalk

“인톡”은 5개의 지역 구분과 5개의 연령, 22개의 관심사가 한 화면에 Listup되고 사용자는 32개의 항목 중에서 다중으로 선택하고 그 선택과 비슷한 사용자와 매치되는 다른 사용자를 찾아준다.

이 채팅앱의 아쉬운 점은 아이템에 “Male, Femail”이 없어서 동성 매칭이 잦다. 성별에 대한 선택이나 표기가 없어서 사용하는 동안 추천된 대화 상대가 대부분 성별을 물어보는 불편함이 있었다.

3. 채팅매니아

“채팅매니아”는 접속하자마자 1:1 기반의 채팅임이 확~ 느껴진다.  접속을 하면 남녀 모든 접속자가 Listup된다. 그리고 지역별, 연령별, 지역별 접속자 선택이 가능하다. 이 지역과 연령은 본인의 Profile에 설정된 것이다. 이 사용자들에게 쪽지를 보낼 수 있고, 대화방에  읽었는지 안읽었는지 표기된다. 이 대화방에서 바로 1:1이 진행되는 것이다.

 4. 1Km

 “1Km”는 접속하자마자 1:1 기반의 채팅임이 확~ 느껴진다.  (채팅매니아에 거리 기반이 추가된 느낌~ ㅎㅎ) 친구신청이나 대화등 모든 Action을 하기 위해서는 사진 등록이 필요하다. 대화의 친밀이나 건전성을 사진으로 잡은 것이다. 그래서 사진에 대한 Filtering이 중요할 것 같다.

카테고리: 채팅 앱 개발하기 | 댓글 남기기

/bin/rm : “인수 명단이 너무 김” 해결 방법

다음과 같이 1000개씩 나누어서 삭제가 가능하다.

$ ls | xargs -n1000 rm -f

혹은

$ echo * | xargs rm -rf

카테고리: IT일반 | 댓글 남기기