데이터 웨어하우스 개발의 세 가지 원칙

Gartner는 새로 시작된 비즈니스 인텔리전스 프로젝트의 70~80%가 실패하는 것으로 추정합니다. 이는 잘못된 도구 선택부터 IT와 비즈니스 이해 관계자 간의 의사 소통 부족에 이르기까지 수많은 이유 때문입니다. 산업 전반에 걸쳐 BI 프로젝트를 성공적으로 구현한 저는 이 블로그 게시물에서 제 경험을 공유하고 비즈니스 인텔리전스 프로젝트가 실패하는 주요 이유를 강조하고자 합니다. 이 기사에서는 데이터 웨어하우스를 구축하는 방법을 제어해야 하는 세 가지 원칙을 기반으로 실패에 대한 대응책을 제시합니다. 이러한 데이터 웨어하우스 개념을 따르면 데이터 웨어하우스 개발자가 BI 구현의 일반적인 움푹 들어간 곳이나 싱크홀을 피하는 개발 여정을 탐색하는 데 도움이 됩니다.

비즈니스 인텔리전스 데이터 웨어하우스 구현

성공적인 비즈니스 인텔리전스 데이터 웨어하우스의 기준은 프로젝트에 따라 다르지만 모든 프로젝트에서 특정 최소값이 예상되고 요구됩니다. 다음은 성공적인 비즈니스 인텔리전스 데이터 웨어하우스에서 일반적으로 발견되는 주요 속성 목록입니다.

• 가치: 비즈니스 인텔리전스 프로젝트는 수개월 또는 수년에 걸쳐 진행될 수 있습니다. 그러나 지속적인 자금 조달과 관심을 보장하기 위해 프로젝트 초기에 비즈니스 이해 관계자에게 데이터 웨어하우스의 이점을 보여주는 것이 중요합니다. 이상적으로는 이해 관계자가 프로젝트의 처음 3주 이내에 새 시스템에서 의미 있는 비즈니스 가치를 보여주어야 합니다.
• 셀프 서비스 BI: IT가 데이터 요청을 이행하거나 데이터 분석을 수행하기를 기다리던 시대는 끝났습니다. 이제 모든 BI 프로젝트의 성공은 비즈니스 사용자가 시스템에서 스스로 가치를 추출할 수 있는 권한을 얼마나 잘 부여하느냐에 따라 측정됩니다.
• 비용: BI 프로젝트는 일반적으로 초기 구현 비용이 비교적 높습니다. 높은 초기 비용을 상쇄하고 상쇄하려면 낮은 유지 관리 비용으로 창고를 설계하는 것이 중요합니다. 클라이언트가 데이터 품질 문제를 보장/진단하고, 데이터 모델을 일상적으로 변경하거나, ETL 오류를 처리하기 위해 BI 개발자로 구성된 완전한 팀이 필요한 경우 시스템은 예산에 많은 비용을 들이고 일정 시간이 지나면 꺼질 위험이 있습니다. .
• 적응성: 진화하는 비즈니스 요구에 적응하는 능력은 매우 중요합니다. 시장에서 사용할 수 있는 수많은 BI 도구와 추가 기능 및 기능을 포함하도록 발전하는 속도를 염두에 두는 것이 중요합니다. 비즈니스가 지속적으로 진화한다는 사실과 함께 창고에 대한 요구 사항도 변경됩니다. 적응성을 위해서는 데이터 웨어하우스가 미래에 다른 백엔드 또는 시각화 도구와 같은 대체 BI 도구를 사용할 수 있도록 설계되어야 하고 종종 예측하지 못한 요구 사항의 변화에 ​​적응할 수 있어야 합니다.

성공적인 솔루션을 구축하고 아마도 더 중요한 것은 실패한 프로젝트에 참여하는 경험을 통해 저는 세 가지 핵심 원칙이 성공적인 비즈니스 인텔리전스 시스템 구현의 가능성을 높이는 데 가장 중요하다는 결론에 도달했습니다. 그러나 자세히 다루기 전에 몇 가지 컨텍스트부터 시작하겠습니다.

데이터 웨어하우스란 무엇입니까?

다양한 데이터 웨어하우스 개념을 살펴보기 전에 데이터 웨어하우스가 실제로 무엇인지 이해하는 것이 중요합니다.

데이터 웨어하우스는 종종 비즈니스 엔터티의 일상적인 보고 요구 사항을 지원하기 위해 만들어진 비즈니스 인텔리전스 시스템으로 생각됩니다. 표준 구현에서 OLTP 데이터 시스템과 동일한 실시간 성능 요구 사항이 없으며 OLTP 시스템에는 비즈니스의 작은 하위 집합과 관련된 데이터만 포함되지만 데이터 웨어하우스 는 사업 .

데이터 웨어하우스 모델은 웨어하우스가 운영 보고서를 생성하는 도구가 아니라 "모든 데이터"의 중심 허브로 간주될 때만 비즈니스에 이점을 제공합니다. 모든 운영 시스템은 데이터 웨어하우스와 양방향 통신을 통해 데이터를 공급하고 운영 효율성을 개선하는 방법에 대한 피드백을 받아야 합니다. 가격 인상 또는 공급/재고 감소와 같은 모든 비즈니스 변화는 데이터 웨어하우스 환경 내에서 먼저 프로토타입을 만들고 예측해야 비즈니스가 결과를 안정적으로 예측하고 수량화할 수 있습니다. 이러한 맥락에서 모든 데이터 과학 및 데이터 분석 기능은 데이터 웨어하우스를 중심으로 합니다.

데이터 웨어하우스에는 많은 구성 요소가 있으며 단순한 데이터베이스가 아닙니다.

• 데이터베이스 는 데이터를 저장하는 매체입니다.
• 데이터 웨어하우스 는 그 이상으로 데이터에서 비즈니스 가치를 추출하는 데 필요한 도구와 구성 요소를 포함하며 통합 파이프라인, 데이터 품질 프레임워크, 시각화 도구 및 기계 학습 플러그인과 같은 구성 요소를 포함할 수 있습니다.

다음은 데이터베이스와 데이터베이스 웨어하우스 구조 간의 차이점을 보다 시각적으로 표현한 것입니다. 데이터베이스 또는 Hive와 같은 새로운 논리적 데이터 메타 저장소는 회전하는 행성으로 다른 모든 구성 요소와 함께 데이터 웨어하우스의 별 시스템에 대한 중심 별을 형성합니다. 그러나 스타 시스템과 달리 데이터 웨어하우스는 하나 이상의 데이터베이스를 가질 수 있으며 이러한 데이터베이스는 이 기사의 뒷부분에서 논의할 것처럼 새로운 기술과 상호 교환할 수 있어야 합니다.

첫 번째 데이터 웨어하우스 원칙: 데이터 품질이 최우선

데이터 웨어하우스는 비즈니스 이해 관계자가 내부 데이터를 신뢰할 수 있을 때만 유용하고 가치가 있습니다. 이를 보장하기 위해 가능한 경우 데이터 품질 문제를 자동으로 캡처하고 수정하는 프레임워크를 구축해야 합니다. 데이터 정리는 데이터 문제를 식별하기 위해 정기적인 데이터 감사 또는 데이터 프로파일링이 수행되는 데이터 통합 ​​프로세스의 일부여야 합니다. 이러한 사전 조치가 구현되는 동안 잘못된 데이터가 이러한 게이트를 빠져나가고 사용자가 보고하는 경우 사후 조치도 고려해야 합니다.

데이터 웨어하우스 시스템에 대한 사용자의 신뢰를 보장하려면 비즈니스 사용자가 강조한 잘못된 데이터를 우선적으로 조사해야 합니다. 이러한 노력을 돕기 위해 데이터 계보 및 데이터 제어 프레임워크를 플랫폼에 구축하여 지원 직원이 모든 데이터 문제를 신속하게 식별하고 수정할 수 있도록 해야 합니다. 대부분의 데이터 통합 ​​플랫폼은 MS SQL Server의 DQS 또는 Informatica의 IDQ와 같은 어느 정도의 데이터 품질 솔루션을 통합합니다.

데이터 통합 ​​파이프라인에서 상용 도구를 사용하는 경우 이러한 기본 제공 플랫폼을 활용하되 추가적으로 또는 기타 방법으로 데이터 품질을 유지하는 데 도움이 되는 메커니즘을 구축해야 합니다. 예를 들어, 대부분의 데이터 통합 ​​도구에는 데이터 계보를 추적하는 좋은 기능이 없습니다. 이러한 한계를 극복하기 위해 시스템 내에서 발생하는 모든 데이터 흐름을 추적하는 일련의 제어 테이블을 사용하여 사용자 지정 배치 제어 프레임워크를 구축할 수 있습니다.

플랫폼 내에서 품질이 좋지 않은 경우 비즈니스 이해 관계자의 신뢰를 회복하는 것은 매우 어렵기 때문에 데이터 품질 프레임워크에 대한 선행 투자는 그만한 가치가 있습니다.

두 번째 데이터 웨어하우스 원칙: 삼각형 뒤집기

이 그림은 대부분의 데이터 웨어하우스의 구현 및 사용에 대한 노력의 분담을 보여줍니다.

대부분의 노력은 웨어하우스를 구축하고 유지 관리하는 데 투자되지만 비즈니스 분석을 위한 웨어하우스의 부가가치는 노력의 훨씬 작은 부분입니다. 이것이 비즈니스 인텔리전스 프로젝트가 자주 실패하는 또 다른 이유입니다. 때로는 프로젝트 주기에서 클라이언트에게 의미 있는 가치를 표시하는 데 너무 오랜 시간이 걸리며, 시스템이 마침내 제자리에 배치되었을 때 시스템에서 비즈니스 가치를 얻으려면 여전히 많은 IT 노력이 필요합니다. 도입부에서 말했듯이 비즈니스 인텔리전스 시스템을 설계하고 배포하는 것은 비용이 많이 들고 시간이 오래 걸리는 프로세스입니다. 따라서 이해 관계자는 비즈니스 인텔리전스 및 데이터 웨어하우징 노력으로 추가된 가치를 신속하게 거두기 시작할 것으로 예상할 것입니다. 부가가치가 실현되지 않거나 결과가 너무 늦어 실제 가치를 얻을 수 없는 경우 플러그를 뽑는 것을 막을 방법이 많지 않습니다.

데이터 웨어하우스 개발의 두 번째 원칙은 여기에 설명된 것처럼 삼각형을 뒤집는 것입니다.

선택하는 비즈니스 인텔리전스 도구와 프레임워크는 창고에 투입되는 노력의 상당 부분이 비즈니스 가치를 구축 및 유지 관리하는 것보다 추출하는 것임을 확인해야 합니다. 이렇게 하면 비즈니스 이해 관계자가 프로젝트에 투자하는 가치를 즉시 확인할 수 있으므로 높은 수준의 참여를 보장할 수 있습니다. 더 중요한 것은 IT에 대한 강한 의존 없이 비즈니스가 가치를 추출하는 데 있어 자급자족할 수 있다는 것입니다.

가능한 한 빨리 생산 기능을 제공할 수 있도록 웨어하우스를 구축할 때 증분 개발 방법론을 따르면 이 원칙을 준수할 수 있습니다. Kimball의 데이터 마트 전략 또는 Linstedt의 Data Vault 데이터 웨어하우스 설계 방법론을 따르면 변경 사항을 원활하게 고려하면서 점진적으로 구축하는 시스템을 개발하는 데 도움이 됩니다. MS SSAS 큐브 또는 Business Objects Universe와 같은 플랫폼의 의미 계층을 사용하여 데이터에 대한 이해하기 쉬운 비즈니스 인터페이스를 제공하십시오. 전자의 경우 사용자가 여전히 가장 널리 사용되는 데이터 분석 도구인 Excel에서 데이터를 쿼리할 수 있는 쉬운 메커니즘도 제공합니다.

Tableau 또는 PowerBI와 같은 셀프 서비스 BI를 지원하는 BI 도구를 통합하는 것은 사용자 참여를 향상시키는 데 도움이 될 것입니다. 이제 SQL을 작성하는 것과 달리 쿼리 데이터에 대한 인터페이스가 대폭 간소화되기 때문입니다.

데이터베이스를 채우기 전에 데이터 레이크 에 소스 데이터를 저장하면 온보딩 프로세스 초기에 사용자에게 소스 데이터를 노출하는 데 도움이 됩니다. 비즈니스 퀀트와 같은 고급 사용자는 이제 파일 위에 Hive/Impala와 같은 도구를 연결하여 원시 파일을 통해 소스 데이터를 요약할 수 있습니다. 이는 기업이 새로운 데이터 포인트를 분석하는 데 필요한 시간을 몇 주에서 며칠 또는 몇 시간으로 줄이는 데 도움이 됩니다.

세 번째 데이터베이스 웨어하우스 원칙: 플러그 앤 플레이

데이터는 석유의 디지털 등가물이 되기 직전입니다. 최근 몇 년 동안 데이터 웨어하우스 플랫폼의 일부로 사용할 수 있는 도구의 수와 혁신 속도가 폭발적으로 증가하는 것을 목격했습니다. 백 엔드에 대한 고급 옵션과 함께 현재 사용할 수 있는 무수한 시각화 도구가 이러한 변화를 주도하고 있습니다. 이러한 환경과 비즈니스 요구 사항이 지속적으로 변경되는 경향을 감안할 때 비즈니스 및 기술 변화에 따라 기술 스택의 구성 요소를 교체하거나 시간이 지남에 따라 다른 구성 요소를 도입/제거해야 한다는 점을 염두에 두는 것이 중요합니다.

개인적인 경험에 비추어 볼 때 플랫폼이 큰 변화 없이 12개월 동안 지속될 수 있다면 다행일 것입니다. 이러한 상황에서는 상당한 노력이 불가피합니다. 그러나 항상 기술이나 디자인을 변경할 수 있어야 하며 플랫폼은 이러한 궁극적인 필요를 충족하도록 설계되어야 합니다. 웨어하우스의 마이그레이션 비용이 너무 높으면 비즈니스는 비용이 정당하지 않다고 판단하고 기존 솔루션을 새 도구로 마이그레이션하는 대신 구축한 것을 포기할 수 있습니다.

상상할 수 있는 모든 미래의 요구를 충족시키는 시스템을 구축하는 것은 불가능합니다. 따라서 데이터 웨어하우스를 구축할 때는 지금 설계하고 구축하는 것이 무엇이든 시간이 지나면 대체될 수 있다는 어느 정도의 인식이 필요합니다. 이를 위해 플랫폼을 실행 중인 도구에 밀접하게 연결하기보다 가능한 경우 일반 도구 및 디자인의 사용을 옹호합니다. 물론 많은 도구, 특히 데이터베이스의 힘은 개별성과 긴밀한 보완에 있기 때문에 신중한 계획과 고려 후에 수행해야 합니다.

예를 들어, ETL 성능은 Python 또는 SSIS를 사용하여 데이터베이스 외부에서 데이터를 추출 및 처리하는 것과 대조적으로 데이터베이스의 저장 프로시저를 사용하여 새로운 비즈니스 분석 데이터를 생성할 때 크게 향상됩니다. 보고 계층과 관련하여 시각화 도구는 다른 도구에서는 쉽게 사용할 수 없는 특정 기능을 제공합니다. 예를 들어 Power BI는 사용자 지정 MDX 쿼리를 지원하지만 Tableau는 지원하지 않습니다. 내 요점은 저장 프로시저를 포기하거나 시스템에서 SSAS 큐브 또는 Tableau를 사용하지 않는 것을 옹호하려는 것이 아닙니다. 내 의도는 플랫폼을 해당 도구에 긴밀하게 연결하기 위해 모든 결정을 정당화할 때 주의를 기울이는 것의 중요성을 홍보하는 것입니다.

또 다른 잠재적인 싱크홀은 통합 레이어에 있습니다. 디버그 기능이나 SQL Server 플랫폼과의 사용 용이성 때문에 데이터 통합을 위해 SSIS와 같은 도구를 사용하는 것은 매우 쉽습니다. 그러나 수백 개의 SSIS 패키지를 다른 도구로 마이그레이션하는 것은 매우 비용이 많이 드는 프로젝트가 될 것입니다. 주로 "EL"을 수행하는 경우 일반 도구를 사용하여 처리하십시오. Python 또는 Java와 같은 프로그래밍 언어를 사용하여 하나의 일반 로더를 작성하여 스테이징 계층을 로드하면 그렇지 않으면 필요했을 개별 SSIS 패키지를 줄이는 데 도움이 됩니다. 이 접근 방식은 유지 관리 및 향후 마이그레이션 비용을 줄이는 데 도움이 될 뿐만 아니라 새로운 개별 패키지를 작성할 필요 없이 데이터 온보딩 프로세스의 더 많은 측면을 자동화하는 데 도움이 됩니다(원칙 2와 연결).

이러한 모든 경우에 변경을 처리할 수 없거나 변경에 너무 많은 시간이 필요했기 때문에 창고가 폐기되지 않도록 즉각적인 이점과 향후 마이그레이션 비용 사이의 실질적인 절충안을 결정 해야 합니다. 노력이나 투자.

마무리

특정 비즈니스 인텔리전스 시스템이 실패하는 데는 여러 가지 이유가 있으며 결국 실패로 이어질 수 있는 몇 가지 일반적인 실수도 있습니다. 끊임없이 변화하는 기술 환경, 운영 시스템에 대한 잘못된 2차 우선 순위로 인한 데이터 시스템의 제한된 예산, 데이터 작업의 복잡성과 어려움은 설계 및 설계 시 즉각적인 목표뿐만 아니라 미래 계획도 신중하게 고려해야 함을 의미합니다. 데이터 웨어하우스의 구성 요소를 구축합니다.

이 문서에 설명된 데이터 웨어하우징 기본 사항은 이러한 중요한 고려 사항을 안내하는 데 도움이 됩니다. 물론 이러한 원칙을 고려한다고 해서 성공이 보장되는 것은 아니지만 실패를 피하는 데 큰 도움이 될 것입니다.