2012.01.18

하둡으로 가는 길 | 제3부 RDBMS에서 하둡으로 전환

Brian Proffitt | ITWorld

귀사에도 하둡이 잘 맞을 것 같다고 생각되면 데이터 프레임워크로 구성된 오픈소스 소프트웨어를 다운로드 받아서 비교적 쉽게 시험해볼 수 있다.

지금껏 연재기사를 통해 하둡을 관리하기 위해 갖춰야 하는 것들, 그리고 하둡을 사용하는데 따른 이익과 문제점들을 알아보았다. 그리고 여기 마지막 회에서는 기존의 RDBMS(관계형 데이터베이스)에서 하둡으로 옮겨가는데 따른 비용과 관계된 기술들을 살펴보고, 기업들이 현재 어떻게 하둡을 설치하는지를 보고, 하둡 데이터를 다른 어떤 RDBMS보다 훨씬 빠르고 저렴하게 분석하는데 사용할만한 툴들을 알아볼 것이다.

->하둡으로 가는 길 | 제1부 기술과 훈련
->하둡으로 가는 길 | 제2부 하둡 대 RDBMS 비용

새롭게 부상하는 기술들, 특히 오픈소스의 기술들이 으레 그러하듯, 하둡 역시 원하는 IT 업체들이 직접 시험해보게 함으로써 그에 따른 이익을 누리고 있다. 이제 하둡은 기술 미디어와 컨퍼런스 등에서 더 많이 주목받았으며, 이에 따라 최고 경영진들이 하둡의 열풍에 덩달아 뛰어들어 하둡이 기업 비용을 얼마나 감축시킬지 직접 보고 싶어 한다. 이러한 하둡의 도입에는 흔히 아래 현장에서부터 혹은 경영진으로부터 시작되는 두 방식이 있으며 이 둘을 지금부터 자세히 들여다보자.

아래에서 위로: IT부서가 주도
그림자 같은 IT는 기업에게 있어서 하나의 축복이거나 혹은 골칫덩어리다. 하지만 종종 실험적인 구성 혹은 샌드박스(sandbox) 구성이 결국에는 기업에게 엄청난 이익을 안겨 주곤 했다. 한 예로 리눅스는 21세기 초에 그러한 그림자 IT에 의해 성장한 수혜자다.

아파치 소프트웨어재단(Apache Software Foundation)의 아파치 하둡 부사장 아룬 머시에 따르면 이제 하둡 차례다.

머시는 “아래에서 위로 확산해갈 경우, 보통 한두 명의 엔니지어들이 하둡을 다운로드 받아서 하나의 노드 혹은 4~5노드로 구성된 조그만 클러스터에 하둡을 설치한다”라고 설명했다.

머시가 여러 번 봐왔던 대로 그 뒤에는 다음과 같은 패턴이 나타난다. 먼저 하둡 클러스터를 사용하는 직원들이 그 툴셋의 가치를 알아채기 시작한다. 그러면 아마도 기업의 다른 부서에서도 그들만의 하둡 클러스터를 설치할 것이다. 결국에는 하둡의 가치가 크게 늘어나고 (그 아래 깔려있는 분산형 파일시스템의 확장성 덕분에) 각각 분리되어 있는 하둡 클러스터들이 대략 50~60노드 정도로 이루어진 커다란 단일 클러스터로 합쳐진다.

머시에 따르면 야후와 하둡에서 처음 하둡을 받아들일 때에도 바로 이러한 과정들이 벌어졌다. 각 부서들과 애플리케이션에게 하둡의 가치가 명료해지기만 하면, 하나의 커다란 하둡 네트워크에 모든 것들을 결합시키는 것이 분명 이상적이다.

물론 페이스북이나 야후처럼 각각 1만 개 혹은 5만 개의 노드로 이루어진 대규모 시스템을 배치해야 할 기업은 많지 않을 것이다. 그러나 일반 원칙은 여전히 동일하다.




2012.01.18

하둡으로 가는 길 | 제3부 RDBMS에서 하둡으로 전환

Brian Proffitt | ITWorld

귀사에도 하둡이 잘 맞을 것 같다고 생각되면 데이터 프레임워크로 구성된 오픈소스 소프트웨어를 다운로드 받아서 비교적 쉽게 시험해볼 수 있다.

지금껏 연재기사를 통해 하둡을 관리하기 위해 갖춰야 하는 것들, 그리고 하둡을 사용하는데 따른 이익과 문제점들을 알아보았다. 그리고 여기 마지막 회에서는 기존의 RDBMS(관계형 데이터베이스)에서 하둡으로 옮겨가는데 따른 비용과 관계된 기술들을 살펴보고, 기업들이 현재 어떻게 하둡을 설치하는지를 보고, 하둡 데이터를 다른 어떤 RDBMS보다 훨씬 빠르고 저렴하게 분석하는데 사용할만한 툴들을 알아볼 것이다.

->하둡으로 가는 길 | 제1부 기술과 훈련
->하둡으로 가는 길 | 제2부 하둡 대 RDBMS 비용

새롭게 부상하는 기술들, 특히 오픈소스의 기술들이 으레 그러하듯, 하둡 역시 원하는 IT 업체들이 직접 시험해보게 함으로써 그에 따른 이익을 누리고 있다. 이제 하둡은 기술 미디어와 컨퍼런스 등에서 더 많이 주목받았으며, 이에 따라 최고 경영진들이 하둡의 열풍에 덩달아 뛰어들어 하둡이 기업 비용을 얼마나 감축시킬지 직접 보고 싶어 한다. 이러한 하둡의 도입에는 흔히 아래 현장에서부터 혹은 경영진으로부터 시작되는 두 방식이 있으며 이 둘을 지금부터 자세히 들여다보자.

아래에서 위로: IT부서가 주도
그림자 같은 IT는 기업에게 있어서 하나의 축복이거나 혹은 골칫덩어리다. 하지만 종종 실험적인 구성 혹은 샌드박스(sandbox) 구성이 결국에는 기업에게 엄청난 이익을 안겨 주곤 했다. 한 예로 리눅스는 21세기 초에 그러한 그림자 IT에 의해 성장한 수혜자다.

아파치 소프트웨어재단(Apache Software Foundation)의 아파치 하둡 부사장 아룬 머시에 따르면 이제 하둡 차례다.

머시는 “아래에서 위로 확산해갈 경우, 보통 한두 명의 엔니지어들이 하둡을 다운로드 받아서 하나의 노드 혹은 4~5노드로 구성된 조그만 클러스터에 하둡을 설치한다”라고 설명했다.

머시가 여러 번 봐왔던 대로 그 뒤에는 다음과 같은 패턴이 나타난다. 먼저 하둡 클러스터를 사용하는 직원들이 그 툴셋의 가치를 알아채기 시작한다. 그러면 아마도 기업의 다른 부서에서도 그들만의 하둡 클러스터를 설치할 것이다. 결국에는 하둡의 가치가 크게 늘어나고 (그 아래 깔려있는 분산형 파일시스템의 확장성 덕분에) 각각 분리되어 있는 하둡 클러스터들이 대략 50~60노드 정도로 이루어진 커다란 단일 클러스터로 합쳐진다.

머시에 따르면 야후와 하둡에서 처음 하둡을 받아들일 때에도 바로 이러한 과정들이 벌어졌다. 각 부서들과 애플리케이션에게 하둡의 가치가 명료해지기만 하면, 하나의 커다란 하둡 네트워크에 모든 것들을 결합시키는 것이 분명 이상적이다.

물론 페이스북이나 야후처럼 각각 1만 개 혹은 5만 개의 노드로 이루어진 대규모 시스템을 배치해야 할 기업은 많지 않을 것이다. 그러나 일반 원칙은 여전히 동일하다.


X