Plate-forme de données Eats : donner aux entreprises les moyens d’accéder aux données | Ingénierie Coupang

Comment Coupang Eats a construit un système d’ingestion, de traitement et d’utilisation de données basé sur la configuration – Partie 1

Par Fred Fu

La commande et la livraison de nourriture en ligne est un marché extrêmement concurrentiel, où la rapidité est la clé de la survie. Coupang Eats (appelé simplement Eats) est la filiale de livraison de nourriture du géant sud-coréen du commerce électronique, Coupang.

Dans cet article, nous expliquerons comment l’équipe de la plate-forme de données Eats a construit un système de traitement de données générique et basé sur la configuration qui accélère notre croissance en automatisant les opérations commerciales critiques.

Table des matières

Introduction
Architecture de la plateforme de données Eats
· Pipelines de traitement de données
∘ Hors temps réel
∘ Temps quasi réel (NRT)
∘ Temps réel pur
Conclusion

Eats est une entreprise relativement nouvelle qui a été lancée fin 2019. Au début, nous étions occupés à mettre en place les opérations et à nous assurer que tout se passait bien. Mais maintenant, nous en sommes au stade de notre activité où notre objectif est non seulement de garantir la stabilité des applications, mais également de s’assurer qu’elles fonctionnent de manière plus efficace et intelligente.

Cela signifie utiliser l’automatisation des données et des modèles complexes d’apprentissage automatique (ML) pour accélérer les activités d’un plus grand nombre de clients à moindre coût d’ingénierie. Par exemple, nous entraînons actuellement des modèles ML pour les estimations des délais de livraison, effectuons des promotions automatiques aux clients sur la base de balises utilisateur en temps réel et créons des services de données dynamiques pour prendre en charge les visualisations de données et les calculs de métriques. Certains détails sur la façon dont nous utilisons la science des données pour surmonter les défis de la livraison de nourriture peuvent être trouvés dans notre article précédent.

La base de ces opérations intelligentes et automatisées repose sur une plate-forme de traitement de données robuste et complète qui peut s’adapter à la croissance de notre clientèle et répondre à tous nos besoins commerciaux, qu’il s’agisse d’analyses en temps réel ou de services de données hors ligne.

Au début de notre activité, nous n’avions pas de plate-forme de données centralisée. La formation et le service des modèles ML et d’autres services de science des données ont été exécutés équipe par équipe avec peu de coordination. Certains de nos points faibles incluent une ingénierie de fonctionnalités inefficace, une surveillance et une alerte lentes des métriques, un manque de visualisations de données complexes, etc. Non seulement cette inefficacité a été un gaspillage de nos ressources d’ingénierie, mais elle est également devenue un gros goulot d’étranglement dans nos efforts d’expansion. Suivez notre compte pour notre prochain article, où nous discuterons plus en détail de ces points douloureux.

Une plateforme de données est chargée de gérer le cycle de vie du flux de traitement des données du début à la fin. Un cycle de vie typique du traitement des données se compose des étapes suivantes :

1. Ingestion de données est le première étape, où les données proviennent de diverses sources. Pour assurer un flux de données fluide dans les étapes suivantes, les données sont hiérarchisées et catégorisées au cours de cette étape.
2. Pré-traitement des données Il consiste à remplir des valeurs vides, à exécuter un formatage standard, à vérifier la qualité des données, à filtrer les données, etc. L’objectif principal du prétraitement est de préparer les données pour les tâches de science des données et d’apprentissage automatique.
3. traitement de l’information implique de transformer les données brutes en types de sortie souhaités selon les besoins pour l’analyse de données complexes. Cette étape comprend également le transfert des données vers les stockages de données appropriés.
4. Utilisation des données génère des analyses à partir des données traitées. Dans cette dernière étape, les valeurs des données sont collectées et introduites dans un large éventail de DaaS qui aident à résoudre intelligemment les problèmes commerciaux.

La plate-forme de données Eats suit les quatre étapes ci-dessus, et vous pouvez voir son architecture détaillée dans la figure 1. La plate-forme est un système à guichet unique qui peut prendre en charge tous nos besoins de traitement de données de manière efficace. Les analystes commerciaux (BA), les ingénieurs de données et les scientifiques des données utilisent notre plate-forme flexible comme un système intégré qui répond à tous leurs divers besoins en données.

La livraison de nourriture est une activité complexe car il s’agit d’un marché à trois faces avec des clients, des partenaires de livraison Eats (EDP) et des commerçants qui nécessite de nombreux calculs en temps réel. Par exemple, l’attribution d’une commande à un partenaire de livraison doit être effectuée en quelques secondes pour la livraison la plus rapide aux clients. Cependant, d’autres tâches, telles que la segmentation des utilisateurs pour les publicités ciblées, ne sont pas aussi urgentes et ne doivent pas être effectuées en temps réel.

Notre plate-forme de données a été conçue pour s’adapter à des tâches avec des exigences de temps aussi radicalement différentes. Dans cette section, nous nous concentrons plus en détail sur les pipelines de traitement de données de notre plateforme de données. Les moteurs de calcul sont responsables du traitement des données en temps non réel, en temps quasi réel et en temps réel.

Hors temps réel

• Efficacité temporelle : au moins 1 heure

Le pipeline en temps différé s’exécute en mode batch avec un planificateur de tâches. Ce pipeline prend en charge la production de fonctionnalités liées au ML, le profilage des utilisateurs et la génération de balises, ainsi que la visualisation des données.

Avant de développer notre plate-forme de données, le plus gros problème du pipeline en temps non réel consistait à pousser les fonctionnalités et les signaux hors ligne vers le stockage en ligne. Le téléchargement de la taille massive des ensembles de données par lots traités était lent, inefficace et coûteux pour nos systèmes.

Pour résoudre ce problème, nous avons développé un pipeline piloté par la configuration pour accélérer ce processus. Avec une approche basée sur la configuration, les ingénieurs peuvent simplement définir de nouvelles configurations pour ajouter une nouvelle source de données, ce qui rend le processus simple et mains libres. En fait, il suffit de suivre les trois étapes simples définies ci-dessous.

1. Définissez les informations de synchronisation des données dans notre système de gestion des métadonnées. Nous pouvons même définir un groupe de fonctionnalités complet, qui peut contenir de nombreuses fonctionnalités prédéfinies pour un scénario métier spécifique et les relations de mappage entre les fonctionnalités et les colonnes de la table Hive.
2. Fournissez un SDK Spark générique qui lira les données Hive et synchronisera les fonctionnalités avec le magasin de fonctionnalités en ligne en fonction de la configuration prédéfinie des métadonnées et du mappage.
3. Créez une tâche Spark dans le planificateur de tâches et consultez le SDK pour synchroniser automatiquement les données avec notre stockage en ligne.

Quasi temps réel (NRT)

• Efficacité temporelle : ≥ 30 secondes

Bien que le streaming de données en temps réel soit pris en charge par diverses applications, il s’agit d’une lourde charge sur l’infrastructure de données et nécessite une configuration technique de haut niveau. Le streaming de données en temps réel manque également de flexibilité pour prendre en charge l’évolution des besoins de l’entreprise.

En raison de ces avantages, nous avons conçu un pipeline en temps quasi réel (NRT) qui tire parti des moteurs OLAP hautes performances. Le pipeline NRT peut générer des signaux proches du temps réel via des tâches planifiées qui exécutent des scripts SQL. Le pipeline NRT prend en charge la génération de fonctionnalités en temps réel pour la prédiction ML, la création de balises utilisateur en temps réel et le tableau de bord et l’alerte de métriques commerciales en temps réel.

Le moteur NRT est un pipeline générique piloté par la configuration, comme le pipeline non en temps réel. Le code peut prendre en charge différents types d’entreprises via SQL, un langage familier aux ingénieurs de données, aux data scientists et aux BA. Depuis l’entretien du pipeline NRT pendant plus de six mois, l’efficacité de notre production de longs métrages s’est considérablement améliorée.

Voici comment nos utilisateurs internes utilisent le pipeline NRT :

1. Ingérez les messages Kafka en amont vers le moteur OLAP ou lisez les données d’une table Hive dans le stockage cloud.
2. Exécutez le SQL du moteur OLAP à intervalles réguliers (30 secondes à 1 heure). Au cours de cette étape, des tables étendues sont créées en joignant plusieurs sources de table ingérées à partir de Kafka ou du stockage cloud, qui stockent toutes deux des données en temps réel.
3. À l’aide des tables étendues générées à l’étape précédente, le scientifique des données crée des tâches SQL du moteur OLAP planifiées pour générer des métriques et des signaux en temps quasi réel.
4. Le planificateur de tâches exécutera le SQL à l’intervalle défini et enverra les signaux produits à Kafka pour les tâches en aval à des fins de consommation ou d’écriture dans le stockage de données.

Temps réel pur

• Efficacité temporelle : < 1 seconde

Le pipeline NRT pourrait couvrir environ 80 % de nos cas d’utilisation de fonctionnalités en temps réel en production. Cependant, il ne pouvait pas prendre en charge des scénarios à très haute efficacité et à faible latence tels que la détection des inondations et le contrôle des risques.

De telles tâches soulagées sur des données en temps réel pures. Cependant, le pipeline en temps réel pur utilise Spark et un autre moteur de traitement distribué. Étant donné que la plupart des utilisateurs de données n’étaient pas familiarisés avec l’écriture de codes de diffusion en continu Spark, il n’était pas pratique de s’attendre à ce qu’ils puissent écrire en continu du code à la demande pour des tâches de données en temps réel.

Encore une fois, nous avons développé un pipeline piloté par la configuration qui pourrait être facilement utilisé pour le traitement des données en temps réel par tous les utilisateurs. Vous trouverez ci-dessous une description de son processus.

1. Ingérez les données nécessaires dans un sujet Kafka.
2. Partitionnez dynamiquement les données d’événement entre différents opérateurs en aval en fonction de la méta-configuration des fonctionnalités en temps réel via le système de diffusion.
3. Calculez les valeurs des fonctionnalités en temps réel en fonction d’un agrégateur pré-implémenté différent en fonction de la définition des métadonnées des fonctionnalités. Envoyez la valeur calculée à Kafka ou à l’opérateur en aval, instantanément ou périodiquement.

Le pipeline en temps réel pur prend actuellement en charge une dizaine de fonctions statistiques fréquemment utilisées telles que SUM, COUNT, UNIQUE COUNT, TOPN. De plus, le pipeline prend en charge les fonctions statistiques multidimensionnelles. Avec ce pipeline en temps réel pur, nous pouvons définir le flux de données sans code. Cela a considérablement réduit le coût du calcul des fonctionnalités en temps réel et augmenté notre efficacité.