데이터는 비트와 바이트이다. 이 데이터가 인간이나 컴퓨터에 의해 의미를 부여받을 때 정보가 된다. 이 정보는 누군가에 의해 적용될 때 지식이 된다. 이 지식이 경험이나 기술 혹은 통찰력과 함께 적용될 때 지혜가 된다. 여기서 우리가 알고 있는 정보와 지식사이의 차이점 몇 가지를 들어보면 다음과 같다.

원제: The Knowledge Farmer
저자: David Coleman
출처: www.collaborate.com/hot_tip/tip1197.html

(0) (0)

Posted by 좐군

(0) (0)

Posted by 좐군

(0) (0)

Posted by 좐군

(0) (0)

Posted by 좐군

(0) (0)

Posted by 좐군

윤성호 | 엔코아정보컨설팅 책임 컨설턴트

정보와 데이터는 전혀 다른 의미를 갖고 있다. 현 시대를 정보의 홍수라 말하지만 사실은 자신과 전혀 상관 없는 데이터가 넘쳐 흘러난다. 이 중에서 자신에게 꼭 맞는 정보를 찾기에 많은 시간과 노력을 소모하고 있는 셈이다. 특히 기업에서는 데이터 통합이 부각되고 있으며, 데이터에 진정한 가치를 부여하기 위한 하나의 요건으로 받아들여지고 있는 데이터 웨어하우스 구축의 필요성이 높아지고 있다. 이 글에서는 데이터 통합의 필수품처럼 여겨지는 데이터 웨어하우스 구축 방법을 살펴보며, 데이터 통합의 중요성을 생각해보도록 하자.

필자는 과거 XX기업의 ‘종합 정보시스템 구축 프로젝트’에 참여한 적이 있다. 왜 XX기업은 이러한 프로젝트를 진행하려고 했을까? 이곳 역시 다음과 같은 질문과 해답의 목마름을 해소하고자 하는 많은 기업들 중 하나였다.

① 제품별로, 대리점별로 혹은 지역별로 당월 목표를 달성했는가?
② 신제품은 모든 지역에서 적절한 비율로 판매됐는가?
③ 신제품 중에 목표치에 미달한 제품이 있는가? 그렇다면 이 제품은 폐기되어야 하는가?
④ 판매 그룹 사이에 평균 할인율은 어떠한가? 이러한 평균 할인율을 반영하도록 수수료 구조가 조정되어야 하는가?
⑤ 인구 통계적 특성이 유사한 대리점들 사이에 차이가 있는가? 차이가 있다면 이러한 차이는 왜 발생했는가?

XX기업은 ‘풍요 속의 빈곤’
XX기업은 지난 수십 년 동안 축적해 온 대량의 데이터에서 사용자의 의사결정에 필요한 중요 정보를 산출하기 위해 여러 방법들을 시도해왔다. 하지만 ‘풍요 속의 빈곤’이란 말처럼 정보의 수집·공유·분석·의사결정을 원활하게 도와주기엔 데이터들이 너무나도 여러 시스템에 분산되어 있었다. 각 부서별로 수집·운영되는 데이터는 다른 부서에서는 참조할 수 없을 정도로 격리되어 있었으며, 이 때문에 중복된 데이터는 데이터의 무결성이 전부 깨져 있는 상태로 존재하고 있었다. 또한 상이한 DBMS 시스템들이 혼재되어 있었으며 데이터를 움직이고 있는 애플리케이션 플랫폼도 매우 다양했다. 

XX기업에서는 지금과 같은 상황으로는 더 이상 ‘기업 지능’, 바로 정보기술을 효과적으로 사용할 수 없다는 판단에 이르렀다. 각 시스템의 호환성 문제와 저장되어 있는 과거 정보를 사용자가 원하는 상태로 바로 복구할 수 없다는 것, 그리고 다양한 시스템에 흩어져 있는 현재의 데이터를 취합하고 이 데이터들을 능숙하게 조정할 수 없었다. XX기업의 상황을 분석해보면 다음과 같다.

XX기업의 전사적 정보 통합 작업인 ‘종합 정보시스템 구축 프로젝트’가 진행될 수밖에 없는 이유였으며, 이 중에서 데이터 통합이란 목적을 위해 ‘데이터 웨어하우스(이하 DW) 구축’이 절대절명의 과제로 떠오를 수밖에 없었다. 이 글에서는 데이터 통합의 이슈가 왜 발생하며, 그에 따른 DW 구축이 무엇을 해결하는지 DW 구축사례를 통해 이해해 보도록 하자.

데이터 웨어하우스의 정당화
XX기업이 DW 구축을 통해 얻을 수 있는 것은 많다. 특히 DW는 업무 사용자들의 의사결정 지원에 전적으로 이용되는데, 올바른 정보와 형태로 적시에 의사결정에 도움을 제공할 수 있는 엔진을 XX기업 정보시스템에 장착할 수 있었다. 

기존 대부분의 운영시스템은 항상 많은 데이터가 중복됨으로써 하나의 사실에 대해 다수의 버전이 존재했다. 하나의 객체를 지칭하는 다양한 이름이 존재하거나 데이터가 갖는 의미가 서로 다르다는 것이다. 하지만 DW에서는 이러한 데이터가 전사적 관점에서 통합돼 DW는 신뢰할 수 있는 하나의 버전(One version of truth)을 사용자에게 제공할 수 있었다.
DW 내의 데이터는 주로 운영시스템으로부터 공급되지만 다양한 외부 정보의 통합 역시 매우 중요하다. 기업조직 바깥에서 일어나는 것에 대한 정보를 말하는데 경쟁사에 대한 정보, 공급사에 대한 정보·시장·정치·경제에 대한 정보 등 다양한 외부정보를 DW 내에 효과적으로 통합해 경영자의 전략적 의사결정에 많은 도움을 줄 수 있다. 또한 ‘이력 관리’가 있는데, 이력 데이터는 기업정보에 있어서 살아 움직이는 것과 같은 존재이다. 우리가 관리하고자 하는 운영시스템의 데이터는 시간의 흐름에 따라 발생한 과거와 현재의 데이터를 지속적으로 유지·관리가 필요한데 DW는 시간성 혹은 역사성을 지니고 있으므로 장기간의 데이터를 갖고 있게 되어 데이터의 이력을 정확히 관리·확인할 수 있다.
기존의 XX기업의 데이터베이스는 대부분 애플리케이션의 일부분이었다. 즉 운영시스템은 재고 관리, 영업 관리 등과 같은 기업 운영에 필요한 특화된 기능만을 지원했는데, DW를 통해 고객, 제품 등과 같은 주요한 주체를 중심으로 그 주체와 관련된 데이터들을 활용할 수 있었다.
XX기업의 관리자들과 분석가들은 즉각적이고 신속하게 자신의 PC로부터 DW에 접근할 수 있게 됨으로써 컴퓨터 시스템에 지식이 없는 사용자들이 쉽게 접근할 수 있게 됐다. XX기업 정보시스템에 다수의 DSS(Decision Support System)를 지원해 운영 데이터의 변형과 통합을 통해 의사결정자의 생산성을 향상시키고, 기업의 통일된 관점을 제공했다.

정말 DW를 구축했나요?
웬만한 기업이라면 자신들도 DW를 구축해 적용하고 있다고 말한다. 하지만 그 내부를 조그만 파고들어가 보면 그저 말뿐이라는 것을 알 수 있다. 단지 다량의 데이터를 액세스해야 생성할 수 있는 분석 자료를 OLTP에서 처리하기에는 부담이 되기 때문에, 다른 서버로 혹은 테이블에 데이터를 임시로 보관한다는 의미에 지나지 않는다. 그럼 XX기업의 DW 구축과정을 살펴보며 데이터 통합이 왜 중요한가를 생각해보자.

DW 구축의 원칙은 통합, 단순, 장기
XX기업의 ‘종합 정보시스템 구축 프로젝트’의 목적은 업무 수행시 이를 이용하고 공유할 수 있는 전산 환경을 제공하고, 업무를 수행하며 생성된 각종 데이터 및 자료를 업무 담당자가 직접 가공하고 분석하며, 분석자료를 경영진과 외부기관에 제공할 수 있는 전산 환경을 구축하는 데 있었다. 이중 XX기업의 전략정보시스템에서 기업 핵심 업무를 대상으로 DW를 구축하는 것을 그 목표로 했다. 

DW의 기본 원칙은 ‘통합’, ‘단순’, ‘장기’라 하겠다. 기업이 필요한 정보를 분석하기 위한 소스와 데이터를 얼마나 체계적이고 효율적으로 관리할 수 있느냐에 대한 문제는 전적으로 DW 구축의 핵심 요소이다. 그러나 다량의 정보 소스는 OLTP에 너무나 넓게 분산되어져 있었고 그들 간의 관계는 잘 드러나지 않기 때문에 이를 명확하게 분류하고 잘 배치한다는 것이 우리에게 쉽지 않은 과제였다. 또한 대용량의 데이터를 처리해야만 한다는 점과 DBMS에게 많은 것을 맡겨야 하는 DW의 특수성 때문에 최대한 단순하고 명료해야 한다는 것도 적지 않은 부담이었다.

XX기업의 DW 구축

첫 단추는 업무분석
DW를 구축함에 있어 첫 단계로 전략 정보로 이용할 만한 가치가 있는 데이터의 후보를 수집했다. 기존 운영계 시스템의 통계 정보, 업무 규정집, 각종 보고서와 같은 문서들을 취합해 검토하고 필요시 현업 부서 및 전산 담당자와의 인터뷰를 통해 기업의 전반적인 업무를 이해하고, 이 중 전략 정보로 활용할 만한 가치가 있는 데이터를 식별하는 과정이었다. 

이 분석 과정에서 파악한 것은 진정한 고급 정보는 단기간이 아닌 오랜 시간에 데이터를 숙성하고 활용해야만 얻을 수가 있다는 것이다. XX기업의 일반 분석 정보는 앞으로 나타날 논리적으로 존재할 수 있는 모든 의미의 정보에 비하면 극히 일부분에 지나지 않았다. 사용자들은 시간이 흐르면서 더욱 종합적이고 고난이도의 분석 정보를 원하게 될 것은 분명한 사실이기 때문이다.
또한 스테이징 영역에 저장해 놓은 데이터를 활용한다는 접근 방식은 필요한 것만 선별해 만들었기 때문에 기업 전체적인 ‘통합’의 원칙에 위배된다. 이로 인해 날이 갈수록 새로운 요구를 반영하려는 노력의 일환으로 자꾸만 중복된 데이터 집합을 생성하게 되는데, 이로 인해 ‘단순’의 원칙도 지킬 수 없는 것이다. 또한 장시간 숙성시켜 유용하게 쓰여야 할 데이터들이 백업과 함께 사라져 버리고 있기 때문에 ‘장기’의 원칙도 무시된 것이었다. 결국 당장은 사용자들이 원하는 것들을 어렵지 않게 제공할 수는 있겠지만 나중에는 혹독한 대가를 지불해야 하는 시기가 올 것이라는 판단을 내렸다.

운영계 리버스 모델링
DW는 데이터가 생명이다. 이 데이터들은 저절로 만들어지는 것이 아니라 OLTP를 기반으로 생성될 수밖에 없다. DW의 원천이 되는 OLTP를 완벽하게 알지 못하고 만들어진 DW는 결코 정상적인 모습을 하고 있을 수 없다. 이에 운영계 리버스 모델링을 정밀하게 모델링했다. 

DW 구축을 위한 운영계 리버스 모델링은 운영계 데이터베이스의 구조 정보 및 운영계 시스템 분석ㆍ설계 산출물을 근거로 해 전형적인 데이터 모델링 산출물인 ERD(Entity Relationship Diagram)를 도출하는 작업이다. 그 목적은 운영계 데이터 모델 및 물리적 데이터베이스의 구조를 이해하고, 운영계 데이터 모델을 도출해 기업의 전반적인 업무 내용을 정확히 숙지할 수 있으며, ODS(Operational Data Store) 모델링의 방향 정립이 가능하고, DW 구축을 위한 운영계 시스템 변경 요소를 파악할 수 있기 위해서다.
XX기업의 현행 운영계 시스템의 분석ㆍ설계 산출물이 순수하게 데이터 관점보다는 객체지향적인 관점에서 이뤄져 있어 클래스 다이어그램 또는 오브젝트 다이어그램만으로는 관계형 데이터베이스 관점의 데이터 모델을 효과적으로 표현하지 못하는 부분이 존재했다. 이를 보완한다는 측면에서 리버스 모델링을 실시했다. 또한 운영계 리버스 모델링 작업의 본래의 목적은 아니지만 운영계 데이터베이스의 물리적인 테이블들간의 관계를 명확히 파악해보기 위해 RI(Referen tial Integrity) 체크를 실시하게 됐다. 이 과정을 통해 데이터베이스의 구조적 관점에서의 오류 데이터를 식별할 수 있으며, 한편으로는 운영 중에 미처 발견하지 못한 운영계 프로그램 오류를 발견할 수도 있었다.

<그림 1> 기존 운영계 시스템의 특징

<그림 2> DW 프레임워크 

<

그림 3> 리버스 모델링 그림 

DW의 아키텍처 구축
   DW의 기반이 되는 OLTP의 모든 데이터에 대해 매우 상세한 아키텍처를 수립하고 이를 바탕으로 모델링한 DW 아키텍처 또한 상세하게 수립됐다면, 이들 간에는 ‘집합과 집합’간의 매핑 룰(Mapping rule)이 존재하게 된다. 이 매핑 룰이 바로 ETL(Extraction, Transfor mation and Loading)의 알고리즘이 된다. 

OLTP 집합과 DW 집합은 데이터의 집합으로써 이들 간의 전환은 ‘집합간의 매핑’으로 볼 수 있는 것이다. 이것을 DB 마이그레이션을 할 때 적용해 왔던 공식처럼 사례별(Case-by-case)로 다뤄 알고리즘을 생성한다면 그 경우의 수는 엄청나게 많이 발생하고, 오류나 누락이 증가한다. 뿐만 아니라 OLTP 설계에 변화가 발생했을 때 유지 보수를 하는 일도 매우 어려워질 것이라 판단됐다.
또한 리버스 모델링 후에 ODS 모델링 및 ETT 프로그램을 개발했는데, 운영계 시스템에 대한 리버스 모델링을 통해 확인된 운영계 데이터 모델 및 데이터베이스의 물리적 구조를 바탕으로 해 ODS(Operational Data Store)를 설계하고 운영계 데이터베이스로부터 데이터를 추출ㆍ가공해 ODS 데이터베이스화할 수 있는 기능을 갖춘 ETT(Extraction, Transformation & Transportation) 프로그램을 작성했다.
운영계 데이터베이스를 구성하는 데이터 항목들 중에서 전략정보로 활용할 만한 가치가 있는 것들, 즉 차원(Dimension)으로 활용될 항목들과 사실(Fact, 또는 Measurement. 이하 Measurement라 함)로 활용될 항목들을 선별하고 이를 전략정보로 쉽게 활용할 수 있는 데이터로 구조화한 것이 ODS이다. 그러므로 ODS는 다음과 같은 정보 요건을 만족할 수 있도록 설계해야 한다.

이상과 같은 요건을 갖춘 ODS 모델이 설계되면 운영계 데이터베이스로부터 데이터를 추출·가공·이관해 ODS 데이터화하기 위한 ETT 프로그램을 작성했다. XX기업의 전략정보시스템을 구축하고 있는 그 시점에는 DW가 이미 기업의 보편적인 시스템으로서 자리매김하고 있었기 때문에 이를 지원하기 위한 각종 기술 및 솔루션도 발표되고 있었다. 이중 ETT 툴도 예외 없이 이미 시장에 다수 출시되어 있어 이를 활용해 ETT 프로그램을 작성할 수 있었으나 ETT 툴이 갖는 다음과 같은 단점으로 인해 이번 DW 프로젝트에서는 순수 SQL만으로 ETT 프로그램을 작성했다.

ODS 데이터는 운영계 데이터보다 늦게 반영을 하는데 운영계 데이터의 변동사항들을 실시간으로 ODS에 반영하는 것이 이상적이기는 하지만 운영계 시스템 성능에 막대한 영향을 미칠 수 있으므로 운영계 시스템 가동이 정지되고 운영계 시스템의 각종 일괄처리 프로그램까지 수행이 완료된 이후에 ODS로 데이터를 이관하는 방법을 취했다. 이와 같은 방법으로 운영계 데이터의 변동사항들을 ODS에 정확하게 반영하기 위해서는 운영계 데이터 변동사항에 대한 time-stamp 기록을 유지하고 있어야 하며, 운영계 데이터에 대한 삭제는 기본적으로 허용되어서는 안 된다는 법칙을 갖고 운영되어야 한다.

데이터 정제

XX기업의 DW 구축에서 가장 우리를 괴롭히는 것 중의 하나는 소스 데이터의 오류를 어떻게 말끔하게 정제(cleansing)할 수 있는가에 대한 문제였다. 이 때문에 우리는 DW의 데이터 원천이 되는 운영계 데이터의 문제점을 발견하고 이를 바로 잡는데 많은 정성을 기울였다. 거의 이 과정에서 프로젝트의 전체 공정 중 45% 이상의 자원이 소요됐다. 그만큼 중요하지만 프로젝트 수행자가 스스로 밝히려 하지 않으면 문제는 드러나지 않기 때문에 이 과정은 프로젝트 수행자들의 인간성, 도덕성이 그대로 나타난다고 해도 과언이 아니다. 데이터를 정보(information)로 재창출하기 위해서는 데이터가 신뢰할 만해야 한다. 수많은 데이터 중에서 단 하나의 데이터 건이라도 잘못되어 있다면 자칫 정보로서 활용할 수 없는 지경에 이르기도 한다. 그러므로 운영계 데이터 중 전략정보로 활용할 가치가 있는 후보 항목들에 대해서는 업무 처리규정이나 데이터 모델 상의 각종 정의대로 데이터가 발생되고 있는지 확인하고 잘못된 데이터에 대해서는 그 원인을 밝혀내야 한다. 원인이 단지 과거 운영계 시스템으로부터 이관하는 과정에서 발생한 것이라면 기존 데이터 수정으로 간단히 해결할 수 있지만, 현행 운영계 시스템에 의해 발생한 것이라면 데이터의 수정과 관련 프로그램의 수정은 물론 데이터 모델의 구조도 재설계해야 하는 경우도 있을 수 있다. <그림 4>는 데이터 정제의 흐름을 도식화한 것이다

<그림 4> 데이터 정체의 흐름

목적 시스템의 구축

이제 많은 노력을 기울여 체계적인 모습으로 잘 정비된 DW는 이 데이터 소스로부터 생성하는 다양한 목적 시스템(Data Mart, 각종 전문가 시스템 등)으로 데이터를 공급하게 된다. 일반적으로 이런 유형의 시스템은 매우 다양하게 존재하고, 앞으로도 계속적으로 증가하는 특성을 갖고 있다. 물론 이러한 시스템을 제대로 활용하도록 하는 것이 바로 DW를 구축하는 본래의 목적인만큼 갈수록 확대되어야 하는 것은 당연하다. 물론 데이터 마트를 설계하기에 앞서 XX 기업의 전략정보를 구성하는 dimension과 measurement를 확정해야 한다. Dimension과 measurement는 DW 시스템을 통해 보고자 하는 사용자 관점의 정보이기 때문에 이를 확정하기 위해서는 XX기업의 정보관리실 및 관련 현업의 역할이 중요했다. 관련 현업의 의견을 최대한 수렴해 dimension과 measurement를 확정하고 이 둘 간의 연관성을 결정해야 한다.
결국 데이터 마트는 관련 현업의 의견이 집약된 dimension과 measurement, 그리고 이 둘간의 연관 관계를 데이터베이스로 표현하는 것이다.
앞에서 데이터 통합의 관점에서 살펴본 DW의 주요 구축사례를 살펴봤다. 기업의 미래가 어떻게 될 것인가는 경영자들, 관리자들 그리고 많은 현업의 업무 담당자들이 매순간마다 내리고 있는 ‘결정과 선택’에 달려 있는 것이다. 이 구축사례에서 강조한 것처럼 DW는 결국 데이터를 다루고자 하는 시스템이므로 OLTP와는 달리 유능한 데이터 전문 인력 위주로 구축하고, 관리하는 것이 바람직하다고 생각한다. 대용량의 데이터를 다양하고 복잡한 가공을 통해 높은 가치의 정보를 생성해야 하기 때문인 것이다.

XX기업의 DW를 구축하면서 고민했던 점
XX기업의 DW 프로젝트에서 고민했던 점은 무척 많았다. 그것을 정리하면 다음과 같다.

또한 프로젝트의 장애요인을 정리해보면 다음과 같다. 하나는 기술적인 요인, 다른 하나는 기업 문화적인 요인이다. 특히 기업 문화적, 정치적 이슈로 인한 장애요인은 데이터 통합 관점에서 바라본 DW 구축을 힘들게 하는 요인이었다. 왜 여기에서 이런 문제를 짚고 넘어가야 하는지 필자도 고민을 많이 했지만 한 기업의 DW 구축뿐만 아니라 우리나라의 IT 프로젝트의 전체적인 문제점이라 생각했기 때문이다. 또한 이 장애요소는 우리가 애타게 구축하려 노력했던 데이터의 통합이 쉽지 않은 이유도 포함되어 있는 것이다.

DW는 어느 방향으로 가야하는가?

왜 기업에서 이러한 DW를 구축하는 일이 일어나는가? “DW는 하나의 과정이며 목적이 아니다.”라는 말이 있다. 일반적으로 경영진의 의사결정 과정을 도와주도록 주관적이고 시기에 따라 변화하는 종합적인 비휘발성(Non-Volatile) 데이터 수집이라고 정의하고 있다. DW는 수집된 데이터 항목과 정보 사항으로부터 의미를 얻어내려는 오랜 연속된 과정이 필요하다. 지금의 경향은 “데이터가 우리가 알고 있는 의미를 이미 앞지르고 있다”고 말한다. 엄청난 양의 데이터 항목을 계속 산출하므로 정보의 홍수가 발생했고, 우리로 하여금 이러한 데이터의 바다를 항해하는 법(적시 정보의 취득)을 배워야 한다고 말하고 있다. 기업이 갖고 있는 데이터 중에서 기업정보의 본질적인 것이 아닌 것을 발견해내고 데이터 분석을 통해 기업의 현실이나 미래에 대해 더 나은 이해를 제공한다는 측면이다.
앞으로 몇 년간은 분명히 정보 집약적인 산업에 종사하는 기업들에게는 더욱 중요한 시기가 될 것이다. 좁아진 시장과 새로운 기술은 이러한 기업들이 어쩔 수 없이 새로운 정보 영역으로 이동하지 않을 수 없게 만들 것이다. 경쟁의 중요한 우위는 역시 고객들을 잡아두기 위해 고객들과 결속을 유지할 수 있는 회사의 능력에서 나올 것이며, 그 열쇠는 관리자들과 분석가들 그리고 최종사용자들이 필요로 할 때 곧바로 사용할 수 있는 관련성 있는 정확한 가치 정보의 확보이다.
오랜 경쟁자 또는 새로운 경쟁자들의 공격을 받는 현 시장은 매우 세밀한 마케팅, 숨겨진 사업 기회의 파악, 시장의 새로운 조류를 빠르게 탐지해야 한다. 그리고 조직체 내에 주요 정보에 신속히 반응할 수 있는 정보지원 시스템을 갖춤으로써 자체 정보 자원에서 최대한의 가치를 뽑아낼 수 있어야 한다. 조직체가 확고한 시스템 설비를 갖출 때, 비로소 대상 정보 자원을 이용하는 최종 사용자들의 의사 결정 지원능력을 향상시키게 되는 것이다.
또한 기업은 그 DW에 무엇을 넣을 것인지 충분히 생각할 필요가 있다. 기업의 정보가치의 부가가치의 창출을 위해서는 새로운 내부 데이터뿐만 아니라 외부 데이터의 확보도 중요하게 바라보는 것이 좋다. 기업의 성장 전망을 충분히 생각하고 DW를 항해한다는 것은 최종 사용자의 관점에서 프로젝트의 성공 또는 실패로 이어지는 가장 중요한 요인이다. 탁월한 구조와 훌륭한 반응 시간이 갖춰져 있다 해도 자신들이 원하는 바를 찾을 수 없다면 DW가 무슨 소용인가? 그래서 이미 시장은 메타데이터 저장소(Metadata repository) 정보에 관한 중요성이 크게 나타나고 있다.
DW 구축은 지식노동자들로 하여금 특정 주제 분야를 선택하고 DW라는 정보의 금광으로부터 과거에는 캐낼 수 없었던 귀중한 정보를 끄집어낼 수 있게 해준다. DW는 지식의 생산 기지라는 것을 DW 항해 중에 항상 생각하길 바란다.

시스템 대통합은 기술적인 문제가 아니다
이 글에서는 데이터 통합, 그중 DW 관점에서 여러 이야기들을 해봤다. 정보는 자원(resource)이다. 이러한 정보 자원을 효율적으로 사용함으로써 조직의 성공을 도모할 수 있는 것이다. 다른 여러 자원들이 계획적으로 관리되는 것과 마찬가지로 정보도 계획적으로 관리되어야 한다. 기업의 정보요구를 평가하고, 정보 요구를 충족시키는 정보 체계를 구축하며, 이 정보 체계의 구현을 지원하는 업무 시스템 체계를 구축하는 모든 것이 최고 경영진과 사용자들이 쉽게 이해·평가·조치할 수 있도록 구축되어져야 한다. 

2000년대의 중요 경영 주체는 ‘통합’이라고 할 수 있으며 IT 기획 부서에서는 반드시 전체 시스템에 대한 통합의 밑그림을 그려야 한다. 각 회사의 경영환경과 목표에 대한 분석부터 IT의 주요 성공요소를 도출하고 이에 대한 미래지향적인 전체 시스템에 대한 통합 모델을 완성해야 한다. 또한 이로부터 각각의 개별 시스템을 통합시켜 주는 방향으로 가야 할 것이다.
IT의 대통합을 구현하는 기술은 이미 언급한 것처럼 많은 분야가 현재 완성된 형태로 존재하고 있으며, 앞으로 빠른 속도로 성장해나갈 것이다. 시스템 대통합은 기술적인 문제가 아니라 그것에 대한 시대적 요청을 얼마나 깊게 인식하느냐가 성공의 관건이라고 할 수 있다.

(0) (0)

Posted by 좐군

ASIQ는 사이베이스에서 개발한 DW 환경에 최적한 제품이다.
다음은 한국사이베이스 홈페이지에서 가져온 ASIQ(Adaptive Server IQ) 특징에 대한 내용이다. 이 중에서도 가장 흥미로운 것은 역시나 DW에 최적화된 "Vertical Processing" 와 "Compress"에 대한 것이다.
그럼 이제 본론으로....

데이터를 저장하고 처리하는 데이터베이스는 데이터 웨어하우스 시스템의 가장 핵심이 되는 요소로 Sybase는 데이터 웨어하우스에서 수행되는 질의의 특성에 맞게 설계된 데이터베이스를 제공합니다. 새로운 기술을 바탕으로 기존의 어떤 데이터베이스보다 빠른 성능을 제공할 수 있으며 정형화된 질의 뿐만 아니라 임의 질의에도 최고의 성능을 보장하는 유연성 그리고 데이터 웨어하우스 구축비용을 절감하여 최고의  투자 대비 효과를 나타낼 수 있는 경제성을 갖춘 ASIQ(Adaptive Server IQ)라는 데이터베이스를 제공 합니다

ü        기존 RDBMS는 OLTP와 DSS가 혼재된 데이터베이스 엔진 인데 반해 ASIQ는 데이터 웨어하우스 전용 RDBMS로 인덱싱이나 액세스 방식에서 데이터 웨어하우스에 맞는 새로운 기법으로 구현된 RDBMS로 성능, 유연성, 경제성 측면에서 가장 탁월한 데이터베이스 입니다

ü        기존 RDBMS는 대량의 데이터에 대한 질의 특히 조인에 대한 성능을 높이기 위해 데이터베이스 스키마를 비정규화 즉 Star-Schema 또는 Snowflake-Schema로 디자인 하기를 권장 하지만 ASIQ의 새로운 기술은 데이터베이스 스키마에 대해 어떠한 제약도 두지 않습니다

ü        RDBMS가 처리 능력을 높이기 위해 단일 질의 작업을 MPP와 같은 병렬 노드에 분담시키는 방법으로 대용량 데이터를 처리 하는 기법을 이용하는데 이는 비용에 비해 성능에 문제가 있습니다

사실 시스템의 처리속도에 가장 큰 영향을 미치는 것은 I/O양 입니다. 타 RDBMS의 액세스 기법 즉 레코드 별 처리는 소수의 레코드에 대한 처리가 중심인 OLTP에 적합한 기법으로 대량의 데이터를 처리하는 데이터웨어 하우스에는 맞지 않습니다. 그리고 기존 RDBMS의 대표적 인덱싱 기법인 B-Tree 인덱스는 소수의 레코드를 빠르게 액세스 하는 OLTP에 최적화 되어 있어 대량의 데이터에 대해 처리하는 분석 업무와 임의 질의에 대해 대응할 수 없어 결국 유연한 데이터 웨어하우스를 구축할 수 없습니다. 그러나 ASIQ의 새로운 인덱싱 기법은 데이터 유형과 질의 형태에 따라 다양한 인덱스를 제공하고 미리 정의되어 있지 않은 임의 질의(Ad-hoc)에도 최고의 성능을 보장합니다. 다음은 사이베이스 ASIQ의 구조 및 특징입니다.

커널구조
ASIQ는 기존 환경에 쉽게 접목 시킬 수 있는 Sybase의 Native Connectivity인 OCDK, 업계 표준 데이터베이스 Connectivity인 ODBC, JAVA환경을 지원하는 JDBC 클라이언트 호출을 모두 지원하고  Ansi Standard 92 표준SQL 명령을 지원할 뿐 아니라 내장된 CIS(Common Integration Services)기능은 메타 데이터 관리 서버인 ASE와 유기적 연동을 지원합니다. 또한 ASIQ는 업계 표준을 따르므로 데이터 웨어하우스 구성요소 인 ETT Tool, OALP Tool, Case Tool과 원활한 연동이 가능한 RDBMS입니다

Vertical Processing

기존 RDBMS는 특정 몇 개의 레코드를 빠르게 검색, 삽입, 갱신, 삭제 하는데 주안점을 두고 설계 되었기 때문에 데이터 액세스 방식이 레코드 레벨로 되어 있습니다. 그러나 데이터 웨어하우스는 일정 주기로 데이터가 로드 되며 로드된 후에 액세스 되는 형태로 이용되어 집니다. 이때 데이터 웨어하우스에 사용되는 질의는 레코드의 모든 항목이 필요한 것이 아니라 특정 몇 개의 컬럼만 필요로 합니다. 따라서 레코드 레벨의 데이터 액세스 방식은 불필요한 I/O를 유발 시키므로 데이터 웨어하우스를 효과적으로 지원할 수 없습니다. 이와 같은 I/O의 증가를 피하기 위해 MPP와 같은 병렬 시스템을 이용 하는데 이는 여러 시스템에 I/O를 분산시켜 성능을 향상 시키기 위한 것인데 결국 I/O의 총량은 변화가 없으며 비용 대비 성능이 탁월하지 않은 것으로 나타났습니다. ASIQ는 I/O 자체를 줄일 수 있는 새로운 데이터 액세스 기법을 제공 합니다. 필요한 컬럼만 액세스 하며 각 컬럼은 Bit-Wise Index 기법으로 압축 되어 있어 한번 I/O에 대단히 많은 양의 데이터를 읽어 들일 수 있습니다.  

이러한 혁신적인 데이터 액세스 기법(Vertical Processing)은 I/O양을 90%이상 줄일 수 있어 RDBMS중에 가장 빠른 성능을 나타냅니다. COL3을 기준으로 COL4를 그룹하여 합계를 낼 때 필요한 컬럼만 액세스하는 Vertical Processing과 16K에서 512K 까지의 Large I/O Block은 I/O를 최소화 하여 어떤 RDBMS도 따라올 수 없는 최고의 성능을 보장합니다 그리고 SMP환경에서 ASIQ는 Read, Write를 모두 병렬로 처리 합니다. 병렬 처리의 단위는 컬럼 레벨 까지 처리할 수 있습니다. COL3과 COL4 그리고 COLN이 동시에 액세스 되고 특히 COLN을 연산할 때 COLN의 각 비트 단위별로 병렬 처리가 가능 합니다

DB Level Striping

기존 RDBMS에서 여러 디스크에 걸쳐 데이터를 로드할 때 데이터 분산 방식은 테이블 파티션에 의존 합니다.이는 관리자가 어떤 분배 방식을 사용할 것인가를 미리 결정하고 어떤 디스크로 데이터를 분산할 것인가를 미리 설정해야 합니다. 이는 관리자의 비용이 많이 드는 작업이고 잘못된 판단을 하였을 경우 데이터 특정 디스크에 몰리는 현상이 나타납니다. ASIQ의 데이터 분산은 기본적으로 이루어 지며 사용하는 DBSPACE(ASIQ로 할당된 디스크 File)들 중 최소 사이즈를 기준으로 데이터 Block단위로 입력되는 순서에 의해 자동 분산 됩니다. 이러한 분산 방식은 입력되는 데이터가 특정 디스크에 몰리는 현상을 없애고 관리자의 부담을 덜어 줄 수 있습니다.

독특한 데이터 저장 방법
일반적인 DBMS는 데이터와 인덱스를 구분하여 저장하여 처리합니다. 이는 데이터 부분은 자주 변환 되어지지만 인덱스는 자주 변환 되지 않고 소량의 데이터를 찾아 가는 최적의 PATH를 제공하는 OLTP에 적합 하도록 설계가 되어 있기 때문 입니다. 여기서 인덱스의 구조를 살펴보면 인덱스의 시작점인 Root, 그리고 중간 Level 인덱스 페이지, 마지막으로 데이터의 Row-ID를 가지고 있는 Leaf페이지로 구성 되어 있는데 Leaf페이지는 해당 컬럼의 데이터를 모두 가지고 있습니다. ASIQ는 이 인덱스 Leaf페이지를 이용하여 데이터를 저장하고 처리하므로 별도의 데이터 부분이 필요치 않습니다. 따라서 데이터 웨어하우스에 존재하는 대량의 데이터를 저장하는 디스크 소요량을 줄이고 효과적인 액세스 기법을 사용할 수 있습니다.

Compress

ASIQ의 특징 중 데이터를 압축저장을 합니다. 카디날리티가 낮을수록 압축 율은 더 높습니다. 그리고 블록사이즈가 클수록 효과적으로 압축할 수 있는데 메모리가 충분하다면 최대 블록 사이즈(512K)로 하는 것이 더욱 효과적 입니다. 예를 들어 원시 데이터가 3년을 기준으로 하면 1.5TB 정도로 추정 된다고 가정했을 때 ASIQ를 이용하여 데이터 웨어하우스를 구축하면 데이터영역 1.2TB와 DB 작업공간 300GB 그리고 Unix 및 ETT영역 500GB로 2TB면 향후 1년을 Disk 추가 없이 이용할 수 있습니다.다른 데이터베이스를 이용할 경우 적어도 4TB이상의 Disk가 소요될 것 입니다

Optimizer

ASIQ의 Optimizer는 기본적으로 Cost-Base Optimizer이며 Option과 Hint를 이용하여 개발자가 Optimizer의 Plan과 Index 선택 부분에 대한 제어를 할 수 있습니다. 그리고 병렬처리 및 다양한 Join전략과 Aggregation전략을 제공하여 다중 사용자 환경 또는 Single 사용자환경 과 같은 다양한 상황에 맞는 Option을 제공 합니다. ASIQ Optimizer가 사용하는 Join 전략에는 다음과 같은 방법들이 있습니다.

ü        Nested-Loop

ü        Sort-Merge

ü        Hash

ü        Join-Index                  

ü        Nested-Loop Push Down

ü        Sort-Merge Push Down

ü        Hash Push Down

또한 Aggregation 전략으로는 다음과 같은 방법들을 사용합니다.

ü        Sort-Merge

ü        Hash

ü        Index

그리고 모든 컬럼이 인덱스화 되어 Ad-hoc Query에 대한 성능을 향상시키며 한 테이블에 대한 Index선택도 복수의 인덱스를 선택할 수 있어 보다 나은 성능을 나타낼 수 있는 지능적인 Optimizer입니다.

유연성
비정형질의 : 비정형 질의의 가장 큰 문제점은 분석 시점에 나타나지 않은 정보를 요구할 때 인덱스로 설정되지 않은 컬럼을 중심으로 데이터를 보고자 하는 것이 가장 큰 문제가 됩니다. 대량의 데이터를 가지고 있는 테이블을 모두 Read해야만 하기 때문에 I/O를 폭증 시켜 성능에 큰 문제를 야기 시킵니다. 특히 다중 사용자 환경에서 이러한 질의는 다른 사용자에게도 매우 큰 악 영향을 미칩니다. 그러나 ASIQ는 모든 컬럼이 인덱스화 되어 있고 필요한 컬럼만 Read하는 Vertical Processing을 지원하므로 어떤 유형의 비정형 질의에도 절대 테이블 스캔을 하지 않습니다. 그리고 ASIQ의 Cost-Base Query Optimizer는 사용자의 질의 문장이 어떻게 쓰여지든 관계없이 문법과 의미가 맞으면 동일한 성능을 나타냅니다. 비정형 질의에서 성능을 보장할 수 있는 것이 Sybase 데이터 웨어하우스 솔루션의 가장큰 특징 입니다

설계변경 : 분석시점에서 반영되지 않거나 사용 중 필요에 의해 새로운 항목의 추가 및 삭제에 대한 원활한 지원은 데이터 웨어하우스의 요구의 변화에 대한 적응력을 높입니다. 모든 RDBMS는 항목의 추가가 간단한 명령만으로 수행됩니다. 그러나 대량의 데이터를 가진 테이블에 추가된 항복에 데이터를 채우기는 용이하지 않습니다. ASIQ는 컬럼 별 Insert 및 Update를 지원하므로 최소의 부하로 대량의 데이터를 Insert 및 Update할 수 있으며 불필요한 항목은 Schema뿐 아니라 Disk영역에서도 완전히 제거할 수 있습니다

DB 재구성
ASIQ는 타 DBMS와 달리 삭제된 공간 즉시 가용공간으로 되돌려 줌으로 DB 재구성 작업을 하지 않습니다.

튜닝
타 DBMS에서 튜닝기법은 질의를 중심으로 하는 튜닝을 합니다. 이것은 성능이 떨어지는 모든 질의에 대해 튜닝을 하여야만 하는 부담을 가지고 있고 경우에 따라 인덱스 재생성 혹은 요약 테이블 관리와 같은 비용이 많이 드는 튜닝을 해야 하지만 ASIQ의 튜닝은 데이터를 중심으로 튜닝을 합니다. 컬럼의 카디날리티와 용도만 파악하여 적절한 인덱스 설정하게 되면 해당 컬럼을 사용하는 모든 질의는 동시에 튜닝이 됩니다. 따라서 튜닝하기 쉽고 지속적으로 유지 됩니다.

다중 SMP 환경에서의 특징
ASIQ Multiplex의 설치는 1 Day정도로 충분히 설치할 수 있고, Instance추가는 사용자 서비스 중에 1시간 정도의 짧은 작업시간으로 추가할 수 있으며 다중 사용자 환경에서 +98%의 Scalability를 보장합니다. 데이터베이스를 공유하기 위해 별도의 Cluster Software을 사용하지 않고도 모든 Instance는 데이터베이스내의 모든 Object를 공유합니다. 그리고 Instance의 추가 또는 삭제로 인해 Application의 변경을 요구하지 않습니다. 각 노드 간의 H/W Size가 업무에 맞게 조정이 가능하여 동일 Size의 H/W를 요구하지 않을 뿐 아니라 동일 기종을 요구하지도 않습니다.이는 H/W 선택권을 구축할 때나 확장할 때 특정 H/W벤더에서 벗어날 수 있는 유연성을 제공하며 다음과 같은 특징이 있습니다

ü        Shared disk 구조

ü        MPP와 같은 Database partitioning 불필요

ü        각 IQM instance는 전체 DB를 처리

ü        Node간 query parallelism이 없음

ü        No complex cluster interconnect

ü        간단한 management 와 tuning

ü        각 Node는 서로 다른 H/W Size

ü        SAN & RAID와 같은 Disk 솔루션 사용

ü        Node제한이 없음

ü        MPP와 같이 새로운 교육 불 필요

ü        MPP와 비교할 때 비용이 1/10

단일 SMP 환경에서의 특징
ASIQ Multiplex의 Instance간 서로 다른 시스템 Resource구성이 가능하며 각 Instance간 서로 다른 업무를 수행함으로 부서간 System 간섭을 피할 수 있고 상호 Fail Over를 유지하여 중단 없는 사용자 서비스를 가능케 합니다. 각 Instance간 사용자를 분배할 수 있어 Load Balance를 유지하며 ASIQ Multiplex에 대한 개발자나 사용자 모두 별도의 교육을 요구하지 않습니다. 그리고 개발자에게 실제 환경과 동일한 개발 환경을 제공하여 개발된 Application에 대한 재검증을 요구하지 않으며 다음과 같은 특징이 있습니다

ü        Single Node에서 구성되어 짐

ü        ASIQ에서 2-3시간 후 ASIQ-M으로 Upgrade

ü        추가적인 H/W 불필요

ü        System Configuration의 변경이 불필요

ü        ASIQ-M Instance간 서로 다르게 구성 가능

ü        ASIQ-M Instance간 서로 다른 업무 가능

ü        ASIQ-M Instance간 서로 다른 User 가능

ü        메인프레임과 같은 Resource Control 가능

ü        Multi-Node ASIQ-M과 동일구조

ü        튜닝을 위한 Down time의 불필요

ASIQ-M과 Disk Solution
 ASIQ Multiplex는 OS Level의 공유 Solution을 이용하지 않고 SAN과 같은 Disk Solution을 그대로 이용하기 때문에 구성이 쉽고 확장이 용이합니다. 그리고 Disk Level의 Striping과 DB Level의 Striping을 같이 사용할 수 있어 Disk 확장 시 데이터베이스를 재 구성할 필요가 없으며 다음과 같이 구성하면 성능향상에 많은 도움이 됩니다

ü        H/W Level의 RAID striping, S/W Level의 IQ-M striping을 사용하고 OS striping은 사용 않음

ü        DB Space는 RAW device로 구성

ü        가능하면 SCSI, RAID SCSI adapter, Host SCSI adapter 를 FC Type으로 Upgrade

ü        FC switch 사용

출처 : http://www.sybase.co.kr/

(0) (0)

Posted by 좐군

추가자료 다운로드 : 

LFM.pdf

(0) (0)

Posted by 좐군

최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고, 의사결정에 활용하는 과정

(0) (0)

Posted by 좐군