쿼리 실행시 동적으로 데이터 정의가 가능 - ex) "Korea, Seoul, GangseoGu"가 '국가','시','구'처럼 3개의 컬럼 혹은 1개의 문자열로 다룰 수 있음 - 데이터를 어떻게 사용할지 모를 때, 일단 저장 후 필요시 동적으로 스키마 정의가 가능
데이터 분석을 위한 풍부한 UDF(User-Defined Function) - SQL로 구현이 어려운 문자열 처리 등이 쉬움
단점
파일 시스템(HDFS)을 기반 - 특정 레코드 하나에 대한 변경/제거가 어려움 - 인덱스가 디폴트로 존재하지 않음
리액턴시가 낮은 처리에 적합하지 않음 - throughput을 위한 아키텍처 - 쿼리 실행 과정 1) HiveQL로 작성된 처리를 자바 코드로 변환 2) 생성된 jar를 각 연산 노드에 배치 후 처리
3) Amazon Redshift
Redshift
AWS에서 제공하는 분산 병렬 RDB
Hive는 파일 기반 batch 처리를 SQL 인터페이스로 구현
Redshift는 RDB - 레코드 업데이트 / 제거 - 트랜잭션 지원 - PostgreSQL과 호환성
장점
일반적인 RDB에서 다룰 수 없는 대용량 데이터 쿼리에 효과적 - Hive는 MapReduce로 분산 처리를 실행하면 가벼운 job도 10초 이상 걸림
작은 규모로 시작하여 큰 규모로 쉽게 변경 가능
단점
전문 지식이 필요 - 성능 튜닝 / 비용 최소화를 위해 최적의 노드 수 / 스펙을 예측하여 인스턴스를 실행 / 종료해야함 - 컬럼 기반 스토리지로, 설계 / 쿼리 실행시 일반 RDB와 다른 발상 필요
상업적인 이용 - 사용 시간에 따라 비용 발생
컬럼 지향 스토리지
테이블의 데이터를 물리적으로 저장할 때, 레코드별로 저장하지 않고 컬럼별로 저장
데이터 압축율이 높음
쿼리 실행 때 디스크 I/O 감소
일반 RDB의 정규화를 사용하지 않고, 분석에 필요한 데이터를 하나의 테이블 칼럼에 추가
4) Google BigQuery
Google BigQuery
빅데이터 분석을 위해 구글이 제공하는 클라우드 서비스
구글의 다른 서비스와 쉬운 연동 - 구글 애널리틱스 등
레거시 SQL과 표준 SQL 두 종류 지원
컬럼 지향 스토리지 아키텍쳐
Redshift와 차이
직접 노드 인스턴스를 관리할 필요 없음
데이터 양으로 비용 발생
단점
데이터 사용량 기준으로 요금을 예측하기 어려움
5) SparkSQL
SparkSQL
Spark의 기능 중 SQL 인터페이스
Spark - MapReduce를 사용한 분산 처리 프레임워크
장점
빅데이터 관련 활용 / 처리를 한 번에 구현
일반적인 경우 - 데이터 추출을 파이썬 스크립트로 작업 - 수집한 데이터를 SQL로 가공 - 통계 분석과 기계학습을 R로 진행 - 결과 리포트를 엑셀로 작성
위 과정을 모두 Spark 프로그램 내부에 한 번에 구현 가능
DataFrames API
SQL 뿐만 아니라 절차적인 프로그래밍 비슷한 구현도 가능 - 중간 과정을 확인하여 처리 - 데이터 처리를 작은 모듈로 분할하여 다양한 처리
2. 데이터
리포트를 만들 때, 데이터에 대한 이해가 필요함
어떤 데이터를 추출하는지
데이터는 어떤 성질을 가지는지
1) 데이터의 종류
데이터의 종류
업무 데이터 - 업무에 필요한 데이터
로그 데이터 - 직접적으로 업무 용도는 아닌 분석을 위해 추출하는 데이터
업무 데이터
서비스와 시스템을 운용하기 위한 목적으로 구축된 데이터베이스에 존재하는 데이터
갱신형 데이터 - 새로운 데이터 삽입이 아닌, 기존 데이터를 갱신
트랜잭션 데이터와 마스터 데이터로 나뉨
트랜잭션 데이터 - 서비스 / 시스템을 통해 사용자의 행동을 기록한 데이터 - 트랜잭션 데이터를 기반으로 리포트를 만드는 경우가 많음 - 그러나 리포트를 만들 때는 이를 설명하는 마스터 데이터가 필요
마스터 데이터 - 서비스 / 시스템이 정의하고 있는 데이터 - 트랜잭션 데이터만으로는 상품의 명칭, 카테고리 등을 알 수 없음 - ex) <사용자 id>, <상품 id>, <개수> 로 이루어진 데이터 {170414, 82091, 2}로는 어떤 상품을 구매했는지 알 수 없음 - 이를 명확하게 만들어야 리포트 업무의 폭을 넓힐 수 있음
로그 데이터
로그 데이터의 종류 - 통계 / 분석 용도로 설계된 데이터 - 특정 태그를 포함하는 데이터 - 특정 행동을 서버에 출력하는 데이터
누적형 데이터 - 출력 시점의 정보를 축적해두는 데이터 - 기존 데이터를 수정하지 않음
2) 업무 데이터
업무 데이터
빅데이터 기반 / 데이터 분석 기반 시스템이 없는 경우, 일반적으로 업무 데이터로 데이터 분석을 진행
업무 데이터의 특징
데이터 정밀도가 높음 - 여러 데이터 처리 중 문제 발생에 대한 내성이 강함 (트랜잭션, 롤백) - 데이터의 정합성이 보증됨 - 정확한 값이 요구되는 경우 업무 데이터 활용 (매출 관련 리포트 등)
갱신형 데이터 - 매일 다양한 데이터 추가 / 갱신 / 제거 등이 실행 - 데이터를 추출하는 시점에 따라 추출 데이터가 바뀔 수 있음을 인지 - 데이터 갱신의 예시
사용자의 탈퇴로 인한 물리적 데이터 제거
주문 취소로 인한 논리적 제거 (플래그 활용)
이사 등 주소 변경으로 인한 사용자 정보 갱신
테이블의 수가 많음 - 대부분 RDB 사용 - 이는 데이터의 확장성 배제, 정합성을 쉽게 유지하며 데이터 저장을 위함 (정규화) - 따라서, 하나의 테이블 참조로 데이터의 상세 내용 파악이 어려움 - ER 다이어그램 파악 / 여러 테이블 결합으로 전체 내용 파악 가능
업무 데이터 축적 방법
모든 데이터 변경하기
날짜 기반 / 누적만 되는 데이터가 아닐 경우 - ex) 우편번호 마스터, 상품 카테고리 마스터 - 데이터 전체를 한꺼번에 바꾸어 최신 상태로 만듦
빈번하게 변경되는 테이블 / 날짜가 경과하면 상태가 바뀌는 테이블 - ex) 사용자의 유료 서비스 신청 - 한꺼번에 바꾸면 항상 최신 상태 - 리포트를 만들 때는 편하지만, 과거 정보를 영구적으로 잃으므로 주의
모든 레코드 스냅샷을 날짜별로 저장하기 - 날짜에 따라 상태가 변하는 데이터 - 용량 측면에서 좋지 않으나, 모든 레코드를 날짜별로 누적하면 신뢰성을 어느 정도 보장함
어제와의 변경 사항만 누적하기 - 트랜잭션 데이터 중 변경/삭제없이 추가만 일어나는 테이블은 한꺼번에 변경 가능 - 그러나 데이터 전송량과 처리 시간을 줄여야할 경우, 어제 데이터와의 차이만 누적해도 됨
업무 데이터 다루기
정확한 값을 요구할 경우 활용 (매출액, 사용자 수) - 트랜잭션 기능으로 데이터의 정합성이 보장됨 - 로그 데이터는 전송 방법에 따라 중간 손실이 발생할 수 있음 - 정확한 값을 요구할 경우 업무 데이터 사용
활용할 수 없는 분석 (서비스 방문 횟수, 페이지뷰, 사용자 유도) - 예를 들어, 구매 데이터의 경우 어떤 장치에서 구매했는지는 업무에 필요없는 정보 - 필요없는 정보 저장은 서비스 처리에 영향을 줄 수 있음 - 따라서, 위와 같은 분석에는 로그 데이터를 활용해야함
데이터 변경이 가능하므로 추출 시점에 따라 결과도 변동 가능 - 업무데이터의 신뢰성은 서비스를 제공할 때임 - 리포트를 만들 때는 데이터 정합성을 완벽히 보장할 수 없음
3) 로그 데이터
로그 데이터의 특징
서비스 처리에 영향 없는 정보 저장 - 시간, 사용자 엔드포인트, IP, URL, 레퍼러, Cookie 등
추출 방법에 따라 데이터 정밀도가 달라짐 - 추출 방법, 집계 대상 데이터의 상태를 제대로 파악하지 않고 사용시 잘못된 판단을 할 수 있음
데이터 갱신/변경없이 추가 - 출력 시점의 정보를 기록 - 상품의 가격이 변하더라도, 과거의 로그 데이터는 변경되지 않음
로그 데이터 축적 방법
로그 데이터 활용시 고려할 사항
어떤 로그 데이터인지 파악
어떤 방법으로 사용할지 검토
리포트로 설명할 범위 결정
로그 데이터 전송 / 축적 방법
태그, SDK를 통해 사용자 장치에서 데이터 전송 / 출력 (비컨 형태) - HTML에 특정 태그 삽입으로 데이터를 전송하는 방식 - 웹사이트 개발시 활용하는 일반적인 방법 - JS로 로그 데이터 전송시, 크롤러의 영향을 적게 받음
서버에서 데이터 추출 / 출력 (서버 형태) - 클라이언트 쪽에서 처리하지 않고, 서버에서 로그를 출력하는 방법 - 크롤러의 접근을 막는 것은 거의 불가능 - 따라서, 사용자의 행동을 집계 / 분석할 경우 잘못된 판단을 내릴 수 있음
로그 데이터 다루기
사이트 방문 횟수, 페이지뷰, 사용자 유도 상황을 집계 / 분석할 때 사용 - 업무 데이터로 관리할 수 없는 열람 페이지, 레퍼러, 사용자 에이전트 등을 저장 - 방문 횟수, 페이지뷰, 액션 수, 장치별 방문 수 등의 지표로 사용
최신 상태를 고려한 분석에는 적합하지 않음 - 당시 상황 분석시 편하지만, 이후 데이터 변경을 고려할 경우 별도 가공이 필요할 수 있음 - ex) 상품 카테고리 변경, 사용자 주소 변경 등
변경 없이 누적만 하는 데이터로, 추출 결과가 변할 가능성이 적음
업무 데이터에 비해 데이터의 정확도는 낮음 - 추출 방법에 따라 크롤러의 로그가 함께 포함되어 집계될 수 있음 - 따라서, 정확한 값이 필요할 경우 적합하지 않음
4) 두 데이터를 사용해서 생성되는 가치
업무 데이터와 로그 데이터의 가치
업무 데이터 - 매출액의 추이 - 어떤 상품이 인기 있는지 - 어떤 상품이 계절성을 가지는지 - 특정 시간이 많이 팔리는지
로그 데이터 - 페이지뷰 - 액션 - 해당 데이터에 포함된 값(레퍼러, 사용자 에이전트, 사용자 정의 변수 등) - 접근 분석 도구의 리포트는 공통으로 사용할 수 있는 형식으로 설계
두 데이터를 사용했을 때 발생하는 새로운 가치
두 데이터를 함께 활용하라는 결론
로그 데이터는 웹사이트에서의 행동을 기록
업무 데이터는 웹사이트+오프리안 데이터도 기록 - POS 데이터, 음식점 예약 데이터, 대응 이력 등
웹사이트에서의 행동이 오프라인 행동에 어떤 영향을 미치는지 조사 가능 - 특정 미디어 / 광고로 유입된 사용자의 오프라인 계약 가능성 확인 - 음식점 방문 전 웹사이트에서 많이 본 상품이 실제 매장에서 많이 팔리는 경향 확인
데이터 사용 가치
목표 관리 - 목표를 관리, 설계하고 서비스 / 조직의 성장에 기여
서비스 개선 - 대량 데이터 기반으로 사용자 경향 발견하고, 매출 / 서비스 개선에 기여
미래 예측 - 과거 경향 기반으로 미래 행동 예측 - 특정 행동의 사용자가 탈퇴하는 경향이 있는지 - 추천 시스템
