■ WareHouse Server 통합관계형 OLAP의 진화

▶ 실무 적용

조직들은 점차적으로 데이타 웨어하우스가 널리 사용됨에 따라 정보에 보다 낫게 접근함으로써 얻을 수 있는 경쟁 우위를 인식 하고 있다. 사용자의 분석 환경이 점차 복잡해지고, 조회되고 있는 데이타 볼륨이 겉보기에도 지수적인 성장을 함에 따라 기존의 데이타 웨어하우스 아키텍쳐, 조회 도구, OLAP(On-Line Analytical Processing) 기술들은 그것들의 한계에 이르고 있다. 병렬 하드웨어와 데이타베이스 기술의 출현으로 데이타를 저장할 수 있는 능력이 데이타를 효과적으로 접근하고 분석할 수 있는 우리 의 능력을 앞질렀다.

정밀한 의사 결정 지원 환경을 다루는 기본 아키텍쳐는 본질적인 진화를 경험하고 있다. 즉, 단순한 관계형 데이타베이스와 조 회 도구 패러다임에서 의사 결정 지원 어플리케이션에 최적화된 다차원 OLAP 데이타베이스로, 정교한 관계형 OLAP 기술로 진화하 고 있다. 이 논문은 본질적 진화의 다음 단계를 다룬다: 통합 관계형 OLAP. 선두 데이타베이스 회 사들이 정교한 분석적, 다차원 적 기능을 데이타베이스 기술에 결합시킴에 따라 결과로 나타나는 보다 나은 성능, 확장성, 병렬성들이 종전보다 더 정교한 분석 을 가능하게 할 것이다.

이와 상응하게, 조회 도구의 선두 회사들은 주요 관계형 데이타베이스의 본래의 분석적인 기능의 확장을 지원하기 위해 움직이 고 있다. 이것은 유니버설 데이타베이스 서버 와 유니버설 조회 클라이언트들을 향한 클라이언트/서버 업계의 광범위한 경향을 반영하는 것이다. 변화가 안정이 되면 데이타베이스 기술과 비통합 관계형 OLAP 조회 도구 회사들은 그런 통합 솔루션들과 경쟁 하는 것이 점차적으로 어려울 것이라는 것을 알게 될 것이다.

▶ 조회 도구

관계형 패러다임의 약속은 결국 기업 데이타에 대한 비정형(ad hoc) 혹은 비체계적인 접근을 가능 하게 하는 것이었다. 1세대 조회와 리포트 도구는 처음으로 정교한 파워 유저들 혹은 IS 스탭들 자신이 리포트를 만들 수 있도록 했다. 첫 제품에서는 관계 형 데이타베이스로부터 결과 세트를 만들기 위해서는 사용자가 업계 표준 구조화 질의어(SQL)를 이해해야 했다.

보다 정교한 조회 도구는 후에 메타데이타를 사용하여 관계형 테이블들과 열들의 기본 이름들을 친숙한 기업 용어들로 대체하였 고 포인트-앤드-클릭 인터페이스를 추가하여 자동적으로 리포트를 만들게 했다. 이런 메타데이타 사전들은 테이블들을 어떻게 조 인(join)할 것인가에 대해서도 기술하고 있어서 사용자들이 관계형 이론과 조인(join)을 전과 같이 명확하게 이해할 필요가 없다 . 관리 조회 환경(MQE)의 주요 회사들은 현재 이러한 영역을 개척하기 시작했다.

▶ 조회 도구에 증대되는 요구들

조회 도구들이 사용의 편리성에 있어서는 주요한 발전을 한 반면, 오늘날 데이타 웨어하우스 환경에서는 상당한 장벽에 부딪치 고 있다. 특히, 다양한 사용자 집단들에 걸친 확장성, 응용성의 영역들에서는 뒤쳐지고 있으며 분석적 기능에 있어서도 정교성이 부족하다.

▶ 확장의 필요성

많은 조직들이 이 장벽을 인식함에 따라, 프로토타입 데이타베이스에서 실행되는 어플리케이션들은 전체의 데이타 웨어하우스에 서 원하는 대로 실행되지 않을 수도 있다. 메타 그룹에 따르면, 데이타 웨어하우스의 평균 사이즈는 100GB를 넘고 있으며 그 이 상으로 확장되고 있다. 불행하게도 종전의 조회 혹은 리포트 도구를 대형 데이타 웨어하우스에서 사용하게 되면 과도하게 많은 잘 정의되지 않은 조회들이 거대한 소트 영역의 요구와 Cartesian Products의 수행 등과 함께 GIGA바이트의 디스크를 스캔하게 되어, 따라서 성능이 급속히 관심의 촛점이 되었다.

▶ 새로운 사용자들

증대되는 방대한 데이타를 저장하는 것 뿐만 아니라 데이타 웨어하우스는 데이타베이스의 접근을 통해 사용자 집단의 폭과 수를 증가시키고 있다. 모든 수준의 의사 결정자를 지원 하기 위한 관계형 데이타베이스는 IS 스탭뿐만 아니라 기업 분석가, 마케팅 판매 책임자, 중역들 등에 의해서도 접근되고 있다. 불행하게도 이러한 모든 사용자 집단들의 요구를 충족하기 위한 도구가 없다

더 복잡한 분석 기능 비지니스 사용자들에게 기업 데이타의 접근이 더 필수적이 됨에 따라 이러한 데이타를 어떻게 사용하는 가 에 대한 요구도 커지고 있다. 예를 들어, 사용자들은 시계열('내게 ...의 성장률을 보여 주시오' 혹은 '작년 같은 기간과 비교한 이번 기간의 총이익을 보여주시오' ), 횡차원(Cross-dimensions) 비교 ('각국의 합계에서 내 지역의 판매액이 차지하는 비율을 보여 주시오' ), 4분기 분석('나의 최고 판매 브랜드를 4분기 순위에 넣으시오'), 통계 프로파일('판매액의 하위 20%의 모든 상 점들에 대한 각 상점별 판매액을 보여 주시오' ), 버킷(Buckets : '수입 그룹에 의해 발 생하는 평균 은행 계좌 잔고를 보여주시 오') 등과 같은 분석 기능들을 적용하기 원하고 있다. 표준 SQL을 이용하여 이러한 종류의 물음들에 대해서 대답하는 것이 어렵 고 거의 불가능 하기 때문에, 종전의 조회 도구의 한계를 넘은 것이라고 할 수 있다. 사용자들은 좀더 자세한 분석을 위해 검색 된 데이타를 스프레드시트로 보냄으로써 문제들을 해결하려고 노력한다. 불행하게도 이런 많은 물음들은 큰 볼륨의 데이타가 가 끔은 다중 조회들로부터 사전 처리되는 것을 필요로 하고, 불행히도 이러한 작업들은 데이타 베이스의 도움이 없이는 불가능한 작업들이다.

▶ 조회 도구의 개선

조회 도구 회사들은 이런 대형 스케일의 데이타 웨어하우스들에 의해 야기된 요구들에 대응하기 시작했다. 예를 들어, Business Objects는 대형 데이타베이스에서의 유용성을 개선 하기 위해 이 보고서에서 기술되는 관계형 OLAP 기술의 일부를 사용할 것이 다. 게다가 조회 도구들은 주요 데이타베이스 시스템으로 통합되고 있는 OLAP 기능을 점차적으로 지원하고 있다. 예를 들어, Cog nos PowerPlay는 인포믹스-유니버설 서버의 MetaCube OLAP 기능을 직접 지원 할 것이다.

15

그림 :

조회 도구 아키텍처

▶ 다 차원 데이타 베이스

제 일세대 조회 도구 접근과 관련된 성능과 분석의 문제를 다루기 위해 일련의 회사들은 조회와 분석에 최적인 별개의 기술을 개발했다. 다차원 데이타베이스(MDD)는 사용자들이 인식하는 사업 규모에 상응하는 특화된 배열 포맷으로 데이타를 저장하는 특 별한 엔진이다. 업계 표준 SQL을 버리고 자신만의 어플리케이션 프로그래밍 인터페이스(API)를 개발함으로써 MDD는 SQL의 한계를 뛰어 넘을 수 있으며 서버 자체 내에서 더 많은 분석 기능들을 수행할 수 있다. 앞 섹션에서 제기된 몇 개의 물음들과 같은 많 은 물음들이 MDD에 의해 쉽게 해결 된다.

불행하게도, 이런 분석 기능을 이용하기 위해서 사용자는 특화된 데이타베이스에서 사용 가능한 주로 MDD 회사에 의해 제공되는 , 제한된 조회 도구들만을 사용해야 한다. 유일한 대체 안은 일반적으로 C에 기록되어 있는 낮은 수준의 API를 찾아 내는 것인데 이것은 최종 사용자(실 사용자)들뿐만 아니라 대부분의 회사 개발자들의 범위의 밖에 있는 것이다. MDD 저장 기술과 접근 방법 들이 기본적으로 관계형 기술과 다르기 때문에 제조 업체나 고객들이 이 둘을 효과적으로 통합하는 것은 매우 어려운 일이다. 고 객들은 관계형 데이타 웨어하우스에서 특화 된 다차원 포맷으로 복제해야 하는데 이는 엄청난 간접비와 유지 비용이 따르게 된다 .

[img16]

그림 : (비통합) 관계형 OLAP 아키텍처

▶ 더 견고한 메타데이타

ROLAP 시스템은 기존의 테이블과 열들에 단순히 비지니스 라벨을 부치는 것을 뛰어 넘는다. ROLAP 시스템은 논리적이고 다차원 적인 모델에 따라 기본의 관계형 구조를 분류한다. 계층들이 정의되고 관계와 DRILL 경로들이 도출된다. 예를 들어, ROLAP 시스 템은 '구역', '지역', '국가'같은 독립적인 엔티티를 갖기보다는 사용자들이 더 쉽게 찾아갈 수 있는 '지리' 라고 하 는 차원으 로 이것들을 체계화 하는데 이것이 사전 통합을 계산하는 기본이 되며 높은 조회 성능을 위한 핵심기술이라고 할 수 있다.

ROLAP 기술은 사용자들을 단순히 SQL을 숨기는 조회 도구에서 한 발 더 나아가 기본 관계형 모델에서 격리시키지만 그래도 사용 자들은 관계형 개념을 이해할 필요는 있다. 사용자들, 심지어 어플리케이션 설계자들까지도 논리적, 다차원 모델을 이해만 하고 있을 뿐이다.

ROLAP 시스템을 정의할 수 있는 성격은 조회 실행 시간에 다이나믹하게 수행되며 사용자들과 어플리케이션에 투명한 자동적이고 정교한 SQL 생성이라고 할 수 있다. 이것은 시스템 설계자들이 후에 의사결정 지원 어플리케이션을 전혀 바꾸지 않으면서 데이 타의 사전 연산 방법을 바꿀 수 있도록 한다.

▶ 배치(일괄) 대 동적 Tradeoff

OLAP 시스템에는 시스템을 설정하는 데 필요한 작업의 양과 ad hoc 조회를 수행하기 위해 필요한 작업의 양 사이에 tradeoff이 존재한다. 만약 모든 조회가 무엇이며 어떤 순서로 조회들이 실행될 것인가를 정확히 알 수 있다면 한 결과를 최단 시간에 얻기 위한 연산 처리를 명확히 최적화 할 수 있을 것이다. 불행하게도, 데이타 웨어하우스에서는 아직 이런 것들을 누릴 수는 없다. Pa ge 39/42전통적인 조회 도구 운용은 일반적으로 모든 원시 데이타를 데이타 웨어하우스에 읽어 들이고 조회 도구로 하여금 원하 는 물음을 묻는 것이었다. 이 경우, 조회 결과를 공식적으로 나타내는 거의 모든 작업이 조회 실행 시간에 이루어진다. 결과는 대형 데이타 웨어하우스를 사용할 때로는 수준 미달의 성능으로 나타난다.

한 편으로, MDD는 모든 조회의 결과들을 과도하게 사전 계산하는 접근을 취한다. 이것은 조회의 응답을 신속하게 하지만, 시스 템을 로드할 때 과도한 지연과 확장성 문제가 있다.

ROLAP 시스템은 시스템 설계자들에게 중간의 어느 수준에서든 이러한 Tradeoff을 조절할 수 있게 한다. 사실, ROLAP 시스템에서 는 이것은 데이터 웨어하우스의 초기 전개 후에 조정될 수 있는 조정(Tuning) 문제이다. 왜냐하면 모든 일괄 처리와 조회 처리 기능들이 메타데이타에서 얻어지기 때문 이다. ROLAP 시스템은 사전 계산할 양과 조회 실행 시 '진행중에(on the fly)' 다이나믹 하게 통합할 양에 대해 기본적으로 중립적이다. 이것은 ROLAP 시스템이 종전의 어떤 기 술보다도 높은 성능으로 더 큰 데이타 웨 어하우스로의 확장을 가능하게 한다.

▶ OLAP 관계형 기술의 발전

관계형 플랫폼에서의 데이터 웨어하우징에 대한 수요 증가의 일로에서 데이터베이스 판매 업계의 선두주자들은 OLAP 스타일 질 의의 반응 시간을 현저하게 단축시키는 주요 기능들을 추가시키고 있다. 이것으로 인해서 ROLAP 솔루션은 경쟁사 제품들과 한층 더 달라지고있다.

▶ 병렬 처리

데이터 웨어하우스들이 안고 있는 주요 문제들 중 하나는 데이터의 분량이다. 복잡한 액션들을 각각 병렬로 실행시키기 위해서 작은 부분들로 쪼개는 작업에 있어서 병렬처리 작업은 매우 중요하다. 이것만 실행되면 실행이 훨씬 빨라진다. 다른 데이터베이 스 회사들은 병렬처리 지원에 대한 완전성과 결과에 있어 상당히 다른 결과들을 얻어왔다. 그러나 데이터베이스 제품들이 모든 부분에서 병렬 실행 작업을 위해 최적화된 것은 아니다.

최상의 결과는 질의 작업과 로딩 작업을 포함하는 주요 작업의 내부 혹은 핵심 병렬처리로 인해서 얻어진다. 최첨단 병렬 데이 터베이스의 질의 프로세서들은 Hash 함수를 사용한 파티션 연산자를 지원해서 OLAP 스타일의 질의에서 가장 중요한 작업인 소트, 조인 그리고 총계 기능들을 완벽하게 병렬처리 한다.

데이터베이스 선정 벤치마크에서 종종 간과되는 로딩, 백업 그리고 저장 작업 또한 마찬가지로 중요하다. 이러한 작업들을 완벽 하게 병렬처리하는 것은 모든 크기의 데이터 웨어하우스에 있어서 절대적으로 중요하다. 그러나 MDD 제품 중에는 이러한 병렬성 을 갖춘 것이 하나도 없다.

▶ 데이터 분할(Data Partition)

데이터를 효과적으로 분할하는 것은 방대한 데이터를 처리하는데 좋은 무기가 된다. 데이터를 분할함으로써 하나 혹은 다수의 테이블 부분들을 자동으로 하나 이상의 부분으로 분배해서 데이터베이스가 작업을 병렬화 하는 기능을 강화하고 큰 데이터 세트 를 쉽게 유지하게 한다. 분할은 또한 데이터베이스가 데이터를 병렬로 최고 속도로 작동하는 다수의 실제 기기에 분배할 수 있게 한다. 최첨단 병렬 데이터베이스의 구현에는 다양한 분할 옵션을 지원하는데 여기에는 데이터 웨어하우징에 매우 중요한 범위에 기초한 분할, 해시에 기초한 분할, 라운드 로빈 분할등이 포함된다.

▶ DSS 색인(인덱스)

의사 결정 지원 어플리케이션들을 위해 관계형 데이타베이스 성능을 향상하는 몇 가지 전문적인 인덱스들이 있다. OLAP 스타일 의 조회에 가장 중요한 종류는 다중테이블 인덱스로서 스타(중앙, 발사형) 조인 인덱스의 범용화 된 형태라고 할 수 있다. 다중 테이블 인덱스는 테이블간의 조인들을 효과적으로 사전 계산하면서 같은 인덱스에서 한 개 이상의 테이블들로부터의 열들을 포함 한다. 조인은 조회 처리에서 늦은 작업들 중의 하나이기 때문에 인덱스 기능은 조회 응답 시간을 현저히 개선시킬 수 있다.

또 다른 중요한 새로운 인덱스는 비트맵 인덱스이다. 인덱스를 보이기 위해 종래의 트리를 사용하는 대신에 비트맵은 한 필드( 항목)에 '참'과 '거짓'을 나타내는 '0'과'1' 같은 주어진 값의 존재를 표시한다. 비트맵은 낮은 카디널리티의 데이터를 효과적으 로 색인한다; 즉, 실제 값의 가능성들이 적은 데이터를 말한다. 카디널리티가 낮은 항목들의 예로서 '성'(남 자 아니면 여자) 혹 은 '구매 형태'(현금, 수표, 카드)를 들 수 있다. 비트맵들은 그런 데이 타의 전통적인 인덱스 보다 훨씬 작고 데이타를 직접 읽 거나 다른 대체 인덱스를 통하는 것보다 훨씬 신속하게 병행적으로 계산이 가능하다.

코어 데이타베이스 조회 처리와 최적화에 기본이 되는 어떤 새로운 인덱스 기술에서는 코 어 데이타베이스 안에 인덱스가 공유 저장 관리자(Shared Storage Manager), 조회 비용 모델(Query Cost Model), 관리 점(point of administration)과 함께 내장되는 것이 중요하다.

▶ 분석기능의 확장성

객체-관계형 기술이 등장함에 따라, 고객과 다른 주변 제조자들은 데이타베이스 서버 자체 의 주요 분석적 기능을 본질적으로 확장 할 수 있게 되었다. 고객들은 사용자-정의 집합 (aggregation) 기능과 사용자 정의 분석 기능을 잘 정의된 객체 프로그래밍 모델을 사용하여 데이타베이스에 첨가 할 수 있다. 이런 기능들이 일단 정의되면, 내장된 기능처럼 동작하 고 코어 데이타베이 스에 완전한 병렬성과 성능을 가져다 준다.

▶ OLAP을 위한 통합 관계형 기술

관계형 OLAP 기술은 대부분의 복잡한 의사 결정 지원 요구 사항들을 위한 뛰어난 솔루션 임에도 불구하고 자체의 비통합적이고 이질적인 층(tier) 구조에 제한을 받는다. 문제는 데이타들이 분석 처리로부터 물리적으로 분리되어있다는 것이다. 많은 조회에 있어서 이것은 주요한 문제는 아니다; 그러나 이것은 가능한 분석의 범위를 제한한다.

전통적인 ROLAP 시스템에서는, 분석 엔진이 최적의 SQL 문구를 나타내고 RDBMS 서버로 보낸다. 그러면 다시 서버로부터 데이터 를 받고 재통합하며 다음 단계의 분석과 연산을 사 용자에게 최종 결과를 제공할 때까지 수행한다. 보통 이것은 데이타가 네트워 크에서 두 번 이동하는 것을 말한다; 한 번은 분석 서버로 다시 클라이언트 어플리케이션으로.

OLAP 기술의 다음 논리적 단계는 ROLAP 엔진과 확장 가능하고 병렬적인 RDBMS 자체 의 통합이라고 할 수 있다: 통합 관계형 OLAP. 통합된 데이타베이스 서버와 관계/다차원 해석을 위한 비용 기준 최적기를 사용하 여 유니버설 서버는 전례 없는 성능과 확장성을 데이타 웨어하우스에 제공한다.

■ 자료출처

1. Inmon, W.H., Building the Data Warehouse(2nd Ed.), John Wiley & Sons, Inc., 1996

2. Keen, P.G.W., Every Managers Guide to Information Technology, Harvard Business School Press, 1991.

3. 조재희,박성진,"데이터웨어 하우징과 OLAP", 대청출판사, 1998

4. 오라클사의 데이터웨워하우스 솔루션

http://www.oracle.co.kr/product/datawarehouse/index.html

5. 싸이베이스 데이타웨어 하우스 솔루션

http://www.sybase.co.kr/solution/dw.htm

6. The University Data Warehouse at Stanford(스탠포드대학의 데이타웨어하우스 구축사례)

http://www.stanford.edu/cgi-bin/leland/group/da/Warehouse/Warehouse.html

7. 관계형 데이터베이스에 관한 데이터 웨어하우스(Data Warehouse) 디자인

http://www.informix.com/kr/library/wp/dw/dwwp/dw.html

8. 인포믹스 데이터 웨어하우스 서버 (통합 관계형 OLAP의 진화)

http://www.informix.com/kr/library/wp/dw/olapwp/dwrolap.html

9. 한국후지쯔 데이터웨어하우스/OLAP 솔루션

http://www.fujitsu.co.kr/solution/datawarehouse/dwh.html

10. The Data Warehousing Information Center

http://pwp.starnetinc.com/larryg/

11 The Data Warehousing Institute "데이타웨어하우징의 세계적인 동향분석"

http://www.dw-institute.com/

12. MicroStrategy Relational OLAP (ROLAP) Solutions for Decision Support and Data Warehousing

http://www.strategy.com/

13. CIO Korea Page(최고경영자를 위한 경영정보 기술지 site로써 국내의 Warehouse에 대한 동향을 알수 있다

http://cio.seoul.kr/resource/dataware.htm

14. PLATINUM Data Warehousing Overview

http://www.platinum.com/products/dataware.htm

15. 한국쌔스소프트웨어(주) "데이타마이닝 솔루션 제공"

http://www.sas.com/offices/asiapacific/korea/index.html