En el episodio de hoy de Un podcast ninja sobre Big Data hacemos un repaso de cómo Uber tiene montada su plataforma de Big Data y cómo ha evolucionado con el tiempo 🚙
El volumen de datos con el trabaja Uber asciende a más de 1 Exabyte, que es como un millón de Terabytes…
Vamos, muchísimo.
Durante los primeros años, recordemos que Uber nace en 2009, únicamente utilizaban los datos que eran capaces de almacenar en bases de datos transaccionales clásicas.
Para ello los ingenieros accedían a las tablas de las bases de datos que necesitaban y escribían las consultas que necesitaban en SQL de manera personalizada y bajo demanda.
Por aquel entonces los datos estaban guardados en tablas separadas en bases de datos separadas y cada uno trabajaba con los datos de los que tenía conocimiento.
No había una visión global de los datos almacenados.
Tenían unos cuantos Terabytes de datos.
Hoy en día hay discos duros externos con esa capacidad y cualquier particular puede comprarlo. No parece Big Data todavía.
Lo que pasa es que Uber crecía muy rápido.
También lo hacía el volumen de datos que manejaba y la necesidad de ser capaces de analizar esos datos.
Así que en 2014 construyeron su primer almacén de datos.
Para este primer almacén el objetivo fue ser capaces de agregar todos los datos en un mismo lugar y poder coordinar el acceso a esos datos.
Así que eligieron el almacén de datos de Vertica porque era rápido, se podía escalar y tenía un diseño orientado a columnas, que era lo que ellos necesitaban.
Sus ingenieros desarrollaron unas cuantas canalizaciones para extraer, transformar y cargar los datos desde las distintas fuentes de datos que tenían hasta el almacén de Vertica.
Y ya estaría.
Todos los datos llegaban hasta el almacén mediante las ETL que tenían y de ahí cualquier científico de datos o analista de Uber que los necesitara para su trabajo pues ahí los tenía.
Todos en el mismo sitio.
Además como para consultar el almacén de datos habían puesto un interfaz sencillo de SQL los equipos de operaciones podían hacer acceder sin problemas ya que no tenían porqué saber técnicamente nada más allá de SQL.
La nueva arquitectura fue un éxito y muchos equipos dentro de Uber la utilizaban de manera intensiva para consultar datos.
Incluso se montaron nuevos equipos para poder sacar partido a todos esos datos. Equipos que después desarrollarían modelos de Machine Learning para integrar cositas en la app de Uber para mejorar la experiencia de los usuarios.
Y con todo este uso empezaron a darse cuenta de las limitaciones que tenía su primera solución con un data warehouse de Vertica.
Para empezar, como para cargar la data en el almacén habían ido creando canalizaciones ETL un poco bajo demanda y personalizadas para cada caso pues vieron que la fiabilidad de los datos del almacén hacía aguas.
A veces los datos aparecían duplicados en el almacén y tenían que hacer un esfuerzo adicional para intentar mantener la calidad de los datos.
Además, si querían introducir datos de alguna fuente nueva tenían que implementar una canalización para extraerlos, transformarlos y cargarlos en Vertica desde casi cero.
Como habían hecho con el resto de ETLs.
Y, por si esto no fuera poco, con el crecimiento tan rápido que tenían en cuanto a volumen de datos, los costes de hacer el almacén de Vertica cada vez más grande eran muy elevados.
Así que para ahorrar empezaron a borrar los datos más antiguos y poder liberar espacio.
Básicamente tuvieron un problema que tienen muchas empresas al principio, cuando empiezan a pensar en Big Data.
Estaban usando su almacén de datos como un lago de datos en el que apilaban los datos que tenían de cualquier manera.
Como cuando vas al trastero de tu casa, abres la puerta y dejas lo que sea que ya no sabes cuando o si lo vas a volver a usar. Cierras la puerta detrás de ti, sin mirar atrás…
Lo que pasa es que en este caso, era de ese mismo trastero del que intentaban obtener los datos para su uso diario.
Para poner un poco de orden en todo esto y superar las limitaciones que tenía la solución que tenían montada hasta aquel momento (era el año 2015) exploraron el ecosistema Hadoop, un ecosistema con un montón de herramientas de código abierto para funcionar en entornos de Big Data.
En ese momento lo que hicieron fue introducir un lago de datos Hadoop en el que poder ir dejando todos los datos en crudo sin transformaciones.
Igual que habían hecho hasta ese momento con su almacén de datos pero sin transformar los datos.
Además del data lake Hadoop empezaron a usar otras herramientas de código abierto para poder acceder y trabajar con los datos del data lake como Presto, Apache Spark y Apache Hive.
Así, cada equipo de Uber podía acceder a los datos de la manera más conveniente para ellos.
¿Y qué pasó con el almacén de datos de Vertica?
Pues que aunque se aseguraron de que las transformaciones de datos únicamente tenían lugar en Hadoop, donde estaba el grueso de sus datos, aún tenían algunas tablas de datos más críticas que usaban los equipos de operaciones de Uber en las distintas ciudades y que necesitaban acceder a la información casi en tiempo real.
Esas tablas se quedaron en el almacén de datos.
Al ser solo una pequeña porción de los datos la que permanecía en el almacén de Vertica consiguieron reducir los costes.
Además comenzaron a utilizar un tipo de formato de fichero columnar más comprimido, también de código abierto, llamado Apache Parquet.
Y con eso redujeron aún más la cantidad de almacenamiento que necesitaban.
Por aquel entonces Uber manejaba unos 10 Petabytes de datos.
Como véis el crecimiento del volumen de datos que manejaba estaba disparado.
Desde algunas decenas de Terabytes en 2014 cuando decidieron montar su primer almacén de datos hasta decenas de Petabytes un par de años después.
Un orden de magnitud más.
Con la implantación de todas esas herramientas de código abierto basadas en el ecosistema Hadoop, Uber, dejaba claro su acercamiento a la comunidad de código abierto.
Desde entonces ha preferido usar siempre que ha sido posible estas herramientas y customizarlas según sus necesidades.
Además en muchas ocasiones ha contribuido a la comunidad liberando sus soluciones para que las pudiera usar todo el mundo.
El tema es que incluso con esta arquitectura basada en Hadoop seguían viendo limitaciones.
Principalmente en el tiempo que tardaban los datos en ser accesibles cuando entraban el data lake, que era de unas 24 horas.
Lo que es demasiado para poder hacer nada que remotamente pueda llamarse tiempo real.
Estaban tardando demasiado en ingestar los datos en la plataforma porque su proceso era ineficiente.
Además, se enfrentaban a la limitación que tiene HDFS, el sistema de ficheros de Hadoop, cuando se enfrenta a muchos ficheros muy pequeños.
HDFS almacena metadatos sobre los archivos que gestiona y lo guarda en un servidor maestro llamado Namenode.
Cuando tenemos una gran cantidad de archivos pequeños, la cantidad de metadatos puede ser abrumadora y generar una sobrecarga en el Namenode.
Esto puede afectar negativamente el rendimiento y la escalabilidad del sistema, ya que el Namenode debe gestionar todos estos metadatos en memoria.
Vamos que HDFS funciona mejor con archivos grandes y éste no era el caso de Uber.
Para resolver el primer problema que tenía su arquitectura de Big Data y conseguir que su proceso de ingesta de datos fuera más eficiente desarrollaron una librería de Spark, Hudi, que después pasaría a formar parte del propio ecosistema de código abierto Hadoop con el nombre de Apache Hudi.
Desde entonces Uber ha seguido trabajando y mejorando su infraestructura de Big Data pero siempre apostando por tener sus propios centros de datos.
De hecho aunque tiene un modelo híbrido y ya usa la nube, el 95% de su infraestructura estaba en sus propios centros de datos.
Y sí, he dicho estaba porque este mismo año ha firmado un acuerdo con Google Cloud para migrar toda su infraestructura a la nube.
En los próximos años dejarán de ser una de las pocas empresas con un volumen de datos tan alto en seguir gestionando sus propios centros de datos.
Durante el Covid tuvieron bastantes problemas para asegurarse el suministro de servidores, chips y piezas hardware, que necesitaban para mantener sus centros de datos a punto. Y esa es una de las razones fundamentales que les han llevado a migrar su ecosistema de Big Data a Google Cloud.
Al hacer esto y pasar toda su infraestructura de Big Data a la nube de Google pueden centrarse en mejorar y diferenciar su producto y dejar de preocuparse por la gestión de los centros de datos.
Ya se encargará Google de encontrar chips para mantener los centros de datos a punto.
Si queréis saber un poco más sobre la nube, podéis escuchar este episodio del podcast.
Espero que os guste el episodio.
Si es así, no olvidéis dejar un «Me gusta» y algún comentario al episodio en Ivoox o una valoración de 5 estrellas del podcast en Apple podcasts, en Spotify, en Google podcasts o donde quiera que escuchéis el podcast.
Recordad que si tenéis cualquier duda o pregunta podéis contactar conmigo a través del formulario de contacto o podemos seguir la conversación en Twitter.
Muchas gracias por estar ahí y os espero en el próximo episodio de Un Podcast Ninja sobre Big Data.