Olá, Habr! As inscrições para um novo fluxo de curso estão abertas agora na OTUS . Antecipando o início do curso, continuamos compartilhando material útil com você.
Gestão de dados
A forte governança de dados é um princípio fundamental da engenharia do Twitter. À medida que implementamos o BigQuery em nossa plataforma, nos concentramos na descoberta de dados, controle de acesso, segurança e privacidade.
Para descobrir e gerenciar dados, expandimos nossa camada de acesso a dados para ) para fornecer ferramentas para dados locais e do Google Cloud, fornecendo uma interface e API únicas para nossos usuários. Como o Google está caminhando para a disponibilidade geral, iremos incluí-lo em nossos projetos para fornecer aos usuários recursos como pesquisa em colunas.
O BigQuery facilita o compartilhamento e o acesso aos dados, mas precisávamos ter algum controle sobre isso para evitar a exfiltração de dados. Entre outras ferramentas, selecionamos duas funções:
- : recurso beta para impedir que usuários compartilhem conjuntos de dados do BigQuery com usuários fora do Twitter.
- : um controle que evita a exfiltração de dados e exige que os usuários acessem o BigQuery a partir de intervalos de endereços IP conhecidos.
Implementamos requisitos de autenticação, autorização e auditoria (AAA) para segurança da seguinte forma:
- Autenticação: usamos contas de usuário do GCP para solicitações ad hoc e contas de serviço para solicitações de produção.
- Autorização: exigimos que cada conjunto de dados tivesse uma conta de serviço do proprietário e um grupo de leitores.
- Auditoria: exportamos logs do stackdriver do BigQuery, que continham informações detalhadas de execução de consultas, para um conjunto de dados do BigQuery para facilitar a análise.
Para garantir que os dados pessoais dos usuários do Twitter sejam tratados corretamente, devemos registrar todos os conjuntos de dados do BigQuery, anotar os dados pessoais, manter o armazenamento adequado e excluir (raspar) os dados que foram excluídos pelos usuários.
Nós olhamos para o Google , que usa aprendizado de máquina para classificar e editar dados confidenciais, mas optou por anotar manualmente o conjunto de dados devido à precisão. Planejamos usar a API Data Loss Prevention para aumentar a anotação personalizada.
No Twitter, criamos quatro categorias de privacidade para conjuntos de dados no BigQuery, listadas aqui em ordem decrescente de confidencialidade:
- Conjuntos de dados altamente confidenciais são disponibilizados conforme a necessidade, com base no princípio do menor privilégio. Cada conjunto de dados possui um grupo separado de leitores e rastrearemos o uso por contas individuais.
- Conjuntos de dados de média sensibilidade (pseudônimos unidirecionais usando hash salgado) não contêm informações de identificação pessoal (PII) e são acessíveis a um grupo maior de funcionários. Este é um bom equilíbrio entre preocupações com privacidade e utilidade dos dados. Isso permite que os funcionários realizem tarefas de análise, como calcular o número de usuários que utilizaram um recurso, sem saber quem são os usuários reais.
- Conjuntos de dados de baixa sensibilidade com todas as informações de identificação do usuário. Esta é uma boa abordagem do ponto de vista da privacidade, mas não pode ser usada para análise ao nível do utilizador.
- Conjuntos de dados públicos (divulgados fora do Twitter) estão disponíveis para todos os funcionários do Twitter.
Quanto ao registro, usamos tarefas agendadas para enumerar conjuntos de dados do BigQuery e registrá-los na camada de acesso a dados (), repositório de metadados do Twitter. Os usuários anotarão os conjuntos de dados com informações de privacidade e também especificarão um período de retenção. Quanto à limpeza, avaliamos 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. Usando instruções DML do BigQuery. Provavelmente usaremos uma combinação de ambos os métodos para atender aos requisitos 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 no gerenciamento de sistemas ou em tarefas administrativas. Foi fácil fornecer mais capacidade de armazenamento e computação. Poderíamos alterar a reserva do slot criando um ticket com o suporte do Google. Identificamos áreas que poderiam ser melhoradas, como alocação de slots de autoatendimento e melhorias no painel para monitoramento, e enviamos essas solicitações ao Google.
de custo
Nossa análise preliminar mostrou que os custos de consulta do BigQuery e do Presto estavam no mesmo nível. Compramos slots para preço para ter um custo mensal estável em vez de pagamento por TB de dados processados. Esta decisão também se baseou no feedback dos utilizadores que não queriam pensar nos custos antes de fazer cada pedido.
Armazenar dados no BigQuery trouxe custos além dos custos do GCS. Ferramentas como Scalding exigem conjuntos de dados no GCS, e para acessar o BigQuery tivemos que carregar os mesmos conjuntos de dados no formato BigQuery . Estamos trabalhando em uma conexão Scalding com conjuntos de dados do BigQuery que eliminará a necessidade de armazenar conjuntos de dados no GCS e no BigQuery.
Para casos raros que exigiam consultas pouco frequentes de dezenas de petabytes, decidimos que armazenar conjuntos de dados no BigQuery não era econômico e usamos o Presto para acessar diretamente os conjuntos de dados no GCS. Para fazer isso, estamos analisando fontes de dados externas do BigQuery.
Próximos passos
Vimos muito interesse no BigQuery desde o lançamento alfa. Estamos adicionando mais conjuntos de dados e comandos ao BigQuery. Desenvolvemos conectores para ferramentas de análise de dados, como Scalding, para leitura e gravação no armazenamento do BigQuery. Estamos analisando ferramentas como Looker e Apache Zeppelin para criar relatórios e notas de qualidade empresarial usando conjuntos de dados do BigQuery.
Nossa colaboração com o Google tem sido muito produtiva e temos o prazer de continuar e desenvolver esta parceria. Trabalhamos com o Google para implementar nosso próprio para enviar consultas diretamente ao Google. Alguns deles, como o carregador BigQuery Parquet, já foram implementados pelo Google.
Aqui estão algumas de nossas solicitações de recursos de alta prioridade para o Google:
- Ferramentas para recepção conveniente de dados e suporte para o formato LZO-Thrift.
- Segmentação horária
- Melhorias no controle de acesso, como permissões em nível de tabela, linha e coluna.
- BigQuery com integração Hive Metastore e suporte para o formato LZO-Thrift.
- Integração aprimorada do catálogo de dados na interface do usuário do BigQuery
- Autoatendimento para alocação e monitoramento de slots.
Conclusão
Democratizar a análise de dados, a visualização e o aprendizado de máquina de forma segura é uma prioridade máxima para a equipe da Plataforma de Dados. Identificamos o Google BigQuery e o Data Studio como ferramentas que poderiam ajudar a atingir esse objetivo e lançamos o BigQuery Alpha para toda a empresa no ano passado.
Achamos que as consultas no BigQuery são simples e eficientes. Usamos ferramentas do Google para ingerir e transformar dados para pipelines simples, mas para pipelines complexos tivemos que construir nossa própria estrutura Airflow. No espaço de gerenciamento de dados, os serviços do BigQuery para autenticação, autorização e auditoria atendem às nossas necessidades. Para gerenciar metadados e manter a privacidade, precisávamos de mais flexibilidade e tivemos que construir nossos próprios sistemas. O BigQuery, sendo um serviço gerenciado, era fácil de usar. Os custos de consulta foram semelhantes aos das ferramentas existentes. O armazenamento de dados no BigQuery gera custos além dos custos do GCS.
No geral, o BigQuery funciona bem para análises SQL gerais. Observamos muito interesse no BigQuery e estamos trabalhando para migrar mais conjuntos de dados, contratar mais equipes e criar mais pipelines com o BigQuery. O Twitter usa uma variedade de dados que exigirão uma combinação de ferramentas como Scalding, Spark, Presto e Druid. Pretendemos continuar a fortalecer as nossas ferramentas de análise de dados e fornecer orientações claras aos nossos utilizadores sobre a melhor forma de utilizar as nossas ofertas.
Palavras de gratidão
Gostaria de agradecer aos meus coautores e colegas de equipe, Anju Jha e Will Pascucci, por sua excelente colaboração e trabalho árduo neste projeto. Também gostaria de agradecer aos engenheiros e gerentes de diversas equipes do Twitter e do Google que nos ajudaram e aos usuários do BigQuery no Twitter que forneceram feedback valioso.
Se você estiver interessado em trabalhar nesses problemas, confira nosso na equipe da plataforma de dados.
Fonte: habr.com