Data Engineering 6 - Extracción y Carga de Datos con Python
Publicado:
mié, 7/1/2026
| Actualizado:
mié, 7/1/2026
Una guía de librerías que no vas a querer perderte
Introducción
Cuando hablamos de Data Engineering, gran parte del trabajo empieza siempre en el mismo lugar: conectarse a un sistema y traer datos.
En Python, esto se resuelve con librerías que funcionan como “traductores” entre nuestro código y esos sistemas. ¿Qué librerías tenemos disponibles para extraer datos de una fuente y luego cargarlos en el destino elegido?
En este post vamos a repasar las librerías mas populares y una breve descripción de cada una. Ideal si te estás familiarizando con el rol, venís de otro rol como backend y estás buscando transicionar a Data Engineering o tan solo querés profundizar en el ecosistema de Python. Vamos al grano.
Drivers de bases de datos
Esta categoría involucra a todas aquellas librerías que nos permiten comunicarnos con bases de datos desde Python.
Podemos entender a un driver como un “traductor” que se encarga de facilitarnos la conexión con una base de datos, encapsulando y abstrayendo múltiples operaciones intermedias para que nosotros podamos concentrarnos únicamente en qué queremos decirle a la base de datos objetivo, y no en cómo hacerlo a bajo nivel.
Un driver requiere el uso de credenciales de autenticación (por ejemplo, usuario y contraseña, certificados, llaves privadas para conexiones vía SSH, entre otros) para crear una conexión. Una vez establecida dicha conexión —que en términos prácticos suele ser un objeto, es decir, una instancia de una clase provista por la librería— podemos:
o interactuar con la base de datos sin escribir SQL directamente, a través de lo que se conoce como un ORM (Object-Relational Mapper)
Independientemente del enfoque que elijamos (SQL directo u ORM), en líneas generales podremos:
leer datos desde la base de datos (SELECT ...)
cargar o modificar datos en la misma (INSERT, UPDATE, DELETE, etc.)
Te comparto 4 librerías que muy probablemente necesites utilizar en algún punto de tu carrera:
psycopg2: si necesitás comunicarte con una base de datos PostgreSQL, este ha sido históricamente uno de los conectores más utilizados en el ecosistema Python.
Nota: investigando esta librería al momento de escribir este artículo, aparece su versión más moderna bajo el nombre de psycopg (versión 3). Según sus creadores, psycopg2 queda principalmente para mantenimiento de aplicaciones existentes, mientras que para nuevos proyectos se recomienda comenzar directamente con psycopg. Más info acá.
sqlite3: integrada nativamente en Python (import sqlite3), por lo que no requiere instalación adicional. Esta librería, escrita en C, provee acceso a una base de datos ligera basada en disco (se almacena como un archivo más en tu sistema) y que no requiere un servidor dedicado. Es especialmente útil para prototipar aplicaciones o desarrollar soluciones simples que luego pueden migrarse a motores más robustos como PostgreSQL, MySQL u Oracle.
pandas: un verdadero caballito de batalla en el mundo de los datos, y no solo para Ingenieros de Datos. Si bien su foco principal no está en la extracción y carga de datos sino en su manipulación eficiente, ofrece múltiples funcionalidades para leer información desde distintos formatos (CSV, TXT, XLSX, FWF, entre otros), cargarla en memoria mediante estructuras llamadas DataFrames, y luego exportarla nuevamente a archivos o incluso a bases de datos. Internamente, para estas operaciones, pandas se apoya en otros drivers o conectores (por ejemplo, psycopg para PostgreSQL). Como alternativa moderna existe polars, con un propósito y una sintaxis muy similares, pero implementado en Rust, lo que le permite destacar en rendimiento y uso de memoria en ciertos escenarios.
duckdb: una base de datos analítica embebida que puede utilizarse directamente desde Python. Permite ejecutar consultas SQL de forma muy rápida y eficiente sobre datasets grandes, incluyendo DataFrames de pandas, archivos CSV o formatos columnar como Parquet. No requiere un servidor independiente, lo que la vuelve comparable a sqlite3 en cuanto a simplicidad de uso, pero orientada a workloads analíticos en lugar de transaccionales.
Muchos proveedores de nube pública, como AWS, GCP y Azure, cuentan con su propio SDK (Software Development Kit) que nos permite interactuar de forma programática con los servicios que ofrecen. En otras palabras, podemos crear, modificar y eliminar recursos desde nuestro lenguaje de programación favorito, en lugar de hacerlo exclusivamente a través de la interfaz web.
En el contexto de pipelines de datos, estos SDK suelen utilizarse para extraer datos desde servicios de almacenamiento de objetos como S3 (AWS) o Cloud Storage (GCP) y, luego del procesamiento o transformación correspondiente, cargarlos nuevamente en el mismo servicio o en otro distinto. Un patrón común es almacenar los datos crudos y los datos procesados en rutas diferentes dentro del mismo bucket (por ejemplo, distintos prefijos en S3), aunque también es habitual cargar los resultados finales en servicios como RDS (bases de datos gestionadas en AWS) o Azure SQL Database.
A continuación, un breve repaso de cómo se organiza el acceso a estos servicios en cada proveedor:
Google Cloud Platform (GCP): la nube de Google ofrece librerías específicas por servicio (por ejemplo, almacenamiento, BigQuery, Pub/Sub, etc.). Este enfoque permite instalar únicamente los clientes necesarios, dando mayor control sobre las dependencias y manteniendo un entorno de desarrollo más liviano.
Azure: presenta una estrategia similar a la de GCP. Se eligen una o más librerías en función de los servicios con los que se necesite interactuar, lo que favorece una gestión más granular de dependencias.
AWS: Amazon optó por un enfoque distinto y centralizó el acceso a sus servicios en boto3, el SDK oficial de AWS para Python. A través de una única instalación, es posible interactuar con prácticamente todos los servicios de AWS mediante dos abstracciones principales: clients y resources. Ambas permiten realizar operaciones similares, pero con distintos niveles de abstracción y ergonomía. ¿Te gustaría que arme una guía rápida para empezar a usar boto3? Hace ya un par de años que lo utilizo y, si bien siempre hay algo nuevo por aprender, creo que puedo aportar una buena base práctica. Decime en los comentarios si te interesaría. 😊
Muchos sistemas exponen datos mediante APIs. Es por ello que las APIs son consideradas en la lista de source systems (sistemas fuente), lugares desde donde debemos extraer datos para transformación y posterior carga.
En términos generales, al comunicarnos con una API lo que hacemos es enviar una petición HTTP (por ejemplo, GET, POST, PUT, etc.), acompañada de ciertos parámetros, encabezados y, en algunos casos, un cuerpo (body). Como respuesta, la API nos devuelve los datos solicitados, habitualmente en formatos como JSON o XML.
requests: probablemente la librería más conocida para realizar peticiones HTTP en Python. No es la única opción disponible, pero sí una de las más simples y amigables de usar. Su principal limitación es que no soporta asincronismo de forma nativa, lo cual puede ser una desventaja en escenarios I/O bound (por ejemplo, cuando realizamos muchas llamadas a APIs externas). En serio: investigá sobre concurrencia y paralelismo, porque tarde o temprano lo vas a necesitar en este contexto.
HTTPX: una librería moderna que ofrece soporte tanto sincrónico como asincrónico, con una sintaxis muy similar a requests. Hace un uso intensivo de type annotations, una característica de Python que vale la pena incorporar, ya que mejora la legibilidad del código y facilita el trabajo con herramientas de análisis estático.
AIOHTTP: una librería puramente asíncrona, orientada a alto rendimiento y muy eficiente en escenarios que requieren alta concurrencia. Trabajar con concurrencia no siempre es sencillo de implementar ni de debuggear, pero es una habilidad clave en sistemas de datos y, en algún momento, conviene “pelearse” con este tipo de herramientas para entenderlas bien.
Este apartado puede subdividirse en dos grandes grupos: archivos locales (los que tenés en tu computadora o en el filesystem del entorno donde corre tu código) y archivos que deben extraerse desde o cargarse hacia servidores que utilizan protocolos como FTP y/o SFTP.
Archivos locales
csv: librería estándar de Python (es decir, no hace falta instalar nada) para trabajar con archivos separados por comas. Ojo igual: el nombre engaña, porque el delimitador no siempre es una coma. Muchas veces vas a encontrarte con ;, | u otros separadores, así que no conviene confiarse. También es común utilizar esta librería para leer archivos .txt que sigan una estructura tabular similar.
Excel: acá decidí invertir el enfoque y, en lugar de mencionar una sola librería, hablar directamente del tipo de archivo. Y es que lidiar con Excel suele ser todo un desafío. Los datos rara vez vienen bien organizados (hay gente que los usa como si fuera Canva o Paint… mejor no profundizar), y si el archivo es grande, podés encontrarte con problemas de memoria. A diferencia de otros formatos, los archivos Excel no están pensados para ser leídos de forma verdaderamente streaming, por lo que en muchos casos terminan cargándose completos en memoria. Dicho esto, ¿qué librerías existen para lidiar con estos subproductos de Satanás?
openpyxl: una de las librerías más conocidas y confiables para trabajar con archivos Excel en formato moderno (.xlsx, Excel 2010 en adelante). Es una opción sólida para la mayoría de los casos.
python-calamine: una alternativa muy rápida y robusta, especialmente útil cuando la estructura interna del archivo no puede ser interpretada correctamente por openpyxl. Personalmente, me ha salvado más de una vez en escenarios complicados.
Docs: (no pude encontrar docs, asi que si tenés el link por ahí, avisame y lo coloco acá)
xlrd: llibrería pensada exclusivamente para leer archivos Excel en formato antiguo (.xls). Importante: no sirve para archivos .xlsx. En mi opinión, hoy en día solo la usaría como failover cuando necesito leer un .xls y las otras alternativas no funcionan o no aplican.
Recomendación: si vas a lidiar frecuentemente con archivos Excel, pandas puede alivianarte bastante el proceso.
A través de métodos como read_excel, podés importar los datos del archivo directamente a un DataFrame, una estructura en memoria que ofrece muchas abstracciones y utilidades para trabajar con datos tabulares.
Internamente, pandas se apoya en varias de las librerías mencionadas anteriormente. Mediante el argumento engine de read_excel, podés alternar entre distintos motores de lectura.
Esto resulta muy útil para implementar estrategias de fallback: por ejemplo, si openpyxl no logra parsear un archivo, podés capturar la excepción y volver a intentar usando calamine como motor alternativo.
Servidores FTP/SFTP
Estos servidores se utilizan típicamente para proveer o intercambiar datos con clientes o terceros fuera de tu compañía. Como Data Engineer, es bastante común tener que conectarse a este tipo de servidores para extraer datos de un cliente, realizar procesos de transformación y limpieza, y luego devolver el resultado ya sea en una ruta específica del mismo servidor o cargándolo en un data warehouse como Snowflake para su posterior análisis.
Hay varios puntos importantes a tener en cuenta al trabajar con este tipo de servidores:
FTP: si el protocolo a utilizar es FTP, la conexión es relativamente simple, pero insegura. Aunque se maneje autenticación mediante usuario y contraseña, las credenciales y los datos suelen viajar en texto plano, lo cual hace tiempo dejó de ser una opción aceptable desde el punto de vista de seguridad.
ftplib: librería estándar de Python (nuevamente, sin necesidad de instalaciones adicionales). Permite automatizar tareas típicas sobre servidores FTP, como conectarse, listar directorios, descargar archivos y subir resultados procesados.
SFTP: acá la historia cambia. Este protocolo funciona sobre SSH, lo que implica una conexión segura, pero también un manejo más cuidadoso de la autenticación. En la práctica, suele requerirse el uso de llaves públicas y privadas, aunque también es posible combinar llaves con usuario y contraseña según la configuración del servidor.
paramiko: librería que implementa el protocolo SSHv2 y permite realizar prácticamente las mismas operaciones que ftplib, pero sobre una conexión segura. Un detalle a tener en cuenta es que paramiko es relativamente pesada en tamaño, lo cual puede convertirse en un problema en entornos con límites estrictos de despliegue. Por ejemplo, si tu aplicación Python se ejecuta como una función AWS Lambda, es posible que el peso total del paquete supere el límite permitido. En esos casos, suele ser necesario recurrir a Lambda Layers u otras estrategias de empaquetado. Si necesitás ayuda con este contexto de despliegue en particular, escribime 😉
Como vimos, existen muchas librerías en Python para extracción y carga de datos. El truco es elegir la herramienta adecuada para la situación correcta.
Además, está bueno saber que Python de por sí viene equipado con librerías para distintos escenarios, por lo que salir corriendo a instalar librerías de terceros no siempre tiene que ser la mejor alternativa.
¿Crees que falta alguna librería para agregar? ¿Hay algo que debería corregir? Escribime por X o LinkedIn (links en footer), siempre estoy atento a cualquier feedback que puedan darme. La idea no es demostrar quién sabe más, sino llegar a las conclusiones correctas mediante información precisa.
Próximamente, vamos a charlar sobre cómo abordar el proceso de transformación de datos en Python a través de librerías.
PD: te odio Excel.
Este contenido salió primero en mi newsletter “El Ingeniero Consciente”, varios días antes de publicarse como blog post. ¿Te gustaría recibir este tipo de material antes que nadie, directo en tu correo y totalmente gratis? ¡Sumate con este enlace!
