1. 빅데이터 처리와 Spark 소개(빅데이터 정의, 하둡 이론 등)

1. 빅데이터 정의와 예

---

빅데이터의 정의

(1) 빅데이터의 정의 1

• 서버 한대로 처리할 수 없는 규모의 데이터
• 2012년 4월 아마존 클라우드 컨퍼런스에서 아마존의 data scientist인 존 라우저가 내린 정의 분산 환경이 필요하느냐에 포커스
• 판다스로 처리해야할 데이터가 너무 커서 처리가 불가능하다면 어떻게 할 것인가?

(2) 빅데이터의 정의 2

• 기존의 소프트웨어로는 처리할 수 없는 규모의 데이터
• 대표적인 기존 소프트웨어 오라클이나 MySQL과 같은 관계형 데이터베이스
  • 분산환경을 염두하지 않음
  • Scale-Up 접근 방식(vs. Scale-out)
    • 메모리 추가, CPU 추가, 디스크 추가

(3) 빅데이터의 정의 3

• 4V(Volume, Velocity, Variety, Varecity)
• Volume : 데이터의 크기가 대용량?
• Velocity : 데이터의 처리속도가 중요?
• Variety : 구조화/비구조화 데이터 둘다?
• Veracity : 데이터의 품질이 좋은지?

 

빅데이터의 예

(1) 디바이스 데이터

• 모바일 디바이스(위치정보)
• 스마트 TV
• 각종 센서 데이터(IOT 센서)
• 네트워킹 디바이스

(2) 웹

• 수십 조개 이상의 웹페이지 존재 -> 온갖 종류의 지식의 바다
• 웹 검색엔진 개발은 진정한 대용량 데이터 처리
  • 웹 페이지를 크롤하여 중요한 페이지를 찾아내고 (페이지 랭크) 인덱싱하고 서빙
  • 구글이 빅데이터 기술의 발전에 지대한 공헌
• 사용자 검색어와 클릭 정보 자체도 대용량
  • 이를 마이닝하여 개인화 혹은 별도 서비스 개발이 가능
    • 검색어를 바탕으로한 트렌드 파악, 통계 기반 번역, ..
• 요즘은 웹 자체가 NLP 거대 모델 개발의 훈련 데이터로 사용되고 있음

 

2. 빅데이터 처리가 갖는 특징

---

(1) 빅데이터 처리의 특징과 해결방안 

• 큰 데이터를 손실 없이 보관할 방법이 필요 : 스토리지
  • 큰 데이터 저장이 가능한 분산 파일 시스템이 필요
• 처리 시간이 오래 걸림 : 병렬 처리
  • 병렬 처리가 가능한 분산 컴퓨팅 시스템이 필요
• 이런 데이터들은 비구조화 된 데이터일 가능성이 높음 : SQL만으로는 부족
  • 예 : 로그 파일
  • 비구조화 데이터를 처리할 방법이 필요
• 결국 다수의 컴퓨터로 구성된 프레임워크가 필요

 

(2) 대용량 분산 시스템이란?

• 분산 환경 기반(1대 혹은 그 이상의 서버로 구성)
  • 분산 파일 시스템과 분산 컴퓨팅 시스템이 필요
• Falut Tolerance
  
  • 소수의 서버가 고장나도 동작해야함
• 확장이 용이해야함
  • Sclae Out이 가능해야함

 

3. 하둡의 등장과 소개

---

(1) 하둡(Hadoop)의 등장

• Doug Cutting이 구글랩 발표 논문들에 기반해 만든 오픈소스 프로젝트
  • 2003년 The Google File System
  • 2004년 MapReduce : Simplified Data Processing on Large Cluster
• 처음 시작은 Nutch라는 오픈소스 검색엔진의 하부 프로젝트
  • 하둡은 Doug Cutting의 아들의 코끼리 인형의 이름
  • 2006년에 아파치 톱레벨 별개 프로젝트로 떨어져나옴

 

(2) Hortonworks의 정의

• An open source software platform for distributed storage and distributed processing of very large data sets on computer clusters built from commodity hardware
• 분산 파일 시스템인 HDFS, 분산 컴퓨팅 시스템인 MapReduce

 

(3) 다수의 노드로 구성된 클러스터 시스템(cluster)

• 마치 하나의 거대한 컴퓨터처럼 동작
• 사실은 다수의 컴퓨터들이 복잡한 소프트웨어로 통제됨
• 야후의 검색엔진은 4000대의 서버로 동작했었음

 

(4) 하둡의 발전

• 하둡 1.0은 HDFS 위에 MapReduce라는 분산 컴퓨팅 시스템이 도는 구조
• MapReduce 위에서 다양한 컴퓨팅 언어들이 만들어짐
  • Map과 Reduce 두개만 operation이 가능했던 점
  • 프로그래밍 생산성이 떨어지면서, 다양한 컴퓨팅언어 발견
  • Pig는 문법이 직관적이지 않아서, 지금은 더 이상 쓰지 않음
  • Hive와 Presto는 SQL 언어라고 보면됨

• 하둡 2.0에서 아키텍처가 크게 변경됨
  • 하둡은 YARN이란 이름의 분산처리 시스템 위에서 동작하는 애플리케이션이 됨
  • Spark은 YARN 위에서 애플리케이션 레이어로 실행됨
  • General한 컴퓨팅 프레임워크가 필요하다는 요구사항으로, YARN이 만들어짐

• HDFS : 분산 파일 시스템
  • 데이터를 블록 단위로 나눠 저장
    • 블록의 크기는 128MB(디폴트)
  • 블록 복제 방식(Replication)
    • 각 블록은 3 군데에 중복 저장됨
    • Falut tolerance를 보장할 수 있는 방식으로 이 블록들은 저장됨
  • 하둡 2.0 네임노드 이중화 지원
    • Active & Standby
      • 둘 사이에 share edit log가 존재
    • Secondary 네임노드는 여전히 존재(네임노드의 정보를 주기적으로 복제)
    • 기존에는 네임노드가 죽으면, manual 한 작업으로 Secondary 노드가 Name node를 갈아끼우게 해야했음
•  

• MapReduce : 분산 컴퓨팅 시스템
  • 하둡 1.0
  • 하나의 잡 트래커와 다수의 태스크 트래커로 구성됨
    • 잡 트래커가 일을 나눠서 다수의 태스크 트래커에게 분배
    • 태스크 트래커에서 병렬처리
    • 일반적으로 네임노드와 잡트래커는 분리함
    • 워낙 중요한 job을 하고 있기 때문에, 나누지만 태스크 트래커와 데이터 노드는 같은 서버에서 동작
  • MapReduce만 지원
    • 제너럴한 시스템이 아님

 

4. YARN의 동작 방식

---

(1) 분산 컴퓨팅 시스템 : 하둡 2.0 (YARN 1.0)

• 세부 리소스 관리가 가능한 범용 컴퓨팅 프레임워크
• 리소스 매니저
  • Job Scheduler, Application Manager
• 노드 매니저 : 서버에 해당하는 리소스(컨테이너)를 관리
• 컨테이너 : 다수의 컨테이너가 있을 수 있음. 자바로 치면 JVM 이라고 생각하면 됨 
  • 앱 마스터
    • 특별한 형태의 Container
  • 태스크
• Spark이 이 위에서 구현

(2) YARN의 동작

1. 클라이언트에서 실행하려는 코드와 환경정보를 리소스매니저에게 넘김
   1. 실행에 필요한 파일들은 applicatoion ID에 해당하는 HDFS 폴더에 미리 복사됨
2. 리소스매니저가 노드매니저를 통해 컨테이너를 받아서, 어플리케이션 마스터를 실행
   1. 어플리케이션 마스터는 프로그램 마다 하나씩 할당되는 프로그램 마스터에 해당
3. 어플리케이션 마스터는 입력 데이터 처리에 필요한 리소스를 리소스 매니저에게 요구
   1. 리소스 매니저는 data locality를 고려해서 리소스(컨테이너)(JAVA JVM))를 할당
4. 어플리케이션 매니저는 할당 받은 리소스를 노드 매니저를 통해 컨테이너로 론치하고 그 안에서 코드를 실행
   1. 이 때 실행에 필요한 파일들이 HDFS에서 Container가 있는 서버로 먼저 복사
5. 각 태스크는 상황을 주기적으로 어플리케이션 매니저에게 보고 (heartbeat)
   1. 태스크가 실패하거나 보고가 오랜 시간 없으면 태스크를 다른 컨테이너로 재실행

이 과정들을 거쳐서 운영이 되는데, SPARK 같은 것들이 클라이언트 자리라고 보면 된다.

 

(3) 하둡 1.0 vs 하둡 2.0

하둡 2.0에서 소개된 클러스터 자원 관리자를 YARN이라고 부름

• 하둡 3.0의 특징
  • YARN 2.0을 사용
    • YARN 프로그램들을 논리적인 그룹(플로우라고 부름)으로 나눠서 자원관리가 가능
    • 이를 통해 데이터 수집 프로세스와 데이터 서빙 프로세스를 나눠서 관리 가능
      • 50%는 배치 데이터에 써라
      • 30%는 스트림 데이터에 써라
      • 20%는 데이터 서빙에 써라 식의 관리 가능
  • 타임 라인 서버에서 HBASE를 기본 스토리지로 사용(하둡 2.1)
  • 파일 시스템
    • 네임노드의 경우 다수의 스탠바이 네임노드를 지원(원래는 1대)
    • HDFS, S3, Azure Storage 이외에도 Azure Data Lake Storage 등을 지원