DataLake

[ramirezosvaldo]

Hola,

Quiero compartirles mis avances.

Llega a un momento que almacenamos mucha informacion con los clientes, y que en muchas ocaciones borramos
tanto de las bases de datos como archivos para que nuestros sistemas puedan seguir funcionado de manera rapida.
( No sin antes respaldar todo )

Y aparte nuestros clientes nos piden informacion para hacer analisis estadisticos y debemos tomar datos historicos, datos que ya no
estan en nuestras bases de datos.

Aqui es cuando el concepto Datalake entra en juego.

Como dato, tengo una tabla de 104 Millones de registros, en mariaDB , la misma tabla en Postgresql y la misma tabla
migrada al Datalake.

Un query como este:

SELECT
idproveed,
COUNT(*) as total_articulos,
AVG(precio) as precio_promedio,
MIN(fecha) as primera_fecha,
MAX(fecha) as ultima_fecha
FROM lstpre
GROUP BY idproveed
ORDER BY total_articulos DESC

En MariaDB Local se tardo 3m 53s
En Postgresql local se tardo 17s
En Trino local se tardo 2.197s

Todo mi ambiente de pruebas esta en una computadora con 32gb memoria, 2Tb nvme y un AMD Ryzen 5700g ( 8 Nucles fisicos,16 procesadores logicos ), usando LinuxMint

Esta semana quiero instalar dos nodos ( dos computadoras viejas ) al Datalake, para ver si el aumento de procesamiento y velocidad.

Las ventajas de tener un DataLake son enormes, Ojo, eso no es para sustituir lo que esta en vivo, esto es para analisis.
Y tambien, no es para subir todo al Datalake, hay que seguir ciertas reglas como son las del ETL.

Anexo un par de imagenes

1.- Caracteristicas del la computadora
2.- Un pantalla de como se ve cuando estaba migrando de MariaDB a PostgreSQL
3.- Herramientas que componen mi datalake

Estare comentado mis avances ...

Saludos a todos!
Osvaldo Ramirez

[ramirezosvaldo]

Les comparto otro filtro/query dentro de la misma tabla, es un poco mas complejo, y los resultados son:

MariaDB 20m 31s
Postgresql 27s
Trino entre >= 2.4s y <= 2.8s

WITH FilteredCatalog AS (
-- Filter out the supplier placeholder and isolate supplier 5 upfront
SELECT barcode, fecha, codint
FROM lstpre
WHERE idproveed = 5
AND codint IS NOT NULL
AND codint != '00000000'
),
MaxCatalogDate AS (
-- Finds the most recent date the supplier sent a catalog to act as our "Today"
SELECT MAX(fecha) AS max_fecha_overall
FROM FilteredCatalog
),
BarcodeLifecycles AS (
-- Groups the data to find the exact lifespan of every barcode per product
SELECT
codint,
barcode,
MIN(fecha) AS first_seen,
MAX(fecha) AS last_seen
FROM FilteredCatalog
GROUP BY codint, barcode
),
BarcodeHistory AS (
-- Uses window functions to look forward and backward in time for each codint
SELECT
b.codint,
b.barcode,
b.first_seen,
b.last_seen,
LAG(b.barcode) OVER (PARTITION BY b.codint ORDER BY b.first_seen ASC) AS prev_barcode,
LEAD(b.barcode) OVER (PARTITION BY b.codint ORDER BY b.first_seen ASC) AS next_barcode,
LEAD(b.first_seen) OVER (PARTITION BY b.codint ORDER BY b.first_seen ASC) AS next_barcode_first_seen,
MAX(b.last_seen) OVER (PARTITION BY b.codint) AS codint_latest_seen,
m.max_fecha_overall
FROM BarcodeLifecycles b
CROSS JOIN MaxCatalogDate m
)
-- Assembles the final historical log with clear status flags and transition dates
SELECT
codint,
barcode,
first_seen,
last_seen,
prev_barcode,
next_barcode,
CASE
WHEN next_barcode IS NOT NULL AND last_seen >= next_barcode_first_seen THEN 'Superseded (With Overlap)'
WHEN next_barcode IS NOT NULL THEN 'Superseded (Clean Cut)'
WHEN next_barcode IS NULL AND codint_latest_seen < max_fecha_overall THEN 'Discontinued entirely'
ELSE 'Current Active SKU'
END AS sku_status,
next_barcode_first_seen AS new_sku_introduction_date,
CASE
WHEN next_barcode IS NOT NULL THEN last_seen
ELSE NULL
END AS old_sku_deprecation_date
FROM BarcodeHistory
-- CRITICAL UPDATE: Filter the final output to focus strictly on 2025 - Present action
WHERE first_seen >= DATE '2025-01-01'
OR last_seen >= DATE '2025-01-01'
OR next_barcode_first_seen >= DATE '2025-01-01'
ORDER BY codint ASC, first_seen ASC;

Hasta ahorita el ganador con millones de registros en tablas SQL seria Postgresql vs MariaDB.
Y no hay duda que tener un datalake ayuda enormemente en realizar querys, es superior!

Saludos