본문 바로가기

Home > 열린마당 > 공개SW 소식

공개SW 소식

빅데이터와 하둡에 대한 9가지 잘못된 속설과 진실

OSS 게시글 작성 시각 2015-06-25 17:49:57 게시글 조회수 2684

2015년 06월 24일 (수)

ⓒ ITWorld, Andrew C. Oliver | InfoWorld



빅데이터 애널리틱스는 경쟁 우위는 물론 기업 생존을 위해서라도 꼭 뛰어들어야 한다는 주요 트렌드 가운데 하나다.

그 결과 빅데이터에 관련된 수많은 오해와 잘못된 속설들이 존재하게 됐다. 이런 잘못된 속설들은 우리의 정신을 흐트려놔서 자원을 낭비하고 막다른 길에 이르게 만든다. 또한 예산 접근방식이 도움을 주는 기회들을 놓치게도 한다.

이에 우리가 믿지 말아야 하는 빅데이터와 하둡에 대한 아홉 가지 잘못된 속설들을 정리했다.

속설 1. 데이터 과학자를 구할 수 있다
최근 필자 회사와 거래하는 파트너의 한 사전영업 엔지니어는 자사가 데이터 과학자를 찾는데 얼마나 어려움을 겪는지 이야기했다.

그의 기업에서 원하는 데이터 과학자의 조건에 대해 묻자 수학부문 박사학위를 받고, 컴퓨터 과학 부문 배경, MBA 교육에다 그 모든 분야에 있어서의 근무한 경력이라고 답했다.

필자는 그 답변을 듣고, "그 조건을 다 갖추려면 한 90살은 되야 될 텐데?"라고 이야기했다. 현장에서 실제 구할 수 있는 사람들은 다음과 같은 사람들이다.

- 파이썬 작성은 엉망이고 종종 비즈니스 관련 내용도 하나하나 가르쳐줘야 되는 좋은 수학자
- 어느 정도 수학을 이해하는 좋은 컴퓨터 과학자
- 충분히 문제들을 작업할 수 있고 어느 정도 비즈니스를 이해하는 좋은 컴퓨터 과학자
- 수학을 이해하는 비즈니스 전문가
- 특정 분야 전문가
- 이런 제각기 다른 사람들을 함께 일하게 만드는 방법을 아는 리더

기업이 이런 데이터 과학자 만능 인재를 구할 수 없기 때문에, 여러 분야의 전문가들을 모아 작업 그룹을 만들어야 한다. 이것이 바로 실제로 우리가 해야 되는 일이다.

속설 2. 모든 것은 새롭다
기술자들은 과거를 버리기 좋아하며 그들은 완전히 새로운 현실이나 문제를 해결하는 세트라고 주장하는 새로운 툴을 선호한다.

예를 들어 카프카(Kafka) 메시지 브로커라는 새로운 툴은 빅데이터에 필요한 제품으로 묘사됐다. 하지만 다른 메시지 브로커에 비교해 카프카는 기능 세트가 상당히 뒤쳐지고 성숙도가 낮다. 실제로 새로운, 즉 다른 것은 카프카가 하둡 플랫폼을 위해 대규모 배치를 염두에 두고 설계됐다는 점이다. 만약 그 결함을 받아들일 수 있다면 그게 유용할 수도 있다.

그래도 가끔 더 세련된 라우팅과 품질 보증이 필요하다. 이런 상황에서는 액티브MQ(ActiveMQ)나 더욱 튼튼한 옵션을 활용하라.

속설 3. 우리에게 필요한 것은 머신 러닝이다
필자는 사람들이 머신 러닝(Machine learning)이라고 부르는 것들의 85%가 단순한 통계라고 추정한다. 우리의 문제 대부분은 아마 단순한 수학과 분석일 것이다. 거기서부터 시작하라.

속설 4. 우리는 특별하다
철학자 더든은 예전에 "당신은 특별한 사람이 아니다. 당신은 세련되고 독특한 눈송이가 아니다"고 이야기한 적이 있다.

현실은 어떨까? 업계 절반 정도는 똑같은 ETL 스크립트를 다수의 동일한 데이터소스에 쓰고 동일한 분석으로 고객 맞춤형 데이터를 생성하느라 바쁘다. 어떤 기업이든, 많은 부서에서 이런 작업을 중복해서 하고 있을 것이다.

지금이야말로 빅데이터 컨설턴트가 되기 좋은 시기라 할 수 있다.

속설 5. 하이브는 빠르다
하이브(Hive)는 빠르지 않다. 우리에게 인상을 남기기 힘들다. 물론 새 버전은 더 나아졌지만 여전히 성능 측면에서는 기대 이하다. 확장성이 좋지만 하둡과 SQL에 있어 다수의 툴이 필요해질 것이다.

속설 6. 12노드 이하로 클러스터를 활용할 수 있다
하둡 2+는 12노드에 겨우 적합하며 이보다 적으면 시작하는 데만 한참을 기다려야 할 것이다. 게다가 자신이 실행하는 모든 건 한참이나 걸려서 완료될 것이다. 12노드 상에서 'hello world'를 실행시킬 수도 있겠지만 하둡 2는 더 많은 프로세스를 구동하는데 더 많은 노드와 메모리가 필요함을 의미한다.

스파크(Spark)는 데이터가 메모리 안에 들어가는 한 HDFS의 로딩 시간을 줄이는데 더 뛰어날 것이다.

속설 7. 가상화는 자신의 데이터 노드를 위한 솔루션이다
자신의 벤더가 '노(No)'라고 이야기했다. 자신의 IT팀은 주저했다. 그렇다면 데이터 노드를 SAN상에 올릴 수 없다. 하지만 만약 자신이 관리 노드를 VM 안에 넣었을 때 만약 로그와 저널 작성에 지연이 발생하거나 데이터 노드에 높은 지연시간이나 낮은 IOPS를 얻을 때 병목현상에 걸릴 수 있다.

그럼에도 아마존 웹 서비스 등 선도업체들은 이런 문제들을 이겨내고 지속적으로 좋은 성능과 확장성을 이끌어낸다. 자신도 그럴 수 있지만 자사의 내부 파일 서버와 외부 기업 사이트와 구분해야 하고 하드웨어와 가상화 자원을 효과적으로 관리해야 할 필요가 있다.

명심하자, 스루풋과 지연시간은 통계적으로 별개다. HDFS는 각기 다른 장소에서 둘에 신경쓴다.

속설 8. 모든 문제는 빅데이터 문제다
만약 자신이 두 개의 필드를 두 개의 조건에 2테라바이트에 걸쳐 매칭시킨다고 한다면, 그건 진정한 빅데이터 문제가 아니다. 모든 애널리틱스 요구를 빅데이터로 간주하지 마라.

속설 9. 자신에게는 빅데이터가 없다
빅데이터가 거대한 데이터셋을 놓고 작업하는 것이지만, 빅데이터 접근방식은 소규모 데이터셋에도 상당히 유용할 수 있다. 그러므로 작은 데이터 작업에서도 예산 접근방식을 무시하지 말라. 1기가 데이터밖에 없더라도 문제에 따라 하둡이나 기타 빅데이터 기술로부터 혜택을 받을 수 있다.

자신도 모르는 빅데이터가 자신에게 있을 수도 있다. 기업이 주로 폐기해왔지만 유용한 데이터 셋도 아주 많이 존재한다. 50명 이상의 직원을 가진 기업이라면 아마도 어느 부분에서든 빅데이터 문제를 안고 있을 것이다. 특히 자산이 많은 업종이라면 더 작은 기업이라도 그럴 수 있다.



※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지


[원문출처 : http://www.itworld.co.kr/news/94151]

맨 위로
맨 위로