¡Hola Habr! La inscripción para una nueva secuencia de cursos está abierta ahora mismo en OTUS . Anticipándonos al inicio del curso, seguimos compartiendo contigo material útil.
Gestión de datos
Una gobernanza de datos sólida es un principio fundamental de la ingeniería de Twitter. A medida que implementamos BigQuery en nuestra plataforma, nos centramos en el descubrimiento de datos, el control de acceso, la seguridad y la privacidad.
Para descubrir y administrar datos, hemos ampliado nuestra capa de acceso a datos para ) para proporcionar herramientas para datos locales y de Google Cloud, proporcionando una única interfaz y API para nuestros usuarios. Como Google está avanzando hacia la disponibilidad general, lo incluiremos en nuestros proyectos para proporcionar a los usuarios funciones como la búsqueda de columnas.
BigQuery facilita compartir datos y acceder a ellos, pero necesitábamos tener cierto control sobre esto para evitar la filtración de datos. Entre otras herramientas, seleccionamos dos funciones:
- : Función beta para evitar que los usuarios compartan conjuntos de datos de BigQuery con usuarios fuera de Twitter.
- : un control que evita la filtración de datos y requiere que los usuarios accedan a BigQuery desde rangos de direcciones IP conocidos.
Hemos implementado requisitos de autenticación, autorización y auditoría (AAA) para la seguridad de la siguiente manera:
- Autenticación: utilizamos cuentas de usuario de GCP para solicitudes ad hoc y cuentas de servicio para solicitudes de producción.
- Autorización: requerimos que cada conjunto de datos tenga una cuenta de servicio de propietario y un grupo de lectores.
- Auditoría: exportamos registros del controlador de pila de BigQuery, que contenían información detallada sobre la ejecución de consultas, a un conjunto de datos de BigQuery para facilitar el análisis.
Para garantizar que los datos personales de los usuarios de Twitter se manejen correctamente, debemos registrar todos los conjuntos de datos de BigQuery, anotar datos personales, mantener un almacenamiento adecuado y eliminar (extraer) los datos que hayan sido eliminados por los usuarios.
Miramos en Google , que utiliza aprendizaje automático para clasificar y editar datos confidenciales, pero decidió anotar manualmente el conjunto de datos debido a su precisión. Planeamos utilizar la API de prevención de pérdida de datos para aumentar la anotación personalizada.
En Twitter, hemos creado cuatro categorías de privacidad para conjuntos de datos en BigQuery, enumeradas aquí en orden descendente de sensibilidad:
- Los conjuntos de datos altamente confidenciales se ponen a disposición según sea necesario según el principio de privilegio mínimo. Cada conjunto de datos tiene un grupo separado de lectores y realizaremos un seguimiento del uso por cuentas individuales.
- Los conjuntos de datos de sensibilidad media (seudónimos unidireccionales que utilizan hash salado) no contienen información de identificación personal (PII) y son accesibles para un grupo más grande de empleados. Este es un buen equilibrio entre las preocupaciones por la privacidad y la utilidad de los datos. Esto permite a los empleados realizar tareas de análisis, como calcular la cantidad de usuarios que utilizaron una función, sin saber quiénes son los usuarios reales.
- Conjuntos de datos de baja sensibilidad con toda la información de identificación del usuario. Este es un buen enfoque desde una perspectiva de privacidad, pero no se puede utilizar para análisis a nivel de usuario.
- Los conjuntos de datos públicos (publicados fuera de Twitter) están disponibles para todos los empleados de Twitter.
En cuanto al registro, utilizamos tareas programadas para enumerar conjuntos de datos de BigQuery y registrarlos en la capa de acceso a datos (), repositorio de metadatos de Twitter. Los usuarios anotarán conjuntos de datos con información de privacidad y también especificarán un período de retención. En cuanto a la limpieza, evaluamos el rendimiento y coste de dos opciones: 1. Limpiar conjuntos de datos en GCS usando herramientas como Scalding y cargarlos en BigQuery; 2. Usar declaraciones DML de BigQuery. Probablemente utilicemos 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 hubo necesidad de involucrar al equipo SRE de Twitter en la administración de sistemas o tareas administrativas. Fue fácil proporcionar más capacidad tanto para el almacenamiento como para la informática. Podríamos cambiar la reserva de franjas horarias creando un ticket con el soporte de Google. Identificamos áreas que podrían mejorarse, como la asignación de espacios de autoservicio y mejoras en el panel de control para el seguimiento, y enviamos esas solicitudes a Google.
costo de
Nuestro análisis preliminar mostró que los costos de consulta para BigQuery y Presto estaban al mismo nivel. Compramos espacios para precio para tener un costo mensual estable en lugar de pago 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 formato BigQuery. . Estamos trabajando en una conexión Scalding a 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 consultas poco frecuentes de decenas de petabytes, decidimos que almacenar conjuntos de datos en BigQuery no era rentable y utilizamos Presto para acceder directamente a los conjuntos de datos en GCS. Para hacer esto, analizamos las fuentes de datos externas de BigQuery.
Próximos pasos
Hemos visto mucho interés en BigQuery desde la versión alfa. Estamos agregando más conjuntos de datos y más comandos a BigQuery. Desarrollamos conectores para herramientas de análisis de datos como Scalding para leer y escribir en el almacenamiento de BigQuery. Estamos analizando herramientas como Looker y Apache Zeppelin para crear informes y notas de calidad empresarial utilizando conjuntos de datos de BigQuery.
Nuestra colaboración con Google ha sido muy productiva y nos complace continuar y desarrollar esta asociación. Trabajamos con Google para implementar el nuestro para enviar consultas directamente a Google. Algunos de ellos, como el cargador BigQuery Parquet, ya han sido implementados por Google.
Estas son algunas de nuestras solicitudes de funciones de alta prioridad para Google:
- Herramientas para una cómoda recepció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.
- BigQuery con integración de Hive Metastore y soporte para el formato LZO-Thrift.
- Integración mejorada del catálogo de datos en la interfaz de usuario de BigQuery
- Autoservicio para asignación y seguimiento de slots.
Conclusión
Democratizar el análisis de datos, la visualización y el aprendizaje automático de forma segura es una de las principales prioridades para el equipo de Data Platform. Identificamos Google BigQuery y Data Studio como herramientas que podrían ayudar a lograr este objetivo y lanzamos BigQuery Alpha en toda la empresa el año pasado.
Descubrimos que las consultas en BigQuery son simples y eficientes. Usamos herramientas de Google para ingerir y transformar datos para canalizaciones simples, pero para canalizaciones complejas tuvimos que crear nuestro propio marco Airflow. En el espacio de gestión de datos, los servicios de BigQuery para autenticación, autorización y auditoría satisfacen nuestras necesidades. Para gestionar los metadatos y mantener la privacidad, necesitábamos más flexibilidad y tuvimos que crear nuestros propios sistemas. BigQuery, al ser un servicio administrado, era fácil de usar. Los costos de consulta eran similares a los de las herramientas existentes. El almacenamiento de datos en BigQuery genera costos además de los costos de GCS.
En general, BigQuery funciona bien para el análisis SQL general. Estamos viendo mucho interés en BigQuery y estamos trabajando para migrar más conjuntos de datos, incorporar 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 fortaleciendo nuestras herramientas de análisis de datos y brindar orientación clara a nuestros usuarios sobre cómo utilizar mejor nuestras ofertas.
Palabras de agradecimiento
Me gustaría agradecer a mis coautores y compañeros de equipo, Anju 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 de Twitter y Google que nos ayudaron y a los usuarios de BigQuery en Twitter que brindaron comentarios valiosos.
Si está interesado en trabajar en estos problemas, consulte nuestro en el equipo de Plataforma de Datos.
Fuente: habr.com