javisantana.com

La respuesta al concurso del Lego de la TGR23

En esta TRG en Tinybird hicimos un concurso en el que tenías que adivinar el tiempo de una query SQL sencilla sobre 1 billón de registros. Si acertabas ganarías un LEGO que seguramente sea más difícil de montar que aprender SQL. El objetivo era no sólamente hacer un concurso estúpido para recoger “leads”, hacer algo que retase a la gente y a su vez sirviese para explicar qué hace nuestra empresa tenía más sentido. Además, si no sabes mucho de datos, te permite aprender.

Antes de escribir nada: es imposible saber el tiempo de ejecución de una query en un sistema donde desconoces todos los componentes. Bueno, aunque los conozcas, es en la práctica imposible. Así que era un juego de un mucho de estimación y otro mucho de suerte

El enunciado era tal que así:

“”” Responde con el tiempo que crees que tarda Tinybird en ejecutar esta query SQL

SELECT 
    toDate(timestamp) AS date, 
    avg(speed) AS avg_speed
FROM rocket_telemetry 
GROUP BY date

La tabla se le añaden 1000 registros por segundo y en el momento del comienzo de la TRG23 tenía 1 billón americano de registros.

HINT: es más rápido de lo que crees. “””

Como ves, sin conocer datos tan básicos como cual es el sistema que corre, como almacena los datos, el esquema de la tabla etc etc es absolutamente imposible. Aún así, vamos a hacer un análisis de como se podría estimar sin ponernos muy técnicos, en términos simples.

Empecemos por los básicos: el tiempo de una query tan sencilla depende del tiempo que tardemos en leer los datos. Esto es así para la gran mayoría de queries que son ejecutadas en nuestras queridas bases de datos.

Así que en el caso que nos atañe tenemos dos columnas, vamos a asumir que son de 4 bytes cada una (un campo Date y otro Float), a la hora de ejecutar la query había unos 1.1b de registros, tenemos un total de ~8.2Gb (=1000000000 * 4 * 2). Mi portátil, macbook pro M1, es capaz de leer aproximadamente unos 3.8gb/s de memoria cuando todos los registros están perfectamente colocados, no tengo ni pajolera de lo que tardará un servidor de google -donde estaba alojada mi cuenta de tinybird- pero entiendo que es algo similar, así que la query debería tardar algo más de 2 segundos.

No tan rápido, en realidad nosotros somos más listos que eso, en la tabla había un timestamp, y en enunciado dice que son unos 1000 registros por segundo. Debería haber usado un timestamp de 64 bits, pero no lo hice (mal), pero en este caso, sabemos que hay 1000 valores seguidos iguales si los vamos colocando en la base de datos según nos los envían.

Y si en vez almacenar el valor, almacenamos la diferencia con el valor anterior? Pues vamos a tener 1 uno, seguido de 999 ceros. No sé a ti, pero a mi me da que eso se puede guardar de una forma eficiente. Alguien ya se dio cuenta hace años he inventó algo llamado RLE compression, que permite reducir la cantidad de información cuando se repiten mucho los valores. En este caso, usé un algoritmo algo más moderno, LZ4. La historia de LZ4 es bastante increíble, os recomiendo este podcast.

Echando cuentas, si guardamos 1 uno y 999 ceros, repetido 60 segundos * 60 minutos * 24 horas son básicamente 1kb que es tamaño que ocupa 1000 valores y otro más para decirle las veces que lo tiene que repetir. En la base de datos que usamos, Clickhouse, ocupa unos 22mb. Lógicamente hay ineficiencias porque el sistema de almacenamiento no está pensado para este caso de uso, ni LZ4 funciona exactamente como he dicho. Aún así, de 4gb a 22Mb podemos decir que hemos hecho un buen trabajo.

Entonces ahora tenemos dos columnas, una de ellas, timestamp, que ocupa 21mb y otra, speed que ocupa 4gb. Dirás, por qué no se comprime esa columna? Pues porque usé un rand() que por definición apenas comprime. La realidad es que usando ZSTD, otro algoritmo de compresión, se queda en aproximadamente 3.8gb. Es importante saber donde es fuerte cada algoritmos de compresión, no tienes que saber los detalles, pero sí tener intuición.

Para terminar, echando cuentas, la query debería tardan aproximadamente 1 segundo, y efectivamente, así era. De las 224 personas que participaron, menos de un 5% dieron una respuesta entre 0.5 y 1.5 segundos, menos de 10% si muevo el rango de 500ms a 3s.

Pero aquí no termina todo, a nada que sepas SQL podrás intuir que para ejecutar esa query no necesitas leer todos los datos todas las veces que ejecutes la query, puedes ir agregando a medida que vienen los datos. SI estás pensando ahora mismo en “pongo un scheduler que se ejecute cada minuto” o “uso spark whatever” o “snowflake blabla” siento decirte que la tecnología ha avanzado en estas últimas 3 décadas y ahora las cosas se pueden en tiempo real. Bueno, procesar 1000 registros cada segundo se puedía hacer hace unos 30 años en cualquier PC, va a hacer 30 años de la release de DOOM, amigos (para los milenials, DOOM era nuestro Fortnite)

Así que si agregas según vienen los datos, necesitas almacenar unos 12 días (aprox 100M de eventos al día son generados a 1000 ev/s) con lo cual necesitas una tabla de 12 filas con 3 columnas: fecha, suma total, count. Eso son unos 144 bytes si usas 4 bytes por cada tipo de dato.

Con ese dato puedes intuir que la query está por debajo de 1 milisegundo casi con total seguridad, lo que se tarde en parsear la SQL y poco más. Si tu sistema tarda en parsear la query y coger 120bytes (~8kb en Clickhouse) más de 1ms, me jode ser yo el que te lo diga, pero hay algo que hay que repensar.

Solo 8 personas respondieron 1ms o menos. De hecho la query total costaba unos 0.8ms, ganó Claudia que puso 0.99 :)

Si has llegado hasta aquí es porque el tema te interesa. Hice un curso de unas 3 horas explicando en detalle todo esto, lo puedes ver por aquí.

Gracias por pasar por el stand de Tinybird, fue un placer hablar con vosotros.

Customer Success

Llevo unos meses liderando lo que llamamos en Tinybird un equipo de “Customer Success”. Antes se llamaba de otra forma que ni recuerdo.

Cambié el nombre porque me parecía que lo que realmente hacíamos era eso, ayudar a los clientes a salir del paso, a quitar la roca del camino, a llegar a puerto, a luchar contra el enemigo comun, a poner en producción vaya. Siendo nuestro producto algo pensado para desarrolladores no veo otra forma más clara de tener “success” que esa.

Resulta que, después de unos meses de ver a la gente que llegaba nueva a la empresa totalmente contrariada, tuve que crear una presentación para explicar quién leches éramos, qué hacíamos y el porqué en vez de ser comerciales, somos un equipo de ingeniería.

Ahora, leyendo sobre el tema (1) y escuchando los sermones (2) de la gente que sabe del sector, veo que la métrica habitual de “Customer success” es incremendar la facturación. Nunca en mi cabeza pondría una métrica que no estuviese alineada con un cliente, pero es que resulta que esta métrica define prácticamente lo que hace el departamento. Y seguramente sea así por una muy buena razón que desconozco, imagino que a escala simplifica todo.

Así que, muy a mi pesar -ya me había costumbrado- cambiaré el nombre de nuevo, aunque sigamos haciendo lo mismo. Eso antes de poner un objetivo absurdo.

Lo complicado de esto es que el equipo no encaja en ninguna definición existente en el panorama startup. Así que o bien busco lo más parecido y me hago otra presentación para explicarlo o pongo una métrica de facturación o le pongo un nombre que genere GPT-3 en base a la descripción.

Puedo comprender el porqué las empresas tratan de poner nombres standard a departamentos, igual que se lo ponemos a los roles, pero la realidad es que tal vez estemos ajustando la empresa a los nombres y no los nombres y funciones a la realidad de la empresa y el producto. Por eso cuando veo que alguien define una oferta de trabajo por lo que hay que hacer y no por el título, incluso si la descripción es vaga, me da sensación de “esta gente sabe lo que se hace”.

(1) La wikipedia acierta bastante con la definición, la verdad.

(2) Me refiero a la primera acepción “Discurso cristiano u oración evangélica que predica el sacerdote ante los fieles para la enseñanza de la buena doctrina.”. La “buena doctrina”, ya sabes.

Alma

En el año 1999 un fulano se presentó al rally París-Dakar con un coche perdedor. El Dakar es un rally que dura unas dos semanas, pasa por caminos de cabras, dunas y otras tantas sendas donde un coche de calle no avanzaría ni un palmo.

Era perdedor porque no era 4x4, así que pasar las zonas de dunas era complicado y no tenía un equipo oficial detrás para reparar el coche después de cada etapa, ni que decir tiene que tampoco para meter la gallina en diseño y desarrollo del coche previo al rally. Hizo todo lo contrario de lo que ponía en el libro de los ganadores.

Pero lo ganó. El coche no era 4x4 pero gracias a eso era más ligero, más sencillo de reparar y tenía sistemas para hinchar y deshinchar las ruedas sin bajarse del coche que le permitían pasar las dunas fácilmente (a menos presión en las ruedas, menos te hundes en la arena). Había aprovechado el reglamento al máximo pensado para las grandes marcas que llevaban coches 4x4, los que el sentido común decía que todo el mundo llevaría.

Era un coche con alma. Y no porque ganara, si no porque el menda llevaba 10 años compitiendo con este tipo de coches (y otros 20 en otras categorías, como F1), que él mismo diseñaba. Creía en su idea y punto.

Schlesser ganó pero hay mucha gente que se cree sus ideas y nunca “gana”. Da igual, no se trata de ganar, esto no es David contra Goliat (aunque cuando lo son es aún más placenetero)

A lo largo de los años, sin realmente buscarlo mucho, me he dado cuenta que me han dejado de gustar las cosas que no tienen “alma”. Como decía Bukowski, “no tengo tiempo para cosas sin alma”. No tenía claro qué era, pero había llegado un punto que prácticamente rechazaba de forma inconsciente algo si era “mainstream”. Necesito el toque personal para que algo me resulte interesante.

Para que nos entendamos, es básicamente lo que está en el polo opuesto de “corporativo”.

Así que en vez de ver series en Netflix termino viendo videos de un fulano con 200 suscriptores grabando videos desde su granja, termino comprando a tiendas solo porque los que lo regentan son unos personajes, leo biografías de gente que hicieron las cosas de otra forma, conduzco un coche que nadie en sus cabales conduciría más allá de 100 kilómetros y uso tecnología que nació desde una necesidad y una convicción, no como forma de conseguir con objetivo.

Todo tiene un precio, habitualmente el fulano con 200 suscriptores postea 1 vez cada 3 meses en vez de tener un episodio semanal, las tiendas son más caras y los coches se rompen más, y te miran raro cuando dices que no usas kubernetes, pero la sensación de estar usando algo hecho con convicción vale seguramente mucho más que todo eso.

Lamentablemente, bueno, no, afortunadamente, las cosas con alma no suelen escalar y suelen perder el alma cuando se hacen por dinero. Así que hay que aprovecharlas mientras duren.

Solo necesitas saber esto para escalar rápido tu equipo técnico.

No son pocas las veces que alguien me escribe con algo tal que así: “tú que tienes experiencia escalando equipos técnicos tal vez nos podrías dar algún consejo sobre como escalar, tenemos muchos retos por delante”

La traducción al mundo real suele ser: vamos hasta arriba de trabajo, estamos intentando hacer y vender más de lo que podemos y nos damos cuenta de que la producción es el cuello de botella. La última frase, la de “los retos” suele ser indicativo de que has levantado pasta y has prometido con todas tus fuerzas.

En ese momento el CEO habla con el CTO, normalmente el desarrollador que ha hecho el 50% de todo el código y dice: “vamos a buscar a alguien que haya pasado ya por aquí y que te cuente como tienes que enfocar el tema”. El CTO, que sabe perfectamente el percal que tiene y pasa tres pueblos de perder el tiempo en hablar de sus penurias con un “gurú” en vez de estar atento al último fuego, termina aceptando. Igual que cuando tienes una enfermedad que nadie te cura y pides cita en un profesional del tarot.

Mi respuesta siempre es: no creo que os pueda ayudar. No es falsa modestia, no es de lejos mi especialidad, pero es que vuestro problema es algo que no tiene solución. Se puede hacer mejor o peor, pero en la vida no se puede tener todo:

No puedes ir rápido y que todo vaya como la seda. No existe. Ni en software ni en otra disciplina.

Por suerte o desgracia los equipos de producto son el cuello de botella de la empresa. Son los que tienen que aterrizar y poner a funcionar todas esas ideas felices que se nos ocurren. Y ahí ya no caben estrategias, ni sinergias, ni reuniones de trabajo, ni documentos colaborativos, ni comités, ni cristo que lo fundó, es tu empresa frente a la realidad de la ejecución, las limitaciones del mundo real.

Así que la solución a tu problema no pasa por squads, kanbans, agile, OKRs u otros metodologías: pasa por entender que la realidad es más complicada de lo que crees y puedes hacer menos cosas de las que quieres.

Pasa por entender que cada línea de código que añades necesita alguien de por vida manteniéndola y que una persona puede mantener un máximo de ellas.

Seguramente, cuando hayas entendido que no puedes tener todo y que si quieres hacer mucho el caos va a ser monumental (y vas a tener que aprender a vivir con ello), ya puedas entrar en la siguiente fase que incluye muchas cosas, pero que las más importantes son:

Y en función de si vas por la vía del caos o la vía del orden (“order or progress” dicen los americanos, que saben mucho) estas dos cosas tienen que ser radicalmente diferente. Necesitas gente diferente y procesos diferentes.

Así que el truco es que no hay truco, lo siento. No vale con una conversación de 45 minutos con alguien que “ya lo ha hecho”. Sí que puedes decidir cuanto balanceas y tener expectativas claras de lo que puede pasar, y apechugar. Cuando ya seas una máquina engrasadísima, conozcas el negocio, etc es posible que puedas ir con cierta velocidad y cierto orden. Me imagino.

Dirás, ya pero la empresa X lo hace. Y te respondo con un refrán popular: “en todas las casas cuecen habas”

Odio el inglés

La primera vez que tuve una reunión en inglés, hace unos 12-13 años, creo que no era capaz de construir una oración de 5 palabras. Entendía a duras penas, especialmente a los británicos. Las pasé putísimas y la sensación de “mejor lo dejo” era diaria. Por suerte había gente en la empresa que se reía de mi con suficiente estilo como para pensar que incluso podría ser divertido. Con los años he mejorado bastante, aún con muchas carencias que suplo con una dosis importante de jeta.

Pero no odio el idioma porque se me de mal (bueno, también), lo odio porque no soy yo el que habla. Es una versión diferente. La forma en la que uso las palabras y como las engrano es lo que hace que sea como soy.

Y no es -solo- por la limitación de vocabulario, mi sensación es que mi parte del cerebro que uso para pensar se malgasta procesando si tengo que decir poner la puta ese de la tercera persona en el verbo o si people es plural o singular.

Pero amigo, el idioma internacional del software es el inglés; programamos en inglés, documentación en inglés, reuniones también en inglés aunque todos habléis castellano (somos la elite, que no se note que somos españoles), hasta las notas las tomo en inglés con tal de no sentirme un fracaso profesional. Incluso escribo en inglés, soy un vendido, un chaquetas.

Uno de mis programadores preferidos es Kenta Cho, no es conocido, ni lo será, me encanta por su estilo diseñando mecánicas de juego super sencillas. El amigo Kenta tuitea en japonés (o eso creo) y programa igual que escribe: pensando en japonés.

Otro buen ejemplo son los rusos, tienen su estilo y estoy seguro que cada país y cultura tiene una forma de atacar los problemas. Y es bastante obvio que la cultura viene dada por el idioma (o al contrario, no soy experto pero me parece una relación suficientemente obvia). No es casualidad que sean los magos del software de alto rendimiento, su tradición matemática seguramente tenga mucho que ver. Además no se cortan ni un pelo, su código suele estar comentado en ruso.

Y así podemos ir cultura por cultura. Pero la situación actual es que todos convergemos: ahora ves presentaciones técnicas de Bytedance (chinos, creadores de Tiktok) y solo sabes que son no americanos por el inglés penoso, si tenían una cultura de desarrollo diferente desde luego ya no está o no la sacan a pasear.

El inglés es el autotune del desarrollo; los matices ya dan igual, todos vamos enfilados por el mismo camino, si había alguna diferencia cultural que hacía que la forma de atacar los problemas o el punto fuerte fuese diferente, tranquilo que ya se difuminará en un inglés mediocre.

Como es lógico, no tiene ningún sentido no saber inglés. Tienes que saberlo, tienes que poder vender lo que haces, pero igual que cuando cambias de provincia se ve una cocina diferente, me encantaría ver lo mismo en el desarrollo de software.

Podrías pensar: Santana es un nacionalista de libro. Nada más lejos de la realidad. Estoy 100% en contra de que la política se apropie la identidad cultural. Estoy a favor de aprovecharla (la identidad, no la política) para buscar formas diferentes de hacer lo mismo. A favor de comunicarlo también para que todo el mundo lo entienda.

Por desgracia en España tenemos muy muy poca tradición tecnológica (en cualquier ámbito) y desarrollar en castellano suena pueblerino, de provincias, poco profesional. Pocos post técnicos son en castellano, igual que pocas charlas de “alto nivel”. Ser nosotros mismos es, en resumen, malo.