Olá, Habr! Neste momento, a OTUS está com inscrições abertas para uma nova turma do curso. . À medida que nos aproximamos do início do curso, continuamos a compartilhar materiais úteis com você.
Manipulação de dados
Uma gestão de dados forte (Strong Data Governance) é um princípio fundamental da engenharia do Twitter. À medida que implementamos o BigQuery em nossa plataforma, estamos focando na descoberta de dados, controle de acesso, segurança e privacidade.
Para descoberta e gestão de dados, ampliamos nosso nível de acesso a dados (Data Access Layer — ), para fornecer ferramentas tanto para dados locais quanto para dados do Google Cloud, oferecendo uma interface única e API para nossos usuários. À medida que o Google avança em direção à disponibilidade pública, iremos integrá-lo em nossos projetos para fornecer funcionalidades como pesquisa por colunas.
O BigQuery permite fácil compartilhamento e acesso aos dados, mas precisávamos controlar isso até certo ponto para evitar a exfiltração de dados. Entre outras ferramentas, escolhemos duas funcionalidades:
- : uma funcionalidade beta que proíbe os usuários de compartilhar conjuntos de dados do BigQuery com usuários fora do Twitter.
- : um controle que impede a exfiltração de dados e exige que os usuários acessem o BigQuery a partir de faixas de endereços IP conhecidas.
Implementamos os requisitos de autenticação, autorização e auditoria (AAA) para garantir a segurança da seguinte maneira:
- Autenticação: utilizamos contas de usuários GCP para consultas ad hoc e contas de serviço para consultas de trabalho.
- Autorização: exigimos que cada conjunto de dados tivesse uma conta de serviço proprietária e um grupo de leitores.
- Auditoria: exportamos os logs do stackdriver do BigQuery, que continham informações detalhadas sobre a execução de consultas, para um conjunto de dados do BigQuery para facilitar a análise.
Para garantir o manejo adequado dos dados pessoais dos usuários do Twitter, devemos registrar todos os conjuntos de dados do BigQuery, anotar dados pessoais, manter armazenamento adequado e remover (limpar) os dados que foram excluídos pelos usuários.
Consideramos o API do Google , que utiliza aprendizado de máquina para classificar e editar dados confidenciais, mas decidimos optar pela anotação manual do conjunto de dados devido à precisão. Planejamos usar a API de Prevenção de Perda de Dados para complementar a anotação do usuário.
No Twitter, criamos quatro categorias de privacidade para conjuntos de dados no BigQuery, listadas aqui em ordem decrescente de sensibilidade:
- Conjuntos de dados altamente sensíveis estão disponíveis conforme necessário com base no princípio do menor privilégio. Cada conjunto de dados possui um grupo de leitores separado, e monitoraremos o uso de contas individuais.
- Conjuntos de dados de sensibilidade média (pseudônimos unidimensionais usando hashing salgado) não contêm informações pessoais (Personally Identifiable Information – PII) e estão disponíveis para um maior grupo de funcionários. Esse é um bom equilíbrio entre considerações de privacidade e utilidade dos dados. Permite que os funcionários realizem tarefas analíticas, como calcular o número de usuários que utilizaram uma função, sem saber quem são os usuários reais.
- Conjuntos de dados de baixa sensibilidade que contêm todas as informações que identificam o usuário. Essa é uma boa abordagem do ponto de vista de privacidade, mas não pode ser usada para análise em nível de usuário.
- Conjuntos de dados públicos (lançados fora do Twitter) estão disponíveis para todos os funcionários do Twitter.
Quanto ao registro, utilizamos tarefas agendadas para listar os conjuntos de dados do BigQuery e registrá-los no Data Access Layer (), o repositório de metadados do Twitter. Os usuários anotarão conjuntos de dados com informações sobre privacidade e também indicarão a duração da retenção. Quanto à limpeza, estamos avaliando o desempenho e o custo de duas opções: 1. Limpeza de conjuntos de dados no GCS usando ferramentas como Scalding e carregamento deles no BigQuery; 2. Uso de operadores DML do BigQuery. Provavelmente, usaremos uma combinação de ambos os métodos para atender às necessidades de diferentes grupos e dados.
Funcionalidade do sistema
Como o BigQuery é um serviço gerenciado, não houve necessidade de envolver a equipe de SRE do Twitter na gestão de sistemas ou na execução de deveres de plantão. Foi fácil garantir uma grande capacidade tanto para armazenamento quanto para computação. Poderíamos ajustar a reserva de slots criando tickets no suporte do Google. Identificamos que havia espaço para melhorias, como a autoatendimento para distribuição de slots e o aprimoramento do painel de monitoramento, e repassamos essas solicitações ao Google.
Custo
Nossa análise preliminar mostrou que o custo das consultas para BigQuery e Presto estava no mesmo nível. Compramos slots a para ter um custo mensal estável em vez de pagar por TB de dados processados. Essa decisão também se baseou em feedbacks de usuários que não queriam se preocupar com os custos antes de executar cada consulta.
O armazenamento de dados no BigQuery trouxe custos adicionais além dos custos com GCS. Ferramentas como Scalding requerem que os conjuntos de dados estejam no GCS, e para acessar o BigQuery precisamos carregar os mesmos conjuntos de dados no formato BigQuery . Estamos trabalhando na conexão do Scalding com os conjuntos de dados do BigQuery, o que eliminará a necessidade de armazenar conjuntos de dados tanto no GCS quanto no BigQuery.
Para os casos raros que exigiam consultas pouco frequentes de dezenas de petabytes, decidimos que armazenar conjuntos de dados no BigQuery não era economicamente viável e usamos o Presto para acesso direto aos conjuntos de dados no GCS. Para isso, estamos analisando as Fontes de Dados Externas do BigQuery.
Próximos passos
Notamos um grande interesse pelo BigQuery desde o seu lançamento em alpha. Estamos adicionando mais conjuntos de dados e mais equipes ao BigQuery. Estamos desenvolvendo conectores para ferramentas de análise de dados, como Scalding, para ler e gravar no armazenamento do BigQuery. Estamos considerando ferramentas como Looker e Apache Zeppelin para criar relatórios corporativos sobre qualidade e notas usando conjuntos de dados do BigQuery.
A colaboração com o Google tem sido muito produtiva, e estamos ansiosos para continuar e expandir essa parceria. Trabalhamos com o Google para implementar nosso próprio , para enviar solicitações diretamente ao Google. Algumas delas, como o carregador BigQuery Parquet, já foram implementadas pelo Google.
Aqui estão alguns de nossos pedidos de recursos de alta prioridade para o Google:
- Ferramentas para receber dados facilmente e suporte ao formato LZO-Thrift.
- Segmentação horária
- Melhorias na área de controle de acesso, como permissões em nível de tabela, linha e coluna.
- BigQuery com integração e suporte ao Hive Metastore para o formato LZO-Thrift.
- Integração melhorada do catálogo de dados na interface do usuário do BigQuery
- Self-service para distribuição e monitoramento de slots.
Conclusão
A democratização da análise de dados, visualização e aprendizado de máquina de maneira segura é a principal prioridade da equipe da Data Platform. Identificamos o Google BigQuery e o Data Studio como ferramentas que podem ajudar a alcançar esse objetivo e lançamos o BigQuery Alpha para toda a empresa no ano passado.
Descobrimos que as consultas no BigQuery eram simples e eficazes. Para receber e transformar dados, usamos ferramentas do Google para pipelines simples, mas para pipelines mais complexos, tivemos que criar nossa própria infraestrutura Airflow. Na área de gerenciamento de dados, os serviços do BigQuery para autenticação, autorização e auditoria atendem às nossas necessidades. Para gerenciamento de metadados e conformidade com a privacidade, precisávamos de maior flexibilidade e tivemos que construir nossos próprios sistemas. O BigQuery, sendo um serviço gerenciado, foi fácil de operar. Os custos das consultas foram semelhantes aos das ferramentas existentes. O armazenamento de dados no BigQuery gerou despesas adicionais além dos custos com GCS.
De maneira geral, o BigQuery funciona bem para análises SQL gerais. Estamos notando um grande interesse no BigQuery e estamos trabalhando para transferir mais conjuntos de dados, envolver mais equipes e criar mais pipelines com o BigQuery. O Twitter usa diferentes dados, para os quais será necessária uma combinação de ferramentas como Scalding, Spark, Presto e Druid. Pretendemos continuar expandindo nossas ferramentas de análise de dados e fornecer orientações claras para nossos usuários sobre como utilizar melhor nossas ofertas.
Palavras de agradecimento
Gostaria de agradecer aos meus coautores e colegas de equipe, Anju Dja e Will Pascucci, pela excelente colaboração e duro trabalho neste projeto. Também gostaria de agradecer aos engenheiros e gerentes de várias equipes no Twitter e no Google, que nos ajudaram e aos usuários do BigQuery no Twitter, fornecendo feedback valioso.
Se você estiver interessado em trabalhar nessas tarefas, confira nossas na equipe de Data Platform.
Fonte: habr.com
