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

* 다음 내용은 [데이터 분석 전문가 가이드] (2019년 개정판)을 읽고 정리한 내용입니다.

제 1절 ETL(Extraction, Transformation, and Load)

1. ETL 개요

• 데이터 이동과 변환 절차와 관련된 업계 표준 용어
• DW(Data Warehouse), ODS(Operational Data Store), DM(Data Mart)에 대한 데이터 적재 작업의 핵심 구성요소
• 데이터 통합 Data Integration, 데이터 이동 Data Migration, 마스터 데이터 관리 MDM(Master Data Management)에 걸쳐 폭넓게 활용
• 정책 기반의 정기적인 실행 일정을 조정할 수 있는 재사용 가능 컴포넌트들로 대용량 데이터를 처리하기 위한, MPP(Massive Paralle Processing)을 지원할 수 있다
• 구성 기능
  • Extraction: 데이터 원천들로부터 데이터 획득
  • Transformation: 데이터 클렌징, 형식변환, 표준화, 애플리케이션에 내장된 비즈니스 룰 적용 등
  • Loading: 변형 처리 완료된 데이터를 특정 목표 시스템에 적재
• 구현 상용 소프트웨어
  • Batch ETL
  • Real Time ETL
• ODS 구현 단계
  • step 0 interface
    
    • 다양한 데이터 원천으로부터 데이터 획득 위한 인터페이스 메커니즘 구현
  • step 1 Staging ETL
    
    • 수립 일정 따라 트랜잭션 데이터 획득 작업 결과물을 스테이징 테이블에 저장
  • step 2 Profiling ETL
    
    • 스테이징 테이블에서 특성 식별하고 품질 측정
  • step 3 Cleansing ETL
    
    • 다양한 규칙 활용해 프로파일링된 데이터 보정 작업
  • step 4 Integration ETL
    
    • 데이터 충돌을 해소, 클렌징된 데이터를 통합
  • step 5 Denormalizing ETL
    
    • 운영 보고서 생성, 데이터 웨어하우스 또는 데이터 마트 적재를 위한 데이터 비정규화 수행

 

 

2. ODS(Operational Data Store) 구성

• 다양한 데이터 원천들로부터 데이터를 추출, 통합한 데이터베이스
• 데이터 클렌징, 중복 제거, 비즈니스 룰 대비 데이터 무결성 점검 등 작업 포함
• Real Time 혹은 Near Real Time 트랜잭션 혹은 원자성(개별성)을 지닌 하위 수준 데이터를 저장하기 위해 설계
• ODS 구성 위한 일괄 작업 ETL은 아래의 6-Layer로 구성된다.

 

가. 인터페이스 단계

• 데이터 원천(트랜잭션 데이터를 저장하고 있는 모든 알려진 데이터 저장소)로부터 데이터 획득
• 프로토콜
  • OLEDB(Object Linking and Enbedding Database)
  • ODBC(Object Data Base Connectivity)
  • FTP(File Transfer Protocol)
• Real Time, Near Real Time OLAP 질의 지원을 위해 실시간 데이터 복제 인터페이스 기술이 활용

 

나. 데이터 스테이징 단계

• 작업 일정이 통제되는 프로세스들에 의해 데이터를 추출하여 스테이징 테이블에 저장
• 정규화가 배제되고, 테이블 스키마는 데이터 원천 구조에 의존적이다
• 데이터 매핑은 일대일 또는 일대다로 구성된다
• 적재 타임스탬프, 데이터 값에 대한 체크 섬 등 통제 정보들이 추가된다
• 신규 데이터 항목의 추가 여부에 따른 데이터 추가 적재 필요성 판단 등에 활용한다
• 일괄(Batch) 작업 형태의 정기적 ETL과 실시간(Real Time) 데이터 획득 방식을 혼용한다

 

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

• 범위, 도메인, 유일성 확보 등 규칙을 기준으로 다음 절차에 따라 데이터 품질 점검
  • 선행자료, 조건: 데이터 프로파일링 요건
  • step 1
    
    • 데이터 프로파일링 수행
  • step 2
    
    • 데이터 프로파일링 결과 통계 처리
  • step 3
    
    • 데이터 품질 보고서 생성 및 공유

 

라. 데이터 클렌징 단계

• 클렌징 ETL 프로세스로 오류데이터를 절차에 따라 수정
  • 선행자료, 조건: 데이터 품질 보고서, 데이터 클렌징 요건
  • step 1
    
    • 클렌징 스토어드 프로시져 실행(예비 작업)
  • step 2
    
    • 클렌징 ETL 도구 실행

 

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

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

 

바. 익스포트 단계

• 익스포트 규칙, 보안규칙 반영한 익스포트 ETL 기능 수행하여 익스포트 테이블 생성
• 다양한 전용 DBMS 클라이언트, 혹은 데이터 마트, 데이터 웨어하우스에 적재
• OLAP 비정형 질의에 활용 가능

 

 

3. 데이터 웨어하우스

• ODS 통해 정제, 통합된 결과물을 데이터 분석과 보고서 생성을 위해 적재
• 특징
  
  • 주제 중심: 실 업무 상황의 특정 이벤트, 업무 항목을 기준으로 구조화
  • 영속성: 최초 저장 이후 읽기 전용 속성, 삭제되지 않는다.
  • 통합성: 기관, 조직이 보유한 대부분 OS에 의해 생성된 데이터의 통합본
  • 시계열성: 최신 데이터 보유, 시간순에 의한 이력 데이터 보유

 

가. 스타 스키마

• 조인스키마로 가장 단순한 형태
• 단일 사실 테이블을 중심으로 다수의 차원 테이블로 구성됨
  • 사실 테이블 Fact Table: 보통 제3정규형으로 모델링
  • 차원 테이블 Dimensional Table: 보통 비정규화된 제2정규형으로 모델링
    
• 전통적 관계형 데이터베이스 통해 다차원 데이터베이스 기능 구현
• 장점
  • 복잡도가 낮아 이해하기 쉽다
  • 쿼리 작성이 용이하다
  • 조인 테이블 개수가 적음
• 단점
  • 비정규화에 따른 데이터 중복으로 적재에 상대적 많은 시간이 소요된다

 

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

• 차원 테이블을 제 3정규형으로 정규화한 형태
• 장점
  • 중복이 제거되어 시간이 단축
• 단점
  • 복잡성 증가로 조인 테이블 개수가 증한다
  • 복잡성 증가로 쿼리 작성 난이도 상승

 

---

 

제 2절 CDC(Change Data Capture)

1. CDC 개요

• 데이터베이스 내 데이터 변경을 식별하여, 필요한 후속 처리(데이터 전송/공유)를 자동화하는 기술, 설계기법, 구조
• 실시간 또는 근접 실시간 데이터 통합에 폭 넓게 활용된다
• 다양한 계층, 다양한 기술 통해 구현 가능하다

 

가. Time Stamp on Rows

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

 

나. Version Numbers on Rows

• 기 식별된 레코드 버전보다 더 높은 버전을 보유한 레코드를 변경된 것으로 식별
• 최신 버전을 기록, 관리하는 '참조 테이블'을 함께 운용하는 것이 일반적

 

다. Status on Rows

• 타임 스탬프 및 버전 넘버 기법 보완 용도로 활용
• 칼럼 상태값(불리언) 기반으로 변경 여부 판단
• 사람이 직접 결정할 수 있도록 유보하는 등 업무 규칙을 적용 가능

 

라. Time/Version/Status on Rows

• 타임스탬프, 버전 넘버, 상태값 모두 활용
• 정교한 쿼리 생성에 활용해 개발 유연성을 제공

 

마. Triggers on Tables

• 사전에 등록된 다수 대상 시스템에 변경 데이터를 배포하는 형태로 CDC 구현
• 시스템 관리 복잡도를 증가, 변경 관리를 어렵게 하고 확장성을 감소하는 등 전반적 시스템 유지보수성을 저하하기에 사용에 주의가 필요

 

바. Event Programming

• 데이터 변경 식별 기능을 어플리케이션에 구현
• 어플리케이션 개발 부담과 복잡도 증가시키나 다양한 조건에 의한 CDC 매커니즘을 구현가능

 

사. Log Scanner on Database

• DBMS는 데이터베이스의 데이터 변경 여부와 변경 값 시간 등 트랜잭션 로그를 기록, 관리 기능 제공
• 트랜잭션 로그에 관한 스캐닝 및 변경 내역에 대한 해석 통해 CDC 매커니즘을 구현
• 이기종 데이터베이스 적용 시 작업 규모 증가 가능
• 장점
  
  • 데이터베이스 영향도 최소화
  • 데이터베이스 사용 애플리케이션 영향도 최소화
  • 변경 식별 지연시간 최소화
  • 트랜잭션 무결성 영향도 최소화
  • 데이터베이스 스키마 변경 불필요
• CDC 구현 방식종류
  • Push
    
    • 데이터원천에서 변경을 식별
    • 대상 시스템에 변경 데이터를 적재
  • Pull
    
    • 대상 시스템에서 데이터 원천을 정기적으로 살핀다
    • 필요하면 데이터를 다운로드

 

 

 

---

 

제 3절 EAI(Enterprise Application Integration)

1. EAI 개요

• 기업 정보 시스템간의 데이터를 연계하고 통합하는 S/W 및 정보 시스템 아키텍처 프레임워크
• 복수의 이질적 정보 시스템들의 데이터를 연계함으로 상호 융화, 동기화되어 동작한다
• 산재된 정보 시스템들을 프로세스 및 메시지 차원에서 통합, 관리한다
• 다수의 정보 시스템에게 기업 내 중요한 데이터 엔터티들의 폭넓고 통합적인 뷰를 제공한다
• 비즈니스 프로세스를 자동화, 실시간으로 통합 연계한다
• 기존)
  
  • 단위 업무 위주, 필요에 따라 정보 시스템들 간 포인트 투 포인트 방식
  • 통합과 연계 확보 어렵고, 통합과 표준화 불가능
  • 연계 경로가 발생, 유지보수성이 극도로 저하
  • 유지보수 및 관리 비용의 상승
• 포인트 투 포인트 방식
  • N개의 연결 대상 노드 존재시, 연결은 N(N-1)/2개 발생
• Hub and Spoke 방식
  • 가운데에 허브 역할의 브로커를 두고 연결 대상 노드들이 데이터 연계 요구를 중계해줌
  • 발생 연결 개수 및 구조를 단순화
  • 각 연결 대상 노드는 스포크에 해당
• EAI 구성요소
  • Adapter: 각 정보 시스템과 EAI 허브 간 연결성 확보 위한 EAI 구성 요소
  • BUS: 어댑터를 매개로 연결된 각 정보 시스템들 간의 데이터 연동 경로
  • Broker: 데이터 연동 규칙을 통제
  • Transformer: 데이터 형식 변환 등을 담당

 

2. EAI 구현 유형

가. Mediation(intra-communication)

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

 

나. Federation(inter-communication)

• EAI 엔진이 외부 정보 시스템으로부터 데이터 요청들을 일괄적으로 수령, 필요 데이터를 전달
• Request/reply Model

 

 

3. EAI 기대 효과

• 향후 정보 시스템 개발 및 유지 보수비용 절감 도모
• 기업 업무 정보 시스템들의 지속적 발전 기반 확보
• 협력사/파트너/고객과의 상호 협력 프로세스 연계 발전 기반 확보
• 웹 서비스 등 인터넷 비즈니스를 위한 기본 토대
  
• 본사와 공장이 별도의 정보시스템 보유한 상태에서 글로벌하게 지역적 분리되어 데이터 동기화 필요한 경우
• 그룹 및 지주 회사 계열사 들 간 상호 관련 데이터 동기화 필요한 경우 등
• 글로벌 경영 환경에 상응하는 데이터 표준화 기반 제공

 

---

 

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

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

• Batch / Near Real-Time / Real-Time 방식을 혼용하여 사용할 수 있다.
• Batch
  
  • 대용량 데이터 처리 가능
  • ETL 기능 통해 운영 시스템으로부터 정기적/반복적으로 대량의 데이터를 획득해 ODS를 구성하고 데이터 웨어하우스나 데이터 마트를 구성 후 OLAP 정형/비정형 질의 통해 경영 분석 수행
• Real Time
  • 관심 대상 영역 상태에 대한 빠른 파악 및 대응이 가능
  • 컨테이너 터미널, 공장 등 생산/운송 장비에 설치된 각종 센서 데이터를 실시간으로 획득, 운영 상태 모니터링
  • Complex Event Processing 이라는 SW 및 데이터 아키텍처 통해 구현 가능
  • 중복 허용하는 분산 저장 환경 구성을 통한 높은 확장성 확보하는 빅데이터 저장 인프라스트럭처의 활용과 병행 설계 사례도 종종 등장
• ETL 솔루션의 변화
  • 전통적 ETL
    • 데이터 웨어하우스 구성만을 주목적으로 했음
  • 최근 동향
    • ODS와 BI 플랫폼, MDM 허브, 하둡 클라우드 환경 등 다양한 데이터 통합 메커니즘을 지원하며 영역을 확장하고 있다
    • 빅데이터 환경과 전통적 데이터 환경 간 빅데이터 추출/변형/적재를 지원한다
    • 기존 ETL 솔루션들도 비정형/준정형 데이터의 정형 데이터로의 변형 작업을 표준화 시도하고 있다

 

---

 

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

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

• log
  • 과거) 시스템의 문제 상황을 보존, 서비스 접근/사용 로그를 기록
  • 최근) 사용자 행태 분석, 마케팅과 영업 전략 등에 이용
  • 용량이 방대하기에 성능과 확장성의 시스템이 필요

 

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

• 다양한 곳에서 대용량 데이터를 실시간으로 수집
• 증가한 서버 수만큼 에이전트의 수를 늘리는 확장이 쉬운 구조

 

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

• 데이터 전송 안정성 수준을 제어한다
• 단계별로 신호를 주고받아 단 하나의 이벤트도 유실되지 않은채로 여러 단계를 거쳐 저장소에 도착한다
• 단지 인접한 단계로만 데이터 전송을 보장하는 방법도 존재한다
• 성능과 안정성은 Trade-off 이므로, 비즈니스 특성 고려해 선택해야 한다

 

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

• 일부 잘 알려진 서비스로부터 몇 가지 설정만으로 데이터를 수집할 수 있도록 내장 플러그인 제공한다
• 하둡 저장 기능 + NoSQL 포함한 다양한 데이터베이스에 저장하는 플러그인까지 제공한다

 

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

• 인터페이스를 확장해 원하는 부분만 비즈니스 용도에 맞게 수정 가능해야
• Flume_NG
  • 비정형 데이터의 주요 특징을 포함, 수집 시스템으로 많이 활용됨
  • 4단계에 걸쳐 데이터를 수집/저장
    1. 데이터 발생하는 애플리케이션 단계
    2. 발생한 데이터 수집하는 단계
    3. 수집한 데이터를 저장하는 단계
    4. 데이터 저장소 보관 단계: 보통 하둡을 사용함

 

 

2. 대규모 분산 병렬 처리

• 대규모 컴퓨팅과 연산 작업 필요시 하둡 사용권장
• 하둡: 대규모 분산 병렬 처리 업계 표준인 MapReduce 시스템 + 분산 파일시스템 HDFS로 구성된 플랫폼 기술

아래는 하둡의 특징이다

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

• 하둡을 구축 = 여러 대의 서버로 클러스터 구성
• 통상적으로 5대가 최소 클러스터 대수
• 비공유 분산 아키텍처 시스템이기 때문에 연산 기능과 저장 기능이 서버 대수에 비례해 증가
• 2만대 서버를 단일 클러스터로 구성 가능한 좋은 확장성
• 선형적 성능 확장도 가능

 

나. 고장 감내성

• 데이터를 3중 복제해 데이터 유실을 방지
• 맵리듀스 중 장애 발생시, 자동 감지해 특정 태스크만 다른 서버에서 재실행 가능
• 고장 감내 기능은 관리자 개입 없이 시스템 수준에서 자동으로 동작

 

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

• 맵리듀스
  • 맵과 리듀스라는 2개의 함수만 구현하면서 동작
• 개발자는 맵리듀스라는 데이터 처리/분석 방식만 이해한 채로 비즈니스 목적에 맞게 간단한 코드만 작성
• 자동 복구 기능(failover)으로 시스템 수준 발생하는 장애, 확장성, 성능 등은 내부적으로 최적화해 처리한다

 

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

• 오픈 소스 프로젝트 형태로 소개된 하둡의 응용 기술들
  • 데이터 수집 기술
    
    • Flume-NG
  • 데이터 연동 기술
    
    • Sqoop
  • 데이터베이스 기술 NoSQL
    
    • HBase
  • 대용량 SQL 질의 기술
    
    • Hive
    • Pig
  • 실시간 SQL 질의 기술
    
    • Impala
    • Tajo
  • 워크플로 관리 기술
    
    • Oozie
    • Azkaban
  • 대규모 분산 병렬 처리 기술
    
    • 맵리듀스
      
      • 구글이 처음 고안해 내부적으로 사용하다 2005년에 오픈소스 프로젝트로 공개하였다
      • 분산 병렬 처리 모델의 알고리즘/로직 개발의 복잡성을 획기적으로 감소시켰다

 

 

3. 데이터 연동

• 비정형 데이터 분석 시, 기업 내 축적된 데이터와 정보를 연동하는 것이 필요하다
• 기간 계 시스템인 데이터베이스 대상으로 대규모 분산 병렬 처리 시 심한 부하를 야기한다
• 데이터베이스의 데이터를 하둡으로 복사 후 대규모 분산 병렬 처리를 수행한다
• 생성된 요약된 작은 데이터 셋을 다시 데이터베이스에 기록한다
• 대표적인 오픈 소스 기반 솔루션: SQOOP
  
  • 오라클, MySQL, PostgreSQL, 사이베이스 등 JDBC(Java Database Connectivity)를 지원하는 대부분 관계형 데이터베이스와 연동 지원
  • HBase 같은 일부 NoSQL 데이터베이스와도 연동
  • 데이터 전송 스크립트
    • 데이터를 가져올 데이터베이스 접속 정보를 입력
    • 가져올 데이터에 대한 SQL 입력
    • 동시에 몇 개의 프로세스를 실행해 데이터를 가져올지 정할 때, 많이 지정하면 빠르지만, 부하가 많이 발생하므로 적절한 개수 지정이 필요하다
    • 데이터베이스의 키 칼럼을 입력
    • 데이터베이스로부터 가져온 데이터를 저장할 하둡상의 경로를 지정
  • 하둡 결과 데이터도 비슷한 스크립트 문법을 이용하여 다시 데이터베이스에 적재 가능하다

 

 

4. 대용량 질의 기술

• 하둡
  • 저비용으로 대용량 데이터 저장, 빠르게 처리가능한 빅데이터 구현 핵심 플랫폼 기술
• Hive
  • 하둡에는 코딩이 필요해 어려운 사용자를 위해 개발
  • SQL이라는 질의 기술을 이용해 하둡에 저장된 데이터를 쉽게 처리 분석
• 실제 업무에는 데이터를 실시간으로 조회, 처리해야 하는 일이 많다
• SQL on 하둡이라고 하는 실시간 SQL 질의 분석 기술
  • 아파치 Drill
    • 하둡 전문 회사인 MapR이 주축
    • 드레멜의 아키텍처와 기능을 동일하게 구현한 오픈 소스 버전의 드레멜
  • 아파치 Stinger
    • 하둡 전문 회사인 호튼웍스 주도
    • 기존의 하이브 코드를 최대한 이용하여 성능을 개선
  • Shark
    
    • 인메모리 기반 대용량 데이터웨어하우징 시스템
    • 하이브와 호환되어 하이브 SQL 질의와 사용자 정의 함수 사용가능
  • 아파치 Tajo
    
    • 고려대 대학원 최초 시작, 국내 빅데이터 전문회사인 Gruter에 합류해 개발 진행
      
    • 아파치 인큐베이션 프로젝트로 등록됨
  • Impala
    • 하둡 전문 회사인 Cloudera에서 개발 주도
    • 기본적으로 하이브의 SQL을 지원하지만 확인 필요
    • 주요 구성 요소
      • 클라이언트
        
        • 임팔라에 접속해 테이블 관리, 데이터 조회 등
      • 메타스토어
        
        • 임팔라로 분석할 대상 데이터들의 정보를 관리, 하이브의 메타데이터를 같이 사용
      • 임팔라 데몬
        
        • ImpalaD로 표시되고, 클라이언트의 SQL 질의를 받아 읽기/쓰기 작업을 수행
        • 내부적으로 질의 실행계획기, 질의 코디네이터, 질의 실행엔진으로 구성
      • 스테이트스토어
        
        • 임팔라 데몬들의 상태를 체크, 건강 정보를 관리
        • 장애 발생시, 알려줘 이후로는 그 데몬에 질의 요청이 가지 않도록 조정
      • 스토리지
        
        • 분석할 데이터 저장하는 HBase, 하둡 분산 파일 시스템을 지원
    • 기본적으로 모든 노드에 구동되며, 임의의 노드에 JDBC나 ODBC, 임팔라쉘을 이용해 질의 요청가능
    • 데이터 지역성 고려해 노드 전체로 분산되어 수행
      • 하둡에서 JobTracker가 데이터 지역성 고려해 TaskTracker에 할당하는것과 유사한 방식
    • 질의요청 받은 코디네이터 데몬은 취합하여 결과 값을 만들어 사용자에게 제공한다
    • 실제 운영 환경에서는 라운드로빈 방식으로 사용자 질의를 분산시켜 질의에 대해 전 노드들이 코디네이터 역할을 고르게 수행하도록 해야 한다
  • HAWQ
    • EMC에서 분사한 하둡 전문 회사인 Pivotal에서 개발
    • 상용과 커뮤니티 버전 제공
  • 프레스토
    • 페이스북 자체 개발
    • 하둡 기반의 데이터웨어하우징 엔진
• Hive가 표준 SQL 솔루션이지만, 더 빠른 처리 위해 임팔라와 같은 기술이 대두되고 있다.
• 새로운 기술들은 사용자 함수 지원, 데이터 조인시 메모리 문제 등 개선 사항이 많지만, 많은 개발자가 개발과 테스트 중이기에 점차적으로 기능과 안정성이 개선되어 중요한 역할을 할 것이다.