Todos los días, más de cien millones de personas visitan Twitter para averiguar y discutir lo que está sucediendo en el mundo. Cada tweet y cualquier otra acción del usuario genera un evento disponible para el análisis de datos internos en Twitter. Cientos de empleados están analizando y visualizando estos datos, y mejorar su experiencia es una de las principales prioridades del equipo de Twitter Data Platform.
Creemos que los usuarios con una amplia gama de habilidades técnicas deberían poder encontrar 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 con menos sesgos técnicos, incluidos analistas de datos y gerentes de productos, extraer información de los datos, lo que les permitiría comprender y usar mejor el poder de Twitter. Así es como democratizamos el análisis de datos de Twitter.
A medida que nuestras herramientas y capacidades para el análisis de datos internos han mejorado, hemos visto mejoras en el servicio de Twitter. 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 gran escala. También tenemos el problema de difundir datos a través de múltiples sistemas sin acceso constante a ellos.
El año pasado, anunciamos una nueva asociación con Google que está moviendo partes de nuestra infraestructura de datos a Google Cloud Platform (GCP). Llegamos a la conclusión de que las herramientas de Big Data de Google Cloud puede ayudarnos con nuestras iniciativas para democratizar el análisis, la visualización y el aprendizaje automático en Twitter:
- BigQuery : un almacén de datos empresarial con un motor SQL basado en Dremel que es conocido por su velocidad, simplicidad y aprendizaje automático .
- Data Studio: una herramienta de visualización de big data con funciones de colaboración como Google Docs.
En este artículo, conocerá nuestra experiencia con estas herramientas: lo que hicimos, lo que aprendimos y lo que haremos a continuación. Ahora nos centraremos en la analítica interactiva y por lotes. Discutiremos la analítica en tiempo real en el próximo artículo.
Historial del almacén de datos de Twitter
Antes de sumergirse en BigQuery, vale la pena volver a 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, usamos Pig. En 2012, reemplazamos Pig con Scalding, que tenía una API de Scala con ventajas como la capacidad de crear tuberías complejas y la facilidad de pruebas. Sin embargo, para muchos analistas de datos y gerentes de producto que se sentían más cómodos trabajando con SQL, fue una curva de aprendizaje empinada. Alrededor de 2016, comenzamos a usar Presto como la interfaz SQL para los datos de Hadoop. Spark ofrecía una interfaz Python, lo que la convierte en una buena opción para la minería de datos ad hoc y el aprendizaje automático.
Desde 2018, hemos utilizado 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 de baja latencia, exploración e interacción baja a métricas de series de tiempo
- Tableau, Zeppelin y Pivot para visualización de datos
Descubrimos que si bien estas herramientas ofrecen capacidades muy poderosas, tuvimos dificultades para poner estas capacidades a disposición de una audiencia más amplia en Twitter. A medida que expandimos nuestra plataforma con Google Cloud, nos enfocamos en simplificar nuestras herramientas de análisis en Twitter.
Almacén de datos de Google BigQuery
Varios equipos en Twitter ya han incluido BigQuery en algunos de sus procesos de producción. Utilizando su experiencia, comenzamos a evaluar las capacidades de BigQuery en todos los casos de uso de Twitter. Nuestro objetivo era ofrecer BigQuery a toda la empresa y estandarizarlo y respaldarlo dentro de la caja de herramientas de la plataforma de datos. Esto fue difícil por muchas razones. Necesitábamos desarrollar una infraestructura para recibir de manera confiable grandes cantidades de datos, respaldar la gestión de datos en toda la empresa, garantizar un control de acceso adecuado y garantizar la privacidad del cliente. También tuvimos que crear sistemas para la asignación de recursos, la supervisión y las devoluciones de cargo para que los equipos puedan usar BigQuery de manera eficaz.
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 borradas de datos personales más utilizados. BigQuery ha sido utilizado por más de 250 usuarios de una variedad de equipos que incluyen ingeniería, finanzas y marketing. Más recientemente, ejecutaron alrededor de 8,000 solicitudes, procesando alrededor de 100 PB por mes, excluidas las solicitudes programadas. Después de recibir comentarios muy positivos, decidimos seguir adelante y ofrecer BigQuery como nuestro 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) mediante la herramienta interna Cloud Replicator. Luego, usamos Apache Airflow para crear canalizaciones que usan " bq_load " 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 de Vertica y Thrift-LZO en BigQuery.
En las siguientes secciones, analizaremos nuestro enfoque y conocimiento en las áreas de facilidad de uso, rendimiento, administración de datos, estado del sistema y costo.
Facilidad de uso
Descubrimos que fue fácil para los usuarios comenzar con BigQuery, ya que no requería la 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 funciones y conceptos de GCP, incluidos recursos como proyectos, conjuntos de datos y tablas. Hemos desarrollado tutoriales y tutoriales para ayudar a los usuarios a comenzar. Con esta comprensión básica, es fácil para los usuarios navegar por conjuntos de datos, ver esquemas y datos de tablas, ejecutar consultas simples y visualizar resultados en Data Studio.
Nuestro objetivo en términos de entrada de datos en BigQuery era garantizar la carga fluida de conjuntos de datos HDFS o GCS con un solo clic. Nosotros consideramosCloud Composer (administrado por Airflow), pero no pudimos usarlo debido a nuestro modelo de seguridad de uso compartido restringido de dominio (más sobre esto en la sección Administración de datos a continuación). Experimentamos con el uso del Servicio de transferencia de datos de Google (DTS) para organizar las tareas de carga de BigQuery. Si bien DTS se configuró rápidamente, no fue flexible para crear canalizaciones de dependencia. Para nuestro alfa, hemos creado nuestro propio marco de Apache Airflow en GCE y lo estamos preparando para la producción y la capacidad de admitir más fuentes de datos como Vertica.
Para transformar los datos en BigQuery, los usuarios crean canalizaciones simples de datos SQL mediante consultas programadas. Para las canalizaciones de dependencia complejas de múltiples etapas, planeamos usar nuestro propio marco de Airflow o Cloud Composer junto con Cloud Dataflow .
Actuación
BigQuery está diseñado para consultas SQL de propósito 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 por Apache Druid . Para consultas analíticas interactivas, nuestros usuarios esperan un tiempo de respuesta de menos de un minuto. Tuvimos que diseñar el uso de BigQuery para cumplir con estas expectativas. Para garantizar un rendimiento predecible para nuestros usuarios, usamos BigQuery, una función disponible para los clientes a una tarifa plana, que permite a los propietarios de proyectos reservar espacios mínimos para sus consultas. EspacioBigQuery 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 encontramos un tiempo de ejecución promedio de 30 segundos. También aprendimos que el rendimiento depende en gran medida del uso de nuestro espacio en varios proyectos y tareas. Tuvimos que distinguir claramente entre nuestra producción y las reservas de tragamonedas ad hoc para mantener el rendimiento para los casos de uso de producción y el análisis interactivo. Esto influyó mucho en nuestro diseño de reservas de espacios y 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, y ahora invitamos a todos a un seminario web en vivo gratuito., , — (Senior Data Engineer, MaximaTelecom).