27 сентября 2018 г., Copyright Brandfolder, Inc., 2018 г.
Введение
Предоставление нашим клиентам (Brandfolder) творческого опыта, основанного на данных, включало расширение чрезвычайно хорошего продукта путем создания платформы машинного обучения для беспрепятственного предоставления набора данных продуктов. Работая в условиях очень небольшой команды с небольшим бюджетом и короткими сроками, было важно использовать проекты с открытым исходным кодом (Apache Spark¹, Apache Zeppelinи Databricks mlflow²) и облачных сервисов (Google Cloud Platform — GCP³), чтобы собрать воедино архитектурную головоломку, которая начинается с приема необработанных данных приложения и событий в одном конец, а на другой выводит службу машинного обучения (ML). В последующем описании этой архитектуры ML описываются причины выбора и его выводы.
Поскольку наши сервисы уже были размещены на Google Cloud Platform (GCP) и, что более важно, их набор сервисов, IAM и ловушки безопасности хорошо подходили для наших нужд, мы решили создать всю платформу машинного обучения на GCP. Это включало использование следующих сервисов GCP: CloudSQL (база данных реплики (БД) Postgres рабочей БД приложения Postgres), Cloud Storage (как озеро данных), Dataproc (как вычислительный кластер HDFS), Composer (в качестве планировщика пакетных заданий), Pub-Sub (в качестве магистрального конвейера данных), Container Registry (для хранения образов докеров) и Kubernetes Engine (в качестве оркестратора контейнеров).
Обзор архитектуры машинного обучения
Как показано на рисунке ниже, транзакционные данные и события с платформы Brandfolder сначала удаляются с помощью процедуры извлечения, преобразования и загрузки (ETL) с использованием Spark в Dataproc и сохраняются в виде секционированного паркета⁴ файлов (с разделением в основном по столбцам года, месяца и дня) в GCS, которая служит озером данных. Затем функции ML извлекаются из данных, хранящихся в GCS, с использованием пользовательских написанных пользовательских функций (UDF) для каждого типа функций. Функции, извлеченные таким образом с помощью Spark, сохраняются в глобальном хранилище функций. Это хранилище функций также размещено в GCS в разделенном формате parquet , как и данные с ETL. Любая комбинация функций, хранящихся в хранилище функций, служит входными данными для построения моделей ML, которые служат для различных вариантов использования ML. Библиотеки MLLib в Spark в настоящее время используются для создания первых вариантов использования машинного обучения. Затем параметры модели, метрики и артефакты различных экспериментов с моделями записываются в конечную точку сервера mlflow, размещенную в Kubernetes. mlflow служит механизмом управления версиями и обслуживания модели. Модель с лучшими показателями выбирается для оценки новых данных с использованием клиентов mlflow как в пакетном режиме, так и в режиме реального времени. Затем для каждого варианта использования создается служба машинного обучения gRPC⁵, которая получает данные в режиме реального времени, извлекает функции с помощью пользовательских функций функций, использует модель, полученную из mlflow, для оценки функций и, наконец, возвращает результат оценки. в ответ на вызов клиента службы машинного обучения. В оставшейся части этого блога мы углубимся в особенности некоторых частей этой архитектуры.
Озеро данных, файловая структура и формат файлов. GCS служит озером данных, в котором в конечном итоге хранятся все данные как из заданий ETL Spark, так и из заданий конвейерного архивирования. данные для аналитики. Кроме того, эти данные хранятся в виде разделенных на разделы файлов parquet, при этом количество файлов parquet в каждом разделе кратно общему количеству рабочих ядер в кластере Dataproc (мы используйте переразметку 64 файлов перед записью разделенных на разделы файлов parquet для 4 рабочих процессов с 4 ядрами в каждой конфигурации). Хранение данных в виде секционированных файлов parquet в сжатом столбцовом формате хранения хорошо подходит для оптимальной аналитической обработки с помощью Spark.
Один инструмент, много применений: Apache Spark в приведенной выше архитектуре используется для ETL-обработки данных из приложений, извлечения функций из таблиц в озере данных, а также для построения моделей машинного обучения с использованием извлеченных функций. Spark также используется в службе ML gRPC, где модель mlflow извлекается как определяемая пользователем функция (UDF) Spark для оценки входящих данные. Артефакт модели mlflow использует вариант Spark, который сохраняет объект конвейера, который включает преобразование таких функций, как документы в токены и токены в word2vec и т. д. Также стоит упомянуть, что индексы данных, разделенных на обучающие и тестовые наборы, также сохраняются в GCS, чтобы можно было вернуться к ним в случае необходимости для дальнейшего исследования. Кроме того, во время цикла разработки модели мы используем Zeppelin Notebooks с открытым исходным кодом с интерпретатором Spark, чтобы итерировать алгоритмы перед их реализацией.
Артефакты UDF функций: функции, которые используются для извлечения функций, хранятся как UDF Spark в GCS. Это служит двойной цели: извлечению функций в пакетном режиме, а также извлечению функций из нового актива для оценки на онлайн-этапе. По мере разработки новых типов функций для моделирования специалист по данным упаковывает их как функции Spark UDF и добавляет их в хранилище артефактов UDF.
Планирование пакетных заданий с помощью Airflow⁶. Google Cloud Composer (Airflow) используется для планирования различных пакетных заданий Spark. Airflow позволяет планировать задания с помощью направленных ациклических графов (DAG), в которых логика выполнения заданий может быть закодирована в структурированном формате. Ниже показан пример DAG, где задание с тремя этапами запускается только в том случае, если два других задания завершены:
Параметры, метрики и артефакты модели машинного обучения: mlflow служит платформой для регистрации параметров, метрик и артефактов модели для каждого запуска модели. На рисунке ниже показана доска mlflow для конкретной модели, которая запускалась ежедневно (версия данных для каждого запуска модели — это исторические данные до момента запуска модели). Это упрощает выбор версии модели для развертывания (из множества запусков), которая может основываться на показателях модели и времени запуска модели. mlflow упрощает сравнение различных запусков модели, что упрощает выбор модели для развертывания. Кроме того, артефакты каждого запуска модели сохраняются с помощью mlflow в GCS и могут быть извлечены на этапе обслуживания модели, как описано в следующем абзаце.
Обслуживание моделей машинного обучения с помощью mlflow. Выбирается модель с лучшими показателями для оценки новых данных, получаемых службой машинного обучения. С этой целью guid эксперимента, выбранного для развертывания с сервера mlflow, передается службе машинного обучения. Клиент mlflow в службе извлекает эту модель и использует ее для преобразования и оценки новых данных для создания прогнозного столбца. Фрагмент этой процедуры показан ниже:
import mlflow
mlflow.set_tracking_uri("http://mlserver.com")
# pulling down the mlflow model with the run_id
model = mlflow.spark.load_model("model",
run_id='92fc7a8324f24371963f66c9ed901748')
# score newdata_df using model and create a prediction column
scored_df = model.transform(newdata_df).select('prediction')
Краткое примечание о языке, CI/CD и репозитории артефактов. В приведенной выше архитектуре машинного обучения полностью используется Python. В частности, API Python для Spark (pyspark) используется для всех заданий Spark. Группы DAG Airflow изначально написаны на Python, и библиотеки mlflow также написаны на Python. Обычные библиотеки Python, такие как numpy, pandas, scikit-learn и matplotlib, широко используются в различных частях проекта. Служба ML gRPC также написана на python (оболочка шлюза Go используется, если службе gRPC необходимо поддерживать интерфейс REST). CircleCI используется для создания, тестирования и развертывания артефактов, когда изменения фиксируются в Github. Артефакты, то есть основной файл Python и дополнительные файлы, передаются в GCS, который служит хранилищем артефактов.
Заключительные замечания
Выше мы описали первую платформу ML, которая позволяет нам быстро перебирать различные варианты использования и выпускать функции продукта, основанные на данных, на платформе Brandfolder. Это также помогает нам модулировать различные функции на платформе, например, специалист по данным может сосредоточиться на разработке UDF функций, написании сценариев извлечения функций, разработке моделей и развертывании их на сервере mlflow для варианта использования. представляет интерес.
Следующие шаги в наших итерациях включают мониторинг предсказания живой модели (чтобы убедиться, что она ведет себя так, как мы ожидаем в производственной среде), выпуск новых моделей посредством затенения (т.е. запуск рядом с действующей моделью, чтобы увидеть, как она работает, но не запуск в производственной среде) также постепенное развертывание новых моделей с использованием A / B-тестирования характеристик новых и старых моделей, а также с учетом отзывов пользователей. Существует также вариант использования потоковой передачи, в котором мы планируем использовать структурированную потоковую передачу Spark для вычисления статистики по мере поступления данных и запуска аномалий, если статистика отклоняется от нормы (которая поддерживается как состояние). Мы также работаем над развертыванием моделей глубоких нейронных сетей, разработанных для неструктурированных данных с использованием TensorFlow⁷ на GCP, используя ту же архитектуру, что описана выше. Следите за нашими приключениями в этих проектах в будущем сообщении в блоге.
использованная литература
[4] https://parquet.apache.org/
[5] https://grpc.io/
