Alors que le dividende du trafic s'estompe progressivement, de plus en plus de sociétés de publicité et de praticiens ont commencé à explorer de nouvelles voies de marketing raffiné, remplaçant les précédents bombardements publicitaires à fort trafic et à grande échelle. Un marketing raffiné signifie sélectionner le public cible le plus potentiel parmi des centaines de millions de personnes, ce qui pose sans aucun doute un défi technique majeur pour les capacités de l'entrepôt de données qui fournissent le support de base du moteur.
Cet article se concentrera sur la technologie du moteur OLAP et l'expérience de mise en œuvre de ByteDance. En prenant la scène interne de ByteDance comme exemple, il démontera spécifiquement la logique de mise en œuvre et les effets commerciaux de l'activité publicitaire.
Scénarios publicitaires précis
Le processus de publicité comprend généralement des processus clés tels que la collecte de données -> l'intégration des données -> la sélection du groupe -> la diffusion de la publicité -> l'analyse des commentaires. La sélection du groupe est une étape clé pour une publicité précise. Elle aide à déterminer le public cible de la publicité et aide la plate-forme de diffusion selon Optimiser les stratégies de diffusion pour différents publics et objectifs publicitaires afin d'augmenter les revenus publicitaires ;
Estimation de la foule
L'estimation de la foule est principalement basée sur certaines conditions de sélection de cercles pour confirmer le nombre d'utilisateurs touchés. Dans le processus de diffusion précise de la publicité, les annonceurs doivent connaître le nombre approximatif de personnes dans le groupe de personnes actuellement sélectionné, ce qui est utilisé pour aider à évaluer la situation de diffusion, puis à déterminer le budget de diffusion. Habituellement, le temps de calcul ne doit pas dépasser 5 secondes.
Publicité
Problèmes et points douloureux rencontrés dans le processus de diffusion précise d’une publicité :
1. Estimation des données : les annonceurs doivent estimer le groupe de personnes sélectionné afin de juger de la situation de livraison et de déterminer le budget de livraison. Cependant, le package crowd contient une grande quantité de données et une large base. Le nombre d'utilisateurs sur la plate-forme est de plusieurs centaines de millions, et le DAU de Douyin à lui seul compte des centaines de millions. Les foules correspondant à Douyin et Toutiao se chiffrent en milliards. La première version estimée utilise ElasticSearch, mais parce que les données sont trop volumineuses , seul un stockage d'échantillonnage de 1/10 peut être utilisé, ce qui entraîne une erreur de 10 %, l'entreprise est inacceptable.
2. Performances des requêtes : les annonceurs peuvent définir une condition de sélection de cercle très complexe, entraînant des calculs complexes (un seul calcul peut contenir des centaines, voire des milliers de packages de foule), et les programmes Hive et ES peuvent réduire la vitesse des requêtes lors du traitement de grandes quantités de données. . Cela deviendra très lent. Si vous devez interroger tous les utilisateurs d'un annonceur, vous devez analyser l'ensemble de la base d'utilisateurs, et ce processus peut prendre plusieurs minutes, voire plusieurs heures, ce qui ne peut pas répondre aux exigences en temps réel.
3. Grand espace de stockage : les solutions telles que Hive et ES nécessitent des structures d'index supplémentaires, ce qui entraîne un espace de stockage plus grand et des coûts de stockage plus élevés. Par exemple, si les attributs utilisateur doivent être indexés, un espace de stockage supplémentaire est requis pour stocker les données d'indexation.
4. Ne prend pas en charge une concurrence élevée : les solutions telles que Hive et ES sont sujettes à des problèmes de performances lors du traitement des demandes à haute concurrence et ne peuvent pas prendre en charge une diffusion efficace des publicités. Par exemple, si plusieurs annonceurs doivent interroger des informations sur les utilisateurs en même temps, des problèmes tels qu'un blocage des requêtes ou un délai de réponse peuvent survenir.
5. Efficacité des requêtes de données : ClickHouse est utilisé pour prendre en charge l'estimation, mais avec la croissance du volume de données, il est difficile pour ClickHouse de garantir le temps de requête avec la prise en charge du moteur de stockage actuel. Cela conduit au problème de l’efficacité des requêtes de données et affecte l’expérience utilisateur.
Solution BitEngine de ByteHouse
Présentation du programme
nouveau moteur de requête
Basé sur des fonctionnalités hautes performances et distribuées, ClickHouse peut répondre aux exigences d'analyse et de requête de données à grande échelle. Par conséquent, l'équipe R&D a développé l'entrepôt de données cloud natif du moteur volcanique ByteHouse basé sur l'open source ClickHouse et a personnalisé un ensemble de modèles de traitement qu'il contient : BitEngine , qui est utilisé pour résoudre le problème d'amélioration des performances de l'intersection et compléter le calcul des ensembles dans des scénarios d'analyse en temps réel.
Le nouveau moteur de requête développé pour l'estimation de la fréquentation publicitaire est basé sur les moteurs de la série MergeTree Family fournis par ByteHouse, ajoutant un nouveau type bitmap64 et une série de fonctions d'agrégation associées. Le type bitmap64 fourni par BitEngine convient au stockage et au calcul de la relation entre un grand nombre d'identifiants d'utilisateur ; dans le secteur de l'estimation de la foule publicitaire, le type bitmap64 est utilisé pour stocker les données du package de foule, puis convertir le calcul d'intersection et de complément entre la foule packages en bitmap Intersection et complémentation entre eux, de manière à atteindre un indice de performance dépassant de loin celui des requêtes ordinaires.
Étapes de mise en œuvre
Créez un type bitmap64, qui peut stocker directement l'ID utilisateur dans le bitmap, fournissez une série de calculs d'intersection et d'agrégation complémentaire, et espérez également utiliser pleinement les capacités de calcul parallèle des processeurs multicœurs, nous avons donc conçu BitEngine. L'exemple est le suivant
CREATE TABLE cdp.tag_uids_map (
tags String,
uids BitMap64 BitEngineEncode
)ENGINE = HaMergeTree('/clickhouse/xxxx/{shard}', '{replica}')
ORDER BY tagLe format de stockage de tag_uids_map est le suivant
| étiqueter | uides |
|---|---|
| UN | {10001,20001,30001,40001,50001,60001,70001,80001,90001} |
| B | {10001,20001,20002,20003,20004,20005,20006,20007,20008} |
Le résultat SQL pour interroger A&B est
SELECT bitmapCount('A&B') FROM tag_uids_map
BitEngine implémente la logique
idée principale
Partitionnez et encodez les données pour garantir qu'il n'y a pas d'intersection entre les données dans chaque intervalle, puis utilisez le bitmap rugissant pour enregistrer les données ;
Pendant le calcul, les données de chaque partition peuvent être agrégées indépendamment pour utiliser pleinement la capacité parallèle de la machine. Le calcul d'agrégation à l'intérieur de chaque partition est l'intersection et la complémentation de plusieurs bitmaps. Le calcul efficace d'intersection et de complémentation du bitmap rugissant réduit l'utilisation du processeur et de la mémoire ;
Le résultat codé est inversé via le dictionnaire. Le codage des données vise à rendre la distribution des données aussi dense que possible, et le bitmap rugissant peut obtenir de meilleures performances lors du stockage et du calcul.
Applications commerciales
éléments critiques pour l'entreprise
Package de foule : les données de foule calculées par les règles personnalisées de l'annonceur, et le tag sont les données de foule définies par l'équipe dmp en fonction de la demande du marché.
ID de balise : il est mis à jour une fois par jour selon les règles de sortie. L'ID de foule est auto-augmentant et il est recalculé chaque jour en fonction des besoins des annonceurs.
Unicode
Afin d'encoder uniformément les UID des données d'étiquette et des données de foule, le service de codage extrait d'abord les UID des données d'étiquette et les UID des données de foule pour un codage unifié, et hache uniformément la quantité totale d'UID dans 10 000 compartiments, et le numéro de compartiment est i[ 0<=i<=9999], l'uid est codé séquentiellement à partir de 1 dans chaque compartiment et la plage de chaque compartiment est i*2^40 - (i+1)*2^40.
Les données UID augmentent chaque jour, il est donc nécessaire de prendre en charge le codage incrémentiel. Le service de codage obtiendra d'abord les UID incrémentiels chaque jour, les hachera et les placera séquentiellement dans chaque compartiment.
stockage de données
Une fois le codage terminé, les données du dictionnaire seront d'abord écrites uniformément dans la table ruche, ce qui convient à divers scénarios d'utilisation du dictionnaire.
Une fois les données partitionnées et codées, ClickHouse peut stocker les données dans divers formats d'importation de données sous forme de bitmap64 sur le disque.
calcul des données
Comment BitEngine utilise-t-il pleinement la capacité parallèle de l'ordinateur pour effectuer le calcul d'intersection et de complément entre plusieurs bitmaps dans chaque partition ?
Il ya un problème:
Supposons qu'il existe quatre bitmaps, à savoir a, b, c, d ; alors (a | c) & (b | d) n'est pas nécessairement égal à (a & b) | (c & d).
foule
Pack de foule A = [10001, 20001, 30001, 40001, 50001], Pack de foule B = [10001, 20001, 20002, 20003, 20004]
Résultat désiré
Calculer A&B via BitEngine = [10001, 20001]
Conception
Le package foule est divisé en plusieurs intervalles selon certaines règles, et les packages foule entre deux intervalles n'ont pas d'intersection.
Un fil de calcul lit uniquement les paquets de foule du même intervalle pour le calcul et obtient un résultat intermédiaire
Le résultat intermédiaire final n'a besoin que d'effectuer simplement un bitmap ou un calcul
Pour cette conception, BitEngine doit garantir que la lecture et le calcul des données sont effectués strictement selon des intervalles. BitEngine construira une tâche de lecture pour chaque fichier lors de la lecture des données, et un module de planification de threads terminera la planification et la lecture de l'ensemble de la tâche. Le principe de planification de ce module de planification de threads est :
Les fichiers dans différentes partitions ne seront pas lus de manière croisée (la granularité de lecture des fichiers de ClickHouse est plus petite que la granularité des fichiers, il y aura plusieurs threads lisant un fichier successivement et une partition peut également être composée de plusieurs fichiers), c'est-à-dire un thread ne peut lire que A_1, B_1, ne lira pas A_2 ou B_2 entre les deux.
Après la lecture d'une partition, des calculs agrégés peuvent être déclenchés immédiatement pour exécuter une logique de calcul entre les bitmaps afin d'obtenir des résultats intermédiaires. Autrement dit, une fois A_1 et B_1 lus, A_1 et B_1 peuvent être calculés immédiatement.
Une fois que le thread a calculé les résultats intermédiaires, il peut continuer à lire d'autres fichiers.
Une fois que BitEngine a terminé le calcul de tous les résultats intermédiaires, il effectuera une fusion de données en fonction des exigences de sortie des résultats :
Si le résultat à calculer est la cardinalité du bitmap, BitEngine ajoute directement la cardinalité de chaque résultat intermédiaire
Si le résultat du calcul nécessite un bitmap, BitEngine fusionne directement tous les bitmaps, où la fusion fait référence au bitmap ou au calcul.
effet commercial
Effet commercial de la publicité
Espace de stockage de données 3x plus petit +
Temps d'importation réduit de 3x+
Les requêtes avg/pct99/max ont toutes chuté de manière significative, pct99 réduit de 5 s à 2 s.
L'utilisation du processeur diminue considérablement, PageCache économise 100 G+
L'erreur de requête est passée de 10 % à 0 %
Interroger une surveillance fastidieuse avant et après la mise en ligne de BitEngine
Comparaison de la charge du processeur après la mise en ligne de BitEngine
Utilisation de PageCache (plus faible est mieux)
Résumé
Après la mise en ligne de BitEngine, après de nombreux réglages, il a obtenu de bons retours dans le secteur de l'estimation de la foule publicitaire. À l'heure actuelle, BitEngine a été intégré à ByteHouse, l'entrepôt de données natif du cloud du moteur volcanique, pour une sortie externe. Le moteur volcanique ByteHouse offre principalement aux utilisateurs une expérience d'analyse extrêmement rapide. Il peut prendre en charge l'analyse de données en temps réel et l'analyse de données massives hors ligne. Il possède des capacités d'expansion et de contraction élastiques pratiques, des performances d'analyse extrêmes et de riches fonctionnalités au niveau de l'entreprise. À l'heure actuelle, il a coopéré avec le China Earthquake Network Center, Neptunus Group, Lilith Games, Geekbang Technology et de nombreuses autres entreprises industrielles et ont conclu une coopération pour aider en profondeur la transformation numérique de diverses industries. À l'avenir, BitEngine continuera d'améliorer ses fonctions pour prendre en charge des scénarios commerciaux publicitaires, notamment : le moteur intègre le codage des données pour rendre le codage transparent pour les utilisateurs ; fournit une mise en cache à granularité fine pour mettre en cache les résultats de calcul de certaines expressions répétées ; optimise l'analyse des expressions. , etc.