Construyendo una empresa data-driven sobre Google Cloud

La nota salió originalmente en inglés en el Blog de Google Cloud. Pueden acceder a la publicación desde aquí.

Tener acceso constante a datos actualizados es un requisito clave para que PedidosYa pueda mejorar e innovar la experiencia de nuestros clientes. Nuestras partes interesadas internas también requieren obtener conocimientos en forma más rápida a fin de impulsar decisiones de negocio ágiles. A principios de 2020, los líderes de PedidosYa asignaron al equipo de datos la tarea de hacer posible lo imposible. La misión de nuestro equipo era democratizar los datos proporcionando acceso universal y seguro mientras se creaba un ecosistema de información integral en PedidosYa. También teníamos que lograr este objetivo manteniendo los costos bajo control, incluso durante la etapa de migración y eliminando los cuellos de botella operativos.

Desafíos con la infraestructura preexistente, en la nube

PedidosYa primero construyó su plataforma de datos sobre AWS. Nuestro datawarehouse se montó sobre Redshift y nuestro datalake — estaba en S3. Usamos Presto y Hue como interfaces de usuario para nuestros analistas de datos. Sin embargo, el mantenimiento de esta infraestructura era una tarea abrumadora. Nuestra plataforma legacy no podía mantenerse al día con las crecientes demandas de análisis. Por ejemplo, los datos almacenados en S3 complementados por Presto / Hue requerían una alta sobrecarga operativa. Esto se debió a que Presto y nuestra IAM (administración de acceso a la identidad) no se integraron bien en nuestro ecosistema existente (“legacy”). Administrar usuarios individuales y mapear roles de IAM con grupos y Kerberos requería mucho tiempo y era costoso desde el punto de vista operativo. Además, fragmentar el acceso a los archivos S3 era demasiado complicado para permitir ACL (listas de control de acceso) sin fisuras.

También hubo algunos desafíos con la gestión de la carga de datos. La carga del datawarehouse era por las noches en forma batch (por lotes). Si un analista programaba una consulta para que se ejecutara durante un proceso ETL (extraer, transformar, cargar) durante la noche, se interrumpía la tarea ETL en curso. Esto podía detener todo el “pipeline” de datos. Teniendo que esperar hasta que los ingenieros de datos intervinieran con una solución manual.

Por otra parte, era difícil comprender si un error de consulta se debía a problemas de desempeño o al agotamiento de los recursos de la plataforma. Esta falta de claridad afectó la capacidad de nuestros analistas de datos para mejorar la eficiencia de las consultas en forma autónoma. Los miembros del equipo de datos necesitaban inspeccionar manualmente las consultas personales para detectar problemas de desempeño. Además, la arquitectura actual era propensa a una situación de “tragedia de los comunes”; considerando la plataforma como un recurso ilimitado y gratuito. Como consecuencia, fue imposible separar la infraestructura en función de las diferentes áreas que componen la empresa, donde las necesidades son muy diferentes.

La decisión de modernizar nuestro almacén de datos

Dados los crecientes desafíos de nuestra plataforma legacy , nuestro equipo de tecnología decidió que era hora de transformar nuestra plataforma de datos. Los criterios de decisión para la nueva plataforma fueron los siguientes:

• Escalabilidad: la capacidad de crecer con una infraestructura que se adapte de forma flexible al incremento de datos y demanda analítica.

• Control de costos — Gestión de costos y transparencia. Estos factores promueven la eficiencia y la responsabilidad, ambos aspectos clave de la democratización de los datos.

• Gestión de metadatos: plataforma de datos intuitiva que se centra en el conocimiento previo de SQL, siendo la curva de aprendizaje mínima. Además, poder enriquecer el ecosistema informativo con metadatos, para disminuir los custodios o “gatekeepers” de los datos.

• Facilidad de administración: el equipo necesitaba reducir los costos operativos con una solución serverless. De esta forma los ingenieros de datos pueden centrarse en sus funciones clave y añadir valor al usuario final en lugar de actuar como administradores de bases de datos e ingenieros de infraestructura. El equipo también quería una disponibilidad mucho mayor y reducir el impacto de las ventanas de mantenimiento sobre el datawarehouse.

• Gobernanza de datos y derechos de acceso: con una base de empleados en crecimiento con diferentes requisitos de acceso a datos, el equipo necesitaba una solución simple pero completa para comprender y rastrear el acceso de los usuarios a los datos.

Migrar a Google Cloud

Después de explorar otras alternativas, llegamos a la conclusión de que Google Cloud tenía una respuesta a cada uno de nuestros drivers de decisión. La plataforma de datos integrada, gestionada y sin servidor de Google Cloud, junto con su perfecta integración con soluciones de código abierto, fue la respuesta perfecta para nuestra organización. En particular, fue clave la integración natural con Airflow como orquestador de trabajos y Kubernetes para una infraestructura flexible bajo demanda.

Usamos Dataflow junto con Pub / Sub y Cloud Functions para la ingesta de datos, lo que hizo que nuestro proceso de deploy con Terraform fuera ágil y eficiente. Debido a que configuramos todo en nuestro entorno de manera programática, se ha reducido el tiempo de operación. En Google Cloud se redujo el proceso de deploy de aproximadamente 16 horas en nuestra plataforma legacy a 4 horas. Esto se debe en parte a la facilidad de automatizar el proceso de deploy (como verificación de esquema, prueba de carga, creación de tablas, compilación) con Terraform, Cloud Functions, Pub / Sub, Dataflow y BigQuery en GCP. Los mensajes de entrada procesados ​​con Dataflow nos permiten abstraer y planificar los cambios de esquema según las necesidades del equipo funcional. Por ejemplo, los cambios de esquema generan una alarma y luego podemos modificar el esquema de la tabla de la capa sin procesar. Al hacerlo, nos aseguramos de que las modificaciones de “backend” que no controlamos no afecten a las capas superiores.

Una razón clave por la que elegimos Google Cloud fue por su avanzada administración de costos y cargas de trabajo junto con sus análisis de registros transparentes. Esta información nos brinda una visión completa de los problemas de desempeño de las consultas para realizar mejoras sobre la marcha. Además, logramos una cantidad significativa de ahorros de costos al consolidar varias herramientas en BigQuery.

Con BigQuery, pudimos reducir nuestro costo total por consulta en 5 veces.

Esto se debió a varias razones:

• La automatización de la implementación del pipeline facilitó el mantenimiento de los procesos relativos al procesamiento de datos.

• Los analistas son conscientes de las consultas que están ejecutando, lo que da como resultado que ejecuten consultas mejor y más optimizadas.

• Los analistas utilizan un panel de Data Studio para ver sus consultas y todos los costos asociados. Como consecuencia, existe mucha más transparencia para cada persona.

Con estos cambios, podemos gestionar y asignar fácilmente los costos asociados con cada carga de trabajo con sus propios centros de costos utilizando proyectos específicos de Google Cloud.

La gestión del cambio siempre es un desafío. Sin embargo, BigQuery es intuitivo y no tiene una curva de aprendizaje pronunciada de Hue / Hive en los conceptos básicos de SQL. BigQuery también permitió al equipo expandir sus capacidades y les dio la posibilidad de trabajar correctamente con estructuras anidadas, evitando uniones innecesarias y mejorando la eficiencia de las consultas. Además, ahora usamos Data Catalog como nuestro único punto de verdad para la gestión de metadatos. Esto permite a nuestro equipo romper las barreras de acceso a los datos y permitir la federación de datos en toda la organización. Al utilizar Airflow para organizar todo, hacemos un seguimiento de cada flujo de datos. Con esta información, cada usuario final puede ver el estado de las entidades de datos que utiliza habitualmente a través del panel de control. Esto también agrega transparencia a nuestros procesos diarios de datos.

Por último, con las reglas de IAM de Google Cloud aplicadas en los diferentes productos, el acceso y el intercambio de datos es casi una experiencia sin operaciones (“noOps”). Hemos implementado el acceso programáticamente, según roles y niveles de acceso dentro de la empresa. Esto permite que ciertos roles previamente validados vean información más sensible. Estas soluciones ayudan a impulsar una experiencia de gobernanza de datos más automatizada.

A continuación: Google Cloud AI / ML

El nuevo stack tecnológico basado en BigQuery ha generado importantes logros de productividad. Liberado de la carga de la gestión operativa, el equipo de datos de PedidosYa ahora puede centrarse en agregar valor a través de productos y herramientas de datos.

• Nuestros ingenieros de datos están mejor equipados para integrar datos operacionales y transaccionales en constante cambio.

• El equipo de DataOps puede automatizar la infraestructura y brindar autonomía al usuario final.

• Nuestro equipo de calidad de datos puede enfocarse en agregar valor agregado al usuario final..

• Los científicos de datos y el analista de datos pueden dedicar más tiempo a analizar datos y menos a pedir accesos a los mismos..

PedidosYa está en posición de democratizar el acceso a los datos mediante una arquitectura bien gobernada. Recién estamos comenzando nuestro viaje, pero nos encontramos más cerca de lograr nuestra visión de construir una organización basada en los datos. El próximo paso: ampliar nuestras capacidades de inteligencia artificial y aprendizaje automático.