Lee la primera parte
Gestión de datos
La gobernanza de datos sólida es el principio principal de la ingeniería de Twitter. A medida que integramos BigQuery en nuestra plataforma, nos centramos en el descubrimiento de datos, el control de acceso, la seguridad y la privacidad.
Para el descubrimiento y la gestión de datos, hemos ampliado nuestra capa de acceso a datos ( DAL ) para proporcionar herramientas tanto para datos locales como para datos de Google Cloud, proporcionando una única interfaz y API para nuestros usuarios. A medida que el Catálogo de datos de Google avanza hacia la disponibilidad general, lo incluiremos en nuestros proyectos para proporcionar a los usuarios funciones como la búsqueda de columnas.
BigQuery facilita compartir y acceder a datos, pero necesitábamos cierto control para evitar la filtración de datos. Entre otras herramientas, hemos elegido dos funciones:
- Uso compartido restringido de dominio : una función beta que evita que los usuarios compartan conjuntos de datos de BigQuery con usuarios fuera de Twitter.
- Controles de servicio de VPC : un control que evita la filtración de datos y requiere que los usuarios accedan a BigQuery desde rangos de IP conocidos.
Hemos implementado los requisitos de seguridad de autenticación, autorización y auditoría (AAA) de la siguiente manera:
- Autenticación: utilizamos cuentas de usuario de GCP para solicitudes ad hoc y cuentas de servicio para solicitudes de trabajo.
- Autorización: Requerimos que cada conjunto de datos tenga una cuenta de servicio de propietario y un grupo de lectores.
- : BigQuery, , BigQuery .
Para asegurarnos de que los datos personales de los usuarios de Twitter se manejen correctamente, debemos registrar todos los conjuntos de datos de BigQuery, anotar los datos personales, mantener un almacenamiento adecuado y eliminar (limpiar) los datos que los usuarios hayan eliminado.
Revisamos la API de prevención de pérdida de datos de Google Cloud , que utiliza el aprendizaje automático para clasificar y editar datos confidenciales, pero optamos por la anotación manual del conjunto de datos debido a la precisión. Planeamos utilizar la API de prevención de pérdida de datos para complementar la anotación personalizada.
En Twitter, hemos creado cuatro categorías de privacidad para los conjuntos de datos de BigQuery, que se enumeran aquí en orden decreciente de sensibilidad:
- . , .
- ( ) (Personally Identifiable Information — PII) . . , , , , .
- , . , .
- ( Twitter) Twitter.
Antes del registro, usamos tareas programadas para enumerar los conjuntos de datos de BigQuery y registrarlos en la capa de acceso a datos ( DAL ), la tienda de metadatos de Twitter. Los usuarios anotarán conjuntos de datos con información confidencial, así como los períodos de retención. En cuanto a la depuración, estimamos el rendimiento y el costo de dos opciones: 1. Limpiar conjuntos de datos en GCS mediante herramientas como Scalding y cargarlos en BigQuery; 2. Uso de operadores DML de BigQuery. Probablemente usaremos una combinación de ambos métodos para cumplir con los requisitos de diferentes grupos y datos.
Funcionalidad del sistema
Debido a que BigQuery es un servicio administrado, no era necesario involucrar al equipo de SRE de Twitter en la administración de sistemas o en las tareas de turno. Fue fácil proporcionar más capacidad tanto para el almacenamiento como para la informática. Podríamos cambiar las reservas de espacios creando tickets en el soporte de Google. Identificamos lo que se podría mejorar, como el autoservicio para la asignación de espacios y mejores paneles de control, y pasamos esas solicitudes a Google.
El costo
Nuestro análisis preliminar mostró que el costo de las consultas para BigQuery y Presto estaban al mismo nivel. Compramos ranuras a un precio fijo para tener un costo mensual estable en lugar de pagar a pedido por TB de datos procesados. Esta decisión también se basó en los comentarios de los usuarios que no querían pensar en los costos antes de realizar cada solicitud.
El almacenamiento de datos en BigQuery generó costos además de los costos de GCS. Herramientas como Scalding requieren conjuntos de datos en GCS y, para acceder a BigQuery, tuvimos que cargar los mismos conjuntos de datos en el formato BigQuery Capacitor .... Estamos trabajando en una conexión Scalding con conjuntos de datos de BigQuery que eliminará la necesidad de almacenar conjuntos de datos tanto en GCS como en BigQuery.
Para casos excepcionales que requerían solicitudes poco frecuentes de decenas de petabytes, decidimos que almacenar conjuntos de datos en BigQuery no era rentable y usamos Presto para acceder directamente a conjuntos de datos en GCS. Para hacer esto, estamos buscando fuentes de datos externas de BigQuery.
Próximos pasos
Hemos notado mucho interés en BigQuery desde el lanzamiento alfa. Agregamos más conjuntos de datos y más comandos a BigQuery. Estamos desarrollando conectores para herramientas de análisis de datos como Scalding para leer y escribir en el almacenamiento de BigQuery. Estamos buscando herramientas como Looker y Apache Zeppelin para generar informes y notas de calidad corporativa utilizando conjuntos de datos de BigQuery.
La asociación con Google ha sido muy productiva y estamos encantados de continuar y desarrollar esta asociación. Trabajamos con Google para implementar nuestro propio Rastreador de problemas de socios para enviar solicitudes a Google directamente. Algunos de ellos, como BigQuery Parquet Downloader, ya están implementados por Google.
Estas son algunas de nuestras solicitudes de funciones de alta prioridad para Google:
- Herramientas para una fácil ingestión de datos y compatibilidad con el formato LZO-Thrift.
- Segmentación horaria
- Mejoras en el control de acceso, como permisos a nivel de tabla, fila y columna.
- Fuentes de datos externas de BigQuery con integración de Hive Metastore y compatibilidad con el formato LZO-Thrift.
- Integración mejorada del catálogo de datos en la IU de BigQuery
- Autoservicio para asignación y seguimiento de slots.
Conclusión
Democratizar el análisis, la visualización y el aprendizaje automático de datos de forma segura es una de las principales prioridades del equipo de Data Platform. Identificamos Google BigQuery y Data Studio como herramientas que pueden ayudarnos a lograr este objetivo, y el año pasado lanzamos BigQuery Alpha para toda la empresa.
Descubrimos que las consultas de BigQuery eran simples y efectivas. Para recibir y transformar datos, usamos herramientas de Google para canalizaciones simples, pero para canalizaciones complejas, tuvimos que crear nuestra propia infraestructura Airflow. En el espacio de administración de datos, los servicios de BigQuery para autenticación, autorización y auditoría satisfacen nuestras necesidades. Necesitábamos mucha flexibilidad para administrar los metadatos y mantener la confidencialidad, y teníamos que construir nuestros propios sistemas. BigQuery, al ser un servicio administrado, fue fácil de usar. El costo de las solicitudes fue similar a las herramientas existentes. El almacenamiento de datos en BigQuery ha generado costos además del costo de GCS.
En general, BigQuery funciona bien para el análisis general de SQL. Vemos mucho interés en BigQuery y estamos trabajando para migrar más conjuntos de datos, involucrar a más equipos y crear más canalizaciones con BigQuery. Twitter utiliza una variedad de datos, que requerirán una combinación de herramientas como Scalding, Spark, Presto y Druid. Tenemos la intención de continuar desarrollando nuestras herramientas de análisis de datos y brindar una guía clara a nuestros usuarios sobre la mejor manera de utilizar nuestras ofertas.
Palabras de agradecimiento
Me gustaría agradecer a mis colaboradores y compañeros de equipo, Anjou Jha y Will Pascucci, por su gran colaboración y arduo trabajo en este proyecto. También me gustaría agradecer a los ingenieros y gerentes de varios equipos en Twitter y Google que nos ayudaron y a los usuarios de BigQuery Twitter que brindaron comentarios valiosos.
Si está interesado en trabajar en estas tareas, consulte nuestras vacantes en el equipo de Plataforma de datos.
Calidad de datos DWH: coherencia del almacén de datos