[ADP] 2과목 1장. 데이터 처리 기술 이해 :: 데이터 처리 프로세스

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

ETL : Extraction, Transformation, and Load

- 데이터 이동과 변환

- Extraction(추출) : 데이터 획득

- Transformation(변형) : 데이터 클렌징/형식 변환/표준화, 통합 또는 비즈니스 룰 적용 등

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

- 데이터 웨어하우스(DW), 운영 데이터 스토어(ODS), 데이터 마트(DM)에 대한 데이터 적재작업의 핵심 구성요소

- 데이터 통합, 데이터 이동, 마스터 데이터 관리에 걸쳐 폭넓게 활용

- 데이터 비정규화 : 성능 향상을 위해 테이블을 다시 합치는 것

 

- ETL 작업 단계

  1) Interface : 데이터 획득을 위한 인터페이스 메커니즘 구현

  2) Staging ETL : 획득된 데이터를 스테이징 테이블에 저장

  3) Profiling ETL : 스테이징 테이블에서 데이터 특성 식별 데이터 품질 측정

  4) Cleansing ETL : 데이터 보정

  5) Integration ETL : 데이터 충돌을 해소하고 클렌징된 데이터 통합

  6) Demoralizing ETL : 운영 보고서 생성, 데이터 웨어하우스/데이터 마트에 데이터를 적재하기 위해 데이터 비정규화 수행  

 

 

[ ODS: Operational Data Store ]

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

- ODS를 위한 데이터 통합은 데이터 클렌징/중복 제거/비즈니스 룰 대비 무결성 점검 등의 작업을 포함

- 일반적으로 원자성(개별성)을 지닌 하위 수준 데이터 (실기간/실시간 근접 트랜잭션, 가격 등)을 저장하기 위해 설계

 

- ODS 구성 단계

  1) Interface : 데이터 획득

  2) Staging

     - 획득한 데이터를 스테이징 테이블에 저장한다

     - 통제(Control) 정보 추가 : 적재 타임 스탬프, 데이터 값에 대한 Check Sum

     - 일괄(Batch)작업 형태의 정기적인 ETL과 실시간(Real Time) 데이터 획득 방식을 혼용하여 구성할 수 있다.

  3) Profiling

     - 범위, 도메인, 유일성 확보 등의 규칙을 기준으로 데이터 특성 식별 & 데이터 품질 점검

     - 선행 자료 또는 조건에 따라 데이터 프로파일링 요건을 설정 > 데이터 프로파일링 수행 > 결과 통계 처리 > 품질보고서 생성 및 공유

  4) Cleansing

  5) Integration : 정제완료 된 데이터를 ODS 내의 단일 통합 테이블에 적재

  6) Export

     - 통합된 데이터를에 익스포트 규칙과 보안규칙을 반영하여 테이블을 생성한 후 DBMS, DW, DM에 적재한다.

 

 

[ 데이터 웨어하우스 ]

1. 데이터 웨어하우스의 특징

  - 주제중심 : 업무항목을 기준으로 구조화

  - 영속성 : 읽기전용, 삭제되지 않는다.

  - 통합성 : 대부분 운영 시스템에 의해 생성된 데이터들의 통합본

  - 시계열성 : 시간순

 

2. 스타스키마 & 스노우 플래이크 스키마

1) 스타스키마 = 조인스키마

   - 단일 사실 테이블을 중심으로 다수의 차원 테이블들로 구성된다.

   - 전통적인 관계형 데이터베이스를 통해 다차원 데이터베이스 기능 구현

   - 사실 테이블 : 제3정규형으로 모델링

   - 차원 테이블 : 비정규화된 제2정규형으로 모델링

 

2) 스노우 플래이크 스키마와 비교

	스타 스키마	스노우 플래이크 스키마
장점	데이터 웨어하우스 스키마 중 가장 단순하다. 복잡도가 낮아서 이해하기 쉽다. 쿼리 작성이 용이하고 조인 테이블 개수가 적다.	데이터의 중복이 제거 → 시간 단축
단점	차원테이블의 비정규화에 따른 데이터 중복으로 해당 테이블에 데이터 적재 시 많은 시간이 소요된다.	스키마 구조의 복잡성증가 → 조인 테이블 개수 증가 쿼리 난이도 상승
차원테이블	비정규화된 제2정규형	제3정규형으로 정규화

---

CDC : Change Data Capture

- Change Data Capture

- 데이터베이스 내 데이터에 대한 변경을 식별해 필요한 후속 처리를 자동화

- 다양한 계층에서 다양한 기술을 통해 구현된다.

- 푸시 : 데이터(Source Data)에서 변경을 식별 → 대상 시스템(Target)에 변경 데이터를 적재

- 풀 : 대상 시스템(Target)에서 데이터(Source)를 정기적으로 살펴보아 필요 시 데이터를 다운로드

 

1. Time Stamp on Rows

- 마지막 변경 타임스탬프 값보다 더 최근의 타임스탬프 값을 갖는 레코드를 변경된 것으로 식별

 

2. Version Numbers on Rows

- 버전을 기록하는 컬럼을 두고 식별된 레코드 버전보다 더 높은 버전을 보유한 레코드를 변경된 것으로 식별

- 레코드들의 최신 버전을 기록/관리하는 참조테이블을 함께 운용

 

3. Status on Rows

- 타임스탬프와 버전 기법에 대한 보완 용도

- 사람이 직접 결정(True/False)

- 업무 규칙을 적용할 수 있다.

 

4. Time/Version/Status on Rows

- 세 가지 모두 활용하는 기법으로 정교한 쿼리 생성에 활용하여 개발 유연성을 제공할 수 있다.

 

5. Triggers on Rows

- 데이터베이스 트리거를 활용하여 등록된 다수 대상 시스템에 변경 데이터를 배포

- 트리거의 영향 : 시스템 관리 복잡도 증가, 변경 관리가 어려워짐, 확장성 감소, 전반적 시스템 유지보수성 저하

 

6. Event Programming

- CDC를 어플리케이션에 구현하여 다양한 조건에 의한 CDC 매커니즘을 구현

- 어플리케이션 개발 부담과 복잡도를 증가시킨다.

 

7. Log Scanner on Database

- 데이터베이스의 트랜잭션 로그 스캐닝 및 변경 내역 해석 활용

- 영향도 최소화 : 데이터베이스 & 데이터베이스 사용 어플리케이션 & 트랜잭션 무결성

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

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

- 데이터베이스 관리 시스템에 따라 트랜잭션 로그 관리 매커니즘이 상이해 다수의 데이터베이스를 사용하는 환경에서 적용 시 작업 규모가 증가

 

---

EAI : Enterprise Application Integration

- Enterprise Application Integration

- 기업 정보 시스템들의 데이터를 연계/통합하는 소프트웨어 및 정보 시스템 아키텍처 프레임워크

- 기업 또는 기업 간 복수의 이질적 정보 시스템들의 데이터를 연계하여 상호 융화, 동기화

- 산재된 정보 시스템들을 프로세스 및 메시지 차원에서 통합/관리

- 다수의 정보 시스템에게 폭넓고 통합적인 뷰를 제공

- 비즈니스 프로세스를 자동화하고 실시간으로 통합 연계

 

1. 기존 단위 업무 위주의 정보 시스템

- 포인트 투 포인트 방식 : 필요에 따라 정보 시스템들 간 데이터를 연계 → 데이터 연계의 복잡성 발생

- 데이터 통합과 연계가 어렵고 기존 마스터 데이터의 통합과 표준화를 불가능하게 한다.

- 방대하고 복잡한 데이터 연계 경로를 발생시키기 때문에 유지보수성이 극도로 저하된다. → 유지보수 및 관리 비용 상승

 

2. Hub and spoke

- 복잡성과 유지보수 비용 증가를 극복

- 가운데 지점에 허브 역할을 하는 브로커(Integration Broker)를 두고 연결 대상 노드(Spoke)들의 데이터 연계 요구를 중계하여 발생 연결 개수 및 구조를 단순화한다.

 

3.EAI 구성요소

- 각 정보 시스템과 EAI 허브(Engine)

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

- 버스(Bus) : 각 정보 시스템들 간의 데이터 연동 경로

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

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

 

3. EAI 구현 유형

1) Mediation

  - intra-communication

  - EAI 엔진이 중개자(Broker)로 동작

  - 특정 정보 시스템 내 유의미한 이벤트 발생을 식별해 사전 약속된 정보 시스템들에게 그 내용을 전달한다.

  - Publish/Subscribe Model

2) Federation

  - inter-communication

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

  - Request/Reply Model

 

4. EAI 기대 효과

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

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

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

- 인터넷 비즈니스를 위한 토대

- 데이터 표준화 기반 제공

 

---

데이터 연계 및 통합

일괄(Batch) 통합	비동기식 실시간 통합	동기식 실시간(Real Time) 통합
- ETL 기능을 통해 운영 시스템으로부터 정기적/반복적으로 대량의 데이터를 획득해 ODS를구성하고 데이터웨어하우스/데이터마트를 구성한 뒤 OLAP 질의를 통해 경영분석 수행 - 비실시간 데이터 통합 - 대용량 데이터 - 높은 데이터 조작 복잡성 - 데이터 추출/변형/적재 - CDC - 감사 증적 - 웹 서비스/SOA - 교차 참조 - 데이터 재처리 허용 - 점대점 데이터 연계 - 자동화 도구 및 자체 개발 SW 혼용	- 근점 실시간(Near Real Time) 데이터 통합 - 중간 용량 데이터 - 중간 데이터 조작 복잡성 - 데이터 추출/변형/적재 - CDC - Data pooling and DB Streams - 웹 서비스/SOA - 감사 증적 - 교차 참조 - 다수 데이터 원천 및 목표 시스템 - 데이터 재처리 허용 - 자동화 도구 및 자체 개발 SW 허용	- 실시간(Real Time) 데이터 통합 - 목표 시스템 데이터 처리 가능 시에만 원천 데이터 획득 - 데이터 추출/변형/적재 - 웹 서비스/SOA - 감사 증적 - Single Transaction Integrations - 단일 트랜잭션 단위 데이터 통합 - 데이터 재처리 불가 - 단일 또는 다수 데이터 원천

 

	전통적 데이터 처리 기법	빅데이터 처리 기법
추출	운영 DB → ODS → 데이터 웨어하우스	빅데이터 환경 → 빅데이터 환경
변환/로딩	O	O
시각화	X	O
분석	OLAP 통계와 데이터 마이닝 기술	통계와 데이터 마이닝 기술
리포팅	BI	BI
인프라스트럭처	SQL 전통적 RDBS 인스턴스	NoSQL 등 초대형 분산 데이터 스토리지

---

대용량 비정형 데이터 처리

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

- 초고속 수집 성능과 확장성

- 데이터 전송 보장 메커니즘 : 유실 x

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

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

 

2. 대규모 분산 병렬 처리

- 하둡 : 대규모 분산 병렬 처리의 업계 표준인 맵리듀스 시스템과 분산 파일시스템인 HDFS로 구성된 플랫폼 기술

- 하둡의 특징

   1) 선형적인 성능과 용량 확장성

     - 여러 대의 서버로 클러스터를 만든다.

     - 비공유 분산 아키텍처 시스템 : 서버를 추가하면 연산 기능과 저장 기능이 서버의 대수에 비례하여 증가한다.

   2) 고장 감내성

     - 고장 감내 기능 : 관리자의 개입 없이 시스템 수준에서 자동으로 동작한다.

     - 서로 다른 물리서버에 저장 → 특정 서버에 장애가 발생하더라도 동일 복제본이 있기에 데이터 유실을 방지한다.

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

   3) 핵심 비즈니스 로직에 집중

     - 시스템 장애 → 자동 복구(failover) 기능

     - 장애 상황이나 확장성, 성능 등의 이슈는 내부적으로 최적화하기에 비즈니스 로직에 집중할 수 있다.

   4) 풍부한 에코시스템 형성 : 다양한 응용 기술

 

3. 데이터 연동

- 스쿱 : 하둡에서 생성된 요약된 작은 데이터 셋을 다시 데이터베이스에 기록

- 데이터를 가져올 데이터베이스 접속 정보 입력 > SQL 입력 > 몇 개의 프로세스를 동시에 실행할 것인지 지정 > 데이터베이스의 키 컬럼 입력 > 데이터베이스로부터 가져온 데이터를 저장할 하둡상의 경로 지정

 

4. 대용량 질의 기술

1) 하둡 : 저비용으로 대용량 데이터를 저장하고 빠르게 처리할 수 있는 시스템, 빅데이터 구현을 위한 핵심적인 플랫폼 기술

2) 하이브 : SQL을 이용하여 하둡상의 저장된 데이터를 쉽게 처리하고 분석

3) SQL on Hadoop : 실시간 SQL 질의 분석 기술

   - 아파치 드릴(맵알) : 드레멜의 아키텍처와 기능을 동일하게 구현한 오픈 소스 버전의 드레멜

   - 아파치 스팅거(호튼웍스) : 기존의 하이브 코드를 이용하여 성능을 개선

   - 샤크 : 인메모리 기반의 대용량 데이터웨어하우징 시스템. 하이브와 호환 → 하이브 SQL 질의와 사용자 정의 함수 사용 가능

   - 아파치 타조(고려대 대학원)

   - 임팔라(클라우데라)

   - 호크(피보탈) :상용과 커뮤니티 2가지 버전

   - 프레스토(페이스북) : 하둡 기반의 데이터웨어하우징 엔진

4) 임팔라

   - HBase나 맵리듀스 같은 별도 개층을 거치지 않고 HDFS와 직접 통신

   - 하이브처럼 하이브쿼리언어(HiveQL)를 사용한다.

   - 하이브는 자바로 만들어졌지만 임팔라는 C++ 기반으로 만들어졌다.

   - 별도의 실행엔진을 사용하므로 맵리듀스 프로그래밍을 할 필요가 없다.

   - 맵리듀스와 달리 쿼리를 아주 낮은 지연속도로 처리 가능하다. 맵리듀스의 셔플링 단계를 거치지 않아 테이블 간의 조인 작업도 반드시 맵리듀스처럼 다대다 커뮤니케이션을 요구하지 않는다.

   - 클라이언트 : 테이블 관리, 데이터 조회

   - 메타스토어 : 분석할 대상 데이터들의 정보 관리

   - 임팔라 데몬 : SQL 질의

   - 스테이트 스토어 : 상태(장애) 체크

   - 스토리지 : 데이터 저장, HBase/HDFS 지원