데이터과학 무엇을 하는가

#1

책의 초판은 2014년이었고 2018년에 개정판을 출간했는데, 자료가 2013이나 2014로 되어있는 부분들을 본다. 물론 최신 년도로 꼭 업데이트해야하는건 아니지만, 그래도 업데이트 해줬다면 더욱 완성도가 높았을텐데 하는 아쉬움이 든다.

p.28

하둡 파일 시스템은 1개의 데이터 파일에 입력된 데이터를 검색하는 것은 빠르지만, 데이터를 다시 꺼내어 정제하고 업데이트하여 분석하는 전처리(preprocess) 과정에는 효율적이지 못하고, 다양한 통계 분석이나 복잡한 고급 알고리즘을 사용하기 어렵다는 단점이 있다. 아직까지는 몇몇 알고리즘(아파치의 머하웃Mahout 이용)을 제외하고는 오픈 소스든 상업용이든 대부분의 분석 알고리즘이 싱글 노드(single node)로 생성되고 있어, 다양한 분석 알고리즘을 분산 처리하여 하둡에서 적용하기는 어려움이 있다.

하둡 맵리듀스(MapReduce)의 데이터 처리 과정을 조금 더 설명하자면, 맵리듀스는 하나의 빅데이터를 많은 수의 작은 데이터 세트들로 나눈 후에 여러 개의 서버나 컴퓨터로 내보내어 각각의 작은 데이터 세트를 개별적으로 작업한 뒤 다시 합쳐서 모으는 기술이다. 그러나 많은 수의 데이터 세트를 통합하거나 변수의 개수가 아주 많을 경우 맵리듀스의 분산처리 방식의 강점인 빠른 속도를 기대하기 어렵다. 이런 경우에는 하둡보다는 인메모리(In memory)나 인데이터베이스(In database) 방식을 고려하는 것이 비용이 많이 들기는 하지만 더 효과적이다.

p.29

빅데이터 문제는 2000년 이전에도 있었다. 다음 논문들은 1998년과 1999년에 빅데이터를 어떻게 처리, 분석했는지 잘 설명한 논문들이다.

"Squashing flat files flatter," Data Mining and Knowledge Discovery by W. Dumouchel, C.Volinsky, T.Johnson, C.Cortes and D.Pregibon, 1999.

"Cached Sufficient Statistics for Efficient Machine Learning on Large Datasets," Journal of Artificial Intelligence Research, Andrew Moore and Marry Soon Lee, 1998.

p.34

데이터 분석가는 데이터 정제 및 원인 분석과 결과 분석 작업(현황 분석)을 주로 하고, 일부 경험 있는 분석가는 드물게 추정 작업(예측 작업)도 한다. 반면 데이터 과학자는 현황 분석보다는 주로 산업별 전문 지식을 갖고 예측 최적화 작업을 한다.

p.36

단계별 분석 기술 비교

현황 분석 - 과거에 무슨 일이 일어났나?

진단(원인) 분석 - 과거에 왜 그런 일이 일어났나?

예측 분석 - 무슨 일이 일어날 것인가?

예측 최적화 분석 - 어떻게 원하는 결과가 일어나게 할 것인가?

p.39

특히 기초 통계와 기계학습, 수리경제학, 수학, 시계열, 전자공학의 시그널 프로세스를 집중적으로 공부한다면 많은 도움이 될 것이다.

p.39

데이터 과학자를 희망한다면, 단기 특별 교육 과정을 듣는 것보다는 기존의 통계학과나 컴퓨터공학과, 수학과, 수리경제학과 등에서 가르치는 다양한 교과를 대학에서 배우고 빅데이터 시대에 필요하다고 생각되는 과목을 대학원 과정에서 보충하는 것이 더 낫다고 생각한다. 가장 중요한 것은 분야별 현업 경험이다.

p.41

답이 없다는 것을 아는 것도 분석 작업의 성과 중 하나이다. 그리고 더 중요한 것은 왜 답이 없는지 납득할 만한 보고 자료를 만드는 것이다. 의사 결정자가 이해하고 수긍할 수 있는 보고서를 철저히 준비해야 한다. 답을 찾아내는 것보다 이 과정에 훨씬 더 많은 노력과 시간이 든다.

p.41

데이터 과학자는 데이터 품질 전문가가 되어야 한다. 이는 선택이 아닌 필수다! 데이터의 품질은 내 영역이 아니라고 말하는 분석가는 아직 갈 길이 멀다.

데이터의 품질은 데이터 자체의 품질과 내용상의 품질로 나눌 수 있다. 예를 들어 데이터에 빠진(Missing)값이 너무 많거나 숫자 필드에 문자가 들어가 있다면 이건 데이터 자체의 품질 문제이다. 그리고 주소 변수에 정확한 주소가 입력되어 있지 않다면 이건 내용상의 품질 문제이다. 또 다른 내용상의 품질 문제는 시간적으로 적합하느냐이다. 데이터는 늘 현재 시간에 맞게 업데이트되어 있어야 가치가 있다. 데이터는 또한 기준에 맞게 일관성도 있어야 한다. A라는 파일은 시(hour)단위로 이루어져 있는데 같은 내용의 B라는 파일은 일(day) 단위로 이루어져 있다면 다시 변환과 통합을 해야만 이 데이터를 사용할 수 있다.

필자는 데이터를 받으면 일단 수천억 개의 레코드를 눈으로 직접 훑어보고, SQL이나 유닉스 스크립트(Unix Script)로 만들어 문제가 없는지 일일이 검토한다. 이를 소홀히 하면 어떤 분석도 다 헛수고라는 것을 수많은 실수와 시행착오를 통해 몸으로 익혔다. 데이터 자체의 품질 문제는 초급자도 쉽게 찾아낼 수 있지만 내용상의 품질 문제를 찾는 것은 경험이 필요하다. 예를 들어 수천 개의 금융 고객 데이터가 논리상 흐름에 맞게 들어왔는지, 또는 가공된 변수가 정확히 계산되어 맵핑되었는지를 학교에서 배우기는 어렵다. 

p.46

빅데이터 예측 분석과 기계학습 알고리즘을 오픈 소스로 제공하는 헥스데이터(0xdata)는 H_2O라는 빅데이터용 인메모리(in-memory) 분석 엔진을 출시했다. H_2O는 통계나 기게학습, 복잡한 수학을 하둡뿐만 아니라 데스크톱이나 클라우드(아마존 EC2 등)에서도 사용할 수 있게 해준다. R, 엑셀(Excel), JSON(자바스크립트 표준 객체) 등과의 호환도 수월해 다양한 고급 분석이 가능하다고 한다. 현재 온라인 영화 대여회사인 넷플릭스(Netflix)에서 빅데이터 고급 분석 베타 버전으로 테스트 중이라고 하니 결과가 기다려진다. 헥스데이터 홈페이지(http://0xdata.com/h2o-2/)에서 H_2O 시험 버전을 다운로드받아 사용할 수 있다.

p.51

분석 과정 중 특정 알고리즘을 사용해야 하는 경우, 종속 변수가 있는지 없는지를 가장 먼저 살펴보아야 한다. 종속 변수의 유무에 따라 사용할 수 있는 알고리즘이 제한되기 때문이다. 예컨대 종속 변수가 없을 땐 군집 분석과 원인 분석, 이상치(Anomaly/Deviation detection), 연관 법칙(Association rules) 등 몇 가지 알고리즘만 사용할 수 있다. 그리고 변수의 속성에 따라서도 사용할 수 있는 알고리즘이 달라진다. 변수의 값들이 연속적 형태를 띨 경우엔 예측 분석이 가능하고, 이산적 형태를 띨 때는 판별 분석이 가능하기 때문에 상황에 맞게 알고리즘을 선택해야 한다.

p.52

알고리즘	주 활용 분야
업리프트 모델링	단계적 추정, 예측 분석
생존 분석	의료 통계, 설비 분야 사건 예측(이탈, 사망, 고장 등)
회귀 분석	예측 분석, 추정 분석(매출, 신용 점수 등)
시각화	원인과 관계 분석
기초 통계	기초 통계 현황 파악
부스팅, 배깅	분류 분석(일종의 앙상블 기법)
시계열/순열 분석	시간상의 예측(이자율, 예산 등 예측)
요인 분석	요인 분석, 차원 축소
이상치 감지 기법	이상치 분석
텍스트 마이닝	시대 경향 및 감성 분석
의사결정나무	분류(종속 변수 존재)
신경 회로망	분류 분석
군집 분석	독립 변수들만의 분류, 그룹화, 프로파일링
앙상블 기법	분류, 예측 최적화 등의 결합 분석
소셜 네트워크 분석	관계망 분석
연관 법칙	관계 분석, 장바구니 분석 등
서포트 벡터 머신(Support Vector Machine, SVM)	분류 분석
주성분 분석(Principal Component Analysis, PCA)	원인 분석(독립 변수 간의 관계), 차원 축소
추천	몇 개의 기본 알고리즘을 활용하여 상품, 내용, 사람 등 추천(일종의 앙상블 기법)

p.57

데이터 과학자는 검증된 알고리즘을 사용하는 사용자이지 알고리즘 개발자는 아니라는 것을 기억하자.

p.72~73

넷플릭스 플랫폼 구상도

넷플릭스 플랫폼은 소셜 네트워크 기반의 웹 스케일 회사가 아닌 일반 회사에서 빅데이터를 활용한 사례 중 최고의 빅데이터 플랫폼이라 할 수 있다. 하둡을 사용한 대량의 데이터 저장과 실시간 분석 알고리즘을 적용한 추천 엔진 시스템, 그리고 NoSQL을 사용해 비용 절감과 빠른 처리 속도의 프로세스를 구축했다. 넷플릭스는 NoSQL로 카산드라(Cassandra, 아파치의 오픈 소스로 공개된 NoSQL의 분산 데이터베이스)와 이브이캐시(EVcache, 클라우딩 시스템의 인메모리 데이터 스토어)를 사용헀으나, 다른 기업의 플랫폼을 구축할 때는 그 기업의 비즈니스 환경에 맞는 NoSQL을 선택하여 적용하는 것이 중요하다. 예를 들면 페이스북은 사용자들의 관계 데이터와 추천, 그래프 등을 관리하기 위해 네오포제이(Neo4j, 그림을 저장하는 비정형 데이터베이스)도 함께 사용했다고 한다. 또한 넷플릭스는 빅데이터 플랫폼의 파워 사용자인 데이터 과학자와 일반 분석가의 영역을 구분하고 실시간, 준실시간, 오프라인을 구분하여 데이터 트래픽을 조절하였다. 그리고 넷플릭스 플랫폼 본부에는 신뢰성팀(Reliability Team)이 있어, 실시간으로 전체 빅데이터 운영 시스템을 모니터링하고 테스트하여 플랫폼 운영의 신뢰성과 안정성을 감시하고 보장한다.

p.74~77

하둡을 선택하기 전에 고려해야 할 것들

1. 빅데이터가 존재하는가?

빅데이터를 보유하고 있다고 믿는 회사가 아주 많은데 실제로는 그렇지 않은 경우가 많다. 다음은 빅데이터를 실제로 보유하고 있는지 확인해 볼 수 있는 진단 질문이다.

- 몇 테라바이트 이상의 데이터가 존재하는가?

- 주기적으로 대량의 데이터가 유입되는가?

- 얼마나 많은 데이터를 비즈니스에 활용할 예정인가?

미국 내 하둡 사용자들은 500~1,000TB를 저장하는 경우도 꽤 된다. 필자의 생각으로는 전체 데이터 사이즈가 10TB 이상이라면 하둡 사용을 고려해 보는 것도 좋다고 본다.

2. 런타임이 길다는 것을 알고 있는가?

하둡은 런타임(Running Time), 즉 실행 시간이 길다. 프로그램 실행 결과가 나오기까지 지연 시간이 긴 것을 고려해야 한다.

실행 시간에 대한 질문

- 사용자가 얼마나 빠른 런타임(실행 시간) 반응 시간을 기대하는가?

- 어떤 일들을 배치(batch)로 처리할 수 있는가?

3. 온라인, 실시간으로 운영해야 하는가?

하둡은 배치 모드(batch mode) 환경이다. 즉 새로운 데이터가 유입되면 전체 데이터를 처음부터 다시 작업해야 해서 계속 분석시간이 늘어난다. 따라서 실시간 환경에는 적용하기 어렵다.

실시간 운영 여부 질문

- 데이터의 상호 교환 수준이 어느 정도 되기를 사용자가 요구하는가?

- 사용자가 테라바이트급의 대량 데이터를 상호 교환하며 수행하기를 원하는가, 아니면 부분 데이터(subset)를 사용하기 원하는가?

4. 데이터의 원본을 유지하는 것이 중요한가?

하둡의 맵리듀스는 데이터의 관계나 내용을 조금 잃어버려도 문제가 되지 않는 키값의 데이터 구조에 적합하다.

데이터 구조에 대한 질문

- 원천 데이터의 구조가 원천 데이터 그 자체만큼 중요한가, 즉 원천 데이터를 그대로 유지해야 하는가?

- 데이터만큼 또는 그 이상으로 데이터 구조를 반영해야 할 이유가 존재하는가?

5. 맵리듀스를 활용할 수 있는 능력이 있는가?

맵리듀스 프로그램 모델은 특별한 고급 분석 알고리즘이나 특정한 일들을 수행 못하는 경우도 있다. 예를 들어 전체 데이터가 크기는 하지만 수많은 작은 데이터들을 결합해야 하는 경우에는 효율적이지 않다.

맵리듀스 활용 가능 여부 질문

- 기업에 특정 도메인 프로세스가 존재하거나 특별한 고급 분석 알고리즘 사용을 강조하는 경우인가?

- 인프라 기술팀이 맵리듀스로 수행 가능한 분석 알고리즘인지 여부를 분석하여 판단할 수 있는 역량을 가지고 있는가?

6. 하둡을 고려해도 좋을 상황인가?

하둡 고려 여부 질문

- 대량의 텍스트 로그로부터 정보를 추출해야 하는 경우인가?
- 대량의 비정형이나 반정형 데이터를 사용 가능한 정형 구조로 변환해야 하는 경우인가?

- 신용카드 회사처럼 하루의 운영 데이터를 전체 데이터베이스에 당일 내에만 반영하면 되는 경우인가? 다시 말해 주식시장의 주가처럼 실시간으로 가격 변동을 반영할 필요 없이 단독 프로세스로 생성된 데이터 값이 다음 프로세스까지 변화 없이 유지되어도 문제가 없는 경우인가?

p.94~95

클로즈 루프 프로세스란 데이터 수집에서 평가 모니터링까지 원 모양으로 순환하는 데이터 프로세스를 말한다. 다양한 채널에서 생성되는 데이터를 수집, 가공, 분석해 실행 가능한 조치를 현업에 적용하게 되는데, 적용한 후 최소 3개월에서 6개월까지는 아무 일도 일어나지 않을 수 있다. 더러는 그 기간이 1년까지 길어지기도 하는데, 이렇게 긴 기다림 끝에 넘겨받은 데이터를 다시 평가, 분석하고 그 결과를 다음 개발 작업에 또다시 반영한다. 이러한 작업을 반복하여 조금이라도 더 발전된 실행 조치를 지속적으로 현업에 반영하는 순환 프로세스다.

p.