[Data Science / Articles] 최악의 빅데이터 프랙티스 10가지

원문 : http://www.itworld.co.kr/news/88583

물론 누구나 빅 데이터를 도입할 수 있다. 그러나 항상 제대로 활용되는 것은 아니다. 꼭 피해야 할 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에 근육 강화제와 약간의 신 맛을 가미했다고 생각하면 된다. 할 수 있다! 필자는 그렇게 믿는다. 조금 큰 규모의 분석을 하려면 하이브, 피그, 맵리듀스, 우지가 포함된 더 규모가 큰 도구 집합이 필요할 수 있다. "하이브가 할 수 없다면 이 일은 할 수 없다"고 말하지 말라. 빅데이터의 핵심은 하나의 기술로 구현 가능한 범위를 넘어 확장하는 데 있다.

6. HBASE를 RDBMS처럼 다루기

사람들은 하둡에 대해 알아보다가 비로소 데이터베이스가 있음을 깨닫곤 한다. 카산드라(Cassandra)를 찾을 수도 있지만 대부분의 경우 HBase를 발견하게 된다. 휴...데이터베이스가 있다면, 그렇게 힘들게 애쓰지 않아도 된다! 장담컨대, HDFS+하이브는 뇌를 그다지 혹사시키지 않는다(IANAD).

HBase와 RDBMS의 유일한 공통점은 둘 다 테이블과 비슷한 무언가를 갖고 있다는 점이다. RDBMS로는 해결하기 어려운 일을 HBase로 거뜬히 할 수 있고, 그 반대의 경우도 있다. HBase는 HBase가 적합한 용도에 유용하지만 그 외에는 대부분 별 쓸모가 없다. 전체 RDBMS 스키마를 있는 그대로 HBase에 표현하려고 시도했다간 머리가 타는 듯한 두통을 느끼게 될 것이다.

7. 100개의 노드를 수동으로 설치하기

내일모레까지 100개의 노드에 하둡과 하둡의 모든 구성 요소를 수동으로 설치한다고? 수작업의 손맛이야말로 최고라 할 수 있지 않은가? 분명히 재미있는 일이다. 누군가 노드를 잃고 그것까지 수작업으로 처리할 때까지는 그렇게 느낄 수도 있다. 최소한 퍼펫(Puppet)을 사용하라. 사실 암바리(Ambari, 또는 사용 중인 배포판에서 이와 유사한 것)를 먼저 사용해야 한다.

8. 데이터 노드의 RAID/LVM/VM화

하둡은 여러 노드에 걸쳐 데이터 블록을 스트라이프하고, RAID는 이를 여러 디스크에 걸쳐 스트라이프한다. 이 둘을 합치면? 엄청난 지연과 열악한 성능의 향연이다. 이건 터덕킨(turducken)도 아니고, 칠면조 안에 칠면조를 넣고 굽는 것과 같은 짓이다. 마찬가지로 LVM은 내부 파일 시스템용으로 훌륭하다. 그러나 예를 들어 데이터 노드 몇 개를 추가하면 될 일을 두고 데이터 노드 100개의 크기를 더 늘리기로 결심하는 경우는 거의 없을 것이다.

그리고 모두가 좋아해 마지않는, I/O에 따라 좌우되는 SAN이 있다. 높은 순간 전송률을 위해 HDFS를 사용하면서, 다시 모든 것을 박스 안에 집어넣어 붙인다? 이 개념은 수평적 확장이다. 동일한 네트워크 파이프에 걸쳐, 동일한 디스크 박스로 어떻게 수평 확장하겠다는 말인가?

EMC는 앞으로 더욱 많은 SAN을 판매하겠지만 이제 그 틀을 벗어나 생각을 해봐야 한다. VM은 좋다. 그러나 최고의 성능에는 I/O가 핵심이다. 하둡의 이름 노드와 나머지 대부분을 가상화할 수 있지만 데이터 노드에 있어서는 베어메탈 이상은 없다. devops 도구를 통해 가상화의 이점을 거의 동일하게 얻을 수 있다. 심지어 클라우드 업체들도 대부분 메탈 옵션을 제공한다.

9. HDFS를 그저 파일 시스템으로 다루기

HDFS에 뭔가를 던져 넣는다고 해서 무조건 유리한 것은 아니다. 물론 HDFS 주변의 도구 사용은 중요하다. 하이브, 피그, 맵리듀스를 적용할 수 있지만 무엇을, 왜, 어디서 HDFS에 집어넣을 것인지에 대해 생각을 해야 한다. 이 모든 것들을 어떻게, 누구를 위해 보호할지 생각해야 한다.

10. 와, 멋지다!

다른 표현은 "오늘은 목요일이니까 스파크(Spark)로 가자". 물론 하둡은 성장하는 생태계이며, 사람들은 경쟁에서 앞서 나가고자 한다. 그 마음은 알지만 자유란 '더 이상 잃을 게 없음'의 또 다른 말이라는 점을 유의하라. 실제 데이터와 실제 사용자를 보유하게 되면 책임질 부분이 없었던 때와 같은 자유를 그대로 누릴 수는 없다. 이제는 계획이 필요하다.

다행히, 그 발전을 관리하고 책임감 있게 앞으로 전진하기 위한 도구가 있다. 갓 나온 새로운 기능을 곧바로 배포할 필요는 없지만 더 이상 하둡 1.1을 사용할 필요도 없다. 다른 모든 기술과 마찬가지로(또한 인생의 모든 것이 그렇듯이) 무리에서 맨 뒤에 처진 가젤, 또는 절벽에서 가장 먼저 떨어지는 레밍이 되지 않기 위한 적절한 방법을 찾아야 한다.