Capacidade de cruzar suas bases com dados de diferentes organizações de forma simples e fácil. Já são centenas de conjuntos de dados públicos das maiores organizações do Brasil e do mundo presentes no nosso datalake.
Compromisso com a transparência, qualidade dos dados e desenvolvimento de melhores pesquisas, análises e soluções para a sociedade. Não só democratizamos o acesso a dados abertos, mas também dados de qualidade. Temos um time especializado que revisa e garante a qualidade dos dados adicionados ao datalake.
Participação de uma comunidade que cresce cada vez mais: milhares de jornalistas, pesquisadores(as), desenvolvedores(as), já utilizam e acompanham a Base dos Dados.
Quer subir dados na BD e nos ajudar a construir esse repositório? Maravilha! Organizamos tudo o que você precisa no manual abaixo em 8 passos
Para facilitar a explicação, vamos seguir um exemplo já pronto com dados da RAIS.
Você pode navegar pelas etapas no menu à esquerda.Sugerimos fortemente que entre em nosso canal no Discord para tirar dúvidas e interagir com a equipe e outros(as) colaboradores(as)! 😉
Alguns conhecimentos são necessárias para realizar esse processo:
Não tem alguma dessas habilidades, mas quer colaborar?Temos um time de dados que pode te ajudar, basta entrar no nosso Discord e mandar uma mensagem em #quero-contribuir.
Mantemos a lista de conjuntos para voluntários no nosso Github. Para começar a subir uma base do seu interesse, basta abrir uma nova issue de dados. Caso sua base (conjunto) já esteja listada, basta marcar seu usuário do Github como assignee
Seu primeiro trabalho é preencher as informações na issue. Essas informações vão te ajudar a entender melhor os dados e serão muito úteis para o tratamento e o preenchimento de metadados.
Quando finalizar essa etapa, chame alguém da equipe dados para que as informações que você mapeou sobre o conjunto já entrem pro nosso site!
Baixe aqui a pasta
template
e renomeie para o <dataset_id> (definido na issue do passo 1). Essa pasta template facilita e organiza todos os
passos daqui pra frente. Sua
estrutura é a seguinte:
<dataset_id>/
code/: Códigos necessários para captura e limpeza dos dados
(vamos ver mais no passo
4).input/: Contém todos os arquivos com dados originais, exatamente
como baixados da fonte primária. (vamos ver mais no passo
4).output/: Arquivos finais, já no formato pronto para subir na BD (vamos ver mais no passo
4).tmp/: Quaisquer arquivos temporários criados pelo código em /code no processo de limpeza e tratamento (vamos ver mais no passo
4).extra/
architecture/: Tabelas de arquitetura (vamos ver mais no passo 3).auxiliary_files/: Arquivos auxiliares aos dados (vamos ver mais no passo 5).dicionario.csv: Tabela dicionário de todo o conjunto de dados (vamos ver mais no passo 6).Apenas a pasta
codeserá commitada para o seu projeto, os demais arquivos existirão apenas localmente ou no Google Cloud.
As tabelas de arquitetura determinam qual a estrutura de cada tabela do seu conjunto de dados. Elas definem, por exemplo, o nome, ordem e metadados das variáveis, além de compatibilizações quando há mudanças em versões (por exemplo, se uma variável muda de nome de um ano para o outro).
Cada tabela do conjunto de dados deve ter sua própria tabela de arquitetura (planilha), que deve ser preenchida no Google Drive para permitir a correção pela nossa equipe de dados.
As tabelas de arquitetura da RAIS podem ser consultadas aqui. Elas são uma ótima referência para você começar seu trabalho já que tem muitas variáveis e exemplos de diversas situações que você pode acabar encontrando.
A cada início e final de etapa consulte nosso manual de estilo para garantir que você está seguindo a padronização da BD
original_name
original_name_YYYY para cada ano ou mês disponívelnamebigquery_typedescription conforme o manualtemporal_coverage de cada variável
covered_by_dictionarydirectory_columnint64 ou float64 verificar se é necessário incluir uma unidade de medidaQuando terminar de preencher as tabelas de arquitetura, entre em contato com a equipe da Base dos Dados para validar tudo. É necessário que esteja claro o formato final que os dados devem ficar antes de começar a escrever o código. Assim a gente evita o retrabalho.
Após validadas as tabelas de arquitetura, podemos escrever os códigos de captura e limpeza dos dados.
Captura: Código que baixa automaticamente todos os dados originais e os salva em /input. Esses dados podem estar disponíveis em portais ou links FTP, podem ser raspados de sites, entre outros.
Limpeza: Código que transforma os dados originais salvos em /input em dados limpos, salva na pasta /output, para, posteriormente, serem subidos na BD.
Cada tabela limpa para produção pode ser salva como um arquivo único ou, caso seja muito grande (e.g. acima de 200 mb), ser particionada no formato Hive em vários sub-arquivos. Os formatos aceitos são .csv ou .parquet. Nossa recomendação é particionar tabelas por ano, mes e sigla_uf. O particionamento é feito através da estrutura de pastas, veja o exemplo a baixo para visualizar como.
A tabela microdados_vinculos da RAIS, por exemplo, é uma tabela muito grande (+250GB) por isso nós particionamos por ano e sigla_uf. O particionamento foi feito usando a estrutura de pastas /microdados_vinculos/ano=YYYY/sigla_uf=XX .
.py, .R, ...) ou notebooks (Google Colab, Jupyter, Rmarkdown, etc).<dataset_id>), ou seja, não devem depender dos caminhos do seu
computador.O código de limpeza foi construído em R e pode ser consultado aqui.
O código de limpeza foi construído em Python pode ser consultado aqui
É comum bases de dados serem disponibilizadas com arquivos auxiliares. Esses podem incluir notas técnicas, descrições de coleta e amostragem, etc. Para ajudar usuários da Base dos Dados terem mais contexto e entenderem melhor os dados, organize todos esses arquivos auxiliares em /extra/auxiliary_files.
Fique à vontade para estruturar sub-pastas como quiser lá dentro. O que importa é que fique claro o que são esses arquivos.
Muitas vezes, especialmente com bases antigas, há múltiplos dicionários em formatos Excel ou outros. Na Base dos Dados nós unificamos tudo em um único arquivo em formato .csv - um único dicionário para todas as colunas de todas as tabelas do seu conjunto.
Detalhes importantes de como construir seu dicionário estão no nosso manual de estilo.
O dicionário completo pode ser consultado aqui. Ele já possui a estrutura padrão que utilizamos para dicionários.
Tudo pronto! Agora só falta subir para o Google Cloud e enviar para
revisão. Para isso, vamos usar o cliente basedosdados (disponível em Python) que facilita as configurações e etapas do processo.
Como existe um custo para o armazenamento no storage, para finalizar essa etapa vamos precisar te disponibilizar uma api_key especifica para voluntários para subir os dados em nosso ambiente de desenvolvimento. Assim, entre em nosso canal no Discord e nos chame em 'quero-contribuir'
7.1 No seu terminal instale nosso cliente: pip install basedosdados.
7.2 Rode import basedosdados as bd no python e siga o passo a passo para configurar localmente com as credenciais de seu projeto no Google Cloud. Preencha as informações conforme a seguir:
* STEP 1: y
* STEP 2: basedosdados-dev (colocar o .json passado pela equipe da bd na pasta credentials)
* STEP 3: y
* STEP 4: basedosdados-dev
* STEP 5: https://api.basedosdados.org/api/v1/graphql
Os dados vão passar por 3 lugares no Google Cloud:
7.3 Crie a tabela no bucket do GCS e BigQuey-DEV-staging, usando a API do Python, da seguinte forma:
import basedosdados as bd
tb = bd.Table(
dataset_id='<dataset_id>',
table_id='<table_id>')
tb.create(
path='<caminho_para_os_dados>',
if_table_exists='raise',
if_storage_data_exists='raise',
)
Os seguintes parâmetros podem ser usados:
path (obrigatório): o caminho completo do arquivo no seu computador, como: /Users/<seu_usuario>/projetos/basedosdados/sdk/bases/[DATASET_ID]/output/microdados.csv.Caso seus dados sejam particionados, o caminho deve apontar para a pasta onde estão as partições. No contrário, deve apontar para um arquivo.csv(por exemplo, microdados.csv).
force_dataset: comando que cria os arquivos de configuração do dataset no BigQuery.
if_table_exists : comando utilizado caso a tabela já exista no BQ:
if_storage_data_exists: comando utilizado caso os dados já existam no Google Cloud Storage:
Se o projeto não existir no BigQuery, ele será automaticamente criado
Consulte também nossa API para mais detalhes de cada método.
7.4 Crie os arquivos .sql e schema.yml a partir da tabela de arquitetura seguindo essa documentação
Caso você precise, nesse momento você pode alterar a consulta em SQL para realizar tratamentos finais a partir da tabelastaging, pode incluir coluna, remover coluna, fazer operações algébricas, substituir strings, etc. O SQL é o limite!
7.5 Rode e teste os modelos localmente seguindo essa documentação
7.6 Suba os metadados da tabela no site:
Por enquanto apenas a equipe dados tem permissões de subir os metadados da tabela no site, por isso será necessário entrar em contato conosco. Já estamos trabalhando para que, num futuro próximo, os voluntários também possam atualizar dados no site.
7.7 Suba os arquivos auxiliares:
st = bd.Storage(
dataset_id = <dataset_id>,
table_id = <table_id>)
st.upload(
path='caminho_para_os_arquivos_auxiliares',
mode = 'auxiliary_files',
if_exists = 'raise')
Ufa, é isso! Agora só resta enviar tudo para revisão no repositório da Base dos Dados.
cd para a pasta local do repositório e abra uma nova branch com git checkout -b [dataset_id]. Todas as adições e modificações serão incluídas nessa branch.table_id.sql na pasta queries-basedosdados/models/dataset_id/ copiando as queries que você desenvolveu no passo 7.queries-basedosdados/dbt_project.yaml (não se esqueça de seguir a ordem alfabética pra não bagunçar a organização)queries-basedosdados/models/dataset_id/codeE agora? Nossa equipe irá revisar os dados e metadados submetidos via Github. Podemos entrar em contato para tirar dúvidas ou solicitar mudanças no código. Quando tudo estiver OK, fazemos um merge do seu pull request e os dados são automaticamente publicados na nossa plataforma!