Résumé : Cet article est compilé à partir de Zhou Yueyue, architecte d'OceanBase, partageant la session d'entrepôt de lac en temps réel de Flink Forward Asia 2022. Le contenu de cet article est principalement divisé en quatre parties :
Interprétation des technologies clés de la base de données distribuée OceanBase
Amarrage écologique et scénarios d'application typiques
Pratique d'OceanBase X Flink dans l'industrie du jeu
perspectives d'avenir
Cliquez pour voir la vidéo originale et le discours PPT
1. Interprétation des technologies clés de la base de données distribuée OceanBase
En tant que base de données distribuée nationale purement auto-développée après 12 ans, de l'approbation du projet de produit au lancement de l'activité de transaction principale, OceanBase s'est fermement déplacé vers une architecture distribuée de l'ère 1.0, et le produit a commencé à être implémenté dans Alipay et à soutenir le cœur de métier. .
Avec l'amélioration des capacités du produit, l'ère OceanBase 2.0 est passée d'un système de stockage KV à une base de données distribuée native avec des transactions distribuées et une forte cohérence de plusieurs copies, et a commencé à servir des clients d'entreprise externes, y compris Internet, la finance, les valeurs mobilières et d'autres industries.
À l'ère 3.0, avec l'amélioration des capacités HTAP, les moteurs hybrides et les solutions de déploiement hybrides attirent davantage d'entreprises clientes étrangères. Avec la sortie de la version 4.0, OceanBase propose une architecture intégrée distribuée autonome pour aider les entreprises à miniaturiser et fournir des services de cloud public.
L'architecture intégrée d'OceanBase peut se résumer en trois mots clés : protocole Paxos, architecture sans partage et haute disponibilité au niveau des partitions.
Par défaut, les données sont stockées en plusieurs copies, c'est le concept de plusieurs copies. Une forte cohérence des données est garantie entre les répliques via le protocole Paxos. Grâce au protocole multi-copie + Paxos, la haute disponibilité du système de base de données est garantie.
Chaque nœud OBServer du système possède à la fois des capacités de calcul et de stockage. Il n'y a pas de goulot d'étranglement à point unique dans l'ensemble du système, et plusieurs points peuvent être lus et écrits. Lorsque le cluster se développe et se réduit, les données sont migrées en utilisant des partitions comme unité de base pour réaliser automatiquement l'équilibrage de charge.
En tant que système qui porte la pierre angulaire d'une entreprise, la haute disponibilité de la base de données est cruciale pour l'entreprise. La solution de déploiement typique en trois copies d'OceanBase basée sur le protocole Paxos garantit que les données ne seront pas perdues et que les services ne seront pas interrompus lorsqu'une seule machine, salle informatique ou ville tombe en panne.
La réduction des coûts et l'augmentation de l'efficacité sont un sujet éternel pour les entreprises, alors comment réduire les coûts du matériel par des moyens techniques est une préoccupation de chaque entreprise. Lorsque des données sont écrites sur OceanBase, elles sont d'abord écrites dans la mémoire, et lorsque les conditions sont remplies ou que le seuil défini est déclenché, les données sont actualisées sur le disque.
Par conséquent, la quantité totale de données dans OceanBase se compose de données de base de disque et de données incrémentielles de mémoire, de sorte qu'OceanBase est parfois appelée une base de données quasi-mémoire. En termes de compression des données, la structure de données arborescente LSM utilisée par OceanBase a un algorithme de compression correspondant à chaque couche.Ce type de compression est appelé compression générale.
Sur la base de la compression générale, OceanBase a auto-développé un ensemble de méthodes de compression (encodage) pour l'encodage mixte des lignes et des colonnes de la base de données, qui compressera davantage les données. L'espace de stockage est encore réduit sur la base de la compression générale. Dans les mêmes conditions, par rapport à Oracle, le coût de stockage d'OceanBase n'est que d'environ 1/3 du premier.
Dans les solutions de base de données traditionnelles, telles que la base de données MySQl la plus couramment utilisée, plusieurs entreprises sont généralement divisées en plusieurs bases de données. Isoler physiquement. Évitez les exceptions métier uniques affectant l'ensemble du système métier. Avec la croissance rapide des activités, le personnel d'exploitation et de maintenance doit exploiter, entretenir et gérer plusieurs ensembles d'environnements, et le coût est élevé.
Dans OceanBase, en cas de ressources suffisantes, il suffit de créer de nouveaux locataires pour accéder à de nouveaux services et d'obtenir l'isolation des ressources et l'indépendance des données entre les services. Le schéma d'isolation des ressources entre les locataires garantit qu'un environnement peut transporter plusieurs ensembles de services, et la charge de travail du personnel d'exploitation et de maintenance est considérablement réduite.
HTAP est un sujet qui a été constamment mentionné ces dernières années, alors HTAP est-il une fausse proposition ? En fait, HTAP n'apparaît pas de nulle part, la réalité est que les utilisateurs ont des besoins commerciaux réels et des scénarios réels.
Dans la solution précédente, les données générées par l'activité TP étaient synchronisées avec certains produits analytiques via des outils permettant d'effectuer des tâches telles que l'analyse des données et l'exécution par lots. Cela implique le raccordement de plusieurs systèmes, ainsi que le transfert et le stockage de plusieurs copies de données.
A l'heure actuelle, le HTAP sur lequel tout le monde s'accorde est aussi le HTAP que pense l'OB : c'est-à-dire tout en faisant du bon travail en TP, en prenant en compte et en améliorant la capacité d'analyse. Dans ce concept, il y a deux points essentiels, à savoir une donnée et un ensemble de systèmes. Les données peuvent être traitées dans un seul système, et il n'est pas nécessaire de les synchroniser et de les transférer à nouveau.
En plus d'un ensemble de moteurs SQL pour répondre aux besoins de TP et AP, OceanBase peut également mettre en œuvre de manière flexible diverses stratégies de séparation lecture-écriture via plusieurs types de copie et une faible cohérence en fonction des exigences de séparation lecture-écriture de l'utilisateur, garantissant que l'entreprise d'origine ne sera pas modifié. Le coût est de 0, ce qui peut répondre aux besoins des utilisateurs.
En tant que base de données distribuée, l'évolutivité est la capacité la plus importante. Dans l'architecture intégrée d'OceanBase, les nœuds du cluster sont égaux, chaque nœud a des capacités de calcul et de stockage, et peut être étendu et réduit en ligne en même temps. Chaque nœud peut lire et écrire. En théorie, les performances du cluster augmentent linéairement avec l'expansion des nœuds.
Il n'y a pas si longtemps, OceanBase a publié la version 4.0, introduisant une architecture intégrée distribuée autonome. L'architecture distribuée est plus utilisée dans les scénarios commerciaux avec un volume et une échelle de données importants, et dans ces scénarios, les avantages distribués peuvent être mieux utilisés.
Pour les utilisateurs d'entreprise dont le volume de données d'entreprise n'est pas assez important ou dont le volume de données actuel n'est pas important, la solution distribuée nécessite trop de ressources, elle n'est donc pas adaptée aux scénarios de volume d'entreprise de petite et moyenne taille. Dans le même temps, une architecture autonome ou légère est plus adaptée à ce type d'entreprise. La solution d'architecture intégrée autonome, tout en utilisant une machine autonome, peut transformer la machine autonome en une architecture distribuée à mesure que l'échelle des données augmente à l'avenir, répondant pleinement aux besoins de développement de l'entreprise.
2. Amarrage écologique et scénarios d'application typiques
En tant que produit représentatif dans le domaine de l'analyse en temps réel, Flink est utilisé par de nombreux utilisateurs de la communauté OceanBasse et utilisé dans des scénarios commerciaux d'entrepôt de données en temps réel. Selon les besoins des utilisateurs de la communauté, nous avons amarré et adapté Flink et ses outils écologiques environnants, tels que ChunJun.
Les utilisateurs utilisent Flink et les outils écologiques correspondants pour permettre aux données de circuler librement dans différents systèmes. Par exemple, les données MySQL ou OceanBase source en amont sont synchronisées avec les destinations OceanBase, Kafka et autres en aval.
Dans la communauté OceanBase, de nombreux utilisateurs utilisent OceanBase+Flink pour résoudre des problèmes pratiques rencontrés en production. Les scénarios d'application typiques incluent :
Scénario 1, écriture de données en temps réel et nettoyage des données, qui est également le scénario le plus utilisé. Lorsque les données sont écrites en flux vers l'aval, il est non seulement nécessaire d'assurer les performances en temps réel de l'écriture, mais il peut également y avoir des problèmes tels que le nettoyage et la conversion du format de données.Par conséquent, Flink peut réaliser l'écriture en temps réel des données vers des bases de données en aval telles que OceanBase, etc., et en même temps des actions telles que le nettoyage des données peuvent être effectuées pendant le processus d'écriture.
Scénario 2 : Élargir le flux de données. La jointure et l'association de plusieurs tables avec une table de dimension et une table de faits sont les scénarios les plus courants. Dans la figure ci-dessus, la source de données métier génère en continu un flux de données et effectue des opérations de jointure avec les tables de dimension dans OceanBase pour élargir le flux de données et générer une grande table large. Enfin, les données sont écrites dans un ensemble de résultats et stockées dans un système de base de données, tel qu'OceanBase.
Scénario 3 : Construire une vue matérialisée. Lorsque des données commerciales sont écrites en continu dans OceanBase, les données de la table changent constamment. À ce stade, lors de l'exécution de certaines opérations de requête, telles qu'une requête d'agrégation, un seul élément de données nouvellement ajouté déclenchera le calcul de la requête. Lorsque l'échelle de données impliquée dans la requête est importante et que les données sont fréquemment mises à jour, les performances de la requête seront insatisfaisantes.
Après avoir utilisé Flink, le flux de données est converti en un tableau dynamique et agrégé en continu. Stockez le jeu de résultats généré en aval, comme OceanBase, etc. Les utilisateurs n'ont qu'à interroger le jeu de résultats pour obtenir les données requises, sans effectuer d'opérations d'agrégation à chaque fois, et l'amélioration des performances est très évidente.
Scénario 4 : traitement secondaire des données. Avec la popularité des solutions distribuées, les entreprises utilisent l'évolutivité des bases de données distribuées pour stocker des données brutes dans des scénarios de Big Data dans des bases de données, telles que diverses données d'indicateurs.
Lorsqu'il est nécessaire de retraiter les indicateurs des données d'origine, à l'aide de la capacité de synchronisation en temps réel de Flink, les données de l'indicateur sont retraitées pendant le processus de synchronisation et les données traitées sont réécrites dans OceanBase pour une utilisation professionnelle. Dans le même temps, les données traitées peuvent être à nouveau traitées comme source, ce qui est très flexible à utiliser.
3. Pratique d'OceanBase X Flink dans l'industrie du jeu
Alors que les entreprises accordent de plus en plus d'attention à la valeur des données, la fraîcheur des données est cruciale et les entreprises doivent être en mesure d'observer les changements dans les données en temps réel. Par exemple, dans la livraison de la livraison express, les entreprises doivent saisir l'état de fonctionnement de la livraison express dans l'ensemble du processus, de la commande de l'utilisateur à la réception de l'utilisateur en temps réel, découvrir en temps opportun les problèmes possibles dans chaque lien et les résoudre rapidement, afin que pour améliorer l'efficacité opérationnelle et l'expérience utilisateur.
Pendant les heures de grande écoute, les décideurs des entreprises doivent toujours prêter attention à la situation des positions publicitaires populaires, ajuster le placement publicitaire en temps opportun et maximiser la valeur des positions publicitaires.
Dans le domaine des entrepôts de données en temps réel Big Data, les entrepôts de données fournissent des stratégies basées sur les données pour le processus décisionnel des entreprises. L'architecture Lambda est une solution d'entrepôt de données antérieure qui utilise deux architectures, le traitement par flux et le traitement par lots, pour les données. traitement. L'architecture de l'entrepôt de données d'une société de jeux est illustrée dans la figure : le traitement hors ligne est confié à Hive et l'analyse en temps réel est effectuée par Click House.
Hive est un outil d'entrepôt de données basé sur Hadoop qui peut effectuer une organisation des données, des requêtes spéciales et un traitement d'analyse sur des ensembles de données stockés dans HDFS. Spark est un système informatique en cluster open source basé sur l'analyse et le calcul en mémoire. Le but est d'accélérer l'analyse des données. Hive + Spark se complètent. Et Spark + Click House est écrit dans Click House via Spark micro-batch, pour jouer la capacité d'analyse de Click House.
Il existe trois scénarios typiques dans l'industrie du jeu :
-
Scénario 1 : Interroger l'ID utilisateur via le numéro d'ID. Lorsqu'un utilisateur s'inscrit, le système doit utiliser les informations du numéro d'identification pour accéder à chaque plate-forme afin de vérifier s'il existe déjà des informations d'enregistrement ou plusieurs ID. S'il existe déjà des informations d'enregistrement, l'utilisateur est invité à se connecter.
-
Scénario 2 : Vérifiez le canal publicitaire via l'ID utilisateur. Une fois l'utilisateur enregistré, le fournisseur de canal tiers doit être rappelé pour savoir si l'attribution est correcte, par exemple si l'utilisateur enregistré à partir de ce canal a été piraté.
-
Scénario 3 : Visualisez les effets publicitaires en temps réel. Lorsque l'ancre du jeu fait la promotion du jeu, il a besoin de voir les données des clics, téléchargements, installations, inscriptions, création de personnages, chaînes et autres informations d'indicateur du jeu en temps réel. Correspondant au niveau métier, il s'agit des opérations associées de 7 tables.
Dans les scénarios 1 et 2, l'analyse à l'aide de Click House prend 66 secondes ; dans le scénario 3, il faut plus de 20 minutes pour terminer la requête dans la solution Hive.
Combinant les caractéristiques du test métier et de l'architecture, les enjeux actuels portent principalement sur les quatre aspects suivants :
- Les performances en temps réel ne suffisent pas. Sous l'architecture Hive, il faut 30 minutes pour que les données soient importées et visibles, tandis que ClickHouse prend également une minute.
- Cohérence insuffisante. Je crois que quiconque a utilisé l'architecture Lambda sait que les données de ClickHouse et de Hive "se battent" souvent et que les données calculées par les deux sont incohérentes. Il est nécessaire de dédupliquer le calcul, mais même après un traitement répété, il existe toujours des incohérences dans les données. Par conséquent, les données ClickHouse ne peuvent être utilisées que pour la visualisation des données en temps réel, et les données Hive seront utilisées pour l'utilisation finale des données.
- La maintenabilité est complexe. En utilisation professionnelle, deux ensembles de codes doivent être développés pour s'interfacer avec les architectures Hive et ClickHouse.
- Les performances des requêtes ne sont pas idéales. Parmi les trois scénarios présentés ci-dessus, cela prend des secondes voire des minutes dans ClickHouse pour les scénarios 1 et 2, et cela prend plus de dix minutes pour le scénario 3.
Après l'introduction de la solution OceanBase+Flink, les données sont écrites sur OB en temps réel via Flink, et le nettoyage des données est effectué en même temps pour normaliser le format des données. Dans le scénario 1 et le scénario 2, les résultats peuvent être renvoyés en millisecondes. Dans la scène 3, l'effet publicitaire peut être vu en 1,5 seconde et l'amélioration des performances est très évidente.
Les avantages de la nouvelle solution sont également très évidents : par rapport à l'architecture précédente, les performances vont de la minute à la seconde voire la milliseconde, avec moins de composants et une architecture plus légère. Un ensemble de solutions peut répondre aux besoins en temps réel de certaines entreprises, avec de faibles coûts de maintenance et de faibles coûts de transformation d'entreprise.
4. Perspectives d'avenir
Dans la mise en œuvre réelle des solutions OceanBase et Flink, nous avons constaté que certaines optimisations peuvent être apportées à Flink, principalement dans les trois aspects suivants :
- En termes de performances. Actuellement, Flink est un instantané de données de lecture à un seul thread. À l'avenir, les instantanés seront découpés en plusieurs tranches de données et lus simultanément pour améliorer les performances.
- En termes de cohérence. Dans la conception d'origine, afin de s'assurer que les données ne sont pas perdues, les lectures incrémentielles sont démarrées en premier, puis les lectures d'instantané sont lancées. Lors des opérations ETL, il peut y avoir des problèmes de redondance des données. Dans la nouvelle conception, la lecture de données instantanées + incrémentielles peut être optimisée pour obtenir une lecture cohérente.
- En termes de compatibilité. Actuellement, Flink est compatible avec la version 5.1 du connecteur OceanBase. Comme OceanBase est compatible avec mysql 8.0, Flink devra également s'adapter au connecteur 8.0 à l'avenir.
Comme OceanBase+Flink est largement utilisé dans l'environnement de production, nous continuerons à adapter et à améliorer la solution avec Flink et les outils écologiques environnants à l'avenir pour mieux servir les utilisateurs en entreprise.