Download
1 / 52
530 likes | 558 Views
Enterprise Data Warehouse. < Software Engineering 특론 >. 한 옥 영. 서론 (1). 서론 (2). 서론 (3). OLTP ( online transaction processing ) 이해
E N D
Enterprise Data Warehouse < Software Engineering특론 > 한 옥 영
서론(1) Software Engineering 특론 - EDW
서론 (2) Software Engineering 특론 - EDW
서론 (3) • OLTP ( online transaction processing )이해 데이터 웨어하우스는 자신의 형태를 결정하기 전에 무엇보다도 먼저 자신의 기반이 되는 OLTP의 데이터 부터 정확히 파악하는 것이 순서이다. 이런 의미에서 제대로 된 데이터 웨어하우스를 구축하기 위해서는 OLTP의 데이터를 반드시 정확하고 구체적으로 아키텍팅(architectonic)할 필요가 있다는 것이다. OLTP의 데이터 아키텍처를 정확히 수립하였고, 그것이 논리화를 거친 논리적 모델이라면 이미 70% 가량 EDW모델에 가까이 근접해 있다. 이 논리적 모델을 바탕으로 데이터 웨어하우스의 원칙인 '통합, 단순, 장기'의 개념을 최대로 승화시킨 모델을 구현해 가는 것이 가장 이상적인 방법. • ETL Algorithm만약 데이터 웨어하우스의 기반이 되는 OLTP의 모든 데이터에 대해 매우 상세한 아키텍처를 수립하였고, 이를 바탕으로 모델링한 EDW데이터 아키텍처 또한 상세하게 수립되어 있다면 이들 간에는 '집합 대 집합' 간의 매핑룰(mapping rule)이 존재하게 된다. 이 매핑룰이 바로 ETL(Extraction, Transformation and Loading; 추출, 변환, 탑재)의 알고리즘이 된다. OLTP도 데이터의 집합이고, EDW 또한 데이터의 집합이므로 이들간의 전환은 결국 '집합 간의 매핑'으로 볼 수 있다. 이것을 지금까지 DB이행(migration)을 할 때 적용해 왔던 방식처럼 일일이 사례별(case-by-case)로 다루어 알고리즘을 생성한다면 엄청난 경우의 수가 발생함은 물론, 오류나 누락이 증가할 뿐만 아니라, OLTP의 설계에 변화가 발생했을 때 유지·보수를 하는 일도 매우 어려워질 것이다. Software Engineering 특론 - EDW
서론 (4) • EDW 이상 장기적인 비전과 전략을 반영한 IT의 궁극적인 가치를 높이는 시스템 • EDW 현실 다른 서버로 데이터를 옮겨 두는 정도에 불과한 경우가 많아서 무용지물이 되거나 착시현상만 유발하고 있는 실정 • EDW 원칙 ‘통합, 단순, 장기(long term)’의 세 가지 정보의 원천인 OLTP는 자신들만이 가져야 하는 복잡한 사연이 있기 때문에 다른 목적들까지 모두 감안해 줄 여력이 없으므로 이들이 자신을 위해 변해 주기를 기다릴 수는 없음. 정보의 분석을 위한 원천 데이터는 너무나 다양하고, 대용량이며, 넓게 흩어져 있고, 그들간의 관련정보는 깊숙이 숨어 있기 때문에 이를 명확하게 재조명한다는 것은 결코 쉬운 일이 아님. 그럼에도 불구하고 ‘장기간’의 대용량의 데이터를 처리해야 하고, 툴이나 DBMS에게 많은 것을 맡겨야 하는 특수성 때문에 최대한 ‘단순/명료’해야 하며, 정보의 일관성과 투명성 확보를 위해 최대한 ‘통합’을 하기 위해서는 데이터 원천을 명확히 알아야만함. Software Engineering 특론 - EDW
서론 (5) • EDW Trend 금융권에 구축 바람이 일고 있는 실정. EDW는 DW를 전사적으로 확대한 개념으로 경영 전략 수립 및 실행에 있어 데이터 분석이 의사결정을 위한 최우선 선행 과제로 부각되면서 차세대 시스템 구축과 함께 금융권의 주요 IT 투자 분야로 부상함. EDW 구축 관련 주요 사례로는 외환은행, 조흥은행, 우리은행, 국민은행 등을 꼽을 수 있음 현대카드, 신용보증기금, 대한생명, 농협, 우리증권 등에서도 구축 완료. • EDW 구축 관련 이슈 기존 DW 환경을 어떻게 EDW 환경으로 전환할 것인가? 빠르게 늘어가는 데이터 분석에 관한 현업의 Needs를 반영하기 위해 어느 정도의 성능과 확장성이 필요한가? 각종 BI 관련 애플리케이션(ABM, BSC, CRM 등)과 어떻게 통합 또는 연계 활용할 것인가? 향후 EDW의 활용 범위 확대에 능동적으로 대처하기 위해 서버나 스토리지 등의 시스템 인프라를 어떻게 마련할 것인가? Software Engineering 특론 - EDW
EDW 정의 (1) • EDW : 기업 데이터 웨어하우스 / 전사 데이터 웨어하우스 • 물리적 정의 기업의 자산 관리 업무를 효율적으로 지원하는 종합 자산 관리 시스템. 기업의 자산 및 장비의 취득에서 운용, 보전, 이동, 애프터 서비스, 업그레이드, 폐기까지의 종합 관리 기반을 제공하는 시스템으로, 관리 비용을 최소화하고 실시간으로 자산의 운영 상태를 파악하여 중복 투자를 감소시키고 연관성 있는 타 부서와의 원활한 업무 조율을 지원하는 웹 기반의 자산 관리 시스템 • 논리적 정의 기존기업 내•외부 Data의 통합과 프로세스 통합까지 구축하여 기업전체의 표준화된 데이터 저장소를 구축하여, 급변하는 환경대응과 신규고객요구수용, 시장진출기회발굴, 프로세스 지연요소 제거 등을 위해 의사결정자에게 실시간으로 정보를 제공하기 위한 정보인프라 Software Engineering 특론 - EDW
EDW 정의 (2) Software Engineering 특론 - EDW
EDW Architecture Software Engineering 특론 - EDW
EDW Characteristics • Single version of the Truth • Multiple Subject Areas • Normalized Design • Mission-Critical Environment • Scalability Across Several Dimensions “What makes an enterprise data warehouse?” by Charles Garry Software Engineering 특론 - EDW
EDW 출현 배경 (1) • “The next logical step in the data warehouse evolution chain.” • Offer a single data resource for all enterprise information • Designed to provide that information in a format accessible to everyone Life & Health Financial Services: Technology Review Software Engineering 특론 - EDW
EDW 출현 배경 (2) • 데이터 량의 증가 • 실시간 처리 요구 • 차세대 아키텍처 구현 목적 Software Engineering 특론 - EDW
EDW 발전 과정 • 조회 정보의 실시간 처리 • 전사 RTE의 정보제공 기반 제공 • 기존 SQL에 비해 진보적인 분석 기능 및 언어 제공 • 플랫폼 내 각 솔루션들의 메타 데이터 통합 • 시스템 및 보안, 각 솔루션의 통합 관리 Software Engineering 특론 - EDW
주요 벤더 EDW 전술과 전략 • 사이베이스: Near Real Time·데이터웨어하우스 상의 EAI의 역할을 애플리케이션 통합보다는 데이터 전달자의 역할로 본다.·비동기 방식의 데이터 전달한다.·실시간이라기 보다는 보다 짧은 주기의 데이터 공급을 목표로 한다.·ETL로의 EAI역할에 관해서는 아직은 ETL을 대체하기에는 역부족으로 봄.·EAI는 소량의 데이터를 적기에 DW에 공급한다.·2PC와 같은 리얼타임은 상호 종속되지 않도록 구현하지 않는 것이 바람직하다. 보다 짧은 주기의 ETL로 해석하는 것이 바람직하다. Software Engineering 특론 - EDW
주요 벤더 EDW 전술과 전략 • 오라클: Oracle Streams(Near Real Time)·온라인 로그 파일을 사용하여 변경분을 추출한다.·DB Trigger를 사용하지 않는다.·DB 기능인 오라클 스트림을 사용하여 Redo log파일을 액세스, 변경분을 추출해 낸다.·일정한 주기에 따라 반복적으로 수행한다.·소스 시스템에 오버헤드를 주지 않는다. Software Engineering 특론 - EDW
주요 벤더 EDW 전술과 전략 • IBM: Real Time BI·데이터를 시계열로 구분하여 추출 및 저장 방식이 다르다(3년 전 데이터: 테이프/3년 전∼ 전일: ETL/당일 데이터 EAI or EII).·MQ Series queue를 사용해 계속적인 추출을 수행한다.·리얼타임 ETL은 Parallelism과 Non-stop loading을 수행하여야 한다.·리얼타임의 구축은 비싼 비용을 요한다. Software Engineering 특론 - EDW
주요 벤더 EDW 전술과 전략 • NCR테라데이타: Active Data Warehouse(Near Real Time)·즉시적인 Updatereal time에 가깝다.·수초 내에 결과를 얻을 수 있는 짧고 전술적인 쿼리가 많다.·Event-Driven Activity.·EAI 아키텍처를 사용해 Near Real Time을 구현한다.·대량 데이터의 적재는 제3의 ETL 툴을 활용한다.·테라데이타 유틸리티를 활용하여 거의 실시간의 데이터 획득 및 데이터 이행을 위한 패키지 형태의 ADW어댑터를 제공한다. Software Engineering 특론 - EDW
EDW 도입 목적 ▶ 비즈니스에 대한 한 가지 일관된 시각 제공▶ 보다 신속한, 보다 나은 의사결정▶ 데이터 품질의 향상▶ 보고 업무와 비즈니스 정보 강화▶ 효율성과 생산성 증대▶ 전반적 비즈니스 비용의 감소▶ 예기치 않은 비즈니스상의 요구 사항의 충족▶ 신속한 가치 전달▶ 언제든 어떤 문제에나 해결 제시 가능▶ 기업의 변화 가능성 Software Engineering 특론 - EDW
EDW 기능 (1) 1. 고유한 단일 Data View - 사실의 단일 버전 제공 하나의 application 중립적인 repository인 EDW의 궁극적인 목적은 조직의 명확한 단일 data view를 제공하는 것이고, 이는 쉽지 않은 일이다. 만일 data warehouse 환경이 각 특정 시점에서의 고객, 상품, 조직 등의 data entity들과 관련 data 요소들을 하나의 정확한 단일 view로 제공하지 못한다면, 이는EDW가 아니다. 2. 공유되는 Data 관점의 주제영역들 - 복수의 업무 영역들 지원 단일의 고유 정보가 공유되기 위해서는 data가 중복되지 않고 통합되어야 한다. data를 중복 없이 통합하기 위해서, 또 그렇게 되었음을 확인, 입증하기 위해서 EDW는 논리적으로 관련 data의 고유성을 확인할 수 있는 단위 영역으로 data가 그룹화 될 필요가 있으며, 이 그룹화된 영역을 (data) 주제영역(예: 고객, 상품, 조직, 거래 등)이라고 한다. 그런데 이 data 관점의 주제영역을 적용업무 영역(예: 재무, 영업, 생산, 물류 등)으로 곧잘 오해한다. 그리고 이 주제영역은 한꺼번에 다 정의, 구현될 수 없다. 주제영역은 고정된 것이 아니고, 업무 요구에 따라 확장, 변경될 수 있다. 새로운 주제영역들이 추가될 때 기존과 data entity 중복이 발생되지 않도록 유의해야 하고, 필요 시 조정되어야 한다. 예를 들어 고객과 관련된 data entity들은 하나의 고객 주제영역 내에 고유하게 존재할 때 단일 고객 view를 제공할 수 있다. data 관점의 각 주제영역이 고유하게 통합되어 있지 않다면 EDW가 아니다. 3. Mixed Workload의 최적화 - 사용자의 접근 허용과 Data Mart의 양육 DW는 동적인 환경이다. 동적인 환경이란 사용자, 사용자의 요구, 사용 data, workload가 동적으로 발생한다는 의미이다. 이 동적인 환경에서 유연성과 성능은 두 마리 토끼이다. 이론적으로는 유연성을 강조한다. 성능에 앞서 유연성이 우선이라는 것이다. 그러나 현실은 그렇게 간단치 않다. EDW는 사용자 query가 접근하는 장소인 동시에 data mart를 양육해 내는 곳이다. 응답 시간과 소요 시간의 문제는 바로 사용의 제한으로 이어진다. 성능은 얼마든지 향상시킬 수 있다는 주장은 모든 환경에 적용되는 일반적인 원칙이 전혀 아니다. EDW는 또한 사용자 요구의 추가나 변경을 동적으로 반영할 수 있어야 한다. entity들 간의 relationship이 유지되어야 하고 유지보수가 최소화되어야 한다. 이는 EDW의 TCO(total cost of ownership, 총소유비용) 이점이다. 따라서 EDW를 위해서는 성능과 유연성의 최적화가 요구된다. 이 동적성과 mixed workload에 대한 최적화의 설계 기술들은 현재 4가지(relational modeling, dimensional modeling, data vault modeling, business modeling)가 있다. 어떠한 기술을 사용하든 사용자의 직접적인 query를 허용하지 않는 EDW는 EDW가 아니다. 사용자의 요구가 동적으로 반영되지 않는 EDW 역시 진정한 EDW가 아니다. Software Engineering 특론 - EDW
EDW 기능 (2) 4. 명세 Data 및 이력 Data의 축적- 분석 기반 EDW는 사용자 요구를 만족시킬 수 있는 가장 상세한 수준의 data 입자(예: transaction)와 필요한 시점별 이력을 계속해서 축적해야 한다. 이는 적절한 요약 혹은 집계 data를 생성시킬 수 있는 분석 기반이다. 가장 상세한 수준이 아니거나 현재 시점의 data만 보유한다면 EDW가 아니다. 5. Data 추적성과 동기화 - 운영과의 연결 EDW data는 항상 해당 운영 data를 추적할 수 있어야 한다. data cleansing이 근본적인 문제 해결이 아니므로, cleansing의 이유로 추적성이 간과되어서는 안된다. 또한 운영 data나 EDW 자체에서 생성된 data의 변경에 따른 해당 EDW data의 동기화에 대한 규칙과 처리 방법이 정의되고 준비되어 있어야 한다. 운영 data에 대한 추적성과 동기화가 확보되어 있지 않다면 EDW가 아니다. 6. 선택이 아닌 필수 - Mission-Critical System EDW는 다양한 운영을 지원할 수 있어야 한다. 이를 위해서는 주요 업무 시스템과 같은 고가용성(no downtime), 업무지속성(장애 극복 및 복구)이 보장되어야 한다. EDW는 business process 및 의사결정을 위해 반드시 필요되어야 한다. 던져 주고 끝나는 시스템은 EDW가 아니다. 7. 확장성 - 성장과 분배 진정한 EDW는 공유로 인해 급격히 - 데이터량, 사용자수(query수), workload에서 - 성장한다. 진정한 EDW는 단순 데이터량이 아니라, 실제 사용자수, 자유로운 query 접근에 의해 다른 것과 구별되고 인정된다. 이는 EDW platform이 증가하는 데이터 량에 대한 어떤 사용자 query(정형, 비정형)도 수용할 수 있어야 하고, 파워 유저와 운영적/전술적 유저를 동시에 지원할 수 있어야 하며, 따라서 필요한 확장성을 선형적으로 보장할 수 있어야 함을 의미한다. EDW platform은 또한 workload balancing, 병렬 처리 등을 통해 성장의 부하를 조정하고 분배할 수 있어야 한다. 이러한 정상적인 확장성이 요구되지 않는 EDW는 EDW가 아니다. Software Engineering 특론 - EDW
EDW 기능 –구축 목적 Software Engineering 특론 - EDW
EDW 구축 시 고려사항 Software Engineering 특론 - EDW
EDW 구축 시 모델 형태 Software Engineering 특론 - EDW
Entity Relationship Diagram Master Data Management ERD vs. MDM Software Engineering 특론 - EDW
DD02 DW아키텍쳐확정 ID01 설계준비 DD01 정보분석요건보완 ID02 설계표준화 DD11 DM모델링 DD21 EDW모델링 DD12 OLAP프로토 타이핑 및 DM보완 DD03 APP/보고서설계 DD13/DD22 ETT매핑/설계 DD04 설계단계검증 DD05 구축단계준비 EDW 구축 방법 –작업 구성도 Software Engineering 특론 - EDW
EDW 구축 방법 - 작업내용 DD01 정보분석요건보완 정보분석요건을 보완하여 구현방안을 확정하고, 정보분석모델을 완성 DD02 DW아키텍쳐확정 분석계의 정보체계와, 데이터I/F방안, DW기술구조를 확정 DD11 DM모델링 정보분석요건을 반영한 DM모델 작성 DD12 OLAP프로토타이핑 OLAP구현 및 프로토타이핑을 통한 DM모델의 보완 DD13 ETT매핑(EDW-DM) EDW-DM간의 ETT매핑흐름도 및 주요 매핑정의서 작성 DD21 EDW모델링 처리계모델과 DM모델의 요건을 바탕으로 EDW모델 작성 DD22 ETT매핑(OD-EDW) 처리계DB-EDW간의 ETT매핑흐름도 및 주요 매핑정의서 작성 DD03 APP/보고서설계 정보분석관련 APP 및 전사보고서에 대한 설계서 작성 DD04 설계단계검증 설계결과에 대한 완전성 및 정확성 검사 DD05 구축단계준비 데이터 변환요건 및 구축단계의 실행계획 수립 Software Engineering 특론 - EDW
EDW 구축 방법 • 정의 • 처리계의 데이터모델, 각 DM의 정보분석요건 및 데이터 모델의 요건을 반영한 전사데이터웨어하우스 모델 작성 • 모델표준 정의 • 세부작업 • EDW초기 모델링 • 처리계모델 반영 • DM모델 반영 • 이력데이터 모델링 • EDW모델 상세화 • 현정보계DB 반영 • 외부데이터 모델링 • …집계 모델링 ... • EDW모델 리뷰 • EDW모델 물리 전환 Software Engineering 특론 - EDW
EDW 구축 방법 - 초기 모델링 • 처리계모델 반영 • EDW 주제영역 정의 • 처리계데이터 구조 조정 • 엔티티구조 조정 • 속성구조 조정 • DM모델 반영 • EDW/DM모델 GAP분석 및 항목 반영 • DM모델 표준화 • 이력데이터 모델링 • 이력관리대상 선정 • 이력관리방법 결정 • 상세화정도 결정 Software Engineering 특론 - EDW
EDW 구축 방법 - 모델 상세화 • 현정보계DB 반영 • 현정보계ERD/신분석계DB Gap분석 • 데이터이행요건 검토 및 반영 • 외부데이터 모델링 : 대상선정 -> 모델링 -> 관리방안 결정 • 보고서요건 반영 • 보고서분류 -> 보고서집계 모델링 -> 공용집계모델 반영 • 집계 모델링 • 공용집계DB 아키텍쳐 확정 • 공용집계 모델링 • DM I/F 데이터 정의 • DM간 데이터 송/수신 내역 파악 -> 관리방식 결정 • ETT구현요건 반영 • ETT구현요건 정의 -> ETT구현요건 모델 반영 Software Engineering 특론 - EDW
Enterprise EDW 구축 방법론 • EDW의 구축은 Business, Data, IT, 유지보수의 관점에서 방안을 제시하여야 함 Software Engineering 특론 - EDW
EDW 구축 방법론 • 다양한 Source System 원천에서 필요한 Data를 분석하여, Data의 무결성 등을 제공하는 기초자료의 데이터 생성 Software Engineering 특론 - EDW
EDW 구축 방법론 • 구축방법론은 Business Requirement를 파악하여 Data Mart를 구축하는 Top-Down 방법과 Source로부터 필요한 Data을 정의하는 Bottom-Up 방법을 병행 하여야함. Software Engineering 특론 - EDW
EDW 구축 방법론 • 구축방법론에서 Bottom-Up Approach와 Top-Down Approach를 병행하는 주요 Task 및 Characteristics Software Engineering 특론 - EDW
Software 구축 방법 (1) • Waterfall 방법론 Software Engineering 특론 - EDW
Software 구축 방법 (2) • Prototyping 모델 Software Engineering 특론 - EDW
Software 구축 방법 (3) • Spiral 모델 Software Engineering 특론 - EDW
EDW 구축 Configuration Software Engineering 특론 - EDW
EDW 구축 전략 Software Engineering 특론 - EDW
EDW 구축 효과 • 실시간 처리가 가능한 솔루션 제공 • 저장 공간 절약 • 용이한 Data Access • Data 신뢰성 • DBMS와 BI 솔루션의 결합 • Maintenance 용이성 • 확장성 및 가용성 • 이기종 데이터와의 연합(Federation) 지원 • TCO 절감 Software Engineering 특론 - EDW
EDW 도입 사례 - KT Software Engineering 특론 - EDW
EDW 도입 사례 - 은행 • NCR Solution : Concept Software Engineering 특론 - EDW
EDW 도입 사례 –은행(continued) • NCR Solution : Architecture Software Engineering 특론 - EDW
Enterprise Data Warehouse EDW 도입 사례 - 병원 • Sybase 아산병원 EDW 구축 사례 : AMOS Software Engineering 특론 - EDW
EDW 사례 한국HP, 1석 3조 노린 BT 선봬 EDW 선점…논스톱 회생…인지도 강화한국HP(대표 최준근)는 최근 차기 IT 비전인 BT(Business Technology)전략을 소개하고, 동 비전을 가시화하는 첫 솔루션으로 ‘네오뷰’를 선보였다. 과거 IT 트렌드가 비즈니스와의 연계를 강조한데 반해, 새롭게 선보인 BT는 비즈니스와의 연계를 넘어 IT가 비즈니스의 결과에 책임을 진다는 데 가장 큰 차이점이 있다. 현재 한국HP는 차기 전략인 BT의 실현을 지원하기 위해 △BTO(Business Technology Optimization) △BIO(Business Informat ion Optimization) △AI(Adaptive Infrastructure) 등의 세 가지 포트폴리오를 재정립한 상태이고, 각각의 포트폴리오 별로 최적의 솔루션과 서비스를 제공한다는 계획 하에 분주한 상태다. 한국HP의 하석구 상무는 “과거 비즈니스와 IT를 동일하게 인식했던 것이 AE(Adaptive Enterprise)였다면, 새로운 전략인 BT는 IT가 비즈니스 결과에 대한 책임을 지는 것이 다른 점”이라며 “HP가 새롭게 선보인 BT전략은 △비즈니스 성장의 가속화 △비용 절감 효과 △위험 요소 감소 등의 3가지 기준으로 그 효과의 정도를 인정받게 될 것”이라고 말했다. ◆ BT, EDW를 겨냥한 물밑작업 한국HP의 BT는 시장에서 크게 3가지를 노린 전략으로 볼 수 있다. 최근 금융기관을 중심으로 서서히 도입 움직임을 보이고 있는 EDW 시장에서, 네오뷰 솔루션을 내세워 시장을 선점하는 것이 그 첫 번째 목적이고, 동시에 EDW 시장에서 파생된 하드웨어 시장의 매출신장이 두 번째 목적이다. 특히 하드웨어 영역 중에서도 최근 유닉스 대세에 밀려 그 가치가 평가 절하되고 있는 논스톱 서버의 회생에 좀더 무게를 둔 상태다. 그러나 BT 전략의 정착을 통해서 한국HP가 기대하는 가장 궁극적인 목적은 하드웨어 중심적이던 기업의 인지도를 개선한다는 데 있다. 현 금융기관의 EDW는 바젤과 같은 법적규제 증가로 인해 데이터 량의 증가세가 기타 분야를 압도하고 있다. 또한 웹기반 업무 환경의 확산에 따라 더 많은 사용자가 기업 내 데이터로의 접근을 시도하는 추세다. 과거에는 고객의 원천 데이터를 중앙에서 수집하고 관리했지만, 최근에는 보다 다양한 고객정보를 확보하기 위해 외부 데이터까지 소싱되는 추세다. 따라서 특정 데이터로의 접근을 시도하는 쿼리의 수가 동시다발적으로 증가되고 있다. 다시 말하면 과거의 업무에서는 고객의 이름이나 계좌정보 등의 단편적인 정보만이 필요했지만, 최근에는 한 명의 고객을 파악하기 위해서 파생적인 다수의 정보가 필요하다는 의미다. 특히 이 과정에서 IT자원의 사용량이 증가될 수밖에 없고, 결국 기업이 필요로 하는 RTE를 실현하기 위해서는 하드웨어 시스템의 유연한 확장성이 기반되어야만 한다는 논리다. Software Engineering 특론 - EDW
EDW 사례 (continued) ◆ 네오뷰, 논스톱 서버의 구세주 BT전략을 가시화하기 위한 첫 솔루션인 네오뷰는 과거 HP와 컴팩의 합병 시절부터 HP가 보유하고 있던 SQL 서버를 기반으로 제작된 솔루션으로, 현재 HP측은 네오뷰 솔루션을 자사의 논스톱 서버에 장착해 어플라이언스 형태로 제품 출시를 마친 상태다. HP측 관계자에 의하면 초기 네오뷰 솔루션을 수퍼돔에 장착하려는 내부의 움직임도 있었지만, 최종적으로는 논스톱 서버의 확장성이 더 뛰어나다는 판단 하에 이 같은 결정을 내렸다고 설명했다. 한국HP의 오영수 이사는 “현재까지의 EDW 구축은 기존 시스템을 그대로 활용하지 못하고 또 다른 시스템을 도입해야 했다”며 “이러한 문제는 독립적인 데이터 마트가 복수로 존재하는 문제를 파생했다”고 말했다. 또한 “네오뷰 엔진은 기존 ETL 툴과 BI 툴을 그대로 사용할 수 있는 장점을 제공한다”며 “향후 EDW 시장에서 핵심적인 역할을 담당하는 주력 제품군 중 하나가 될 것”이라고 강조했다. 우선 한국HP가 차기 주력제품이 될 네오뷰를 논스톱 서버에 장착한 가장 큰 이유는 최근 시장에서 고전을 면치 못하고 있는 논스톱 서버사업의 활성화를 도모하기 위함이다. 최근 유닉스 시스템의 안정성이 향상되면서 논스톱 서버가 약세에 몰린 상태다. 따라서 향후 교체주기를 맞아 퇴출 위기로 몰린 논스톱 서버의 전신인 텐덤 서버를 네오뷰를 통해 얼마만큼 수성할 수 있을지에 관심이 주목되고 있다. ◆ CIO로부터 영업 물고 튼다 국내에 레퍼런스가 전무한 네오뷰의 성공여부는 일단 국내 기업의 CIO 손으로 넘어간 상태다. 한국HP는 최근 외부 기관을 활용해 비즈니스와 기술의 상관관계 변화를 조사했고, 이 결과 기업의 의사결정 시 CEO와 CIO의 연계가 크게 증대한 상태라고 밝혔다. 또한 각 기업의 CIO를 대상으로 한 네오뷰 영업을 강화해 나갈 계획이고, 초기 도입비용이 기존 제품군보다 40%가량 저렴하다는 장점을 강하게 어필할 계획이라고 강조했다. 한국HP 최준근 사장은 “기술 투자와 관련해 대부분의 기업에서 기술이 전략적 의사 결정의 일부가 되고 있다”며 “늘어나는 비즈니스의 기술 의존도 따라 CIO의 역할이 중요해지고 있음에 주목할 필요가 있다”고 말했다. 또한 “앞으로 기업들이 경쟁력 유지를 위해 의사결정 과정에 기술 결정자를 더 많이 참여시키면서 중역회의 석상에 앉는 CIO들이 더욱 늘어날 것”이라고 덧붙였다. 김남규기자2007년 5월 17일 한국금융 Software Engineering 특론 - EDW
EDW 한계 (1) • EDW DB 급격히 증가 • Data 처리 성능 저하 • 정보 검색 단계와 시간 증가 • 분석용 Data의 Download 양 증가 Software Engineering 특론 - EDW
EDW 한계 (2) • EDW DB설계와 운영계 DB 설계의 Gap Software Engineering 특론 - EDW
EDW 한계 -사례별 사례 1: 점증하는 분석 및 레포팅 업무 요구를 지원하기 위해 구축된 independent data mart는 시간이 경과하면서 사용자와 사용 빈도가 늘어나고 추가 요구들이 발생하게 되었으며, 주요 업무 기능의 처리를 지원하는 중요한 시스템이 되었다. 조직에서는 이의 필요성을 인식하여 운영 지원, 유지보수 및 향상에 인력과 비용을 투자하였고, 그 규모도 훨씬 더 커지게 되었다. 또한 주변에는 업무 기능별로 제한된 여러 independentmart들 혹은 reporting database들이 공식적, 비공식적으로 생겨났으며, 데이터를 수집하고 정보를 생성하는 각자의 시도로 인해전체적으로는 대단히 혼란스러운 처리 구조가 되었다. 처음에는 소규모로 각자의 단순한 필요에 의해 독자적으로 구축되었던 이 data mart들은 결국 EDW를 위한 리엔지니어링을 요구하게 되었다.사례 2: 구체적인 업무 문제 및 기회에 대한 필요성과 기대, business case 개발에 소홀한 채로 구축된 대규모의 EDW는 시간이 경과하면서 제한된 사용에 따른 사용자 관심의 저하, 정보의 불일치 및 신뢰성 문제가 발생되었고, 주요 업무 기능의 처리에 충분한 도움을 주지 못하는 이차적 시스템이 되었다. 이 EDW는 보완을 위한 공식, 비공식의 지속적인 고도화 프로젝트를 수행하면서 유지보수 및 그때그때의 문제를 해결하기 위한 비용이 계속적으로 크게 발생되었다. 사례 3: EDW가 구축된 후, 사용자 주도의 개별 data mart들이 활발히 구축되기 시작하였다. 그런데 시간이 갈수록 data mart들의 단기적 구현에 급급해지면서, 상대적으로 EDW에 대한 관심이 점차 소외되거나 소홀해져 갔고, 따라서 EDW의 관리 및 향상이 뒷전으로 밀려났으며 EDW의 원칙이 불분명해졌다. 각 mart 프로젝트 관점에서 시간과 노력, 비용이 독립적으로 투자되었으며, 이 과정에서 EDW 역시 하나의 mart 수준으로 전락되었다. Software Engineering 특론 - EDW
EDW 한계 –진정한 EDW? IT에서는 하나의 용어가 업체, 솔루션 유형, 영업 혹은 마케팅 관점, 프로젝트 상황, 개별 실무자 입장에 따라 다양한 방식으로 사용되는 경우가 자주 있다. 이 때문에 실제적인 의미 이해의 어려움에서부터 커뮤니케이션의 곤란이나 심지어는 단절을 겪기도 한다. 특별히 EDW의 경우, 우리는 그 용어 자체에 지나치게 집착함으로써 EDW는 단지 개념으로만 존재하고 실제로는 이래도 EDW, 저래도 EDW가 되곤 하는 현실에서, 과연 EDW는 필요한 것을 주고 있는지 의아한 경우가 곧잘 있다. 이제 왜곡된 경험이나 기술, 자기 합리화로부터 벗어나 그것이 무엇이어야 하는지, 공통적인 시각으로 그 실제를 함께 확인해 볼 필요가 있다. - 이는 마치 하나의 현미경을 통해서 동일한 관찰이 가능하듯, 진정한 EDW를 명확히 확인하기 위한 핵심 기준들을 통해서 가능해진다. 통상 EDW라고 할 때는 CIF(corporate information factory)를 의미한다. 이는 - dimensional data warehouse와는 달리 - data가 주제영역 기준으로 통합되고 시간적으로 축적되며 end-user 접근이 가능한 data store로서, 물리적인 분산은 가능하나 일반적으로 하나의 중앙의 database로 존재하며 그 규모는 대단히 커질 수 있다. 그러면 몇 개의 data mart들을 하나의 platform 상에 합쳐 놓은 것이 EDW일까? data를 수집해서, 보관하고, 넘겨주는 것이 EDW일까? EDW가 어떤 역할을 감당해야만 하는지 혹은 EDW가 무엇이어야 하는지 - EDW가 진정한 EDW인지를 확인, 평가하기 위해서는 EDW의 기본 하부구조에서부터 설계 전반에 적용되는 명확한 원칙들이 평가 기준들로 정의되어야 한다. 진정한 EDW는 이 모든 기준들을 구현해야 한다. 어떤 이유로든 이 기준들을 만족시키지 못한다면 진정한 EDW가 아니다. Software Engineering 특론 - EDW
