Edward J. Yoon's Blog

빅데이터는 노하우의 내재화가 핵심이다.

2012-02-12T23:33:00.000-08:00

내가 지금껏 IT 업계에서 봐온 짜증-류의 작업은 크게 3개 정도 있다.

1) 첫째가 새벽에 출근해서 DB 만지는 것.

가령, 블로그 서비스에 (사소할지언정) 어떤 기능이 하나 추가되거나 기획자들이 리포트를 원할 때면 필연적으로 RDBMS 스키마를 변경하거나 묵직한 쿼리를 날려야 되는 문제가 따라온다. 그러면 그냥 새벽에 ‘임시점검’ 띄워놓고 DB 작업하는 거다. 데이터가 증가하거나 장애가 뜨면 또 어떤가. 바로 이런 짜증스런 문제에서 Schema-free, ad-hoc query processing, fault tolerant 요구가 나오고 NoSQL 기술이 진화하는 것이다.

2) 두 번째, 웹 서버에 웹 로그 파일 4GB 짜리가 수십 개씩 뚝뚝 떨어진다.

로그파일 떨어지는걸 감당못해 바로바로 압축하고 테이프에 떠서 지워가는 곳도 있을거다. 이 때, 어떤 장애가 발생하면 당근 과거 로그는 뒤져볼 수 가 없겠고, 로그레벨을 debug로 맞춰서 재현될 때까지 멍청하게 눈팅 하는거다. 그래서 거대한 분산 파일시스템, 로그 마이닝 같은 기술에 열광하는게 아닐까. 잡설 1, 미국 어느 주에서는 Facebook, Twitter 타임라인가지고 crime prediction 하기도 하고 (왠지 자살같은것도 미연에 방지할 수 있겠고) 그런다던데 ... 한국은 왠지 알바생들이 나꼼수 트위터 눈팅할 듯.

3) 세 번째, 의사결정권자는 언제나 근거자료를 원한다.

어떤 문제나 서비스/상품을 기획해서 에스컬레이션 올리면 의사결정권자는 근거를 원한다. 그 근거는 수치로 말하는 것이 확실하다. Shut up and use the math. 이런 통계를 내려고 MySQL 깔아서 데이터 입력해놓고 쿼리문으로 조지던 개발자들 많을거다.

뭐 여튼, 빅데이터 기술 진화는 사실 이렇게 필연적이었다고 말할 수 있겠다. 이게 뭐 꼭 오늘날 직면하게된 문제는 아니고 5년 전부터 그 증상들이 이곳저곳에서 나타나고 있었지. 양키들이 NoSQL만들때 우리는 무얼했나? 뭐든 빨리빨리 아웃풋 내놓으라고 쪼아대던 관리자가 주범이다. 그들은 x잡고 반성해야되며, 우리 개발자들의 무능함을 탓하지 말라.

.. 간혹 킬러앱으로 소셜 데이터를 분석해서 서비스 퀄러티를 높인다는 둥 .. 내 생각에 요건 한계가 있다.

검색엔진이 페이지랭크로 추천해주는 문서보다는 그냥 물어보고 직접 사람이 답하는 Q&A 서비스가, 암만 뉴스 개인화 추천시스템이 훌륭해봐야 트위터 친구들이 끊임없이 물어다주는 뉴스들이 더 감칠맛나는 것처럼, ... 빅데이터 분석을 응용하면 서비스의 퀄러티가 높아진다는건 좀 .. (물론 가능성은 있지만) 시만틱웹처럼 뭔가 애매~ 합니다잉.

여튼 뭘 하든지 간에, 결국은 빅데이터는 노하우의 내재화가 핵심인거다. 외부 솔루션 들여와서 자 이제 뭘 할건데?

Graph computing with Apache Hama

2012-02-08T05:02:00.001-08:00

Today, the Pregel-like graph programming framework has been committed into TRUNK. Interfaces are not elegant yet, but I'm sure that Apache Hama will provide best performance than others e.g., Giraph, GoldenOrb. :D ( Hama Performance Benchmarks: http://wiki.apache.org/hama/Benchmarks )

Here's Hama version Single Shortest Path algorithm, it's the same as described in Google's Pregel paper:

  public static class ShortestPathVertex extends Vertex<IntegerMessage> {
    public ShortestPathVertex() {
      super(IntegerMessage.class);
      this.setValue(Integer.MAX_VALUE);
    }

    public boolean isStartVertex() {
      String startVertex = getConf().get(START_VERTEX);
      return (this.getVertexID().equals(startVertex)) ? true : false;
    }

    @Override
    public void compute(Iterator<IntegerMessage> messages) throws IOException {
      int minDist = isStartVertex() ? 0 : Integer.MAX_VALUE;

      while (messages.hasNext()) {
        IntegerMessage msg = messages.next();
        if (msg.getData() < minDist) {
          minDist = msg.getData();
        }
      }

      if (minDist < (Integer) this.getValue()) {
        this.setValue(minDist);
        for (Edge e : this.getOutEdges()) {
          sendMessage(e.getTarget(), new IntegerMessage(e.getName(), minDist
              + e.getCost()));
        }
      }
    }
  }

Terminate AWS instances with Java SDK

2012-02-01T07:03:00.001-08:00

    BasicAWSCredentials awsCredentials = new BasicAWSCredentials(
        AWSAccessKeyId, SecretAccessKey);

    AmazonEC2Client ec2Client = new AmazonEC2Client(awsCredentials);
    ec2Client.setEndpoint(ZONE);

    List<string> instancesToTerminate = new ArrayList<string>();
    instancesToTerminate.add("i-0749ea42");   
    instancesToTerminate.add("i-3353ea16");
    ...
    
    TerminateInstancesRequest term = new TerminateInstancesRequest();
    term.setInstanceIds(instancesToTerminate);
    ec2Client.terminateInstances(term);

Mother Nature is harsh

2012-01-30T04:38:00.000-08:00

When I saw the documentary, "남극의 눈물", I was deeply shocked by the scene where giant petrel attacked a baby penguin.

Mother Nature is harsh.

Big Data vs. Cloud computing, 또 한번의 기술진화

2012-01-24T23:49:00.000-08:00

Hadoop 2.0 부터는 resource sharing architecture로 가면서, 사실상 Facebook이나 Y!같은 인터넷 기업의 통합 Big Data 처리 솔루션에 좀 더 가까워지고 우리가 흔히 아는 장비 렌트 개념의 Cloud 환경에는 그닥 어울리지 않는 ^{왜냐하면 가상화된 다수의 VMs를 다시 Hadoop cluster로 가상화하면서 발생하는 virtualization penalties, 구조상으로도 그저 복잡해지기만 하기 때문} 스스로가 완전한 Cloud computing 솔루션이 되어버렸다.

Apache Whirr이라는 솔루션이 Cloud 환경에 각각의 NoSQL이나 분산 시스템을 deploy할 수 있게 도와주기는 하지만 내 생각에 Big Data 솔루션 공급자와 Cloud provider 입장 사이에 어떤 연결고리가 끊겨있다. 입장 별 시장 타깃을 고려한 비지니스적 전략인지, 기술적 문제의 한계인지는 자세히 따져보지않아 잘 모르겠지만 Big Data 처리능력과 Cloud computing의 elasticity, agility, cost-efficiency 장점 모두를 원하는 고객이 있고 그 시장이 충분히 커진다면, 그 끊겨있는 연결고리를 채워줄 또 한번의 기술진화는 불가피할 것으로 보인다.

[O'Reilly Radar] 빅데이터란 무엇인가?

2012-01-12T23:37:00.000-08:00

* You can see the original post here.

빅데이터는 전통 데이터베이스의 연산 수용능력을 초과한 "너무 크고, 빠르게 변하거나 데이터베이스에 구조화하기 힘든" 데이터를 말한다. 이런 데이터에서 가치를 얻으려면 대안을 찾는 수 밖에.

2012년 핫키워드 빅데이터는 거대한 데이터 3Vs^{volume, velocity and variability}를 싼 값에 다룰 수 있는 형태로 실용화되고 있다. 이런 빅데이터 내에 의미있는 패턴과 정보가 묻혀 있는데, 추출하는 일은 결코 쉽지 않아 예전엔 그냥 그대로 묻혀 있었다. 구글이나 월마트같은 소수의 선두기업만이 막대한 비용을 들여 빅데이터 처리 능력을 갖추고 있었지. 그러나 오늘날의 하드웨어, 클라우드, 그리고 오픈소스는 이제 싼 값에 클라우드를 렌트하여 사업하는 벤처기업마저도 빅데이터를 처리할 수 있게 도와준다.

빅데이터의 가치는 분석 용도와 신규 제품 개발에 활용되는 두 개의 분야로 나뉘는데, 빅데이터 분석은 그간 막대한 비용 뒷켠에 꽁꽁 숨어있던 인사이트를 찾는데 사용된다. 예를 들면, 쇼핑몰 고객의 거래내역, 사회적 지역적 데이터를 분석함으로서 고객들의 영향력을 분석한다. 또, 빠른 시간내 모든 데이터를 연산하는게 가능하여 샘플링하는 번거로움이 없고 사전 정의된 질의에 대한 정기적인 리포트를 뽑아내는 기존의 다소 정적인 방식 대신 새로운 데이터 분석과 교정작업을 필요할때 즉각 처리할 수 있다^{역자주: SQL 리포트 서비스나 비지니스 인텔리전스 Predefined or ad-hoc reports 참고}.

지난 십여년 간 성공한 신생 웹 기업의 신규 사업과 서비스가 바로 이런 빅데이터를 잘 활용한 사례인데, 예를 들면, 페이스북은 사용자 행태와 친구관계를 분석함으로써 고급스럽게 개인화된 UX와 새로운 형태의 광고 사업을 만들어낸 것이다. 빅데이터 대부분의 아이디어와 솔루션이 구글, 야후!, 아마존 그리고 페이스북 등 기업에서 나온 것은 결코 우연히 아닌 것이다.

기업에 빅데이터 출현은 민첩함을 필연적 과제로 안겨다 준다. 빅데이터에서 성공적으로 가치를 얻으려면 연구와 실험을 필요로한다. 신규 사업을 개발하든 시장에서 경쟁 우위를 점할 방법을 찾든 호기심과 기업적 전망이 필요한 것이다.

What does big data look like?

"빅데이터"는 포괄적인 용어로 꽤 모호하다. "클라우드"가 다양한 기술을 커버하는것처럼 말이지. 빅데이터 시스템에 인풋이 되는 데이터는 웹로그, 위성 이미지, 트래픽 로그, 소셜 네트워크, 인터넷뱅킹 거래내역, 웹 컨텐츠, 금융 관련 데이터 등 헉헉! 보시는바와 같이 다양하거든?

의미가 좀 더 명확하게 표현하기 위해, 3Vs (volume, velocity and variety) 라는 것이 있다. 이는 일반적으로 빅데이터의 각기 다른 면을 표현하고자 사용되는데, 데이터의 본질과 그에 맞는 플랫폼을 확인하고 이해하는데 도움주는 잣대로 쓰면 된다.

Volume

거대한 정보를 연산처리할 수 있는 능력이 빅데이터 분석의 주된 매력이다. 사실 좋은 모델보다는 그냥 데이터셋이 많은게 좋거든. 단지 팩터가 늘어난다고 보다 정확한 수요예측이 가능해지진 않고, 거대한 데이터셋에 간단한 수학이 오히려 효과적일때가 있다.

이런 빅 volume은 기존의 IT 구조에 즉각 도전장을 던지지. 확장가능한 스토리지와 분산 쿼리 접근을 요구하니까. 많은 회사들은 이미 많은 데이터를 보유하고 있겠지만, 연산처리할 엄두를 못 내고 있는게 현실일게다.

기존의 관계형 데이터베이스에 안맞는 거대한 볼륨이 있다면, 데이터웨어하우스나 Greenplum 같은 데이터베이스 또는 Apache Hadoop 기반 솔루션들과 같은 분산처리시스템을 골라야할게다. 이 선택에는 3Vs 중에서 "variety"를 갖다 대면 된다. 일반적으로 데이터웨어하우징은 사전 정의된 스키마와 일정하고 느리게 변화하는 데이터셋에 적합한 반면, Apache Hadoop은 요런 데이터 구조에 문제가 없다.

Hadoop은 다수의 서버를 묶어 분산처리하는 플랫폼인데, 분산처리하는 "map" 단계와 결과를 취합하는 "reduce" 단계로 이루어진 구글의 MapReduce 모델을 본떠 만든 프로젝트로써 야후!의 더그커팅에 의해서 처음 개발되고 배포되었다.

데이터 저장은 자체 분산 파일시스템인 HDFS를 활용하는데 Hadoop의 일반적인 사용 패턴은 다음과 같다:

HDFS로 데이터를 로딩
MapReduce로 연산처리
HDFS에 결과 저장

이 과정은 배치 연산이기때문에 분석이나 비대화식 컴퓨팅에 적합하다. 이 때문에 Hadoop이 데이터베이스 또는 데이터웨어하우스 솔루션은 아니지만 분석 보조자의 역할을 수행할 수 있다는 말씀.

Hadoop을 이러한 패턴으로 사용하는 가장 잘 알려진 사용자로는 페이스북이 있는데, MySQL 데이터베이스에 실데이터를 저장하고 Hadoop에 백업해서 친구 추천같은 작업을 MapReduce로 처리하고 다시 결과를 MySQL로 업데이트한다고 하지.

Velocity

데이터의 velocity의^{데이터를 처리하는 속도} 중요성은 volume과 비슷한 패턴을 갖고 있다. 금융쪽과 같이 일부 특수 산업 분야에만 제한되어있던 문제들이 이제는 훨씬 광범위한 분야로 나타나고 있다. 요거 이제 우리 모두가 겪을 차례다.

왜냐? 인터넷과 모바일의 시대는 곧 우리 모두 서비스를 이용하면서 서비스 제공자에게 데이터를 꾸준히 만들어냄을 의미하니까. 쇼핑몰 사업자들은 단순 판매만이 아니라 고객의 클릭 로그나 행태를 모두 수집하면서 신속하게 그러한 정보를 활용하여 추가 구매를 추천하는 등의 방식으로 경쟁력을 얻을 수 있다. 스마트폰의 시대는 지형정보 이미지나 음성같은 데이터들로 유입량이 더 많아졌지.

단순히 유입되는 데이터의 속도만이 문제는 아니다. 배치 작업으로 스토리지에 밀어넣으면 되니까. 중요한건 들어온 데이터를 빠른 속도로 처리하여 결과를 얻는데 달려있다. IBM에 광고를 예로, 5분 전의 트래픽 정보 처리 결과 가지고는 도로를 못건넌다는. 즉, Hadoop 배치 job 완료될 때까지 못기다리겠다는 경우가 있다는것.

이렇게 빠른 속도로 유입되는 데이터를 처리하는 것을 공돌이 용어로는 "스트리밍 데이터" 또는 "컴플렉스 이벤트 프로세싱"이라고 한다. 먼저 일반적으로 사용된건 "스트리밍 프로세싱"이고, 뒤에 나온 용어는 제품용에다 갖다 붙이면서 탄생한 용어다.

스트리밍 프로세싱을 고려하는 이유는 크게 두 가지로 생각할 수 있는데, 첫번째로는 빠르게 들어오는 인풋데이터 전부를 스토리지에 때려넣기 버겁고 스토리지를 어떤 분석 가능한 형상으로 계속 유지하려는 경우다^{역자주: 극단적인 예로 초대형 입자가속기 얘기가 잠깐 나오는데 유용한 정보 안지웠길 희망한다네}. 스트리밍을 고려하는 두 번째 이유는 어플리케이션이 즉각 반응해야하는 경우다. 모바일 어플리케이션과 온라인 게임의 출현 덕분에이 점점 더 일반적인 상황이지.

스트리밍 데이터를 처리하기위한 제품은 IBM의 InfoSphere Streams, 그리고 아직은 덜 익은(?) 트위터의 Storm과 야후!의 S4가 있다^{역자주: Apache Hama Realtime Processing도 참고하시라}.

앞서 언급했듯, 비단 인풋 데이터에 대한 얘기만은 아니다. 시스템의 아웃풋 결과 처리 속도 또한 마찬가지라는 말씀. 예를 들면, 결과를 곧바로 페이스북의 추천 서비스에 반영하거나 의사결정 대쉬보드에 올려줘야 경쟁력을 갖춘다는 이야기.

특히 key-value 저장소나 column-oriented 데이터베이스같은 NoSQL 기반에 미리 요약된 정보를 빠르게 조회하도록 만든 웹서비스가 이러한 빠른 스트리밍 프로세싱이 필요하다!

Variety

데이터가 연산 가공하기 편하게 잘 준비된 형태를 갖추는 경우는 매우 드물다. 빅데이터 시스템은 관계형 구조에 안맞는 다양한 데이터를 다루는 것이 일반 주제다. 소셜 네트워크, 이미지, 센서의 raw 데이터에서 나온 텍스트같은 것들 말이지. 이것들은 개발자 어플리케이션에 쏙 들어갈 준비가 안 되어있다.

웹에서도, 컴퓨터간의 통신이 이뤄져야하는 경우 데이터는 매우 지저분하다. 다른 브라우저가 전송한 각 데이터, 정보를 제대로 입력안하는 유저들, 각기 다른 버전의 소프트웨어로 접근하지. 게다가 이런 과정에 사람 손을 타는 작업이 있으면, 오류와 모순 투성일게다.

빅데이터 프로세싱의 일반적인 사용은 비정형 데이터를 가지고 사람 또는 어플리케이션에 정형화된 인풋용으로 요구된 의미를 찾는것이다. 개체명 식별을 예로^{텍스트 마이닝에 Name/Entity resolution}, "런던"이 영국의 "런던"을 가리키는지 텍사스의 "런던"을 가리키는지 파악할 수 있다.

원본 데이터에서 필요한 데이터로 전환하는 과정에 정보의 손실이 있을수 있다. 다 끝나고 작업자가 원본을 지워버릴수 있겠지. 빅데이터의 핵심이니까 지금부터 밑줄 쫙~. "보관할 수 있을때, 보관해라". 지워버린 데이터에 유용한 정보가 또 숨겨져 있을 수 있다. 지워버리면 되돌릴 수가 없으니.

관계형 데이터베이스가 인기있고 친숙하더라도 언제나 사용해야하는건 아니다. 특정 데이터 형식은 그에 걸맞는 데이터베이스에 잘 맞다. 예를 들어, XML로 인코딩된 문서는 MarkLogic같은 XML 특화된 저장소에 저장하는게 좋다. 소셜 네트워크 그래프는 Neo4j같은 그래프 데이터베이스에 저장하는것이 더 간단하고 효과적이다.

근본적으로 데이터 형식에 문제가 없더라도, 관계형 데이터베이스의 단점은 정적인 스키마다. 더 많은 시그널을 탐지하고 발견하면서 계산 결과는 계속 진화하니까. NoSQL 이놈들은 데이터를 구성하기에 충분한 구조를 제공하지만, 저장하기 전에 고정된 스키마를 필요하지 않거든.

--
빅데이터 = 말 그대로 '크고 많은 양'의 데이터들. 스마트폰, 스마트패드 등 단말기가 많아지고 소셜네트워크서비스(SNS) 등 정보채널이 확대되면서 이용자들이 생산, 유통하는 정보 양이 기하급수적으로 증가했다. 형태가 각기 다른 정보들을 수집하고 분석해 이용하는 방법이 중요하다.

Install a Hama cluster using Whirr

2011-12-19T16:40:00.000-08:00

Apache Whirr provides a Cloud-neutral way to run a properly-configured system quickly through libraries, common service API, smart defaults, and command line tool. Currently it supports various Cloud services e.g., Hadoop, HBase, Hama, Cassandra, and ZooKeeper. Let's see how it is simple to install Hama cluster using Whirr.

The following commands install Whirr and start a 5 node Hama cluster on Amazon EC2 in 5 minutes or less.

% curl -O http://apache.tt.co.kr//whirr/whirr-0.7.0/whirr-0.7.0.tar.gz
% tar zxf whirr-0.7.0.tar.gz; cd whirr-0.7.0

% export AWS_ACCESS_KEY_ID=YOUR_ID
% export AWS_SECRET_ACCESS_KEY=YOUR_SECKEY
% ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa_whirr

% bin/whirr launch-cluster --config recipes/hama-ec2.properties --private -key-file ~/.ssh/id_rsa_whirr

Upon success you should see imok echoed to the console, indicating that Hama is running.

Oh... finished. :)
Now you can run an BSP examples as below:

edward@domU-12-31-39-0C-7D-41:/usr/local/hama-0.3.0-incubating$ bin/hama jar hama-examples-0.3.0-incubating.jar 
An example program must be given as the first argument.
Valid program names are:
  bench: Random Communication Benchmark
  pagerank: PageRank
  pi: Pi Estimator
  sssp: Single Source Shortest Path
  test: Serialize Printing Test
edward@domU-12-31-39-0C-7D-41:/usr/local/hama-0.3.0-incubating$ bin/hama jar hama-examples-0.3.0-incubating.jar pi
11/12/25 11:48:11 INFO bsp.BSPJobClient: Running job: job_201112251143_0001
11/12/25 11:48:14 INFO bsp.BSPJobClient: Current supersteps number: 0
11/12/25 11:48:17 INFO bsp.BSPJobClient: Current supersteps number: 1
11/12/25 11:48:20 INFO bsp.BSPJobClient: The total number of supersteps: 1
Estimated value of PI is 3.147866666666667
Job Finished in 9.635 seconds

SSSP (Single Source Shortest Path) problem with Apache Hama

2011-12-13T02:18:00.000-08:00

From yesterday I'm testing Apache Hama SSSP (Single Source Shortest Path) example with random graph of ~ 100 million vertices and ~ 1 billion edges as a input on my small cluster. More specifically:

Experimental environments

One rack (16 nodes 256 cores) cluster
Hadoop 0.20.2
Hama TRUNK r1213634.
10G network

Task and data partitioning

Based on hashing of vertextID in graph and size of input data.

SSSP algorithm

Algorithm described in Pregel paper

And here's rough results for you:

Vertices (x10 edges)	Tasks	Supersteps	Job Execution Time
10 million	6	5423	656.393 seconds
20 million	12	2231	449.542 seconds
30 million	18	4398	886.845 seconds
40 million	24	5432	1112.912 seconds
50 million	30	10747	2079.262 seconds
60 million	36	8158	1754.935 seconds
70 million	42	20634	4325.141 seconds
80 million	48	14356	3236.194 seconds
90 million	54	11480	2785.996 seconds
100 million	60	7679	2169.528 seconds

What do you think on this chart? I'm quite satisfied considering that the job execution time contains the data partitioning and loading time (100 ~ 500 seconds) and there is still much to be desired. This surely shows scalable performance, the SSSP processing time will not increase linearly with the number of vertices.

2012 다짐

2011-12-11T03:47:00.000-08:00

벌써 2012!

지금까지는 상대를 배려한답시고 뭔가 좀 어물쩡하던 성향이 없지 않았는데, 이게 오히려 어떤 꼬투리의 빌미를 제공하는 것 같다. 대놓고 코 베간다고 .. 눈에 뻔히 보이는 유치한 것들 이제는 그냥 피해가지 않고 내 생각 그대로 밀고 가야겠다.

시간은 짧다.

Whirr 커뮤니티 통계

2011-12-05T20:59:00.000-08:00

프리젠테이션 자료로 활용코자 이미지 업로드 겸.. 블로깅.
여타 아파치 재단 프로젝트가 그렇듯, 훨 커뮤니티도 빠른 속도로 증가 중.

whirr-dev@ list

whirr-user@ list

Living life

2011-11-24T19:32:00.000-08:00

Have you once thought about how many days you have left until you die? If so you already know that what a cruel thing is time.

Human life is too short.

Everyday is very precious, don't stress the small stuff!

Doomsday is nothing

2011-11-21T04:18:00.000-08:00

Cloud 기반에 Hadoop과 NoSQL 솔루션들

2011-11-03T06:38:00.000-07:00

몇몇 사람들의 아마존 EC2 경험담, 그리고 내 경험에 의하면 역시 잘 안맞는다.

Hadoop이나 NoSQL같은 분산 솔루션을 10 VM nodes 규모의 클러스터로 만들어 사용하는건 모르겠으나, 100 VM nodes 이상 규모의 클러스터로 만들면 생각 만큼의 성능은 기대하기 힘들다. 우리집 화장실에 'made in 용산' PC 10대보다 더 느리다.

이런 대형 데이터 처리를 위한 분산 솔루션들은 특히나 IO와 network을 많이 사용하는데 서버 가상화 기술과 네트워크로 제공되는 논리적 볼륨 기반 Cloud 환경에 올라가면 공유자원 부하 문제가 발생할 수 있고 인접한 VM들도 영향을 받을 수 있다.

게다가 fault-tolerant design 일환으로 구현된 node간 파일 복제나 똑똑한 failure detector, 자동 recovery 기능들을 잘못쓰면 때로는 사소한(?) 네트워크 응답지연문제를 시작점으로 줄줄이 도미노처럼 무너지는 장애 쓰나미를 유발할 수 있다.

애초 commodity PC clustering을 겨냥해서 design된 솔루션을 가지고 서버 가상화같은 온갖 기술을 몽땅 Cloud 하나로 포장하면서 발생되는 부작용인가?

Landscapes

2011-10-23T08:07:00.001-07:00

Landscapes: Volume Two from Dustin Farrell on Vimeo.

Open-source M&A

2011-10-17T03:03:00.000-07:00

There are two types of M&A from a buyer's perspective: social status/influence (valuable users/employees/databases/experiences) and positive business model. Typically, knowledge-based industry's case falls under the former. For examples, art, internet service, software, .., etc. In a similar vein, open source software also have a big opportunity.

If your open source software is able to make some buzz among the people, be ambitious!

Google Summer of Code 2011 T-shirt

2011-10-13T05:37:00.000-07:00

Just received my Google Summer of Code 2011 T-shirt gift from Google today, as I was a mentor for GSoC @ Apache this year.

After all, Hama project have found a friend in Thomas.

MapReduce, Twitter Storm, 그리고 Hama BSP

2011-10-12T18:10:00.000-07:00

과거 MapReduce는 확실히 batch-oriented 된 processing engine 이었고, 한 동안 서비스개발에서 멀어져있던 나는 그 굴레에서 쉽게 벗어나지를 못하고 있었던것 같다. large-scale과 우아한 알고리듬 처리 .. 만 생각하고 있었다.

그런데 오늘날 서비스들을 잘 보면 트위터 트렌드나 네이버 실시간 급상승 인기 검색어, 등등 .. 실시간으로 변화하고 진화하는 분야의 문제를 위해 이제는 단순히 거대한 big data/large-scale processing 에서 data stream mining[1], online processing, continuous computation 형태로 진화함을 보고 있다.

확실히 기술은 필요에 의해서 발전의 기틀을 마련한다. 국내에 대형 포탈들은 조용한데 이상한 회사들이 big data를 논하고 있는 현상은 ... 그냥 trend 타고있음을 강조하기 위해 사용되는 서술자. ㅋ

어쨌건 그래서 Storm이나 Stream processing엔진들이 나오고 있고, Google의 Pregel도 100% 이런 형태로 사용되고 있음을 짐작한다. Storm은 내가 안봐서 확실히는 모르겠고, M/R과 달리 Hama BSP는 이 분야에 대해 확실한 강점을 갖는다. traffic anomaly detection 을 위한 시스템을 실험해본 결과 너무 훌륭했다랄까. YARN과 통합된 이후 어떻게 발전할지 기대된다. :D

1. http://en.wikipedia.org/wiki/Data_stream_mining

Real-time, continous, and stream processing with BSP?

2011-10-12T09:03:00.000-07:00

Recently, I attended some seminar, met some people who want to use Hama or already made something. I expected only some large-scale/batch-oriented data processing applications but heard very interesting use cases. One was that a continuous processing using infinite loop in a bsp function of each task.

I realized that BSP is can also be used easily for real-time, continous, and stream processing unlike MapReduce.

나의 2011년을 뒤돌아 보며, 그리고 2012

2011-10-06T04:34:00.000-07:00

3개월이나 남았으므로 아직 끝난것은 아니나 성격이 급해놔서.

어디보자~ 블로그를 스캔하니 금방이다. 올해는 블로깅이 매우 뜸했다. 특별히 계획은 안보이고 년초에 4월까지의 목표라고 정리한게 보이는데 ...

~~1. 송도 국제도시로 이사 완료~~
~~2. MongoDB 번역 완료 및 출판~~
~~3. Apache Hama 0.2 릴리즈~~
~~4. 후보 2명을 커미터로 충원~~
~~5. 작년에 인디 오더 넣은 애마 인수~~

몽땅 올킬. 굿!

그럼 2012년 목표는:

1. Hama를 Hadoop nextGen에 통합
2. 좀 더 많은 커미터 꼬실레이션
3. 1 thousand nodes 대규모 Hama cluster 테스트
4. Hama 0.5까지 릴리즈
5. 아파치 인큐베이터 졸업
6. 실사례, 킬러앱 추가
7. Hama In Action 저술

더 있지만 일단 요정도만.

Introduction of Apache Hama @ National University Of Chungnam

2011-10-04T02:55:00.000-07:00

Introduction of Apache Hama - 2011

View more presentations from Edward J. Yoon

월요일 잡담

2011-09-26T04:30:00.000-07:00

한 때는 순진하게도 어미에게 물려받은 사냥 스킬 하나면 광야를 홀로 누비는 자유로운 삶이 해결된다 믿었다.

한 사람 개인에게 주어지는 한정적인 시간과 능력.

순진한 방법으로는 생존 조차 어려운게 오늘날 우리네 인간사회 현실이다.

Be Sexy Than Smart

2011-09-01T04:27:00.000-07:00

I recently saw some blogs talking about the 2012 end of days, and surprised at them that study harder and research harder than any historians and scientists (even if the quality is low).

Many people can't concentrate on physics and philosophy, but they can concentrate on doomsday and bible. Why? ..

I think, it's probably the same reason we prefer the sexy than smart.

Instinct!
rumor-based risk sharing, a desire for existence and breeding, ..., etc.

LOL,
Semantic Web and AI is too un-sexy.

스마트함보단 섹시함

2011-09-01T03:52:00.000-07:00

2012 종말론을 재미로 살펴보면서 네티즌들에게 깜놀했다.
역사학자보다 과학자보다 더 열심히 연구하고 분석하고 있었거덩.
누가 연구 의뢰해서도 아니고 돈줘서도 아니고. ㄷㄷ
(물론 퀄러티는 저질이다만 .. )

공부 하라고~ 하라고~ 할 쩍에는 제일 싫어하는 과목이 수학/물리/철학이면서..
키보드만 쥐어주면 무엇이 그들을 우주과학, 역사, 종교 전반을 아우르는 학자로 만드는가?

재밌는 이야기가 담겨있어서?
요거는 똑똑한 여자보다 섹시한 여자가 끌리는 이유랑 똑같다.

이성을 뛰어넘는 맹렬한 본능.
루머 기반 위기 공유, 생존, 번식, ... ㅋㅋ

Cancers Generate Muscle-Like Contractions ...

2011-08-28T21:29:00.000-07:00

There are only two cells that declares independence from our body. A germ cell and cancer cell. Few days ago, I saw the amazing news "Cancers Generate Muscle-Like Contractions to Spread Around the Body ... ".

Do they wants to revert back to a single cell state? Are they independent beings?

구글 모토로라 인수 뉴스에 댓글을 보자하니

2011-08-16T19:24:00.000-07:00

많은 개발자들은 열악한 환경과 대우에 불만을 토로하며 그 속에서 원인을 찾는다. 소프트웨어 분야에 대한 지속적인 투자가 필요하다는 댓글도 몇몇 보이고. 이러면 안정적인 직장과 탄탄한 대우를 요구하는것 밖에 ..

이에 따라 건희형은 ..

이 회장은 지난달 삼성전자 수원사업장에서 열린 '선진제품 비교 전시회'에서 "필요한 소프트 기술은 악착같이 확보해야 하며, 열과 성을 다해 소프트웨어 인력을 뽑고 육성해야 한다"고 강조한 바 있다.

필요한 기술 악착같이 확보하고 인력 뽑아서 육성하라 그러지.

철학 없이 상생모델을 떠들고 개방형 플랫폼에 대한 이해 없이 Open API를 공개하는 한국 IT 대기업과 노동자간에 근무환경과 조건 문제의 줄다리기, 소프트웨어 발전과 별로 관계없는 얘기다.

직시해야할 본질적인 문제는 개발자 또는 신생벤처가 성공할 수 있는 기회가 너무 없어서 재능있고 개념찬 사람들이 IT산업의 리더 반열에 못 오르니까 그렇다.

이런 상황에서 대기업 행태가 밥맛이라면 차라리 양키랑 손잡고 반란을 주도하는 편이.. :D