Data visualizations

Привет, хабр! Прямо сейчас в OTUS открыт набор на новый поток курса Data Engineer. В преддверии старта курса мы традиционно подготовили для вас перевод интересного материала.

---

Каждый день более ста миллионов человек посещают Twitter, чтобы узнать, что происходит в мире, и обсудить это. Каждый твит и любое другое действия пользователя генерируют событие, доступное для внутреннего анализа данных в Twitter. Сотни сотрудников анализируют и визуализируют эти данные, и улучшение их опыта является главным приоритетом для команды Twitter Data Platform.

Мы считаем, что пользователи с широким спектром технических навыков должны иметь возможность находить данные и иметь доступ к хорошо работающим инструментам анализа и визуализации на основе SQL. Это позволило бы целой новой группе пользователей с меньшим техническим уклоном, включая дата аналитиков и продакт менеджеров, извлекать информацию из данных, позволяя им лучше понимать и использовать возможности Twitter. Так мы демократизируем анализ данных в Twitter.

По мере совершенствования наших инструментов и возможностей для внутреннего анализа данных мы стали свидетелями улучшения сервиса Twitter. Тем не менее, еще есть куда расти. Текущие инструменты, такие как Scalding, требуют опыта программирования. Инструменты анализа на основе SQL, такие как Presto и Vertica, имеют проблемы с производительностью в большом масштабе. У нас также есть проблема с распространением данных по нескольким системам без постоянного доступа к ним.

В прошлом году мы объявили о новом сотрудничестве с Google, в рамках которого переносим части нашей инфраструктуры данных на Google Cloud Platform (GCP). Мы пришли к выводу, что инструменты Google Cloud Big Data могут помочь нам в наших инициативах по демократизации анализа, визуализации и машинного обучения в Twitter:

• BigQuery: хранилище корпоративных данных с SQL движком на основе Dremel, который славится быстротой, простотой и справляется с машинным обучением.
• Data Studio: инструмент для визуализации больших данных с функциями совместной работы, как в Google Docs.

Из этой статьи вы узнаете о нашем опыте работы с этими инструментами: что мы сделали, чему научились и что будем делать дальше. Сейчас мы сосредоточимся на пакетной и интерактивной аналитике. Аналитику в реальном времени мы обсудим в следующей статье.

История хранилищ данных в Twitter

Прежде чем углубляться в BigQuery, стоит кратко пересказать историю хранилищ данных в Twitter. В 2011 году анализ данных в Twitter производился в Vertica и Hadoop. Для создания MapReduce работ Hadoop мы использовали Pig. В 2012 году мы заменили Pig на Scalding, у которого был Scala API с такими преимуществами, как возможность создавать сложные конвейеры и простота тестирования. Тем не менее, для многих дата аналитиков и продакт менеджеров, которым было более комфортно работать с SQL, это была достаточно крутая кривая обучения. Примерно в 2016 году мы начали использовать Presto в качестве SQL интерфейса для данных Hadoop. Spark предлагал Python интерфейс, который делает его хорошим выбором для ad hoc исследований данных и машинного обучения.

Начиная с 2018 года мы использовали следующие инструменты для анализа и визуализации данных:

• Scalding для производственных конвейеров
• Scalding и Spark для ad hoc анализа данных и машинного обучения
• Vertica и Presto для ad hoc и интерактивного SQL анализа
• Druid для малой интерактивного, исследовательского и доступа с малой задержкой к метрикам временных рядов
• Tableau, Zeppelin и Pivot для визуализации данных

Мы обнаружили, что, хотя эти инструменты предлагают очень мощные возможности, мы испытывали сложности в реализации доступности этих возможностей для более широкой аудитории в Twitter. Расширяя нашу платформу с помощью Google Cloud, мы концентрируемся на упрощении наших аналитических инструментов для всего Twitter.

Хранилище данных BigQuery от Google

Несколько команд в Twitter уже включили BigQuery в некоторые из своих производственных конвейеров. Используя их опыт, мы начали оценивать возможности BigQuery для всех сценариев использования Twitter. Нашей целью было предложить BigQuery всей компании, а также стандартизировать и поддерживать ее в рамках набора инструментов Data Platform. Это было затруднительно по многим причинам. Нам необходимо было разработать инфраструктуру для надежного приема больших объемов данных, поддержки управления данными в масштабах всей компании, обеспечения надлежащего контроля доступа и обеспечения конфиденциальности клиентов. Нам также пришлось создавать системы для распределения ресурсов, мониторинга и возврата платежей, чтобы команды могли эффективно использовать BigQuery.

В ноябре 2018 года мы выпустили альфа-релиз BigQuery и Data Studio для всей компании. Мы предложили сотрудникам Twitter некоторые из наших наиболее часто используемых таблиц с очищенными персональными данными. BigQuery использовали более 250 пользователей из различных команд, включая инженерные, финансовые и маркетинговые. Совсем недавно они выполняли около 8 тыс. запросов, обрабатывая около 100 ПБ в месяц, не считая запланированных запросов. Получив весьма положительные отзывы, мы решили двигаться вперед и предложить BigQuery в качестве основного ресурса для взаимодействия с данными в Twitter.

Вот схема высокоуровневой архитектуры нашего хранилища данных Google BigQuery.


Мы копируем данные из локальных кластеров Hadoop в Google Cloud Storage (GCS), используя внутренний инструмент Cloud Replicator. Затем мы используем Apache Airflow для создания конвейеров, которые используют bq_load для загрузки данных из GCS в BigQuery. Мы используем Presto для запроса наборов данных Parquet или Thrift-LZO в GCS. BQ Blaster это внутренний инструмент Scalding для загрузки наборов данных HDFS Vertica и Thrift-LZO в BigQuery.

В следующих разделах мы обсудим наш подход и знания в области простоты использования, производительности, управления данными, работоспособности системы и стоимости.

Простота использования

Мы обнаружили, что пользователям было легко начинать с BigQuery, поскольку он не требовал установки программного обеспечения и пользователи могли получать к нему доступ через интуитивно понятный веб-интерфейс. Тем не менее пользователям необходимо было ознакомиться с некоторыми функциями GCP и его концепциями, включая такие ресурсы, как проекты, наборы данных и таблицы. Мы разработали учебные материалы и туториалы, чтобы помочь пользователям начать работу. С приобретением базового понимания пользователям стало легко перемещаться по наборам данных, просматривать схему и данные таблиц, выполнять простые запросы и визуализировать результаты в Data Studio.

Наша цель касаемо ввода данных в BigQuery состояла в том, чтобы обеспечить плавную загрузку наборов данных HDFS или GCS одним щелчком мыши. Мы рассматривали Cloud Composer (управляемый Airflow), но не смогли его использовать из-за нашей модели безопасности Domain Restricted Sharing (подробнее об этом в разделе Управление данными ниже). Мы экспериментировали с использованием Google Data Transfer Service (DTS) для организации нагрузочных задач BigQuery. В то время как DTS быстро настраивался, он не был гибким для построения конвейеров с зависимостями. Для нашей альфа версии мы создали собственную среду Apache Airflow в GCE и готовим ее к работе в продакшене и возможности поддерживать больше источников данных, таких как Vertica.

Для преобразования данных в BigQuery пользователи создают простые конвейеры данных SQL, используя запланированные запросы. Для сложных многоступенчатых конвейеров с зависимостями мы планируем использовать либо нашу собственную инфраструктуру Airflow, либо Cloud Composer вместе с Cloud Dataflow.

Производительность

BigQuery создан для SQL запросов общего назначения, которые обрабатывают большие объемы данных. Он не предназначен для запросов с низкой задержкой, высокой пропускной способностью, необходимых для транзакционной базы данных, или для анализа временных рядов с низкой задержкой, реализованного Apache Druid. Для интерактивных аналитических запросов наши пользователи ожидают времени отклика менее одной минуты. Мы должны были спроектировать использование BigQuery таким образом, чтобы соответствовать этим ожиданиям. Чтобы обеспечить предсказуемую производительность для наших пользователей, мы использовали функционал BigQuery, доступный для клиентов на фиксированной оплате, которая позволяет владельцам проектов резервировать минимальные слоты для своих запросов. Слот BigQuery это единица вычислительной мощности, необходимой для выполнения SQL запросов.

Мы проанализировали более 800 запросов, обрабатывающих около 1 ТБ данных каждый, и обнаружили, что среднее время выполнения составило 30 секунд. Мы также узнали, что производительность сильно зависит от использования нашего слота в различных проектах и задачах. Мы должны были четко разграничить наши производственные и ad hoc резервы слотов, чтобы поддерживать производительность для производственных сценариев использования и интерактивного анализа. Это очень сильно повлияло на наш дизайн для резервирования слотов и иерархии проектов.

Про управление данными, функциональность и стоимость систем, поговорим уже в ближайшие дни во второй части перевода, а сейчас приглашаем всех желающих на бесплатный живой вебинар, в рамках которого можно будет подробно узнать о курсе, а также задать вопросы нашему эксперту Егору Матешуку (Senior Data Engineer, MaximaTelecom).

---

Читать ещё:

• Data Build Tool или что общего между Хранилищем Данных и Смузи
• Погружение в Delta Lake: принудительное применение и эволюция схемы
• Высокоскоростной Apache Parquet на Python с Apache Arrow

Привет, Хабр! Прямо сейчас в OTUS открыт набор на новый поток курса Data Engineer. В преддверии старта курса продолжаем делиться с вами полезным материалом.

Читать первую часть

---

Управление данными

Сильное управление данными (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 КОНСИСТЕНТНОСТЬ ХРАНИЛИЩА ДАННХ

---