2012.02.02

기고 | 파이어호스 데이터를 처리하는 방법

Brian Proffitt | ITWorld
어떤 데이터들은 일정한 속도로, 심지어 초고속으로 전송된다. IT시스템이 어떻게 그러한 데이터 흐름을 처리하면서 데이터 분석까지 해 내는지 알아 보자.

대용량 데이터를 논할 때 문제가 되는 것은 비단 데이터의 ‘규모’만은 아니다. 사용자의 컴퓨터에 데이터가 수신되는 수신율 역시 중요하다.


데이터 자동화 시대가 시작되기 전까지만 해도, 데이터는 주로 미리 설정된 시간에 데이터 구성(organization)으로 수신되곤 했었다. 데이터의 비즈니스 아워(Business hour)가 그 좋은 예다. 가령 데이터가 9시부터 5시 사이에 수신됐다면, 데이터는 완벽하게 예상 가능한 속도로 성장했으며, 이 데이터에 접근 및 분석하는 일도 마찬가지로 예측 가능한 속도로 이루어 졌다. 게다가, 사람들이 모두 퇴근한 밤 시간에 일어나는 다운타임은 야간 데이터베이스 관리 책임자(DBA)가 문제의 데이터베이스를 업데이트 및 수리 할 수 있도록 하기도 했다.

심지어 초과 근무 수당까지 지불하기도 했다.

많은 기업들에서는 아직도 이러한 방식으로 데이터를 처리하고 있으며, 일부 기업들에선 이 방법만 사용하기도 한다. (그리고 ‘초과 근무’라는 이상한 단어는 대부분 사라졌다) 그러나 다운타임이 없는 자동화된 소스에서 데이터가 전송되는 빈도가 잦아지고 있으며 매일, 매 초 데이터 구성에 데이터를 보내고 있을 수도 있다. 그것도 상당한 양의 데이터를 말이다.

당신의 IT 인프라가 관리하도록 돼 있으며, 모든 것이 말 한 대로 이뤄졌을 경우 실제로 경영상의 의사 결정에 사용되는 일정하고도 강력한 데이터 스트림, 데이터 구루(guru)들은 이를 ‘파이어호스 데이터(firehose data)’라고 부른다.

포스트그레SQL 엑스퍼트(PostgreSQL Experts Inc.)의 CEO 조쉬 베커스에 따르면, 파이어호스 데이터를 다루는 데는 네 가지의 어려움이 존재 한다고 한다. 베커스는 지난 1월 22일 열린 서던 캘리포니아(Southern California) 리눅스 엑스포에서 그러한 어려움들에 대해 다음과 같이 설명했다.

우선, 파이어호스의 크기가 매우 클 것이다. 적게는 초당 수 백에서 많게는 수 천 팩트(fact)까지 가능하다. 그러한 용량은 스파이크(spikes)가 있을 수 있으므로 꾸준한 속도를 유지하지는 않을 수도 있지만, 여러 개의 통제되지 않은 소스로부터 오므로 시간이 지남에 따라 성장할 수 있다.

두 번째 문제는 파이어호스의 용량 속도(rate of volume)는 다양할 수 있으나 흐름 그 자체는 하루 24시간, 일주일 내내 거의 일정할 것이라는 점이다. 즉, 데이터베이스 관리책임자는 데이터를 처리하기 위해 시스템을 멈출 수도, 유지하기 위해 전체 인프라스를 무너뜨릴 수도 없다. 이것과 더불어 뒤죽박죽된 데이터가 더해지면 추출, 변환, 전송(ETL)이 일어날 확률이 거의 없어진다.

세 번째로, 적게는 몇 TB에서 많게는 PB에 이르는 데이터를 다루기 때문에 데이터베이스 그 자체가 매우 클 것이라고 베커스는 청중들에게 말했다.

“이것은 곧 많은 하드웨어가 필요함을 의미한다”라고 베커스는 말했다. 베커스에 따르면, 싱글 노드 데이터베이스 관리 시스템으로는 부족할 것이기 때문이다. 단순히 데이터를 수신하기만 해서도 안 된다. 이렇게 큰 데이터 셋(data set)의 분석 과정 역시 엄청나게 많은 자원을 필요로 하기 때문이다. 또 이 문제를 더 복잡하게 만드는 요소 중 하나는 데이터베이스의 성장인데, “그 누구도 데이터를 버리려는 사람은 없기 때문”이라고 그는 덧붙였다.

마지막 난관은 구성요소장애를 극복하는 것이다. “모든 요소들은 장애를 겪지만, 설령 네트워크가 장애를 겪는다 하더라도 데이터 수집은 계속돼야 한다”라고 베커스는 전했다.




2012.02.02

기고 | 파이어호스 데이터를 처리하는 방법

Brian Proffitt | ITWorld
어떤 데이터들은 일정한 속도로, 심지어 초고속으로 전송된다. IT시스템이 어떻게 그러한 데이터 흐름을 처리하면서 데이터 분석까지 해 내는지 알아 보자.

대용량 데이터를 논할 때 문제가 되는 것은 비단 데이터의 ‘규모’만은 아니다. 사용자의 컴퓨터에 데이터가 수신되는 수신율 역시 중요하다.


데이터 자동화 시대가 시작되기 전까지만 해도, 데이터는 주로 미리 설정된 시간에 데이터 구성(organization)으로 수신되곤 했었다. 데이터의 비즈니스 아워(Business hour)가 그 좋은 예다. 가령 데이터가 9시부터 5시 사이에 수신됐다면, 데이터는 완벽하게 예상 가능한 속도로 성장했으며, 이 데이터에 접근 및 분석하는 일도 마찬가지로 예측 가능한 속도로 이루어 졌다. 게다가, 사람들이 모두 퇴근한 밤 시간에 일어나는 다운타임은 야간 데이터베이스 관리 책임자(DBA)가 문제의 데이터베이스를 업데이트 및 수리 할 수 있도록 하기도 했다.

심지어 초과 근무 수당까지 지불하기도 했다.

많은 기업들에서는 아직도 이러한 방식으로 데이터를 처리하고 있으며, 일부 기업들에선 이 방법만 사용하기도 한다. (그리고 ‘초과 근무’라는 이상한 단어는 대부분 사라졌다) 그러나 다운타임이 없는 자동화된 소스에서 데이터가 전송되는 빈도가 잦아지고 있으며 매일, 매 초 데이터 구성에 데이터를 보내고 있을 수도 있다. 그것도 상당한 양의 데이터를 말이다.

당신의 IT 인프라가 관리하도록 돼 있으며, 모든 것이 말 한 대로 이뤄졌을 경우 실제로 경영상의 의사 결정에 사용되는 일정하고도 강력한 데이터 스트림, 데이터 구루(guru)들은 이를 ‘파이어호스 데이터(firehose data)’라고 부른다.

포스트그레SQL 엑스퍼트(PostgreSQL Experts Inc.)의 CEO 조쉬 베커스에 따르면, 파이어호스 데이터를 다루는 데는 네 가지의 어려움이 존재 한다고 한다. 베커스는 지난 1월 22일 열린 서던 캘리포니아(Southern California) 리눅스 엑스포에서 그러한 어려움들에 대해 다음과 같이 설명했다.

우선, 파이어호스의 크기가 매우 클 것이다. 적게는 초당 수 백에서 많게는 수 천 팩트(fact)까지 가능하다. 그러한 용량은 스파이크(spikes)가 있을 수 있으므로 꾸준한 속도를 유지하지는 않을 수도 있지만, 여러 개의 통제되지 않은 소스로부터 오므로 시간이 지남에 따라 성장할 수 있다.

두 번째 문제는 파이어호스의 용량 속도(rate of volume)는 다양할 수 있으나 흐름 그 자체는 하루 24시간, 일주일 내내 거의 일정할 것이라는 점이다. 즉, 데이터베이스 관리책임자는 데이터를 처리하기 위해 시스템을 멈출 수도, 유지하기 위해 전체 인프라스를 무너뜨릴 수도 없다. 이것과 더불어 뒤죽박죽된 데이터가 더해지면 추출, 변환, 전송(ETL)이 일어날 확률이 거의 없어진다.

세 번째로, 적게는 몇 TB에서 많게는 PB에 이르는 데이터를 다루기 때문에 데이터베이스 그 자체가 매우 클 것이라고 베커스는 청중들에게 말했다.

“이것은 곧 많은 하드웨어가 필요함을 의미한다”라고 베커스는 말했다. 베커스에 따르면, 싱글 노드 데이터베이스 관리 시스템으로는 부족할 것이기 때문이다. 단순히 데이터를 수신하기만 해서도 안 된다. 이렇게 큰 데이터 셋(data set)의 분석 과정 역시 엄청나게 많은 자원을 필요로 하기 때문이다. 또 이 문제를 더 복잡하게 만드는 요소 중 하나는 데이터베이스의 성장인데, “그 누구도 데이터를 버리려는 사람은 없기 때문”이라고 그는 덧붙였다.

마지막 난관은 구성요소장애를 극복하는 것이다. “모든 요소들은 장애를 겪지만, 설령 네트워크가 장애를 겪는다 하더라도 데이터 수집은 계속돼야 한다”라고 베커스는 전했다.


X