Lire la première partie
Gestion de données
Une gouvernance solide des données est le principe principal de l'ingénierie Twitter. Alors que nous intégrons BigQuery à notre plate-forme, nous nous concentrons sur la découverte de données, le contrôle d'accès, la sécurité et la confidentialité.
Pour la découverte et la gestion des données, nous avons étendu notre couche d'accès aux données ( DAL ) pour fournir des outils pour les données locales et les données Google Cloud, en fournissant une interface et une API uniques à nos utilisateurs. À mesure que le catalogue de données Google évoluera vers une disponibilité générale, nous l'inclurons dans nos projets pour fournir aux utilisateurs des fonctionnalités telles que la recherche de colonnes.
BigQuery facilite le partage et l'accès aux données, mais nous avions besoin d'un certain contrôle pour empêcher l'exfiltration des données. Entre autres outils, nous avons choisi deux fonctions:
- Partage restreint de domaine : une fonctionnalité bêta qui empêche les utilisateurs de partager des ensembles de données BigQuery avec des utilisateurs extérieurs à Twitter.
- Contrôles du service VPC : contrôle qui empêche l'exfiltration des données et oblige les utilisateurs à accéder à BigQuery à partir de plages d'adresses IP connues.
Nous avons mis en œuvre les exigences de sécurité d'authentification, d'autorisation et d'audit (AAA) comme suit:
- Authentification: nous avons utilisé des comptes d'utilisateurs GCP pour les demandes ad hoc et des comptes de service pour les demandes de travail.
- Autorisation: nous avons exigé que chaque ensemble de données ait un compte de service propriétaire et un groupe de lecteurs.
- : BigQuery, , BigQuery .
Pour nous assurer que les données personnelles des utilisateurs de Twitter sont correctement traitées, nous devons enregistrer tous les ensembles de données BigQuery, annoter les données personnelles, conserver un stockage approprié et supprimer (nettoyer) les données qui ont été supprimées par les utilisateurs.
Nous avons examiné l' API Google Cloud Data Loss Prevention , qui utilise l'apprentissage automatique pour classer et modifier les données sensibles, mais avons opté pour l'annotation manuelle de l'ensemble de données en raison de sa précision. Nous prévoyons d'utiliser l'API Data Loss Prevention pour compléter l'annotation personnalisée.
Sur Twitter, nous avons créé quatre catégories de confidentialité pour les ensembles de données BigQuery, répertoriées ici par ordre décroissant de sensibilité:
- . , .
- ( ) (Personally Identifiable Information — PII) . . , , , , .
- , . , .
- ( Twitter) Twitter.
Avant l'enregistrement, nous avons utilisé des tâches planifiées pour énumérer les ensembles de données BigQuery et les enregistrer dans la couche d'accès aux données ( DAL ), le magasin de métadonnées de Twitter. Les utilisateurs annoteront les ensembles de données avec des informations de confidentialité ainsi que des périodes de conservation. En ce qui concerne le nettoyage, nous estimons les performances et le coût de deux options: 1. le nettoyage des ensembles de données dans GCS à l'aide d'outils tels que Scalding et leur chargement dans BigQuery; 2. Utilisation des opérateurs DML BigQuery. Nous utiliserons probablement une combinaison des deux méthodes pour répondre aux exigences de différents groupes et données.
Fonctionnalité du système
Étant donné que BigQuery est un service géré, il n'était pas nécessaire d'impliquer l'équipe SRE de Twitter dans la gestion des systèmes ou les tâches en service. Il était facile de fournir plus de capacité pour le stockage et l'informatique. Nous pourrions modifier les réservations de créneaux en créant des billets avec l'assistance de Google. Nous avons identifié ce qui pouvait être amélioré, comme le libre-service pour l'attribution des créneaux horaires et de meilleurs tableaux de bord de surveillance, et avons transmis ces demandes à Google.
Le coût
Notre analyse préliminaire a montré que le coût des requêtes pour BigQuery et Presto était au même niveau. Nous avons acheté des créneaux horaires à un prix fixe pour avoir un coût mensuel stable au lieu de payer à la demande pour TB de données traitées. Cette décision reposait également sur les retours des utilisateurs qui ne voulaient pas penser aux coûts avant de faire chaque demande.
Le stockage des données dans BigQuery entraînait des coûts en plus des coûts GCS. Des outils comme Scalding nécessitent des ensembles de données dans GCS, et pour accéder à BigQuery, nous avons dû charger les mêmes ensembles de données au format BigQuery Capacitor... Nous travaillons sur une connexion Scalding avec des ensembles de données BigQuery qui éliminera le besoin de stocker des ensembles de données à la fois dans GCS et BigQuery.
Pour les rares cas nécessitant des demandes peu fréquentes de dizaines de pétaoctets, nous avons décidé que le stockage des ensembles de données dans BigQuery n'était pas rentable et avons utilisé Presto pour accéder directement aux ensembles de données dans GCS. Pour ce faire, nous examinons les sources de données externes BigQuery.
Prochaines étapes
Nous avons remarqué un grand intérêt pour BigQuery depuis la version alpha. Nous ajoutons plus d'ensembles de données et de commandes à BigQuery. Nous développons des connecteurs pour des outils d'analyse de données tels que Scalding pour la lecture et l'écriture dans le stockage BigQuery. Nous examinons des outils tels que Looker et Apache Zeppelin pour générer des rapports et des notes de qualité d'entreprise à l'aide d'ensembles de données BigQuery.
Le partenariat avec Google a été très productif et nous sommes ravis de poursuivre et de développer ce partenariat. Nous avons travaillé avec Google pour mettre en œuvre notre propre outil de suivi des problèmes de partenaire afin d'envoyer directement les demandes à Google. Certains d'entre eux, comme le téléchargeur BigQuery Parquet, sont déjà mis en œuvre par Google.
Voici quelques-unes de nos demandes de fonctionnalités hautement prioritaires pour Google:
- Outils pour une ingestion facile des données et une prise en charge du format LZO-Thrift.
- Segmentation horaire
- Améliorations du contrôle d'accès telles que les autorisations de table, de ligne et de colonne.
- Sources de données externes BigQuery avec intégration Hive Metastore et prise en charge du format LZO-Thrift.
- Intégration améliorée du catalogue de données dans l'interface utilisateur de BigQuery
- Self-service pour l'attribution et la surveillance des créneaux horaires.
Conclusion
Démocratiser l'analyse, la visualisation et l'apprentissage automatique des données de manière sûre est une priorité absolue pour l'équipe Data Platform. Nous avons identifié Google BigQuery et Data Studio comme des outils pouvant nous aider à atteindre cet objectif, et nous avons lancé BigQuery Alpha pour l'ensemble de l'entreprise l'année dernière.
Nous avons constaté que les requêtes BigQuery étaient simples et efficaces. Nous avons utilisé des outils Google pour des pipelines simples pour recevoir et transformer des données, mais pour des pipelines complexes, nous avons dû créer notre propre infrastructure Airflow. Dans la gestion des données, les services BigQuery d'authentification, d'autorisation et d'audit répondent à nos besoins. Nous avions besoin de beaucoup de flexibilité pour gérer les métadonnées et maintenir la confidentialité, et nous avons dû construire nos propres systèmes. BigQuery, en tant que service géré, était facile à utiliser. Les coûts de demande étaient similaires à ceux des outils existants. Le stockage de données dans BigQuery a entraîné des coûts en plus du coût de GCS.
Dans l'ensemble, BigQuery fonctionne bien pour l'analyse SQL générale. Nous constatons un grand intérêt pour BigQuery, et nous travaillons à migrer plus d'ensembles de données, à engager plus d'équipes et à créer plus de pipelines avec BigQuery. Twitter utilise une variété de données, ce qui nécessitera un mélange d'outils tels que Scalding, Spark, Presto et Druid. Nous avons l'intention de continuer à nous appuyer sur nos outils d'analyse de données et de fournir des conseils clairs à nos utilisateurs sur la meilleure façon d'utiliser nos offres.
Paroles de gratitude
Je tiens à remercier mes collaborateurs et coéquipiers, Anjou Jha et Will Pascucci, pour leur excellente collaboration et leur travail acharné sur ce projet. Je tiens également à remercier les ingénieurs et les responsables de plusieurs équipes sur Twitter et Google qui nous ont aidés ainsi que les utilisateurs de BigQuery Twitter qui ont fourni de précieux commentaires.
Si vous souhaitez travailler sur ces tâches, consultez nos postes vacants au sein de l'équipe Data Platform.
Qualité des données DWH - Cohérence de l'entrepôt de données