1

저는 비즈니스의 중요한 부분으로보고되는 거래 플랫폼에서 작업하고 있습니다.데이터베이스 (OLTP) 및보고

설정은 다음과 같습니다. SQL OLTP 데이터베이스 (약 200 개 테이블) - 레코드 수가 적습니다. (2 만 기록은 가장 큰 테이블이지만 매주 계속 증가합니다.) 보고 서비스의 경우 SQL 조회가 라이브 트랜잭션 데이터베이스를 쿼리하는 데 사용됩니다. 데이터웨어 하우스 접근 방식의 관점에서보기의 결과 세트가 비정규 화 된 결과를 상상해보십시오. 그런 다음 이러한 데이터 세트는 타사보고 플랫폼 (Tableau, Power Bi 또는 SiSense와 같은)으로 전달되어 이러한 데이터 세트를 가져 와서 큐브 (아마도 모노 db, hadoop 등과 같은 일부 기둥 구조)에 던집니다. 여기에서 보고서가 생성됩니다.

현재의 문제. SQL 뷰 (약 8). 거대하고 유지하기가 매우 어렵습니다. 예를 들어보기 중 하나는 100 개의 필드를 출력합니다. 그러나 각각의 필드는 복잡한 CASE 문, 중첩 된 IF 문, 인라인 함수 및이 뷰를 700 줄의 SQL 코드만큼 크게 만드는 계산되지 않은 필드로 계산됩니다. 나는 이것들을 다른 사원으로부터 물려 받았다. 지금은 슬프게도, 나는 그들을 유지해야한다. 데이터는 매주 수백 개의 레코드 (마이그레이션 및 트랜잭션을 통해)로 증가하고보기의 필드 수가 증가하므로 (매주 몇 번씩) 큐브 작성 시간이 오래 걸립니다. 예를 들어, 몇 달 전에 우리는 큐브를 10 분 동안 재구성하여 데이터를 새로 고침 (5 분 소요)했습니다. 현재 빌드에 12-15 분이 소요되므로 30 분마다 설정합니다. 당신이 상상할 수 있듯이, 이것은 데이터와 필드의 수가 계속 증가함에 따라 더 나 빠지게 될 것입니다; 가능한 한 최신 데이터를 필요로합니다.

유일한 좋은 점은 일단 큐브가 빌드되면 보고서가 제 3 자 플랫폼에서 끌어 당겨 지므로 보고서가 빨리로드된다는 것입니다. 여기서는 걱정할 필요가 없습니다.

내가 마음 이 무엇인지 나는 maintenanace의 과정을 쉽게하고 또한 최소 큐브 재 구축의 기간을 유지할 수 있도록 뷰를 제거하고 싶습니다.

옵션 :

  1. 는 데이터웨어 하우스를 구축. 그런 다음 SSIS 패키지를 만들어이 구조에 실제 트랜잭션 데이터를 채 웁니다. 정규화되지 않은 구조는 아마도 위에서 언급 한 관점과 매우 유사하게 보일 것입니다. 여기서 다시 생각해 보면 실제로 OLAP에서 OLAP (데이터웨어 하우스)으로의 데이터 마이그레이션이라는 하나 이상의 계층을 추가하는 것만으로도 훨씬 단순화 된 것처럼 느껴지지 않습니다. 그리고 나는 여전히 입방체를 다시 만들어야 할 것입니다.
  2. 현재 뷰를 SQL 인덱스 된 뷰 (구체화 된 뷰)로 전환하기 위해 전체 뷰에서 많이 사용되는 비정규 및 인라인 함수 때문에 현재 상태를 그대로 유지할 수 없습니다.
  3. 또 다른 옵션은 ODS (Operational Data Store - 현재 가지고있는 SQL 뷰와 유사한 테이블을 포함하는 데이터베이스 일 것입니다.)를 작성하는 것입니다. 트리거 또는 트랜잭션을 사용하고있을 수도 있습니다. 로그? 그러나 나는 그러한 것을 만드는 데 무엇이 관련되는지, 그리고 유지하는 것이 얼마나 어려운지 잘 모르겠습니다.

질문 : 어떻게 접근을해야합니까? 위의 3 중 하나라도 의미가 있습니까? 물론 다른 아이디어 나 제안에도 관심이 있습니다.

고맙습니다!

답변

0

내 경험에 의하면 최선의 방법은 1이 될 것입니다. 비용이 많이 들지만 더 나은 혜택을 줄 것입니다. ROLAP DWH를 작성하십시오 (모범 사례 및 디자인 패턴을 위해 Kimball의 "The Data Warehouse Toolkit"을 권장합니다), 열거 형 데이터 저장소 (amazon redshift 또는 sap sybase iq와 같은) 및 모든 case 문, 중첩 된 ifs 언급 한 모든 작업이 ETL 시간에 적용되므로 ROLAP에서 모든 것이 사전 계산되어 소비에 최적화됩니다. 그리고 (당신이 사용하는 의존 기술에 의존하는) 색인을 첨부하는 것에 대해 잊지 마십시오. 일부 데이터베이스 공급 업체는 이미 ROLAP에 "최상의 모범 사례 색인"을 게시 했으므로 테이블 유형 (차원) 및 데이터 형식에 따라 어떤 유형의 인덱스가 도움이되는지 알려줄 것입니다.

+0

안녕 Luis Leal. 당신의 답변에 감사드립니다. 예, 숫자 1이 첫 번째 옵션 이었지만 현재 SiSense의 큐브를 통해 30 분마다 데이터가 새로 고쳐지며 30 분이 지나지 않아 동일하게 유지하려고합니다. 따라서 데이터웨어 하우스를 구축하면 데이터를 새로 고치는 시간을 연장시킬 수있는 ETL 인 다른 레이어를 통해 프로세스에 복잡성이 추가됩니다. – Alin

+0

이제는 라이브에서 직접 가져 오는 SQL 뷰를 통해 하나의 프로세스 대신 필요한 로직 (모든 case 문)이 포함 된 패키지가 데이터 형식을 DW로 생생하게 가져옵니다. 그런 다음 SiSense 큐브는 여전히 이러한 데이터웨어 하우스 테이블에서 가져와야합니다. 또한 케이스 문을 통해 해당 필드를 가져 오는 방법의 논리를 계속 변경하고 있습니다. 유지 관리가 더 나빠지지는 않을지 궁금합니다. SQL 뷰 대신 SSIS 내부에서 수행합니다. 그래서, 나는 여전히 최선의 방법이 무엇인지 혼란 스럽습니다. :) – Alin