Как BigQuery от Google демократизировал анализ данных. Часть 1

Привет, Хабр! Прямо сейчас в 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

Источник: habr.com