Некоторые компании изучают Snowpark и Snowflake и рекомендуют своим инженерам, ученым и аналитикам данных отказаться от DataBricks. Чтобы успешно использовать Snowpark, вы должны сначала понять его синтаксис.

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

Snowpark не оптимизирует и не ускоряет выполнение сверх того, что вы можете сделать с механизмом Snowflake SQL. Производительность похожа. Однако при сравнении ядра за ядром механизм Snowflake SQL намного быстрее, чем Spark, при обычных рабочих нагрузках ETL или Query. 2–10x — это то, что мы видим в среднем на вычислениях аналогичного размера.

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

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

Snowpark выполняет две важные задачи:

1. Позволяет выполнять действия по обработке данных с использованием Python и фреймов данных без использования SQL в коде. Методы обработки данных Snowpark вполне сопоставимы с PySpark в том смысле, что 80–90% вашего кода останутся без изменений, если вы решите переключиться.

Фреймы данных Snowpark запускаются удаленно на бессерверных вычислительных кластерах MPP Snowflake. Это означает, что среда Python, в которой выполняется код, не влияет на фактическую производительность выполнения, независимо от того, сколько данных обрабатывается или насколько мала/медленна машина, на которой выполняется код (локальный ноутбук, ноутбук Jupiter, бесплатный облачный ноутбук). как colab), они будут работать точно так же, как Snowflake выполняет все вычисления. Snowpark делает это, преобразовывая операции кадра данных в ANSI,-SQL в парадигме отложенного выполнения и отправляя их в Snowflake для выполнения.

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

2. Что происходит, когда ваши фреймы данных выполняют действия, недоступные SQL? В качестве примера рассмотрим выполнение кода Python, который вызывает библиотеку NLTK для анализа настроений. Snowpark упакует код вашей пользовательской функции Python, а также все сторонние библиотеки, загрузит их в Snowflake и зарегистрирует в качестве определяемых пользователем функций в этом сценарии. Фреймы данных затем будут использовать эти функции как часть своих операций, где код Python запускается непосредственно на вычислительных кластерах Snowflake и распараллеливается с использованием всех ядер в кластере. Чем быстрее он работает, тем больше кластер. Ваш код не нужно настраивать, настраивать или оптимизировать.

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

Поддержка Python была введена как на уровне планировщика запросов, так и на уровне механизма выполнения, поэтому планировщик запросов Snowflake полностью осведомлен о природе UDF и способах оптимизации для него.

Имея дело со Сноупарком в Snowflake, помните о следующих моментах:

  1. Он рекламировался как позволяющий вам выполнять работу, связанную с данными, с использованием Python внутри Snowflake, позволяя вам получать доступ к вычислениям Snowflake и вашим данным без необходимости перемещать данные за пределы Snowflake для анализа данных и работы с данными.
  2. Вы не можете выполнять чистый Python, Pandas, Numpy или любой другой библиотечный код в среде Snowflake. Вы должны сначала переписать существующий код в синтаксисе Snowpark, прежде чем запускать его на Snowflake, если вы хотите использовать Snowpark вместе с ним.
  3. Фрейм данных Snowpark и кадр данных Pandas — это не одно и то же. Snowpark удобен для подключения к Snowflake, извлечения данных, сохранения этих данных в виде кадра данных Pandas (что нарушает точку зрения Snowpark), выполнения работы в pandas/python, а затем использования Snowpark для передачи результирующих данных и таблиц обратно в Snowflake, если это необходимо. .
  4. Когда дело доходит до получения данных из Snowflake и помещения данных обратно в Snowflake, это лучше и проще, чем алхимия SQL.
  5. В Snowpark UDF похожа на функцию снежинки, написанную на Python, а не на SQL. Это не сильно. Параметризованный UDF по своей природе сложно реализовать.
  6. Они дают базовую UDF в качестве «примера», но когда вы попытаетесь применить ее в реальном приложении, вы обнаружите, что ее не хватает. Пользовательскую функцию, которая требует передачи имен столбцов в качестве входных данных для вычисления результата, например, будет почти сложно создать с помощью Snowpark.
  7. Ограничение. Если вы хотите перейти на другую систему, вы не можете просто запустить свой код Snowpark в новой системе так же, как вы можете запускать обычный код Pandas или Python в любой системе Python.
  8. Зависимость — синтаксис Snowpark НЕОБХОДИМО Snowflake для инициализации и использования. В отличие от Pandas или другой библиотеки Python, вы можете выполнять без Snowflake.

Snowpark — это конструктор запросов, а не замена Spark. Он может выполнять еще несколько действий, требующих использования сторонних библиотек.

Поддержка Snowflakes Python кажется неэффективной. Инженеры по обработке данных/ученые/аналитики хотели запустить несколько моделей машинного обучения напрямую, потому что объем операций ввода-вывода для извлечения данных из Snowflake был высоким, и они не предоставили нужных нам библиотек.

Дополнительные советы. Если ваше представление о безопасности данных —

  1. Вы должны создать правильные правила IAM, чтобы никто не мог получить доступ к файлам паркета в облачном хранилище непосредственно за пределами платформы Lakehouse.
  2. Вы должны настроить дополнительное шифрование, используя мои ключи для хранения.
  3. Вам необходимо настроить дополнительную службу каталогов UNITY
  4. Вы должны применять правила RBAC к каждому элементу данных.
  5. Вы должны убедиться, что используемые кластеры имеют правильную версию и правильно настроены, чтобы они не игнорировали правила RBAC и не раскрывали все данные всем.
  6. Платформу необходимо настроить таким образом, чтобы пользователи не могли создавать или изменять свои собственные кластеры, чтобы избежать создания типов кластеров, не поддерживающих RBAC.