Привет, Хабр! Прямо сейчас в OTUS открыт набор на новый поток курса «Data Engineer». В преддверии старта курса продолжаем делиться с вами полезным материалом.
Читать первую часть
Сильное управление данными (Strong Data Governance) — основной принцип Twitter Engineering. Поскольку мы внедряем BigQuery в нашу платформу, мы концентрируемся на обнаружении данных, контроле доступа, безопасности и конфиденциальности.
Для обнаружения данных и управления ими мы расширили наш уровень доступа к данным (Data Access Layer — DAL), чтобы предоставлять инструменты как для локальных данных, так и для данных Google Cloud, предоставляя единый интерфейс и API для наших пользователей. По мере того как Google Data Catalog движется в сторону общедоступности, мы включим его в наши проекты, чтобы предоставить пользователям такие функции, как поиск по колонкам.
BigQuery позволяет легко обмениваться данными и получать к ним доступ, но нам нужно было до некоторой степени контролировать это, чтобы предотвратить эксфильтрацию данных. Среди других инструментов мы выбрали две функции:
Мы реализовали требования аутентификации, авторизации и аудита (AAA) для обеспечения безопасности следующим образом:
Чтобы обеспечить надлежащую обработку личных данных пользователей Twitter, мы должны зарегистрировать все наборы данных BigQuery, аннотировать личные данные, поддерживать надлежащее хранение и удалять (вычищать) данные, которые были удалены пользователями.
Мы рассматривали Google Cloud Data Loss Prevention API, который использует машинное обучение для классификации и редактирования конфиденциальных данных, но приняли решение в пользу ручной аннотации набора данных из-за точности. Мы планируем использовать Data Loss Prevention API, чтобы дополнить пользовательскую аннотацию.
В Twitter мы создали четыре категории конфиденциальности для наборов данных в BigQuery, перечисленные здесь в порядке убывания чувствительности:
Что до регистрации, мы использовали запланированные задачи для перечисления наборов данных BigQuery и регистрации их в Data Access Layer (DAL), хранилище метаданных Twitter. Пользователи будут аннотировать наборы данных информацией о конфиденциальности, а также указывать срок хранения. Что до очистки, мы оцениваем производительность и стоимость двух вариантов: 1. Очистка наборов данных в GCS с помощью таких инструментов, как Scalding, и загрузка их в BigQuery; 2. Использование операторов BigQuery DML. Мы, вероятно, будем использовать комбинацию обоих методов для удовлетворения требований различных групп и данных.
Поскольку BigQuery является управляемой службой, не было необходимости подключать SRE команду Twitter к управлению системами или выполнению дежурных обязанностей. Было легко обеспечить большую емкость как для хранения, так и для вычислений. Мы могли бы изменить резервирование слотов, создавая тикеты в поддержке Google. Мы определили, что можно было бы улучшить, например, самообслуживание для распределения слотов и улучшение дашборда для мониторинга, и передали эти запросы в Google.
Наш предварительный анализ показал, что стоимость запросов для BigQuery и Presto была на одном уровне. Мы приобрели слоты по фиксированной цене, чтобы иметь стабильную ежемесячную стоимость вместо оплаты по требованию за ТБ обработанных данных. Это решение также было основано на отзывах пользователей, которые не хотели думать о затратах перед выполнением каждого запроса.
Хранение данных в BigQuery принесло расходы в дополнение к затратам на GCS. Такие инструменты, как Scalding, требуют наличия наборов данных в GCS, а для доступа к BigQuery нам пришлось загрузить те же наборы данных в формат BigQuery Capacitor. Мы работаем над соединением Scalding с наборами данных BigQuery, которое устранит необходимость хранения наборов данных как в GCS, так и в BigQuery.
Для редких случаев, которые требовали нечастых запросов на десятки петабайт, мы решили, что хранение наборов данных в BigQuery не является экономически эффективным, и использовали Presto для прямого доступа к наборам данных в GCS. Для этого мы присматриваемся к BigQuery External Data Sources.
Мы отметили большой интерес к BigQuery с момента выпуска альфы. Мы добавляем больше наборов данных и больше команд в BigQuery. Мы разрабатываем коннекторы для инструментов анализа данных, таких как Scalding, для чтения и записи в хранилище BigQuery. Мы рассматриваем такие инструменты, как Looker и Apache Zeppelin, для создания корпоративных отчетов о качестве и заметок с использованием наборов данных BigQuery.
Сотрудничество с Google было очень продуктивным, и мы рады продолжить и развивать это партнерство. Мы работали с Google, чтобы внедрить наш собственный Partner Issue Tracker, чтобы напрямую отправлять запросы в Google. Некоторые из них, такие как загрузчик BigQuery Parquet, уже реализованы Google.
Вот некоторые из наших высокоприоритетных запросов фич для Google:
Демократизация анализа данных, визуализации и машинного обучения безопасным способом является высшим приоритетом для команды Data Platform. Мы определили Google BigQuery и Data Studio как инструменты, которые могут помочь в достижении этой цели, и зарелизили в прошлом году BigQuery Alpha для всей компании.
Мы обнаружили, что запросы в BigQuery были простыми и эффективными. Для приема и преобразования данных мы использовали инструменты Google для простых конвейеров, но для сложных конвейеров нам пришлось создать собственную инфраструктуру Airflow. В области управления данными службы BigQuery для аутентификации, авторизации и аудита удовлетворяют наши потребности. Для управления метаданными и соблюдения конфиденциальности нам требовалась большая гибкость и нам приходилось создавать собственные системы. BigQuery, будучи управляемым сервисом, был прост в эксплуатации. Затраты на запросы были аналогичны существующим инструментам. Хранение данных в BigQuery понесло расходы в дополнение к затратам на GCS.
В целом, BigQuery хорошо работает для общего SQL анализа. Мы отмечаем большой интерес к BigQuery, и мы работаем над переносом большего количества наборов данных, привлечением большего количества команд и созданием большего количества конвейеров с BigQuery. В Twitter используются разные данные, для которых потребуется сочетание таких инструментов, как Scalding, Spark, Presto и Druid. Мы намерены продолжать наращивать наши инструменты анализа данных и предоставлять четкие рекомендации нашим пользователям о том, как наилучшим образом использовать наши предложения.
Я хотел бы поблагодарить моих соавторов и товарищей по команде, Анжу Джа и Уилла Паскуччи, за их великолепное сотрудничество и тяжелую работу на этом проекте. Я также хотел бы поблагодарить инженеров и менеджеров из нескольких команд в Twitter и Google, которые помогли нам и пользователям BigQuery в Twitter, предоставившим ценную обратную связь.
Если вы заинтересованы в работе над этими задачами, ознакомьтесь с нашими вакансиями в команде Data Platform.
Качество данных в DWH — консистентность хранилища данных
Читать первую часть
Управление данными
Сильное управление данными (Strong Data Governance) — основной принцип Twitter Engineering. Поскольку мы внедряем BigQuery в нашу платформу, мы концентрируемся на обнаружении данных, контроле доступа, безопасности и конфиденциальности.
Для обнаружения данных и управления ими мы расширили наш уровень доступа к данным (Data Access Layer — DAL), чтобы предоставлять инструменты как для локальных данных, так и для данных Google Cloud, предоставляя единый интерфейс и API для наших пользователей. По мере того как Google Data Catalog движется в сторону общедоступности, мы включим его в наши проекты, чтобы предоставить пользователям такие функции, как поиск по колонкам.
BigQuery позволяет легко обмениваться данными и получать к ним доступ, но нам нужно было до некоторой степени контролировать это, чтобы предотвратить эксфильтрацию данных. Среди других инструментов мы выбрали две функции:
- Domain restricted sharing: бета-функция, запрещающая пользователям обмениваться наборами данных BigQuery с пользователями за пределами Twitter.
- VPC service controls: элемент управления, который предотвращает эксфильтрацию данных и требует от пользователей доступ к BigQuery с известных диапазонов IP-адресов.
Мы реализовали требования аутентификации, авторизации и аудита (AAA) для обеспечения безопасности следующим образом:
- Аутентификация: мы использовали учетные записи пользователей GCP для ad hoc запросов и учетные записи служб для рабочих запросов.
- Авторизация: мы требовали, чтобы каждый набор данных имел учетную запись службы владельца и группу читателей.
- Аудит: мы экспортировали журналы стекдрайверов BigQuery, в которых содержалась подробная информация о выполнении запросов, в набор данных BigQuery для удобства анализа.
Чтобы обеспечить надлежащую обработку личных данных пользователей Twitter, мы должны зарегистрировать все наборы данных BigQuery, аннотировать личные данные, поддерживать надлежащее хранение и удалять (вычищать) данные, которые были удалены пользователями.
Мы рассматривали Google Cloud Data Loss Prevention API, который использует машинное обучение для классификации и редактирования конфиденциальных данных, но приняли решение в пользу ручной аннотации набора данных из-за точности. Мы планируем использовать Data Loss Prevention API, чтобы дополнить пользовательскую аннотацию.
В Twitter мы создали четыре категории конфиденциальности для наборов данных в BigQuery, перечисленные здесь в порядке убывания чувствительности:
- Высокочувствительные наборы данных доступны по мере необходимости на основе принципа наименьших привилегий. Каждый набор данных имеет отдельную группу читателей, и мы будем отслеживать использование отдельных учетных записей.
- Наборы данных средней чувствительности (односторонние псевдонимы с использованием соленого хеширования) не содержат личной информации (Personally Identifiable Information — PII) и доступны для большей группы сотрудников. Это хороший баланс между соображениями конфиденциальности и полезности данных. Это позволяет сотрудникам выполнять задачи анализа, такие как вычисление количества пользователей, которые использовали функцию, не зная, кто является реальными пользователями.
- Наборы данных с низкой чувствительностью со всей информацией, идентифицирующей пользователя. Это хороший подход с точки зрения конфиденциальности, но его нельзя использовать для анализа на уровне пользователя.
- Публичные наборы данных (выпущенные вне Twitter) доступны всем сотрудникам Twitter.
Что до регистрации, мы использовали запланированные задачи для перечисления наборов данных BigQuery и регистрации их в Data Access Layer (DAL), хранилище метаданных Twitter. Пользователи будут аннотировать наборы данных информацией о конфиденциальности, а также указывать срок хранения. Что до очистки, мы оцениваем производительность и стоимость двух вариантов: 1. Очистка наборов данных в GCS с помощью таких инструментов, как Scalding, и загрузка их в BigQuery; 2. Использование операторов BigQuery DML. Мы, вероятно, будем использовать комбинацию обоих методов для удовлетворения требований различных групп и данных.
Функциональность системы
Поскольку BigQuery является управляемой службой, не было необходимости подключать SRE команду Twitter к управлению системами или выполнению дежурных обязанностей. Было легко обеспечить большую емкость как для хранения, так и для вычислений. Мы могли бы изменить резервирование слотов, создавая тикеты в поддержке Google. Мы определили, что можно было бы улучшить, например, самообслуживание для распределения слотов и улучшение дашборда для мониторинга, и передали эти запросы в Google.
Стоимость
Наш предварительный анализ показал, что стоимость запросов для BigQuery и Presto была на одном уровне. Мы приобрели слоты по фиксированной цене, чтобы иметь стабильную ежемесячную стоимость вместо оплаты по требованию за ТБ обработанных данных. Это решение также было основано на отзывах пользователей, которые не хотели думать о затратах перед выполнением каждого запроса.
Хранение данных в BigQuery принесло расходы в дополнение к затратам на GCS. Такие инструменты, как Scalding, требуют наличия наборов данных в GCS, а для доступа к BigQuery нам пришлось загрузить те же наборы данных в формат BigQuery Capacitor. Мы работаем над соединением Scalding с наборами данных BigQuery, которое устранит необходимость хранения наборов данных как в GCS, так и в BigQuery.
Для редких случаев, которые требовали нечастых запросов на десятки петабайт, мы решили, что хранение наборов данных в BigQuery не является экономически эффективным, и использовали Presto для прямого доступа к наборам данных в GCS. Для этого мы присматриваемся к BigQuery External Data Sources.
Следующие шаги
Мы отметили большой интерес к BigQuery с момента выпуска альфы. Мы добавляем больше наборов данных и больше команд в BigQuery. Мы разрабатываем коннекторы для инструментов анализа данных, таких как Scalding, для чтения и записи в хранилище BigQuery. Мы рассматриваем такие инструменты, как Looker и Apache Zeppelin, для создания корпоративных отчетов о качестве и заметок с использованием наборов данных BigQuery.
Сотрудничество с Google было очень продуктивным, и мы рады продолжить и развивать это партнерство. Мы работали с Google, чтобы внедрить наш собственный Partner Issue Tracker, чтобы напрямую отправлять запросы в Google. Некоторые из них, такие как загрузчик BigQuery Parquet, уже реализованы Google.
Вот некоторые из наших высокоприоритетных запросов фич для Google:
- Инструменты для удобного приема данных и поддержка формата LZO-Thrift.
- Почасовое сегментирование
- Улучшения в области контроля доступа, такие как разрешения на уровне таблиц, строк и столбцов.
- BigQuery External Data Sources с интеграцией и поддержкой Hive Metastore для формата LZO-Thrift.
- Улучшенная интеграция каталога данных в пользовательском интерфейсе BigQuery
- Самообслуживания для распределения и мониторинга слотов.
Заключение
Демократизация анализа данных, визуализации и машинного обучения безопасным способом является высшим приоритетом для команды Data Platform. Мы определили Google BigQuery и Data Studio как инструменты, которые могут помочь в достижении этой цели, и зарелизили в прошлом году BigQuery Alpha для всей компании.
Мы обнаружили, что запросы в BigQuery были простыми и эффективными. Для приема и преобразования данных мы использовали инструменты Google для простых конвейеров, но для сложных конвейеров нам пришлось создать собственную инфраструктуру Airflow. В области управления данными службы BigQuery для аутентификации, авторизации и аудита удовлетворяют наши потребности. Для управления метаданными и соблюдения конфиденциальности нам требовалась большая гибкость и нам приходилось создавать собственные системы. BigQuery, будучи управляемым сервисом, был прост в эксплуатации. Затраты на запросы были аналогичны существующим инструментам. Хранение данных в BigQuery понесло расходы в дополнение к затратам на GCS.
В целом, BigQuery хорошо работает для общего SQL анализа. Мы отмечаем большой интерес к BigQuery, и мы работаем над переносом большего количества наборов данных, привлечением большего количества команд и созданием большего количества конвейеров с BigQuery. В Twitter используются разные данные, для которых потребуется сочетание таких инструментов, как Scalding, Spark, Presto и Druid. Мы намерены продолжать наращивать наши инструменты анализа данных и предоставлять четкие рекомендации нашим пользователям о том, как наилучшим образом использовать наши предложения.
Слова благодарности
Я хотел бы поблагодарить моих соавторов и товарищей по команде, Анжу Джа и Уилла Паскуччи, за их великолепное сотрудничество и тяжелую работу на этом проекте. Я также хотел бы поблагодарить инженеров и менеджеров из нескольких команд в Twitter и Google, которые помогли нам и пользователям BigQuery в Twitter, предоставившим ценную обратную связь.
Если вы заинтересованы в работе над этими задачами, ознакомьтесь с нашими вакансиями в команде Data Platform.
Качество данных в DWH — консистентность хранилища данных