¡Hola Habr! La inscripción para una nueva secuencia de cursos está abierta ahora mismo en OTUS . Anticipándonos al inicio del curso, tradicionalmente hemos preparado para usted una traducción de material interesante.
Cada día, más de cien millones de personas visitan Twitter para saber qué está pasando en el mundo y discutirlo. Cada tweet y cualquier otra acción del usuario genera un evento que está disponible para el análisis de datos internos dentro de Twitter. Cientos de empleados analizan y visualizan estos datos, y mejorar su experiencia es una prioridad absoluta para el equipo de Twitter Data Platform.
Creemos que los usuarios con una amplia gama de habilidades técnicas deberían poder descubrir datos y tener acceso a herramientas de visualización y análisis basadas en SQL de buen rendimiento. Esto permitiría a un grupo completamente nuevo de usuarios menos técnicos, incluidos analistas de datos y gerentes de productos, extraer información de los datos, lo que les permitiría comprender y utilizar mejor las capacidades de Twitter. Así democratizamos el análisis de datos en Twitter.
A medida que nuestras herramientas y capacidades de análisis de datos internos mejoraron, vimos cómo Twitter mejoraba. Sin embargo, aún se puede mejorar. Las herramientas actuales como Scalding requieren experiencia en programación. Las herramientas de análisis basadas en SQL, como Presto y Vertica, tienen problemas de rendimiento a escala. También tenemos el problema de distribuir datos entre múltiples sistemas sin acceso constante a ellos.
El año pasado anunciamos , dentro del cual transferimos partes de nuestro en Google Cloud Platform (GCP). Concluimos que las herramientas de Google Cloud puede ayudarnos con nuestras iniciativas para democratizar el análisis, la visualización y el aprendizaje automático en Twitter:
- : almacén de datos empresarial con motor SQL basado , que es famoso por su velocidad, simplicidad y hace frente a .
- Herramienta de visualización de big data con funciones de colaboración similares a las de Google Docs.
En este artículo conocerás nuestra experiencia con estas herramientas: qué hemos hecho, qué hemos aprendido y qué haremos a continuación. Ahora nos centraremos en el análisis interactivo y por lotes. El análisis en tiempo real se analizará en el próximo artículo.
La historia de los almacenes de datos en Twitter
Antes de sumergirnos en BigQuery, vale la pena contar brevemente la historia del almacenamiento de datos de Twitter. En 2011, el análisis de datos de Twitter se realizó en Vertica y Hadoop. Para crear trabajos de MapReduce Hadoop, utilizamos Pig. En 2012, reemplazamos Pig con Scalding, que tenía una API Scala con beneficios como la capacidad de crear canalizaciones complejas y facilidad de prueba. Sin embargo, para muchos analistas de datos y gerentes de productos que se sentían más cómodos trabajando con SQL, fue una curva de aprendizaje bastante pronunciada. Alrededor de 2016, comenzamos a usar Presto como interfaz SQL para datos de Hadoop. Spark ofrecía una interfaz Python, lo que la convierte en una buena opción para la ciencia de datos y el aprendizaje automático ad hoc.
Desde 2018, utilizamos las siguientes herramientas para el análisis y visualización de datos:
- Escaldado para transportadores de producción.
- Scalding y Spark para análisis de datos ad hoc y aprendizaje automático
- Vertica y Presto para análisis SQL ad hoc e interactivo
- Druid para acceso interactivo, exploratorio y de baja latencia a métricas de series temporales
- Tableau, Zeppelin y Pivot para visualización de datos
Descubrimos que, si bien estas herramientas ofrecen funciones muy potentes, hemos tenido dificultades para ponerlas a disposición de una audiencia más amplia en Twitter. Al ampliar nuestra plataforma con Google Cloud, nos centramos en simplificar nuestras herramientas de análisis para todo Twitter.
Almacén de datos BigQuery de Google
Varios equipos de Twitter ya han incorporado BigQuery en algunos de sus procesos de producción. Utilizando su experiencia, comenzamos a evaluar las capacidades de BigQuery para todos los casos de uso de Twitter. Nuestro objetivo era ofrecer BigQuery a toda la empresa y estandarizarlo y respaldarlo dentro del conjunto de herramientas de la plataforma de datos. Esto fue difícil por muchas razones. Necesitábamos desarrollar una infraestructura para incorporar de manera confiable grandes volúmenes de datos, respaldar la gestión de datos en toda la empresa, garantizar controles de acceso adecuados y garantizar la privacidad del cliente. También tuvimos que crear sistemas para la asignación de recursos, el monitoreo y las devoluciones de cargos para que los equipos pudieran usar BigQuery de manera efectiva.
En noviembre de 2018, lanzamos una versión alfa de BigQuery y Data Studio para toda la empresa. Hemos ofrecido a los empleados de Twitter algunas de nuestras hojas de cálculo más utilizadas con datos personales limpios. BigQuery ha sido utilizado por más de 250 usuarios de diversos equipos, incluidos ingeniería, finanzas y marketing. Más recientemente, ejecutaron alrededor de 8 solicitudes y procesaron alrededor de 100 PB por mes, sin contar las solicitudes programadas. Después de recibir comentarios muy positivos, decidimos seguir adelante y ofrecer BigQuery como recurso principal para interactuar con datos en Twitter.
A continuación se muestra un diagrama de la arquitectura de alto nivel de nuestro almacén de datos de Google BigQuery.
Copiamos datos de clústeres de Hadoop locales a Google Cloud Storage (GCS) utilizando la herramienta interna Cloud Replicator. Luego usamos Apache Airflow para crear canalizaciones que usan "» para cargar datos de GCS en BigQuery. Usamos Presto para consultar conjuntos de datos de Parquet o Thrift-LZO en GCS. BQ Blaster es una herramienta de Scalding interna para cargar conjuntos de datos HDFS Vertica y Thrift-LZO en BigQuery.
En las siguientes secciones, analizamos nuestro enfoque y experiencia en las áreas de facilidad de uso, rendimiento, gestión de datos, estado del sistema y costo.
Facilidad de uso
Descubrimos que era fácil para los usuarios comenzar a usar BigQuery porque no requería instalación de software y los usuarios podían acceder a él a través de una interfaz web intuitiva. Sin embargo, los usuarios debían familiarizarse con algunas de las características y conceptos de GCP, incluidos recursos como proyectos, conjuntos de datos y tablas. Hemos desarrollado materiales educativos y tutoriales para ayudar a los usuarios a comenzar. Una vez adquiridos unos conocimientos básicos, a los usuarios les resultó fácil navegar por conjuntos de datos, ver esquemas y datos de tablas, ejecutar consultas sencillas y visualizar resultados en Data Studio.
Nuestro objetivo al ingresar datos en BigQuery era permitir la carga fluida de conjuntos de datos HDFS o GCS con un solo clic. Nosotros consideramos (administrado por Airflow) pero no pudimos usarlo debido a nuestro modelo de seguridad de uso compartido restringido de dominio (más información sobre esto en la sección Administración de datos a continuación). Experimentamos con el uso del Servicio de transferencia de datos (DTS) de Google para organizar cargas de trabajo de BigQuery. Si bien DTS se configuró rápidamente, no fue flexible para crear canalizaciones con dependencias. Para nuestra versión alfa, hemos creado nuestro propio marco Apache Airflow en GCE y lo estamos preparando para ejecutarlo en producción y poder admitir más fuentes de datos como Vertica.
Para transformar datos en BigQuery, los usuarios crean canales de datos SQL simples mediante consultas programadas. Para canalizaciones complejas de varias etapas con dependencias, planeamos utilizar nuestro propio marco Airflow o Cloud Composer junto con .
Rendimiento
BigQuery está diseñado para consultas SQL de uso general que procesan grandes cantidades de datos. No está diseñado para las consultas de baja latencia y alto rendimiento que requiere una base de datos transaccional, ni para el análisis de series de tiempo de baja latencia implementado. . Para consultas de análisis interactivos, nuestros usuarios esperan tiempos de respuesta de menos de un minuto. Tuvimos que diseñar nuestro uso de BigQuery para cumplir con estas expectativas. Para brindar un rendimiento predecible a nuestros usuarios, aprovechamos la funcionalidad de BigQuery, disponible para los clientes mediante una tarifa fija que permite a los propietarios de proyectos reservar espacios mínimos para sus consultas. BigQuery es una unidad de potencia informática necesaria para ejecutar consultas SQL.
Analizamos más de 800 consultas que procesaban aproximadamente 1 TB de datos cada una y descubrimos que el tiempo promedio de ejecución fue de 30 segundos. También aprendimos que el rendimiento depende en gran medida del uso de nuestro espacio en diferentes proyectos y tareas. Tuvimos que delinear claramente nuestra producción y nuestras reservas de espacios ad hoc para mantener el rendimiento para los casos de uso de producción y el análisis en línea. Esto influyó mucho en nuestro diseño para la reserva de espacios y la jerarquía de proyectos.
Hablaremos sobre la gestión de datos, la funcionalidad y el costo de los sistemas en los próximos días en la segunda parte de la traducción, pero ahora invitamos a todos a , durante el cual podrá conocer en detalle el curso y hacer preguntas a nuestro experto, Egor Mateshuk (ingeniero de datos senior, MaximaTelecom).
Lee mas:
Fuente: habr.com