SensorFlow: ingesta de analitica autoalojada en Go, ClickHouse y Superset
El proyecto propone mover primero la frontera de ingesta para cambiar de sistema de analitica sin reescribir los clientes que ya emiten eventos.
SensorFlow es un stack de analitica de producto autoalojado que recibe eventos con un servicio escrito en Go, los almacena en ClickHouse y los publica a traves de Apache Superset. La tesis del proyecto es que cambiar de sistema de analitica casi nunca es una decision de dashboard: lo complicado esta en la frontera de ingesta, donde clientes web, Android, iOS, mini-program y backend emiten con ciclos de release distintos y arrastran anos de convenciones de nombres y casos raros de identidad.
Para los equipos que ya usan el flujo estandar de subida de los SDK oficiales de Sensors Data, la pregunta practica es si ingesta y almacenamiento pueden mudarse a infraestructura propia sin tocar de golpe cada integracion de cliente. El repositorio esta en GitHub y la documentacion cubre el despliegue.
Que queda a la vista
El operador puede inspeccionar los registros crudos, definir metricas en SQL y montar dashboards contra su propia base de datos. No se trata de esconder la analitica detras de otra capa alojada por un tercero, sino de que los eventos funcionen como el resto del stack de datos: cambios de esquema revisables, consultas que se pueden leer y controles de acceso que encajen con la infraestructura que ya existe.
Los limites vienen declarados
Autoalojar no libra de operar. Docker Compose sirve para evaluar, pero produccion exige HTTPS, credenciales unicas, controles de acceso, monitorizacion, copias de seguridad, pruebas de restauracion y planificacion de capacidad. El alcance tambien es deliberadamente estrecho: no hay grabacion de sesiones, ni experimentacion, ni feature flags, ni flujos no-code amplios. Quien busque un reemplazo funcional de una suite de analitica de producto al uso no lo va a encontrar aqui.
El publico objetivo son equipos de ingenieria con instrumentacion multiplataforma ya en marcha, necesidad de control sobre sus datos y ganas de operar ClickHouse. Uno de los maintainers pide justamente retroalimentacion sobre compatibilidad de ingesta, decisiones de esquema en ClickHouse, fiabilidad del despliegue y validacion en produccion.
La decision interesante no es que herramienta de analitica se elige, sino donde vive el dato. Empezar por la ingesta deja los clientes intactos y permite volver atras si el experimento no sale; cambiar primero los dashboards, en cambio, ata a un sistema nuevo con los eventos todavia en el viejo. Hasta donde llegara la compatibilidad con los SDK propietarios dependera de lo que reporten los equipos que lo pongan a prueba.
