ADP _ 자격증 공부 (1) - 2과목 1장. 데이터 처리 기술 이해 : 데이터 처리 프로세스
ADSP에 이어서 ADP를 공부하려고 한다.. ADP 책을 따로 사지 않아서 감사하게도 개념 내용을 올려주신 분들의 내용을 참고하여 공부해보려고 한다!!
그래서 겹치는 3과목은 작년에 어느정도 봤으니 나머지 2과목을 우선 하고 그 후에 3과목 짜리를 해야겠다는 계획이다.
몇일 안남았지만.. ADSP도 하루만에 불살라 버렸듯.. ADP도 불살를 각오로!! 열심히 해야겠다!!
키보드로 타자를 치면서 공부 하듯이 하면서 적는 것이다!!
2과목 1장. 데이터 처리 기술 이해 : 데이터 처리 프로세스
1장. 데이터 처리 프로세스
ETL : Extraction, Transformation, and Load
: 데이터의 이동과 변환
Extraction: 추출 : 데이터 획득
Transformation : 변형 : 데이터 클렌징/ 형식변환/ 표준화, 통합 또는 비즈니스 룰 적용 등
Loading : 적재 : 변형 처리가 완료된 데이터를 목표 시스템에 적재
데이터 웨어 하우스(DW), 운영 데이터 스토어(ODS) , 데이터 마트(DM)에 대한 데이터 적재작업의 핵심 구성요소
데이터 통합, 데이터 이동, 마스터 데이터 관리에 걸쳐 폭넓게 활용된다
데이터 비정규화란 성능향상을 위해 테이블을 다시 합치는 것이다
ETL 의 작업단계는 다음과 같다.
1. INTERFACE :
- 다양한 이기종 dbms&스프레드 시트 등 데이터 원천으로부터 데이터 획득을 위한 인터페이스 메커니즘 구현
2. STAGING ETL : 수집된 일정에 따라 데이터 원천으로부터 트랜잭션 데이터 획득 작업 수행후, 획득된 데이터를 스테이징 테이블에 저장
3. PROFILING ETL: 스테이징 테이블에서 데이터 특성 식별 데이터 품질 측정
4. CLEANSING ETL : 데이터 보정 작업
5. INTEGRATION ETL: (이름,값,구조)데이터 충돌을 해소하고 클렌징된 데이터 통합
6. DEMORALIZING ETL: 운영보고서 생성, 데이터 웨어하우스/ 데이터 마트에 데이터를 적재하기 위해 데이터 비정규화 수행
++) 근데 DEMORALIZING 의 뜻을 몰라서 네이버를 찾아보았다!!
사기를 꺾다, 의기소침하게 만들다 (=dishearten)
???? 그냥 데이터 비정규화를 DEMORALIZING이라고 하는듯.. 테이블을 다시 합친다는게 약간 사기저하 시킨다는 의미랑 비슷하게 통하는듯..?
[ODS : OPERATIONAL DATA STORE]
- 데이터에 추가 작업을 위해 다양한 데이터 원천(SOURCE)들로부터의 데이터를 추출/통합한 데이터 베이스
- ODS를 위한 데이터 통합은 데이터클렌징/중복제거/ 비즈니스 룰 대비 무결성 점검 등의 작업을 포함
- 일반적으로 원자성(개별성)을 지닌 하위 수준 데이터 ( 실기간/ 실시간 근접 트랜잭션, 가격 등) 을 저장하기 위해 설계
- ODS 구성단계
1) INTERFACE : 데이터 획득
2) STAGING
- 획득한 데이터를 스테이징 테이블에 저장한ㄴ다
- 통제(CONTROL) 정보 추가: 적재타임 스탬프, 데이터 값에 대한 CHECK SUM
- 일괄 (BATCH) 작업 형태의 정기적인 ETL과 실시간(REAL TIME) 데이터 획득 방식을 혼용하여 구성할 수 있다.
3) PROFILNG
- 범위, 도메인, 유일성 확보 등의 규칙을 기준으로 데이터 특성 식별 & 데이터 품질 점검
- 선행 자료 또는 조건에 따라 데이터 프로파일링 요건을 성정 > 데이터 프로파일링 수행 > 결과 통계 처리> 품질 보고서 생성 및 공유
4) CLEANSING
5) INTEGRATION : 정제완료 된 데이터를 ODS 내의 단일 통합 테이블에 적재
6) EXPORT
-통합된 데이터를 익스포트 규칙과 보안규칙을 반영하여 테이블을 생성 한 후 DBMS, DW, DM에 적재한다.
ETL과 ODS의 차이점
ETL은 다양한 DBMS로부터 데이터 획득이 목적이었다면,
ODS는 통합된 데이터를 익스포트 규칙과 보안규칙을 반영한 익스포트 DTL 기능을 수행해 익스포트 테이블을 생성한 후, 다양한 전용 DBMS클라이언트 OR DM,DW 에 적재
[데이터 웨어 하우스]
1. 데이터 웨어 하우스의 특징
- 주제 중심 : 업무항목을 기준으로 구조화
- 영속성 : 읽기 전용, 삭제되지 않는다.
- 통합성 : 대부분 운영시스템에 의해 생성된 데이터 들의 통합본
- 시계열성 : 시간순
2. 스타스키마 & 스노우 플레이크 스키마
1) 스타 스키마 = 조인스키마
- 단일 사실 테이블을 중심으로 다수의 차원 테이블들로 구성된다.
- 전통적인 관계형 데이터 베이스를 통해 다차원 데이터 베이스 기능 구현
- 사실 테이블 : 제3 정규형으로 모델링
- 차원 테이블 : 비정규화된 제2정규형으로 모델링
== 왠지 이부분 시험에 나올 각
2) 스노의 플래이크 스키마와 비교
스타 스키마 | 스노우 플래이크 스키마 | |
장점 | 데이터 웨어하우스 스키마 중 가장 단순 복잡도가 낮아서 이해하기 쉬움 쿼리 작성이 용이하고 조인 테이블 개수가 적음 |
데이터의 중복이 제거되어 시간 단축 |
단점 | 차원테이블의 비정규화에 따른 데이터 중복으로 해당 테이블에 데이터 적재 시 많은 시간이 소요된다 | 스키마 구조의 복잡성 증가 -> 조인 테이블 개수 증가 쿼리 난이도 상승 |
차원 테이블 | 비정규화된 제 2 정규형 | 제3정규형으로 정규화 |
CDC : 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
- 데이터 베이스의 트랜잭션 로그 스캐닝 및 변경 내역해석 활용
- 영향도 최소화 : 데이터 베이스 & 데이터 베이스 사용 어플리케이션 & 트랜잭션 무결성
- 변경 식별 지연시간 최소화
- 데이터 베이스 스키마 변경 불필요
- 데이터 베이스 관리 시스템에 따라 트랜잭션 로그관리 매커니즘이 상이해 다수의 데이터 베이스를 사용하는 환경에서 적용 시 작업 규모가 증가
==== 오늘은 여기까지 3/ 9
3/10 부터 다시
EAI(EnterPrise Application Integration)
: 기업 또는 기업간 이질적 정보시스템들의 데이터를 연계함으로써 상호융화 내지 동기화
기대효과 : 본사와 공자이 별도의 정보시스템을 보유한 상태에서, 글로벌하게 지역적으로 분리돼 있고
해당 정보 시스템들 간 데이터 동기화가 필요한 경우나
그룹 & 지주회사 계열사들간 상호관련 데이터 동기화가 필요한 경우
연계방식
1. Point to Point(ETL /CDC 방식)
- 필요에 따라 정보세스템들간 데이터 연계로 복잡성 발생/ 표준화 불가능/ 유지보수성 저하 및 관리 비용 상승
2. 허브앤스포크 아키텍처
-복잡성과 유지보수비용증가를 극복
- 가운데 지점에 허브역할을 하는 브로커(integration Broker)를 두고 연결대상노드(Spoke)들의 데이터 연계요구를 중계하여 발생 연결 개수 및 구조를 단순화 한다.
3. EAI 구성요소
- 각 정보 시스템과 EAI 허브(engine)
- 어댑터 : 정보시스템과 허브 간 연결성을 확보
- 버스 : 각 정보 시스템들 간의 데이터 연동 경로
- 브로거 : 데이터 연동 규칙을 통제
- 트랜스포머 : 데이터 형식 변환
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) 고장 감내성
- 고장 감내 기능: 관리자의 개입없이 시스템 수준에서 자동으로 동작한다..
- 서로 다른 물리서버에 저장 -> 특정 서버에 장애가 발생하더라도 동일 복제본이 있기에 데이터 유실을 방지한다.
- 맵리듀스 작업을 수행하다 특정 task에서 장애가 생기면 시스템이 자동으로 감지해 장애가 발생한 특정 테스크만 다른서버에서 재실행을 할 수 있따.
3)0 핵심 비즈니스 로직에 집중
- 시스템 장애 -> 자동 복구(failover) 기능
- 장애 상황이나 확장성, 성능 등의 이슈는 내부적으로 최적화하기에 비즈니스 로직에 집중 할 수 있다.
4) 풍부한 에코시스템 형성: 다양한 응용 기술
3. 데이터 연동
- 스쿱: 하둡에서 생성된 요약된 작은 데이터 셋을 다시 데이터 베이스에 기록
- 데이터를 가져올 데이터 베이스 접속 정보 입력 >sql 입력> 몇개의 프로세스를 통시에 실행할 것인지 지정 > 데이터 베이스의 키 컬럼 입력 > 데이터 베이스로 부터 가져온 데이터를 저장할 하둡상의 경로 지정
4. 대용량 질의 기술
1) 하둡 : 저비용으로 대용량 데이터를 저장하고 빠르게 처리할 수 있는 시스템, 빅데이터 구현을 위한 핵심적인 플랫폼 기술
2) 하이브: SQL을 이용하여 하둡상의 저장된 데이터를 쉽게 처리하고 분석
3) SQL on Hadoop ; 실시간 sql 질의 분석 기술
- 아파치 드릴(맵알) : 드레멜의 아키텍처와 기능을 동일하게 구현한 오픈소스버전의 드레멜
- 아파치 스팅거(호든웍스) : 기존의 하이브 코드를 이용하여 성능을 개선
- 샤크 : 인메모리 기반의 대용량 데이터 웨어하우징 시스템, 하이브와 호환 - > 하이브 sql 질의와 사용자 정의 함수 사용 가능
- 아파치 타조 (고려대 대학원)
- 임팔라(클라우데라)
4) 임팔라
- HBase나 맵리듀스 같은 별도 개층을 거치지않고 hdfs와 직접 통신
- 하이브 처럼 하이브쿼리언어를 사용한다
- 하이브는 자바로 만들어 졌지만 임팔라는 c++기반으로 만들어졌다.
- 별도의 실행엔진을 사용하므로 맵리듀스 프로그래밍을 할 필요가 없다.
- 맵리듀스와 달리 쿼리를 아주 낮은 지연속도로 처리 가능하다. 맵리듀스의 셔플링 단계를 거치지 않아 테이블 간의 조인 작업도 반드시 맵리듀스 처럼 다대다ㅣ 커뮤니케이션을 요구하지 않는다.
- 클라이언트 : 테이블 관리, 데이터 조회
- 메타 스토어 : 분석할 대상 데이터들의 정보 관리
- 임팔라 데몬 : sql 질의
- 스테이트 스토어 : 상태(장애) 체크
- 스토리지 : 데이터 저장 , Hbase/HDFS 지원
클라우드 인프라 기술
-클라우드 컴퓨팅 ( SaaS, PaaS,Iaas)
: 동적으로 확장할 수 있는 가상화 자원들을 인터넷으로 서비스 할 수 있는 기술
- 서버 가상화 기술
: 물리적인 서버와 운영체제 사이에 적절한 계층을 추가해, 서버를 사용하는 사용자에게 물리적인 자원은 숨기고 논리적은 자원만을 보여주는 기술
-cpu 가상화 기술
: 하나의 서버의 운영체에 안에, 또 하나의 가상 머신을 만들어 마치 서버가 여러대 있는 것처럼 시스템을 구축하여 운영할 수 있는 기술