Hallo, Habr! De inschrijving voor een nieuwe cursusstroom is momenteel geopend bij OTUS . Vooruitlopend op de start van de cursus blijven wij nuttig materiaal met u delen.
Gegevensbeheer
Sterk databeheer is een kernprincipe van Twitter Engineering. Terwijl we BigQuery in ons platform implementeren, richten we ons op gegevensontdekking, toegangscontrole, beveiliging en privacy.
Om gegevens te ontdekken en te beheren, hebben we onze Data Access Layer uitgebreid naar ) om tools te bieden voor zowel lokale als Google Cloud-gegevens, waardoor onze gebruikers één enkele interface en API krijgen. Als Google zich in de richting van algemene beschikbaarheid beweegt, zullen we het in onze projecten opnemen om gebruikers functies te bieden zoals zoeken in kolommen.
BigQuery maakt het gemakkelijk om gegevens te delen en te openen, maar we moesten hier enige controle over hebben om gegevensexfiltratie te voorkomen. Naast andere tools hebben we twee functies geselecteerd:
- : Bètafunctie om te voorkomen dat gebruikers BigQuery-datasets delen met gebruikers buiten Twitter.
- : een controle die gegevensexfiltratie voorkomt en vereist dat gebruikers toegang hebben tot BigQuery vanuit 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-hocverzoeken en serviceaccounts voor productieverzoeken.
- Autorisatie: we hebben vereist dat elke dataset een eigenaarserviceaccount en een lezersgroep heeft.
- Controle: We hebben BigQuery Stackdriver-logboeken, die gedetailleerde informatie over de uitvoering van query's bevatten, geëxporteerd naar een BigQuery-dataset voor eenvoudige analyse.
Om ervoor te zorgen dat de persoonlijke gegevens van Twitter-gebruikers op de juiste manier worden verwerkt, moeten we alle BigQuery-datasets registreren, persoonlijke gegevens annoteren, de juiste opslag onderhouden en gegevens verwijderen (scrapen) die door gebruikers zijn verwijderd.
Wij hebben op Google gekeken , dat machinaal leren gebruikt om gevoelige gegevens te classificeren en te bewerken, maar vanwege de nauwkeurigheid heeft gekozen voor het handmatig annoteren van de dataset. We zijn van plan de Data Loss Prevention API te gebruiken om de aangepaste annotatie uit te breiden.
Bij Twitter hebben we vier privacycategorieën gemaakt voor datasets in BigQuery, hier weergegeven in aflopende volgorde van gevoeligheid:
- Zeer gevoelige datasets worden beschikbaar gesteld wanneer dat nodig is, op basis van het principe van de minste privileges. Elke dataset heeft een aparte groep lezers en we houden het gebruik van individuele accounts bij.
- Middelgevoelige datasets (eenrichtingspseudoniemen met behulp van salted hashing) bevatten geen persoonlijk identificeerbare informatie (PII) en zijn toegankelijk voor een grotere groep werknemers. Dit is een goede balans tussen privacykwesties en gegevensnut. Hierdoor kunnen medewerkers analysetaken uitvoeren, zoals het berekenen van het aantal gebruikers dat een functie heeft gebruikt, zonder te weten wie de echte gebruikers zijn.
- Laaggevoelige datasets met alle gebruikersidentificerende informatie. Dit is een goede aanpak vanuit privacyperspectief, maar kan niet worden gebruikt voor analyse op gebruikersniveau.
- Openbare datasets (die buiten Twitter worden vrijgegeven) zijn beschikbaar voor alle Twitter-medewerkers.
Wat de logboekregistratie betreft, hebben we geplande taken gebruikt om BigQuery-datasets op te sommen en deze te registreren bij de Data Access Layer (), Twitter-metagegevensopslagplaats. Gebruikers zullen datasets annoteren met privacy-informatie en ook een bewaartermijn specificeren. Wat schoonmaken betreft, evalueren we de prestaties en kosten van twee opties: 1. Datasets in GCS opschonen met tools als Scalding en deze in BigQuery laden; 2. BigQuery DML-instructies gebruiken. We zullen waarschijnlijk een combinatie van beide methoden gebruiken om aan de eisen van verschillende groepen en gegevens te voldoen.
Systeemfunctionaliteit
Omdat BigQuery een beheerde service is, was het niet nodig om het SRE-team van Twitter te betrekken bij systeembeheer of bureauwerkzaamheden. Het was gemakkelijk om meer capaciteit te bieden voor zowel opslag als computers. We kunnen de slotreservering wijzigen door een ticket aan te maken met Google-ondersteuning. We hebben gebieden geïdentificeerd die verbeterd konden worden, zoals de toewijzing van selfservice-slots en dashboardverbeteringen voor monitoring, en die verzoeken ingediend bij Google.
kosten
Uit onze voorlopige analyse bleek dat de querykosten voor BigQuery en Presto op hetzelfde niveau lagen. We hebben slots gekocht voor prijs om stabiele maandelijkse kosten te hebben in plaats van betaling per TB verwerkte gegevens. Deze beslissing was ook gebaseerd op feedback van gebruikers die niet aan de kosten wilden denken voordat ze een verzoek indienden.
Het opslaan van gegevens in BigQuery bracht naast de GCS-kosten ook kosten met zich mee. Voor tools als Scalding zijn datasets in GCS nodig, en om toegang te krijgen tot BigQuery moesten we dezelfde datasets in BigQuery-indeling laden . We werken aan een Scalding-verbinding met BigQuery-datasets, waardoor het niet meer nodig is om datasets in zowel GCS als BigQuery op te slaan.
Voor zeldzame gevallen waarbij onregelmatige zoekopdrachten van tientallen petabytes nodig waren, hebben we besloten dat het opslaan van datasets in BigQuery niet kosteneffectief was en hebben we Presto gebruikt om rechtstreeks toegang te krijgen tot datasets in GCS. Om dit te doen, kijken we naar externe gegevensbronnen van BigQuery.
Volgende stappen
Sinds de alfarelease hebben we veel belangstelling voor BigQuery gezien. We voegen meer datasets en meer opdrachten toe aan BigQuery. We ontwikkelen connectoren voor tools voor gegevensanalyse, zoals Scalding, om te lezen en te schrijven naar BigQuery-opslag. We kijken naar tools zoals Looker en Apache Zeppelin voor het maken van rapporten en notities van bedrijfskwaliteit met behulp van BigQuery-datasets.
Onze samenwerking met Google is zeer productief geweest en we zijn blij dat we deze samenwerking kunnen voortzetten en ontwikkelen. We hebben met Google samengewerkt om onze eigen implementatie te implementeren om vragen rechtstreeks naar Google te sturen. Sommigen daarvan, zoals de BigQuery Parquet-lader, zijn al door Google geïmplementeerd.
Hier volgen enkele van onze functieverzoeken met hoge prioriteit voor Google:
- Tools voor gemakkelijke gegevensontvangst en ondersteuning voor het LZO-Thrift-formaat.
- Segmentatie per uur
- Verbeteringen in toegangscontrole, zoals machtigingen op tabel-, rij- en kolomniveau.
- BigQuery met Hive Metastore-integratie en ondersteuning voor het LZO-Thrift-formaat.
- Verbeterde gegevenscatalogusintegratie in de BigQuery-gebruikersinterface
- Selfservice voor slottoewijzing en monitoring.
Conclusie
Het op een veilige manier democratiseren van data-analyse, visualisatie en machine learning is een topprioriteit voor het Data Platform-team. We hebben Google BigQuery en Data Studio geïdentificeerd als tools die dit doel kunnen helpen bereiken en hebben vorig jaar BigQuery Alpha voor het hele bedrijf uitgebracht.
We vonden dat zoekopdrachten in BigQuery eenvoudig en efficiënt waren. We gebruikten Google-tools om gegevens voor eenvoudige pipelines op te nemen en te transformeren, maar voor complexe pipelines moesten we ons eigen Airflow-framework bouwen. Op het gebied van gegevensbeheer voldoen de services van BigQuery voor authenticatie, autorisatie en audit aan onze behoeften. Om metadata te beheren en de privacy te behouden hadden we meer flexibiliteit nodig en moesten we onze eigen systemen bouwen. BigQuery was als beheerde service eenvoudig te gebruiken. De querykosten waren vergelijkbaar met die van bestaande tools. Het opslaan van gegevens in BigQuery brengt naast de GCS-kosten ook kosten met zich mee.
Over het algemeen werkt BigQuery goed voor algemene SQL-analyse. We zien veel interesse in BigQuery en we werken eraan om meer datasets te migreren, meer teams aan te trekken en meer pijplijnen te bouwen met BigQuery. Twitter gebruikt een verscheidenheid aan gegevens waarvoor een combinatie van tools nodig is, zoals Scalding, Spark, Presto en Druid. We zijn van plan onze tools voor gegevensanalyse te blijven versterken en onze gebruikers duidelijke richtlijnen te bieden over hoe ze ons aanbod het beste kunnen gebruiken.
Woorden van dankbaarheid
Ik wil mijn co-auteurs en teamgenoten, Anju Jha en Will Pascucci, bedanken voor hun geweldige samenwerking en harde werk aan dit project. Ik wil ook graag de technici en managers van verschillende teams bij Twitter en Google bedanken die ons hebben geholpen, en de BigQuery-gebruikers op Twitter die waardevolle feedback hebben gegeven.
Als je geïnteresseerd bent om aan deze problemen te werken, bekijk dan onze in het Data Platform-team.
Bron: www.habr.com