[Data Engineering] 빅테이터란? 빅데이터 정의/예/처리방식의 변천/시스템 구성, 하둡 성공 스토리

📌 목차

• 빅데이터 정의
• 빅데이터의 예
• 빅데이터 처리방식의 변천
• 빅데이터 시스템의 구성
• 하둡 성공 스토리들
• 빅데이터 도입 시 유념사항
• 빅데이터 관련 회사들
• 빅데이터 시스템의 미래

 

🍀 빅데이터 정의

빅데이터를 여러 군데서 정의를 했다.

1. "서버 한대로 처리할 수 없는 규모의 데이터"
   • 2012년 4월 아마존 클라우드 컨퍼런스에서 아마존의 data scientist인 존 라우저가 내린 정의
   • 분산 환경이 필요하느냐에 포커스
   • '서버 여러대에서 처리 = 분산환경' 필요함
2. "기존의 소프트웨어로는 처리할 수 없는 규모의 데이터"
   • 대표적인 기존 소프트웨어 
     • 오라클/MySQL과 같은 관계형 데이터베이스 (대부분 Single Machine, 서버 한대에서 돌아가는 소프트웨어)
     • 많은 경우 분산환경을 염두에 두지 않음
     • Scale-Up 접근방식 : CPU, 서버 성능이 올라가면 자동으로 소프트웨어 성능이 올라감. 기존 소프트웨어 로직을 최적화해서 소프트웨어 자체 성능을 높이는 방식. (Single Load에서 성능 높이기 위함)
       • CPU frequency를 높이는 것이 목적인데, 5기가가 최대인데 발열이 심해 지원하지 않음. 그래서 CPU 내에 core를 여러 개 두어서 일을 나눠서 할 수 있게끔 CPU 발전이 이뤄졌음.
       • 소프트웨어도 비슷하게 한 서버에서 돌아가는 게 아니라 여러 서버/컴퓨터에서 돌아가게 하는 방향으로 발전되었음. 👇🏻
     • Scale-Out 접근방식 : 기존 소프트웨어/CPU는 대부분 그대로 유지하고 같은 일을 하고 있는 소프트웨어 인스턴스를 분산화시켜서 병렬로 처리하거나 분산형으로 변화하는 방식. (분산환경으로 성능 높이기 위함)
       • 기존 소프트웨어/하드웨어를 그대로 복제해서 사용할 수 있다는 장점이 있음.
       • 저가형, 중저가형 서버를 이용해서 이 서버들을 여러 개 두고 그 안에서 소프트웨어를 구동하는 방식이라서 일반적으로 가성비가 좋음.
3. 4V (Volume, Velocity, Variety, Variablity)
   • IDC와 같은 컨설팅 업체가 가장 많이 사용하는 정의
   • Volume : 데이터의 크기가 대용량
   • Velocity : 데이터의 생성속도
   • Variety : 구조화/비구조화 데이터
     • 정형/비정형 데이터로 얘기함.
     • 엑셀, DB는 정형 데이터라고 함. 데이터의 형태가 레코드, 테이블이라는 형태로 정해져 있어서 구조화 데이터라고 함.
     • html은 semi structured라고 함. 반정형화라고 하는데, tag를 이용해서 형태는 있지만 완전히 관계형 DB나 엑셀처럼 완전히 정형화되어 있지 않음.
     • text는 구조화된 형태가 없기 때문에 비구조화된 데이터라고 함.
   • Variablity : 데이터의 포맷 변화
     • JSON, html, protocol buffer 등 데이터를 저장하고 읽어가고 해석하는 포맷이 다양함.

아마 현재는 4V의 관점에서 빅데이터를 가장 많이 설명하는 것 같다.

 

🍀 빅데이터의 예

1. 검색 엔진 데이터
   • 전세계 수천억개의 웹페이지들을 크롤, 인덱싱
   • 웹페이지 그래프를 기반으로 페이지랭크 계산
     • 크롤은 실제 검색 엔진 데이터를 만들어주는 서버가 전세계에 있는 수천억개의 웹페이지들에 http로 실제 접근해서 웹페이지 다운로드를 먼저 받고 인덱싱을 함. 인덱싱은 질의할 수 있는 단어 별로 그 단어에 가장 적합한 웹페이지를 분류하는 작업임!
     • 다시 말하면 검색 엔진 데이터를 만들려면, 그 서비스를 제공하는 회사의 데이터 센터에 있는 서버들이 전세계에 있는 웹서버들에 다 접속해서 웹페이지들을 다 다운로드 받음(=그 데이터를 저장함).
     • 이런 데이터들이 사이즈도 크고, 웹페이지들이 추가되고 변화되기에 생성 속도고 크다고 봄. 구조 형태도 html이 대부분이고 외부를 통해 다운로드 받는 게 html 뿐만 아니라 pdf, ms에서 제공하는 office로 만들어내는 file 등으로 데이터 형태가 다양함. 따라서 검색 엔진 데이터도 빅데이터의 한 예가 됨.
   • 사용자 검색어와 클릭로그
     • 이를 기반으로 한 각종 마이닝 가능
       • 동의어 찾기
       • 통계기반 번역
       • 검색입력 자동 완성
     • 실제 검색 엔진 자체에서도 빅데이터를 생성해냄. 검색어와 클릭에 대한 로그도 빅데이터라고 볼 수 있음.
2. 디바이스 데이터
   • 주로 센서 데이터라고 생각하면 됨. 
   • 모바일 디바이스
     • 위치정보 (GPS)
     • 전세계 사용 중인 스마트폰 개수를 생각하면, GPS 정보도 빅데이터라고 볼 수 있고 생성 속도도 빠름. GPS 정보는 위치이기 때문에 비교적 정형화되어 있는 데이터임. 
   • 스마트 TV
     • 어떤 것들을 보고 있고 뭘 클릭하는지 빅데이터라고 볼 수 있음.
   • 각종 센서 데이터
   • 네트워킹 디바이스
     • AP, 무선 인터넷 쓸 때 사용하는 디바이스들도 실시간으로 로그 데이터들을 만들어 내고 이 데이터도 빅데이터라고 볼 수 있음.
3. 소셜 네트워크 데이터
   • 트위터, 페이스북 등의 소셜 미디어에서 만들어내는 데이터
     • 트위터의 예: 1억 4천만명의 사용자가 하루 3억 4천만개의 트윗 (2012.06 기준)
   • 비즈니스 분야에서 굉장히 유용하게 활용 가능한 데이터
     • 새로운 마케팅 및 광고 타게팅의 기본 데이터
     • 사용자들의 관심사를 이용하고 보게 하는 것도 유도할 수 있음.
4. 웹 서버 로그
   • 웹서비스 회사의 경우 대규모의 사용자 로그 생성
   • 세션 레벨 분석이 중요
     • 세션: "한 사용자의 일련의 페이지 방문"
     • 이를 통해 어떤 서비스의 유입 패턴 등의 분석 가능
   • 쇼핑 사이트의 예
     • 구글에서 검색을 통해 들어오는 트래픽에서 가장 많은 돈을 벌어다주는 검색어는 무엇인가?
     • 쇼핑몰 사이트 생각하면, 해당 쇼핑몰에 로그인함. 로그인한 사용자에게 쇼핑몰 회사의 서버가 일종의 세션을 할당함. 세션이라는 것은 로그인된 사용자와 매핑되어 있는 가상의 연결이고, 이 세션을 통해서 우리가 어떤 사이트에서 어떤 것을 검색하고 구매하는지, 취소하는지 등의 로그를 남김. 
   • 이쪽의 최강자는 Splunk

 

🍀 빅데이터 처리방식의 변천

아파치 하둡을 기반으로 프로그래밍할 건데, 아파치 하둡을 처음 만든 분들이 근무한 곳이 야후다. 야후에서 도입해서 사용하고 변경되는 히스토리를 본다.

🔅 야후 검색팀의 예 (하둡 사용 전)

• 크롤, 색인, 그래프 생성을 위해서 조금씩 다른 자체개발 소프트웨어들을 사용. ✔️ 
  • 중복투자 및 유지보수의 문제
    • 세 가지 모두 일종의 분산처리시스템으로 자기가 하는 일에 최적화 되었지만, 많은 부분에 공통점들이 존재함. 
    • 분산처리 시스템을 이용해서 여러 개의 서버에서 돌고 있는 소프트웨어들이 동작하고 있을 때 하나의 서버가 고장나더라도 나머지 서버에서 처리할 수 있거나 새 서버를 할당 받아서 장애가 난 서버가 하는 일을 대신하게 한다던지 하는 로직이 부가적으로 들어가게 돼있음.
    • 스케줄링(작업의 순서를 정함)이 공통적으로 들어가게 돼있음. 분산처리 하다보면 모든 서버가 비슷한 수준을 갖고 일을 하면 좋은데 그렇지 못한 경우가 많기에 그 점을 해소하고 모든 서버가 비슷한 사용률을 갖도록 처리하는 스케줄링도 들어가있음.
    • 이 외에도 굉장히 많은 부분에서 세가지 소프트웨어가 비슷한 일을 하고 있는 것을 알게 되었고, 그럼 중복으로 개발한 것이고 유지보수는 개별 소프트웨어 별로 이루어지기 때문에 문제가 있음. 
  • 야후 밖에서 전혀 쓸모가 없음
    • 개인의 스킬셋 제약 및 Hiring 과점에서도 문제.
    • 각 팀에서 채용할 때도 문제가 될 수 있음. 너무 전형 소프트웨어라 교육의 문제도 있음.
• 검색 로그의 경우 용량 문제로 데이터의 전수조사 불가
  • 마이닝 샘플링에 의존
  • 데이터 액세스 자체가 쉽지 않았음.
    • 이것 역시 복잡한 승인 프로세스로 시간이 걸렸음.

 

🔅 하둡이란?

• Doug Cutting이 구글랩에서 발표한 두개의 논문에 기반해 2005년 만든 오픈소스 프로젝트
  • 구글에서 만든 검색 엔진에 들어가는 2가지 core 기술 
    • 2003년 The Google File System : 빅데이터를 저장하는 것에 초점.
    • 2004년 MapReduce: Simplified Data Processing on Large : Google File System에 저장되어 있는 데이터를 분산 처리 해주는 프로그램 패러다임이자 프로그래밍 시스템. 
    • 원래는 오픈소스 아니었음.
  • 처음 시작은 Nutch라는 오픈소스 검색 엔진의 하부 프로젝트
    • 검색 엔진은 당연히 빅데이터를 저장하고 인덱싱할 수 있어야 하므로 Google File System과 같은 빅데이터를 저장할 수 있는 저장용 소프트웨어, 저장되어 있는 빅데이터를 분산처리 해줄 수 있는 MapReduce와 같은 분산처리 프레임워크가 필요하게 되어서 시작됨.
    • 하둡은 Doug Cutting의 아들의 코끼리 인형의 이름.
    • 아파치 하둡이 유명해져서 2006년 아파치 톱레벨 별개 프로젝트로 떨어져나옴. 
  • 크게 분산파일시스템인 HDFS와 분산처리시스템인 MapReduce 두개의 컴포넌트로 구성됨.

 

🔅 야후 검색팀의 예 (하둡 도입 초반)

• 2006년 초 Doug Cutting을 영입하여 하둡 도입을 실험. 20노드(서버 20개) 하둡 클러스터 셋업.
• 2008년 1000+ 노드 하둡 클러스터를 셋업.
  • 웹페이지 그래프 계산을 하둡으로 포팅
• 2009년 30여개의 마켓의 모든 검색어를 하둡에 저장하고 처리.
• 웹페이지 classification(분류)이나 Machine Learned Ranking 등의 모델 빌딩에 하둡 클러스터 사용

 

🔅 야후 검색팀의 예 (하둡 성숙기)

• 몇 개의 하둡 성공 스토리 이후 하둡팀이 전사적인 조직으로 확대 (Platform 그룹).
  • 2011년 HottonWorks라는 회사로 스핀오프.
• 미디어 팀들을 포함한 거의 모든 팀들이 사용하기 시작
  • 하둡이 일종의 corporate-wide 데이터 저장소 -> Web Of Object 프로젝트
  • 4개의 하둡 클러스터 존재.
    • 조직별, 리서치용 vs 프로덕션

 

하둡이 최초에는 굉장히 작은 오픈소스 프로젝트로 시작했다가, 야후에서 성공 스토리를 만들어내고 점차 확대되어 야후에서 전사적으로 사용하게 되었다.

🔅 몇가지 교훈들

• 대용량 데이터 중앙 수집의 어려움
  • 빅데이터 처리를 위해서는 그 빅데이터를 한군데로 모으는 것이 시작인데 여러가지 어려움이 존재.
  • 소프트웨어 변경이 필요하며 여러 유관팀의 도움이 필요.
• 성공스토리의 필요성
  • 성공스토리가 있어야 보다 더 많은 팀의 adoption이나 매니지먼트의 지원을 끌어낼 수 있음
• ROI(Return Of Investment)를 고려
  
  • 데이터가 있다고 무작정 그걸 하둡에서 처리하려고 하기 보다는 무엇을 할 것인지 그게 리턴이 있을지 먼저 고려. 빅데이터 처리 시스템을 만드는 것은 많은 시간과 비용이 들어간다는 점을 명심.
• 데이터 접근 민주화의 중요성
  • 그 전에는 샘플조차 얻기 힘들던 데이터들이(보안 때문에) 접근도 되고 그걸 쉽게 처리할 수 있는 시스템까지 제공되자 크고 작은 이노베이션들이 쏟아져 나옴.

 

🍀 빅데이터 시스템의 구성

🔅 데이터 수집

• 빅데이터의 시작은 데이터를 수집하여 처리할 수 있는 장소로 올리는 것!
• 데이터의 용량이 큰 경우 데이터의 수집 자체가 큰 문제.
  • 네트워크를 타고 업로드하는 자체가 오랜 시간이 걸림.
  • 많은 경우 데이터 발생해주는 소스와 하둡을 같은 데이터 센터에서 고속네트워크로 연결
  • 예를 들어 웹 서버 접근하는 로그를 남길 건데, 그런 데이터들을 원격에 데이터센터에 업로드 하는 게 아니라 네트워크 입장에서 근처에 있는 데이터센터에 업로드하는 경우가 많음.
• 데이터 수집하는 데 몇가지 오픈소스 솔루션이 많이 쓰임
  • Flume: Cloudera에서 만들어서 지금 Apache 오픈소스.
  • Chukwa: Apache 오픈소스
  • 기본적으로 분산환경을 기반으로 여러 대의 데이터 소스로부터 데이터를 받아다가 계층구조 형태로 머칭하는 형태의 구조를 갖고 있으며 데이터 푸시보다는 데이터 풀링을 많이 사용.

🔅 데이터 저장과 처리

• 빅데이터를 저장하는 것을 목적으로 하고, 저장도 한 대의 서버에 저장하지 못하는 게 일반적. 여러 개의 노드 사용해서 저장하고 저장된 노드에서 MapReduce 같은 것을 이용해 프로세싱하는 것을 데이터의 저장과 처리라고 함.
• 대부분의 빅데이터 시스템에서 이 역할을 하는 것은 바로 하둡
  • 데이터의 저장소이자 프로세싱 브레인.
• 프로세싱을 위해서 여러가지 언어가 만들어짐.
  • Java MapReduce, Hive, Pig 등
• 하둡을 기반으로한 생태계가 만들어지고 있으며 많은 회사들이 관련 소프트웨어/서비스를 만들고 있음
  • IBM, EMC, Amazon, MS, Cloudera, MapR 등

🔅 워크플로우 실행 및 관리

• 빅데이터를 처리할 때 하나의 프로그램으로 처리하는 게 아니라 여러 체인 형태의 작업이 연속적으로 실행돼서 실행된 결과가 보통 같이 있는 information인 경우가 많음.
• 계속적으로 발생하는 데이터의 처리를 위해 처리 작업들의 실행이 자동화되어야 함.
  • 복잡한 ETL 작업의 경우 수십개의 job들의 chaining이 필요.
  • 주기적으로 혹은 데이터가 특정 위치에 생기면 특정 job을 시작하게 하는 메커니즘이 필요. 즉, 워크플로우 관리가 필요 (job들 관리, chaining)
• 몇 개의 오픈소스 프로젝트가 널리쓰임.
  • Oozie, Cascading, Azkaban, Hamake 등

🔅 결과 데이터의 액세스

• 만들어진 information들이 저장이 되는데, 액세스하는 것도 중요함
• 하둡으로 처리된 데이터는 어떤 형태로건 바깥에서 액세스가 필요
• 3가지 정도의 패턴 존재
  • RDBMS에 저장 : 작은 크기 데이터에 적합. 예를 들면 리포트
  • NoSQL에 저장 : HBase, Cassandra, MongoDB 등. 이 경우 데이터 크기에 관계없이 액세스 가능. Ad-hoc 분석을 위한 방법도 제공
  • Search Engine에 저장 : Lucene, Solr, ElasticSearch 등

🔅 데이터 Visualization

• 데이터를 어떻게 보기 쉽고 이해하기 쉽고 멋있게 보여줄 수 있을까? InfoGraphics

🔅 데이터 마이닝 - Data Scientist

• 일단 시스템이 구성되고 나면 누군가 데이터에서 새로운 가치와 의미를 찾아야함. 이게 데이터 마이닝
• 데이터 마이닝을 하는 사람 = Data Scientist의 몫
  • 수학/통계 지식(모델링)
  • 프로그래밍 스킬
  • 데이터분석에 대한 열정과 비즈니스에 대한 이해
• Mahout, R 등이 널리 쓰임

 

🍀 하둡 성공 스토리들

🔅 Fraud Detection

• Bank of America, Chase 등의 은행은 과거 신용 카드의 과거 트랜잭션 데이터들을 바탕으로 fraud detection 모델을 빌딩. 
• 모든 트랜잭션은 fraud detection 모델을 거침
  • 부정 결제. 특정 사용자들이 부정결제 하기 전 여러 행위들이 있음. 체크 카드를 이용해서 부정 결제를 하기 전에 일어나는 모델들을 이용해 은행 데이터를 실시간으로 분석해 Fraud Detection 하는 데에 사용함.
  • 실제 이 자체를 하둡에서 처리하는 게 아니라 어떤 형태를 가지면 이게 fraud 같다고 판단하게 해주는 fraud detection 모델을 만들어내는 데에 빅데이터 처리 시스템의 도움이 필수적임!
• 모델 빌딩은 빅데이터 시스템의 도움 없이는 불가능
  • 충분한 데이터의 수집
  • 주기적인 모델의 빌드를 가능
  • 빠른 실험과 테스트가 가능 (개발기간의 단축)

하둡과 같은 빅데이터 시스템을 갖고 이런 일을 처리할 수 있었다 !

🔅 Netflix 영화 추천

• 25M + subscriber, 30M movie play per day, 4M rating per day, 3M searches a day, 2B hours streamed in Q4 2011
  • 75% 영화감상이 영화 추천에 기반함
• Markov chain 기반의 알고리즘
  • 거대 N*N 행렬 계산
  • 처음에는 RDBMS 기반으로 일주일에 한 번 주말에 실행.
  • Hadoop 도입 이후 지금은 매일 한 번씩 계산 (추천 알고리즘 빠르게 고도화)
  • 성능상의 이유로 Netflix Prize 우승 알고리즘은 사용 못함.

🔅 Bioinformatics - DNA 분석

• 인간의 유전체는 총 30억쌍. 1인당 DNA 정보는 대략 120GB.
• 하둡을 기반으로 DNA 분석과 비교를 해주는 회사들이 등장하기 시작
  • Cloudburst 등
  • 한국에서는 얼마 전에 SDS에서도 서비스를 발표.

🔅 Trulia

• 부동산 가격 예측 사이트. 2006년 설립된 샌프란시스코 기반의 스타트업 (2013년 나스닥 상장)
• 부동산세 정보와 부동산 판매 가격을 계속적으로 수집/조인하여 가격을 예측
  • 처음에는 이 프로세스를 MySQL로 구현. 미국 전체 데이터를 돌리는 데 일주일 걸림.
  • 하둡으로 포팅 후 7시간으로 단축. 다양한 실험이 가능해짐.

🔅 Yahoo

• 검색어 자동완성 데이터베이스가 하둡을 이용해 빌딩됨.
  • 3년치의 로그 데이터
  • 20여개의 MapReduce job들이 데이터베이스를 빌딩.

 

🍀 빅데이터 도입 시 유념사항(문제점)

❗️프라이버시 이슈

• 빅데이터 시스템의 등장은 그 전까지는 불가능했던 레벨의 데이터 수집과 조인을 가능케함 -> 디지털 빅브라더의 탄생이 가능
  • 데이터들이 많아서 어떤 데이터가 들어올지 모름. 프라이버시 이슈를 세세하게 처리해야 함.
• EU의 경우 선도적으로 많은 부분에서 규제장치를 도입
  • 검색 엔진 쿼리의 경우 개인관련 정보(IP 주소, 브라우저 쿠키 정보)를 6개월 이상 저장하지 않도록 권고 
  • 예를 들어 검색어 자동완성은 개인정보 처리를 해야함. (개인화된 검색어 자동완성의 문제점) 빅데이터 기반 개인화 서비스 설계할 때는 프라이버시 이슈가 예민함. 
• 예를 들어 병원의 데이터만 해도 빅데이터인데, 병원 데이터 자체가 프라이버시. 그럼에도 모아서 처리하면 이점이 있음. 병원 데이터를 빅데이터로 모아서 처리하는 것도 프라이버시 이슈를 해결해 나가면서 구축되고 있는 게 현재 상황.

❗️ROI

• MySQL 한대로 충분한지 먼저 생각. 하둡을 기반으로 한 빅데이터 시스템은 시간, 돈, 노력이 모두 많이 들어간다는 점을 명심.
• 정말로 스케일이 문제가 될 경우에만 고려.
• 고려 시에도 처음부터 하드웨어부터 다 준비하지 말고 클라우드 서비스를 이용해서 가능성 타진

❗️오픈소스로 구성된 시스템

• 요즘 빅데이터 시스템들은 대부분 오픈소스 프로젝트들을 여러개 모아서 만들어지고 있음.
  • 보안 문제 가능성(완전 공개된 소스)
  • 오픈소스는 굉장히 빠르게 진화하며 없어지기도 함. (호환성 이슈, 버전간 충돌 이슈 등)
  • 많은 스타트업들이 버전관리와 서포트를 해주는 배포판 제공
  • 버그 패치가 느릴 수 있음

 

🍀 빅데이터 관련 회사들

🔅 아파치 재단

• 회사는 아니지만 하둡을 프로젝트로 관리해주는 재단.
• 스폰서 받아 관리해줌. 

🔅 Cloudera

• 하둡 배포판 관리해줌.
• 컨퍼런스 주최
• 하둡 창시자 Doug Cutting이 2009년 조인.
• 자격증 관련 업

🔅 HortonWorks

• 2011년 야후 내의 하둡플랫폼팀이 분사하여 설립됨.
• Cloudera와 거의 흡사한 일을 함.

🔅 MapR

• 자체하둡배포판 기술 지원

🔅 IBM, EMC, SAS, SAP

• 기존의 RDBMS나 DW 솔루션에다가 하둡 기반의 빅데이터 솔루션을 함께 제공

🔅 EMC/VMWARE 

• 빅데이터 시스템을 가상화 측면에서 접근하게 해줌

 

🍀 빅데이터 시스템의 미래

• 기본기능 개선
  • 하둡의 security는 굉장히 초보적인 수준. 기본적으로 기반 운영체제의 보안을 이용
  • 스케줄링의 경우 기본적으로 FIFO이며 매끄러운 pre-emption을 지원하지 못함
  • MapReduce 이외의 분산처리 프레임워크 지원
  • 마스터 노드의 failover 기능 (장애 극복) 지원
  • 기존 RDBMS의 SQL 지원
• 리얼타임 처리
  • 하둡 = 대용량 오프라인 배치 처리 프레임워크 (단계별로 처리)
    • 데이터 처리에 적어도 시간 단위의 지연이 발생
    • 예를 들어 은행 송금, 쇼핑몰 결제에서 배치 처리하게 되면 사용자들이 힘듦.
    • 오프라인 배치 처리 말고 리얼타임 처리도 필요하다는 게 의견.
• 가상화
  • VMWare의 Serengeti 프로젝트
  • 하둡 클러스터 서버의 이용도를 높이기 위함
• 특화 서비스들의 출현
  • 예) 추천 엔진
  • 많은 수의 회사들이 자사 컨텐츠의 추천 엔진으로 하둡을 활용