빅데이터를 지탱하는 기술.md

서평

• 데이터 엔지니어링 공부를 하면서 빅데이터에 대해 전반적인 구조를 익힐 수 있는 기술서로 추천하고 싶은 책이다.
• 데이터 분석가가 데이터에서 가치 있는 정보를 추출한다면 데이터 엔지니어는 시스템의 구축 및 운용, 자동화 등을 담당한다. 이 책에서 다루는 것은 데이터 활용 방법이 아니라 데이터 처리를 어떻게 시스템화하는가에 대한 문제로 데이터 처리과정에서 사용되는 소프트웨어와 데이터베이스, 프로그래밍 언어와 시각화 도구 등의 특징을 정리하여 데이터를 효율 높게 취급하기 위한 기초를 먼저 설명하고 워크플로우 관리와 스트림 처리 등의 데이터 처리 기술을 자세히 알려주고 있다.
• 데이터 엔지니어 업무를 수행하면서 빅데이터의 기초 지식에 대해 많이 구글링을 하고 있습니다. 데이터 수집 시 데이터 전송 방식에 대해 , 스트림 처리와 배치 처리가 무엇인지, 분산 스토리지의 구성과 파이프라인의 구성, 수집된 데이터를 분산 데이터 처리하는 방법과 워크플로 관리하는 방법 등 책을 읽으면서 실무적으로 부족한 부분에 대해서 익힐 수 있어서 좋았습니다.
• 이 책을 읽으면서 회사에서의 빅데이터 플랫폼 구축이 어떻게 이루어졌는지 조금씩 이해하기 시작하였고 코드를 보면서 실무자들이 파이프라인 관리와 튜닝을 하려는 흔적을 알아볼 수 있어서 좋았습니다. 또한 팀 동료와 일을 할 때, 도메인이 다를 때 많은 도움이 될 거 같습니다.
• EMR 분산 처리스스템과 airflow를 활용한 워크플로 업무를 실제로 하다 보니까 분산 데이터 처리의 공통 플랫폼인 Hadoop부분에 대해서 흥미롭게 읽었습니다. 분산 시스템의 구성요소와 데이터 처리 및 엔진의 특징을 알아서 좋았고 웹이나 앱으로부터의 데이터 수집과 배송에 대해 전체적인 구조를 읽힐 수 있어서 좋았습니다.
• 빅데이터에 관심이 많다면 엔지니어링 측면에서 많은 도움이되어 추천하며 빅데이터의 전반적인 구성을 보고 배우며 앞으로의 로드맵을 그릴 때 많은 도움이 될 거 같습니다.

주요 내용

• 빅데이터
  • 데이터 엔지니어(data engineer) : 시스템의 구축 및 운용, 자동화 등을 담당
  • 데이터 분석가 : 데이터에서 가치 있는 정보를 추출
    • 확증적 데이터 분석(confirmatory data analysis) : 가설을 세우고 그것을 검증
    • 탐색적 데이터 분석(exploratroy data analysis) : 데이터를 보면서 그 의미를 읽어내려고 하는것
• 이 책에서 다루는 것은 데이터 활용 방법이 아니라 '데이터 처리를 어떻게 시스템화하는가에 대한 문제'
• 데이터 처리 과정에 사용되는 소프트웨어와 데이터베이스, 프로그래밍 언어와 시각화 도구 등의 특징을 정리하여 데이터를 효율 높게 취급하기 위한 기초를 먼저 설명 워크플로우 관리와 스트림 처리 등의 데이터 처리 기술을 살펴봄
• 추가적으로 알아두면 좋은 것
  • 비지니스 인텔리전스(Business intelligence) : 기업의 업적 등을 수집해서 경영상의 의사결정에 도움을 주는 것
  • 데이터 마이닝(data mining) : 통계 분석과 머신러닝 등의 알고리즘을 사용하여 데이터로부터 가치 있는 정보를 발견

빅데이터 기초 지식

Hadoop

• 웹 서버 등에서 생성된 데이터는 처음에 RDB와 NoSQL 등의 텍스트 데이터 저장됨 -> 그 후 모든 데이터가 Hadoop으로 모이고, 거기서 대규모 데이터 처리가 실행
• 다수의 컴퓨터에서 대량의 데이터를 처리하기 위한 시스템
• 구글에서 개발된 분산 처리 프레임워크인 'MapReduce'를 참고하여 제작
  • 초기 Hadoop MapReduce를 동작시키리면 데이터 처리의 내용을 기술하기 위해 자바 언어로 프로그래밍
  • SQL과 같은 쿼리 언어를 Hadoop에서 실행하기 위한 소프트웨어로 Hive(하이브)가 개발됨

NoSQL 데이터베이스(빈번한 읽기/쓰기 및 분산 처리가 강점)

• 전통적인 RDB의 제약을 제거하는것을 목표로 한 데이터베이스의 총칭
  • 키 밸류 스토어(key-value store/KVS) : 다수의 키와 값을 관련지어 저장
  • 도큐멘트 스토어(document store) : JSON과 같은 복잡한 데이터 구조를 저장
  • 와이드 칼럼 스토어(wide-column store) : 여러 키를 사용하여 높은 확장성을 제공

엔터프라이즈 데이터 웨어하우스(enterprise data warehouse/EDW , 데이터웨어하우스/DWH)

• 일부 기업에서 데이터 분석 기반으로 사용

데이터 디스커버리(data discovery)

• 대화형으로 데이터를 시각화하여 가치 있는 정보를 찾으려고 하는 프로세스
• 셀프서비스용 BI 도구
  • BI 도구(business intelligence tool) : 예전부터 데이터 웨어하우스와 조합되어 사용된 경영자용 시각화 시스템, 대기업 IT 부서에 의해 도입되는 대규모 도구

빅데이터 기술

• 기존의 데이터 웨어하우스와 다른 점
  • 다수의 분산 시스템을 조합하여 확장성이 뛰어난 데이터 처리 구조를 만든다는 점

데이터 파이프라인

• 데이터 파이프라인(데이터 수집에서 워크플로 관리까지)
  • 차례대로 전달해나가는 데이터로 구성된 시스템

데이터 수집

• 데이터 전송(data transfer)
  • 벌크(bulk) 형
    • 이미 어딘가에 존재하는 데이터를 정리해 추출하는 방법
    • 데이터베이스와 파일 서버 등에서 정기적으로 데이터를 수집하는 데에 사용
  • 스트리밍(streaming) 형
    • 차례차례로 생성되는 데이터를 끊임없이 계속해서 보내는 방법으로 모바일 애플리케이션과 임베디드 장비 등에서 널리 데이터를 수집하는데 사용

스트림 처리와 배치 처리

• 스트림 처리(stream processing)
  • 스트리밍형 방법으로 받은 데이터는 아무래도 실시간으로 처리
• 배치 처리(batch processing)
  • 어느 정도 정리된 데이터를 효율적으로 가공하기 위한 구조

분산 스토리지(객체 스토리지, NoSQL 데이터베이스)

• 분산 스토리지(distribute storage)
  • 여러 컴퓨터와 디스크로부터 구성된 스토리지 시스템
• 객체 스토리지(object storage)
  • 한 덩어리로 모인 데이터에 이름을 부여해서 파일로 저장, Amazon S3

분산 데이터 처리(쿼리 엔진, ETL 프로세스)

• 빅데이터를 SQL로 집계
  • 1. 쿼리 엔진(query engine)
    • 분산 스토리지 상의 데이터를 SQL로 집계하기 위해, Hive 등
    • 현재 Hive 보다 고속인 대화형 쿼리 엔진(interactive query engine)
  • 2. ETL(extract-transform-load) 프로세스
    • 데이터를 추출(extract)하고, 그것을 가공(transform)한 후, 데이터 웨어하우스에 로드(load)
    • 외부의 데이터 웨어하우스 제품을 이용
    • 분산스토리지에서 추출한 데이터를 데이터 웨어하우스에 적합한 형식으로 변환

워크플로 관리

• 전체 데이터 파이프라인의 동작을 관리하기 위해
• 매일 정해진 시간에 배치 처리를 스케줄대로 실행, 오류가 발생한 경우에는 관리자에게 통지하는 목적
• 모니터링
  • 계획적으로 데이터의 변화를 추적해 나가는 것
  • KPI(key performance indicator) : 프로젝트의 현황을 파악하기 위한 숫자로 업계마다 중요한 지표
    • 행동 가능(actionable) : 그 결과에 따라 자신의 다음 행동이 결정될지 여부 -> 자신의 행동을 결정할 때 직감에 의지하는 것이 아니라 객관적인 데이터를 근거하여 판단하는 것을 데이터 기반(data-driven) 의사 결정
    • 웹 서비스의 KPI
      • DAU(Daily Active User) : 서비스를 이용한 1일 유저 수
      • 계속률(Customer Retention) : 서비스를 계속해서 이용하고 있는 유저의 비율
      • ARPPU(Average Revenue Per Paid User) : 유료 고객 1인당 평균 매출
    • 온라인 광고의 KPI
      • CTR(Click Through Rate) : 광고의 표시 횟수에 대한 클릭 비율
      • CPC(Cost Per Click) : 1회 클릭에 대해서 지불한 광고비
      • CPA(Cost per Acquisition) : 1건의 고객 취득을 위해 지불된 광고비

데이터 웨어하우스와 데이터 마트 - 데이터 파이프라인 기본형

• 데이터 웨어하우스
  • 대량의 데이터를 장기 보존하는 것에 최적화
  • 정리된 데이터를 한 번에 전송하는것은 뛰어나지만 소량의 데이터를 자주 쓰고 읽는 데는 적합하지 않다
    • 데이터 소스(data source) : 업무 시스템을 위한 RDB나 로그 등을 저장하는 파일 서버
    • 로우 데이터(raw data) : 원시 데이터
• 데이터 마트
  • 데이터 분석과 같은 목적에 사용하는 경우에는 데이터 웨어하우스에서 필요한 데이터만을 추출하여 데이터 마트(data mart)를 구축

데이터 레이크

• 모든 데이터를 원래의 형태로 축적해두고 나중에 그것을 필요에 따라 가공하는 구조
• 여러 곳에서 데이터가 흘러들어오는 데이터를 축적하는 호수에 비유해 데이터의 축적 장소를 데이터 레이크(data lake)
• 대부분의 경우 CSV나 JSON 등의 범용적인 텍스트

애드 혹 분석(ad hoc analysis)

• 자동화 등을 생각하지 않고 수작업으로 데이터를 집계(일회성 데이터 분석)

컴퓨터 시스템

• 기간계 시스템(mission-critical system)
  • 비즈니스 근간에 관련된 중요한 시스템으로 이것이 정지되면 업무가 멈추기 때문에 완벽하게 테스트를 반복하고 신중하게 운용
• 정보계 시스템(information system)
  • 사내 커뮤니케이션과 의사 결정 등을 위해 이용하는 시스템

빅데이터의 탐색

크로스 테이블(cross table)

• 행과 열이 교차하는 부분에 숫자 데이터가 들어가는 것 을 부름

트랙잭션 테이블

• 행 방향으로만 증가하게 하고, 열 방향으로는 데이터를 증가시키지 않는것
  • 크로스 집계 : 트랜잭션 테이블에서 크로스 테이블로 변환하는 과정
  • 스프레드시트의 피벗 테이블 : 소량의 데이터를 크로스 집계하는데 편리한 것
  • 피벗 그래프 : 결과를 크로스 테이블에 정리할 뿐만 아니라 그것을 그래프로 시각화 한것

룩업 테이블(테이블을 결합하여 속성 늘리기)

• 트랙잭션 테이블에 새로운 항목을 추가하는 것이 아니라, 다른 테이블과 결합하고 싶은 경우에 사용

SQL에 의한 테이블의 집계

• BI 도구와 pandas라면 수백만 레코드는 집계할 수 있지만, 그 이상이 되면 너무 느려져서 쓸 수가 없음
• 집계(aggregation) : 대량의 데이터를 크로스 집계하려면 SQL을 사용하여 데이터를 집계, 집계함수
• 데이터 집계 프로세스 : 데이터를 먼저 SQL로 집계
• 시각화 프로세스 : 시각화 도구로 크로스 집계

MPP(massive parallel processing : 대규모 병렬 처리)

• 분산된 데이터를 읽어 들이려면 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리하는 것이 효과적
• 대량의 데이터를 분석하기 위해 데이터베이스에서 널리 사용
• Amazon Redshift , Google BigQuery
• 데이터 집계에 최적화되어 있으며, 데이터 웨어하우스와 데이터 분석용의 데이터베이스에서 특히 많이 사용
• MPP 데이터 베이스
  • 하드웨어 수준에서 데이터 집계에 최적화된 데이터베이스
  • MPP의 아키텍처 : Hadoop과 함께 사용되는 대화형 쿼리 엔진으로 채택
  • 하나의 쿼리를 다수의 작은 태스크로 분해하고 이를 가능한 한 병렬로 실행
    • MPP 데이터베이스에서는 여러 디스크에 분산된 데이터가 서로 다른 CPU 코어에 의해 읽혀 부분적인 쿼리 실행이 이루어짐, 그 결과들을 한 곳에 모이고 최종적인 결과가 출력 -> 이러한 일련의 처리는 가능한 한 동시에 병렬로 실행
    • 디스크로부터의 로드가 병목 현상이 발생하지 않도록 데이터가 고르게 분산
    • 구조상, 고속화를 위해 CPU와 디스크 모두를 균형 있게 늘려야함

데이터 접근

• 열 지향(column-oriented)

  • 빅데이터로 취급되는 데이터 대부분은 디스크 상에 있기 때문에 쿼리에 필요한 최소한의 데이터만을 가져옴으로써 지연이 줄어들게 됨

• 행 지향(row-orinted database)

  • 일반적으로 업무 시스템 등에서 사용되는 데이터베이스는 레코드 단위의 읽고 쓰기에 최적화
  • Oracle Database MySQL

• 열 지향 데이터베이스, 칼럼 지향 데이터베이스(칼럼을 압축하여 디스크 I/O를 줄이기)

  • Teradata(테라데이터), Amazon Redshint
  • 칼럼별로 데이터를 보관해두고, 집계 시에 관련된 칼럼만 읽어 들임
  • 열 지향 데이터베이스는 그 데이터 구조상 집계하는 데는 고속이지만, 저장하는 데는 시간이 걸림

• 행 지향 데이터 베이스(각 행이 디스크 상에 일련의 데이터로 기록)

  • 테이블의 각 행을 하나의 덩어리로 디스크에 저장
  • 각 행이 디스크 상에서 일련의 데이터로 쓰여짐, 새로운 레코드를 추가할 경우네 끝부분에 추가되므로 고속으로 쓰기가 가능
    • 2017-01-01 상품A 1234
    • 2018-01-01 상품B 1234
    • 2019-01-01 상품A 2345
  • 데이터 검색을 고속화하기 위해 인덱스를 만듬, 만약 인덱스가 없다면 저장되는 모든 데이터를 로드해야 원하는 레코드를 찾을 수 있으므로 많은 디스크 I/O가 발생해서 성능이 저하 -> 적절한 인덱스를 사용되도록 튜닝하는 것이 중요

데이터 처리의 성능

• 일정 시간에 처리할 수 있는 데이터의 양(처리량, throughput) : 배치 처리 등의 대규모 데이터 처리에서 중요시
• 데이터 처리가 끝날 때까지의 대기 시간(지연), 주로 애드 혹 데이터 분석 등에서 중시

대시보드 도구

• 대시보드 도구 : 새로운 그래프를 쉽게 추가할 수 있는 것이 중시

  • 정해진 지표의 일상적인 변화를 모니터링 하고 싶은 경우

• BI 도구 : 대화형 데이터 탐색이 중요시

  • 그래프를 클릭하여 상세한 표시로 전환하거나 집계에 기반이 되는 로우 데이터(원시 데이터)를 표시하는 등 시간을 들여 차분히 데이터를 보고 싶은 경우

• Redash(SQL에 의한 쿼리의 실행 결과를 그대로 시각화)

  • 다수의 데이터 소스에 대응하는 파이썬으로 만든 대시보드 도구로 SQL에 의한 쿼리의 실행 결과를 그대로 시각화하는 데에 적합
  • Redash의 구조는 알기 쉽고, SQL로 쿼리를 작성해서 그래프로 만들거나 또는 그 결과를 팀 내에서 공유하기 위한 콘솔로 우수
  • BI 도구만큼 ㅁ대량의 데이터를 처리할 수 없다는 점에서 주의가 필요

• Superset(화면상에서 마우스 조작만으로 그래프 만들기)

  • 대화형 대시보드(interactive dashboard)를 작성하기 위한 파이썬으로 만든 웹 애플리케이션
  • 화면상으로 마우스 조작으로 그래프를 만드는 것
  • 데이터 집계는 외부 데이터 저장소에 의존하고 있음, 시계열 데이터에 대응한 열 지향 스토리지인 Druid를 표준으로 지원하며 스트리밍 형의 데이터 전송과 조합시킴으로써 실시간 정보를 취급

• Kibana(Elasticsearch의 프런트 엔드에서 실시간으로 작성)

  • 자바스크립트로 만들어진 대화식 시각화 도구, 실시간 대시보드를 만들 목적으로 자주 이용
  • 검색 엔진인 Elasticsearch의 프런트 엔드로 개발되었기 때문에 도입에는 Elasticsearch가 필수적
  • Elasticsearch 이외의 데이터 소스에는 대응하고 있지 않아 시각화하려는 데이터는 모두 Elasticsearch에 저장

OLAP(online analytical processing)

• 데이터 집계를 효율화하는 접근 방법 중의 하나
• MDX(multidimensional expressions) : 다차원 모델의 데이터 구조 등의 쿼리 언어로 집계
• 데이터 분석을 위해 만들어진 다차원 데이터를 OLAP 큐브(OLAP cube) -> 이것을 크로스 집계하는 구조가 OLAP

테이블 비정규화

• 트랜잭션(transaction) : 시간과 함께 생성되는 데이터를 기록한 것
  • 한번 기록하면 변화하지 않음
• 마스터(master) : 트랜잭션에 참고되는 각종 정보
  • 상황에 따라 다시 쓰임
• 팩트테이블(fact table) : 트랙잭션처럼 사실이 기록된 것
• 디멘전 테이블(dimension table) : 거기에 참고되는 마스터 데이터 등
• 스타 스키마(star schema) : 팩트 테이블을 중심으로 여러 디멘전 테이블을 결합하는것
• 다차원 모델
  • 비정규화 테이블을 준비했다면 그것을 다차원 모델에 의해 추상화
  • BI 도구의 기본이 되는 데이터 모델로 테이블 및 칼럼의 집합을 알기 쉽게 정리해 이름을 붙인 것
  • 측정값(measure) : 숫자 데이터와 그 집계 방법을 정의하는 것
  • 디멘젼(dimension) : 크로스 집계에 있어서의 행과 열을 이용하는 것
• 브레이크 다운 분석(breadkdown analysis) : 복잡한 데이터를 분석하기 쉽게 하려면 데이터를 몇 개의 그룹으로 분산하여 각 그룹에 내용을 정리하는 것이 효과적

대규모 분산 처리의 프레임워크

구조화 데이터와 비구조화 데이터

• 스키마(schema) : 테이블의 칼럼 명과 데이터형, 테이블 간의 관계 등을 일컬음
• 구조화된 데이터 : 스키마가 명확하게 정의된 데이터
• 비구조화된 데이터 : 텍스트 데이터와 이미지, 동영상 등의 미디어 데이터가 포함된 스키마가 없는 데이터를 의미함
  • 비구조화 데이터를 읽어 들여 열 지향 스토리지로 변환하는 과정에서는 데이터의 가공 및 압축을 위해 많은 컴퓨터 리소스가 소비
  • Hadoop과 Spark 등의 분산 처리 프레임워크
• 스키마리스 데이터(schemaless data) : CSV ,JSON, XML 등의 데이터는 서식은 정해져 있지만, 칼럼 수나 데이터형은 명확하지 않음
• Apache ORC : 구조화 데이터를 위한 열 지향 스토리지로 처음에는 스키마를 정한 후 데이터를 저장
• Apache Parquet : 스키마리스에 가까운 데이터 구조로 되어 있어 JSON 같은 뒤얽힌 데이터도 그대로 저장 가능

Hadoop(분산 데이터 처리의 공통 플랫폼)

• 단일 소프트웨어가 아니라 분산 시스템을 구성하는 다수의 소프트웨어로 이루어진 집합체

• 분산 시스템의 구성 요소

  • 분산 파일 시스템(distributed file system) : HDFS(Hadoop Distributed File System)
    • HDFS는 분산 시스템의 스토리지를 관리하여 데이터가 항상 여러 컴퓨터에서 복사되도록 함
    • Hadoop에서 처리되는 데이터 대부분은 분산 파일 시스템인 HDFS에 저장
    • 네트워크에 연결된 파일 서버와 같은 존재, 다수의 컴퓨터에 파일을 복사하여 중복성을 높임
  • 리소스 관리자(resource manager) : YARN(Yet Another Resource Negotiator)
    • YARN은 CPU와 메모리를 관리하고 리소스에 여유가 있는 컴퓨터에서 프로그램을 실행
    • CPU나 메모리 등의 계산 리소스는 매니저인 YARN에 의해 관리됨
    • YARN은 애플리케이션이 사용되는 CPU코어와 메모리를 컨테이너(container)라 불리는 단위로 관리
  • 분산 데이터 처리(distributed data processing)의 기반 : MapReduce
    • MapReduce도 YARN 상에서 동작하는 분산 애플리케이션 중 하나이며, 분산시스템에서 데이터 처리를 실행하는 데 사용
    • 원래 대량의 데이터를 배치 처리 하기 위한 시스템
    • 임의의 자바 프로그램을 실행시킬 수 있기 때문에 비구조화 데이터를 가공하는 적합
    • 데이터 처리의 스테이지가 바뀔 때 대기 시간이 있어서 복잡한 쿼리에서는 대기 시간만 증가
  • 쿼리 엔진
    • SQL 등의 쿼리 언어에 의한 데이터 집계가 목적이라면 그것을 위해 설계된 커리 엔진
    • Apache Hive : 쿼리를 자동으로 MapReduce 프로그램으로 변환하는 소프트웨어로 개발됨
      • Hive on Tez : HIve를 가속화하기 위한 노력의 하나로 개발된 것, 기존의 MapReduce를 대체할 목적으로 개발된 프로젝트, MapReduce에 있던 몇 가지 단점을 해소함으로써 고속화를 실현
      • 대량의 비구조화 데이터를 가공하는 무거운 배치 처리에는 높은 처리량(Throughput)으로 리소스를 활용할 수 있는 Hive를 이용
      • SQL-on-Hadoop : Hadoop에서는 다수의쿼리 엔진이 개발되어 있으며 그것들을 총칭해서 일컬음
  • 대화형 쿼리 엔진
    • Hive를 고속화하는 것이 아니라 처음부터 대화형의 쿼리 실행만 전문으로 하는 쿼리 엔진
      • Hive 메타 스토어(Hive Metastore)라고 불리는 특별한 데이터베이스에 저장
      • Hive는 데이터베이스가 아닌 데이터 처리를 위한 배치 처리 구조
      • 원래 데이터가텍스트이든 스키마리스 데이터이든 간에 그것이 Hive에서 읽을 수 있는 형식이라면 무엇이든지 쿼리를 조금 고쳐 쓰는 것만으로 어떤 테이블이라도 만들 수 있음
        • 데이터 구조화가 완료되면 데이터 마트 구축 시작 -> 테이블을 결합 및 집약해서 비정규화 테이블을 만듬 -> Presto 같은 대화형 쿼리 엔진을 사용할 것인지, Hive 같은 배치형 쿼리 엔진을 사용할 것인지 고민
        • 시간이 걸리는 배치 처리는 원칙적으로 Hive를 사용 ( 비정규화 테이블이 수억 레코드나 되면, 그것을 데이터 마트로 내보내는 것만으로도 상당한 시간이 소요) -> 쿼리 엔진 자체의 성능은 최종적인 실행 시간에 그다지 많은 영향을 끼치지 않고 배치형 시스템을 사용하는 편이 리소스의 이용 효율을 높일 수 있음
    • Presto(페이스북에 출시됨)
      • Hive와 같은 배치형 쿼리 엔진은 대량 출력을 수반하는 대규모 데이터 처리에 적합하지만, 작은 쿼리를 여러 번 실행하는 대화형 데이터 처리에는 부적합, 쿼리 실행의 지연을 감소시키는 것을 목적으로 개발된 것이 대화형 쿼리 엔진
      • 다수의 컴퓨터에서 실행되는 분산 시스템, 하나의 코디네이터(Presto Coordinator)와 여러 워커(Presto Worker)로 구성, 쿼리는 Presto CLI 등의 클라이언트에서 코디네이터로 전송됨
      • 플러그인 가능한 스토리지 설계, Hive 메타 스토어 이외에도 다양한 데이터 소스를 테이블로 참고
      • ORC 형식의 로드에 최적화되어 있으며, 그것을 확장성이 높은 분산 스토리지에 배치하여 최대의 성능을 발휘
      • 분산 결합(distribute join)을 실시, 같은 키를 갖는 데이터는 동일한 노드에 모임, 분산 결합에서는 노드 간의 데이터 전송을 위한 네트워크 통신이 발생하기 때문에 종종 쿼리의 지연을 초래 -> 브로드캐스트 결합(broadcast join)을 사용하여 처리 속도를 크게 고속화 가능, 결합하는 테이블의 모든 데이터가 각 노드에 복사됨
      • SQL의 실행에 특화된 시스템으로 쿼리를 분석하여 최적의 실행계획을 생성하고 그것을 자바의 바이트 코드로 변환
    • Presto와 Impara는 YARN과 같은 범용적인 리소스 관리자를 사용하지 않고 SQL의 실행만 특화한 독자적인 분산 처리를 구현하고 있음, MPP데이터베이스처럼 멀티코어를 활용하면서 가능한 한 많은 데이터 처리를 병렬화함으로써 고속화를 실현

• 다양한 소프트웨어 중에서 자신에게 맞는 것을 선택하고 그것들을 조합함으로써 시스템을 구성하는 것이 Hadoop을 중심으로 하는 데이터 처리의 특징

Spark - 인 메모리형의 고속 데이터 처리

• 대량의 메모리를 활용하여 고속화를 실현하는 것
• MapReduce를 대체하는 존재
• Hadoop을 이용하지 않는 구성도 가능하며, 분산 스토리지로 Amazon S3를 이용하거나 분산 데이터베이스인 카산드라(cassandra)에서 데이터를 읽어 들이는 것도 간으
• Spark의 실행은 자바 런타임이 필요하지만, Spark 상에서 실행되는 데이터 처리는 스크립트 언어를 사용할 수 있다는 점도 매력
• Spark에서는 중간 데이터를 디스크에 쓰지 않고 메모리에 보존, 프로그램 실행 중에는 많은 메모리가 필요하지만, 실행 시간은 단축됨, 장애 등으로 메모리 상의 중간 데이터를 읽어버려도, 한 번 더 입력 데이터로 다시 실행하며 중간 데이터는 의도적으로 디스크 상에 캐시하는 것도 가능
• SQL로 쿼리를 실행하기 위한 Spark SQL과 스트림 처리를 수행하기 위한 Spark Streaming
• 대규모 배치 처리뿐만 아니라 SQL에 의한 대화형 쿼리 실행과 실시간 스트림 처리에 이르기까지 널리 이용됨
• 고속화를 방해하는 다른 하나 문제는 데이터 편차(data skew)로 중복이 없는 값을 세려면 데이터를 한곳에 모아야 해서 분산 처리하기 어려워지기 때문

데이터 분석의 프레임워크 선택하기

• MPP 데이터베이스 - 완성한 비정규 테이블의 고속 집계에 적합
  • 구조화 데이터를 SQL로 집계하는 것뿐 -> 기존의 데이터 웨어하우스 제품과 클라우드 서비스를 이용하는것이 가장 좋음
  • 스토리지 및 계산 노드가 일체화되어 있어 처음에 ETL 프로세스 등으로 데이터를 가져오는 절차가 필요, 이 부분만 완성되면 그 다음은 SQL만으로 데이터를 집계할 수 있으므로 이 장에서 다루는 기술은 아무것도 필요없음
  • 확장성 및 유연성 등의 측면에서는 분산 시스템에 유리
  • 시각화를 위한 데이터 마트로만 생각하면 유리
• Hive - 데이터양에 좌우되지 않는 쿼리 엔진
  • 높은 확장성과 내결함성을 목표로 설계됨
  • 대규모 배치 처리를 꾸준히 실행한다는 점에서 실적
  • 텍스트 데이터를 가공하거나 열 지향 스토리지를 만드는 등의 무거운 처리는 아무래도 처리 시간이 길어지는 경향이 있어서 Hive에서 실행하는것이 적합
  • 분산시스템의 동향은 서서히 인 메모리의 데이터 처리로 옮겨 가고 있지만, Hive는 앞으로도 데이터양에 좌우되지 않는 쿼리 엔진으로 계속 이용될 것
• Presto - 속도 중시&대화식으로 특화된 쿼리 엔진
  • 속도로 인해 다양한 것을 희생, 쿼리의 실행 중에 장애가 발생하면 오류가 떠서 처음부터 다시 실행, 메모리가 부족하면 쿼리를 실행할 수 없는 경우도 있음
  • 대화식 쿼리의 실행에 특화되어 있기 때문에 텍스트 처리가 중심이 되는 ETL 프로세스 및 데이터 구조화에는 적합하지 않음
• Spark - 분산 시스템을 사용한 프로그래밍 환경
  • 인 메모리의 데이터 처리가 중심이며 Presto 뿐만 아니라 대화형 쿼리 실행에 적합
  • ETL 프로세스에서 SQL에 이르기까지의 일련의 흐름을 하나의 데이터 파이프라인으로 기술
  • 분산 시스템을 사용한 프로그래밍 환경으로 ETL프로세스이거나 머신러닝 같은 모든 데이터 처리에 사용 가능
  • 메모리를 어떻게 관리하느냐가 중요 -> 여러 번 이용하는 데이터 캐시에 올려놓거나, 디스크에 스왑(Swap) 시킴으로써 메모리를 해제하는 등 메모리 사용을 프로그래머가 어느 정도 제어할 수 있음
    • Apache Mesos : Yarn과 함께 분산 시스템에서 사용되는 리소스 관리자
      • OS 수준의 가상화 기술을 사용 , Yarn보다 더 엄격한 리소스 제어
      • Linux 컨테이너(LXC)가 사용되며 Docker 이미지를 사용하여 프로그램을 실행할 수 있음
      • YARN은 HDFS와 연계함으로써 데이터가 어디에 있는가 하는 정보를 사용하여 애플리케이션을 실행, HIve와 같은 대규모 배치 처리는 되도록 데이터 부근에서 실행하는 것이 효율이 높기 때문에 YARN을 사용하는 것이 적합, Mesos는 HDFS의 존재를 알지 못하므로 동일한 일을 실현하기 위해서는 이용자가 여러 궁리를 해야함

데이터 마트의 구축

• 팩트 테이블 - 시계열 데이터 축적하기
  • 추가(append) : 새로 도착한 데이터만을 증분으로 추가
  • 치환(replace) : 과거의 데이터를 포함하여 테이블 전체를 치환
• 테이블 파티셔닝 - 물리적인 파티션으로 분할
  • 하나의 테이블을 여러 물리적인 파티션으로 나눔으로써 파티션 단위로 정리하여 데이터를 쓰거나 삭제할 수 있도록 함
    • 추가에 실패한 것을 알아채지 못하면 팩트 테이블의 일부에 결손이 발생
    • 추가를 잘못해서 여러 번 실행하면 팩트 테이블의 일부가 중복
    • 나중에 팩트 테이블을 다시 만들고 싶은 경우의 관리가 복잡
• 집계 테이블 - 레코드 수 줄이기
  • 팩트 테이블을 어느 정도 모아서 집계하면 데이터의 양이 크게 줄어듬
  • 일일 집계(daily summary) : 데이터를 1일 단위로 집계
  • 카티널리티(cardinality) : 칵 칼럼이 취하는 값의 범위
    • 성별과 같이 취합 할 수 있는 값이 적은 것은 카디널리티가 작음
    • IP주소와 같이 여러 값이 있는 것은 카디널리티가 커짐
• 스냅샷 테이블 - 마스터의 상태를 기록하기
  • 마스터 데이터처럼 업데이트될 가능성이 있는 테이블에 대해서는 두 가지 방안이 존재
    • 스냅샷 테이블(snapshot table) : 정기적으로 테이블을 통째로 저장하는 방법
    • 이력테이블(history table) : 변경 내용만을 저장하는 방법, 마스터 변화 기록하기
      • 변경된 데이터만을 증분으로 스냅샷 하거나 변경이 있을 때마다 그 내용을 기록

빅데이터의 축적

• 객체 스토리지와 데이터 수집(분산 스토리지에 데이터 읽어들이기)

  • 빅데이터는 대부분의 경우 확장성이 높은 분산 스토리지(distributed storage)에 저장
  • 대량으로 파일을 저장하기 위한 객체 스토리지(object storage)
    • 다수의 컴퓨터를 사용하여 파일을 여러 디스크에 복사함으로써 데이터의 중복화 및 부하 분산을 실현
  • Hadoop이라면 HDFS, 클라우드 서비스라면 Amazon S3
  • 데이터 수집(data ingestion) : 수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스
    • 데이터 수집부터 구조화 데이터의 작성, 분산 스토리지에 대한 장기적인 저장 등이 포함

• 벌크 형의 데이터 전송 - ETL 서버의 설치 필요성

  • 전통적인 데이터 웨어하우스에 사용, 데이터베이스나 파일 서버 또는 웹 서비스 등에서 각각의 방식(SQL, API 등)으로 정리해 데이터를 추출
  • 데이터 전송을 위한 ETL서버(ETL server)를 설치
  • ETL 프로세스는 하루마다 또는 1시간 마다의 간격으로 정기적인 실행을 하므로 그동안 축적된 데이터는 하나로 모임
  • 워크플로 관리 도구 : 정기적인 스케줄 실행 및 오류 통지 등
    • 매일 매일의 마스터 데이터의 스냅샷과 신뢰성이 중시되는 과금 데이터 전송 등은 다른 배치처리와 함께 워크플로의 일부에 포함되는 것이 좋음

• 스트리밍 형의 데이터 전송 - 계속해서 전송되어 오는 작은 데이터를 취급하기 위한 데이터 전송

  • HTTP(실제로는 암호화된 HTTPS) : 웹 브라우저나 모바일 앱은 메시지 배송의 통신 프로토콜

  • MQTT(MQ Telemetry Transport) : IoT 같은 머신 데이터는 MQTT등의 오버헤드가 작은 프로토콜이 사용되는 경우도 있음

  • 메시지 배송(message delivery) : 다수의 클라이언트에서 계속해서 작은 데이터가 전송되는 것

    • 전송되는 데이터양에 비해 통신을 위한 오버헤드가 커지기 때문에 이를 처리하는 서버는 높은 성능을 요구
    • 작은 데이터 쓰기에 적합한 NoSQL 데이터베이스를 이용
    • 메시지 큐(message queue)와 메시지 브로커(message broker) 등의 중계 시스템에 전송 -> 기록된 데이터는 일정한 간격으로 꺼내고 모아서 함께 분산 스토리지에 저장
      • 메시지 브로커 - 스토리지의 성능 문제를 해결하는 중간층의 설치
        • 빅데이터의 메시지 배송 시스템에서는 종종 데이터를 일시적으로 축적하는 중산층이 설치되며 이것을 뜻함
        • 빅데이터를 위한 분산형 메시지 브로커는 오픈 소스의 경우 Apache Kafka(아파치 카프카)가 유명, 클라우드 서비스라면 Amazon Kinesis(아마존 키네시스)등이 유명
        • 푸쉬 형과 풀 형 - 확장성 향상과 파일 사이즈의 적정화
          • 푸시(push) 형 : 송신 측의 제어로 데이터를 보내는 방식
          • 풀(pull) 형 : 수신 측의 주도로 데이터를 가져오는 것
          • 생산자(producer) : 메시지 브로커에 데이터를 넣는 것
          • 소비자(consumer) : 메시지 브로커에 데이터를 꺼내오는 것
          • 메시지 브로커는 데이터의 쓰기 속도를 조정하기 위한 완충 부분이며, 푸쉬 형에서 풀 형으로 메시지 배송의 타이밍을 변환
          • 스트림 처리(stream processing) : 짧은 간격으로 차례대로 데이터를 꺼내서 처리하는 것
          • 메시지 라우팅(message routing) : 메시지 브로커에 써넣은 데이터는 복수의 다른 소비자에서 읽어 들일 수 있ㅇ므, 이를 통해 메시지가 복사되어 데이터를 여러 경로로 분기
            • 메시지 일부를 실시간 장애 감지를 사용하면서 같은 메시지를 장기적인 데이터 분석을 위한 분산 스토리지에 저장하는 것도 가능

  • 웹 브라우저에서의 메시지 배송 - Fluentd, Logstash, 웹 이벤트 트래킹

    • 웹 서버 안에서 메시지를 만들어 배송
    • 전송 효율을 높이기 위해 서버상에서 일단 데이터를 축적해 놓고 나중에 모아서 보내는 경우가 많음
    • Fluentd나 Logstash와 같은 서버 상주형 로그 수집 소프트웨어가 자주 사용
    • 웹 이벤트 추적(web event tracking) : 자바스크립트를 사용하여 웹 브라우저에서 직접 메시지를 보내느 경우도 있음

  • 모바일 앱으로부터의 메시지 배송 - MBaaS, SDK

    • 모바일 앱은 HTTP 프로토콜을 사용하는 클라이언트 중 하나이므로 메시지 배송 방식이 웹 브라우저와 동일
    • MBaaS(Mobile Backend as a Service)라는 백 엔드의 각종 서비스를 이용
    • 모바일앱에 특화된 액세스 해석 서비스를 통해 이벤트 데이터를 수집 -> 모바일 용의 편리한 개발 키트(SDK)를 사용하여 메시지를 보냄

  • 디바이스로부터의 메시지 배송(MQTT의 예)

    • TCP/IP를 사용하여 데이터를 전송하는 프로토콜의 하나, Pub/Sub 형 메시지 배송(Pub/Sub message delivery)이라는 구조, 전달(publish)과 구독(subscription)의 약자이며 채팅 시스템이나 메시징 앱 또는 푸시 알림 등의 시스템에서 자주 사용되는 기술
    • MQTT는 관리자에 의해 토픽(topic)이 만들어짐 -> 메시지를 송수신 하기 위해 대화방과 같은 것으로 그 토픽을 구독하면 메시지가 도착하게 되고, 그 토픽을 전달하면 구독 중인 모든 클라이언트에 보내짐,
      • MQTT 브로커(MQTT broker) : 메시지의 교환을 중계하는 서버
      • MQTT 구독자(MQTT subscriber) : 메시지를 수신하는 시스템
      • MQTT에서 데이터를 수집하려면 먼저 토픽을 작성하고 그것을 구독 -> 각 디바이스가 토픽에 메시지를 전달하는 프로그램을 작성하고 나면 MQTT가 정하는 규칙에 따라 메시지 배송이 이루어짐 -> MQTT의 특징 중의 하나로서 네트워크에서 분리된 경우에는 나중에 재전송하는 구조가 프로토콜 수준에서 고려되고 있음

  • 메시지 배송의 공통화 - 다른 부분과 공통되는 부분을 분리해서 생각하기

    • 클라이언트(client) : 메시지가 처음 생성되는 기기
    • 프런트 엔드(frontend) : 해당 메시지를 먼저 받는 서버
      • 클라이언트와의 통신 프로토콜을 제대로 구현하는 것, 악의적인 공격으로부터 데이터를 보호하기 위해 암호화와 사용자 인증을 구현하고 성능 문제를 해결하기 위해 높은 확장성도 필요

  • 메시지 배송 - 신뢰성 문제와 세 가지 설계 배송

    • at most once
      • 메시지는 한 번만 전송됨, 그러나 도중에 전송에 실패해서 사라질 가능성이 있다(결손 발생)
      • 무슨 일이 일어나도 절대로 메시지를 다시 보내지 않는다, 데이터의 결손을 피하고자 재전송(retransmission)이 이루어짐
    • exactly once
      • 메시지는 손실되거나 중복 없이 한 번만 전달됨
      • 네트워크상에서 분단되 두 개의 노드가 있는 경우에 양쪽의 통신 내요을 보장하려면 그 사이에 중계하는 코디네이터(coordinator)의 존재가 필수적
        • 분산 시스템에서는 코디네이터가 항상 존재한다고 가정할 수 없음 -> 성능상의 문제로 코디네이터의 판단에만 따르고 있으면 시간이 너무 소요
    • at least once - 중복 제거는 사용자에게 맡김
      • 메시지는 확실히 전달됨, 단, 같은 것이 여러 번 전달될 가능성이 있다(중복)
      • 메시지가 재전송되어도 그것을 없앨 수 있는 구조만 있으면 보기에 중복이 없는 것처럼 보이게 할 수 있음

  • 중복 제거는 높은 비용의 오퍼레이션

    • 메시지의 중복을 제거하려면 과거에 받은 것인지에 대한 여부를 판정
      • 오프셋을 이용한 중복 제거
      • 고유 ID에 의한 중복 제거 - UUID(Universally Unique IDentifier)
      • 종단간(End to End)의 신뢰성
      • 고유 ID를 사용한 중복 제거의 방법 - NoSQL 데이터베이스, SQL

• 시계열 데이터의 최적화

  • 프로세스와 시간과 이벤트 시간
    • 이벤트 시간(event time) : 클라이언트 상에서 메시지가 생성된 시간
    • 프로세스 시간(process time) : 서버가 처리하는 시간
    • 풀 스캔(full scan) : 다수의 파일을 모두 검색하는 쿼리

• 비구조화 데이터의 분산 스토리지

  • NoSQL 데이터베이스에 의한 데이터 활용

    • 쓰기 빈도가 높은 데이터는 별도 RDB에 저장하고 정기적으로 스냅샷을 하거나 분산 데이터베이스(distributed database)에 저장
    • 분산 KVS(distributed Key-Value Store) - 디스크로의 쓰기 성능을 높이기
      • 모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소
      • 마스터/슬레이브 형 시스템 : 1대의 마스터가 전체를 관리하게 되어 있어 마스터가 중지되면 아무도 데이터를 읽고 쓸 수 없음
      • P2P형의 시스템 : 모든 노드가 대등한 관계이므로, 클라이언트는 어떤 노드에 연결해도 데이터를 읽고 쓸 수 있음
    • Amazon DynamoDB
      • 항상 안정된 읽기 쓰기 성능을 제공하도록 디자인된 분산형 NoSQL 데이터베이스
      • 하나 또는 두 개의 키에 연결하는 형태로 임의의 스키마리스 데이터를 저장할 수 있음
      • JSON과 같이 중첩된 데이터 구조도 취급할 수 있어 간단한 분산 KVS라기보다는 도큐먼트 스토어로 사용
      • P2P 형의 분산 아키텍처를 소유
      • 미리 설정한 초 단위의 요청 수에 따라 노드가 증감되는 특징
      • 데이터의 읽기 및 쓰기에 지연이 발생하면 곤란한 애플리케이션에 유용
      • Amazon EMR 및 Amazon Redshift 등과 결합함으로써 Hive에 의한 배치 처리를 실행하거나 데이터 웨어하우스에 데이터를 전송
      • DynamoDB Streams를 사용하면 데이터 변경을 이벤트로 외부에 전송해 실시간 스트림 처리를 할 수 있음
      • NoSQL 데이터 베이스는 애플리케이션에서 처음에 데이터를 기록하는 장소로 이용 -> 대량의 데이터를 집계하는 기능이 없는 것이 많아 데이터 분석을 위해서는 외부로 데이터를 추출해야 함 -> RDB 등과 비교하면 읽기 성능이 높기 때문에 쿼리 엔진에서 접속해도 성능상의 문제는 발생하기 어려움 -> 애드 혹 분석 등에서는 데이터를 사전에 복사하지 않고 필요시 직접 연결 가능
        • ACID 특성
          • 원시성, 일관성, 독립성, 내구성
        • CAP 정리
          • 일관성, 가용성, 분단내성

  • 와이드 칼럼 스토어 - 구조화 데이터를 분석해서 저장하기

    • 와이드 칼럼 스토어(wide-column store) : 분산 KVS를 발전시켜 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것
      • Google Cloud Bigtable, Apache HBase, Apache Cassandra(아파치 카산드라)
      • 내부적으로 행 키와 칼럼 명의 조합에 대해 값을 저장
      • 주로 성능 향상을 목표로 함
    • Apache Cassandra
      • 내부적인 데이터 저장소로 와이드 칼럼 스토어를 이용하면서 CQL이라 불리는 높은 수준의 쿼리 언어가 구현
      • P2P 형의 분산 아키텍처를 보유, 지정한 키에 의해 결정한 노드에 해당 키와 관련된 모든 값을 저장

  • 도큐먼트 스토어(document store) - 스키마리스 데이터 관리하기

    • 데이터 처리의 유연성을 목적, 구체적으로는 JSON처럼 복잡하게 뒤얽힌 스키마리스 데이터를 그대로의 형태로 저장하고 쿼리를 실행
    • 스키마를 정하지 않고 데이터 처리를 할 수 있다는 점, 외부에서 들여온 데이터를 저장하는 데 특히 적합

  • MongoDB

    • 오픈 소스의 분산형 도큐먼트 스토어로 자바스크립트나 각종 프로그래밍 언어를 사용하여 데이터를 읽고 쓸 수 있음

  • 검색 엔진(search engine) - 키워드 검색으로 데이터 검색

    • 저장된 데이터를 쿼리로 찾아낸다는 점에서는 유사한 부분도 많고, 특히 텍스트 데이터 및 스키마리스 데이터를 집계하는데 자주 사용
    • 텍스트 데이터를 전문 검색하기 위해 역 색인을 만드는 부분, 데이터를 기록하는 시스템 부하 및 디스크 소비량은 커지지만, 그 덕분에 키워드 검색이 훨씬 고속화됨
      • 역 색인(inverted index) : 텍스트에 포함된 단어를 분해하고 어떤 단어가 어떤 레코드에 포함되어 있는가 하는 인덱스를 먼저 만들어 둠으로써 검색을 고속화
    • Elasticssearch
      • ELK 스택 또는 Elastic 스택으로 자주 이용
        • Logstash : 로그 수집 소프트웨어
        • Kibana : 시각화 소프트웨어
      • 임의의 JSON 데이터를 저장할 수 있기 때문에 도큐먼트 스토어와 비슷, 아무것도 지정하지 않으면 모든 필드에 색인이 만들어지는 특징
      • 자체 쿼리 언어에 의한 고급 집계 기능을 제공, 열 지향 스토리지에도 대응
    • Splunk(스플렁크)
      • 상용 검색 엔진
      • 비정형 데이터, 주로 웹서버나 네트워크 기기 등으로부터 출력되는 로그 파일이나 JSON 파일을 다루어 텍스트 처리를 해야만 분석할 수 있는 데이터

빅데이터의 파이프라인

• 워크플로 관리 - 데이터의 흐름을 일원 관리하기

  • 워크플로 관리(workflow management) : 기업 내의 정형적인 업무프로세스(신청,승인,보고 등)와 같이 정해진 업무를 원활하게 진행하기 위한 구조
  • 워크플로 관리 도구 : 정기적으로 태스크를 실행하고 비정상적인 상태를 감지하여 그것에 대한 해결을 돕는 것
    • 기능
      • 태스크를 정기적인 스케줄로 실행하고 그 결과 통지하기
      • 태스크 간의 의존 관계를 정하고, 정해진 순서대로 빠짐없이 실행하기
      • 태스크의 실행 결과를 보관하고, 오류 발생 시에는 재실행할 수 있도록 하기
      • Hadoop에서의 잡(Job)을 손쉽게 호출하거나 집계 결과를 데이터 마트에 기록하는 기능을 제공하는 등 데이터 파이프라인의 모든 태스크를 일원관리하기 쉽게 한 것이 빅데이터를 위한 워크플로 관리 도구
    • 선언형(declarative) 도구
      • XML 이나 YAML 등의 서식으로 워크플로를 기술하는 타입
    • 스크립트 형(scripting) 도구
      • 스크립트 언어로 워크플로를 정희하는 유형
  • 태스크(task) : 데이터 파이프라인의 실행 과정에서 데이터를 잇달아 이동하면서 정해진 처리를 반복하며 실행되는 개별 처리를 뜻함
  • 오류 : 네트워크의 일시적인 장애, 하드웨어의 장애, 스토리지의 용량 부족, 쿼리 증가에 따른 성능 부족 -> 태스크의 실행 순서를 정하는 것과 동시에 오류로부터 어떻게 회복할 것인가라는 계획을 정함
  • 플로우(flow) : 워크플로 관리 도구에 의해 실행되는 일련의 태스크
  • 재시도(retry) : 여러 번 발생하는 오류에 대해서는 되도록 자동화하여 수작업 없이 복구 및 단순한 재실행
  • 백필(backfill) - 일정 기간의 플로우를 연속해서 실행하는 구조
    • 실패한 플로우를 보구하는 다른 하나의 수단은 플로우 전체를 처음부터 다시 실행하는 것
    • 파라미터에 포함된 일시를 순서대로 바꿔가면서 일정 기간의 플로우를 연속해서 실행하는 구조

• 멱등한 조작으로 태스크를 기술 - 동일 태스크를 여러 번 실행해도 동일한 결과

  • 원자성 조작(atomic operation) : 트랜잭션 처리에 대응한 데이터베이스라면, 여러 번의 쓰기를 한 번의 트랜잭션으로 실행할 수 있지만, 그렇지 않다면 쓰기가 필요한 수만큼 태스크를 나누도록 하며 이를 뜻함
  • 멱등한 조작(idempotent operation) - 추가와 치환
    • 동일한 태스크를 여러 번 실행해도 동일한 결과가 되도록 하는것 - SQL이라면 테이블을 삭제한 후 다시 만들기
    • 추가(append) : 분산 스토리지에 파일을 업로드한다면, 매번 새로운 파일명을 만들 경우
    • 치환(replace) : 동일 파일명으로 덮어쓰기
    • 테이블 파티셔닝 : 테이블을 1일마다 또는 1시간마다 파티션으로 분할하고, 파티션 단위로 치환

• 태스크 큐 - 자원의 소비량 컨트롤 하기

  • 태스크의 크기나 동시 실행 수를 변화시킴으로써 자원의 소비량을 조정하여 모든 태스크가 원활하게 실행되도록 함 -> 외부 시스템의 부하 컨트롤
  • 잡 큐(job queue)
  • 태스크 큐(task queue)
  • 워커를 너무 증가시키면, 어디선가 병목 현상이 발생해서 성능의 향상이 한계점에 도달하거나 오류가 발생하기 시작
  • 워크플로 실행 시에 자주 발생하는 문제(서버의 내부적인 요인)
    • CPU 사용률 100% -> CPU 코어 수를 늘린다, 서버를 증설한다
    • 메모리 부족 -> 메모리를 증설한다. 스왑 디시크를 추가한다. 태스크를 작게 분할한다.
    • 디스크 넘침 -> 각 태스크가 임시 파일을 삭제하고 있는지 확인한다. 디스크를 증설한다.
    • 디스크 I/O의 한계 -> SSD 등의 고속 디스크를 사용한다. 여러 디스크로 분산한다
    • 네트워크 대역의 한계 -> 고속 네트워크를 사용한다. 데이터의 압축률을 높인다
    • 통신 오류나 타임 아웃 -> 시스템 상의 한계일 가능성이 있다. 서버를 분리한다.
  • 태스크 수의 적정화 - 너무 크거나 너무 작지 않은 정도로 분할하기
    • 작은 태스크를 다수 실행하면 오버헤드만 커져서 실행 시간이 증가하고 오류 발생률을 높이는 요인이 됨

• 배치 형의 데이터 플로우

  • 데이터 플로우(data flow) : 다단계의 데이터 처리를 그대로 분산 시스템의 내부에서 실행
  • 데이터 플로우를 위한 프레임워크
    • Google Cloud Dataflow
    • Apache Spark
    • Apache Flink
  • MapReduce의 구조
    • 분할된 데이터를 처리하는 단계인 Map, 그 결과를 모아서 집계하는 단계인 Reduce -> Map과 Reduce를 반복하면서 목적하는 결과를 얻을 때까지 계속해서 데이터를 변환해 나가는 구조가 MapReduce
    • Map과 Reduce를 반복한다는 사고방식은 지금도 유효하지만, 초기 MapReduce의 구현은 쓸데없는 것이 많아서 더 이상 시대에 맞지 않는 설계가 됨
  • Dag(directed acyclic graph)
    • 방향성 비순환 그래프
    • 수학과 컴퓨터 알고리즘에서 사용되는 데이터 모델의 하나
    • 성향
      • 노드와 노드가 화살표로 연결된다(방향성)
      • 화살표를 아무리 따라가도 동일 노드로는 되돌아오지 않는다(비순환)
    • 데이터 플로우에서는 실행해야 할 일련의 태스크를 DAG에 의한 데이터 구조로 표현함
    • 지연 편가(lazy evaluation) - DAG에 의한 프로그래밍의 특징
      • 프로그램의 각 행은 실제로는 DAG의 데이터 구조를 조립하고 있을 뿐, 거기서 특별히 뭔가를 처리하지는 않음
      • 데이터 파이프라인 전체를 DAG로 조립하고 나서 실행에 옮김으로써 내부 스케줄러가 분산 시스템에 효과적인 실행 계획을 세워주는 것이 데이터 플로우의 장점
    • 데이터를 읽어들이는 플로우
      • 외부 데이터 소스로부터의 읽어들이기에서는 어떤 오류가 발생할 지 예측불가, 그러한 부분에서는 워크플로를 이용하고 데이터 플로우에서는 안정된 분산 스토리지만을 이용
    • 데이터를 써서 내보내는 플로우
      • 외부 시스템으로의 데이터 전송에는 어떤 오류가 발생할 지 예측 불가, 데이터 플로우에서는 CSV와 같은 파일을 만들기만 하도록 하고,그것을 워크플로 안에서 전송

• 스트리밍 형의 데이터 플로우

  • 시스템 모니터링 : 서버와 네트워크의 상태를 감시하고, 그 시간 추이를 그래프로 표시
  • 로그 관리 시스템 : 운영체제(OS)의 시스템 이벤트나 로그 파일을 검색해서 비정상적인 상태라면 경고를 생성
  • 복합 이벤트 처리(Complex Event Processing, CEP) : 다수의 업무 시스템으로부터 보내온 이벤트 데이터를 자동으로 처리한다
  • 배치 처리
    • 도달한 데이터를 우선 분산 스토리지에 보관하고, 그것을 정기적으로 추출함으로써 데이터 처리를 함
    • 데이터가 영속적으로 보존되기 때문에 몇 번이고 재실행할 수 있음
    • 장기적인 데이터 분석을 예상하여 집계 효율이 높은 열 지향 스토리지를 구축할 수 있음
    • 유한 데이터(bounded data) : 배치 처리와 같이 실행 시에 데이터양이 정해지는 것
  • 스트림 처리
    • 데이터가 도달하는 것과 거의 동시에 처리가 시작됨
    • 처리 내용은 미리 정해 둘 피룡가 있으며, 과거로 거슬러 올라가 재실시하는 것은 고려하지 않음
    • 처리한 결과는 시계열 데이터에 적합한 데이터 스토어에 보관하거나, 기존 실시간 시스템에 전송함
    • 무한 데이터(unbouned data) : 스트림 처리와 같이 제한이 없이 데이터가 보내지는 것
  • 람다 아키텍처 - 배치 레이어, 서빙레이어 , 스피드 레이어
    • 모든 데이터는 반드시 배치 레이어(batch layer)에서 처리, 과거의 데이터를 장기적인 스토리지에 축적하고 여러 번이고 다시 집계 가능
    • 배치 처리 결과는 서빙 레이어(serving layer)를 통해서 접근, 응답이 빠른 데이터베이스를 설치하여 집계 결과를 바로 추출함
    • 서빙 레이어에서 얻어진 결과를 배치 뷰(batch view), 배치 뷰는 정기적으로 업데이트 되지만, 실시간 정보는 얻을 수 없음
      • 다른 경로로 스트림 처리를 하기 위해 스피드 레이어(speed layer) 설치
      • 스피드 레이어에서 얻은 결과를 실시간 뷰(realtime view), 배치 뷰가 업데이트될 동안까지만 이용되고, 오래된 데이터는 순서대로 삭제됨
  • 카파 아키텍처(kappa architecture)
    • 람다 아키텍처를 단순화한것
    • 람다 아키텍처로부터 배치 레이어나 서빙 레이어를 완전히 제거하고, 스피드 레이어만을 남김
    • 메시지 브로커의 데이터 보관 기간을 충분히 길게 하여 무슨 문제가 일어났을 때는 메시지 배송 시간을 과거로 다시 설정
    • 배치 처리와 같은 과거 데이터의 일괄 처리를 스트림 처리만으로 실행
  • 아웃 오브 오더의 데이터 처리(out of order)
    • 늦게 도달하는 메시지, 프로세스 시간과 이벤트 시간의 차이
    • 이벤트 시간 윈도윙(event-time windowing) : 이벤트시간에 의해 윈도우를 나누는 것

스키마리스 데이터의 애드 혹 분석

• Docker - 데이터 분석 환경 가상화하기
  • 가상 머신을 이용하면 컴퓨터를 바꾸어도 환경을 옮기는것이 간단하며, 프로젝트마다 환경을 전환하기가 쉽고, 팀 전원이 같은 환경을 공유할 수 있는 장점
  • 새로운 Docker 이미지를 작성하고, docker run 명령어로 컨테이너를 기동함
  • -volume 옵션을 사용하여 호스트 컴퓨터와 디스크를 공유 -> 노트북이 호스트 상에서 보존될수 있으므로 컨테이너를 정지해도 노트북이 사라지지 않음
• Spark에 의한 분산 환경 - 데이터양이 늘어도 대응 가능하게 하기
  • Spark는 마스터/슬레이브 형의 분산 시스템으로 클라이언트로부터 마스터에 명령을 보냄으로써 프로그램을 실행함,
    • 드라이버 프로그램(=클라이언트) : 주피터와 조합시키면 대화식 데이터 처리를 실행하기 쉬워짐
  • 실제 환경에서는 Spark 클러스터에 접속하여 아무런 지정을 하지 않아도 로컬 호스트에서 Spark 프로세스가 기동하므로 멀티 코어를 활용해 병렬 처리를 실행 가능
  • 텍스트 데이터의 가공(스크립트 언어의 활용) - 최대 장점으로 스크립트 언어에 의한 프로그래밍
  • RDD(Resilient Distributed Dataset)라 불리는 로우 레벨(low level)의 데이터 구조로 되어 있음
• BI 도구
  • 데스크톱형 : 컴퓨터에 직접 설치하는 BI 도구
  • 웹 애플리케이션 형 : 서버에 설치(클라우드 서비스로서 제공되는것)
• Hadoop에 의한 데이터파이프라인
  • 일일 배치 처리를 태스크화하기
    • 정기적으로 데이터를 전송하고 그것을 집계한 후 데이터 마트를 만드는 전형적인 데이터 파이프라인을 고려
    • 데이터 소스는 MongoDB를 이용, Hive로 열 지향 스토리지를 만들고 Presto로 집계
    • Embulk
      • MongoDB로부터 데이터를 추출하기 위해 오픈 소스의 벌크 전송 도구
• 워크플로 관리 도구에 의한 자동화
  • Airflow - 스크립트 형의 워크플로 관리
    • 파이썬으로 워크플로를 기술하는 스크립트 형의 도구
    • Airflow에 의한 워크플로는 여러 태스크로 이루어진 DAG의 형태로 정의
    • 의존 관계가 없는 태스크는 동시에 병렬로 실행
    • 모든 태스크를 시간과 관련지어 보존
      • Airflow의 태스크에는 컨텍스트로 항상 처리해야 할 데이터의 시간이 전달되는 점
      • 자원 풀(resource pool) 태스크의 동시 실행을 제한하기 위한 구조
    • airflow test : airflow test 명령어로 개별 태스크를 테스트함
    • airflow backfill : DAG에 포함되는 모든 태스크를 실행, 태스크의 실행 결과는 데이터베이스에 기록되고 실행 순서도 의존 관계에 따라서 결정, 시간의 시작부터 종료까지의 범위를 지정할 수 있음
    • airflow scheduler : Airflow로 태스크의 스케줄 실행을 시작, 데이터베이스의 상태를 정기적으로 점검하고 그다음으로 실행 가능한 태스크를 찾음
  • 태스크
    • Operator : 태스크를 만들기 위한 클래스
      • BashOperator : 워크플로부터 호출되는 태스크를 종종 셸 스크립트로서 실행되며 그것을 실행하는 것
      • PythonOperator : 태스크를 파이썬 함수로 구현, 직렬화(serialized)되어 지연 평가되므로 글로벌 스코프(global scope)로 정의
      • 컨텍스트(context) 각 태스크에 전달되는 실행 시의 파리미터
• 클라우드 서비스에 의한 데이터 파이프라인
  • 풀 매니지드 형(full managed) : 어느 정도 장애대응과 확장성의 확보까지 서비스 일부로 제공되는 것
  • 아마존 웹 서비스
    • Amazon S3 : 객체 스토리지
      • 기본적으로 COPY 명령에 의해 Redshift에 로드, Redshift Spectrum 기능을 이용하여 S3 상의 파일을 Redshift에서 직접 편집 가능
    • Amazon DynamoDB : NoSQL 데이터베이스
    • Amazon EMR : Hadoop&Spark
    • Amazon Athena : 쿼리 엔진(Presto)
    • Amazon Elasticsearch : 검색 엔진
    • Amazon Kinesis : 메시지 브로커
    • Amazon Kinesis Streams : 스트림 처리
    • Amazon Redshift : MPP 데이터베이스
      • 데이터 웨어하우스를 위한 MPP데이터 베이스, 스토리지와 계산 노드가 잋레화되어 있어 보존할 데이터양이 늘어나면 그것에 맞추어서 노드를 확장할 필요가 있음
      • 전통적인 데이터 웨어하우스 제품과 같은 구조여서 이용 빈도가 적은 데이터를 대량으로 보존해두는 데에는 그다지 적합하지 않음
    • Amazon QuickSight : BI 도구
  • 구글 클라우드플랫폼
    • 전세계의 데이터를 날마다 처리하고 있는 구글의 소프트웨어와 기본시설을 활용하여 대규모 데이터 처리를 실행할 수 있는 강점
    • Google Cloud Storage : 객체 스토리지
    • Google Cloud Datastore : NoSQL 데이터베이스
    • Google CloudDataproc : Hadopo & Spark
    • Google Cloud Dataflow : 데이터 플로우(배치, 스트리밍)
    • Google Cloud Datalab : 노트북, 시각화
    • Google Cloud Pub/Sub : 메시지 브로커(Pub/Sub 서비스)
    • Google BigQuery : 쿼리 엔진
    • Google Data Studio : BI 도구
  • 트레주어 데이터
    • 데이터 처리의 플랫폼으로 오픈 소스의 스트리밍 형 전송 도구인 Fluentd와 벌크 형 전송 도구인 Embulk를 개발한 곳
    • 처음부터 모든 서비스가 포함된 상태로 제공 , 다수의 외부 시스템과의 연계가 통합
    • Data Collection : 데이터 수집(스트리밍, 벌크)
    • Data Set Managemet : 분산스토리지, 구조화 데이터
    • Data Processing : 쿼리 엔진(Hive, Presto)
    • Data Delivery and Activation : ETL 프로세스
    • Treasure Workflow : 워크플로 관리
    • Treasure Reporting : BI 도구
      • Digdag - 선언형의 워크플로 관리
        • 트레주어 데이터에 있어 쿼리의 스케줄 실행과 외부 시스템과의 연계는 서비스에 포함된 워크플로 구조로 제어됨
        • 의존 관계가 있는 복잡한 워크플로를 실행하기 위해서 오픈 소스의 선언형 워크플로 관리 도구인 Digdag 제공
  • Amazon Redshift와 Google BigQuery의 차이점
    • Redshift : 전용 리소스(dedicated resource)
      • 전통적인 MPP 데이터베이스의 흐름을 이어 왔기에 스토리지 계산 노드가 일체화된 환경에서 효율적으로 쿼리를 실행
      • 자원이 전용이라 다른 사용자가 사용할 수 없기 때문에 성능이 안정적, 노드 수를 늘리면 스토리지 용량과 계산 능력이 모두 증가하므로, 데이터양에 대한 일정한 성능이 유지
    • BigQuery : 공유 리소스(shared resource)
      • 설계 사상으로 수천 대나 되는 하드 디스크에 데이터를 분산함으로써 고속화를 실현
      • 자신의 노드를 관리할 필요가 없는 풀 매니지드 형의 서비스