데이터 아키텍처의 이해 ①
데이터 아키텍처의 필요성
윤성호 | 엔코아컨설팅 책임컨설턴트
연·재·목·차
제1회: 데이터 아키텍처의 필요성
제2회: 데이터 아키텍처의 구성요건
제3회: 데이터 아키텍처 활용방안
제4회: 데이터 아키텍처의 단계별 접근전략
제5회: 데이터 아키텍처의 확장
IT시스템을 활용해 기업의 목적을 달성하기 위해서는 체계적인 정보기술 아키텍처의 도입이 필수적이다. 이에 따라 최근 들어 EA가 주목 받고 있는데 그 중에서도 데이터 아키텍처의 중요성이 더욱 커지고 있다. 데이터 모델링을 포함해 데이터에 관한 모든 것을 체계화하는 데이터 아키텍처는 향후에 나타날 수 있는 IT의 시행착오를 현격하게 감소시켜 줄 수 있는 불요불급한 방법론이다.
최근 국내 소프트웨어산업의 피폐함을 탄식하는 분들을 많이 만나게 된다. 제품 기획부터 설계, 프로덕트 마케팅, 유통, 기업 솔루션 영업의 난맥상에 이르기까지 국내 소프트웨어산업 태동기부터 감지되어 왔던 문제점들이 끊임없이 확대 재생산되는 느낌이다. 아무래도 기업이 요구하는 전반적인 IT시스템 규모가 커지면서 소프트웨어분야도 이에 상응하는 발전과 진보를 보여야 함에도 불구하고 여전히 구습을 이어가고 있기 때문에 그만큼 문제점이 크게 드러나고 있는 것이다.
무엇이든 다급하게 당장 눈에 보이는 것을 만들어 내는데 익숙한 우리 문화가 전문 소프트웨어업체의 소프트웨어 제작 과정이나 기업 전산팀의 시스템 설계에도 그대로 반영되고 있다. 물론 빠른 대응이 전반적인 IT 산업의 외면적인 발전에 크게 기여한 요인이었던 것을 부인할 수는 없으나 그 발전이라는 것이 편중된 사상누각이라면 언제까지고 심각한 부작용으로 남을 것임은 자명하다.
많은 기관과 업체에서 근본적인 문제를 해소하기 위해 다각도의 노력을 기울여 왔음에도 10년 전의 상황에 비해 개선이 없는 원인은 무엇일까? 그 실마리를 필자는 ‘근본으로 돌아가자’는 여전히 유효한 구호에서 찾고 싶다. 가장 상식적인 기본들이 지켜지고 있지 않은 현실이 지금까지도 근본으로 돌아가야 하는 상황을 만들어 내고 있는 것이다.
일례로 소프트웨어 솔루션을 개발하는 과정을 들여다보자. 시장과 고객의 요구를 정확히 분석, 수요를 예측하고 이를 구체적인 컨셉으로 정의하여 제품 설계에 반영한 후 점차 세밀한 집적도를 완성해 가는 ‘체계화’를 기대하기란 거의 불가능하다. 심지어 상황이 다급하면 설계도도 없이 일단 당장 필요한 기능에 맞추어 소스를 붙이는데 급급해 왔다. 전문 개발사에서조차도 이런 상황이 되풀이되고 있으니 참으로 답답한 현실이라 하겠다.
그러다 보면 결국 시스템을 통합하거나 근본적으로 개·보수해야 하는 큰 변화에 부딪히면 단순한 비효율을 뛰어넘는 위기상황이 연출되고야 마는 것이다. 지극히 비상식적으로 보이지만 주변을 돌아보면 어디서나 발견되는 현상이다. 많은 분들이 공감하듯 원칙과 근본을 무시해왔기 때문에 벌어지는 일이다. 만약 책임 있는 담당자가 당장의 이익과 조건에 연연하지 않고 제대로 하는 것을 목표로 하여 진행했다면 결코 일어나지 않았을 시스템 사고들이 아직도 되풀이되는 것은 바로 근본을 무시했기 때문이다.
ITA 도입 필요성
패러다임의 변화와 IT환경의 급격한 변화는 오늘날의 경영 환경을 본격적인 정보화 시대로 도래하게 하였고, 국제화의 급속한 전진, 기업간의 인수, 합병, 소비자 요구의 고급화 등에 따라 국제화와 산업 개편이 가속화되었으며, 더욱 전문화되고 다각화 된 형태로 나타나고 있다. 이에 따라 경영환경의 목적이 효율과 효과를 지향하는 패러다임으로 확실하게 변해가고 있다. 이러한 변화는 필연적으로 모든 변화의 기반이 되는 정보기술 환경의 변화를 불러와 네트워크의 보편화, 전자상거래, 보안, 데이터 마이닝의 필요성과 신속한 경영 의사 자료의 요구성을 크게 높여 주었고, 이를 위해 클라이언트/서버 및 분산·객체 환경으로 변화가 더욱 가속화되고 있다.
그럼에도 불구하고 기존의 개발 방법론의 문제점에 따라 엔터프라이즈의 목적과 아키텍처 부문의 연계는 아주 미흡하였다. 정보 시스템 활용을 통한 조직의 목표의 효과적인 달성과 전략적 우위 선점이라는 기업의 목적을 위해서는 체계적인 정보기술 아키텍처의 도입이 절실히 요구되고 있다.
오늘날 기업 활동은 ‘비즈니스’와 ‘정보 기술’이라는 두 개의 큰 축으로 유지된다. 이들 간의 원활한 상호 작용을 구체화하기 위한 모델의 중심에 ‘정보기술 아키텍처(ITA)’의 사상이 있다. 패러다임과 IT환경의 급격한 변화는 경영 환경의 목적을 효율과 효과지향적으로 확실하게 변모시키고 있지만 기존의 개발 방법론의 문제점에 따라 기업의 목적과 아키텍처 부문과의 연계는 아주 미흡하였다. 이로 인해 경영의 기반인 정보 시스템이 근본적으로 불안하게 되어 빈번하게 아키텍처를 조정해야 하는 악순환이 반복되고 있다.
따라서 정보 시스템 활용을 통한 조직 목표의 효과적인 달성과 전략적 우위 선점이라는 기업의 목적을 위해서는 비즈니스의 실행에 필요한 정보와 기술, 업무의 변경 요구에 적용할 새로운 기술로의 전환 프로세스를 설명한 전략적 정보 자원인 정보기술 아키텍처의 도입이 절실하게 요구된다. 정보기술 아키텍처(ITA, Information Technology Architecture)는 정보 시스템에 대한 요구 사항을 충족시키고, 상호 운용성 및 보안성을 보장하기 위해 조직의 업무와 사용되는 정보, 그리고 이들을 지원하기 위한 정보 기술 등의 구성 요소를 분석하고, 이들 간의 관계를 구조적으로 정리한 체계로서 전사적 아키텍처, 기술 참조 모델, 표준 프로파일로 구성된다.
정보 기술 아키텍처에서 가장 대표적인 쟈크만 프레임워크는 가로축에 아키텍처를 수립해야 할 대상을 육하원칙에 입각해서 정의하였으며, ‘What’을 ‘데이터’로 인정함으로써 데이터야말로 정보 시스템의 근원이라는 것을 나타내고 있다. 세로축은 상세화 수준을 정의한 것으로써 가로축의 모든 구성 요소들이 최상위 단계에서부터 최하위 단계에 이르기까지 모두 아키텍처를 수립해야 한다고 주장하고 있다.
<그림 1> 쟈크만 프레임워크
전사적 아키텍처의 도입 의미
필자는 최근 공공 부문과 금융권 대형 프로젝트를 중심으로 큰 이슈가 되고 있는 EA(Enterprise Architecture) 역시 결국 ‘설계’라는 근본으로 돌아가서 체계를 바로 잡는 방법론이라고 믿고 있다. 비즈니스 설계(Business Architecture), 애플리케이션 설계(Application Archi-tecture), 기술적 설계(Technical Archi-tecture), 데이터 설계(Data Archi-tecture) 등 4가지 중심축으로 구성되는 EA는 단순화시켜 말하자면 각 하부 영역의 구조적인 설계를 서로 유기적으로 통합하는 과정으로 설명할 수 있을 것이다. EA의 최종적인 키워드는 역시 설계 또는 체계화로 정의될 수 있는 아키텍처(Architecture)로 귀착된다.
체계화란 최상위의 개괄적인 단계에서부터 출발하여 개념적인 단계, 논리적인 단계, 물리적인 단계, 부가적인 상세화 단계, 실제 운용 단계에 이르기까지 모든 진행 과정이 서로 완벽한 연결(얼라인먼트)이 되도록 해야 한다는 것을 말하며, 이것이 지금까지의 접근 방법과는 크게 다른 점이다.
전사적 아키텍처(Enterprise Archi-tecture)는 업무와 업무 실행에 필요한 정보, 이것을 지원하는 기술, 그리고 새로운 기술의 실행을 위한 전환 프로세스를 설명한 전략적 정보 자원의 기초이다. 전사적 아키텍처(Enterprise Architecture)의 기반이라고 할 수 있는 데이터의 완벽한 아키텍처를 수립하기 위해서는 체계적인 접근 방법과 내용의 합리성을 극대화시킬 수 있는 구체적인 판단 기준들이 필요하다.
DA의 정의와 구성
이러한 EA의 각 하위 요소 중에서도 특히 중요하게 여겨지는 요소가 바로 데이터 아키텍처(DA, Data Architecture)인 것도 우연이 아니다. 애플리케이션이나 기술적인 요소보다 언제나 먼저 정의되어야 하는 것이 시스템의 근본을 구성하는 데이터 요소다. 기업 정보 시스템을 구성하는 가장 기본적인 원자라 할 수 있는 데이터에 관련된 모든 구조를 상세한 설계 과정을 통해 체계화하는 것이 바로 데이터 아키텍처다. EA중에서 데이터 아키텍처가 특히 중요성을 인정받는 이유 역시 데이터의 이런 근본 지향적인 특성에서 찾을 수 있다.
데이터 아키텍처란 데이터 모델링을 비롯해 그보다 더 개괄적인 영역과 물리적인 영역까지도 포함한 데이터에 관한 한 모든 구조를 체계화하는 것을 말한다. 체계화란 최상위의 개괄적인 단계에서부터 출발하여 개념적인 단계, 논리적인 단계, 물리적인 단계, 부가적 상세화 단계, 실제 운용하는 단계에 이르기까지 서로 완벽한 연결(얼라인먼트)이 되도록 해야 한다는 말이며, 이것이 지금까지의 접근 방법과 크게 다른 점이다.
특히 인간이 결정해야 할 모든 것들을 체계적으로 형상화해야 하는 논리적 모델 구현 단계는 데이터 아키텍처 수립의 핵심이다. 어떤 방법론을 이용해 정보 시스템을 구축하든지 데이터는 언제나 존재하는 필수적이고, 본질적인 것이므로 결코 홀대할 수 없는 귀중한 자산이다.
이처럼 데이터 아키텍처는 데이터에 관한 모든 계층을 총망라해서 객관적이고 구체적인 접근 방법을 명시한 체계적인 방법론이다. 마치 건물을 구축할 때 전체적인 전략을 설계한 조감도를 먼저 작성한 다음, 개념적인 구조를 결정하고, 점차 상세한 설계와 시방서를 작성해 가는 것과 유사하다. 기업 정보의 골격인 데이터를 이처럼 체계적으로 접근해 내려오는 것은 매우 가치 있는 일이고, 앞으로 나타날 수 있는 시행착오를 현격하게 감소시켜 주는 한 차원 높은 접근 방법이다.
<그림 2> 데이터 아키텍처의 구성
제공 : DB포탈사이트 DBguide.net
[출처] 데이터 아키텍처의 이해 ①|작성자 눈꽃천사
[참조사이트] http://blog.naver.com/oyukihana.do?Redirect=Log&logNo=60007657362
2009년 2월 1일 일요일
데이터웨어하우스 및 데이터마이닝 개요
데이터웨어하우스 및 데이터마이닝
* 세부사항 첨부참조
1. 데이터웨어하우스
가. 데이터웨어하우스 개요
(1) 데이터웨어하우스의 정의와 특징
데이터웨어하우스(Data Warehouse)는 1990년대 중반 이후 데이터베이스 분야에서 특히 학문계에서보다 산업계에서 그 태동이 시작되었다. 많고 다양한 형태의 오퍼레이셔날 데이터베이스(Operational Database)가 운용되고 시간이 지날수록 그 데이터베이스의 크기가 커지게 되었다. 따라서 데이터베이스 위에서 의사 결정(decision making) 등을 위해 사용되는 다양한 종류의 응용프로그램들은 그 질의(query) 수행이 원만하게 이루어지기 위하여 오퍼레이셔날 데이터베이스 위에 새로운 형태의 통합된 데이터 저장소(repository)가 필요했는데, 이것이 데이터웨어하우스가 등장한 배경이라 할 수 있다.
데이터웨어하우스의 정의에는 여러 가지가 있지만 데이터웨어하우스 시스템 아키텍처를 초창기에 이끈 W.H. Inmon에 따르면, "데이터웨어하우스란 의사 결정 프로세스를 지원하도록 데이터를 1) 주제 지향적(Subject-Oriented)이고, 2) 통합(Integrated) 되고, 3) 시계열적(Time- Variant)이고, 4) 비휘발성(Non-Volatile)이게 모아 놓은 것(collection)"을 의미한다. 이 정의에서 사용된 4개의 의미는 다음과 같다.
(가) 주제 지향(Subject-Oriented)
데이터웨어하우스는 조직이 통상적으로 운용하는 트랜잭션 프로세싱을 위한 일반적이고 다양한 종류의 데이터의 저장소가 아니며, 의사 결정에 필요한 특정 주제(subject)의 데이터만을 가지고 그 외의 데이터는 포함하지 않는다.
(나) 통합(Integrated)
데이터웨어하우스에 저장, 관리되는 데이터는 일반적으로 다수의 서로 다른 형태의 데이터베이스로부터 통합(integrated)된 것이다.
(다) 시계열 (Time-Variant)
데이터를 이용해 의사 결정을 하는데 가장 유용한 측면중의 하나는 데이터가 시간에 따라 어떻게 변하였는지를 살피는 것이다. 따라서 대부분의 데이터웨어하우스에는 시간에 따라 변화된 데이터 정보를 저장한다.
(라) 비휘발성(Non-Volatile)
데이터웨어하우스는 오퍼레이셔날 데이터베이스와는 물리적으로 별도로 데이터를 저장한다. 오퍼레이셔날 데이터베이스에서 필요한 트랜잭션 관리, 복구 기법, 동시성 제어 기법 등은 중요시되지 않는 경우가 대다수이다. 그 대신 정기적으로 데이터를 오퍼레이셔날 데이터베이스로부터 로딩하고 로딩된 데이터를 액세스하는 기법이 중요시된다.
(2) 오퍼레이셔날 데이터베이스와의 차이점
데이터웨어하우징 시스템을 현재 상업적으로 사용되는 데이터베이스 시스템과 비교하면 데이터웨어하우징 시스템의 이해가 더 쉽다. 오퍼레이셔날 데이터베이스 시스템이 주로 조직이 필요로 하는 일상 업무(day-to-day operations)를 위한 OLTP(On-Line Transaction Processing)을 위한 시스템이라면, 데이터웨어하우징 시스템은 데이터 분석이나 의사 결정 등을 지원하는 OLAP(On-Line Analytical Processing)을 위한 시스템이다.
OLTP시스템과 OLAP시스템의 주요 차이는 다음과 같은 측면으로 요약 될 수 있다.
나. 다차원 데이터 모델
(1) 데이터 큐브
데이터웨어하우스와 OLAP 도구들은 다차원(multi-dimensional) 데이터 모델을 기반으로 하는데, 조직이 원하는 여러 차원(측면, dimension)에서 데이터 모델링이 데이터 큐브(Data Cube)를 통해 이루어진다. 데이터 큐브와 다차원 데이터 모델링을 설명하기 위해 먼저 차원(Dimension)과 사실(Fact)이란 두 용어를 설명하자.
차원(Dimension)이란 조직이 데이터 레코드를 운용하는 이유의 대상이 되는 측면을 의미하고, 사실(Fact)이란 숫자적으로 표현되는 값을 의미한다. 예를 들어 가나다 백화점이 백화점 관리에 따른 의사 결정을 위한 ‘가나다 판매분석 데이터웨어하우스’를 만드는데, 관심 있는 측면이 연도, 품목, 지점에 따른 총 판매 금액이라 하자. 이 경우 차원(Dimension)은 연도, 품목, 지점 세 가지이고, 총 판매 금액은 사실(Fact)이 된다. 따라서 ‘가나다 판매분석 데이터웨어하우스’는 3차원 데이터 모델이 필요한데, 어떻게 데이터 큐브를 통해 이루어지는지 [그림 4-10-16]을 참고로 설명하기로 한다.
[그림 4-10-16] 상단 왼쪽 테이블은 연도라는 하나의 차원에 대한 총 판매 금액을 표시하며 이에 해당하는 1차원 데이터 큐브이다. 상단 오른쪽에는 연도와 품목이라는 두 개의 차원에 대한 총 판매 금액을 테이블 형태와 이에 해당하는 2차원 데이터 큐브가 있다. 여기에 지점별로 다시 총 판매 금액을 보여주기 위해 연도, 품목, 지점의 세 차원에 대한 테이블과 이에 상응하는 3차원 데이터 큐브가 그림 하단에 나타난다. 큐브란 용어 자체는 기하학적으로 3차원을 의미해 용어상 혼동을 줄 수 있겠지만 데이터 큐브에서는 원하는 차원의 일반적인 n차원을 의미한다.
다차원 데이터 모델을 위한 데이터 큐브에서 각각의 데이터 큐브를 큐보이드(cuboid)라고도 부르며, 이러한 큐보이드 간에는 [그림 4-10-17]과 같이 래티스(lattice) 관계가 형성되게 된다.
‘가나다 판매 분석 데이터웨어하우스’를 이용하여 예를 들어 경영자가 지점별 예산 편성이나 특화 분야 선정을 하는 의사 결정을 내리기 위해 질의 패턴중 대표적인 것으로는 드릴다운과 롤업이 있다. 연도별 총 판매 금액, 다시 연도와 품목별 총 판매 금액, 그리고 연도, 품목, 지점별 총 판매 금액 정보를 계산해 내는 방식으로 점점 더 기존 차원에 또 다른 차원을 첨가해 세분화된 질의를 하는 질의 패턴을 드릴다운(Drill- Down)이라 한다. 이와 반대로 차원 수를 줄여가며 점점 요약된 형태의 정보를 얻어 나가는 질의 패턴은 롤업(Roll-Up)이라 한다. 이 밖에 슬라이싱(Slicing), 다이싱(Dicing), 피봇(Pivot) 등도 흔히 나타나는 질의 패턴이다.
(2) 스타 스키마/스노우플레이크 스키마
앞서 살펴보았듯이 데이터웨어하우스에는 다차원 모델이 적합한데 이를 논리적 (Conceptual)으로 설계할 때 제일 자주 사용되는 스키마는 스타 스키마(Star Schema)와 스노우플레이크 스키마(Snowflake Schema)이다.
스타 스키마는 필요한 사실과 기타 속성들로 이루어진 사실 테이블과, 관심있는 차원과 그에 따른 부가적인 정보들을 각각 하나의 차원 테이블로 설계해, 사실 테이블과 차원 테이블을 외부키(Foreign Key)로 연결할 수 있도록 한다. 그림 상으로 보면 마치 별 모양이 되도록 구성한 스키마이다. 스타 스키마의 변형인 스노우플레이크 스키마(Snowflake Schema)는 차원 테이블을 다시 정규화(Normalize)함으로서 이들 테이블들이 마치 눈꽃(Snowflake) 모양이 되도록 만든 스키마이다.
다. 데이터웨어하우스 아키텍처와 데이터웨어하우징 시스템
(1) 아키텍처와 OLAP 구현 분류
데이터웨어하우징 시스템은 통상적으로 데이터 소스로부터 데이터를 클리닝하고 로딩하며 메타 정보 등을 관리하는 데이터웨어하우스 서버를 하위 티어에 두고, 중간 티어에 OLAP 프로세스 서버를 두며, 상위 티어에 데이터마이닝 등의 의사 결정 응용 프로그램 도구를 두는 3-티어 아키텍처를 가진다.
OLAP 서버는 크게 ROLAP과 MOLAP 그리고 HOLAP의 세 종류로 구분해 볼 수 있다. ROLAP(Relational OLAP) 서버란 관계형 데이터베이스나 확장된 관계형 데이터베이스를 사용해 다차원 모델링되는 데이터 큐브를 테이블 형태로 저장 운용하는 방식을 말한다. MOLAP (Multidimensional OLAP) 서버란 데이터 큐브를 실제로 어레이를 기반한 다차원 저장 엔진을 사용하여 저장 운용하는 방식이다. HOLAP (Hybrid OLAP) 서버는 말 그대로 ROLAP과 MOLAP을 혼용하는 방식을 의미한다.
(2) 데이터웨어하우징 시스템
현재 상업적으로 개발된 데이터웨어하우징 시스템은 많으나 그 중 몇 가지를 들면 다음과 같다. IBM사에서는 Informix eXtended Parallel Server(XPS), Readbrick Warehouse, DB2 OLAP Server 등이 있으며, Oracle사에서는 Oracle Data Warehousing이, Microsoft사에서는 MS SQL Server OLAP Services,NCR사에서는 TeraData Warehousing, Sybase사에서는 Sybase Anywhere Studio, Microstrategy사의 Microstrategy OLAP Services, Hyperion 사의 Essbase OLAP Server등을 들 수 있겠다.
2. 데이터마닝
가. 데이터마이닝 개요
데이터웨어하우스와 비슷한 시기에 데이터베이스 분야를 중심으로 연구가 활발하게 시작된 분야가 데이터마이닝(Data Mining)이다. 90년대 중반이후에 데이터베이스나 데이터웨어하우스의 크기는 웹 로봇과 같이 데이터를 수동이 아닌 자동으로 수집하는 도구의 대중화와 오랜 기간의 시계열적 데이터 량의 증가 등으로 그 크기가 급속도로 커졌고, 이를 시스템이 기술적으로 감당할 수 있게 됨으로서 데이터마이닝이란 새로운 응용 분야가 탄생할 수 있었다.
데이터마이닝은 ‘대용량의 데이터에서 필요한 지식(Knowledge)을 얻고자 하는 과정’이라 간단히 정의할 수 있는데, 데이터베이스에서 분야에서는 지식 발견(KDD : Knowledge Discovery in Databases)이라고도 불리며, 그 응용 분야에 따라 비즈니스 인텔리전스, 지식 추출, 정보 분석 등의 용어로도 불린다. 여기서 발견하고자하는 지식은 뻔한 사실이 아니고(Non-Trivial), 데이터에 직접적으로 나타나지 않고 내포되었으며(Implicit), 기존에 발견되지 않은, 잠재적으로 유용한 지식을 의미한다.
데이터마이닝은 잠재적으로 폭 넓은 응용 분야를 가지고 있는데 고객 구매 성향 분석, 타겟 마케팅, 크로스-마켓팅 등의 마켓팅 분석 및 관리 분야, 위험 분석 및 관리 분야, 사기 상행위 발견 및 예측 분야, 텍스트 나 웹 등에서의 정보 발견, DNA 데이터 분석 및 의료정보학, 기타 스포츠, 과학 등을 망라하는데 데이터마이닝 기술이 발전하면서 그 응용의 폭이 점점 더 커지고 있는 추세이다.
나. 지식발견과정 : 데이터마이닝
데이터마이닝은 일반적으로 다음 [그림 4-10- 20]과 같은 과정을 밟는다.
데이터 클리닝(cleaning)과 통합 : 데이터 소스는 서로 다른 관계형 데이터베이스로에서부터 파일 혹은 이메일 자료 등 다양할 수 있으며 그 데이터 형식도 다양할 수 있다. 이 과정에서는 에러를 보정하고 포맷을 통일시키고 데이터의 일관성을 유지하며 스키마를 통합하는 등의 작업을 수행한다.
데이터 선별과 변환 : 데이터웨어하우스와 같은 통합된 데이터 저장소로부터 분석작업에 필요한 데이터를 선별하고 데이터마이닝을 수행할 수 있는 형태로 데이터를 변환한다.
데이터마이닝 : 데이터로부터 다양한 형태의 마이닝 기법을 적용시켜 패턴을 추출해 낸다.
패턴 평가와 표현 : 추출된 패턴이 얻고자하는 지식에 필요한 것인지를 척도에 맞추어 평가해보고 궁극적으로 사람이 이해할 수 있는 방법으로 지식을 표현한다.
다. 데이터마이닝 시스템 아키텍처와 필요 기능
[그림 4-10-20]에서 제시된 데이터마이닝 과정을 처리하기 위한 데이터마이닝 시스템의 아키텍처는 [그림 4-10-21]과 같이 데이터베이스/데이터웨어하우스 서버, 데이터마이닝 엔진, 패턴 분석기, 사용자 인터페이스 등으로 구성될 수 있다.
데이터마이닝 시스템에서 필요한 기능적 요소를 요약해 보면 다음과 같다.
(1) 개념 설명 : 특징화(Characterization)와 비교(Discrimination)
예를 들어 백화점 판매 분석 데이터웨어하우스에서 고객들의 분류에 따른 물품별 판매 패턴을 분석하여 그로부터 백화점 경영에 대한 지식을 얻는데 데이터마이닝 기법을 도입한다 하자. 그러면 SRAM, DRAM 등은 메모리로 분류되고, 다시 이는 하드디스크, PC, 모니터 등을 포함하는 컴퓨터라는 물품으로 분류되는 등의 물품 분류가 필요하다. 또 고객별 성향을 20대 30대 등의 나이별 분류에서 씀씀이가 큰 고객, 신세대 고객 등의 분류도 필요할 수 있다. 이와 같이 데이터를 클래스화하고 개념화하기 위해서는 비슷한 부류의 데이터가 가지고 있는 성질 등을 일반적인 용어를 사용하여 요약(Summarize)하는 특징화(Characterization)와, 비교되는 부류의 데이터와 대조를 하여 클래스화하는 비교(Discrimination) 기법 등이 필요하다.
개념의 효율적인 요약, 특징화 등을 위하여, 데이터 큐브 기반 일반화 기법, 속성중심 추론(Attributed-Oriented Induction) 기법, 표준 편차(Standard Deviation)나 중앙집중 경향(CentralTendency)등의 통계적 요약기법, 일반화 기반 추론(Generalization-Based Induction) 기법, 속성 연관성(Attribute Relevance) 파악 기법 등이 사용된다.
(2) 연관성 법칙(Association Rule)
연관성 법칙(Association Rule)이란 어떤 속성들이 가지는 값이 자주 나타나는 조건을 보여주는 것인데,형식적으로는 A1∧A2∧...∧An⇒B1∧B2∧...∧Bm 같이 논리적 폼으로 쓰여질 수 있다. 여기서 프레디킷(Predicate) Ai와 Bj에는 각각 속성과 그 값이 나타내며 ∧는 논리곱을 의미한다. 예를 들어 나이(X,“35..45”)∧성별(X,“남자”)∧자녀여부(X,“예”)⇒구매(X,“컴퓨터”) [지지도=40%, 신뢰도=75%]라는 연관성 법칙은 “나이가 35에서 45세 사이에 있고 자녀가 있는 남자는 컴퓨터를 구매한다”를 의미한다. 연관성 법칙은 지지도(support)와 신뢰도(confidence)가 같이 수반될 때 연관성 법칙으로서의 의미가 제대로 파악될 수 있다.
지지도는 연관성 법칙에 나타나는 각 프레디킷을 모두 만족시키는 데이터가 전체 데이터에서 나타나는 확률을 의미하고, 신뢰도란 주어진 조건 안에서 법칙이 성립하는 확률을 의미한다: 지지도(A⇒B) = P(A∪B), 신뢰도(A⇒B) = P(A|B). (P는 확률을 의미함)
예를 들어 위에서 지지도와 신뢰도의 확률 계산이 트랜잭션 숫자에 기준한 통계로 이루어 졌다면, 지지도=40%가 의미하는 바는 전체 백화점 판매 데이터베이스에서 나타나는 트랜잭션 숫자 중에서 나이가 35에서 45세 사이에 있고 자녀가 있는 남자가 컴퓨터를 구매한 트랜잭션의 숫자의 비율이 0.4임을 의미한다. 또 신뢰도=75%가 의미하는 바는 나이가 35에서 45세 사이에 있고 자녀가 있는 남자가 구매한 트랜잭션 가운데 컴퓨터를 구매한 트랜잭션의 비율이 0.75라는 의미이다.
일반적으로 높은 지지도와 높은 신뢰도를 가진 연관성 법칙일수록 좋은 법칙이라 할 수 있겠는데, 최소지지도와 최소 신뢰도를 시스템이 정하고 이를 넘는 지지도와 신뢰도를 가진 연관성 법칙을 스트롱(Strong) 연관성 법칙이라 부른다. 대용량 데이터베이스에 존재하는 연관성(특히 스트롱 연관성)을 어떻게 효율적으로 찾을 수 있는지, 얼마만큼 많은 연관성 법칙들을 찾을 수 있는지, 혹은 필요한 연관성 법칙이 무엇인지를 알아내는 등이 주요 이슈가 된다.
(3) 클래스화(Classification) 혹은 클러스터링(Clustering)
클래스화란 서로 비슷한 특징을 보이는 데이터 혹은 객체들로 분류하는 모델을 찾는 과정인데, 흔히 훈련 데이터(Training Data)로부터 적당한 클래스화를 얻어본 후 실제 데이터에 구해진 클래스에 따른 클래스화 및 클래스에 속한 객체에 대한 특징 예측(Predict)을 해나간다. 클러스터링도 객체를 분류한다는 측면에서는 비슷하지만, 훈련 데이터를 통하거나 사전에 미리 클래스화해서 실제 데이터를 그 클래스화에 적용하는 방식이 아니고, 비슷한 특징을 가진 객체끼리 클러스터간 유사성은 커지면서 동일 클러스터내의 객체간 유사성은 높이도록 분류해 나간다는 것이 그 차이점이다. 흔히 기계학습(Machine Learning)분야에서는 이러한 클래스화와 클러스터링의 차이를 감독학습(Supervised Learning)과 비감독학습(Unsupervised Learning)으로 말하기도 한다.
클래스화 기법은 크게, 의사 결정 트리 추론(Decision Tree Induction)기법,인스턴스 기반(Instance Based) 기법, 베이지안 네트워크(BayesianNetwork)기법, 신경망(Neural-Net) 기반 기법, k-근접 이웃(k-Nearest Neighbor) 기법, 유전자(Genetic) 기법 등으로 분류될 수 있다. 이에 비해 클러스터링 기법은 파티셔닝(Partitioning) 기법, 계층화(Hierarchical) 기법, 밀집-기반(Density-Based) 기법, 그리드-기반(Grid-Based) 기법, 모델-기반 기법 등이 있다.
(4) 비쥬얼화(Visualization)
분석된 패턴이 이해할 수 있는 지식이 되기 위해서는 비쥬얼화가 중요하다. 비쥬얼화에는 데이터를 3차원 큐브, 분포 차트 등의 다양한 형태로 보여주는 데이터 비쥬얼화 뿐만 아니라, 데이터마이닝으로 얻어진 연관성 법칙이나 클러스터 등을 플로팅하는 등의 데이터마이닝 결과 비쥬얼화, 데이터마이닝 과정 자체에 대한 비쥬얼화 등이 포함된다.
라. 데이터마이닝 시스템
현재 상업적으로 개발된 데이터마이닝 시스템 중 몇 가지로서는, IBM사의 Intelligent Miner, SAS Institute 사의 Enterprise Miner,Silicon Graphic 사에서 개발한 MineSet, Oracle사의 Data Mining Suite 등을 들 수 있겠다.
마. 향후 전망
현재까지 데이터마이닝 연구 및 개발은 주로 수평적 시스템을 구성하기 위한 기본 연구에 치중하였으며, 그 응용 영역도 확대해 왔다. 앞으로의 연구는 특정 응용 분야에 한정한 수직적(Vertical) 데이터마이닝으로 그 활용 영역을 넓혀갈 것으로 보인다. 예를 들어 웹마이닝(Web Mining), 바이오정보학 마이닝(Bioinformatics Mining)은 좋은 예라 할 수 있다. 또 수직적 데이터마이닝 못지 않게 더 인텔리전트하고, 효율적이고, 또 대용량 데이터베이스에서도 적용 가능한(Scalable) 데이터마이닝 시스템을 만드려는 연구 개발도 당분간 지속되리라 본다. 관련분야의 세계적인 학술대회인 ACM SIGKDD International Conference on Knowledge Discovery and Data Mining이나, 데이터베이스전반을 다루는 ACM SIGMOD International Conference on Management of Data, 그리고 International Conference on Very Large Data Bases 등에서의 데이터웨어하우스나 데이터마이닝의 2001, 2002년도 최근 연구는 이를 반영한다 할 수 있다.
데이터웨어하우스와 데이터마이닝은 그 수요에 있어서는 별개의 제품으로서가 아닌, 데이터마트와 같은 전자상거래 시스템(e-Commerce), 고객관리시스템(CRM, Customer Relationship Management), 공급사슬관리(SCM, Supply Chain Management), 기업애플리케이션통합(EAI, Enterprise Application Integration), 비즈니스 인텔리전스(Business Intelligence)등의 비즈니스 시스템 통합형태로 시장을 형성해 왔으며, 앞으로도 그러한 수요가 지속되리라 예견된다.
[출처] 데이터웨어하우스 및 데이터마이닝 개요 |작성자 문식
[참조사이트] http://blog.naver.com/mylog?Redirect=Log&logNo=140004891281
* 세부사항 첨부참조
1. 데이터웨어하우스
가. 데이터웨어하우스 개요
(1) 데이터웨어하우스의 정의와 특징
데이터웨어하우스(Data Warehouse)는 1990년대 중반 이후 데이터베이스 분야에서 특히 학문계에서보다 산업계에서 그 태동이 시작되었다. 많고 다양한 형태의 오퍼레이셔날 데이터베이스(Operational Database)가 운용되고 시간이 지날수록 그 데이터베이스의 크기가 커지게 되었다. 따라서 데이터베이스 위에서 의사 결정(decision making) 등을 위해 사용되는 다양한 종류의 응용프로그램들은 그 질의(query) 수행이 원만하게 이루어지기 위하여 오퍼레이셔날 데이터베이스 위에 새로운 형태의 통합된 데이터 저장소(repository)가 필요했는데, 이것이 데이터웨어하우스가 등장한 배경이라 할 수 있다.
데이터웨어하우스의 정의에는 여러 가지가 있지만 데이터웨어하우스 시스템 아키텍처를 초창기에 이끈 W.H. Inmon에 따르면, "데이터웨어하우스란 의사 결정 프로세스를 지원하도록 데이터를 1) 주제 지향적(Subject-Oriented)이고, 2) 통합(Integrated) 되고, 3) 시계열적(Time- Variant)이고, 4) 비휘발성(Non-Volatile)이게 모아 놓은 것(collection)"을 의미한다. 이 정의에서 사용된 4개의 의미는 다음과 같다.
(가) 주제 지향(Subject-Oriented)
데이터웨어하우스는 조직이 통상적으로 운용하는 트랜잭션 프로세싱을 위한 일반적이고 다양한 종류의 데이터의 저장소가 아니며, 의사 결정에 필요한 특정 주제(subject)의 데이터만을 가지고 그 외의 데이터는 포함하지 않는다.
(나) 통합(Integrated)
데이터웨어하우스에 저장, 관리되는 데이터는 일반적으로 다수의 서로 다른 형태의 데이터베이스로부터 통합(integrated)된 것이다.
(다) 시계열 (Time-Variant)
데이터를 이용해 의사 결정을 하는데 가장 유용한 측면중의 하나는 데이터가 시간에 따라 어떻게 변하였는지를 살피는 것이다. 따라서 대부분의 데이터웨어하우스에는 시간에 따라 변화된 데이터 정보를 저장한다.
(라) 비휘발성(Non-Volatile)
데이터웨어하우스는 오퍼레이셔날 데이터베이스와는 물리적으로 별도로 데이터를 저장한다. 오퍼레이셔날 데이터베이스에서 필요한 트랜잭션 관리, 복구 기법, 동시성 제어 기법 등은 중요시되지 않는 경우가 대다수이다. 그 대신 정기적으로 데이터를 오퍼레이셔날 데이터베이스로부터 로딩하고 로딩된 데이터를 액세스하는 기법이 중요시된다.
(2) 오퍼레이셔날 데이터베이스와의 차이점
데이터웨어하우징 시스템을 현재 상업적으로 사용되는 데이터베이스 시스템과 비교하면 데이터웨어하우징 시스템의 이해가 더 쉽다. 오퍼레이셔날 데이터베이스 시스템이 주로 조직이 필요로 하는 일상 업무(day-to-day operations)를 위한 OLTP(On-Line Transaction Processing)을 위한 시스템이라면, 데이터웨어하우징 시스템은 데이터 분석이나 의사 결정 등을 지원하는 OLAP(On-Line Analytical Processing)을 위한 시스템이다.
OLTP시스템과 OLAP시스템의 주요 차이는 다음과 같은 측면으로 요약 될 수 있다.
나. 다차원 데이터 모델
(1) 데이터 큐브
데이터웨어하우스와 OLAP 도구들은 다차원(multi-dimensional) 데이터 모델을 기반으로 하는데, 조직이 원하는 여러 차원(측면, dimension)에서 데이터 모델링이 데이터 큐브(Data Cube)를 통해 이루어진다. 데이터 큐브와 다차원 데이터 모델링을 설명하기 위해 먼저 차원(Dimension)과 사실(Fact)이란 두 용어를 설명하자.
차원(Dimension)이란 조직이 데이터 레코드를 운용하는 이유의 대상이 되는 측면을 의미하고, 사실(Fact)이란 숫자적으로 표현되는 값을 의미한다. 예를 들어 가나다 백화점이 백화점 관리에 따른 의사 결정을 위한 ‘가나다 판매분석 데이터웨어하우스’를 만드는데, 관심 있는 측면이 연도, 품목, 지점에 따른 총 판매 금액이라 하자. 이 경우 차원(Dimension)은 연도, 품목, 지점 세 가지이고, 총 판매 금액은 사실(Fact)이 된다. 따라서 ‘가나다 판매분석 데이터웨어하우스’는 3차원 데이터 모델이 필요한데, 어떻게 데이터 큐브를 통해 이루어지는지 [그림 4-10-16]을 참고로 설명하기로 한다.
[그림 4-10-16] 상단 왼쪽 테이블은 연도라는 하나의 차원에 대한 총 판매 금액을 표시하며 이에 해당하는 1차원 데이터 큐브이다. 상단 오른쪽에는 연도와 품목이라는 두 개의 차원에 대한 총 판매 금액을 테이블 형태와 이에 해당하는 2차원 데이터 큐브가 있다. 여기에 지점별로 다시 총 판매 금액을 보여주기 위해 연도, 품목, 지점의 세 차원에 대한 테이블과 이에 상응하는 3차원 데이터 큐브가 그림 하단에 나타난다. 큐브란 용어 자체는 기하학적으로 3차원을 의미해 용어상 혼동을 줄 수 있겠지만 데이터 큐브에서는 원하는 차원의 일반적인 n차원을 의미한다.
다차원 데이터 모델을 위한 데이터 큐브에서 각각의 데이터 큐브를 큐보이드(cuboid)라고도 부르며, 이러한 큐보이드 간에는 [그림 4-10-17]과 같이 래티스(lattice) 관계가 형성되게 된다.
‘가나다 판매 분석 데이터웨어하우스’를 이용하여 예를 들어 경영자가 지점별 예산 편성이나 특화 분야 선정을 하는 의사 결정을 내리기 위해 질의 패턴중 대표적인 것으로는 드릴다운과 롤업이 있다. 연도별 총 판매 금액, 다시 연도와 품목별 총 판매 금액, 그리고 연도, 품목, 지점별 총 판매 금액 정보를 계산해 내는 방식으로 점점 더 기존 차원에 또 다른 차원을 첨가해 세분화된 질의를 하는 질의 패턴을 드릴다운(Drill- Down)이라 한다. 이와 반대로 차원 수를 줄여가며 점점 요약된 형태의 정보를 얻어 나가는 질의 패턴은 롤업(Roll-Up)이라 한다. 이 밖에 슬라이싱(Slicing), 다이싱(Dicing), 피봇(Pivot) 등도 흔히 나타나는 질의 패턴이다.
(2) 스타 스키마/스노우플레이크 스키마
앞서 살펴보았듯이 데이터웨어하우스에는 다차원 모델이 적합한데 이를 논리적 (Conceptual)으로 설계할 때 제일 자주 사용되는 스키마는 스타 스키마(Star Schema)와 스노우플레이크 스키마(Snowflake Schema)이다.
스타 스키마는 필요한 사실과 기타 속성들로 이루어진 사실 테이블과, 관심있는 차원과 그에 따른 부가적인 정보들을 각각 하나의 차원 테이블로 설계해, 사실 테이블과 차원 테이블을 외부키(Foreign Key)로 연결할 수 있도록 한다. 그림 상으로 보면 마치 별 모양이 되도록 구성한 스키마이다. 스타 스키마의 변형인 스노우플레이크 스키마(Snowflake Schema)는 차원 테이블을 다시 정규화(Normalize)함으로서 이들 테이블들이 마치 눈꽃(Snowflake) 모양이 되도록 만든 스키마이다.
다. 데이터웨어하우스 아키텍처와 데이터웨어하우징 시스템
(1) 아키텍처와 OLAP 구현 분류
데이터웨어하우징 시스템은 통상적으로 데이터 소스로부터 데이터를 클리닝하고 로딩하며 메타 정보 등을 관리하는 데이터웨어하우스 서버를 하위 티어에 두고, 중간 티어에 OLAP 프로세스 서버를 두며, 상위 티어에 데이터마이닝 등의 의사 결정 응용 프로그램 도구를 두는 3-티어 아키텍처를 가진다.
OLAP 서버는 크게 ROLAP과 MOLAP 그리고 HOLAP의 세 종류로 구분해 볼 수 있다. ROLAP(Relational OLAP) 서버란 관계형 데이터베이스나 확장된 관계형 데이터베이스를 사용해 다차원 모델링되는 데이터 큐브를 테이블 형태로 저장 운용하는 방식을 말한다. MOLAP (Multidimensional OLAP) 서버란 데이터 큐브를 실제로 어레이를 기반한 다차원 저장 엔진을 사용하여 저장 운용하는 방식이다. HOLAP (Hybrid OLAP) 서버는 말 그대로 ROLAP과 MOLAP을 혼용하는 방식을 의미한다.
(2) 데이터웨어하우징 시스템
현재 상업적으로 개발된 데이터웨어하우징 시스템은 많으나 그 중 몇 가지를 들면 다음과 같다. IBM사에서는 Informix eXtended Parallel Server(XPS), Readbrick Warehouse, DB2 OLAP Server 등이 있으며, Oracle사에서는 Oracle Data Warehousing이, Microsoft사에서는 MS SQL Server OLAP Services,NCR사에서는 TeraData Warehousing, Sybase사에서는 Sybase Anywhere Studio, Microstrategy사의 Microstrategy OLAP Services, Hyperion 사의 Essbase OLAP Server등을 들 수 있겠다.
2. 데이터마닝
가. 데이터마이닝 개요
데이터웨어하우스와 비슷한 시기에 데이터베이스 분야를 중심으로 연구가 활발하게 시작된 분야가 데이터마이닝(Data Mining)이다. 90년대 중반이후에 데이터베이스나 데이터웨어하우스의 크기는 웹 로봇과 같이 데이터를 수동이 아닌 자동으로 수집하는 도구의 대중화와 오랜 기간의 시계열적 데이터 량의 증가 등으로 그 크기가 급속도로 커졌고, 이를 시스템이 기술적으로 감당할 수 있게 됨으로서 데이터마이닝이란 새로운 응용 분야가 탄생할 수 있었다.
데이터마이닝은 ‘대용량의 데이터에서 필요한 지식(Knowledge)을 얻고자 하는 과정’이라 간단히 정의할 수 있는데, 데이터베이스에서 분야에서는 지식 발견(KDD : Knowledge Discovery in Databases)이라고도 불리며, 그 응용 분야에 따라 비즈니스 인텔리전스, 지식 추출, 정보 분석 등의 용어로도 불린다. 여기서 발견하고자하는 지식은 뻔한 사실이 아니고(Non-Trivial), 데이터에 직접적으로 나타나지 않고 내포되었으며(Implicit), 기존에 발견되지 않은, 잠재적으로 유용한 지식을 의미한다.
데이터마이닝은 잠재적으로 폭 넓은 응용 분야를 가지고 있는데 고객 구매 성향 분석, 타겟 마케팅, 크로스-마켓팅 등의 마켓팅 분석 및 관리 분야, 위험 분석 및 관리 분야, 사기 상행위 발견 및 예측 분야, 텍스트 나 웹 등에서의 정보 발견, DNA 데이터 분석 및 의료정보학, 기타 스포츠, 과학 등을 망라하는데 데이터마이닝 기술이 발전하면서 그 응용의 폭이 점점 더 커지고 있는 추세이다.
나. 지식발견과정 : 데이터마이닝
데이터마이닝은 일반적으로 다음 [그림 4-10- 20]과 같은 과정을 밟는다.
데이터 클리닝(cleaning)과 통합 : 데이터 소스는 서로 다른 관계형 데이터베이스로에서부터 파일 혹은 이메일 자료 등 다양할 수 있으며 그 데이터 형식도 다양할 수 있다. 이 과정에서는 에러를 보정하고 포맷을 통일시키고 데이터의 일관성을 유지하며 스키마를 통합하는 등의 작업을 수행한다.
데이터 선별과 변환 : 데이터웨어하우스와 같은 통합된 데이터 저장소로부터 분석작업에 필요한 데이터를 선별하고 데이터마이닝을 수행할 수 있는 형태로 데이터를 변환한다.
데이터마이닝 : 데이터로부터 다양한 형태의 마이닝 기법을 적용시켜 패턴을 추출해 낸다.
패턴 평가와 표현 : 추출된 패턴이 얻고자하는 지식에 필요한 것인지를 척도에 맞추어 평가해보고 궁극적으로 사람이 이해할 수 있는 방법으로 지식을 표현한다.
다. 데이터마이닝 시스템 아키텍처와 필요 기능
[그림 4-10-20]에서 제시된 데이터마이닝 과정을 처리하기 위한 데이터마이닝 시스템의 아키텍처는 [그림 4-10-21]과 같이 데이터베이스/데이터웨어하우스 서버, 데이터마이닝 엔진, 패턴 분석기, 사용자 인터페이스 등으로 구성될 수 있다.
데이터마이닝 시스템에서 필요한 기능적 요소를 요약해 보면 다음과 같다.
(1) 개념 설명 : 특징화(Characterization)와 비교(Discrimination)
예를 들어 백화점 판매 분석 데이터웨어하우스에서 고객들의 분류에 따른 물품별 판매 패턴을 분석하여 그로부터 백화점 경영에 대한 지식을 얻는데 데이터마이닝 기법을 도입한다 하자. 그러면 SRAM, DRAM 등은 메모리로 분류되고, 다시 이는 하드디스크, PC, 모니터 등을 포함하는 컴퓨터라는 물품으로 분류되는 등의 물품 분류가 필요하다. 또 고객별 성향을 20대 30대 등의 나이별 분류에서 씀씀이가 큰 고객, 신세대 고객 등의 분류도 필요할 수 있다. 이와 같이 데이터를 클래스화하고 개념화하기 위해서는 비슷한 부류의 데이터가 가지고 있는 성질 등을 일반적인 용어를 사용하여 요약(Summarize)하는 특징화(Characterization)와, 비교되는 부류의 데이터와 대조를 하여 클래스화하는 비교(Discrimination) 기법 등이 필요하다.
개념의 효율적인 요약, 특징화 등을 위하여, 데이터 큐브 기반 일반화 기법, 속성중심 추론(Attributed-Oriented Induction) 기법, 표준 편차(Standard Deviation)나 중앙집중 경향(CentralTendency)등의 통계적 요약기법, 일반화 기반 추론(Generalization-Based Induction) 기법, 속성 연관성(Attribute Relevance) 파악 기법 등이 사용된다.
(2) 연관성 법칙(Association Rule)
연관성 법칙(Association Rule)이란 어떤 속성들이 가지는 값이 자주 나타나는 조건을 보여주는 것인데,형식적으로는 A1∧A2∧...∧An⇒B1∧B2∧...∧Bm 같이 논리적 폼으로 쓰여질 수 있다. 여기서 프레디킷(Predicate) Ai와 Bj에는 각각 속성과 그 값이 나타내며 ∧는 논리곱을 의미한다. 예를 들어 나이(X,“35..45”)∧성별(X,“남자”)∧자녀여부(X,“예”)⇒구매(X,“컴퓨터”) [지지도=40%, 신뢰도=75%]라는 연관성 법칙은 “나이가 35에서 45세 사이에 있고 자녀가 있는 남자는 컴퓨터를 구매한다”를 의미한다. 연관성 법칙은 지지도(support)와 신뢰도(confidence)가 같이 수반될 때 연관성 법칙으로서의 의미가 제대로 파악될 수 있다.
지지도는 연관성 법칙에 나타나는 각 프레디킷을 모두 만족시키는 데이터가 전체 데이터에서 나타나는 확률을 의미하고, 신뢰도란 주어진 조건 안에서 법칙이 성립하는 확률을 의미한다: 지지도(A⇒B) = P(A∪B), 신뢰도(A⇒B) = P(A|B). (P는 확률을 의미함)
예를 들어 위에서 지지도와 신뢰도의 확률 계산이 트랜잭션 숫자에 기준한 통계로 이루어 졌다면, 지지도=40%가 의미하는 바는 전체 백화점 판매 데이터베이스에서 나타나는 트랜잭션 숫자 중에서 나이가 35에서 45세 사이에 있고 자녀가 있는 남자가 컴퓨터를 구매한 트랜잭션의 숫자의 비율이 0.4임을 의미한다. 또 신뢰도=75%가 의미하는 바는 나이가 35에서 45세 사이에 있고 자녀가 있는 남자가 구매한 트랜잭션 가운데 컴퓨터를 구매한 트랜잭션의 비율이 0.75라는 의미이다.
일반적으로 높은 지지도와 높은 신뢰도를 가진 연관성 법칙일수록 좋은 법칙이라 할 수 있겠는데, 최소지지도와 최소 신뢰도를 시스템이 정하고 이를 넘는 지지도와 신뢰도를 가진 연관성 법칙을 스트롱(Strong) 연관성 법칙이라 부른다. 대용량 데이터베이스에 존재하는 연관성(특히 스트롱 연관성)을 어떻게 효율적으로 찾을 수 있는지, 얼마만큼 많은 연관성 법칙들을 찾을 수 있는지, 혹은 필요한 연관성 법칙이 무엇인지를 알아내는 등이 주요 이슈가 된다.
(3) 클래스화(Classification) 혹은 클러스터링(Clustering)
클래스화란 서로 비슷한 특징을 보이는 데이터 혹은 객체들로 분류하는 모델을 찾는 과정인데, 흔히 훈련 데이터(Training Data)로부터 적당한 클래스화를 얻어본 후 실제 데이터에 구해진 클래스에 따른 클래스화 및 클래스에 속한 객체에 대한 특징 예측(Predict)을 해나간다. 클러스터링도 객체를 분류한다는 측면에서는 비슷하지만, 훈련 데이터를 통하거나 사전에 미리 클래스화해서 실제 데이터를 그 클래스화에 적용하는 방식이 아니고, 비슷한 특징을 가진 객체끼리 클러스터간 유사성은 커지면서 동일 클러스터내의 객체간 유사성은 높이도록 분류해 나간다는 것이 그 차이점이다. 흔히 기계학습(Machine Learning)분야에서는 이러한 클래스화와 클러스터링의 차이를 감독학습(Supervised Learning)과 비감독학습(Unsupervised Learning)으로 말하기도 한다.
클래스화 기법은 크게, 의사 결정 트리 추론(Decision Tree Induction)기법,인스턴스 기반(Instance Based) 기법, 베이지안 네트워크(BayesianNetwork)기법, 신경망(Neural-Net) 기반 기법, k-근접 이웃(k-Nearest Neighbor) 기법, 유전자(Genetic) 기법 등으로 분류될 수 있다. 이에 비해 클러스터링 기법은 파티셔닝(Partitioning) 기법, 계층화(Hierarchical) 기법, 밀집-기반(Density-Based) 기법, 그리드-기반(Grid-Based) 기법, 모델-기반 기법 등이 있다.
(4) 비쥬얼화(Visualization)
분석된 패턴이 이해할 수 있는 지식이 되기 위해서는 비쥬얼화가 중요하다. 비쥬얼화에는 데이터를 3차원 큐브, 분포 차트 등의 다양한 형태로 보여주는 데이터 비쥬얼화 뿐만 아니라, 데이터마이닝으로 얻어진 연관성 법칙이나 클러스터 등을 플로팅하는 등의 데이터마이닝 결과 비쥬얼화, 데이터마이닝 과정 자체에 대한 비쥬얼화 등이 포함된다.
라. 데이터마이닝 시스템
현재 상업적으로 개발된 데이터마이닝 시스템 중 몇 가지로서는, IBM사의 Intelligent Miner, SAS Institute 사의 Enterprise Miner,Silicon Graphic 사에서 개발한 MineSet, Oracle사의 Data Mining Suite 등을 들 수 있겠다.
마. 향후 전망
현재까지 데이터마이닝 연구 및 개발은 주로 수평적 시스템을 구성하기 위한 기본 연구에 치중하였으며, 그 응용 영역도 확대해 왔다. 앞으로의 연구는 특정 응용 분야에 한정한 수직적(Vertical) 데이터마이닝으로 그 활용 영역을 넓혀갈 것으로 보인다. 예를 들어 웹마이닝(Web Mining), 바이오정보학 마이닝(Bioinformatics Mining)은 좋은 예라 할 수 있다. 또 수직적 데이터마이닝 못지 않게 더 인텔리전트하고, 효율적이고, 또 대용량 데이터베이스에서도 적용 가능한(Scalable) 데이터마이닝 시스템을 만드려는 연구 개발도 당분간 지속되리라 본다. 관련분야의 세계적인 학술대회인 ACM SIGKDD International Conference on Knowledge Discovery and Data Mining이나, 데이터베이스전반을 다루는 ACM SIGMOD International Conference on Management of Data, 그리고 International Conference on Very Large Data Bases 등에서의 데이터웨어하우스나 데이터마이닝의 2001, 2002년도 최근 연구는 이를 반영한다 할 수 있다.
데이터웨어하우스와 데이터마이닝은 그 수요에 있어서는 별개의 제품으로서가 아닌, 데이터마트와 같은 전자상거래 시스템(e-Commerce), 고객관리시스템(CRM, Customer Relationship Management), 공급사슬관리(SCM, Supply Chain Management), 기업애플리케이션통합(EAI, Enterprise Application Integration), 비즈니스 인텔리전스(Business Intelligence)등의 비즈니스 시스템 통합형태로 시장을 형성해 왔으며, 앞으로도 그러한 수요가 지속되리라 예견된다.
[출처] 데이터웨어하우스 및 데이터마이닝 개요 |작성자 문식
[참조사이트] http://blog.naver.com/mylog?Redirect=Log&logNo=140004891281
EDW의 이해 - EDW의 필요성과 현황
EDW(Enterprise Data Warehouse)는 기존 DW(Data Warehouse)를 전사적으로 확장한 모델인 동시에 BPR과 CRM, BSC 같은 다양한 분석 애플리케이션들을 위한 원천이 된다. 따라서 EDW를 구축하는 것은 단순히 정보를 빠르게 전달하는 대형 시스템을 도입한다는 의미가 아니라 기업 리소스의 유기적 통합, 다원화된 관리 체계 정비, 데이터의 중복 방지 등을 위해 시스템을 재설계 하는 것으로 이해해야 한다.
데이터 웨어하우징(Data Ware-housing)의 개념은 기간계의 주요 데이터를 주제별로 통합하여 현업 부서의 정보분석 요구를 신속히 충족시키는 시스템을 의미한다. 이를 위해 기업의 정보기반이 되는 인프라를 구축하고 이를 IT부서의 도움 없이 액세스하는 방법을 제공하게 된다. EDW는 이 개념을 기업의 전사적인 영역으로 확장시킨 개념이라고 볼 수 있다.
그렇다면 EDW의 범주를 어디까지 보아야 할까? 기업에서 최근 일반적으로 구성되는 표준 모델의 형태는 <그림>과 같다.
<그림>에서 보면 이전과 같이 전면에 포지셔닝 되는 그림이 아닌 BI(Business Intelligence) 애플리케이션을 위한 데이터 인프라로서의 역할이 강조되는 것을 확인할 수 있다. 이와 같이 EDW란 것은 이전의 DW를 전사적으로 확장하려고 하는 부분에서 생긴 다양한 시스템간의 인터페이스와 데이터 통합, 표준화 등을 중요시한 DW의 확장 모델인 동시에 기업 정보에 관한 프로세스의 표준화와 개선, 즉 BPR적 영역을 포함한다. 또한 CRM, BSC 같은 다양한 분석적 애플리케이션들을 위한 데이터의 원천이 된다.
EDW의 출현 배경
IT시장에 DW의 개념이 나오고 일반화된지 거의 10년이 되어가고 있지만 초기의 정의와 역할과는 다르게 최근 DW의 의미는 거의 분석계 플랫폼의 전체를 지칭하는 명사로 인식되고 있다. 단순히 데이터를 주제별로 통합해 OLAP 시스템을 통한 다차원의 분석을 가능케 하는 초기 정의와는 달리 2000년대 들어서는 정제되고 통합된 데이터를 거의 모든 BI 애플리케이션(ABM, BSC, CRM 등)에게 제공해 주는 데이터 인프라 측면이 강조되었다.
이에 따라 ABM, BSC, 혹은 CRM 프로젝트란 이름 하에 각 시스템의 분석 마트를 설계하는 프로젝트들이 진행되어 왔다. 또한 근래에 들어서는 RTE(Real Time Enterprise), EAI와의 연동을 통한 좀더 기술적, 비즈니스적으로 진보된 플랫폼으로 구축하려는 시도를 보이고 있다.
사실 처음 EDW란 용어가 시장에 나왔을 때 당혹해 하는 사람들도 많았을 것이다. DW 시장 도입 초기단계에서는 시스템 발전에 따른 비용부담의 감소로 인해 이전에 할 수 없었던 대용량의 데이터 분석이 가능해졌고, 이로 인해 기업 내 데이터의 전사적인 인프라 구축과 정보 조회가 가능하다고 소개를 했다.
하지만 이후 단순한 데이터만으로는 사용자의 다양한 구미에 맞는 모든 경우의 주제 모델링이 불가능해지자 각각의 목적에 맞게 데이터 마트를 구축하는 것이 흐름으로 이어져 새로운 DW 구축 프로젝트를 만들어 나가기 시작했다. 그러나 데이터 마트도 기본적으로는 DW를 잘 설계했다면 불필요한 모델이었을 것이다.
그러나 중요한 것은 각 벤더의 이해가 달린 새로운 개념의 출현이 아니다. 새로운 개념이 출현했다고 해서 꼭 그것을 반영하고 도입해야 할 이유도 없고, 그것이 정답이 될 수도 없기 때문이다. 중요한 것은 각 기업의 상황에 맞는 가장 적절하고 유용한 시스템을 구축하는 것이다. 이는 DW 도입의 초기 단계에서부터 줄곧 주장되어 온 것으로 현재의 상황에서도 적합한 말이다. 단지 그것이 확장되고 진보되었을 뿐이다.
DW가 한 순간의 유행으로 끝나지 이유는 기업의 정보 데이터 인프라를 구축하는 최적의 개념이고 필수적인 요소이기 때문이다.
EDW의 이슈와 과제
각 컨설팅업체와 벤더들 사이에서 EDW에 대한 나름의 이론을 내놓고 있다. 기업 운영 과정에서 생산되는 전체 데이터를 한 통에 남김없이 모두 적재해 데이터의 중복을 방지하고 동기화를 보장해야 한다거나, 여러 종류의 마트 중심으로 데이터를 구축하는 것이 차후의 여러 BI 시스템의 확장에 유연하게 대처할 수 있다는 등 벤더 위주의 정의들을 내리고 있다.
그러나 실제 이상주의적인 개념들과는 달리 현실 세계에서의 EDW 구축에서는 정답이 없다는 것이 필자의 생각이다. 실제로 많은 회사에서 DW를 구축했고, 부서 단위의 분석 마트를 운영하며, 업무의 효율을 높이기 위해 노력하고 있다,
이들 또한 데이터들의 전사적인 관리와 통합이라는 측면에서 EDW 프로젝트를 준비하고 있는 것이 사실이다. 그러나 실제 EDW 프로젝트가 수행된 결과물을 보면, 단지 지금까지 있었던 DW를 크게 만들어 놓은 것과 크게 다르지 않아 보인다. I/O를 확장하고, 모델이 전사 영역으로 확장되고, CRM 등의 프론트 오피스를 하나 얹어 놓는 등의 형태로 구축되는 것이 현재 거의 모든 사이트에서 진행되는 EDW의 형태인 것이다.
물론 전사영역으로 확장하는 것만으로도 충분히 많은 경비와 인력과 노력을 요하는 것은 사실이다. 그러나 과연 이것이 EDW의 전부일까? 물리적으로 데이터를 모아놓는다는 측면에서만 생각하면 이같은 형태를 EDW라고 할 수도 있지만 진정한 기업의 인프라로서의 EDW란 데이터 측면만으로 부족하다.
기업 데이터를 하나의 분석플랫폼에 모아놓으려는 의도는 무엇인가? 모든 데이터의 접근성을 용이하게 하고, 각 데이터의 주제적 연관성을 보장하여 기업이 가진 정보의 가치를 높이는 것이 EDW라 하면 이 작업은 데이터의 수집만이 아닌 프로세스 개선과 POS에서 백오피스, 분석계까지의 모든 데이터 표준화와 동기화를 말하는 것이다.
이를 위해 필요한 것은 몹시 크고 빠른 공룡 같은 새로운 시스템을 도입하는 것이 아니다. 기업들이 모든 리소스들의 아키텍처 개선을 통한 유기적인 통합과 다원화된 관리 체계를 재정비하여 불필요하게 낭비되는 관리비용을 줄이고, 데이터의 중복을 방지할 수 있는 방향으로 시스템을 재설계 하는 것이 EDW의 중요한 초석일 것이다.
EDW의 기술적 문제점 시스템이 빨라지고 가격이 낮아져 대용량의 데이터를 처리할 수 있게 됐다고 하지만 그 속도에 맞추어 분석에 대한 요구도 복잡해지고, 데이터의 수도 크게 늘어난 것이 사실이다. 이에 따라 DW의 초기부터 논의되고 시간이 지나면 해결될 것으로 봤지만 여전히 해결되지 않고 있는 부분이 몇 가지 있다.
우선 추출에서의 Real Time, 즉 실시간 데이터 처리 문제와 인덱스의 발전에도 불구하고 수GB 이상의 테이블 간 결합을 통한 대량의 데이터 분석 문제, DRS 등으로 표현되는 백업과 복구에 관한 문제 등이 그것이다. 특히 EDW에서는 이와 같은 처리의 중요성이 더욱 부각되고 있지만 현재 시장에 나와 있는 기술로는 완벽한 해결책을 제시하지 못하고 있다.
실시간 처리의 대안으로 EAI 또는 DB의 로그를 처리하는 기술이 부각되고 있지만, 이 역시 많은 코딩을 필요로 하고 실시간으로 요약 데이터에 반영해줄 수는 없다. 실제 OLTP를 사용하는 것과 같은 EDW에 변경 분을 반영하는 것은 적어도 향후 5년 정도 뒤에나 가능할 것으로 보인다.
또한 대량의 트랜잭션을 처리하는 기업과 통신사의 콜 데이터나 은행의 트랜잭션들은 발전된 하드웨어의 속도가 무색할 정도로 증가하고 있다. 하루에도 수십 GB씩 쌓이는 이들 데이터를 처리하고 분석하기 위해 파티션 기법, 비트맵 인덱싱들의 기술들이 사용되고 있으나 근본적인 문제의 해법을 제시해 주지 못하고 있다.
한편 백업의 경우에는 각 DB 벤더들이 솔루션을 보유하고 있고, 나름의 복구 방안을 제시하고 있지만 사용이 어렵고 신뢰성도 부족하기 때문에 전체 파일 시스템의 백업 방법을 쓰고 있는 회사가 대부분이다.
EDW는 그 기술의 근간을 RDBMS에 두고 있다. 이는 분석의 한계 역시 SQL의 영역에 국한됨을 의미한다. 이러한 약점에 따라 이전의 OLTP용 DB를 사용할 경우는 MOLAP을 DW의 부가적인 분석을 제공하는 시스템으로 구축하고 마트를 만들어 왔다.
그러나 분석 전용 DB의 등장과 ROLAP 툴의 발달로 MOLAP은 서서히 그 효용가치를 잃어가고 있는 상황이다. 그러나 이와 같은 관계형 DB기술의 발달에도 불구하고, 여전히 관계형 DBMS는 사용자의 고차원적인 분석 욕구를 해결해 주지 못하고 있는 것 또한 현실이다.
EDW 시장 동향
근래 들어 전 산업에 걸쳐 고르게 EDW의 수요가 증가하고 있다. 작년 한해 동안 금융권에서는 조흥은행, 우리은행, 국민은행 등이 구축을 완료하거나 현재 진행 중이고 현대카드, 신용보증기금, 대한생명, 농협, 교보생명, 우리증권 등이 올해 신규로 EDW를 준비중이다. 또 제조·유통 쪽에서는 롯데백화점, 신세계 이마트, 제일모직, LG패션 등이 지난해 구축을 완료했거나 현재 진행 중이다.
통신산업에서는 KT가 현재 전사적인 EDW를 진행 중이고, 정보통신부도 각각의 업무 부서별로 여러 건의 DW 프로젝트가 진행 중이거나 신규도입을 준비하고 있다. 이외에도 연세의료원, 건국대 병원 등 많은 종합 병원들이 올해 DW의 도입을 계획하고 있는 상황이다.
근래에 와서 BI 애플리케이션의 수요가 증가하고 있다. 이는 기존의 모델링 방법론의 실패 요인을 줄이는 한편 각 인더스트리의 선진 기술에 프로세스를 맞추어 개발 기간을 단축하고, 많은 부분이 표준화되어 있는 리포지토리를 도입해 업무의 효율을 높이려는 시도라고 볼 수 있다.
그렇다면 높은 비용에도 불구하고 OLAP 툴을 쓰는 이유는 무엇일까? 이는 기존의 OLTP 시스템 개발과 같이 충분히 개발을 할 수 있는 기술이 있음에도 미리 개발되어 있는 컴포넌트들을 사용함으로써 빠른 시간에 프로젝트를 완료하고, 완성도 높은 분석을 제공하기 위함이다.
이러한 BI 애플리케이션들이 아무리 좋은 선진 프로세스와 첨단 기능을 제공한다할 지라도 기존 분석의 근간이 되는 데이터가 부족하고 데이터의 신뢰성이 없다면 또 하나의 유행에 의한 시스템이 될 뿐이다.
이러한 문제의식은 기반 데이터의 통합과 정제라는 기본에서 출발해야 하는 공통의 인식을 가지게 하였고, 거의 모든 기업에서 EDW는 필수적인 정보인프라로 자리매김하게 된 것이다.
또한 기존에 EDW를 구축한 기업에서는 고도화를 통해 새로운 활용처를 모색하게 되었고, 보다 고급화되고 정밀한 분석을 위해 즉시성의 데이터 요구가 생기게 되었다.
이 를 위해 기존의 일 배치나 월 배치의 형태에서 벗어나 데이터의 업데이트 주기를 최소화하는 Near Real Time 처리 방법에 대한 논의가 활발하게 이루어지고 있으며 기존의 DW, OLAP의 분석으로 만족할 수 없었던 집단(마케팅이나 정보분석실과 같은 부서)을 위해 IT의 주도 하에 이루어지던 주제 영역의 모델링, 데이터 조작 등의 작업 주도권과 사용권한을 사용자에게 줄 수 있는 고급분석 시스템에 대한 요구가 증가하고 있다.
[출처] EDW의 이해 - EDW의 필요성과 현황|작성자 문식
[참고사이트] http://blog.naver.com/mylog?Redirect=Log&logNo=140004891281
데이터 웨어하우징(Data Ware-housing)의 개념은 기간계의 주요 데이터를 주제별로 통합하여 현업 부서의 정보분석 요구를 신속히 충족시키는 시스템을 의미한다. 이를 위해 기업의 정보기반이 되는 인프라를 구축하고 이를 IT부서의 도움 없이 액세스하는 방법을 제공하게 된다. EDW는 이 개념을 기업의 전사적인 영역으로 확장시킨 개념이라고 볼 수 있다.
그렇다면 EDW의 범주를 어디까지 보아야 할까? 기업에서 최근 일반적으로 구성되는 표준 모델의 형태는 <그림>과 같다.
<그림>에서 보면 이전과 같이 전면에 포지셔닝 되는 그림이 아닌 BI(Business Intelligence) 애플리케이션을 위한 데이터 인프라로서의 역할이 강조되는 것을 확인할 수 있다. 이와 같이 EDW란 것은 이전의 DW를 전사적으로 확장하려고 하는 부분에서 생긴 다양한 시스템간의 인터페이스와 데이터 통합, 표준화 등을 중요시한 DW의 확장 모델인 동시에 기업 정보에 관한 프로세스의 표준화와 개선, 즉 BPR적 영역을 포함한다. 또한 CRM, BSC 같은 다양한 분석적 애플리케이션들을 위한 데이터의 원천이 된다.
EDW의 출현 배경
IT시장에 DW의 개념이 나오고 일반화된지 거의 10년이 되어가고 있지만 초기의 정의와 역할과는 다르게 최근 DW의 의미는 거의 분석계 플랫폼의 전체를 지칭하는 명사로 인식되고 있다. 단순히 데이터를 주제별로 통합해 OLAP 시스템을 통한 다차원의 분석을 가능케 하는 초기 정의와는 달리 2000년대 들어서는 정제되고 통합된 데이터를 거의 모든 BI 애플리케이션(ABM, BSC, CRM 등)에게 제공해 주는 데이터 인프라 측면이 강조되었다.
이에 따라 ABM, BSC, 혹은 CRM 프로젝트란 이름 하에 각 시스템의 분석 마트를 설계하는 프로젝트들이 진행되어 왔다. 또한 근래에 들어서는 RTE(Real Time Enterprise), EAI와의 연동을 통한 좀더 기술적, 비즈니스적으로 진보된 플랫폼으로 구축하려는 시도를 보이고 있다.
사실 처음 EDW란 용어가 시장에 나왔을 때 당혹해 하는 사람들도 많았을 것이다. DW 시장 도입 초기단계에서는 시스템 발전에 따른 비용부담의 감소로 인해 이전에 할 수 없었던 대용량의 데이터 분석이 가능해졌고, 이로 인해 기업 내 데이터의 전사적인 인프라 구축과 정보 조회가 가능하다고 소개를 했다.
하지만 이후 단순한 데이터만으로는 사용자의 다양한 구미에 맞는 모든 경우의 주제 모델링이 불가능해지자 각각의 목적에 맞게 데이터 마트를 구축하는 것이 흐름으로 이어져 새로운 DW 구축 프로젝트를 만들어 나가기 시작했다. 그러나 데이터 마트도 기본적으로는 DW를 잘 설계했다면 불필요한 모델이었을 것이다.
그러나 중요한 것은 각 벤더의 이해가 달린 새로운 개념의 출현이 아니다. 새로운 개념이 출현했다고 해서 꼭 그것을 반영하고 도입해야 할 이유도 없고, 그것이 정답이 될 수도 없기 때문이다. 중요한 것은 각 기업의 상황에 맞는 가장 적절하고 유용한 시스템을 구축하는 것이다. 이는 DW 도입의 초기 단계에서부터 줄곧 주장되어 온 것으로 현재의 상황에서도 적합한 말이다. 단지 그것이 확장되고 진보되었을 뿐이다.
DW가 한 순간의 유행으로 끝나지 이유는 기업의 정보 데이터 인프라를 구축하는 최적의 개념이고 필수적인 요소이기 때문이다.
EDW의 이슈와 과제
각 컨설팅업체와 벤더들 사이에서 EDW에 대한 나름의 이론을 내놓고 있다. 기업 운영 과정에서 생산되는 전체 데이터를 한 통에 남김없이 모두 적재해 데이터의 중복을 방지하고 동기화를 보장해야 한다거나, 여러 종류의 마트 중심으로 데이터를 구축하는 것이 차후의 여러 BI 시스템의 확장에 유연하게 대처할 수 있다는 등 벤더 위주의 정의들을 내리고 있다.
그러나 실제 이상주의적인 개념들과는 달리 현실 세계에서의 EDW 구축에서는 정답이 없다는 것이 필자의 생각이다. 실제로 많은 회사에서 DW를 구축했고, 부서 단위의 분석 마트를 운영하며, 업무의 효율을 높이기 위해 노력하고 있다,
이들 또한 데이터들의 전사적인 관리와 통합이라는 측면에서 EDW 프로젝트를 준비하고 있는 것이 사실이다. 그러나 실제 EDW 프로젝트가 수행된 결과물을 보면, 단지 지금까지 있었던 DW를 크게 만들어 놓은 것과 크게 다르지 않아 보인다. I/O를 확장하고, 모델이 전사 영역으로 확장되고, CRM 등의 프론트 오피스를 하나 얹어 놓는 등의 형태로 구축되는 것이 현재 거의 모든 사이트에서 진행되는 EDW의 형태인 것이다.
물론 전사영역으로 확장하는 것만으로도 충분히 많은 경비와 인력과 노력을 요하는 것은 사실이다. 그러나 과연 이것이 EDW의 전부일까? 물리적으로 데이터를 모아놓는다는 측면에서만 생각하면 이같은 형태를 EDW라고 할 수도 있지만 진정한 기업의 인프라로서의 EDW란 데이터 측면만으로 부족하다.
기업 데이터를 하나의 분석플랫폼에 모아놓으려는 의도는 무엇인가? 모든 데이터의 접근성을 용이하게 하고, 각 데이터의 주제적 연관성을 보장하여 기업이 가진 정보의 가치를 높이는 것이 EDW라 하면 이 작업은 데이터의 수집만이 아닌 프로세스 개선과 POS에서 백오피스, 분석계까지의 모든 데이터 표준화와 동기화를 말하는 것이다.
이를 위해 필요한 것은 몹시 크고 빠른 공룡 같은 새로운 시스템을 도입하는 것이 아니다. 기업들이 모든 리소스들의 아키텍처 개선을 통한 유기적인 통합과 다원화된 관리 체계를 재정비하여 불필요하게 낭비되는 관리비용을 줄이고, 데이터의 중복을 방지할 수 있는 방향으로 시스템을 재설계 하는 것이 EDW의 중요한 초석일 것이다.
EDW의 기술적 문제점 시스템이 빨라지고 가격이 낮아져 대용량의 데이터를 처리할 수 있게 됐다고 하지만 그 속도에 맞추어 분석에 대한 요구도 복잡해지고, 데이터의 수도 크게 늘어난 것이 사실이다. 이에 따라 DW의 초기부터 논의되고 시간이 지나면 해결될 것으로 봤지만 여전히 해결되지 않고 있는 부분이 몇 가지 있다.
우선 추출에서의 Real Time, 즉 실시간 데이터 처리 문제와 인덱스의 발전에도 불구하고 수GB 이상의 테이블 간 결합을 통한 대량의 데이터 분석 문제, DRS 등으로 표현되는 백업과 복구에 관한 문제 등이 그것이다. 특히 EDW에서는 이와 같은 처리의 중요성이 더욱 부각되고 있지만 현재 시장에 나와 있는 기술로는 완벽한 해결책을 제시하지 못하고 있다.
실시간 처리의 대안으로 EAI 또는 DB의 로그를 처리하는 기술이 부각되고 있지만, 이 역시 많은 코딩을 필요로 하고 실시간으로 요약 데이터에 반영해줄 수는 없다. 실제 OLTP를 사용하는 것과 같은 EDW에 변경 분을 반영하는 것은 적어도 향후 5년 정도 뒤에나 가능할 것으로 보인다.
또한 대량의 트랜잭션을 처리하는 기업과 통신사의 콜 데이터나 은행의 트랜잭션들은 발전된 하드웨어의 속도가 무색할 정도로 증가하고 있다. 하루에도 수십 GB씩 쌓이는 이들 데이터를 처리하고 분석하기 위해 파티션 기법, 비트맵 인덱싱들의 기술들이 사용되고 있으나 근본적인 문제의 해법을 제시해 주지 못하고 있다.
한편 백업의 경우에는 각 DB 벤더들이 솔루션을 보유하고 있고, 나름의 복구 방안을 제시하고 있지만 사용이 어렵고 신뢰성도 부족하기 때문에 전체 파일 시스템의 백업 방법을 쓰고 있는 회사가 대부분이다.
EDW는 그 기술의 근간을 RDBMS에 두고 있다. 이는 분석의 한계 역시 SQL의 영역에 국한됨을 의미한다. 이러한 약점에 따라 이전의 OLTP용 DB를 사용할 경우는 MOLAP을 DW의 부가적인 분석을 제공하는 시스템으로 구축하고 마트를 만들어 왔다.
그러나 분석 전용 DB의 등장과 ROLAP 툴의 발달로 MOLAP은 서서히 그 효용가치를 잃어가고 있는 상황이다. 그러나 이와 같은 관계형 DB기술의 발달에도 불구하고, 여전히 관계형 DBMS는 사용자의 고차원적인 분석 욕구를 해결해 주지 못하고 있는 것 또한 현실이다.
EDW 시장 동향
근래 들어 전 산업에 걸쳐 고르게 EDW의 수요가 증가하고 있다. 작년 한해 동안 금융권에서는 조흥은행, 우리은행, 국민은행 등이 구축을 완료하거나 현재 진행 중이고 현대카드, 신용보증기금, 대한생명, 농협, 교보생명, 우리증권 등이 올해 신규로 EDW를 준비중이다. 또 제조·유통 쪽에서는 롯데백화점, 신세계 이마트, 제일모직, LG패션 등이 지난해 구축을 완료했거나 현재 진행 중이다.
통신산업에서는 KT가 현재 전사적인 EDW를 진행 중이고, 정보통신부도 각각의 업무 부서별로 여러 건의 DW 프로젝트가 진행 중이거나 신규도입을 준비하고 있다. 이외에도 연세의료원, 건국대 병원 등 많은 종합 병원들이 올해 DW의 도입을 계획하고 있는 상황이다.
근래에 와서 BI 애플리케이션의 수요가 증가하고 있다. 이는 기존의 모델링 방법론의 실패 요인을 줄이는 한편 각 인더스트리의 선진 기술에 프로세스를 맞추어 개발 기간을 단축하고, 많은 부분이 표준화되어 있는 리포지토리를 도입해 업무의 효율을 높이려는 시도라고 볼 수 있다.
그렇다면 높은 비용에도 불구하고 OLAP 툴을 쓰는 이유는 무엇일까? 이는 기존의 OLTP 시스템 개발과 같이 충분히 개발을 할 수 있는 기술이 있음에도 미리 개발되어 있는 컴포넌트들을 사용함으로써 빠른 시간에 프로젝트를 완료하고, 완성도 높은 분석을 제공하기 위함이다.
이러한 BI 애플리케이션들이 아무리 좋은 선진 프로세스와 첨단 기능을 제공한다할 지라도 기존 분석의 근간이 되는 데이터가 부족하고 데이터의 신뢰성이 없다면 또 하나의 유행에 의한 시스템이 될 뿐이다.
이러한 문제의식은 기반 데이터의 통합과 정제라는 기본에서 출발해야 하는 공통의 인식을 가지게 하였고, 거의 모든 기업에서 EDW는 필수적인 정보인프라로 자리매김하게 된 것이다.
또한 기존에 EDW를 구축한 기업에서는 고도화를 통해 새로운 활용처를 모색하게 되었고, 보다 고급화되고 정밀한 분석을 위해 즉시성의 데이터 요구가 생기게 되었다.
이 를 위해 기존의 일 배치나 월 배치의 형태에서 벗어나 데이터의 업데이트 주기를 최소화하는 Near Real Time 처리 방법에 대한 논의가 활발하게 이루어지고 있으며 기존의 DW, OLAP의 분석으로 만족할 수 없었던 집단(마케팅이나 정보분석실과 같은 부서)을 위해 IT의 주도 하에 이루어지던 주제 영역의 모델링, 데이터 조작 등의 작업 주도권과 사용권한을 사용자에게 줄 수 있는 고급분석 시스템에 대한 요구가 증가하고 있다.
[출처] EDW의 이해 - EDW의 필요성과 현황|작성자 문식
[참고사이트] http://blog.naver.com/mylog?Redirect=Log&logNo=140004891281
피드 구독하기:
글 (Atom)