Ola, Habr! A inscrición para un novo curso está aberta agora mesmo en OTUS . Antes do comezo do curso, tradicionalmente preparámosche unha tradución de material interesante.
Cada día, máis de cen millóns de persoas visitan Twitter para coñecer o que está a suceder no mundo e discutilo. Cada chío e calquera outra acción do usuario xera un evento que está dispoñible para a análise de datos internos de Twitter. Centos de empregados analizan e visualizan estes datos, e mellorar a súa experiencia é unha prioridade para o equipo de Twitter Data Platform.
Cremos que os usuarios cunha ampla gama de habilidades técnicas deberían poder descubrir datos e ter acceso a ferramentas de análise e visualización baseadas en SQL de bo rendemento. Isto permitiría a un grupo totalmente novo de usuarios menos técnicos, incluídos analistas de datos e xestores de produtos, extraer información dos datos, permitíndolles comprender e utilizar mellor as capacidades de Twitter. Así é como democratizamos a análise de datos en Twitter.
A medida que melloraron as nosas ferramentas e as capacidades internas de análise de datos, vimos que Twitter melloraba. Non obstante, aínda hai marxe de mellora. As ferramentas actuais como Scalding requiren experiencia en programación. As ferramentas de análise baseadas en SQL como Presto e Vertica teñen problemas de rendemento a escala. Tamén temos o problema de distribuír datos entre varios sistemas sen acceso constante a eles.
O ano pasado anunciamos , dentro do cal transferimos partes do noso en Google Cloud Platform (GCP). Concluímos que as ferramentas de Google Cloud pode axudarnos coas nosas iniciativas para democratizar a análise, a visualización e a aprendizaxe automática en Twitter:
- : almacén de datos empresarial con motor SQL baseado , que é famoso pola súa velocidade, sinxeleza e manexa .
- ferramenta de visualización de big data con funcións de colaboración similares a Google Docs.
Neste artigo, coñecerás a nosa experiencia con estas ferramentas: o que fixemos, o que aprendemos e o que faremos a continuación. Agora centrarémonos nas análises interactivas e por lotes. Discutaremos as análises en tempo real no seguinte artigo.
Historia das tendas de datos de Twitter
Antes de mergullarse en BigQuery, paga a pena contar brevemente a historia do almacenamento de datos de Twitter. En 2011, realizouse a análise de datos de Twitter en Vertica e Hadoop. Usamos Pig para crear traballos de MapReduce Hadoop. En 2012, substituímos Pig por Scalding, que tiña unha API de Scala con vantaxes como a capacidade de crear canalizacións complexas e a facilidade de proba. Non obstante, para moitos analistas de datos e xestores de produtos que estaban máis cómodos traballando con SQL, foi unha curva de aprendizaxe bastante pronunciada. Ao redor de 2016, comezamos a usar Presto como interface SQL para os datos de Hadoop. Spark ofreceu unha interface Python, o que a converte nunha boa opción para a ciencia de datos ad hoc e a aprendizaxe automática.
Desde 2018, utilizamos as seguintes ferramentas para a análise e visualización de datos:
- Escaldado para transportadores de produción
- Scalding e Spark para análise de datos ad hoc e aprendizaxe automática
- Vertica e Presto para análise SQL ad hoc e interactiva
- Druid para un acceso interactivo, exploratorio e de baixa latencia ás métricas de series temporais
- Tableau, Zeppelin e Pivot para a visualización de datos
Descubrimos que aínda que estas ferramentas ofrecen capacidades moi potentes, tivemos dificultades para poñer estas capacidades a disposición dun público máis amplo en Twitter. Ao ampliar a nosa plataforma con Google Cloud, centrámonos en simplificar as nosas ferramentas de análise para todo Twitter.
BigQuery Data Warehouse de Google
Varios equipos de Twitter xa incorporaron BigQuery nalgúns dos seus pipelines de produción. Usando a súa experiencia, comezamos a avaliar as capacidades de BigQuery para todos os casos de uso de Twitter. O noso obxectivo era ofrecer BigQuery a toda a empresa e estandarizalo e apoialo dentro do conxunto de ferramentas Data Platform. Isto foi difícil por moitas razóns. Necesitabamos desenvolver unha infraestrutura para inxerir de forma fiable grandes volumes de datos, apoiar a xestión de datos en toda a empresa, garantir os controis de acceso adecuados e garantir a privacidade dos clientes. Tamén tivemos que crear sistemas de asignación de recursos, seguimento e contracargos para que os equipos puidesen utilizar BigQuery de forma eficaz.
En novembro de 2018, publicamos unha versión alfa para toda a empresa de BigQuery e Data Studio. Ofrecémoslles aos empregados de Twitter algunhas das nosas follas de cálculo de uso máis frecuente con datos persoais limpos. BigQuery foi utilizado por máis de 250 usuarios de diversos equipos, incluíndo enxeñería, finanzas e mercadotecnia. Máis recentemente, executaron preto de 8k solicitudes, procesando preto de 100 PB ao mes, sen contar as solicitudes programadas. Despois de recibir comentarios moi positivos, decidimos seguir adiante e ofrecer BigQuery como recurso principal para interactuar cos datos en Twitter.
Aquí tes un diagrama de alto nivel da nosa arquitectura de almacén de datos de Google BigQuery.
Copiamos datos de clústeres de Hadoop locais a Google Cloud Storage (GCS) mediante a ferramenta interna Cloud Replicator. Despois usamos Apache Airflow para crear canalizacións que usen "» para cargar datos de GCS en BigQuery. Usamos Presto para consultar conxuntos de datos Parquet ou Thrift-LZO en GCS. BQ Blaster é unha ferramenta interna de Scalding para cargar conxuntos de datos HDFS Vertica e Thrift-LZO en BigQuery.
Nas seguintes seccións, comentamos o noso enfoque e experiencia nas áreas de facilidade de uso, rendemento, xestión de datos, saúde do sistema e custo.
Facilidade de uso
Descubrimos que era doado para os usuarios comezar con BigQuery porque non precisaba instalación de software e os usuarios podían acceder a el a través dunha interface web intuitiva. Non obstante, os usuarios necesitaban familiarizarse con algunhas das funcións e conceptos de GCP, incluídos recursos como proxectos, conxuntos de datos e táboas. Elaboramos materiais educativos e titoriais para axudar aos usuarios a comezar. Cos coñecementos básicos adquiridos, aos usuarios resultou fácil navegar polos conxuntos de datos, ver os datos de esquemas e táboas, realizar consultas sinxelas e visualizar os resultados en Data Studio.
O noso obxectivo para a entrada de datos en BigQuery era permitir a carga fluida de conxuntos de datos HDFS ou GCS cun só clic. Consideramos (xestionado por Airflow) pero non puidemos usalo debido ao noso modelo de seguranza de uso compartido de dominios restrinxidos (máis sobre isto na sección Xestión de datos a continuación). Experimentamos co servizo de transferencia de datos de Google (DTS) para organizar as cargas de traballo de BigQuery. Aínda que DTS foi rápido de configurar, non foi flexible para construír canalizacións con dependencias. Para a nosa versión alfa, creamos o noso propio marco Apache Airflow en GCE e preparámolo para executalo en produción e poder admitir máis fontes de datos como Vertica.
Para transformar os datos en BigQuery, os usuarios crean canalizacións de datos SQL sinxelas mediante consultas programadas. Para canalizacións complexas de varias etapas con dependencias, pensamos usar o noso propio marco Airflow ou Cloud Composer xunto con .
Produtividade
BigQuery está deseñado para consultas SQL de propósito xeral que procesan grandes cantidades de datos. Non está pensado para as consultas de baixa latencia e alto rendemento requiridas por unha base de datos transaccional nin para a análise de series temporales de baixa latencia implementada. . Para consultas de análise interactiva, os nosos usuarios esperan tempos de resposta inferiores a un minuto. Tivemos que deseñar o noso uso de BigQuery para cumprir estas expectativas. Para ofrecer un rendemento previsible aos nosos usuarios, aproveitamos a funcionalidade de BigQuery, dispoñible para os clientes cunha tarifa plana que permite aos propietarios dos proxectos reservar espazos mínimos para as súas consultas. BigQuery é unha unidade de potencia informática necesaria para executar consultas SQL.
Analizamos máis de 800 consultas que procesaban aproximadamente 1 TB de datos cada unha e descubrimos que o tempo medio de execución era de 30 segundos. Tamén aprendemos que o rendemento depende moito do uso do noso slot en diferentes proxectos e tarefas. Tivemos que delimitar claramente as nosas reservas de slots de produción e ad hoc para manter o rendemento dos casos de uso da produción e da análise en liña. Isto influíu moito no noso deseño para as reservas de slots e a xerarquía de proxectos.
Sobre a xestión de datos, a funcionalidade e o custo dos sistemas falaremos nos próximos días na segunda parte da tradución, pero agora convidamos a todos a que , durante o cal poderás aprender en detalle sobre o curso, así como facer preguntas ao noso experto - Egor Mateshuk (Enxeñeiro de datos senior, MaximaTelecom).
Le máis:
Fonte: www.habr.com