Dev Story..

이번 회사에서 팀 프로젝트를 진행하면서 실시간 분석 프로젝트를 하게 되었다. 

처음으로 알아볼 오픈소스 시스템은 Storm이다.

시간이 날때마다 공식 사이트 메뉴얼을 번역해보고자 한다. 아직 번역 실력이 허접함..

Home(서문)

Storm is a distributed realtime computation system. Similar to how Hadoop provides a set of general primitives for doing batch processing, Storm provides a set of general primitives for doing realtime computation. Storm is simple, can be used with any programming language, is used by many companies, 

and is a lot of fun to use!

Storm은 분산 처리 시스템이다. Hadoop에서 제공하는 일반적인 기본 배치 프로세싱과 흡사하며, Storm은 실시간 처리를 제공한다. Storm은 간단하며, 다양한 언어가 지원되며, 많은 회사에서 재밌는 일에 사용하고 있다.

The past decade has seen a revolution in data processing. 

지난 10년간 데이터 처리는 많은 발전을 이뤄왔다.

MapReduce, Hadoop, and related technologies have made it possible to store and process data at scales previously unthinkable. 

MapReduce, Hadoop과 같은 기술들은 이전에는 상상도 할 수 없는 데이터양을 처리하고 저장하는 것을 가능하게 해주었다.

Unfortunately, these data processing technologies are not realtime systems, nor are they meant to be.

하지만 안타깝게도, 이러한 데이터 처리 기술은 실시간 시스템들이 아니였다.

There's no hack that will turn Hadoop into a realtime system; realtime data processing has a fundamentally different set of requirements than batch processing.

Hadoop은 실시간 처리보다는 배치 처리기술에 가까웠다.

However, realtime data processing at massive scale is becoming more and more of a requirement for businesses. 

점점 더 실시간 처리 기술은 사업에서 필요한 기술이 되었다.

The lack of a "Hadoop of realtime" has become the biggest hole in the data processing ecosystem.

Hadoop의 실시간 처리의 공백은 점점 더 커져만 갔다.

Storm fills that hole.

Storm은 이 공백을 채워준다.

Before Storm, you would typically have to manually build a network of queues and workers to do realtime processing. 

Storm 이전에 기술들은 대부분 실시간 처리를 위한 네트워크 큐와 워커를 생성한다.

Workers would process messages off a queue, update databases, and send new messages to other queues for further processing. 

워커는 큐를 처리하고 DB를 업데이트하고 새로운 메시지를 앞 큐에 전달한다.

Unfortunately, this approach has serious limitations:

이 방식에는 심각한 한계가 존재한다.

1. Tedious: You spend most of your development time configuring where to send messages, deploying workers, and deploying intermediate queues. The realtime processing logic that you care about corresponds to a relatively small percentage of your codebase.

1. 따분함: 당신은 

2. Brittle: There's little fault-tolerance. You're responsible for keeping each worker and queue up.

2. 불안정성:

3. Painful to scale: When the message throughput get too high for a single worker or queue, you need to partition how the data is spread around. You need to reconfigure the other workers to know the new locations to send messages. This introduces moving parts and new pieces that can fail.

3. 확장의 불편함: 

Although the queues and workers paradigm breaks down for large numbers of messages, message processing is clearly the fundamental paradigm for realtime computation. The question is: how do you do it in a way that doesn't lose data, scales to huge volumes of messages, and is dead-simple to use and operate?

비록 큐와 워커 패러다임이 많은 수로 메시지를 분산되더라도, 실시간 처리를 위한 기본 패러다임은 완벽하게 수행되어야 한다. 여기에서 질문: 당신이라면 데이터를 잃지 않고, 큰 데이터를 어떻게 간단하게 사용하며 운용할 것인가?

Storm satisfies these goals. 

스톰은 이러한 목적을 만족시켜줄 것이다.

Why Storm is important(왜 스톰을 사용하여하는가?)

• Event Stream Processing is focused more on high-speed querying of data in streams of events and applying mathematical algorithms to the event data.
• Complex Event Processing includes event data analysis, but places emphasis on patterns of events, and abstracting and simplifying information in the patterns.

ESP(Event Stream Processing): 시간에 따라 변화하는 이벤트를 빠르게 분석할 수 있는 기술

CEP(Complex Event Processing): 다양하고 복잡한 이벤트를 분석할 수 있는 기술

CEP vs ESP

CEP와 ESP를 다른 듯 같은 기술로 다룹니다. CEP기술은 1980년후반부터 분산환경하에서 시스템들이 발생하는 이벤트들을 분석하기 위해 등장하였습니다. 반면 ESP는 1990년대 중반 정도 DBMS업체들을 중심으로 실시간 데이터를 분석하기 위하여 Continuous Query기술을 검토하여 시작하였습니다. ESP는 시간의 경과에 따라 변화하는 이벤트들의 집합인 Stream을 빠른 속도로 분석하기 위한 기술에 중점을 두는 반면 CEP는 다양한 장소에서 발생하는 이벤트들의 집합인 Cloud에서 특정한 패턴의 정보를 추출하는 기술에 방점을 두고 있습니다.

때문에 ESP기술을 상업적으로 처음으로 적용한 대상이 알고리즘 트레이딩을 위한 마켓데이터 분석이었습니다. 반면 CEP기술은 BAM(Business Activity Monitoring)에 적용되었습니다.

기존에는 CEP와 ESP가 분리되어져 사용되어왔지만 근래 들어서는 CEP&ESP 복합적으로 사용되는 추세로 보인다.

오픈소스로는 Esper Engine를 예로 들 수 있다.

이럴 경우에는 stty columns 명령어를 통해서 늘려주면 된다 150이든 160이든 상황에 맞게 늘려주면 된다.

공감세미나 동영상 자료

http://readme.skplanet.com/?p=4605

플래폼 데이 강의 자료

http://www.platformday.com/2013/lecture.html

Storm과 Esper로 실시간 분석 샘플 사용기

http://mimul.com/pebble/default/2012/03/14/1331718971671.html

빅데이터 실시간 분석: 스톰과 에스퍼 믹스

http://blog.naver.com/ladekas?Redirect=Log&logNo=90156703919

빅데이터 어떻게 시작할 것인가?

http://subokim.wordpress.com/2013/10/18/how-to-start-bigdata/

트윗핑

http://tweetping.net

어떻게 하면 조직적인 학습을 효과적으로 진행할 수 있을까요 ?

조직적인 학습을  시작하기 좋은 지점은 바로 스탠드업 회의입니다

스탠드업 회의에서 ‘어제 한 일’, ‘오늘 할 일’, ‘이슈’를 팀원 들이

돌아가며 말하죠

프레임워크 설정 때문에 문제를 겪는 팀원이 있다면 스탠드업 회의에서

이 문제를 이슈로 제기합니다

물론 간단한 설정 문제라면 스탠드 업 회의가 끝나고 해결책을 아는 팀원이

문제를 겪는 팀원에게 해결책을 알려주겠죠

하지만 이런 간단한 설정 문제가 아니라 복잡하게 얽힌 문제고 해결책을 아는

팀원이 없다면 ‘조직적인 학습’이 필요한 시점입니다. 문제와 관련된 팀원들을

모두 화이트 보드에 모이도록 부탁하고 이슈를 제기한 팀원이 문제를 상세하게

설명합니다

설명이 끝나면 문제를 일으키는 근본 원인을 찾습니다. 근본 원인을 찾는 데 도요타에서 사용해서 유명해진 ‘왜’를 5번 반복해서 질문하는 방법을 활용합니다

근본원인을 찾았다면 근본원인을 해결하는 세 가지 대안을 생각해 봅니다. 물론

근본 원인을 해결할 방안이 명확하다면 굳이 대안을 세 개씩이나 만드는 것은

낭비지만 근본원인을 해결할 대책이 명확하지 않을 때 세 가지 대안을 생각함으로써 문제를 다양한 방식으로 고민할 수 있습니다

팀원들이 모여 각 대안의 장점, 단점을 비교해서 가장 적합한 대안을 선택합니다

대안을 평가할 때 말로 팀원들끼리 주고받는 것보다 화이트보드에 각 대안을 나열하고 대안마다 장단점을 기록하는 게 대안을 선택할 때 효과적입니다

이런 해결책의 진행상황은 매일 아침마다 진행하는 스탠드 업 회의에서 보고하기

때문에 팀원들이 쉽게 진척상황을 공유하고 이슈가 발생하면 공동으로 대응할 수

있습니다

스탠드업 회의에서 이슈를 제기하고 팀원들이 모여서 근본원인을 찾아 세가지를

생각하고 해결책을 실행하며 결과를 기록하는 과정은 팀원들이 공동으로 진행하는

팀 활동이기 때문에 이 과정에서 생성되는 지식을 팀 단위에서 자연스럽게 공유하고 습득합니다. 경험으로 체득하는 지식이기 때문에 굳이 기록이 필요하지 않을 듯하지만 프로젝트 팀 밖으로 지식을 전파하고 시간이 지나서 팀원들의 기억이 왜곡되거나 퇴색했을 때 참고하려면 이슈에서 해결책을 실행하는 과정과 결과를

기록으로 남겨야 합니다

기록이 필요하지만 그렇다고 많은 시간을 들이는 것도 옳지 않습니다 따라서 해결책을 수행할 담당자를 선정했다면 담당자는 이슈 내용, 근본원인, 대안 3가지와 선택한 해결책 등을 간략하게 적어서 회의실의 벽에 부착해 놓습니다     

1. du -h /폴더명: 디렉토리 별로 하위 디렉토리까지 확인

2. du -hs /폴더명: 하위 디렉토리까지 확인

3. du -s 폴더명: 해당 폴더의 용량

df -h: 파티션 별 용량 확인

이런 에러로 DML DDL명령이 안될때가 있다.

해당 DB가 lock 이 걸린경우 나오므로 해당 DB의 lock을 풀어주어야 한다.

예를 들어, EMP 테이블이라하면

dba 관리자 모드로 들어가서

sqlplus 디비접속(시스템계정으로)

쉘에서 -> sqlplus "/as sysdba"

이후

SQL> select a.sid, a.serial# 
from v$session a, v$lock b, dba_objects c 
where a.sid=b.sid and 
b.id1=c.object_id and 
b.type='TM' and 
c.object_name='EMP'; 

>>출력

SID SERIAL# 
--- ------- 
5        1 
6        1 

SQL> alter system kill session '5, 1'; 
SQL> alter system kill session '6, 1'; 

private function listFonts():void {

var fontArray:Array = Font.enumerateFonts(true);

var str:String = "Fonts: \n";

for(var i:int = 0; i < fontArray.length; i++) {

var thisFont:Font = fontArray[i];

str += "FONT " + i + ":: name: " + thisFont.fontName + "; typeface: " + 

thisFont.fontStyle + "; type: " + thisFont.fontType;

if (thisFont.fontType == "embeddedCFF"||thisFont.fontType == "embedded") {

str += "*";              

}            

str +=  "\n";

}

trace(str);

}

JSTL 리스트 카운트 표시

<c:set value="${list.size()}" var="listCnt"></c:set>

JSTL 조건문

<c:if test="${listCnt == listStatus.index }">

</c:if>

JSTL if, else 조건문

<c:choose>

<c:when test="${listCnt > 0}">

<c:forEach items="${list}" var="listItem" varStatus="listStatus">

listItem.title, listItem.content

</c:forEach>

</c:when>

<c:otherwise>

게시물이 없습니다.

</c:otherwise>

</c:choose>

  <c:choose>

        <c:when test="${results.totalAns ne 0}">

            <fmt:formatNumber value="${results.totalSec / results.totalAns }" maxFractionDigits="3" />

        </c:when>

        <c:otherwise>

            0

        </c:otherwise>

    </c:choose>

JSTL formatter

<fmt:parseDate  type="date" value="${listItem.regDt }" var="regDt" pattern="yyyyMMddHHmmss"/>

<fmt:formatDate value="${regDt}" pattern="yyyy-MM-dd HH:mm" />  

프로젝트들을 셋팅하고 있는데 아래와 같은 에러가 났다.

Access restriction: The type BASE64Decoder is not accessible due to restriction on required library 

확인해보니 이건 로컬 이클립스 셋팅에 나는거지 소스상에 문제는 없다. (rt.jar에 있는 특정 클래스 직접 접근하려고 했을 경우 나는 에러)

Window -> Preferences -> java -> Compiler -> Errors/Warnings 들어가서

Deprecated and restricted API 를 활성화 시켜서 Forbidden reference (access rules) 에 Error 로 체크되어 있는걸

Ignore로 바꿔주고 Apply 하면 된다.