Você sabe quais seriam as práticas recomendadas em relação ao SSAS e aos relatórios em tempo real?
Não tenho certeza se devemos extrair dados de nosso banco de dados ativo ou usar o SSIS para mover dados periodicamente para um banco de dados de data warehouse antes de reprocessar o cubo.
Qualquer conselho sobre qual é a melhor abordagem seria muito apreciado.
O ato de equilíbrio mais significativo a considerar é se sua necessidade de relatórios em tempo real supera o impacto no desempenho que seus sistemas OLAP e OLTP terão ao usar sua fonte de dados OLTP diretamente como tabelas de fatos e dimensões e, em seguida, desativar as consultas ROLAP/HOLAP deles. Se todas as tabelas forem muito pequenas e o servidor ainda não estiver sobrecarregado, a penalidade provavelmente será insignificante. Se as consultas SSAS forem iniciar leituras de mais de 500 MB, isso é um problema.
E a menos que você esteja fazendo algum tipo de negociação de alta frequência, provavelmente não precisa ter seu banco de dados SSAS atualizado. Parece que o SSAS é mais útil para resumos gerais e, se as últimas horas de dados ainda não foram incluídas, não fará grande diferença para quem está executando os relatórios (pergunte para ter certeza, obviamente ).
Carregamos nossos armazéns de dados e processamos os cubos todas as noites, e isso normalmente é suficiente. Também temos alguns relatórios simples construídos em tabelas OLTP para visualizar dados mais direcionados e atualizados (coisas que são realmente mais OLTP do que OLAP por natureza).
Relatórios operacionais x analíticos
Relatórios ad hoc em um sistema operacional são uma má ideia, então a resposta depende de quais são seus requisitos em tempo real.
Na maioria dos casos, o requisito real em tempo real é para um punhado de relatórios operacionais. Eles geralmente não são de natureza agregada ou estatística e tendem a ser relatórios de exceção, relatórios de status ou listas de tarefas. Eles normalmente não devem atingir grandes quantidades de dados, mas sim selecionar determinados registros que correspondam aos critérios do relatório.
Os relatórios operacionais estão quase sempre vinculados a um processo específico e nunca de natureza analítica. Normalmente, os relatórios analíticos podem ser executados com uma carga periódica e não precisam de dados atualizados. Existem algumas exceções a isso, como feeds de dados de mercado, mas esses são casos excepcionais.
Nesse caso, você deve fazer uma carga periódica em um data mart, extração de dados ou sistema de data warehouse para os relatórios analíticos e criar os relatórios operacionais como relatórios personalizados e ajustados. Execute-os de uma instância de banco de dados replicada, se possível, para reduzir a carga transitória no banco de dados do sistema operacional.
Alguns aplicativos precisam de dados em tempo real ou quase real (baixa latência) para serem carregados em um sistema analítico. Alguns exemplos desse tipo de exigência são os sistemas analíticos de dados de mercado ou os sistemas de relatórios de contas. No primeiro caso, o sistema é usado pelos comerciantes para executar análises estatísticas sobre os dados e, no último caso, normalmente há um requisito para que os contadores possam preparar e inserir um diário e, em seguida, relatá-lo imediatamente.
Esses são relatórios realmente operacionais disfarçados e tendem a ter seu SLA vinculado ao sistema de origem. Uma coisa que esses sistemas têm em comum é que eles tendem a ter um modelo relativamente direto para os dados subjacentes.
Você pode enfrentar determinados bancos de dados operacionais com uma ferramenta ROLAP que consulta o esquema subjacente. Raramente é uma boa ideia fazer isso com um banco de dados do sistema operacional, pois eles tendem a não se prestar a consultas agregadas eficientes.
Eu fiz isso em uma ocasião com um sistema de contas e um modelo de relatório - em teoria, um cubo também poderia ter sido usado. A Oracle também fornece uma ferramenta de relatório ad-hoc baseada em descobridor para o Oracle Financials que funciona de maneira semelhante. No entanto, o modelo de dados nativo de um sistema de contabilidade é realmente muito próximo de um esquema de floco de neve, então você pode se safar disso. No entanto, os relatórios tendem a ser bastante lentos e ainda sobrecarregam o sistema se forem carregados.
Se você realmente deseja análises ad hoc em uma fonte de baixa latência, pode criar um processo ETL de baixa latência que preencha um data mart. Esse tipo de coisa é mais trabalhoso e complicado do que um processo ETL tradicional, portanto, você não deseja fazer isso para aplicativos em que não há requisitos genuínos. Você pode colocar um cubo com uma partição ROLAP principal nele e armazenar os dados históricos como MOLAP. Eu estive envolvido na construção de um sistema que funciona assim.
Sistemas analíticos de baixa latência
Dependendo de sua fonte de dados, você pode usar um mecanismo de captura de dados alterados ou um mecanismo de sondagem para identificar novas transações. Esse processo pode, então, enviar os dados para o data mart. Se você deseja uma latência realmente baixa e controla o banco de dados de origem, pode implementar gatilhos que enviam transações para o data mart, embora essa opção possa colocar uma carga significativa em seu sistema.
Partição ROLAP principal em um cubo
Um cubo de baixa latência pode ser feito com uma arquitetura híbrida. Os dados principais (por exemplo, para o atual período contábil aberto) podem ser consultados por meio de uma partição ROLAP, que emitirá consultas contra os dados subjacentes. Os dados fechados ou históricos são gerenciados por meio de partições MOLAP que possuem agregações. Isso fornece dados quase em tempo real sem a necessidade de fazer consultas de banco de dados em grandes volumes de dados e os benefícios de desempenho de agregações nos dados históricos.
Isso tem algumas ressalvas. Dimensões ROLAP puras restringem substancialmente os recursos que podem ser usados nos grupos de medidas (por exemplo, sem agregações, exceto SUM ou COUNT). Se você espera atualizações incrementais para dados dimensionais, é melhor usar dimensões MOLAP e um processo de atualização incremental acionado a partir do trabalho que atualiza a tabela de dimensão subjacente. Isso é bastante eficiente se você processar a dimensão de forma incremental.
Testar esse tipo de sistema é um tanto complicado, pois você precisa garantir que a captura de dados alterados ou o mecanismo de carregamento incremental esteja funcionando corretamente. Você provavelmente precisará criar um equipamento de teste que possa postar transações no sistema para executar testes de unidade.
Se você estiver usando o SSAS no modo de armazenamento MOLAP, será necessário processar o cubo para atualizar os relatórios que usam o cubo como fonte de dados. Quer você use seu banco de dados "ativo" ou uma versão "não ativa" gerada por meio de processos ETL, você deve processar o cubo para atualizá-lo. Se você estiver usando SSAS para obter as vantagens de agregações de alto desempenho, terá que aceitar algum grau de latência de dados.
Na outra extremidade dos modos de armazenamento para SSAS está o ROLAP. O ROLAP não requer o processamento de um cubo, pois na verdade não gera um armazenamento de dados de cubo. Em vez disso, tudo o que ele faz é gerar consultas SQL no banco de dados do sistema de origem sempre que você executa uma consulta MDX. Isso significa que ele está indo diretamente contra seu banco de dados subjacente. Portanto, se você tiver um banco de dados "ativo", poderá obter dados atuais sem processar um cubo se o modo de armazenamento for ROLAP. Minha própria experiência pessoal é que as consultas subjacentes são geralmente horríveis. Por exemplo, se eu quisesse consultar um fato e alguns atributos de uma dimensão, o MDX geraria um SELECT DISTINCT * FROM Dimimension.Table JOIN Fact.Table ON Key.Column = Key2.Column2. Isso basicamente tornou o ROLAP inútil para mim, pois teve um desempenho pior do que qualquer outra alternativa.
No meio, você tem o modo de armazenamento HOLAP. Isso é basicamente MOLAP para algumas dimensões e tabelas de fatos e ROLAP para outras. Então você tem que processar parte do seu cubo e a outra parte são dados ao vivo do banco de dados. Para mim, essa não era uma solução viável, pois ainda sofria dos mesmos problemas de desempenho do ROLAP e adicionava alguma latência como o MOLAP.
Se você realmente deseja consultar seus dados ao vivo sem forçar os usuários a aprender SQL, você pode criar um modelo de dados de relatório no BIDS, implantá-lo em seu servidor Reporting Services e usá-lo como uma fonte de dados. O modelo de dados é um metadado posterior que é quase idêntico ao modelo no SSAS -- ele simplesmente não permite que você gere um cubo pré-armazenado a partir dele. Esta poderia ser uma alternativa razoável ao SSAS. No entanto, os modelos de dados de relatório funcionam apenas com SSAS -- eles não funcionam com o Excel. Se seus usuários desejam uma fonte de dados de alta velocidade para Excel que não exija a gravação de SQL, sua única solução viável é MOLAP SSAS. Se seus usuários desejam dados "ativos" e não precisam do Excel como ponto de partida, use o SSRS e um modelo de dados de relatório.
Se você estiver usando Cognos, Business Objects, Microstrategy ou alguma outra solução de BI, observe que todos eles têm camadas de metadados de modelo de dados semelhantes ao modelo de dados de relatório e também podem consultar os sistemas de origem "ativos" com instruções SQL geradas.
Um conselho: não programe uma solução de relatórios em um banco de dados de produção, a menos que você esteja criando os relatórios na interface do aplicativo de produção subjacente. Mesmo assim, você provavelmente ainda deseja descarregar as consultas de relatório para alguma fonte de dados replicada em vez do sistema OLTP de produção. Você não quer que a consulta de alguém sobre vendas anteriores bloqueie uma nova venda real. Se você estiver criando um sistema de relatórios apenas para usuários internos, reserve um tempo para carregar os dados em outro servidor por meio de replicação, envio de log, espelhamento, backup/restauração etc. e, em seguida, carregue os dados em um data warehouse via SSIS ou alguma outra solução ETL. Você realmente não quer que um relatório seja o motivo de uma interrupção do sistema de produção ou problema de latência.