Si has llegado hasta aquí y has leído todos los capítulos verás que el Data Lake es el sueño de cualquier empresa media grande. Un sitio centralizado donde se puede consumir de forma uniforme toda la información del sistema.
Bien, es tan soñado que es una utopía si tu empresa no ha arrancado así desde cero (y si tiene cierto éxito, creeme, empezará a haber ramificaciones de los datos por aquello de la agilidad)
Así que si estás planteandote el data lake, data warehouse o sistema centralizado, piensa muy mucho si lo que realmente quieres es que las diferentes áreas de negocio expongan sus datos de una forma lógica.
Cada día más se habla de los microservicios, de dividir las empresas en diferentes áreas para darles agilidad (esto no es nuevo, ya lo decía Ricardo Semler en Maverick), de productizar esas áreas, pero la realidad es que poco se aplica cuando se habla de los datos, donde la centralización es el santo grial, especialmente en empresas donde la estrategia de datos ha sido mover CSV de FTP en FTP y donde básicamente se invierten cientos de millones en mega estructuras que nunca llegan a funcionar porque, ni son ágiles, ni son rápidas, ni son útiles porque se pensó más en la fiscalización que en la disponibilidad de la información y porque hay empresas que saben vender muy bien el dorado cuando el problema que no resuelven es el de las personas.
Hay muchas más estrategías además de centralizar:
Recuerda, tener centralizada la información es el camino, pero el objetivo es hacer que la información esté disponible y a eso se puede llegar por muchos caminos.
Y por último, empieza por la cultura y no por la tecnología, si tus empleados no saben nada de datos (formatos, como se almacenan, distribuyen, consumen…) y no hay unas guías clarísimas que pasen de generación en generación (eso es la cultura, no?) cualquier iniciativa será en vano y terminarán usando la tecnología que se lo ponga más fácil (en este caso en la nube) y lo peor, seguirá habiendo los silos generados para mantener un puesto de trabajo.
No olvidemos que el objetivo final del data lake es poner a disposición de quien necesite la información de la forma que necesitan consumirla. Es decir, todo lo que he escrito anteiormente no deja de ser grasa, lo importante es poner a disposición la información
Y esto tiene muchos planos, por un lado el que información se necesita, normalmente derivada de la intersección de varias fuentes de datos, y otra el como: a veces se necesita información en tiempo real, otra un sistema analítico para poder hacer descubrimiento, otro se analítica y a veces simplemente se necesita poder exportar a un formato específico (por ejemplo, Excel)
Es decir, tiene que tener la capacidad de transformar y mezclar datos si no que además tiene que soportar cargas de consumo de diverso índole.
Por poner un ejemplo, querríamos disponer de información para servir la analítica de una parte de nuestro negocio en tiempo real (con requerimientos de baja latencia y mucha velocidad) y a su vez tener esos mismos datos disponibles para que un data scientist haga queries muy pesadas para entender y modelar el dataset.
Y claro, que un tipo de carga no afecte a la otra. Y que además este actualizada en tiempo real con nuestro sistema productivo.
Así que, de una y otra forma estamos pidiendo que el data lake sea capaz de ser tan bueno como postgres en carga transaccional, tan bueno como spark para hacer análisis en batch, tan rápido como hbase y siendo capaces de tener capacidades de analítica en tiempo real como kx o Clickhouse.
Y obviamente esto es imposible de tener al mismo tiempo, de ahí que tengamos que replicar los datos.
En general, los casos de uso que debería ser capaz de sustentar son:
Capacidad analítica: es decir, permitir usar BI, herramientas internas, excel o similar para entender los datos
Capacidad analítica++, es decir, permitir casos de uso más avanzados que permitan a gente con más conocimiento técnico usar sus herramientas (jupyter/python, R)
Alimentar sistemas transaccionales. Es decir, una parte del negocio necesita datos de otra parte? el sistema debería ser capaz de poner en su base de datos (mysql por ejemplo) esos datos
Exponer los datos como API. Este es el caso ideal en vez del anterior porque permite a cualquier sistema beber de los datos, independientemente de su naturaleza.
Enviarlos a sistemas variados, S3, FTP, herramientas SaaS…
Y aquí puedes imaginar todo lo que se te ocurra.
Cuando hablamos con alguien con cierta experiencia en el mundillo startup y nos pregunta, después de un rato de conversación “bueno, pero qué queréis conseguir con Tinybird”. Hay muchas posibles respuestas standard en el mundillo en el que nos movemos: “venderla”, “hacer de ella un unicornio” o cualquier empresarial-motivacional.
Pero la cara se les arruga cuando dices: lo que queremos es trabajar juntos de la forma que mejor sabemos, hacer algo que las empresas necesiten, crear un negocio sostenible, con una buena base tecnológica que aporte valor y como resultado ganar dinero. Lo que viene después, como en el 100% de las empresas, nadie lo sabe por mucho que nos empeñemos en buscar fórmulas e indicadores para argumentar lo que básicamente viene a ser una apuesta (un muy bien artículo relacionado sobre la inversión).
Quizá deberíamos entrenar el pitch de vamos a liderar el sector de vaya usted a saber pero no hacen falta grandilocuencias ni adornos artificiales para hacer un buen producto.
Al grano, qué leches hacéis en Tinybird? hacemos dos cosas, un producto y el complemento que casi cualquier producto necesita:
Un producto que permite exponer una gran cantidad de datos como un API. Esto es, desde que tienes un puñado de CSV con cientos de Gb exportados de vaya usted a saber donde, hasta que lo consumes un API bien estructurada en menos de cientos de milisegundos.
Consultoría de analítica de datos (usando nuestro producto sobretodo). Leer “consultoría” suele ser sinónimo de “algo estás haciendo mal”, ya sabéis, lo dicen todos los VC (haz producto, tienes que hacer producto) y todo los neo-filósofos te dicen que no vendas tu tiempo, pero no veo mejor método para ponerte en la piel de los demás que entender y ayudar a resolver sus problemas usando tu punto de vista y experiencia. Para mi la consultoría también es parte del producto, por eso estamos diseñando el proceso que nos permite abordar este tipo de proyectos de una forma sistemática.
Por suerte el sector de la tecnología lleva unos años en la gloria a nadie se le escapa que se puede vivir bien si estás dentro del mundillo y no falta trabajo. Esto es, puedes, ahora mismo, trabajar en una empresa con todas las comodidades, un buen sueldo, sin realmente matarte a trabajar y con retos intelectuales interesantes. Es el escenario soñado.
Y así estaba yo, en un corporate, con ciertos privilegios y con una cómoda jornada de 9 a 5. Quien es el iluminado que me manda a mi dejar ese status quo para meterme en camisas de once varas, no me jodas.
Tiene una explicación sencilla. Hay dos cosas que valoro por encima de los privilegios y el dinero: hacer las cosas como yo quiero y poder trabajar con la gente con la que comparto algo más que oficina. Y esto lo he aprendido a base de confundirme unas cuantas veces y darme cuenta que no todo el mundo está hecho para según que sitios.
Dicho esto, nada tengo en contra de los trabajos 9-5 y ni el corporate (no siempre ha sido así) donde he aprendido muchísimo en un año, sobretodo a respetar ciertas cosas que son difíciles de ver pero que los mantienen vivos y coleando (esto lo dejo para otro post)
Por otro lado tengo en mucha consideración a las personas que aprovechan lo que saben hacer bien, y creo que uno de mis fuertes es hacer sistemas que saben hacer bien la digestión de los datos… puede que llevar 10 años haciendolo tenga que ver. Me mataría dejar de hacer algo con lo que he disfrutado y disfruto.
Qué mejor manera de aprovechar lo que sabemos que haciendo un producto que resuelva algunos de los dolores que hemos pasado durante los últimos años y que vemos todos los días en empresas que trabajan de una forma u otra con datos.
Resolver un problema bien, usando la que consideramos la mejor tecnología para hacerlo, haciendolo con un standard alto de calidad y seriedad, guiado por la necesidad de resolver ciertos problemas y provechando al máximo el conocimiento acumulado gestionando datos en empresas por las que hemos pasado. Y además, hacer todo esto siendo lo más feliz posible y divirtiendose con cada milisegundo que optimizas extrayendo información de los datos. Eso es Tinybird.
Y esto requiere una cantidad de trabajo y esfuerzo que a medida que te haces mayor cuesta hacer. Sí, cuesta trabajo, en mi caso sacrifico horas de otras cosas que me gustan, pero hacer las cosas como crees que hay que hacerlas tiene este tipo de cosas. Sarna con gusto no pica dicen en mi pueblo.
Al hilo del comentario anterior sobre la gente que sabe hacer las cosas bien y las aprovecha, estoy siguiendo muy de cerca la creación del Instituo Tramontana, especialmente el programa en dirección de producto que imparten dos buenos amigos.
Pero no es solo el contenido del programa, es todo lo que está alrededor del curso, el espacio la solemnidad del programa, las referencias a libros y contenidos con tantos años como calidad (uno de mis propósitos de este año era no leer libros con menos de 30 años, que como todo propósito, he incumplido) y la dedicación con la que están preparando todo. Os recomiendo seguir la lista de correo de Javier, el directo del instituto, donde va contando algunas cosas relacionadas y otras que no, pero que dan contexto.
Tengo un recuerdo agridulce de los problemas de matemáticas de la escuela: todo lo sencillo que parecía cuando veías a la profesora resolverlo paso a paso pasaba a ser un mar de dudas cuando te enfrentabas al problema tu solo.
Añadía más frustración el pensar que lo habías entendido perfectamente.
Lo que no sabias era que la profesora había hecho miles de veces problemas como ese, tanto que podía hacerlos mientras los explicaba.
Cuando leo un blogpost sobre cómo la empresa X resolvió Y, ya sea usando microservicios, tal base de datos o cuál metodología, y que además el problema se igual parecido al mío, me pregunto si no será mi profesora de matemáticas convertida en desarrolladora. Me pregunto si no será mucho más complicado y no habrán pasado miles de veces por ahí. Y entonces me pregunto si yo tengo tiempo de pasar miles de veces por ahí.
Por otro lado no hay cosa más divertida que enfrentarte a algo nuevo, es realmente la única forma de entender algo que ya has entendido.
En este mundo donde las conferencias se han covertido en en fin (y no como resultado de hacerlo bien) para conseguir leads, en donde la calidad brilla por su ausencia, donde un título “catchy” vale más que plasmar años de trabajo en una charla, da gusto encontrarse con maravillas como esta. Y me ha gustado por varios motivos:
No hay mes que no piense en organizar una pequeña conferencia donde la gente venga a contar la verdad del día a día sin miedos, a explicar cómo hacen esto o aquello, o como resolvieron lo de más allá usando el hack más absurdo.
No es noticia que Carmack es uno de mis programadores favoritos. Gracias a él aprendí muchísimo leyendo el código de Quake (especialmente el 2), escuchando sus maravillosas master class en las quakecon y leyendo maravillas como esta, cuando se fue una semana aislado a aprender machine learning. La forma en la que “locuta” me hipnotiza.
Hace pocos días le han hecho una entrevista en un podcast bastante conocido (que no conocía). La entrevista es tan larga como interesante (puedes encontrar resúmenes por ahí), así que da para hablar de bastantes temas: VR, redes sociales y sus problemas, el tema sobre cuantas horas hay que trabajar, coches, videojuegos… en todos ellos su visión es muy muy sensata aunque creo que el hecho de trabajar en Oculus (comprada por facebook) le hace tener una posición un poco sesgada sobre lo que la cúpula de facebook piensa.
Dejando a un lado esa posición sesgada y que está maravillado con su Tesla… hay dos temas que me han llamado la atención poderosamente:
El primero es cuando habla sobre la cantidad de horas que trabaja. Comenta que él solo puede ser productivo 13 horas al día… últimamente ha habido una gran cantidad de comentarios sobre este tema dando recomendaciones sobre cuanto trabajar. En mi vida ha habido periodos donde he trabajado 10-12 horas al día y no los cambiaría por nada. No es sostenible ni para todo el mundo, obviamente, y cada periodo de la vida tiene diferentes prioridades, pero en mi opinión es complicado ser muy bueno en algo si no inviertes una buena cantidad de horas. De ahí que esté un poco de acuerdo con Carmack aquí sobre que cada uno elija libremente las horas que puede o no trabajar (sabiendo, eso sí, que hay vida necesaria más allá que el editor de código)
El segundo, y más importante, es cuando habla de la velocidad de computación
Las máquinas están empezando a ser más lentas, no en absoluto, pero la velocidad a la que la velocidad crece ha bajado dramáticamente. Y el punto está en que, según carmack, los móviles están llegando al límite de lo que pueden dar.
Como derivada, y esta es la parte más llamativa, habla de un cambio cultural, tenemos que empezar a volver a pensar en el performance. Y no es el único, cada semana veo varios artículos sobre como la web está a rebosar de código que hace que vaya lento en todo lo que no sean móviles de última generación. La gente ya no sabe que pasa debajo del código que hace (React, te estoy mirando a ti) y en general se tiende a pensar que con levantar unas cuantas máquinas más en AWS resuelve todos los problemas. Aquí una charla de otro de mis favoritos, hablando precisamente de como el hecho de que los desarrolladores actuales no tengamos ni puñetera idea de lo que pasa por debajo es algo muy muy malo en un futuro próximo (un poco apocalítico, pero bueno)
No puedo estar más agradecido de haber empezado mi carrera profesional haciendo videojuegos, donde tener que refrescar millones de pixeles 60 veces por segundo hacía que el “performance” fuese un ciudadano de primera.
Hablaré más sobre este tema en futuros post
Este mes de agosto he escrito bastante pero he publicado muy poco, cosas de las vacaciones y que por otro lado dejo madurar los posts unos días para ver si pasan el test de la lectura después de una semana.He avanzado con mi serie de post sobre el data lake, en esta entrega la trazabilidad
Estoy escribiendo esta serie con dos objetivos: 1) Que alguien que se pregunte qué leches es un “data lake” lo sepa 2) Demostrar que un daka lake es una panacea y que no deberías hacer algo así.
Casi todas las bases de datos tienen sistemas para planificar como van a ejecutar una query en base a unas estadísticas sobre los datos. Suelen ser sistemas complejísimos y a veces tienes que saber como funcionan para optimizar bien las queries.
Clickhouse, mi base de datos favorita, no tiene un planificador (tiene algo muy simple, que dicho sea de paso simplifica todo el diseño), no obstante las queries se pueden ejecutar con diferentes parámetros. Estoy usando una aproximación diferente: en vez de calcular estadísticas de los datos y ver cual es el mejor plan, estoy ejecutando los diferentes tipos de queries con diferentes parámetros y entrenando un modelo de ML para luego saber cual es el mejor plan dados unos parámetros. De momento el modelo predice con exactitud el tiempo de ejecución (lo que me ha sorprendido gratamente).
El objetivo es integrarlo en Tinybird para los endpoints que tengas publicados. Publicaré los resultados en el blog de Tinybird
Hay aproximaciónes para usar ML en bases de datos, aquí un articulo brutal de como usar un modelo para sustituir a los índices tradicionales.
Si vas a leer algún link de esta lista, que sea este post de Feli, “tengo cáncer”