Olá, Habr! As inscrições para um novo fluxo de curso estão abertas agora na OTUS . Antecipando o início do curso, tradicionalmente preparamos para você uma tradução de material interessante.
Todos os dias, mais de cem milhões de pessoas visitam o Twitter para descobrir o que está acontecendo no mundo e discutir o assunto. Cada tweet e qualquer outra ação do usuário gera um evento que fica disponível para análise de dados internos do Twitter. Centenas de funcionários analisam e visualizam esses dados, e melhorar sua experiência é uma prioridade para a equipe da Plataforma de Dados do Twitter.
Acreditamos que os usuários com uma ampla gama de habilidades técnicas devem ser capazes de descobrir dados e ter acesso a ferramentas de análise e visualização baseadas em SQL de bom desempenho. Isto permitiria a todo um novo grupo de utilizadores menos técnicos, incluindo analistas de dados e gestores de produtos, extrair insights dos dados, permitindo-lhes compreender e utilizar melhor as capacidades do Twitter. É assim que democratizamos a análise de dados no Twitter.
À medida que nossas ferramentas e recursos internos de análise de dados melhoraram, vimos o Twitter melhorar. No entanto, ainda há espaço para melhorias. Ferramentas atuais como Scalding requerem experiência em programação. Ferramentas de análise baseadas em SQL, como Presto e Vertica, apresentam problemas de desempenho em escala. Também temos o problema de distribuir dados por vários sistemas sem acesso constante a eles.
No ano passado anunciamos , dentro do qual transferimos partes de nossos no Google Cloud Platform (GCP). Concluímos que as ferramentas do Google Cloud pode nos ajudar com nossas iniciativas para democratizar análises, visualização e aprendizado de máquina no Twitter:
- : data warehouse corporativo com mecanismo SQL baseado , que é famoso por sua velocidade, simplicidade e lida com .
- ferramenta de visualização de big data com recursos de colaboração semelhantes aos do Google Docs.
Neste artigo, você conhecerá nossa experiência com essas ferramentas: o que fizemos, o que aprendemos e o que faremos a seguir. Agora vamos nos concentrar em análises interativas e em lote. Discutiremos análises em tempo real no próximo artigo.
História dos armazenamentos de dados do Twitter
Antes de mergulhar no BigQuery, vale a pena recontar brevemente a história do armazenamento de dados do Twitter. Em 2011, a análise dos dados do Twitter foi realizada em Vertica e Hadoop. Usamos Pig para criar trabalhos MapReduce Hadoop. Em 2012, substituímos o Pig pelo Scalding, que tinha uma API Scala com benefícios como a capacidade de criar pipelines complexos e facilidade de testes. No entanto, para muitos analistas de dados e gerentes de produto que se sentiam mais confortáveis trabalhando com SQL, foi uma curva de aprendizado bastante acentuada. Por volta de 2016, começamos a usar o Presto como interface SQL para dados do Hadoop. O Spark ofereceu uma interface Python, o que o torna uma boa escolha para ciência de dados ad hoc e aprendizado de máquina.
Desde 2018, utilizamos as seguintes ferramentas para análise e visualização de dados:
- Escaldagem para transportadores de produção
- Scalding e Spark para análise de dados ad hoc e aprendizado de máquina
- Vertica e Presto para análise SQL ad hoc e interativa
- Druid para acesso pouco interativo, exploratório e de baixa latência a métricas de séries temporais
- Tableau, Zeppelin e Pivot para visualização de dados
Descobrimos que, embora essas ferramentas ofereçam recursos muito poderosos, tivemos dificuldade em disponibilizá-los para um público mais amplo no Twitter. Ao expandir nossa plataforma com o Google Cloud, estamos nos concentrando em simplificar nossas ferramentas de análise para todo o Twitter.
Armazém de dados BigQuery do Google
Várias equipes do Twitter já incorporaram o BigQuery em alguns de seus pipelines de produção. Usando a experiência deles, começamos a avaliar os recursos do BigQuery para todos os casos de uso do Twitter. Nosso objetivo era oferecer o BigQuery para toda a empresa e padronizá-lo e oferecer suporte dentro do conjunto de ferramentas da Data Platform. Isso foi difícil por vários motivos. Precisávamos desenvolver uma infraestrutura para ingerir grandes volumes de dados de forma confiável, dar suporte ao gerenciamento de dados em toda a empresa, garantir controles de acesso adequados e garantir a privacidade do cliente. Também tivemos que criar sistemas de alocação de recursos, monitoramento e estornos para que as equipes pudessem usar o BigQuery de maneira eficaz.
Em novembro de 2018, lançamos uma versão alfa do BigQuery e do Data Studio para toda a empresa. Oferecemos aos funcionários do Twitter algumas de nossas planilhas usadas com mais frequência com dados pessoais limpos. O BigQuery foi usado por mais de 250 usuários de diversas equipes, incluindo engenharia, finanças e marketing. Mais recentemente, eles estavam executando cerca de 8 mil solicitações, processando cerca de 100 PB por mês, sem contar as solicitações agendadas. Depois de receber um feedback muito positivo, decidimos seguir em frente e oferecer o BigQuery como principal recurso para interagir com dados no Twitter.
Aqui está um diagrama de alto nível da nossa arquitetura de data warehouse do Google BigQuery.
Copiamos dados de clusters Hadoop locais para o Google Cloud Storage (GCS) usando a ferramenta interna Cloud Replicator. Em seguida, usamos o Apache Airflow para criar pipelines que usam "» para carregar dados do GCS no BigQuery. Usamos Presto para consultar conjuntos de dados Parquet ou Thrift-LZO no GCS. BQ Blaster é uma ferramenta Scalding interna para carregar conjuntos de dados HDFS Vertica e Thrift-LZO no BigQuery.
Nas seções a seguir, discutiremos nossa abordagem e experiência nas áreas de facilidade de uso, desempenho, gerenciamento de dados, integridade do sistema e custo.
Facilidade de uso
Descobrimos que foi fácil para os usuários começarem a usar o BigQuery porque ele não exigia instalação de software e os usuários podiam acessá-lo por meio de uma interface da Web intuitiva. No entanto, os usuários precisavam se familiarizar com alguns recursos e conceitos do GCP, incluindo recursos como projetos, conjuntos de dados e tabelas. Desenvolvemos materiais educacionais e tutoriais para ajudar os usuários a começar. Com um conhecimento básico adquirido, os usuários acharam fácil navegar em conjuntos de dados, visualizar dados de esquema e tabela, executar consultas simples e visualizar resultados no Data Studio.
Nosso objetivo para a entrada de dados no BigQuery era permitir o carregamento contínuo de conjuntos de dados HDFS ou GCS com um clique. Nós consideramos (gerenciado pelo Airflow), mas não conseguimos usá-lo devido ao nosso modelo de segurança de compartilhamento restrito de domínio (mais sobre isso na seção Gerenciamento de dados abaixo). Experimentamos usar o Google Data Transfer Service (DTS) para orquestrar cargas de trabalho do BigQuery. Embora o DTS tenha sido configurado rapidamente, ele não era flexível para criar pipelines com dependências. Para nossa versão alfa, construímos nossa própria estrutura Apache Airflow no GCE e estamos preparando-a para ser executada em produção e ser capaz de oferecer suporte a mais fontes de dados, como Vertica.
Para transformar dados em BigQuery, os usuários criam pipelines de dados SQL simples usando consultas programadas. Para pipelines complexos de vários estágios com dependências, planejamos usar nossa própria estrutura Airflow ou Cloud Composer junto com .
Desempenho
O BigQuery foi projetado para consultas SQL de uso geral que processam grandes quantidades de dados. Ele não se destina às consultas de baixa latência e alto rendimento exigidas por um banco de dados transacional ou à análise de série temporal de baixa latência implementada . Para consultas analíticas interativas, nossos usuários esperam tempos de resposta inferiores a um minuto. Tivemos que projetar nosso uso do BigQuery para atender a essas expectativas. Para fornecer um desempenho previsível aos nossos usuários, aproveitamos a funcionalidade do BigQuery, disponível aos clientes por uma taxa fixa, que permite aos proprietários do projeto reservar espaços mínimos para suas consultas. BigQuery é uma unidade de poder computacional necessária para executar consultas SQL.
Analisamos mais de 800 consultas processando aproximadamente 1 TB de dados cada e descobrimos que o tempo médio de execução foi de 30 segundos. Aprendemos também que o desempenho é altamente dependente da utilização do nosso slot em diferentes projetos e tarefas. Tivemos que delinear claramente nossas reservas de produção e de slots ad hoc para manter o desempenho em casos de uso de produção e análise on-line. Isso influenciou muito nosso design de reservas de slots e hierarquia de projetos.
Falaremos sobre gerenciamento de dados, funcionalidade e custo de sistemas nos próximos dias na segunda parte da tradução, mas agora convidamos a todos para , durante o qual você poderá conhecer detalhadamente o curso, bem como tirar dúvidas ao nosso especialista - Egor Mateshuk (Engenheiro de Dados Sênior, MaximaTelecom).
Consulte Mais informação:
Fonte: habr.com