티스토리 뷰

 

Power BI 보고서 작성시 피해야 할 5가지

 

Power BI MVP인 Reza의 글과 제 생각을 정리해보았습니다. 자세한 정보는 여기에서 확인할 수 있습니다.  

 

1. 모든 관계의 교차필터 양방향 지정

보고서를 작성시 관계는 아주 중요한 요소중의 하나입니다. 관계가 설정되어 있지 않거나 잘못 설정되어 있는 경우 데이터는 제대로 표시되지 않습니다.

 

하지만 현업실무자에게 관계를 이해시키기는 어렵습니다. 그래서 데이터를 잘 알고 있는 실무자들에게는 관계 설정 창에서 데이터를 보여주면서 진행합니다.

간혹 이상하여 보고서를 살펴보면 관계 설정 창에서 ‘크로스필터’ 방향이 있는데 이를 ‘모두’(양방향)으로 설정하는 경우가 있습니다. 일반적인 상황이 아닌 특정 상황에서 필요한 내용인데 실수로 설정한 경우가 많거나 잠깐 설정했다 잊어버린 경우도 있습니다.

모든 관계의 교차필터 방향을 양방향으로 지정하게 되면 성능 저하, 모델과 관계에서 모호성 증가하는 문제가 발생합니다.

 

그래서 스타스키마 모델링, 교차필터를 단방향으로 설정하는 것이 일반적이며, 교차필터를 설정하는 경우 제대로 알고 설정해야 하며, 설정한 후 시각화 데이터를 검증해야 합니다!

관계 설정과 교차필터 방향에 대한 내용은 여기에서 확인할 수 있습니다.

 

2. 변환없이 데이터 로드(스타스키마 모델 미구성)

 Power BI에서 다양한 데이터 원본을 연결 가능합니다. 어떤 기업에서는 데이터웨어하우스 없이 직접 정규화된 데이터베이스를 연결합니다. 직접 정규화된 테이블을 로드하게 되면 수많은 테이블이 로드되어 복잡해지며, 교차필터 양뱡향이 등장되기도 하고 성능이 저하될 수 있습니다.

추가로 모든 데이터를 하나의 플랫 테이블이나 Excel 파일로 묶어서 관리하는 방법도 문제가 아주 많습니다.

시각화를 보다 더 원활하게 하려면 데이터웨어하우스를 구축하는 것이 효과적입니다. 스타스키마또는 별모양 스키마 (Star schema) 또는 눈송이 스키마(Snow-flake schema) 형태의 차원과 팩트 테이블을 구성한 후 Power BI에서 데이터웨어하우스를 접근하도록 합니다.

데이터웨어하우스를 구축하는 것이 어렵다면 변환에서 병합 등을 통해 차원과 팩트 테이블을 구성하여 모델링을 진행해야 합니다.

 

 

스타스키마에 대한 내용은 여기에서 확인할 수 있습니다.

 

3. 데이터 변환 대신 DAX

데이터 변환으로 간단히 해결 가능한 부분을 DAX 표현식으로 엄청난 작업을 수행하는 보고서를 본 적이 있습니다. 거기다 원본 Excel 파일을 직접 수정하여 매번 수작업을 진행하기도 합니다. 대표적인 예가 피벗해제에 대한 부분입니다.

데이터 변환에서는 필터, 행 그룹화, 데이터 형식, 사용자 지정 열 등 다양한 쿼리 작업을 지원해주며 사용자 지정 함수, 파일 결합, 쿼리 병합/추가를 지원합니다.

데이터 변환의 M 언어와 DAX 수식은 실행하는 단계가 상이하며 사용처가 다른 것이라 각각 필요한 곳에 사용되어야 합니다. ‘우리 기업은 데이터 변환보다는 DAX를 위주로 씁니다’라는 회사에는 사실 프로젝트 하러 가기 싫어집니다.

쿼리 작업에 대한 내용은 여기에서 확인할 수 있습니다.

 

4. DAX 측정값 과도한 사용

DAX의 측정값은 아주 훌륭합니다. 대표적인 측정값의 예는 집계, 백분율, 상위 N, 전월대비 변화, 월누적 등이 있습니다. 수식을 직접 작업하지 않아도 Power BI Desktop에서는 백분율, 상위 N, 빠른 측정값을 제공하고 있습니다. DAX를 적용하려면 어떤 데이터를 어떻게 표시할지 스토리보드를 구성해야 합니다. 본인이 어떻게 표시할지도 모르면서 DAX를 적용해야 한다고 하니 안타깝기만 합니다. 그래서 어떤 기업의 담당자는 단순 열 분할, 열 병합 작업 등등 DAX로 수행합니다. 시간차원도 DAX 수식을 통해 매번 작업합니다. 사실 왜 그렇게 해야 하는지는 아직도 이해가 안됩니다.

DAX를 과도하게 사용하면 보고서에서 필터나 탐색하는 속도가 느리며 메모리 소비가 늘어나게 됩니다.

 

스토리보드를 통해 필요하다면 데이터웨어하우스에 작업해두거나 데이터 변환에서 작업할 수 있습니다. DAX는 DAX 나름대로 필요한 사항에 쓰는거죠. 이전 글을 참고할 수 있습니다.

여기를 살펴보면 칼 그림이 나옵니다. 셰프가 쓰임새에 따라 적절한 칼을 사용하는 것처럼, 스토리보드와 요구사항에 따라 적절하게 DAX나 M 언어를 사용하면 됩니다.

 

5. 재사용하지 않는 문제

재사용에 대한 문제는 일반적인 코딩과 유사하다고 볼 수 있습니다. 재사용하지 않고 복사하거나 새로 생성하게 되면 유지관리에 문제가 발생합니다.

대표적인 예가 시간 차원입니다. 각각의 Power BI Desktop의 M 언어나 DAX를 통해 시간 차원 테이블을 관리하는 것은 아주 비효율적입니다. 데이터웨어하우스에 회계연도와 년도 관련 시간 차원 테이블을 생성하면 됩니다.

 

공통적인 테이블, 측정값, 변환을 Power BI의 데이터 흐름과 데이터 세트로 생성하고 Power BI Desktop에서 연결하여 재사용할 수 있습니다.

 

 

간략히 보고서 작성시 피해야할 내용을 정리해보았습니다.

 

댓글