Многие системы данных утверждают, что предоставляют «унифицированную модель для пакетной и потоковой передачи» — Apache Spark, Apache Flink, Apache Beam и т. д. Это заманчивое обещание, поскольку оно предполагает, что конвейер может быть написан один раз и использоваться как для пакетной обработки исторических данных, и потоковая обработка новых данных. К сожалению, между этим обещанием и реальностью часто существует значительный разрыв.

Эти «унифицированные» системы данных предоставляют набор инструментов для операций по манипулированию данными, которые могут применяться к различным источникам и приемникам и выполняться как одноразовое пакетное задание или как онлайн-потоковое задание. В зависимости от платформы некоторые источники могут не работать или могут вести себя неожиданно по-разному в зависимости от режима выполнения. Используя компоненты в этом наборе инструментов, можно написать пакетный конвейер или потоковый конвейер. Точно так же можно использовать Java для написания веб-сервера или приложения для Android, поэтому Java — это «унифицированный инструментарий для Интернета и Android».

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

  1. Обслуживание: Поддерживайте актуальные значения функций в каком-либо быстром и высокодоступном хранилище, таком как Redis или DynamoDB, чтобы их можно было использовать для применения модели в рабочей среде.
  2. Предоставление возможности вычисления обучающих примеров в определенные моменты времени требует более глубокой поддержки упорядоченной обработки и путешествий во времени, чем это обеспечивается существующими вычислительными моделями. Feature Engine должен обеспечивать поддержку вычислительных функций (включая объединения) в определенные моменты времени, зависящие от данных. Делаем ее конфигурируемой В дополнение к вычислению обучающих примеров нам нужно иметь возможность использовать ту же логику для вычисления текущих значений при применении модели. Если мы используем Spark, это может означать упаковку логики для вычисления функций прогнозирования в библиотечные методы, а затем наличие двух конвейеров — один, который работает с историческими данными (в определенные отфильтрованные моменты времени) для создания обучающих примеров, а другой, который применяет ту же логику к потоку данных. Это требует систематизации некоторых обучающих примеров в первом конвейере, что, вероятно, захотят контролировать специалисты по данным, поскольку выбор обучающих примеров влияет на качество модели. Таким образом, достижение настраиваемости путем запекания в конвейер создает некоторые трудности для изменения выбора обучающего примера. Мы также увидим, что наличие потокового конвейера для последних значений создает проблемы с обновлением конвейера. Это обсуждается более подробно в следующем разделе. Feature Engine должен поддерживать вычисление обучающих примеров на основе исторических данных и последних результатов на основе комбинации исторических и потоковых данных. В идеале специалистам по данным легко настроить выбор обучающих примеров. Обновление конвейеров с отслеживанием состояния Потоковые конвейеры полезны для поддержания последних значений функций в целях применения модели. К сожалению, потоковые конвейеры, которые вычисляют агрегаты, сохраняют состояние. Это управляемое изнутри — фактически почти скрытое — состояние часто затрудняет обновление конвейера. Рассмотрим простую агрегацию, такую ​​как «сумма сумм транзакций за последнюю неделю». Когда эта функция добавлена ​​в систему, состояние недоступно. Можно использовать две стратегии. Во-первых, мы могли вычислить начальное состояние, взглянув на данные за последнюю неделю. Это хорошо, потому что позволяет сразу же использовать новую функцию, но может потребовать либо хранения данных в потоке как минимум за одну неделю, либо более сложного конвейера потоковой передачи, который сначала считывает события из исторических данных, а затем переключается на чтение из потока. Это может привести к конвейеру функций, который будет выглядеть примерно так, как показано ниже. Обратите внимание, что работа по конкатенации и дедупликации будет зависеть от того, как хранятся ваши данные, и это может потребоваться для каждого источника или типа данных.

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

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

Обучающие примеры и последние значения

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

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

Обучающие примеры вычислений

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

Как только мы решим эту задачу, все может стать еще сложнее. Представьте, что мы хотим использовать информацию из социальной сети пользователя как часть прогноза. Например, мы хотим найти значения из 5 наиболее частых контактов, поскольку мы подозреваем, что если они уйдут, то пользователь с большей вероятностью уйдет. Теперь у нас есть проблема — когда мы вычисляем признаки для Боба (используя данные до 7 февраля), он может искать признаки для Алисы. В этом случае эти вычисленные значения для Алисы должны включать данные до 7 февраля. Мы видим, что простая стратегия фильтрации событий для каждого пользователя не работает. Если мы используем Spark, нам может потребоваться либо скопировать все события от Алисы к Бобу, а затем отфильтровать, но это быстро приводит к взрывному росту данных. Альтернативой может быть попытка обработки данных, упорядоченных по времени, но это быстро приводит к снижению производительности, поскольку Spark и другие не очень подходят для вычисления значений в каждый момент времени.

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

Feature Engine должен обеспечивать поддержку для вычисления новейших функций таким образом, чтобы их можно было легко обновлять. Идеальная стратегия позволяет немедленно использовать новую функцию, а состояние заполняется из исторических данных. Быстрая итерация Еще одна вещь, о которой Data Engineer легко забыть, — это итеративный и исследовательский процесс создания и улучшения моделей. Для этого требуется возможность определять новые функции, обучать модели, чтобы увидеть, как они работают, и, возможно, экспериментировать с их использованием в производстве. Все это требует предоставления специалистам по данным возможности экспериментировать с новыми функциями в ноутбуке. Новые функции должны использоваться в производственной среде с минимальными усилиями. Feature Engine должен позволять Data Scientist быстро экспериментировать с различными функциями и обучающими примерами в рамках итеративного создания модели. Механизмы функций Мы увидели, почему вычисление функций для машинного обучения создает уникальный набор проблем, которые невозможно решить с помощью простой унифицированной модели. Вы можете построить это самостоятельно на существующих инструментах обработки данных, и в этом случае вышеизложенное предоставляет дорожную карту для вещей, о которых вам следует подумать, когда вы собираете строительные блоки. Альтернативой является выбор Feature Engine, который предоставляет упомянутые возможности из коробки. Это позволяет предоставить специалистам по обработке и анализу данных простой способ разработки новых функций и их развертывания, требующий минимального вмешательства от специалистов по обработке данных или вообще не требующий его вмешательства. В свою очередь, это позволяет вам сосредоточиться на предоставлении более качественных данных специалистам по данным.

На что обратить внимание при выборе Feature Engine: 1. Feature Engine должен поддерживать вычислительные функции (включая соединения) в определенные моменты времени, зависящие от данных.

2. Feature Engine должен поддерживать вычисление обучающих примеров на основе исторических данных и последних результатов на основе комбинации исторических и потоковых данных. В идеале специалистам по данным легко настроить выбор обучающих примеров.

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

4. Feature Engine должен позволять Data Scientist быстро экспериментировать с различными функциями и обучающими примерами в рамках итеративного создания модели.

Kaskada Feature Engine предоставляет все это и многое другое. Точные вычисления на определенный момент времени обеспечивают точные вычисления без утечек, в том числе с соединениями. Один запрос может вычислять функции в выбранные моменты времени для обучающих примеров. Тот же запрос может быть выполнен для получения только окончательных значений для обслуживания. Запросы работают с историческими и потоковыми данными, при этом используются добавочные вычисления, чтобы гарантировать, что для обновления значений функций необходимо обрабатывать только новые данные. Функции, созданные в записной книжке, могут быть развернуты в рабочей среде без каких-либо изменений. Во время исследования Data Scientist может работать с подмножеством сущностей, чтобы уменьшить размер набора данных, не влияя на совокупные значения.

Для получения дополнительной информации свяжитесь с нами по @ [email protected]

Почему вам нужен унифицированный механизм функций, а не унифицированная модель вычислений