Especificação para automação de carga de dados no CKAN

[fjuniorr]

Adiciona especificação.

• Link para especificação

[Andrelamor]

Sobre a necessidade de se replicar a mesma periodicidade de atualização dos dados do Portal para o CKAN: em reunião (05/11), pontuou-se que o preço da atualização diária (e.g. compras, patrimônio) é cerca de 4.000/mês; alternativa aventada foi criar usuário CKAN na API da Transparência.

O dataset de execução orçamentária do município de São Paulo tem indicação explícita de atualização diária, apesar de constar na ficha desse dataset que a única carga/atualização dele, no ano de 2019, ocorreu em 13/05 (o que parece ser um campo estático do CKAN, sem atualização automática de data quando se carrega novo arquivo). A última coluna do respectivo csv informa a data da extração de 01/12/2019.

No Espírito Santo, a atualização da execução das despesas é diária. Em Pernambuco, embora não encontrei menção explícita sobre a periodicidade, também parece ser diária. A última atualização informada no campo do CKAN foi 02/12/2019.

Em Recife, é semanal. Recife e Pernambuco têm APIs em seus portais de dados abertos.

[Andrelamor]

Ver dicas do PLANO DE ABERTURA DE DADOS no GUIA DE DADOS ABERTOS DO GOVERNO DE SP (págs. 38 e 39)

Um cenário fictício

Imagine que a Secretaria de Logística e Transportes do Estado de São Paulo tenha desenvolvido uma API pública para que qualquer desenvolvedor pudesse acessar informações sobre as condições de manutenção das estradas paulistas. Em determinado momento o servidor de API foi inundado e o servidor do banco de dados travou. Os serviços estaduais que dependem desse banco de dados pararam de funcionar. Os registros mostravam que houve um aumento grande no tráfego entre oito e nove horas da manhã com muitas requisições de API vindas de muitos lugares diferentes. Depois das nove horas o nível de acessos nos servidores diminuiu e tudo voltou ao normal.

O que aconteceu?

Seguindo com o cenário fictício, um ano antes, a Secretaria de Logística e Transportes começou a abrir seus dados como parte da política de transparência do estado. Havia pressa e, com a equipe reduzida, eles decidiram criar uma API para os dados das estradas configurando um servidor de API acessível pela Internet. A API foi desenvolvida levando em consideração potenciais situações em que os desenvolvedores de aplicativos poderiam usála, mas era difícil saber exatamente o que as pessoas iriam querer. Ao todo, a equipe da Secretaria estabeleceu três chamadas genéricas de API. Passado o ocorrido com os servidores, um ano mais tarde, os servidores descobriram que um empreendedor havia desenvolvido um aplicativo de celular que fez muito sucesso, sendo usado por centenas de milhares de pessoas. Todos os dias de manhã o aplicativo anunciava, antes da pessoa ir trabalhar, qual era a situação de manutenção nas estradas paulistas. Para baixar esses dados cada aplicativo instalado em cada celular precisava realizar duas chamadas de API. Foi isso que derrubou os servidores da Secretaria, pois a infraestrutura não estava preparada para lidar com o número de acessos.

Alternativa

Uma alternativa ao modelo apresentado anteriormente é publicar “dumps” de dados na forma de arquivos. Nesse modelo, os dados da base são exportados e transformados num arquivo de formato aberto, tal como o CSV. Depois disso, recebem um nome padronizado e são armazenados num servidor de páginas da Web. Isso significa que qualquer desenvolvedor pode baixar todos os seus dados, carregá-los na infraestrutura deles e desenvolver suas próprias APIs (nesse caso, privadas) de acordo com a necessidade deles. Além disso, grandes quantidades de acesso estarão concentradas nos servidores deles, sem afetar o funcionamento de outros serviços do governo. Outra vantagem é que a publicação de arquivos “dumps” num servidor de páginas da Web é muito simples. Se os arquivos e URLs receberem nomes consistentes, será fácil para os desenvolvedores baixarem os dados ao longo do tempo (por exemplo, http://exemplo.com/estradas/2015-01-30.csv).

[Andrelamor]

para atualizar sobre decisões e alterações na arquitetura e processos de automação no CKAN