La arquitectura de los sistemas de datos modernos está sufriendo un cambio fundamental. Pregunta a un desarrollador cómo construyen sistemas de datos hoy en día, y la respuesta cada vez más se ve así: Postgres para la aplicación, un lago para la analítica y la ciencia de datos. Postgres, desde hace mucho tiempo favorecido para las cargas de trabajo transaccionales, ha evolucionado en una base de datos operativa de propósito general. Es confiable, flexible y profundamente extensible, alimentando todo desde las transacciones del cliente y las aplicaciones CRUD, hasta los dashboards en tiempo real y las características de producto respaldadas por la IA. Su ecosistema ha crecido para soportar el análisis en tiempo real ( ), datos geoespaciales (PostGIS), búsqueda vectorial y de texto completo (pgvector y pgvectorscale), y más. TimescaleDB Al mismo tiempo, el auge de las tecnologías de lagos abiertos ha redefinido cómo las organizaciones gestionan y analizan datos a escala.El almacenamiento desagregado, los formatos de tablas abiertas como Iceberg, los catálogos de datos estructurados y los motores de consulta compostables han hecho posible analizar datos a escala de petabytes con precisión y control.Esta arquitectura puede ofrecer gobernanza, evitar el bloqueo de los proveedores y todavía proporcionar a los equipos de datos flexibilidad en su elección de herramientas. Lo que es sorprendente no es sólo el éxito de estas tecnologías individualmente, sino la frecuencia con la que ahora se están desplegando juntas.Las organizaciones necesitan cada vez más apoyar tanto las cargas de trabajo operativas (alimentadas por bases de datos) como las cargas de trabajo no operativas (alimentadas por lagos), a menudo utilizando datos de las mismas fuentes – personas, máquinas, sistemas digitales o agentes. En realidad, creemos que está surgiendo una nueva arquitectura más coherente: una que trata a Postgres y el lago no como mundos separados, sino como capas distintas de un sistema único y modular, diseñado para satisfacer el espectro completo de necesidades operativas y analíticas. Los límites de la dicotomía OLTP vs. OLAP La vieja forma de pensar sobre las bases de datos era simple: OLTP para transacciones, OLAP para análisis. Usted usó Postgres para alimentar su aplicación, y envió trabajos ETL nocturnos a un almacén de datos para informes internos y dashboards.Esta distinción tradicional nos sirvió bien cuando las aplicaciones eran más simples, y la notificación interna podría vivir en una cadencia mucho más lenta. Las aplicaciones modernas son pesadas en datos, orientadas al cliente y en tiempo real por diseño. 
 
 
 
 Una aplicación financiera podría ejecutar un motor de negociación que necesita acceso milisegundo a las carteras de clientes, mientras que al mismo tiempo alimenta los informes de riesgo en tiempo real y los dashboards internos. Una aplicación SaaS no es solo almacenar clics, sino calcular métricas de uso, desencadenar alertas y servir modelos personalizados. Un sistema de monitoreo industrial podría ingerir decenas de millones de lecturas de sensores por hora, impulsar la detección de anomalías y la lógica de alerta, y archivar años de telemetría para análisis a largo plazo y capacitación de modelos de IA. Estos casos de uso no son extraños - se están convirtiendo rápidamente en la norma. We increasingly see a more useful split: operational databases that power products, and lakehouses that power organizations. Sin embargo, a pesar de que la propiedad de estos tipos de sistemas están divididos – los equipos de ingeniería de productos responsables de los sistemas operativos que alimentan sus productos, y los equipos de datos responsables de la gestión de los sistemas de lagos como servicios organizativos – los dos todavía necesitan hablar entre sí. Arquitectura Operacional Medallion Un patrón que vemos ganando tracción es lo que llamamos Inspirado en los modelos de medallion popularizados en el mundo de la ingeniería de datos, este patrón también incorpora capas de bronce, plata y oro - no solo para el análisis interno, sino también para alimentar sistemas en tiempo real orientados al usuario. Arquitectura operativa Medallion Aquí está lo que parece: 
 
 
 
 Layer de bronce: Los datos brutos viven en archivos de Parquet o Iceberg en AWS S3 o sistemas de almacenamiento sin fondo de bajo costo similares. Estos datos suelen ser inmutables, únicamente en apéndices y pueden ser consultados por cualquier cosa: motores de consultas como AWS Athena, DuckDB, Trino, ClickHouse o Polars, o incluso directamente de una base de datos operativa como Postgres. La capa de plata operativa: los datos limpios, filtrados, validados y deduplicados se escriben en Postgres para alimentar la analítica en tiempo real, los dashboards o la lógica de las aplicaciones de los productos orientados al usuario. Layer de oro operativo: Los datos preagregados sobre los datos de plata (como las vistas materializadas de Postgres o los agregados continuos de TimescaleDB) sirven a experiencias de producto de baja latencia y alta competencia. Crucialmente, cada capa es interrogable, y este movimiento de datos es bidireccional. Puede sacar datos crudos o transformados de S3 directamente a Postgres (acaso a ETL reverso estrechamente integrado). Puede rollar agregados de Iceberg a las tablas de Postgres (por consulta única o de pie contra archivos de Iceberg de Postgres). Puede sincronizar continuamente un esquema completo o una tabla única de la base de datos al lago. Al igual que los datos de bronce (o transformados) se pueden leer de la capa de almacenamiento del lago en S3 a la base de datos, la plata y el oro en la base de datos se pueden escribir a estos formatos de almacenamiento del lago. Un patrón común que hemos observado en las aplicaciones que requieren datos frescos es escribir desde un sistema de streaming de arriba como Kafka o Kinesis tanto a S3 (para la fila, datos de bronce no modificados) como a Postgres (dependiendo de esquemas de bases de datos y restricciones para la validación de datos).Después, estas tablas de plata y los agregados de oro subsiguientes en la base de datos se exportan a S3 de nuevo, por lo que los equipos de datos ahora tienen acceso a los "datos de verdad de la tierra" que se habían servido a los clientes. En paralelo Ahora, cada sistema mantiene su separación de preocupaciones.La base de datos operativa puede ejecutarse bloqueada - tanto para usuarios como para consultas no amigables - mientras que los datos todavía se ponen a disposición como parte del lago abierto donde sea necesario en la org. ¿Por qué ahora? las fuerzas técnicas que impulsan el cambio Varios desarrollos están impulsando este cambio de las bases de datos operativas y los lagos de ser siloados a integrados. En primer lugar, Iceberg ha madurado en un formato de tabla estable y flexible que soporta la evolución del esquema, las transacciones ACID y la compactación eficiente. Permite a múltiples motores de computación leer y escribir a los mismos conjuntos de datos - con capas de catálogo que rastrean metadatos y aplican la gobernanza a través de la pila. En segundo lugar, Postgres ha continuado evolucionando como una plataforma.Con extensiones para almacenamiento en columnas, datos de series temporales y búsqueda vectorial y híbrida – lo que hemos estado construyendo en Timescale durante años – Postgres ahora sirve a muchos productos que incorporan análisis en tiempo real y flujos de trabajo de agentes directamente.Y con el soporte emergente para la consulta de datos de S3 e Iceberg directamente desde dentro de Postgres, es cada vez más posible incorporar datos alojados en S3 directamente. Esta no es solo una capa de caché de datos para los datos pre-calculados, sino una base de datos SQL completa para agregar, enriquecer o agregar en el momento de la consulta. now acts as the serving layer for products incorporating both transactional and analytical data En tercer lugar, los desarrolladores esperan compostabilidad.Algunas organizaciones pueden estar atrapadas con sus plataformas de datos monolíticos legados, pero la mayoría de los desarrolladores y científicos de datos quieren flexibilidad para componer sus propias pilas, integrando herramientas familiares de maneras que reflejen las necesidades de su aplicación.El cambio hacia formatos abiertos y almacenamiento desagregado se ajusta a esta mentalidad. Put differently: the market is moving toward modular, open, developer-friendly architectures. Lo que viene después Creemos que el futuro de la infraestructura de datos será modelado por sistemas que integran las capas operativas y analíticas más profundamente – sistemas que tratan a Postgres y el lago como dos lados de la misma moneda. Esto no sucederá a través de otro monolito.Vendrá de interfaces cuidadosas - sincronización incremental, catálogos compartidos, superficies de consulta unificadas- y de una filosofía arquitectónica que abraza la heterogeneidad en lugar de combatirla. Estamos trabajando en algo nuevo en este espacio.Algo que se basa en los puntos fuertes de Postgres e Iceberg, se integra estrechamente con los sistemas de lagos existentes, y hace que sea dramáticamente más fácil construir sistemas de datos completos con fidelidad operativa y analítica. No se trata de usar ETL para mover datos de sistemas antiguos a nuevos sistemas, se trata de construir una arquitectura de datos moderna coherente que sirva casos de uso operativos y no operativos, igualmente. Quédate atento

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Este audio es producido en el idioma original de la historia!

Postgres y el lago se convierten en un sistema - aquí está lo que viene a continuación

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Una breve introducción a la teoría del cerebro de Boltzmann

Cómo mejorar su flujo de trabajo 10 veces: 17 aplicaciones esenciales

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Una breve introducción a la teoría del cerebro de Boltzmann

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps