Leia a primeira parte
Gestão de dados
Forte governança de dados é o princípio principal da engenharia do Twitter. Como estamos implementando o BigQuery em nossa plataforma, estamos nos concentrando na descoberta de dados, controle de acesso, segurança e privacidade.
Para descoberta e gerenciamento de dados, expandimos nossa camada de acesso a dados ( DAL ) para fornecer ferramentas para dados locais e dados do Google Cloud, fornecendo uma única interface e API para nossos usuários. À medida que o Catálogo de dados do Google evolui para a disponibilidade geral, nós o incluiremos em nossos projetos para fornecer aos usuários recursos como pesquisa de coluna.
O BigQuery facilita o compartilhamento e o acesso aos dados, mas precisávamos de algum controle para evitar a exfiltração de dados. Entre outras ferramentas, escolhemos duas funções:
- Compartilhamento restrito de domínio : um recurso beta que impede os usuários de compartilhar conjuntos de dados do BigQuery com usuários fora do Twitter.
- Controles de serviço VPC : um controle que impede a exportação de dados e exige que os usuários acessem o BigQuery a partir de intervalos de IP conhecidos.
Implementamos os requisitos de segurança de autenticação, autorização e auditoria (AAA) 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 trabalho.
- Autorização: exigimos que cada conjunto de dados tivesse uma conta de serviço do proprietário e um grupo de leitores.
- : BigQuery, , BigQuery .
Para garantir que os dados pessoais dos usuários do Twitter sejam tratados de maneira adequada, devemos registrar todos os conjuntos de dados do BigQuery, anotar dados pessoais, manter o armazenamento adequado e excluir (limpar) os dados que foram excluídos pelos usuários.
Revisamos a API Google Cloud Data Loss Prevention , que usa aprendizado de máquina para classificar e editar dados confidenciais, mas optamos pela anotação manual do conjunto de dados devido à precisão. Planejamos usar a API Data Loss Prevention para complementar a anotação personalizada.
No Twitter, criamos quatro categorias de privacidade para conjuntos de dados do BigQuery, listadas aqui em ordem decrescente de sensibilidade:
- . , .
- ( ) (Personally Identifiable Information — PII) . . , , , , .
- , . , .
- ( Twitter) Twitter.
Antes do registro, usamos tarefas agendadas para enumerar conjuntos de dados do BigQuery e registrá-los na camada de acesso a dados ( DAL ), o repositório de metadados do Twitter. Os usuários irão anotar conjuntos de dados com informações de confidencialidade, bem como períodos de retenção. Quanto à depuração, estimamos o desempenho e o custo de duas opções: 1. Depuração de conjuntos de dados no GCS usando ferramentas como Scalding e carregando-os no BigQuery; 2. Usando operadores 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 havia necessidade de envolver a equipe SRE do Twitter no gerenciamento de sistemas ou nas tarefas de plantão. Foi fácil fornecer mais capacidade de armazenamento e computação. Poderíamos alterar as reservas de slots criando tíquetes com o suporte do Google. Descobrimos o que poderia ser melhorado, como autoatendimento para alocação de slots e melhores painéis de monitoramento, e repassamos essas solicitações ao Google.
O custo
Nossa análise preliminar mostrou que o custo das consultas para BigQuery e Presto estavam no mesmo nível. Compramos slots a um preço fixo para ter um custo mensal estável em vez de pagar sob demanda por TB de dados processados. Essa decisão também foi baseada no feedback de usuários que não queriam pensar nos custos antes de fazer cada solicitação.
O armazenamento de dados no BigQuery trouxe custos além dos custos de 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 do capacitor do 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 solicitações infrequentes de dezenas de petabytes, decidimos que armazenar conjuntos de dados no BigQuery não era econômico e usamos o Presto para acessar conjuntos de dados diretamente no GCS. Para fazer isso, estamos analisando as fontes de dados externas do BigQuery.
Próximos passos
Percebemos muito interesse no BigQuery desde o lançamento alfa. Estamos adicionando mais conjuntos de dados e mais comandos ao BigQuery. Estamos desenvolvendo 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 gerar relatórios e notas de qualidade corporativa usando conjuntos de dados do BigQuery.
A colaboração com o Google tem sido muito produtiva e estamos muito satisfeitos em continuar e desenvolver essa parceria. Trabalhamos com o Google para implementar nosso próprio Partner Issue Tracker para enviar solicitações ao Google diretamente. Alguns deles, como o BigQuery Parquet Downloader, já são implementados pelo Google.
Aqui estão algumas de nossas solicitações de recursos de alta prioridade para o Google:
- Ferramentas para fácil ingestão de dados e suporte para o formato LZO-Thrift.
- Segmentação horária
- Melhorias no controle de acesso, como permissões de tabela, linha e coluna.
- Fontes de dados externas do BigQuery com integração Hive Metastore e suporte para o formato LZO-Thrift.
- Integração de catálogo de dados aprimorada na IU 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 maneira segura é uma das principais prioridades da equipe da plataforma de dados. Identificamos o Google BigQuery e o Data Studio como ferramentas que podem nos ajudar a atingir esse objetivo e lançamos o BigQuery Alpha para toda a empresa no ano passado.
Descobrimos que as consultas do BigQuery eram simples e eficazes. Usamos ferramentas do Google para pipelines simples para receber e transformar dados, mas para pipelines complexos, tivemos que criar nossa própria infraestrutura do Airflow. No espaço de gerenciamento de dados, os serviços do BigQuery para autenticação, autorização e auditoria atendem às nossas necessidades. Precisávamos de muita flexibilidade para gerenciar metadados e manter a confidencialidade, e tínhamos que construir nossos próprios sistemas. O BigQuery, sendo um serviço gerenciado, era fácil de usar. O custo das solicitações foi semelhante ao das ferramentas existentes. O armazenamento de dados no BigQuery gerou custos além do custo do GCS.
No geral, o BigQuery tem um bom desempenho para análise SQL geral. Vemos muito interesse no BigQuery e estamos trabalhando para migrar mais conjuntos de dados, envolver mais equipes e construir mais pipelines com o BigQuery. O Twitter usa uma variedade de dados, o que exigirá uma combinação de ferramentas como Scalding, Spark, Presto e Druid. Pretendemos continuar a desenvolver nossas ferramentas de análise de dados e fornecer uma orientação clara aos nossos usuários sobre a melhor forma de usar nossas ofertas.
Palavras de gratidão
Gostaria de agradecer aos meus colaboradores e companheiros de equipe, Anjou Jha e Will Pascucci, por sua grande colaboração e trabalho árduo neste projeto. Também gostaria de agradecer aos engenheiros e gerentes de várias equipes do Twitter e Google que nos ajudaram e aos usuários do Twitter do BigQuery que forneceram feedback valioso.
Se você tem interesse em trabalhar nessas tarefas, confira nossas vagas na equipe de Data Platform.
DWH Data Quality - Consistência de Data Warehouse