성공적인 LuckyTemplates 구현을 위한 팁

LuckyTemplates 프로젝트 계획 및 구현에 대한 시리즈를 계속하겠습니다. 이번에는 데이터 세트 설계 , 프로파일링 및 모드 에 대해 논의할 것입니다 . 배포 모드를 다루는 프로젝트 계획 시리즈의 첫 번째 부분 과 검색 및 수집 에 대해 설명하는 두 번째 부분을 확인하십시오 .

목차

• LuckyTemplates 프로젝트 구현을 위한 데이터 세트 설계
  • 데이터세트 설계를 위한 4단계
  • 비즈니스 프로세스를 선택합니다.
    • LuckyTemplates 구현에서 피해야 할 안티 패턴
  • 곡물을 선언하십시오.
  • 치수를 식별합니다.
  • 사실을 정의하십시오.
• LuckyTemplates 프로젝트 구현을 위한 데이터 버스 매트릭스
• LuckyTemplates 구현을 위한 데이터 프로파일링
  • SQL 서버 통합 서비스
  • 닥스 스튜디오
  • 파워 BI 데스크탑
• LuckyTemplates 구현을 위한 데이터 세트 계획
  • 데이터 세트 모드 선택
  • 데이터 세트 모드를 선택할 때 물어볼 몇 가지 질문
• 결론

LuckyTemplates 프로젝트 구현을 위한 데이터 세트 설계

데이터 세트 설계 프로세스 에 대해 이야기 하고 한동안 사용된 도구인 데이터 웨어하우스 버스 매트릭스에 대해 논의해 봅시다.

LuckyTemplates 데이터 세트 설계는 데이터 웨어하우스 설계와 유사합니다. 따라서 데이터 세트와 데이터 웨어하우스 모두 팩트 및 차원 테이블, 스타 스키마, 느리게 변경되는 차원, 팩트 테이블 세분성 및 테이블 간의 관계 구축을 위한 로컬 정보 키와 같은 유사한 개념을 가지고 있습니다.

데이터세트 설계를 위한 4단계

데이터 세트 설계 프로세스에는 비즈니스 프로세스 선택 , 팩트 테이블의 그레인 선언 , 차원 식별 , 팩트 정의의 네 가지 단계가 있습니다 .

비즈니스 프로세스를 선택합니다.

첫 번째 단계에서 각 비즈니스 프로세스는 차원에 대한 다대일 관계 의 스타 스키마가 있는 팩트 테이블로 표시됩니다 .

검색 또는 요구 사항 수집 프로세스 중에 사용자가 여러 비즈니스 프로세스를 동시에 정기적으로 분석하기 때문에 단일 비즈니스 프로세스에 집중하기가 어렵습니다.

LuckyTemplates 구현에서 피해야 할 안티 패턴

LuckyTemplates 프로젝트에서 피하려는 일반적인 안티 패턴 (일반적으로 비효율적이고 잠재적으로 비생산적인 재발 문제에 대한 응답) 은 비즈니스 프로세스가 아닌 특정 프로젝트 또는 팀을 위한 데이터 세트 개발 입니다 .

예를 들어 마케팅 팀 전용 데이터 세트와 영업 조직용 데이터 세트를 개발합니다. 이 접근 방식은 동일한 판매 데이터가 두 데이터 세트에서 두 번 쿼리되고 새로 고쳐지기 때문에 자연스럽게 리소스 낭비로 이어집니다. 또한 LuckyTemplates 서비스의 저장소 리소스를 사용합니다.

이것이 데이터 세트 설계를 위한 좋은 프로세스를 거쳐야 하는 몇 가지 이유입니다. 데이터 세트에 변형 및 변환이 포함될 수 있으므로 격리된 접근 방식은 관리 용이성 및 버전 제어 문제로 이어집니다.

사용자 또는 팀의 분석 요구 사항이 LuckyTemplates 프로젝트의 우선 순위이지만 궁극적으로 팀 간에 공유할 수 있는 지속 가능한 솔루션을 계획하는 것도 중요합니다.

곡물을 선언하십시오.

그레인 오브 팩트 테이블은 궁극적으로 분석 쿼리에 사용할 수 있는 세부 수준과 액세스할 수 있는 데이터의 양을 다룹니다.

따라서 높은 그레인은 더 많은 디테일을 의미하고 낮은 그레인은 덜 디테일함을 의미합니다. 이에 대한 예는 판매 주문 라인 수준을 가져오려는 경우 또는 프로젝트에 각 판매 주문의 요약 수준만 포함하고 해당 판매의 일부로 주문된 특정 제품에 도달하지 않도록 하려는 경우입니다.

경우에 따라 이 곡물은 기간에 따라 달라질 수 있습니다. 현재 분기에 대한 매우 세분화된 팩트 테이블을 원하는 많은 고객을 만났지만 이전 분기에 대해서는 해당 분기의 총 매출이 얼마인지 알아야 했습니다.

이 단계에서 서로 다른 비즈니스 프로세스의 각 행이 무엇을 나타내는지 결정하려고 합니다 . 예를 들어 데이터 웨어하우스의 판매 팩트 테이블의 각 행은 고객의 판매 주문 라인을 나타냅니다.

반대로 판매 및 마진 계획의 행은 달력 월, 제품 하위 범주 및 판매 지역에서 집계됩니다. 따라서 이 경우 두 개의 다른 팩트 테이블과 두 개의 다른 곡물이 있습니다. 두 가지를 비교하려면 일부 데이터 모델링 작업이 필요합니다.

치수를 식별합니다.

치수는 이전 디자인 단계에서 선택한 곡물의 자연스러운 부산물입니다.

따라서 팩트 테이블의 단일 샘플 행은 개별 프로젝트를 구매한 고객, 특정 날짜 및 특정 시간의 제품과 같이 주어진 프로세스와 관련된 비즈니스 엔터티의 차원을 명확하게 나타내야 합니다. 더 낮은 입자를 나타내는 팩트 테이블은 더 적은 차원을 가집니다.

예를 들어, 구매 주문서의 헤더 수준을 나타내는 팩트 테이블은 공급업체를 식별할 수 있지만 공급업체로부터의 개별 제품 구매는 식별할 수 없습니다. 따라서 이 경우 제품 범주 또는 제품 하위 범주 차원을 포함할 필요가 없습니다.

사실을 정의하십시오.

팩트는 팩트 테이블에 포함된 숫자 열을 나타냅니다. 따라서 3단계의 차원 열은 관계에 사용되는 반면 팩트 열은 수량 열의 합계 또는 가격 열의 평균과 같은 집계 논리를 포함하는 측정값에 사용됩니다.

LuckyTemplates 프로젝트 구현을 위한 데이터 버스 매트릭스

데이터 웨어하우스 버스 매트릭스는 Ralph Kimball 데이터 웨어하우스 아키텍처의 필수 요소로, 데이터 웨어하우스 설계에 점진적이고 통합된 접근 방식을 제공합니다.

여기에 표시되는 아키텍처는 Ralph Kimball의 3판인 The Data Warehouse Toolkit 에서 가져온 것입니다. 여러 비즈니스 팀 또는 기능이 동일한 비즈니스 프로세스 및 차원에 액세스하는 데 종종 필요한 확장 가능한 데이터 모델을 허용합니다.

데이터 웨어하우스 버스 매트릭스를 유지하는 것이 유용합니다. 작성하면 유사한 인터넷 팩트 테이블 및 차원 테이블을 포함하는 다른 데이터 세트가 있는지 알 수 있습니다. 이는 프로젝트의 재사용성을 촉진하고 프로젝트 커뮤니케이션을 개선합니다.

따라서 각 행은 총계정원장의 월별 마감과 같이 중요하고 반복되는 비즈니스 프로세스를 반영합니다. 각 열은 하나 이상의 비즈니스 프로세스와 관련될 수 있는 비즈니스 엔터티를 나타내며 음영 처리된 행은 프로젝트 내에 포함되는 비즈니스 프로세스를 나타냅니다.

LuckyTemplates 구현을 위한 데이터 프로파일링

그레인을 식별하고 4단계 데이터 세트 설계 프로세스가 완료되면 팩트 및 차원 테이블의 소스 데이터에 대한 기술 분석이 즉시 이어져야 합니다 .

데이터베이스 다이어그램 및 데이터 프로파일링 결과를 포함한 기술 메타데이터는 프로젝트 계획 단계에 필수적입니다.

이 정보는 LuckyTemplates 데이터 세트가 의도한 비즈니스 정의를 반영하고 건전하고 신뢰할 수 있는 소스를 기반으로 구축되었는지 확인하는 데 사용됩니다.

따라서 세 가지는 프로파일링 정보를 수집하는 세 가지 다른 방법입니다. 이는 사람들이 디자인 프로세스에서 나오면 가장 먼저 수행해야 하는 단계입니다.

SQL 서버 통합 서비스

이에 대해 몇 가지 방법이 있습니다. 한 가지 방법은 SSIS( SQL Server Integration Services ) 패키지 내에서 데이터 프로파일링 작업을 사용하는 것입니다 .

데이터 프로파일링 작업에는 ADO.NET 연결이 필요하며 해당 출력을 XML 파일 또는 SSIS 변수에 쓸 수 있습니다.

이 예에서 ADO.NET 원본 데이터는 AdventureWorks 데이터 웨어하우스, 데이터베이스 및 SQL 서버이고 대상은 XML 파일입니다.

따라서 작업이 실행되면 SQL 서버 데이터 프로필 뷰어를 통해 XML 파일을 읽을 수 있습니다. null 개수 및 null 개수 백분율로 결과를 볼 수 있습니다.

닥스 스튜디오

데이터 프로파일링의 또 다른 방법은 DAX Studio를 사용하는 것입니다. 실제로 DAX Studio로 이동하고 고급 탭으로 이동한 다음 VertiPaq Analyzer를 실행하여 데이터를 LuckyTemplates 데이터 세트로 수집해야 합니다 .

열의 카디널리티에 대한 동일한 종류의 정보를 표시하므로 데이터 모델에서 가장 많은 공간을 차지하는 열을 알 수 있습니다. 여기에는 데이터 주변의 모든 다양한 통계가 포함됩니다.

파워 BI 데스크탑

데이터 프로파일링은 LuckyTemplates Desktop 내의 파워 쿼리에서도 사용할 수 있습니다. 보기 탭 으로 이동하면 열 품질, 열 분포 및 열 프로필과 같은 항목을 켤 수 있습니다. 적어도 처음 1,000개 행 정도에 대해 오류, null, 평균 및 표준 편차와 같은 정보를 볼 수 있습니다.

LuckyTemplates 구현을 위한 데이터 세트 계획

소스 데이터가 4단계 데이터 세트 디자인 프로세스에서 식별된 요구 사항에 대해 프로파일링되고 평가된 후 BI 팀은 데이터 세트에 대한 구현 옵션을 추가로 분석할 수 있습니다.

거의 모든 LuckyTemplates 프로젝트에서 엔터프라이즈 데이터, 웨어하우스, 아키텍처, ETL 도구 및 프로세스에 상당한 투자를 한 경우에도 소스 데이터의 품질과 가치를 향상시키기 위해 일정 수준의 추가 논리, 통합 또는 변환이 필요합니다.

데이터 세트 계획 단계에서는 데이터 세트를 지원하기 위해 식별된 데이터 변환 문제를 해결하는 방법을 결정합니다. 또한 프로젝트 팀은 가져오기 모드 데이터 세트 , 직접 쿼리 데이터 세트 또는 복합 데이터 세트를 개발할지 여부를 결정해야 합니다 .

데이터 세트 계획 프로세스를 명확히 하기 위해 이 다이어그램은 변환 및 비즈니스 논리를 구현할 수 있는 데이터 웨어하우스 및 LuckyTemplates 데이터 세트의 다양한 계층을 식별합니다.

일부 프로젝트에서는 최소한의 변환이 필요하며 LuckyTemplates 데이터 세트에 쉽게 포함될 수 있습니다. 예를 들어 차원 테이블에 몇 개의 추가 열만 필요하고 이러한 열을 계산하는 방법에 대한 간단한 지침이 있는 경우 IT 조직은 데이터 웨어하우스를 수정하는 대신 M 파워 쿼리 내에서 이러한 변환을 구현하도록 선택할 수 있습니다.

BI 요구 사항과 회사 데이터 웨어하우스 간의 상당한 격차가 지속되도록 허용되는 경우 LuckyTemplates 데이터 세트를 구축하고 유지 관리하기가 더 복잡해집니다.

데이터 세트 설계자는 더 높은 수준의 복잡성이 있는 경우 데이터 세트의 의미를 정기적으로 분석하고 전달해야 합니다.

그러나 필요한 변환 논리가 여러 공동 작업, 행 필터 및 데이터 유형 변경으로 인해 복잡하거나 광범위할 경우 IT 조직은 새로운 데이터 세트 및 향후 BI 프로젝트를 지원하기 위해 데이터 웨어하우스에서 필수 변경 사항을 구현하도록 선택할 수 있습니다.

예를 들어 프로세스를 지원, 수정 및 업데이트하기 위해 스테이징 테이블 및 SQL 저장 프로시저가 필요할 수 있습니다. 또는 DirectQuery 데이터 세트의 쿼리 성능을 개선하기 위해 인덱스 생성이 필요할 수 있습니다.

데이터 세트 모드 선택

데이터 세트 계획과 밀접한 관련이 있는 후속 단계는 기본 가져오기 모드, DirectQuery/라이브 모드 또는 복합 모드 중에서 선택하는 것입니다.

일부 프로젝트에서는 알려진 요구 사항을 고려할 때 단 하나의 옵션만 실행 가능하거나 현실적인 간단한 결정인 반면, 다른 프로젝트에서는 각 설계의 장단점에 대한 중요한 분석이 수반됩니다.

따라서 데이터 소스가 느리거나 많은 양의 분석 쿼리를 처리할 수 있는 장비가 부족한 것으로 간주되는 경우 가져오기 모드 데이터 세트가 선호되는 옵션일 가능성이 큽니다.

마찬가지로 데이터 원본의 거의 실시간 가시성이 필수적인 경우 DirectQuery 또는 라이브 모드가 이를 달성할 수 있는 유일한 옵션입니다. DirectQuery와 라이브 모드는 서로 매우 유사합니다. 두 방법 모두 데이터 세트 자체에 데이터를 저장하지 않으며 둘 다 소스 시스템을 직접 쿼리하여 사용자 작업을 기반으로 데이터를 검색합니다. 이제 LuckyTemplates 데이터 세트용 DirectQuery와 Analysis Services용 DirectQuery가 있습니다.

데이터 세트 모드를 선택할 때 물어볼 몇 가지 질문

다음은 사용할 모드를 결정할 때 묻는 몇 가지 질문입니다. 데이터 세트에 대한 단일 소스가 있습니까? 단일 소스가 없으면 과거에 DirectQuery/라이브 소스를 사용할 수 없었습니다.

이제 복합 모드 데이터 세트가 있지만 단일 소스가 없으면 가져오기 또는 복합이 되기 때문에 처음부터 물어보는 것이 여전히 좋은 질문입니다.

DirectQuery/라이브 소스가 옵션인 경우 소스가 분석 쿼리를 지원할 수 있습니까? 수십억 또는 수조 개의 행으로 작업하는 경우 가져오기 모드 데이터 세트가 적합하지 않을 수 있으며 DirectQuery 또는 복합 모드로 이동하여 데이터 세트를 사용할 수 있는지 확인해야 합니다.

DirectQuery/Live 소스가 워크로드를 지원할 수 있는 경우 DirectQuery/Live 연결이 가져오기 모델에서 제공하는 성능 및 유연성보다 더 가치가 있습니까?

결론

이 게시물은 LuckyTemplates 프로젝트 계획에 대한 이 시리즈를 마무리합니다. 작업하는 모든 LuckyTemplates 프로젝트의 필수 단계라고 생각합니다. 이러한 단계는 특히 엔터프라이즈 비즈니스 인텔리전스 설정에서 실사를 수행할 때 중요합니다.

모두 제일 좋다,

그렉 데클러