Привет, Хабр! Запись на новый поток курсов открыта прямо сейчас в OTUS «Инженер данных» .
В ожидании старта курса мы продолжаем делиться с вами полезным материалом.
Прочтите первую часть 
Управление данными
Надежное управление данными — основной принцип разработки Twitter. Внедряя BigQuery в нашу платформу, мы уделяем особое внимание обнаружению данных, контролю доступа, безопасности и конфиденциальности.Чтобы обнаруживать данные и управлять ими, мы расширили наш уровень доступа к данным, чтобы ДАЛ ), чтобы предоставить инструменты как для локальных данных, так и для данных Google Cloud, предоставляя единый интерфейс и API для наших пользователей.
Как Google Каталог данных движется к общедоступности, мы включим его в наши проекты, чтобы предоставить пользователям такие функции, как поиск по столбцам.
BigQuery упрощает обмен данными и доступ к ним, но нам нужно было иметь некоторый контроль над этим, чтобы предотвратить утечку данных.
Среди других инструментов мы выбрали две функции: Ограниченный доступ к домену : бета-функция, запрещающая пользователям делиться наборами данных BigQuery с пользователями за пределами Twitter. Управление услугами VPC : элемент управления, который предотвращает утечку данных и требует от пользователей доступа к BigQuery из известных диапазонов IP-адресов.
Мы реализовали требования к аутентификации, авторизации и аудиту (AAA) для обеспечения безопасности следующим образом: Аутентификация: мы использовали учетные записи пользователей GCP для специальных запросов и учетные записи служб для производственных запросов.
Авторизация.
Мы требовали, чтобы каждый набор данных имел учетную запись службы владельца и группу читателей.
Аудит. Мы экспортировали журналы стекдрайвера BigQuery, которые содержали подробную информацию о выполнении запросов, в набор данных BigQuery для упрощения анализа.
Чтобы обеспечить правильную обработку персональных данных пользователей Twitter, мы должны зарегистрировать все наборы данных BigQuery, аннотировать персональные данные, обеспечить надлежащее хранение и удалить (очистить) данные, которые были удалены пользователями.
Мы посмотрели на Google API предотвращения потери данных в облаке , которая использует машинное обучение для классификации и редактирования конфиденциальных данных, но решила использовать аннотирование набора данных вручную из-за точности.
Мы планируем использовать API предотвращения потери данных для расширения пользовательской аннотации.
В Twitter мы создали четыре категории конфиденциальности для наборов данных в BigQuery, перечисленные здесь в порядке убывания конфиденциальности: Наборы высококонфиденциальных данных доступны по мере необходимости на основе принципа наименьших привилегий.
У каждого набора данных есть отдельная группа читателей, и мы будем отслеживать использование отдельными учетными записями.
Наборы данных средней конфиденциальности (односторонние псевдонимы с использованием «соленого» хеширования) не содержат информации, позволяющей установить личность (PII), и доступны более широкой группе сотрудников.
Это хороший баланс между заботой о конфиденциальности и полезностью данных.
Это позволяет сотрудникам выполнять задачи анализа, такие как подсчет количества пользователей, использовавших функцию, не зная, кто настоящие пользователи.
Наборы данных низкой чувствительности со всей информацией, идентифицирующей пользователя.
Это хороший подход с точки зрения конфиденциальности, но его нельзя использовать для анализа на уровне пользователя.
Публичные наборы данных (опубликованные за пределами Twitter) доступны всем сотрудникам Twitter. Что касается ведения журнала, мы использовали запланированные задачи для перечисления наборов данных BigQuery и регистрации их на уровне доступа к данным ( ДАЛ ), хранилище метаданных Twitter. Пользователи будут аннотировать наборы данных информацией о конфиденциальности, а также указывать срок хранения.
Что касается очистки, то мы оцениваем производительность и стоимость двух вариантов: 1. Очистка наборов данных в GCS с помощью таких инструментов, как Scalding, и загрузка их в BigQuery; 2. Использование операторов BigQuery DML. Вероятно, мы будем использовать комбинацию обоих методов для удовлетворения требований различных групп и данных.
Функциональность системы
Поскольку BigQuery является управляемым сервисом, не было необходимости привлекать команду SRE Twitter к управлению системами или выполнению рабочих обязанностей.Было легко обеспечить большую емкость как для хранения, так и для вычислений.
Мы могли изменить резервирование слотов, создав заявку при поддержке Google. Мы определили области, которые можно улучшить, такие как распределение слотов самообслуживания и улучшения информационной панели для мониторинга, и отправили эти запросы в Google.
Цена
Наш предварительный анализ показал, что затраты на запросы для BigQuery и Presto были на одном уровне.Мы приобрели слоты для зафиксированный цена, чтобы иметь стабильную ежемесячную стоимость вместо оплаты по требованию за ТБ обработанных данных.
Это решение также было основано на отзывах пользователей, которые не хотели думать о затратах перед каждым запросом.
Хранение данных в BigQuery принесло дополнительные затраты помимо затрат на GCS. Для таких инструментов, как Scalding, требуются наборы данных в GCS, а для доступа к BigQuery нам приходилось загружать те же наборы данных в формат BigQuery. Конденсатор .
Мы работаем над подключением Scalding к наборам данных BigQuery, которое устранит необходимость хранить наборы данных как в GCS, так и в BigQuery.
В редких случаях, когда требовались нечастые запросы объемом в десятки петабайт, мы решили, что хранение наборов данных в BigQuery нерентабельно, и использовали Presto для прямого доступа к наборам данных в GCS. Для этого мы рассматриваем внешние источники данных BigQuery.
Следующие шаги
Мы заметили большой интерес к BigQuery с момента его альфа-версии.Мы добавляем в BigQuery больше наборов данных и больше команд. Мы разрабатываем коннекторы для инструментов анализа данных, таких как Scalding, для чтения и записи в хранилище BigQuery. Мы рассматриваем такие инструменты, как Looker и Apache Zeppelin, для создания отчетов и заметок корпоративного качества с использованием наборов данных BigQuery. Наше сотрудничество с Google было очень продуктивным, и мы рады продолжать и развивать это партнерство.
Мы работали с Google над внедрением собственного Отслеживание проблем партнеров для отправки запросов непосредственно в Google. Некоторые из них, например загрузчик BigQuery Parquet, уже реализованы Google. Вот некоторые из наших высокоприоритетных запросов на функции для Google: Инструменты для удобного приема данных и поддержки формата ЛЗО-Бережливость.
Почасовая сегментация Улучшения контроля доступа, такие как разрешения на уровне таблицы, строки и столбца.
Большой запрос Внешние источники данных с интеграцией 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. Качество данных в СХД — согласованность хранилища данных Теги: #Большие данные #Инжиниринг данных #аналитика #визуализация данных #большой запрос
-
Надежные И Долговечные Аккумуляторы От Acer!
19 Oct, 24 -
Мужской Мозг Лучше Всего Работает В 39 Лет
19 Oct, 24
