Hallo, Habr! Momenteel is er een nieuwe aanmelding geopend voor de cursus bij OTUS. . In aanloop naar de start van de cursus blijven we nuttige materialen met jullie delen.
Gegevensbeheer
Sterk gegevensbeheer (Strong Data Governance) is een fundamenteel principe van Twitter Engineering. Terwijl we BigQuery in ons platform implementeren, richten we ons op gegevensontdekking, toegangscontrole, beveiliging en privacy.
Voor gegevensontdekking en -beheer hebben we ons gegevenstoegangsniveau (Data Access Layer — ) uitgebreid om tools voor zowel lokale gegevens als gegevens van Google Cloud te bieden, met een enkele interface en API voor onze gebruikers. Terwijl Google streeft naar openbaarmaking, zullen we dit in onze projecten opnemen om gebruikers functies zoals kolomzoekopdrachten te bieden.
BigQuery maakt het eenvoudig om gegevens te delen en toegang te krijgen, maar we moesten dit in zekere mate controleren om gegevensexfiltratie te voorkomen. Onder andere tools hebben we gekozen voor twee functies:
- : een bèt kenmerk dat gebruikers verbiedt om BigQuery-datasets te delen met gebruikers buiten Twitter.
- : een controle-element dat gegevensexfiltratie voorkomt en gebruikers verplicht om toegang tot BigQuery te hebben vanaf bekende IP-adresbereiken.
We hebben de vereisten voor authenticatie, autorisatie en auditing (AAA) voor beveiliging als volgt geïmplementeerd:
- Authenticatie: we gebruikten GCP-gebruikersaccounts voor ad-hoc verzoeken en serviceaccounts voor werkverzoeken.
- Autorisatie: we vereisten dat elke dataset een serviceaccount-eigenaar en een lezersgroep had.
- Auditing: we exporteerden BigQuery-stackdriverlogs, die gedetailleerde informatie over uitgevoerde verzoeken bevatten, naar een BigQuery-dataset voor gemakkelijkere analyse.
Om een juiste behandeling van persoonlijke gegevens van Twitter-gebruikers te waarborgen, moeten we alle BigQuery-datasets registreren, persoonlijke gegevens annoteren, zorgen voor juiste opslag en verwijderen (opschonend) van gegevens die door gebruikers zijn verwijderd.
We hebben gekeken naar de Google , die machine learning gebruikt voor het classificeren en bewerken van vertrouwelijke gegevens, maar we hebben besloten om handmatige annotatie van de dataset te gebruiken vanwege de nauwkeurigheid. We zijn van plan om de Data Loss Prevention API te gebruiken om de gebruikersannotatie aan te vullen.
Bij Twitter hebben we vier privacycategorieën voor datasets in BigQuery gecreëerd, hier opgesomd in volgorde van afnemende gevoeligheid:
- Zeer gevoelige datasets zijn beschikbaar op basis van het principe van de minste privileges. Elke dataset heeft een aparte groep lezers, en we zullen het gebruik van afzonderlijke accounts volgen.
- Datasets met gemiddelde gevoeligheid (éénzijdige aliassen met behulp van zout-gehashte waarden) bevatten geen persoonlijke informatie (Personally Identifiable Information - PII) en zijn beschikbaar voor een grotere groep medewerkers. Dit is een goede balans tussen privacyoverwegingen en nuttigheid van gegevens. Het stelt medewerkers in staat om analyses uit te voeren, zoals het berekenen van het aantal gebruikers dat de functie heeft gebruikt, zonder te weten wie de echte gebruikers zijn.
- Datasets met lage gevoeligheid bevatten alle informatie die de gebruiker identificeert. Dit is een goede benadering vanuit privacyperspectief, maar kan niet worden gebruikt voor analyses op gebruikersniveau.
- Openbare datasets (vrijgegeven buiten Twitter) zijn toegankelijk voor alle Twitter-medewerkers.
Wat betreft de registratie hebben we geplande taken gebruikt om de datasets in BigQuery op te sommen en ze te registreren in de Data Access Layer (), de metadataopslag van Twitter. Gebruikers zullen datasets annoteren met informatie over vertrouwelijkheid en de bewaartermijn aangeven. Wat betreft de schoonmaak, we evalueren de prestaties en kosten van twee opties: 1. Het schoonmaken van datasets in GCS met hulpmiddelen zoals Scalding en het uploaden ervan naar BigQuery; 2. Het gebruik van BigQuery DML-operators. We zullen waarschijnlijk een combinatie van beide methoden gebruiken om te voldoen aan de vereisten van verschillende groepen en gegevens.
Functionaliteit van het systeem
Aangezien BigQuery een beheerde service is, was het niet nodig om het SRE-team van Twitter te betrekken bij het beheer van systemen of het uitvoeren van waakdiensten. Het was eenvoudig om grote capaciteit te bieden, zowel voor opslag als voor berekeningen. We konden de reservering van slots aanpassen door tickets in te dienen bij de ondersteuning van Google. We hebben vastgesteld dat we verbeteringen konden aanbrengen, zoals zelfbediening voor de distributie van slots en verbeteringen aan het dashboard voor monitoring, en hebben deze verzoeken aan Google doorgegeven.
Cost
Onze voorlopige analyse toonde aan dat de kosten voor verzoeken voor BigQuery en Presto gelijk waren. We hebben slots aangeschaft tegen prijs, zodat we een stabiele maandelijkse kostenstructuur hadden in plaats van betalen voor verwerkte data per TB. Deze beslissing was ook gebaseerd op feedback van gebruikers die niet willen nadenken over kosten voordat ze elk verzoek uitvoeren.
Het opslaan van gegevens in BigQuery bracht kosten met zich mee naast de kosten voor GCS. Hulpmiddelen zoals Scalding vereisen datasets in GCS, en om toegang te krijgen tot BigQuery moesten we dezelfde datasets in het BigQuery-formaat uploaden. . We werken aan het verbinden van Scalding met BigQuery-datasets, wat de noodzaak van opslag van datasets in zowel GCS als BigQuery zal wegnemen.
Voor zeldzame gevallen die niet vaak verzoeken vereisten voor tientallen petabytes, hebben we beslist dat het opslaan van datasets in BigQuery niet kosteneffectief was, en hebben we Presto gebruikt voor directe toegang tot datasets in GCS. Hiervoor onderzoeken we BigQuery External Data Sources.
Volgende stappen
We hebben een grote interesse in BigQuery opgemerkt sinds de release van de alpha. We voegen meer datasets en meer teams toe aan BigQuery. We ontwikkelen connectors voor data-analysetools zoals Scalding, voor lezen en schrijven naar BigQuery-opslag. We overwegen tools zoals Looker en Apache Zeppelin om bedrijfsrapporten over kwaliteit en notities te maken met BigQuery-datasets.
De samenwerking met Google was zeer productief en we kijken ernaar uit om dit partnerschap voort te zetten en uit te breiden. We hebben met Google samengewerkt om onze eigen , te implementeren om verzoeken rechtstreeks naar Google te sturen. Sommige van deze, zoals de BigQuery Parquet-loader, zijn al geïmplementeerd door Google.
Hier zijn enkele van onze hooggeprioriteerde fungevraag aanvragen voor Google:
- Tools voor gemakkelijke dataverwerking en ondersteuning voor het LZO-Thrift formaat.
- Uurtarief segmentatie
- Verbeteringen op het gebied van toegangscontrole, zoals permissies op tabel-, regel- en kolomniveau.
- BigQuery met integratie en ondersteuning van Hive Metastore voor het LZO-Thrift formaat.
- Verbeterde integratie van de gegevenscatalogus in de gebruikersinterface van BigQuery
- Zelfservice voor het toewijzen en monitoren van slots.
Conclusie
Democratisering van data-analyse, visualisatie en machine learning op een veilige manier is de hoogste prioriteit voor het Data Platform-team. We hebben Google BigQuery en Data Studio geïdentificeerd als tools die kunnen helpen bij het bereiken van dit doel en in het afgelopen jaar BigQuery Alpha vrijgegeven voor het hele bedrijf.
We hebben ontdekt dat de aanvragen in BigQuery eenvoudig en efficiënt waren. Voor het ontvangen en transformeren van data gebruikten we Google-tools voor eenvoudige pipelines, maar voor complexe pipelines moesten we onze eigen Airflow-infrastructuur opzetten. Wat betreft databeheer voldoen de BigQuery-diensten voor authenticatie, autorisatie en audit aan onze behoeften. Voor het beheren van metadata en privacy hadden we meer flexibiliteit nodig en moesten we onze eigen systemen creëren. BigQuery, als een beheerde service, was eenvoudig te gebruiken. De kosten voor aanvragen waren vergelijkbaar met bestaande tools. De opslagkosten in BigQuery kwamen bovenop de kosten voor GCS.
Over het algemeen presteert BigQuery goed voor algemene SQL-analyse. We merken veel interesse in BigQuery en werken eraan om meer datasets over te zetten, meer teams aan te trekken en meer pipelines met BigQuery te creëren. In Twitter worden verschillende gegevens gebruikt waarvoor een combinatie van tools zoals Scalding, Spark, Presto en Druid nodig zal zijn. We zijn van plan onze data-analysetools verder uit te bouwen en duidelijke aanbevelingen aan onze gebruikers te geven over hoe ze het beste gebruik kunnen maken van onze aanbiedingen.
Woorden van dank
Ik wil mijn co-auteurs en teamgenoten, Anju Dja en Will Pasqucchi, bedanken voor hun geweldige samenwerking en harde werk aan dit project. Ik wil ook de ingenieurs en managers van verschillende teams bij Twitter en Google bedanken, die ons en de BigQuery-gebruikers bij Twitter hebben geholpen door waardevolle feedback te geven.
Als je geïnteresseerd bent in het werken aan deze taken, bekijk dan onze in het Data Platform-team.
Bron: habr.com
