Todos os dias, mais de cem milhões de pessoas visitam o Twitter para descobrir e discutir o que está acontecendo no mundo. Cada tweet e todas as outras ações do usuário geram um evento disponível para análise de dados internos no Twitter. Centenas de funcionários estão analisando e visualizando esses dados, e melhorar sua experiência é uma das principais prioridades da equipe da Twitter Data Platform.
Acreditamos que os usuários com uma ampla gama de habilidades técnicas devem ser capazes de localizar dados e ter acesso a ferramentas de análise e visualização baseadas em SQL de bom desempenho. Isso permitiria que todo um novo grupo de usuários com menos preconceito técnico, incluindo analistas de dados e gerentes de produto, extraísse informações dos dados, permitindo-lhes compreender melhor e usar o poder do Twitter. É assim que democratizamos a análise de dados do Twitter.
Como nossas ferramentas e recursos para análise de dados internos foram aprimorados, vimos melhorias no serviço do Twitter. No entanto, ainda há espaço para melhorias. Ferramentas atuais como Scalding requerem experiência de programação. Ferramentas de análise baseadas em SQL como Presto e Vertica têm problemas de desempenho em grande escala. Também temos o problema de espalhar dados por vários sistemas sem acesso constante a eles.
No ano passado, anunciamos uma nova parceria com o Google que está movendo partes de nossa infraestrutura de dados para o Google Cloud Platform (GCP). Concluímos que as ferramentas de Big Data do Google Cloud pode nos ajudar com nossas iniciativas para democratizar a análise, visualização e aprendizado de máquina no Twitter:
- BigQuery : um data warehouse empresarial com um mecanismo SQL baseado em Dremel, conhecido por sua velocidade, simplicidade e aprendizado de máquina .
- Data Studio: uma ferramenta de visualização de big data com recursos de colaboração como o Google Docs.
Neste artigo, você aprenderá sobre 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 em lote e interativas. Discutiremos análises em tempo real no próximo artigo.
Histórico de armazenamento 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 de dados do Twitter foi feita no Vertica e no Hadoop. Para criar jobs do MapReduce Hadoop, usamos o Pig. Em 2012, substituímos o Pig pelo Scalding, que tinha uma API Scala com vantagens como a capacidade de criar pipelines complexos e facilidade de teste. No entanto, para muitos analistas de dados e gerentes de produto que se sentiam mais confortáveis trabalhando com SQL, era uma curva de aprendizado íngreme. Por volta de 2016, começamos a usar Presto como a interface SQL para dados Hadoop. O Spark ofereceu uma interface Python, o que o torna uma boa escolha para mineração de dados ad hoc e aprendizado de máquina.
Desde 2018, usamos as seguintes ferramentas para análise e visualização de dados:
- Queimadura para esteiras 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 às métricas de série temporal
- Tableau, Zeppelin e Pivot para visualização de dados
Descobrimos que, embora essas ferramentas ofereçam recursos muito poderosos, tínhamos dificuldade em disponibilizar esses recursos para um público mais amplo no Twitter. À medida que expandimos nossa plataforma com o Google Cloud, estamos nos concentrando em simplificar nossas ferramentas de análise no Twitter.
Armazém de dados do Google BigQuery
Várias equipes no Twitter já incluíram 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 apoiá-lo na caixa de ferramentas da plataforma de dados. Isso foi difícil por muitos motivos. Precisávamos projetar a infraestrutura para receber de forma confiável grandes quantidades de dados, dar suporte ao gerenciamento de dados em toda a empresa, garantir o controle de acesso adequado e garantir a privacidade do cliente. Também tivemos que criar sistemas para alocação de recursos, monitoramento e estornos para que as equipes pudessem usar o BigQuery com eficácia.
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 tabelas mais usadas com dados pessoais apagados. O BigQuery foi usado por mais de 250 usuários de várias equipes, incluindo engenharia, finanças e marketing. Mais recentemente, eles executaram cerca de 8.000 solicitações, processando cerca de 100 PB por mês, excluindo as solicitações programadas. Depois de receber um feedback muito positivo, decidimos seguir em frente e oferecer o BigQuery como nosso principal recurso para interagir com dados no Twitter.
Aqui está um diagrama da arquitetura de alto nível de nosso 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 “ bq_load ” para carregar dados do GCS no BigQuery. Usamos Presto para consultar conjuntos de dados Parquet ou Thrift-LZO no GCS. BQ Blaster é uma ferramenta de escalonamento interna para carregar conjuntos de dados HDFS Vertica e Thrift-LZO no BigQuery.
Nas seções a seguir, discutiremos nossa abordagem e conhecimento nas áreas de facilidade de uso, desempenho, gerenciamento de dados, integridade do sistema e custo.
Fácil de usar
Descobrimos que é fácil para os usuários começarem a usar o BigQuery, pois ele não exige a instalação de software e os usuários podem acessá-lo por meio de uma interface da web intuitiva. No entanto, os usuários precisavam se familiarizar com alguns dos recursos do GCP e seus conceitos, incluindo recursos como projetos, conjuntos de dados e tabelas. Desenvolvemos tutoriais e tutoriais para ajudar os usuários a começar. Com esse entendimento básico, torna-se fácil para os usuários navegar por conjuntos de dados, visualizar esquemas e dados de tabela, executar consultas simples e visualizar resultados no Data Studio.
Nosso objetivo com a entrada de dados do BigQuery era garantir o carregamento suave de conjuntos de dados HDFS ou GCS com um clique. Nós consideramosCloud Composer (gerenciado pelo Airflow), mas não foi possível 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 organizar as tarefas de carregamento do BigQuery. Embora o DTS fosse rápido de configurar, ele não era flexível para construir pipelines de dependência. Para nosso alfa, criamos nossa própria estrutura Apache Airflow no GCE e estamos preparando-a para produção e a capacidade de oferecer suporte a mais fontes de dados como Vertica.
Para transformar dados em BigQuery, os usuários criam pipelines simples de dados SQL usando consultas programadas. Para pipelines de dependência complexos de vários estágios, planejamos usar nossa própria estrutura do Airflow ou o Cloud Composer junto com o Cloud Dataflow .
atuação
O BigQuery foi projetado para consultas SQL de uso geral que processam grandes quantidades de dados. Não se destina a consultas de baixa latência e alto rendimento exigidas por um banco de dados transacional ou à análise de série de tempo de baixa latência implementada pelo Apache Druid . Para consultas analíticas interativas, nossos usuários esperam um tempo de resposta de menos de um minuto. Tivemos que projetar o uso do BigQuery para atender a essas expectativas. Para garantir um desempenho previsível para nossos usuários, usamos o BigQuery, um recurso disponível para os clientes por uma taxa fixa, que permite aos proprietários de projetos reservar slots mínimos para suas consultas. SlotBigQuery é uma unidade de capacidade de computação necessária para executar consultas SQL.
Analisamos mais de 800 consultas processando cerca de 1 TB de dados cada e encontramos um tempo médio de execução de 30 segundos. Também aprendemos que o desempenho é altamente dependente do uso de nosso slot em vários projetos e tarefas. Tivemos que distinguir claramente entre nossa produção e reservas de slots ad hoc para manter o desempenho para casos de uso de produção e análise interativa. Isso influenciou muito nosso design para 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, e agora convidamos a todos para um webinar ao vivo gratuito, , — (Senior Data Engineer, MaximaTelecom).