Hybrid & Logical Data Warehouse

1. 1
Hybrid / Logical Data Warehouse
1. 배경
2. 전체 Architecture
3. ODS Layer – Hbase
4. DW Layer – Hadoop / DM Layer – RDB
5. ETL – Stream & Mapreduce to Multi Target
6. 고려사항
7. 추가 고려 필요 사항
양흥순, hsyang76@hotmail.com

2. 2
1. 배경
ODS와 Data Mart가 통합된 환경의 문제점을 해결하는, 최적화된 방안을 찾기 위함
요건 현황 및 문제점 해결 방안
1. 시간별 배치 리포팅
2. 리포팅 결과로 부터 Drill
Down 가능해야 함
3. 문제 발생시, 장기간의
데이터에 대한 탐구적
데이터 탐색이나 데이터
마이닝도 함
현황
1. ODS와 Data Mart를 통합한,
Hourly Data Mart로 구성
2. 상용 MPP DBMS 도입
문제점
1. Hourly Batch를
만족시키려고, Data Mart의
부하 제약함
- 짧은 기간의 데이터 보관
- 사용자 직접 쿼리 제한
2. 데이터 탐색 등에 필요한
원천 데이터 전체를
보관하지 못함
- 원천+시계열 형태의 DW
없음 (용량/처리시간)
3. 상용 MPP RDBMS의 용량
한계 및 비용
저렴하고, Scalable한 대용량
데이터 관리/처리 Infra
데이터 처리/활용 패턴에 따른
정보계 Layer 구분
+=
Hybrid / Logical
Data Warehouse

3. 3
2. 전체 Architecture
기존 통합형 DW에 비하여, 분석계의 Layer의 데이터처리/활용 패턴에 따라 별도의 Infra를
사용함. 또한 데이터의 처리 방법이 SQL 에서 벗어남에 따라, 데이터 흐름에 변화가 있음
전체 Architecture
Source ETL 1차 - Stream ODS - Hbase
DM - RDB
탐구DW/Archive - Hadoop
Data 활용
.
.
.
.
수집 Stream
ODS 가공
DM 가공
DW/Archive
가공
2차 요약 (선처리)
2차 요약
Daily Merge
Formatting
BI
( OLAP / Data
Discovery )
Direct Access
/ User-
Developed
App
Fixed
Format
: Critical Path
ETL - 전송 타영역
: Daily/Hourly Batch
Hive

4. 4
중소규모 데이터의 빠른 처리, Key 를 이용한 Query/Join, Update 를 위해 NoSQL 활용
ODS Layer 의 모델링 (DM Layer와 비교)
3. ODS Layer - Hbase
Why Hbase for ODS
Why Not
Hadoop
1
• Hourly Batch의 처리를 위해 중소규모
데이터에 최적화 필요
2
• 특정 시간 구간 내의 데이터 처리 뿐만
아니라, Key를 이용한 Query/Join 을
빠른 시간에 처리해야 함
3 • 레코드 Update 처리가 되야 함
Why Not
RDB
1
• 대규모 MPP 가 가능하면서, Columnar
를 동시에 지원
2 • 상용대비 저렴
3
• 정형 Online Reporting에만 사용할
것이므로, SQL의 편이성이 필수가
아님
기존의 DM /w RDBMS :
데이터 용량 및 SQL 처리의 편의를 고려한 지표별
Subset의 구성. 데이터 조회시 다시 Join
원천 테이블
주문이력공통이력 반품이력
ODS /w Hbase :
Columnar 특성 및 Java Application 특성을 고려
한 비정규화
SQL1 SQL2 SQL3
원천 테이블
주문속성공통속성 반품속성
Java Stream App
- 원천 조회
- 공통속성 구하기
- If (초기주문) then 주문속성 구하기
- if (반품) then 반품속성 구하기
- 데이터 입력
Hbase Coprocessor
or
Mapreduce

5. 5
DW Layer는 고급사용자의 제한된 접근이나, Archive 용도를 감안해 저렴한 Hadoop으로 구성.
DM Layer는 대부분의 EUC 및 다른 시스템의 데이터 제공을 원활하게 하기 위하여, RDB 활용
DW Layer 의 모델링 및 데이터 처리 고려사항
4. DW Layer – Hadoop / DM Layer – RDB
Why RDB for Data Mart
공통 1
• 사용자나 다른 Tool에서 친숙한 SQL
(Complex SQL 포함) 을 지원해야 함
Why Not
Hadoop
1
• 많은 사용자의 중소규모 조회가 많을
것이므로, Response Time 중요
2
• Multi-path Report 의 경우도 유연하게
대응해야 함
Why Not
Hbase
1
• Online Reporting에 영향을 완전히
배제하기 위함
2
• 타영역에서 데이터 추출 및 Join을
쉽게 하기 위함
 단, 타 시스템 연동 지연을 최소화 하기 위하여,
1차요약 데이터는 Stream으로 전달
원천테이블
계약ID
이력발생일시
이력속성
DW 파일
계약ID
유효시작일시
유효종료일시
이력속성
• 데이터 분석시 성능/편의를 위해서
선분이력으로 구성 필요
• 하지만 선분이력의 경우, 이전
레코드의 유효종료일시를 Update 를
해야 함
• HDFS 특성상 Update는 처리 비용이
크기 때문에 Daily 로 처리해야 하며,
Update할 최소한의 Partition을 찾는
로직을 구사해야 함
 여기서 DW는 일반적인 DM의 Source 역할이
아닌, 탐구용/Archive용에 더 가까우며,
Inmon의 ER Style 임

6. Stream을 이용하여, 추출과 동시에 일부 로직을 처리하여 Batch Time 줄임. 유사한 데이터가
ODS와 RDB에 양쪽에 적재되지만, 로직은 한 군데만 두어 통합성 유지
5. ETL – Stream & Mapreduce to Multi Target
Stream 처리 예시
ETL 1차 - Stream
수집 Stream
ODS 가공
DM 가공
DW/Archive
가공
ODS -
Hbase
주문이력 검사
직전 주문시간을 구해야 하는 주문이력인가?
직전 주문시간 속성 셋팅
직전 주문시간이 Stream 상에 있는가?
Stream 에서 직전
주문이력 정보 가져옴
ODS에서 직전
주문이력 정보 가져옴
ODS 입력DM가공 Stream 에 전달
DM –
RDB
직전 주문시간이 구해져 있는가?
DM_주문시간
테이블입력
Case 1 : 대용량 Stream과 작은 용량의 마스터만 Join 해서
처리 가능한 로직
 마스터를 Stream 내 Memory로 Load해서 처리
Case 2 : 대용량 Stream 간 Join이 필요하지만, Join 되는
데이터의 시점차가 거의 같은 경우
 일단 Stream 내에서 Join 하고 없는 경우만 별도로
모아서 DB에서 찾아옴
Case 3 : 대용량 Stream 간 Join이 필요하고, 데이터간 시점차도
큰 경우
 일단 Hbase 에 넣고, 2차로 배치 처리

7. 아키텍쳐 구성시, 다음과 같은 사항을 고려했음
6. 고려사항
추가 고려 필요 사항
1 Why Stream
• 특정 시점의 이력데이터와 비교적 작은 데이터 (주로 마스터) 만 가지고 처리할 수 있는 로직의 경우는 추출하면서 동시
처리해서, Batch 부하를 분산하고, Delay Time을 줄임
• 최대 결과를 Async로 3곳에 씀 (hbase, hadoop, rdb)
2 Why Hbase
• 서로 시점 차가 나는 데이터를 key를 통해 조인해야 하는 경우를 위함
• hadoop의 sequential search의 경우 partition 할 기준도 없으므로 느릴 것임
• in-memory db 의 경우는 메모리의 제한으로 힘들 것임
• 그럼 병렬처리 가능하면서 Free인 거는 결국 hbase
3 Why Hadoop
• 데이터 탐색/마이닝의 경우 처럼 한 번에 큰 데이터를 처리해야 할 때는, memory cache가 오히려 불리
• Archive 의 역할도 해야 하므로, 저렴해야 함
4 Why 3 Cluster
• 데이터 탐색/마이닝의 부하와 online reporting 부하를 분리하기 위함
• Hadoop 2.0 은 online/batch를 다 지원하지만, 그건 사실 오라클/DB2 등 범용 DBMS도 마찬가지임
• OLTP/DSS를 모두 지원하지만, 그렇다고 그 두 업무를 한 instance 에 담는 것이 오히려 비효율적일 수 있음
5 Why 1 ODS • 데이터의 통합 및 교환 리포팅 고려
6
Why RDB for
Mart
• hbase + hive : 혹시나 online reporting에 장애 줄까봐 피함
• hadoop + hive : 그래도 마트는 많이 활용되는 편일 텐데, hadoop 으로 느리게 볼 필요 없음. 특히 다단계 리포트
• 제일 좋은 거는, 여러 Tool에서 지원하고 (SQL), 데이터의 처리와 조회를 병렬로 수행가능하고, 컬럼베이스인 DBMS  Vertica?
HANA?

8. 아키텍쳐 구성시, 다음과 같은 사항을 고려했음
6. 고려사항 - 계속
추가 고려 필요 사항
7
Stream 결과를
어디에
보관하지?
• Stream에서 재사용 할 건 : Online Reporting 에 Critical 하므로 ODS – hbase에 보관
• online reporting에서 쓸 건 -> 부하의 분리를 위해서는 hbase가 유리. drill down을 위해서는 RDB가 유리 (위 질문과 상통함)
- 대부분 2차 요약 마트를 가지고 online reporting 함
- 리포트의 특성상 한 데이터셋을 여러 리포트에서 쓰므로, hadoop은 좋지 않음
- 어차피 hbase에서 데이터를 꺼내서 요약한 후 다시 써야 하니, 다시 쓸 때 hbase/RDB 양쪽에 씀 (요약했으니 데이터 량은
크지 않을 것임)
- online reporting은 hbase 꺼를 가져다 쓰고 (Hive? Hbase framework?), 비정형은 동일한 데이터를 RDB에서 보게 해줌
• online reporting은 아니지만, 다른 영역 (ex. Non-Hadoop analytic systems)에서 쓸 건?
- hbase꺼를 그대로 쓴다면, 서로 조인 할 때 힘들 거고, RDB로 옮긴 다음에 쓸꺼면 IF타임이 걸림..
- 결국 RDB에도 적재하되, stream 화 해서 IF타임을 줄임
8
2차 요약작업
방법은?
• map reduce? 딴 거 있나?
• 성능이 중요하다만, Hive로 하는 경우는 거의 없을 것임. 성능을 위해 custom MR (job 병합 등) 을 쓸 개연성 높음
• 선처리를 위해서 hbase 내에서 coprocessor 쓰는 것도 고려 필요

9. 다음과 같은 추가 고려 필요 사항이 있음
7. 추가 고려 필요 사항
추가 고려 필요 사항
1
• 오류나, 신규 서비스/속성의 초기적재 로 인한 재적재 방안
• 어느 소스에서 어떤 PGM으로?
2 • PM 을 포함한 장애시 Catch-Up 방안
3
• ROI 산정 방안
- 성능 : 성능은 일단 기존과 동일하게 맞춘다고 가정
- 구축비용 – Infra : 기존 RDB에서는 ETL 부하가 빠지므로 그 만큼 라이선스 비용 감소. 대신 Bigdata Platform 비용이 들어감
- 구축비용 – 공수 : RDB로 유지시 보다 Bigdata Platform 전환이 비용이 클 것임
- 정성적 : 사용자가 직접 고급 분석을 할 수 있는 토대가 마련됨
- 관리비용 : Infra 유지보수 비용 위주. 분명 Bigdata platform 이면 유지보수 인원 측면에서도 multi-skill 이 되야 하지만, 이건 결국
나중에는 다 돼더라..