Предварительная обработка данных для ML: варианты и рекомендации

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

В этом документе предполагается, что вы знакомы с BigQuery , Dataflow , Vertex AI и API TensorFlow Keras .

Второй документ, «Предварительная обработка данных для машинного обучения с помощью Google Cloud» , представляет собой пошаговое руководство по реализации конвейера tf.Transform .

Введение

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

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

Размер наборов обучающих данных для реальных моделей машинного обучения может легко достигать одного терабайта (ТБ) или превышать его. Следовательно, вам нужны крупномасштабные платформы обработки данных для эффективной и распределенной обработки этих наборов данных. Когда вы используете модель ML для прогнозирования, вам необходимо применить те же преобразования, которые вы использовали для обучающих данных, к новым точкам данных. Применяя те же преобразования, вы представляете живой набор данных модели ML так, как ожидает модель.

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

В этом документе также представлен обзор TensorFlow Transform ( tf.Transform ), библиотеки для TensorFlow, которая позволяет определять преобразование данных как на уровне экземпляра, так и полнопроходное с помощью конвейеров предварительной обработки данных. Эти конвейеры выполняются с помощью Apache Beam и создают артефакты, которые позволяют применять те же преобразования во время прогнозирования, что и при обслуживании модели.

Предварительная обработка данных для машинного обучения

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

Инженерия данных по сравнению с разработкой функций

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

Необработанные данные (или просто данные )

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

Подготовленные данные

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

Инженерные функции

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

На следующей диаграмме (рис. 1) показаны этапы подготовки предварительно обработанных данных:

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

Операции предварительной обработки

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

Для структурированных данных операции предварительной обработки данных включают следующее:

• Очистка данных: удаление или исправление записей с поврежденными или недопустимыми значениями из необработанных данных, а также удаление записей, в которых отсутствует большое количество столбцов.
• Выбор и секционирование экземпляров: выбор точек данных из входного набора данных для создания обучающих, оценочных (проверочных) и тестовых наборов . Этот процесс включает в себя методы повторяемой случайной выборки, избыточной выборки классов меньшинства и стратифицированного разделения.
• Настройка функции: улучшение качества функции для машинного обучения, включая масштабирование и нормализацию числовых значений, вменение пропущенных значений, обрезку выбросов и корректировку значений, которые имеют искаженное распределение.
• Преобразование признаков: преобразование числового признака в категориальный признак (посредством сегментирования ) и преобразование категориальных признаков в числовое представление (посредством быстрого кодирования, обучения с помощью подсчетов , встраивания разреженных признаков и т. д.). Некоторые модели работают только с числовыми или категориальными функциями, тогда как другие могут обрабатывать функции смешанного типа. Даже если модели обрабатывают оба типа, они могут извлечь выгоду из разных представлений (числовых и категориальных) одной и той же функции.
• Извлечение функций: сокращение количества функций за счет создания более мощных представлений данных меньшей размерности с использованием таких методов, как PCA , извлечение встраивания и хеширование .
• Выбор функций: выбор подмножества входных функций для обучения модели и игнорирование нерелевантных или избыточных с использованием методов фильтра или оболочки . Выбор объектов также может включать простое удаление объектов, если в объектах отсутствует большое количество значений.
• Построение функций: создание новых функций с использованием типичных методов, таких как полиномиальное разложение (с использованием одномерных математических функций) или пересечение функций (для регистрации взаимодействия функций). Функции также могут быть созданы с использованием бизнес-логики из области использования ML.

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

• Для текстовых документов: стемминг и лемматизация , расчет TF-IDF и извлечение n-грамм , поиск по внедрению.
• Для изображений: обрезка, изменение размера, обрезка, размытие по Гауссу и канареечные фильтры.
• Для всех типов данных (включая текст и изображения): трансферное обучение , при котором все слои полностью обученной модели, кроме последних, рассматриваются как этап разработки функций.

Детализация предварительной обработки

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

Операции предварительной обработки и преобразования можно разделить на следующие категории в зависимости от степени детализации операций:

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

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

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

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

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Полнопроходные преобразования включают в себя следующее:

  • Числовые характеристики масштабирования MinMax с использованием минимумов и максимумов , вычисленных из набора обучающих данных.
  • Числовые характеристики стандартного масштабирования (нормализация z-показателя) с использованием μ и σ, вычисленные на наборе обучающих данных.
  • Группирование числовых характеристик с использованием квантилей.
  • Вменение пропущенных значений с использованием медианы (числовые признаки) или моды (категориальные признаки).
  • Преобразование строк (номинальных значений) в целые числа (индексы) путем извлечения всех различных значений (словаря) входного категориального признака.
  • Подсчет появления термина (значения признака) во всех документах (экземплярах) для расчета TF-IDF.
  • Вычисление PCA входных объектов для проецирования данных в пространство меньшей размерности (с линейно зависимыми объектами).

  Вам следует использовать только обучающие данные для вычисления таких статистических данных, как μ, σ, min и max . Если вы добавите данные тестирования и оценки для этих операций, вы потеряете информацию из данных оценки и тестирования для обучения модели. Это повлияет на надежность результатов испытаний и оценок. Чтобы гарантировать, что вы применяете согласованное преобразование ко всем наборам данных, вы используете одну и ту же статистику, рассчитанную на основе обучающих данных, для преобразования данных тестирования и оценки.

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

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

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

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

Конвейер машинного обучения в Google Cloud

В этом разделе обсуждаются основные компоненты типичного сквозного конвейера для обучения и обслуживания моделей TensorFlow ML в Google Cloud с использованием управляемых сервисов. Также обсуждается, где можно реализовать различные категории операций предварительной обработки данных, а также общие проблемы, с которыми вы можете столкнуться при реализации таких преобразований. В разделе «Как работает tf.Transform» показано, как библиотека TensorFlow Transform помогает решить эти проблемы.

Архитектура высокого уровня

На следующей диаграмме (рис. 2) показана высокоуровневая архитектура типичного конвейера машинного обучения для обучения и обслуживания моделей TensorFlow. Метки A, B и C на схеме относятся к различным местам конвейера, где может выполняться предварительная обработка данных. Подробная информация об этих шагах представлена ​​в следующем разделе.

Трубопровод состоит из следующих этапов:

1. После импорта необработанных данных табличные данные сохраняются в BigQuery, а другие данные, такие как изображения, аудио и видео, сохраняются в Cloud Storage. Во второй части этой серии в качестве примера используются табличные данные, хранящиеся в BigQuery.
2. Разработка данных (подготовка) и разработка функций выполняются в масштабе с использованием Dataflow. В результате этого выполнения создаются готовые к машинному обучению наборы для обучения, оценки и тестирования, которые хранятся в облачном хранилище. В идеале эти наборы данных хранятся в виде файлов TFRecord , оптимизированного формата для вычислений TensorFlow.
3. Пакет обучения модели TensorFlow передается в программу Vertex AI Training, которая использует предварительно обработанные данные из предыдущих шагов для обучения модели. Результатом этого шага является обученная сохраненная модель TensorFlow, которая экспортируется в Cloud Storage.
4. Обученная модель TensorFlow развертывается в Vertex AI Prediction как сервис с REST API, чтобы его можно было использовать для онлайн-прогнозирования. Эту же модель можно использовать и для пакетных заданий прогнозирования.
5. После развертывания модели как REST API клиентские приложения и внутренние системы могут вызывать API, отправляя запросы с некоторыми точками данных и получая ответы от модели с прогнозами.
6. Для организации и автоматизации этого конвейера вы можете использовать Vertex AI Pipelines в качестве планировщика для запуска этапов подготовки данных, обучения модели и развертывания модели.

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

Где сделать предварительную обработку

На рисунке 2 метки A, B и C показывают, что операции предварительной обработки данных могут выполняться в BigQuery, Dataflow или TensorFlow. В следующих разделах описывается, как работает каждый из этих вариантов.

Вариант А: BigQuery

Обычно в BigQuery реализуется логика для следующих операций:

• Выборка: случайный выбор подмножества данных.
• Фильтрация: удаление нерелевантных или недействительных экземпляров.
• Разделение: разделение данных для создания обучающих, оценочных и тестовых наборов.

Скрипты BigQuery SQL можно использовать в качестве исходного запроса для конвейера предварительной обработки Dataflow, который является этапом обработки данных на рисунке 2. Например, если система используется в Канаде, а в хранилище данных есть транзакции со всего мира, фильтрация по Получить данные обучения только для Канады лучше всего в BigQuery. Разработка функций в BigQuery проста и масштабируема и поддерживает реализацию преобразований функций на уровне экземпляра и исторических агрегаций.

Однако мы рекомендуем использовать BigQuery для разработки функций только в том случае, если вы используете свою модель для пакетного прогнозирования (оценки) или если функции предварительно вычисляются в BigQuery, но сохраняются в хранилище функций Vertex AI для использования во время онлайн-прогнозирования. Если вы планируете развернуть модель для онлайн-прогнозирования и у вас нет разработанной функции в онлайн-хранилище функций, вам придется реплицировать операции предварительной обработки SQL для преобразования необработанных точек данных, генерируемых другими системами. Другими словами, вам необходимо реализовать логику дважды: один раз в SQL для предварительной обработки обучающих данных в BigQuery, а второй раз в логике приложения, которое использует модель для предварительной обработки точек онлайн-данных для прогнозирования.

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

Если вы используете свою модель только для пакетного прогнозирования (например, с помощью пакетного прогнозирования Vertex AI), и если ваши данные для оценки получены из BigQuery, вы можете реализовать эти операции предварительной обработки как часть SQL-скрипта BigQuery. В этом случае вы можете использовать один и тот же сценарий SQL предварительной обработки для подготовки данных обучения и оценки.

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

Вариант Б: поток данных

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

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

На следующей диаграмме (рис. 3) показана роль потока данных в обработке потоковых данных для прогнозов, близких к реальному времени.

Как показано на рисунке 3, во время обработки события, называемые точками данных, передаются в Pub/Sub . Поток данных использует эти точки данных, вычисляет функции на основе агрегатов с течением времени, а затем вызывает развернутый API модели машинного обучения для прогнозирования. Затем прогнозы отправляются в исходящую очередь Pub/Sub. Прогнозы из Pub/Sub могут использоваться последующими системами, такими как мониторинг или управление, или они могут быть отправлены обратно (например, в виде уведомлений) исходному запрашивающему клиенту. Прогнозы также можно хранить в хранилище данных с низкой задержкой, например Cloud Bigtable, для извлечения в реальном времени. Cloud Bigtable также можно использовать для накопления и хранения этих агрегатов в реальном времени, чтобы при необходимости их можно было просматривать для прогнозирования.

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

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

Поток данных можно использовать для выполнения полнопроходного преобразования путем вычисления необходимой статистики в масштабе. Однако эту статистику необходимо где-то хранить, чтобы ее можно было использовать во время прогнозирования для преобразования точек данных прогнозирования. Используя библиотеку TensorFlow Transform ( tf.Transform ), вы можете напрямую встроить эту статистику в модель, а не хранить ее где-то еще. Этот подход объясняется позже в разделе «Как работает tf.Transform» .

Вариант C: TensorFlow

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

• Реализация всей логики преобразования уровня экземпляра в функциях input_fn и в serving_fn . Функция input_fn подготавливает набор данных, используя API tf.data.Dataset для обучения модели. Функция serving_fn получает и подготавливает данные для прогнозов.
• Размещение кода преобразования непосредственно в вашей модели TensorFlow с помощью слоев предварительной обработки Keras или создания пользовательских слоев .

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

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

Проблемы предварительной обработки

Ниже приведены основные проблемы реализации предварительной обработки данных:

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

  Если преобразования станут частью самой модели, можно будет легко обрабатывать преобразования на уровне экземпляра, как описано ранее в Варианте C: TensorFlow . В этом случае интерфейс обслуживания модели ( serving_fn ) ожидает необработанные данные, в то время как модель внутренне преобразует эти данные перед вычислением выходных данных. Преобразования такие же, как и те, которые применялись к необработанным точкам данных обучения и прогнозирования.

• Полнопроходные преобразования . Вы не можете реализовать полнопроходные преобразования, такие как преобразования масштабирования и нормализации, в вашей модели TensorFlow. При полнопроходных преобразованиях некоторые статистические данные (например, max и min значения для масштабирования числовых признаков) необходимо заранее вычислить на обучающих данных, как описано в Варианте B: Поток данных . Затем значения необходимо где-то сохранить, чтобы использовать их во время обслуживания модели для прогнозирования для преобразования новых точек необработанных данных в виде преобразований на уровне экземпляра, что позволяет избежать перекоса при обслуживании обучения. Вы можете использовать библиотеку TensorFlow Transform ( tf.Transform ), чтобы напрямую встраивать статистику в вашу модель TensorFlow. Этот подход объясняется позже в разделе «Как работает tf.Transform» .

• Предварительная подготовка данных для повышения эффективности обучения . Реализация преобразований на уровне экземпляра как части модели может снизить эффективность процесса обучения. Это ухудшение происходит потому, что одни и те же преобразования неоднократно применяются к одним и тем же обучающим данным в каждую эпоху. Представьте, что у вас есть необработанные данные обучения с 1000 функциями, и вы применяете сочетание преобразований на уровне экземпляра для создания 10 000 функций. Если вы реализуете эти преобразования как часть своей модели и затем передаете модели необработанные данные обучения, эти 10 000 операций применяются N раз в каждом экземпляре, где N — количество эпох. Кроме того, если вы используете ускорители (GPU или TPU), они простаивают, пока ЦП выполняет эти преобразования, что не является эффективным использованием ваших дорогостоящих ускорителей.

  В идеале данные обучения преобразуются перед обучением с использованием метода, описанного в разделе «Вариант Б: поток данных» , где 10 000 операций преобразования применяются только один раз для каждого экземпляра обучения. Преобразованные данные обучения затем представляются модели. Никакие дальнейшие преобразования не применяются, и ускорители все время заняты. Кроме того, использование Dataflow помогает предварительно обрабатывать большие объемы данных в любом масштабе, используя полностью управляемый сервис.

  Предварительная подготовка данных обучения может повысить эффективность обучения. Однако реализация логики преобразования вне модели (подходы, описанные в Варианте A: BigQuery или Варианте B: Dataflow ) не решает проблему перекоса между обучением и обслуживанием. Если вы не сохраните спроектированную функцию в хранилище функций, которая будет использоваться как для обучения, так и для прогнозирования, логика преобразования должна быть где-то реализована, чтобы применяться к новым точкам данных, поступающим для прогнозирования, поскольку интерфейс модели ожидает преобразованные данные. Библиотека TensorFlow Transform ( tf.Transform ) может помочь вам решить эту проблему, как описано в следующем разделе.

Как работает tf.Transform

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

На следующей диаграмме (рис. 4) показано, как библиотека tf.Transform предварительно обрабатывает и преобразует данные для обучения и прогнозирования. Этот процесс описан в следующих разделах.

Преобразование данных обучения и оценки

Вы предварительно обрабатываете необработанные данные обучения с помощью преобразования, реализованного в API-интерфейсах tf.Transform Apache Beam, и запускаете их в масштабе в Dataflow. Предварительная обработка происходит в следующие этапы:

• Фаза анализа. На этапе анализа необходимая статистика (например, средние значения, дисперсии и квантили) для преобразований с отслеживанием состояния вычисляется на обучающих данных с помощью полнопроходных операций. На этом этапе создается набор артефактов преобразования, включая граф transform_fn . Граф transform_fn — это граф TensorFlow, логика преобразования которого представлена ​​в виде операций уровня экземпляра. Он включает в себя статистику, вычисленную на этапе анализа, в виде констант.
• Фаза преобразования. На этапе преобразования график transform_fn применяется к необработанным обучающим данным, где вычисленная статистика используется для обработки записей данных (например, для масштабирования числовых столбцов) на уровне экземпляра.

Подобный двухэтапный подход решает проблему предварительной обработки при выполнении полнопроходных преобразований.

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

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

Прикрепите преобразования к экспортируемой модели

Как уже отмечалось, график transform_fn , созданный трубопроводом tf.Transform , хранится в виде экспортируемого графика TensorFlow. Экспортируемый график состоит из логики преобразования в качестве операций на уровне экземпляра, а также всех статистических данных, рассчитанных в полноходных преобразовании, как константы графика. Когда обученная модель экспортируется для обслуживания, график transform_fn прикреплен к SaveedModel как часть своей функции serving_fn .

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

График transform_fn , который теперь является частью модели, применяет всю логику предварительной обработки в входящей точке данных. Он использует хранимые константы (например, μ и σ, чтобы нормализовать числовые особенности) в работе на уровне экземпляра во время прогнозирования. Следовательно, график transform_fn преобразует необработанную точку данных в преобразованный формат. Преобразованный формат - это то, что ожидается внутренним интерфейсом модели для получения прогнозирования, как показано на рисунке 4.

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

Краткое описание вариантов предварительной обработки

В следующей таблице приведены варианты предварительной обработки данных, которые обсуждал этот документ. В таблице «N/A» означает «не применимо».

^* С TensorFlow, преобразования, такие как пересечение, встраивание и однопольное кодирование, должны быть выполнены в виде столбцов feature_columns .

Что дальше

• Чтобы реализовать конвейер tf.Transform и запустить его с помощью DATAFLOW, прочтите вторую часть этой серии, предварительная обработка данных для ML с использованием преобразования TensorFlow .
• Возьмите специализацию Coursera на ML с TensorFlow в Google Cloud .
• Узнайте о лучших практиках для ML Engineering в правилах ML .
• Для получения дополнительных эталонных архитектур, диаграмм и лучших практик изучите облачные решения TFX .

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

Этот документ предполагает, что вы знакомы с BigQuery , DataFlow , Vertex AI и API Tensorflow Keras .

Второй документ, предварительная обработка данных для ML с Google Cloud , предоставляет пошаговое руководство по реализации трубопровода tf.Transform .

Введение

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

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

Размер обучающих наборов данных для реальных моделей ML может легко быть равен или больше одного терабайта (TB). Следовательно, вам нужны крупномасштабные структуры обработки данных, чтобы эффективно и распределять эти наборы данных. Когда вы используете модель ML для прогнозирования, вы должны применять те же преобразования, которые вы использовали для учебных данных в новых точках данных. Применяя те же преобразования, вы представляете живой набор данных для модели ML, как ожидается модель.

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

В этом документе также представлен обзор преобразования TensorFlow ( tf.Transform ), библиотеки для Tensorflow, которая позволяет вам определить как преобразование данных на уровне экземпляра, так и полноразмерное преобразование данных с помощью трубопроводов предварительной обработки данных. Эти трубопроводы выполняются с помощью Beam Apache , и они создают артефакты, которые позволяют вам применять те же преобразования во время предсказания, что и при обслуживании модели.

Данные предварительной обработки для ML

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

Техника данных по сравнению с инженерией функций

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

Необработанные данные (или просто данные )

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

Подготовленные данные

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

Инженерные функции

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

Следующая диаграмма, рисунок 1, показывает шаги, которые участвуют в подготовке предварительных данных:

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

Предварительная обработка

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

Для структурированных данных операции предварительной обработки данных включают следующее:

• Очищение данных: удаление или исправление записей, которые повреждены или неверные значения из необработанных данных, и удаление записей, в которых отсутствует большое количество столбцов.
• Выбор и разделение экземпляров: выбор точек данных из набора данных ввода для создания обучения, оценки (проверка) и наборов тестирования . Этот процесс включает в себя методы повторяемой случайной выборки, классов меньшинств, перенасыщенной и стратифицированной разделы.
• Настройка функций: улучшение качества функции для ML, которое включает в себя масштабирование и нормализацию численных значений, вменение пропущенных значений, выбросов выреза и регулировки значений, которые имеют искаженные распределения.
• Преобразование функций: преобразование числовой функции в категориальную функцию (посредством ведра ) и преобразование категориальных функций в числовое представление (через одножележное кодирование, обучение с подсчетами , разреженные элементы функций и т. Д.). Некоторые модели работают только с числовыми или категориальными функциями, в то время как другие могут обрабатывать функции смешанного типа. Даже когда модели обрабатывают оба типа, они могут извлечь выгоду из разных представлений (числовых и категориальных) одной и той же функции.
• Извлечение функций: уменьшение количества функций за счет создания более низких, более мощных представлений данных с использованием таких методов, как PCA , извлечение встраивания и хэширование .
• Выбор функций: выбор подмножества входных функций для обучения модели, и игнорирование нерелевантных или избыточных избыточных средств, используя методы фильтра или обертки . Выбор функций также может включать в себя простое сброс функций, если в функциях отсутствует большое количество значений.
• Конструкция функций: создание новых функций с использованием типичных методов, таких как расширение полинома (с использованием одномерных математических функций) или пересечения объектов (для захвата взаимодействий функций). Особенности также могут быть построены с использованием бизнес -логики из домена варианта использования ML.

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

• Для текстовых документов: Stemming and Lemmatization , расчет TF-IDF и экстракция N-грамма , поиск внедрения.
• Для изображений: обрезка, изменение размера, обрезка, размытие Гаусса и канарейские фильтры.
• Для всех типов данных (включая текстовые и изображения): переносное обучение , которое рассматривает все, но нормальные слои полностью обученной модели как этап инженерии.

Предварительная обработка гранулярности

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

Операции предварительной обработки и преобразования могут быть классифицированы следующим образом, на основе операции гранулярности:

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

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

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

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

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Полнопроходные преобразования включают следующее:

  • Численные функции масштабирования MINMAX с использованием MIN и MAX , рассчитанного из учебного набора данных.
  • Стандартное масштабирование (нормализация Z-показателя) численные особенности с использованием μ и σ, рассчитанных на учебном наборе данных.
  • Ведение численных функций с использованием квантилей.
  • Вменение пропущенных значений с использованием медианных (числовых функций) или режима (категориальные функции).
  • Преобразование строк (номинальные значения) в целые числа (индексы) путем извлечения всех различных значений (словарь) входной категориальной функции.
  • Подсчет возникновения термина (значение функции) во всех документах (экземплярах) для расчета для TF-IDF.
  • Вычисление PCA входных функций для проецирования данных в более низкое пространство (с линейно -зависимыми функциями).

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

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

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

  Точнее, когда вы готовите учебные данные, если агрегированное значение нет в необработанных данных, значение создается на этапе разработки данных. Необработанные данные обычно хранятся в базе данных с форматом (entity, timestamp, value) . В предыдущих примерах entity является идентификатором сегмента маршрута для маршрутов такси и идентификатором части двигателя для сбоя двигателя. Вы можете использовать окно -операции для вычисления (entity, time_index, aggregated_value_over_time_window) и использовать функции агрегации в качестве ввода для обучения вашей модели.

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

ML Pipeline на Google Cloud

В этом разделе обсуждаются основные компоненты типичного сквозного трубопровода для обучения и обслуживания моделей Tensorflow ML на Google Cloud с использованием управляемых сервисов. В нем также обсуждается, где вы можете реализовать различные категории операций предварительной обработки данных, и общие проблемы, с которыми вы можете столкнуться при реализации таких преобразований. Раздел «Как TF.Transform Works» показывает, как библиотека преобразования TensorFlow помогает решать эти проблемы.

Архитектура высокого уровня

На следующей диаграмме, на рисунке 2, показана архитектура высокого уровня типичного конвейера ML для обучения и обслуживания моделей тензора. Метки A, B и C на диаграмме относятся к различным местам в трубопроводе, где может происходить предварительная обработка данных. Подробная информация об этих шагах представлена ​​в следующем разделе.

Конвейер состоит из следующих шагов:

1. После того, как необработанные данные импортируются, табличные данные хранятся в BigQuery, а другие данные, такие как изображения, аудио и видео, хранятся в облачном хранилище. Вторая часть этой серии использует табличные данные, хранящиеся в Бигкери, в качестве примера.
2. Инженерная инженерия данных (подготовка) и инженерия функций выполняются в масштабе с использованием DATAFLOW. Это выполнение создает готовые к ML обучение, оценку и тестовые наборы, которые хранятся в облачном хранилище. В идеале эти наборы данных хранятся в виде файлов TFRECORD , который является оптимизированным форматом для вычислений TensorFlow.
3. Пакет Tensorflow Model Trainer Package представлен в Training Vertex AI, в котором используются предварительно обработанные данные из предыдущих шагов для обучения модели. Вывод этого шага - это обученная тензорафальная сохраненная модель , которая экспортируется в облачное хранилище.
4. Обученная модель Tensorflow развернута в прогнозировании AI Vertex в качестве услуги, которая имеет API REST, чтобы ее можно было использовать для онлайн -прогнозов. Та же модель также может быть использована для заданий по прогнозированию партий.
5. После того, как модель развернута в качестве API REST, клиентские приложения и внутренние системы могут вызывать API, отправив запросы с некоторыми точками данных и получая ответы от модели с прогнозами.
6. Для организации и автоматизации этого трубопровода вы можете использовать трубопроводы Vertex AI в качестве планировщика для вызова подготовки данных, обучения модели и этапов развертывания моделей.

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

Где делать предварительную обработку

На рисунке 2 этикетки A, B и C показывают, что операции предварительной обработки данных могут происходить в BigQuery, DataFlow или TensorFlow. В следующих разделах описывается, как работает каждый из этих вариантов.

Вариант A: BigQuery

Как правило, логика реализована в BigQuery для следующих операций:

• Отбор проб: случайным образом выбор подмножества из данных.
• Фильтрация: удаление нерелевантных или недействительных экземпляров.
• Разделение: разделение данных для получения обучения, оценки и тестов.

BigQuery SQL Scripts можно использовать в качестве исходного запроса для обеспечения обработки DataFlow Prefelocessing, который представляет собой этап обработки данных на рисунке 2. Например, если система используется в Канаде, а хранилище данных имеет транзакции со всего мира, фильтруя в Получить данные обучения только для Канады лучше всего выполнять в BigQuery. Инженерная инженерия в BigQuery проста и масштабируется, и поддерживает реализацию уровня экземпляра и исторических агрегаций.

Тем не менее, мы рекомендуем вам использовать BigQuery для инженерии функций, только если вы используете свою модель для прогнозирования партии (оценка), или если функции предварительно выпускаются в BigQuery, но хранятся в магазине Vertex AI Features, которые будут использоваться во время онлайн -прогноза. Если вы планируете развернуть модель для онлайн -прогнозов, и если у вас нет инженерной функции в онлайн -магазине функций, вам необходимо воспроизвести операции предварительной обработки SQL, чтобы преобразовать необработанные точки данных, которые генерируют другие системы. Другими словами, вам необходимо дважды реализовать логику: один раз в SQL для предварительного обработки данных обучения в BigQuery, а также во второй раз в логике приложения, которая потребляет модель для предварительного обработки данных онлайн -данных для прогнозирования.

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

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

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

Вариант B: DataFlow

Как показано на рисунке 2, вы можете реализовать вычислительно дорогие операции предварительной обработки в Beam Apache и запустить их в масштабе, используя DataFlow. DataFlow является полностью управляемой службой автоматической мастерской для обработки пакетов и потоковых данных. Когда вы используете DataFlow, вы также можете использовать внешние специализированные библиотеки для обработки данных, в отличие от BigQuery.

DataFlow может выполнять преобразования на уровне экземпляра, а также исторические преобразования агрегации в реальном времени. В частности, если ваши модели ML ожидают входной функции, такой как total_number_of_clicks_last_90sec , функции окна Apache Beam могут вычислять эти функции на основе агрегации значений Windows of Windows of Realtime (потоковые) событий (например, нажимают события). В предыдущем обсуждении гранулярности трансформаций это называлось «историческими агрегациями во время обучения, но агрегации в реальном времени во время прогноза».

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

Как показано на рисунке 3, во время обработки, события, называемые точками данных , принимаются в паб/суб . DataFlow потребляет эти точки данных, вычисляет функции, основанные на агрегатах с течением времени, а затем вызывает развернутый API ML Model для прогнозов. Затем прогнозы отправляются в исходящий паб/суб -очередь. Из Pub/sub прогнозы могут быть использованы с помощью систем, таких как мониторинг или контроль, или их можно отодвинуть (например, в качестве уведомлений) к исходному запросу клиента. Прогнозы также можно хранить в хранилище данных с низкой задержкой, например, Cloud Bigtable для извлечения в реальном времени. Cloud Bigtable также может использоваться для накопления и хранения этих агрегаций в реальном времени, чтобы их можно было смотреть, когда это необходимо для прогнозирования.

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

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

DataFlow может использоваться для выполнения полноходного преобразования путем вычисления требуемой статистики в масштабе. Тем не менее, эти статистические данные должны храниться где -то для использования во время прогнозирования для преобразования точек данных прогнозирования. Используя библиотеку TensorFlow Transform ( tf.Transform ), вы можете непосредственно встроить эту статистику в модель вместо того, чтобы хранить их в другом месте. Этот подход объясняется позже в том, как работает TF.Transform .

Вариант C: TensorFlow

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

• Реализация всей логики преобразования на уровне экземпляра в функции input_fn и в функции serving_fn . Функция input_fn готовит набор данных с использованием API tf.data.Dataset для обучения модели. Функция serving_fn получает и готовит данные для прогнозов.
• Поместите код преобразования непосредственно в вашу модель TensorFlow, используя керас -предварительные слои или создавая пользовательские слои .

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

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

Проблемы предварительной обработки

Ниже приведены основные проблемы реализации предварительной обработки данных:

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

  Если преобразования становятся частью самой модели, он может быть простым для обработки преобразований на уровне экземпляра, как описано ранее в варианте C: TensorFlow . В этом случае интерфейс модели, обслуживающей модель (функция serving_fn ), ожидает необработанные данные, в то время как модель внутренне преобразует эти данные перед вычислением вывода. Преобразования такие же, как и те, которые были применены к необработанным точкам данных обучения и прогнозирования.

• Полнопроходные преобразования . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Что дальше

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

Введение

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )

The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.

Prepared data

The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.

Engineered features

The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

• Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
• Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
• Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
• Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
• Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
• Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
• Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

• For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
• For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
• For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

• Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

  These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

• Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

  For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Full-pass transformations include the following:

  • MinMax scaling numerical features using min and max computed from the training dataset.
  • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
  • Bucketizing numerical features using quantiles.
  • Imputing missing values using the median (numerical features) or the mode (categorical features).
  • Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
  • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
  • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

  You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

• Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

• Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

  More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

  When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

High-level architecture

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

The pipeline consists of the following steps:

1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

• Sampling: randomly selecting a subset from the data.
• Filtering: removing irrelevant or invalid instances.
• Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

• Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
• Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

• Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

  If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

• Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

Что дальше

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .