Ola, Habr! A inscrición para un novo curso está aberta agora mesmo en OTUS . De cara ao comezo do curso, seguimos compartindo material útil con vós.
Xestión de datos
Strong Data Governance é un principio básico da Enxeñaría de Twitter. Mentres implementamos BigQuery na nosa plataforma, centrámonos no descubrimento de datos, control de acceso, seguridade e privacidade.
Para descubrir e xestionar datos, ampliamos a nosa capa de acceso a datos ) para proporcionar ferramentas tanto para datos locais como de Google Cloud, proporcionando unha única interface e API para os nosos usuarios. Como Google está avanzando cara á dispoñibilidade xeral, incluirémolo nos nosos proxectos para ofrecer aos usuarios funcións como a busca de columnas.
BigQuery facilita compartir e acceder aos datos, pero necesitabamos controlar isto para evitar a exfiltración de datos. Entre outras ferramentas, seleccionamos dúas funcións:
- : función beta para evitar que os usuarios compartan conxuntos de datos de BigQuery con usuarios alleos a Twitter.
- : un control que impide a exfiltración de datos e require que os usuarios accedan a BigQuery desde intervalos de enderezos IP coñecidos.
Implementamos os requisitos de autenticación, autorización e auditoría (AAA) para a seguridade do seguinte xeito:
- Autenticación: utilizamos contas de usuario de GCP para solicitudes ad hoc e contas de servizo para solicitudes de produción.
- Autorización: esiximos que cada conxunto de datos tivese unha conta de servizo propietario e un grupo de lectores.
- Auditoría: exportamos os rexistros de BigQuery stackdriver, que contiñan información detallada de execución de consultas, a un conxunto de datos de BigQuery para facilitar a análise.
Para garantir que os datos persoais dos usuarios de Twitter se manexan correctamente, debemos rexistrar todos os conxuntos de datos de BigQuery, anotar os datos persoais, manter o almacenamento adecuado e eliminar (rascar) os datos que foron eliminados polos usuarios.
Miramos en Google , que utiliza a aprendizaxe automática para clasificar e editar datos sensibles, pero decidiu anotar manualmente o conxunto de datos debido á súa precisión. Pretendemos utilizar a API de prevención de perdas de datos para aumentar a anotación personalizada.
En Twitter, creamos catro categorías de privacidade para conxuntos de datos en BigQuery, listadas aquí en orde decrecente de sensibilidade:
- Os conxuntos de datos moi sensibles están dispoñibles segundo sexa necesario, baseándose no principio do mínimo privilexio. Cada conxunto de datos ten un grupo separado de lectores e faremos un seguimento do uso por contas individuais.
- Os conxuntos de datos de sensibilidade media (pseudónimos unidireccionais que usan hash salgado) non conteñen información de identificación persoal (PII) e son accesibles para un grupo máis grande de empregados. Este é un bo equilibrio entre os problemas de privacidade e a utilidade dos datos. Isto permite aos empregados realizar tarefas de análise, como calcular o número de usuarios que utilizaron unha función, sen saber quen son os usuarios reais.
- Conxuntos de datos de baixa sensibilidade con toda a información de identificación do usuario. Este é un bo enfoque desde a perspectiva da privacidade, pero non se pode usar para a análise a nivel de usuario.
- Os conxuntos de datos públicos (publicados fóra de Twitter) están dispoñibles para todos os empregados de Twitter.
En canto ao rexistro, utilizamos tarefas programadas para enumerar conxuntos de datos de BigQuery e rexistralos na capa de acceso a datos (), repositorio de metadatos de Twitter. Os usuarios anotarán conxuntos de datos con información de privacidade e tamén especificarán un período de conservación. En canto á limpeza, avaliamos o rendemento e o custo de dúas opcións: 1. Limpar conxuntos de datos en GCS mediante ferramentas como Scalding e cargándoos en BigQuery; 2. Usando instrucións DML de BigQuery. É probable que usemos unha combinación de ambos os métodos para satisfacer os requisitos de diferentes grupos e datos.
Funcionalidade do sistema
Dado que BigQuery é un servizo xestionado, non houbo que implicar ao equipo SRE de Twitter na xestión dos sistemas ou nas tarefas de escritorio. Foi doado proporcionar máis capacidade tanto para o almacenamento como para a informática. Poderíamos cambiar a reserva de slot creando un ticket co soporte de Google. Identificamos áreas que se poderían mellorar, como a asignación de espazos de autoservizo e as melloras do panel de control para a supervisión, e enviamos esas solicitudes a Google.
Custa
A nosa análise preliminar mostrou que os custos de consulta para BigQuery e Presto estaban ao mesmo nivel. Compramos slots para prezo para ter un custo mensual estable en lugar de pago por TB de datos procesados. Esta decisión tamén se baseou nos comentarios dos usuarios que non querían pensar nos custos antes de facer cada solicitude.
O almacenamento de datos en BigQuery supuxo custos ademais dos custos de GCS. Ferramentas como Scalding requiren conxuntos de datos en GCS e para acceder a BigQuery tivemos que cargar os mesmos conxuntos de datos en formato BigQuery . Estamos traballando nunha conexión Scalding con conxuntos de datos de BigQuery que eliminará a necesidade de almacenar conxuntos de datos tanto en GCS como en BigQuery.
Para casos raros que requirían consultas pouco frecuentes de decenas de petabytes, decidimos que almacenar conxuntos de datos en BigQuery non era rendible e utilizamos Presto para acceder directamente aos conxuntos de datos en GCS. Para iso, estamos analizando as fontes de datos externas de BigQuery.
Próximos pasos
Vimos moito interese en BigQuery desde o lanzamento alfa. Estamos engadindo máis conxuntos de datos e máis comandos a BigQuery. Desenvolvemos conectores para ferramentas de análise de datos como Scalding para ler e escribir no almacenamento de BigQuery. Estamos analizando ferramentas como Looker e Apache Zeppelin para crear notas e informes de calidade empresarial mediante conxuntos de datos de BigQuery.
A nosa colaboración con Google foi moi produtiva e temos o pracer de continuar e desenvolver esta asociación. Traballamos con Google para implementar o noso para enviar consultas directamente a Google. Algúns deles, como o cargador BigQuery Parquet, xa foron implementados por Google.
Estas son algunhas das nosas solicitudes de funcións de alta prioridade para Google:
- Ferramentas para a recepción de datos cómodo e soporte para o formato LZO-Thrift.
- Segmentación horaria
- Melloras de control de acceso, como permisos a nivel de táboa, fila e columna.
- bigquery coa integración de Hive Metastore e soporte para o formato LZO-Thrift.
- Mellora a integración do catálogo de datos na interface de usuario de BigQuery
- Autoservizo para a asignación e seguimento de slots.
Conclusión
Democratizar a análise de datos, a visualización e a aprendizaxe automática de forma segura é unha prioridade para o equipo de Data Platform. Identificamos Google BigQuery e Data Studio como ferramentas que poderían axudar a acadar este obxectivo e o ano pasado publicamos BigQuery Alpha para toda a empresa.
Consideramos que as consultas en BigQuery son sinxelas e eficientes. Usamos ferramentas de Google para inxerir e transformar datos para canalizacións sinxelas, pero para canalizacións complexas tivemos que construír o noso propio cadro de fluxo de aire. No espazo de xestión de datos, os servizos de autenticación, autorización e auditoría de BigQuery satisfacen as nosas necesidades. Para xestionar os metadatos e manter a privacidade, necesitabamos máis flexibilidade e tivemos que construír os nosos propios sistemas. BigQuery, ao ser un servizo xestionado, foi fácil de usar. Os custos de consulta eran similares aos das ferramentas existentes. O almacenamento de datos en BigQuery implica custos ademais dos custos de GCS.
En xeral, BigQuery funciona ben para a análise xeral de SQL. Estamos a ver moito interese en BigQuery e estamos a traballar para migrar máis conxuntos de datos, crear máis equipos e crear máis canalizacións con BigQuery. Twitter usa unha variedade de datos que requirirán unha combinación de ferramentas como Scalding, Spark, Presto e Druid. Pretendemos seguir reforzando as nosas ferramentas de análise de datos e proporcionar unha orientación clara aos nosos usuarios sobre como utilizar mellor as nosas ofertas.
Palabras de agradecemento
Gustaríame agradecer aos meus coautores e compañeiros de equipo, Anju Jha e Will Pascucci, a súa gran colaboración e o seu traballo duro neste proxecto. Tamén me gustaría agradecer aos enxeñeiros e xestores de varios equipos de Twitter e Google que nos axudaron a nós e aos usuarios de BigQuery en Twitter que proporcionaron comentarios valiosos.
Se estás interesado en traballar nestes problemas, consulta o noso no equipo Data Platform.
Fonte: www.habr.com