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

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

 

ETL

 

• ETL
  

  Extraction	데이터 원천으로부터 데이터를 가져오는 것
  Transformation	클렌징, 변환, 표준화, 통합 등 비즈니스 적용
  Load	타깃에 적재

  • 대용량 처리를 위한 MPP(Massive Parallel Processing) 지원
  • 작업 단계
    1. interface : 다양한 원천으로부터 데이터를 획득하기 위한 인터페이스 구현
    2. Staging ETL : 데이터 획득 작업 후 스테이징 테이블 저장
    3. Profiling ETL : 스테이징 테이블에서 특성 식별 및 품질 측정
    4. Cleansing ETL : 규칙을 활용한 데이터 보정 작업
    5. Intergration ETL : 데이터 충돌 해소 및 클렌징 데이터 통합
    6. Denormalizing ETL : 데이터 웨어하우스/마트에 데이터 적재를 위한 비정규화
• ODS
  • Operational Data Store
  • 비교적 최근 데이터 저장을 목적
  • Real-time 또는 Near Real-time 트랜젝션 데이터 혹은 개별성을 지닌 하위 수준 데이터를 저장 목적
  • 구성 단계 - ETL 작업 단계와 유사
    1. 인터페이스 : 데이터 획득 단계
       - OLEDB, ODBC, FTP 등 사용
       - DW의 실시간/준실시간 OLAP을 지원하기 위한 실시간 데이터 복제 인터페이스 기술 활용
    2. 스테이징 단계 : 스테이징 테이블에 저장되는 단계
       - 정규화 배제, 원천 데이터 구조에 의존적, 일대일 혹은 일대다 매핑
       - Control 정보 추가 : 적재 타임스탬프, 데이터 체크 섬 등
    3. 데이터 프로파일링 : 데이터 품질 점검 단계
       - 선행요건 : 데이터 프로파일링 요건
    4. 데이터 클렌징 : 프로파일링 단계에서 식별된 오류 데이터 수정
       - 선행요건 : 데이터 품질 보고서, 클렌징 요건
    5. 데이터 인터그레이션 : ODS 내 단일 통합 테이블에 적재
       - 선행요건 : 데이터 클렌징 테이블, 데이터 충돌 판단 요건
    6. 익스포트 단계 : 익스포트 테이블 생성
       - 익스포트 규칙 + 보안 규칙
       - 그 후 DM/DW에 익스포트 테이블 적재
       - OLAP 비정형 질의에 활용
• 데이터 웨어하우스
  • ODS를 통해 정제 및 통합된 데이터가 데이터 분석과 보고서 생성을 위해 적재되는 저장소
  • 특징
    1. 주제 중심성 : 특정 이벤트 및 업무 항목으로 구조화되기에 end-user도 이해하기 쉬운 형태
    2. 영속성, 비휘발성 : 적재 이후 read-only, 삭제되지 않음
    3. 통합성 : 여러 원 천에서 발생한 데이터의 통합
    4. 시계열성 : 시간 순에 의한 이력 데이터
  • 모델링 기법
    1. 스타 스키마
       - one fact(3 정규형) - multi dimension(비 정규화된 2 정규형)
       - 낮은 복잡도로 이해하기 쉽고, 쿼리 작성이 용이
       - 디멘젼이 비정규화로 데이터 중복이 발생하고, 적재할 때 상대적으로 시간 소요
    2. 스노 플레이크
       - 디멘젼을 3 정규화
       - 데이터 중복이 제거되어 적재 시 시간 단축
       - 스키마 구조 복잡, 쿼리 작성 난이도 상승
• ODS VS DW
  

  구분	ODS	DW
  데이터 내용	비교적 최신	오래된, 상세, 요약 등 다양한 구조
  데이터 양	비교적 소규모	대규모
  데이터 갱신	지속적 갱신	데이터 축적 보관
  기술적 요소	DB의 모든 기능을 사용	LOAD와 ACCESS

CDC

 

• 개념 : 데이터의 변경을 식별해 필요한 후속처리를 자동화하는 기술 및 기법
• 특징
  • 실시간 / 준실시간
  • 스토리지 하드웨어 계층부터 애플리케이션 계층까지 다양한 계층/기술로 구현됨
• 구현 기법
  • Time Stamp on Rows : 변경 타임스탬프 칼럼으로 식별
  • Version Number on Rows : 버전 기록하는 칼럼으로 식별, 최신 버전 관리하는 참조 테이블 운영
  • Status on Rows : 타임스탬프와 버전 기법의 보완 용도, 변경 여부를 식별하는 칼럼
    - 레코드에 대한 변경 여부를 사람이 직접 결정할 수 있도록 유보하는 등의 업무규칙 적용 가능
  • 타임스탬프+버전+상태 짬뽕
  • Trigger on Tables : 트리거를 이용해 구현
    - 시스템 관리 복잡도 증가, 관리 어려움, 확장성 감소 유발, 시스템 유지보수성 저하
  • Event Programming : 애플리케이션 구현
    - 개발 부담 및 복잡도 증가하나, 다양한 조건의 CDC 구현 가능
  • Log scanner on Database : DBMS에서 제공하는 트랜잭션 로그 이용
    - 다수 이기종 DMBS 사용 시 작업 규모 증가
    - 영향도 최소화, 변경 식별 시간 최소화, 무결성에 대한 영향도 최소화, 스키마 변경 불필요
• 구현 방식
  
  • 푸시 방식
  • 풀 방식

 

EAI(Enterprise Application Intergration

 

• 개념 및 특징
  • 비즈니스 프로세스 중심
  • 이질적 정보 시스템들의 데이터를 연계, 상호 융화 내지 동기화
  • 애플리케이션을 프로세스 및 메시지 차원에서 통합 관리
  • ETL은 배치 프로세스 중심, EAI는 실시간/준실시간
• 데이터 연계 방식
  • (기존) point to point 
    1. 복잡성 증가 -> 유지보수성 저하
  • (EAI) Hub and spoke
    1. 허브가 중개하는 방식으로 연결 개수 및 구조 단순화
• 구성요소
  • 어댑터 / 버스 / 중개인 / 트랜스포머
• 구현 유형
  • Mediation(intra-communication)
    1. EAI엔진이 중개자 역할
    2. 이벤트 발생을 미리 식별, 약속된 정보시스템에 전달
    3. Publish / subsribe
  • Federation(inter-communication)
    1. EAI엔진이 외부 정보 시스템으로부터 데이터 요청을 일괄 수거, 필요한 데이터 전달
    2. Request / Reply
• 활용 효과
  • 개발 및 유지보수 비용 절감
  • 지속적 발전기반 확보
  • 상호 협력 프로세스 연계
  • 인터넷 비즈니스를 위한 기본 토대
  • 지역적 분리되어 있는 시스템들 간 데이터 및 계열사들 간 데이터 동기화
• EAI VS ESB
  

  구분	EAI	ESB
  기능	Hub를 이용하여 비즈니스 로직 중심, 애플리케이션 통합/연계	Bus를 이용하여 서비스 중심, 시스템을 연계
  통합 관점	애플리케이션	프로세스
  로직 연동	개별 애플리케이션	ESB
  아키텍처	단일접점의 중앙집중식	버스 형태의 느슨, 유연한 구조

데이터 통합 및 연계 기법

구분	전통적 데이터 처리	빅데이터 처리	비고
추출	운영 -> ODS -> DW	빅데이터 처리 환경-> 좌동	target-> source라는 점 동일
변환	O
로딩	O
시각화	X	O	데이터에서 인사이트를 얻고자 하는 것은 빅데이터 고유 특징
분석	OLAP/통계/데이터 마이닝	통계/데이터 마이닝
리포팅	BI	BI
인프라	SQL/RDMS	NOSQL 등 / 분산 데이터 스토리지	다수의 노드에 중복을 허용하는 것이 특징

 

대용량의 비정형 데이터 처리방법

 

• 대용량 로그 수집
  • 대표적인 비정형 데이터
  • 용량이 크기에 고성능/확장성 시스템 필요
• 대용량 비정형 데이터 수집 시스템 특징
  • 초고속 수집 성능 / 확장성
  • 데이터 전송 보장 메커니즘
    1. 단계별 혹은 인접 단계 끼지 신호를 통해 이벤트의 유실을 방지하는 방식을 전송 보장 가능
    2. 하지만, 성능과 안정성이라는 trade-off
  • 다양한 원천 수집과 플러그인
  • 인터페이스 상속을 통한 애플리케이션 기능 확장
    1. 확장을 통해 원하는 부분만 목적에 맞게 수정해야 됨
• 대규모 분산 병렬 처리(하둡)
  • 개념
    • 맵리듀스 + HDFS
    • 아파치 루씬의 서브 프로젝트로 시작
    • 비공유 분산 아키텍처
  • 특징
    • 선형적인 성능+확장
      - 최소 클러스터(5대), 비공유 분산 아키이기에 추가 서버만큼 성능과 용량 증가
    • 고장 감내성 : 3중 복제
      - 맵리듀스 중 장애 시 발생만 특정 타스크를 다른 서버에서 실행 가능
    • 핵심 비즈니스 로직에 집중
      - 맵+리듀스 2개의 함수만 구현하면 끝
      - 비지니스 로직에 집중하도록 자동복구, 확장성 및 성능 등의 이슈도 하둡 내부적으로 최적화 처리
    • 풍부한 에코 시스템
      - 모니터링 및 관리(Zookeeper) : 서버들 간 상호 조정이 필요한 서비스 제공
      - 워크플로우(Oozie, Azkaban) : 작업을 관리하는 워크플로우 및 코디네이터
      - 분산 데이터베이스(HBase) : HDFS기반의 칼럼 NoSQL
      - 배치 분석(Pig, Hive)
        ① Pig : 맵리듀스 프로그램을 대체할 Pig Latin 언어 제공
        ② Hive : 하둡 기반 DW, 테이블 단위 데이터 저장, HiveQL
      - 기계학습(Mahout) : 데이터 마이닝 알고리즘을 구현한 오픈소스
      - 메타데이터 관리(Hcatalog) : 테이블 및 스토리지 관리
      - 데이터 직렬화(Avro) : RPC과 데이터 직렬화 지원
      - 비정형 데이터 수집(Chukwa, Flume, Scribe, Kafca)
        ① Chukwa : 분산 환경의 데이터를 HDFS에 안정적으로 저장
        ② Flume : 소스 서버에 에이전트 -> 데이터 전달받는 콜렉터
        ②-1 Flume-NG : 대표적인 로그 수집, 데이터 발생하는 애플리케이션 단계 -> 데이터 수집 단계 -> 저장하는 단계 -> 데이터 저장소 보관단계
        ③ Scribe : 페이스북 개발, 중앙집중 서버로 전송
      - 정형 데이터 수집(Sqoop, Hiho)
        ① Sqoop : 대용량 데이터 전송 설루션, 다양한 저장소 가능
        ② Hiho : 대용량 데이터 전송 Solution, 하둡에서 데이터를 가져오기 위한 SQL 지정, JDBC 지원
      - YARN : 맵리듀스 단점을 극복하기 위한, 자원 관리 프레임워크 지원
  • 데이터 연동
    • 맵리듀스 같이 대규모 분산 병렬 처리를 데이터 베이스를 대상으로 하기에는 부하가 커지기에, 보통 데이터베이스 -> 하둡 복사 -> 분산처리 -> 결과 요약 데이터셋 생성 -> 데이터베이스 기록(Sqoop이용)
    • Sqoop
      - RDBMS 연동 지원
      - 맵 인풋 포맷 털 르 사용, SQL을 통해 테이블에서 데이터 추출
      - 데이터 이동을 맵리듀스를 이용하기에 장애 허용 능력과 병렬 처리 기능 제공
      - Import : RDBMS -> HDFS
      - Export : HDFS -> RDBMS
  • 대용량 질의 기능
    • SQL을 이용하여 하둡에 저장된 데이터를 쉽게 처리/분석할 수 있는 Hive
    • 하둡과 하이브는 대용량 데이터를 배치 처리하는데 최적화, 하지만 업무에서는 실시간 요구
    • 실시간 SQL 질의 분석 기술 ( SQL on 하둡)
      - 아파치 드릴 : 드레멜의 아키택처와 기능 구현
      - 아파치 스팅거 : 호튼웍스, 하이브 최대한 이용
      - 샤크 : 인메모리, 하이브 호환
      - 아파치 타조 : 고려대학원+그루터, 인큐베이션
      - 임팔라 : 클라우데라
      - 호크 : 피보탈
      - 프레스토 : 페이스북