Sobre el autor Hola, soy Pratik. Soy ingeniero de software en Yellowbrick y he trabajado en distintas partes del motor de base de datos y la plataforma durante los últimos años. Me suelen atraer los problemas que se sitúan entre el diseño de sistemas y la usabilidad en el mundo real. Recientemente trabajé en la Edición Comunitaria de Yellowbrick, adaptando un sistema empresarial para ejecutarse como un entorno Docker de nodo único. Este artículo es una reflexión sobre ese trabajo: qué tuvo que cambiar, qué me sorprendió y qué me pareció más interesante en el camino.
Resumen Tomamos la Enterprise Edition de Yellowbrick, un motor analítico compatible con PostgreSQL, y construimos una Community Edition de nodo único basada en Docker pensada para ejecutarse en un portátil de desarrollador. Para lograrlo replanteamos varias suposiciones propias de entornos empresariales: añadimos carga de ficheros locales desde SQL tratando rutas locales como un backend de almacenamiento externo de primera clase con sandbox y lista blanca de directorios; sustituimos la capa BBFS por un backend Local FS ligero que se comporta de forma predecible en contenedores; convertimos los cargadores que funcionaban en pods en procesos del sistema operativo de corta duración con límites explícitos de CPU y memoria; eliminamos el pinning de memoria y adoptamos madvise MADV_DONTNEED para devolver memoria al sistema cuando deja de ser necesaria; y desacoplamos Yellowbrick Manager de Kubernetes mediante un conector local y una configuración simplificada. El resultado es el mismo motor y comportamiento SQL empaquetado para un entorno de un solo contenedor orientado a desarrolladores. Puedes probarlo en el hub de Docker prueba la Edición Comunitaria en Docker Hub.
Qué es Yellowbrick Yellowbrick es una plataforma de datos SQL diseñada para cargas analíticas. Se puede desplegar on premise, en nubes públicas o en entornos híbridos, permitiendo a las organizaciones elegir dónde y cómo gestionar sus datos. La plataforma es compatible con PostgreSQL, lo que facilita que las herramientas y flujos de trabajo existentes se conecten sin reescribir sentencias SQL. Internamente, usa una arquitectura distribuida pensada para soportar consultas analíticas sobre grandes volúmenes de datos manteniendo aislamiento entre tipos de carga de trabajo.
Qué significa Enterprise Edition La Enterprise Edition es la versión completa y apta para producción de Yellowbrick. Está diseñada para despliegues distribuidos e incluye capacidades como operación multinodo, aislamiento de cargas, características de disponibilidad y controles de seguridad empresariales. Soporta modelos de despliegue y requisitos operativos habituales en grandes organizaciones que ejecutan sistemas analíticos críticos.
Por qué creamos la Edición Comunitaria Queríamos que Yellowbrick fuera accesible sin necesitar un clúster distribuido, instalaciones largas o infraestructura dedicada. De esa motivación nació la Community Edition: una versión gratuita de nodo único que se ejecuta por completo en Docker. Está basada en el mismo motor y en la misma interfaz SQL que la Enterprise Edition, pero orientada a desarrollo, evaluación y casos de uso de menor escala. Algunas funciones empresariales como escalado multinodo, gestión avanzada de cargas y ciertas capacidades de seguridad se excluyen intencionadamente para mantener la simplicidad y foco local.
Ingeniería para un entorno Docker de nodo único Hacer que un sistema pensado para entornos empresariales funcione dentro de un solo contenedor exige revisar supuestos arquitectónicos. Capas de almacenamiento, mecanismos de carga, comportamiento de memoria y herramientas de gestión partían de modelos que no se daban en un entorno local. A continuación se describen los cambios más relevantes y cómo se implementaron.
Carga de ficheros locales vía SQL En Enterprise se cargan datos desde almacenes de objetos externos con sentencias SQL tipo LOAD TABLE my_table FROM 's3://bucket/path/data.csv'. Las rutas de sistema de ficheros local no estaban soportadas directamente por SQL y había herramientas CLI aparte para importar ficheros locales, una experiencia poco adecuada para un contenedor auto contenido. En CE extendimos la abstracción de almacenamiento externo para incluir rutas locales. Los ficheros locales se tratan como otro tipo de almacenamiento externo implementado como plugin dentro del marco YbFile. El flujo general —frontend PostgreSQL, middleware y ejecución por trabajadores— no cambió; solo se ajustó la resolución del backend de almacenamiento. Por seguridad CE restringe el acceso a directorios explícitamente permitidos dentro del contenedor, bloquea traversal de rutas y asume un entorno de usuario único donde quien ejecuta el contenedor controla los montajes.
Sustitución de BBFS por Local FS Enterprise usa BBFS, un sistema de ficheros por bloques diseñado para entornos distribuidos de larga vida con almacenamiento dedicado. Ese diseño no encajaba bien en despliegues Docker de nodo único porque preasignaba espacio en disco de formas no apropiadas para máquinas de desarrollador, liberaba espacio con dificultad, asumía inodos de 32 bits en conflicto con sistemas modernos de 64 bits y partía de infraestructuras persistentes en lugar de contenedores efímeros. En CE sustituimos BBFS por un backend Local FS que interactúa directamente con las APIs del sistema de ficheros del sistema operativo manteniendo las interfaces internas del resto del sistema. Para resolver la compatibilidad de inodos CE genera y gestiona identificadores estables de 32 bits propios en lugar de depender de los inodos del host. Esa solución adaptó la capa de almacenamiento al entorno de contenedores sin cambios arquitectónicos profundos.
De pods a procesos para trabajos de carga En Enterprise los jobs de carga se ejecutan en pods de Kubernetes que proporcionan aislamiento y gestión de ciclo de vida. CE no usa Kubernetes, así que cada trabajo de carga se convierte en un proceso nativo del sistema operativo que se lanza durante la duración del job. Se aplican límites de recursos a nivel de proceso y el proceso finaliza limpiamente al completar la carga. Esto preserva aislamiento entre cargas y encaja de forma natural en el modelo de un solo contenedor.
Gestión de memoria en entorno local Los despliegues empresariales suelen usar memory pinning para comportamientos predecibles en hardware dedicado. En un entorno Docker local eso puede ser problemático. CE evita el pinning y devuelve memoria al sistema operativo en cuanto deja de ser necesaria usando madvise con flag MADV_DONTNEED. De este modo el sistema operativo puede reclamar memoria inmediatamente, un enfoque más apropiado para máquinas de desarrollador con recursos compartidos y limitados.
Desacoplar Yellowbrick Manager de Kubernetes Yellowbrick Manager fue diseñado alrededor de conceptos de Kubernetes como descubrimiento de pods, ConfigMaps y Secrets. CE funciona sin Kubernetes por lo que YM necesitó un modo local: se eliminaron dependencias específicas de Kubernetes, la configuración se proporciona mediante variables de entorno locales, se introdujo un mecanismo ligero de autenticación para sustituir secretos gestionados por Kubernetes y se deshabilitaron características exclusivas de clústeres distribuidos. Así YM puede gestionar y observar una instancia de nodo único sin orquestadores externos.
Mismo motor en distinto contexto Community Edition demuestra que el motor de Yellowbrick puede operar fuera de un clúster distribuido cuando sus supuestos se ajustan al entorno local. Al extender abstracciones para almacenamiento local, simplificar la capa de sistema de ficheros, adaptar la ejecución y la gestión de memoria y desacoplar la gestión de Kubernetes, preservamos el núcleo del sistema haciéndolo utilizable en un entorno Docker de nodo único. El objetivo de CE sigue siendo sencillo: facilitar el acceso al motor Yellowbrick para uso local, experimentación y desarrollo.
Sobre Q2BSTUDIO Q2BSTUDIO es una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial, ciberseguridad y servicios cloud en AWS y Azure. Ofrecemos soluciones integrales que incluyen servicios de inteligencia de negocio, implementación de agentes IA y proyectos con Power BI para ayudar a las empresas a convertir datos en decisiones accionables. Si busca desarrollar una aplicación personalizada o modernizar sistemas le podemos ayudar con nuestros servicios de desarrollo adaptados a su negocio, vea ejemplos en nuestra sección de desarrollo de aplicaciones y software a medida desarrollo de aplicaciones y software a medida. Para iniciativas que integren aprendizaje automático, agentes IA o iniciativas de IA para empresas consulte nuestro apartado de inteligencia artificial servicios de inteligencia artificial para empresas. En Q2BSTUDIO también trabajamos en ciberseguridad y pentesting, automatización de procesos y soluciones cloud en AWS y Azure, todos alineados para mejorar rendimiento, seguridad y escalabilidad.
Palabras clave aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.
Contacto Si desea más información sobre cómo adaptar soluciones empresariales a entornos locales o lanzar proyectos de datos e inteligencia artificial con soporte profesional, Q2BSTUDIO puede acompañarle en el diseño, desarrollo e integración de la solución adecuada.
.jpg)
.jpg)