2014.07.21

최악의 빅데이터 프랙티스 10가지

Andrew Oliver | InfoWorld

물론 누구나 빅 데이터를 도입할 수 있다. 그러나 항상 제대로 활용되는 것은 아니다. 꼭 피해야 할 10가지 빅 데이터 사용 방법을 알아보자.

1. 몽고DB를 빅 데이터 플랫폼으로 선택하기
왜 몽고DB를 선택하는가? 이유는 모르겠지만, 지금 가장 많이 오용되는 NoSQL 데이터베이스는 몽고DB다. 몽고DB에는 맵리듀스, 그리고 (문서화가 매우 열악한) 하둡 커넥터와 비슷한 집계 프레임워크가 있긴 하지만 원래의 용도는 분석 시스템이 아니라 운영 데이터베이스다.

"몽고를 사용해서 분석할 것은..."이라고 생각한다면 그 생각을 당장 멈추라. 스스로 무슨 짓을 하고 있는지 돌아보길 바란다. 가끔 "추후 분석을 위한 수집"에 사용하는 경우도 있는데, 그렇다면 현재 수행하는 작업에 따라서 용인될 수도 있다. 그러나 몽고DB를 정말 일종의 데이터 웨어하우징 기술로 사용할 생각이라면 그 프로젝트는 시작부터 망친 운명이다.

2. RDBMS 스키마를 파일로 사용하기.
RDBMS의 각 테이블을 파일로 덤프한다. 이것을 HDFS에 저장한다. 여기에 하이브를 사용할 생각이다.

우선 주지하다시피 하이브는 일반적인 모든 작업에서 RDBMS보다 느리다. 간단한 선택에도 맵리듀스를 사용한다. "테이블" 조인을 위한 "최적화된" 경로를 한 번 보라. 다음으로 크기 문제가 있다. 몇 KB 크기의 플랫 파일들이다. 하둡은 비교적 플랫한 데이터의 대용량 집합에 대한 작업에서 가장 효과적이다. 물론 더 비정규화된 추출(extract)을 분명히 생성할 수 있다.

3. 데이터 연못 만들기
'데이터 호수(Data Lake)'를 만드는 과정에서, 옆길로 잠깐 빠져 일련의 데이터 연못을 만든다. 게다가 콘웨이의 법칙이 작용하면서 각 비즈니스 그룹은 자체 데이터 분석뿐만 아니라, 자체 미니 저장소까지 만든다. 처음에는 이것이 그렇게 나쁘다고 생각되지 않는다. 그러나 다양한 추출, 그리고 데이터를 자르고 다듬는 과정을 거치게 되면 남는 것은 여러 가지 데이터 뷰다. 플랫 대 큐브 이야기를 하는 것이 아니다. 동일한 질문에 대해 다른 답이 도출되는 현상을 말하는 것이다. 스키마-온-리드(Schema-on-read)는 "전혀 계획하지 않음"을 의미하는 것이 아니라, "질문할 수도 있는 모든 질문을 다 계획하진 않는 것"을 의미한다.

어쨌든 큰 그림에 대한 계획을 수립해야 한다. 위젯을 판매한다면 얼마나 많이, 누구에게, 얼마나 자주 위젯을 판매했는지에 대한 질문에 답해야 할 때가 온다. 공통적인 포맷에서 이 답을 찾고, 약간의 사전 설계를 통해 각 개별 비즈니스 그룹이 소유하는 데이터 연못과 웅덩이들이 난립하지 않도록 하라.

4. 타당한 사용 사례 개발의 실패
업체들은 솔루션을 판매할 때 실제 사용 사례 대신 데이터 호수 개념을 내세운다(이는 부서의 자금 제약을 회피하는 방편이기도 함). 데이터 호수 접근 방법도 타당할 수는 있지만 반드시 실제 사용 사례를 염두에 두어야 한다. 중간 규모 기업에서 대기업에 이르기까지, 사용 사례를 생각해 내기란 대부분 별로 어렵지 않다. 먼저 최근에 누군가가 "그건 데이터베이스가 감당하지 못해서 못합니다"라고 말했던 경우를 생각해 본다. 그런 다음 더 심한 사례로 옮겨간다. 예를 들어 "비즈니스 개발"은 우수 영업 인력을 위한 단순한 명목상의 프로모션이 아니라 실질적인 무언가를 의미해야만 한다.

예를 들어 머하웃(Mahout)을 사용해서 공통적인 고객 주문을 찾는 것은 어떤가? 대부분의 기업에서 대부분의 고객 주문은 서로 비슷하다. 다만 꽤 자주 일어나지만 일반적인 주문에서 벗어나는 경우는 어떻게 될까? 영업 담당자가 신경을 쓰기에는 너무 적을 수 있지만 회사의 미래 비즈니스 라인이 될 수도 있다(즉, 실질적인 비즈니스 개발). 현실 환경에서 최소 두 개의 하둡 사용 사례를 떠올릴 수 없다면 아마도 하둡이 필요가 없다는 뜻일 것이다.

5. 하이브에 대한 생각이 가장 중요하다
사람들은 SQL을 알고 SQL을 좋아하며 지금까지 SQL을 사용해 왔다. 필자도 안다. 하지만 거기서 더 성장할 수는 없을까? 오래 전으로 거슬러 올라가 생각해 보면, SQL을 처음 배우면서 새로운 세계에 눈을 뜬 어린 아이를 기억해낼 수 있을 것이다. 그 아이가 다른 것을 배운다고 상상해 보라.

누구나 다시 그 아이가 될 수 있다. 최소한 피그(Pig)는 배울 수 있다. 그렇게 (많이) 힘들지는 않다. 그저 PL/SQL에 근육 강화제와 약간의 신 맛을 가미했다고 생각하면 된다. 할 수 있다! 필자는 그렇게 믿는다. 조금 큰 규모의 분석을 하려면 하이브, 피그, 맵리듀스, 우지가 포함된 더 규모가 큰 도구 집합이 필요할 수 있다. "하이브가 할 수 없다면 이 일은 할 수 없다"고 말하지 말라. 빅데이터의 핵심은 하나의 기술로 구현 가능한 범위를 넘어 확장하는 데 있다.




2014.07.21

최악의 빅데이터 프랙티스 10가지

Andrew Oliver | InfoWorld

물론 누구나 빅 데이터를 도입할 수 있다. 그러나 항상 제대로 활용되는 것은 아니다. 꼭 피해야 할 10가지 빅 데이터 사용 방법을 알아보자.

1. 몽고DB를 빅 데이터 플랫폼으로 선택하기
왜 몽고DB를 선택하는가? 이유는 모르겠지만, 지금 가장 많이 오용되는 NoSQL 데이터베이스는 몽고DB다. 몽고DB에는 맵리듀스, 그리고 (문서화가 매우 열악한) 하둡 커넥터와 비슷한 집계 프레임워크가 있긴 하지만 원래의 용도는 분석 시스템이 아니라 운영 데이터베이스다.

"몽고를 사용해서 분석할 것은..."이라고 생각한다면 그 생각을 당장 멈추라. 스스로 무슨 짓을 하고 있는지 돌아보길 바란다. 가끔 "추후 분석을 위한 수집"에 사용하는 경우도 있는데, 그렇다면 현재 수행하는 작업에 따라서 용인될 수도 있다. 그러나 몽고DB를 정말 일종의 데이터 웨어하우징 기술로 사용할 생각이라면 그 프로젝트는 시작부터 망친 운명이다.

2. RDBMS 스키마를 파일로 사용하기.
RDBMS의 각 테이블을 파일로 덤프한다. 이것을 HDFS에 저장한다. 여기에 하이브를 사용할 생각이다.

우선 주지하다시피 하이브는 일반적인 모든 작업에서 RDBMS보다 느리다. 간단한 선택에도 맵리듀스를 사용한다. "테이블" 조인을 위한 "최적화된" 경로를 한 번 보라. 다음으로 크기 문제가 있다. 몇 KB 크기의 플랫 파일들이다. 하둡은 비교적 플랫한 데이터의 대용량 집합에 대한 작업에서 가장 효과적이다. 물론 더 비정규화된 추출(extract)을 분명히 생성할 수 있다.

3. 데이터 연못 만들기
'데이터 호수(Data Lake)'를 만드는 과정에서, 옆길로 잠깐 빠져 일련의 데이터 연못을 만든다. 게다가 콘웨이의 법칙이 작용하면서 각 비즈니스 그룹은 자체 데이터 분석뿐만 아니라, 자체 미니 저장소까지 만든다. 처음에는 이것이 그렇게 나쁘다고 생각되지 않는다. 그러나 다양한 추출, 그리고 데이터를 자르고 다듬는 과정을 거치게 되면 남는 것은 여러 가지 데이터 뷰다. 플랫 대 큐브 이야기를 하는 것이 아니다. 동일한 질문에 대해 다른 답이 도출되는 현상을 말하는 것이다. 스키마-온-리드(Schema-on-read)는 "전혀 계획하지 않음"을 의미하는 것이 아니라, "질문할 수도 있는 모든 질문을 다 계획하진 않는 것"을 의미한다.

어쨌든 큰 그림에 대한 계획을 수립해야 한다. 위젯을 판매한다면 얼마나 많이, 누구에게, 얼마나 자주 위젯을 판매했는지에 대한 질문에 답해야 할 때가 온다. 공통적인 포맷에서 이 답을 찾고, 약간의 사전 설계를 통해 각 개별 비즈니스 그룹이 소유하는 데이터 연못과 웅덩이들이 난립하지 않도록 하라.

4. 타당한 사용 사례 개발의 실패
업체들은 솔루션을 판매할 때 실제 사용 사례 대신 데이터 호수 개념을 내세운다(이는 부서의 자금 제약을 회피하는 방편이기도 함). 데이터 호수 접근 방법도 타당할 수는 있지만 반드시 실제 사용 사례를 염두에 두어야 한다. 중간 규모 기업에서 대기업에 이르기까지, 사용 사례를 생각해 내기란 대부분 별로 어렵지 않다. 먼저 최근에 누군가가 "그건 데이터베이스가 감당하지 못해서 못합니다"라고 말했던 경우를 생각해 본다. 그런 다음 더 심한 사례로 옮겨간다. 예를 들어 "비즈니스 개발"은 우수 영업 인력을 위한 단순한 명목상의 프로모션이 아니라 실질적인 무언가를 의미해야만 한다.

예를 들어 머하웃(Mahout)을 사용해서 공통적인 고객 주문을 찾는 것은 어떤가? 대부분의 기업에서 대부분의 고객 주문은 서로 비슷하다. 다만 꽤 자주 일어나지만 일반적인 주문에서 벗어나는 경우는 어떻게 될까? 영업 담당자가 신경을 쓰기에는 너무 적을 수 있지만 회사의 미래 비즈니스 라인이 될 수도 있다(즉, 실질적인 비즈니스 개발). 현실 환경에서 최소 두 개의 하둡 사용 사례를 떠올릴 수 없다면 아마도 하둡이 필요가 없다는 뜻일 것이다.

5. 하이브에 대한 생각이 가장 중요하다
사람들은 SQL을 알고 SQL을 좋아하며 지금까지 SQL을 사용해 왔다. 필자도 안다. 하지만 거기서 더 성장할 수는 없을까? 오래 전으로 거슬러 올라가 생각해 보면, SQL을 처음 배우면서 새로운 세계에 눈을 뜬 어린 아이를 기억해낼 수 있을 것이다. 그 아이가 다른 것을 배운다고 상상해 보라.

누구나 다시 그 아이가 될 수 있다. 최소한 피그(Pig)는 배울 수 있다. 그렇게 (많이) 힘들지는 않다. 그저 PL/SQL에 근육 강화제와 약간의 신 맛을 가미했다고 생각하면 된다. 할 수 있다! 필자는 그렇게 믿는다. 조금 큰 규모의 분석을 하려면 하이브, 피그, 맵리듀스, 우지가 포함된 더 규모가 큰 도구 집합이 필요할 수 있다. "하이브가 할 수 없다면 이 일은 할 수 없다"고 말하지 말라. 빅데이터의 핵심은 하나의 기술로 구현 가능한 범위를 넘어 확장하는 데 있다.


X