Hadoop & Spark 교육 - 2일차

1교시 - chapter 00.1day-review

• Shared-Nothing Architecture
• 공유하는게 Network밖에 없음
• 공유하는것은 메타정보로만 관리할뿐 공유되는것이 없다
• 특정 서버가 나가더라도 전체 서비스에 영향이 없는 구조
• Hadoop
• 트랜잭션 개념이 없다?

chapter 01.mapreduce - 집합연산을 위한 병렬처리 프레임웍

• MapReduce
• mapper 
• data를 key-value를 만들어서 반환
• 데이터의 움직임을 최소화 시키는 것이 목표
• Mapper까지는 network의 이동을 안하고 Reduce로 갈때 network 이동 필요
• 데이터 지역성
• 철저하게 지켜지는것이 mapper
• reducer는 최대한 지키는것이 목표
• WordCount: Flow p12
• reducer만 개발자가 직접 짜는것임.. Mapper는? 
• Input Split : default는 1줄씩 자르는것, 설정 가능함
• record reader: 어떻게 읽을거냐
• Parquet 관련도 여기 해당
• Mapper한테 데이터를 자르고 읽어서 한 건씩 넘겨준다
• Mapper
• 한 라인에 대한 단어 단위로 자른다
• 단어단위로 포문을 돌리면서 단어 카운트
• <"The",1> ... return 해준다
• 하나의 인풋을 받아서 여러개를 리턴해줌
• join 등이 어려운데 이를 처리할 수 있또록 hive 등장
• Partitioner
• Key를 보고 배분
• network 병목 발생하는 부분
• 매 단계마다 file이 많이 생성됨 - 단점
• MapReduce 02 - Spark 할 때도 필요한 것 p26
• Spark은 이제 무조건 YARN 에서 돌린다
• 과거 한때 mesos에서 돌린 적이 있었음
• MRv3은 YARN의 성능이 더 좋아진 것
• Hadoop 3.0
• Erasure 가 핵심
• 복사본은 두개만 있으면 된다는 것
• 단점
• 데이터도 변해야 함
• 클러스터 전체를 마이그레이션 해야 함

Chapter 03.pig

• MR의 대체용도?

Chapter 04.Hive

• 2.0 으로 갈듯
• 배치 레이어
• 관계형 DB는 write할 때 validation 체크를 하므로 write할때 부하가 크지만 얘는 읽을때 체크하기 때문에 Schema on Read p25
• 하이브의 단점을 극복하기 위해 나온 것이 Impala p69

• Impala
• 대용량 배치처리는 아니고 OLTP용 인터페이스?
• 적당한 용량만 사용 가능
• MR을 안타는것 자체만으로도 굉장한 이득을 얻음
• HIVE는 MR을 타는 구조기 때문에 속도에서 좋을수가 없다
• UDF(User Defined Function) 하이브는 어느정도 정리된다.

Chapter 05.Flume, Kafka

• Flume
• 단점: 자바로 돼있음
• 자바 프로세스 안에서 멀티쓰레드
• Channel
• 메모리일 수 있고 파일일 수 있고 디비일 수 있다
• DB쓸 경우 network를 타야해서 속도가 떨어진다 - Dilema

• Kafka
• Kafka에 썼다는것은 메모리에 있는게 아니고 파일에 썼다는 것 - 데이터 유실에 대한 문제가 없음
• MSA, Event, IoT등의 MS(Messaging Service)에 부합
• Zookeeper base
• Consumer group을 만들고 이것이 Zookeeper와 연결되는게 가장 이상적인 형태
• 어떻게 병렬로 가져가는지에 대해서는 컨수머그룹이 알아서 
• 성능이 되게 좋은 File I/O 
• 고성능 File IO에 적합한 구성
• MSA
• 트랜잭션을 DB에 안쓰고 로그만 쌓는다
• 보통 단독서버로 구성한다

Chapter 05.others

• Hbase
• Columnar 기반의 NoSQL
• 무겁고 번거로움
• Zookeeper
• Runtime의 Meta정보를 관리하는 것