RTL Alemania reinventó su lago de datos centralizado, pasando de la retención estándar de 30 días a 90 días, reduciendo casi a la mitad la cantidad de nodos y finalizando la migración sin pérdida de datos.
Resumen
RTL Alemania ejecuta un lago de datos Elastic a nivel empresarial que ha crecido durante casi una década hasta convertirse en la plataforma estándar para el logging, los datos de aplicaciones y la inteligencia empresarial en todos los departamentos. Un límite de almacenamiento local de 100 TB había restringido la retención estándar a aproximadamente 30 días, lo que impedía a los equipos analizar cómo evolucionaban los KPI a lo largo de los meses y obligaba a que los datos de cumplimiento residieran en cubetas S3 separadas fuera del lago de datos consultable. Con el paso de Platino a Empresarial y el nuevo diseño de las snapshots buscables y del nivel congelado, la retención estándar se triplicó a 90 días, la capacidad combinada creció a 235 TB en el mismo espacio con licencia, la huella del hipervisor se redujo de 18 a 10 nodos físicos y todo el corte terminó con cero tiempo de inactividad y cero pérdida de datos.
Un lago de datos que alcanza su límite de almacenamiento
El lago de datos Elastic de RTL Alemania abarca casi una década de logging a nivel empresarial, datos de aplicaciones e inteligencia empresarial en el sector de la radiodifusión y los medios. En 2024, el lago se estaba topando con un límite. Aproximadamente 100 TB de almacenamiento local limitaba la retención estándar a unos 30 días, pero varios departamentos necesitaban meses de datos históricos para seguir cómo evolucionaron los KPI a lo largo del tiempo, y los datos de cumplimiento sujetos a una expectativa de retención de seis meses según la política interna permanecían fuera de la plataforma buscable en cubetas S3 separadas. Con el paso de Platino a Empresarial y el nuevo diseño de las snapshots buscables y del nivel congelado, RLT Alemania triplicó la retención estándar a 90 días, la capacidad combinada creció a 235 TB en el mismo espacio con licencia, la huella del hipervisor bajó de 18 a 10 nodos físicos y todo el corte terminó con cero tiempo de inactividad y cero pérdida de datos.
"A los equipos que trabajan en inteligencia de negocios no les alcanzó con treinta días. Querían ver cómo evolucionaban los KPI a lo largo de los meses, y no podíamos proporcionárselo debido a la limitación de almacenamiento. Ahora estamos en un estándar de 90 días, y algunos sets de datos un año completo".
Los bloques de 30 días no son solo un historial más largo, sino una clase de preguntas: comparaciones trimestrales, ciclos estacionales año tras año, líneas de base lo suficientemente largas para hacer creíble una línea de tendencia. Para los usuarios de BI de RTL Alemania, el lago de datos contenía los datos operativos pero no cumplía las expectativas cuando comenzaban las preguntas analíticas. Con 90 días de historia estándar y un año completo en algunos índices, esa clase de pregunta ahora se puede responder dentro del mismo lago de datos que los equipos operativos están viendo en vivo, contra los mismos datos, sin exportarlos a otro lugar.
Ese resultado depende de dos transiciones distintas a lo largo de la vida útil de la plataforma: una consolidación en 2023 en Elastic tras una fusión corporativa que incorporó una segunda plataforma de logging, y la posterior actualización de licencias que transformó la arquitectura de almacenamiento para que la retención pudiera triplicarse sin aumentar la huella licenciada.
Cómo RTL Alemania llegó aquí
El entorno Elastic de RTL Elastic comenzó como una herramienta de infraestructura compartida hace casi una década y creció, equipo por equipo, hasta convertirse en un lago de datos a nivel empresarial. Dos sucesos definieron la plataforma actual.
El primero fue una consolidación posterior a la fusión en 2023. Una nueva entidad de la compañía llegó operando una plataforma de logging diferente. El entorno Elastic de RTL Alemania ya era local con capacidad de sobra, y ejecutar dos plataformas en paralelo no tenía sentido financiero ni operativo. La migración fuera de la herramienta de logging heredada se ejecutó durante unos cinco meses, siendo el mayor esfuerzo la comunicación, la reconstrucción de los dashboards y los flujos de trabajo de notificaciones que el equipo construyó durante años, y la reestructuración de los pipelines de ingesta.
El segundo fue el límite de almacenamiento y la solución. Después de ver snapshots buscables y el nivel congelado en Elastic{ON} Munich, el equipo vio un diseño que coincidía directamente con el problema de almacenamiento: mantener la huella de la licencia, mover los datos long-tail al almacenamiento congelado respaldado por S3 y usar el espacio libre del nivel caliente para extender la retención. Antes de comprometerse, el equipo construyó una prueba de concepto centrada en la única pregunta que importaba: ¿Qué tan rápido se ejecutarían las consultas contra datos más antiguos en el nivel congelado? El resultado fue lo suficientemente rápido como para que la decisión de rediseñar todo el clúster, pasando de caliente-frío a caliente-congelado, fuera sencilla.
Antes: superar el margen de 30 días
Antes del rediseño, la retención estándar de RTL Alemania estaba limitada a aproximadamente 30 días por 100 TB de almacenamiento local. El lago de datos estaba funcionando correctamente, pero tres realidades operativas estaban al límite al mismo tiempo.
Las necesidades de inteligencia empresarial superaron los 30 días. Algunos departamentos querían seguir cómo evolucionaron los KPI a lo largo del tiempo. Un historial de treinta días no fue suficiente para hacer ese trabajo en el lago de datos. Los equipos tenían los datos que necesitaban para las operaciones, pero no el margen necesario para el análisis.
Los datos de conformidad se almacenaban afuera del lago. Los datos de firewall sujetos a una expectativa de retención de seis meses según la política interna se almacenaban en cubetas S3 separadas, no en la plataforma de búsqueda. Los datos se conservaban, pero acceder a ellos durante una investigación significaba sacarlos del almacenamiento de objetos y cargarlos en una plataforma buscable, lo que el equipo describió como una gran molestia en cualquier caso real.
El hardware estaba envejeciendo. El clúster se ejecutaba en servidores que tenían aproximadamente cinco o seis años de antigüedad, con SSD estándar en lugar de NVMe. El equipo sabía que la renovación de hardware iba a llegar, cambiara o no la arquitectura.
El equipo ocupaba el tiempo en mantener la plataforma existente en buen estado y al máximo de su capacidad, no en extender su uso al resto del negocio.
El rediseño: caliente y congelado en Empresarial
El equipo pasó de platino a empresarial para desbloquear snapshots buscables y el nivel congelado, y luego rediseñó el diseño de almacenamiento de un modelo caliente y congelado, respaldado por S3.
El flujo de datos de principio a fin se mantuvo familiar. Los nodos Logstash realizan la ingesta de fuentes de datos de toda la organización y escriben en Elastic. Los índices calientes residen en SSD NVMe locales en el nuevo clúster. Los índices antiguos se trasladan al nivel congelado, donde se almacenan en S3 y se extraen a una caché local bajo demanda cuando se les consulta. La búsqueda entre clústeres conectó los clústeres antiguos y nuevos durante el corte, para que los usuarios pudieran llegar a datos históricos sin cambiar de entorno.
La compensación en el rendimiento resultó ser manejable. La primera consulta contra un índice en el nivel congelado tarda aproximadamente 30 segundos mientras los datos relevantes se cargan en la caché de los nodos congelados. Después de eso, las consultas contra los mismos datos se ejecutan a la velocidad del nivel caliente.
"Puede tomar el doble de tiempo para la primera consulta, pero después no hay diferencia".
Aspectos técnicos destacados
- Velocidad de consulta de nivel caliente para los datos actuales: 35 TB de SSD NVMe en servidores más nuevos, ejecutándose en KVM.
- Meses a años de retención a bajo costo: 200 TB de almacenamiento congelado respaldado por S3, servido a través de snapshots buscables.
- Capacidad triplicada en la misma huella con licencia: 235 TB combinados (35 TB activos más 200 TB congelados), sin aumento en las unidades de recursos con licencia.
- Clúster más pequeño y rápido: la huella del hipervisor se redujo de 18 a 10 nodos físicos, en hardware más nuevo con más núcleos por nodo.
- Transferencia de carga por carga de trabajo sin reingeniería del pipeline: Logstash continuó manejando la ingesta; los destinos se redirigieron por fuente de datos durante la migración.
- Sin pérdida de acceso a los datos históricos a mitad de la migración: la búsqueda entre clústeres está activa en todo momento, por lo que los usuarios siguieron leyendo índices más antiguos en el clúster heredado mientras los nuevos datos fluían al nuevo.
- Velocidad de nivel caliente contra datos más antiguos después de la primera consulta: ~30 segundos para la hidratación de la caché de nivel congelado en la consulta inicial; las consultas subsiguientes se ejecutan a la velocidad del nivel caliente.
Una transición paralela sin tiempo de inactividad
En vez de implementar un cambio repentino, el equipo implementó el nuevo clúster junto al antiguo y migró carga de trabajo por carga de trabajo, comenzando con las fuentes de datos más grandes. Como la ingesta se ejecuta a través de Logstash, mover una carga de trabajo a menudo era tan sencillo como cambiar el destino en el nodo Logstash del maestro del clúster antiguo al nuevo. La búsqueda entre clústeres mantenía a los usuarios en el nuevo entorno con acceso de lectura a los datos que aún se encontraban en el clúster antiguo, por lo que los datos históricos permanecían accesibles durante todo el tiempo.
El equipo también aprovechó la oportunidad para migrar los pipelines de ingesta personalizados a las integraciones mantenidas de Elastic siempre que fuera posible, lo que describen como la mejor opción para el futuro.
El soporte de Elastic extendió el período de superposición cuando los envíos de hardware se retrasaron, lo que el equipo señaló específicamente como una de las cosas que hicieron que el cronograma funcionara.
"Fuimos migrando departamento por departamento durante tres meses. Lo único que cambió para los usuarios fue la URL, y con la búsqueda entre clústeres activa, nadie perdió acceso a datos antiguos. Sin tiempo de inactividad ni pérdida de datos".
La prueba de concepto en sí tomó alrededor de dos semanas. La mayor parte del plazo de seis a ocho semanas de la prueba de concepto se dedicó a adquirir y provisionar hardware, no a probar. La transición completa se ejecutó durante aproximadamente tres meses y terminó sin tiempo de inactividad ni pérdida de datos.
Desde el punto de vista de los usuarios: casi no pasó nada
Para los departamentos que usan el lago de datos día a día, el cambio fue casi invisible. Los usuarios tenían que apuntar sus marcadores a la nueva URL durante la superposición temporal y volver al dominio estándar después del corte. La búsqueda entre clústeres mantenía los datos históricos accesibles desde el nuevo clúster en todo momento, por lo que nadie tenía que aprender un nuevo flujo de trabajo ni consultar dos sistemas para encontrar datos antiguos.
En cuanto al cumplimiento, los datos que antes estaban en cubetas S3 separadas ahora se encuentran dentro del lago de datos indexado. La retención de firewall de seis meses ya no es un problema de flujo de trabajo. Si un departamento necesita revisar todo el período de retención, hace la consulta de la misma manera que lo haría para cualquier otra cosa en el lago.
Antes y después
| Dimensión | Antes | Después |
|---|---|---|
| Retención estándar | ~30 días, con límite de almacenamiento | Estándar de 90 días, con algunos sets de datos conservados durante un año completo |
| Capacidad de almacenamiento | ~100 TB local | 235 TB combinados: 35 TB NVMe de nivel activo más 200 TB de nivel congelado respaldado por S3 |
| Unidades de recursos licenciadas | Base | Misma base, sin licencias adicionales |
| Nodos de hipervisor | 18 | 10, en hardware más reciente con más núcleos por nodo |
| Hypervisor y hardware | Clúster más antiguo, servidores de ~5 a 6 años, SSD estándar | KVM en servidores actualizados, SSDs NVMe |
| Datos de cumplimiento (por ejemplo, firewall, retención de 6 meses) | Almacenado en cubetas S3 separadas fuera del lago de datos; búsqueda lenta y dolorosa | Vive en el lago de datos con capacidad de búsqueda; consulta como cualquier otro índice |
| Velocidad de consulta en datos antiguos | Acceder a los datos más antiguos fuera del lago requería extraerlos de las cubetas S3 y cargarlos en algo que se pudiera buscar | Primera consulta de nivel congelado~30 segundos para la hidratación de la caché; consultas subsiguientes a la velocidad de nivel caliente |
| Modelo de riesgo de migración | n/a | Clústeres paralelos con búsqueda entre clústeres; cero tiempo de inactividad, cero pérdida de datos |
Lo que RTL Alemania aprendió
Del proyecto se desprenden algunas lecciones prácticas.
Usar integraciones administradas donde sea posible. RTL Alemania contaba con años de pipelines de ingesta personalizados y migró muchos de ellos a las integraciones mantenidas por Elastic durante la transición. El equipo describió esto como una mejor opción para el futuro, no solo para este proyecto.
Tratar una migración como un lavado de cara. Sustituir el hardware obsoleto, modernizar la arquitectura y revisar las integraciones al mismo tiempo multiplicó el valor del proyecto en comparación con realizar cualquiera de estas acciones por separado.
Evalúe el modelo de alojamiento con honestidad. La opción local era coherente, dados los recursos existentes y las consideraciones comerciales de RTL Alemania. Para las organizaciones más pequeñas sin la capacidad interna para montar y ejecutar un clúster, el equipo recomendaría la opción SaaS de Elastic para evitar la sobrecarga operativa.
La parte difícil es el volumen, no la complejidad. Redirigir la ingesta de un clúster a otro fue sencillo. El verdadero esfuerzo fue la enorme cantidad de pipelines y la escala de datos que tuvieron que pasar por ese simple cambio.
Lo que viene después
Dos resultados determinan lo que viene después. El primero: reduce el tiempo que tardan los nuevos miembros del equipo en encontrar la Data view correcta, conectando Elastic AI Agent a los modelos internos de lenguaje grande (LLMs) de RTL Germany. Esto ayudará a los miembros más nuevos del equipo a navegar por la plataforma y encontrar la Data view correcta más rápido, lo que históricamente ha sido uno de los pasos de incorporación más difíciles.
El segundo: absorber aún más logs de aplicaciones en el lago de datos, sin volver a revisar la huella de licencias. Este es un programa interno que incorporará aún más logs de cada aplicación en el lago de datos. La nueva arquitectura se diseñó deliberadamente teniendo en cuenta este crecimiento. Con 200 TB de capacidad respaldada por S3 y la capacidad de extender ese almacenamiento fácilmente, el equipo tiene espacio para absorber el volumen sin revisar la huella de licencias.
"Ahora nos queda mucho espacio, y poder ampliar el almacenamiento S3 fácilmente es una opción que no teníamos antes. En el futuro, vamos a incorporar muchos más datos".
Puede que tu organización no esté gestionando hoy un lago de datos de una década que cubre todo un negocio de radiodifusión y medios, pero los mismos principios se aplican tanto si empiezas con unos pocos terabytes de datos de log como si realizas un escalado hacia una arquitectura de 235 TB con datos calientes y congelados: la huella con licencia no tiene que crecer con el margen de retención.
RTL Alemania es parte del Grupo RTL, la compañía de radiodifusión y medios más grande de Alemania, con operaciones que abarcan televisión, transmisión y producción de contenido.
Descubre cómo el nivel congelado de Elastic Observability extiende la retención sin costo adicional, o consigue ya una prueba gratis.
Recursos relacionados
- Elastic Observability
- Monitoreo de logs
- Elasticsearch
- Logstash
- Integraciones de datos
- Observability Labs
- Documentación de Elastic
Temas: Elastic Observability, Elasticsearch, Logstash, nivel congelado, snapshots buscables, almacenamiento por niveles, búsqueda entre clústeres, análisis de logs, lago de datos, retención de datos de cumplimiento, medios y radiodifusión, medios y entretenimiento