일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 데이터엔지니어링
- ORACLE문법
- 데이터 수집
- 하둡1.0
- 하둡
- 지연연산
- 카프카
- Databricks
- 프로그래머스힙
- kafka 설치
- 런타임데이터영역
- 하둡에코시스템
- EMR 구조
- 스파크
- Spark 최적화
- 서버간 복사
- 빌드도구
- 데이터베이스복사
- Catalyst Optimizer
- AWS Crawler
- Spark
- 실행엔진
- lazy evaluation
- 문맥교환
- ORACLE MSSQL차이
- 프로그래머스 큰 수 만들기
- 하둡2.0
- 데이터파이프라인
- freenom
- 프로그래머스
- Today
- Total
띵유로그
실시간 적재에 사용되는 기술 - HBase, 스톰, 에스퍼... 본문
이 전 글에서는 대용량 로그 파일을 적재하는 기술에 대해 설명했다면, 이번 글에서는 실시간 적재 기능에 대해 설명한다.
실시간으로 발생하는 대규모 메시지성 데이터를 신속히 처리하고 저장하기에는 하둡은 적합하지 않다. (레이턴시가 높기 때문)
대신 Hbase와 같은 NoSQL 데이터 베이스를 사용하면 좋다. 저장할 때에는 제약사항이 적고 조회할 때는 랜덤 액세스가 가능하다.
1. HBase
NoSQL데이터 베이스들을 key/ value 구조로 단순화 되어있고 제약사항이 적어 고성능 읽기/쓰기가 가능하다. HBase는 하둡 기반의 칼럼 지향 데이터베이스로 스키마 변경이 자유롭고 여러 분산서버로 샤딩, 복제 기능을 지원한다.
- HTable : 칼럼 기반의 데이터 구조를 정의한 테이블. 공통점이 있는 칼럼들의 그룹을 묶은 칼럼 패밀리와
테이블 로우를 식별해서 접근하기 위한 로우 키로 구성되어있다.
- HMaster : HRegion서버를 관리하며 HRegion들이 속한 서버의 메타정보를 관리한다.
- HRegion : HTable의 크기에 따라 자동으로 수평 분할이 발생하고 분할된 블록을 Hregion단위로 지정한다.
- HRegionServer : 분산 노드별 HRegionServer가 구성되며 하나의 HRegionServer에는 다수의 HRegion이 존재한다.
- Store : 하나의 Store에는 칼럼 패밀리가 저장, 관리되고 MemStore, HFile로 구성된다.
- MemStore : Store내의 데이터를 인메모리에 저장, 관리하는 데이터 캐시 영역이다.
- HFile : Store내의 데이터를 스토리지에 저장, 관리하는 영구 저장영역이다.
*샤딩 (sharding) : 같은 테이블 스키마를 가진 데이터베이스를 여러 서버에 분산 저장하는 방법이다. 분산하는 방법에 따라 hash sharding, dynamic sharding 등등 여러 방법이 있다.
아래 글에 매우 잘 정리되어있다.
Database의 샤딩(Sharding)이란? (nesoy.github.io)
Database의 샤딩(Sharding)이란?
nesoy.github.io

HBase아키텍쳐에 대해 살펴보자.
Data 저장 )
클라이언트가 HBase 테이블에 특정 데이터를 저장하기 전 주키퍼를 통해 HTable의 기본정보와 HRegion의 위치 정보를 알아낸다. 그리고 그 정보를 기반으로 Client가 직접 HRegionsServer와 연결하여 MemStore(HRegion의 Memory 영역) 에 저장한다. MemStore에 저장된 데이터는 특정한 시점에 HFile로 플러시되고 HFile은 HRegion의 상황에 따라 최적의 HFile로 재구성된다. 이러한 플러시과정을 Minor/Major Compaction이라고 한다.
Data Read )
데이터를 가져올 때는 주키퍼를 통해 RowKey에 해당하는 데이터의 위치 정보를 알아낸다. 그리고 HRegionServer의 Memory 영역인 MemStore에서 데이터를 가져와 디스트 I/O를 최소화 하면서 빠른 응답속도를 보장한다. 만약 이미 MemStore에서 플러시 되어 존재하지 않으면 HFile영역으로 이동해서 데이터를 찾는데, HBase와 HDFS사이의 모든 데이터 스트림 라인들이 항상 열려있기때문에 레이턴시가 크지는 않다.
이러한 방식으로 HBase에 저장된 실시간 데이터를 신속하게 조회하고 활용할 수 있다.
2. 레디스
레디스는 분산 캐시 시스템이면서 NoSQL 데이터베이스처럼 대규모 데이터 관리 능력도 가지고 있다.
레디스는 key/ value 형태의 데이터 구조를 분산 서버상의 메모리에 저장하면서 고성능의 응답속도를 보장한다. 또 다양한 데이터 타입을 지원하며 인메모리 데이터를 영구적으로 저장할 수 있는 스냅샷 기능을 제공한다. 또 NoSQL 데이터베이스에서 주로 사용되는 Sharding과 Replication도 지원하고 있어 고성능이 필요한 서비스에서 많이 사용된다.
- Master : 분산 노드간의 데이터 복제와 Slave서버의 관리를 위한 마스터 서버
- Slave : 다수의 Slave서버는 읽기 요청을 처리하고 Master서버는 쓰기 요청을 처리한다.
- Sentinel : Master서버에 문제가 생길 경우 새로운 master서버를 선출하는 기능
- Replication : Master서버에 쓰인 내용을 Slave 서버로 복제해서 동기화 처리한다.
- AOF / Snapshot : 데이터를 영구 저장. 명령어를 기록하는 AOF와 스냅샷 이미지 파일 방식을 지원.

레디스 아키텍쳐는 Master인 쓰기 노드와 Slave인 읽기 노드로 분리하여 구성한다. Master에 쓰여진 데이터는 복제를 통해 Slaver로 복제하여 데이터의 정합성을 유지한다. Redis 3.x 부터는 master서버에 문제가 발생할 경우를 해결하기 위해 sentinel이라는 모니터링/ 제어 컴포넌트를 추가했다. Sentinel 노드가 모니터링 하다가 master 노드에 문제가 생기면 slave노드중 하나를 master노드로 지정하고 문제가 된 master노드와의 연결을 끊는것이다.
HBase에는 모든 실시간 로그를 저장하고 레디스에는 특정 패턴을 감지한 이벤트 결과만 저장하는 방안이 좋다.
3. 스톰
스톰은 실시간 데이터를 병렬 프로세스로 처리하기 위한 소프트웨어다.
실시간 분산 처리기는 데이터를 적재하기 전에 발생과 동시에 이벤트를 감지해서 처리하는 방식과,
적재와 동시에 이벤트를 감지해 처리하는 방식이 있는데, 스톰은 전자에 해당한다.
- Spout : 외부로부터 데이터를 유입받아 가공처리해서 튜플을 생성한다. 이후에 해당 튜플을 Bolt에 전송한다.
- Bolt : 튜플을 받아서 실제 분산 작업을 수행하며, 필터링, 집계, 조인 등의 연산을 병렬로 실행한다.
- Topology : Spout - Bolt의 데이터 처리 흐름을 정의하는것으로 하나의 Spout와 다수의 Bolt로 구성되어있다.
- Nimbus : Topology를 Supervision에 배포하고 작업을 할당한다. Supervisior를 모니터링 하다 필요시에 Fail over처리한다.
- Supervisor : Topology를 실행할 Worker를 구동시키며 Topology를 Worker에 할당하고 관리한다.
- Worker : Supervisior 상에서 실행중인 자바 프로세스로 Spout과 Bolt를 실행한다.
- Executor : Worker내에서 실행되는 자바 스레드이다.
- Tasker : Spout 및 Bolt 객체가 할당된다.

스톰 아키텍쳐를 이해하기 위해 Nimbus와 Supervisor의 역할을 알아야 한다. Nimbus는 자바 파일로 구성된 Topology jar 를 배포하기 위해 주키퍼로부터 Supervisor 정보를 알아낸다. 그 후에 Topology jar 파일을 Supervisor에 전송하면 supervisor는 해당 node에서 worker, executor를 만들고 task도 할당한다. task에서는 Spout, bolt가 실행되는데 설명해보면, 데이터가 spout 로 유입되면 이를 bolt가 전달받아 데이터를 분산처리하고 처리 결과는 bolt를 통해 타깃 시스템으로 전송되는 형태이다. task, executor개수를 증가시키면서 대규모 병렬 처리가 가능해지고, spout, bolt성능이 향상된다.
supervisor가 생성한 work프로세스에 문제가 생기면 supervisor는 새로운 worker프로세스를 생성하고 데이터들을 롤백한다. 토폴로지가 다시 정상복구되면 롤백된 부분에서 다시 처리를 시작한다.
스톰은 실시간 정보를 라우팅하고나 스트리밍 처리하는데에 유용한다. 예를들어 운전다의 운행정보가 무작위하게 들어올때, 1차로 볼트A에서 처리 후 HBase Bolt, 레디스 Bolt로 나누어 처리하여 Hbase에는 정제없이 그대로 적재하게 하고 레디스에는 특정한 이벤트를 감지했을 때에만 적재하는 형태로 나눌 수 있다.
4. 에스퍼
스트리밍데이터가 복잡한 이벤트 처리가 필요하다면 사용되는 룰 엔진이다. 스톰은 실시간데이터로부터 패턴을 찾고 패턴에따라 이벤트를 처리하는데는 기능이 부족하다. 실시간 발생 데이터간의 관계를 복합적으로 판단하고 처리하는 것을 CEP(Complex Event Processing) 이라고 하는데 에스퍼는 이 기능을 제공한다.
- Event : 실시간 스트림으로 발생하는 데이터들의 특정 흐름 또는 패턴을 정의
- EPL : 유사 SQL을 기반으로 이벤트 데이터를 처리하는 스크립트 언어
- Input Adaper : 소스로부터 전송되는 데이터를 처리하기 위한 어댑터를 제공 (ex. CSV, Socket, JDBC)
- Ouptut Adapter : 타깃으로 전송하는 데이터를 저리하기 위한 어댑터 제공 (ex. HDFS, CSV, Socket)
- Window : 실시간 스트림 데이터로부터 특정 시간 또는 개수를 설정한 이벤트들을 메모리상에 등록한 후 EPL을 통해 결과 추출
'DataEngineering > 하둡' 카테고리의 다른 글
[빅데이터] - 하둡과 주키퍼 (대용량 로그파일 적재) (0) | 2020.12.15 |
---|---|
빅데이터 - 플럼, 카프카 (수집) (0) | 2020.12.12 |
[HADOOP] 하둡이란? (0) | 2020.09.27 |