[빅데이터] 2장_빅데이터를 위한 데이터 모델

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

2.1 데이터의 속성

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

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

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

2.1.1 데이터는 원시적이다

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

2.1.2 데이터는 불변이다.

관계형 데이터메이스 갱신은 없어서는 안 될 연산이다. 그러나 불변성을 다루기 위해서는 데이터를 갱신하거나 삭제하면 안되고 추가만 해야한다. 빅데이터 시스템에서 불변 스키마를 사용하면 다음 두 가지 이점이 있다.

  1. 인적 내결함성
    실수로 인해 데이터가 손실되지 않는다. 잘못된 데이터가 쓰여도 이전에 있던 데이터는 그대로 남는다.

  2. 단순성
    마스터 데이터 집함에 새 데이터를 추가할 수 있으면 된다. 데이터에 대한 색인이 필요하지 않아 단순하다.

데이터의 불변성을 유지하는 것의 장점은 가변 스키마와 비교하면 명확하다.

톰이 LA 로 이사했다. 그러면 톰의 현재 주거지를 반영하기 위해 갱신을 해야하는데, 톰이 샌프란시스코에 살았다는 지식은 완전히 손실된다.
불변 스키마를 사용하면 상황이 다르다. 사용자 정보가 바뀔 때마다 독립된 레코드를 생성한다. 이렇게 하려면 두 가지를 바꿔야한다.

  1. 사용자 정보의 각 항목을 독립된 레코드에 저장한다.
  2. 각 데이터 단위에 그 정보가 알려진 시간을 붙인다.

톰이 새 주거지로 이사를 하면, 주거지 테이블에 새 래코드를 추가한다. 이제 톰의 주거지를 저장하는 레코드가 두 개가 된다. 관련된 모든 주거지 정보를 훑으면서 타임스태프가 가장 최신인 것을 골라내, 현재 주거지를 알 수 있다.
불변 방식을 사용하는 방법으로 감당해야하는 것은 가변 스키마보다 공간을 많이 사용한다는 것이다. 사용자 ID 는 가변 방식에서처럼 로우마다 한 번 나오는게 아니라 모든 속성에 나온다. 게다가 현재 상태 뿐만 아니라 이벤트 기록을 전부 저장한다.
하지만, 빅데이터 기술을 통해 막대한 데이터의 저장 능력을 이용해서 불변성의 헤택을 끌어내야한다. 마스터 데이터 집합을 구축하는 일은 정말 중요하다.

2.1.3 데이터는 영원히 참이다.

데이터의 불변성으로 인해 만들어지는 중요한 결과는, 데이터가 영원히 참이 된다는 것이다.

2.2 데이터 표현을 위한 팩트 기반 모델

마스터 데이터 집합 안에서 데이터를 표현하는 방법은 여러가지다.

  1. 전통적인 관계형 데이터베이스의 테이블
  2. 구조화된 XML
  3. 반구조화된 JSON
  4. 팩트 기반 모델 (fact-based model) : 데이터를 fact 라고 불리는 기본 단위로 분해
2.2.1 팩트의 예와 속성

팩트 기반 모델은,

  1. 원시 데이터를 원자적인 팩트로 저장한다.
  2. 타임스탬프로 인해 팩트는 불변성을 지니며 영원히 참이다.
  3. 질의 처리 과정 중에 중복 식별이 가능하도록 각 팩트의 식별 가능성을 보장한다.

팩트는 유일하게 식별할 수 있는 데이터와 연관되어야한다. 페이스스페이스에 페이지뷰에 대한 데이터를 저장하는 경우를 생각해보자.

1
2
3
4
struct PageView:
DateTime timestamp
String url
String ip_address

이 구조체를 사용한 팩트는 특정한 페이지뷰 이벤트로 유일하게 식별되지 않는다. 동일한 IP 주소에서 동일한 URL 에 대한 여러개의 페이지뷰가 동시에 발생하면, 이 때 생겨난 각각의 페이지뷰는 정확히 같은 데이터 레코드이다.
서로 다른 페이지뷰를 구분하기 위해 스키마에 nonce (임시값), 각 페이지뷰마다 난수 생성법을 써서 만든 64 비트 숫자를 추가해보자.

1
2
3
4
5
struct PageView:
DateTime timestamp
String url
String ip_address
Long nonce

임시값을 추가하면 페이지뷰 이벤트를 서로 구별할 수 있고, 두 개의 페이지뷰 데이터 단위가 동일하면 이벤트도 동일하다는 것을 알 수 있다.

2.2.2 팩트 기반 모델이 주는 혜택
  1. 과거의 어느 시점에 대한 질의도 받을 수 있다.
    팩트에 타임스탬프가 붙어있고 불변성을 지녀 생기는 결과이다.

  2. 사람의 실수에 대해 내성을 가진다.
    톰이 샌프란시스코에서 로스앤잴래스로 이사한 것을 실수로 저장했다. 톰이 로스엔제렐스에 산다는 팩트를 지우면, 톰의 주거지가 자동으로 이전의 것으로 재설정된다.

  3. 부분 정보를 처리할 수 있다.
    톰이 나이와 성별은 입력했지만 주거지나 직업은 입력하지 않으면, 데이터 집합은 알려진 정보에 대한 팩트만 보관한다. 팩트가 존재하지 않는다는 것은, 논리적으로 null 과 동일하다.

  4. 데이터 저장소의 질의 처리 계층이 분리된다.
    batch layer 와 serving layer 모두에 정보가 저장되기 때문에 데이터가 정규화된 형태와 비정규화된 형태로 있게 되고, 양쪽의 모든 장점을 뽑을 수 있다.

데이터 정규화를 다루는 관계형 테이블 예를 보자. 관계형 테이블을 사용할 때는 질의 효율성과 데이터 일관성 중 어떤 것이 중요하냐에 따라 정규화 스키마와 비정규화 스키마 중 하나를 선택한다.

  1. 비정규화된 스키마
    동일한 이름이 여러 로우에 저장 될 수 있다. 이것은 각 회사의 직원수를 빨리 알아 낼 수 있도록 하지만, 회사가 이름을 바꾸면 많은 로우를 갱신해야한다. 정보를 여러 위치에 저장하는 것은 일관성이 깨질 위험이 있다.

  2. 정규화된 스키마
    오직 하나의 위치에만 저장된다. 일관성이 깨질 위험은 없지만, 질의에 응답하려면 테이블을 조인해야하고 계산 비용이 커질 수 있다.

람다 아키텍쳐에서는 질의 처리와 데이터 저장 목적이 분리되어 있다.

  1. 마스터 데이터 집합
    완전히 정규화되어 있다. 어떤 데이터도 중복 되지 않는다. 현재 타임스템프를 붙여 새 팩트를 추가하면 과거 팩트는 무효화되어 갱신이 쉽다.

  2. 일괄처리 뷰
    데이터 집합의 데이터 하나가 여러 뷰로 생성될수 있다는 점에서 비정규화된 테이블과 같다. 큰 차이는, 일괄 처리 뷰는 마스터 데이터 집합에 대한 함수로 정의된다는 것이다. 마스터 데이터 집합으로부터 계속 재생성 되므로 일괄 처리 뷰를 갱신할 필요가 없다.

2.3 그래프 스키마

팩트 그 자체만으로는, 데이터 집합에 저장된 팩트의 형식에 대한 기술도 없고, 그들 사이의 관계에 대한 설명도 없다. 그래서, 그래프 스키마가 필요하다.

2.3.1 그래프 스키마의 요소

세 가지 핵심 요소는,

  1. 노드 : 시스템 내의 개체
  2. 간선 : 노드 사이의 관계
  3. 속성 : 개체에 대한 정보

2.3.2 강제 기능 스키마는 왜 필요한가

팩트를 저장할 때 어떤 형식으로 저장해야할까. JSON 처럼, 반구조화된 텍스트 형식을 사용한다고 하자. 실질적으로 어떤 것도 마스터 데이터 집합에 기록할 수 있어서 단순하고 유연하다. 하지만 문제가 있다.
톰의 나이를 JSON 으로 나타내면,

1
{"id" : 3, "field" : "age", "value" : 29, "timestamp" : 133589484}

사람의 실수로 데이터 집합에 아래와 같은 팩트가 들어 갈 수 있다.

1
{"id" : 3, "field" : "age", "value" : 29}

JSON 자체는 유효하지만, 형식의 일관성을 지키지 못했고 데이터도 누락되었다. 텍스트 형식으로는 이 부분을 강제할 수 없다.
대안으로, 팩트의 구조를 엄격히 정의하는 강제 기능 스키마를 사용하면 된다. 처음에는 해줄게 많지만, 필요한 필드가 모두 존재하고 모든 값이 기대한 형식에 맞게 한다는 조건이 보장된다. 중요한 것은, 데이터 생성 중에 실수가 있을 때 강제 기능 스키마가 바로 그 시점에 오류를 낸다.


빅데이터, 람다 아키텍처로 알아보는 실시간 빅데이터 구축의 핵심 원리와 기법 <네이선 마츠, 제임스 워렌>

Comments