javisantana.com · rss · rss resumen semanal

Micro

Esto es un pequeño blog (2 minutos de lectura por post), sin ruido, sin distracciones donde escribo las cosas que me gustaría leer. Recibe un correo cada fin de semana con las actualizaciones y "comentarios del director"

Data lake (y VIII): Conclusiones

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:

  • Exponer los sistemas como API (muy en la línea de amazon)
  • Entender los sistemas como productos. Acaso cuando usas Google Analytics piensas en centralizar sus datos también? en realidad piensas como consumirlos (que normalmente es a través de su interfaz) o con un sistema lateral como Big Query.
  • Al hilo de lo anterior, es facilísimo disponibilizar los datos de una parte del negocio usando herramientas que tengan una forma fácil de conectar a tus sistemas y tenga un sistema básico de autorización, auditoría y disponibilización de los datos. Tinybird, el producto que desarrollo es uno de estos sistemas, pero hay muchos otros, por ejemplo Databricks, Amazon Glue

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.

· #

Data lake VII: datos derivados

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:

  1. Capacidad analítica: es decir, permitir usar BI, herramientas internas, excel o similar para entender los datos

  2. 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)

  3. 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

  4. 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.

  5. Enviarlos a sistemas variados, S3, FTP, herramientas SaaS…

Y aquí puedes imaginar todo lo que se te ocurra.

· #

Data lake VI: trazabilidad

Hay dos momentos en los cuales quieres saber lo que está pasando en tu sistema: cuando lo estás integrando y sobretodo, cuando pasa algo malo.

Así que quieres saber qué, cuándo, quién y cómo.

Que ha pasado: alguien ha accedido a un dato, alguien ha metido datos, borrado, cambiado…

Cuándo se ha hecho lo anterior

Quién, que persona o que bot (y quién es responsable de ese voy)

Y cómo: por API, por web…

Pero no queda ahí, además de guardar toda esa información tienes que ser capaz de consultarla. Quién no se ha encontrado con 300gb de logs que hay que investigar cuando hay un problema.

Y ojo, no solo para los datos, también para los metadatos. Por ejemplo, cuando se le dio permiso de escritura a fulanito?

Tan fácil de escribir, tan difícil de implementar bien.

· #

Cloud computing

Hace ya unos años se empezó a hablar de cloud computing.

Para los nativos digitales poder tener máquinas bajo demanda es lo lógico. Para empresas donde los desarrolladores tenían que decir 6 meses antes que máquinas iban a necesitar para poder pedirlas, instalarlas y demás era la panacea.

De hecho, una de las cosas que más te choca cuando empiezas a trabajar con el corporate como proveedor de software es que te piden que les digas el aprovisionamiento necesario para X usuarios. Que dicho de paso, no tienes ni idea porque tienes la falsa seguridad de que tu software escala añadiendo máquinas y bueno, porque saber medir y ajustar la carga requiere de un control absoluto de la mayoría del software que usas y/o tener experiencia con algo que te aplaste (yo aprendí por fuerza bruta gracias a Google y el WSJ)

Sin embargo la nube se vendió como un sitio maravilloso dónde tú no tenías que preocuparte de nada, tu software escalaba solo. Típico overselling que cualquier mid manager se podía tragar. Con lo fácil que hubiese sido dejarlo en “tu infrastructura bajo demanda, en menos de 1 minuto”. Hoy muchas empresas desarrollan como si tuvieran esa capacidad y están “limitadas” por un datacenter con poca capacidad de cambio. O por el dinero, porque levantar máquinas es fácil, pero luego nos encontramos con facturas de 20k/mes.

La realidad del asunto es que empresas como Amazon, Google pueden desarrollar software distribuido resiliente que puede correr en hardware barato que muere cada dos por tres. Y pueden desarrollarlo porque tienen gente muy buena en ese área, que sabe como hacer software distribuído e invierten años en hacer que funcione bien. Pero la mayoría de desarrolladores al uso nos quedamos en lo que nos da el framework (4 ó 5 niveles por encima de entender lo que significa una split de red), todos veníamos de tener hardware muy bueno (y caro).

La derivada de eso es que tu software sigue pensado para correr en cosas que no falle pero usando servicios AWS que si están pensados para correr en cloud. El paradigma de hacer software par a la nube se basa no en seguir un paradigma (que como digo, es muy complicado y caro) si no en usar unos servicios que nos proveen (a precio de oro). Así que es normal que todos los proveedores apuesten por microservicios, kubernetes y sistemas complejos donde necesitas apalancarte en su tecnología. Esto no es necesariamente malo, pero no todo el mundo lo necesita (y puede admitir esa complejidad).

La jodido de esto es que no hace mucho hablábamos de “el grid”, dónde el sistema operativo se encargaba de gestionar la complejidad por ti. De hecho la unión Europea se gastó una millonada en proyectos de investigación, subvenciones que lógicamente trincaron los de siempre. Puedes ver el proyecto xtreemos aquí.

Así que en vez de trabajar en software que sea capaz de paralelizar trabajamos en integraciones con servicios. Lo triste es que lo más parecido a un paradigma cloud son las famosas aws lambda/google run.

Necesitamos otro Torvalds y gente con un poco de cabeza que entienda los problemas que están por venir: Jonathan Blow - Preventing the Collapse of Civilization

· #

Data Lake, parte V: Autorización

Tienes todos los datos de tu empresa en un solo sitio. Nadie en su sano juicio permitiría acceder a todos los usuarios a todos los datos. Esto obviamente no aplica tanto a una pequeña empresa, aquí con dar acceso de solo lectura a una réplica de la base de datos de producción [1] para que la herramienta de BI de turno pueda coger datos es más que suficiente. Eso sí, no llames a esto “democratizar el acceso a datos”, el término sería “anarquizar el acceso a datos”

Porque hoy hay 30 personas en tu organización pero mañana hay 120 y luego 119… me sigues no? Esta es una razón para dejar que ciertas personas vean solo ciertos datos, pero hay otras, por ejemplo simplificar la vida de la gente.

De ahí que tengas que tener un control de acceso (autentificación). Esto es tan viejo cómo que la cueva Alibaba ya tenían un password

Pero ahora podemos hacer algo mejor que tener una sola puerta para la cueva, podemos tener sistemas de autorización robustos:

  • Tenemos sistemas de directorio donde tenemos registradas y agrupadas a las personas que forman parte de la organización
  • Deberíamos poder decir quién accede a qué con granularidad de fila/documento. Y esto a nivel de grupos y/o personas. Esto está resuelto por absolutamente todas las bases de datos decentes hace años. Y si el acceso es temporal, pues durante un tiempo. Y si el acceso tiene que ser a datos tokenizados, que así sea.
  • En la organización no solo hay personas, hay otra cosa llamada “software” que acceden al sistema, es decir, aplicaciones que usan estos datos (de hecho debería ser lo habitual). Estos bots/applicaciones deberían también estar registradas y gestionados. Hay cosas como oauth que podrían resultar muy útil aquí (mira como por ejemplo google da acceso a los diferentes datos de un usuario)

En este último punto es donde se suele pinchar si la empresa tiene cierto recorrido: es complicado entender que hay actores no humanos, que, de hecho, son los más importantes, porque como dice Vicki Boykis, los humanos estamos para dar significado a los datos, para procesarlos ya lo hacen mejor las máquinas.

[1] Evita como puedas dar acceso a la base de datos de producción, por mucha prisa que tengas.

· #

Integración continua

Time To Fix

Una metrica fundamental (*) que cualquier equipo de desarrollo/producto (bueno, en realidad toda la empresa debería estar involucrada aquí) debe medir y mejorar es el tiempo desde que un cliente tiene un problema hasta que ese mismo cliente deja de tenerlo.

Parece una metrica tonta, es facilísima de medir, basta con tener un tracker de issues e ir cambiando los estados a medida que la fases (reporte, evaluación, fix, deploy, test, close). Sí, esto es el peñazo universal, pero también lo era ponerte el cinturón de seguridad al montarte en el coche ahora no puedes avanzar un metro sin él puesto.

“deployear”

Una de esas fases es el deploy, es decir desde que tu código está en el control de versiones, hasta que llega a estar en producción.

Nadie ya discute que ese es un buen procedimiento, que debe estar automatizado y responder a cambios en el repositorio.

Vale, ahora imaginad que retrocedemos 20 años en la época en la que había un servidor FTP donde unos ficheros PHP era ejecutados por apache. O incluso unos scripts corriendo por CGI (las lambdas de hace unos años, para los milenials)

Imaginaos editar directamente esos ficheros en producción, es decir, cuando guardas en el editor la siguiente request ya usaría el nuevo código.

Nos hemos acostumbrado a cosas lentas

Obviamente hay muchas razones para no hacer esto, pero así se hacia hace años y es el en lo que tienes que pensar cuando tu deploy tarda 30 minutos: el baseline son unos milisegundos, así que todo lo lejos que estés de milisegundos lo estás haciendo peor que hace 25 años.

Digo obviamente pero yo no tengo tan claro que las herramientas actuales de desarrolladores no sean “caballos más rápidos” y no coches como diría Ford. Lo mejor que he visto últimamente en esta línea es esto y glitch, que está empezando de juguete pero “ojo lluvia” que viene de gente que sabe como hacer producto web. Pero este tema da para otro post.

Nos hemos acostumbrado a que las cosas vayan lentas a cambio de unas promesas que, en muchos casos, no son ni media verdad.

(*) Si tienes un equipo de desarrollo mediano (+10) la métrica TTF (time to fix) es un driver buenísimo para mejorar la calidad del desarrollo. Y además si eres CTO te sirve como métrica para poner en el excel para los inversores (que siempre es un peñazo encontrar buenas métricas)

· #

pico8

Había visto ya hace un tiempo gente publicando imágenes con el hashtag #pico8 y me habían llamado la atención pero nunca me he parado a ver de qué iba y no sé si es nostalgia pero estoy enganchado.

Básicamente es una consola virtual, con sus cartuchos virtuales con un par de peculiaridades: el developer es first class citizen y las restricciones son muchas, por ejemplo, tienes una paleta de fija de 16 colores, el tamaño de la pantalla es 128x128px (hay favicons más grandes) y un máximo de tamaño de juego de 64kb. Solo hay que echar un ojo al cheatsheet

Y esto hace que como producto sea espectacular. Tiene todo lo que necesitas para hacer un juego (lógica, sprites, mapas, efectos de sonido y música (*)) en el mismo sitio, te permite hacer virguerías, pero te las restricciones te obligan a hacer las cosas super sencillas.

Nada de complicaciones, con esos recursos tienes todo lo necesario, eso sí, crear, modificar y usar esos recursos en el juego es muy muy fácil, así que las limitaciones se convierten en una ventaja.

Cómo plus tiene un halo retro y una filosofía del software noventero preinternet que hace echar de menos la época de cuando el software lo hacía gente en otra liga.

(*) Si te interesa la generación de audio procedural escribí un artículo hace unos 14 años sobre como generar audio en demos de 4kb.

· #

Joinable API

TLDR: nowadays any software service depends on others. The problem is your data ends up being distributed and there is no easy way to join those different sources easily. I’m proposing a “joinable API” to fix that problem.

Data lock-in

We have been talking about the vendor lock-in for years, where once you start using a provider it’s nearly impossible to move to a different one. I think the software world is like that no matter the software you use: once your software is running on production changing it is a really expensive and painful task.

Before the explosion of SaaS providers we had data exporting tools so you could more or less get your data in a standard format and import to another system. Today that’s not totally true: try to get all “your data” from your google analytics account. Don’t worry, those providers have tools that can access your data easily.

Hundred of services

10 years ago was easy to see a monolithic services running on just one big machine with everything needed in there (user management, accounting, the service itself) today you start a company and the one week later your software is talking to several services through HTTP APIs.

That’s good, you spend your time in the thing you provide more value instead of doing billing code.

Give me some stats

Eventually, someone will ask a question like “hey, how many users do we have in our XXXX tier, have signed up 3 times during the last month and also have ….”

So you either 1) use a platform that collects everything or 2) a one that fetches data from all those services and put data in a place you can query. in any case, querying data from a third party services is a pain. Here is the point where a lot of scrapping and “CSV file transfer” horror stories start.

Joinable API

Most of those operations are what we call joins. It’s easy to do when all the data is in the same place but hard to do in a distributed system.

So how do we keep those services and at the same time the possibility of using our data? why don’t we request to our service providers to have a Joinable API apart of full, easy to use and documented data dumps and their regular service API (more on this in this excellent talk)

Tech solution

Let’s imagine you have a regular OLTP database like Postgres, it’d be nice to be able to do:

SELECT * FROM MyTable 
JOIN Service('billingservice.com', 'transactions')
ON ... 
WHERE date = yesterday() ...

fetching remote data is already supported by Postgres using FDW (and all databases have a way to fetch remote data) but the problem is getting the data from the service.

The service would need to provide:

  • An API endpoint that exposes resources. It does not need to be HTTP but it’d work.
  • Each resource should be able to return a list of columns ordered by a column (so merge joins, the common ones in these operations are faster) with some filters (so databases can push down them)
  • Most likely the data format should be columnar so it takes less time over the network. An example dataset with 1M rows, 12 columns takes about 10mb with the data well prepared (compressed binary columnar data format). 1M rows are enough to cover most of the common use cases.
  • Ideally, some aggregations should be possible.
  • It must be really fast. That’s key but “batch” APIs traditionally have been slow.

This is what most of the distributed databases do, it’s not rocket science, a common well-tested pattern that every single service should expose so you don’t have data lock-in.

· #

Data lake parte IV, los cambios

El modelo de datos cambia sí o sí, básicamente porque modelan la vida real y la vida real cambia. Mucho.

Queremos que las cosas no cambien

Todas las bases de datos series tienen mecanismos para cambiar la forma de los datos. Es muy simple añadir una columna, cambiar el tipo o el nombre. Hay algunas incluso que el cambio es la constante como las orientadas a documento.

Dado que van a cambiar queremos:

  • Mantener todas las versiones de los datos
  • Tener registro de todos esos cambios
  • Poder consultar esos datos como si no hubiese cambios

Esto es más o menos trivial a nivel de gestión, lo complicado es saber cuando los datos han cambiado. Parece fácil, pero no lo es, a menudo los desarrolladores cambiamos el modelo de datos, el interfaz del API sin tener en cuenta todos los sistemas afectados.

Los tipos de cambios

Hay dos cambios fundamentales (bueno, seguramente más, pero estos son los peores) que se pueden producir en los datos:

  • Un cambio del esquema, es decir, hay una nueva columna o una vieja desaparece. Una columna ahora puede tener valores vacíos.
  • No hay cambios de esquema pero la semántica del dato es diferente. Un atributo pasa de millas a kilómetros.

En ambos casos debe haber una diferencia clara.

El interfaz común

La clave del asunto es no afectar a los sistemas que dependen de estos datos (si es posible). Si por ejemplo, se añade una nueva columna o atributo, es fácil hacer que los sistemas que beben información sean compatibles.

Si pasamos de millas a kilómetros es fácil que la mayoría de sistemas se vuelan locos. Tenemos dos opciones, o cambiar todos los sistemas que dependen de mis datos o expongo mis datos a través de un API en el que pueda multiplicar por 0.62 los datos en millas y por 1.0 los de kilómetros.

· #

Además de poder importar datos de forma sencilla hay otro tema fundamental que es saber qué datos has importado.

No me refiero solo a saber “el día 25 importamos estos datos” si no a saber de qué van esos datos:

  • Qué: datos de ventas
  • Cúando: creado el 7 de septiembre del 2018
  • Cómo: carga masiva de vaya usted a saber
  • Fuente: Oracle
  • Nombre Campos: A, B, C, D
  • Descriptión técnica de los campos: …
  • Descriptión de negocio de los campos: …
  • Relaciones de los campos con otras fuentes de datos: …
  • Historial de cargas

Obviamente son todos los que están pero no están todos los que son. De hecho hay un tema peliagudo que es el control de los cambios, pero eso lo vamos a dejar para la parte IV.

Pero esto no es todo. Aunque tengamos catalogados con absoluta perfección no solo tenemos los datos que entran, si no los que salen.

No tiene sentido tener un data lake sin poder explorar esos datos. Y lo habitual no es consultar los datos de entrada si no más bien datos derivados que muy posiblemente vengan de un JOIN (JOIN de SQL para los que vengan de usar Mongo) con otras 3 ó 4 fuentes de datos (alguna posiblemente externa). De hecho es casi más importante este catálogo como el de los datos de entrada. Pero de eso hablaré en la parte VII.

· #

Data Lake, parte II: las fuentes

Nadie crea una empresa con base tecnológica (*) y dice “empecemos pensando en el data lake”. Bueno, salvo que tu empresa sea de data lakes.

Si fuese así lo primero que crearísmos sería un equipo de data services que nos diera servicio para que los desarrolladores (y otras partes de la empresa, claro) pudieran almacenar los datos ahí.

Te imaginas tener un servicio donde un comercial conecte salesforce, una ingeniera cree “as a service” una base de datos para el core de la aplicación que sustenta el negocio y que todo estuviera en el mismo sitio y se puediera relacionar.

No hay que imaginarse mucho, AWS y Google llevan metiendo, poco a poco, todo su arsenal para que tus datos vivan allí y los consumas con sus, relativamente caros, servicios. De qué si no iba Amazon a darte S3 a un precio “tirado”?

Volvamos a la realidad.

El negocio crece, los datos crecen, el equipo crece, escalar tecnología es muy complicado, así que divides los equipos y eso hace que haya una o varias fuentes más de datos.

Llega nuestro amigo el data lake y dice: chavalada, sabéis esos datos que tenéis? pues me los tenéis que pasar o dejar recoger.

Esto en una empresa “nativa digital” es complicado, imagina en un corporate donde hay cientos de fuentes de datos, de departamentos diferentes. “a mi Oracle tú no entras que me lo tiras”, “estos datos son confindeciales”, “si borro un registro por imperativo legal (GPRD), como lo borras tú, amigo Data Lake”

Y aquí radica el principal y mayor problema de un data lake a nivel de organización. Así que toca hacer cosas como estas :

  1. Dejar de llamar al data lake “Data Lake” y empezar a llamarlo “servicios de datos”
  2. Hacer fácil que los equipos metan sus datos
  3. Hacer que los equipos sientan los datos como suyos aún dentro de un sitio común
  4. Hacer que los nuevos equipos/proyectos nazcan con los datos ya dentro del data lake

(*) La base de todas las empresas es la gente que pasa por ellas, la tecnología facilita.

· #

Data Lake parte I, Introducción

Yo no tengo ni idea de lo que es un data lake pero la definición se me parece a algo así: tira aquí todos los datos y ya veremos.

Pinta bien, si algún día necesitas no sé qué dato para hacer machine learning, ahí está, lo coges y lo usas.

Ahora, me pregunto: si es complicado mantener tus datos de producción, cómo demonios se mantiene mínimamente organizado, y por tanto usable, toda la cantidad de datos que genera una empresa.

Los datos son como el cuerpo humano: las partes que no ejercitas son grasa y esta pasa factura a largo (y a corto) y necesitas ejercitarlo para que funcione bien

Pero imaginemos que el data lake es perfecto:

  • II. Es capaz de recoger datos de todas las fuentes.
  • III. Tiene un catálogo de todos los datos con datos técnicos y de negocio
  • IV. Trazabilidad de cambios
  • V. Acceso segmentado por usuario
  • VI. Auditoría de lo que ha pasado
  • VII. Posibilidad de tener datos derivados (aplicando todo los anteriores)
  • VIII. Conclusiones y opinión personal

Me cuesta ver como alguien que no está acostumbrado a los datos pueda abrir Tableu, engancharlo ahí y sacar “insights”. A un desarrollador, en teoría más cerca de los datos, le cuesta trabajar solo con los datos de producción…

Me pregunto, no tiene sentido que la exposición de los datos sea también lo que llamamos “producto”?

· #

micro

Twitter es una maravilla, te permite hablar con gente y todo ese rollo que nos hace humanos. Pero:

Lo que escribes se va, aunque no tenga fecha de caducidad.

Lo que escribes es de twitter, cosa bastante justa porque ellos ponen la pasta.

Así que qué mejor que un repositorio donde almacenar esas cosas que, a veces, no entran en 200 y pico caracteres y que quiero que permanezcan.

Menos ruido, más contenido.

Esto es micro.

· #