Машинное обучение

Слой данных для машинного обучения

Вы, вероятно, слышали историю о том, что 80% времени специалиста по машинному обучению уходит на очистку данных. Независимо от того, соответствует ли этот миф действительности, неизменным остается то, что данные находятся в центре задачи машинного обучения от начала и до конца. Будь то построение RAG-конвейеров, fine-tuning, обучение собственной модели или оценка качества модели — в основе каждой из этих задач лежат данные.

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

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

Существуют два основных измерения этих рисков:

1. Затраты на обучение, сопровождение и переключение

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

2. Дублирование данных и затраты на их передачу

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

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

Исследование данных

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

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

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

ClickHouse, в свою очередь, является хранилищем данных в реальном времени, поэтому пользователи получают преимущества лидирующей в индустрии скорости выполнения запросов для аналитических вычислений. Кроме того, ClickHouse обеспечивает высокую производительность «из коробки» и не прячет критически важные функции ускорения запросов за более высокими ценовыми планами. ClickHouse также может выполнять запросы к данным непосредственно из объектного хранилища или data lake, поддерживая распространенные форматы, такие как Iceberg, Delta Lake и Hudi. Это означает, что независимо от того, где находятся ваши данные, ClickHouse может выступать в роли объединяющего слоя доступа и вычислений для ваших нагрузок машинного обучения.

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

Исследование данных

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

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

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

ClickHouse, в свою очередь, является хранилищем данных в реальном времени, поэтому пользователи получают преимущества лидирующей в индустрии скорости выполнения запросов для аналитических вычислений. Кроме того, ClickHouse обеспечивает высокую производительность «из коробки» и не прячет критически важные функции ускорения запросов за более высокими ценовыми планами. ClickHouse также может выполнять запросы к данным непосредственно из объектного хранилища или озер данных, поддерживая распространенные форматы, такие как Iceberg, Delta Lake и Hudi. Это означает, что независимо от того, где находятся ваши данные, ClickHouse может выступать в роли объединяющего слоя доступа и вычислений для ваших нагрузок машинного обучения.

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

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

Подготовка данных и извлечение признаков

Данные затем подготавливаются: очищаются, трансформируются и используются для извлечения признаков, по которым модель будет обучаться и оцениваться. Этот компонент иногда называют конвейером генерации или извлечения признаков, и это ещё один срез уровня данных для машинного обучения, где часто появляются новые инструменты. Участники рынка MLOps, такие как Neptune и Hopsworks, демонстрируют множество различных продуктов для трансформации данных, которые используются для оркестрации подобных конвейеров. Однако, поскольку это отдельные инструменты по отношению к базе данных, с которой они работают, они могут быть хрупкими и вызывать сбои, которые приходится устранять вручную.

В отличие от этого, трансформации данных легко выполняются непосредственно в ClickHouse с помощью материализованных представлений. Они автоматически инициируются при вставке новых данных в исходные таблицы ClickHouse и используются для простого извлечения, трансформации и модификации данных по мере их поступления — устраняя необходимость самостоятельно строить и мониторить индивидуальные конвейеры. Когда этим трансформациям требуются агрегации по полному набору данных, который может не помещаться в память, использование ClickHouse гарантирует, что вам не придётся пытаться приспособить этот шаг к работе с датафреймами на локальной машине. Для тех наборов данных, которые удобнее анализировать локально, ClickHouse local является отличной альтернативой, наряду с chDB, позволяя пользователям использовать ClickHouse совместно со стандартными библиотеками данных Python, такими как Pandas.

Обучение и оценка

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

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

В экосистеме хранилищ признаков ClickHouse может выступать в роли:

Источника данных — Благодаря возможности выполнять запросы или приём данных более чем в 70 различных форматах файлов, включая форматы озёр данных, такие как Iceberg и Delta Lake, ClickHouse является идеальным долгосрочным хранилищем для хранения или запроса данных. Благодаря разделению хранения и вычислений с помощью объектного хранилища, ClickHouse Cloud дополнительно позволяет хранить данные неограниченно долго — с возможостью уменьшать вычислительные ресурсы или полностью останавливать их для минимизации затрат. Гибкие кодеки в сочетании с колоночным хранением и упорядочиванием данных на диске максимизируют степень сжатия, минимизируя тем самым необходимый объём хранилища. Пользователи могут легко комбинировать ClickHouse с озёрами данных, используя встроенные функции для выполнения запросов к данным непосредственно в объектном хранилище.

Движка преобразований — SQL предоставляет естественный способ декларативного описания трансформаций данных. При расширении аналитическими и статистическими функциями ClickHouse эти трансформации становятся лаконичными и оптимизированными. Помимо применения к таблицам ClickHouse, когда ClickHouse используется как хранилище данных, табличные функции позволяют писать SQL‑запросы к данным, хранящимся в таких форматах, как Parquet, на диске или в объектном хранилище, а также даже в других хранилищах данных, таких как Postgres и MySQL. Полностью параллельный движок исполнения запросов в сочетании с колоночным форматом хранения позволяет ClickHouse выполнять агрегации по петабайтам данных за секунды — в отличие от трансформаций над датафреймами в памяти, пользователи не ограничены объёмом памяти. Более того, материализованные представления позволяют трансформировать данные во время вставки, перенося вычислительную нагрузку с момента выполнения запроса на момент загрузки данных. Эти представления могут использовать тот же набор аналитических и статистических функций, идеально подходящих для анализа и суммирования данных. Если существующих аналитических функций ClickHouse недостаточно или необходимо интегрировать пользовательские библиотеки, пользователи могут также использовать пользовательские функции (User Defined Functions, UDFs).

Offline feature store

Offline feature store используется для обучения моделей. Как правило, это означает, что сами признаки формируются пакетными конвейерами преобразования данных (как описано в разделе выше), и обычно нет жёстких требований по задержке к доступности этих признаков.

Благодаря возможности читать данные из нескольких источников и применять преобразования с помощью SQL-запросов, результаты этих запросов также могут сохраняться в ClickHouse с помощью операторов INSERT INTO SELECT. Поскольку преобразования часто группируются по идентификатору сущности и возвращают несколько столбцов в качестве результата, механизм вывода схемы ClickHouse может автоматически определить необходимые типы на основе этих результатов и создать соответствующую схему таблицы для их хранения. Функции генерации случайных чисел и статистического семплирования позволяют эффективно итерировать и масштабировать данные до миллионов строк в секунду для подачи в конвейеры обучения моделей.

Часто признаки представлены в таблицах с временной меткой, указывающей значение для сущности и признака в конкретный момент времени. Как описано ранее, конвейерам обучения часто требуется состояние признаков в определённые моменты времени и в разрезе групп. Разреженные индексы ClickHouse позволяют быстро фильтровать данные для удовлетворения запросов «среза по времени» и фильтров отбора признаков. В то время как другие технологии, такие как Spark, Redshift и BigQuery, полагаются на медленные, сохраняющие состояние оконные подходы для определения состояния признаков в конкретный момент времени, ClickHouse поддерживает запрос ASOF (as-of-this-time) LEFT JOIN и функцию argMax. Помимо упрощения синтаксиса, этот подход обладает высокой производительностью на больших наборах данных благодаря использованию алгоритма сортировки и слияния. Это позволяет быстро собирать группы признаков, сокращая время подготовки данных перед обучением.

Online feature store

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

Как база данных для аналитики в реальном времени, ClickHouse может обслуживать высококонкурентные нагрузки по запросам с низкой задержкой. Хотя для этого данные, как правило, должны быть денормализованы, это соответствует способу хранения групп признаков, используемых как при обучении, так и при инференсе. Важно, что ClickHouse способен обеспечивать такую производительность запросов при высокой нагрузке на запись благодаря дереву слияния журналов (log-structured merge tree). Эти свойства необходимы онлайн-хранилищу, чтобы поддерживать признаки в актуальном состоянии. Поскольку признаки уже доступны в оффлайн-хранилище, их можно легко материализовать в новые таблицы либо в том же кластере ClickHouse, либо в другом инстансе с помощью уже имеющихся возможностей, например remoteSecure. Интеграции с Kafka — либо через решение exactly-once Kafka Connect, либо через ClickPipes в ClickHouse Cloud — также делают потребление потоковых данных из стриминговых источников простым и надёжным.

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

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

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

Inference

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

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

Vector store

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

Основная операция в векторной базе данных — это «поиск по схожести» (similarity search), позволяющий находить векторы, которые «наиболее близки» друг к другу согласно выбранной математической метрике. Векторные базы данных стали популярны, потому что они используют специальные приёмы, делающие этот процесс — сравнение векторов — максимально быстрым. Как правило, эти методы подразумевают, что сравнение векторов выполняется приблизительно, а не путём сравнения входного вектора с каждым сохранённым вектором.

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

Observability

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

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