Как использовать универсальность BigQuery для информационных продуктов

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

Функции

BigQuery - это облачное «полностью управляемое, петабайтное, экономичное хранилище аналитических данных от Google, которое используется на той же арене, что и Redshift от Amazon. Функции и предложения высокого уровня включают:

  • Потоковая запись, пакетное копирование
  • SQL-запросы к неструктурированным и вложенным / повторяющимся данным JSON
  • Нет управления инфраструктурой, глобальная репликация, плата за использование вместо оборудования
  • Изоляция производительности запросов от других запросов
  • Дешевая запись и хранение, вы платите 5 долларов за ТБ отсканированного изображения, не платите за базовое оборудование, такое как Redshift.
  • Только добавление, без обновлений, без удалений, без индексов
  • Пользовательские функции в Javascript, которые могут принимать одну строку и выводить одну или несколько строк.

Как BigQuery используется в Ravelin

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

Мы транслируем все данные в BigQuery в режиме реального времени через небольшой сервис, который использует нашу систему обмена сообщениями, NSQ. Он отвечает за управление миграцией схем в наших таблицах (что не влияет на производительность!) И передает данные в таблицы партиями каждые несколько секунд с помощью потокового API BigQuery. Каждый раз, когда мы хотим добавить или перенести таблицу, мы меняем определения структур, и таблицы создаются или перестраиваются. Мы обернули относительно низкоуровневый API, предоставляемый библиотеками Go, внутренней библиотекой, которая управляет обновлением токенов, выводом схем и записью пакетных таблиц.

Отслеживание

Внутри Ravelin построен как разрозненные сервисы, обычно отвечающие за один домен, которые взаимодействуют друг с другом. Отслеживание запросов между этими службами (в духе Dapper или Zipkin) неоценимо для оценки производительности распределенной системы. Мы отбираем небольшой процент нашего трафика для отслеживания по всей системе. Если мы выберем отслеживание данного запроса, будут захвачены все вызовы, тела и ошибки RPC вместе с любыми асинхронными потребителями сообщений, созданных в очереди. Это дает нам полное представление о таймингах внутренних запросов и позволяет динамически отображать всю систему.

Кроме того, это позволяет нам выполнять как специальные запросы, так и подробный анализ задержки для сотен миллионов запросов, что было бы очень сложно или невозможно с традиционной базой данных временных рядов. Этот небольшой процент трафика по-прежнему приводит к сотням миллионов строк в месяц - количество, которое BigQuery легко обрабатывает. Хранение данных в необработанном формате означает, что любители приключений могут создавать модели или симуляции, чтобы снизить чувствительность всей системы к изменениям задержки отдельных компонентов или общей нагрузки.

Ведение журнала API

В настоящее время мы храним все необработанные запросы событий в нашем API вместе с заголовками и кодами состояния. Это позволяет нам возвращать журнал нашим клиентам при интеграции с нами, чтобы проверять тела запросов, которые они делают, и отлаживать любые проблемы, возвращаемые нашей проверкой схемы API. Это также позволяет нам понимать, что происходит через наш API, и оперативно устранять любые проблемы. Наша работа была бы намного сложнее и медленнее, если бы эти данные просто хранились на S3 в файлах журнала, как это было раньше.

Анализ производительности и специальное расследование

Важнейшей частью построения системы машинного обучения является оценка производительности. BigQuery используется для расчета показателей нашего классификатора в реальном времени с разумным использованием быстрых соединений между таблицами: это позволяет нашей команде машинного обучения понимать производительность модели по мере того, как метки поступают от наших клиентов. Это позволяет нам быстро диагностировать любые несоответствия от автономного обучения до онлайн-прогнозирования и сравнивать несколько моделей друг с другом. Те же данные также используются для создания панели отчетов в нашем продукте, чтобы показать общие бизнес-показатели и пролить свет на нашу эффективность. Хотя выполнение запросов занимает всего несколько секунд, Redis находится впереди в качестве кеша по причинам задержки.

BigQuery также поддерживает любое специальное расследование, которое мы хотели бы провести. Это может быть как создание тепловых карт мошенничества в определенных областях, так и визуализация последствий утечки данных для различных эмитентов карт по всему миру.

Для чего мне его использовать?

  • Схема, неизменные данные - «четко определенная, необычная вещь, произошедшая во время T». Эти данные хорошо подходят для модели BigQuery только с добавлением, и их можно очень быстро разрезать в разные стороны.
  • Низкоуровневое ведение журнала и трассировка. Использование BigQuery позволяет нам собирать гораздо больше данных, чем мы хотели бы обрабатывать с помощью Elasticsearch, и при этом гораздо дешевле. Возможно, вы никогда раньше не задумывались об этом варианте использования - мы не думали - но вам стоит. Извлеките данные из файлов журналов и поместите их в BigQuery. Полнотекстовый поиск и возможность запроса по необработанному JSON неоценимы для устранения проблем.
  • Обработка данных с уменьшением карты. Мы написали UDF, который геохеширует наши данные GPS для последующей обработки. Наш рекорд - 100 миллионов адресов, обработанных за 20 секунд. Если ваша проблема может быть объяснена как функция карты, и ей не нужно вызывать какие-либо внешние службы (например, синтаксический анализ строки пользовательского агента), то BigQuery, вероятно, является самым быстрым решением на рынке.
  • Быть тихим, надежным и не вести себя как примадонна. Вам даже не нужно думать об этом с точки зрения надежности инфраструктуры.

Что с этим труднее?

  • Данные, которые очень часто обновляются - вам нужно будет написать представление, которое представляет только последнюю версию строки и иногда сжимает таблицы.
  • Данные, которые нужно удалять очень часто. Как уже упоминалось, удалений нет, поэтому вам придется скопировать всю таблицу, кроме данных, которые вы хотите удалить.
  • Выполняйте потоковую передачу больших объемов данных. Иногда нам нужно перестраивать базы данных с нуля (как наша база данных графов), используя известный источник истины. BigQuery не очень хорош в этом, поскольку он позволяет выгружать только 128 МБ сжатых данных. Данные большего размера должны быть сохранены в таблице и переданы через Google Storage. Меня раздражает то, что нам приходится преодолевать эти препятствия (это больше способов что-то пойти не так), и это похоже на деталь реализации, которая была без надобности раскрыта клиенту.
  • Очень большие ORDER BY. Сортировка данных происходит на одном узле. Если вам нужно выполнить глобальную сортировку, тогда все данные будут перенесены на один узел. Если это превышает установленный предел (я думаю, что в настоящее время установлено значение 128 МБ), BigQuery завершится ошибкой с исключением превышения ресурса. Вариантов использования глобально отсортированных данных немного, и команда BigQuery активна, помогая пользователям переработать свои запросы.

В целом нам очень понравился BigQuery. Он позволяет записывать большой объем данных каждый день - объем, который нам почти наверняка придется нанять на полный рабочий день, чтобы просто заботиться о нем, - и обрабатывать его быстро способами, которые мы не смогли бы сделать с другими продуктами. Есть несколько подводных камней, к которым вам нужно привыкнуть и, возможно, создать свой собственный инструментарий. Если вы только начинаете создавать инфраструктуру данных, я настоятельно рекомендую использовать ее, поскольку требует минимальных усилий, чрезвычайно высокого качества и смехотворно дешевого хранилища данных. Не стесняйтесь обращаться ко мне в Twitter, чтобы поговорить дальше (@sjwhitworth).