Chaque jour, plus de cent millions de personnes visitent Twitter pour découvrir et discuter de ce qui se passe dans le monde. Chaque tweet et chaque autre action de l'utilisateur génère un événement disponible pour l'analyse des données internes sur Twitter. Des centaines d'employés analysent et visualisent ces données, et l'amélioration de leur expérience est une priorité absolue pour l'équipe Twitter Data Platform.
Nous pensons que les utilisateurs possédant un large éventail de compétences techniques devraient pouvoir trouver des données et avoir accès à des outils d'analyse et de visualisation SQL performants. Cela permettrait à un tout nouveau groupe d'utilisateurs avec moins de préjugés techniques, y compris des analystes de données et des chefs de produit, d'extraire des informations des données, leur permettant de mieux comprendre et utiliser la puissance de Twitter. C'est ainsi que nous démocratisons l'analyse des données Twitter.
Au fur et à mesure que nos outils et capacités d'analyse des données internes se sont améliorés, nous avons constaté des améliorations dans le service Twitter. Cependant, il y a encore place à l'amélioration. Les outils actuels comme Scalding nécessitent une expérience en programmation. Les outils d'analyse basés sur SQL comme Presto et Vertica ont des problèmes de performances à grande échelle. Nous avons également le problème de diffuser des données sur plusieurs systèmes sans y avoir constamment accès.
L'année dernière, nous avons annoncé un nouveau partenariat avec Google qui apporte une partie de notre infrastructure de données à Google Cloud Platform (GCP). Nous avons conclu que les outils Google Cloud Big Data peut nous aider dans nos initiatives de démocratisation de l'analyse, de la visualisation et de l'apprentissage automatique sur Twitter:
- BigQuery : un entrepôt de données d'entreprise doté d'un moteur SQL basé sur Dremel, réputé pour sa vitesse, sa simplicité et son apprentissage automatique .
- Data Studio: un outil de visualisation Big Data avec des fonctionnalités de collaboration telles que Google Docs.
Dans cet article, vous découvrirez notre expérience avec ces outils: ce que nous avons fait, ce que nous avons appris et ce que nous ferons ensuite. Nous allons maintenant nous concentrer sur les analyses par lots et interactives. Nous discuterons de l'analyse en temps réel dans le prochain article.
Historique du magasin de données Twitter
Avant de plonger dans BigQuery, il vaut la peine de raconter brièvement l'histoire du stockage de données Twitter. En 2011, l'analyse des données Twitter a été effectuée dans Vertica et Hadoop. Pour créer des tâches MapReduce Hadoop, nous avons utilisé Pig. En 2012, nous avons remplacé Pig par Scalding, qui avait une API Scala avec des avantages tels que la possibilité de créer des pipelines complexes et la facilité des tests. Cependant, pour de nombreux analystes de données et chefs de produit qui étaient plus à l'aise avec SQL, la courbe d'apprentissage était abrupte. Vers 2016, nous avons commencé à utiliser Presto comme interface SQL pour les données Hadoop. Spark a offert une interface Python, ce qui en fait un bon choix pour l'exploration de données ad hoc et l'apprentissage automatique.
Depuis 2018, nous utilisons les outils suivants pour l'analyse et la visualisation des données:
- Échaudage pour convoyeurs de production
- Scalding et Spark pour l'analyse de données ad hoc et l'apprentissage automatique
- Vertica et Presto pour une analyse SQL ad hoc et interactive
- Druid pour un accès interactif, exploratoire et à faible latence aux métriques de séries chronologiques
- Tableau, Zeppelin et Pivot pour la visualisation des données
Nous avons constaté que si ces outils offrent des fonctionnalités très puissantes, nous avons eu du mal à les rendre disponibles à un public plus large sur Twitter. Alors que nous étendons notre plate-forme avec Google Cloud, nous nous concentrons sur la simplification de nos outils d'analyse sur Twitter.
Entrepôt de données Google BigQuery
Plusieurs équipes sur Twitter ont déjà inclus BigQuery dans certains de leurs pipelines de production. Forts de leur expérience, nous avons commencé à évaluer les capacités de BigQuery pour tous les cas d'utilisation de Twitter. Notre objectif était de proposer BigQuery à l'ensemble de l'entreprise, de le standardiser et de le supporter dans la boîte à outils Data Platform. Cela a été difficile pour de nombreuses raisons. Nous devions concevoir l'infrastructure pour recevoir de manière fiable de grandes quantités de données, prendre en charge la gestion des données dans toute l'entreprise, assurer un contrôle d'accès approprié et garantir la confidentialité des clients. Nous avons également dû créer des systèmes d'allocation, de surveillance et de rétrofacturation des ressources afin que les équipes puissent utiliser BigQuery efficacement.
En novembre 2018, nous avons publié une version alpha de BigQuery et Data Studio pour l'ensemble de l'entreprise. Nous avons offert aux employés de Twitter certaines de nos feuilles de calcul de données personnelles les plus utilisées. BigQuery a été utilisé par plus de 250 utilisateurs issus de diverses équipes, dont l'ingénierie, la finance et le marketing. Plus récemment, ils ont exécuté environ 8 000 demandes, traitant environ 100 PB par mois, sans compter les demandes planifiées. Après avoir reçu des commentaires très positifs, nous avons décidé d'aller de l'avant et d'offrir BigQuery comme notre principale ressource pour interagir avec les données sur Twitter.
Voici un schéma de l'architecture de haut niveau de notre entrepôt de données Google BigQuery.
Nous copions les données des clusters Hadoop sur site vers Google Cloud Storage (GCS) à l'aide de l'outil Cloud Replicator interne. Nous utilisons ensuite Apache Airflow pour créer des pipelines qui utilisent « bq_load » pour charger des données de GCS dans BigQuery. Nous utilisons Presto pour interroger les ensembles de données Parquet ou Thrift-LZO dans GCS. BQ Blaster est un outil de Scalding interne permettant de charger des ensembles de données HDFS Vertica et Thrift-LZO dans BigQuery.
Dans les sections suivantes, nous discuterons de notre approche et de nos connaissances dans les domaines de la facilité d'utilisation, des performances, de la gestion des données, de l'intégrité du système et des coûts.
Facilité d'utilisation
Nous avons trouvé qu'il était facile pour les utilisateurs de démarrer avec BigQuery, car il ne nécessitait pas d'installation de logiciel et les utilisateurs pouvaient y accéder via une interface Web intuitive. Cependant, les utilisateurs devaient se familiariser avec certaines des fonctionnalités de GCP et de ses concepts, notamment des ressources telles que des projets, des ensembles de données et des tableaux. Nous avons développé des tutoriels et des tutoriels pour aider les utilisateurs à démarrer. Grâce à cette compréhension de base, il devient facile pour les utilisateurs de parcourir les ensembles de données, d'afficher les données de schéma et de table, d'exécuter des requêtes simples et de visualiser les résultats dans Data Studio.
Notre objectif avec la saisie de données BigQuery était de garantir un chargement fluide des ensembles de données HDFS ou GCS en un seul clic. Nous avons considéréCloud Composer (géré par Airflow), mais n'a pas pu l'utiliser en raison de notre modèle de sécurité de partage restreint de domaine (plus d'informations à ce sujet dans la section Gestion des données ci-dessous). Nous avons expérimenté l'utilisation du service de transfert de données Google (DTS) pour organiser les tâches de chargement BigQuery. Bien que DTS ait été rapide à mettre en place, il n'était pas flexible pour la création de pipelines de dépendance. Pour notre alpha, nous avons créé notre propre framework Apache Airflow dans GCE et le préparons pour la production et la possibilité de prendre en charge plus de sources de données comme Vertica.
Pour transformer des données en BigQuery, les utilisateurs créent de simples pipelines de données SQL à l'aide de requêtes planifiées. Pour les pipelines de dépendances complexes à plusieurs étapes, nous prévoyons d'utiliser notre propre framework Airflow ou Cloud Composer avec Cloud Dataflow .
Performance
BigQuery est conçu pour les requêtes SQL à usage général qui traitent de grandes quantités de données. Il n'est pas destiné aux requêtes à faible latence et à haut débit requises par une base de données transactionnelle, ni à l'analyse de séries chronologiques à faible latence implémentée par Apache Druid . Pour les requêtes analytiques interactives, nos utilisateurs s'attendent à un temps de réponse de moins d'une minute. Nous avons dû concevoir l'utilisation de BigQuery pour répondre à ces attentes. Pour garantir des performances prévisibles à nos utilisateurs, nous avons utilisé BigQuery, une fonctionnalité proposée aux clients à un tarif forfaitaire, qui permet aux propriétaires de projets de réserver des emplacements minimums pour leurs requêtes. FenteBigQuery est une unité de puissance de calcul requise pour exécuter des requêtes SQL.
Nous avons analysé plus de 800 requêtes traitant chacune environ 1 To de données et avons trouvé un temps d'exécution moyen de 30 secondes. Nous avons également appris que les performances dépendent fortement de l'utilisation de notre emplacement dans divers projets et tâches. Nous avons dû faire une distinction claire entre notre production et nos réserves de créneaux ad hoc pour maintenir les performances des cas d'utilisation de production et de l'analyse interactive. Cela a grandement influencé notre conception des réservations d'emplacements et de la hiérarchie des projets.
Nous parlerons de la gestion des données, des fonctionnalités et du coût des systèmes dans les prochains jours dans la deuxième partie de la traduction, et maintenant nous invitons tout le monde à un webinaire en direct gratuit, , — (Senior Data Engineer, MaximaTelecom).