Часто говорят, что путь в тысячу миль начинается с одного шага.

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

Любой пользователь LinkedIn, в названии которого есть слово «данные», знает, что рынок насыщен поставщиками всех видов. От хорошо известных поставщиков облачных услуг до представителей узкой ниши — каждый этап жизненного цикла данных контролируется десятками технологических компаний, каждая из которых утверждает, что имеет лучшее и наиболее экономически эффективное решение.

PrimaryBid — это бизнес, определяющий категории, и поэтому у нас нет признанных игроков, которым мы могли бы следовать при выборе наших технологий обработки данных. Наши требования имели несколько уровней:

  • PrimaryBid обеспечивает розничным инвесторам новый доступ к краткосрочным сделкам по сбору средств на публичных рынках акций и долговых обязательств. Таким образом, нам нужна платформа, которая может быть эластичной к рыночным условиям, со значительным предпочтением переменных, а не фиксированных затрат.
  • PrimaryBid работает в строго регулируемой среде: мы подчиняемся правилам финансовых услуг в каждой из наших юрисдикций, а также правилам защиты данных (включая GDPR). Поэтому крайне важно, чтобы наш набор технологий обеспечивал лучшее в своем классе соответствие всем применимым требованиям.
  • PrimaryBid обрабатывает многие типы конфиденциальных данных, включая личную информацию (PII), рыночную/инсайдерскую информацию и собственную интеллектуальную собственность (IP). Поэтому информационная безопасность является важнейшим требованием.
  • Частью интеллектуальной собственности PrimaryBid является наша способность прогнозировать спрос розничных инвесторов на транзакцию, используя наши собственные и уникальные активы данных. В результате наш стек должен включать масштабируемую среду машинного обучения с разнообразным набором функций моделей рынка, партнеров и клиентов.
  • Поскольку мы являемся бизнесом серии C с международными амбициями, технологии, которые мы выбираем, должны масштабироваться в геометрической прогрессии, как и мы, и быть доступными во всем мире, поскольку мы нацелены на географическое расширение.
  • Как создатели категорий, мы должны иметь возможность понимать наш рынок, наших клиентов и наших партнеров практически в реальном времени, что позволит нам оставаться конкурентоспособными и ориентированными на пользователей.
  • И, пожалуй, самое большое клише: нам нужно было все вышеперечисленное по максимально низкой цене, с возможностью легко меняться по мере развития нашей стратегии.

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

Вид с высоты 30 000 футов

Вид с высоты 30 000 футов не удивит ни одного профессионала в области данных. Мы собираем данные из различных источников, структурируем их во что-то полезное, представляем их различными способами и объединяем в модели, которые мы демонстрируем в наших продуктах и ​​услугах. На протяжении всего этого процесса мы отслеживаем качество данных, обеспечиваем конфиденциальность данных и отправляем оповещения нашей команде, когда что-то ломается.

Сбор и преобразование данных

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

Для удовлетворения наших потребностей мы выбрали (теперь классическую) комбинацию FiveTran и dbt.

Fivetran поддерживает огромный набор предварительно созданных коннекторов данных, которые позволяют группам данных получать новые каналы за считанные минуты, удовлетворяя наши потребности в различных источниках данных, которые мы хотим объединить. Принятая нами модель затрат основана на ежемесячных активных строках; т. е. вы платите постепенно за изменяющиеся строки, а не за строки, которые остаются прежними. Это означает, что мы платим только за то, что используем. Дополнительным преимуществом этого подхода является то, что вы можете получать данные с той частотой, которая вам подходит; нет никакой разницы в стоимости, если вы будете получать подачу ежедневно или каждые 30 секунд.

Fivetran также занимается обслуживанием разъемов; Обновления схемы, изменения версий и т. д. автоматически обрабатываются на их стороне. Это высвобождает огромное количество времени на разработку данных в нашей команде за счет передачи на аутсорсинг постоянного цикла обновления интеграции API наших более чем 35 источников данных.

Как только данные извлекаются с помощью Fivetran, dbt превращает необработанные данные в структуру, пригодную для последующих инструментов. Этот процесс известен как аналитическая инженерия. Наша облачная модель dbt рассчитана на каждое рабочее место и поэтому будет хорошо масштабироваться по мере роста команды. dbt и Fivetran создают синергетическое партнерство: многие соединители Fivetran имеют готовые шаблоны dbt, которые могут использовать группы обработки данных, что является еще одним повышением производительности и сокращения времени на получение аналитической информации. dbt пользуется огромной популярностью среди инженеров по обработке данных и содержит множество передовых методов разработки программного обеспечения (например, тестирование, контроль версий), которые обеспечивают надежность и прозрачность аналитических преобразований.

Обе платформы имеют свои собственные инструменты оркестрации для планирования и мониторинга конвейеров, но мы развертываем Apache Airflow 2.0, управляемый через Cloud Composer Google Cloud, чтобы дать нам более детальный контроль над этим процессом. Результатом являются конвейеры, которые доставляют данные пользователям с задержкой менее 2 минут при минимальных затратах.

Хранение данных, управление и конфиденциальность

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

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

Что нас привлекло в экосистеме Google Cloud, так это интеграция конфиденциальности данных, управления и происхождения во всех аспектах. Используя Dataplex от Google, мы устанавливаем политики безопасности в одном месте, на самих необработанных данных. Поскольку данные затем преобразуются, передаются между сервисами Google Cloud и превращаются в прогнозные модели, эти же политики безопасности соблюдаются повсюду без каких-либо дополнительных усилий.

Одним из примеров является персональная информация, которая закрыта для каждого сотрудника, за исключением небольшого числа людей, которым она нужна для выполнения повседневных функций. Мы помечаем данные один раз флагом has_PII, и не имеет значения, какой инструмент вы используете для доступа к данным (BigQuery, инструменты BI, блокноты Python и т. д.), если у вас нет разрешения на PII в необработанном виде. данные, которые вы никогда и нигде не сможете увидеть.

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

Аналитика данных

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

В качестве PrimaryBid мы выбрали Looker, платформу бизнес-аналитики, приобретенную Google Cloud в 2019 году. Имея командный опыт работы с PowerBI, Tableau, Data Studio (теперь Looker Studio) и многими другими инструментами, Looker оказался относительно дорогим выбором по сравнению с конкурентами. Однако для нас это принесло несколько преимуществ, превосходящих альтернативы.

Во-первых, требования разработчика: в нашем случае каждый член нашей команды данных очень хорошо владеет SQL. Это лежит в основе функционирования Looker; вместо того, чтобы хранить данные самостоятельно, Looker записывает SQL-запросы непосредственно к вашему хранилищу данных. Чтобы убедиться, что он пишет правильный запрос, инженеры и аналитики создают аналитические модели Looker с помощью LookML. LookML по большей части использует мало кода, но для сложных преобразований SQL можно записать непосредственно в модель, что играет на руку нашей команде.

В отличие от этого, PowerBI использует язык VBA/Excel под названием DAX; когда я использовал PowerBI, я писал DAX только при создании информационных панелей. В результате я так и не почувствовал по-настоящему этот язык, и разработка стала бы медленным и тяжелым процессом с использованием Stack Exchange. Благодаря навыкам нашей команды, основанным на SQL, LookML было гораздо легче освоить и запомнить.

Во-вторых, ключевым фактором при принятии решения была возможность расширения Looker на наши платформы. При наличии моделей LookML преобразованные чистые данные можно передавать в любую нижестоящую службу. Нашей первой разработкой были информационные панели внутри самого Looker; при их наличии данные также можно вызывать через API через Looker SDK, предлагая простой и эффективный способ внедрения аналитики внутри и снаружи. Как технологической компании, способность внедрять аналитику с помощью методов low-code позволяет нам гибко подходить к тому, как мы представляем данные и кто может их видеть.

Наконец, взаимодействие между Looker и Dataplex особенно эффективно. За кулисами Looker пишет запросы к BigQuery. При этом сохраняются все правила безопасности и конфиденциальности данных, адаптированные к каждому конкретному пользователю. Хранение данных в одном месте и по одному набору правил было предпочтительнее копирования данных на другую платформу BI или Analytics, что способствовало соблюдению требований соответствия и конфиденциальности.

Наука о данных + машинное обучение (DS/ML)

Последний шаг в наших конвейерах данных — это среда DS/ML. Изначально мы изучали DataBricks для удовлетворения наших потребностей; несколько членов нашей команды имеют фантастический опыт работы с их платформой, и я определенно воспользуюсь ими снова в будущем. В частности, их блокноты для совместной работы являются лучшими в своем классе.

На этот раз мы еще больше изучили предложения Google Cloud и решили попробовать Vertex AI для разработки, развертывания и мониторинга моделей.

Как и в случае с Looker, Vertex AI сразу же получает преимущества управления и конфиденциальности от DataPlex, а происхождение автоматически выявляется на всем пути от необработанных данных до вывода модели; Хранилище метаданных Vertex AI отлично подходит для обеспечения прозрачного представления действующих моделей и данных, которые в них подаются.

Данные в PrimaryBid поступают из широкого спектра внутренних и внешних источников. Стандартизация входных данных модели и их универсальная доступность были первоочередной задачей, чтобы гарантировать, что мы используем все, что у нас есть, для прогнозирования рынков капитала. Интегрированный Магазин функций Vertex AI оказался огромным преимуществом в наших конвейерах моделей и может предоставлять функции с низкой задержкой для живых моделей в производстве, которые часто обновляются по мере изменения рыночных условий.

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

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

Итак, вот вам краткий обзор стека данных. Мы очень довольны сделанным выбором и получаем отличные отзывы от бизнеса. Мы всегда стремимся к улучшению; если у вас есть какие-либо мысли или предложения, пожалуйста, дайте мне знать!

Будущее

Уже некоторое время вышеописанный стек работает на полной скорости, и мы довольны производительностью, гибкостью и стоимостью сделанного нами выбора. Однако, будучи растущим бизнесом, мы не можем стоять на месте; Я предполагаю, что в ближайшем будущем мы увидим следующие расширения нашего стека:

  • Обратный ETL: одна из технологий, не упомянутая выше, — это Segment, платформа, которую мы используем для отслеживания событий и анализа продуктов. Позже в этом году мы планируем использовать возможности обратного ETL Segment, записывая преобразованные данные обратно в исходные системы, из которых они поступили.
  • Поддержка нескольких регионов: конфиденциальность и безопасность данных встроены в структуру нашего стека данных. Сегодня наша установка предназначена главным образом для удовлетворения законодательных и нормативных требований Великобритании и ЕС; это будет адаптироваться и развиваться по мере того, как мы будем работать во все большем и большем количестве географических регионов.
  • Генеративный ИИ: мы ожидаем расследования того, как PrimaryBid может использовать генерирующий ИИ внутри и снаружи. Конечно, подходя к этой задаче, мы прекрасно понимаем свои обязательства по сохранению конфиденциальности данных и интеллектуальной собственности, особенно с учетом громких ошибок, которые могут быть допущены на этапе зарождения технологии. Мы планируем использовать подход модели замороженного/адаптера, как показано на рисунке ниже, — используя возможности массивных моделей больших языков (LLM), но в частной среде. Подробнее об этом — позже в этом году!

Особая благодарность команде обработки данных PrimaryBid, а также Ине Чобану за их вклад в эту статью, а также Статису Онасоглу и Дэйву Эллиотту за их вклад перед публикацией.

Автор:Энди Тернер, директор по данным PrimaryBid. Энди имеет более чем 10-летний опыт управления функциями обработки и анализа данных, анализа данных и бизнес-аналитики в организациях, предоставляющих финансовые услуги и розничную торговлю. Он работал в Великобритании, Европе, на Ближнем Востоке, в Северной и Южной Америке и Южной Африке.