비즈니스 정보 수집 비용 절감

소개

업무 분석 성능을 극적으로 향상시킬 수 있는 기술로서 온라인 분석 처리(OLAP)가 점점 더 많은 인기를 얻고 있지만 지금까지는 값비싼 도구, 구현의 어려움, 개발의 경직성 같은 특징을 가지고 있었습니다. Microsoft는 OLAP 문제를 연구하여 훨씬 폭넓은 대상층이 아주 저렴한 총 소유 비용으로 다차원 분석에 액세스할 수 있도록 하는 솔루션을 개발했습니다.

Microsoft® DSS(의사 결정 지원 서비스)는 완벽한 기능을 가진 새로운 OLAP 기능으로서 Microsoft SQL Server™ 버전 7.0의 구성 요소로 제공됩니다. DSS에는 사용자들이 대용량 데이터에 대해 정교한 고성능 분석 작업을 수행할 수 있도록 하는 중간 계층 서버가 포함됩니다. DSS의 둘째 구성 요소는 클라이언트 캐시 및 Microsoft 피벗 테이블 서비스라는 계산 엔진입니다. 이 엔진은 성능을 향상시키고 네트워크 소통량을 줄이는 데 도움이 됩니다. 피벗 테이블 서비스는 또한 사용자들이 회사 네트워크와의 연결이 끊어진 상태에서 분석을 수행할 수 있도록 합니다.

OLAP은 데이터 웨어하우징 프로세스의 핵심 구성 요소이며 DSS는 사내 보고로부터 고급 의사 결정 지원에 이르는 다양한 응용 프로그램에 대해 필수적인 기능을 제공합니다. SQL Server에 OLAP 기능을 포함하면 다차원 분석 제품을 훨씬 저렴하게 제공할 수 있고 OLAP의 이점을 더욱 다양한 대상층에 제공할 수 있습니다. 이러한 대상층에는 소규모 조직은 물론 현재 유통되고 있는 제품의 비용과 복잡성 때문에 OLAP 산업에 참여할 수 없었던 대규모 기업의 그룹과 개인들도 포함됩니다.

OLAP용 Microsoft OLE DB 인터페이스를 통해 OLAP 응용 프로그램을 지원하는 다양한 도구 및 응용 프로그램과 함께 DSS는 더욱 많은 조직이 정교한 분석 도구를 사용할 수 있도록 하고 데이터 웨어하우징의 비용을 낮추는 데 도움을 줄 것입니다.

OLAP의 필요성

전통적으로, 회사 컴퓨팅 환경에 대한 투자는 대부분 회계, 주문 처리, 제조, 고객 정보 시스템 등 데이터를 만들거나 수집하는 시스템에 대한 투자였습니다. 조직들은 수집된 이 데이터에서 부가 가치를 만드는 응용 프로그램과 기술에 점점 더 많은 투자를 하고 있습니다. 데이터 웨어하우징이란 다양한 운용 시스템에서 데이터를 수집, 정리, 추출한 다음 그 최종적인 정보를 다양한 비즈니스 사용자들이 분석 및 보고에 사용할 수 있도록 하는 프로세스를 말합니다. 데이터 웨어하우스 및 데이터 마트는 정보를 정리하고 요약하여 사용자들이 검색할 수 있도록 저장해 두는 비휘발성 저장소를 나타내는 용어로 폭넓게 사용됩니다.

몇 년 전, Microsoft는 비즈니스 세계에서 데이터 웨어하우징 및 의사 결정 지원 기능의 가용성을 확장한다는 총체적인 목표 아래 두 가지 해결 방안을 모색했습니다. Microsoft 데이터 웨어하우징 프레임워크와 Microsoft 데이터 웨어하우징 제휴 파트너가 그것입니다. 전자는 Microsoft 제품 개발의 안내도이고 후자는 업계 파트너들이 개발 및 마케팅 목적으로 Microsoft 플랫폼 및 데이터 웨어하우징 프레임워크 작업을 전담하기 위해 만든 연합체입니다. 이 해결 방안들은 아래와 같은 방법으로 데이터 웨어하우징 프로세스에 기여하기 위한 Microsoft의 중심 전략을 중심으로 추진되었습니다.

• 데이터 웨어하우스의 구입, 구현 및 유지 관리 비용 절감
• 대규모 시스템은 물론 개별 사용자에 대한 계속적인 하향 확장성도 가능하도록 데이터 웨어하우징 시스템의 확장성 재정의
• 다른 공급업체에서 제공하는 데이터 웨어하우징 도구들의 통합 성능 향상

Microsoft 데이터 웨어하우징 프레임워크

데이터 웨어하우징 프레임워크는 데이터 웨어하우스와 데이터 마트의 구축 및 관리와 관련하여 데이터 및 메타데이터의 공유 메커니즘을 기술하는 개방형 아키텍처입니다. Framework의 바탕이 되는 필수 기술은 OLE DB 데이터 인터페이스와 SQL Server에서 실행되는 Microsoft Repository의 인스턴스입니다. 리포지토리는 소프트웨어 구성 요소와 이들의 관계(메타데이터)에 대한 설명 정보를 저장하는 데이터베이스입니다. 데이터베이스 스키마, 데이터 변환 및 OLAP 데이터베이스 스키마에 대한 메타데이터 모델이 Microsoft Repository에 정의되었습니다.

Framework 구성 요소는 데이터 웨어하우징 프로세스의 필수 단계들을 나타냅니다. 이중 일부를 Microsoft가 제공하고 있지만 Microsoft 고객 및 업무 파트너가 대체 기술을 사용하여 쉽게 확장할 수 있습니다. SQL Server 7.0은 데이터 웨어하우스를 구축하고 유지 관리하는 데 필요한 기본 구성 요소들을 많이 제공합니다. 그래픽 스키마 디자이너를 사용한 데이터베이스 설계, 고용량 데이터 저장소, 데이터 변환 서비스(DTS)를 통한 데이터 변환 기능, DSS를 사용한 OLAP 기능 등이 여기에 해당합니다.

"The Microsoft Data Warehousing Strategy"(part number 098-80704)라는 제목의 관련 SQL Server 백서에 Microsoft 데이터 웨어하우징 프레임워크에 대한 자세한 설명이 나옵니다.

데이터 웨어하우징이란 사용자들이 이용할 수 있도록 데이터를 준비하는 프로세스이지만 관계형 데이터 웨어하우스에 포함된 대부분의 정보는 검색하기가 쉽지 않습니다. 비즈니스 사용자들이 데이터 구조를 이해하기란 보통 쉽지 않으며 SQL 관계형 쿼리 언어로 표현된 비즈니스 질문(예: "Who are the top sales people in each region for last year by month?")은 매우 복잡합니다. 이러한 문제 중 일부는 사용자에게 데이터베이스의 복잡성을 드러내지 않는 고급 쿼리 도구를 사용하여 해결할 수 있습니다. 그러나 사용자가 다차원 데이터를 보게 되는 많은 응용 프로그램의 경우 OLAP 기술이 최상의 솔루션입니다.

그 업무 내용과 상관없이 모든 조직은 다차원 데이터를 가지며 복잡도가 반드시 회사 규모에 의해 결정되는 것은 아닙니다. 아주 작은 회사도 제품, 판매 사원, 지역, 고객 및 시간에 따라 매출을 추적하고자 할 수 있습니다. 이러한 각 설명 범주가 OLAP 모델에서 하나의 차원이 됩니다. 조직들은 다차원 데이터를 쉽고 자연스런 방법으로 액세스하고 탐색하고 분석하기 위한 도구를 오랫동안 기다려 왔습니다.

OLAP은 새로운 개념이 아닙니다. 그러나 그 인기가 높아짐에 따라 최근에야 이 기술에 "OLAP"이라는 이름이 사용되었습니다. 1993년, 유명한 데이터베이스 연구가이자 관계형 데이터베이스 모델의 고안자인 Dr. E. F. Codd가 OLAP 응용 프로그램의 특징을 "정의하는" 12가지 규칙을 제시한 백서¹에서 이 용어를 처음 사용했습니다. 그 후, OLAP Report의 공동 작성자인 Nigel Pendse와 Richard Creeth가 이른바 FASMI(Fast Analysis of Shared Multidimensional Information) 테스트를 사용하여 Codd의 정의를 다듬었습니다. OLAP 응용 프로그램은 공유 다차원 정보를 신속하게 분석할 수 있어야 한다는 것이 이 테스트가 제시하는 조건입니다.²http://www.olapreport.com/ (영문) 웹 사이트를 참조하십시오.

OLAP은 최대의 융통성과 성능을 통해 업무용 데이터를 액세스하고 보고 분석할 수 있는 방법을 제공합니다. 맨 먼저, OLAP은 자연스럽고 직관적인 데이터 모델을 통해 사용자에게 데이터를 제공합니다. 이러한 손쉬운 탐색 스타일을 통해 비즈니스 사용자들은 데이터 웨어하우스에 포함된 정보를 더욱 효과적으로 보고 이해할 수 있으며 조직들은 데이터의 가치를 더욱 깊이 있게 인식할 수 있습니다. 둘째, OLAP은 일부 계산된 데이터 값을 실행 시가 아니라 사전에 준비함으로써 이러한 다차원 구조를 보는 사용자들에게 정보를 더 빠르게 배달합니다. 손쉬운 탐색과 빠른 성능이 결함됨으로써 사용자들은 관계형 데이터베이스 기술만 사용될 때보다 훨씬 더 빠르고 효과적으로 데이터를 보고 분석할 수 있습니다. 결과적으로, 데이터 분석에는 시간이 많이 들지만 데이터베이스 분석에는 시간이 적게 듭니다.

OLAP 용어 및 개념

OLAP 데이터 모델에서, 정보는 개념상 큐브로 간주됩니다. 큐브는 설명 범주(차원)와 분량 값(측정값)으로 구성됩니다. 다차원 데이터 모델에서는 사용자들이 아주 간단하게 복잡한 쿼리를 형식화하고, 보고할 데이터를 준비하고, 요약 데이터를 자세히 정리하고, 데이터를 필터링하거나 분할하여 의미 있는 집합으로 만들 수 있습니다. 예를 들어, 판매 정보가 포함된 큐브에는 일반적으로 Time, Geography, Product, Channel, Organization, Scenario(Budget 또는 Actual) 등의 차원이 포함될 것입니다. 측정값에는 보통 Dollar Sales, Unit Sales, Inventory, Headcount, Income 및 Expense가 포함될 것입니다.

OLAP 데이터 모델의 각 차원 안에서, 데이터의 세부 수준을 나타내는 계층 구조로 데이터를 조직할 수 있습니다. 예를 들어, Time 차원 안에 Years, Months 및 Days 수준이 있을 수 있으며 Geography 차원 안에 Country, Region, State/Province 및 City 수준이 있을 수 있습니다. OLAP 모델의 특정 인스턴스는 계층 구조 안의 각 수준에 대해 특정 값을 가집니다. OLAP 데이터를 보는 사용자는 데이터 수준 간에 위나 아래로 이동하여 자세한 정보나 요약 수준 정보를 볼 수 있습니다.

큐브, 차원, 계층 구조 및 측정값은 OLAP 다차원 탐색의 필수 요소입니다. 이런 방식으로 데이터를 기술하고 제공함으로써 사용자들은 쉽고 직관적으로 복잡한 데이터 집합을 탐색할 수 있습니다. 그러나 데이터 모델을 더 직관적인 형태로 기술하는 것만으로는 사용자에게 정보를 더 빨리 전달하는 데 거의 아무 도움이 되지 않습니다. OLAP의 주된 원칙은 사용자들이 요청한 각 뷰 또는 데이터 조각에 대해 일관된 응답 시간을 제공받아야 한다는 것입니다. 데이터는 일반적으로 세부 수준에서만 수집되기 때문에 보통 정보 요약이 미리 계산됩니다. 이러한 미리 계산된 값 또는 집계가 바로 OLAP 성능 이점의 기반이 됩니다.

OLAP 기술의 초창기에는 대부분의 공급업체가 OLAP 응용 프로그램에 대한 유일한 솔루션이 특별한 비관계형 저장소 모델을 사용하는 것이라고 생각했습니다. 그 후, 다른 공급업체들이 데이터베이스 구조(스타 및 스노플레이크 스키마), 인덱싱 및 집계 저장소를 사용함으로써 관계형 OLAP에 데이터베이스 관리 시스템(RDBMS)을 사용할 수 있다는 것을 발견했습니다. 이러한 공급업체들은 자신들의 기술을 관계형 OLAP(ROLAP)이라고 명명했습니다. 그리고 초기 OLAP 공급업체들이 다차원 OLAP에 대해 MOLAP이라는 용어를 채택했습니다.

지난 몇 년 동안 MOLAP과 ROLAP 간의 싸움이 가속화되었습니다. MOLAP 구현은 일반적으로 관계형 기술보다 성능은 우수하지만 확장성에 문제가 있습니다. 반면에, ROLAP 구현은 확장성이 더 뛰어나며 기존의 관계형 데이터베이스 기술에 대한 투자를 활용하기 때문에 고객들이 선호하는 경우가 많습니다.

최근에는 하이브리드 OLAP 솔루션이 개발되었습니다. HOLAP라고도 하는 이 솔루션은 ROLAP과 MOLAP 아키텍처를 조합함으로써 우수한 성능과 폭넓은 확장성이라는 양쪽의 장점을 살린 솔루션으로 개발되었습니다. HOLAP에 대한 한 가지 접근 방식은 관계형 데이터베이스에 자세한 기록(최대 용량)을 유지하면서 별도의 MOLAP 저장소에 집계를 유지하는 것입니다.

의사 결정 지원 서비스 아키텍처

DSS는 처음부터 OLAP 응용 프로그램의 구축 및 유지 관리에 드는 가장 중요한 총 소유 비용을 최소화할 목적으로 개발되었습니다. DSS는 서버 및 클라이언트 소프트웨어 구성 요소로 구성됩니다.

서버에서, DSS 분석 서버는 Microsoft Windows NT® 서비스로 동작하며 핵심적인 연산 기능을 제공합니다. DSO(Decision Support Objects)라는 개체 모델을 통해 분석 서버의 관리 기능에 대한 체계적인 액세스가 이뤄지며 이 개체 모델은 Microsoft에 의해 제공됩니다. DSS에 대한 기본 제공 관리 사용자 인터페이스(OLAP 관리자) 역시 DSO를 기반으로 개발되었으며 프로그래밍을 요구하지 않고 풍부한 사용자 경험을 제공합니다. OLAP 관리자는 분석 서버가 아닌 다른 컴퓨터에서 실행될 수 있습니다. 데이터베이스 관리자들은 OLAP 관리자를 사용하여 다른 기능들 간에 OLAP 데이터베이스 모델을 설계하고, 관계형 데이터베이스 저장소(RDBMS)의 정보에 액세스하고, 집계를 설계하고, OLAP 데이터 저장소를 채울 수 있습니다. OLAP 메타데이터 정의는 개인 리포지토리에 저장되지만 간단한 유틸리티를 사용하면 OLAP 정보 모델과 함께 Microsoft Repository로 내보낼 수 있습니다.

DSS는 모든 OLE DB 데이터 공급자의 원본 데이터에 액세스할 수 있습니다. SQL Server는 물론 Microsoft Access, Microsoft FoxPro, Oracle, Sybase, Informix 등을 포함한 다양한 데스크톱 및 서버 데이터베이스가 이러한 데이터 공급자에 속합니다. ODBC 드라이버를 "숨기고" 이들이 마치 기본 OLE DB 인터페이스인 것처럼 나타내는 OLE DB의 기능을 통해서도, ODBC 인터페이스를 제공하는 모든 데이터베이스 원본에 액세스할 수 있습니다. 이러한 데이터 원본은 Windows NT 운영 체제 이외의 플랫폼, 예를 들어 UNIX 또는 대형 컴퓨터 시스템 및 데이터베이스(DB2 또는 Teradata)에도 존재할 수 있습니다. OLE DB의 다중 플랫폼 기능을 통해 마치 DSS 서버의 로컬 데이터인 것처럼 다양한 시스템에서 데이터에 액세스할 수 있습니다.

DSS에는 또한 피벗 테이블 서비스라는 클라이언트 구성 요소도 포함됩니다. 이 서비스에 대해서는 이 문서의 뒷부분에서 자세히 설명합니다. 지금은, 피벗 테이블 서비스를 OLAP 클라이언트 응용 프로그램을 DSS 서버에 연결하는 서비스로 생각해도 충분합니다. DSS가 관리하는 데이터에 대한 사용자 정의 프로그램 또는 클라이언트 도구의 모든 액세스는 피벗 테이블 서비스가 제공하는 OLAP용 OLE DB 인터페이스를 통해 이뤄집니다.

DSS의 클라이언트 및 서버 구성 요소 모두 기능을 확장할 수 있습니다. 고객 사이트, 독립 소프트웨어 공급업체 및 컨설턴트 모두 잘 정리된 DSO 기능을 사용하여 계산, 데이터 관리 또는 응용 프로그램 기능을 확장할 수 있습니다. 기본 제공 확장성이 있기 때문에, 고객들은 항상 DSS가 고객들의 응용 프로그램 요구 사항을 해결하는 데 필요한 기능을 제공할 것이라는 확신을 가질 수 있습니다.

OLAP 구현 문제 해결

OLAP 구현의 기본적인 문제는 초기 데이터베이스 스키마를 다차원 모델에 매핑하는 것입니다. 현재 시중에 나와 있는 많은 제품에서 이런 매핑을 수행하려면 상당한 프로그래밍 작업이 필요합니다. 지난 몇 년 동안 OLAP 제품이 발전하면서 OLAP 데이터베이스 설계는 개발 중인 특정 OLAP 기술과 복잡하게 연결되어 전문적이고 비밀스런 프로세스가 되었습니다. 결과적으로, OLAP 데이터베이스 개발자는 매우 전문적인 기술을 습득하게 되었고 이로 인해 응용 프로그램을 개발하려면 데이터 설계 단계에 집중적으로 많은 비용을 들여야 했습니다.

대부분의 OLAP 구현에서는 데이터 웨어하우징 프로세스를 통해 데이터 분석 준비가 완료된 것으로 간주합니다. 즉, OLAP 응용 프로그램으로 통합하기 전에 이 프로세스를 통해 운용 시스템에서 정보를 추출하고, 정리하고, 확인하고, 요약한 것으로 간주합니다. 이는 프로세스의 필수 단계로서 OLAP 사용자가 보는 데이터의 정확성과 일관성을 보장하고 데이터가 조직 상의 데이터 정의와 일치하도록 합니다.

점점 더 많은 데이터 웨어하우스의 정보가 스타 또는 스노플레이크 스키마로 조직되고 있습니다. 이러한 스키마는 사용자가 데이터를 쉽게 이해할 수 있도록 돕고, 의사 결정 지원 응용 프로그램의 데이터베이스 쿼리 성능을 최대화하고, 대규모 데이터베이스에 대해 더 작은 저장소를 필요로 합니다. 이러한 스키마는 OLAP 데이터 모델을 관계형 방식으로 표현한 것이며 OLAP 큐브 정의를 구축하는 데 좋은 출발점이 될 수 있습니다. 그러나 이 방식을 이용한 OLAP 제품은 거의 없었습니다. 이들은 일반적으로 스타 스키마를 OLAP 모델에 매핑하기 위한 간편한 도구를 제공하지 않았으며 OLAP 모델의 구축 비용이 매우 비쌌고 개발 시간도 불필요하게 길었습니다.

이 그림은 스타 스키마의 예를 나타낸 것입니다. 이 데이터베이스 스키마 유형에서 중앙의 "fact" 테이블은 관련 속성 또는 차원 테이블들과 연결되어 있습니다.

액세스 성능을 향상시키는 직관적 사용자 인터페이스

DSS의 주된 이점 중 하나는 OLAP 관리자 사용자 인터페이스입니다. 이 인터페이스는 액세스가 많지 않은 OLAP 데이터베이스 관리자(DBA)를 염두에 두고 설계되었습니다. DSS OLAP 관리자는 Microsoft Management Console(MMC)의 스냅인으로 제공되며 SQL Server 및 Microsoft BackOffice® 제품군과 같은 관리 사용자 인터페이스를 공유합니다. 따라서 OLAP DBA가 SQL Server 및 다른 Microsoft 제품의 기술을 더 잘 해석할 수 있다는 분명한 이점이 있습니다. 그러나 MMC의 힘과 융통성을 이해할 때 훨씬 더 많은 가치가 극명하게 드러납니다. DSS에는 초보자나 자주 액세스하지 않는 사용자들이 일반적인 작업을 수행할 수 있도록 도와 주는 완전한 작업 창이 제공됩니다. DSS에는 OLAP 개념에 관한 완벽한 자습서와 OLAP 큐브 구축에 대한 단계별 가이드가 제공됩니다. 완벽한 마법사 서비스를 사용하여 차원 정의 만들기 같은 일반적인 작업을 자동화할 수 있습니다.

또한 DSS는 스타 또는 스노플레이크 스키마가 설계되어 있는 데이터 웨어하우스 개발에 맞게 최적화되어 있습니다. 큐브 작성 마법사는 특히 이러한 기본 제공 스키마에 적합하며 다차원 모델로의 변환이 매우 빨리 수행됩니다. 그러나 DSS는 다른 원본 스키마가 발견되면 이들을 쉽게 수용할 수 있습니다.

DSS의 사용자 인터페이스 개념이 올바르게 해석되는지 확인하기 위해 지원자들의 도움을 받아 Microsoft 랩에서 많은 가용성 테스트를 실시했습니다. 마지막으로, 이전에 OLAP 업계에서 실시했던 어떤 테스트보다 광범위한 대규모 베타 테스트를 실시하여 다양한 고객층을 참여시키고 이들에게 DSS를 공개했습니다. DBA 요구 사항에 쏟은 노력 덕분에 대부분의 사용자들이 30분 안에 첫째 큐브를 만들 수 있습니다.

앞에서 설명한 대로 대부분의 OLAP 제품에서 성능을 향상시키기는 데 핵심 역할을 하는 것은 미리 계산된 집계입니다. 그러나 사전 집계에는 막대한 비용이 따릅니다. 즉, 집계 수가 초기 세부 지점의 수를 쉽게 넘어설 수 있으며 저장된 데이터의 크기가 극적으로 커집니다. 예를 들어, 이 그림을 보면 차원 2개와 각 차원에 하나의 집계 수준이 있는 간단한 OLAP 모델에서 어떻게 필요한 집계가 5개가 되고 2.25:1의 비율이 나오는지 알 수 있습니다. ³http://www.olapreport.com/ (영문)을 참조하십시오.

이 데이터 폭증의 영향을 보여 주는 실제 예들이 많이 있습니다. 최근에 발표된 다른 OLAP 제품에 대한 표준 벤치마크 테스트에서는 데이터 폭증 비율이 240으로 나타났습니다. 이는 10MB의 입력 데이터를 관리하는 데 2.4GB의 저장소가 필요하다는 뜻입니다. 대량의 데이터 확장을 처리할 수 있는 적절한 디스크 저장소를 제공하려면 대규모 OLAP 구현에 막대한 비용을 들여야 하며, 필요한 모든 원본 수준 데이터를 분석하는 조직의 능력에 분명한 한계가 생깁니다.

데이터 폭증 현상 때문에, OLAP 응용 프로그램은 원본 또는 세부 데이터가 다차원 큐브 전체에 걸쳐 넓게 분산될 때 훨씬 더 큰 어려움을 겪을 수 있습니다. 없는 데이터 값이나 잘못된 데이터 값 때문에 OLAP 데이터 모델에 데이터 희소성이 나타납니다. 최악의 경우 OLAP 제품이 빈 값을 저장할 수도 있습니다. 예를 들어, 회사가 일부 지역에서 일부 제품을 판매하지 않는 경우 공통 영역(판매되지 않는 제품과 판매되지 않는 지역이 만나는 영역)에 어떤 값도 나타나지 않을 것입니다. 아래 그림은 북동부에서는 하드웨어를 판매하지 않고 남동부에서는 소프트웨어를 판매하지 않는다는 점에서 앞의 예제와 다릅니다.

데이터 희소성은 OLAP 공급업체가 해결해야 할 과제였으며 공급업체마다 서로 다른 수준으로 이 문제를 해결했습니다. 빈 값을 저장함으로써 조밀도가 극히 낮고 공간과 리소스를 낭비하는 데이터베이스를 구현하는 것이 최악의 시나리오일 것입니다. DSS는 빈 값을 저장하지 않기 때문에 큐브가 조밀하게 채워지지 않아도 규모가 커지지 않습니다. 일부 OLAP 공급업체에서 이 문제를 OLAP 아키텍처의 결정적인 요소로 강조하곤 하지만, 데이터 희소성 관리에 대한 공급업체 간 구현 차이는 너무 많은 집계를 미리 계산함으로써 발생하는 훨씬 더 중대한 데이터 폭증에 비하면 사소한 문제에 지나지 않습니다.

리소스를 더 효과적으로 사용하기 위한 융통성 있는 저장소 옵션

DSS는 가장 적합한 저장소 모델을 OLAP DBA가 결정할 수 있도록 하는 융통성 있는 솔루션을 제공함으로써 시장을 선도하고 있습니다. DSS는 완전 MOLAP 구현, 완전 ROLAP 구현 또는 하이브리드 솔루션을 지원합니다. 하이브리드 솔루션에서는 집계가 다차원 기술과 관계형 기술로 저장됩니다. 예를 들어, 데이터베이스 관리자는 자주 액세스되는 데이터(예: Current Year)는 MOLAP에 저장하고 확장성 문제가 좀더 많은 기록 데이터는 ROLAP에 저장할 수 있습니다. 그러나 기저에 놓인 데이터 모델은 클라이언트 응용 프로그램에 전혀 드러나지 않으며 사용자는 큐브만 인식합니다.

MOLAP, ROLAP 또는 HOLAP 중 어떤 데이터 모델을 구현하든 DSS와 관계형 데이터베이스의 통합이 우수한 솔루션입니다. GUI 설계 도구 및 마법사를 OLE DB에 직접 결합함으로써 DSS는 원본 데이터, OLAP 다차원 메타데이터 및 집계 자체 간에 매우 강력한 연결을 유지합니다.

ROLAP 데이터 모델을 구현하면 DSS가 모든 관계형 데이터베이스 구조를 정의하고 채우고 유지합니다. 이 기능 덕분에 개발자들은 이러한 작업을 수행할 필요가 없으며 여러 테이블 및 서버 간의 복잡한 쿼리를 관리할 필요가 없습니다.

인텔리전트 사전 집계

DSS는 또한 OLAP 기술의 근본적인 문제, 즉 과도한 사전 집계로 인한 데이터 폭증을 최소화했습니다. 앞에서 설명한 대로, OLAP 데이터 폭증은 다차원 사전 집계 때문에 발생합니다. 일반적인 OLAP 시스템에서는 실행 시에 계산되지 않는 한 사전 집계되지 않은 데이터를 보고 및 분석에 사용할 수 없습니다. 일반적인 OLAP 제품은 가능한 모든 집계 조합(예: 모든 시간 간격, 모든 조직, 모든 배포 채널 등에 걸친 모든 제품 및 제품 수준의 합계)을 미리 계산하고 저장하기 때문에 대량의 데이터 폭증을 유발합니다.

가능한 모든 집계를 계산하는 주먹구구식 접근 방식을 사용하는 대신, DSS는 최대의 성능 향상을 제공하는 집계가 무엇인지 결정할 뿐만 아니라 OLAP DBA가 시스템 속도 및 집계 관리에 필요한 디스크 공간 중에 취사 선택할 수 있도록 합니다. 개발자가 모든 집계를 미리 계산한다면 디스크 공간 요구 사항이 극대화될 것이고 데이터 폭증 현상이 발생할 것입니다. 반면에, 개발자가 아무것도 미리 계산하지 않는다면 디스크 요구 사항은 전혀 없겠지만 성능이 향상되지 않을 것입니다.

대부분의 경우, DSS는 과도한 사전 집계 없이 쿼리 성능을 80% 정도 향상시킬 수 있습니다. 급격한 데이터 폭증은 일반적으로 나머지 20%의 집계가 이뤄지는 동안 발생합니다. DSS는 OLAP 메타데이터 모델을 분석하고 경험적 접근 방식을 사용하여 다른 모든 집계를 도출할 수 있는 최적의 집계 집합을 결정합니다. 그 결과 DSS는 전체 데이터 웨어하우스를 검색하는 대신 기존의 몇 가지 집계 값에서 집계되지 않은 데이터를 끌어냅니다. 그러나 이 부분 사전 집계 전략은 출발점일 뿐입니다.

DSS의 경험적 접근 방식이 뛰어나기는 하지만 이 방식은 실제 사용 양식과 일치할 수도 있고 그렇지 않을 수도 있는 수치 연산 모델을 기반으로 합니다. 실제 사용 양식에 따라 성능을 최적화하기 위해 DSS는 서버로 보내지는 쿼리를 선택적으로 로깅합니다. 그러면 이러한 로그를 사용하여 DSS가 유지하는 집계 집합을 세부적으로 조정할 수 있습니다. 예를 들어, 간단한 마법사를 통해 DBA가 응답하는 데 n초보다 오래 걸린 모든 쿼리에 대해 새로운 집계 집합을 만들도록 DSS에 지시할 수 있습니다. 여기서 n은 10초 이상이 될 수 있습니다.

대부분의 조직에서는 처리 시간이 디스크 공간보다 더 중요합니다. 디스크 공간은 언제든지 구입할 수 있지만 하루의 가치를 지닌 새 데이터를 처리하는 데 하루가 걸린다면 부족한 시간을 돈으로 벌충할 수 없습니다. 그러나 데이터 폭증 문제에 대한 DSS 솔루션은 필요한 디스크 공간의 크기를 최소화할 뿐만 아니라 초기 로드 및 증분 업데이트를 처리하는 데 필요한 시간도 줄입니다. 10GB 데이터 웨어하우스로 시작한 응용 프로그램이 10GB의 집계를 만드는 경우, 완전 폭증된 집계 집합을 처리하는 데 필요한 시간의 극히 일부만 있으면 이 집계를 처리할 수 있습니다.

DSS는 데이터 희소성 문제에 대해서도 혁신적인 방식을 채택했습니다. 세부적인 내부 구현은 서로 다르겠지만, 궁극적으로는 MOLAP 및 ROLAP 구현 모두 저장소 요구 사항을 아주 잘 관리한다는 것과 사실상 원래의 세부 데이터보다 OLAP 저장소 요구 사항이 더 적은 데이터베이스가 만들어질 수 있다는 것이 중요합니다.

사용자가 최소한 하나의 공통 차원을 공유하는 서로 다른 두 큐브의 정보를 결합하여 보고자 하는 상황이라면 가상 큐브를 사용할 수 있습니다. 개념상 관계형 뷰와 비슷한 가상 큐브는 쿼리 시에 하나 이상의 공통 차원과 함께 연결되는 둘 이상의 큐브입니다. 데이터 희소성이 중요한 문제로 인식되는 상황에서 가상 큐브의 이점을 얻을 수 있습니다. 예를 들어, 단위별 그리고 실제 판매 가격별 판매 측정값이 포함된 큐브에 할인 가격을 계산하기 위한 표시 가격 측정값도 포함될 수 있지만 표시 가격 값은 여러 번 반복될 것입니다. DSS는 가상 큐브에서 실제 판매 정보와 결합되는 표시 가격 큐브를 만들어 많은 데이터 중복을 제거할 수 있습니다. 가상 큐브를 만들 수 있다는 것은 OLAP 데이터 저장소에서 불필요한 많은 값을 완전히 제거할 수 있다는 뜻입니다.

성능 및 확장성

OLAP 응용 프로그램의 구체적인 성능은 데이터베이스 크기, 하드웨어의 처리 능력, 사전 집계된 데이터에 할당된 디스크 공간을 포함한 몇 가지 요소에 의해 결정됩니다. 그러나 실제 구현에서는 DSS 응용 프로그램이 대부분의 쿼리에 5초 안에 응답하고 거의 모든 쿼리에 10초 안에 응답합니다.

DSS에 구현된 혁신적인 분할 큐브는 OLAP 기술의 확장성을 대폭 향상시킵니다. 분할 큐브는 하나의 논리 데이터 큐브가 여러 실제 큐브, 심지어 서로 다른 실제 서버 상에 분산되어 존재할 수 있도록 합니다. 사용자 쿼리에 응답할 때 DSS는 분할된 서버 간에 쿼리를 분배하기 때문에 데이터가 병렬로 검색될 수 있습니다.

예를 들어, 열 군데의 지리적 위치에 대한 전화 호출을 추적하는 응용 프로그램을 생각할 수 있습니다. 모두 합하여 하루에 수백 만 통의 전화가 걸려온다고 가정합니다. 분석을 위해, 10대의 서버에 데이터를 분할하여 각 서버에 특정 지역의 데이터를 포함할 수 있습니다. 그러나 사용자 입장에서는 하나의 논리 데이터 큐브만 있을 뿐입니다. 사용자가 이 정보를 요청하면 DSS는 10대의 각 서버에 대한 쿼리를 적절히 변환하고 사용자에게 단일 결과 집합을 반환합니다. 특정 지역의 정보만 찾는 분석자가 10개의 각 데이터베이스에 별도로 액세스할 수도 있습니다. 여러 서버 간에 분할된 데이터를 효율적으로 관리하는 DSS의 기능을 통해, 이 기술은 다른 많은 경쟁 기술보다 훨씬 뛰어난 확장성을 제공하는 기술이 되었습니다.

전통적으로, OLAP 서버 기술은 고유의 클라이언트 기술과 긴밀히 연결되어 있었습니다. 이는 고객들에게 최고의 제품들을 함께 사용할 수 있는 선택권이 거의 주어지지 않았다는 뜻입니다. 그 결과, 매우 많은 구현 비용이 필요했으며 클라이언트/서버 및 웹 기반 OLAP 정보 배달 모두를 요구하는 응용 프로그램을 선택하게 되는 바람직하지 않은 경우도 많았습니다. 관계형 데이터베이스 업계에서 이미 수년 전에 인식한 것처럼, 응용 프로그램 및 데이터베이스를 자유롭게 선택할 수 있도록 하려면 공통 인터페이스가 필요합니다. 이렇게 하여 ODBC가 표준이 되었습니다.

업계 표준

1996년, OLAP Council이라는 공급업체 컨소시엄이 더 많은 공급업체의 참여를 끌어내기 위한 중심점을 만들 목적으로 상호 운용성 표준(MDAPI)을 발표했을 때, OLAP 도구의 개방성 문제가 처음으로 제기되었습니다. 고객들의 많은 기대에도 불구하고 OLAP Council의 구성원을 포함한 공급업체들은 대부분 API를 다루지 않았습니다.

Microsoft는 기존의 고객 투자를 활용하는 단일 표준의 필요성을 인식하고 다차원 기능을 포함하도록 기존 OLE DB 데이터 액세스 API의 정의를 확장하는 작업에 착수했습니다. Microsoft는 근 1년 동안 두 가지 API 시안을 게시하고 공급업체 및 일반인들의 의견을 공개적으로 수렴한 다음 마침내 1998년 2월 이미 베타 릴리스에서 18개 공급업체로부터 인증받은 최종 버전을 발표했습니다.

현재 14개 이상의 공급업체가 OLAP용 OLE DB API를 지원하고 있습니다. Microsoft 웹 사이트(http://www.microsoft.com/data/oledb/olap)에서 이들 공급업체 목록을 확인할 수 있습니다. 이제 내리막으로 접어든 OLAP Council의 거의 모든 구성원이 이 목록에 포함되어 있습니다. 이들 중 많은 공급업체가 이미 이 규정을 기반으로 한 베타 제품을 제공하고 있으며 DSS 사용자들은 이들 제품을 사용할 수 있습니다. 현재 Microsoft DSS 지원 제품을 제공하고 있는 공급업체 목록을 http://www.microsoft.com/sql/support/default.asp에서 확인할 수 있습니다.

연결되지 않은 상태에서의 배달 및 웹 기반 배달

업무 분석가들은 외근지에서 랩톱 컴퓨터를 사용할 때처럼 회사 네트워크와 연결되지 않은 상태에서 데이터를 다차원적으로 분석해야 하는 경우가 많이 있습니다. 이동이 잦은 사용자들은 일반적으로 전체 큐브의 일부 조각만 보고 분석하고자 합니다. 예를 들어, 판매 관리자의 경우 지역 사무소를 방문할 때 특정 지역의 수익 요약 정보를 가져가고자 할 수 있습니다. 이런 필요성은 아주 일반적이어서 DOLAP(Desktop OLAP)이라는 추가 용어가 만들어졌습니다. DOLAP은 다차원 데이터 액세스에 공유 서버를 필요로 하지 않습니다.

현재 이용할 수 있는 대부분의 OLAP 서버 기술은 사용자에게 드러나지 않게 데스크톱 DOLAP 큐브를 만드는 기능을 제공하지 않습니다. 따라서, 이 단계는 또 다른 개발 과제로 남겨지거나 데스크톱 사용을 지원하기 위해 부득이 OLAP 기능에 추가한 OLAP 클라이언트 도구로 넘어갑니다. 종합적으로, 이 때문에 연결된 클라이언트와 그렇지 않은 클라이언트 모두를 필요로 하는 응용 프로그램을 제공하는 데 따른 비용과 복잡성이 증가했습니다.

현재 모든 유형의 정보를 보기 위해 사용하는 가장 일반적인 보기 도구는 웹 브라우저이며 OLAP 역시 예외가 아닙니다. 웹 브라우저는 대규모 OLAP 응용 프로그램에서 사용자 당 비용을 줄이는 핵심적인 수단으로서 훨씬 폭넓은 대상층에 다차원 액세스 환경을 제공합니다. 현재, 인트라넷을 통해 OLAP 데이터를 배달하는 매우 우수한 제품과 도구들이 있지만 응용 프로그램 개발자들이 쉽게 사용자 정의 OLAP 보기 도구를 만들 수 있는 메커니즘은 제공되지 않습니다.

Microsoft 피벗 테이블 서비스

DSS 서버는 데이터는 물론 사용자 쿼리와 메타데이터도 캐시합니다. 캐시된 쿼리 정의와 메타데이터를 통해 DSS는 디스크에 액세스하는 대신 이전에 캐시된 데이터를 계산함으로써 새 쿼리에 응답할 수 있습니다. 예를 들어, 어떤 사용자가 1월, 2월, 3월의 판매 데이터를 요청한다고 가정합니다. 또 다른 사용자는 1/4분기의 데이터를 요청합니다. 그러면 DSS는 디스크에서 1/4분기 데이터를 반입하는 것보다 빠르게 RAM에서 1월부터 3월까지의 데이터를 요약할 수 있습니다. 이는 DSS가 가진 이점의 일부일 뿐이며 다른 대부분의 OLAP 서버와 다르지도 않습니다.

DSS는 클라이언트에 많은 동일 기능을 제공한다는 점에서 특별합니다. 모든 클라이언트는 Microsoft 피벗 테이블 서비스라는 클라이언트 구성 요소를 사용하여 DSS 서버에 연결합니다. 피벗 테이블 서비스는 "드라이버" 역할을 하여 클라이언트와 서버 간의 연결을 관리합니다. 피벗 테이블 서비스는 대부분의 코드를 DSS 서버와 공유하며 서버의 다차원 계산 엔진, 캐싱 기능 및 쿼리 관리를 클라이언트에 직접 제공합니다. 그 결과, 성능을 최적화하고 네트워크 소통량을 최소화하는 아주 혁신적인 클라이언트/서버 데이터 관리 모델이 제공됩니다. 이 모델에는 아주 약간의 컴퓨팅 비용만 필요합니다. 즉, 피벗 테이블 서비스에 필요한 디스크 공간은 대략 2MB이고 메모리 요구 사항은 캐시된 데이터 이외에 500K밖에 되지 않습니다.

DSS의 인텔리전트 클라이언트/서버 아키텍처는 사용자 요청에 최대한 빨리 응답하는 방법을 결정할 수 있으며 중복되는 네트워크 소통량을 제거할 수 있습니다. 이 아키텍처의 핵심은 클라이언트와 서버 간의 공유 메타데이터입니다. 사용자가 서버의 정보를 요청하면 데이터와 메타데이터(큐브 구조의 정의) 모두 클라이언트로 다운로드됩니다. 클라이언트에 큐브 메타데이터를 유지하면 피벗 테이블 서비스가 어떤 요청을 서버로 보내 해결해야 하는지 결정할 수 있습니다.

예를 들어, 3개월 동안의 판매 데이터 시나리오를 생각해 볼 수 있습니다. DSS 서버와 클라이언트 응용 프로그램 모두 방금 시작되었다고 가정합니다. 사용자가 1월, 2월, 3월의 판매 데이터를 요청하면 그 데이터가 서버와 클라이언트 모두에 캐시됩니다. 그런 다음 사용자가 1/4분기 데이터를 요청하면 피벗 테이블 서비스는 쿼리를 서버로 보내지 않고 클라이언트에서 로컬로 결과를 도출합니다. 이어서 사용자가 지난 해의 데이터와 비교한 올해의 1/4분기 데이터를 요청하면 피벗 테이블 서비스는 서버에 액세스하여 지난 해의 데이터만 가져옵니다.

피벗 테이블 서비스는 또한 이동이 잦은 사용자를 위한 메커니즘도 제공합니다. 서버에서 정의되고 액세스되는 큐브의 일부를 클라이언트에 저장한 다음 나중에 네트워크 연결이 끊어졌을 때 저장된 큐브에 액세스할 수 있습니다. 이런 방식으로, 비즈니스 사용자들은 외근 시 자신들의 데이터베이스 중 일부를 가져가 사무실 밖에서도 완전한 분석 기능을 사용할 수 있습니다. 또한 사용자들은 피벗 테이블 서비스를 사용하여 플랫 파일에서 데스크톱 데이터베이스에 이르기까지 간단한 OLAP 모델을 로컬로 만들고 OLE DB 호환 데이터 원본의 정보에 액세스할 수 있습니다.

마지막으로, 피벗 테이블 서비스는 웹 기반 응용 프로그램에 연결을 제공합니다. OLAP용 OLE DB는 하위 수준 프로그래밍 인터페이스이지만 다차원 데이터 액세스를 제공하는 새로운 ADO(ActiveX Data Objects) 확장이 개발되었습니다. ADO/MD라는 이들 확장을 사용하면 Microsoft Visual Basic®에서 손쉽게 ActiveX® 컨트롤을 만들어 웹 페이지에서 DSS의 데이터를 찾거나 차트를 만들거나 보고서를 작성할 수 있습니다. ADO/MD는 DSS의 전체 기능에 액세스하는 데 사용할 수 있는 회사 응용 프로그래머를 위한 도구입니다.

DSS는 OLAP 업계의 모든 비용 예측을 깼습니다. 일반적으로, 수십 명이 사용할 수 있는 OLAP 제품의 가격은 5만 달러부터 10만 달러까지 다양합니다. Microsoft는 OLAP이 데이터베이스 기술의 자연스런 확장이라는 것을 깨닫고 DSS를 SQL Server 7.0의 기능으로 포함했습니다.

SQL Server 7.0에는 데이터 웨어하우징 프로세스를 보조하는 아래와 같은 다른 많은 보완 기능들도 제공됩니다.

• 데이터베이스 스키마 작성을 위한 시각적 데이터베이스 도구
• 운용 데이터를 추출하고 변환하여 데이터 웨어하우스를 만들기 위한 데이터 변환 서비스
• SQL Server에 포함되어 단일한 메타데이터 저장소를 제공하는 Microsoft Repository

Microsoft Office 통합

Microsoft는 이후의 Microsoft Office 버전에 DSS와 호환되는 OLAP 찾아보기 기능 집합을 많이 제공할 것입니다. OLAP용 OLE DB 인터페이스를 기반으로 구축되는 이러한 새 기능은 DSS 서버에 대한 실시간 액세스, 연결되지 않은 상태에서의 사용, 웹 기반 액세스를 지원할 것입니다. 먼저, Microsoft Excel에 포함되는 새로운 피벗 테이블 기능이 Microsoft Excel 스프레드시트와 OLAP용 OLE DB 데이터 공급자 간의 연결을 가능하게 합니다. 이 공급자가 DSS인 경우 서버에 저장된 큰 큐브의 조각에서 로컬 큐브를 만드는 기능 등 추가 기능이 제공됩니다.

Microsoft Excel에 포함된 현재의 피벗 테이블® 엔진은 DSS의 피벗 테이블 서비스 엔진으로 바뀔 것입니다. 이 엔진은 현재의 피벗 테이블 동적 뷰에 적용되는 메모리 제약이 없는 다차원 구조 생성과 관련하여 데스크톱 사용자들에게 훨씬 많은 융통성을 제공합니다.

마지막으로, 이후의 Office 릴리스에서는 웹 구성 요소라는 새로운 기능 집합이 모든 웹 페이지에 추가할 수 있는 ActiveX 컨트롤을 통해 기본적인 OLAP 찾아보기 및 차트 기능을 제공할 것입니다. OLAP용 OLE DB를 기반으로 구축되는 이러한 컨트롤은 DSS를 포함한 모든 호환 OLAP 공급자와 함께 사용할 수 있습니다.

Microsoft는 기본적인 OLAP 보기 및 분석 기능을 포함하여 Microsoft Office를 강화함과 동시에, 데이터 웨어하우징 전략의 일부로 데스크톱 의사 결정 지원 도구의 구입 비용을 낮추기 위해 노력하고 있습니다.

다른 공급업체의 클라이언트 도구

OLAP용 OLE DB가 급속히 확산됨에 따라 다른 소프트웨어 공급업체들의 다양한 제품을 DSS와 함께 사용할 수 있게 되었습니다. DSS의 정보에 액세스하는 데 사용할 수 있는 기존의 또는 새로운 클라이언트 도구와 구성 요소가 많이 있기 때문에, 고객들은 응용 프로그램 요구 사항을 충족하는 제품을 더욱 폭넓게 선택할 수 있고 클라이언트 도구 구입과 관련된 비용을 더 많이 줄일 수 있습니다.

결론

SQL Server 7.0에 포함된 많은 데이터 웨어하우징 지향적 기능을 통해, Microsoft는 업계에서 선도적 위치를 차지하고 있으며 좀더 저렴한 소프트웨어를 제공하여 데이터 웨어하우징 시장을 확대하기 위해 노력하고 있습니다. Microsoft 데이터 웨어하우징 프레임워크 아키텍처를 기반으로 구축된 의사 결정 지원 서비스 같은 제품들이 이전보다 저렴하고 간편한 데이터 웨어하우징 기능을 제공하기 위해 선도적인 역할을 하고 있습니다. 앞으로 Microsoft Office에 포함될 OLAP 찾아보기 기능과 함께, Microsoft의 데이터 웨어하우징 및 의사 결정 지원 응용 프로그램 제품군을 선택하는 고객들은 회사의 성장과 함께 확장될 수 있고 업계의 뛰어난 많은 도구를 수용할 수 있는 솔루션을 제공받는 것입니다.

이 문서에 포함된 정보는 문서를 발행할 때 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 나타냅니다. Microsoft는 변화하는 시장 환경에 대처해야 하므로 이를 Microsoft 측의 책임으로 해석해서는 안 되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보장하지 않습니다.

이 설명서는 오직 정보를 제공하기 위한 것입니다. Microsoft는 이 설명서에서 어떠한 명시적이거나 묵시적인 보증도 하지 않습니다.

© 1998 Microsoft Corporation. All rights reserved.

Microsoft, ActiveX, BackOffice, BackOffice 로고, Fox Pro, PivotTable, Visual Basic 및 Windows NT는 미국, 대한민국, 및/또는 기타 국가에서의 Microsoft Corporation의 등록 상표 또는 상표입니다.

여기에 인용된 다른 제품이나 회사 이름은 해당 소유자의 상표일 수 있습니다.

달리 언급하지 않은 한 여기에 인용된 회사, 제품, 사람, 인물 및/또는 데이터는 보기일 뿐이며 어떠한 실제 개인, 회사, 제품 또는 이벤트와도 연관시킬 의도가 없습니다.

1 "Providing OLAP (On-line Analytical Processing) to User-Analysts:An IT Mandate", E. F. Codd and Associates, 1993

2 OLAP Report 웹 사이트를 참조하십시오.

3 OLAP 모델에서 집계 수는 차원 수, 계층 구조 안의 수준 수 및 부모-자식 비율에 의해 결정됩니다. 문제의 복잡성에 대한 자세한 설명을 보려면 OLAP Report 분석 웹 사이트를 참조하십시오.