[ADP] 2-1 데이터 처리 프로세스

제1절 ETL(Extraction, Transformation and Load)

1. ETL 개요

ETL(Extraction, Transformation and Load)은 데이터 이동과 변환 절차와 관련된 업계 표준 용어임. ETL은 데이터 웨어하우스(DW, Data Warehouse), 운영 데이터 스토어(ODS, Operational Data Store), 데이터 마트(DM, Data Mart)에 대한 데이터 적재 작업의 핵심 구성요소로서, 데이터 통합(Data Integration), 데이터 이동(Data Migration), 마스터 데이터 관리(MDM, Master Data Management)에 걸쳐 폭넓게 활용 됨.

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

• Extraction(추출) : 하나 또는 그 이상의 데이터 원천들로 부터 데이터 획득
• Transformation(변형) : 데이터 클렌징/형식 변환/표준화, 통합 또는 다수 애플리케이션에 내장된 비즈니스 룰 적용 등
• Loading(적재) : 위 변형 단계 처리가 완료된 데이터를 특정 목표 시스템에 적재

ETL 작업 단계에서는 정책 기반의 정기적인 실행 일정을 조정할 수 있는 재사용 가능한 컴포넌트들로 대용량 데이터를 처리하기 위한 MPP(Massive Parallel Processing)를 지원할 수 있음. 또한 다수 시스템들간 대용량 또는 복잡도가 높은 비즈니스 룰 적용이 필요한 데이터 교환에 활용됨.

ETL 구현을 위한 여러 사용 소프트웨어 도구들이 있으며, 일괄(Batch) ETL과 실시간(Real Time) ETL로 구분됨.

• Step 0 interface : 다양한 이기종 DBMS 및 스프레드시트 등 데이터 원천으로부터 데이터를 획득하기 위한 인터페이스 메커니즘 구현
• Step 1 Staging ETL : 수립된 일정에 따라 데이터 원천으로부터 트랜잭션 데이터 획득 작업 수행 후, 획득된 데이터를 스테이징 테이블에 저장
• Step 2 Profiling ETL : 스테이징 테이블에서 데이터 특성을 식별하고 품질을 측정
• Step 3 Cleansing ETL : 다양한 규칙들을 활용해 프로파일린된 데이터 보정 작업
• Step 4 Intergration ETL : (이름, 값, 구조) 데이터 충돌을 해소하고, 클렌징된 데이터를 통합
• Step 5 Demoralizing ETL : 운영 보고서 생성, 데이터 웨어하우스 또는 데이터 마트 데이터 적재를 위해 데이터 비정규화 수행

2. ODS 구성

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

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

가. 인터페이스 단계

다양한 데이터 원천으로부터 데이터를 획득하는 단계. 데이터 원천은 관계형 데이터베이스, 스프레드시트, 플랫 파일, 웹 서비스, XML 문서 또는 트랜잭션 데이터를 저장하고 있는 모든 알려진 데이터 저장소 등. 데이터 원천들로 부터 데이터를 획득하기 위한 프로토콜로는 OLEDB(Object Linking and Embedding Database), ODBC(Object Data Base Connectivity), FTP(File Transfer Protocol) 등과 더불어, 데이터 웨어하우스에 대한 실시간 또는 근접 실시간 OLAP(Online Analytical Processing) 질의를 지원하기 위해 실시간 데이터 복제 인터페이스 기술들이 함께 활용됨.

나. 데이터 스테이징 단계

이 단계에서는 작업 일정이 통제되는 프로세스들에 의해 데이터 원천들로부터 트랜잭션 데이터들이 추출되어 하나 또는 그 이상의 스테이징 테이블들에 저장됨. 이 테이블들은 정규화가 배제되며, 테이블 스키마는 데이터 원천의 구조에 의존적임. 데이터 원천과 스테이징 테이블과의 데이터 매핑은 일대일 또는 일대다로 구성될 수 있음.

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

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

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

• 선행 자료 또는 조건 : 데이터 프로파일링 요건
• Step 1 : (스테이징 테이블 내 데이터에 대한) 데이터 프로파일링 수행
• Step 2 : 데이터 프로파일링 결과 통계 처리
• Step 3 : 데이터 품질 보고서 생성 및 공유

라. 데이터 클렌징 단계

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

• 선행 자료 또는 조건 : 데이터 품질 보고서, 데이터 클렌징 요건
• Step 1 : 클렌징 스토어드 프로시져 실행(예비 작업)
• Step 2 : 클렌징 ETL 도구 실행

마. 데이터 인터그레이션 단계

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

• 선행 자료 또는 조건 : 데이터 클렌징 테이블, 데이터 충돌 판단 요건
• Step 1: 통합 스토어드 프로시저 실행(예비 작업)
• Step 2 : 통합 ETL 도구 실행

바. 익스포트 단계

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

3. 데이터 웨어하우스

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

• 주제 중심(Subject Oriented) : 데이터 웨어하우스의 데이터는 실 업무 상황의 특정 이벤트나 업무 항목을 기준으로 구조화됨.
• 영속성(Non Volatile) : 데이터 웨어하우스 데이터는 최초 저장 이후에는 읽기 전용(Read Only) 속성을 가지며 삭제되지 않음.
• 통합성(Intergrated) : 데이터 웨어하우스의 데이터는 기관/조직이 보유한 대부분의 운영 시스템들에 의해 생성된 데이터들의 통합본.
• 시계열성(Time Variant) : 운영시스템들은 최신 데이터를 보유하고 있지만, 데이터 웨어하우스는 시간 순에 의한 이력 데이터를 보유.

가. 스타 스키마

• 조인 스키마(join schema)라고도 하며, 데이터 웨어하우스 스키마 중 가장 단순함. 단일 사실 테이블(Fact Table)을 중심으로 다수의 차원 테이블(Dimensional Table)들로 구성됨.
• 스타 스키마를 활용할 때는 전통적인 관계형 데이터베이스를 통해 다차원 데이터베이스(Multi-Dimensional Database) 기능을 구현.
• 스타 스키마는 이해하기 쉬운 것이 장점. 스타 스키마의 사실 테이블(Fact Table)은 보통 제3정규형으로 모델링하는 것이 일반적. 차원 테이블(Dimensional Table)을 정규화하는 것을 스노우 플래이크 스키마라 함.
• 스타 스키마는 스노우 플래이크 스키마에 비해 복잡도가 낮아서 이해하기 쉽고, 쿼리 작성이 용이하고 조인 테이블 개수가 적은 장점을 가지고 있음.
• 반면 스타 스키마는 차원 테이블(Dimensional Tables)들의 비정규화에 따른 데이타 중복으로 해당 테이블에 데이터 적재 시 상대적으로 많은 시간이 소요된다는 단점이 있음.

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

스타 스키마의 차원 테이블을 제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/False 불린 값으로 저장하는 컬럼의 상태 값을 기반으로 변경 여부를 판단함. 더 높은 버전 넘버 또는 더 최근의 갱신 타임 스탬프를 보유한 레코드에 대한 변경 여부 판단을 사람이 직접 결정할 수 있도록 유보하는 등의 업무 규칙을 적용할 수 있음.

라. Time/Version/Satus on Rows

• 타임스탬프, 버전 넘버, 상태 값의 세 가지 특성을 모두 활용하는 기법으로 ‘특정 시간대의 버전 넘버 x.xx를 보유했으며 변경 상태 값이 True인 모든 레코드를 추출’하는 등 정교한 쿼리 생성에 활용해 개발 유연성을 제공.

마. Triggers on Tables

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

바. Event Programming

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

사. Log Scanner on Database

• 대부분의 데이터베이스 관리 시스템(DBMS)은 데이터베이스의 데이터에 대한 변경 여부와 변경 값 시간 등을 트랜잭션 로그를 기록/관리하는 기능을 제공. 이 트랙재션 로그에 대한 스캐닝 및 변경 내역에 대한 해석을 통해 CDC 매커니즘을 구현. 그런데 각 데이터베이스 관리 시스템에 따라 트랜잭션 로그 관리 매커니즘이 상이해 다수의 이기종 데이터베이스를 사용하는 환경에서 적용 시 작업 규모가 증가할 수 있으니 주의가 필요.
• 장점
  1. 데이터베이스에 대한 영향도 최소화
  2. 데이터베이스 사용 어플리케이션에 대한 영향도 최소화
  3. 변경 식별 지연시간 최소화
  4. 트랜잭션 무결성에 대한 영향도 최소화
  5. 데이터베이스 스키마 변경 불필요

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

제3절 EAI(Enterprise Application Integration)

1. EAI 개요

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

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

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

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

2. EAI 구현 유형

가. Mediation(intra-communication)

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

나. Federation(inter-communicattion)

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

3. EAI 기대 효과

• 향후 정보 시스템 개발 및 유지 보수비용 절감 도모
• 기업 업무 정보 시스템들의 지속적 발전 기반 확보
• 협력사/파트너/고객과의 상호 협력 프로세스 연계 발전 기반 확보
• 웹 서비스 등 인터넷 비즈니스를 위한 기본 토대

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

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

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

• 일괄 작업의 사례로는 ETL 기능을 통해 운영 시스템으로부터 정기적/반복적으로 대량의 데이터를 획득해 ODS를 구성하고, 이후 데이터 웨어하우스나 데이터 마트를 구성한 뒤 OLAP 정형/비정형 질의를 통해 경영 분석을 수행하는 작업을 들 수 있음
• 동기식 실시간 데이터 통합의 사례로는 컨테이너 터미널, 공장 등의 생산/운송 장비에 설치된 각종 센서들로부터 데이터를 실시간으로 획득해 운영 상태를 모니터링하고 필요한 경우 작업을 통제하는 사례를 들 수 있음.

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

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

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

1, 대용향 로그 데이터 수집

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

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

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

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

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

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

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

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

• 서비스에 적용하는 과정에서 수집 시스템에서 제공하는 기능을 사용하지만, 업무 특성상 일부 기능을 수정해야 하는 경우가 발생할 수 있음. 이때 인터페이스를 확장해 원하는 부분만 비즈니스 용도에 맞게 수정할 수 있어야 함.
• 플럼(Flume)은 앞서 언급한 비정형 데이터의 주요특징을 포함하고 있으며, 빅데이터 플랫폼을 구축할 때 수집 시스템으로 많이 활용되고 있음.

2. 대규모 분산 병렬 처리

한 번에 처리해야할 원천 데이터가 수십 GB에서 수십 TB에 이른다거나 대규모 컴퓨팅과 연산 작업이 필요하다면 하둡을 사용하는 것을 적극적 검토해야 함. 하둡은 대규모 분산 병렬 처리의 업계 표준인 맵리듀스(MapReduce) 시스템과 분산 파일시스템인 HDFS로 구성된 플랫폼 기술이며, 다음과 같은 특징을 갖음.

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

• 하둡을 구축함은 여러 대의 서버로 클러스터를 만든다는 것을 의미. 하둡은 필요 시 서버를 추가하면 연산 기능과 저장 기능이 서버의 대수에 비례해 증가함. 이는 하둡이 기본적으로 비공유(Shared Nothing) 분산 아키텍처 시스템이기 때문임. 하둡은 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 하둡은 빅데이터 기술 분야에서 가장 관심을 많이 받고 있는 기술이라고 할 수 있으며 다음과 같은 기술들이 시장에 나온 상태임.

• 아파치 드릴(Drill) : 하둡 전문 회사인 맵알(MapR)이 주축이 되어 진행하고 있는 프로젝트. 드레메르이 아키텍처와 기능을 동일하게 구현한 오픈 소스 버전의 드레멜
• 아파치 스팅거(Stinger) : 하둡 전문 회사인 호튼웍스에서 개발을 주도하고 있음. 새로운 엔진이라기 보다는 기존의 하이브 코드를 최대한 이용하여 성능을 개선하는 식으로 개발이 진행되고 있음.
• 샤크(Shark) : 인메모리 기반의 대용량 데이터웨어하우징 시스템이며, 하이브와 호환되기 때문에 하이브 SQL 질의와 사용자 정의 함수(User Defined Fuction)를 사용할 수 있음.
• 아파치 타조(Tajo) : 고려대 대학원에서 프로젝트가 최초 시작되었으며, 대학원생들은 국내 빅데이터 전문회사인 그루터(Gruter)에 합류하여 개발을 진행하고 있음. 아파치 인큐베이션 프로젝트로 등록되어 있음.
• 임팔라(Impala) : 하둡 전문 회사인 클라우데라(Cloudera)에서 개발을 주도하고 있음.
• 호크(HAWQ) : EMC에서 분사한 하둡 전문회사인 피보탈(Pivotal)에서 개발한 프로젝트. 상용과 커뮤니티 2가지 버전을 제공
• 프레스토 : 페이스북에서 자체적으로 개발하여 사용하고 있는 하둡 기반의 데이터웨어하우징 엔진임.

가장 먼저 공개된 임팔라를 살펴봄. 임팔라는 기본적으로 하이브의 SQL을 지원하지만, 모든 SQL문을 지원하는 것은 아니기 때문에 지원 되는 구문을 확인하는 것이 필요함.

• 클라이언트 : ODBC, JDBC 클라이언트, 임팔라쉘 같이 임팔라에 접속해서 테이블 관리, 데이터 조회 등의 작업을 수행
• 메타스토어 : 임팔라로 분석할 대상 데이터들의 정보를 관리하며, 하이브의 메타데이터를 같이 사용
• 임팔라 데몬 : 시스템에서는 ImpalaD로 표시되며, 클라이언트의 SQL 질의를 받아서 데이터 파일들의 읽기/쓰기 작업을 수행. 임팔라 데몬은 내부적으로 질의 실행계획기, 질의 코디네이터, 질의 실행엔진으로 구성
• 스테이트스토어 : 임팔라 데몬들의 상태를 체크하고 건강 정보를 관리해주는 데몬임. 임팔라 데몬에 장애가 생겼을 경우, 다른 데몬들에게 이 사실을 알려줘서 이후부터는 장애가 발생한 데몬에게는 질의 요청이 가지 않도록 해줌.
• 스토리지 : 분석할 데이터를 저장하는 현재는 HBase, 하둡분산파일시스템 두 가지를 지원함.