Documents d'apprentissage : Pratique Doris | Lalamove big data Pratique Doris d'assurance de la stabilité
notes d'étude
La collecte de données est divisée en collecte en temps réel et collecte hors ligne :
- Collecte en temps réel : les données d'achat des utilisateurs sont transmises au lien en temps réel pour le calcul.
- Collecte hors ligne : les données des commandes commerciales sont collectées dans de grands compartiments de base de données par heure et par jour pour être utilisées.
Cas de problèmes et de solutions :
- Requête PTZ Doris signale des erreurs intermittentes
- Emplacement de la cause : l'utilisateur a soumis un grand nombre de requêtes, y compris des requêtes volumineuses, ce qui a saturé le pool de threads de traitement RPC du fragment.
- Solution : Augmenter la capacité du cache et augmenter le taux de réussite du cache ; réduire le temps de requête et augmenter les capacités d'interception des requêtes volumineuses
- Dans un scénario quasi-temps réel, l'exécution de plusieurs tâches dans une tâche planifiée de 5 minutes expire.
- Localisation de la cause : la partie commerciale a soumis d'autres tâches qui étaient sérieusement en panne, ce qui a ralenti le débit d'écriture global du cluster, affectant le scénario quasi-temps réel.
- Solution : les tâches et les paramètres d'importation de Doris ont été optimisés, le processus de contrôle et d'approbation des spécifications de modification de Doris a été renforcé et l'isolation multi-locataires de l'entreprise est en cours de mise en œuvre.
L’objectif de l’assurance de la stabilité
- Moins d'accidents : planification des capacités, capacités d'automatisation, capacités d'interception des requêtes, isolation de l'entreprise et contrôle des droits des utilisateurs
- Découverte rapide : capacité de découverte
- Récupération rapide : capacité de récupération rapide après les pannes
capacité de découverte
- Surveillance au niveau de la table, surveillant principalement la capacité et l'état de la table
- Surveillance des tâches, surveillance de l'état des tâches dérivées
- Surveillance des composants, surveillance des métriques de service (telles que requêtes, dérivés), métriques de processus et de machine
planification des capacités
Tri de capacité :
- La scène actuelle est-elle en temps réel ou hors ligne ?
- Vitesse d'écriture des données, état de la partition
- Exigences de requête et de stockage
Surveillance de la capacité : CPU, mémoire, disque, doris_be_add_batch_task_queue_size, doris_fe_query_latency_ms, doris_be_plan_fragment_count
La haute disponibilité
Haute disponibilité du service : s'appuie principalement sur les propres capacités de Doris, en introduisant des backends d'équilibrage de charge et de liaison pour atteindre un équilibre dans le nombre de connexions et une disponibilité élevée en lecture et en écriture.
Liaison haute disponibilité : prend en charge les tentatives anormales et les alarmes téléphoniques, et les données prennent en charge les opérations idempotentes
Autres capacités de support
- Capacités d'interception métier : définissez des capacités d'interception au niveau de l'utilisateur, définissez des règles d'interception basées sur l'ordre de grandeur réel et l'échelle des requêtes ; capacité à éliminer rapidement les requêtes anormales.
- Capacité de récupération rapide des pannes : capacité de récupération rapide des données de partition, capacité de récupération de l'état de la tablette
- Isolation de l'entreprise : l'isolation des clusters et la mutualisation sont effectuées en fonction de l'importance de l'entreprise et du type de données en temps réel ou hors ligne.
- Contrôle des autorisations des utilisateurs : le propre RBAC de Doris
Règles d'utilisation de Doris
- Créer un tableau
- La valeur recommandée pour le nombre de compartiments est de 16 ou 32, et une seule tablette équivaut à environ 1 G : contre-exemple, si les compartiments sont trop petits, ce qui rend une seule tablette trop grande, l'exécution compacte sera lente et le cluster le débit sera faible)
- Modèle de table (utilisez de préférence Aggregate/Duplicate) ; index de préfixe (défini en fonction des conditions de requête) ; champ de partition (définissez un cycle de vie raisonnable)
- Il est recommandé de placer les tables fréquemment écrites dans une base de données distincte pour éviter un nombre excessif de transactions affectant d'autres tables de la même base de données.
- Flink écrit
- N'utilisez jamais votre propre fichier jar, utilisez flinksql : contre-exemple, utilisez votre propre fichier jar, une donnée est écrite dans la transaction, ce qui ralentit le débit du cluster.
- Les données ne sont pas en désordre (garanti qu'il n'y a que des données dans une seule partition) : contre-exemple, il y a beaucoup de désordre dans les données, et chaque tâche d'écriture implique des dizaines de partitions, ce qui ralentit le débit du cluster. vers le bas
- Il est recommandé que la quantité de données à envoyer dans un seul lot soit Taille du lot >= 100 Mo ou délai d'attente = 2 à 5 minutes, concurrence d'instance d'importation par lots de table unique <= 2
- insérer écrire
- Une fois l'insertion réussie, vous devez toujours attendre que la version soit publiée avant que les données soient visibles.
- supprimer
- Évitez les suppressions fréquentes, qui entraîneraient une pression de compactage élevée et affecteraient les performances d’écriture et de requête.
- suppression de l'exécution, la visibilité des données est asynchrone
- Il n'est pas nécessaire d'ajouter de la force après l'instruction drop, afin qu'une suppression accidentelle puisse être rappelée dans un certain laps de temps.
- Réviser
- Une seule modification peut être exécutée sur une table à la fois : contre-exemple, une exécution pour modifier le type de colonne traversera les données, ce qui prend beaucoup de temps. Si elle est exécutée à nouveau pendant cette période, une erreur sera signalée.
- Prend en charge l'ajout, la suppression et la modification de colonnes, mais ne prend pas en charge la modification des noms de colonnes.
- Arrêtez d'écrire des tâches avant d'ajouter/supprimer des données et attendez 5 minutes avant de les exécuter pour éviter toute incohérence des données.
- Renseigner
- Interrogez strictement l'intégralité des données sans conditions de filtrage, et il est recommandé d'ajouter une limite pour couvrir l'ensemble de la situation.
- Doris ne convient pas aux scénarios QPS à haute concurrence
- Doris est compatible avec le protocole MySQL et traceId peut être utilisé dans les requêtes métier pour faciliter le dépannage.