Прошедший Snowflake Summit был полон анонсов. В этой записи в блоге я хочу поделиться некоторыми идеями о двух из них. Snowpark Python и нативные приложения. Удивительно, что я присоединился к Snowflake пару лет назад и был очень впечатлен возможностями Создания лучших моделей машин с использованием облака данных Snowflake. Это было хорошо, но с тех пор невероятно видеть все инновации, появившиеся в Snowflake. В то время я использовал Python на клиентском слайде и коннекторе Python. Теперь с помощью Snowpark Python у нас есть возможности использовать фреймы данных, которые переводят все преобразования в Snowflake, и, что еще более эффективно, определять хранимые процедуры, пользовательские функции (UDF) и пользовательские табличные функции (UDTF). которые выполняются на стороне Snowflake, используя всю производительность, эластичность и плату за использование Snowflake Data Cloud Platform. Эти функции упростят перенос большего количества рабочих нагрузок машинного обучения в Snowflake.

Облако данных развивается вместе с нативными приложениями, как было объявлено на саммите. С новой платформой приложений Snowflake Native Application Framework, которая в настоящее время находится в частной предварительной версии, разработчики могут создавать приложения и монетизировать их на Snowflake Marketplace, а потребители могут безопасно устанавливать и запускать эти приложения непосредственно в своих экземплярах Snowflake, уменьшая потребность в перемещении данных. . В этом конкретном примере я реализовал собственное приложение, которое может запускать машинное обучение для анализа мошенничества с кредитными картами. Он основан на этой предыдущей работе Building Fast and Furious: Streamlining your Data Pipelines и идее добавления совместного машинного обучения. Используя новые возможности Snowpark Python, я теперь могу внедрить всю логику в хранимые процедуры и пользовательские функции и запустить все это в Snowflake.

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

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

Собственное приложение будет обслуживать процедуры fe_training() и fe_scoring(). Потребитель создаст собственную базу данных на основе общего доступа bank1_app_db от поставщика. База данных будет иметь установщик, предоставленный Приложением, со всеми объектами, которые будут созданы на стороне потребителя. Это будет включать создание схемы с именем app, где процедура fe_scoring() создаст таблицу с результатом оценки.

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

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

Это весь код Python, который будет выполняться на стороне потребителя. Преимущество среды Native App заключается в том, что процедура сможет считывать данные из обеих учетных записей Snowflake, но эти данные не будут доступны за пределами процедуры. Поставщик не может проникнуть в какие-либо данные от потребителя, поскольку он только записывает в схемы потребителей, а потребитель не может украсть какие-либо данные у поставщика, поскольку именно приложение контролирует видимость их объектов. Поставщик не сможет записывать или обновлять какие-либо данные обратно в учетную запись поставщика.

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

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

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

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

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

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

Карлос.-