Com BigQuery de Google va democratitzar l'anàlisi de dades. Part 2

Hola, Habr! La inscripció per a un nou flux de cursos està oberta ara mateix a OTUS Enginyer de dades. En previsió de l'inici del curs, seguim compartint material útil amb vosaltres.

Llegeix la primera part

Com BigQuery de Google va democratitzar l'anàlisi de dades. Part 2

Gestió de dades

Strong Data Governance és un principi bàsic de l'enginyeria de Twitter. Quan implementem BigQuery a la nostra plataforma, ens centrem en la descoberta de dades, el control d'accés, la seguretat i la privadesa.

Per descobrir i gestionar dades, hem ampliat la nostra capa d'accés a dades DAL) per proporcionar eines tant per a dades locals com de Google Cloud, proporcionant una única interfície i API per als nostres usuaris. Com Google Catàleg de dades avança cap a la disponibilitat general, l'inclourem als nostres projectes per oferir als usuaris funcions com la cerca de columnes.

BigQuery facilita compartir i accedir a les dades, però n'havíem de tenir un cert control per evitar l'exfiltració de dades. Entre altres eines, hem seleccionat dues funcions:

  • Compartició restringida del domini: funció beta per evitar que els usuaris comparteixin conjunts de dades de BigQuery amb usuaris fora de Twitter.
  • Controls del servei VPC: un control que evita l'exfiltració de dades i requereix que els usuaris accedeixin a BigQuery des d'intervals d'adreces IP coneguts.

Hem implementat els requisits d'autenticació, autorització i auditoria (AAA) per a la seguretat de la manera següent:

  • Autenticació: hem utilitzat comptes d'usuari de GCP per a sol·licituds ad hoc i comptes de servei per a sol·licituds de producció.
  • Autorització: vam exigir que cada conjunt de dades tingués un compte de servei de propietari i un grup de lectors.
  • Auditoria: vam exportar els registres de BigQuery stackdriver, que contenien informació detallada sobre l'execució de consultes, a un conjunt de dades de BigQuery per a una anàlisi fàcil.

Per garantir que les dades personals dels usuaris de Twitter es gestionen correctament, hem de registrar tots els conjunts de dades de BigQuery, anotar dades personals, mantenir l'emmagatzematge adequat i suprimir (esborrar) les dades que han estat suprimides pels usuaris.

Hem mirat Google API Cloud Data Loss Prevention, que utilitza l'aprenentatge automàtic per classificar i editar dades sensibles, però es va decidir a favor d'anotar manualment el conjunt de dades a causa de la precisió. Tenim previst utilitzar l'API de prevenció de pèrdues de dades per augmentar l'anotació personalitzada.

A Twitter, hem creat quatre categories de privadesa per a conjunts de dades a BigQuery, que s'enumeren aquí en ordre decreixent de sensibilitat:

  • Els conjunts de dades molt sensibles es posen a disposició segons sigui necessari segons el principi del mínim privilegi. Cada conjunt de dades té un grup separat de lectors i farem un seguiment de l'ús per comptes individuals.
  • Els conjunts de dades de sensibilitat mitjana (pseudònims unidireccionals que utilitzen hashing salat) no contenen informació d'identificació personal (PII) i són accessibles per a un grup més gran d'empleats. Aquest és un bon equilibri entre les preocupacions de privadesa i la utilitat de les dades. Això permet als empleats realitzar tasques d'anàlisi, com ara calcular el nombre d'usuaris que han utilitzat una funció, sense saber qui són els usuaris reals.
  • Conjunts de dades de baixa sensibilitat amb tota la informació d'identificació dels usuaris. Aquest és un bon enfocament des d'una perspectiva de privadesa, però no es pot utilitzar per a l'anàlisi a nivell d'usuari.
  • Els conjunts de dades públiques (publicats fora de Twitter) estan disponibles per a tots els empleats de Twitter.

Pel que fa al registre, hem utilitzat tasques programades per enumerar conjunts de dades de BigQuery i registrar-los amb la capa d'accés a dades (DAL), dipòsit de metadades de Twitter. Els usuaris anotaran conjunts de dades amb informació de privadesa i també especificaran un període de conservació. Pel que fa a la neteja, avaluem el rendiment i el cost de dues opcions: 1. Netejar conjunts de dades a GCS amb eines com Scalding i carregar-los a BigQuery; 2. Ús de declaracions DML de BigQuery. És probable que utilitzem una combinació d'ambdós mètodes per satisfer els requisits de diferents grups i dades.

Funcionalitat del sistema

Com que BigQuery és un servei gestionat, no calia implicar l'equip SRE de Twitter en la gestió de sistemes o les tasques d'escriptori. Va ser fàcil proporcionar més capacitat tant per a l'emmagatzematge com per a la informàtica. Podríem canviar la reserva de ranura creant un bitllet amb el suport de Google. Vam identificar àrees que es podrien millorar, com ara l'assignació d'espais d'autoservei i les millores del tauler de control per al seguiment, i vam enviar aquestes sol·licituds a Google.

Cost

La nostra anàlisi preliminar va mostrar que els costos de consulta de BigQuery i Presto estaven al mateix nivell. Hem comprat espais per fix preu per tenir un cost mensual estable en lloc de pagament sota demanda per TB de dades processades. Aquesta decisió també es va basar en els comentaris dels usuaris que no volien pensar en els costos abans de fer cada sol·licitud.

L'emmagatzematge de dades a BigQuery comportava costos a més dels costos de GCS. Eines com Scalding requereixen conjunts de dades a GCS i per accedir a BigQuery vam haver de carregar els mateixos conjunts de dades en format BigQuery Condensador. Estem treballant en una connexió Scalding amb conjunts de dades de BigQuery que eliminarà la necessitat d'emmagatzemar conjunts de dades tant a GCS com a BigQuery.

En casos rars que requerien consultes poc freqüents de desenes de petabytes, vam decidir que emmagatzemar conjunts de dades a BigQuery no era rendible i vam utilitzar Presto per accedir directament als conjunts de dades a GCS. Per fer-ho, estem analitzant les fonts de dades externes de BigQuery.

Següents passos

Hem vist molt d'interès en BigQuery des del llançament alfa. Estem afegint més conjunts de dades i més ordres a BigQuery. Desenvolupem connectors per a eines d'anàlisi de dades com Scalding per llegir i escriure a l'emmagatzematge de BigQuery. Estem buscant eines com Looker i Apache Zeppelin per crear informes i notes de qualitat empresarial amb conjunts de dades de BigQuery.

La nostra col·laboració amb Google ha estat molt productiva i ens complau continuar i desenvolupar aquesta associació. Hem treballat amb Google per implementar el nostre Seguiment de problemes de socisper enviar consultes directament a Google. Alguns d'ells, com ara el carregador BigQuery Parquet, ja han estat implementats per Google.

Aquestes són algunes de les nostres sol·licituds de funcions d'alta prioritat per a Google:

  • Eines per a la recepció de dades còmoda i suport per al format LZO-Thrift.
  • Segmentació horària
  • Millores de control d'accés, com ara permisos a nivell de taula, fila i columna.
  • BigQuery Fonts de dades externes amb la integració de Hive Metastore i suport per al format LZO-Thrift.
  • Integració millorada del catàleg de dades a la interfície d'usuari de BigQuery
  • Autoservei per a l'assignació de franges i el seguiment.

Conclusió

Democratitzar l'anàlisi de dades, la visualització i l'aprenentatge automàtic d'una manera segura és una prioritat màxima per a l'equip de Data Platform. Vam identificar Google BigQuery i Data Studio com a eines que podrien ajudar a assolir aquest objectiu i l'any passat vam llançar BigQuery Alpha a tota l'empresa.

Hem trobat que les consultes a BigQuery eren senzilles i eficients. Hem utilitzat eines de Google per ingerir i transformar dades per a canalitzacions senzilles, però per a canalitzacions complexes hem hagut de crear el nostre propi marc de flux d'aire. En l'espai de gestió de dades, els serveis d'autenticació, autorització i auditoria de BigQuery satisfan les nostres necessitats. Per gestionar les metadades i mantenir la privadesa, necessitàvem més flexibilitat i havíem de construir els nostres propis sistemes. BigQuery, en ser un servei gestionat, era fàcil d'utilitzar. Els costos de consulta eren similars als de les eines existents. L'emmagatzematge de dades a BigQuery comporta costos a més dels costos de GCS.

En general, BigQuery funciona bé per a l'anàlisi SQL general. Estem veient molt interès en BigQuery i estem treballant per migrar més conjunts de dades, incorporar més equips i crear més canalitzacions amb BigQuery. Twitter utilitza una varietat de dades que requeriran una combinació d'eines com Scalding, Spark, Presto i Druid. Tenim la intenció de continuar reforçant les nostres eines d'anàlisi de dades i oferir una guia clara als nostres usuaris sobre com utilitzar millor les nostres ofertes.

Paraules d'agraïment

M'agradaria donar les gràcies als meus coautors i companys d'equip, Anju Jha i Will Pascucci, per la seva gran col·laboració i el seu treball dur en aquest projecte. També m'agradaria donar les gràcies als enginyers i gestors de diversos equips de Twitter i Google que ens van ajudar a nosaltres i als usuaris de BigQuery a Twitter que ens van oferir comentaris valuosos.

Si estàs interessat a treballar en aquests problemes, consulta el nostre vacants a l'equip de la plataforma de dades.

Qualitat de les dades a DWH - Coherència del magatzem de dades

Font: www.habr.com

Afegeix comentari