제1장 데이터 처리 프로세스

과목 2  데이터 처리 기술 이해 

과목 소개

: 

1장에서는 데이터 처리 프로세스 과정을 관계형 데이터베이스와 같은 정형 데이터와 같은 비졍형 데이터 측면에서 설명한다.

 원천데이터에서 분석에 필요한 데이터를 추출하는 방법, 의미 있는 정보를 만드는 방법들을 설명한다. 

2장에서는 데이터 처리를 위한 분산 파일 스토리지 같은 저장 기술과 하둡과 같은 분산 병렬 처리 기술, 그리고 이러한 플랫폼들을 구동할 수 있는 클라우드 컴퓨팅 인프라 기술에 대해서 설명한다.

목차 

제1장 데이터 처리 프로세스

제1절 ETL(Extraction, Transformation and Load)

제2절 CDC(Change Data Capture)

제3절 EAI(Enterprise Application Integration)

제4절 데이터 연계 및 통합 기법 요약

제5절 대용량 비정형 데이터 처리

제2장 데이터 처리 기술

제1절 분산 데이터 저장 기술

제2절 분산 컴퓨팅 기술

제3절 클라우드 인프라 기술

제1장

데이터 처리 프로세스

장 소개

조직 내 정형 데이터 연계 및 통합을 위한 기술인 ETL, CDC, EAI를 살펴 본 뒤, 빅데이터와의 비교분석을 통하여 그 개요를 파악한다. 이어 최근 그 중요성이 크게 부각되고 있는 대용량 비정형 데이터 처리에 대하여 살펴봄으로써 타 산업과의 융합을 지향하는 최근 IT 동향 내에서의 비정형 데이터 관리의 중요성에 대하여 이해한다.

제1절 ETL(Extraction, Transformation and Load)

1. ETL 개요

ETL은 데이터 이동과 변환 절차와 관련된 업계 표준 용어다.

데이터 웨어하우스, 운영 데이터 스토어, 데이터  마트에 대한 데이터 적재 작업의 핵심 구성요소로서, 데이터 통합, 데이터 이동, 마스터 데이터 관리에 걸쳐 폭넓게 활용된다.

ETL은 데이터 이동과 변환을 주 목적으로 하며, 다음의 3가지 기능으로 구성된다.

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

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

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

* MPP (Massive Parallel Processing) : ETL 작업 단계에서는 정책 기반의 정기적인 실행 일정을 조정할 수 있는 재사용 가능한 컴포넌트들로 대용량 데이터를 처리하기 위한 것.

ETL 구현을 위한 여러 상용 소프트웨어 : 일괄(Batch) ETL , 실시간 (Real Time) ETL로 구분

step 0 interface : 다양한 이기종 DBMS 및 스프레드시트 등 데이터 원천으로부터 데이터를 획득하기 위한 인터페이스 메커니즘 구현

step 1 Staging ETL  : 수립된 일정에 따라 데이터 원천(Source)로부터 트랜잭션 데이터 획득 작업 수행 후, 획득된 데이터를 스테이징 테이블에 저장

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

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

step 4 Integration ETL : (이름, 값, 구조) 데이터 충돌을 해소하고, 클렌징 된 데이터를 통합

step 5 Demoralizing ETL : 운영 보고서 생성, 데이터 웨어하우스 또는 데이터 마트 데이터 적재를 위해 데이터 비정규화 수행 (참고 : http://l2j.co.kr/986)

2. ODS 구성

ODS(Operational Data Store)는 데이터에 추가 작업을 위해 다양한 데이터 원천(Source)들로부터의 데이터를 추출 통합한 데이터베이스이다. ODS 내의 데이터는 향후 비지니스 지원을 위해 타 정보 시스템으로 이관되거나, 다양한 보고서 생성을 위해 데이터 웨어하우스로 이관된다.

다양한 원천들로부터 데이터가 구성되기 때문에, ODS를 위한 데이터 통합은 일반적으로 데이터 클렌징, 중복제거, 비지니스 룰 대비 데이터 무결성 점검 등의 작업들을 포함한다. ODS는 일반적으로 실시간 (Real Time) 또는 실시간 근접(Near Real Time) 트랜잭션  또는 가격 등 원자성(개별성)을 지닌 하위 수준 데이터들을 저장하기 위해 설계된다.

ODS 구성을 위한 일괄 작업 ETL은 다음과 같은 단계로 이루어 진다.

 가. 인터페이스 단계

다양한 데이터 원천으로부터 데이터를 획득하는 단계다. 데이터 원천은 관계형 데이터베이스, 스프레드시트, 플랫 파일, 웹 서비스, 웹 사이트, XML 문서 또는 트랜잭션 데이터를 저장하고 있는 모든 알려진 데이터 저장소(Repository) 등이다. 

데이터 원천들로부터 데이터를 획득하기 위한 프로토콜 : 

OLEDB(Object Linking and Embedding Database)

ODBC(Object Data Base Connectivity)

FTP(File Transfer Protocol) 등과 더불어, 데이터 웨어하우스에 대한 실시간 도는 근접 실시간 OLAP 질의를 지원하기 위해 실시간 데이터 복제 인터페이스 기술들이 함께 활용 된다.

 나. 데이터 스테이징 단계

이 단계에서는 작업 일정이 통제되는 프로세스들에 의해 데이터 원천들로부터 트랜잭션 데이터들이 추출되어 하나 또는 그 이상의 스테이징 테이블들에 저장된다. 

 * 트랜잭션이란? http://121202.tistory.com/17

이 테이블들은 정규화가 배제되며, 테이블 스키마는 데이터 원천의 구조에 의존적이다. 데이터 원천과 스테이징 테이블과의 데이터 매핑은 일대일 또는 일대다로 구성될 수 있다.

데이텉가 슽에이징 테이블에 적재되는 시점에 적재 타임스탬프, 데이터 값에 대한 체크 섬 등 통제(Control) 정보들이 추가되며, 체크 섬 정보는 신규 데이터 항목의 추가 여부에 따른 데이터 추가 적재 필요성 판단 등에 활용된다.

다양한 이기종 데이터 저장소 원천으로부터 데이터를 획득해 스테이징 테이블에 적재하며, 이때 일괄 작업 형태의 정기적인 ETL과 실시간 데이터 획득 방식을 혼용해 구성할 수 있다.

 다. 데이터 프로파일링 단계

이 단계에서는 범위 도메인 유일성 확보 등의 규칙을 기준으로 다음과 같은 절차에 따라 데이터 품질 점검을 한다.

선행 자료 또는 조건 : 데이터 프로파일링 요건

Step 1 : 데이터 프로파일링 수행

Step 2 : 데이터 프로파일링 결과 통계 처리

Step 3 : 데이터 품질 보고서 생성 및 공유

 라. 데이터 클렌징 단계

이 단계에서는 클렌징 ETL 프로세스들로 앞 데이터 프로파일링 단계에서 식별된 오류 데이터들을 다음 절차에 따라 수정한다.

선행 자료 또는 조건 : 데이터 품질 보고서, 데이터 클렌징 요건

Step 1 : 클렌징 스토어드 프로시져 실행 (예비 작업)

Step 2: : 클렌징 ETL 도구 실행

 마. 데이터 인티크레이션 단계

이 단계에서는 앞 단계에서 수정 완료한 데이터를 ODS 내의 단일 통합 테이블에 적재하며, 다음의 단계를 거친다.

선행 자료 또는 조건 : 데이터 클렌징 테이블, 데이터 충돌  판단 요건

Step 1: 통합 스토어드 프로시저 실행 ( 예비 작업)

Step 2: 통합 ETL 도구 실행

 바. 익스포트 단계

 앞 단계에서 통합된 데이터를 익스포트 규칙과 보안 규칙을 반영한 익스포트 ETL 기능을 수행해 익스포트 테이블을 생성한 후, 다양한 전용 DBMS 클라이언트 또는 데이터 마트, 데이터 웨어하우스에 적재한다. 해당 데이터는 OLAP 비정형 질의에 활용될 수 있다.

 3. 데이터 웨어하우스

ODS를 통해 정제 및 통합된 데이터는 데이터 분석과 보고서 생성을 위해 데이터 웨어하우스에 적재되며, 데이터 웨어하우스는 다음의 특징들을 가진다.

주제중심 : 데이터 웨어하우스의 데이터는 실 업무 상황의 특정 이벤트나 업무 항목을 기준으로 구조화 된다.

영속성 : 데이터 웨어하우스의 데이터는 최초 저장 이후에는 읽기 전용 속성을 가지며 삭제되지 않는다.

통합성 : 데이터 웨어하우스의 데이터는 기관 조직이 보유한 대부분의 운영 시스템들에 의해 생성된 데이터들의 통합본이다.

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

   데이터 웨어하우스의 테이블들은 스타 스키마 또는 스노우 플레이크 스키마로 모델링 된다.

가. 스타 스키마

 조인 스키마라고도 하며, 데이터 웨어하우스 스키마 중 가장 단순하다. 단일 사실 테이블을 중심으로 다수의 차원 테이블들로 구성된다.

 스타 스키마를 활용할 때는 전통적인 관계형 데이터베이스를 통해 다차원 데이터베이스 기능을 구현할 수 있다.

 스타 스키마는 이해하기 쉬운 것이 장점이다. 스타 스키마의 사실 테이블은 보통 제3정규형으로 모델링하며, 차원 테이블들은 보통 비정규화된 제2정규형으로 모델링하는 것이 일반적이다. 차원 테이블을 정규화하는 것을 스노우 플레이크 스키마라고 한다.

스타 스키마는 스노우 플레이크 스키마에 비해 복잡도가 낮아서 이해하기 쉽고, 쿼리 작성이 용이하고 조인 테이블 개수가 적은 장점을 갖고 있다.

반면 스타 스키마는 차원 테이블들의 비정규화에 따른 데이터 중복으로 해당 테이블에의 데이터 적재 시 상대적으로 많은 시간이 소요된다는 단점이 있다.

나. 스노우 플레이크 스키마

스타 스키마의 차원테이블을 제3정규형으로 정규화한 형태로, 데이터 중복이 제거돼 데이터 적재 시 시간이 단축되는 장점이 있다. 하지만 스키마 구조의 복잡성 증가에 따른 조인 테이블 개수 증가와 쿼리작성 난이도 상승이라는 단점이 있다.

제2절 CDC(Change Data Capture)

1. CDC 개요

CDC(Change Data Capture)는 데이터베이스 내 데이터에 대한 변경을 식별해 필요한 후속 처리(데이터 전송/공유 등)를 자동화하는 기술 또는 설계 기법이자 구조다. CDC는 실시간 또는 근접 실시간 데이터 통합을 기반으로 하는 데이터 웨어하우스 및 기타 데이터 저장소 구축에 폭 넓게 활용된다.

CDC는 스토리지 하드웨어 계층에서부터 애플리케이션 계층에 이르기까지 다양한 계층에서 다양한 기술을 통해 구현될 수 있다.단일 정보 시스템 내 다수의 CDC 메커니즘이 구현돼 동작 될 수 있다. CDC 구현기법들을 살펴보면 다음과 같다.

가. Time Stamp on Rows

변경이 반드시 인지되어야 하는 테이블 내 마지막 변경 시점을 기록하는 타임스탬프 컬럼을 두고, 마지막 변경 타임스탬프 값보다 더 최근의 타임스탬프 값을 갖는 레코드를 변경되는 것으로 식별한다. 

나. Version Numbers on Rows

변경이 반드시 인지되어야 하는 테이블 내 해당 레코드의 버전을 기록하는 컬럼을 두고, 기 식별된 레코드 버전보다 더 높은 버전을 보유한 레코드를 변경된 것으로 식별한다. 레코드들의 최

신 버전을 기록 관리하는 '참조 테이블'을 함께 운용하는 것이 일반적이다.

다. Status on Rows

타임 스탬프 및 버전 넘버 기법에 대한 보완 용도로 활용되며, 변경 여부를 True/Flase 불린 값으로 저장하는 컬럼의 상태 값을 기반으로 변경 여부를 판단한다. 더 높은 버전 넘버 또는 더 최근의 갱신 타임스탬프를 보유한 레코드에 대한 변경 여부 판단을 사람이 직접 결정할 수 있도록 유보하는 등의 업무 규칙을 적용할 수 있다.

라. Time/ Version/ Status on Rows

세 가지 특성을 모두 활용하는 기법으로, '특정 시간 대의 버전 넘버 x.xx를 보유했으며 변경 상태 값이 True인 모든 레코드를 추출'하는 등 정교환 쿼리 생성에 활용해 개발 유연성을 제공할 수 있다.

마. Triggers on Tables

 데이터베이스 트리거를 활용해 사전에 등록된 다수 대상 시스템에 변경 데이터를 배포하는 형태로 CDC를 구현하는 기법이다. 단 데이터베이스 트리거는 시스템 관리 복잡도를 증가시키며 변경 관리를 어렵게 하며 확장성을 감소시키는 등 전반적 시스템 유지보수성을 저하시키는 특성이 있어 사용에 주의를 요한다.

바. Event programming

 데이터 변경 식별 기능을 어플리케이션에 구현하며, 어플리케이션 개발 부담과 복잡도를 증가시키나, 다양한 조건에 의한 CDC 매커니즘을 구현할 수 있는 기법이다.

사. Log Scanner on Database

 대부분의 데이터베이스 관리 시스템(DBMS)은 데이터베이스의 데이터에 대한 변경 여부와 변경 값 시간등을 트랜잭션 로그를 기록 관리하는 기능을 제공한다. 이 트랜잭션 로그에 대한 스캐닝 및 변경 내역에 대한 해석을 통해 CDC 매커니즘을 구현한다. 그런데 각  데이터베이스 관리 시스템에 따라 트랜잭션 로그 관리 매커니즘이 상이해 다수의 이기종 데이터베이스를 사용하는 환경에서 적용 시 작업 규모가 증가 할 수 있으니 주의가 필요하다.

이 기법은 다음과 같은 장점을 갖는다.

 - 데이터베이스에 대한 영향도 최소화

 - 데이터베이스 사용 애플리케이션에 대한 영향도 최소화

 - 변경 식별 지연시간 최소화

 - 트랜잭션 무결성에 대한 영향도 최소화

 - 데이터베이스 스키마 변경 불필요

CDC 구현 시 데이터 원천에서 변경을 식별하고 대상 시스템에 변경 데이터를 적재해 주는 '푸시' 방식과 대상 시스템에서 데이터 원천을 정기적으로 살펴보다 필요 시 데이터를 다운로드 하는 '풀' 방식으로 구분된다.

제3절 EAI(Enterprise Application Integraion)

1.EAI개요

EAI(Enterprise Appliacion Integration)는 기업 정보 시스템들의 데이터를 연계 통합하는 소프트웨어 및 정보 시스템 아키텍처 프레임워크로서, 기업 또는 기업 간 복수의 이질적 정보 시스템들의 데이터를 연계함으로써 상호 융화 내지 동기화돼 동작하도록 한다. 즉 EAI는 프론트 오피스 시스템, 기존의 레가시 시스템, 패키지 애플리케이션 등의 형태로 산재된 정보 시스템들을 프로세스 및 메시지 차원에서 통합 관리 할 수 있게 한다.

EAI를 통해 다수의 정보 시스템에게 기업 내 주요한 데이터 엔터티들에 대한 폭넓고 통합적인 뷰를 제공할 수 있다. 이를 통해 비지니스 프로세스를 자동화하고 실시간으로 통합 연계할 수 있다.

기존 단위 업무 위주의 정보 시스템 개발 시, 그때 그때의 필요에 따라 정보 시스템들 간 포인트 투 포인트 방식으로 데이터를 연계함으로써 데이터 연계의 복잡성이 발생한다. 이러한 방식은 정보 시스템 간 데이터 통합과 연계를 확보하기 어렵게 하고, 기준 마스터 데이터의 통합과 표준화를 불가능 하게 한다. 또한 방대하고 복잡한 데이터 연계 경로를 발생시키기 때문에 유지보수성이 극도로 저하된다. 이는 유지보수 및 관리 비용의 상승으로 연결된다.

투 포인트 방식으로 정보 시스템을 개발하고 데이터 연계 시, N개의 연결 대상노드들이 존재할 경우 연결은 N(N-1)/2개가 발생한다. 이러한 특성으로 발생하는 복잡성과 유지보수 비용증가를 극복하기 위해 'Hub and Spoke' 방식의 EAI 기반 구조를 적용할 수 있다. 즉 가운데 지점에 허브 역할을 하는 브로커를 두고, 연결 대상 노드들의 데이터 연계 요구를 중계해줌으로써 발생 연결 개수 및 구조를 단순화 할 수 있다. 각 연결 대상 노드들은 스포크에 해당한다.

EAI 구성 요소로서 각 정보 시스템과 EAI 허브(Engine) 간 연결성을 확보하기 위한 어댑터 들이 있다. 이 어댑터들을 매개로 연결된 각 정보 시스템들 간의 데이터 연동 경로인 버스, 데이터 연동 규칙을 통제하는 브로커, 데이터 형식 변환등을 당담하는 트랜스포머가 있다.

2.EAI 구현 유형

가. Mediation ( intra-communication)

EAI 엔진이 중개자(Broker)로 동작하며, 특정 정보 시스템 내 데이터 신규 생성 또는 갱신 신규 트랜잭션 완료(Commit) 등 유의미한 이벤트 발생을 식별해, 사전 약속된 정보 시스템들에게 그 내용을 전달한다. 

나. Federation(inter-communication)

EAI 엔진이 외부(고객 또는 파트너) 정보 시스템으로부터의 데이터 요청들을 일괄적으로 수령해 필요한 데이터를 전달한다. Request/reply Model

3. EAI 기대효과

EAI를 활용함으로써 아래와 같은 효과를 거둘 수 있다.

향후 정보 시스템 개발 및 유지 보수비용 절감 도모

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

협력사 파트너 고객과의 상호 협력 프로세스 연계 발전 기반 확보

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

또한 본사와 공장이 별도의 정보 시스템을 보유한 상태에서 글로벌하게 지역적으로 분리돼 있고 해당 정보 시스템들 간 데이터 동기화가 필요한 경우나, 그룹 및 지주 회사 계열사들 가 ㄴ상호 관련 데이터 동기화가 필요한 경우 등 글로벌 경영 환경에 상응하는 데이터 표준화 기반을 제공할 수 있다.

제4절 데이터 연계 및 통합 기법 요약

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

 데이터 연계 및 통합 시 일괄 작업 또는 비동기식 근접 실시간 또는 동기식 실시간 방식이 혼용 사용 될 수 있다. 일괄 작업 시에는 대용량 데이터의 처리가 가능하며, 실시간 통합 시에는 관심 대상 영역 상태에 대한 빠른 파악 및 대응이 가능하다는 장점이 있다.

 일괄 작업의 사례로는 ETL 기능을 통해 운영 시스템으로부터 정기적 반복적으로 대량의 데이터를 획득해 ODS를 구성하고, 이후 데이터 웨어하우스나 데이터 마트를 구성한 뒤 OLAP 정형/비정형 질의를 통해 경영 분석을 수행하는 작업을 들 수 있다.

 동기식 실시간 데이터 통합의 사례로는 컨테이너 터미널, 공장 등의 생산 운송 장비에 설치된 각종 센서들로부터 데이터ㄹㄹ 실시간으로 획득해 운영 상태를 모니터링하고 필요한 경우 작업을 통제하는 사례를 들 수 있다. 이는 Complex Event Processing이라는 SW 및 데이터 아키텍처를 통해 구현할 수 있다. 요즘 들어 데이터 중복을 허용하는 분산 저장 환경 구성을 통한 높은 확장성을 확보하는 빅데이터 저장 인프라스트럭처의 활용과 병행 설계되는 사례도 등장하고 있다.

전통적인 ETL 기술은 데이터 웨어하우스 구성만을 주 목적으로 했으나, 최근 들어 ODS와 BI 플랫폼, MDM 허브, 하둡 클라우드 환경 등 다양한 데이터 통합 메커니즘들을 지원하는 것으로 그 영역을 확장하고 있다. 특별히 최근의 ETL 솔루션들은 빅데이터 환경과 전통적 데이터 환경(RDBMS 기반) 간 빅데이터 추출 변형 적재를 지원하고 있다. 

최근 기업 의사 결정 지원을 위해 전자메일, 각종 문서 파일 등에 보관되는 비정형 또는 준정형 데이터의 중요성이 부각 되고 있다. 비정형 또는 준정형 데이터를 정형 데이터로의 변환은 빅데이터의 주요한 기술적 특성이다. Map Reduce 등 빅데이터 기술을 황용하지 않을 경우, 정형 데이터로 변환하기 위한 많은 추가 개발이 요청된다. 특히 빅데이터 기술을 이용하지 않고 정형데이터로 변환하는 접근은 향후 시스템 확장성과 유연성을 확보하기 어렵게 하고, 기업 IT 투자를 중장기적으로 보호할 수 없게 된다. 따라서 기존 ETL 솔루션들도 이에 대응하기 위해 비정형 또는 준정형 데이터의 정형 데이터로의 변형 작업을 표준화 하기 위한 시도들을 하고 있다.

제5절 대용량 비정형 데이터 처리

1. 대용량 로그 데이터 수집

비정형 데이터의 폭발적 증가는 오늘날 빅데이터라는 새로운 기술 트렌드와 산업 영역을 만들어 냈다. 이 중에서 로그(log)는 기업에서 발생하는 대표적인 비정형 데이터다. 과거에는 시스템의 문제 상황을 보존, 서비스 접근, 사용 로그를 기록하는 용도로 사용됐다. 최근에는 사용자 행태 분석 등 기업의 주요 비즈니스 영역인 마케팅과 영업 전략 등에 필수적인 정보를 생성하는 데에 사용되고 있다. 이러한 비정형 로그는 데이터 용량이 방대하기 때문에 이를 분석하기 위해서는 성능과 확장성의 시스템이 필요하다.

대용량 비정형 데이터 수집 시스템은 다음과 같은 특징을 갖는다.

가. 초고속 수집 성능과 확장성

 수많은 서비스와 시스템에서 실시간으로 발생하는 대용량 데이터를 놓치지 않고 수집할 수 있어야 한다. 또한 수집 대상 서버가 증가하면, 증가한 서버 수만큼 에이전트의 수를 늘리는 방식으로 손쉽게 확장할 수 있는 구조를 갖는다.

나. 데이터 전송 보장 메커니즘

 수집한 데이터는 처리 또는 분석을 위한 저장소인 분산 파일시스템이나, 데이터베이스, NoSQL 등에 저장된다. 이때 데이터의 종류에 따라 수집에서 저장소까지의 양 종단점 간에 데이터 전송 안정성 수준을 제어할 수 있다. 수집된 데이터가 여러 단계를 거쳐 저장소에 도착할 수 있는데, 단계별로 전송될 때마다 신호를 주고 받아서 단 하나의 이벤트도 유실되지 않게 할 수 있다. 또한 여러 단계의 데이터 전송에서 단지 인접한 단계로만 데이터 전송을 보장하는 방버도 있다. 각 방식은 성능과 안정성이라는 트레이드 오프가 존재하므로 비지니스의 특성을 고려해 선택해야 한다.

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

 비정형 데이터는 기업 내부에서 발생하는 로그나 성능 모니터링 데이터뿐만 아니라, 트위터와 같은 소셜서비스의 데이터도 있다. 로그나 성능 데이터를 수집할 수 있는 기본 기능뿐만 아니라, 일부 잘 알려진 서비스로부터 몇 가지 설정만으로 데이터를 수집할 수 있도록 내장 플러그인을 제공해야 한다. 데이터 저장소 서비스도 하둡 저장 기능은 기본이며, NoSQL을 포함한 다양한 데이터베이스에 저장하는 플러그인들까지 제공하는 추세다.

라. 인터페이스 상속을 통한 애플리케이션 기능 확장

서비스에 적용하는 과정에서 수집 시스템에서 제공하는 기능을 사용하지만, 업무 특성상 일부 기능을 수정해야 하는 경우가 발생할 수 있다. 이때 인터페이스를 확장해 원하는 부분만 비지니스 용도에 맞게 수정할 수 있어야 한다.

대표적인 오픈소스 데이터 수집 시스템인 Flume-NG를 살펴보자. 플럼은 앞서 언급한 비정형 데이터의 주요 특징을 포함하고 있으며, 빅데이터 플랫폼을 구축할 때 수집 시스템으로 많이 활용되고 있다.

4단계에 걸쳐 플럼을 이용해 데이터를 수집, 저장할 수 있다. 첫 번째는 데이터가 발생하는 애플리케이션 단계, 두 번째는 발생한 데이터를 수집하는 단계, 세 번째는 수집한 데이터를 저장하는 단계며, 네 번째는 데이터 저장소 보관이다. 특별히 설정하지 않으면 네 번째 단계에서 사용되는 저장소는 분산 파일 시스템인 하둡이다. 각 플럼 에이전트는 설정을 통해 각 단계에 맞게 동작한다.

2. 대규모 분산 병렬 처리

처리할 비정형 데이터의 크기가 수백 MB 정도라면, 다소 시간이 걸리더라도 한 대의 서버에서 처리한 다음에 데이터베이스에 요약 정보를 기록하거나, 데이터베이스에 원천 비정형 데이터를 직접 적재 처리할 수 있을 것이다. 

하지만 한 번에 처리해야 할 원천 데이터가 수십 GB에서 수십 TB에 이른다고나 대규모 컴퓨팅과 연산 작업이 필요하다면 하둡을 사용하는 것을 적극적으로 검토해야 한다.

하둡은 대규모 분산 병렬 처리의 업계 표준인 맵리듀스(MapReduce) 시스템과 분산 파일시스템인 HDFS로 구성된 플랫폼 기술이며, 다음과 같은 특징을 갖는다.

가. 선형적인 성능과 용량 확장

하둡을 구축함은 여러 대의 서버로 클러스터를 만든다는 의미다. 이론적으로 클러스터의 서버의 대수에 제한이 있는 것은 아니지만 통상적으로 5대 정도가 최소 클러스터 대수라고 할 수 있다. 하둡은 필요 시 서버를 추가하면 연산 기능과 저장 기능이 서버의 대수에 비례해 증가한다.

이는 하둡이 기본적으로 비공유 분산 아키텍처 시스템이기 때문이다. 하둡 이전의 분산 컴퓨팅 시스템의 최대 클러스터링 대수가 100대였던 반면, 하둡은 2만 대의 서버들을 단일 클러스터로 구성할 수 있을 정도로 확장성이 뛰어나며, 선형적인 성능확장도 가능하다.

나. 고장 감내성

데이터는 3중 복제가 돼 서로 다른 물리서버에 저장된다. 따라서 특정 서버에서 장애가 발생하더라도 동일 복제본이 있기에 데이터 유실을 방지할 수 있다. 또는 맵리듀스 작업을 수행하다가 특정 태스크에서 장애가 생기면, 시스템이 자동으로 감지해 장애가 발생한 특정 태스크만 다른 서버에서 재실해을 할 수 있다. 이러한 고장 감내 기능(Fault Tolerance)은 관리자의 개입 없이 시스템 수준에서 자동으로 동작한다.

다. 핵심 비지니스 로직에 집중

맵리듀스는 기본적으로 맵과 리듀스라는 2개의 함수만 구현하면서 동작하는 시스템이다. 알고리즘이나 비지니스 로직 개발자는 맵리듀스라는 데ㅣ터 처리 분석 방식만 이해하고 비지니스 목적에 맞게 간단한 코드만 작성해주면, 데이터가 크고 작음에 크게 신경쓰지 않아도 된다. 작업을 수행하는 중간에 어떠한 시스템적인 장애 상황이 발생하더라도 자동 복구(Failover) 기능이 있기 때문에, 개발자가 크게 걱정하지 않아도 된다. 오직 비지니스 로직에만 집중할 수 있도록, 시스템 수준에서 발생하는 장애 상황이나 확장성, 성능 등의 이슈는 하둡이 내부적으로 최적화해 처리한다.

라. 풍부한 에코시스템 형성

하둡의 맵리듀스와 분산 파일 시스템은 빅데이터 처리와 분석을 위한 기반 시스템 기술이라고 할 수 있다. 비지니스의 요구 사항을 위해서는 필연적으로 하둡 같은 인프라 시스템에서 동작하는 다양한 응용 기술이 있다. 데이터 수집 기술로는 Flume-NG, 데이터 연동 기술로는 Sqoop, 데이터베이스 기술인 NoSQL로는 HBase, 대용량 SQL 질의 기술로 Hive와 Pig, 실시간 SQL 질의 기술로 Impala와 Tajo, 워크플로 관리기술로 Oozie, Azkaban 등이 있다. 하둡에서 제공하는 대규모 분산 병렬 처리 기술인 맵리듀스는 구글이 처음 고안해 상용화한 기술이다. 외부에 공개하지 않고 구글 내부적으로만 사용하다가 2005년에 오픈소스 프로젝트로 공개한 것이 지금의 하둡이다. 맵리듀스는 당시 업계에서 사용했던 분산 병렬 처리 모델의 알고리즘 로직 개발의 복잡성을 획기적으로 줄였다. 그래서 일부 연구 영역에서만 사용됐던 부산 병렬 처리 기술이 다양한 분야에서 적윽 사용되는 계기가 됏다.

3. 데이터 연동

비정형 데이터를 가지고 데이터 분석을 하려면 기업 내의 축적된 데이터와 정보를 연동하는 것이필요하다. 예를 들면 인구 통계학 정보를 기반으로 분석을 한다면, 기간 계 시스템에 저장 된 사용자 프로파일 정보와 비정형 데이터를 연계하여 분석을 해야 한다. 하지만 기간 계 시스템인 데이터 베이스를 대상으로 맵리듀스와 같은 대규모 분산 병렬 처리를 하는 것은 심한 부하를 야기할 수 있다. 이러한 이유로 정형 데이터와 비정형 데이터간의 연계 분석을 위해서, 데이터 베이스의 데이터를 하둡으로 복사를 한 후 대규모 분산 병렬 처리를 수행한다. 그 결과로 생성된 요약된 작은 데이터 셋을 다시 데이터베이스에 기록을 하는 식으로 작업을 수행한다. 이러한 기능을 수행하는 대표적인 오픈 소스 기반의 솔루션으로 스쿱(SQOOP)이 있다.

하둡과 데이터베이스 연동 솔루션인 스쿱은 오라클, MySQL, PostgreSQL, 사이베이스 등 JDBC를 지원하는 대부분의 관계형 데이터베이스와의 연동을 지원한다. 또한 에이치베이스(HBase)와 같은 일부 NoSQL데이터베이스와도 연동이 된다.

스쿱을 이용해서 데이터베이스로부터 하둡으로 데이터를 전송하는 스크립트는 다음과 같다.

 -데이터를 가져올 데이터베이스 접속 정보를 입력한다.

 -가져올 데이터에 대한 SQL을 입력한다.

 -동시에 몇 개의 프로세스를 실행하여 데이터를 가져올지를 지정한다. 프로세스를 많이 지정하면 더 빨리 데이터를 가져오겠지만, 그만큼 데이터에는 부하가 많이 발생할 수 있으니 적절한 개수를 지정해야 한다.

 -데이터베이스의 키 칼럼을 입력한다.

 -데이터베이스로부터 가져온 데이터를 저장할 하둡상의 경로를 지정한다.

스쿱 스크립트를 실행하여 하둡에 저장된 데이터베이스 데이터를 다른 비정형 데이터와 함께 맵리듀스 작업을 입력데이터로 사용할 수 있다. 하둡 결과 데이터도 마찬가지로 비슷한 스크립트 문법을 이용하여 다시 데이터베이스에 적재할 수 있다.

4. 대용량 질의 기술

하둡은 저비용으로 대용량 데이터를 저장하고 빠르게 처리할 수 있는 시스템이며 빅데이터 구현을 위한 핵심적인 플랫폼 기술로 사용되고 있다. 하지만 이전에 비해 훨씬 단순해졌지만 여전히 코딩이 필요하기 때문에 분석가에게는 어려울 수 있다. 이러한 이유로 나온 것이 하이브(Hive)이다. 하이브는 사용자에게 친숙한 SQL이라는 질의 기술을 이용하여 하둡상의 저장된 데이터를 쉽게 처리하고 분석할 수 있도록 해주는 도구로 널리 사용되고 있다. 이러한 하둡과 하이브는 대용량 데이터를 배치 처리하는데 최적화 되어 있지만, 실제 업무에서는 배치 처리뿐만 아니라, 데이터를 실시간으로 조회하거나 처리해야 하는 일들이 많다. 실시간 처리라는 측면에서 하둡의 제약사항을 극복하기 위한 다양한 시도가 있었으며, 이 중에 최근 주목 받고 있는 것이 SQL on 하둡이라고도 하는 실시간 SQL 질의 분석 기술이다. SQL on 하둡은 빅데이터 기술분야에서 가장 관심을 많이 받고 있는 기술이라고 할 수 있으며 다음과 같은 기술들이 시장에 나온 상태이다.

아파치 드릴 : 하둡 전문 회사인 맵알(MapR)이 주축이 되어 진행하고 있는 프로젝트이다. 드레멜의 아키텍처와 기능을 동일하게 구현한 오픈 소스 버전의 드레멜이다.

아파치 스팅거 : 하둡 전문 회사인 호튼웍스에서 개발을 주도하고 있다. 새로운 엔진이라기 보다는 기존의 하이브 코드를 최대한 이용하여 성능을 개선하는 식으로 개발이 진행되고 있다.

샤크 : 인메모리 기반의 대용량 데이터웨어하우징 시스템이며, 하이브와 호환되기 때문에 하이브 SQL 질의와 사용자 정의 함수를 사용할 수 있다.

아파치 타조 : 고려대 대학원에서 프로젝트가 최초 시작되었으며, 대학원생들은 국내 빅데이터 전문회사인 그루터에 합류하여 개발을 진행하고 있다. 아파치 인큐베이션 프로젝트로 등록되어 있다.

임팔라 : 하둡 전문 회사인 클라우데라에서 개발을 주도하고 있다.

호크 : EMC에서 분사한 하둡 전문 회사인 피보탈에서 개발한 프로젝트로, 상용과 커뮤니티 2가지 버전을 제공한다.

프레스토 : 페이스북에서 자체적으로 개발하여 사용하고 있는 하둡 기반의 데이터웨어하징 엔진이다. 올해 내에 대중에게 공개할 예정이다.

SQL on 하둡 기술 중의 하나이며, 오픈 프로젝트 중에 가장 먼저 대중에게 공개된 임팔라를 살펴보자. 임팔라는 기본적으로 하이브의 SQL을 지원하지만, 모든 SQL문을 지원하는 것은 아니기 때문에 지원되는 구문을 확인하는 것이 필요하다. 임팔라의 주요 구성요소는 다음과 같다.

-클라이언트 : ODBC, JDBC 클라리언트, 임팔라쉘 같이 임팔라에 접속해서 테이블 관리, 데이터 조회 등의 작업을 수행한다.

-메타스토어 : 임팔라로 분석한 대상 데이터들의 정보를 관리하며, 하이브의 메타데이터를 같이 사용한다.

-임팔라 데몬 : 시스템에서는 ImpalaD로 표시되며, 클라이언트의 SQL 질의를 받아서 데이터 파일들의 읽기/쓰기 작업을 수행한다. 임팔라 데몬은 내부적으로 질의 실행계획기, 질의 코디네이터, 질의 실행엔진으로 구성된다.

- 스테이트스토어 임팔라 데몬들의 상태를 체크하고 건강(health)정보를 관리해주는 데몬이다. 임팔라데몬에 장애가 생겼을 경우, 다른 데몬들에게 이 사실을 알려줘서 이후부터는 장애가 발생한 데몬에게는 질의 요청이 가지 않도록 해준다.

- 스토리지: 분석을 할 데이터를 저장하는 현재는 에이치베이스, 하둡분산파일시스템 두 가지를 지원한다.

기본적으로 모든 노드에 임팔라 데몬이 구동되며, 사용자는 이 데몬들이 구동된 임의의 노드에 JDBC나 ODBC또는 임팔라쉘을 이용하여 질의를 요청할 수 있다. 그러면 사용자의 질의는 데이터의 지역성을 고려해서 노드 전체로 분산되어서 수행된다. 하둡에서 잡트랙커(JobTracker)가 데이터 지역성을 고려해서 태스크를 태스크트랙커(TaskTracker)에게 할당하는 것과 유사한 방식이다. 사용자의 질의 요청을 받은 코디네이터 데몬은 분산되어 수행된 각 임팔라 노드들의 부분 결과들을 취합하여 결과 값을 만들어서 사용자에게 제공한다. 실제 운영 환경에서는 라운드로빈 방식으로 사용자 질의를 분산시켜서 질의에 대해 전 노드들이 코디네이터 역할을 고르게 수행할 수 있도록 해야 한다.

하이브가 하둡에 저장된 다양한 형태의 대용량 비정형 데이터를 효율적으로 처리하는 표준 SQL솔루션으로 사용되고 있지만, 더 빠른 처리가 필요한 비지니스 요구 사항 때문에 임팔라와 같은 기술이 대두되고 있다. 이러한 기술은 운영 시스템에 적용하기 위해서는 사용자 함수 지원, 데이터 조인 시 메모리 문제 등 여러 가지로 개선해야 할 사항들이 ㅇ라직 있다. 하지만 중요한 빅데이터 기술 트랜드로 최근에 큰 관심을 받고 있으며, 많은 개발자가 개발과 테스트에 참여하고 있기 대문에 점차적으로 기능과 안정성이 개선 될 것으로 보이며 향후 비정형 빅데이터 처리 및 분석에 중요한 역할을 할 것으로 예상 된다.