데이터 시스템의 목적은, 데이터에 관한 임의의 질문에 응답하는 것이다. 데이터 집합 전체를 입력으로 받는 함수는 실행 시간이 매우 오래 걸리므로, 질의의 빠르게 응답할 수 있는 다른 전략이 필요하다.
람다 아키텍쳐에서 일괄처리 계층은, 마스터 데이터 집합으로부터 일괄처리 뷰를 사전 계산해서 질의가 빠르게 처리될 수 있도록 한다.

6.1 일괄 처리 구실로 좋은 예제

각 예제는 마스터 데이터 집합 전체를 입력 받는 함수로, 질의를 어떻게 실행하는지 보여준다. 이 예제는 질의 요청이 들어올 때 즉석으로 실행하는 대신, 사전 계산을 사용하도록 구현이 변경될 것이다.

6.1.1 시간대별 페이지뷰

지정한 시간대에서 발생한 특정 URL 에 대한 페이지뷰 수의 총계를 구하는 것.

6.1.2 성별 추로

이름 데이터 집합 레코드를 사용해서 개인의 성별 추론.

6.1.3 영향력 지수

소셜 네트워크에서 개인의 영향력 지수를 구함.

6.2 일괄 처리 계층에서 계산을 수행하기

HDFS 를 사용하는 방법과, 상위 수준 API 를 사용하여 필요한 작업을 자동화하는 방법을 정리한다. 항상 그랬듯이, 도구를 비교하는 것이 아니라 상위 수준의 개념을 보강하는 것이 목적이다.

5.1 하둡 분산 파일 시스템 사용하기

HDFS 의 동작 방식을 정리하면,

1. 파일은 블록으로 쪼개져서 클러스터에 있는 여러 노드로 퍼뜨려진다.
2. 블록은 여러 노드로 복제되어서 장비가 다운되어도 데이터는 여전히 사용 가능하다.
3. 네임노드는 각 파일이 어떤 블록으로 구성되는지와, 그 블록이 어디에 저장되어 있는지를 추적한다.

파일과 폴더를 조작하는 HDFS API 사용법을 보자. 서버에 로그인한 정보를 모두 저장한다고 하자.

1
2
3
4
5

$ cat logins-2020-03-31.txt
jko	192.168.12.125 Thu Mar 31 22:33 - 22:46
jh	192.168.12.125 Thu Mar 31 21:15 - 22:42
ko	192.168.12.125 Thu Mar 31 23:31 - 22:13
jko	192.168.12.125 Thu Mar 31 22:33 - 22:43

이 데이터를 HDFS 에 저장하려면 데이터 집합 저장용 디렉토리를 우선 만들고 올리면 된다. 파일을 올리면 자동으로 블록으로 쪼개져서 여러 데이터 노드 사이에 분산된다.

1
2

$ haddop fs -mkdir /logins
$ haddop fs -put logins-2020-03-31.txt /logins

5.1.1 작은 파일 문제

하둡은 데이터가 HDFS 상의 여러 작은 파일에 저장되어있을 때는, 계산 성능이 떨어지는 특성이 있다.
그 원인은, 맵리듀스 작업이 입력 데이터 집합의 각 블록마다 테스크를 하나씩 실행하기 때문이다. 각 테스크는 실행을 계획하고 조정하는 오버헤드를 소모하는데, 각각의 작은 파일은 독립적인 테스크에서 실행되어야하므로, 그 비용은 반복적으로 발생한다.

마스터 데이터 집합은하나의 서버에 저장하기에는 너무 크다. 데이터를 여러 장비에 어떻게 분산시킬 것인지기 중요하다.
이번 장은 다음을 정리한다.

1. 마스터 데이터 집합을 저장하는데 필요한 요구사항
2. 분산 파일 시스템이 왜 데이터 집합을 저장하는데 적합한지

4.1 마스터 데이터 집합 저장소의 요구사항

“데이터를 한 번만 쓰고, 읽기는 큰 단위로 여러 번 수행된다” 방식에 초점을 두면, 다음과 같이 요구사항을 정리할 수 있다.

• 쓰기

  • 데이터 추가의 효율성 : 유일한 쓰기 연산은 새로운 데이터를 추가하는 것뿐이다.
  • 확장성 있는 저장소 : 데이터 집합이 커질 때 확장하기 쉬워야한다.

• 읽기

  • 병렬 처리 지원 : 거대한 양의 데이터를 확장성 있는 방식으로 다룰 수 있도록 병렬 처리를 지원해야한다.

• 둘 다

  • 저장 비용과 처리 비용 조율 : 필요에 따라 데이터를 저장학고 압축하는 방식을 선택하는 유연성이 있어야한다.
  • 불변성 강제

4.2 일괄 처리 계층을 위한 저장소 솔루션 선택

4.2.1 키/값 저장소

여러 장비에 분산되는 거대하고 영속적인 hash map

1. 값은 저장할 데이터이다. 키는 무엇일까 ? 우리가 사용하는 데이터 모델에는 데이터 자체가 대량 소비를 전제로 한다. 그래서 원래 키가 없고, 필요하지도 않다. 즉, 처음 부터 데이터 모델과 키/값 저장소의 동작 방식이 맞지 않는 것이다. 유일하게 쓸만한 방법이라면, UUID 를 생성해서 키로 사용하는 것이다.
2. 키/값 저장소는 무작위 읽기와 쓰기를 지원하기 위해 키/값 쌍에 세밀하게 접근해야한다. 그래서, 여러 개의 키/값 쌍을 묶어서 압축하는 것도 불가능하다.
3. 키/값 저장소는 변경 가능한 저장소에 사용하도록 만들어져서, 마스터 데이터 집합에 불변성을 강제하는 게 극히 필요한 경우라면 문제가 된다.
4. 키/값 저장소에는 불필요한 기능이 많다. 무작위 읽기, 쓰기 그리고 이들을 가능하게 하는 모든 장치들이 이에 해당된다.
5. 데이터 색인을 하며 우리에게는 필요 없는 서비스도 제공해서 저장소 비용이 증가하고 데이터를 읽고 쓰는 성능이 저하될 수 있다.

4.2.2 분산 파일 시스템

Apache Thrift 란 직렬화 프레임워크를 사용해 SuperWebAnalytics.com 데이터 모델을 구현한다.

3.1 어째서 직렬화 프레임워크인가

많은 개발자들이 원시 데이터를 기록하는 방법으로 JSON 등의 스키마 없는 형식을 고른다. 작업을 쉽게 착수할 수 있는 장점이 있지만, 데이터 오염이 언제든지 터질 수 있는 단점이 있다.
데이터 오염 문제는 그 문제가 어떻게 발생했는지에 대한 전후사정을 거의 손에 넣을 수 없기 때문에 디버깅이 어렵다. 예를 들어, 필수 항목이 누락되어 NPE 가 발생하면 문제의 원인이 누락된 항목이라는 것은 바로 알 수 있지만 애초에 그 데이터가 어떻게 들어왔는지에 대한 정보는 없다.
강제 가능 스키마를 만들었으면, 데이터를 기록하는 시점에 오류가 나므로 데이터가 무효화된 사정과 원인에 대한 전후 사정을 알 수 있다. 그리고, 이때 발생한 오류 덕에 프로그램은 무효 데이터를 기록하지 못하므로 마스터 데이터 집합도 오염되지 않는다.
직렬화 프레임워크를 사용하면 강제가능 스키마를 쉽게 적용 할 수 있다.

3.2 Apache Thrift

Apache Thrift 는 정적 타입의 강제가능 스키마를 정의하는데 쓰이는 도구이다. 이와 유사한 도구로, Protocol Buffers 나 Avro 등이다.
Apache Thrift 의 주요 요소는 구조체 (struct) 와 공용체 (union) 타입 정의이다. 이들은 다음 필드의 조합으로 구성된다.

1. 기본 데이터 타입 : 문자열, 정수, long 정수, double 실수
2. 다른 타입의 집합체 (리스트, 맵, 세트)
3. 다른 구조체와 공용체

3.2.1 노드

SuperWebAnalytics.com 의 사용자 노드에서 개인은 사용자ID 나 브라우저 키기로 식별된다. 이 둘이 동시에 함께 식별에 쓰이지는 않는다. 이런 패턴은 노드를 나타날 때 흔히 볼 수 있는데, 공용체 데이터 타입과 일치한다. 하나의 값으로 여러 가지를 나타내는 타입이다.

1
2
3
4
5
6
7
8

union PersonID {
	1: string cookie;
	2: i64 user_id;
}

union PageID {
	1: String url;
}

3.2.2 간선

마스터 데이터 집합은 람다 아키텍처에서 반드시 오염으로부터 보호되어야하는 유일한 영역이다.

2.1 데이터의 속성

대규모 소셜 네트워크 (페이스스페이스) 를 설계한다고 하자. 각각의 정보 계층은 바로 앞 단계로부터 파생되지만 단방향성이다.
앞으로 사용하게 될 용어들을 정리한다.

1. 정보 : 지식의 일반적인 모음
2. 데이터 : 어떤 것으로부터 파싱되지 않은 정보
3. 질의 : 데이터에 물어볼 수 있는 질문
4. 뷰 : 특정 타입의 질의에 응답하는데 도움을 주기 위해 만들어 지는 것

어떤 사람의 데이터는 또 다른 사람의 뷰각 될 수 있다. 어떤 광고 회사가 페이스스페이스 사용자 프로필로부터 인구 통계학 정보를 긁어 가는 수집기를 만들었다. 톰의 출생월일은 생년월일로부터 도출될 수 있기 때문에 페이스스페이스에게는 뷰 이지만, 광고 회사 입장에서는 톰에 대한 제한된 정보를 가지는 것으로 시작하므로 데이터이다.
데이터의 핵심 속성을 살펴보자 : 원시성 / 불변성 / 영원성

2.1.1 데이터는 원시적이다

가공되지 않은 데이터일수록 더 많은 질문을 그 데이터에 대해 던질 수 있다.

1.1 이 책의 구성

이론을 다루는 장과 사례를 다루는 장으로 나뉜다. 이론을 다루는 장은 빅데이터 시스템을 구축하는 방법을 다루고, 사례를 다루는 장에서는 이론을 구체적인 도구에 연관시킨다.

1.2 전통적인 데이터베이스를 사용해 확장하기

간단한 웹 분석 어플리케이션을 개발한다고 하자. 고객의 웹 페이지는 페이지뷰가 발생할 때마다 애플리케이션의 웹서버에 URL 정보를 보내야한다. 웹 서버는 데이터베이스에 페이지뷰에 해당하는 row 의 값을 증가시킨다. 이제 애플리케이션에 개선되며 어떤 문제가 생기는지 살펴본다.

1.2.1 큐를 사용해 확장하기

백엔드의 데이터베이스가 부하를 견디지 못해 페이지 뷰를 증가시키는 쓰기 요청을 신속히 처리하지 못해 타임 아웃이 나고 있다고 하자.
웹 서버가 데이터베이스에 직접 접근하도록 하는 대신, 웹 서버와 데이터베이스 사이에 큐를 넣는다. 그래서, 페이지뷰 이벤트를 받을 때마다 이벤트는 큐에 추가된다. 그리고, 큐에서 한 번에 100개씩 이벤트를 꺼내 하나의 데이터베이스 갱신 요청으로 일괄 처리하는 작업자 프로세스를 추가한다.

1.2.2 데이터베이스를 샤딩하여 확장하기

이 웹 분석 애플리케이션이 계속 인기가 높아져, 데이터베이스에 과부하가 다시 걸렸다고 하자. 기존의 작업자 프로세스로는 쓰기 요청을 감당할 수 없어 갱신을 병렬 처리 하기 위해 작업자 프로세스의 수를 늘렸보았지만 도움이 되지 않았다.
그래서, 데이터베이스 서버를 여러 대 사용하고 테이블을 여러 서버에 분산시키는 수평 분할, 또는 샤딩이라고 불리는 방법을 사용한다. 즉, 각 서버는 전체 테이블의 일부를 가지는 것이다. 쓰기 부하를 여러 서버, 즉 샤드로 분산 시키게 되는 것이다.
이 애플리케이션의 인기가 높어져, 데이터베이스를 더 많은 샤드로 나누었다고 하자. 샤드 개수가 변경되어서 기존의 애플리케이션 코드에도 반영을 해야하고 이것을 깜빡하면 의도하지 않은 샤드에 기록된다.

1.2.3 내결함성 문제 발생 시작

어쨌든 샤드를 늘렸는데, 이제 데이터베이스 장비에서 디스크 장애가 발생하는 상황이 왔다. 디스크 장애가 발생한 장비가 다운된 동안엔 그 디스크에 저장된 데이터를 사용할 수 없다. 해결책으로는,

1. 워크 플로우 관리

기초 지식

1. 워크 플로우 관리 도구

   워크 플로우 관리 도구의 주요 역할은, 정기적으로 태스크를 실행하고 비정상적인 상태를 감지하여 해결을 돕는 것이다.

   ex) Airflow, Azkaban, Digdag, Luigi, Oozie

2. 태스크

   데이터 파이프라인의 실행 과정에서 데이터를 잇달아 이동하면서 정해진 처리를 반복하는데, 이때 실행되는 개별 처리이다.

3. 기본 기능

   • 테스크를 정기적인 스케쥴로 실행하고 결과 통지

   • 테스크 간의 의존 관계를 정하고 순서대로 빠지없이 실행

   • 테스크의 실행 결과를 보관하고, 오류 발생하면 재실행 할 수 있도록 하기

4. 선언 형과 스크립트 형

   • 선언형 : XML 이나 YAML 등의 서식으로 워크플로우 기술
   • 스크립트형 : 스크립트 언어로 워크플로우 정의

오류로부터 복구 방법

모든 오류를 사전에 예상하는 것은 불가능하기 때문에, 오류 발생 가능성을 고려하여 대처 방법을 결정해야한다.

1. Retry

   재시도를 반복해도 문제가 없는 태스크라면, 1회나 2회의 재시도를 실행해도 좋다.

   그러나, 그 이상은 재시도가 아니라 올바른 문제 해결 방법을 찾아야한다.

2. Backfill

   플로우 전체를 처음부터 다시 실행한다. 다음 상황에 사용한다.

   • 태스크의 실패가 며칠 동안이나 계속된 후에 이를 모아서 재시도 하고 싶을 때
   • 새롭게 만든 워크 플로우를 과거로 거슬라 올라가 실행하고 싶을 때

재실행의 안정성을 위한 두가지 방법

1. 원자성 조작 (Atomic Operation)

   예를 들어, INSERT 문 2회를 호출하는 태스크가 있다고 하자.

   첫 번째의 INSERT 가 종료되고 오류가 발생하면 태스크를 재실행하면 동일한 데이터가 다시 쓰이게 될 수 있다.

   이 문제를 회피하기 위해, 각 태스크가 시스템에 변경을 가하는 것을 한 번만 할 수 있도록 하는 것이다.

   쓰기가 필요한 수 만큼 테스크를 나누는 것이다.

   하지만, 태스크 구현상의 버그 등으로 원자성 조작 직후에 문제가 발생하면 원자성 조작 자체는 성공했어도 워크 플로우 관리 도구에서는 오류로 여길 수 있다.

2. 멱등한 조작

   더 확실한 방법은, 동일한 태스크를 여러 번 실행해도 동일한 결과가 되도록 하는 것이다.

   예를 들어 분산 스토리지에 파일을 업로드할 때,

   • 매번 새로운 파일명을 만들 경우 데이터를 추가 (append) 하는 것이고,
   • 동일 파일명으로 덮어쓰면 치환 (replace)하는 것이다. 치환은 반복해도 결과가 변하지 않으므로 멱등하다.

데이터 추가

1. 멱등한 추가

   과거의 모든 데이터를 치환하면 멱등하지만 부하가 커진다. 그래서, Table Partitioning 이 필요하다.

   예를 들면 테이블을 1일마다 또는 1시간 마다 파티션으로 분할하고 파티션 단위로 치환하는 것이다.

   파티션의 모든 데이터를 삭제할 때, TRUNCATE 문이나 INSESRT OVERWRITER 문 등을 사용할 수 있다.

   ex) Hive 는 파티셔닝 지원, Amazon Redshift 는 파티셔닝을 지원하지 않아 UNION ALL 사용

2. 원자성을 지닌 추가

   하나의 테이블에 여러번 데이터를 써넣는 경우, 중간 테이블을 이용해 마지막에 목적 테이블에 한 번 추가한다.

   즉, 전반 부분에서는 중간 테이블을 만들기 위해 테이블을 치환하므로 멱등하다.

   그러나 마지막에 INSESRT 는 단순히 추가이므로 전체로서는 멱등하지 않다.

   단, 마지막에 쓰기를 1회만 실시하므로 이것은 원자성을 지닌 조작이다.

   그래서 플로우가 실패해도 아무것도 쓰이지 않아 실패한 태스크를 재실행해도 복구가 완료된다.

1. 벌크 형과 스트리밍 형의 데이터 수집

데이터 수집 방법으로 두 가지 방법이 있다.
이 챕터에서는 각각의 방법으로, 분산 스토리지에 데이터가 저장되기까지의 흐름을 정리한다.

1. 벌크 형
2. 스트리밍 형

객체 스토리지와 데이터 수집

빅데이터는 확장성이 높은 분산 스토리지에 저장된다. 분산 스토리지로,

1. 분산형 데이터베이스

2. 객체 스토리지
   객체 스토리지는 다수의 컴퓨터를 사용해 파일을 여러 디스크에 복사해서 데이터 중복화 및 부하 분산을 실현한다.
   객체 스토리지의 구조는 데이터 양이 많을 때는 우수하지만, 소량의 데이터에 대해서는 비효율적이다.
   하둡의 HDFS, 클라우드 서비스의 Amazon S3 가 대표적이다.

데이터 수집

데이터 수집이란, 수집한 데이터를 가공해 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스이다.
작은 데이터는 적당히 모아서 하나의 큰 파일로 만들어 효율을 높이는데 도움이 된다.
파일이 지나치게 크면, 네트워크 전송 시간이 오래 걸려 오류 발생률이 높다.

벌크 형 데이터 전송

1.빅데이터의 정착

빅데이터 기술의 요구 : Hadoop 과 NoSQL 의 대두

세계 곳곳에서 엑세스 되는 시스템 증가로, 전통적인 관계형 데이터베이스로는 취급 할 수 없는 데이터가 쌓이게 되었다.
그래서 다른 구조가 필요했다.

1. Hadoop
   다수의 컴퓨터에서 대량의 데이터 처리

2. NoSQL Database
   빈번한 읽기/ 쓰기 및 분산처리가 강점

분산 시스템의 비즈니스 이용 개척 : 데이터 웨어하우스와의 공존

위 그림처럼, 확장성이 뛰어난 Hadoop 에 데이터 처리를 맡겨 데이터 웨어하우스의 부하를 줄이고 있다.

직접 할 수 있는 데이터 분석 폭 확대

‘여러 컴퓨터에서 분산 처리한다’ 는 빅데이터의 특징으로 하드웨어를 준비하고 관리하는게 어려웠다.
하지만, 클라우드 시대에서는 필요한 자원 확보가 쉬워서 얼마든지 빅데이터를 이용할 수 있다.

데이터 디스커버리의 기초 지식

1. 크로스 집계

크로스 집계

1. 크로스 테이블
   행과 열이 교차하는 부분에 숫자 데이터가 들어감

2. 트랜젝션 테이블
   행방향으로만 증가하고, 열방향으로는 데이터가 증가하지 않음

3. 크로스 집계
   트레젝션 테이블에서 크로스 테이블로 변환하는 과정.
   피봇 테이블을 이용해서 할 수 있다.

룩업 테이블

트랜젝션 테이블의 ‘상품 ID’ 를 사용해서 ‘상품명’ 과 ‘상품 카테고리’ 참고할 때 사용되는 것이, 룩업 테이블이다.
상품 정보를 하나의 테이블로 정리해두면 나중에 속성을 추가하거나 변경하는 것도 간단하다.

2. 열 지향 스토리지

처리량과 지연 시간

1. 처리량 ( throughput )
   일정 시간에 처리할 수 있는 데이터의 양.
   배치 처리 등 대규모 데이터 처리에서 중요시.

2. 지연 ( latency )
   데이터 처리가 끝날 때 까지의 대기 시간.
   애드 혹 데이터 분석에서 중요시.

데이터 처리의 지연