서론
빅데이터 시대의 도래
- 1950년대 첫 컴퓨터가 나옴 (폰노이만) - 프로그램 내장 방식
- 1960년대 운영체제와 프로그래밍 언어 등장 (FORTRAN 및 COBOL)
- 1964~ 대화형 컴퓨터, 시분할, 다중 프로그래밍
- 1970년대 고밀도 직접회로, 마이크로 컴퓨터, PC시대 (MS, Apple 설립)
- 1990년에 www 인터넷, 1995 Java
- 기기가 개인화되고 데이터가 많아짐
- 빅데이터 처리 시스템이 필요하다
데이터 생성의 주체
- 기존에 데이터는 인간이 만들어 냈다.
- 기기가 보편화되고 센서들(IoT)이 많이 나오면서, 인간 외에도 데이터를 만들어내는 주체가 생겼다.
- 텍스트
- 비텍스트 - 숫자, 카테고리, 관계, 오디오, 비디오 등
빅데이터의 특성 (3V)
데이터의 볼륨 (Volume)
- 테라바이트, 페타바이트 이상
데이터의 다양성 (Variety)
- 정형 - RDB, xpdlqmf
- 반정형 - HTML, XML
- 비정형 - 텍스트, 이미지, 동영상, 음성 등
데이터 발생 속도 (Velocity)
- 모바일, SNS, 셍서 등으로 인해 과거와 비교할 수 없는 속도로 생성됨
빅데이터 처리
3V의 특성에 맞는 새로운 처리 프레임워크가 필요함
- 많은 데이터를 처리
- 실시간으로 데이터를 처리
- 저비용으로 처리 (오픈소스, 소프트웨어 비용 절감)
- 결함이 허용되는 시스템 - 무장애가 아니라, 결함에 대비하고 복구할 수 있는 시스템
실시간 데이터 처리
- SNS에서 실시간으로 발생하는 데이터를 처리
- 데이터를 실시간으로 분석하고, 사용자의 패턴을 파악하고, 의사결정
- RFID, IoT 센서에서 발생하는 데이터 처리
스트리밍 데이터
연속적으로 생성되는 데이터 (보통 작은 KB단위로 동시에 전송)
빅데이터 처리 시스템
- 대용량 데이터를 분산, 병렬 처리하고 관리하는 사시템
- 실시간 처리, 배치 처리를 할 수 있는 프레임워크
- 대규모의 양의 데이터를 수집, 관리, 유통, 분석 처리하는 분산 병렬 프레임워크
빅데이터 전주기 프로세스
수집 - 저장 - 처리 - 분석 - 시각화(표현)
(하둡같은 처리 시스템은 저장-처리에 해당, 에코시스템은 전체를 포괄)
빅데이터 시스템 설계 원칙
결함 허용 시스템 (Fault Tolerance)
- 한대의 PC가 1년에 한번 장애가 발생한다면, 365대는 하루에 한번, 빅데이터 처리 클러스터는 매시간에 한번만큼 자주 발생할 수 있다.
- 모든 시스템은 많은 문제로 장애가 발생할 수 있다.
- 따라서 장애가 발생해도 시스템 운영을 계속할 수 있어야 한다. (대체시스템 혹은 고장대응체계)
- 장애를 버티고 수행하는 능력이 있는 시스템
저비용 시스템 (Cost Effective)
- 비용에 민감한 시스템
- 수직확장 (scale up) & 수평확장 (scale out)
- 수직확장 - 메모리, 디스크 등 한대의 컴퓨터에 확장, 하지만 기계노후 등 한계가 있음
- 수평확장 - 같은 컴퓨터를 클러스터로 묶어 여러대를 함께 운용, 확장성이 증대된다
- 데이터 구조, 응답시간, 처리량에따라 적당한 형태(툴)와 비용을 선택
- 저비용 서버로 시스템 구성 - 저렴한 비용의 성능 낮은 서버로 시스템 구성 가능
- 오픈소스 도입으로 상용 라이센스 비용 절감
기존 시스템과의 연계성
- 소셜, 시스템로그, 텍스트, 멀티미디어, 센서로그와 같은 다양한 데이터를 수집하고 저장하고 처리가 가능해야함
- 기존 DBMS/파일시스템을 연계할 수 있어야함
하둡의 역사
2003년 - 구글 파일 시스템 (GFS) - 구글의 논문 (하둡의 근간이 됨)
2004년 - 구글 맵피듀스 (MapReduce) - 구글의 논문 (하둡의 근간이 됨)
2005년 - 아파치 넛지 (Nutch) 프로젝트 (더그 커팅, 마이크 카페렐라) 검색엔진
- 서치엔진에서 데이터 핸들링에 대한 고민을 지속
2006년 - 야후 하둡 프로젝트 (더그 커팅)
2008년 - 클라우데라 (Cloudera) 창립
2011년 - 호튼웍스 (Hotonworks) 창립
하둡 1.0
- 맵리듀스 분산 처리 계층 (데이터 처리 계층)
- 하둡 분산 파일 시스템 (HDFS) 계층 (데이터 저장 계층)
- 한대가 아닌, 여러대가 클러스터링 된 분산 시스템 기반 (Fault-Tolerance)
데이터 저장계층 (HDFS)
- 분산된 여러개의 디스크를 하나의 파일시스템인것 처럼 구성
- 사용자는 한개의 파일시스템이라고 느낌
- 한대가 죽어도 계속 서비스가 가능할 수 있게 데이터 복제(Replication)
- 분산처리를 하고 파일(블럭)이 생성될 때 복제해서 저장 (기본적으로 3개 복제, 옵션으로 설정 가능)
- 2개의 Master 4개의 Slave 디폴트로 구성 (master/worker 라고 하기도 함)
- 마스터는 네임스페이스(네임노드) 관리 슬레이브는 데이터노드 관리
- 네임스페이스(네임노드) --> Replication이 된 저장소의 자리수(일종의 인덱스)의 목록
- 데이터노드 --> 실제 읽고 쓰인 데이터
데이터 처리계층 (맵리듀스)
- 일단 복잡하지 않은 문제를 풀자 (복잡해지면 각각의 구성이 성능이 좋아야함) - 단위 작업을 심플하게
- 마스터는 리소스 분배/할당, 슬레이브는 작업만 수행
Secondary-Master의 경우는 2nd Master가 수행을 아예 하지 않다가, 마스터가 죽으면 잠깐의 다운타임 후에 서비스
Active-Stanby (고가용성 / High Availability)는 두개의 마스터가 모두 보고를 받고 마스터가 죽으면 바로 서비스
맵리듀스
- 분산 병렬 처리 방식으로 여러개의 작업 노드에 작업을 분산해 병렬 처리하는 프레임워크
- 마스터가 슬레이브에게 작업을 던져주고, 슬레이브는 작업을 수행
- 작업은 맵리듀스 (맵리듀스 수행방법) 을 전달
- 맵(Map)과 리듀스(Reduce)를 합친 말
- 맵 단계 --> 분산된 데이터를 Key값과 Value값의 리스트로 모으는 단계
- 파일 데이터를 마스터가 슬레이브에게 나누어 맵(분배)
- 셔플 단계 (Suffle andf Sort) --> 맵 단계에서 나온 중간 결과를 해당
- 처리가 되면 다시 마스터가 데이터를 받아서 셔플과 소팅을 진행
- 리듀스 단계 - 리스트에서 원하는 데이터를 찾아 집계하는 단계
- 다시 슬레이브가 리듀스 잡을 받아 수행 후 집계 수행
- 순서: 데이터&맵함수분배(마스터) - 맵(슬레이브) - 셔플/소트&리듀스함수분배(마스터) - 리듀스/집계(슬레이브)
워드카운트(Word Count) 문제
- Input으로 "Dear Bear River Car Car River Deer Car Bear"가 들어온다
- 마스터는 "Dear Bear River", "Car Car River", "Deer Car Bear"으로 스플릿 해서 맵함수와같이 분배
- Worker들은 공백으로 Split한 후 , 1을 붙이게 됨
- Worker 1: (Deer, 1), (Bear, 1), (River, 1)
- Worker 2: (Car, 1), (Car, 1), (River, 1)
- Worker 3: (Deer, 1), (Car, 1), (Bear, 1)
- 마스터는 셔플링/소팅을 수행 (취합)
- Bear(1, 1), Car(1, 1, 1), Deer(1, 1), River(1, 1)
- Worker는 리듀스 잡을 수행, 단순 카운트 잡
- (Bear, 2), (Car, 3), (Deer, 2), (River, 2)
- Worker들은 집계를 수행
에코시스템의 탄생 배경
Java 기반이라 DBA들이 Java를 배워야함 --> Hive가 탄생
Hive - SQL과 비슷한 Hive QL로 Map Reduce를 수행하게 해주는 프레임워크
Pig - 시스템관리 스크립팅 (Batch/Shell 스크립트)로 Map Reduce를 수행하게 해주는 프레임워크