Guide de cet article :

OneConnect, en tant que société affiliée de Ping An Group of China, s'appuie sur la riche expérience de Ping An Group dans le secteur financier et sur ses capacités de recherche scientifique indépendante depuis plus de 30 ans pour fournir à ses clients des produits intégrés d'« intégration horizontale et de couverture complète verticale ». Une compétitivité unique aide les clients à améliorer l'efficacité, à améliorer le service, à réduire les coûts, à réduire les risques et à réaliser la transformation numérique. Dans le processus de création d'une solution numérique, face à des problèmes tels qu'un calibre d'index incohérent, des calculs répétitifs et une faible efficacité de livraison dans le processus de production de rapports traditionnel, OneConnect a décidé de créer une plate-forme de service de données d'index intégré basée sur Apache Doris pour obtenir une centralisation construction et gestion d'index, réduisant la charge de travail de développement ETL et d'autres objectifs commerciaux. Cet article présentera en détail le processus d'évolution de l'architecture à deux générations de OneConnect, partagera l'expérience de construction et la pratique d'application de la plate-forme de service de données, et vous montrera comment obtenir une réponse de requête au niveau de la milliseconde basée sur Apache Doris en multi-table scénarios d'association et de forte concurrence.

Auteur｜ Hou Lan, ingénieur en exploration de données, OneConnect

OneConnect est un fournisseur de technologie en tant que service pour les institutions financières et une entreprise nationale de haute technologie. En tant que société affiliée de China Ping An Group, OneConnect s'appuie sur les 30 années d'expérience de Ping An Group dans le secteur financier et sur ses capacités de recherche scientifique indépendantes pour fournir à ses clients des produits intégrés « d'intégration horizontale, de couverture complète verticale », notamment des services bancaires numériques, des l'assurance et la plate-forme Jiama, qui fournit une infrastructure numérique fintech, utilise "technologie + entreprise" comme sa compétitivité unique pour aider les clients à améliorer l'efficacité, à améliorer les services, à réduire les coûts, à réduire les risques et à réaliser la transformation numérique.

point sensible de l'entreprise

Dans le processus de création de solutions numériques, nous utilisons principalement des indicateurs (tels que les indicateurs de performance opérationnelle de la banque : AUM client) pour refléter intuitivement le statut commercial de l'entreprise et développer des rapports via des indicateurs pour aider le personnel de l'entreprise à effectuer des analyses de données, orientant ainsi les décisions de gestion. et l'autonomisation de la numérisation fonctionnent. Dans notre première méthode de reporting, les différents métiers des métiers utilisaient des outils d'analyse différents pour définir des indicateurs selon leur périmètre d'activité.Cette méthode traditionnelle apportera deux difficultés majeures lors de la coopération inter-métiers :

Les indicateurs et les normes ne sont pas uniformes : les rapports générés par les différents métiers s'entassent comme une montagne, du fait de l'utilisation d'outils d'analyse différents, les sources de données d'ancrage sont diverses et compliquées, ce qui pose le problème des indicateurs contradictoires.
Calcul d'index dupliqué et faible efficacité de livraison : une fois que le processus de développement doit être proposé par l'entreprise, le personnel informatique explore la source de données et la traite, puis établit un rapport et se connecte en ligne pour acceptation. Tout au long du processus, le service informatique doit communiquer plusieurs fois avec l'entreprise pour synchroniser les informations, ce qui entraîne l'élaboration de rapports ordinaires prenant deux semaines.

Afin de résoudre ces deux problématiques majeures, notre groupe a décidé de développer en interne une plateforme de service de données indexées intégrées, en mettant en place un système d'indexation répondant aux objectifs stratégiques des clients, et en standardisant le processus de développement et les modes d'utilisation à l'aide de la plateforme de service. , nous avons réalisé la construction et la gestion centralisée des indicateurs. Dans le même temps, le moteur de requête OLAP est utilisé pour faciliter le développement et l'application d'indicateurs, afin que le personnel de l'entreprise puisse trouver rapidement les données requises, réduire la charge de travail du développement ETL, raccourcir le cycle de développement des rapports et accélérer le temps d'indicateur. release et visualisation Génération Kanban.

Au cours du processus de construction de la plate-forme de service de données, OneConnect a connu deux générations d'évolution de l'architecture de l'entrepôt de données. L'architecture de première génération interroge les données d'index sur la base du pré-calcul Apache Kylin, et après l'utilisation de l'architecture, il s'avère que ses performances d'interrogation sont insuffisantes. Afin de répondre aux exigences de notre entreprise, nous avons poursuivi la recherche de sélection OLAP et avons finalement introduit Apache Doris pour la mise à niveau de l'architecture, avec l'aide des capacités d'analyse hautes performances d'Apache Doris pour accompagner une requête d'index efficace.

Cet article présentera en détail le processus d'évolution de l'architecture à deux générations de OneConnect et expliquera comment créer une plate-forme de données intégrée basée sur Apache Doris pour une construction, une requête et une gouvernance unifiées des indicateurs, et obtenir une réponse de requête au niveau de la milliseconde dans associations multi-tables et scénarios à forte concurrence.

Les premiers défis de l'architecture

Architecture 1.0 : Hadoop + Presto + Apache Kylin

Au début de l'entreprise, nous avons développé des rapports T + 1 basés sur Apache Kylin. La figure ci-dessus montre le processus de construction et de requête des indicateurs. Au cours du processus de construction des indicateurs, les développeurs effectueront un épissage SQL en fonction des indicateurs et des dimensions sélectionnés, et effectueront des calculs sur chaque dimension en appelant Apache Kylin via l'API pour terminer la construction du modèle et le chargement des données. Dans le processus de requête d'index, la stratégie combinée de requête rapide et de requête déroulante est adoptée. Si le champ de requête touche Cube, nous pouvons interroger directement dans Apache Kylin ; s'il n'y a pas de réponse, pousser jusqu'à Presto, puis interroger.

Alors que le volume d'affaires continue de croître, de plus en plus d'utilisateurs professionnels utilisent la plateforme.Dans le processus de promotion client et d'utilisation interne au sein du groupe, nous avons constaté que l'architecture était insuffisante dans les aspects suivants et ne pouvait pas répondre à nos demandes commerciales :

Analyse flexible : le précalcul Apache Kylin ne peut répondre qu'aux besoins de certains scénarios, et il n'existe aucun moyen de répondre à des besoins d'analyse plus flexibles.
Performances des requêtes : lorsque le champ de requête n'atteint pas le cube, il doit être poussé vers Presto. Cependant, les performances de requête de Presto ne peuvent être garanties, en particulier dans le scénario de la valeur du code de requête, le phénomène de délai d'expiration de la requête sera rencontré, ce qui entrave la libération des indicateurs.
Coûts d'utilisation, d'exploitation et de maintenance : l'architecture Apache Kylin nécessite l'utilisation de plusieurs ensembles de composants dans le processus de requête et de développement, ce qui entraîne des coûts de maintenance élevés.

Sur la base de l'expérience d'utilisation de l'architecture de première génération, nous avons un besoin urgent de trouver un moteur OLAP qui puisse non seulement prendre en charge les scénarios de requêtes associées à plusieurs tables d'index, mais aussi réduire les coûts et augmenter l'efficacité. Avec ces appels à l'esprit, nous avons comparé les moteurs OLAP actuellement populaires pour la sélection du système et avons effectué des comparaisons sous quatre aspects : scénarios d'association multi-tables, protocoles d'utilisation, coûts d'utilisation et scénarios et cas d'application financière.

Comparaison de sélection OLAP

Nous avons d'abord exclu TiDB, principalement parce qu'il est plus enclin à répondre aux exigences de TP, et ses performances sont relativement insuffisantes lorsqu'il s'agit de scénarios d'analyse de gros volumes de données. Deuxièmement, nous avons également exclu Clickhouse et Greenplum. En raison des mauvaises performances de Greenplum autonome, il ne convient pas à nos scénarios de requête ; bien que Clickhouse fonctionne bien dans les performances de requête à table unique, il ne prend pas en charge le protocole MySQL et la jointure multi-table ne peut pas fonctionner correctement. Par conséquent, aucun produit ne peut répondre à nos exigences en matière de données massives. Exigences de requête dans les scénarios d'association multi-tables.

Au final, sur la base des retours et recommandations d'autres filiales du groupe, nous avons trouvé qu'Apache Doris était très adapté à nos besoins, et nous avons résolument choisi Apache Doris pour la mise à niveau de l'architecture, principalement pour les raisons suivantes :

Développement facile et pratique : Apache Doris est non seulement compatible avec le protocole MySQL, mais prend également en charge la syntaxe de requête SQL standard, ce qui rend le développement facile et pratique.
Performances des requêtes d'association multi-tables dans des scénarios complexes : Apache Doris prend en charge les jointures distribuées, l'agrégation de détails, etc., et peut fournir divers mécanismes d'optimisation lors de l'exécution de jointures multi-tables pour améliorer l'efficacité des requêtes. Dans le même temps, Apache Doris prend également en charge les vues matérialisées et les fonctions d'indexation pour compléter les effets de précalcul et obtenir une réponse rapide aux requêtes lors de l'accès aux vues matérialisées.
Fonctionnement et maintenance simples, facile à étendre : le déploiement global d'Apache Doris n'a que deux rôles : FE et BE, ce qui simplifie considérablement le lien de l'architecture, fait en sorte que l'architecture n'a plus besoin de s'appuyer sur d'autres composants et permet un fonctionnement et un fonctionnement à faible coût. entretien.

Mise à niveau basée sur l'architecture Apache Doris

Architecture 2.0 : Apache Doris

Sur la base des avantages de performance d'Apache Doris, nous avons mis à niveau l'architecture en termes de migration de données et d'application. Au cours du processus de migration des données, Apache Doris a remplacé Apache Kylin et Presto dans l'architecture de première génération, unifié le stockage, le traitement et le calcul des données d'indicateur, et a utilisé le modèle Duplicate Key pour interroger les données détaillées, et a utilisé Range pour effectuer le partitionnement temporel et formuler des associations de dimension La clé est utilisée comme une clé, ce qui résout efficacement les problèmes de performances insuffisantes et de simultanéité insuffisante de la requête détaillée Presto dans l'architecture initiale. Dans le même temps, Apache Doris adopte le modèle MPP dans le moteur de requête, qui a des capacités de calcul à haute simultanéité et à faible latence, permet une exécution parallèle entre les nœuds et au sein des nœuds, et prend en charge la jointure aléatoire distribuée de plusieurs grandes tables, ce qui peut répondre à nos exigences. pour les scénarios complexes Exigences pour les requêtes associées multi-tables.

Au niveau applicatif, nous avons réécrit le moteur de requêtes compatible MySQL, lors de l'utilisation de la plateforme d'indicateurs pour les requêtes, il n'est plus nécessaire d'utiliser l'interface d'appel Apache Kylin en Architecture 1.0, cliquez sur l'indicateur de réexécution depuis la page, et une série de tâches fastidieuses Basé sur Apache Doris, le personnel peut utiliser directement la syntaxe MySQL pour interroger, ce qui simplifie grandement le processus de publication des indicateurs.

Apache Kylin contre Apache Doris

Nous avons sélectionné le scénario d'association multi-tables commun de la plate-forme d'indicateurs pour comparer les performances d'Apache Kylin et d'Apache Doris, et avons constaté qu'Apache Doris obtenait de meilleurs résultats en termes de performances de requête et d'efficacité de développement d'indicateurs. Comme le montre la figure ci-dessus, lorsqu'Apache Doris associe des centaines de milliers d'ensembles de données, la réponse à la requête atteint essentiellement le niveau de la milliseconde. Dans le même temps, nous n'avons plus besoin d'attendre qu'Apache Kylin termine la construction du segment pour utiliser les indicateurs.La publication des indicateurs prend en moyenne 30 minutes pour être utilisée immédiatement, ce qui améliore considérablement l'efficacité du développement des indicateurs.

L'introduction d'Apache Doris permet également d'économiser considérablement l'espace de stockage des index, ce qui répond à la demande de réduction des coûts du groupe. Ainsi, d'autres métiers du groupe (assurance de biens, assurance vie) ont également commencé à utiliser Apache Doris. La mise à niveau de la nouvelle architecture a permis d'obtenir une amélioration très efficace en termes de matériel, de main-d'œuvre et de temps, et est devenue un support solide pour la construction d'une plate-forme intégrée d'indicateurs numériques.

Plateforme de données d'indicateurs intégrée

Une fois la mise à niveau de l'architecture terminée, nous pouvons créer un système d'indicateurs unifié, créer des fonctions de plate-forme via le contenu des indicateurs, la technologie BI et AI, et construire conjointement une plate-forme de données d'indicateurs intégrée.

Construire un système d'indicateurs

À l'aide de l'analyse des relations d'attribution, OneConnect aide les institutions à créer des indicateurs de haut en bas, à trier les KPI de base et à démanteler les indicateurs couche par couche, garantissant ainsi l'intégrité et la mise en œuvre du système d'indicateurs. Selon la manière dont les indicateurs sont générés, les types d'indicateurs sont subdivisés.En prenant l'exemple du scénario marketing bancaire, les indicateurs de mesure (AUM) de la valeur totale des actifs de la clientèle dans la gestion d'actifs bancaires peuvent être subdivisés en trois types :

Indicateur atomique : l'indicateur le plus granulaire connecté à la plate-forme d'indicateurs via la source de données, généralement un champ de table, tel que le solde AUM.
Indicateurs dérivés : pour une analyse plus approfondie des indicateurs, la plate-forme dérive automatiquement une série d'indicateurs, tels que l'AUM d'une année sur l'autre, l'augmentation nette d'un mois sur l'autre, etc.
Indicateurs dérivés : afin de répondre à des scénarios d'analyse d'indicateurs complexes, basés sur des indicateurs atomiques, des conditions de filtrage sont ajoutées ou combinées avec d'autres indicateurs pour le calcul, aidant les utilisateurs à configurer eux-mêmes le kanban et à enregistrer le processus de récupération des données. Par exemple, si un utilisateur souhaite générer le solde AUM par client pour analyse, la plateforme peut générer cet indicateur à l'aide de l'indicateur atomique Solde AUM et du nombre total de clients.

Créer des fonctions de plate-forme d'indicateurs

La réalisation de la fonction de la plate-forme d'indicateurs dépend principalement de la prise en charge de l'architecture d'entrepôt de données Apache Doris, et le processus global d'indicateurs en ligne est complété sur la base du développement et de la coopération commerciale. Les développeurs effectuent d'abord la gestion des métadonnées et la saisie d'index sur la plate-forme, y compris l'enregistrement de la table inférieure du rapport de traitement, la configuration de la granularité des données et la fréquence de mise à jour de la table intermédiaire, puis la corrélation des tables et la saisie du nom de l'index et des informations sur le calibre de l'index. Après avoir saisi les informations de base des indicateurs, le personnel de l'entreprise est responsable de la sélection des dimensions requises pour l'analyse des indicateurs et de la publication des indicateurs.

Sur la base des deux étapes ci-dessus, nous pouvons analyser plus en détail les données des indicateurs dans la plateforme. Comme indiqué sur le côté gauche de la figure ci-dessus, la plate-forme d'indicateurs fournit diverses vues d'analyse en colonnes, et le personnel de l'entreprise peut visualiser visuellement le tableau de classement des indicateurs et analyser le classement AUM de chaque succursale bancaire. Dans le même temps, nous avons intégré des algorithmes intelligents d'IA pour détecter les indicateurs anormaux à l'aide de modèles de séries chronologiques, assisté l'inspection des KPI grâce à des algorithmes d'analyse des causes profondes et analysé les raisons des changements d'indicateurs. Pour les indicateurs de stock, la plate-forme fournit un système de notation de la valeur, qui peut mettre en place des indicateurs hors ligne en temps opportun avec une faible valeur, afin d'atteindre l'objectif de gouvernance lors de l'utilisation.

Pratique d'application basée sur l'index Apache Doris

La construction d'une plate-forme de données intégrée a complètement résolu les problèmes de calibre d'index incohérent et de double comptage des indicateurs dans l'élaboration des rapports traditionnels par OneConnect. En termes d'efficacité d'analyse, nous espérons atteindre l'objectif d'un temps de réponse de l'interface de 600 millisecondes et d'une réponse à la requête dans les 100 millisecondes dans des scénarios complexes d'association multi-tables. Par conséquent, nous avons testé et réglé Apache Doris, et partagé la pratique d'application d'Apache Doris dans ce scénario sous trois aspects : préparation des données, déploiement du cluster et réglage du modèle.

Dans le processus préliminaire de préparation des données, étant donné que notre ensemble de données est très similaire à l'ensemble de données SSB testé sur le site officiel, nous avons choisi la configuration de l'environnement de développement et de test recommandée par le site officiel et sélectionné la version Apache Doris 1.1 pour les tests. Parce que nous générons directement des fichiers CSV via des données Python Mock, nous utilisons Stream Load pour les dérivés par lots. Les fichiers CSV importés à chaque fois sont dans la taille de fichier 1-10G recommandée par Stream Load, et le taux de compression des données final atteint 3:1 , mais la vitesse d'importation du nœud unique dépasse 40 Mo/s.

Pendant le processus de déploiement du cluster, afin de surveiller les performances de l'indicateur et le serveur (CPU, IO, disque et mémoire), nous utilisons Prometheus pour importer le modèle de surveillance Apache Doris afin de surveiller le déploiement du cluster. Prometheus reçoit les éléments de surveillance de l'exposition Apache Doris , puis les visualise avec Grafana présenté.

Une fois le travail préparatoire terminé, vous pouvez lancer la requête associée à la grande table.Nous avons choisi le SQL chronophage pour interroger le graphique de tendance des indicateurs. Sur la base de l'objectif de requête au niveau de la milliseconde, nous avons implémenté deux solutions d'optimisation. La première solution consiste à utiliser Colocation Join pour agréger les données à l'avance lors de la création de tables. La deuxième solution consiste à collecter le SQL haute fréquence à l'aide d'Audit Loader, à optimiser à rebours la construction de la table de l'entrepôt de données et à réécrire le SQL, et à utiliser la conception de la table large pour remplacer l'ancien modèle étoile/flocon de neige. Grâce au test et à l'évaluation des deux schémas, nous avons constaté que le second schéma peut apporter des avantages plus significatifs en termes de réponse aux requêtes et d'économie de ressources de service.

Des centaines de millions de requêtes d'association multi-tables de données, pour obtenir une réponse de requête au niveau de la milliseconde

Nous avons fait des statistiques sur le temps d'exécution des requêtes SQL.Comme le montre la figure ci-dessus, lors de l'adoption de la solution 1 Colocation Join, le temps de réponse de la requête est passé de 5 secondes à 1 seconde. Bien que l'efficacité des requêtes ait été améliorée, nous espérons raccourcir encore le temps de réponse et atteindre l'objectif escompté. Après avoir ajusté le modèle de données à l'aide de la deuxième option, le temps d'exécution SQL est passé des 5 secondes d'origine à 63 millisecondes, et le temps de réponse à la requête a été considérablement amélioré, atteignant notre objectif de réponse à la requête en millisecondes.

Dans le même temps, nous avons utilisé Grafana pour vérifier les performances de requête d'Apache Doris et avons constaté que le schéma de construction de table large peut réduire le temps de requête de plus de dix secondes à moins de 100 millisecondes, et le serveur ne tremble plus.

Activer le cache SQL pour économiser les ressources du serveur

Après avoir adopté le schéma de construction de table large, afin d'améliorer encore les performances des requêtes, nous avons également activé le cache SQL pour aider le scénario de rapport T+1 à obtenir des performances de requête efficaces :

Une fois la mise en cache activée, fondamentalement, toutes les durées de requête sont à un seul chiffre et permettent finalement d'obtenir le résultat qu'un seul utilisateur accède à la page en 4 secondes ;
Lorsque 30 indicateurs sont exécutés en même temps (plus de 120 instructions SQL), l'interface peut atteindre le retour en 600 ms ;
Dans le scénario simultané, le TPS optimal atteint 300 et le processeur, la mémoire, le disque et les E/S atteignent moins de 80 % ;
Après évaluation, nous avons constaté que sous l'échelle de cluster de test recommandée par le site officiel, Apache Doris peut mettre en cache des dizaines de milliers d'indicateurs, ce qui économise considérablement les ressources.

plan d'avenir

Actuellement, OneConnect a mis en place une plate-forme de données intégrée basée sur Apache Doris pour la construction, l'interrogation et la gouvernance unifiées des indicateurs, fournissant aux banques des services tels que l'analyse et l'affichage complets des indicateurs et la gestion intelligente du cycle de vie des indicateurs. Dans le cadre de la construction d'une telle plate-forme, la scène bancaire au sein du groupe a obtenu des résultats très remarquables. Jusqu'à présent, des dizaines de milliers d'indicateurs actifs et des milliers de dimensions d'analyse ont été accumulés, et des dizaines de milliers de Kanbans ont été traités et formés. , réduisant la charge de travail du développement ETL de 30 %. . À l'avenir, l'entreprise continuera d'explorer et d'optimiser sur la base d'Apache Doris, et nous nous concentrerons sur les aspects suivants :

Analyse en temps réel de la plateforme : Basé sur Apache Doris, le lac et l'entrepôt sont intégrés, et combinés avec Flink CDC et Apache Iceberg pour construire conjointement une analyse en temps réel unifiée.
Vue matérialisée de la plate-forme : dans l'attente des points forts de la nouvelle version, explorez l'optimisation des requêtes sous l'association multi-tables, comme la création d'une vue matérialisée multi-tables.
Migration d'autres produits : migrez d'autres produits du middle office vers Apache Doris. À l'heure actuelle, la plate-forme d'étiquetage basée sur Elasticsearch rencontre certains problèmes d'utilisation et nous prévoyons de migrer la plate-forme vers Apache Doris à l'avenir.

Un merci spécial à l'équipe technique de SelectDB et à la communauté Apache Doris pour leur réponse rapide à tous les problèmes rencontrés lors de l'utilisation, ce qui nous a permis de réduire de nombreux coûts d'essais et d'erreurs. À l'avenir, nous participerons également activement aux contributions et aux activités de la communauté, et progresserons et grandirons avec la communauté !

La pratique d'application d'Apache Doris dans la plate-forme de Financial OneConnect Index