KilJaeeun commented 2 years ago

파트

파트 1. 하둡 기초 > chapter 1. 하둡과의 만남 / 파트 2. 맵리듀스

발표자

길재은

해야할일

(하둡책 거르기)
발표 순서 지정

발표 기간

9월 29일 22:00 ~
마감 기한
9월 28일 23:59 까지

참고 링크

일정표 : https://www.notion.so/Hadoop-4f533d9016884066ae0c87199d2bf65d
하둡 완벽가이드: http://grut-computing.com/HadoopBook.pdf

hyunju-song commented 2 years ago

https://hazel-developer.tistory.com/301

hyunju-song commented 2 years ago

발표기간이랑 마감 기한을 수정해야 할거 같아욤!! 👀 ㅎㅎ

wookiist commented 2 years ago

KilJaeeun commented 2 years ago

1장

배운점

Mysql = hdfs + mapreduce
제타바이트 크기는 겁나 크다
이전에 컴퓨터 클러스터들과 하둡과의 차이
이전에는 고성능 컴퓨터 가격 보다 저렴한거 여러개여서라고 생각했는데, 전송성능이 데이터 저장단위보다 발달이 느렸다라는 새로운 관점 ( 만수르도 하둡을이용해야하는 이유)

2장

jasonkang14 commented 2 years ago

https://jasonkang14.github.io/hadoop/meet-hadoop

JSYoo5B commented 2 years ago

1장. 하둡과의 만남

데이터의 크기, 생산 방식, 속도 등이 매우 빠르게 증가하고 있다. 이전같으면 정말 중요한 정보만 저장했지만, 이제는 자연스럽게 모든 데이터를 생산하고 있다. (ex. 정제된 log만을 기록하는 것이 아닌, IoT 등 하찮고 많은 데이터를 기록) 그런데 이렇게 쌓인 데이터를 저장, 분석하는 것은 어렵다.

문제는 실질적인 데이터를 저장할 저장장치의 속도 발전이 늦어짐에 있다. 용량 대 가격 비율, 보관성, 불량률 등을 고려해서 2차 저장장치를 사용하고 있다.

HDD는 저장 가능한 용량은 급격히 늘었지만, 속도는 물리적인 한계에 의해 발전 속도가 더디다.
플래터와 디스크 암이 움직이는 물리적인 속도는 전기의 속도를 따라잡을 수 없다.
SSD는 저장 용량 대비 가격이 비싸다. 하지만 NAND flash의 특성상 복원하기 힘든 수명이 생기며,
발열, 장기보관 문제, 가격, 동작원리에 적합하지 않은 FS 구현 등의 문제가 있다.

SSD는 그나마 최근이라 치고, HDD만 가정했을 때, 속도가 제일 큰 병목 지점이 된다. 또한 하드웨어 장애가 발생한다. 단일 시스템 내 속도 병목과 하드웨어 장애를 고려하여 RAID란 방법이 있음. (하둡은 그냥 분산 스토리지 접근법) 또한 저장된 데이터를 결합해야 하는 문제가 있는데, 이걸 하둡에서 Key-value 페어 처리로 추상화할 수 있다.

MR은 batch processing의 일종이지만, 비정형 쿼리를 수행하고 이를 합리적 시간 내에 결과를 내준다는 점이 특징. 이제 batch processing에서 진화하여, 대화형 분석 등 기존 실행 시나리오와 달라도 적합하게 개발되고 있다. (초기 하둡이 MR+자원관리에서 자원관리는 YARN으로 분리된다던지, HBase의 등장이라던지)

비교

RDB

RDB가 쓰기에 집중이라면, MR은 읽기에 집중
RDB가 정규화라면 MR은 비정규화

그리드

간단히 요약해서 접근법이 다름

역사 등은 생략

2장. 맵리듀스

가장 기초적인 분석 방식은 클러스터 등의 성능을 활용하지 못하고, 원하는 결과를 받기에 오랜 시간이 걸린다. 분산 처리에 어려운 문제를 정의하면 다음과 같다.

작업을 공평하게 나눠 실행한다는 것은 생각보다 추상적이다.
여러 나눈 작업을 한번에 합치는 과정에서도 추가 오버헤드가 생길 수 있다.
작업의 전체 과정을 조율할 수 없다.

맵리듀스

Key-value 페어로 입/출력, 맵 단계와 리듀스 단계에서 할 일을 정의하여 접근

맵: raw data에서 원하는 속성 추출하여 Key-value 페어로 변형, 값의 유효성 판단
(셔플): 리듀스 이전에, Key를 바탕으로 정렬, 리듀스 이전에 value들을 묶음
리듀스: 같은 Key를 가진 여러 value를 가공하여 원하는 결과를 계산

분산 처리

하둡은 Map task, Reduce task로 나눠, YARN을 통해 스케쥴링하고, 여러 노드에서 실행된다. 입력 단위는 split이란 고정 크기 조각으로 분리한다. 이 노드에 대한 스케쥴링에서 데이터 지역성을 고려한다. (다른 노드로 데이터를 옮기느라 네트워크 쓰기 싫음)

맵 작업의 결과물은 HDFS가 아닌 로컬 디스크에 임시 저장된다. (중간 결과물이라서 추후 버려질 내용이며, HDFS에 저장하는 것은 생각보다 무거운 요청이다.) 리듀스 작업은 여러 노드의 결과를 종합해야 하므로 데이터 지역성이 불가능에 가깝다. 리듀스의 결과물은 HDFS에 저장된다. (리듀스 노드에 먼저 저장하고, 나머지를 NameNode, DataNode에 저장) 리듀스를 여러 노드에서 하게 될 때는 데이터를 파티셔닝 해서 잘 나눠야하는데, 이 부분은 어려운 문제.

맵->리듀스로 넘기기 위해 데이터를 모으는 셔플 과정에서 미리 리듀싱이 가능하다면 이걸 미리 처리하는 컴바이너 함수를 활용할 수 있다.

스트리밍

유닉스 스트림(파이프)으로 입력, 출력 할 수 있는 다른 언어 프로그램을 작성해서 활용하는 방식 기본적으로 하둡은 원래 Java 기반으로 작성해서 돌려야 하나, 이 작업을 외부 스크립트로 수행 (근데 이게 왜 스트리밍이지...)

morebo2ks / hadoop

18주차 hadoop 책 스터디 #18

파트

발표자