데이터 연계 및 통합 기법
더 많은 작업
- Data Integration Techniques; 데이터 연계·통합 기법
- 흩어진 여러 시스템의 데이터를 한곳으로 모으거나 시스템끼리 주고받게 하는 방법들을 통합 주기(일괄·실시간)와 방식(동기·비동기)에 따라 정리한 것
기업의 데이터는 업무 시스템마다 따로 만들어지고 저장된다. 이를 분석에 쓰거나 다른 시스템이 함께 쓰려면 데이터를 옮기고, 형식을 맞추고, 같은 대상을 가리키는 값을 하나로 묶어야 한다. ADP 필기 2과목 '데이터 처리 프로세스'는 ETL, CDC, EAI를 하나씩 다룬 다음 '데이터 연계 및 통합 기법 요약'에서 이들을 한데 놓고 비교한다. 이 문서는 그 요약 부분에 해당한다.
데이터 통합 기법은 크게 두 축으로 나눠 볼 수 있다.
- 언제 옮기는가: 정해진 주기에 모아서 한꺼번에 옮기는 일괄(배치) 통합과, 변경이 생기는 대로 곧바로 옮기는 실시간 통합
- 어떻게 주고받는가: 보낸 쪽이 응답을 기다리는 동기식과, 메시지를 넘겨 두고 다른 일을 계속하는 비동기식
| 구분 | 일괄(배치) 통합 | 비동기식 근접 실시간 통합 | 동기식 실시간 통합 |
|---|---|---|---|
| 처리 시점 | 하루 1회 등 정해진 주기에 모아서 처리 | 변경 직후 짧은 지연을 두고 처리 | 요청 즉시 처리하고 결과를 바로 돌려받음 |
| 데이터 단위 | 대량(테이블 전체 또는 기간 단위) | 변경된 건 또는 작은 묶음 | 건 단위 트랜잭션 |
| 대표 기술 | ETL, 파일 전송, 스쿱 같은 대량 적재 도구 | CDC, 메시지 큐, 게시-구독 방식의 메시징 | EAI·ESB를 통한 서비스 호출, 동기 API |
| 장점 | 대량 처리에 효율적, 원천 시스템 부하를 한가한 시간대로 미룰 수 있음 | 원천과 대상이 서로 기다리지 않아 결합도가 낮음, 최신성 확보 | 데이터 일관성과 즉시성이 가장 높음 |
| 단점 | 다음 주기까지 데이터가 늦음 | 순서 보장·중복 처리 등 설계가 필요 | 상대 시스템이 느리거나 멈추면 함께 영향을 받음 |
| 주 용도 | 데이터 웨어하우스·데이터 마트 적재, 일·월 단위 리포트 | 실시간 대시보드, ODS 갱신, 시스템 간 데이터 복제 | 주문·결제처럼 즉시 결과가 필요한 업무 연동 |
배치와 실시간은 둘 중 하나만 고르는 문제가 아니다. 대용량 이력은 배치로 적재하고, 그 사이에 생기는 변경분은 CDC로 따라잡는 식으로 함께 쓰는 경우가 많다. Oracle 데이터 웨어하우징 문서도 적재 기술이 발전하면서 변경분을 조금씩 계속 흘려 넣어(trickle-feed) 데이터 웨어하우스를 근접 실시간으로 갱신할 수 있게 되었다고 설명한다.
- 동기(synchronous): 호출한 쪽이 상대의 처리 결과를 받을 때까지 기다린다. 결과를 바로 확인할 수 있지만, 상대가 느려지면 호출한 쪽도 함께 느려진다.
- 비동기(asynchronous): 메시지를 큐나 브로커에 넣어 두고 바로 다음 일을 한다. 받는 쪽은 자기 속도로 꺼내 처리한다. 결합도가 낮고 장애가 번지지 않지만, 전달 보장·순서·중복 처리를 따로 설계해야 한다.
| 구성 요소 | 역할 | 처리 방식 | 데이터 성격 |
|---|---|---|---|
| ETL | 원천에서 추출(Extract)하여 변환(Transform)한 뒤 대상에 적재(Load) | 주로 일괄. 대상 DB 안에서 변환하는 ELT 방식도 있음 | 정제·통합된 분석용 데이터 |
| CDC | 원천 데이터의 변경(삽입·수정·삭제)만 찾아내 대상에 반영 | 근접 실시간 또는 짧은 주기 | 변경분(이벤트) |
| EAI | 업무 애플리케이션끼리 데이터와 프로세스를 연계 | 실시간(동기·비동기 모두) | 업무 트랜잭션, 메시지 |
| ODS | 여러 원천의 현재 데이터를 정제·통합해 두는 운영 데이터 저장소 | 실시간 또는 짧은 주기로 갱신 | 현재 시점 위주, 이력은 짧음 |
| 데이터 웨어하우스 | 분석과 의사결정을 위한 통합 저장소 | ETL로 주기적 적재 | 주제 중심, 통합, 비휘발, 시간에 따라 변하는 이력 데이터 |
Oracle 문서에 따르면 ODS는 일상 업무를 지원하기 위한 저장소로, 데이터는 정제·검증되어 있지만 이력이 깊지 않아 당일 데이터만 두기도 한다. ODS는 아직 데이터 웨어하우스에 적재되지 않은 최신 데이터를 볼 수 있는 곳이자, 데이터 웨어하우스 적재의 원천으로도 쓰인다. 데이터 웨어하우스의 특징으로는 인먼(William Inmon)이 제시한 주제 지향(Subject Oriented), 통합(Integrated), 비휘발(Nonvolatile), 시간 가변(Time Variant)이 흔히 쓰인다.
EAI는 애플리케이션을 어떻게 연결하느냐에 따라 다음과 같이 나눈다.
| 방식 | 구조 | 장점 | 단점 |
|---|---|---|---|
| Point-to-Point | 애플리케이션끼리 일대일로 직접 연결 | 연결이 적을 때 빠르고 단순함 | 시스템이 n개면 연결이 최대 n(n−1)/2개로 늘어 관리가 어렵고 재사용이 안 됨 |
| Hub & Spoke | 가운데 허브(중개 서버)가 모든 연결을 맡고, 각 애플리케이션은 허브에만 연결 | 연결 수가 줄고 관리가 한곳에 모임 | 허브에 부하가 몰리며, 허브가 멈추면 전체 연계가 멈춤(단일 장애점) |
| Message Bus(ESB) | 애플리케이션 사이에 공통 버스(미들웨어)를 두고 어댑터로 연결 | 확장성이 높고 대용량 처리에 유리, 표준 기반 서비스 연계 | 구축이 복잡하고 비용이 큼 |
| Hybrid | 그룹 안은 Hub & Spoke, 그룹 사이는 Message Bus로 묶음 | 필요한 곳에 맞는 방식을 골라 씀 | 설계·운영 복잡도 증가 |
ADP 교재(데이터분석 전문가 가이드)는 EAI 구현 유형을 조직 내부의 정보 시스템끼리 연계하는 Mediation(intra-communication) 방식과, 외부 정보 시스템과 데이터를 주고받는 Federation(inter-communication) 방식으로도 나눈다. ESB는 메시지 버스 방식을 서비스 지향 구조로 발전시킨 것으로, 자세한 내용은 ESB 문서를 참고한다.
| 구분 | 전통적 데이터 통합 | 빅데이터 환경의 데이터 통합 |
|---|---|---|
| 주 대상 | 관계형 DB의 정형 데이터 | 로그, 텍스트, 센서 데이터 등 비정형 데이터와 반정형 데이터까지 포함 |
| 규모 | 기가바이트~테라바이트 수준의 업무 데이터 | 테라바이트~페타바이트 이상, 계속 쌓이는 스트림 |
| 스키마 | 적재 전에 정해 둔 스키마에 맞춰 변환(스키마 온 라이트) | 원본을 먼저 저장하고 읽을 때 구조를 해석하는 방식도 많이 씀(스키마 온 리드) |
| 저장소 | 데이터 웨어하우스, 데이터 마트, ODS | 하둡 분산 파일 시스템, NoSQL, 데이터 레이크 |
| 수집·연계 도구 | ETL 도구, CDC, EAI | 플럼 같은 로그 수집기, 스쿱, 카프카 같은 메시징 시스템 |
| 처리 방식 | 단일 DB 서버의 SQL 처리 중심 | 맵리듀스, 스파크 같은 분산 병렬 처리 |
빅데이터 환경이라고 전통적 기법이 사라지는 것은 아니다. 비정형 데이터에서 뽑아낸 결과(예: 로그에서 집계한 지표, 텍스트에서 추출한 감성 점수)는 다시 정형 데이터가 되어 데이터 웨어하우스나 데이터 마트에 ETL로 적재되기도 한다. 대용량 비정형 데이터를 모으고 처리하는 방법은 대용량 비정형 데이터 처리 문서에서 다룬다.
- 일괄(배치) 통합, 비동기식 근접 실시간 통합, 동기식 실시간 통합의 차이와 각각에 어울리는 기술(ETL, CDC, EAI)을 짝지을 수 있어야 한다.
- EAI의 Point-to-Point, Hub & Spoke, Message Bus, Hybrid 구성 방식의 장단점, 특히 Point-to-Point의 연결 수 증가와 Hub & Spoke의 허브 단일 장애점 문제가 자주 묻는 내용이다.
- ODS(현재 데이터, 짧은 이력, 운영 지원)와 데이터 웨어하우스(이력 데이터, 분석 지원, 주제 지향·통합·비휘발·시간 가변)를 구분한다.
- 전통적 통합은 정형 데이터와 사전 스키마 중심, 빅데이터 환경은 비정형·대용량 데이터와 분산 처리 중심이라는 대비를 기억한다.