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

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

Первый вопрос, который мы можем задать: наши потребители — люди или машины? Разница важна, потому что эти два объекта очень по-разному обрабатывают информацию! Человеку может понадобиться информационная панель с контекстной информацией и визуальной последовательностью; машине потребуются четкие API для отправки запросов и получения ответов.

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

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

Поэтому нам нужна серверная база данных, созданная для таких рабочих нагрузок. В идеале это должна быть транзакционная база данных, которая может обрабатывать запросы на уровне строк с высокой скоростью и/или пропускной способностью. Хотя Delta отлично справляется с аналитическими запросами на основе столбцов, здесь она может не подойти. Вместо этого в нашем примере можно использовать транзакционную базу данных, такую ​​как Cosmos DB или Dynamo DB.

Другой вопрос, который мы могли бы рассмотреть, заключается в том, нужен ли нам Spark для постобработки прогнозов нашей модели. Обычно это хорошая идея, если у нас есть большие объемы данных, которые выиграют от распределенной обработки. Если это так, то мы можем использовать API Delta Lake (доступные в Python, Scala и Java) для чтения, записи и иной обработки наших данных. Если нам не нужно создавать сеанс Spark (возможно, наши данные могут поместиться в ОЗУ одной машины), мы можем обойти Spark и рассмотреть ряд других собственных коннекторов.

Одним из доступных нативных коннекторов является Delta Rust API, который позволяет Rust низкоуровневый доступ к дельта-таблицам. Библиотека, разработанная инженерами Scribd, была разработана специально, потому что инженеры не хотели накладных расходов на создание сеанса Spark только для доступа к небольшим объемам данных из Delta для передачи их приложениям. Rust API также имеет оболочку Python, что означает, что разработчики, предпочитающие использовать Python, также могут получать доступ к дельта-таблицам без Apache Spark.

Аналогичным образом разработчики Java и Scala могут использовать автономные соединители Delta для чтения и записи из таблиц Delta через соединение JDBC. Однако имейте в виду, что этот метод будет более медленным и менее масштабируемым, чем чтение из одной из транзакционных баз данных, о которых мы упоминали ранее.

Экосистема разъема Delta Lake разнообразна. Есть варианты почти для каждого популярного языка программирования, а также разные сценарии развертывания и разные аудитории. Хотя это разнообразие велико, в нем также может быть трудно ориентироваться. Надеюсь, эта блок-схема даст вам отправную точку для оценки ваших вариантов!