С ростом объема генерируемых данных повышаются требования к компетенции ИТ-специалистов в части работы с Big Data и решениями для их сбора, обработки и хранения. Это общий тренд, который по мере цифровизации бизнеса только набирает обороты. 

В соответствии с этим вектором IT Академия Samsung в апреле 2025 года провела уже второй хакатон IT Academy Hack 2025. VK Tech стал индустриальным партнером и предоставил инфраструктуру для студентов, а также подготовил одну из двух задач, которую студенты решали в рамках хакатона.

Меня зовут Павел Кутаков, я эксперт-архитектор команды VK Tech в направлении Data Services. В этой статье расскажу об актуальных решениях для работы с данными, а также о задаче и подходах, которые можно было применить для ее решения.

Немного контекста и ретроспективы

Ежедневно в мире генерируется около 402 млн Тб данных, то есть около 147 Зб (зеттабайт) данных в год. По прогнозам, к 2025 году объем создаваемых данных достигнет 181 Зб. 

Причем очевидных границ роста пока нет, а тренд не меняется.

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

Чтобы убедиться в этом, стоит сделать небольшой исторический экскурс.

С чего все начиналось

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

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

Результатом такого поиска стала идея хранить данные «перпендикулярно» — так появилось понятие колоночного хранения, при котором каждая колонка в таблице хранится (и сжимается) отдельно. Это позволило существенно повысить производительность для аналитических запросов. 

Следующим этапом стало шардирование базы данных, а также применение для DWH-систем модели Massive Parallel Processing (MPP), при котором используется несколько серверов БД, каждый из которых хранит и обрабатывает только часть данных.

Одновременно с появлением MPP-систем появилась и концепция Data Lake, которая подразумевает создание централизованного «хранилища», куда сливают все возможные данные компании в их исходном, сыром виде, без предварительной строгой обработки и структурирования. Основных предпосылок создания Data Lake было две:

• желание хранить не только строго табличные данные, а вообще любые данные;

• необходимость решения проблем с масштабируемостью традиционных СУБД.

Символом эпохи Data Lake стала система Hadoop, которая действительно решила проблему масштабируемости, хотя баланс между хранением и вычислением все равно был недостижим.

Примечание: Надо отметить, что хайп вокруг «неструктурированных» данных сыграл злую шутку: «озеро» нередко быстро превращалось в «болото», то есть обычную свалку разнородных данных, где уже мало кто помнит, что это за данные и чьи они.

На смену Data Lake пришла концепция Data Lakehouse — подход к хранению и обработке данных, который сочетает достоинства Data Lakes (озер данных) и Data Warehouses, а также позволяет преодолеть ограничения предыдущих решений. Технической предпосылкой появления Data Lakehouse стала де-факто стандартизация протокола S3 от Amazon: хранение (Storage) отделилось от вычислений (Compute) и появилась возможность брать ровно столько ресурсов, сколько нужно.

Примечание: Безусловно, идеальный баланс достигается только в публичных облаках, но даже при On-premise-инсталляции существенно повышается оптимальность, ведь у любого S3-хранилища масштабирование является врожденным свойством. А в случае DWH с масштабированием были проблемы: зачастую систему строили с запасом по мощности в 3–5 раз, чтобы получить нужный объем хранения.

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

Для работы с Data Lakehouse были разработаны и специализированные SQL-движки, которые умеют разбирать и оптимизировать запрос, а затем извлекать данные из источника. Одним из таких стал Trino — механизм для федеративной и интерактивной аналитики разнородных источников данных, который предлагает множество коннекторов к существующим системам, умеет работать с S3 и Iceberg. 

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

Собственно, наша задача для хакатона и предлагала поработать с относительно простым Data Lakehouse.

Задача от VK Tech

В рамках проблематики поиска новых способов оптимизации хранения данных мы и предложили задачу студентам, ее выбрали 40+ команд. Для всех мы подключили личные кабинеты VK Cloud с доступом к сервисам Data Platform, где уже был развернут сервис Trino и подготовлены данные в S3-совместимом хранилище Object Storage. 

В основе задачи лежал классический TPC-H-тест для аналитических систем с оптимизацией SQL-запросов и реструктуризацией данных. Несмотря на то что сама концепция теста была придумана давно, на деле проблематика, заложенная в вопросы теста, изменились мало, за исключением того, что кратно увеличились объемы обрабатываемых данных. 

Ключевой целью была оптимизация скорости запросов.

Пойти здесь можно было двумя путями.

• Изменить сами SQL-запросы. В тесте они сформулированы довольно прямолинейно, а в современных редакциях языка SQL допустимы более сложные конструкции. Более того, поскольку Trino является Open-Source-инструментом, можно было заглядывать в его исходники, чтобы подсмотреть, как движок оптимизирует запросы. 

• Изменить структуру хранения данных, то есть применить партиционирование. По умолчанию данные разбиты просто на части, по мере наливки. Самая большая таблица содержала примерно 750 Гб сырых данных и, конечно же, представляла собой большое количество файлов. При анализе запросов можно было сделать вывод, что разбиение на файлы нужно делать по определенным ключам, а не так, как захотелось системе по умолчанию.

Критерий оценки результатов очевидный: чем быстрее запрос, тем лучше. 

В задании описывались некоторые запросы и их опорное время, которое измерили на модельном стенде. Скорость запросов требовалось улучшить как минимум на 25%, но для победы требовалось ставить еще более амбициозную цель в 50%. Данные специально были хаотичными, чтобы прогресс был заметнее. 

Примечание: Если в процессе решения задачи результат команды был ниже или равен Baseline в 7 минут, команда жюри помогала перенаправить работу участников.

Результаты выполнения запросов можно было отслеживать в самом Trino через сводную панель или детализацию.

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

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

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

Примечание: Джоины — операции, которые используются для объединения строк из нескольких таблиц.

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

Например, в первой стадии мы фильтруем большую часть данных, а потом используем результаты в более высокоуровневом запросе. 

Надо отметить, что студентам также предстояло столкнуться с Common Table Expressions в Trino, чтобы дать больше свободы — на случай, если кому-то захочется использовать рекурсивные запросы. Ожидалось, что студенты будут активно менять физическое разбиение таблиц: данные те же самые, но в файлы сгруппированы иначе. Например, можно было распределить блоки по дате/месяцу/году операции. 

Мы предполагали, что в решении будут один или два файла: 

• Опциональный, который описывает новую структуру таблиц (его нужно накатить, чтобы выполнить второй файл).

• Файл с запросом. Если участники переписывают запрос так, чтобы он лучше работал и учитывал особенности планировщика, то можно было обойтись и без первого файла. 

Поправка на время

Может показаться, что вместе с популяризацией нейросетей какие-то соревновательные форматы уходят в прошлое. Тем не менее мы специально не стали менять запросы от оригинального теста TPC-H, хоть и понимали, что условный ChatGPT может быть использован для попытки оптимизации. Отчасти это обусловлено тем, что простейшие способы изменения запроса, которые выдаст нейросеть, не дают прироста производительности: оптимизатор Trino достаточно хорош в этом вопросе и победить его непросто. 

На практике же максимум результатов давало именно изменение разбиения данных, что применили далеко не все команды. 

Что в итоге

Подготовленный VK Cloud кластер со всем набором инструментов позволил студентам реализовать End-to-end-сценарии обработки больших данных. Участники смогли попробовать технологии и оценить их роль в общем контексте решения задачи. 

На выполнение задачи у участников хакатона было два дня. После дедлайна и проверки команды были приглашены на очную защиту своих работ.

Абсолютным победителем в решении кейса компании VK Tech стала команда Курского государственного университета Gopher go data (Антон Файтельсон, Егор Гришанов, Иван Матанцев), которая оптимизировала выполнение наибольшего количества запросов с минимальным суммарным временем их выполнения.

Лучшими командами на площадках вузов-партнеров стали Hugging_Hands (ЮФУ, Ростов-на-Дону), Zlaya, but zaya (ТПУ, Томск), ZOV (САФУ, Архангельск), «Филькина грамота» (РТУ МИРЭА, Москва), «Магистры Кода» (КубГТУ, Краснодар), Kickback-povorot (ИГУ, Иркутск).

Победителей ждал приятный приз: мы предоставили каждой команде по 30 000 бонусных рублей в облаке VK Cloud на развитие их проектов.

Поздравляем всех победителей и желаем дальнейших успехов!

Подписывайтесь на каналы VK Cloud | Новости сервисов, Вокруг Kubernetes в VK и Данные на стероидах, чтобы всегда быть в курсе обновлений. Обсуждайте новости и рабочие моменты в чате пользователей платформы.