Le monde tire de plus en plus de valeur des données, comme en témoigne le chatGPT dont on parle actuellement beaucoup, qui, je crois, est un analyste de données robotique. Cependant, à l’ère actuelle, ce qui est plus important que les données elles-mêmes, c’est la capacité de localiser rapidement les informations recherchées parmi toutes les données débordantes. Dans cet article, je vais donc parler de la façon dont j’ai amélioré l’efficacité globale du traitement des données en optimisant le choix et l’utilisation des entrepôts de données.
Trop de données dans mon assiette
Le choix des entrepôts de données n’a jamais figuré en tête de ma liste de préoccupations jusqu’en 2021. Je travaille comme ingénieur de données pour un fournisseur Fintech SaaS depuis sa constitution en 2014. Au début de l’entreprise, nous n’avions pas trop de données à jongler. Nous n’avions besoin que d’un outil simple pour OLTP et les rapports commerciaux, et les bases de données traditionnelles couperaient la moutarde.
Mais au fur et à mesure que l’entreprise grandissait, les données que nous recevions sont devenues extrêmement importantes en volume et de plus en plus diversifiées dans leurs sources. Chaque jour, nous avions des tonnes de comptes d’utilisateurs qui se connectaient et envoyaient des myriades de demandes. C’était comme collecter de l’eau à mille robinets pour éteindre un million de pièces de feu éparpillées dans un bâtiment, sauf que vous devez apporter la quantité exacte d’eau nécessaire pour chaque point de feu. De plus, nous recevions de plus en plus d’e-mails de nos collègues nous demandant si nous pouvions leur faciliter l’analyse des données. C’est alors que l’entreprise a réuni une équipe de big data pour s’attaquer à la bête.
La première chose que nous avons faite a été de révolutionner notre architecture de traitement des données. Nous avons utilisé DataHub pour collecter toutes nos données transactionnelles ou de journal et les ingérer dans un entrepôt de données hors ligne pour le traitement des données (analyse, calcul, etc.). Ensuite, les résultats seraient exportés vers MySQL puis transmis à QuickBI pour afficher les rapports visuellement. Nous avons également remplacé MongoDB par un entrepôt de données en temps réel pour les requêtes commerciales.
Cette nouvelle architecture a fonctionné, mais il restait quelques cailloux dans nos souliers :
- Nous voulions des réponses plus rapides. MySQL pouvait être lent à agréger de grandes tables, mais nos responsables produits ont demandé un temps de réponse aux requêtes inférieur à cinq secondes. Alors d’abord, nous avons essayé d’optimiser MySQL. Ensuite, nous avons également essayé d’ignorer MySQL et de connecter directement l’entrepôt de données hors ligne à QuickBI, en espérant que la combinaison de la capacité d’accélération des requêtes du premier et de la mise en cache du second ferait la magie. Pourtant, cet objectif de cinq secondes semblait inaccessible. Il fut un temps où je pensais que la seule solution parfaite était que l’équipe produit engage des personnes plus patientes.
- Nous voulions moins de douleur dans le maintien des tables de dimension. L’entrepôt de données hors ligne effectuait une synchronisation des données toutes les cinq minutes, ce qui le rendait inapplicable aux scénarios fréquents de mises à jour ou de suppressions de données. Si nous devions y conserver des tables de dimension, nous devions filtrer et dédupliquer les données régulièrement pour assurer la cohérence des données. Par notre instinct d’aversion pour les problèmes, nous avons choisi de ne pas le faire.
- Nous voulions prendre en charge les requêtes ponctuelles à haute simultanéité. La base de données en temps réel que nous utilisions auparavant nécessitait jusqu’à 500 ms pour répondre à des requêtes ponctuelles hautement simultanées dans le stockage en colonnes et le stockage en lignes, même après optimisation. Ce n’était pas suffisant.
Frappez là où ça fait le plus mal
En mars 2022, nous avons commencé notre recherche d’un meilleur entrepôt de données. À notre grande déception, il n’y avait pas de solution unique. La plupart des outils que nous avons examinés n’étaient bons que pour une ou quelques-unes des tâches, mais si nous rassemblions le meilleur interprète pour chaque scénario d’utilisation, cela équivaudrait à une boîte à outils lourde et désordonnée, ce qui allait à l’encontre de l’instinct.
Nous avons donc décidé de résoudre d’abord notre plus gros casse-tête : la lenteur de la réponse, car elle nuisait à la fois à l’expérience de nos utilisateurs et à l’efficacité de notre travail interne. Pour commencer, nous avons essayé de déplacer les plus grandes tables de MySQL vers Apache Doris, une base de données analytique en temps réel qui supporte le protocole MySQL. Cela a réduit le temps d’exécution de la requête d’un facteur huit. Ensuite, nous avons essayé et utilisé Doris pour accueillir plus de données.
Pour l’instant, nous utilisons deux clusters Doris : l’un pour gérer les requêtes ponctuelles (RPS élevé) de nos utilisateurs et l’autre pour les requêtes ad hoc internes et les rapports. En conséquence, les utilisateurs ont signalé des expériences plus fluides et nous pouvons fournir davantage de fonctionnalités qui étaient auparavant entravées par la lenteur de l’exécution des requêtes. Le déplacement de nos tables de dimension vers Doris a également permis de réduire les erreurs de données et d’améliorer l’efficacité du développement.
Les processus FE et BE de Doris peuvent être mis à l’échelle, de sorte que des dizaines de PB de données stockées dans des centaines d’appareils peuvent être placées dans un seul cluster. De plus, les deux types de processus implémentent un protocole cohérent pour assurer la disponibilité du service et la fiabilité des données. Cela supprime la dépendance à Hadoop et nous permet ainsi d’économiser le coût de déploiement des clusters Hadoop.
Conseils
Voici quelques-unes de nos pratiques à partager avec vous :
Modèle de données
Parmi les trois modèles de données Doris, nous trouvons que le modèle unique et le modèle agrégé répondent le mieux à nos besoins. Par exemple, nous utilisons le modèle unique pour assurer la cohérence des données lors de l’ingestion des tables de dimension et des tables d’origine et le modèle agrégé pour importer les données du rapport.
Ingestion de données
Pour l’ingestion de données en temps réel, nous utilisons le Flink-Doris-Connector : une fois que nos données commerciales, les binlogs basés sur MySQL, sont écrites dans Kafka, elles seront analysées par Flink, puis chargées dans Doris en temps réel.
Pour l’ingestion de données hors ligne, nous utilisons DataX : cela implique principalement les données de rapport calculées dans notre entrepôt de données hors ligne.
Gestion de données
Surveillance et alerte
En plus des différentes métriques de monitoring de Doris, nous avons déployé un plugin de journal d’audit pour surveiller de plus près certains SQL lents de certains utilisateurs pour optimisation.
Requêtes SQL lentes :
Certaines de nos métriques de surveillance souvent utilisées :
Compromis entre l’utilisation des ressources et la disponibilité en temps réel
Il s’est avéré que l’utilisation de Flink-Doris-Connector pour l’ingestion de données peut entraîner une utilisation élevée des ressources du cluster. Nous avons donc augmenté l’intervalle entre chaque écriture de données de 3 s à 10 ou 20 s, compromettant un peu la disponibilité en temps réel des données dans échange pour beaucoup moins d’utilisation des ressources.
Communication avec les développeurs
Nous avons été en contact étroit avec la communauté Doris open source depuis notre enquête jusqu’à notre adoption de l’entrepôt de données, et nous avons fourni quelques suggestions aux développeurs :
- Activez Flink-Doris-Connector pour prendre en charge l’écriture simultanée de plusieurs tables dans un seul récepteur.
- Activez les vues matérialisées pour prendre en charge la jointure de plusieurs tables.
- Optimisez le compactage sous-jacent des données et réduisez autant que possible l’utilisation des ressources.
- Fournissez des suggestions d’optimisation pour le SQL lent et des avertissements pour les comportements de création de table anormaux.
Si l’entrepôt de données parfait n’est pas là pour être trouvé, je pense que fournir des commentaires pour le deuxième meilleur est un moyen d’aider à en créer un. Nous examinons également sa version commercialisée appelée SelectDB pour voir si des fonctionnalités avancées plus personnalisées peuvent graisser les roues.
Conclusion
Alors que nous cherchions à trouver un entrepôt de données unique qui pourrait répondre à tous nos besoins, nous avons fini par trouver quelque chose de moins que parfait mais assez bon pour améliorer considérablement la vitesse de nos requêtes et en avons découvert quelques caractéristiques surprenantes en cours de route. Donc, si vous oscillez entre différents choix, vous pouvez parier sur celui avec la chose que vous voulez le plus, et vous occuper du reste ne sera pas si difficile.