Usa Silver como fonte do OpenAlex match no ETL#727
Conversation
- Não usaremos mais raw_openalex_works - Usaremos silver_openalex-* - Usaremos silver_scientific_production-* - Ambos representados pelo alias silver_scientific_production
- campo max_docs foi removido em PR anterior
| oca_data = ( | ||
| candidate.get("oca_data") | ||
| if isinstance(candidate.get("oca_data"), dict) | ||
| else {} | ||
| ) | ||
|
|
||
| oca_openalex = ( | ||
| oca_data.get("openalex") | ||
| if isinstance(oca_data.get("openalex"), dict) | ||
| else {} | ||
| ) |
There was a problem hiding this comment.
oca_ids = (
candidate.get("oca_data", {})
.get("openalex", {})
.get("ids")
)
Se tiver a certeza que candidate["oca_data"] e candidate["oca_data"]["openalex"] são sempre dicionários, poderia simplificar removendo os isinstance
There was a problem hiding this comment.
100% certeza é dificil garantir num universo de dados desse tamanho. Podemos adotar algo que projeta com a chave apontando para None. Algo parecido com a sua sugestão, mas que projete um passo além:
oca_data = candidate.get("oca_data") or {}
openalex = oca_data.get("openalex") or {}
oca_ids = openalex.get("ids")Ou de forma mais enxuta:
oca_ids = ((candidate.get("oca_data") or {}).get("openalex") or {}).get("ids")| elif oca_ids: | ||
| values.append(oca_ids) | ||
|
|
||
| for value in values: |
There was a problem hiding this comment.
Em cada if...elif, faz um for em oa_ids e oca_ids e faz o return dentro dele. Não precisa de uma lista para adicionar os itens e depois interar nesse for.
There was a problem hiding this comment.
Esse _first_openalex_id está legado (tinha a ver com o raw) - o sistema deve olhar para todos os IDs OpenaAlex de um doc (e como estamos olhando para o silver, agora pode haver mais de um válido). Vou fazer uma correção.
- o correto, a partir do silver, é obter todos os IDs OpenAlex - e não apenas o primeiro ID, como era o método substituído
- a versão anterior considerava apenas o primeiro encontrado
- cria utilitário interno para facilitar comparação - cria três testes para avaliar ordem de mescla com all ids
- o alias silver_scientific_production contem docs mesclados - isso complica a mescla e deve ser tratado em outro PR - este PR envolve substituir raw_openalex_works por silver_openalex-*
- esses procedimentos permitiam realizar mescla fora da rotina padrão - e potencialmente estragam a mescla, se executadas de maneira indevida - perderam o sentido, com a troca para silver - havia função em task servindo de apoio para managed command
2 participants
O que esse PR faz?
Altera o fluxo de OpenAlex matching do ETL para usar documentos já normalizados no índice Silver como fonte de candidatos, em vez de consultar e reprocessar documentos raw de OpenAlex. Observação: boa parte do diff é fixture de teste. São 585 linhas em JSON fixtures usadas para cobrir cenários reais de match/merge com Silver.
Principais mudanças:
SilverDocument;content_urlde candidatos Silver no merge;Onde a revisão poderia começar?
Começaria por:
etl/deduplicator/openalex.pyDepois seguiria para:
etl/pipeline.pyetl/transform/merger.pyetl/tests/pipeline/test_pipeline_dedup.pyComo este poderia ser testado manualmente?
EtlPipelineConfigestejam apontandoopenalex_indexparasilver_scientific_production.oca_data.merge_trace.openalex_matchesfoi preenchido;ids.openalexfoi preservado;Validação
Para validar este PR, é suficiente rodar a suíte focada de ETL abaixo, que foi alterara para usar o silver_scientific_production no lugar do raw_openalex_works. Ela cobre as regras de deduplicação, o matching OpenAlex contra documentos Silver e a mescla SciELO/OpenAlex, incluindo preservação de IDs, trace e campos enriquecidos.
python manage.py test etl.tests.pipeline.test_pipeline_dedup etl.tests.transform.test_mergerAlgum cenário de contexto que queira dar?
O índice Silver já contém documentos OpenAlex normalizados. Usar esse índice como fonte de match evita repetir a standardização de documentos raw durante o merge SciELO/OpenAlex e aproxima o matching do formato final consumido pelo restante da aplicação. E o mais importante é evitar que tenhamos um índice raw_openalex_works (que está disponível apenas no servidor legado).
Screenshots
N/A
Quais são tickets relevantes?
#719
Referências
N/A