안녕하세요 한소희입니다. 공부를 통해 배운 내용을 작성하고 있습니다. 혹여 해당 포스팅에서 잘못된 부분이 있을 경우, 알려주시면 빠르게 수정 조치하도록 하겠습니다. 감사합니다.
문득, 빅데이터를 지탱하는 기술 이라는 책의 마지막 챕터 포스팅을 하지 않았다는 것을 인지했다.
따라서, 유종의 미를 거두고자(?) 마지막 챕터에 대한 느낀 점을 간단히 정리해보고자 한다.
목차
스키마리스 데이터의 애드 혹 분석
Hadoop에 의한 데이터 파이프라인
워크 플로 관리 도구에 의한 자동화
클라우드 서비스에 의한 데이터 파이프라인
01. 스키마리스 데이터의 애드 혹 분석
해당 챕터에서는, json 에 의한 스키마리스 데이터를 집계/분석하는 로직을 다룬다.
예제 위주로 설명이 되어 있는데, 예제를 직접 따라해보기 보다는 해당 예제 속에서 얻을 수 있는 인사이트 위주로 정리를 해보고자 한다.
1-1. json 데이터 수집 및 처리
책에서는 twitter API를 이용하여 데이터를 수집하여, spark 기반 분산 처리 환경을 구축하였다.
pyspark를 이용해, 데이터를 쿼리하여 분산처리 한다. 이때, sparkSQL 쿼리를 날리는 작업은 컬럼 단위 읽기에 최적화되어 있지 않아, 웬만해선 한 차례 데이터를 수집해야 한다고 한다. 이 단계를 도표화하면 아래와 같다.
1-2. 데이터 집계 및 마트 구축, 시각화
데이터를 수집하였으니, 비정규화 테이블을 생성한 뒤, 데이터를 작게 집약하여 시각화 대시보드를 구현한다.
비정규화 테이블을 생성하는 데에는 동일하게 Spark를 썼다. 이때, 통계 비정규화 테이블을 구성할 예정이므로, 카디널리티를 축소하여 비정규화 테이블을 구현해준다.
💡 통계 결과를 위한 비정규화 테이블 생성 팁
카디널리티를 축소하여 시각화 프로세스를 최적화 한다.
예를 들어서, 만약 상위 랭크만 필요하다면, 하위의 값에 대한 결과는 "카테고리" 를 하나로 묶어 그 결과값으로 count가 집계될 수 있도록 한다. 이로써, row수를 크게 줄여 전반적인 비용을 감소시킬 수 있다.
[예시]
고객이 검색한 검색어 통계 대시보드(목적: 어떤 단어가 가장 많이 검색되었는지, 얼마나 검색되었는지)를 위한 DM을 설계한다.
이때, 10번 이하 검색된 검색어들에 대해서 처리하는 것은 목적과 멀어지기도 하고 무한 카디널리티를 유발하여 부하를 줄 수 있다.
이때, 10번 이하로 검색된 검색어들은 category 컬럼에 각각 1번 조회된 단어라면 "count=1", 2번 조회된 단어라면 "count=2"...와 같이 넣어준다. 그리고 10번 이상 검색된 검색어는 그 검색어 자체로써 category에 값을 넣어준다.
예시를 테이블로 시각화하면 아래와 같다.
id word search_count category 1 데이터 100 데이터 2 엔지니어링 240 엔지니어링 3 lfaksj;flkm 1 count=1 4 https://nav... 8 count=8 5 sdsfsd 1 count=1
그리고 이 데이터에서 필요한 값만을 출력하여 작게 집약 및 저장한다. 예시에서는, 모든 순위가 필요 없이 상위 2개 데이터만 필요했으므로, 상위 2개에 대한 값만 CSV파일에 저장 해두었다.
이후, 이를 시각화하여 CSV파일을 바라보도록 하는 예시를 소개했다.
해당 챕터에서 가장 인상깊었던 부분은, 통계 시 카디널리티다. 저렇게 설계하면 시각화 단에서의 부하 뿐만 아니라, 여러 DB로 운영한다면 데이터 저장 관련 경제성도 함께 가지고 갈 수 있겠다는 생각이 들었다.
02. Hadoop에 의한 데이터 파이프라인
2-1. Hive와 Presto 를 사용한 배치형 데이터 처리
Hive와 Presto는 아래 설명을 작성 해두었다. (2년 전 글이라는 점 참고)
https://eng-sohee.tistory.com/34
결론적으로, 이 챕터에서 다룬 아키텍처는 아래와 같다.
(1) Embulk로 데이터를 추출
(2) Hive로 데이터를 구조화
(3) Presto로 데이터를 집계
(4) 이후 시각화
하는 로직이다.
03. 워크 플로 관리 도구에 의한 자동화
3-1. Apache Airflow
위와 같은 배치 프로세스를 주기적으로 수기로 돌린다면 매우 힘들 것이다. 따라서, 주기적 스케줄링을 이용한 Airflow 활용 방법이 나와 있다.
airflow 에 대한 설명은 아래 포스팅에서 다루었다.
https://eng-sohee.tistory.com/80
airflow는, 주기적인 스케줄링을 이용하여 배치 프로세스를 잘 동작할 수 있도록 한 것 외에도, 백필을 할 수 있다는 장점이 있다.
이로써, 오류가 발생하여도 과거의 데이터를 처리할 수 있다는 장점이 있다.
또한, web UI로 DAG의 실행현황 등을 한 눈에 보기가 쉽다. 따라서 cronjob 등에 비해 운영도 수월하다는 장점이 있다.
💡 수 초만에 종료하는 작은 task나, 수 천을 넘는 대량 task 실행에는 Airflow가 적합하지 않은 이유
왜냐하면 동시 실행하는 task 수의 상한이 설정 파일에 정해져 있고, 그 이상의 task가 등록되면 보류되기 때문이다.
또한, 너무 task가 커져버리면 메모리를 많이 잡아먹어 동시 실행하는 task에 영향을 줄 수 기 때문이다.
따라서, 너무 작은 task의 경우 적절히 모아서 하나의 task로 실행한다거나 & 너무 큰 task의 경우 쪼개어 실행할 수 있도록 한다.
04. 클라우드 서비스에 의한 데이터 파이프라인
4-1. 아마존 웹 서비스
아마존 웹 서비스란, 2009년에 시작한 EMR을 시작으로, 빅데이터 분야에서 예전부터 이용되고 있는 클라우드 서비스다.
대표적인 빅데이터 관련 서비스(일부)는 아래와 같다.
서비스 명 | 역할 |
S3 | 오브젝트 스토리지 |
Dynamo DB | NoSQL DB |
EMR | Hadoop&Spark |
Athena | 쿼리엔진(Presto) |
Elasticsearch | 검색 엔진 |
Kinesis | 메시지 브로커 |
Kinesis Stream | 스트림 처리 |
Redshift | MPP 데이터베이스 |
QuickSight | BI 도구 |
4-2. 구글 클라우드 플랫폼
구글 클라우드 플랫폼이란, 구글의 소프트웨어와 기본 시설을 활용하여 대규모 데이터 처리를 실행할 수 있는 강점이 있는 클라우드 서비스다.
대표적인 빅데이터 관련 서비스(일부)는 아래와 같다.
서비스 명 | 역할 |
GCS | 오브젝트 스토리지 |
Datastore | NoSQL 데이터베이스 |
Dataproc | Hadoop & Spark |
Dataflow | 데이터 플로우(배치, 스트리밍) |
Datalab | 노트북, 시각화 |
Pub/Sub | 메시지 브로커(Pub/Sub 서비스) |
Bigquery | 쿼리 엔진(MPP 아키텍처) |
Data Studio | BI 도구 |
4-3. 트레주어 데이터
트레주어 데이터란, 데이터 처리의 플랫폼으로 2011년에 설립된 서비스다.
AWS나 GCP는 사용자가 개별 서비스를 조합하여 데이터 파이프라인을 만드는 반면, 트레주어 데이터는 처음부터 모든 서비스가 포함된 상태로 제공된다는 특징이 있다.
대표적인 빅데이터 관련 서비스(일부)는 아래와 같다.
서비스 명 | 역할 |
Data Collection | 데이터 수집(스트리밍, 벌크) |
Data Set Management | 분산 스토리지, 구조화 데이터 |
Data Processing | 쿼리 엔진(Hive, Presto) |
Data Delivery and Activation | ETL 프로세스 |
Treasure Workflow | 워크플로우 관리 |
Treasure Reporting | BI 도구 |
'데이터 공부 > 빅데이터 & 하둡' 카테고리의 다른 글
데이터허브(Datahub) 구축기 - (1/3) 데이터허브란, 데이터 허브 용어 살펴보기 (48) | 2023.11.22 |
---|---|
[책리뷰] 데이터 과학자 원칙 (0) | 2023.07.02 |
04. Spark 간단히 살펴보기, 기능 둘러보기 (0) | 2021.07.15 |
05. 워크플로 관리와 데이터 플로우 (0) | 2021.07.08 |
04. 빅데이터의 축적 (0) | 2021.07.07 |