Otimizações no processo de consolidação física
Description
Stakeholder
- @Bruno Tortato Furtado
- @Robson Thanael Poffo
Problema
Identificamos casos onde registros foram deletados da staging de forma lógica (mdmDeleted=true) mas acabaram não sendo excluídos do Data Model pois, antes da execução da pipeline, o registro havia sido excluído de forma física pela consolidação que plataforma executa.
Analisando o código fonte da versão 1 de consolidação (link) e também o da versão 2 (link), notamos que a deleção é realizada sem quaisquer outros filtros, podendo gerar esse tipo de inconsitência.
Exemplificando o problema:
- Pipeline roda semanalmente no sábado a noite.
- Um registro foi enviado com mdmDeleted=true durante a semana.
- No sábado a tarde a consolidação roda e remove esse registro.
- No sábado a noite a pipeline roda e não considera esse registro, mantendo o mesmo na DM.
- Para o cliente, o comportamento não é o adequado pois o registro deveria ser removido da DM.
Objetivo
- Atender as necessidades de clientes, onde manter o último registro, mesmo que ele possua o campo mdmDeleted=true, preserva o estado e gera maior consistência de dados, minimizando impactos de negócio.
- Impactar o mínimo possível armazenamento e processamentos ao manter um volume de registros maior na plataforma, levando em consideração o fato de que estaremos mantendo alguns registros com mdmDeleted=true.
Links
- Thread com conversa no Slack: link
Critérios de aceite
- Excluir todas as versões dos registros diferentes da mais atual (preservando a versão mais recente que o mdmDeleted seja
true).- Excluir registros que a versão mais recente seja o registro com mdmDeleted =
truee tempo de vida (mdmStagingCounter) maior do que 30 dias.
- Excluir registros que a versão mais recente seja o registro com mdmDeleted =
- Eliminamos registros idênticos, deixando apenas um deles. Devemos considerar no desempate o
_ingestionDatetime. E mesmo caso haja empate manter apenas um registro.
Activity
Show:
Details
Priority
HighAssignee
FELIPE BARBOSA MENDES
Reporter
Robson Thanael Poffo
Labels
PLANNED
Due Date
30 August 2024
Fix versions
CAPL_4.06
Components
BIG_QUERY | CONSOLIDATION
Created
29 June 2024, 10:23
Updated
28 August 2024, 18:13
More fields
Created: 29 June 2024, 15:23
Updated:
28 August 2024, 23:13
Ocorreu o deploy em Produção. Issue movimentada para Done.
Nenhuma issue associada no Jira Produção.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Esta issue teve o seu status alterado, pois ocorreu o merge da branch capl-6257-fix-consolidation-query-v2 na branch main.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Teste 3:
Limpar a tabela
consolidations,consolidation_tenant_status,consolidation_statseconsolidation_discover_statsdo postgres.Limpar a tabela
dmticketno BigQuery e recopiar os dados.Rodar uma consolidação agendada alterando a coluna
execution_weekdayda tabelaconsolidation_configpara o dia da semana atual e acoluna execution_hourpara 3 horas posterior a hora atual e a colunaexecution_lookback_dayspara 15 diasConfirmar na tabela
consolidationsdo postgres que todas as consolidações terminaram com um statusDONEConfirmar na
ingestion_dmticketno BigQuery que apenas um registros duplicado foi removido por ter _ingestionDatetime maior do que 15 dias atrás.Teste 2:
Limpar a tabela
consolidationseconsolidation_tenant_statusdo postgres.Limpar a tabela
dmticketno BigQuery e recopiar os dados.Rodar uma consolidação agendada alterando a coluna
execution_weekdayda tabelaconsolidation_configpara o dia da semana atual e acoluna execution_hourpara 3 horas posterior a hora atual com o apoio do MendesConfirmar na tabela
consolidationsdo postgres que todas as consolidações terminaram com um statusDONEConfirmar na
ingestion_dmticketno BigQuery que os registros duplicados ou com mdmDeteled true inseridos há mais de 30 dias foram devidamente excluídos.Teste 1:
Criar sandbox e provisioná-la
Criar data model
dmticketusando snapshotCopiar dados da tabela
labs-poc.custom_data.dmticket_copypara a tabeladmticketcriada na sandbox Mendes ajudou aquiSolicitar consolidação utilizando o endpoint
/v1/tenant/{mdmTenantId}/consolidations_tenantcom um payload:{"mdmTaskId": "COLOQUE AQUI UM TASK ID"}Confirmar na tabela
consolidationsdo postgres que todas as consolidações terminaram com um statusDONEConfirmar na
ingestion_dmticketno BigQuery que os registros duplicados ou com mdmDeteled true inseridos há mais de 30 dias foram devidamente excluídos.Esta issue teve o seu status alterado, pois foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Esta issue teve o seu status alterado, pois foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Esta issue teve o seu status alterado, pois foi criado o PR sem a sigla WIP no título.
Foi criada a branch.
Foi aprovado o PR.
Foi aprovado o PR.
@FELIPE BARBOSA MENDES ,
1. Dúvida sobre o campo mdmStagingCounter
Nas stagings o atributo é
mdmCounterForEntity.2. Casos onde mdmStagingCounter forem nulos
Curioso esse cenários, não deveria ser null o counterForEntity. Talvez sejam dados inseridos via endpoint golden RT e que por consequencia não tenham um vinculo com staging table.
Respondendo a pergunta:
Sim, podemos assumir o _ingestionDateTime quando o
mdmStagingCounterfor null.@Robson Thanael Poffo para os cenários levantados pelo Bruno você acredita que possamos usar o campo
_ingestionDatetime?Olá pessoal, vou aproveitar a oportunidade para levantar os seguintes pontos sobre a query sugerida:
1. Dúvida sobre o campo mdmStagingCounter
O trecho de código abaixo leva em conta tanto DM quanto STG?
Pergunto pois o campo mdmStagingCounter parece não existir em STGs.
1
2
3
2. Casos onde mdmStagingCounter forem nulos
Para algumas situações, notamos que o mdmStagingCounter pode ser nulo (não entendi muito bem se tem relação com registros passados ou o porque isso ocorre, talvez porque ainda inserem direto pelo DM). O fato é que isto ocorre e pode impactar o resultado desta condição:
1
Sendo assim a sugestão de melhoria seria algo como:
1
Lembrando que a sugestão acima aparentemente funcionaria apenas para DM, para STG teriamos de inserir alguma condição no script pois o campo mdmStagingCounter parece não existir.
@Robson Thanael Poffo ,
@PEDRO BUZZI FILHO ,
@Geny Isam Hamud Herrera ,
Este issue foi planejada para ser entregue até 2024-08-30. Você pode confirmar consultando o campo Due Date desta issue.
Data já planejadas para esta issue: 2024-08-30
Se o campo External Issue Link estiver preenchido com o link de uma issue válida no Jira Produção o cliente também será notificado no Jira Produção.