2018년 빅데이터 스터디 람다 일괄처리 계층 발표

1. 람다 일괄처리 계층
최용호

2. 일괄처리 계층이 필요한 이유
● 데이터 시스템의 목적은 데이터에 관한 임의의 질문에 응답하는 것
○ 데이터 전체에 대해 질문에 대한 처리가 이루어짐
○ 데이터 집합의 크기가 크면 클 수록 이에 대해 처리되는 시간도 비례해서 커짐
● 응답을 빠르게 하기 위한 다른 전략이 필요
○ 람다 아키텍처의 일괄처리 계층

3. 일괄처리 계층이란?
● 마스터 데이터 집합으로부터 일괄처리 뷰를 사전계산
○ 사전 계산을 적용할 부분과 실행 시간에 계산될 부분의 균형이 중요
○ 질의를 신속하게 처리하기 위한 충분한 정보만을 추려서 사전 계산
● 사전 계산을 위한 방식 두가지
○ 재계산 알고리즘 (recomputation algorithm)
○ 증분 알고리즘 (incremental algorithm)

4. 예제1. 시간대별 페이지 뷰
● 사용자가 URL에 접속하면 해당 페이지에 대한 접속 레코드를 기록
● 레코드 데이터
○ URL
○ 타임스탬프
● 위 데이터를 활용하여 시간별 접속 횟수를 계산할 수 있음

5. 예제2. 성별 추론
● 이름 데이터 집합을 가지고 개인의 성별을 추론
● 레코드 데이터
○ 이름
● 각 이름에 대해 정규화를 수행
○ 밥을 로버트로, 빌을 윌리엄으로
○ 정규화에 대한 알고리즘은 제공안함.
● 정규화된 이름으로 성별을 추론
● 알고리즘에 따라 결과가 달라질 수 있음

6. 예제3. 영향력 지수
● 트위터와 유사
● 데이터 집합에 반응(reaction) 레코드가 포함됨
○ 리트윗이나 댓글을 의미
● 레코드 데이터
○ sourceId : 글쓴이 아이디
○ responderId : 리트윗하거나 댓글 단 사용자 아이디
● 소셜 네트워크 상에서 개인의 영향력(influence) 지수를 구하는 것이 목적
○ 반응 개수를 기반으로 각 개인에게 가장 큰 영향을 준 사람 선택
○ 이 사람을 통해 영향을 많이 받은 사람들의 수 결정

7. 람다 아키텍처의 작동 방식
● 일괄처리 계층은 마스터 데이터 집합에 대한 함수를 실행하여 중간 결과를 사
전 계산 (일괄처리 뷰)
● 일괄처리 뷰는 서빙 계층에 로딩됨
● 서빙 계층은 색인 생성 (데이터에 빨리 접근할 수 있도록)
● 속도 계층은 일괄처리 계층의 지연시간이 높은 것을 보완
● 질의는 서빙 계층의 뷰와 속도 계층의 뷰 처리 결과를 합쳐서 응답 받음

8. 람다 아키텍처의 핵심
● 어떤 질의에 대해서도 일괄처
리 계층에서 데이터를 사전계
산하여 서빙 계층에서 신속하
게 처리되도록 할 수 있다는
것

9. 사전 계산에 대한 전략
● 사용 가능한 모든 질의를 사전 계산해서 서빙 계층에 저장
○ 처리가 간단
● 모든 질의를 사전 계산하기란 사실상 불가능
○ 시간대별 페이지 뷰 예제를 보면 모든 URL에 대해 모든 시간 범위에 대한 페이지 뷰가 필요
○ 1년이라면 대략 3억 8천만개

10. 사전 계산에 대한 전략
● 페이지뷰 예제를 이어서
● 모든 시간에 대해 사전계산 하지 않고, 시간대 별로 계산 후 실시간 데이터를
합산하는 방식으로 개선 가능
○ 1년 3억 8천만개에서 8760개로 계산값이 줄어듬

11. 일괄처리 뷰 갱신 전략
● 마스터 데이터 집합은 시간이 흐를 수록 계속 증가
● 새로운 데이터에 대해 어떻게 일괄처리 뷰를 갱신할지에 대한 전략은 필수
● 두가지 알고리즘
○ 재계산
○ 증분

12. 재계산 알고리즘
● 오래된 일괄처리 뷰는 버리고 데이터 집합 전체에 대해 함수를 실행
○ 새로운 데이터를 먼저 데이터 집합에 추가
○ 모든 레코드를 처음부터 다시 세어서 개수 갱신

13. 증분 알고리즘
● 새로운 데이터가 도착했을 때 일괄처리 뷰를 직접 갱신
○ 새로운 데이터 레코드의 수를 센 후 그 값을 기존 값에 더함

14. 고려사항
● 증분 알고리즘이 더 효율적으로 보임
● 효율 외에도 고려해야할 사항들이 많음
○ 성능
○ 인적 내결함성
○ 알고리즘의 일반성

15. 성능
● 고려사항
○ 일괄처리 뷰를 갱신하는데 필요한 자원의 양
○ 일괄처리 뷰의 크기

16. 증분 알고리즘
● 새롭게 추가된 데이터와 기존의 일괄처리 뷰를 사용하기 때문에 자원을 훨씬
적게 사용
● 시간대별 페이지 뷰처럼 데이터를 종합하기 때문에 뷰의 크기또한 마스터 데
이터 집합보다 훨씬 적음
재계산 알고리즘
● 전체 데이터 집합을 살펴봐야 하므로 갱신에 필요한 자원이 증분 알고리즘의
수십, 수백배 이상

17. 증분 알고리즘이 훨씬 효율적인거 같은데?
● 증분 알고리즘의 뷰 크기가 훨씬 더 커질 때가 있음
● 페이지 뷰 예제
○ 모든 URL에 대한 페이지뷰 수를 순 사용자로 계산해야 한다고 가정
○ 순사용자를 기준으로 하게 되면 증분 알고리즘 사용 시 모든 사용자의 id를 저장해야 중복되지
않게 계산이 가능
■ 이를 저장하려면 사이즈가 재계산 알고리즘보다 상수 배로 커짐

18. 인적 내결함성
● 데이터 시스템의 긴 수명 동안 버그가 실서비스 시스템에 배포될 수 밖에 없음
● 버그에 대한 대비책을 항상 생각하고 있어야함
● 재계산 알고리즘은 내결함성을 갖추고 있음
○ 코드를 고쳐서 배포하기만 하면 됨
● 증분 알고리즘에는 치명적
○ 버그에 영향받은 부분을 찾아내어 수정해야함
○ 데이터가 망가지지 않도록 엄청나게 신경을 써야함

19. 알고리즘의 일반성
● 페이지 뷰 예제에서 순사용자의 평균을 증분 알고리즘을 통해서 한다면 집계
된 사용자의 id를 전부 저장해야 하는 이슈가 있었음
○ 하이퍼로그로그와 같은 확률적 계산 알고리즘을 사용하여 완화 시킬 수 있음
○ 일괄처리뷰의 저장 비용이 크게 줄지만 근사치 계산
● 성별 추론 예제에서 생각해보면 증분 알고리즘 사용 시 이름에 대한 정규화 방
식이 변경되면 지금까지 증분 계산된 일괄처리 뷰는 옛날 것이 됨
○ 이를 해결하려면 모든 이름을 저장해야하고, 정규화 과정을 즉석 처리 부분에서 수행해야 함
○ 질의가 수행될 때마다 재정규화 하기 때문에 지연시간이 증가
● 이러한 부분들에선 재계산 알고리즘이 효율적.

20. 알고리즘 방식 선택
● 어떠한 경우라도 재계산 알고리즘은 항상 있어야함
○ 증분 알고리즘에 버그가 발생하더라도 재계산 알고리즘을 통해 인적 내결함성을 해결할 수 있
음
● 효율적인 자원 사용이 필요한 경우 증분 알고리즘을 선택적으로 사용

21. 일괄처리 계층에서의 확장성
● 확장성 : 시스템의 부하가 증가할 때 자원을 더 추가함으로써 성능을 유지
● 부하(load) : 데이터의 현재 총량 및 매일 추가되는 데이터양, 애플리케이션이
서비스하는 초당 요청 개수 등을 조합한 것
● 선형 확장성 : 부하가 증가하면 증가된 부하에 비례하는 자원을 추가함으로써
성능을 유지
● 선형으로 확장 가능하다는 것은 부하에 비례해서
시스템 비용도 증가한다는 의미

22. 분산 계산 프레임워크
● 일괄처리 계층을 구현하는데 사용할 수 있는 분산 계산 프레임워크 중 하나는
맵 리듀스
● 맵 리듀스가 선형 확장이 가능하다는 점을 염두해 두어야 함

23. 맵 리듀스
● 확장성과 내결함성을 지님
● 구글에서 개발
● 맵 리듀스 = 키/값 쌍을 다루는 맵 함수 + 데이터 처리용 계산을 정의하는 리듀
스 함수

24. 맵 리듀스의 확장성
● 10기가 바이트의 데이터에서 실행되는 프로그램은 10페타 바이트의 데이터에
서도 실행 됨
● 입력 데이터의 크기에 상관없이 계산을 클러스터에서 자동으로 병렬화
● 입력 데이터는 하둡 분산 파일시스템(HDFS)에 저장

25. 맵 리듀스 수행 절차
1. 클러스터에 있는 어떤 장비가 입력 데이터를 포함하고 있는 블록을 갖고 있는
지 찾아냄
2. 입력 데이터 크기에 비례하는 개수의 맵 태스크를 시작
a. 각각의 맵 태스크는 입력 데이터의 일부를 할당 받고, 그 데이터에 대해 맵 함수를 실행

26. 3. 리듀스 태스크 시작 (맵 태스크와 마찬가지로 클러스터에 퍼트려짐)
a. 리듀스 함수는 해당 키와 관련된 모든 값이 필요하므로 모든 맵 태스크가 완료될때까지 시작할
수 없음
4. 맵 태스크가 끝나면 방출된 키/값 쌍은 해당 키를 담당하는 리듀스 태스크로 전
달됨 (셔플링)
5. 리듀스 태스크가 모든 맵 작업으로부터 모든 키/값 쌍을 받으면 키를 기준으로
정렬
a. 같은 키를 갖는 값들이 모두 함께 모이게됨
6. 리듀스 함수 실행

27. ● 셔플 단계
● 정렬 후 리듀스 함수 실행

28. 맵 리듀스의 내결함성
● 프로그램이 실패할 수 있는 원인 들
○ 용량 초과
○ 메모리 초과
○ 하드웨어 고장
● 맵 리듀스는 이러한 오류를 감지하고 실패한 계산을 다른 노드에서 재시도함
● 전체 노드에서 설정한 횟수 이상 실패했을 때만 실제 실패로 인정 (기본값 4)
○ 장비보다는 코드 문제일 확률이 높음
● 작업은 재시도 될 수 있기 때문에 맵리듀스의 맵, 리듀스 함수는 결정적
(deterministic)이어야 함
○ 입력이 동일하면 함수가 항상 동일한 결과를 내보내야 한다는 의미

29. 맵 리듀스의 일반성
● 맵 리듀스가 지원하는 계산 모델은 어떤 함수라도 계산할 수 있을 정도로 충분
한 표현력을 갖추고 있음
● 앞서 살펴보았던 예제들도 전부 표현 가능
● 맵리듀스 vs 스파크
○ 스파크는 메모리에 캐싱할 수 있음.
○ 메모리를 사용하기 때문에 데이터 집합을 반복적으로 수행해야 하는 경우 훨씬 좋은 성능으로
동작할 수 있음
○ 머신러닝에 적합

30. 파이프 다이어그램
● 일괄처리 계산에 대한 상위 수준의 사고 체계
● 간결성과 직관성이 핵심
● 관련 도구
○ 캐스캐이딩
○ 피그
○ 하이브
○ 캐스캘로그

31. 파이프 다이어그램의 개념
● 데이터 처리를 투플(tuple), 함수(function), 필터(filter), 종합자(aggregation), 조
인(join), 병합(merge) 등을 사용한 세계로 바라보는 것
● 단어수 세기 예제
○ sentence 하나를 입력받음
○ split 함수로 문장을 여러개의 word 투플로 변환
○ filter를 거쳐 a나 the를 제거
○ 전체 투플 집합은 word 필드로 그룹화
○ 각 그룹에 count 종합자(aggregation)이 적용
○ count 결과에 두배를 하여 새로운 필드를 만들 수도 있음
○ 마지막으로 필요한 필드만 출력하고 나머지는 버림

34. 파이프 다이어그램의 조인 연산 - 1
● 모든 조인 항들 가운데 공통으로
존재하는 필드 선택
● 조인할 필드 이름이 완전이 같아야
함

35. 파이프 다이어그램의 조인 연산 - 2
● 독립적인 투플 집합들을 하나의 투
플 집합으로 합치는 것
○ 병합 연산
● 모든 투플 집합의 필드 개수가 동
일해야 하며 결과 투플에 사용할
새로운 이름을 지정해야 함

36. 맵리듀스를 통해 파이프 다이어그램 실행
● 모든 파이프 다이어그램 연산은 맵리듀스로
옮길 수 있음
● 함수와 필터 : 레코드를 한번에 하나씩 처리
○ 맵 단계 또는 리듀스의 조인이나 종합자 뒤에 나올 수
있음
● 그룹화 : 맵 단계에서 방출되는 키를 사용하는 것
● 종합자 : 리듀스 단계에서 하나의 그룹에 속하는 모든 투플
을 대상으로 처리
● 조인 : 맵 단계의 코드와 리듀스 단계의 코드가 필요
● 병합 : 동일한 코드가 다중 데이터 집합에 실행된다는 의미

37. 결합자 방식의 종합자 - 문제 이해
● 결합자 : 일반적인 종합자보다 훨씬 효율적으로 실행될 수 있
는 특별한 종류의 종합자
● 데이터 집합에 존재하는 모든 레코드의 개수를 집계하고 싶다
고 가정
○ 오른쪽 그림에서 GLOBAL 단계는 모든 투플이 같은 그
룹으로 분류되어야 하고 종합자는 데이터 집합에 존재하
는 모든 개별 투플에 대해 실행되어야 함
○ 이 절차는 모든 투플이 한 대의 장비로 보내지고 그 장비
에서 종합자 코드가 실행되는 식으로 작동
○ 병렬성을 확보할 수 없고 확장성도 잃게 됨

38. 결합자 방식의 종합자 - 문제 해결
● 모든 투플을 한 장비로 보내는 대신 전체 데이터 집합의 일부를 갖고 있는 각
장비에서 부분집계를 수행
● 부분 집계 결과를 하나의 장비로 보내 합한 후에 전체 집계를 계산
● 부분 집계 결과의 개수는 클러스터 내 장비의 대수와 동일할 것이므로 전체 계
산에 비하면 계산 작업량이 매우 적어짐

39. 파이프 다이어그램 예제
시간대별 페이지뷰 예제
성별 추론 예제
영향력 지수 예제

40. 감사합니다.