Guía de formatos de serialización de datos: Parquet, Avro, Proto y más
En el mundo de la ingeniería de datos y el desarrollo de software, la forma en que almacenamos y transmitimos los datos es fundamental. Si bien JSON es el rey de las API web debido a su legibilidad, a menudo es demasiado voluminoso o lento para el procesamiento de grandes volúmenes de datos, la mensajería de alta frecuencia o la depuración especializada.
Esta guía explora las extensiones de archivo especializadas que se utilizan para la serialización de datos más allá del JSON y el CSV básicos.
Tabla de referencia rápida: Formatos de serialización de datos
| Extensión | Nombre completo | Formato | Caso de uso principal |
|---|---|---|---|
.ndjson, .jsonl |
JSON delimitado por nuevas líneas | Texto (ASCII) | Archivos de registro, transmisión de datos, importaciones de Big Data |
.parquet |
Apache Parquet | Binario (Colummar) | Análisis de Big Data (Hadoop, Spark, AWS S3) |
.avro |
Apache Avro | Binario (Basado en filas) | Serialización de datos con esquemas (Kafka) |
.proto |
Protocol Buffers | Texto (DSL) | Definición de interfaces gRPC y estructuras de datos |
.bson |
JSON binario | Binario | Almacenamiento e intercambio de datos en MongoDB |
.cbor |
Representación concisa de objetos binarios | Binario | IoT, entornos de bajo ancho de banda |
.har |
Archivo HTTP | Texto (JSON) | Depuración de solicitudes de red en navegadores |
.edn |
Notación de datos extensible | Texto (tipo Lisp) | Ecosistema Clojure, configuración de metadatos |
1. JSON apto para streaming (.ndjson, .jsonl)
El JSON estándar requiere que todo el archivo se lea en la memoria para poder analizarlo (comienza con [ y termina con ]). Esto es imposible para archivos de registro de 100 GB.
- NDJSON / JSONL: Cada línea es un objeto JSON válido e independiente.
- ¿Por qué usarlo? Puede leer un archivo línea por línea sin cargar todo el contenido. Si el archivo se trunca o se corrompe, solo pierde la última línea, no todo el conjunto de datos.
2. Almacenamiento columnar para Big Data (.parquet, .orc)
Las bases de datos tradicionales almacenan los datos fila por fila. Las bases de datos analíticas a menudo prefieren el almacenamiento columnar.
- Parquet: El estándar de la industria para Big Data. Debido a que almacena los datos por columna, puede comprimir los datos de manera mucho más efectiva y le permite "saltarse" columnas que no necesita para una consulta específica.
- ORC: Optimized Row Columnar. Similar a Parquet pero utilizado principalmente en el ecosistema Apache Hive.
3. Serialización con esquema previo (.avro, .proto)
A diferencia de JSON, donde los nombres de las claves ("first_name") se repiten en cada registro, los formatos con esquema previo separan las "reglas" de los "datos".
- Avro: El esquema se almacena como JSON, pero los datos son binarios. Es el estándar para Apache Kafka porque es rápido y admite la evolución del esquema.
- Protobuf (.proto): Desarrollado por Google. Usted define su estructura de datos en un archivo
.protoy luego un compilador genera código para su lenguaje preferido. Es la columna vertebral de gRPC.
4. Alternativas binarias a JSON (.bson, .cbor, .msgpack)
Si le gusta la flexibilidad de JSON pero necesita más velocidad o archivos de menor tamaño, los formatos binarios son la respuesta.
- BSON: Utilizado internamente por MongoDB. Admite más tipos de datos que JSON (como fechas y datos binarios).
- CBOR: Diseñado para ser extremadamente pequeño y eficiente. Se usa ampliamente en dispositivos IoT (Internet de las cosas) donde cada byte de ancho de banda cuenta.
- MessagePack: Similar a CBOR, es "como JSON pero rápido y pequeño".
5. Formatos especializados (.har, .edn)
- HAR (HTTP Archive): Si alguna vez ha "exportado" un rastro de red desde las herramientas de desarrollo de Chrome o Firefox, es un archivo
.har. En realidad, es solo un archivo JSON masivo que contiene cada encabezado, cookie y cuerpo de respuesta de su sesión de navegación. - EDN: Utilizado principalmente en el mundo de Clojure. Es más potente que JSON porque admite tipos personalizados (etiquetas) y estructuras de datos más complejas de forma nativa.
Cómo ver estos archivos
- NDJSON/JSONL: Use cualquier editor de texto o la herramienta de línea de comandos
jq. - Parquet: Requiere visores especializados o bibliotecas de Python (como
pandasofastparquet). - Protobuf: Por lo general, necesita el archivo de definición
.protopara decodificar los datos binarios. - HAR: Puede arrastrarlo y soltarlo nuevamente en las herramientas de desarrollo de Chrome/Firefox o usar un Visor de HAR en línea.
Preguntas frecuentes (FAQ)
P: ¿Por qué mi archivo Parquet es más pequeño que mi CSV?
R: Parquet utiliza técnicas de compresión avanzadas como la "codificación de diccionario" y la "codificación por longitud de racha". Dado que almacena los datos por columna, los valores en una columna (como "País") suelen ser idénticos, lo que permite relaciones de compresión masivas en comparación con los archivos de texto.
P: ¿Puedo editar un archivo .proto?
A: Sí, los archivos .proto son archivos de texto legibles por humanos donde usted define sus estructuras de datos. Sin embargo, no puede "editar" directamente los datos binarios producidos a partir de él; debe usar el código compilado.
P: ¿Es .bson lo mismo que JSON?
R: No exactamente. BSON es una representación binaria que incluye datos similares a JSON pero también agrega tipos como Buffer, Long y Decimal128 que el JSON estándar no admite.
Herramientas relacionadas en Tool3M
- Conversor de JSON a CSV: Convierta sus datos estructurados en una tabla plana.
- Guía de serialización binaria: Obtenga más información sobre Protobuf y MessagePack.