¡Hola, Habr! En este momento, OTUS está aceptando inscripciones para una nueva edición del curso . En la antesala del inicio del curso, seguimos compartiendo material útil con ustedes.
Gestión de datos
Una fuerte gobernanza de datos (Strong Data Governance) es un principio fundamental de Twitter Engineering. A medida que implementamos BigQuery en nuestra plataforma, nos concentramos en la detección de datos, el control de acceso, la seguridad y la privacidad.
Para la detección y gestión de datos, hemos ampliado nuestro nivel de acceso a datos (Data Access Layer — ), para ofrecer herramientas tanto para datos locales como para datos de Google Cloud, proporcionando una interfaz y API única para nuestros usuarios. A medida que Google avanza hacia la disponibilidad pública, lo incluiremos en nuestros proyectos para ofrecer a los usuarios funciones como la búsqueda por columnas.
BigQuery facilita el intercambio y acceso a datos, pero necesitábamos controlar esto hasta cierto punto para prevenir la exfiltración de datos. Entre otras herramientas, elegimos dos funciones:
- : una función beta que prohíbe a los usuarios compartir conjuntos de datos BigQuery con usuarios fuera de Twitter.
- : un elemento de control que previene la exfiltración de datos y requiere que los usuarios accedan a BigQuery desde rangos de direcciones IP conocidas.
Implementamos requisitos de autenticación, autorización y auditoría (AAA) para garantizar la seguridad de la siguiente manera:
- Autenticación: utilizamos cuentas de usuario de GCP para consultas ad hoc y cuentas de servicio para consultas de trabajo.
- Autorización: requerimos que cada conjunto de datos tenga una cuenta de servicio propietaria y un grupo de lectores.
- Auditoría: exportamos los registros de Stackdriver 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 asegurar el tratamiento adecuado de los datos personales de los usuarios de Twitter, debemos registrar todos los conjuntos de datos de BigQuery, anotar los datos personales, mantener un almacenamiento adecuado y eliminar (depurar) los datos que hayan sido eliminados por los usuarios.
Consideramos Google , que utiliza aprendizaje automático para clasificar y editar datos confidenciales, pero decidimos optar por la anotación manual del conjunto de datos debido a la precisión. Planeamos usar la API de Prevención de Pérdida de Datos para complementar la anotación del usuario.
En Twitter, hemos creado cuatro categorías de privacidad para conjuntos de datos en BigQuery, enumeradas aquí en orden descendiente de sensibilidad:
- Los conjuntos de datos de alta sensibilidad están disponibles según sea necesario, con base en el principio de menor privilegio. Cada conjunto de datos tiene un grupo separado de lectores, y vamos a monitorear el uso de cuentas individuales.
- Los conjuntos de datos de sensibilidad media (seudónimos unidireccionales que utilizan hash con sal) no contienen información personal (Información Personalmente Identificable - PII) y están disponibles para un grupo más amplio de empleados. Este es un buen equilibrio entre consideraciones de privacidad y utilidad de los datos. Permite a los empleados realizar tareas de análisis, como calcular la cantidad de usuarios que han utilizado una función, sin saber quiénes son los usuarios reales.
- Los conjuntos de datos de baja sensibilidad contienen toda la información que identifica al usuario. Este es un buen enfoque desde el punto de vista de la 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 (), el almacenamiento de metadatos de Twitter. Los usuarios anotarán los conjuntos de datos con información sobre privacidad, así como indicando el tiempo de retención. En cuanto a la limpieza, estamos evaluando el rendimiento y el costo de dos opciones: 1. Limpiar conjuntos de datos en GCS utilizando herramientas como Scalding y cargarlos en BigQuery; 2. Uso de operadores DML de BigQuery. Probablemente utilizaremos una combinación de ambos métodos para satisfacer las demandas de diversos grupos y datos.
Funcionalidad del sistema
Dado que BigQuery es un servicio gestionado, no fue necesario involucrar al equipo de SRE de Twitter en la gestión de sistemas o en las tareas de guardia. Fue fácil garantizar una gran capacidad tanto para almacenamiento como para cálculos. Podíamos modificar la reserva de slots creando tickets en el soporte de Google. Identificamos que se podrían realizar mejoras, como la autoservicio para la distribución de slots y la mejora del panel de control para la monitorización, y enviamos estas solicitudes a Google.
Costo
Nuestro análisis preliminar mostró que el costo de las consultas para BigQuery y Presto era comparable. Compramos slots a para tener un costo mensual estable en lugar de pagar por TB de datos procesados. Esta decisión también se basó en comentarios de los usuarios que no querían pensar en los costos antes de ejecutar cada consulta.
Almacenar datos en BigQuery generó gastos adicionales además de los gastos en 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 conectar Scalding con conjuntos de datos de BigQuery, lo que eliminará la necesidad de almacenar conjuntos de datos tanto en GCS como en BigQuery.
Para casos raros que requerían consultas infrecuentes 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 ello, estamos considerando las Fuentes de Datos Externas de BigQuery.
Próximos pasos
Hemos notado un gran interés en BigQuery desde el lanzamiento de la versión alfa. Estamos agregando más conjuntos de datos y más equipos en BigQuery. Estamos desarrollando conectores para herramientas de análisis de datos, como Scalding, para leer y escribir en el almacenamiento de BigQuery. Estamos considerando herramientas como Looker y Apache Zeppelin para crear informes corporativos sobre calidad y notas utilizando conjuntos de datos de BigQuery.
La colaboración con Google ha sido muy productiva y estamos entusiasmados por continuar y desarrollar esta asociación. Trabajamos con Google para implementar nuestro propio , para enviar solicitudes directamente a Google. Algunas de ellas, como el cargador de BigQuery Parquet, ya han sido implementadas por Google.
Aquí hay algunas de nuestras solicitudes de funciones de alta prioridad para Google:
- Herramientas para la recepción conveniente de datos y soporte para el formato LZO-Thrift.
- Segmentación por horas
- Mejoras en el control de acceso, como permisos a nivel de tablas, filas y columnas.
- BigQuery con integración y soporte para Hive Metastore para el formato LZO-Thrift.
- Mejor integración del catálogo de datos en la interfaz de usuario de BigQuery
- Autoservicio para distribución y monitoreo de slots.
Conclusión
La democratización del análisis de datos, la visualización y el aprendizaje automático de manera segura es la máxima prioridad para el equipo de Data Platform. Hemos identificado Google BigQuery y Data Studio como herramientas que pueden ayudar a alcanzar este objetivo y lanzamos el año pasado BigQuery Alpha para toda la empresa.
Hemos descubierto que las consultas en BigQuery eran simples y eficientes. Para la recepción y transformación de datos, utilizamos herramientas de Google para tuberías simples, pero para tuberías complejas tuvimos que crear nuestra propia infraestructura de Airflow. En el ámbito de la gestión de datos, los servicios de BigQuery para autenticación, autorización y auditoría satisfacen nuestras necesidades. Para la gestión de metadatos y el cumplimiento de privacidad necesitábamos una mayor flexibilidad y tuvimos que crear nuestros propios sistemas. BigQuery, al ser un servicio administrado, fue fácil de operar. Los costos por consulta fueron similares a las herramientas existentes. El almacenamiento de datos en BigQuery incurrió en gastos además de los costos en GCS.
En general, BigQuery funciona bien para análisis SQL en general. Notamos un gran interés en BigQuery y estamos trabajando para trasladar más conjuntos de datos, atraer a más equipos y crear más tuberías con BigQuery. En Twitter se utilizan diferentes datos que requerirán una combinación de herramientas como Scalding, Spark, Presto y Druid. Planeamos seguir ampliando nuestras herramientas de análisis de datos y proporcionar recomendaciones claras a nuestros usuarios sobre cómo aprovechar mejor nuestras ofertas.
Palabras de agradecimiento
Quiero agradecer a mis coautores y compañeros de equipo, Anju Dja y Will Pascucci, por su magnífica colaboración y duro trabajo en este proyecto. También quiero agradecer a los ingenieros y gerentes de varios equipos en Twitter y Google que nos ayudaron a nosotros y a los usuarios de BigQuery en Twitter, proporcionando valiosos comentarios.
Si está interesado en trabajar en estas tareas, consulte nuestras en el equipo de Data Platform.
Fuente: habr.com
