2012.01.12

하둡으로 가는 길 | 제2부 하둡 대 RDBMS 비용

Brian Proffitt | ITWorld
하둡의 오픈소스라는 특성은 예산이 빠듯한 기업들에게 매력적인 요인으로 작용할 것이다.

많은 사람들은 오픈소스 데이터 프레임워크인 하둡을 아주 방대한 양의 데이터 관리와 관련시켜 생각한다. 여기에는 물론 나름대로 합당한 이유들이 있다:  하둡 스토리지는 누구라도 막대한 양의 데이터를 떠올릴만한 페이스북과 야후가 사용하고 있다. 하둡으로 가는 길 | 제 1부에서도 설명했듯 하둡의 얼리 어답터이자 엄청난 기여자 야후는 이미 5만 개의 노드로 구성된 하둡 네트워크를 설치했으며, 페이스북은 1만 개가 넘는 노드로 구성된 하둡 시스템을 갖췄다.

자 그렇다면 빅 데이터의 ‘빅’은 마련된 것이다.

->하둡으로 가는 길 | 제1부 기술과 훈련
->하둡으로 가는 길 | 제3부 RDBMS에서 하둡으로 전환

그러나 아파치소프트웨어재단(ASF)의 아파치 하둡 부사장이자 호트웍스의 아키텍트인 아룬 머시는 하둡과 기업 내 하둡의 사용에 대해 이견을 제기했다. 머시는 하둡의 활용이 빅 데이터를 훨씬 넘어선다고 주장하는 사람이다. 하둡의 가장 강력한 능력 중 하나는 바로 확장성이며, 야후와 페이스북은 하둡이 어떻게 확장될 수 있는지를 보여주는 훌륭한 예들이다. 그러나 하둡이 다른 방향으로 어떻게 스케일링(scaling)할 수 있으며 어떻게 모든 규모의 기업들에게 의사결정에 필요한 분석 데이터를 제공할 수 있을지에 대해서는 별다른 의견이 없다.

모든 데이터가 동등하게 생성된다
머시의 설명에 따르면 이전의 데이터 스토리지에는 비용이 많이 들었다. 5년 전만 해도 대기업과 중소기업(SMB)들은 폭발적으로 증가하는 데이터 셋(data set)들을 계속해서 기록하고 스스로 관리해야 했다: 이메일, 검색결과, 판매 데이터, 재고 데이터, 고객 데이터, 웹의 클릭 경로 등 이 모든 정보들과 그 외의 더 많은 데이터들이 쏟아져 들어왔고 이를 관계형 데이터베이스 관리시스템(RDBMS)에서 관리하겠다는 것은 막대한 비용이 따르는 계획이었다.

제대로 된 데이터 관리 기능과 비용 절감을 동시에 추구하는 기업은 들어오는 모든 이벤트 및 신호 데이터들을 일반적으로 더 작은 하위집합들로 샘플링할 것이고 이렇게 하향샘플링(downsample)된 데이터를 머시는 ‘히스토리컬 데이터(historical data)’라고 불렀다. 이 데이터는 자동으로 특정 가정에 근거해 분류되며 그 중에서도 어떤 데이터가 다른 데이터들보다 항상 더 중요할 것이라는 가정이 가장 우선적으로 작용할 것이다.
 
예를 들면 전자상거래 데이터에서 우선 순위는 신용카드 데이터가 제품 데이터보다 중요하며 제품 데이터는 클릭 경로 데이터보다 중요하다는 합리적인 가정이 수립될 것이다.

이렇게 하나의 주어진 가정 집합에 근거한 비즈니스 모델을 운영한다면 비즈니스 의사결정을 위한 정보들을 끌어내기가 별로 어렵지 않을 것이다. 하지만 이 정보들은 항상 초기 가정들에 입각해 있을 것이고 만약 그 가정 자체가 바뀌면 어떻게 될까? 데이터가 이전에 이미 하향샘플링을 거쳤기 때문에 모든 원 데이터(raw data)는 이미 오래 전에 사라져버렸을 것이고 어떠한 새로운 비즈니스 시나리오든 스토리지에 남아있는 걸러진 데이터를 사용해야 할 것이다.

게다가 RDBMS기반 스토리지의 비용 부담으로 이 데이터는 종종 기관 내부에서 격리된 채로 저장된다. 영업부의 데이터는 영업부가, 마케팅부의 데이터는 마케팅부가, 회계부의 데이터는 회계부가, 그 외 여타 부서들도 마찬가지로 각 부서가 자신들의 데이터를 보관할 것이다. 따라서 비즈니스 모델과 관련된 결정들은 기업 전체가 아니라 기업의 각 부서들로 제한될 것이다.




2012.01.12

하둡으로 가는 길 | 제2부 하둡 대 RDBMS 비용

Brian Proffitt | ITWorld
하둡의 오픈소스라는 특성은 예산이 빠듯한 기업들에게 매력적인 요인으로 작용할 것이다.

많은 사람들은 오픈소스 데이터 프레임워크인 하둡을 아주 방대한 양의 데이터 관리와 관련시켜 생각한다. 여기에는 물론 나름대로 합당한 이유들이 있다:  하둡 스토리지는 누구라도 막대한 양의 데이터를 떠올릴만한 페이스북과 야후가 사용하고 있다. 하둡으로 가는 길 | 제 1부에서도 설명했듯 하둡의 얼리 어답터이자 엄청난 기여자 야후는 이미 5만 개의 노드로 구성된 하둡 네트워크를 설치했으며, 페이스북은 1만 개가 넘는 노드로 구성된 하둡 시스템을 갖췄다.

자 그렇다면 빅 데이터의 ‘빅’은 마련된 것이다.

->하둡으로 가는 길 | 제1부 기술과 훈련
->하둡으로 가는 길 | 제3부 RDBMS에서 하둡으로 전환

그러나 아파치소프트웨어재단(ASF)의 아파치 하둡 부사장이자 호트웍스의 아키텍트인 아룬 머시는 하둡과 기업 내 하둡의 사용에 대해 이견을 제기했다. 머시는 하둡의 활용이 빅 데이터를 훨씬 넘어선다고 주장하는 사람이다. 하둡의 가장 강력한 능력 중 하나는 바로 확장성이며, 야후와 페이스북은 하둡이 어떻게 확장될 수 있는지를 보여주는 훌륭한 예들이다. 그러나 하둡이 다른 방향으로 어떻게 스케일링(scaling)할 수 있으며 어떻게 모든 규모의 기업들에게 의사결정에 필요한 분석 데이터를 제공할 수 있을지에 대해서는 별다른 의견이 없다.

모든 데이터가 동등하게 생성된다
머시의 설명에 따르면 이전의 데이터 스토리지에는 비용이 많이 들었다. 5년 전만 해도 대기업과 중소기업(SMB)들은 폭발적으로 증가하는 데이터 셋(data set)들을 계속해서 기록하고 스스로 관리해야 했다: 이메일, 검색결과, 판매 데이터, 재고 데이터, 고객 데이터, 웹의 클릭 경로 등 이 모든 정보들과 그 외의 더 많은 데이터들이 쏟아져 들어왔고 이를 관계형 데이터베이스 관리시스템(RDBMS)에서 관리하겠다는 것은 막대한 비용이 따르는 계획이었다.

제대로 된 데이터 관리 기능과 비용 절감을 동시에 추구하는 기업은 들어오는 모든 이벤트 및 신호 데이터들을 일반적으로 더 작은 하위집합들로 샘플링할 것이고 이렇게 하향샘플링(downsample)된 데이터를 머시는 ‘히스토리컬 데이터(historical data)’라고 불렀다. 이 데이터는 자동으로 특정 가정에 근거해 분류되며 그 중에서도 어떤 데이터가 다른 데이터들보다 항상 더 중요할 것이라는 가정이 가장 우선적으로 작용할 것이다.
 
예를 들면 전자상거래 데이터에서 우선 순위는 신용카드 데이터가 제품 데이터보다 중요하며 제품 데이터는 클릭 경로 데이터보다 중요하다는 합리적인 가정이 수립될 것이다.

이렇게 하나의 주어진 가정 집합에 근거한 비즈니스 모델을 운영한다면 비즈니스 의사결정을 위한 정보들을 끌어내기가 별로 어렵지 않을 것이다. 하지만 이 정보들은 항상 초기 가정들에 입각해 있을 것이고 만약 그 가정 자체가 바뀌면 어떻게 될까? 데이터가 이전에 이미 하향샘플링을 거쳤기 때문에 모든 원 데이터(raw data)는 이미 오래 전에 사라져버렸을 것이고 어떠한 새로운 비즈니스 시나리오든 스토리지에 남아있는 걸러진 데이터를 사용해야 할 것이다.

게다가 RDBMS기반 스토리지의 비용 부담으로 이 데이터는 종종 기관 내부에서 격리된 채로 저장된다. 영업부의 데이터는 영업부가, 마케팅부의 데이터는 마케팅부가, 회계부의 데이터는 회계부가, 그 외 여타 부서들도 마찬가지로 각 부서가 자신들의 데이터를 보관할 것이다. 따라서 비즈니스 모델과 관련된 결정들은 기업 전체가 아니라 기업의 각 부서들로 제한될 것이다.


X