Share           Pin It

빅데이터를 위한 하둡 Hadoop이나 머신러닝 라이브러리인 마훗 Mahout의 디테일한 것을 설명하려는 것이 아닙니다. 그냥 마훗의 추천 알고리즘을 실행해본 수준에서 경험했던 프랙티스에 대한 간단한 리마크만 하겠습니다. 하둡이나 마훗에 대한 상세 설명이나 설치/설정 방법에 대해서는 다른 문서들을 찾아보시기 바랍니다. 특히 마훗의 아이템기반CF의 상세한 사용방법은 위키페이지를 참조하세요.

먼저 마훗CF를 사용하기 위한 입력데이터는 {UserID, ItemID, Rating} 페어로 된 CSV 파일이 필요합니다. 마지막 값인 Rating은 암묵점수에서는 넣을 필요없이 하둡/마훗을 실행할 때 옵션 --booleanData를 활성화시키면 됩니다. 여기서 중요한 점은 UserID와 ItemID가 모두 Long integer 형태여야 합니다. 스트링타입을 Long타입으로 변경하려면 마훗 라이브러리에 포함된 MemoryIDMigrator() 클래스를 이용해서 매핑 & 역매핑하시면 됩니다. 그냥 스트링타입의 데이터를 입력하면 java.lang.NumberFormatException.forInputString 익셉션이 발생합니다.

준비된 유저-아이템 레이팅 CSV 파일을 HDFS에 올려놓고 실행시키면 됩니다. 실행하는 방법은 크게 세가지가 있습니다. 아래는 아이템기반CF를 중심으로 명시했습니다. 

  • 마훗 라이브러리를 이용해서 Java 등의 프로그램으로 직접 구현해서 실행하는 방법 (인터넷에 찾아보면 예제파일 있음)
  • 하둡을 이용해서 마훗을 실행하는 방법 (hadoop jar /../mahout-core-0.7-job.jar org.apache.mahout.cf.taste.hadoop.similarity.item.ItemSimilarityJob --OPTION)
  • 마훗을 바로 실행하는 방법 (/../mahout/bin/mahout itemsimilarity --OPTION)

사용되는 옵션은 위키페이지에 자세히 명시되어있습니다. 하둡을 이용해서 마훗을 실행하면 좋은 점이 하둡 옵션을 지정해서 맵리듀스 사이즈를 별도로 정할 수 있다는 점입니다. (-D mapred.reduce.tasks=X)

대용량 데이터를 처리하기 위해서 하둡 및 마훗을 사용했는데, 유사도 (Similarity Measure)를 어떤 것을 사용하느냐에 따라서 Java Heap Size 문제가 발생하기도 했습니다. 다음검색에서 블로그글의 한달치 클릭로그로 테스트해봤는데, 간단한 Tanimoto를 사용했을 때는 별다른 문제가 발생하지 않았는데, 다른 measure로 변경했을 때는 메모리 에러가 났습니다. 실서비스를 위해서 안정적인 계산이 필요한 경우에는 데이터 사이즈 및 유사도를 미리 잘 테스트해 볼 필요가 있습니다. (유사도는 --similarityClassname 옵션을 사용해서, 위키에 지정된 것들을 사용하면 됩니다.)

인풋파일은 따로 명시되지 않고 지정된 하둡 디렉토리 (--input /../input)의 모든 CSV 파일들을 그대로 사용하는 듯하고 (확인필요), 아웃풋파일은 지정된 하둡 디렉토리에 (--output /../output)에 생성됩니다. 파일 이름의 컨벤션은 정확히 기억나지 않습니다. 직접 확인해보세요. 옵션 중에 maxSimilaritiesPerItem이 있는데, 처음에는 아이템별로 유사 아이템 개수를 지정해주는 것으로 이해했지만, 테스트해보니 아웃개수 (아이템수)를 지정하는 옵션이 아닌 듯합니다.

하둡/마훗을 사용하기에 잘 정리하지는 못했지만, 이 정도의 설명도 없어서 처음에는 조금 당황했던 기억이 납니다. 잘 사용하셔서 좋은 성과 얻으시기 바랍니다.

추천시스템 전체 목록

  1. 추천 시스템과의 조우 (PR시리즈.1)
  2. 추천 시스템을 위한 데이터 준비 (PR시리즈.2)
  3. 추천대상에 따른 추천 시스템의 분류 (PR시리즈.3)
  4. 알고리즘에 따른 추천 시스템의 분류 (PR시리즈.4)
  5. 추천 시스템을 위한 유사도 측정 방법 (PR시리즈.5)
  6. 추천 시스템의 성능 평가방법 및 고려사항 (PR시리즈.6)
  7. 추천 시스템에서의 랭킹과 필터링 문제 (PR시리즈.7)
  8. 추천 시스템의 쇼핑하우 적용예 (PR시리즈.8)
  9. 개인화 추천 시스템에 대하여 (PR시리즈.9)
  10. 추천 시스템의 부작용 - 필터버블 (PR시리즈.10)
  11. 추천 시스템의 레퍼런스 (PR시리즈.11)
  12. 추천 시스템에 대한 잡다한 생각들 (PR시리즈.12)
  13. 추천 시스템을 위한 하둡 마훗 사용하기 (PR시리즈.13)
  14. 추천 시스템에 대해서 여전히 남은 이야기들 (PR시리즈.14)

==

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

며칠 전에 VectureBeat에 Guy Harrison이 적은 Why Hadoop projects fail -- and how to make yours a success라는 기사를 간단하게 정리했습니다. 전체를 번역하는 데는 무리가 있어, 큰 흐름에서 의역 및 생각을 추가했습니다. 자세한 내용은 원문을 참조하시기 바랍니다.

---

클라우드 컴퓨팅이 각광을 받으면서 빅데이터, 특히 하둡은 기업IT의 메인스트림으로 들어왔지만, 무분별한 실행은 애초의 기대/약속을 충족시키지 못하고 값비싼 실패, 소위 하둡행오버 Hadoop Hangover를 경험할 가능성이 높다.

빅데이터는 구글이나 아마존의 성공을 가능케했다. 단순히 차트나 레포트를 통한 실행결정을 하는 것이 아니라, 사용자 경험을 증진시키는 비즈니스 프로세스에 직접적으로 연결된 데이터 기반의 알고리즘이다. 현재 많은 기업들이 단순히 다양한 출처의 원본 데이터를 수집, 저장하는 단계에 머무르고 있다. 데이터를 수집하고 그것의 의미를 파악하는 것만으로는 충분치 않다. 그렇기에 빅데이터 분석이 필요한데, 많은 데이터가 모일수록 덜 복잡한 알고리즘이 필요하다. (개인적으로 더 정확한 알고리즘보다 더 간단하면서 빠르면서 적응적인 알고리즘이 빅데이터 시대에 더 적합하다고 생각함) 그리고 머신러닝과 결합하여 더 많은 데이터는 더 정확한 예측 및 실행모델을 만들지만, 여전히 가장 좋은 답을 얻기 위해서는 인간의 경험과 지능이 필요하다. 데이터 수집은 빅데이터의 단지 시작일 뿐이고, 옳은 질문에 바른 대답을 제시하는 스마트 알고리즘이 필요하다.

구글이나 아마존이 성공한 이유는 많은 데이터를 수집했기 때문만이 아니라, 우수한 인재들이 모여있기 때문이다. 그들은 프로그래밍 스킬이 띄어날 뿐만 아니라, 복잡한 통계 분석 능력, 비즈니스 인사이트, 인지과학 및 창의적 문제해결 능력을 갖춘 인재들, 즉 데이터 과학자들이다. 불행히도 그런 다양한 기술 (통계, 알고리즘, 분산컴퓨팅 등)을 갖춘 인재는 늘 부족하고, 학교에서는 학위 이수정도의 커리큐럼만 가지고 있을 뿐이다. 데이터 과학자들이 늘어나겠지만, 그들은 적어도 경쟁적 비즈니스 전략, 머신러닝 알고리즘, 그리고 대용량 분산/패러렐 데이터 프로그래밍이라는 3가지 분야에 두루 전문성을 가지고 있어야지만이, 기업이 빅데이터 기반으로 미래를 예측하는데 일조할 수 있다. (즉, 기업에서 필요한 인재는 데이터 과학자이고, 그들은 전략, 알고리즘, 프로그래밍(의 조합)에 전문성을 가져야 한다.)

그리고 데이터 과학자들이 활용할 충분한 빅데이터툴도 여전히 부족하다. 맵리듀스 프로그래밍만으로는 빅데이터를 제대로 활용하는 실용적인 방법이 아니다. 빅데이터에서 빅밸류/빅인사이트를 얻기 위해서는 데이터 과학자들이 다양한 통계가설을 테스트하고, 예측모델을 만들고, 결과를 리포팅하고 비쥬얼라이즈해줄 수 있는 도구들이 필요하다. Mahout, Weka, R 등의 오픈소스들이 존재하지만, 여전히 사용하기 쉽지 않고 때로는 기업이 가진 빅데이터를 충분히 수용할만큼 스케일러블하지도 않다. 그래서 기업에서 빅데이터를 제대로 활용하기 위해서는 하둡 및 하둡에코 이상의 빅데이터 분석플랫폼 및 툴킷이 필요하다.

하둡이 많은 데이터를 경제적으로 저장, 처리할 수 있을 뿐만 아니라, 다양한 형태의 데이터를 수용할 수 있기 때문에 성공했다. 그런데 그런 다양한 포맷의 데이터가 제대로 활용되기 위해서는 포맷변경이 필요하다. 하둡은 schema on read를 허용해서 다양한 원본 데이터를 처리할 수 있지만, 여전히 적절한 데이터 스키마를 작성해야 한다. 그러나 자동으로 수집되는 데이터들은 구조가 자주 바뀌고 나중에는 구조를 제대로 파악하기가 힘들어진다는 위험도 내재한다. 그리고 데이터 생성시에 발생한 오류가 너무 늦게 발견되기도 한다. 그래서 데이터 디자인 및 수집 단계에서부터 데이터의 품질과 구조에 많은 주의를 기울일 필요가 있다.

하둡이 복잡한 분석능력을 제공해주지만 여전히 내재된 문제점들이 존재한다. 하둡의 보안성이 여전히 취약하고, 데이터 백업이 어렵고, 기업 내의 기존 모니터링 시스템과의 통합이 부족하고, 리소스 관리가 초보적이고, 실시간 쿼리가 불가능하다. 이런 점들을 고려해서 하둡 프로젝트를 진행해야 한다.

빅데이터는 많은 기업들에게 분명 복잡하지만 잠재력을 가진 파괴적 도전이다. 이제 가격경쟁력이나 애향심만으로는 부족하다. 개인화, 타게팅, 예측추천모델 등의 경쟁적인 차별화가 필요하다. 데이터 기반의 결정 및 실행 능력을 획득하는 것이 생존에 필수적이다.

---

읽으면서 스마트한 빅데이터 분석을 위해서는 결국 기술 지식, 도메인/비즈니스 로직, 그리고 사람에 대한 이해가 필요하다는 것을 느꼈습니다.

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

지난 글에서 (빅데이터) 분석 플랫폼에 대한 생각을 적었습니다. (참고. 데이터 분석 플랫폼에 대한 고민) 그냥 잊어버리려했지만 계속 머리 속에서 생각이 더 구체화되고 있습니다. '아키텍트가 필요하다' 글에서도 밝혔듯이 현실적으로 어려운 여건들이 많이 있지만, 전체 퍼즐을 완성하기 전에 부분 그림은 맞출 수 있을 것같다는 느낌이 옵니다. 데이터를 준비하는 과정은 서비스나 도메인에 따라서 최적화시켜야하는 부분이어서 지금 시점에서 구체적인 안을 제시할 수가 없고, 또 분석된 결과를 해석해서 더 가치있는 인사이트로 전개하는 것은 단기간에 해결될 수 있는 것도 아닙니다. 그리고 빅데이터를 위한 하드웨어 및 소프트웨어 인프라를 설계하고 개발하는 것도 제 영역/능력을 벗어난 일입니다. 그렇다면 현시점에서 당장 할 수 있는 것은 분석 시스템 자체의 기능을 공부하고 구현해두는 것밖에 없습니다. 그래서 현재 존재하는 다양한 빅데이터 관련 기술들을 조사해서 분석 시스템에 어떻게 활용될 것인가?를 먼저 생각해보기로 했습니다. 잘 진행이 된다면 팀 내에서 각각의 파트를 나눠서 공부해서 각 파트의 전문가를 한두명씩 양성할 수 있으면 좋겠다는 생각도 해봅니다.

하드웨어 인프라가 갖춰지면, 기본적인 소프트웨어 인프라는 설치하고 설정할 수 있어야 합니다. 모든 소프트웨어 패키지들을 설치할 필요는 없겠지만, 기본적으로 하둡 Hadoop 시스템이나 Hive와 Pig와 같은 스크립팅 시스템은 설치/설정할 수 있어야 할 것이고, 필요에 따라서 카산드라, MongoDB나 HBase와 같은 NoSQL도 설치/설정이 가능해야할 것이고, 그 외에 ZooKeeper와 같은 기반 환경 등도 최적화할 수 있어야 할 것입니다. 분석가의 입장에서는 조금 귀찮은 일이기도 하지만, 설치와 최적화라는 삽질을 통해서 더 시스템을 더 잘 이해하고 활용할 수가 있습니다. 팀에서 처음 하둡 등을 설치할 때, 저도 잘 모르지만 함께 참여해서 다양한 시도를 해봤더라면 지금 빅데이터 시스템을 더 잘 활용하고 있을텐데라는 후회가 늘 따릅니다.

이제 HW/SW 인프라라 세팅되었다면, Java나 Python과 같이 자신에게 편한 프로그래맹 랭귀지로 간단한 데이터에서 작동하는 MapReduce 알고리즘정도는 구현해볼 필요가 있습니다. 하이브나 피그와 같이 다양한 스크립팅 시스템도 개발/지원되고 있지만, 그것들은 테스트 환경이나 프로토타입을 위해서 장려될 뿐, 궁극적으로 서비스를 위해서는 좀더 네이티브한 랭귀지로 최적화, 안정화될 필요가 있습니다. 하둡이 Java로 구현되었기 때문에 자바를 통합 맵리듀스 구현이 가장 바람직하겠지만, 최근에 파이썬 등에서도 많이 최적화되었기 때문에 자신이 편한 개발환경에서 다양한 프랙티스를 해볼 것을 권합니다.

다음으로 필요한 것은 Hive나 Pig와 같은 스크립팅 랭귀지를 마스터하는 것입니다. 자바나 파이썬 등이 편한 개발자가 굳이 스크립팅 언어까지 배울 필요가 있을까?라는 생각도 듭니다. 더우기 사용성에 초점을 둔 스크립팅 언어는 컴파일이 필요한 네이티브들보다는 다양한 활용에 -- 비정형 데이터처리 등과 같은 -- 제약이 많습니다. 그러나 빠르게 구현해서 바로 실행시켜볼 수 있다는 장점이 있기 때문에, 프로토타이핑 단계에서는 스크립팅언어로 그리고 시스템화에서는 네이티브언어로 구현하는 것은 여러 모로 도움이 됩니다. 피그보다는 하이브가 더 SQL과 가깝기 때문에 팀내에서는 일단 하이브의 사용을 권장하고 있습니다. 그리고 밑에서 적겠지만 R을 이용하는 RHive를 사용할 것이라면 Hive에 익숙해질 필요가 있습니다.

그리고 데이터분석이라면 머신러닝을 빼놓을 수 없습니다. 다양한 문서들과 (검색) 로그들을 활용하기 위해서 단순 카운팅이나 몇몇 독립적으로 배포된 알고리즘들은 사용해보고 있지만, 일반적으로 머신러닝으로 알려진 ANN이나 SVM 등과 같은 것들을 비정형 빅데이터에 적용해보는 것은 아직 엄두도 못 내고 있습니다. 그러나 사람들의 생각은 모두 비슷한가 봅니다. 이미 Mahout이라는 이름으로 아파치에서 빅데이터를 위한 머신러닝 오픈프로젝트가 진행중입니다. 저도 Mahout이라는 이름만 들어봤지, 실제 어떻게 이용되고 있는지에 대한 정보는 없습니다. 대충 훑어보니 SVD, 베이지언, 클러스터링 등의 기능들이 포함되어있어서 안정화되면 분석플랫폼에서 아주 유용하게 쓸 수 있을 듯합니다. Mahout 얘기를 하다보니 학교 다닐 때 들었던 Weka라는 자바용 머신러닝 라이브러리가 얼핏 떠오릅니다. ... 아직은 초기/불안정한 단계에 있지만 Mahout도 초반부터 공부해둘 필요가 있을 듯합니다.

그리고 빅데이터가 뜨면서 함께 주목받는 통계 패키지가 있습니다. 바로 R 입니다. SAS나 매트랩 등의 고가의 소프트웨어에 비해서, R은 통계전공자들에게 늘리 이용되고 있는 오픈/프리 소프트웨어입니다. 그런데 R은 빅데이터/하둡과 연결되어 R이 가진 다양한 통계 기능/라이브러리를 빅데이터에 바로 이용할 수 있습니다. Mahout과 같은 빅데이터-네이티브가 아니라서 아직은 훨씬 더 불안정하고 제약사항이 많지만, 큰 프로그램을 구현하기에 앞서 기존의 패키지로 다양한 테스트를 해볼 수가 있기 때문에 유용합니다. 주변에서 R과 하둡을 함께 사용하는 팀이 있는데, 아직은 많이 불안정하다고 합니다. 그냥 초기에 히스토그램을 그려보거나 초기 파라메터값을 설정하는 용도정도의 제한된 사용만 하고 있다고 합니다. 레볼루션 애널리틱스의 R+Hadoop과 국내 NexR의 RHive가 현재 사용중입니다. 저도 일단은 R을 공부해보기로 했습니다. 책도 구입하고 웹의 다양한 튜토리얼도 보고 있지만, 오랜만에 새로운 랭귀지를 공부하는 거라서 쉽지가 않습니다. 매트랩에서는 행렬, SAS에서는 DataSet의 특성을 잘 파악하면 되었듯이, R에서는 벡터를 잘 이해/활용하면 R 좀 쓴다는 말을 들을 수 있을 것같습니다.

마지막으로 데이터 시각화 도구와 결과 리포팅 기능이 필요합니다. 이미 지난 글에서도 적었듯이 (참고, 데이터 시각화 도구들) 웹에서 데이터를 다양한 도표와 그림으로 시각화해주는 오픈소스들이 많이 있습니다. 물론 앞서 언급했던 R에서도 다양한 시각화가 가능합니다. 그러나 R은 여전히 불안정하고 또 웹을 통한 인터렉티브 그래프를 제공해줄 수가 없기 때문에, 자바스크립트 등을 이용한 웹 시각화 도구에 대한 공부가 필요합니다. 그리고 단순히 어떤 시각화 도구를 사용할 것인가보다는 데이터를 어떻게 표현하는 것이 가장 효과적인가에 대한 고민이 더 필요합니다. 예를들어, 같은 데이터라도 막대그래프가 적절할 때가 있고 파이그래프가 더 적절할 때가 있습니다. 그렇듯이 어떻게 보여줄 것인가? 그래서 어떤 효과를 낼 것인가?를 고민하는 것이 어떤 툴을 이용할 것인가보다 더 중요합니다.

요즘 계속 이런 저런 생각들로 머리가 복잡합니다. ... 두서없이 적었지만, 빅데이터 분석에 관심이 있는 초보자들에게는 그래도 도움이 되었으면 합니다. 앞으로는 좀 더 기술적인 것들도 능력이 되는대로 다루겠습니다.

(2013.01.18 작성 / 2013.01.23 공개)

댓글을 달아 주세요