Системы для работы с данными: зачем нужны и как их построить

Индустрия больших данных растет кратными темпами год к году. По оценке Ассоциации больших данных, в 2021 году объем рынка в России составлял 10-30 млрд рублей, а к 2024 году он достигнет 300 млрд рублей.

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

Рассмотрим пару отраслевых примеров.

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

В игровой индустрии также есть уникальный пример выхода в физическое пространство — и в случае с AR- или VR-играми командам приходится работать с движением человека в пространстве, для чего нужны сложнейшие технологические системы и моментальная скорость их реакции.

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

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

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

Правильно выбранный арсенал инструментов критичен для будущего системы. Если двадцать лет назад это было сложно, сегодня есть выбор доступных инструментов и накопленный опыт в разработке собственных. Мы, например, в VK сначала для собственных задач создали in-memory платформу Tarantool. С ее помощью можно разрабатывать высоконагруженные системы хранения и обработки данных. По мере развития продукта мы вывели его в открытый доступ (open source).

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

Параметры систем хранения и обработки данных — на что обращать внимание?

Если говорить про данные, поддерживающие бизнес-процессы компании, то при разработке систем важно в первую очередь обращать внимание на следующие параметры:

Безопасность

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

Масштабирование

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

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

Также любопытен подход управления хаосом (Chaos Engineering). С усложнением систем становится труднее понять, как отдельные компоненты будут реагировать на стрессы.

Chaos engineering — это методика, которая позволяет спроектировать последовательность стрессовых для систем событий, с уже разработанными инструментами. Например, если система размещена в облаке, можно быстро проверить, как база данных реагирует на неожиданные всплески нагрузки на центральный процессор (CPU) в условиях резкого роста запросов из внешних систем, и внести изменения в кодовую базу, процессы и регламенты восстановления.

Экономический аспект

Экономика и пользовательский опыт идут рука об руку с компромиссом — команды архитекторов и развития бизнеса должны согласовать уровень сервиса, который учитывает время ответа системы и допустимые финансовые издержки. Важно постоянно тестировать гипотезы: сколько выделено ресурсов, как они должны работать и масштабироваться. Если в день анонса игры в приложение зашли тысячи пользователей, а команда включила автомасштабирование без тестирования, есть серьезный риск неоправданных затрат.

Для разработки инфраструктуры и управления ресурсами можно подключать облачные решения. В этом случае компания использует готовый сервис (PaaS — платформа как сервис), способный выдержать заданную нагрузку, и платит за те ресурсы, которые реально использовала.

Качественная инфраструктура для работы с данными — какая она

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

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

1. Сбор

На первом этапе данные собираются. В случае с турбиной простые датчики только передают информацию. Более продвинутые решения могут принимать сигналы и управлять работой оборудования.

2. Передача

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

3. Обработка и хранение

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

4. Визуализация

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

Строим платформу для работы с данными — какие специалисты нужны

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

Внутреннюю команду стоит разделить на несколько стримов:

Архитекторы. В зависимости от сложности задач, это может быть один специалист или целая команда: enterprise-архитектор выстраивает взаимодействие систем в крупной компании; solution-архитектор прорабатывает конкретное решение, а application-архитектор — приложение; архитектор данных планирует, как данные будут работать внутри решения и интегрироваться с внешними системами; security-архитектор отвечает за проектирование безопасного периметра.

Команда бизнес-развития. Специалисты команды вырабатывают бизнес-требования к решению на основе вклада других команд.

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

Команда разработчиков. Задача разработчиков — проанализировать вклад других команд, свести его к плану и дорожной карте продукта, донести обратную связь в виде технологической реализации.

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

В поддержке и развитии инфраструктуры должны постоянно участвовать все команды. Это важный фактор, который нужно учитывать в планировании — система должна периодически проходить стадии перепроектирования. Состав команды также зависит от технологического стека проекта. Если проект реализован с помощью решений без программного кода (no-code/ low-code подход) или использует Kubernetes, команды могут быть небольшими. Когда нужна постоянная кастомизация или разрабатываемая платформа должна стать основой для других решений, команда проекта может достигать десятков тысяч специалистов.

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

Сроки и альтернативы — как быстро можно выйти с решением на рынок

Платформа для работы с данными состоит из интегрированных между собой инструментов для сбора, обработки, хранения, аналитики и визуализации данных.

• Источниками данных могут быть любые системы, которые собирают потенциально полезную для бизнеса информацию — ERP, CRM, реляционные базы данных, Saas-сервисы и т.д.
• В качестве инструментов для обработки данных чаще всего используют Apache Spark, Kafka, Airflow.
• Для хранения и анализа данных подходят in-memory платформа Tarantool, аналитические базы данных Greenplum, Clickhouse, Vertica, а также инструменты из экосистемы Hadoop.
• С задачей визуализации данных справляются BI-системы — Power BI, Qlik, Tableau, Apache Superset или их аналоги.

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

Если в основе инфраструктуры облачные решения, ситуация может быть обратной. В облачных проектах часто стадии тестирования и согласования сокращают до минимума, используя принцип получения быстрых инсайтов от ошибок. Кроме того, у облачных провайдеров уже есть готовые примеры архитектуры и большой опыт в индустрии. Это позволяет запустить некоторые проекты за месяц. Например, «Магнит», VK Cloud и Tarantool за два месяца запустили онлайн-доставку с помощью партнеров ритейлера и подключили к ней 400 магазинов сети.

Сегодня большая часть технологических проектов в области работы с данными может быть размещена в облачных сервисах. По данным исследования, которое мы провели в этом году, 46% компаний в России используют облачные решения для работы с такими проектами и 29% планируют переезд в облака в ближайшее время. Опыт вендора и модель оплаты за ресурсы по факту использования (Pay-as-You-Go) снимают риски и делает жизнь команды проекта проще. В дальнейшем такие проекты только продолжат набирать популярность, ведь количество данных растет, как и потребность в них, а инвестировать в новые физические ресурсы, масштабирование и обучение команды могут единицы компаний.