hyerimir_archive

클라우드 컴퓨팅

: 클라우드 컴퓨팅은 동적으로 확장할 수 있는 가상화 자원들을 인터넷으로 서비스 하는 기술

3가지 유형

- IaaS(Infrastructure as a Service) : 네트워크 장비, 서버와 스토리지 등과 같은 IT 인프라 자원을 빌려주는 클라우드 서비스

- SaaS(Software as a Service) : 서비스로서의 소프트웨어를 의미하며, 소프트웨어를 웹에서 사용할 수 있게 해주는 서비스

- Paas(Platform as a Service) : 서비스로서의 플랫폼을 의미하며, 애플리케이션이나 소프트웨어 개발 및 구현 시 필요한 플랫폼을 제공하는 서비스

: VMware, Xen, KVM 등과 같은 서버 가상화 기술은 데이터 센터나 기업들에게 인프라스트럭처를 위한 클라우드 서비스의 가능성을 보여주며, IaaS에 주로 활용됨

: 아마존은 S3와 EC2 환경을 제공함으로써 플랫폼을 위한 클라우드 서비스를 최초 실현, 특히 AWS와 EMR은 하둡을 온디맨드로 이용할 수 있는 클라우드 서비스

: 구글은 AppEngine, Apps, Gears, Gadgets 등을 제공함으로써 웹 기반의 다양한 소프트웨어들이 클라우드 서비스로서 어떻게 구체화될 수 있는지를 보여주었다.

인프라 기술은 클라우드 컴퓨팅의 근간이 되는 기술이며, 인프라 기술들 중에서도 가장 기반이 되는 기술은 서버 가상화

서버 가상화 : 물리적인 서버와 운영체제 사이에 적절한 계층을 추가해 서버를 사용하는 사용자에게 물리적인 자원은 숨기고 논리적인 자원만을 보여주는 기술

클라우드 컴퓨팅 환경에서 많이 사용되는 서버는 x86계열

서버 가상화 기술의 효과

- 가상머신 사이의 데이터 보호

- 예측하지 못한 장애로부터 보호

- 공유 자원에 대한 강제 사용의 거부

- 서버 통합 : 가장 일반적인 효과, 동일한 데이터 센터의 물리적 자원(공간, 전원 등)을 이용하면서 더 많은 서버를 운영

- 테스팅

- 정확하고 안전한 서버 사이징

- 시스템 관리 : 하드웨어 장애, 로드 밸런싱, 업그레이드

CPU 가상화

하이퍼바이저(Hypervisor)의 개념

: 물리적 서버 위에 존재하는 가상화 레이어를 통해 운영체제를 수행하는데 필요한 하드웨어 환경을 가상으로 만들어줌

: 하이퍼바이저(Hypervisor)는 호스트 컴퓨터에서 다수의 운영 체제를 동시에 실행하도록 하기 위한 논리적인 플랫폼

: 가상머신(Virtual Machine)이라고도 불림

: 하이퍼바이저는 서버 가상화 기술의 핵심

하이퍼바이저의 기능

: 하드웨어 환경 에뮬레이션

: 실행환경 격리

: 시스템 자원 할당

: 소프트웨어 스택 보존

플랫폼 별 분류

x86 계열 : VMware, MS Virtual Server, Xen

하이퍼바이저의 위치와 기능에 따른 분류

- 베어메탈 하이퍼바이저 : 하드웨어와 호스트 운영체제 사이에 위치

  베어메탈 하이퍼바이저는 반가상화(Para Virtualizaiton)과 완전가상화(Full Virtualization)으로 구분

- 호스트 기반 하이퍼바이저 : 호스트 운영체제와 게스트 운영체제 사이에 위치

Privileged 명령어 처리 방법에 따른 분류

: 새로운 가상화 방법이 계속 나오기 때문에 서버 가상화 기술을 정확하게 분류하기는 힘들다

: x86 계열 운영체제는 자신의 모든 하드웨어에 대한 제어 소유권을 갖고 있다는 가정 아래 하드웨어 직접명령을 수행하는 방식으로 디자인돼 있다

: x86 아키텍처는 하드웨어에 대한 접근 권한을 관리하기 위해 4개의 레벨로 구성돼 있다. 일반적으로 사용자 애플리케이션 Ring 3레벨로 수행되며, 운영체제의 경우 메모리나 하드웨어에 직접 접근해야 하기 때문에 Ring 0레벨에서 수행된다

가상화 방식의 분류

- 완전 가상화

: 완전 가상화란 하이퍼바이저보다 우선순위가 낮은 가상머신에서는 실행되지 않는 Privileged 명령어에 대해서 Trap을 발생시켜 하이퍼바이저에서 실행하는 방식

: VMware ESX Server, MS Virtual Server

장점 : CPU뿐만 아니라 메모리, 네트워크 장치 등 모든 자원을 하이퍼바이저가 직접 제어, 관리하기 때문에 어떤 운영 체제라도 수정하지 않고 설치 가능

단점 : 하이퍼바이저가 자원을 직접 제어하기 때문에 성능에 영향을 미침, 자원들이 하이퍼바이저에 너무 밀접하게 연관돼있어 운영 중인 게스트 운영체제에 할당된 CPU나 메모리 등의 자원에 대한 동적 변경 작업이 단일 서버 내에서는 어려움, Para Virtualization에 비해 속도가 느림

- 하드웨어 지원 완전 가상화

: 최근에는 완전 가상화 방식에서 Intel VT-x, AMD-V CPU의 하드웨어에서 제공하는 가상화 기능 이용

: 인텔에서는 반가상화와 하드웨어 지원 완전 가상화를 모두 사용하는 하이브리드 가상화를 제시

- 반가상화

: Privileged 명령어를 게스트 운영체제에서 Hypercall로 하이퍼바이저에 전달하고, 하이퍼바이저는 Hypercall에 대해서 Privileged 레벨에 상관없이 하드웨어로 명령을 수행시킨다

: CPU와 메모리 자원의 동적 변경이 서비스의 중단 없이 이루어질 수 있으며, 완전 가상화에 비해 성능이 뛰어나다

: 반가상화는 Privileged 명령어를 직접 호출(Hypercall)하므로 속도는 빠르나 커널을 변경해야함

  완전 가상화는 통신을 통해 처리하므로 속도는 느리나 커널 변경이 없다

: VMI는 표준 인터페이스를 제시하고, 이 인터페이스를 준수하는 모든 게스트 운영체제를 지원하는 체계로 반가상화를 지원하고 있다

: 수정된 OS 사용, hypercall을 가능하도록 게스트 OS 변경함, 호환성이 안좋음, 속도는 빠르나 커널 변경해야함

Monolithic vs Microkernel

: 하드웨어에 대한 드라이버가 어느 계층에 있느냐

- Monolithic : 사용하는 드라이버를 하이퍼바이저 계층에서 모두 갖고 있는 방식

- Microckernel : 각 가상머신에서 드라이버를 갖는 방식

호스트 기반 가상화

: 호스트 기반 가상화는 완전한 운영체제가 설치되고, 가상화를 담당하는 하이퍼바이저가 호스트 운영체제 위에 탑재되는 방식

: 제약 사항이 많음, 가장 큰 단점은 단일 운영체제의 취약성

: VMware, Workstation, Microsoft Virtual PC

: 주로 테스트 환경에서 많이 사용

컨테이너 기반 가상화

: 컨테이너 기반 가상화는 호스트 운영체제 위에 가상의 운영체제를 구성하기 위한 운영 환경 계층을 추가하여 운영체제만을 가상화한 방식

: 컨테이너 기반 가상화 방식에서 가상화를 지원하는 계층을 하이퍼바이저라고 하지 않으며, 가상 운영환경이라고 부름

장점 : 운영체제만을 가상화 대상으로 하므로 전체 하드웨어를 대상으로 하는 하이퍼바이저 기반 가상화 방식에 비해 훨씬 적게 가상화함, 가상화 수준이 낮기 때문에 다른 방식에 비해 빠른 성능을 보임, 한 대의 서버에서 더 많은 컨테이너를 실행할 수 있음

단점 : 자원 간 격리 수준이 낮아 하나의 가상 운영체제에서 실행되는 애플리케이션의 자원 사용에 따라 다른 가상 운영체제가 영향을 받음, 호스트 운영체제를 공유하기 때문에 호스트 운영체제의 문제가 전체 가상 운영체제에도 영향을 미침

하이퍼바이저 기반 가상화와 컨테이너 기반 가상화 비교

하이퍼바이저 기반(Full, Para)

- 하드웨어 독립성 : 가상머신 내에서 완전 독립

- OS 독립성 : 호스트 OS와 완전 독립

- 격리 수준 : 높은 격리 수준

- 성능 : 높은 오버헤드 발생, 성능 향상을 위해 HW 가상화 기술 병행

- 관리 : 가상머신 별로 별도 관리

- 응용분야 : 이기종 통합

- 대표제품 : VMware ESX, MS Virtual Server, Xen(Para Virtualization)

컨테이너 기반

- 하드웨어 독립성 : 호스트 OS 사용

- OS 독립성 : 호스트와 게스트 동일

- 격리 수준 : 낮은 격리 수준

- 성능 : 오버헤드 거의 없음, HW 자원의 대부분을 활용

- 관리 : 공통 SW 중앙 집중식 관리

- 응용분야 : 단일 OS 환경 자원 통합 대규모 호스팅 업체

- 대표제품 : Virtuozzo, Sun Solaris Container

메모리 가상화 : VMware 기법

: Vmware란 한 대의 컴퓨터로 마치 여러 대의 컴퓨터를 사용하는 것과 같이 가상의 공간을 만들어주는 프로그램

: 운영체제는 메모리를 관리하기 위해 물리주소와 가상주소를 사용

- 물리주소 : 0부터 시작해서 실제 물리적인 메모리 크기까지 나타냄

- 가상주소 : 하나의 프로세스가 가리킬 수 있는 최대 크기를 의미

: 프로그램에서의 주소는 물리적인 메모리의 주소 값이 아닌 가상주소의 값, 가상주소 값의 위치(VPN)를 실제 물리적인 주소 값 위치(MPN)로 매핑하는 과정이 필요하며 Page Table을 이용

: 매핑 연산을 하드웨어적으로 도와주는 것을 TLB라고 한다

: VMware 하이퍼바이저의 핵심 모듈은 VMkernel이다

: VMkernel은 Service Console, 디바이스 드라이버들의 메모리 영역을 제외한 나머지 전체 메모리 영역을 모두 관리하면서 가상머신에 메모리를 할당

가상머신 메모리 할당의 문제 해결을 위한 방법

- Memory Ballooning : 예약된 메모리보다 더 많은 메모리를 사용하는 가상머신의 메모리 영역을 빈값으로 강제로 채워 가상머신 운영체제가 자체적으로 Swapping하도록 한다

- Transparent Page Sharing : 동일한 내용을 담고 있는 페이지는 물리적인 메모리 영역에 하나만 존재시키고 모든 가상머신이 공유하도록 한다

- Memory Overcommitment

I/O 가상화

: 하나의 물리적인 장비에 여러 개의 가상머신이 실행되고 있는 상황에서 가장 문제가 되는 것은 I/O에서의 병목 현상

: CPU 자원의 파티셔닝만으로는 가상화 기술을 제대로 활용할 수 없으며, I/O 자원의 공유 및 파티셔닝이 필요하다

가상 이더넷

: 가상 이더넷은 대표적인 I/O 가상화 기술의 하나로, 가상화 기능 중에서 물리적으로 존재하지 않는 자원을 만들어내는 에뮬레이션 기능을 이용

: 사용자들은 별도의 물리적 어댑터와 케이블을 사용하지 않고도 네트워크 이중화, 네트워크의 안정적 단절 등의 효과를 얻을 수 있음

공유 이더넷 어댑터

: 공유 이더넷 어댑터는 여러 개의 가상머신이 물리적인 네트워크 카드를 공유할 수 있게 하며, 공유된 물리적 카드를 통해서 외부 네트워크와 통신이 가능하다

: 하나의 자원을 여러 가상머신이 공유하기 때문에 발생하는 병목현상은 피할 수 없다

가상 디스크 어댑터

: 가상화된 환경에서 가상 디스크를 이용해 가상머신이 디스크 자원을 획득하는 방법(내장디스크, 외장디스크)

MapReduce

: 구글에서 분산 병렬 컴퓨팅을 이용하여 대용량 데이터를 처리하기 위한 목적으로 제작한 소프트웨어 프레임워크

: 분할정복 방식으로 대용량 데이터를 병렬로 처리할 수 있는 프로그래밍 모델

: 맵리듀스에서 Client의 수행 작업 단위는 맵리듀스 잡(MapReduce Job)이라고 하며, 잡(Job)은 Map Task와 Reduce Task로 나뉘어서 실행된다.

: Map Task 하나가 1개의 블록(64MB)을 대상으로 연산을 수행

프로그래밍 모델 : Map과 Reduce라는 2개의 단계로 나눌 수 있음

: Map에서는 Key와 Value의 쌍들을 입력으로 받는다

: 하나의 Key, Value 쌍은 사용자가 정의한 Map 함수를 거치면서 다수의 새로운 Key, Value 쌍들로 변환되어 로컬 파일시스템에 임시 저장된다

: 저장된 임시 파일들은 프레임워크에 의해 Reduce에게 전송된다. 이 과정에서 자동으로 Shuffling과 Group by 정렬의 과정을 거친 후 Reduce의 입력 레코드로 들어가게 되는데 형식은 Key와 Value의 리스트이다.

: Reduce의 입력 레코드들은 사용자가 정의한 Reduce 함수를 통해 최종 Output 으로 산출된다.

실행 과정

: 하나의 큰 파일은 여러 개의 파일 Split들로 나뉘며, 각 Split들이 Map 프로세스들의 할당 단위가 된다. Split 수만큼 Map Task드이 워커로부터 Fork됨

: 동일한 Key들은 같은 Reduce로 배정된다

: 분산 Grep이나 빈도 수 계산 등의 작업은 적합하지만, 정렬과 같은 작업은 적합하지 않음

폴트톨러런스

: 각 프로세스에서는 Master에게 Task 진행 상태를 주기적으로 보낸다

: MapReduce는 Shared Nothing 아키텍처이기 때문에 간단한 메커니즘을 가진다.

Hadoop Mapreduce

: 아파치 오픈소스 프로젝트인 하둡의 MapReduce는 구글에서 발표한 논문을 바탕으로 하여 자바 언어로 구현된 시스템

: 하둡은 데몬 관점에서 4개의 구성 요소를 가지고 있음

- 네임노드

- 데이터노드

- 잡트래커

- 태스크트래커

: JobTracker는 작업을 다수의 Task로 쪼갠 후, 데이터 지역성을 보장하기 위해 그 Task들을 어떤 Task Tracker에게 보낼지를 감안해 내부적으로 스케줄링 해 큐에 저장

: Task는 맵퍼나 리듀서가 수행하는 단위 작업을 의미

: TaskTracker는 JobTracker에게 3초에 한 번씩 주기적으로 하트비트를 보내 살아있다는 것을 알린다

Hadoop MapReduce의 실행절차(워드카운트(Word Count) 예제 수행 과정 순서)

1. 스플릿(Split) : HDFS의 대용량 입력 파일을 분리하여 파일스플릿을 생성하고, 파일스플릿 하나당 맵 태스크 하나씩 생성

2. 맵(Map) : 각 스플리트에 대해서 레코드 단위로 Map 함수를 적용하여 Key-Value 쌍을 생성

3. 컴바인(Combine) : 리듀스와 동일한 프로그램을 적용하여, 리듀스 단계로 데이터를 보내기 전에 중간 결과값들을 처리하여 데이터의 크기를 줄여준다.

4. 파티션(Partition) : key를 기준으로 데이터를 디스크에 분할 저장하며, 각 파티션은 키를 기준으로 정렬이 수행된다. 또한 분할된 파일들은 각각 다른 리듀스 태스크에 저장된다

5. 셔플(Shuffle) : 여러 맵퍼들의 결과 파일을 각 리듀서에 할당하고, 할당된 파일을 로컬 파일 시스템으로 복사한다.

6. 정렬(Sort) : 병합 정렬 방식을 이용하여 맵퍼의 결과 파일을 Key를 기준으로 정렬한다

7. 리듀스(Reduce) : 정렬 단계에서 생성된 파일에 대해 리듀스 함수를 적용한다

하둡의 성능

: MapReduce의 Sort는 MapReduce에서 어떠한 작업을 실행하더라도 Map에서 Reduce로 넘어가는 과정에서 항상 발생하는 내부적인 프로세스이다, Sort 작업은 데이터가 커질수록 처리 시간이 선형적으로 증가한다

병렬 쿼리 시스템

: 스크립트나 사용자에게 친숙한 쿼리 인터페이스를 통해 병렬 처리를 할 수 있는 시스템

: 대표적으로 구글의 Sawzall, 야후의 Pig 등이 있으며, 이들은 사용자가 MapReduce를 쉽게 사용할 수 있도록 새로운 쿼리 언어로 추상화된 시스템들

구글 Sawzall

: 구글 Sawzall는 MapReduce를 추상화한 최초의 스크립트 형태 병렬 쿼리 언어

: 이후에 나온 오픈소스 프로젝트인 Pig나 하이브(Hive)도 개발 배경과 기본적인 개념은 Sawzall과 유사

아파치 Pig

: 아파치 Pig는 야후에서 개발해 오픈소스 프로젝트화한 데이터 처리를 위한 고차원 언어

:  Hadoop MapReduce 위에서 동작하는 추상화된 병렬 처리 언어이며, 아파치 하둡의 서브 프로젝트에 속한다

: 실제 대부분의 업무는 한번의 MapReduce 작업으로 끝나지 않는 경우가 많음 이를 해결하기 위해 의미적으로는 SQL과 비슷하지만 새로운 언어인 Pig를 정의하게 되었다

: MapReduce는 무공유 구조이기 때문에 Join 연산을 매우 복잡하게 처리해야 하지만, Pig를 사용하면 단 10라인의 코드로 간단히 해결할 수 있음

아파치 하이브

: 하이브는 페이스북에서 개발한 데이터 웨어하우징 인프라로 아파치 내의 하둡 서브 프로젝트로 등록돼 개발되고 있음

: Pig와 마찬가지로 하둡 플랫폼 위에서 동작하며, 사용자가 쉽게 사용할 수 있도록 SQL 기반의 쿼리 언어와 JDBC를 지원

: 하둡에서 가장 많이 사용하는 병렬처리 기능인 Haddop-Streaming을 쿼리 내부에 삽입해 사용할 수 있음

: 아파치 하이브는 맵리듀스의 모든 기능을 지원

아파치 하이브 아키텍처

: 하이브의 구성요소 중에서 Meta Store는 Raw File 들의 콘텐츠를 일종 테이블 내 칼럼처럼 구조화된 형태로 관리할 수 있게 해주는 스키마 저장소

: 별도의 DBMS를 설정하지 않으면 Embedded Derby를 기본 데이터베이스로 사용

하이브의 언어 모델

: DDL, DML, Query

SQL on 하둡

: 실시간 처리라는 측면에서 하둡의 제약사항을 극복하기 위한 시도 중 하나인 SQL on 하둡은 실시간 SQL 질의 분석 기술

임팔라

: SQL on 하둡 기술 중 먼저 대중에게 공개된 기술

: 임팔라는 분석과 트랜잭션 처리를 모두 지원하는 것을 목표로 만들어진 SQL 질의 엔진

: 하둡과 Hbase에 저장된 데이터를 대상으로 SQL 질의를 할 수 있음

: 고성능을 낼 수 있도록 자바 대신 C++ 언어를 사용하였으며, 맵리듀스를 사용하지 않고 실행 중에 최적화된 코드를 생성해 데이터를 처리

임팔라의 구성요소

- 클라이언트

- 메타스토어

- 임팔라 데몬

- 스테이트 스토어 : 임팔라 데몬들의 상태를 체크하고 건강정보를 관리해주는 데몬

- 스토리지 : 현재는 HBase, HDFS의 두가지를 지원

임팔라 동작 방식

: 모든 노드에 임팔라 데몬이 구동

: 사용자의 질의는 데이터의 지역성을 고려해서 노드 전체로 분산되어 수행된다

: 실제 운영 환경에서는 라운드 로빈 방식으로 사용자 질의를 분산시켜서 질의에 대한 전 노드들이 코디네이터 역할을 고르게 수행할 수 있도록 해야 한다

임팔라의 SQL 구문

: 데이터 정의 언어, 데이터 조작 언어, 내장 함수

임팔라 데이터 모델

: 임팔라는 하둡 분산 파일시스템에 데이터를 저장하며, 어떤 저장 포맷을 사용하느냐에 따라 데이터 조회시 처리 성능이 달라짐

: 저장 포맷별 특징

- 로우 단위로 저장 : 테이블에서 하나의 컬럼을 읽든 전체 테이블을 읽든 동일한 디스크 입출력이 발생

- 컬럼 단위의 저장 : 읽고자하는 칼럼만큼의 디스크 입출력이 발생하기 때문에 처리 성능을 개선할 수 있음, 로우 단위 파일 포맷을 사용했을 때보다 처리 시간이 적게 걸리므로 처리 시간의 측면에서 더 효율적

분산 파일 시스템의 개요

: 분산 데이터 저장 기술은 분산 파일시스템, 클러스터, 데이터베이스, NoSQL로 구분된다.

: 최근 파일의 메타데이터를 관리하는 전용 서버를 가지고 있는 '비대칭형(asymetric) 클러스터 파일 시스템'이 활발하게 개발되고 있음, 이 시스템은 메타데이터에 접근하는 경로와 데이터에 접근하는 경로가 분리된 구조를 가진다

구글 파일 시스템(GFS, Google File System)

: GFS는 Google File System으로서, 구글이 자사 사용 목적으로 개발한 분산 파일 시스템이며 구글의 대규모 클러스터 서비스 플랫폼의 기반이 되는 시스템이다.

: 일반적 파일 시스템에서의 클러스터 및 섹터와 유사하게 고정된 크기(64MB)의 청크(chunk)들로 나누고, 각 chunk에 대한 여러 개의 복제본과 chunk를 청크서버에 분산, 저장한다. 청크 서버들은 데이터를 자동으로 복사하여 저장하고, 주기적으로 청크서버의 상태를 마스터에게 전달한다.

: 트리 구조가 아닌 해시 테이블 구조 등을 사용함으로써 메모리상에서 보다 효율적인 메타데이터의 처리를 지원한다.

: chunk는 마스터에 의해 생성/삭제될 수 있으며, 유일한 식별자에 의해 구별된다.

GFS 설계의 가정

: 저가형 서버로 구성된 환경으로 서버의 고장이 빈번히 발생할 수 있다고 가정

: 파일에 대한 쓰기 연산은 주로 순차적으로 이루어지며, 파일에 대한 갱신은 드물게 이루어진다.

: 여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드를 최소화할 수 있는 방법이 요구됨

: 낮은 응답 지연시간보다 높은 처리율이 더 중요하다.

GFS의 구성요소

: GFS는 여러 클라이언트들에 의해 접근되는 하나의 마스터와 청크서버들로 구성된다.

- 클라이언트(Client) : 파일에 대한 읽기/쓰기 동작을 요청하는 애플리케이션으로 POSIX(Portable Operating System Interface) 인터페이스를 지원하지 않으며, 파일 시스템 인터페이스와 유사한 자체 인터페이스를 지원

- 마스터(Master) : 단일 마스터 구조로 모든 메타데이터를 메모리상에서 관리, 주기적으로 수집되는 청크서버의 하트비트(Heartbeat) 메시지를 이용하여 chunk들의 상태에 따라 chunk를 재복제하거나 재분산하는 것과 같은 회복동작을 수행

- 청크서버(Chunk Server) : 로컬 디스크에 chunk를 저장, 관리하면서 클라이언트로부터 chunk 입출력 요청을 처리, 하트비트(Heartbeat) 메시지를 통해 청크서버의 상태에 대한 정보를 주기적으로 마스터에게 전달

GFS에서 파일을 읽어오는 과정

: 클라이언트는 파일에 접근하기 위해 마스터로부터 해당 파일의 chunk가 저장된 chunk 서버의 위치와 핸들을 먼저 받아온 뒤, 직접 청크서버에게 파일 데이터를 요청한다.

하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)

: 아파치 너치(Apache Nutch) 웹 검색 엔진의 파일 시스템으로 개발되었으며, 구글 파일 시스템의 아키텍처와 사상을 그대로 구현한 클로닝(Cloning) 프로젝트

: 클라우드 컴퓨팅 환경을 구축하기 위해 이용하여 대용량 데이터의 분산 저장 기능을 제공하는 시스템

: HDFS는 GFS의 마스터와 유사한 하나의 네임노드(NameNode), GFS의 청크서버와 유사한 다수의 데이터노드(DataNodee)로 구성되며, 파일 데이터는 블록(또는 청크) 단위로 나뉘어 여러 데이터 노드에 분산, 복제, 저장된다.

: HDFS에서 기본적으로 파일은 한 번 쓰이면 변경되지 않는다고 가정한다.

: HDFS는 순차적 스트리밍 방식으로 파일을 저장하거나 저장된 파일을 조회하며, 배치 작업에 적합하도록 설계돼 있다.

: 낮은 데이터 접근 지연 시간보다는 높은 데이터 처리량에 중점을 두고 있다.

HDFS의 구성요소

- 네임노드(NameNode) : HDFS상의 모든 메타데이터를 관리하며, 마스터/슬레이브 구조에서 마스터 역할, 시스템 전반의 상태 모니터링, 데이터를 저장하거나 애플리케이션을 실행하는 작업은 수행하지 않음, 클라이언트로부터의 파일 접근 요청을 처리, 데이터노드들로부터 하트비트(HeartBeat)를 받아 데이터노드들의 상태를 체크하는데, 하트비트 메시지에 포함된 블록 정보를 가지고 블록의 상태를 체크할 수 있음

- 데이터노드(DataNode) : HDFS의 슬레이브 노드로, 클라이언트로부터 데이터 입출력 요청을 처리, 데이터의 유실을 방지하기 위해 블록을 3중복제하여 저장, 블록을 저장할 때, 해당 블록에 대한 파일의 체크섬(Checksum) 정보를 별도 저장, 주기적으로 데이터노드의 상태를 나타내는 하트비트(HeartBeat)와 자신이 관리하는 블록의 목록인 Blockreport를 네임노드에게 전송

- 보조네임노드 : HDFS 상태 모니터링을 보조

HDFS의 파일 읽기 과정

: 클라이언트는 읽고자 하는 파일에 대한 정보를 네임노드에게 요청

: 네임노드는 파일에 대한 모든 블록의 목록과 블록이 저장된 데이터노드의 위치를 클라이언트에게 반환

: 클라이언트는 전달받은 블록의 위치를 이용해 데이터노드로부터 직접 데이터를 읽어 들인다.

러스터(Luster)

: 클러스터 파일 시스템에서 개발한 객체 기반의 클러스터 파일 시스템, 계층화된 모듈 구조

구성요소

- 클라이언트 파일 시스템

- 메타데이터 서버

- 객체 저장 서버 : 파일데이터를 저장하고, 클라이언트로부터의 객체 입출력 요청을 처리, 데이터는 세그먼트라는 작은 데이터 단위로 분할해서 복수의 디스크 장치에 분산시키는 기술인 스트라이핑 방식으로 분산, 저장한다.

구동방식

: 러스터는 유닉스 시맨틱을 제공하면서 파일 메타데이터에 대해서는 라이트백 캐시(Write Back Cache)를 지원한다. 이를 위해 클라이언트에서 메타데이터 변경에 대한 갱신 레코드를 생성하고 나중에 메타데이터 서버에 전달한다.

: 러스터는 파일의 메타데이터와 파일 데이터에 대한 동시성 제어를 위해 별도의 잠금을 사용한다.

: 러스터는 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 최소화하기 위하여 메타 데이터에 대한 잠금 요청 시에 메타데이터 접근 의도를 같이 전달하는 인텐트(Intent) 기반 잠금 프로토콜을 사용한다.

데이터베이스 클러스터

: 데이터베이스 클러스터는 하나의 데이터베이스를 여러 개의 서버(또는 가상 서버) 상에 구축하는 것

: 데이터를 통합할 때, 성능과 가용성의 향상을 위해 데이터베이스 차원의 파티셔닝 또는 클러스터링을 이용

데이터 베이스 파티셔닝 구현의 효과

: 병렬처리, 고가용성(특정 파티션에서 장애가 발생하더라도 서비스가 중단 않음), 성능향상(성능의 선형적인 증가 효과)

데이터베이스 클러스터의 구분

: 데이터베이스 시스템을 구성하는 형태에 따라 단일 서버 내의 파티셔닝과 다중서버 사이의 파티셔닝으로 구분

: 리소스 공유 관점에서는 다시 공유디스크와 무공유로 구분

데이터베이스 클러스터의 구분

무공유 디스크

: 무공유(Shared Nothing) 클러스터에서 각 데이터베이스 인스턴스는 자신이 관리하는 데이터 파일을 자신의 로컬 디스크에 저장하며, 이 파일들은 노드 간에 공유하지 않는다.

: 각 인스턴스나 노드는 완전히 분리된 데이터의 서브 집합에 대한 소유권을 가지고 있으며, 각 데이터는 소유건을 갖고 있는 인스턴스가 처리한다.

: Oracle RAC(Real Application Cluster)를 제외한 대부분 데이터베이스 클러스터가 무공유 방식을 채택

장점 : 노드 확장에 제한 없음

단점 :  각 노드에 장애가 발생할 경우를 대비해 별도의 폴트톨러런스(fault-tolerance)를 구성해야 함

공유 디스크

: 공유 디스크(Shared Disk) 클러스터에서 데이터 파일은 논리적으로 모든 데이터베이스 인스턴스 노드들은 데이터 파일을 논리적으로 공유하며, 각 인스턴스는 모든 데이터에 접근할 수 있음

: 데이터를 공유하려면 SAN(Storage Area Network)과 같은 네트워크가 반드시 있어야 함

: 모든 노드가 데이터를 수정할 수 있기 때문에 노드간의 동기화 작업 수행을 위한 별도의 커뮤니케이션 채널 필요

장점 : 높은 수준의 폴트 톨러런스를 제공하므로 클러스터를 구성하는 노드 중 하나의 노드만 살아 있어도 서비스 가능

단점 : 클러스터가 커지면 디스크 영역에서 병목현상 발생

데이터베이스 클러스터의 종류

- Oracle RAC 데이터베이스 서버

: 공유 클러스터, 클러스터의 모든 노드에서 실행되며 데이터는 공유 스토리지에 저장됨

: 클러스터의 모든 노드는 데이터베이스의 모든 테이블에 동등하게 액세스하며, 특정 노드가 데이터를 '소유'하는 개념 없음

: 응용 프로그램은 클러스터의 특정 노드가 아니라 RAC 클러스터에 연결하며, RAC는 클러스터의 모든 노드에 로드를 고르게 분산

Oracle RAC 데이터베이스 서버의 장점

: 가용성(높은 수준의 폴트 톨러런스), 확장성(새 노드를 클러스터에 쉽게 추가), 비용 절감

도입 비용 때문에 확장성이 중요한 데이터보다는 고가용성을 요구하는 데이터에 많이 사용됨

- IBM DB2 ICE(Integrated Cluster Environment)

: DB2는 CPU, 메모리, 디스크를 파티션별로 독립적으로 운영하는 무공유 방식의 클러스터링 지원

: 애플리케이션은 여러 파티션에 분산된 데이터베이스를 하나의 데이터베이스로 보게 되고, 데이터가 어느 파티션에 존재하고 있는지 알 필요 없음

: 각 노드로 분사되는 파티셔닝을 어떻게 구성하느냐에 따성능의 차이가 많이 발생할 수 있음

- 마이크로소프트 SQL Server

: SQL Server는 연합(Federated) 데이터베이스 형태로, 여러 노드로 확장할 수 있는 기능 제공

: 연합 데이터베이스는 디스크 등을 공유하지 않는 독립된 서버에서 실행되는 서로 다른 데이터베이스들 간의 논리적인 결합이며, 네트워크를 이용하여 연결됨

: 각 노드의 데이터베이스 인스턴스 사이에 링크를 구성한 후 모든 파티션에 대해 UNION ALL을 이용해 논리적인 뷰를 구성하는 방식

: DBA나 개발자가 파티셔닝 정책에 맞게 테이블과 뷰를 생성해야 하고, 전역 스키마 정보가 없기 때문에 질의 수행을 위해 모든 노드를 액세스 해야함

: SQL Server에서도 페일오버 메커니즘을 제공하지만, Active-Active가 아닌 Active-Standby 방법을 사용

- MySQL

: MySQL 클러스터는 비공유형으로 메모리(최근에는 디스크도 제공) 기반 데이터베이스의 클러스터링 지원

: 특정한 하드웨어 및 소프트웨어를 요구하지 않고 병렬 서버구조로 확장 가능

: 관리노드, 데이터노드, MySQL 노드로 구성됨

- 관리노드 : 클러스터를 관리하는 노드로 클러스터 시작과 재구성 시에만 관여

- 데이터 노드 : 클러스터의 데이터를 저장하는 노드

- MySQL 노드 : 클러스터 데이터에 대한 접근을 지원하는 노드

: 장애가 발생했던 노드가 복구되어 클러스터에 투입된 경우에도 기존 데이터와 변경된 데이터에 대한 동기화 작업이 자동으로 수행된다

My SQL 클러스터를 구성을 할 경우의 제한 사항

: 파티셔닝은 LINEAR KEY 파티셔닝만 사용 가능

: 클러스터에 참여하는 노드(SQL 노드, 데이터 노드, 매니저를 포함) 수는 255로 제한, 데이터노드는 최대 48개가지만 가능

: 트랜잭션 수행 중에 롤백을 지원하지 않으므로 작업 수행 중에 문제가 발생하였다면, 전체 트랜잭션 이전으로 롤백해야 한다

: 모든 클러스터의 기종은 동일해야 한다

: 운영 중에 노드를 추가/삭제할 수 없다

NoSQL

: 여러 대의 데이터베이스 서버를 묶어 클러스터링한 후 하나의 데이터베이스를 구성

: 비관계형 데이터베이스 기술로, SQL 계열 쿼리 언어를 사용할 수 있다는 사실을 강조한다는 면에서 Not only SQL로 불리기도 한다

: NoSQL은 저장되는 데이터의 구조에 따라 Key-Value 모델, Document 모델, Graph 모델, Column 모델로 구분된다

: NoSQL은 Key와 Value의 형태로 자료를 저장하고, 빠르게 조회할 수 있는 자료 구조를 제공하는 데이터 저장소

: 스키마 없이 동작하며, 구조에 대한 정의 변경 없이 자유롭게 데이터베이스의 레코드에 필드를 추가할 수 있음

: 복잡한 Join 연산 기능은 지원하지 않음

: 대부분이 오픈소스이며, 구글 빅테이블, 아파치 HBase, 아마존 Simple DB, 마이크로소프트 SSDS 등이 있음

구글 빅테이블

: 빅테이블은 구글이 대용량의 데이터를 저장하기 위해 개발한 분산 데이터 관리 저장소로, 구글 클라우드 플랫폼에서 데이터 저장소로 사용됨

: 공유 디스크 방식이며, 구글에서 개발된 분산 파일시스템을 이용하고 있어 모든 노드가 데이터, 인덱스 파일을 공유하고 있음

구글 빅데이블 데이터 모델

: 빅테이블은 Multi-Dimension Sorted Hash Map을 파티션하여 분산 저장하는 저장소

: 테이블 내의 모든 데이터는 Row-Key의 사전적 순서로 정렬, 저장된다

: Row는 n개의 Column-Family(Column의 모음)를 가질 수 있으며, Column-Family에는 Column-Key, Value, Timestamp의 형태로 데이터를 저장한다.

: 동일한 Column-key에 대해 타임스탬프(Timestamp)가 다른 여러 버전의 값이 존재할 수 있으며, 타임스탬프는 칼럼 값의 버전을 관리하기 위해 사용된다.

: BigTable에 저장되는 하나의 데이터(Map)의 키 값 또는 정렬 기준은 Rowkey + Columnkey + Timestamp(로우식별자 + 칼럼 이름 + 타임스탬프)이다.

페일오버(Failover)

: 특정 노드에 장애가 발생할 경우, 빅데이블의 마스터는 장애가 발생한 노드에서 서비스되던 Tablet을 다른 노드로 재할당

: Chubby는 폴트톨러런스 지원 구조이기 때문에 절대로 장애가 발생하지 않는다

:

AppEngine

: 구글 클라우드 플랫폼의 일부로 빅테이블을 사용

: 빅테이블에서는 별도의 사용자 정의 인덱스를 제공하지 않는 반면, AppEngine에서는 사용자가 수행하는 쿼리를 분석하여 자동으로 인덱스를 생성해준다.

HBase

: 하둡 분산 파일 시스템(HDFS)를 기반으로 구현된 칼럼 기반의 분산 데이터베이스로 파워셋 회사에서 구글의 빅테이블을 모델로 하여 만듦

: HBase는 관계형 구조가 아니며, SQL을 지원하지 않는다

: 구조화된 데이터보다는 비구조화된 데이터에 더 적합

: 노드만 추가하면 선형으로 학장이 가능한 구조를 가지고 있으며, 클러스터를 통한 데이터의 복제 기능을 제공

: 관계형 데이터베이스와는 달리 수평적으로 확장성이 있어 큰 테이블에 적합

아마존 SimpleDB

: SimpleDB는 아마존의 데이터 서비스 플랫폼으로, 웹 애플리케이션에서 사용하는 데이터의 실시간 처리를 지원한다

: SimpleDB는 하나의 데이터에 대해 여러 개의 복제본을 유지하는 방식으로 가용성을 높이며, 트랜잭션 종료 후 데이터가 모든 노드에 즉시 반영되지 않고 초 단위로 지연 동기화되는 Eventual Consistency 정책을 취한다

: SimpleDB의 데이터 모델은 Domain, Item, Attribute, Value로 구성되며 스키마가 없는 구조

- 도메인 : 관계형 데이터베이스의 테이블과 동일한 개념

- Item : 관계형 데이터베이스의 레코드와 동일한 개념

- Attribute : 관겨형 데이터베이스의 칼럼과 동일한 개념이지만 사용하기 전에 미리 정의할 필요 없음, Name, Value 쌍으로 데이터를 저장, Item의 특정 Attribute에는 여러 개의 값을 저장할 수 있음

: 한 번에 하나의 도메인에 대해서만 쿼리를 수행해야함

마이크로소프트 SSDS

: SSDS(SQL Server Data Service)는 마이크로소프트에서 2008년 4월에 베타서비스를 실시한 데이터 서비스로 고가용성을 보장한다

: 컨테이너, 엔티티로 구성됨

로그(Log)

: 로그(Log)는 기업에서 발생하는 대표적인 비정형 데이터

: 용량이 방대하기 때문에 이를 분석하기 위해서는 고성능과 확장성을 가진 시스템이 필요

: 로그 데이터 수집 시스템의 예 : 아파치 Flume-NG, 페이스북 Scribe, 아파치 Chuckwa 등

대용량 비정형 데이터 수집 시 시스템의 특징

- 초고속 수집 성능과 확장성 : 수집 대상 서버가 증가하면 증가한 서버 수만큼 에이전트의 수를 늘리는 방식으로 쉽게 확장할 수 있는 구조

- 데이터 전송 보장 메커니즘 : 데이터가 여러 단계를 거쳐 저장소에 도착할 수 있는데, 단계별로 혹은 인접한 단계끼리 신호를 주고받아 이벤트의 유실을 방지하는 방식으로 전송을 보장할 수 있음, 각 방식은 성능과 안정성이라는 트레이드 오프가 존재하므로 비지니스의 특성을 고려해 선택해야함

- 다양한 수집과 저장 플러그인

- 인터페이스 상속을 통한 애플리케이션 기능 확장 : 인터페이스를 확장해 원하는 부분만 비지니스 용도에 맞게 수정할 수 있어야 함

대규모 분산 병렬 처리

하둡(Hadoop)

: 대규모 분산 병렬 처리의 업계 표준인 맵리듀스(MapReduce)시스템과 분산 파일시스템인 HDFS를 핵심 구성요소로 가지는 플랫폼 기술

: 여러 대의 컴퓨터를 마치 하나의 시스템인 것처럼 묶어 분산 환경에서 빅데이터를 저장 및 처리할 수 있도록 하는 자바 기반의 오픈소스 프레임워크

: 비공유 분산 아키텍처를 사용

하둡(Hadoop)의 특징

- 선형적인 성능과 용량 확장

: 여러 대의 서버로 클러스터를 만들어 하둡을 구축할 때 이론적으로 클러스터를 구성할 수 있는 서버의 대수에는 제한이 없고, 통상적으로 최소 클러스터 대수는 5대 정도

: 하둡은 비공유(Shared Nothing) 분산 아키텍처 시스템이기 때문에 서버를 추가하면 연산 기능과 저장 기능이 서버의 대수에 비례해 증가한다

- 고장 감내성

: HDFS에 저장되는 데이터는 3중복제가 되어 서로 다른 물리서버에 저장되므로 서버에서 장애가 발생하더라도 데이터 유실을 방지할 수 있음

: 맵리듀스 작업 수행 중 특정 태스크에서 장애가 생기면, 시스템이 자동으로 감지해 장애가 발생한 태스크만 다른 서버에서 재실행 할 수 있음

- 핵심 비즈니스 로직에 집중

: 하둡의 맵리듀스는 맵과 리듀스라는 2개의 함수만 구현하면서 동작하는 시스템

: 오직 비즈니스 로직에만 집중할 수 있도록 시스템 수준에서 발생하는 장애에 대해 자동 복구(Failover)를 제공하고, 확장성 및 성능 등의 이슈도 하둡이 내부적으로 최적화해 처리한다

하둡 에코 시스템(Hadoop Ecosystem)

: 하둡 프레임워크를 이루고 있는 다양한 서브 프로젝트들의 집합으로, 수집, 저장, 처리기술과 분석, 실시간 SQL 질의 기술로 구분

1. 비정형 데이터 수집

- 척와(Chuckwa) : 분산된 각 서버에서 에이전트를 실행하고, 컬렉터가 에이전트로부터 데이터를 받아 HDFS에 저장하는 기술

- 플럼(Flume) : 많은 양의 로그 데이터를 효율적으로 수집, 집계, 이동하기 위해 이벤트와 에이전트를 활용하는 기술

- 스크라이브(Scribe) : 다수의 서버로부터 실시간으로 스트리밍되는 로그 데이터를 수집하여 분산 시스템에 데이터를 저장하는 대용량 실시간 로그 수집 기술이며, 최종 데이터는 HDFS 외에 다양한 저장소를 활용

2. 정형 데이터 수집

- 스쿱(Sqoop) : 대용량 데이터 전송 솔루션으로 커넥터를 사용하여 관계형 데이터베이스 시스템(RDBMS)에서 하둡 파일 시스템(HDFS)으로 데이터를 수집하거나, 하둡 파일 시스템에서 관계형 데이터베이스로 데이터를 보내는 기술

- 히호(Hiho) : 스쿱과 같은 대용량 데이터 전송 솔루션이며, 하둡에서 데이터를 가져오기 위한 SQL을 지정할 수 있으며, JDBC 인터페이스를 지원

3. 분산 데이터 저장

- HDFS : 대용량 파일을 분산된 서버에 저장하고, 그 저장된 데이터를 빠르게 처리할 수 있게 하는 하둡 분산 파일 시스템으로 범용 하드웨어 기반 클러스터에서 실행되고 데이터 접근 패턴을 스트리밍 방식으로 지원하며, 다중 복제, 대량 파일 저장, 온라인 변경, 범용 서버 기반, 자동 복구 특징이 있음

 네임노드 : 마스터 역할, 모든 메타데이터 관리, 데이터노드들로부터 하트비트를 받아 상태 체크

 보조 네임노드 : 상태 모니터링을 보조함

 데이터노드 : 슬레이브 역할, 데이터 입출력 요청, 데이터 유실방지를 위해 블록을 3중 복제

4. 분산 데이터베이스

- HBASE : HDFS를 기반으로 구현된 컬럼 기반의 분산 데이터베이스로 실시간 랜덤 조회 및 업데이트를 할 수 있으며, 각각의 프로세스는 개인의 데이터를 비동기적으로 업데이트

5. 분산 데이터 처리

맵리듀스 : 대용량 데이터 세트를 분산 병렬 컴퓨팅에서 처리하거나 생성하기 위한 목적으로 만들어진 소프트웨어 프레임워크로 모든 데이터를 키-값(Key-Value) 쌍으로 구성

- 맵 : Key-Value 형태로 데이터를 취합

- 셔플 : 데이터를 통합하여 처리

- 리듀스 : 맵 처리된 데이터를 정리

6. 리소스 관리

- 얀(YARN) : 하둡의 맵디류스 처리 부분을 새롭게 만든 자원 관리 플랫폼으로, 리소스 매니저와 노드 매니저로 구성됨

 리소스 매니저 : 스케줄러 역할을 수행하고, 클러스터 이용률 최적화를 수행

 노드 매니저 : 노드 내의 자원을 관리하고, 리소스 매니저에게 전달 수행 및 컨테이너를 관리

 애플리케이션 마스터 : 리소스 매니저와 자원의 교섭을 책임지고, 컨테이너를 실행

 컨테이너 : 프로그램 구동을 위한 격리 환경을 지원하는 가상화 지원

7. 인메모리 처리

- 아파치 스파크(Apache Spark) : 하둡 기반 대규모 데이터 분산처리시스템으로 스트리밍 데이터, 온라인 머신러닝 등 실시간 데이터를 처리

8. 데이터 가공

- 피그(Pig) : 대용량 데이터 집합을 분석하기 위한 플랫폼으로 하둡을 이요하여 맵리듀스를 사용하기 위한 높은 수준의 스크립트 언어인 피그 라틴이라는 자체 언어를 제공

- 하이브(Hive) : 하둡 기반 DW 솔루션으로 SQL과 매우 유사한 HiveQL이라는 쿼리를 제공

9. 데이터 마이닝

- 머하웃(Mahout) : 하둡 기반으로 데이터 마이닝 알고리즘을 구현한 오픈소스로 분류, 클러스터링, 추천 및 협업 필터링, 패턴 마이닝, 회귀 분석, 진화 알고리즘 등 주요 알고리즘 지원

10. 실시간 SQL 질의

- 임팔라(Impala) : 하둡 기반의 실시간 SQL 질의 시스템으로 데이터 조회를 위한 인터페이스로 HiveQL을 사용하며, 수초 내의 SQL 질의 결과를 확인할 수 있으며, HBase와 연동이 가능

- 타조(Tajo) : 다양한 데이터 소스를 위한 하둡 기반의 ETL 기술을 이용해서 데이터 웨어 하우스에 적재하는 시스템

11. 워크플로우 관리

- 우지(Oozie) : 하둡 작업을 관리하는 워크플로우 및 코디네이터 시스템

12. 분산 코디네이션

- 주키퍼(Zookeeper) : 분산 환경에서 서버들 간에 상호 조정이 필요한 다양한 서비스를 제공하는 기술로 하나의 서버에서만 서비스가 집중되지 않도록 서비스를 알맞게 분산하여 동시에 처리

데이터 연동

스쿱(Sqoop)

: 하둡과 데이터베이스간의 데이터 연동 솔루션인 스쿱은 오라클, MySQL, PostgreSQL, 사이베이스 등 JDBC를 지원하는 대부분의 관계형 데이터베이스와의 연동을 지원한다

: HBase와 같은 일부 NoSQL 데이터베이스와도 연동 가능

: 스쿱은 데이터의 이동을 맵리듀스를 통해 처리하여 장애 허용 능력과 병렬 처리 기능을 제공

: 스쿱 스크립트의 Import 명령어를 이용하여 RDBMS의 데이터를 HDFS로 옮기고, Export 명령어를 이용하여 HDFS의 데이터를 RDBMS로 옮길 수 있음

: 스쿱을 통해 관계형 DB에서 하둡으로 데이터를 전송하는 스크립트

 1. 데이터를 가져올 데이터베이스 정보를 입력

 2. 가져올 데이터에 대한 SQL문을 입력

 3. 동시에 몇 개의 프로세스를 실행하여 데이터를 가져올지를 지정(프로세스를 많이 지정하면 데이터 전송 속도는 빠르지만 부하가 발생할 수 있으므로 적절한 개수를 지정)

 4. 데이터베이스의 키 칼럼을 입력

 5. 가져온 데이터를 저장할 하둡상의 경로를 지정

대용량 질의 기술

: 하둡은 저비용으로 대용량 데이터를 저장하고 신속하게 처리할 수 있는 시스템으로 이전에 비해 단순해졌지만 여전히 코딩이 필요하기 때문에 분석가에게는 어려움이 존재

: 이러한 이유로 사용자에게 친숙한 SQL이라는 질의 기술을 이요하여 하둡에 저장된 데이터를 쉽게 처리하고 분석할 수 있도록 해주는 하이브(Hive)가 등장해 널리 사용되고 있음

: 하둡과 하이브는 대용량 데이터를 배치 처리하는데 최적화 되어 있지만, 실제 업무에서는 데이터를 실시간으로 조회하거나 처리해야 하는 요구사항이 많다

: 실시간 조회 및 처리에 대한 제약을 극복하기 위해 실시간 SQL 질의 분석 기술인 SQL on 하둡이 등장하였음

SQL on 하둡 기술

- 아파치 드릴(Drill), 아파치 스팅거(Stinger), 샤크(Shark) : 인메모리 기반의 대용량 데이터 웨어하우스 시스템, 하이브와 호환되기 때문에 하이브 SQL 질의와 사용자 정의 함수를 사용할 수 있음, 아파치 타조(Tajo), 임팔라(Impala), 호크(HAWQ), 프레스토(페이스북에서 자체 개발)

데이터 연계 및 통합 유형(동기화 기준)

: 데이터 연계 및 통합 시 일괄(Batch) 작업 또는 비동기식 근접 실시간(Near Real Time) 또는 동기식 실시간(Real Time) 방식이 혼용, 사용될 수 있음

- 일괄(Batch) 통합 : 비실시간 데이터 통합, 대용량 데이터 대상, CDC

- 비동기식 실시간 통합

- 동기식 실시간 통합 : 목표 시스템 데이터 처리 가능시에만 원천 데이터 획득

시각화를 통해 대용량 데이터에서 통찰력(Insight)을 획득하고자 하는 시도는 빅데이터의 고유한 특성

전통적 데이터 저장 메커니즘 대비 다수의 노드에 중복을 허용하는 방식으로 데이터를 저장하는 것은 빅데이터의 고유한 특성

EAI(Enterprise Application Integration)

: 비지니스 프로세스를 중심으로 기업 내 각종 애플리케이션간의 상호 연동이 가능하도록 통합하는 솔루션

: 애플리케이션을 프로세스 및 메시지 차원에서 통합 및 관리

: 비지니스 프로세스를 자동화하고 실시간으로 통합 연계할 수 있음

: EAI는 실시간 혹은 근접 실시간 처리 중심, ETL은 배치 프로세스 중심

데이터 연계 방식

- 기존의 데이터 연계 방식 : Point to Point

-  EAI의 데이터 연계 방식 : Hub and Spoke

  : EAI는 다수 정보 시스템의 데이터를 중앙의 Hub가 연계하고 통합하는 기법

  : 각 연결의 대상이 되는 노드들은 Spoke에 해당

EAI의 구성요소

- 어댑터(Adapter) : 각 정보 시스템과 EAI 허브(Engine) 간의 연결성을 확보

- 버스(BUS) : 어댑터를 매개로 연결된 각 정보 시스템들 간의 데이터 연동 경로

- 브로커(Broker) : 데이터 연동 규칙을 통제

- 트랜스포머(Transformer) : 데이터 형식 변환을 담당

EAI 구현 유형

- Mediation(Intra-Communication)

 : EAI 엔진이 중개자(Broker)로 동작하며, 식별하여 미리 약속된 정보 시스템에 해당 내용(데이터)을 전달

 : Publish/Subscribe Model이라고 부른다

- Federation(Inter-Communication)

 : EAI 엔진이 외부 정보 시스템으로부터 데이터 요청들을 일괄적으로 수령해 필요한 데이터를 전달한다

 : Request/Reply Model이라고 부른다

EAI의 활용 효과

: 정보 시스템 개발 및 유지 보수비용 절감

: 기업 정보 시스템의 지속적 발전 기반 확보

: 협력사, 파트너, 고객과의 상호 협력 프로세스 연계

: 웹 서비스 등 인터넷 비지니스를 위한 기본 토대 확립

: 지역적으로 분리되어 있는 정보 시스템들 간의 데이터 동기화, 그룹 및 지주 회사 계열사들 간 상호 관련 데이터 동기화 등을 위한 데이터 표준화 기반 제공

EAI와 ESB의 비교

EAI(Enterprise Application Integration)

기능 : 미들웨어(Hub)를 이용하여 비지니스 로직을 중심으로 Application을 통합, 연계

통합관점 : Application

로직연동 : 개별 Application에서 수행

아키텍처 : 단일 접점인 허브시스템을 이용한 중앙집중식 연결구조

ESB(Enterprise Service Bus)

기능 : 미들웨어(Bus)를 이용하여 서비스 중심으로 시스템을 유기적으로 연계

통합관점 : Process

로직연동 : ESB에서 수행

아키텍처 : 버스(Bus) 형태의 느슨하고 유연한 연결구조

CDC(Change Data Capture):

- 데이터베이스 내 데이터에 대한 변경을 식별해 필요한 후속처리(데이터 전송/공유 등)를 자동화하는 기술 또는 설계 기법이자 구조

- 실시간 또는 근접 실시간 데이터 통합을 기반으로 하는 데이터 웨어하우스 및 기타 데이터 저장소 구축에 폭 넓게 활용

- 스토리지 하드웨어 계층에서부터 애플리케이션 계층에 이르기까지 다양한 계층에서 다양한 기술을 통해 구현

- 단일 정보 시스템 내에 다수의 CDC 메커니즘이 구현돼 동작될 수 있음

CDC 구현 기법

- Time Stamp on Rows

- Version Numbers on Rows

: 레코드들이 최신 버전을 기록, 관리하는 참조 '참조 테이블'을 함께 운영하는 것이 일반적

- Status on Rows

: 타임스탬프 및 버전 넘버 기법에 대한 보완 용도, 데이터 변경의 여부를 True/False의 불린(Boolean) 값으로 저장하는 칼럼의 상태값을 기반으로 변경 여부를 판단하는 기법

- Time/Version/Status on Rows

- Triggers on Tables

: 데이터베이스 트리거를 활용해 사전에 등록(Subscribe)된 다수 대상 시스템(Target)에 변경 데이터를 배포(Publish)하는 형태로 CDC를 구현하는 기법

: 시스템 관리 복잡도 증가, 변경 관리의 어려움, 확장성의 감소를 유발하는 등 전반적인 시스템 유지보수성을 저하시키는 특성이 있어 사용에 주의를 요함

- Event Programming

- Log Scanner on DataBase

: 각 데이터베이스 관리 시스템에 따라 트랜잭션 로그 관리 메커니즘 상이

: 데이터베이스와 사용 애플리케이션에 대한 영향도 최소화, 변경 식별 지연시간 최소화, 트랜잭션 무결성에 대한 영향도 최소화, 데이터베이스 스키마 변경 불필요

CDC 구현 방식

- 푸시 방식 : 데이터 원천(Source)에서 변경을 식별하고 대상 시스템(Target)에 변경 데이터를 적재해주는 방식

- 풀 방식 : 대상 시스템(Target)에서 데이터 원천(Source)을 정기적으로 살펴보고, 필요 시 데이터를 다운로드 하는 방식

ETL(Extraction, Transformation and Load):

- 데이터의 이동 및 변환 절차와 관련된 업계 표준용어

- 재사용이 가능한 컴포넌트들로, 대용량 데이터를 처리하기 위한 MPP(Massively Parallel Processing)를 지원

- Batch(일괄) ETL, Real Time(실시간) ETL로 구분됨

ETL의 기능

Extraction(추출) : 하나 또는 그 이상의 데이터 원천(Source)들로부터 데이터 획득

Transformation(변형) : 데이터 클렌징, 형식변환, 표준화, 통합 또는 다수 애플리케이션에 내장된 비지니스 룰 적용 등

Load(적재) : 변형 단계의 처리가 완료된 데이터를 특정 목표 시스템에 적재

ETL의 작업 단계

0. Interface : 데이터 원천(Source)으로부터 데이터를 획득하기 위한 인터페이스 메커니즘 구현

1. Staging : 획득된 데이터를 스테이징 테이블에 저장

2. Profiling : 스테이징 테이블에서 데이터 특성을 식별하고 품질을 측정

3. Cleansing : 다양한 규칙들을 활용해 프로파일링된 데이터의 보정 작업을 수행

4. Integration : 데이터 충돌을 해소하고, 클렌징된 데이터를 통합

5. Denormalizing : 운영 보고서 생성 및 데이터 웨어하우스 또는 데이터 마트에 대한 데이터 적재를 위해 데이터 비정규화 수행

ODS(Operational Data Store):

- 데이터에 대한 추가 작업을 위해 다양한 데이터 원천(Source)들로부터 데이터를 추출, 통합한 데이터베이스

- 일반적으로 실시간(Real Time) 또는 실시간 근접(Near Real Time) 트랜잭션 데이터 혹은 가격 등의 원자성(개별성)을 지닌 하위 수준 데이터들을 저장하기 위해 설계됨

ODS 구성 단계

1) 인터페이스 단계

: 데이터 획득하는 단계, 실시간 데이터 복제 인터페이스 기술들이 함께 활용됨

- OLAP(Online Analytical Processing) : 데이터웨어하우스 상의 데이터에 대해 다양한 방식으로 다차원 분석을 진행하는것

2) 데이터 스테이징 단계

: 데이터 원천들로부터 트랜잭션 데이터들이 추출되어 하나 또는 그 이상의 스테이징 테이블들에 저장되는 단계

: 이 테이블들은 정규화가 배제되며, 테이블의 스키마는 데이터 원천의 구조에 의존적

: 데이터 원천과 스테이징 테이블과의 데이터 매핑은 일대일 또는 일대다로 구성됨

: 데이터가 스테이징 테이블에 적재되는 시점에 적재 타임스탬프, 데이터 값에 대한 체크 섬 등의 통제(Control) 정보들이 추가됨

: 이때 일괄(Batch) 작업 형태인 정기적인 ETL과 실시간 ETL을 혼용할 수 있음

3) 데이터 프로파일링 단계

: 데이터 품질 점검

4) 데이터 클렌징 단계

: 오류 데이터들을 수정

5) 데이터 인티그레이션 단계

: 수정 완료한 데이터를 ODS 내의 단일 통합 테이블에 적재

6) 익스포트 단계

데이터 웨어하우스

: ODS를 통해 정제 및 통합된 데이터가 데이터 분석과 보고서 생성을 위해 적재되는 데이터 저장소

데이터 웨어하우스의 특징

- 주제 중심성(Subject Oriented) : 데이터의 웨어하우스의 데이터는 실 업무 상황의 특정 이벤트나 업무 항목을 기준으로 구조화되므로, 최종사용자(end user)도 이해하기 쉬운 형태를 지님

- 영속성, 비휘발성(Non Volatile) : 데이터 웨어하우스의 데이터는 최초 저장 이후에는 읽기 전용(Read Only)의 속성을 가지며, 삭제되지 않음

- 통합성(Integrated) : 기관, 조직이 보유한 대부분의 운영 시스템들에 의해 생성된 데이터들의 통합본

- 시계열성(Time Variant) : 운영 시스템들은 최신 데이터를 보유하고 있지만, 데이터 웨어하우스는 시간 순에 의한 이력 데이터를 보유

데이터 웨어하우스의 테이블 모델링 기법

- 스타스키마

: 조인스키마라고도 하며, 데이터 웨어하우스의 스키마 중 가장 단순함

: 단일 사실 테이블을 중심으로 한 다수의 차원 테이블들로 구성됨

: 스타 스키마의 사실 테이블은 보통 제 3정규형으로 모델링하며, 차원테이블들은 보통 비정규화된 제 2정규형으로 모델링하는 것이 일반적

장점 : 복잡도가 낮아 이해하기 쉽고, 쿼리 작성이 용이하고 조인 테이블 개수가 적음

단점 : 차원 테이블에 대한 비정규화에 따른 데이터 중복으로 인해 테이블을 적재할 때 상대적으로 많은 시간이 소요됨

- 스노우 플레이크 스키마

: 스타 스키마의 차원 테이블을 제 3정규형으로 정규화한 형태

장점 : 데이터의 중복이 제거돼 데이터 적재 시 시간 단축

단점 : 스타 스키마에 비해 스키마 구조의 복잡성이 증가하므로 조인 테이블의 개수가 증가하고 쿼리 작성의 난이도 상승

ODS와 DW의 비교

ODS

- 데이터의 내용 : 현재 또는 비교적 최신 데이터

- 데이터의 양 : 비교적 소규모 데이터

- 데이터의 갱신 : 지속적으로 갱신되어 현재의 DB 상태를 반영(Volatile)

- 기술적 요소 : 데이터베이스 처리의 모든 기능을 사용하도록 설계됨

DW

- 데이터의 내용 : 오래된 상세 데이터, 현재 상세 데이터, 요약 데이터, 2차로 가공된 고도로 요약된 데이터 등 다양한 구조의 데이터

- 데이터의 양 : 대규모 데이터

- 데이터의 갱신 : 데이터 축적 보관(Non-Volatile)

- 기술적 요소 : 단순한 적재(Load)와 접근(Access) 중심