Snowpark Python 운영: 1부

이 게시물의 1부에서는 Snowpark Python 코드를 프로덕션에 적용하는 것과 관련된 몇 가지 고유한 문제를 간략하게 설명하고, 구성 요소에 대해 자세히 논의하고, Snowpark Python으로 빌드할 때 따라야 할 몇 가지 코드 설계 원칙을 간략하게 설명합니다.

향후 2부에서는 Snowpark Python으로 작업하는 Python 개발자를 위한 관련 CI/CD 개념에 대해 설명합니다.

핵심 과제

프로덕션에서 Snowpark 코드를 관리하는 것이 프로덕션에서 기존/레거시 코드를 관리하는 것과 다른 이유는 무엇입니까? 여러 면에서 그렇지 않습니다. 실제로 Snowflake로 구동되는 애플리케이션 및 기능을 구축하는 데 이미 익숙하고 저장 프로시저, 사용자 정의 함수 등과 같은 기능을 활용하는 경우(SQL 또는 다른 언어의 Snowpark) Snowpark Python 코드를 관리하는 것은 오늘날 동일한 작업을 수행하는 방식과 근본적으로 다르지 않습니다. Snowflake의 서버 측 Python 런타임에는 몇 가지 환경적 제약이 있지만 이는 Snowpark에서 Javascript 및 Java 기능이 제한되는 방식과 유사하므로 기존 Snowflake 기능에 대해 따르는 것과 동일한 원칙과 관행이 적용됩니다. 스노우파크 파이톤.

차이점과 과제는 Python을 기반으로 하지만 Snowflake를 기반으로 하지 않는 팀과 애플리케이션에서 더욱 분명해집니다. Snowflake가 기존 아키텍처 내에서 데이터 소스 및/또는 싱크 역할을 하는 경우에도 Snowflake 외부에서 실행되는 Python 기능(서버리스 또는 클라우드 호스팅 VM 등)과 Snowpark Python에 구축된 기능에는 몇 가지 중요한 차이점이 있습니다. 알아 두십시오. 기본적으로 Snowpark에 구축된 기능은 Python 코드일 뿐이며, 현재 팀에서 기존 코드 베이스를 관리하기 위해 사용하는 것과 동일한 많은 관행과 도구가 여전히 관련이 있습니다. Snowpark 기반 구축과 관련된 주요 고려 사항은 최종 코드와 애플리케이션이 완전히 관리되는 SaaS 플랫폼에 배포된다는 사실에서 비롯됩니다. 따라서 코드가 작동해야 하는 인프라 및 컴퓨팅 프레임워크는 사용자의 제어 및 재량에 완전히 개방되지 않습니다. 또한 이 애플리케이션은 데이터 플랫폼과 완전히 통합되어 많은 이점을 제공하지만 대부분의 애플리케이션이 개발되는 것과는 패러다임이 다르기 때문에 권장되는 디자인 패턴이 다릅니다. Python 코드를 SQL 우선 환경에 배포하면 데이터의 종류와 모듈, 함수 등 간에 데이터를 전달할 수 있는 방법에 제한이 있습니다. Snowpark 애플리케이션은 지속적으로 실행되도록 설계된 다른 애플리케이션과도 다릅니다. 24 /7. Snowpark는 주문형 및/또는 예약/오케스트레이션 작업 및 애플리케이션에 더 적합합니다.

스노우파크 구성품

광범위한 용어인 Snowpark Python은 근본적으로 다르지만 밀접하게 결합된 두 가지 구성 요소를 나타냅니다. 하나는 클라이언트 데이터 프레임 API로, Python 패키지로 제공되며 모든 Python 환경(Python 3.8 지원은 2022년 11월 7일 기준 GA)에 설치할 수 있으며 모든 Python 애플리케이션 등에서 활용하여 데이터 프레임 변환을 수행할 수 있습니다. Snowflake 컴퓨팅으로. 이와는 대조적으로 Snowpark에는 데이터와 함께 바로 실행될 수 있도록 Snowflake 관리 런타임에 더 많은 임의의 Python 코드를 배포할 수 있는 서버 측 런타임도 있습니다. Python 코드를 서버 측 런타임에 배포하고 실행하는 방법에 대한 여러 가지 메커니즘이 있습니다. 이에 대해서는 아래에서 자세히 설명합니다. 이 구분이 중요한 이유는, Snowpark Python에 대해 광범위하게 해결해야 하는 공통된 문제가 있지만 이러한 각 구성 요소에는 이 문서 전체에서 해결하고자 하는 구체적이고 고유한 문제도 있습니다. 일반적으로 우리는 Snowpark Python을 참조하여 일반적으로 두 구성 요소를 모두 포함하고 클라이언트 및/또는 데이터 프레임 API는 설치 가능한 Python 라이브러리를 참조하고 서버 측 런타임은 Snowflake 관리 Python 실행 환경을 참조합니다. 이 게시물에서는 핵심 구성 요소를 요약하지만 다음을 참조해야 합니다. 서버 측 런타임은 Snowflake 관리 Python 실행 환경을 나타냅니다. 이 게시물에서는 핵심 구성 요소를 요약하지만 다음을 참조해야 합니다. 서버 측 런타임은 Snowflake 관리 Python 실행 환경을 나타냅니다. 이 게시물에서는 핵심 구성 요소를 요약하지만 다음을 참조해야 합니다.추가 세부 정보, 코드 예제, 설명서 등을 보려면 Python용 Snowpark 개발자 가이드 .

클라이언트 데이터 프레임 API

Snowpark 클라이언트 데이터 프레임 API는 Python 커널을 실행할 수 있고 Snowflake 계정에 연결할 수 있는 모든 환경에 설치할 수 있는 Python 라이브러리입니다(참고: 현재 데이터 프레임 API는 Python 3.8만 호환됨). Dataframe API는 쿼리 푸시다운, 변환 등을 Snowflake의 관리형 컴퓨팅 환경으로 수행하기 위한 데이터프레임 스타일의 Python 구문을 제공합니다.

기본적으로 Snowpark API는 일반적인 SQL 작업에 해당하는 Python 메서드를 PySpark Dataframe API에 대한 친숙한 구문으로 제공하며 현재 PySpark에서 수행할 수 있는 기능과 상당히 중복됩니다. Snowpark는 PySpark와 근본적으로 다른 백엔드 컴퓨팅 엔진을 사용하지만 구문 및 기능적으로는 PySpark Dataframe API와 매우 유사하게 보이고 느껴질 것이라는 점에 유의해야 합니다. API는 Snowflake 내부의 테이블, 뷰 등에 대한 포인터인 Snowpark 데이터 프레임에서 작동합니다. Snowpark API 호출에 해당하는 작업은 Snowflake 가상 웨어하우스에서 느리게 실행됩니다. 이것은 아니오Snowpark 데이터 프레임 작업은 Python 클라이언트의 컴퓨팅 환경에서 직접 실행되므로 클라이언트의 컴퓨팅 요구 사항이 매우 낮을 수 있습니다. Snowpark는 또한 Snowpark 데이터 프레임을 클라이언트의 메모리에 pandas 데이터 프레임으로 가져오거나 그 반대로(pandas 데이터 프레임을 Snowflake에 다시 쓰기) 편리한 방법을 제공합니다. Snowpark API는 Snowflake 가상 웨어하우스로 변환 푸시다운을 수행하기 위해 소스 데이터가 Snowflake에 있어야 합니다. SQL 작업에 해당하는 메서드 외에도 Snowpark API에는 Python 클라이언트에서 서버 측 Snowpark Python 객체(UD(T)F 및 Spprocs, 자세한 내용은 아래에서 설명)를 호출하는 기능과 함께 다른 도우미 함수가 포함되어 있습니다. 실행 시간.

UD(T)F 및 저장 프로시저

Snowpark Python 서버 측 런타임을 사용하면 Snowflake에 배포되는 Python 저장 프로시저 및 사용자 정의(테이블) 함수(UD(T)Fs)를 작성할 수 있으며 Snowflake 인터페이스에서 호출할 수 있고 보안 Snowflake 가상 웨어하우스의 Python 샌드박스.

Python UDF 및 UDTF는 함수가 실행 중인 가상 웨어하우스를 구성하는 모든 스레드 및 노드에서 병렬로 발생하도록 기본 Python 코드와 관련된 처리를 확장합니다. Snowpark Python에는 세 가지 UDF 유형 메커니즘이 있습니다.

• 사용자 정의 함수(UDF)는 일대일 스칼라 작업입니다. 함수에 전달된 입력 데이터 행에 대해 단일 출력이 생성됩니다. 데이터 행은 가상 웨어하우스 내 각 노드의 Python 프로세스에서 병렬로 처리됩니다.
• 벡터화/배치 UDF는 위에서 설명한 UDF와 마찬가지로 일대일 스칼라 작업입니다. 차이점은 UDF 가 데이터의 개별 행 에서 UDF 작업을 병렬화한다는 것입니다 . 벡터화 된 UDF는 배치 에서 UDF 작업을 병렬화합니다.데이터(여러 행). 기능적으로 벡터화된 UDF는 여전히 데이터의 각 입력 행에 대해 단일 출력을 생성하지만 데이터는 UDF의 개별 인스턴스로 일괄 처리됩니다(많은 행이 동시에 전달되고 많은 일괄 처리가 병렬로 처리됨). 그 이유는 Python UDF에서 사용할 수 있는 Pandas, Numpy, scipy 등에 기반한 많은 Python 작업이 벡터 스타일 작업으로 실행되도록 최적화되어 있기 때문입니다. 표준 UDF에서와 같이 개별 행이 처리될 때 UDF는 기본 Python 라이브러리에 내장된 배열 기반 최적화를 충분히 활용하지 않습니다. 벡터화된 UDF를 사용하면 이 작업을 수행할 수 있습니다. 기능적으로는 일반 Python UDF와 동일하지만 데이터가 일괄 처리되고 다양한 일반 Python 라이브러리에서 배열 기반 최적화를 활용하기 위해 대량으로 작동됩니다.
• UDTF(사용자 정의 테이블 함수)는 데이터 배치에 대한 상태 저장 작업이 필요한 Python 함수입니다. 벡터화된 UDF는 보다 최적화되고 가속화된 처리를 위해 무작위로 데이터를 일괄 처리하지만 사용자/개발자가 일괄 처리 할 데이터와 전체 데이터 일괄 처리 방법 을 결정할 수 없습니다 . 개별 행만 가능합니다. UDTF는 다대다 및 다대일 행 처리를 허용합니다. 모든 UDTF에는 프로세스 메소드와 endPartition 메소드가 있습니다. 처리 방법은 개별 행 으로 수행되는 작업을 정의합니다.배치에서 처리됩니다(기본 기능에 따라 행당 일종의 출력을 반환하거나 반환하지 않을 수 있음). endPartition 메서드는 모든 개별 행을 처리한 후 데이터의 전체 배치에서 수행되는 작업을 정의하고 배치가 처리되면서 구축된 일종의 상태 저장 작업을 포함할 수 있습니다. UDTF가 호출될 때 파티션 기준 식을 사용하면 데이터를 일괄 처리하는 데 사용되는 기본 데이터의 필드를 지정할 수 있습니다. 즉, COUNTRY로 파티션을 나누면 COUNTRY=US인 모든 레코드는 COUNTRY=CHINA는 동일한 배치 등으로 처리됩니다.

UD(T)F 외에도 Snowpark Python의 서버 측 런타임은 Python 저장 프로시저를 지원합니다. 저장 프로시저는 Snowflake 가상 웨어하우스에서 실행되는 보다 임의적인 스크립트로 생각할 수 있습니다. 주요 차이점은 저장 프로시저가 단일 노드라는 것입니다. 따라서 저장 프로시저 내에서 대규모 데이터 변환 또는 분석을 수행하려면 저장 프로시저가 클라이언트 데이터 프레임 API 또는 기타 배포된 UD(T)F를 활용하여 가상 웨어하우스의 모든 노드에서 해당 컴퓨팅을 확장해야 합니다. 이는 쿼리 에서 모든 데이터를 가져오는 것과는 대조적입니다.저장 프로시저 및 pandas 등으로 조작합니다. 대신 데이터 프레임 API 및 UD(T)F를 활용하여 계산 집약적인 작업을 통해 저장 프로시저에서 가상 웨어하우스 전체로 계산을 확장합니다. 이는 아래 코드 설계 원칙에 자세히 설명되어 있습니다. 데이터를 저장 프로시저로 직접 가져오는 것을 가능한 한 최대로 피해야 합니다(일부 예외 있음: 이 문서의 뒷부분에서 자세히 설명함). 그러나 저장 프로시저가 제공하는 것은 스크립트와 같은 프로그램 흐름을 Snowpark 서버 측 런타임에 배포하는 간단한 방법이며, 태스크 또는 직접 SQL "CALL sproc" 문을 통해 작업으로 "시작"할 수 있습니다.

코드 디자인

설계 원칙

1. Snowpark Python으로 운영 기능을 구축하기 위한 기본 원칙 은 Snowflake에서 데이터 를 가져 오지 않고 가능하면 클라이언트 환경에서 처리하는 것입니다 . 대신 Snowpark 클라이언트 데이터 프레임 API를 활용하여 SQL과 같은 작업을 푸시다운하고 서버 측 런타임을 활용하여 Snowflake 가상 웨어하우스 전체에서 확장하고 데이터를 보다 효율적으로 처리할 수 있는 UD(T)F로 임의 코드를 배포합니다. 이는 다른 도구나 애플리케이션에서 JDBC를 통해 SQL을 푸시하는 것과 유사한 프로그래밍 방식으로 생각할 수 있습니다.
2. 모든 데이터를 클라이언트 애플리케이션으로 가져와 처리하는 대신 데이터를 쿼리하고 변환할 때 애플리케이션에서 Snowpark 클라이언트 데이터 프레임 API를 사용합니다. 이를 통해 전체 애플리케이션이 Snowpark 서버 측 런타임 환경 내에서 실행되는지 아니면 Snowflake Python 환경 외부에서 실행되는지에 관계없이 데이터 변환을 효과적으로 확장할 수 있습니다. 데이터 프레임 API를 사용하는 대신 SQL을 직접 사용할 수 있다는 점은 주목할 가치가 있지만, 많은 개발자는 다른 언어로 작성된 애플리케이션 내에서 SQL을 시도하고 작성하고 사용하는 것이 번거롭다는 것을 알고 있습니다. 동일한 규모의 결과.
3. 데이터를 조작, 분석 또는 변환하는 코드는 가능한 최대 범위까지 UD(T)F로 작성되어야 합니다(UDF와 UDTF 사이의 결정은 주로 코드/변환이 실제로 수행하는 기능에 따라 결정됨 ) . Snowpark 클라이언트 데이터 프레임 API를 사용하여 구현되었습니다. 데이터 프레임 API 및 UD(T)F를 사용하면 가상 웨어하우스에서 수행되는 계산 작업을 확장하고 병렬화할 수 있기 때문입니다.
4. Python Spprocs는 Python 프로그램의 제어 흐름에 가장 적합합니다. sproc을 기본 스크립트 또는 애플리케이션으로 생각하십시오. sproc은 개체를 초기화하고 상태를 유지하는 등의 작업을 수행합니다. sproc 내에서 모든 데이터 집약적 계산은 데이터 프레임 API를 호출하거나 별도로 빌드 및 배포된 UD(T)F를 사용해야 합니다. "클라이언트에 데이터를 추출하지 마십시오"라는 위의 원칙과 유사하게 일반적으로 저장 프로시저의 메모리로 데이터를 가져오는 것을 피해야 합니다. 이는 확장 능력을 제한하기 때문입니다. 대신 데이터 프레임 API 및 UD(T)F를 사용하여 sproc에서 수행된 작업을 가상 웨어하우스 do에 푸시합니다. sproc은 작업 또는 외부 오케스트레이션 서비스(예: Airflow)를 사용하여 오케스트레이션할 수 있는 애플리케이션 내의 작업 "단위"로 생각할 수 있습니다.
5. 다시 강조하자면, 데이터를 Sproc으로 직접 가져오는 것은 최대한 피해야 합니다. Sproc은 가상 웨어하우스의 단일 노드에서 실행하도록 제한되므로 해당 노드의 계산 리소스로 제한됩니다. Snowpark에 최적화된 웨어하우스(현재 공개 미리 보기 중)는 sproc이 더 많은 메모리/데이터 집약적 작업을 수행할 수 있는 기능을 확장하지만, 일반적으로 sproc은 자체적으로 중요한 계산을 수행하는 작업을 수행해서는 안 되며 sproc 내에서 다음을 수행해야 합니다. Snowpark API 및/또는 UD(T)F로 작업을 오프로드합니다.
6. 원칙 5의 예외는 분산 방식으로 수행할 수 없는 계산이며 수행하려면 전체 데이터 세트(또는 대규모 샘플)에 대한 액세스가 필요합니다. 예를 들어 단일 노드 기계 학습 모델 교육은 일반적으로 저장 프로시저 컨텍스트에서 수행되어야 하지만 데이터 집약적 계산이 저장 프로시저에서 수행되어야 하는 드문 예입니다. 너무 많은 세부 사항을 파고들지 않고 특히 UD(T)F를 통한 병렬화가 의미가 있는 모델 훈련에 대한 사용 사례가 있을 수 있지만 이것은 작고 구체적인 사용 사례 집합입니다.
7. 코드의 모듈성, 재사용성 등과 관련하여 표준 Python 코드 설계 원칙을 따라야 합니다. 응용 프로그램에서 일반적으로 사용되는 유틸리티를 타사 사용자 정의 패키지 종속성으로 가져오는 것이 좋습니다. Snowpark 애플리케이션의 생태계 전체에서 잠재적으로 활용됩니다.
8. 애플리케이션 전체에서 사용하는 사용자 지정 클래스 및 개체는 UD(T)F와의 호환성을 평가해야 합니다. 예를 들어, 많은 데이터를 가져와 분석을 수행한 다음 분석 결과를 기반으로 사용자 지정 Python 클래스 개체를 구성하는 애플리케이션의 일부가 있다고 가정합니다. 이것은 잠재적으로 UDTF에 적합하지만 Snowpark 함수에서 임의의 Python 객체 반환을 지원하지 않습니다. 따라서 Snowflake 테이블 데이터에서 클래스 개체를 초기화할 수 있도록 to_json() 및 from_json() 생성자/직렬 변환기를 구현하는 등 지원되는 SQL 데이터 유형에 대한 개체의 직렬화/역직렬화 방법을 고려해야 합니다. 이진 직렬화를 고려할 수도 있습니다. 접근 방식에 관계없이 이를 고려해야 합니다.
9. UD(T)F의 인스턴스는 단일 쿼리 세트 내에서 재사용됩니다. 함수 메서드 외부 의 실행과 코드의 전역/정적 부분으로 재사용할 수 있는 초기화 코드 또는 변수/임시 상태를 이동하여 이를 활용할 수 있습니다 . 이는 후속 실행에서 각각의 모든 실행을 다시 초기화하지 않고도 해당 변수 또는 임시 상태를 재사용할 수 있음을 의미합니다. 이는 함수 선언 외부에 HTTP 클라이언트 또는 연결 풀을 배치하려는 외부 액세스와 같은 항목을 사용할 수 있게 됨에 따라 특히 중요합니다(유사한 설계 패턴 및 모범 사례는 AWS Lambda/Azure Functions 참조).
10. 벡터화(배치) UDF를 사용하면 UDF와 동일한 작업을 수행할 수 있으며 Pandas 및 Numpy 유형 개체에서 Python의 자체 내부 배열 기반 최적화를 활용할 수 있습니다(자세한 내용은 위에 설명되어 있음). 일반적으로 데이터의 기본 작업이 Numpy/Pandas에 의존하거나 벡터 작업을 사용하여 구현되는 경우 UDF를 벡터화된 UDF로 배포 하는 것이 일반적으로 가장 좋습니다. 이렇게 하면 서버 측 런타임에 대한 데이터 배포가 최적화되고 Snowpark가 내장된 Python 최적화를 활용할 수 있습니다.
11. Snowflake의 자체 캐싱 레이어 외에도 Snowpark Python 코드는 쿼리 결과를 캐싱해야 하는 경우를 제외하고 일반적으로 Python 캐싱 모범 사례를 따라야 합니다(Snowflake가 아키텍처의 다양한 레이어에서 이 작업을 수행하므로). 그러나 예를 들어 애플리케이션에서 텍스트 토큰화를 수행하는 UDF가 있고 이를 사용하려면 스테이지에서 빌드된 토크나이저를 로드해야 하는 경우 cachetools를 사용하여 토크나이저를 UDF에 로드하는 함수를 래핑해야 반복적으로 방지할 수 있습니다. 스테이지에서 UDF로 토크나이저를 로드합니다. 이는 아티팩트를 스테이지에서 UD(T)F로 로드해야 하는 Snowpark 코드 내 캐싱의 가장 일반적인 사용 사례입니다 .

기존 애플리케이션을 Snowpark로 포팅

많은 고객이 확장성, 성능, 거버넌스 및 보안을 개선하는 동시에 아키텍처를 단순화하고 인프라 소유 및 관리와 관련된 복잡성을 제거하기 위해 Snowpark에서 실행하기 위해 기존 기능과 애플리케이션을 포팅하는 방법을 묻고 있습니다. "Snowpark에서 이 애플리케이션 및/또는 코드를 지원할 수 있습니까?"에 대한 초기 평가 외에도 코드를 가장 최적으로 이전하는 방법에 대한 광범위한 논의와 대화가 있어야 합니다. PySpark 애플리케이션을 특히 Snowpark로 마이그레이션하는 경우(다른 보다 일반적인 Python 앱과 비교) Snowflake는 Mobilize.net 과 파트너 관계를 맺었습니다.기존 코드베이스가 Snowpark로 마이그레이션하기에 적합한 후보인지 판단하는 데 도움이 되는 무료 PySpark to Snowpark 코드 분석 도구를 제공합니다. 또한 Snowflake의 전문 서비스 팀과 SI 파트너는 전체 마이그레이션 지원을 제공할 수 있습니다.

보다 일반적인 Python 응용 프로그램의 경우 Python 스크립트 는그냥 Python sprocs에 떨어뜨리고 어느 정도 "작동"할 가능성이 있지만 특정 스크립트가 계산적으로 가볍지 않은 한 이것은 극도로 비효율적인 구현일 가능성이 높습니다. 특히 이러한 기존 애플리케이션은 위에서 강조한 것처럼 Snowpark에서 애플리케이션을 빌드하는 데 권장되는 패턴이 아닌 Snowflake에서 데이터를 가져올 가능성이 높습니다. 고려해야 할 두 가지 주요 질문은 (1) 더 많은 컴퓨팅 푸시다운을 활용하기 위해 Snowflake에서 데이터를 추출하는 코드를 리팩토링해야 하는 방법입니다. 또한 (2) Python UD(T)F를 활용하고 가상 창고의 확장성과 성능을 활용하여 어떤 기능, 메서드, 클래스 등이 더 잘 제공되는지 결정하기 위해 특히 데이터 집약적 애플리케이션을 평가해야 합니다.

순수한 코드 분석 외에도 이 마이그레이션 평가를 수행하기 위한 또 다른 접근 방식은 코드 기반에서 시작하여 개별 계산 구성 요소로 나누어진 애플리케이션/스크립트의 논리적 흐름도를 생성하는 것입니다. 많은 팀에서 이미 이러한 종류의 소프트웨어 디자인/아키텍처 다이어그램을 사용할 수 있지만 그렇지 않은 경우 데이터 및 계산 작업이 응용 프로그램 전체에 분산되는 방식을 이해하기 위한 좋은 출발점입니다. 이 다이어그램에는 사용자 정의 클래스 개체 등도 포함될 수 있습니다. 사용되는 각 함수, 클래스, 메서드에 대해 제공해야 하는 데이터와 생성되는 출력을 평가해야 합니다. 출력이 Snowflake 데이터 유형과 호환됩니까? 무엇이 출력을 소비하고 어떻게 사용됩니까? 계산이 가상 웨어하우스의 컴퓨팅 노드 클러스터에서 수행될 만큼 충분히 집약적으로 수행됩니까? 기능/개체 사용을 반복할 때마다 얼마나 많은 사용자 지정 구성이 필요합니까?

이 다이어그램을 작성하면 애플리케이션의 논리적 흐름 계층에 무엇이 있어야 하고(Snowpark Python sproc에 적합할 수 있음) UD(T)F로 오프로드해야 하는 것이 명확해지기 시작할 것입니다. , 따라서 잠재적으로 리팩터링됩니다. 이것은 또한 위의 설계 원칙에 설명된 대로 Snowpark 테이블 구조에 쓰기/초기화하기 위해 직렬화 메서드가 필요한 사용자 정의 클래스 및 개체를 나타냅니다.

이 시점부터 리프트 및 시프트할 수 있는 코드와 리팩토링, 재구현 또는 수정이 필요한 코드를 이해할 수 있습니다. 또한 Snowflake 전문 서비스는 원칙과 모범 사례를 넘어 애플리케이션을 Snowpark로 마이그레이션하는 데 있어 보다 실질적인 지원을 제공합니다.

결론

이 게시물에서는 Snowpark Python 이 무엇인지 (클라이언트 데이터 프레임 API 및 서버 측 런타임)와 이를 Python 애플리케이션에서 가장 잘 사용할 수 있는 방법에 대해 자세히 설명했습니다. Snowpark Python용 애플리케이션을 설계하거나 마이그레이션할 때 따라야 하는 핵심 설계 원칙을 설명했습니다. 2부에서는 이러한 새로운 기능을 기존 CI/CD 및 DevOps 사례에 통합하는 방법을 살펴보고 Snowpark Python이 다른 개발 프레임워크와 유사하면서도 상당히 다른 점을 포함합니다.