🎙 Episodio 53. El Big Data de Uber

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 en Uber

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.

Los inicios del Big Data en Uber: Cuando aĂșn solo era "Data"

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.

El primer Data Warehouse de Uber

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.

Limitaciones de la primera soluciĂłn de Big Data en Uber

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.

Uber conoce a Hadoop 🐘

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.

Limitaciones del ecosistema de Big Data basado en Hadoop en Uber

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. 

Uber migra su Big Data a Google Cloud

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.

BoletĂ­n Ninja

SuscrĂ­bete a la newsletter y recibe la guĂ­a ninja del Big Data y la Inteligencia Artificial.

GuĂ­a ninja del Big Data
Copyright © 2023  Â· Datos đŸ„· · Todos los derechos reservados