Plataforma Big Data de UBER

Plataforma Big Data de UBER

1. 1era Generación: El comienzo de Big Data en Uber (2014 -2015)

   • Manejo de pocos terabytes en MySQL y PostgreSQL con latencia en el orden del minuto
     • Se categorizan los usuario de datos en tres categorias con el fin de que Uber sea basado en datos
       • Cientificos y analistas de datos (cientos de usuarios) repartidos en diferentes grupos funcionales
       • Equipo de ingenieria (Cientos de usuarios) Centrados en crear aplicaciones de datos automatizadas
       • Equipos de operaciones en la ciudad (miles de usuarios) administran y escalan la red de transporte de Uber en cada mercado
   • Almacen Análitico
     • Utilización de Vertica
     • Generación de ETL ad-hoc
     • Estandarización de SQL como interfaz de la aplicación utilizada
     • Creación de servicio de consultas en línea para las consultas de usuarios y enviarlas al motor de consultas
   • Limitaciones 1era generación
     • Preocupación en la confiabilidad de los datos
     • Rigidez en formato de archivos origen JSON
     • Sobre costos por creciente almacenamiento de datos
     • No escalabilidad horizontal
     • Duplicación de datos por no existir protocolos en la ingestión de datos

2. 2da Generación: La llegada de Haoop (2015-2016)

   • Inconporación del ecosistema Hadoop
     • Ingestión de datos sin procesar a DataLake
     • ETL ad-hoc desde datalake a bases de datos escalables
     • Utilización de Presto para realizar consultas iterativas
     • Utilización de Apache Spark para el acceso de datos programados sin procesar
     • Utilización de Apache Hive para ejecución de las consultas extremadamente grandes
     • Utilización de Apache Parquet integrada con Apache Spark
     • Incorporación de escalado horizontal para todos los servicios de datos
     • Esquematización de todos los datos permitiendo realizar la transición de JSON a Parquet
   • Se agregaron decenas de terabytes diarios de datos nuevos al datalake, la plataforma de big data creció en más de 10.000 cores con unos 100.000 procesos diarios por lotres
   • Limitaciones 2da. generación
     • Sobrecarga sobre los namenodes de HDFS por la gran cantidad de pequeños archivos generados
     • Latencia de 24 hs para el acceso a los datos nuevos por parte del negocio
     • Aun se presenta cuello de botella en las ETL ya que tiene que poblar todo la tabla en cada ejecución
     • Procesos de ingestión de datos podían llevar más de veinte horas con más de 1,000 ejecutores de Spark en proceso.
     • Se presentan problemas en la actualización de datos ya que HDFS y Parquet no admiten la funcionalidad

3. 3er Generación: Reconstrucción de la plataforma de Big Data a largo plazo (2017)

   • Comenzaron a sufrir problema de alta latencia de datos, llegando al limite de la escalabilidad.
     • Atacaron cuatro puntos para solucionarlo
       • ETL y modelado más rápido: Los trabajos de modelado y ETL requieren que la plataforma reconstruya las tablas en cada ejecución con alta latencia de datos.
         • Mitigante: ETL gradualmente extraían solo los datos modificados de la tabla de origen sin procesar y actualizar la tabla de salida
       • Velocidad de lectura: 24hs de latancia para obtener un reporte no era viable para el negocio
         • Mitigante utilizado: Se rediseñó la tubería para la ingestión incremental de datos unicamente actualizados y nuevos
       • Limitaciones de escalabilidad de HDFS: la gran catidad de pequeños archivos afecta la performance de los namenodes alrededor de los 10 betabytes y es un problema por arriba de los 50-100
         • Mitigante utilizado: ViewFS y Federación HDFS NameNode
       • Actualizaciones y eliminaciones en Hadoop y Parquet: Hadoop y Parquet no soportan las actualizacones y las eliminaciones de forma instantanea, problema para el cual deben encontrar una solución
   • Intoducción de Hudi: Hadoop Upserts Deletes Incremental, es una biblioteca de código abierto de Spark que brinda una capa de abstracción sobre HDFS y Parquet para admitir las operaciones de actualización y eliminación necesarias. Es escalable horizontalmente y solo depende de HDFS para operar.
     • Permite a los usuarios de datos extraer de forma incremental solo los datos modificados,
     • Permite un modelo de ingesta de datos incremental la cual reduce la latencia de datos de 24 horas a menos de una hora.
   • Ingesión generica de datos
     • Formalización del traspaso de los cambios del almacén de datos entre los equipos de almacenamiento y big data a través de Apache Kafka
   • Modelado incremental de datos
   • Modelo de datos estandarizados

4. 4ta Generación: ¿Qué sigue?