none
PROCESSAR PARTIÇÃO EM USO DO ANALYSIS SERVICES RRS feed

  • Pergunta

  • Boa tarde,

    Gostaria de saber se é possível construir um pacote dinâmico que processe somente a última partição de um cubo do analysis. Caso seja possível, se alguém tem um tutorial ou com algo parecido.

    Desde já agradeço,

    terça-feira, 28 de maio de 2013 18:52

Respostas

  • Oi Ailton,

    Sim, e possivel. Você teria que usar XMLA Script

    Nao tenho nenhum tutorial pronto ( mas e uma boa ideia para um post), porem encontrei esse artigo em ingles http://secretsql.wordpress.com/2011/02/06/ssas-dynamic-partition-processing/ acredito que vai te ajudar

    abs!

    • Sugerido como Resposta Bruno_v3 quarta-feira, 29 de maio de 2013 19:58
    • Marcado como Resposta Ailton Pedro sexta-feira, 14 de junho de 2013 13:10
    quarta-feira, 29 de maio de 2013 01:41
  • Ailton, Boa tarde,

    Construímos um que faz esse processamento dinâmico, tomamos por base o tutorial citado na resposta anterior e depois acrescentamos alguns itens de melhoria e voltados ao nosso cenário, como a criação de agregações, e reprocessamento de partições perdidas ou carga histórica.

    O mesmo requer um bom conhecimento de integration services e algum conhecimento de C#, mas compensa pois o resultado ficou ótimo.

    Sugiro que siga o modelo, abaixo segue uma breve explicação do processo que montamos, e caso tenha alguma dúvida só postar no fórum!

    Estamos criando um blog, http://cuboelevadoaocubo.com/, assim que possível fazemos uma postagem mais detalhada com esse processo e solutions de exemplo.

    Caso o post seja útil, qualifique!

    Explicações Pacote Dynamic Partition

    Criei um banco de dados à parte seguindo a nomenclatura, ele é composto pelas três tabelas abaixo:

    BANCO: DB_PRD_DIM_INDICADOR_WFM_CC

    TABELAS: CubeLog

    PartitionLog

    XMLModel

      • Nela devem ser cadastrados o ID do database do cubo, o ID do cubo, o ID do Measure(s) Group, o ID do DataSource, o QueryDefinition, a Periodicity, o Process e o PartitionNameRigid.
      • DataBaseID = Todo cubo tem um ID e um nome, o ideal é que sejam o mesmo, dessa forma, na hora da criação atentar-se as propriedades deles para que sejam iguais.
      • CubeID = Tal qual o item anterior, o ideal é que o ID e o nome sejam iguais, vide o caso 3, aonde o cubo de indicadores de fila, tem por ID “DB PRD DIM INDICADOR WFM PA”.
      • MeasureGroupID = Um cubo pode ter um ou n measures group, em geral, tem apenas um.
      • DataSourceID = Nome do datasource que o cubo utiliza para ler os dados da base relacional.
      • QueryDefinition = É o select que servirá para limitar a partição, nos casos de data, seguir os exemplos já existentes, aonde no final a clausula WHERE deve ser deixada assim “WHERE ID_SEQ_DATA BETWEEN “. Nos casos de partições rígidas, basta montar o select e complementar a clausula where, exemplo “WHERE ID_SEQ_ORGANIZACAO = 100”.
      • Periodicity = Campo que define qual a periodicidade em dias que as partições de data devem processar, serve para que por exemplo, no dia 02/02/2013, sejam processadas as partições de JANEIRO e FEVEREIRO, pois os dados são alterados em D-7 no caso de aderência e fila. Caso a partição seja rígida o valor deve ser 0.
      • Process = É baseado nesse campo que o pacote irá dizer quais partições ele deve criar/processar, logo ele é referenciado no pacote de carga do CUBO.dtsx, aonde a task deve ter o mesmo nome, vide imagem 2.
      • PartitionNameRigid = Para as partições que não forem de data, aonde os nomes são dados automaticamente, é preciso informar um nome de partição rígido, que não será alterado, e que será processado toda carga. Esse cenário hoje ainda não existe pois todas as partições trabalham com data.

    Abaixo segue o script de insert na tabela de CuboLog, a idéia é executa-lo uma vez após criação e testes no cubos, e só sendo necessária nova execução perante alguma mudança de estrutura que impacte em novos measures groups e/ou campos de origem:

    insert into CubeLog(

    DataBaseID

    ,CubeID

    ,MeasureGroupID

    ,DataSourceID

    ,QueryDefinition

    ,Periodicity

    ,Process

    , PartitionNameRigid)

    values(

    'WFM'

    ,'WFM'

    ,'Métricas Aderência 1'

    ,'DB_PRD_DIM_INDICADOR_WFM_PA','SELECT DISTINCT       F.ID_SEQ_ATIVIDADE, F.ID_SEQ_CAMPANHA, F.ID_SEQ_FUNCIONARIO, F.ID_SEQ_ORGANIZACAO, F.ID_SEQ_DATA, F.ID_SEQ_TEMPO_INICIO,       F.ID_SEQ_TEMPO_FIM, F.ID_SEQ_SERVIDOR, F.ID_SEQ_TIPO, F.NM_TEMPO_TOTAL_PLANEJADO, F.NM_TEMPO_TOTAL_ADERINDO,       F.NM_TEMPO_TOTAL_NAO_ADERINDO, F.NM_TEMPO_TOTAL_NAO_ADERINDO_APROVADO, F.ID_SEQ_FUNCIONARIO_SUPERVISOR, FUN.NM_COD_RE_RH, F.NM_QTD_LICENCA       FROM         dbo.TB_FAT_ADERENCIA AS F INNER JOIN       dbo.TB_DIM_FUNCIONARIO AS FUN ON F.ID_SEQ_FUNCIONARIO = FUN.ID_SEQ_FUNCIONARIO       WHERE ID_SEQ_ORGANIZACAO = 100'

    ,0

    ,'CC - Aderencia'

    ,'')

    • PartitionLog
      • Ela é responsável pelo gerencialmente das partições efetivamente dito, viabilizando a criação automática de partições de data, ela não necessita de nenhum insert manual ou manutenção, o preenchimento da tabela anterior sendo feito corretamente essa tende a simplesmente funcionar como auxiliar.
      • PartitionName = Nome criado automaticamente para as partições de data, para as partições rígidas será considerado o nome da tabela anteior.
      • FromDateKey = Campo alimentado automaticamente baseando-se na data corrente. Caso não existam ainda valores para aquele Cubo será adotado o valor inicial default de “20120101 – 20120131”.
      • ToDateKeu = Idem campo anterior.
      • CreateDate = Controle.
      • LastProcessDate = Controle.
      • ProcessedCount = Controle.
      • MeasureGroupID = Alimentado baseando-se na tabela anterior, serve para referência e gerar o LOOP de processamento de partições.


    Imagem 3 – Print da tabela em produção.

    • XML_MODEL
      • Tabela que possui apenas os campos com o modelo XMLA para CREATE e PROCESS de partição. Futuramente poderá possuir outros modelos mais detalhados e ou de outros processos.
    • Pacote DTSX:
      • Loop Cubo e Measures = Lê a tabela CubeLog e baseando-se no nome do pacote que realizou a chamada lista os cubos e measures que precisam ser criados/processados.
      • Loop – Cubo e Measures = Completo = Atribui os valores do select anterior em variáveis e realiza o looping.
      • Vertifica tipo partição = Serve apenas para direcionar o fluxo baseando no Periodicity, que defini se a partição é do tipo data ou genérica.
      • Partição Genérica/Partição Data = Sequences containers apenas para melhor disposição das tasks.
      • Carrega modelo XMLA = Idêntico em ambos, lê a tabela XML_MODEL e carrega em variáveis os XMLA de criação e processamento.
      • TSQL – Defini nome da partição e range de data = Na “Genérica” apenas utiliza o nome cadastrado na tabela CubeLog, no “Data” verifica o mais valor de partição existente na tabela de log, e compara com o dia corrente, para verificar se necessidade criar uma nova partição ou somente processar a corrente.
      • Sequence Container – Cria nova partição = Apenas para melhor disposição das tasks.
      • Script Task – Altera variável XMLA para criar e processar nova parti... = Único código C# do pacote, tem por função validar se a partição existe ou não e alterar as variáveis de XMLA baseando-se nas demais variáveis alimentadas pela tabela CubeLog. Possui apenas duas funções “VarifyPartition” e “ModifyXMLA”.
      • Analysis Services Execute DDL Task - Cria nova partição = Task padrão do SSIS que executa um XMLA no servidor SSAS, recebe a variável alterada pelo script anterior, só é executado caso a flag de partição existente seja igual a zero.
      • Execute SQL Task - Inseri partição na tabela de LOG = Registra na tabela PartitionLog a nova partição. Tornando-a assim uma tabela sem alimentação manual.

     

    OBS: Até aqui os fluxos apresentaram pequenas diferenças, agora que existe uma divisão maior escreverei em azul algumas partes referentes apenas as partições de data.

     

    • Loop Partições = Lê a tabela PartitionLog e baseando-se no nome do measure group que está em looping busca todas as partições que estejam dentre do range de data atual baseando no campo Periodicty.
    • Loop – Partições = Atribui os valores do select anterior em variáveis e realiza o looping.

     

    Obs: As próximas tasks são equivalentes novamente.

    • Analysis Services Processing Task – Partição = Processa a partição do measure group criada ou recorrente. Sendo possível determinar o tipo de processamento, FULL, DATA, INDEX, ...
    • Execute SQL Task - Atualiza tabela de LOG de partição = Atualiza a tabela PartitionLog com a data do último processamento e o contador de quantas vezes a partição foi processada.

    Obs: O pacote se encontra dentro da solution WFM, pasta Aderencia, projeto CC.


    Imagem 4 – Pacote completo

    • Sugerido como Resposta Bruno_v3 quarta-feira, 29 de maio de 2013 19:58
    • Marcado como Resposta Ailton Pedro sexta-feira, 14 de junho de 2013 13:10
    quarta-feira, 29 de maio de 2013 16:55

Todas as Respostas

  • Oi Ailton,

    Sim, e possivel. Você teria que usar XMLA Script

    Nao tenho nenhum tutorial pronto ( mas e uma boa ideia para um post), porem encontrei esse artigo em ingles http://secretsql.wordpress.com/2011/02/06/ssas-dynamic-partition-processing/ acredito que vai te ajudar

    abs!

    • Sugerido como Resposta Bruno_v3 quarta-feira, 29 de maio de 2013 19:58
    • Marcado como Resposta Ailton Pedro sexta-feira, 14 de junho de 2013 13:10
    quarta-feira, 29 de maio de 2013 01:41
  • Ailton, Boa tarde,

    Construímos um que faz esse processamento dinâmico, tomamos por base o tutorial citado na resposta anterior e depois acrescentamos alguns itens de melhoria e voltados ao nosso cenário, como a criação de agregações, e reprocessamento de partições perdidas ou carga histórica.

    O mesmo requer um bom conhecimento de integration services e algum conhecimento de C#, mas compensa pois o resultado ficou ótimo.

    Sugiro que siga o modelo, abaixo segue uma breve explicação do processo que montamos, e caso tenha alguma dúvida só postar no fórum!

    Estamos criando um blog, http://cuboelevadoaocubo.com/, assim que possível fazemos uma postagem mais detalhada com esse processo e solutions de exemplo.

    Caso o post seja útil, qualifique!

    Explicações Pacote Dynamic Partition

    Criei um banco de dados à parte seguindo a nomenclatura, ele é composto pelas três tabelas abaixo:

    BANCO: DB_PRD_DIM_INDICADOR_WFM_CC

    TABELAS: CubeLog

    PartitionLog

    XMLModel

      • Nela devem ser cadastrados o ID do database do cubo, o ID do cubo, o ID do Measure(s) Group, o ID do DataSource, o QueryDefinition, a Periodicity, o Process e o PartitionNameRigid.
      • DataBaseID = Todo cubo tem um ID e um nome, o ideal é que sejam o mesmo, dessa forma, na hora da criação atentar-se as propriedades deles para que sejam iguais.
      • CubeID = Tal qual o item anterior, o ideal é que o ID e o nome sejam iguais, vide o caso 3, aonde o cubo de indicadores de fila, tem por ID “DB PRD DIM INDICADOR WFM PA”.
      • MeasureGroupID = Um cubo pode ter um ou n measures group, em geral, tem apenas um.
      • DataSourceID = Nome do datasource que o cubo utiliza para ler os dados da base relacional.
      • QueryDefinition = É o select que servirá para limitar a partição, nos casos de data, seguir os exemplos já existentes, aonde no final a clausula WHERE deve ser deixada assim “WHERE ID_SEQ_DATA BETWEEN “. Nos casos de partições rígidas, basta montar o select e complementar a clausula where, exemplo “WHERE ID_SEQ_ORGANIZACAO = 100”.
      • Periodicity = Campo que define qual a periodicidade em dias que as partições de data devem processar, serve para que por exemplo, no dia 02/02/2013, sejam processadas as partições de JANEIRO e FEVEREIRO, pois os dados são alterados em D-7 no caso de aderência e fila. Caso a partição seja rígida o valor deve ser 0.
      • Process = É baseado nesse campo que o pacote irá dizer quais partições ele deve criar/processar, logo ele é referenciado no pacote de carga do CUBO.dtsx, aonde a task deve ter o mesmo nome, vide imagem 2.
      • PartitionNameRigid = Para as partições que não forem de data, aonde os nomes são dados automaticamente, é preciso informar um nome de partição rígido, que não será alterado, e que será processado toda carga. Esse cenário hoje ainda não existe pois todas as partições trabalham com data.

    Abaixo segue o script de insert na tabela de CuboLog, a idéia é executa-lo uma vez após criação e testes no cubos, e só sendo necessária nova execução perante alguma mudança de estrutura que impacte em novos measures groups e/ou campos de origem:

    insert into CubeLog(

    DataBaseID

    ,CubeID

    ,MeasureGroupID

    ,DataSourceID

    ,QueryDefinition

    ,Periodicity

    ,Process

    , PartitionNameRigid)

    values(

    'WFM'

    ,'WFM'

    ,'Métricas Aderência 1'

    ,'DB_PRD_DIM_INDICADOR_WFM_PA','SELECT DISTINCT       F.ID_SEQ_ATIVIDADE, F.ID_SEQ_CAMPANHA, F.ID_SEQ_FUNCIONARIO, F.ID_SEQ_ORGANIZACAO, F.ID_SEQ_DATA, F.ID_SEQ_TEMPO_INICIO,       F.ID_SEQ_TEMPO_FIM, F.ID_SEQ_SERVIDOR, F.ID_SEQ_TIPO, F.NM_TEMPO_TOTAL_PLANEJADO, F.NM_TEMPO_TOTAL_ADERINDO,       F.NM_TEMPO_TOTAL_NAO_ADERINDO, F.NM_TEMPO_TOTAL_NAO_ADERINDO_APROVADO, F.ID_SEQ_FUNCIONARIO_SUPERVISOR, FUN.NM_COD_RE_RH, F.NM_QTD_LICENCA       FROM         dbo.TB_FAT_ADERENCIA AS F INNER JOIN       dbo.TB_DIM_FUNCIONARIO AS FUN ON F.ID_SEQ_FUNCIONARIO = FUN.ID_SEQ_FUNCIONARIO       WHERE ID_SEQ_ORGANIZACAO = 100'

    ,0

    ,'CC - Aderencia'

    ,'')

    • PartitionLog
      • Ela é responsável pelo gerencialmente das partições efetivamente dito, viabilizando a criação automática de partições de data, ela não necessita de nenhum insert manual ou manutenção, o preenchimento da tabela anterior sendo feito corretamente essa tende a simplesmente funcionar como auxiliar.
      • PartitionName = Nome criado automaticamente para as partições de data, para as partições rígidas será considerado o nome da tabela anteior.
      • FromDateKey = Campo alimentado automaticamente baseando-se na data corrente. Caso não existam ainda valores para aquele Cubo será adotado o valor inicial default de “20120101 – 20120131”.
      • ToDateKeu = Idem campo anterior.
      • CreateDate = Controle.
      • LastProcessDate = Controle.
      • ProcessedCount = Controle.
      • MeasureGroupID = Alimentado baseando-se na tabela anterior, serve para referência e gerar o LOOP de processamento de partições.


    Imagem 3 – Print da tabela em produção.

    • XML_MODEL
      • Tabela que possui apenas os campos com o modelo XMLA para CREATE e PROCESS de partição. Futuramente poderá possuir outros modelos mais detalhados e ou de outros processos.
    • Pacote DTSX:
      • Loop Cubo e Measures = Lê a tabela CubeLog e baseando-se no nome do pacote que realizou a chamada lista os cubos e measures que precisam ser criados/processados.
      • Loop – Cubo e Measures = Completo = Atribui os valores do select anterior em variáveis e realiza o looping.
      • Vertifica tipo partição = Serve apenas para direcionar o fluxo baseando no Periodicity, que defini se a partição é do tipo data ou genérica.
      • Partição Genérica/Partição Data = Sequences containers apenas para melhor disposição das tasks.
      • Carrega modelo XMLA = Idêntico em ambos, lê a tabela XML_MODEL e carrega em variáveis os XMLA de criação e processamento.
      • TSQL – Defini nome da partição e range de data = Na “Genérica” apenas utiliza o nome cadastrado na tabela CubeLog, no “Data” verifica o mais valor de partição existente na tabela de log, e compara com o dia corrente, para verificar se necessidade criar uma nova partição ou somente processar a corrente.
      • Sequence Container – Cria nova partição = Apenas para melhor disposição das tasks.
      • Script Task – Altera variável XMLA para criar e processar nova parti... = Único código C# do pacote, tem por função validar se a partição existe ou não e alterar as variáveis de XMLA baseando-se nas demais variáveis alimentadas pela tabela CubeLog. Possui apenas duas funções “VarifyPartition” e “ModifyXMLA”.
      • Analysis Services Execute DDL Task - Cria nova partição = Task padrão do SSIS que executa um XMLA no servidor SSAS, recebe a variável alterada pelo script anterior, só é executado caso a flag de partição existente seja igual a zero.
      • Execute SQL Task - Inseri partição na tabela de LOG = Registra na tabela PartitionLog a nova partição. Tornando-a assim uma tabela sem alimentação manual.

     

    OBS: Até aqui os fluxos apresentaram pequenas diferenças, agora que existe uma divisão maior escreverei em azul algumas partes referentes apenas as partições de data.

     

    • Loop Partições = Lê a tabela PartitionLog e baseando-se no nome do measure group que está em looping busca todas as partições que estejam dentre do range de data atual baseando no campo Periodicty.
    • Loop – Partições = Atribui os valores do select anterior em variáveis e realiza o looping.

     

    Obs: As próximas tasks são equivalentes novamente.

    • Analysis Services Processing Task – Partição = Processa a partição do measure group criada ou recorrente. Sendo possível determinar o tipo de processamento, FULL, DATA, INDEX, ...
    • Execute SQL Task - Atualiza tabela de LOG de partição = Atualiza a tabela PartitionLog com a data do último processamento e o contador de quantas vezes a partição foi processada.

    Obs: O pacote se encontra dentro da solution WFM, pasta Aderencia, projeto CC.


    Imagem 4 – Pacote completo

    • Sugerido como Resposta Bruno_v3 quarta-feira, 29 de maio de 2013 19:58
    • Marcado como Resposta Ailton Pedro sexta-feira, 14 de junho de 2013 13:10
    quarta-feira, 29 de maio de 2013 16:55
  • Boa tarde!

    Paulo, gostaria de entender melhor o container de criação de nova partição... Poderia exemplificar por gentileza?

    Desde já agradeço a ajuda de ambos,

    Abraço,

    segunda-feira, 29 de julho de 2013 20:24