무한의 세계

무한 집합의 크기Cardinality, 즉 원소의 개수를 수학에서는 '농도'라고 말한다. 유한 집합의 크기는 그대로 원소의 개수 이지만, 무한 집합의 경우는 원소의 개수를 낱낱이 셈하는 것은 불가능하기 때문에 '농도'라는 말을 사용하고 히브리 문자 ℵ로 표시하고 aleph라 읽는다.

자연수 전체의 개수, 즉 농도가 ℵ0인 집합은 \(\{ℵ0,ℵ1,ℵ2,…\}\) 와 같이 자연수로 번호Index를 붙일 수 있는 집합이라 하여 가부번 무한(집합)이라고 하고 \(\{ℵ_n : n ∈ ℕ\}\) 와 같다.

자연수 다음에 등장하는 것은 유리수(분수)이다. 분수는 직선 상에서 아무리 짧은 부분을 잡아도 그 속에 또 분수가 촘촘히 박혀 있다. 즉, 유리수의 집합은 조밀한 농도를 지닌다. 그러나, 분수 전체의 집합도 자연수의 집합과 1대 1 대응이 가능하며, 따라서 유리수 집합도 같은 가부번 집합이다.

그런데, 0 에서 1 사이의 선분 상의 점을 나타내는 수들의 집합은 아무리 해도 1, 2, 3, ...과 같이 번호를 매길 수 없다. 실수 집합의 농도는 연속의 선분 상의 점의 개수와 같기 때문에 연속체 농도 또는 비-가부번 농도라고 부르며, ℵ1으로 나타낸다. 즉, 실수의 집합은 자연수보다 훨씬 큰 무한 집합이다.

거시세계와 미시세계가 프랙탈 구조로서 연속되어 있다는 석가모니의 우주관에서 소름이 돋을수 밖에 없다! 우주의 무한 크기에 놀랄 것 없이 우리 자체가 훨씬 큰 무한일지 모르겠다.

음성 인공지능 스타트업의 기회 분석

음성 인공지능 분야에서 스타트업이 생각해볼 수 있는 전략은 아마 다음과 같이 3가지 정도가 있을 것이다:

  1. 독자적 Vertical 음성 인공지능 Application 구축
  2. 기 음성 플랫폼을 활용한 B2B2C 형태의 비지니스 구축
  3. 기 음성 플랫폼 생태계 내에 3rd party 서비스 구축

(1) 의 접근은 도메인 특화된 Standalone 음성 인공지능 Application을 만드는 방법이다. (2) 의 접근은 기 음성 플랫폼 비지니스 사업자에 특수 분야 기술을 제공해서 최종적으로 소비자에게 전달되는 B2B2C 형태의 사업 추진이다. 마지막으로 (3) 은 기 음성 플랫폼 내 3rd party 서비스를 개발하여 소비자에게 제공하는 방법이다. 지금부터 하나씩 사례와 함께 자세히 살펴보자.

1) 독자적 Vertical 음성 인공지능 Application 구축

너무 당연한 얘기지만 스타트업이 구글이나 아마존의 범용 음성인식과 차별없는 음성 인식을 통해 경쟁하려 든다면 그것은 별로 좋은 아이디어는 아니다. 구글이나 바이두와 같은 막강한 기업 만큼의 예산과 기술을 갖추고 있지 않기 때문에 무조건 백전 백패다.

그러나, 특정 산업에 특화된 문제를 발굴하고 AI를 결합해 그 문제를 해결하는 접근으로 속도를 내고 있는 Vertical AI 스타트업이 있다. 대표적으로 Chorus.ai와 한국의 리뷰와이저(?), 액션파워 정도가 될 것 같다.

코러스의 창업자는 도메인 특화된 버티컬 엔진이 (경험적으로 퉁쳐서) 일반 범용 엔진보다 최소 15% 향상된 성능을 낼 수 있다고 한다. 국내 Vertical voice AI 회사도 만나본 적은 있지만 개인적으로 나눈 대화다 보니 특별히 언급은 생략한다.

뭐 여하튼 (정량적 평가 수치는 확인할 수 없었으나) 기술적으로 따져보았을 때 명백히 narrow domain으로 접근하면 자연어 처리에 있어 그 복잡도를 낮추고 결론적으로 높은 성능을 낼 수는 있을 것이다.

이 때문에 도메인 특화된 음성 인식 엔진은 당장 빠르게 우위를 점할 수 있다는 점은 분명하다.

다만, 막강한 자본과 기술로 무장한 메이저 플레이어들이 데이터를 확보하는 것은 시간 문제이기 때문에, 시간이 지남에 따라 점점 더 많은 활용 사례로 확장될 것이고 장기적으로 보았을때 방어력을 구축 하는 것은 어려울 것이라고 생각한다.

물론 Vertical 이라 해서 단순히 "전문용어" 같은 언어적 특성 영역 만을 바라볼 필요는 없다. 업무 몰입을 돕는 VoxoAgvoice 라는 스타트업도 있다.

2) 기 음성 플랫폼을 활용한 B2B2C 형태의 비지니스 구축

아마존 에코 (echo) 를 활용해서 심장병 환자의 가정 치료 솔루션을 병원에 제공하는 회사가 하나 있다. 카디오큐브라는 곳인데, 그들은 기 음성 플랫폼을 전략적 B2B 비지니스 고객으로 활용해서 의료기기 형태로 제품을 만들고 병원을 통해 그것이 최종 환자 (소비자) 에게 공급되도록 하는 B2B2C 형태의 비지니스를 하고 있다.

AI 스피커를 따로 만들고 음성 인식 관련 기술을 모두 자체 연구 개발하는 것 대신 기 음성 스피커를 적당히 레버러징하여 비지니스를 풀어내는 것이다.

언뜻 보면 굉장히 매력적인 모습으로 보이긴 하는데, 이런식으로 제품을 만들면 구글과 아마존의 플랫폼 전략에 좌지우지 되며 결국 제약에 발목을 잡힐 수 있지 않을까?

또, 그들 플랫폼은 원본 오디오나 텍스트 정보에 접근하는 것을 엄격하게 제한하고 있기 때문에 서비스 품질을 고도화하거나 자체적인 데이터 경쟁력을 확보하기 어려워 장기 계획을 세우기 어렵다고 볼 수 있다.

3) 기 음성 플랫폼 생태계 내에 3rd party 서비스 구축

거대 회사에서 음성 플랫폼을 만들자마자 역시나 빠르게 기존 성공 방정식대로 서비스 분석 통계 툴, 개발 생산성 도구, 그리고 cross-platform SDK 제공 회사들이 빠르게 쏟아져 나왔다. 대표적인 업체가 VoiceLabs, Storyline, Jovo 등이 있다.

이러한 3rd party 사업은 다 좋은데 그 시장이 충분히 성장한 상태인지가 중요하다. 개인적으로는 이러한 스타트업들은 선점 효과만을 보고 들어가는 약간의 도박성이 있다고 생각한다.

선점 효과가 존재한다는 것은 결국 진입이 쉽다는 얘기라 빠른 시간 내 무한 경쟁 환경에 처하게 되고, (2) 접근과 같이 거대 기업의 플랫폼 전략에 운명이 좌지우지 할 수 밖에 없다.

서비스 분석 통계 툴을 제공하는 VoiceLabs 경우는 아마존의 정책 변경 때문에 서비스를 종료하는 상황도 맞이했는데, 내가 보았을 땐 다분히 의도적인 대기업 횡포의 일환이라고 본다.

맺으며

요즘 특히 음성 AI에 관심이 많다. (지금은 쪼깨 막연하긴 하지만) 음성이라는 것이 정보 소통과 정보 기록에 있어 중요한 인터페이스라는 점에서다. 소통이라는 것은 너무 본질적인 것이다 보니 인간사와 20년 전부터 오늘날 모든 인터넷 서비스에도 여전히 킬러 요소로 자리하고 있다.

어쨌든 스타트업으로써는 (1) 의 접근이 가장 현실적이라고 생각하고 있고, 특별히 B2C 서비스로 AI startup 이 활약할 기회는 (지금 까지 내 생각엔) 크게 많지 않다고 생각하고 있다. 메모장이나 통화 기록을 받아적어주는 정도랄까? (이것들은 이미 내가 시도를 해봤고 playstore에서도 한번 받아 써볼 수 있다).

그래서 B2B 사업 전략과 기회들을 간략히 한번 살펴보았고, 내릴 수 있는 결론은 3가지 모두 장단이 있어서 상황과 문제 특성과 타이밍에 의존적이며, 그에 맞는 전략을 취하는 것이 좋다.

방향이 없는 아주 초기 경우에는 (1) 의 접근이 조금 좋아보인다. 문제는 도메인 지식이다.

다음은 "The Secrets of Successful AI Startups. Who’s Making Money in AI?" 라는 제목의 블로그 포스트 일부 내용이다.

It is clear that AI startups are providing valuable point solutions to enterprises and are succeeding as they have access to (1) large and proprietary data training sets, (2) domain knowledge that gives them deep insights into the opportunities within a sector, and (3) a deep pool of talent around applied AI.

큰 틀에서는 동의를 하지만 내 경험상 데이터는 그렇게 중요한 문제가 아니라고 생각하고 있고, .. 그래서 가장 중요한 문제는 역시나 특정 분야 내 기회를 잡아낼 수 있는 날카로운 인사이트와 도메인 지식이 가장 중요하다고 생각하고 있다.

기술력은 후행 변수다. 타겟이 명확히 없으면 트렌드 공부와 academic 수준의 쉐도우복싱 (?) 말고는 할 것이 없다.

그렇다보니 AI로 돈벌어 먹고 살거라면, 세상을 살펴보고 다양한 사람들을 만나보는 것이 어쩌면 지금 가장 우리가 해야할 일이 아닌가 싶다.


References:

 - https://towardsdatascience.com/the-secrets-of-successful-ai-startups-whos-making-money-in-ai-part-ii-207fea92a8d5
 - http://www.bradfordcross.com/blog/2017/6/13/vertical-ai-startups-solving-industry-specific-problems-by-combining-ai-and-subject-matter-expertise


CTC 손실 함수

\(L\)을 label의 집합, \(L’\)을 공백이 포함된 label의 집합이라고 하자. 길이 T를 갖는 sequence에 대하여, 모든 가능한 paths(network output)의 집합을 \(L’^T = \pi\) 라 하자. 실제 labeling z를 갖는 input x에 대하여, 제대로 labelling이 될 확률을 최대화 하는 문제가 된다. 이후에 maximum likelihood estimation 을 이용해 최적화한다.

\(\hat\theta = arg \max_{\theta} \prod_{i=1}^N p(Z^{(i)} | X^{(i)} ; \theta)\)

output에서 얻은 labels에서 중복되는 label과 공백을 없애는 n:1 함수를 B라고 정의하자. 함수 B는 “Collapsing” operation한다고 칭한다. 예시는 다음과같다.
B(_A__AAAA_BBBCCCC) = B(A_A_BBBB_CC) = AABC

B의 역함수 B-1 가 정의 가능하며, 이 함수는 ground truth에 대하여 모든 possible paths로 map이 가능하다.
B-1(ABCC) = -A-AAA-BBBCCC, 등등등등등 (1:n 함수?형태)

역함수의 성질을 수식으로 표현하면 우측과 같다: \(\{ B(x)|x \in B^{-1}(z)\} = z \)

이제, 주어진 labelling z에 대한 가능도를 정의할 수 있으며, z로 Collapse 가능한 모든 paths가 나올 확률의 합으로 가능도를 정의할 수 있다.

\(p(Z|x ; \theta) = \sum_{\pi \in B^{-1}(z)} p(\pi | x ; \theta) \)

앞서 본 인풋x에 대해 labeling z 를 최적화 하려는 식(아래의 식) 안에 대입을 하고 합의 형태로 바꿔 minimazation 문제로 바꾸면 최종식은 다음과 같다.

\(\hat\theta = arg \max_{\theta} \sum_{i=1}^Nlog [ \sum_{\pi \in B^{-1}(z^{(i)})} p(\pi | x^{(i)} ; \theta) ] \)

How socket.io-redis adapter works? 레디스 어댑터 동작원리

보통 실시간 메시징 처리에 socket.io와 redis를 많이 사용하는데, 그 동작 메커니즘이 자세히 소개된 글을 찾기 어려웠다. 이유는 간단한데, 소스코드가 그냥 간단해서 글로 쓰고 자시고 건더기도 없어 그런듯. 

기본적으로 socket.io는 Server, Namespace, Room, 그리고 Socket으로 구성되어있고 멀티 노드를 위해 pluggable 디자인 방식으로 Adapter라는 것이 존재한다. 

Default In-Memory 방식은 배열에 socket과 room 정보를 저장하기 때문에 웹 서버에 붙어있는 clients 외 에는 알 길이 없다. 이때 redis adapter를 사용하면 다음과 같이 동작하는데, sender가 원격에서 넘어왔다면 그냥 내 로컬 clients에게 deliver하는 것으로 종료하고 그렇지 않으면, 다른 노드에게 publish하여 메시지를 전달한다. 


분산 인프라 치고는 놀랍게도 Javascript 몇 줄 안되는 소스코드로 node, socket.io, 그리고 redis가 동작한다. 좀 이해하기 쉽게 도식화하면 다음과 같다:


딥 러닝의 블랙 박스 열어보기

Opening the black box of Deep Neural Networks via Information
- https://arxiv.org/pdf/1703.00810.pdf

지금까지 딥 러닝은 어떻게 동작하는지 이해할 수 없다고 믿어져왔다. 그러나, 천재들은 그 근본 원리를 이해하려고 노력하고 있지.

이 논문은 SGD가 무슨 역할을 하는지에 대한 해석으로, 이들은 SGD가 drift와 diffusion단계로 구분된다고 설명한다.

첫 drift 단계에서는 multidimensional space를 탐험하고, 수렴을 시작하면 diffusion 단계로 접어들어 (첨부 그림에서 점선 오른쪽에 해당) 굉장히 느려지기 시작하며 chaotic 한 단계로 들어가는데 이게 바로 네트워크가 압축하는 법을 배우는 과정이라는 것이다.



SGD의 무질서도는 local minima에 빠지지 않고 더 나은 방향으로 수렴 할 가능성을 제공 할 뿐만 아니라, diffusion 단계에서 매우 효과적인 internal representations(?)를 생성하는데 자기가 볼쩍에 다소 과한것으로 보이며, 자기들의 IB iterations with stochastic relaxation methods로 DNN 학습 방법을 개선할 수 있을거라고 얘기한다.

제프리 힌트 교수가 지대한 관심과 찬사를 보냈기에 많은 관심을 받고 있는 내용인데, 딥 러닝 대가들의 근본 원리와 최적화 이론에 대한 얘기라, 나는 훔쳐만 봤지 뭔소리인지는 정확히는 이해하기 어렵다.

THE HUNT (JAGTEN)


The Hunt (2012 film).jpg추측으로 만들어진 억측 또는 소문을 ‘카더라 통신’이라고 한다. ‘누가 언제 어쨌다 카더라.’로 시작되는 이야기. 믿거나 말거나 장난처럼 흘린 말이 시간이 지나면서 엉뚱한 방향으로 튀어 종잡을 수 없게 된다. 급기야 열기구처럼 둥둥 떠다니며 온갖 티를 묻히기도 하는데, 그 볼썽사나움이란 형언하기조차 어렵다.

요즈음에는 ‘넷카시즘’이 횡행한다. 인터넷이나 SNS 공간에서 누리꾼 다수가 특정 개인을 공격하는 것 말이다. 마녀사냥이라고 해야 할지. 광속도로 자행되는 돌팔매질 앞에서 당하는 사람은 속수무책이다.

둘의 공통점은 불특정 다수가 특정 개인을 잡도리한다는 것이다. 자신과 이해관계가 없음에도, 심지어 상대를 잘 알지 못함에도 덩달아 가담하여 사태를 악화시킨다. 

‘거짓 동의 효과’라는 게 있다. ‘다른 사람이 나와 같을 것으로 생각하는 경향으로 그들에게 자신을 투영하는 현상.’을 말하는 것인데, 집단적 왜곡으로 치달을 때 그 파괴력은 상상을 초월한다. 속된 표현으로 사람 잡을 일이다. 

잠시 우리 직장으로 고개를 돌려보자. 지금 우리는 어느 동료직원에게 돌을 던지고 있지 않은가. 어떤가. 부지불식중에 확인되지 않은 남 이야기를 하고 있지 않느냐 말이다.

이러한 상황에 내몰린다면 어떻게 처신해야할까? 편히 앉아 영화 한편 때리셔라. The Hunt.

페이스북, AI의 직관적 물리학 체계 실험

아들을 데리고 탄천을 산책 하면서 우연히 돌계단을 오르며 생각했다. 표면이 고르지 않은 돌계단에 나는 내딛을 위치를 어떻게 결정하고 있는가?

우리의 뇌는 직관적 지름길과 어림법heuristic을 많이 가지고 있다. 예를 들면, 움직이는 물체의 궤적을 예측할 수 있는 "직관적 물리학 체계"를 타고 난다. 연구에 따르면, 신생아도 자신에게 다가오는 물체가 충돌 궤적을 따르느냐 아니냐에 따라 상이한 반응을 보인다.

우리는 '던져진 물체와 '낙하하는' 물체를 직관적으로 구분한다. 던져진 물체에 대해서는 물체에 가해진 힘과 중력 두 가지를 고려하지만 낙하하는 물체에 대해서는 중력만 고려되기 때문에 그 물체는 곧게 하강할 것이라 예측하는 것이다.

완전한 3차원 재구성을 하지 않아도 단순한 사진 장면에 대해 우리는 물리적으로 이해할 수 있고, 이것을 직관적 물리학 체계라고 할 수 있다.


최근 INRIA와 Facebook AI 팀의 연구원들은 AI가 이러한 직관적 물리학을 얼마나 이해하는지 진단하는 평가 프레임 워크를 개발했다. (참고: IntPhys: A Framework and Benchmark for Visual Intuitive Physics Reasoning)

만일 AI가 이러한 직관적 물리학 체계를 얻게 된다면 바둑 두는 정도가 아니라 생각된다. 씹~소오름.

Introducing Rebase: a Firebase like backend service based on Node.js, Redis, and HBase

삼성전자 재직시절 (아마도 2 ~ 3년 전) 대외 기고 승인까지 다 받아놓고 게재하지 않았던 글을 이제서야 올려본다. 지금 다시 보니 감회가 새롭네.

Introducing Rebase: a Firebase like backend service based on Node.js, Redis, and HBase 

Guest post written by Edward J. Yoon and Sungwon Han, Senior Software Engineers, Samsung Electronics.

 Event-driven applications that handle user actions, sensor outputs, or messages from other applications have become increasingly popular in recent years, in part as a result of the proliferation of smart devices and the Internet of Things. With this, the real-time databases (like Google's Firebase [1] and RethinkDB [2]) are considered as important technologies for supporting these non-traditional applications and workloads. In this guest post, we introduce Rebase, a Firebase-like backend service that allows you to store and synchronize data in online/offline modes, push notifications and provides analytics (in near future) for mobile platforms. Rebase was first deployed to run on Amazon AWS. However due to performance and cost reasons, we soon migrated it to run on Joyent’s Triton Cloud. We share performance benchmarks for Rebase on Joyent Triton vs. Amazon AWS, which served as our key decision metric.

Rebase 

Recently, we developed a container-based real-time database for Samsung IoT applications, called Rebase. It uses event-driven model to notify changes among clients, stores data as JSON objects in a K/V databases. It also provides easy-to-use RESTful APIs and client libraries that accessible to cross-platforms such as iOS and Android in form of SDKs. With Rebase, developers can focus on core functionality and not have to worry about the infrastructure running the backend services.

Below is a reference architecture for Rebase. It has the following key components:

 Rebase backend container stack 

NGINX, Node.js, and Standalone Redis 

We adopted NginX, Node.js, and Redis as a backend servers. Node.js is a JavaScript runtime environment that processes incoming requests asynchronously in a loop, called event loop. It has an event-driven and non-blocking I/O model, thus it allows handling large throughput of data and building scalable applications. NginX is used as a load balancer, and the standalone Redis is used for message queueing and asynchronous messaging.

Redis and HBase Cluster 

For the persistent storage, we reviewed NoSQLs and K/V stores such as Redis, HBase, and MongoDB. MongoDB isn't suitable for the time-series workloads. Redis is very fast but it has limited scalability and persistency capabilities. HBase is column-oriented K/V store that allows horizontal scalability, and allows to store not only JSON object itself but also parsed columns for fast columnar scan. So, we decided to use the sharded Redis cluster as cache storage, and the HBase as persistent storage.

Programming Interface 

Rebase's client SDK is very similar to the Google's Firebase. It provides basic CRUD operations and stream subscriptions APIs. For example, chatting app synchronization can be written like the following:
var setMessage = function(data) {
    var val = data.val();
    this.displayMessage(data.key, val.name, val.text);
  }.bind(this);

// Loads the last 3 messages and listen for new ones.
this.messages.limitToLast(3).on('child_added', setMessage);

Joyent Triton vs. AWS 

Cost

In the early days of Rebase, we mainly used Amazon EC2 instances and ECS service as a container pools for Rebase backend service. AWS served our needs well, when our users and traffic workloads were small. However as we started scaling out, it quickly turned into a very expensive option for our long term needs.

Server Density

Additionally, AWS runs containers on VMs, which adds unnecessary overhead to the compute nodes. Also if you end up running Kubernetes to manage containers, on VMs running on EC2, the layers of abstraction keep adding flab and reduce efficiency of the compute resources. We tried Joyent and were impressed with it’s containers on bare-metal service. No VMs or abstraction layers to go through.

Performance

Moving to bare metal with Joyent's Triton service [3], we were able to get significant performance improvements as following throughput graph illustrates. For Read operations, we were able to increase throughput by 3~5% while keeping latency under 1 second. For Write operations, we were able to increase throughput by 63% at the same latency of under 1 second. 

Deployment Time

We were able to reduce the deployment time drastically (5 minutes to 1 minute) for new cluster of rebase backend service using Triton’s optimized container provisioning.

State of the Project 

We are still in the early stages and the code isn't meant for production usage yet. The auto-scaling with minimal downtime is challenging. An elastic solution that allows auto scaling up and down or non-stop migrating service is our next goal. Container Pilot and the auto pilot pattern look like some of the right tools to try.

We also plan to open source this project once we've made a few more refinements to it, so that we could tailor it and contribute back to the wider community. We will also be looking to add contributors, so keep a lookout on here for updates! 

References

1. "Google Firebase". https://firebase.google.com/
2. "RethinkDB". http://www.rethinkdb.com/
3. "Joyent Triton". https://www.joyent.com/triton

Holonomic brain theory and Capsule Network

Hinton's CapsNet explains about entity's pose, lighting and deformation, instead of shape feature and pattern. While I reading Hinton's idea, I thought about Holonomic brain theory.

"If a holographic image, containing the image of an apple, is cut in half and then illuminated by a laser, each half will contain the overall image of the apple! Even if the halves are sliced again and again, from each little piece of the film can be restored the image of a whole apple (although the image will become less clear with the reduction of the parts)."

Our brain is also very similar. We don't store images in brain, we store some transformed code. We don't lose our memory, it just fade out.

Gear Watchface Designer on Mac OS X

재직 시절에 (싸게) 구매했던 기어 S3를 쓰다보면 watchface 권태기를 3개월마다 겪게 되는데, 그럴때마다 구매한게 지금 거진 20개 가까이 된다. 그런데 내 마음에 썩 들지도 않고 얼마 안하지만 아깝기도 해서 직접 만들어보기로 했다.

디자이너들을 위한 개발 도구는 Gear Watchface Designer를 검색해서 설치하면 되는데, Java 버전에 따라 키보드와 마우스가 먹통이 되는 현상이 있다. Java다 보니 뭐 맥북이든 윈도우즈든 상관은 없고, 최신버전 JDK에서는 동작하지 않고 반드시 JDK 8u151 [1] 버전을 설치해야 한다. 이것 때문에 개삽...

아래는 내가 지금 만들고 있는 watchface 인데, free 이미지를 활용해서 Roman 스타일로 내 맘에 꼭 든다 ㅋ 돈 받고 팔아봐야지~


Elegant Roman Javik 검색하면 나옴~


[1]. JDK 8u151 버전 설치 링크: http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html?printOnly=1

Storm vs. Spark Streaming: 내부 메커니즘의 차이점

트렌드 면에서는 기계학습에 밀린 것 같지만, 실시간 처리 또는 스트리밍 처리는 대단히 중요한 기술이다. 오픈소스로 존재하는 Storm과 Spark을 한번 비교해보자. 물론 솔루션 선택은 자유이고, 상황에 맞는 것이 바로 최적의 솔루션이다.

1. Task Prallel vs. Data Parallel

계산 프로그래밍 모델에서부터 느낄 수 있는 가장 뚜렷한 차이는 먼저, Storm은 Task Parallelism이고 Spark Streaming은 Data Parallelism이다.  개인적으로는 보다 완성도 높은 시스템을 구현할 수 있는 Storm의 계산 그래프 구조를 선호하지만 코드의 복잡도 면에서는 Spark이 유리할 수 있다.

2. Streaming vs. Micro-batches

Spark streaming의 경우는 엄밀히 말하면 실시간 처리보다는 작은 단위의 배치 연속이라고 할 수 있다. Storm은 전형적인 event-driven record at a time processing model로써 살아있는 데이터를 처리한다고 하면, Spark은 휴면 상태로 넘어간 데이터를 처리한다. 때문에 Latency에서 차이가 발생하는데 Storm은 subsecond, Spark의 경우에는 사용자 임의지정 few seconds가 된다.

여기에서 중대한 차이점이 발생하는데, Storm의 경우에는 데이터 유실이 없어야 할 때 (no data loss), Spark은 중복 연산이 없어야할 때 (exactly once) 선택하는 것이 좋다.

한편, Storm Trident는 Micro-batches 스타일도 가능하다고 한다.



3. Stateless vs. Stateful

앞서 소개한대로 Storm은 매 레코드 별로 처리하기 때문에 State을 유지하지 않기 때문에 장애 복구 메커니즘이 Spark보다 복잡하고 re-launching 시간이 더 걸릴 것이다.  Stateless vs. Stateful는 (뭔가 더 있을 것 같지만) 장애 복구 외의 차이점은 전혀 없다.

4. Integration with Batch processing

긴말 필요없이 당연히 Spark이 유리하겠다.

여기까지 알아봤고 과연 무엇이 최상의 솔루션인가? 내 생각엔 Storm이 조금 우수하다 판단한다. 물론 최적의 솔루션은 당신 상황에 맞아야 하겠다.

Belief Propagation 알고리즘

한 때, 병렬 그래프 연산과 알고리즘에 심취한 적이 있다. 그중에 신뢰 전파(Belief Propagation) 알고리즘에 대해 적어본다. 이 알고리즘은 Graphical model에서 inference problem의 근사해를 추정하는 기법으로, Graph 상에 관측된 특정한 확률변수의 분포가 주어졌을 때, 직간접적으로 영향 받는 모든 관측되지 않은 확률 변수의  Marginal distribution을 추정하는 기법이다.

즉, 아래와 같은 Poly Tree 구조 안에 C 노드와 E 노드가 Evidence가 주어졌을 때, \( P(B|C,E) = ? \)



알고리즘은 각 노드 간 Down or Upward Message Passing과 Data Fusion 단계를 거쳐 각 노드의 확률 분포를 추정하기 때문에 병렬 연산을 위해서 Bulk Synchronous Parallel 모델이 대단히 적합하다 할 수 있다.

문득, Google의 DistBelief는 이러한 분산 베이지안 네트워크의 메시지 전달 방식이라 지어진게 아닌가 싶다. 그나저나 요즘의 나는 트리 탐색 구현 정도나 할 수 있을까 모르겠네?

딥 러닝의 비밀을 파헤치는 새로운 이론

예루살렘 히브리 대학 (Hebrew University of Jerusalem)의 컴퓨터 과학자이자 물리학 교수인 티쉬비(Naftali Tishby)가 작년 베를린의 한 컨퍼런스에서 딥 러닝이 어떻게 작동 하는지를 설명하는 새로운 이론을 제시했다.

"deep learning is an information bottleneck procedure that compresses noisy data as much as possible while preserving information about what the data represent."

딥 러닝이란, 데이터의 노이즈는 줄이고 그것이 무엇을 표현 하는지에 대한 주요 정보만 남기는 정보 병목 (Information bottleneck) 절차라는 것이다.

정보 병목 기법 (Information bottleneck method) 은 두 랜덤변수의 결합확률분포가 주어진 경우, 두 변수 간의 상호 정보량을 최대한 보존하면서 한 변수를 압축하는 기법이다 (위키 참고 [1]).

위키에 Information theory of deep learning 섹션은 정리되다 말았지만, X가 실제 개 사진의 픽셀같은 복잡한 대량의 데이터 셋이고, Y가 “개”와 같이 그 데이터를 표현하는 단순한 변수라 가정해보자. 딥 러닝은 즉, Y의 정보를 최대한으로 보유하고 있는 X 의 축약된 표현을 구함으로써 일반화라는 목표에 도달하는 과정이라는 것이다.

내가 이 내용에 관심을 갖게 된 이유는, 딥 러닝 대부인 힌튼 교수께서 친히 티쉬비의 연구 결과에 찬사를 보냈다고 한다.

 “I have to listen to it another 10,000 times to really understand it, but it's very rare nowadays to hear a talk with a really original idea in it that may be the answer to a really major puzzle.”

한편으로 또한 재밌는 것은, 티쉬비 교수 인터뷰에 따르면 딥 러닝이 잘 할 수 있는 것과 못하는 것의 한계는 명백 해진다. 세부적인걸 포기하기 때문에 큰 수 곱셈이나 암호 코드 박살 내는건 잘 해내지 못할 거라고 한다 ㅋ.

우리 인간은 보고싶은 것만 본다. 세계로부터 전달되는 엄청난 정보의 대부분을 포기하고 정말로 보고 싶은 것만 보고 있는지 모르겠다.

1. https://en.wikipedia.org/wiki/Information_bottleneck_method

에이전트 오브 쉴드 엉뚱 짤막 후기

전형적인 미드 중 하나로 .. 뭔가 스파이 비밀조직에서 팀을 이루고 문제를 해결해나가는 스토리다. 한국은 누구랑 친해? 또는 누구랑 놀지마, 친하게 지내, 그리고 경쟁적이고 아파트 평수로 파를 가르는 문화가 있는데 아이를 키우는 입장에서 정말 부럽다는 생각이 든다. 다양성을 인정하고 팀으로 문제를 해결하는 환경으로 바뀌어나갔으면 좋겠어.

무한의 세계

무한 집합의 크기 Cardinality , 즉 원소의 개수를 수학에서는 '농도'라고 말한다. 유한 집합의 크기는 그대로 원소의 개수 이지만, 무한 집합의 경우는 원소의 개수를 낱낱이 셈하는 것은 불가능하기 때문에 '농도'라...