제플린(Zeppelin) 란?

: 제플린은 Apache Spark을 기반으로 한 시각화 툴이며, UI에서 코딩도 할 수 있고 SQL도 날리면서 데이터를 시각화해서 보여주는 빅데이터 분석 및 시각화 툴입니다.

 

 

제플린(Zeppelin) 홈페이지 :  zeppelin.apache.org/

 

 

제플린(Zeppelin)의 등장 배경

: 대용량 데이터를 효과적으로 탐색 및 분석하기 위해서는 대용량 데이터셋을빠르게 파악하고 이해하기 위한 분석 및 시각화 툴 필요했습니다. 그래서 하둡의 저장소에 있는 데이터를 참조하여 데이터 분석이 가능하도록 스파크를 기반으로 하는 제플린이 탄생하였습니다.

- 국내 스타트업 기업인 NFLaps에서 2013년부터 주도하고 있는 오픈소스 프로젝트로, 2014년 12월 아파치 재단에 인큐베이팅됐고, 2016년 5월 아파치 최상위 프로젝트로 승격되었습니다.

 

 

 

제플린(Zeppelin)의 장점 '

 

- Notebook : 데이터 처리 , 데이터 검색 , 데이터 분석 , 데이터 시각화 및 협업

 

- 다중 언어 백엔드

 

- Apache Spark와 통합 : - 자동 SparkContext 및 SQLContext 삽입, 로컬 파일 시스템 또는 메이븐 저장소로부터의

  런타임 jar 의존성로드,  작업 취소 및 진행 상황 표시

 

- Visualization : Table, Line Chart, Pie Chart 등 다양한 형태로 시각화

  Spark의 좋은 성능 덕분에 대부분 코드가 즉시 실행되므로 interactive하게 데이터를 다룰 수 있음

  HTML을 표현 가능하므로, 테이블에 이미지를 표시하거나, link를 넣거나 하는 등의 동작이 가능

 

- 새로운 Workflow : 데이터 정제, 처리, 요약 데이터 시각화, 고급 분석까지 전부 Spark와 Zeppelin으로 해결

 

 

 

제플린(Zeppelin)의 NoteBook

Apache Zeppelin은 Spark를 통한 데이터 분석의 불편함을 Web기반의 Notebook을 통해서 해결해보고자 만들어진 어플리케이션입니다. Web기반 Notebook 스타일 환경이란 Web에 워드프로세서 처럼 아무거나 입력 가능한 하얀 화면이 뜨고 여기에 코드를 작성-실행-결과확인-코드수정을 반복하면서 원하는 결과를 만들어 낼수있는 작업환경을 말합니다.

 

 

 

 

제플린(Zeppelin) 아키텍처

 

NoteBook : 웹 상에서 제플린의 인터프리터 언어를 작성하고 명령을 실행 및 관리할 수 있는 UI

Visualization : 잍터프리터의 실행 결과를 곧바로 웹 상에서 다양한 시각화 도구로 분석해 볼 수 있는 기능

Zeppelin Server : NoteBook을 웹으로 제공하기 위한 웹 애플리케이션 서버로서 인터프리터 엔진 및 인터프리터 API 등을 지원

Zeppelin interpreter : 데이터 분석을 위한 다양한 인터프리터를 제공하며, 스파크, 하이브, JDBC, 셀 등이 있으며 필요 시 인터프리터를 추가 확장

 

* 인터프리터 : (interpreter, 문화어: 해석기)는 프로그래밍 언어의 소스 코드를 바로 실행하는 컴퓨터 프로그램 또는 환경을 말합니다.

 

 

 

 

임팔라(Impala)란?

아파치 임팔라(Apache Impala)는 아파치 하둡을 실행하는 컴퓨터 클러스터에 저장된 데이터를 위한 오픈 소스 대규모 병렬 처리(MPP) SQL 쿼리 엔진입니다. 빅데이터 분석을 인메모리 기반의 실시간 온라인 분석까지 확대를 가능하게 하며, 구글 드레멜 논문 2010년에 발표를 시작으로 2012년 10월 실시간 빅데이터 분석 질의가 가능한 임팔라를 클라우데라가 오픈소스로 발표하였습니다.

 

임팔라(Impala) 홈페이지 : impala.apache.org/

 

 

 

임팔라(Impala)의 기능(실시간 - real time)

 

- H베이스(HBase)나 맵-리듀스 같은 별도 계층을 거치지 않고 HDFS(Hadoop Distributed File System)와 직접 통신을 합니다. 그리고 하이브처럼 ‘하이브쿼리언어(HiveQL)’‘하이브 쿼리 언어(HiveQL)’를 사용합니다.

( 추가 설명 : C++ 기반으로 만들어졌으며, 별도의 실행 엔진을 사용하므로 맵-리듀스 프로그래밍을 할 필요가 없습니다.)

 

- 임팔라는 동일한 파일과 데이터 포맷, 메타데이터, 보안 및 자원 관리 프레임워크(맵리듀스, 아파치 하이브, 아파치 피그 및 기타 하둡 소프트웨어가 사용)를 사용하기 위해 하둡과 연동된다.  

 

- 임팔라는 다양한 파일 저장소(HDFS, 쿠두, Hbase, Amazon-S3, Azure Data Lake Store)의 데이터를 SQL을 사용해 실시간으로 분석하는 것을 지원합니다.

 

 

Impala와 Hive의 차이점

 

: Impala와 Hive의 차이는 실시간성 여부입니다. Hive는 데이터 접근을 위해 MapReduce 프레임워크를 이용하는 반면에, Impala는 응답 시간을 최소한으로 줄이기 위해 고유의 분산 질의 엔진을 사용합니다. 이 분산 질의 엔진은 클러스터 내 모든 데이터 노드에 설치되도록 했습니다. 그래서 Impala와 Hive는 동일 데이터에 대한 응답 시간에 있어서 확연한 성능 차이를 보이고 있습니다.

 

Cloudera는 Impala의 성능이 좋은 이유로 다음 세 가지를 언급합니다.

 

1) Impala는 Hive보다 CPU 부하를 줄였고, 줄인 만큼 I/O 대역폭을 이용할 수 있습니다. 그래서 순수 I/O bound 질의의 경우 Impala는 Hive보다 3~4배 좋은 성능 결과를 보여줍니다.

 

2) 질의가 복잡해지면 Hive는 여러 단계의 MapReduce 작업 또는, Reduce-side 조인(JOIN) 작업이 필요합니다. 이처럼 MapReduce 프레임워크로 처리하기에 비효율적인 질의(적어도 하나 이상의 JOIN 연산이 들어간 질의)의 경우 Impala가 7~45배 정도 더 좋은 성능을 보입니다.

 

3) 분석할 데이터블록이 파일 캐시 되어 있는 상태라면 매우 빠른 성능을 보여주고, 이 경우 Hive보다 20~90배 빠른 성능을 보여줍니다.

 

 

 

임팔라(Impala) 아키텍처

 

Impalad : 하둡의 데이터노드에 설치되어 임팔라의 실행 쿼리에 대한 계획, 스케줄링, 엔진을 관리하는 코어

Impalad 안에 Query Planner , Query Coordinator , Query Exec Engine 이 들어있습니다.

 

Query Planner : 임팔라 쿼리에 대한 실행 계획을 수립

Query Coordinator : 임팔라의 잡 리스트 및 스케줄링 관리

Query Exec Engine : 임팔라의 쿼리를 최적화해서 실행하고, 쿼리 결과를 제공

 

Statestored : 분산 환경에 설치돼 있는 Impalad의 설정 정보 및 서비스를 관리

 

Catalogd : 임팔라에서 실행된 작업들을 관리하며, 필요시 작업 이력을 제공

 

임팔라는 크게 impalad와 statestored 로 구성돼 있습니다. impalad는 분산 질의 엔진 역할을 담당하는 프로세스로, Hadoop 클러스터 내 데이터 노드 위에서 질의에 대한 plan 설계와 질의 처리 작업합니다. 그리고 impala state store 프로세스는 각 데이터 노드에서 수행되는 impalad에 대한 메타데이터를 유지하는 역할을 담당합니다. impalad 프로세스가 클러스터 내에 추가 또는 제거될 때, impala state store 프로세스를 통해 메타데이터가 업데이트됩니다.

Hue 란?

: Hue(Hadoop User Experience)는 Apache Hadoop 클러스터와 함께 사용되는 웹 기반 사용자 인터페이스입니다. Hue는 다른 Hadoop 에코시스템과 함께 그룹화되어 Hive 작업 및 Spark Job 등을 실행할 수 있습니다. Hue는 다양한 하둡의 에코시스템의 기능들을 웹 UI로 통합 제공되었으며, 오픈 소스로 깃허브에 공개, 2016년 공식 사이트에서 릴리즈하였습니다.

Hue 공식 사이트 :  gethue.com/

 

 

Hue 등장 배경

: 빅데이터 탐색/분석은 반복적인 작업이면서 그 과정에서 많은 도구들이 활용되고, 하둡 기반의 하아브, 피그, 우지, 스쿱 등 알아야 할 기술 요소가 지나치게 많아 업무 담당자 또는 데이터 분석가들이 직접 사용하기에 어려움울 많이 느꼈습니다. 또한 빅데이터 기술이 성숙해지면서 이러한 복잡도를 숨기고 접근성을 높이기 위해 소프트웨어를 만들었습니다.

 

 

Hue 아키텍처

 

Job Designer : 우지의 워크플로 및 Coodinator를 웹 UI에서 디자인

Job Browser : 등록한 잡의 리스트 및 진행 상황과 결과 등을 조회

Hive Editor : 하이브 QL을 웹 UI에서 작성, 실행, 관리

Pig Editor : 피그 스크립트를 웹 UI에서 작성, 실행, 관리

HDFS Browser : 하둡의 파일시스템을 웹 UI에서 탐색 및 관리

HBase Browser :  HBase의 HTable 을 웹 UI에서 탐색 및 관리

 

 

우지(Oozie) 란?

: 하둡의 잡(job)을 관리하기 위한 서버 기반의 워크플로 스케줄링 시스템입니다. 자바 기반의 웹 애플리케이션으로서 Java servlet-container에서 수행되는 서버 기반의 워크플로 엔진으로 정의할 수 있습니다.

 

 

 

우지(Oozie)의 등장 배경

: 반복적이면서 복잡한 후처리 job을 처리하기 위해 방향성 있는 비순환 그래프(DAG:Direct Acyclic Graph)로 정의해서 job에 시작, 처리, 분기, 종료점 등의 액션(Action)으로 구성하는 워크플로(workflow)가 필요했습니다. 또한 수집 및 적재된 수백 개 이상의 데이터셋을 대상으로 다양한 후처리 job이 데이터 간의 의존성과 무결성을 유지하며 복잡하게 실행되었습니다. 이러한 필요성에 의해서 우지가 만들어졌습니다.

 

 

 

우지(Oozie)의 기능

 

1) Scheduling

  - 특정 시간에 액션 수행

  - 주기적인 간격 이후에 액션 수행

  - 이벤트가 발생하면 액션 수행

 

2) Coordinating

  - 이전 액션이 성공적으로 끝나면 다음 액션 시작

 

3) Managing

  - 액션이 성공하거나 실패했을 때 이메일 발송

  - 액션 수행시간이나 액션의 단계를 저장

 

 

 

우지(Oozie) 아키텍처

 

- Oozie Workflow : 주요 액션에 대한 작업 규칙과 플로우를 정의

 

- Oozie Client : 워크플로를 Server에 전송하고 관리하기 위한 환경

 

- Oozie Server : 워크플로 정보가 잡으로 등록되어 잡의 실행, 중지, 모니터링 등을 관리

 

- Control 노드 : 워크플로의 흐름을 제어하기 위한 Start , End , Decision 노드 등의 기능을 제공

 

- Action 노드 : 잡의 실제 수행 태스크를 정의 하는 노드로서 하이브, 피그, 맵리듀스 등의 액션으로 구성

                    (우지에서 실행 할 수 있는 하나의 작업 단위)

 

- Coodinator : 워크플로 잡을 실행하기 위한 스케줄 정책을 관리(Data sets과 Workflow를 실행하는 스케줄러 정의)

 

 

 

우지(Oozie)의 실행 순서

 

1. 클라이언트는 우지 서버에 연결하여 job properties을 제출합니다.

- job properties는 key-value 형태로 작업에 필요한 파라미터를 정의합니다.

- workflow.xml(Action들과 그들을 연결하는 로직은 Workflow를 정의) 파일의 NameNode와 Yarn ResourceManager(혹은 JobTracker)에 대한 URI를 포함하고 있습니다.

 

2. 우지 서버가 HDFS로 부터 workflow 파일을 읽습니다. .

3. 우지 서버에서 workflow를 파싱해서 액션을 수행합니다.

스파크(Spark)란?

: 빅데이터 워크로드에 주로 사용되는 분산처리 기능을 제공하는 하둡과 마찬가지로 오픈소스입니다. 특징은 빠른 성능을 위해 인 메모리 캐싱과 최적화된 실행을 사용하고 일반 배치 처리, 스트리밍 분석, 머신러닝, 그래프 데이터 베이스 및 임시 쿼리를 지원합니다.

아파치 스파크 홈페이지 : spark.apache.org/

 

맵리듀스 코오를 그대로 사용하는 하이브는 성능면에서 만족스럽지 못했으며, 그로 인해 반복적인 대화형 연산 작업에서는 하이브가 적합하지 못합니다. 이러한 단점을 극복한 고성능 인메모리 위에서 분석함으로써 대용량 데이터 작업에도 빠른 성능을 보장합니다.

 

하둡과 하이브를 비롯한 기존의 여러 솔루션과의 연동(스칼라, 자바, 파이썬, R)을 지원하고 마이크로 배치 방식의 실시간 처리 및 머신러닝 라이브러리를 비롯해 빅데이터 처리와 관련된 다양한 라이브러리를 지원합니다

* 스칼라 : 융통성, 유연성, 데이터 분석에 적합한 함수형 프로그래밍 개념을 사용할 수 있는 특징을 가지고 있습니다.

 

 

 

스파크(Spark)의 기능

 

- 빅데이터 애플리케이션에 필요한 대부분의 기능을 지원합니다.

- 맵리듀스와 유사한 일괄 처리 기능

- 실시간 데이터 처리 기능 (Spark Streaming)

- SQL과 유사한 정형 데이터 처리 기능 (Spark SQL)

- 그래프 알고리즘(Spark GraphX)

- 머신 러닝 알고리즘(Spark MLlib)

 

 

 

스파크(Spark) 단점

: 데이터 셋이 적어서 단일 노드로 충분한 애플리케이션에서 스파크는 분산 아키텍처로 인해 오히려 성능이 떨어질 수 있습니다. 또한 대량의 트랜잭션을 빠르게 처리해야 하는 애플리케이션은 스파크가 온라인 트랜잭션 처리를 염두에 두고 설계되지 않았기 때문에 유용하지 않을 수 있습니다.

 

 

 

스파크(Spark) 아키텍처

 

스파크는 일반적으로 "Driver Program"이라고 하는데, 이 Driver Program 은 여러 개의 병렬적인 작업으로 나뉘어서 Spark의 Worker Node에 있는 Executor에서 실행합니다.

 

SparkContext가 SparkClusterManager에 접속합니다.  이 클러스터 매니저는 스파크 자체의 클러스터 메니져가 될 수 도 있고 Mesos, YARN 등이 될 수 있습니다. 이 클러스터 매니저를 통해서 가용한 Excutor 들을 할당받습니다.

                         ↓

Excutor를 할당받으면, 각각의 Executor들에게 수행할 코드를 보냅니다.

                         ↓

다음으로 각 Excutor 안에서 Task에서 로직을 수행합니다.



 

 주요 구성 요소

 

Spark Core :  스파크 잡과 다른 스파크 컴포넌트에 필요한 기본 기능을 제공, 특히 분산 데이터 컬렉션을 추상화 한 객체인 RDD로 다양한 연산 및 변환 메소드를 제공합니다. RDD는 노드에 장애가 발생해도 데이터 셋을 재구성할 수 있는 복원성을 가지고 있습니다. 쉽게 이야기해서 하둡과 같은 일괄처리 담당하며 다른 프래임워크의 기반이다.  

 

Spark RDD : 스파크 프로그래밍의 기초 데이터셋 모델, 데이터 내장애성 보유 구조, 데이터 집합의 객체 개념

 

Spark Driver / Executors : Driver는 RDD 프로그램을 분산 노드에서 실행하기 위한 Task의 구성, 할당, 계획 등을 수립하고 , Executor는 Task를 실행 관리하며, 분산 노드의 스토리지 및 메모리를 참조

 

Spark Cluster Manager : 스파크 실행 환경을 구성하는 클러스터 관리자로 Mesos, YARN , Spark Standalone이 있음

 

Spark SQL : SQL 방식으로 스파크 RDD 프로그래밍을 지원

 

Spark Streaming : 스트리밍 데이터를 마이크로 타임의 배치로 나누어 실시간 처리

 

Spark MLib : 스파크에서 머신러닝 프로그램(군집, 분류, 추천 등)을 지원

 

Spark GraphX : 다양한 유형의 네트워크(SNS, 하이퍼링크 등) 구조 분석을 지원, 그래프는 정점과 두 정점을 잇는 간선으로 구성된 데이터 구조이며, 그래프 RDD 형태의 그래프 구조를 만들 수 있는 기능을 제공합니다.

 

 

스파크(Spark) vs 스톰(Storm)

항목 스파크 스톰
데이터 처리 일괄 처리 방식 실시간 스트리밍 방식
업데이트 파일 or 테이블 스트림(튜플)
컴퓨터 환경 인메모리 기반 인메모리 기반
반복 작업 강력한 성능 일반적 수준
프러그램 언어 Scala Clojure
사용 환경 반복 & 많은 연산 응답시간 ↓ , 다양질의

 

 

하이브(Hive)란?

: MapReduce는 복잡도가 높은 프로그래밍 기법이 필요했고, 이는 업무 분석가 및 관리자들에게 빅데이터에 접근하는 것을 어렵게 만들었습니다. 이를 해결하기 위해 페이스북에서 SQL과 매우 유사한 방식으로 하둡 데이터에 접근성을 높인 Hive 개발을 하게 되었습니다. 하둡에서 정형화된 데이터를 처리하기 위한 데이터 웨어하우스 인프라 입니다.

 

 

하이브 홈페이지 : hive.apache.org/

 

초기에는 페이스북에서 개발되었지만 넷플릭스등과 같은 회사에서 사용되고 있으며 개발되고 있으며, 오픈 소스로 공개되면서 2016년 2월 하이브 2.0이 릴리스되었습니다. (빅데이터의 가장 대표적인 SQL on Hadoop 제품으로 자리 잡음)

 

 

하이브(Hive) 수행 기능

 

1) 아파치 하이브는 아파치 HDFS이나 아파치 HBase와 같은 데이터 저장 시스템에 저장되어 있는 대용량 데이터 집합들을 분석합니다.

2)  HiveQL 이라고 불리는 SQL같은 언어를 제공하며 맵리듀스의 모든 기능을 지원합니다.

3) 쿼리를 빠르게 하기위해 비트맵 인덱스를 포함하여 인덱스 기능을 제공합니다. 

4)  하둡에서 동작하는 데이터 웨어하우스(Data Warehouse) 인프라 구조로서 데이터 요약, 질의 및 분석 기능을 제공합니다.

 

하이브(Hive) 주요 구성 요소

 

CLI : 사용자가 하이브 쿼리를 입력하고 실행할 수 있는 인터페이스 입니다.

JDBC / ODBC Driver : 하이브의 쿼리를 다양한 데이터 베이스와 연결하기 위한 드라이버를 제공 합니다.

Query Engine : 사용자가 입력한 하이브 쿼리를 분석해 실행 계획을 수립하고 하이브 QL을 맵리듀스 코드로 변환 및 실행 합니다.

MetaStore : 하이브에서 사용하는 테이블의 스키마 정보를 저장 및 관리하며, 기본적으로 더비DB(Derby DB)가 사용되나 다른 DBMS(MySQL, PostgreSQL 등)로 변경이 가능 합니다.

 

하이브(Hive) 의 기본 아키택처

 

- 하이브의 클라이언트는 CLI(Command Line interface : CLI), 하이브 서버, 웹 인터페이스로 구송됩니다. 하이브 서버의 경우 JDBC, ODBC, 쓰리프트로 개발된 클라이언트가 하이브 서비스를 이용할 수 있게 쓰리프트 서비스를 제공합니다.

 

- 하이브는 메타스토어(Metastore)라는 저장소를 만드어 하둡에서 처리된 메타데이터의 구조를 메타스토어에 저장합니다. 하이브는 오라클, MySQL등 JDBC를 지원하는 모든 데이터베이스를 이용하여 메타스토어를 구축할 수 있습니다.

 

- 드라이버는 사용자가 입력한 하이브QL 문을 해석합니다. 하둡과 연결되어 하이브QL 문을 실행하고, 하이브QL 은 하이브QL 문의 실행 계쇡을 작성하고, 최적화 작업까지 함께 수행합니다.

 

 

하둡x1 & Hive

Execute Query
- 사용자가 Hive web이나 커맨드라인을 통해 하이브 데이터베이스로 쿼리를 보냅니다. (데이터베이스와의 연결은 JDBC같은 아무런 드라이버나 사용가능)

                  ↓
Get Plan
- 드라이버는 컴파일러에게 쿼리 플랜을 요청합니다. 쿼리 컴파일러는 쿼리를 받아서 쿼리를 어떻게 처리할 것인지 쿼리 플랜을 작성합니다.

                  ↓
Get Metadata
- 쿼리 컴파일러는 Metastore로부터 쿼리를 처리하는데 필요한 메타정보를 받습니다.

                  ↓
Send Plan
- 컴파일러는 쿼리 플랜을 작성해서 드라이버에게 전달합니다.

                  ↓
Execute Plan
- 드라이버는 Execution Engine에게 쿼리 플랜을 전달합니다.

                  ↓   
Execute Job
- 이제부터는 쿼리가 내부적으로 맵리듀스 잡으로 변환되어 실행합니다. Execution Engine은 네임노드에 있는 JobTracker에게 잡을 전달하고,  JobTracker는 데이터 노드에 있는 TaskTracker에게 잡을 임명합니다.

                  ↓
Fetch Result
- Execution Engine은 맵 리듀스 처리 결과를 데이터노드로부터 받습니다.

                  ↓
Send Results
- Execution Engine은 드라이버에게 데이터노드로 부터 받은 결과들을 전달합니다.

                  ↓
Send Results
- 드라이버는 하이브 인터페이스에게 결과들을 전달합니다.

 

 

하둡x2 & Hive

UI : 사용자가 쿼리 및 기타 작업을 시스템에 제출하는 사용자 인터페이스 (CLI, Beeline, JDBC 등)

Driver : 쿼리를 입력받고 작업을 처리, 사용자 세션을 구현하고, JDBC/ODBC 인터페이스 API 제공

Compiler : 메타 스토어를 참고하여 쿼리 구문을 분석하고 실행계획을 생성

Metastore : 디비, 테이블, 파티션의 정보를 저장

Execution Engine : 컴파일러에 의해 생성된 실행 계획을 실행

 

 

사용자가 제출한 SQL문을 드라이버가 컴파일러에 요청하여 메타스토어의 정보를 이용해 처리에 적합한 형태로 컴파일

                          ↓                     

컴파일된 SQL을 실행엔진으로 실행

                          ↓

리소스 매니저가 클러스터의 자원을 적절히 활용하여 실행

                          ↓

실행 중 사용하는 원천데이터는 HDFS등의 저장장치를 이용

                          ↓

실행결과를 사용자에게 반환

레디스(Redis)란?

: (Redis)Remote Dictionary Server의 약자로서, "키-값" 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 데이터베이스 관리 시스템(DBMS)입니다.

 

IMDG(In-Memory Data Grid) 소프트웨어(메모리기반으로 되어 있는 소프트웨어) – 분산 캐시 시스템이면서 NoSQL 데이터베이스처럼 대규모 데이터 관리 능력도 갖추고 있습니다. 실질적인 메모리 용량에 있어서는 한계를 가지고 있습니다.(소규모성의 빠른 필터링을 통해 영구 보관할 필요 없을 때 사용하는 데이터 셋)

 

NOSQL: Not Only SQL, 비관계형 데이터베이스

그렇다면 왜, 언제 NOSQL을 쓰는 걸까요? 아주 많은 양의 데이터를 효율적으로 처리가 필요할 때, 데이터의 분산처리, 빠른 쓰기데이터의 안정성이 필요할 때 사용합니다. 특정 서버에 장애가 발생했을 때에도 데이터 유실이나 서비스 중지가 없는 형태의 구조이기 때문에, NOSQL을 사용합니다.

 

 

레디스(Redis)의 특징

 

1) key/value 형식의 데이터 구조를 분산 서버상의 메모리에 저장하면서 고성능의 응답 속도를 보장합니다.

 

2) hash, set, list 등 다양한 자료구조를 지원하기 때문에 다양한 유형의 자료 구조를 저장할 수 있습니다.

 

3) 데이터 유실에 대비한 AOF(Append Only File) 기능으로 정합성 보장합니다.

- 다양한 명령어 구문을 제공을 통해 히스토리들을 하나도 빠짐없이 데이터를 저장하여 손실을 최소화할 수 있습니다.

 

4) 저장된 데이터를 수행하는 업무시스템과 연계하여 처리될 수 있도록 합니다(업무처리의 신속성)

 

5) 휘발성이면서 영속성을 가진 key-value 저장소 입니다.

 

= 대규모 빅데이터 아키텍처에서는 실시간으로 분석한 결과를 레디스에 저장해서 주변 업무 시스템과 결과를 빠르게 공유하는 데 주로 활용.

 

 

레디스(Redis)의 아키텍처

 

 

● Master : 분산 노드 간의 데이터 복재와 Slave 서버의 관리를 위한 마스터 서버입니다.

 

● Slave : 다수의 Slave 서버는 주로 읽기 요청을 처리하고, Master 서버는 쓰기 요청을 처리 합니다.

 

● Sentinel : 레디스3.x에서 지원하는 기능으로, Master 서버에 문제가 발생할 경우 새로운 Master를 선출하는 기능

 

● Replication : Master 서버에 쓰인 내용을 Slave 서버로 복재해서 동기화 처리

 

● AOF/Snapshot : 데이터를 영구적으로 저장하는 기능으로, 명령어를 기록하는 AOF와 스냅샷 이미지 파일 방식 지원

 

 

HBase란?

: 아파치 HBase(Apache HBase)는 하둡 플랫폼을 위한 공개 비관계형 분산 데이터 베이스이다. 구글의 빅테이(BigTable)을 본보기로 삼았으며 자바로 쓰여졌습니다. 아파치 소프트웨어 재단의 아파치 하둡 프로젝트 일부로서 개발되었으며 하둡의 분산 파일 시스템인 HDFS위에서 동작을 합니다.

 

 

                                   HBase 홈페이지 : hbase.apache.org/

 

 

HBase의 특징

 

1) 하둡의 HDFS를 저장소로 사용하는 컬럼 기반 지향의 NoSQL 데이터베이스입니다.

 - NoSQL DB는 데이터를 키/값(key/value) 형식으로 단순하게 구조화하는 

   대신 고성능의 쓰기/읽기가 가능하도록 만든 데이터베이스 (핵심포인트) – 실시간성의 처리 최적화

-  HBase의 경우 특히 쓰기 성능에 좀 더 최적화되어 있으며, 대용량 처리가 

   필요한 대규모 NoSQL 아키텍처 구성이 필요할 때 자주 사용.

 

2) 논리적 관점에서 로우키와 컬럼패밀리, 컬럼 퀄러파이어의 중첩 맵 구조로 저장합니다.

- 컬럼패밀리 : 컬럼과 값의 집합을 선능 상의 이유로 물리적으로 값을 장소에 배치하는 것을 의미합니다. 

- 컬럼퀄러파이어 : 데이터를 인덱스를 제공하기 위해 컬럼 패밀리에 추가된 것입니다.  

 

3) 물리적 관점에서는 컬럼 패밀리 단위로 생성되는 HFile 이라는 파일에 저장합니다.

 

- 중간 매개체적 역할을 하는 것이 HBase 입니다. 직접적으로 memory 를 이용해서 수행할 수 있도록 되어있습니다. 최종적으로 hdfs에 적재되도록 구성되어 있으며 HRegion 서버를 통해서 가능하게 합니다.

 

 

 

HBase 아키텍처

 

※ 주키퍼(zookeeper)의 역할

 

1) 클라이언트가 region에 통신하려면 zookeeper을 통해야 합니다.

2) 클러스터에 있는 모든 RegionServer 들을 (주키퍼를 이용해서) 모니터링 합니다.

3) 클라이언트와 HMaster와의 연동을 도와줍니다.

4) 클러스터를 구성하는 서버들의 상태를 관리를 합니다.

5) 클러스터간의 정보공유를 위한 저장소 역할을 합니다.  

 

HMaster – HRegion 서버를 관리하며, HRegion 서버의 메타 정보를 관리합니다. 관리 기능 - 테이블의 생성, 삭제, 업데이트,  클러스터에 있는 모든 리전 서버들을 (주키퍼를 이용해서) 모니터링

 

HRegionServer - 분산 노드별 HRegionServer가 구성되며 하나의 HRegionServer에는 다수의 HRegion이 생성되어

HRegion을 관리합니다. 또한 클라이언트와 틍신을 하고 데이터 관련 연산을 관리합니다.

 

HRegion – Htable의 크기에 따라 자동으로 수평 분할이 발생하고, 이때 분할된 블록을 HRegion 단위로 지정

 

HTable – 칼럼 기반 데이터 구조를 정의한 테이블로서, 공통점이 있는 칼럼들의 그룹을 묶은 칼럼 패밀리와 테이블의 로우를 식별해서 접근하기 위한 로우키로 구성합니다.

 

Store - 하나의 Store에는 칼럼 패밀리가 저장 및 관리되며, MemStore HFile로 구성되어 있습니다.

 

MemStore – Store 내의 데이터를 인메모리에 저장 및 관리하는 데이터 캐시 영역입니다. Key/Value 데이터를 정렬해서 저장하고, 이 데이터를 그대로 HFile에 저장합니다. 하나의 컬럼패밀리당 하나의 MemStore가 존재합니다. 

 

HFile – Store 내의 데이터를 스토리지에 저장 및 관리하는 영구 저장 영역입니다. Key & Values 형태로 저장됩니다.

 

 

 

 

+ Recent posts