Introduction Data Warehouse Based on IBM DB 2

Agenda 1. What is Data Warehouse? 2. Trends of Data Warehouse 3. Real-time Data Warehouse 4. DW Architecture by IBM 5. Parallel Database 6. Case Study : KT EDW

1. What is Data Warehouse? Naver 지식 검색을 활용하세요! 데이터 웨어하우스는 1980년대 중반 IBM이 자신이 하드웨 어를 판매하기 위해 처음으로 도입했던 개념으로 IBM은 인포메이션 웨어하우스(Informationn Warehouse)라는 용어를 사용하였다. 이후 이 개념은 많은 하드웨어, 소프트웨어 및 툴 공급 업체 들에 의해 이론적, 현실적으로 성장하였으며, 1980년대 후 반 Inmon이 데이터 접근 전략으로 데이터 웨어하우스 개념 을 사용함으로써 많은 관심과 집중을 받게 되었다. - From Naver 지식in

OLTP vs. Data Warehouse 트랜잭션 시스템 데이터웨어하우스 OLTP(On-line Transaction Processing) OLAP(On-line Analytical Processing) 반복되는 단위업무처리(거래처리) 신속한 거래처리 의사결정지원(ad-hoc query) 대량의 정보관리 매우 빠른 속도로 데이터 량 증가 업무별 정보 주제영역별 정보 현행정보(Current Values) 이력정보(Historical Snapshots of Data) 상세정보 + 요약, 집계, 외부정보 1~2 초 내의 Response Time Several seconds to minutes “Run your business” “Analyze your business”

Data Warehouse… §Query only, no updates, no transactions - Optimized for Retrieval §Data refresh at regular intervals §Separate from OLTP apps –OLTP: “Run your business” –DW: “Analyze your business” –Oriented toward a specific business function §Historical snapshots of data §Potentially rapid data growth - Scalability critical!

Data Mart… §Subset of an existing data warehousing §Narrower business function §Query only, no updates, no transactions - Optimized for Retrieval §Data refresh at regular intervals §Separate from OLTP apps –OLTP: “Run your business” –DW: “Analyze your business” –Oriented toward a specific business function §Highly summarized data §Historical data

DW, DM Query … Select product, market, customer… , sum(revenue), sum(margin) … from sales, product, market, customer. . . where date between 01/01/2002 and 12/31/2002 납부 and market. state in (‘서울’, ‘경기’) 험료는 보 ? 주소는 이번 달 and customer_age in (18 to 34) 고객의 고객이 group by product… 567의 이라는 4 ” 은? 6 -123 ü“갑돌 의 내역 order by customer… ; 12345 보험 번호 는 모든 민등록 ü주 고있 가입하 ? 객이 했는가 번의 고 101 객번호 ü고 ü고객들이 정말로 선호하는 것은 무엇인가? ü지난 5년간 고객들의 구매 패턴은 어떻게 변해왔는가? ü작년에 각 지역별로 가장 많은 이익을 남겨준 제품은 무엇인가? ü각 지역별로 top 10에 드는 고객은 누구인가? ü분기별로 각 벤더들의 제품에 대하여 매출액, 비용, 순이익은 얼마인가?

Star Schema Customer Dimension customer code customer name age gender address company income level education …… (수백만 건) Store Dimension store code store name store type street state …… (수백 건) Time Dimension Fact Table : Sales time code product code store code customer code revenue cost unit_sold net profit quantity …… (수십억 건) time code order date month quarter year …… (수백 건) Product Dimension product code product name product type vendor name …… (수천 건) §Fact table : dimensional model의 중심, measures, how much or how many §Dimension tables : what, where, when

DW 개발 단계 üThink big üBuild small üVerify success against success criteria Analysis interview를 한다 üexecutive, manager, business analyst, end user ü기본 report üDW에 기대하는 요구사항 üScope 결정, requirement 정의 ü포괄적으로 data가 모두 사용 가능한 가? 제시간 안에 data를 얻을 수 있는가? ü필요한 H/W, S/W 사양은? ü필요한 Design ü주제 영역을 정한다 ümeasure/dimension 정의 üfact table의 구성요소 정의 üDimensional model 생성 ü사용자들과 함께 model 확정 üPhysical model 생성 시연 & feedback 사용자들에게 DW와 개 발된 프로그램 소개 üFeedback üTuning üRecovery plan ü일정 Data gathering ü데이터 추출 ü데이터 cleansing ü데이터 변환 ü데이터 로드 Implement üQuery prototype 실행 및 tuning üBI 툴을 사용한 개발 ü필요한 application 개발

DW의 구축 효과 기업 경영상의 효과 최종사용자 부문의 효과 ü기업 ü전산부서 경쟁력 향상 일관성 있는 정보제공 ü사용자에게 직접 정보제공 ü정보자산의 효율적 이용 ü새로운 시장기회 발견 ü의사결정정보에 관한 전산실 업무 감소 ü양질의 정보제공 üBusiness Process Reengineering ü과거 정보시스템 리엔지니어링 ü하나의 의존도 감소 편리성 ü원하는 정보에 신속하게 접속 ü다양한 분석 수행 ü워크그룹 생산성 증대(업무 프로세스 개 선) ü환경변화에 신속하게 대응 ü사용의 Data Warehouse 효과 정보기술 부문의 효과 üOLTP 시스템 작업량 감소 프로그래밍 작업량 감소 ü보고서 생성 작업량 감소 ü유지보수 비용 절감 ü기 투자된 시스템 가치 상승 üSQL

2. Trends of Data Warehouse

Top 5 trends …. BI Becomes: Pervasive Just in time The driver of action Maximize Business Insight Mission Critical & Essential Forward looking

Trend #1 – BI Becomes “Pervasive” § 조직이 보다 많은 사용자들의 다양한 업무수행을 위해 BI가 활용될 수 있기를 기대 § 비즈니스 일선에 좀 더 자세하고 수행 가능한 정보를 제공 § 아주 전문적인 분석가나 BI 전문가가 아니더라도 쉽게 사용될 수 있는 insight를 요구 • § Eclipsys Health Systems – 환자 침대 옆의 컴퓨터들이 a) 이젠 데이터베이스와 연결되어 환자의 상세정보 조회가능 BI가 병원의 더 이상 별도의 영역이 아니라 업무 수행의 모든 b) 여러 병원의 데이터베이스와도 연결되어 치료 정보와 결과를 제공 영역에 스 며들어 별도로 분리할 수 없게 됨. • Monaco Cardio Thoracic Centre – 아주 상세한 환자의 레코드들과 예정된 절차, 치 료과정 등을 조회 • Staples – 재고 관리, 상품간의 제휴, Cross Sell과 Self Service 채널 등

Trend #2 – BI Becomes “Just-in-time” § 가장 최근의 정확하고 개인화된 데이터를 기반으로 비즈니스 insight 제공. § 의미 있는 정보가 어떤 device를 통해서나 어느 곳으로나 바 로 전달될 수 있게 됨으로써 정보의 가치를 극대화하도록 기 대 • Pepsi – “on the fly” 배달 트럭의 경로를 결정함에 있어 가 장 수익성있는 배달 경로를 적시에 발견

Trend #3 – BI Becomes the Driver of Actions § BI와 analytics가 비즈니스 프로세스와 작업의 흐름에 바로 결합되어 짐 - 조직의 DNA와 같은 일부가 됨. § Analytics를 operational 시스템과 연계하여 insight와 비즈니스 수행 사이의 Closed loop cycle을 형성. § 이 insight를 활용하여 비즈니스 전략과 수행을 가이드 • Bank One – 지점의 수익성 시스템이 핵심적인 관리 도구가 되어 직원들의 업 무수행과 보너스를 결정 • Nieman Marcus – 여러 상점들의 재고 관리 시스템이 요구에 따라 각 지역 branch 들 사이의 상품의 흐름을 제어. • Home Deport – 고객, 재고, 수익 그리고 employee들의 관리를 도울 수 있는 광범위한 enterprise system • Credit Union Of Texas – “CEO Flight Deck” 고객, cross-sell/up-sell, 캠페인의 효과를 추적하고, spatial dimensions도 분석 가능

Trend #4 – BI Becomes Forward Looking § 단순히 레포팅과 분석의 범위를 넘어서 BI는 predictive modeling으로 발전되고 있음. § 향후 데이터 마이닝이나 패턴인식과 같은 차원 높은 분석기법에 대한 관심과 기대가 증대될 것임. § 의사결정 프로세스가 실제로 데이터를 기반으로 한 expert 시스템과 통합. – 콜센터에서 수집된 voice 데이터의 마이닝을 통해 안 • Ford 전에 대한 이슈와 recall등을 예측 • Boots The Chemist (UK) – 스마트 카드 로열티 프로그램이 수익성있는 고객을 확보할 수 있게 함

Trend #5 – BI Becomes Mission Critical & Essential § BI 솔루션이 비즈니스 수행과 성공 그리고 경쟁우위를 점할 수 있는 비즈니 스의 핵심이 되고 있음. § BI 아키텍처가 보다 강력하고 확장성이 보장될 수 있도록 기대되고 있음. § 수 terabytes의 데이터를 다루고 수천 명의 사용자들이 사용하며, 24*365의 가용성이 요구되고 있음. § 진취적인 조직은 필요한 정보를 비즈니스 사용자에게 “push”함으로써 신속 함과 융통성 그리고 결단력을 확보 • Sprint PCS – 100 TB 데이터 웨어하우스 운영; 전사 데이터 웨어하우스가 단순한 분석 시스템이 아니라 비즈니스 수 행과 고객 billing을 위한 핵심 시스템. 만일 DW가 down되면 기업으로서는 ‘money’를 잃게 되는 심각한 상 황을 초래. 기본 애플리케이션과 비즈니스 인텔리전스 정보의 사용이 더 이상 경쟁 우위의 요소는 아님. 고객, 투자자, regulators, 임원과 emploees들이 이미 자연스러운 것으로 인식되고 있음

What’s on the minds of 450 of the world’s leading CEOs? CEO 요구사항 CIO 고민들 § 비용절감으로 인한 매출성장 § IT 와 비즈니스의 결합으로 매출증대 와 비용절감의 목표달성 § Key competency: responsiveness § Critical success factor: effectiveness 확보 - people and processes Source: CEO Study of 456 WW CEOs IBM Corporation - Feb 2004 § IT를 통하여 조직의 역할을 지원 § 어떻게 IT가 사람들과 팀 이 좀 더 효 과적으로 일할 수 있도록 도와줄 것인 가? Source: Operating Environment Market Drivers Study, IBM Corp. 2004

Business Intelligence is evolving… BI used to employ the following fundamentals: Yesterday …. . Going back as much as 15 years § Batch로 Data Warehousing updates § Data marts, Warehouse, Transaction Systems과의 분리 § Point in time BI § Stand alone 웨어하우스; 불완전한 EDWs 원인 : 기술적인 제약, 기능적인 제약, best practices의 부족 Focus: 완벽한 data warehouse 구축

Business Intelligence is evolving… Today’s cutting edge warehouses raise the bar: Yesterday …. . Going back as much as 15 years Today § Batch로 Data Warehousing updates § 보다 빠른 데이터 제공과 성능 향상 § Data marts; Warehouse , Transaction Systems과의 분리 § 통합, 데이터의 중복 감소 § Point in time BI § Stand alone 웨어하우스Real-time 가용성을 통한 이벤트 모니터링 § ; 불완전한 EDWs § Unstructured 데이터를 포함하여 보다 부족 원인 : 기술적인 제약, 기능적인 제약, best practices의 많은 데이터 소스의 데이터를 통합, Focus: 완벽한 data warehouse 구축 Focus: true Business Intelligence

Business Intelligence is evolving… Unveiling opportunities to significantly change the way you do business Yesterday Today What this means § Batch로 Data Warehousing updates • 보다 빠른 데 이터 제공과 성능 향상 § 가치있는 가공되지 않은 데이터의 사용 증가 § 현재 필요한 데이터에 바로 분석하여 비즈니스 수행 § 배치 시간의 감소 § Data marts; Warehouse , Transaction Systems과의 분리 § 통합, 데이터의 중복 감소 § 복잡성의 감소 § 비용의 감소 § data inconsistencies 감소 § Real-time 가 용성을 통한 이벤트 모니터 링 § 즉석에서 당일의 정보를 획득하여 즉시 조치 § “Intelligent”의 변화(주기적인 특성 등)를 알 필요가 있음 § Unstructured 데이터를 포함 하여 보다 많 은 데이터 소 스의 데이터를 통합, § 분산된 데이터에 접근 § 낮은 리스크와 EDW와 관련된 비용 § 통합된 마이그레이션 경로 개발 § Point in time BI § Stand alone 웨어하우스; 불완전한 EDW

Insight e iv t ac ro p § 많은 데이터 소스로부터 데 이터와 컨텐트를 통합 § 데이터를 유용한 정보로 전 환 ac tiv e Information § 이 정보를 실시간 분석으로 intelligent하면서도 신속한 Data ss iv e 의사결정을 지원 pa Business flexibility & responsiveness Information On Demand - 데이터를 Business Insight로 Business value

3. Real-time Data Warehouse

실시간(Real time) & 준 실시간(Near Real time) § 절대적인 시간이라기 보다는 고객의 환경에 따라 새로이 정의되어야 함 § 데이터가 발생한 후 정보로서 처리되는데 걸리는 시간으로 구분 – 실시간 : 현재의 비즈니스 상태를 반영한 새로운 데이터를 기업 정보로 처리 – 준 실시간 : 현재 발생하는 비즈니스 데이터는 아니지만, 그 기업에 “충분히 신선 한(fresh enough)” 데이터를 기업의 정보로 처리 source: META, Applied Analytics for Extreme Business Performance Management, 25 September 2002

분석을 위한 데이터의 latency? < 1 second Not sure 16% <1 day 6% 6% <1 minute 16% 1시간 미만이 절반이상 21% 30% 11% < 12 hours < 1 hour N=419 Source: Colin White & The Data Warehousing Institute, Building the Real-Time Enterprise, Oct 2003

실시간 BI 를 개발하거나 개발 계획이 있는 분야? Source: Cutter Consortium: Corporate Use of Real-Time Data Warehousing By DMReview. com Web Editorial , July 29, 2003

리얼타임 BI 어플리케이션 § 고객 접점 분석 – – 상점 내 ‘즉시 발행’ 쿠폰 – ATM 사용시 개인에 맞는 광고 – 고객 개인에 맞는 웹 사이트 광고 및 관심 분야 표시 – 최적화되고, 예측 가능한 공급망 유지 – § 온라인 콜센터 고객 스코어링 적시 재고 관리 및 모니터링 부정행위 적발 – ATM, 휴대 전화, POS § 항공기 티켓의 적정가격 결정 혹은 결항 비행편에 대한 차선 스케줄 결정 § 온라인 대출 신용정보 조회 § 통신/에너지 분야의 망 관련 정보 관리 § 열차, 트럭, 선박 화물의 적재 및 운송 관리

실시간 BI 동시 사용자 조회 병렬 ETL Engines ODS MQSeries queues 끊임 없는 적재 DB 2 Warehouse 복제 Information Integration 웹 서비스 개인화 , 데이 터 마이닝, 비즈니스 룰, 캠페인 경보, 트리거, KPIs, 분석 고객 Corporate Dashboards

ETL, EII, EAI App 2 App 1 EAI 인터페이스를 이용한 응 용 프로그램 간의 호출 방식 MQIn Formatti ng & Mapping Route. To. La bel App 3 MQOu t EII 비정형 데이터 “뷰”를 통한 단일한 가상의 데이터 저 장소 구성 응용 프로그램 ETL Data Mart Data Warehouse Data Mart … 데이터 복제 원시 데이터 소스 Data Warehouse Data Mart

ETL – 적재를 사용한 실시간 환경 - 지속적인 loading 과 사용자 쿼리를 동시에 수행 - 고속 적재를 지원 동시 쿼리 짧은 주기의 지속적인 ETL

EII를 사용한 실시간 환경 DB 2 Family 실시간 접근 DB 2/390 Sybase VSAM Data Warehouse DB 2 II Classic Federation IMS Informix DB 2 Information Integrator Software AG Adabas SQL Server CA-Datacom Oracle CA-IDMS IBM Extended Search … Biological Data And Algorithms Text XML Excel Web. Sphere MQ WWW, email, … Teradata … ODBC

EAI를 사용한 실시간 환경 - Queue를 사용하여 데이터의 실시간 전송 - IBM Websphere MQ 연동 function을 DB 2에서 제공 Source ETL DB 2 Oracle MQSI ETL Informix VSAM IMS DB 2 MQ Listener User Stored Procedure DB 2 MQ Data Warehouse function

ETL vs. EII vs. EAI – Strengths and Challenges 구분 ETL EII Strength § Extract, Transform, Load § Middleware 영역 § 여러 데이터 소스로부터 데이터를 추 출하여 변환하고 정제한 후 또다른 데 이터베이스 즉 DW나 DM, 혹은 비즈니 스 프로세스에 따라서는 또다른 운영 시스템에 적재 • Data. Stage 정의 § 분산되어 있는 다양한 종류의 데이터 소스를 마치 하나의 소스인 것처럼 단 일 뷰 제공 § structured data 처리 § structured data와 unstructured data(컨 텐트) 모두 처리 가능 § Batch 작업으로 처리 § 한 번에 대용량 데이터 처리 § 계산이나 집계, 또는 많은 단계를 거쳐 야 하는 복잡한 변환도 쉽게 작성 § 관리자에 의한 스케줄에 기반한 실행 § 대부분의 툴이 GUI 기반으로써 직관적 인 view를 제공하며 생산성이 높음 § 개발된 모듈의 재사용성이 높음 § impact analysis를 포함한 metadata 수 집과 관리가 용이 EAI • 조직 안팎에서 서로 다른 어플리케이 션 및 프로세스 사이에서 데이터의 이동 및 교환 가능한 솔루션 • Websphere MQ § Websphere Information Integrator § real-time으로 data read/write 가능 § 데이터 모델과 metadata가 생성되기 이 전에 데이터 탐색 가능 § remote source의 global access에 강점 § 성능, 예산, 가용성, 보안 등의 문제로 데이터의 이동이 어려운 데이터 또는 불필요한 데이터의 이동을 피하기 위한 데이터의 위치에 대한 관리 § 가상의 데이터 저장소 제공 § 분산 또는 복제, 물리적 통합 제공 § 통합 정보의 metadata 관리 § 새로운 데이터 소스에 대한 유연한 확 장성 제공 § Data Grid • 비즈니스 레벨의 프로세스 및 데이터 통합에 focus • 비즈니스 프로세스와 데이터의 재사 용 및 분배 • API 기반의 어플리케이션 • real-time 또는 near real-time • 개별적인 event 또는 트랜잭션 기반 으로 데이터의 이동이 일어남 • 간단하고 기본적인 변환 또는 데이터 그 자체만을 이동시키고자 할 때 강 점 • workflow의 컨트롤이 가능

ETL vs. EII vs. EAI – Strengths and Challenges 구분 Challenge ETL § 단방향의 데이터 흐름 § 소스 시스템의 데이터 변경에 대한 관 리가 어려움 § 많은 공간의 staging 영역이 필요함 ; 스토리지 낭비의 우려 § out-of-sync이므로 소스 데이터가 DW 에 도달하기까지의 시간이 오래 걸림 § 실제 사용 여부와 상관없이 데이터 이 동이 일어남 EII EAI § 데이터 변환의 제약 ; SQL 기반의 변환 • 여러 소스에 대하여 key를 match 시켜 야함 • 데 이 터 소 스 에 따 라 data type mismatch • 소스 시스템의 resource 사용 ; 소스 시 스템에 부하를 줄 수 있음 • 한 번에 수천~수만 레코드 처리 • 사용량이 많은 시간에는 network 부하 우려 • 데이터 변환의 제약 - 간단한 데이터 변환 • 데이터 집계 제약 • 트랜잭션 당 10여개의 레코드 이동 • 개발하기가 복잡함 • 변환 작업의 재사용의 어려움 • metadata 관리의 어려움 ; metadata 의 사용 및 import/export • Semantic integrity • 사용량이 많은 시간에는 network 부 하 우려 Fulfillment e-Commerce Marketing 비즈니스 응용 프로그램 ETL tool Integrated Information

ETL vs. EII vs. EAI – 기술적 관점에서의 비교 ETL EII EAI Data Flow • 단방향 – source to target • 양방향 Data 이동 시점 • 스케줄에 의한 Batch Job • Daily - Monthly • Query time - Query (SQL) managed • Real-time • Transaction triggered – 비동기식 • Transaction managed • (Near) Real-time 데이터 변환 및 정제 /Metadata 관리의 효율성 및 재사용성 • Best • 일반적으로 ETL Job 모듈 과 프로세스의 재사용성 이 높다 • Medium • 변환은 SQL 기반으로 이 루어지며, view 등의 database object를 이용하 게 된다 • Low • 변환은 ESQL 프로그램 기반으로 이루어지며, DB catalog 정보에 제한된 metadata만을 사용할 수 있다 데이터 이동 방법 • FTP 또는 direct database connection • Direct database connection • Messaging 한 번에 처리 가능한 데이 터 볼륨 • Very large • 수백만~수십억 레코드 이 상 • Medium • 수십만~수백만 레코드 • Small • 10여 레코드를 몇 개의 pipe를 통하여 처리 변환의 복잡도 • 매우 복잡한 변환도 쉽게 처리 • SQL로 처리될 수 있는 정 도의 복잡도 • 간단한 변환 • broker에 의해 구현 가능 한 semantic transformation에 제한됨

ETL Best Practices ETL tool § ETL은 일반적으로 대용량 I/O bound 작업 – 불필요한 staging step을 줄여주어야 함 – 속도가 빠른 storage 사용 – 뜻하지 않은 I/O를 피하라 – “lookup” 프로세스에 주의 – data file의 위치에 유의 § ETL 툴 사용시 생산성 및 데이터 일관성 향상 § data mart에서 data mart로 가는 작업은 피하는 것이 좋음 § 과도한 locking을 피해야 함 – 많은 수의 프로세스들을 병렬로 처리하는 것이 키 – Key to running many concurrent processes in parallel – Query, Load, Backup이 동시에 허용되어야 함

EII Best Practices F e Marketing -Commerceulfillment 비즈니스 응용 프로그램 Integrated Information § 일반적으로 규칙적이지 않은 ad-hoc 액세스에는 적합하지 않음 § 최상의 성능을 위해서 WII는 자주 사용되는 데이터를 캐쉬함으로써 query 실행 비용을 관리하도록 계획을 세움 § WII는 query의 종류와 비용을 관리 – DB 2 Query Patroller § remote source 사이에 많은 데이터의 이동이 발생하는 operation의 경 우 WII는 꽤 많은 시간이 소요될 것이다 – “permanent basis”에는 WII를 이용하여 “virtual warehouse” 구축을 시도하지 말라, 특히 ad-hoc 액세스가 일어날 것으로 예상되어진다면 더욱 그렇다 § remote 소스에 대한 federated query의 영향을 항상 염두에 두어야 한 다 – Remote data에 대해서는 target access § 데이터의 흐름은 remote 소스에서 federated server로 – 두 개 이상의 remote 소스에서 사이즈가 큰 테이블을 조인하는 것은 피하라

EAI Best Practices § Point-to-point 통합은 피하라 – 좀 더 나은 재사용성을 Hub와 broker 사용 § 어플리케이션 개발시 주의사항 – 선행되어야 할 내용에 대한 준비 및 계획이 필요함 – 연관되는 시스템에 미치는 영향도를 이해해야 함 – 데이터 흐름에 대한 시나리오 및 일어날 수도 있는 현상에 대한 이해가 필요 § 성능에 대한 모니터링 § workflow에서 데이터의 일관성과 성능에 대한 병목현상을 trace할 수 있도록 준비가 필요하다

실시간 BI 동시 사용자 조회 병렬 ETL Engines ODS MQSeries queues 끊임 없는 적재 DB 2 Warehouse 복제 Information Integration 웹 서비스 개인화 , 데이 터 마이닝, 비즈니스 룰, 캠페인 경보, 트리거, KPIs, 분석 고객 Corporate Dashboards

4. DW Architecture by IBM

전통적인 EDW framework BI Apps Application Data Marts Application Mart ETL / Replication EDW Data Warehouse ETL / Replication ODS Layer ODS ETL Operational systems ODS Issues: - 실시간 데이터 처리 난해 - 애플리케이션이 여러 레이어로 접속 - 처리 시간의 지연 - 전체 TCO 증가 - 변화가 어려움 - Network 부하 발생

통합 데이터 웨어하우스 아키텍처 BI Apps Application EDW Data Marts (LOB Apps) Application Logical and or Physical Mart layer Atomic Data (normalized) ODS / Staging Layer Benefit: ETL Operational systems - 실시간 데이터 처리 - 애플리케이션이 단일 레이어로 접속 - 필요에 따라 여러 레이어의 데이터 접근 - 처리 시간의 감소 - 전체 TCO 감소 - 변화에 대한 대처 용이 - Network 부하 감소 - 동적인 자원 관리

계층별 Data 아키텍처 L 5 량 터 이 데 L 3 1차 집계 요약 데이터 준 수 세 상 기간 터 이 보관 상위 Layer로 진행될 수로 데이터 량은 줄어듬 2, 3차 집계 데이터 마트 (요건 중심) 데 L 4 의사결정 데이터 및 L 2 L 1 주제영역별 사용자테이블 ( So. R -3 rd normal form) 원천 Raw 데이터, Staging & 사용자테이블 Rolling data EDW is an architecture, Not a database!! 상위 Layer로 진행 될수록 데이터는 요약되고 보관 기간이 길어짐

쿼리 성능의 저하 없는 동시 적재, 쿼리 수행, 유지보수 제공 다차원 OLAP 분석 (정형/비정형) 의사결정 데이터 다차원 모델 일별/월별 데이터 단계적 Recursive 정제 가공 수행 필요한 단계에 필요한 가공 요약영역 정형 조회 사용자 Ad-hoc Query 정제된 전사 통합 모델 데이터 Executive Area Require Specific Area 2, 3차 집계 데이터 다차원 모델 일별/월별 데이터 L 5 1차 집계 요약 데이터 일별/월별 데이터 L 4 L 3 통합영역 Summary Area L 2 Subject Area 정형조회/비정형/ 수집영역 실시간/준 실시간 화면 조회 L 1 주제영역별로 정리된 상세 수준 의 데이터 3차 정규화 모델 정제 완료된 데이터 준실시간/일별/월별 Raw Data Area 수집영역 데이터 근접 실시간 제공 최소의 데이터 가공, 신속한 데이터 제공 • 원천 시스템 데이터와 동일한 상 세 수준 데이터 • 1차 정제 수준 • 준실시간/일별/월별

Federation: Join real-time data to the warehouse § Access current customer records from a call centre Application § Access current stock levels from a supply chain data mart § Business activity monitoring – linking events to trends DB 2 Information Integrator Mart ODS Mart Enterprise Data Warehouse DB 2 Operational systems DBMS

Federation: Access XML & Unstructured Content Application Mart DB 2 Information Integrator § Access to customer documentation (e. g. letters, media) from a call centre § Linking photos or documents to analysis of customer claims in insurance Mart Enterprise Data Warehouse XML Operational systems DBMS Content Systems

Federation: Joining Marts & Warehouses § Access to marts developed by different departments for specific data BI Tool § Access from mart to warehouse level for detailed data Mart Enterprise Data Warehouse DB 2 Information Integrator Mart Second EDW

Intelligent Queuing and Governance § Mixed workload requires workload balancing § Evaluation and workload management prior to resource consumption – Define a data path for executives and emergency work – Define a data path for “as long as it gets done” work – Define rules or priority for the rest (80%+) § Evaluation and adjustment during resource consumption – Identify priority and “just get it done” work, allotting appropriate resources – Adjust the rest up and down based on priority, current workload and time period

Data Archiving and Retrieval § More important where regulatory & compliance reporting needs more history than Decision Support and BI § Set threshold for active vs aged data § Different partitions and storage groups § Use Hierarchical Storage Management (HSM) to leave stubs in aged tables, move data to tape § Aged data (ie candidate for archive) still available to SQL – HSM retrieves on demand § Generally over stressed, aged data will not usually influence or change aggregation and summaries § Be fast enough to keep up Aged data Active data EDW Hierarchical Storage Manager Offline Storage

5. Parallel Database

Data Warehouse System is… - 대용량 데이터 - 대량 적재 - 분석 시스템 - 비교적 적은 수의 동시 사용자 - 복잡한 쿼리

Massive Data - 폭발적인 데이터의 증가 (GB -> TB -> PB) - 사용자의 증가 - 사용자의 데이터베이스에 성능에 대한 기대 수준 증가

Query - 대부분 Reporting Tool을 통해 생성되는 Query - 90% 이상의 정형 쿼리 - 10% 미만의 비정형 쿼리 - 악성 쿼리 발생 가능 - Query administration 정형쿼리 비정형쿼리 쿼리 비율 정형쿼리 비정형쿼리 자원 사용율

Mixed Workload - 데이터 적재 주기의 감소 - 분석대상 데이터의 동시성 욕구 증가 - 조회와 적재가 동시에 발생 - 트랜잭션 발생 후 30분 이내에 분석 가능한 시스템의 사례 source: The Data Warehousing Institute, ETL Trends & Requirements, 2003

Data Warehouse System is REALY… - 대용량 데이터 - 폭발적인 데이터의 증가 - 대량 적재 - 준 실시간 적재 - 분석 시스템 - 분석요구 증가 - 비교적 적은 수의 동시 사용자 - 동시 사용자의 증가 - 복잡한 쿼리 - ad-hoc 쿼리 - Mixed workload - Real-time DW

Parallel system CP U … CP U Memory CP U MEM Storage SMP CP U Storage MPP … Memory CP U … CP U Memory Storage SMP Cluster …. . CP U … Memory CP U

SMP system performance 50 Linear CPUs of Performance 40 30 Best in class SMPs 20 good SMPs 10 1 Common Wintel SMPs 1 10 20 30 CPUs Installed 40 50

Parallel Database System - H/W의 병렬 아키텍처와는 다른 DBMS의 병렬 아키텍처 - Shared disk I/O 확장에 제한적, 데이터 쏠림(Skew) 발생 - Shared Nothing 데이터 공유로 인한 Disk 병목현상을 근본적으로 제거하여 성능 보장 무제한적인 확장, 대용량 데이터 처리에 적합 Shared Nothing Shared Disk CPU CPU Mem Mem Interconnect CPU Disk Controllers CPU CPU Mem Mem

DB 2 UDB의 Partition DB 2 Data Partition DB 2 Agents CPU Memory - Bufferpool Communication I/O Channels Storage Capacity - DB 2 Agents CPUs for DB 2 Agents Memory for DB 2 Agents IO Channels Communications Storage

DB 2 UDB의 Parallel Architecture - 대용량 데이터에 대한 복잡한 쿼리 수행에 가장 적합한 Shared-nothing 구조를 채용 모든 시스템 자원을 극대화할 수 있는 병렬처리 기법 파티션간 데이터 이동을 최소화하여 병렬처리의 최대 성능을 보장 데이터/사용자의 증가에 따른 무한한 확장방안 제공 시스템 확장에 따른 선형적인 성능 증가 보장 병렬 적재, 백업, 복구 SQ L DB 2 Data Partition DB 2 Agents CPU CPU Memory - Bufferpool Communication I/O Channels Storage Capacity Table I/O Channels Storage Capacity

SMP system performance 50 Linear DB 2 DPF CPUs of Performance 40 30 Best in class SMPs 20 good SMPs 10 1 Common Wintel SMPs 1 10 20 30 CPUs Installed 40 50

H/W에 독립적인 parallel DBMS architecture SMP - Cluster MPP Partition Partition CPU CPU CPU CPU Memory Memory Data Data

Intelligent Optimizer 1. Cost-based Optimizer(without rules) Statistics - Access Path를 결정하는 Algorithm(Know-How) - 20년 이상의 Know-how가 접목 Optimizer - 사용자에 상관없이 동일한 성능 보장 - 질의 수행에 대한 여러 가지 고려사항(Hint) 불필요 - Explain을 통해 확인 가능 2. Query re-write - Optimizer에 의해 비효율적인 query 재작성 - SQL 튜닝 없이도 향상된 성능 보장 3. Self tuning - 자동 runstats 수행 - Learning Optimizer (LEO) – self tuning Column Group (Correlation) Stats. Best Plan Execution ATM / RUNSTATS Statistical Profile Estimated Cardinalities es Actual Cardinalities Optimizer Feedback Warehouse Background Process

Full 64 Bit Support 64 Bit (V 8) 0 x 0000 ? MB 32 Bit (V 7, V 8) 125 MB 0 x 0000 0 x 10000000 0 x 20000000 0 x 30000000 0 x 40000000 0 x 50000000 0 x 60000000 0 x 70000000 0 x 80000000 0 x 90000000 0 x. A 0000000 0 x. B 0000000 0 x. C 0000000 0 x. D 0000000 0 x. E 0000000 0 x. F 0000000 2 GB AIX Kernel 0 x 10000000 0 x 20000000 0 x 30000000 0 x 40000000 0 x 50000000 0 x 60000000 DB 2 memory segment 14 EA 0 x 70000000 0 x 80000000 0 x 90000000 DB 2 memory segment ? EA . . . AIX Kernel . . ∞ AIX Kernel

Multidimensional Clustering - Star schema 구조에 따라 다차원 CUBE 형태로 데이터를 저장/관리 - Query 수행시 Scan 범위를 대폭 축소하여 성능 증가 - 물리적으로 항상 Clustering 되어 있기 때문에 Reorg 작업 불필요 Nation Prior to MDC Clustering in one dimension only lclustering NOT guaranteed (degrades once page free space is exhausted) l Year With MDC East North South. West Clustering guaranteed ! l. Smaller indexes l. Faster query response l. Simple definition syntax l. Fast roll-in & roll-out l CREATE TABLE MDCTABLE ( Year INT, Nation CHAR(25), Color VARCHAR(10), . . . ) ORGANIZE BY( Year, Nation, Color ) 97 98 99 Year 99 00

Multidimensional Clustering (cont. )

Multidimensional Clustering MDC ORing MDC ANDering

Dynamic Bitmap Index - 하나의 테이블에 복수의 인덱스가 존재하는 경우 복수의 인덱스를 모두 사용 - 인덱스를 Bitmap화하여 Anding, Oring의 기법으로 통합 - 사용자의 개입 없이 Optimizer에 의해 자동으로 수행 - 인덱스 사용의 효율성 향상 DB 2 Index #1 Col 1 + Col 2 SQL Query Index #2 Col 3 Index #1 ■■□□■□■□□■■■■■□■□□■□□□■■□□■□■□□■■■■■□■□□ Index #2 ■■□■□□■□■□□□■■□□■□■□ ORing ■■□■■□■□■■■■□□■□■□□■■■■□ Index #1 ■■□□■□■□□■■■■■□■□□■□□□□□■□■□□■■■■■□■□□■□ Index #2 ■■□■□□□■■□□■□■□□□■■□□■□■□■■ ANDing ■■□□□□■□□□□□■□■□□□□□□□■□

Materialized Query Table - 쿼리 성능 향상을 위해서 필요한 데이터만으로 MQT를 생성 - 디자인 어드바이저를 통해 MQT 권장 - DB 2 Optimizer는 쿼리를 분석하여 필요에 따라서 자동으로 MQT를 통해 처리 - Cube views SQL Query Rewrite DB 2 Optimizer x Table A Table C MQT Table B Table D

다양한 Modeling 기법 Flat schema, Star schema, Snow-flake Schema 등 다양한 모델링 기법 지원 DB 2 Intelligent Optimizer는 다양한 모델링 형태를 인식하고 그에 적합한 Access plan을 Cost를 기반으로 작성 【 Flat schema 】【 Snow-flake schema 】【 Star schema 】 Fact

Query administration OLAP분석가 최고경영자 일반사용자 쿼리가 DBMS에 요청 되기 전 사전 예측 통 제! Query Patroller 1 2 3 4 DB 2 Governor 30% 15% 10% DB 2 Batch 작업 실행 중인 쿼리에 대한 자원 통제! 5%

6. Case Study : KT EDW

구축 경과 m 프로젝트 착수 : 2003. 11. 25 m 장비도입 및 검수 : 2003. 12. 30 m 정보 요구사항 분석 : 2003. 11. 25 ~ 12. 31(1. 5개월) m EDW 모델링 설계 : 2004. 1. 9 ~ 4. 28 (4개월) m 프로그램 구현 : 2004. 4. 29 ~ 7. 20 (3개월) m EDW 단위시험 : 2004. 7. 21 ~ 9. 23 (2개월) m 통합시험 : 2004. 9. 24 ~ 10. 24(1개월) m 완제품시험/시스템시험/성능시험 : 2004. 10. 25 ~ 11. 26 (1개월) m EDW 추진 실무위원회 개최 : 2004. 11. 23 m EDW 본위원회 개최 : 2004. 11. 26 m EDW 업무전환 : 2004. 11. 29 정보센터 6층

H/W 구성 LPAR(Logical Partition) extra memory 4 GB Gigabit Ethernet Fibre Channel 범 례 기존운영 장비 구성내용 설명 UNIX서버 p 690(IBM) 16 GB NT서버 x 440(IBM) 3대 디스크 Hitachi 100 TB 16 GB 실시간 6 Way 8대 EDW WAS 3 Way 8 GB ROLAP IBM X 440 4 GB 보안 2 Way LPAR(Logical Partition) extra memory 12 GB 32 GB 표준관리 ROLAP WEB SVR IBM X 440 백업장비 Storage. Tek 9310 16 GB 표준/품질 WAS DB 2 Way 3 Way 시스템관리 콘솔 IBM X 440 Molap & Report 4 Way 16 GB 4 GB 시스템 관리 2 Way L 4 스위치 Alteon 184 보안 2 Way 기간계 시스템 4 Way 16 GB SAN 스위치 SNFC S 48 8 Way 16 GB 4 Way 8 GB App 서버 1 App 서버 2 IBM P 690+ 16 Way 64 GB 전사 통합 데이터베이스 수집 서버(IBM P 690+) 16 Way 64 GB HA 16 Way 64 GB 8 Way 64 GB 디스크 어레이 HDS 9980 V - 물리적 용량 : 15. 5 TB - Raid-5 구성 - 사용자 용량 : 10. 7 TB - Cache Size : 24 GB - FC Ports : 16 ea 통합/요약 서버( IBM P 690+) Gigabit 스위치 CMP 24 Way 96 GB HA 24 Way 96 GB CMP 기존 마트 사용자 Gigabit 스위치 디스크 어레이 HDS 9980 V -물리적 용량 : 17. 8 TB - Raid-1+0 구성 - 사용자 용량 : 8. 2 TB - Cache Size : 32 GB - FC Ports : 32 ea - 물리적 용량 : 27. 8 TB - Raid-1+0 구성 - 사용자 용량 : 13. 7 TB - Cache Size : 32 GB - FC Ports : 32 ea 방화벽 통합콘솔 인터넷 Gigabit 스위치 Cisco 6506

S/W 구성 EDW 서버 수집서버 Data Stage Parallel Data Stage XE MQ Integrity Sync. Sort DB 2 UDB (DPF) Open. View /i. Agent Tivoli Agent 통합/요약 DB 2 UDB (DPF) Open. View /i. Agent Tivoli Agent TWS Agent AMOS Agent 통합/요약 TWS Agent AMOS Agent Networker Agent AIX 5 L 보안 서버 1 EDW WAS 표준/품질 품질관리 Web. SEAL 실시간조회 AP 표준/품질 AP LDAP IBM http Server DB 2 UDB Open. View / i. Agent AMOS Agent Networker Agent AIX 5 L Web. Sphere Open. Vie/i. Agent 실시간 서버 Information Integrator SQL*NET DB 2 UDB Open. View/i. Agent Open. View /i. Agent Tivoli Agent AMOS, TWS Agent Networker Agent AIX 5 L Networker Agent AIX 5 L AMOS Agent Tivoli Agent AMOS Agent NT AP 서버 ROLAP 서버 MSTR Server IIS Open. View Agent Tivoli Agent MQ Client DB 2 UDB Client Windows 2003 Ser ver Networker Agent AIX 5 L Tivoli Agent 통합/요약 Networker Agent Open. View/i. Agent AMOS Agent Legacy Appl. MQ(일부) TWS Agent(일부) OS Open. View /i. Agent Tivoli Agent Legacy System Mart Appl. UDB Client TWS Agent UNIX AIX 5 L 보안 서버 2 Web. SEAL LDAP DB 2 UDB Open. View / i. Agent AMOS Agent Networker Agent AIX 5 L MOLAP / REPORT 서버 Power. Play / Report Net DB 2 UDB Client TWS Agent 표준화 관리 시스템 관리 Meta. Stage TBSM IIS Open. View Agent Tivoli Agent DB 2 UDB Client Windows 2003 Server MS SQL DB 2 UDB Client Windows 2000 Ser ver 시스템 관리 관리자 PC DB 2 UDB Query Patroller Admin TAM 콘솔 Tivoli Master Health Center Quality. Stage Designer Web Browser Open. View / i. Agent Open. View /i. Agent Data Stage. Client UDB Client Networker Agent AIX 5 L Networker Master DB 2 UDB Cient Windows AIX 5 L TEC Console Tivoli Agent AMOS Agent TWS Mster §제품명 • DBMS • DB 2 UDB • ETT • Data. Stage XE / PX • Sorting • Sync. Sort • Job Scheduler • MOLAP §소프트웨어 • Reporting • Report. Net • ROLAP • MSTR • WAS / Web • Web. Sphere / IBM • MDR • Meta. Stage • Cleansing • Quality. Stage Server • TWS • Powerplay §제품명 http Server §소프트웨어 §제품명 • Mining • Enterprise Miner • 전송 미들웨어 • CASE(ED • Erwin Data Modeler • 객체지향 • Networker • 시스템성능 • i. Agent for Unix • 시스템장애 • HP Open View 관리 관리 WSAD PVCS Client CASE • 시스템통합관 리 • TBSM • EAM • TAM • 서버보안 • AMOS 사용자 PC Web Browser Report. Net Client Windows • ROSE • 백업관리 Windows • MQ W) Rational Rose TWS Console TBSM Console §소프트웨어 개발자 PC Data Stage. Client ER-Win PC 환경

Ⅱ. 사업 수행 내역 정보시스템의 변경된 구조 전사통합 모델 구축으로 원천발생 데이터와 최종 사용자 사이의 정보Hub가 구축 되어, 데이터 정합 성 보장, 중간저장소 단일화, 전사적 관점의 정보제공 가능 시스템 구조 정보제공 -정보제공의 적시성, 유연성 및 확장성 미흡 -정보Hub 인프라 구축을 통한 정보제공의 적시성, 유연성 및 확장성 강화 ETT 처리 -마트별 별도 운영으로 인한 데이터 처리 및 저장 제공에 대한 비효율적 운영 -통합 관리를 통한 운영의 비효율적 요인 최소화 -전사적 표준 부재로 인한 데이터관리 최적 화의 한계 -전사적 데이터 표준 및 품질관리를 통한 데이터관리 최적화 기반 확보 데이터관리

Ⅱ. 사업 수행 내역 정보제공 인프라 개선

Ⅱ. 사업 수행 내역 프로세스 개선

Current Model after Project 본사/본부부서 -전사 경영전략 정보 -매출분석정보 -6σ표준/품질분석 사업부서/지사 -기관별 매출실적 -서비스 이용내역 -고객민원정보 ROLAP MOLAP Query & Reporting RM/AM 직원(Biz 마케팅본부) -관리고객분석 -관리시장정보 -다양한 통계정보 표준/품질 Web 정형 화면 데이터 마트 통합DB (EDW) 원천시스템 수집영역 고객 고객 File/DB 상품 상품 File/DB 경영 경영 File/DB 시설 경영 통합영역 요약영역 TDWM 9개 주제영역 데이터 표준화 집계 고객 관점 업무관계자 계약 집계 가공 상품 관점 이벤트 계약 관점 상품 ICID IBIS PMIS Net. IS … … 마트 I/F 경영방침 시설 File/DB 요약 가공 조직 관점 상품 데이터 정제 다차원데이터 요약 가공 DW추출 영역 마트제공 영역 So. R (System of Record) 주소/건물 기준정보 현행화 구축 표준 데이터 set 현행화 표준데이터 관리시스템 RAS ABM BSC 구매BIS IT-BSC 월추정매출 표준데이터 품질관리 시스템 품질정보 요약 통화호 상호접속 정액제

Data 정보 ØFACT 1 Table üRecord 수 : 23, 102, 691, 624 üFile Size : 4, 805, 359, 857, 792 (4. 8 TB) üDB Size : 4, 658, 835, 750, 912 (4. 6 TB) ØFACT 2 Table üRecord 수 : 12, 463, 529, 688 üFile Size : 2, 555, 023, 586, 040 (2. 5 T B) üDB Size : 2, 602, 058, 121, 216 (2. 6 TB) ØFACT 3 Table üRecord 수 : 9, 307, 532, 736 üFile Size : 2, 298, 960, 585, 792 (2. 3 TB) üDB Size : 1, 753, 433, 505, 792 (1. 7 TB) ØFACT 4 Table üRecord 수 : 14, 370, 182, 640 üFile Size : 1, 379, 537, 533, 440 (1. 4 TB) üDB Size : 1, 391, 611, 871, 232 (1. 4 TB)

사전 테스트 결과 Test 내용 Fact table Load 고객의 예상시간 시작시간 종료시간 소요시간 18시 11분 02초 21시 00분 26초 2시 49분 24초 데이터 추가 및 정재 6시 23시 09분 29초 23시 32분 27초 0시 22분 58초 4개의 Fact Table 12개월 증식 6시 23시 40분 42초 0시 18분 32초 0시 37분 50초 0. 5시 0시 23분 56초 0시 26분 37초 0시 02분 41초 8시 0시 35분 20초 1시 56분 59초 1시 21분 39초 Fact Table에 대한 정형질의(100 user) 24시 9시 27분 23초 10시 10분 57초 0시 43분 34초 Fact Table에 대한 비 정형질의(10 user) 72시 　 예상시간 10시 00분 00초 고객별/월별 Summary Table 생성 8시 7시 25분 24초 8시 25분 57초 1시 00분 33초 차원별/월별 Summary Table 생성 36시 1시 43분 20초 6시 50분 53초 5시 07분 33초 정형질의(500 user) 36시 19시 33분 27초 2시 08분 25초 6시 34분 58초 Table 구조 변경 및 Column 변경 일별 Summary Table 생성

Feel free to contact me at: leejg@kr. ibm. com