Salut Habr ! L'inscription à un nouveau volet de cours est ouverte dès maintenant chez OTUS. . En prévision du début du cours, nous continuons de partager du matériel utile avec vous.
Gestion de données
Une gouvernance solide des données est un principe fondamental de l’ingénierie Twitter. Lorsque nous implémentons BigQuery dans 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 découvrir et gérer les données, nous avons étendu notre couche d'accès aux données pour ) pour fournir des outils pour les données sur site et Google Cloud, en fournissant une interface et une API uniques à nos utilisateurs. Comme Google évolue vers une disponibilité générale, nous l'inclurons dans nos projets pour offrir aux utilisateurs des fonctionnalités telles que la recherche de colonnes.
BigQuery facilite le partage et l'accès aux données, mais nous devions avoir un certain contrôle sur cela pour empêcher l'exfiltration des données. Entre autres outils, nous avons sélectionné deux fonctions :
- : fonctionnalité bêta permettant d'empêcher les utilisateurs de partager des ensembles de données BigQuery avec des utilisateurs extérieurs à Twitter.
- : contrôle qui empêche l'exfiltration de données et oblige les utilisateurs à accéder à BigQuery à partir de plages d'adresses IP connues.
Nous avons mis en œuvre les exigences d'authentification, d'autorisation et d'audit (AAA) pour la sécurité comme suit :
- Authentification : nous avons utilisé des comptes d'utilisateurs GCP pour les demandes ponctuelles et des comptes de service pour les demandes de production.
- Autorisation : nous avons exigé que chaque ensemble de données ait un compte de service propriétaire et un groupe de lecteurs.
- Audit : nous avons exporté les journaux BigQuery Stackdriver, qui contenaient des informations détaillées sur l'exécution des requêtes, dans un ensemble de données BigQuery pour une analyse facile.
Pour garantir que les données personnelles des utilisateurs de Twitter sont traitées correctement, nous devons enregistrer tous les ensembles de données BigQuery, annoter les données personnelles, maintenir un stockage approprié et supprimer (gratter) les données qui ont été supprimées par les utilisateurs.
Nous avons regardé Google , qui utilise l'apprentissage automatique pour classer et modifier les données sensibles, mais a décidé d'annoter manuellement l'ensemble de données pour des raisons de précision. Nous prévoyons d'utiliser l'API Data Loss Prevention pour augmenter l'annotation personnalisée.
Chez Twitter, nous avons créé quatre catégories de confidentialité pour les ensembles de données dans BigQuery, répertoriées ici par ordre décroissant de sensibilité :
- Des ensembles de données hautement sensibles sont mis à disposition selon les besoins, sur la base du principe du moindre privilège. Chaque ensemble de données dispose d'un groupe distinct de lecteurs et nous suivrons l'utilisation par compte individuel.
- Les ensembles de données de sensibilité moyenne (pseudonymes à sens unique utilisant le hachage salé) ne contiennent pas d'informations personnelles identifiables (PII) et sont accessibles à un groupe plus large d'employés. Il s'agit d'un bon équilibre entre les problèmes de confidentialité et l'utilité des données. Cela permet aux employés d’effectuer des tâches d’analyse, comme calculer le nombre d’utilisateurs ayant utilisé une fonctionnalité, sans savoir qui sont les véritables utilisateurs.
- Ensembles de données à faible sensibilité avec toutes les informations d’identification des utilisateurs. Il s'agit d'une bonne approche du point de vue de la confidentialité, mais ne peut pas être utilisée pour une analyse au niveau de l'utilisateur.
- Les ensembles de données publics (publiés en dehors de Twitter) sont accessibles à tous les employés de Twitter.
En ce qui concerne la journalisation, nous avons utilisé des tâches planifiées pour énumérer les ensembles de données BigQuery et les enregistrer auprès de la couche d'accès aux données (), référentiel de métadonnées Twitter. Les utilisateurs annoteront les ensembles de données avec des informations de confidentialité et spécifieront également une période de conservation. Quant au nettoyage, nous évaluons les performances et le coût de deux options : 1. Nettoyer les ensembles de données dans GCS à l'aide d'outils comme Scalding et les charger dans BigQuery ; 2. Utilisation des instructions 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
BigQuery étant un service géré, il n'était pas nécessaire d'impliquer l'équipe SRE de Twitter dans la gestion des systèmes ou dans les tâches administratives. Il était facile de fournir davantage de capacité de stockage et de calcul. Nous pourrions modifier la réservation du créneau en créant un ticket avec le support Google. Nous avons identifié les domaines qui pourraient être améliorés, tels que l'attribution d'emplacements en libre-service et l'amélioration du tableau de bord pour la surveillance, et avons soumis ces demandes à Google.
coût de
Notre analyse préliminaire a montré que les coûts des requêtes pour BigQuery et Presto étaient au même niveau. Nous avons acheté des emplacements pour prix pour avoir un coût mensuel stable au lieu du paiement par To de données traitées. Cette décision s'est également basée 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 tels que 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. . Nous travaillons sur une connexion Scalding aux 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 requêtes peu fréquentes de plusieurs 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 constaté beaucoup d'intérêt pour BigQuery depuis la version alpha. Nous ajoutons davantage d'ensembles de données et de commandes à BigQuery. Nous développons des connecteurs pour les outils d'analyse de données tels que Scalding afin de lire et d'écrire sur le stockage BigQuery. Nous étudions des outils tels que Looker et Apache Zeppelin pour créer des rapports et des notes de qualité entreprise à l'aide d'ensembles de données BigQuery.
Notre collaboration avec Google a été très productive et nous sommes heureux de poursuivre et de développer ce partenariat. Nous avons travaillé avec Google pour mettre en œuvre notre propre pour envoyer des requêtes directement à Google. Certains d'entre eux, comme le chargeur BigQuery Parquet, ont déjà été implémentés par Google.
Voici quelques-unes de nos demandes de fonctionnalités hautement prioritaires pour Google :
- Outils pour une réception pratique 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 au niveau des tables, des lignes et des colonnes.
- BigQuery avec l'intégration de Hive Metastore et la prise en charge du format LZO-Thrift.
- Intégration améliorée du catalogue de données dans l'interface utilisateur de BigQuery
- Libre-service pour l’attribution et la surveillance des créneaux horaires.
Conclusion
Démocratiser l'analyse des données, la visualisation et l'apprentissage automatique de manière sécurisée est une priorité absolue pour l'équipe Data Platform. Nous avons identifié Google BigQuery et Data Studio comme des outils susceptibles de nous aider à atteindre cet objectif, et avons lancé BigQuery Alpha à l'échelle de l'entreprise l'année dernière.
Nous avons trouvé que les requêtes dans BigQuery étaient simples et efficaces. Nous avons utilisé les outils Google pour ingérer et transformer les données de pipelines simples, mais pour les pipelines complexes, nous avons dû créer notre propre framework Airflow. Dans le domaine de la gestion des données, les services d'authentification, d'autorisation et d'audit de BigQuery répondent à nos besoins. Pour gérer les métadonnées et préserver la confidentialité, nous avions besoin de plus de flexibilité et avons dû créer nos propres systèmes. BigQuery, étant un service géré, était facile à utiliser. Les coûts des requêtes étaient similaires à ceux des outils existants. Le stockage de données dans BigQuery entraîne des coûts en plus des coûts GCS.
Dans l'ensemble, BigQuery fonctionne bien pour l'analyse SQL générale. Nous constatons beaucoup d'intérêt pour BigQuery et nous travaillons à migrer davantage d'ensembles de données, à recruter davantage d'équipes et à créer davantage de pipelines avec BigQuery. Twitter utilise une variété de données qui nécessiteront une combinaison d'outils tels que Scalding, Spark, Presto et Druid. Nous avons l'intention de continuer à renforcer nos outils d'analyse de données et de fournir des conseils clairs à nos utilisateurs sur la meilleure façon d'utiliser nos offres.
Mots de remerciement
Je tiens à remercier mes co-auteurs et coéquipiers, Anju 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 de Twitter et de Google qui nous ont aidé, ainsi que les utilisateurs de BigQuery sur Twitter qui nous ont fourni de précieux commentaires.
Si vous souhaitez travailler sur ces problèmes, consultez notre dans l'équipe Data Platform.
Source: habr.com