Capacidad de cruzar sus bases con datos de diferentes organizaciones de forma sencilla y fácil. Ya hay cientos de conjuntos de datos públicos de las organizaciones más grandes de Brasil y del mundo presentes en nuestro datalake.
Compromiso con la transparencia, la calidad de los datos y el desarrollo de mejores investigaciones, análisis y soluciones para la sociedad. No solo democratizamos el acceso a datos abiertos, sino también a datos de calidad. Contamos con un equipo especializado que revisa y garantiza la calidad de los datos añadidos al datalake.
Participación de una comunidad cada vez más grande: miles de periodistas, investigadores y desarrolladores ya utilizan y siguen la Base de Datos.
¿Quieres subir datos a la BD y ayudarnos a construir este repositorio? ¡Genial! Hemos organizado todo lo que necesitas en el siguiente manual en 8 pasos
Para facilitar la explicación, seguiremos un ejemplo ya preparado con datos de RAIS.
Puede navegar por los pasos en el menú de la izquierda¡Le recomendamos encarecidamente que se una a nuestro canal en Discord para resolver dudas e interactuar con el equipo y otros colaboradores! 😉
Para llevar a cabo este proceso, es necesario tener algunos conocimientos:
¿No tienes ninguna de estas habilidades, pero quieres colaborar?Tenemos un equipo de datos que puede ayudarte, solo tienes que entrar en nuestro Discord y enviar un mensaje a #quiero-contribuir.
Mantenemos la lista de conjuntos para voluntarios en nuestro Github. Para empezar a subir una base que le interese, solo tiene que abrir una nueva incidencia de datos. Si su base (conjunto) ya aparece en la lista, solo tiene que marcar su usuario de Github como «assignee»
Tu primera tarea es completar la información en la incidencia. Esta información te ayudará a comprender mejor los datos y será muy útil para el tratamiento y la cumplimentación de metadatos.
Cuando finalices esta etapa, llama a alguien del equipo de datos para que la información que has mapeado sobre el conjunto se introduzca en nuestro sitio web.
Descarga aquí la carpeta
template
y renómbrala como <dataset_id> (definido en el paso 1). Esta carpeta de plantilla facilita y organiza todos los
pasos a partir de ahora. Su
estructura es la siguiente:
<dataset_id>/
code/: Códigos necesarios para capturar y limpiar los datos
(veremos más en el paso
4).input/: Contiene todos los archivos con los datos originales, tal y como
se descargaron de la fuente primaria. (veremos más en el paso
4).output/: Archivos finales, ya en formato listo para subir a la base de datos (veremos más en el paso
4).tmp/: Cualquier archivo temporal creado por el código en /code durante el proceso de limpieza y tratamiento ( veremos más en el paso
4).
extra/
architecture/: Tablas de arquitectura (veremos más en el paso 3).auxiliary_files/: Archivos auxiliares de los datos (veremos más en el paso 5).dicionario.csv: Tabla diccionario de todo el conjunto de datos (veremos más en el paso 6).Solo la carpetacodese confirmará en su proyecto, los demás archivos solo existirán localmente o en Google Cloud.
Las tablas de arquitectura determinan la estructura de cada tabla de su conjunto de datos. Definen, por ejemplo, el nombre, el orden y los metadatos de las variables, además de las compatibilidades cuando hay cambios en las versiones (por ejemplo, si una variable cambia de nombre de un año a otro).
Cada tabla del conjunto de datos debe tener su propia tabla de arquitectura (hoja de cálculo), que debe completarse en Google Drive para que nuestro equipo de datos pueda corregirla.
Las tablas de arquitectura de RAIS pueden consultarse aquí. Son una excelente referencia para comenzar su trabajo, ya que contienen muchas variables y ejemplos de diversas situaciones con las que se puede encontrar.
Al inicio y final de cada etapa consulta nuestro manual de estilo para garantizar que estás siguiendo la estandarización de BD
original_nameoriginal_name_YYYY para cada año o mes disponibletemporal_coverage de cada variable.directory_columnint64 o float64, compruebe si es necesario incluir una unidad de medidaCuando termines de completar las tablas de arquitectura, contacta con el equipo de Base de los Datos para validar todo. Es necesario que esté claro el formato final que los datos deben tener antes de empezar a escribir el código. Así evitamos el retrabajo.
Una vez validadas las tablas de arquitectura, podemos escribir los códigos de captura y limpieza de los datos.
Captura: Código que descarga automáticamente todos los datos originales y los guarda en /input. Estos datos pueden estar disponibles en portales o enlaces FTP, pueden extraerse de sitios web, entre otros.
Limpieza: Código que transforma los datos originales guardados en /input en datos limpios, los guarda en la carpeta /output, para posteriormente subirlos a la base de datos.
Cada tabla limpia para producción puede guardarse como un único archivo o, si es muy grande (por ejemplo, más de 200 MB), dividirse en el formato Hive en varios subarchivos. Los formatos aceptados son .csv o .parquet. Nuestra recomendación es dividir las tablas por ano, mes y sigla_uf. La división se realiza a través de la estructura de carpetas, vea el ejemplo a continuación para ver cómo.
La tabla microdados_vinculos de RAIS Vinculos, por ejemplo, es una tabla muy grande (+400 GB), por lo que la hemos particionado por año y sigla_uf. La partición se realizó utilizando la estructura de carpetas /microdados_vinculos/ano=YYYY/sigla_uf=XX .
.py, .R, ...) o notebooks (Google Colab, Jupyter, Rmarkdown, etc).<dataset_id>), es decir, no deben depender de las rutas de su
ordenador.El código de limpieza se ha creado en R y se puede consultar aquí.
El código de limpieza se ha creado en Python y se puede consultar aquí
Es habitual que las bases de datos se proporcionen con archivos auxiliares. Estos pueden incluir notas técnicas, descripciones de recolección y muestreo, etc. Para ayudar a los usuarios de la base de datos a tener más contexto y comprender mejor los datos, organice todos estos archivos auxiliares en /extra/auxiliary_files.
Siéntase libre de estructurar subcarpetas como desee dentro de esta carpeta. Lo importante es que quede claro qué son estos archivos.
A menudo, especialmente con bases antiguas, hay múltiples diccionarios en formatos Excel u otros. En la Base de Datos unificamos todo en un único archivo en formato .csv: un único diccionario para todas las columnas de todas las tablas de su conjunto.
Los detalles importantes sobre cómo construir su diccionario se encuentran en nuestro manual de estilo.
El diccionario completo se puede consultar aquí. Ya tiene la estructura estándar que utilizamos para los diccionarios.
¡Todo listo! Ahora solo falta subirlo a Google Cloud y enviarlo para su revisión. Para ello, utilizaremos el cliente basedosdados (disponible en Python), que facilita la configuración y los pasos del proceso.
Dado que el almacenamiento tiene un coste, para finalizar este paso necesitaremos proporcionarte una api_key específica para voluntarios para subir los datos a nuestro entorno de desarrollo. Para ello, entra en nuestro canal de Discord, envíanos un mensaje con «quiero-contribuir» y etiqueta a@equipe_dados.
7.1 En su terminal, instale nuestro cliente: pip install basedosdados.
7.2 Ejecute import basedosdados as bd en Python y siga los pasos para configurar localmente con las credenciales de su proyecto en Google Cloud. Rellene la información como se indica a continuación:
* PASO 1: y
* PASO 2: basedosdados-dev (coloque el .json proporcionado por el equipo de bd en la carpeta credentials)
* PASO 3: y
* PASO 4: basedosdados-dev
* PASO 5: https://api.basedosdados.org/api/v1/graphql
Los datos pasarán por tres lugares en Google Cloud:
7.3 Cree la tabla en el bucket de GCS y BigQuey-DEV-staging, utilizando la API de Python, de la siguiente manera:
import basedosdados as bd
DATASET_ID = "dataset_id"
TABLE_ID = "table_id"
tb = bd.Table(dataset_id=DATASET_ID, table_id=TABLE_ID)
tb.create(
path=path_to_data,
if_storage_data_exists="raise",
if_table_exists="replace",
source_format="csv"
)
Si tus datos están particionados, la ruta debe apuntar a la carpeta donde están las particiones. En caso contrario, debe apuntar a un archivo.csv(por ejemplo, microdados.csv).Si el proyecto no existe en BigQuery, se creará automáticamente.
7.4 Cree los archivos .sql y schema.yml a partir de la tabla de arquitectura para ejecutar la materialización y las pruebas en dbt (data build-tool):
from databasers_utils import TableArchitecture
arch = TableArchitecture(
dataset_id="<dataset-id>",
tables={
"<table-id>": "URL de la arquitectura de Google Sheet", # Ejemplo https://docs.google.com/spreadsheets/d/1K1svie4Gyqe6NnRjBgJbapU5sTsLqXWTQUmTRVIRwQc/edit?usp=drive_link
},
)
# Crea el archivo yaml
arch.create_yaml_file()
# Crea los archivos sql
arch.create_sql_files()
# Actualiza el dbt_project.yml
arch.update_dbt_project()
Si lo necesita, en este momento puede modificar la consulta en SQL para realizar tratamientos finales a partir de la tablastaging, puede incluir columnas, eliminar columnas, realizar operaciones algebraicas, sustituir cadenas, etc. ¡El SQL es el límite!
set_datalake_projectLos archivos sql de dbt utilizan la macro set_datalake_project, que indica de qué proyecto (basedosdados-staging o basedosdados-dev) se consumirán los datos. Al crear los archivos con la función create_sql_files, se insertará la macro.
select
col_name
from {{ set_datalake_project(«<DATASET_ID>_staging.<TABLE_ID>») }}
Materializa un único modelo por su nombre en basedosdados-dev consumiendo los datos de basedosdados-dev.{table_id}_staging
dbt run --select dataset_id__table_id
Materializa todos los modelos en una carpeta en basedosdados-dev consumiendo los datos de basedosdados-dev.{table_id}_staging
dbt run --select model.dateset_id.dateset_id__table_id
Materializa todos los modelos en la ruta en basedosdados-dev consumiendo los datos de basedosdados-dev.{table_id}_staging
dbt run --select models/dataset_id
Materializa un único modelo por la ruta del archivo sql en basedosdados-dev consumiendo los datos de basedosdados-dev.{table_id}_staging
dbt run --select models/dataset/table_id.sql
Prueba un único modelo
dbt test --select dataset_id__table_id
Prueba todos los modelos de una carpeta
dbt test --select model.dateset_id.dateset_id__table_id
Prueba todos los modelos de la ruta
dbt test --select models/dataset_id
7.6 Suba los metadatos de la tabla al sitio web:
Por ahora, solo el equipo de datos tiene permisos para subir los metadatos de la tabla al sitio web, por lo que será necesario ponerse en contacto con nosotros. Ya estamos trabajando para que, en un futuro próximo, los voluntarios también puedan actualizar los datos en el sitio web.
¡Ya está! Ahora solo queda enviar todo para revisión al repositorio de la Base de Datos.
dataset__table_id.sql en la carpeta pipelines/models/dataset_id/ copiando las consultas y el esquema que ha creado en el paso 7.pipelines/models/dataset_id/code¿Y ahora qué? Nuestro equipo revisará los datos y metadatos enviados a través de Github. Es posible que nos pongamos en contacto contigo para aclarar dudas o solicitar cambios en el código. Cuando todo esté bien, fusionaremos tu solicitud de extracción y los datos se publicarán automáticamente en nuestra plataforma.
Base de los Datos