Bonjour, Habr ! Actuellement, il y a une nouvelle session d'inscription pour le cours sur OTUS. . À l'approche du début du cours, nous continuons à partager avec vous du matériel utile.
Gestion des données
La gouvernance des données forte (Strong Data Governance) est le principe fondamental de l'ingénierie chez Twitter. Au fur et à mesure que nous intégrons BigQuery dans notre plateforme, nous nous concentrons sur la découverte des 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 élargi notre niveau d'accès aux données (Data Access Layer — ), afin de fournir des outils tant pour les données locales que pour les données Google Cloud, en offrant une interface unique et une API à nos utilisateurs. À mesure que Google avance vers la transparence, nous l'intégrerons dans nos projets pour offrir aux utilisateurs des fonctionnalités telles que la recherche par colonnes.
BigQuery permet un partage et un accès faciles aux données, mais nous devions exercer un certain contrôle pour empêcher l'exfiltration de données. Parmi d'autres outils, nous avons choisi deux fonctionnalités :
- : une fonctionnalité bêta qui interdit aux utilisateurs de partager des ensembles de données BigQuery avec des utilisateurs externes à Twitter.
- : un contrôle qui empêche l'exfiltration de données et exige que les utilisateurs accèdent à BigQuery à partir de plages d'adresses IP connues.
Nous avons mis en œuvre les exigences d'authentification, d'autorisation et d'audit (AAA) pour garantir la sécurité de la manière suivante :
- Authentification : nous avons utilisé des comptes d'utilisateur GCP pour des requêtes ad hoc et des comptes de service pour des requêtes de travail.
- Autorisation : nous exigions que chaque ensemble de données ait un compte de service propriétaire et un groupe de lecteurs.
- Audit : nous avons exporté les journaux des pilotes de pile BigQuery, qui contenaient des informations détaillées sur l'exécution des requêtes, dans un ensemble de données BigQuery pour faciliter l'analyse.
Pour assurer le traitement approprié des données personnelles des utilisateurs de Twitter, nous devons enregistrer tous les ensembles de données BigQuery, annoter les données personnelles, maintenir un stockage approprié et supprimer (nettoyer) les données qui ont été supprimées par les utilisateurs.
Nous avons examiné l'API Google , qui utilise l'apprentissage automatique pour classifier et éditer les données sensibles, mais nous avons décidé de privilégier l'annotation manuelle du jeu de données en raison de sa précision. Nous prévoyons d'utiliser l'API de prévention des pertes de données pour compléter l'annotation par les utilisateurs.
Sur Twitter, nous avons créé quatre catégories de confidentialité pour les jeux de données dans BigQuery, énumérées ici par ordre de sensibilité décroissante :
- Les jeux de données hautement sensibles sont accessibles au besoin, sur la base du principe du moindre privilège. Chaque jeu de données a un groupe distinct de lecteurs, et nous suivrons l'utilisation des comptes individuels.
- Les jeux de données de sensibilité moyenne (pseudonymes à sens unique utilisant un hachage salé) ne contiennent pas d'informations personnelles identifiables (Personally Identifiable Information — PII) et sont accessibles à un plus grand groupe d'employés. C'est un bon équilibre entre les considérations de confidentialité et l'utilité des données. Cela permet aux employés d'effectuer des tâches d'analyse, comme le calcul du nombre d'utilisateurs ayant utilisé la fonctionnalité, sans connaître l'identité des véritables utilisateurs.
- Les jeux de données à faible sensibilité contiennent toutes les informations permettant d'identifier l'utilisateur. C'est une bonne approche en termes de confidentialité, mais cela ne peut pas être utilisé pour des analyses au niveau utilisateur.
- Les jeux de données publics (publiés en dehors de Twitter) sont accessibles à tous les employés de Twitter.
En ce qui concerne l'enregistrement, nous avons utilisé des tâches planifiées pour lister les jeux de données BigQuery et les enregistrer dans la couche d'accès aux données (), le référentiel de métadonnées de Twitter. Les utilisateurs annoteront les jeux de données avec des informations de confidentialité et définiront également la durée de conservation. En ce qui concerne le nettoyage, nous évaluons la performance et le coût de deux options : 1. Nettoyage des jeux de données dans GCS à l'aide d'outils comme Scalding, puis chargement dans BigQuery ; 2. Utilisation des opérateurs DML de BigQuery. Nous utiliserons probablement une combinaison des deux méthodes pour répondre aux exigences des 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 l'exécution des tâches de garde. Il était facile de fournir une grande capacité tant pour le stockage que pour le calcul. Nous pouvions modifier la réservation de slots en créant des tickets auprès du support Google. Nous avons constaté que des améliorations pouvaient être apportées, par exemple, l'auto-assistance pour la distribution des slots et l'amélioration du tableau de bord pour le monitoring, et nous avons transmis ces demandes à Google.
Coût
Notre analyse préliminaire a montré que le coût des requêtes pour BigQuery et Presto était comparable. Nous avons acquis des slots à pour avoir un coût mensuel stable au lieu de payer par To de données traitées. Cette décision a également été basée sur les retours des utilisateurs qui ne souhaitaient pas réfléchir aux coûts avant d'exécuter chaque requête.
Le stockage des données dans BigQuery a engendré des coûts en plus des dépenses sur GCS. Des outils comme Scalding nécessitent des ensembles de données dans GCS, et pour accéder à BigQuery, nous devions télécharger les mêmes ensembles de données au format BigQuery . Nous travaillons sur la connexion de Scalding aux ensembles de données BigQuery, ce qui éliminera la nécessité de stocker des jeux de données à la fois dans GCS et dans BigQuery.
Pour les cas rares nécessitant des requêtes peu fréquentes sur des dizaines de pétaoctets, nous avons décidé que le stockage des ensembles de données dans BigQuery n'était pas économiquement viable et avons utilisé Presto pour un accès direct aux ensembles de données dans GCS. Pour cela, nous examinons BigQuery External Data Sources.
Prochaines étapes
Nous avons remarqué un grand intérêt pour BigQuery depuis le lancement de la version alpha. Nous ajoutons plus d'ensembles de données et plus d'équipes dans BigQuery. Nous développons des connecteurs pour des outils d'analyse de données, comme Scalding, afin de lire et écrire dans le stockage BigQuery. Nous considérons des outils comme Looker et Apache Zeppelin pour créer des rapports d'entreprise sur la qualité et des notes utilisant des ensembles de données BigQuery.
La collaboration avec Google a été très productive et nous sommes heureux de continuer et de développer ce partenariat. Nous avons travaillé avec Google pour mettre en place notre propre , pour envoyer directement des requêtes à Google. Certain d'entre eux, comme le chargeur BigQuery Parquet, ont déjà été réalisés par Google.
Voici quelques-unes de nos demandes de fonctionnalités à haute priorité pour Google :
- Outils pour faciliter l'importation de données et prise en charge du format LZO-Thrift.
- Segmentation horaire
- Améliorations en matière de contrôle d'accès, telles que les autorisations au niveau des tables, des lignes et des colonnes.
- BigQuery avec intégration et support de Hive Metastore pour le format LZO-Thrift.
- Intégration améliorée du catalogue de données dans l'interface utilisateur de BigQuery
- Autonomie pour la distribution et le monitoring des slots.
Conclusion
La démocratisation de l'analyse de données, de la visualisation et de 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 pouvant aider à atteindre cet objectif, et nous avons lancé l'année dernière BigQuery Alpha pour l'ensemble de l'entreprise.
Nous avons découvert que les requêtes dans BigQuery étaient simples et efficaces. Pour importer et transformer les données, nous avons utilisé des outils Google pour des pipelines simples, mais pour des pipelines complexes, nous avons dû créer notre propre infrastructure Airflow. En matière de gestion des données, les services BigQuery pour l'authentification, l'autorisation et l'audit répondent à nos besoins. Pour la gestion des métadonnées et le respect de la confidentialité, nous avons besoin d'une plus grande flexibilité et avons dû créer nos propres systèmes. BigQuery, en tant que service géré, était simple à utiliser. Les coûts des requêtes étaient comparables à ceux des outils existants. Le stockage des données dans BigQuery a engendré des coûts en plus des frais pour GCS.
Dans l'ensemble, BigQuery fonctionne bien pour l'analyse SQL générale. Nous notons un grand intérêt pour BigQuery, et nous travaillons à transférer un plus grand nombre de ensembles de données, à attirer davantage d'équipes et à créer plus de pipelines avec BigQuery. Des données variées sont utilisées sur Twitter, nécessitant une combinaison d'outils tels que Scalding, Spark, Presto et Druid. Nous avons l'intention de continuer à développer nos outils d'analyse de données et à fournir des recommandations claires à nos utilisateurs sur la meilleure façon d'utiliser nos offres.
Mots de remerciement
Je voudrais remercier mes co-auteurs et collègues de l'équipe, Anju Dja et Will Pascucci, pour leur magnifique collaboration et leur travail acharné sur ce projet. Je tiens également à remercier les ingénieurs et managers de plusieurs équipes chez Twitter et Google qui nous ont aidés ainsi que les utilisateurs de BigQuery chez Twitter pour leurs retours précieux.
Si vous êtes intéressé par ces tâches, consultez nos dans l'équipe Data Platform.
Source : habr.com
