Databricks에 SQL 저장 프로시저 소개

데이터 정리, 비즈니스 규칙 업데이트 또는 배치 로직 실행과 같이 반복적인 SQL 작업을 코드 복사 및 붙여넣기로 처리하는 것은 번거롭고 오류가 발생하기 쉽습니다. 

이제 Databricks의 SQL 저장 프로시저(일반 공급 시작)를 사용하면 해당 로직을 한 번 저장하고 필요할 때마다 실행하며 Unity Catalog에서 거버넌스를 유지할 수 있습니다. 

분석 전에 데이터를 정리하든, 비즈니스 기준에 따라 테이블을 업데이트하든, 레거시 엔터프라이즈 데이터 웨어하우스에서 워크로드를 마이그레이션하든, 저장 프로시저를 사용하면 프로세스가 더 간단하고 일관되며 유지 관리하기 쉬워집니다.

Databricks는 독점적이거나 공급업체별 구현을 피하면서 개방형 표준 및 상호 운용성을 지원합니다. SQL 저장 프로시저는 ANSI/PSM SQL 표준을 따르며 오픈 소스 Apache Spark™에 기여될 예정입니다.

프로시저는 관리 작업, 데이터 관리 및 ETL 워크플로, 특히 엔터프라이즈 데이터 웨어하우스(EDW)에서 널리 사용됩니다. EDW에서 Databricks로 마이그레이션하는 고객의 경우 기존 저장 프로시저를 다시 작성하지 않고 마이그레이션할 수 있어 전환이 더 간단해집니다. 그리고 언제나 그렇듯이 최고의 데이터 웨어하우스는 레이크하우스입니다.

고객 세분화와 관련된 중요 사용 사례 중 하나에서 DBSQL과 함께 SQL 저장 프로시저를 활용하여 성능, 확장성 및 비용 효율성을 개선했습니다. SQL에 익숙했기 때문에 솔루션을 매우 짧은 시간 안에 구현하고 프로덕션에 배포할 수 있었습니다. 저장 프로시저를 사용함으로써 전체 아키텍처를 간결하고 유지 관리 가능하게 유지하면서 복잡한 로직을 더 효과적으로 관리할 수 있었습니다. —SambaSiva Rao, Sr. Data Engineer/Architect, ClicTechnologies

SQL 저장 프로시저가 이제 일반 공급됩니다.

SQL 저장 프로시저 개요

저장 프로시저란 무엇인가요?

데이터 처리 워크플로 전반에 걸쳐 고객은 반복적인 작업과 복잡한 로직의 일관성과 성능을 유지하는 데 어려움을 겪을 수 있습니다. 저장 프로시저는 이러한 경우에 훌륭한 접근 방식으로, 데이터가 일관되고 표준화된 방식으로 처리되도록 하고 성능을 최적화합니다. 

데이터 정리 작업의 경우 프로시저는 일관되지 않은 날짜 형식을 표준화된 구조로 변환하거나, 텍스트 필드의 선행 및 후행 공백을 제거하거나, 잘못된 값을 대체하거나 수정하는 등의 변환을 적용할 수 있습니다. 이를 통해 데이터를 다운스트림 분석에 사용할 수 있도록 준비할 수 있습니다. 아래의 자세한 ETL 예제를 참조하세요.

데이터 관리 측면에서는 저장 프로시저를 사용하여 정의된 비즈니스 규칙에 따라 테이블 값을 효율적으로 업데이트할 수 있습니다. 예를 들어, 오래된 레코드를 플래그 지정하거나, 필드를 다시 계산하거나, 관련 테이블 간의 데이터를 동기화하는 것입니다. 이러한 작업을 프로시저로 캡슐화함으로써 팀은 일관된 실행을 보장하고 수동 개입을 줄이며 대규모 데이터 품질을 개선할 수 있습니다. 아래의 저장 프로시저를 사용하여 로열티/멤버십 프로그램을 업데이트하는 자세한 데이터 관리 예제를 참조하세요.

그렇다면 프로시저란 무엇일까요? 프로시저는 SQL 문을 미리 컴파일한 모음으로, 사용자가 SQL 로직을 단일 재사용 가능한 단위로 관리할 수 있습니다. 프로시저는 Unity Catalog에 저장되므로 거버넌스가 적용되고 권한이 완전히 캡슐화됩니다. 저장 프로시저가 호출되면 데이터베이스는 이러한 사전 정의된 작업을 실행하여 향상된 보안, 복잡한 워크로드의 유지 관리 간소화 및 성능 향상 가능성의 이점을 제공합니다.

무엇이 지원되나요?

프로시저를 지원하는 5가지 핵심 명령은 CREATE, CALL, DESCRIBE, SHOW 및 DROP입니다.

• CREATE PROCEDURE: Unity Catalog 내에 새 저장 프로시저를 정의하고 저장합니다. 프로시저의 이름, 매개변수(있는 경우) 및 프로시저가 호출될 때 실행될 SQL 문을 지정합니다.
• CALL PROCEDURE: 이전에 생성된 저장 프로시저를 실행합니다. 필요한 매개변수를 전달합니다.
• DESCRIBE PROCEDURE: 이름과 매개변수와 같이 기존 프로시저에 대한 기본 메타데이터를 반환합니다. EXTENDED를 사용하면 설명에 소유자, 생성 날짜/시간, 보안 유형 등 추가 메타데이터가 포함됩니다.
• SHOW PROCEDURES: 현재 카탈로그 스키마에서 사용 가능한 모든 저장 프로시저를 나열합니다.
• DROP PROCEDURE: 저장소에서 기존 프로시저를 삭제합니다. 

프로시저를 생성할 때 여러 매개변수 유형을 사용하여 입력과 출력을 제어할 수 있습니다. 

• `IN` 매개변수: 값을 입력으로 프로시저에 전달하는 데 사용됩니다. 예를 들어, 해당 고객의 데이터만 검색하거나 처리하기 위해 고객 ID를 전달할 수 있습니다. 프로시저는 이러한 값을 읽을 수는 있지만 수정할 수는 없습니다.
• `OUT` 매개변수: 할당된 후 프로시저에서 값을 반환하는 데 사용됩니다. 예를 들어, 고객 ID를 전달하고 해당 계정 상태 또는 계산된 판매 총액을 반환하여 프로시저 외부에서 추가 처리를 할 수 있습니다.
• `INOUT` 매개변수: 이중 목적을 수행하여 값을 프로시저에 전달하고, 프로시저 내에서 수정하고, 업데이트된 값을 반환할 수 있습니다. 입력과 출력 모두로 작동합니다. 

이러한 매개변수는 다음을 할당할 수 있습니다.

• 로컬 변수: 스크립트/프로시저 내에서 선언됩니다.
• 세션 변수: 세션 내에서 선언되며 스크립트/프로시저 외부에서도 사용할 수 있습니다.

SQL 저장 프로시저 내에 캡슐화된 로직은 SQL 스크립팅을 기반으로 구축됩니다. 저장 프로시저는 매개변수가 있는 재사용 가능한 스크립트로 간주될 수 있으며 Unity Catalog에 의해 거버넌스됩니다. 다음 두 가지 소개 블로그에서 스크립팅에 대해 자세히 알아볼 수 있습니다.

• SQL 스크립팅 소개 파트 1
• SQL 스크립팅 소개 파트 2
• SQL 스크립팅 문서를 검토하세요.

중첩 및 재귀 프로시저 호출이 지원됩니다. 즉, 고객은 작업 단위 또는 비즈니스 로직을 별도의 프로시저로 편리하게 구성하여 전체 SQL 실행 흐름을 더 모듈화할 수 있습니다. 이는 가독성과 유지 관리를 향상시킵니다.

프로시저와 함수는 어떻게 다른가요?

프로시저는 UI에서 함수와 함께 Unity Catalog에 그룹화됩니다. 그러나 프로시저와 함수는 SQL 로직을 재사용할 수 있게 해주지만 다른 목적을 수행합니다.

함수는 값 또는 테이블을 반환하는 데 사용됩니다. SQL 쿼 내에서 사용해야 하며 동적 SQL 또는 절차적 로직을 포함할 수 없습니다. 반면에 프로시저는 일련의 SQL 문을 실행하는 데 사용됩니다. 제어 흐름, 변수, 루프 및 IDENTIFIER 및 EXECUTE IMMEDIATE를 사용한 동적 SQL을 포함할 수 있습니다. 프로시저는 일반적으로 작업이나 워크플로를 수행하기 위해 독립 실행형 명령으로 호출합니다.

SQL 저장 프로시저 사용 예제

SQL 저장 프로시저의 기능을 다루었으니, 이제 몇 가지 예제를 살펴보고 그 가치와 해결하는 문제를 보여드리겠습니다.

이 노트북을 사용하여 따라 할 수 있습니다. 이 노트북에는 이 게시물의 모든 예제와 데이터 준비 명령이 포함되어 있습니다.

ETL – 데이터 정리: Silver 또는 Gold 레이어 테이블 준비

일반적인 메달리온 아키텍처를 따른다면, Bronze에서 Silver로 (또는 Silver에서 Gold로) 데이터를 이동할 때 데이터 정리, 변환, 집계 및 형식 지정이 필요할 수 있다는 것을 알고 계실 겁니다. Stored Procedure는 ETL 워크플로우 내에서 이러한 반복적인 프로세스를 관리하는 데 매우 유용합니다. 

이 ETL 시나리오에서는 Procedure를 사용하여 다음을 수행합니다.

• 원시 데이터를 fact 테이블로 로드
• 날짜 범위 및 판매 출처(웹, 모바일, POS, 3자 공급업체)를 기반으로 데이터 선택
• 날짜를 특정 형식으로 변환하고 공백을 제거하여 데이터 정리 및 형식 지정
• 정리된 데이터는 ‘clean’ 테이블로 로드
• 타임스탬프, 시작-종료 날짜 및 판매 출처를 기반으로 로그 레코드 추가
• Procedure를 사용하여 2025년 6월의 모바일 앱 판매 조회

이와 같은 Procedure는 데이터 제품을 표준화하는 데 도움이 됩니다. 이 Procedure를 사용하는 모든 사용자는 날짜 범위나 판매 시점에 관계없이 동일한 구조의 데이터를 생성하게 됩니다. 이것이 코드를 재사용하는 주요 이점입니다. 동일한 로직이 매번 실행되므로 코드 재사용은 자연스럽게 오류 발생 가능성이 줄어듭니다.

데이터 관리: 비즈니스 기준에 따라 테이블 업데이트

데이터 관리는 데이터의 정확성, 일관성 및 효율적인 액세스를 보장하는 관행으로, 데이터 기반 의사 결정을 목표로 하는 모든 조직에 필수적인 품질입니다. 강력한 데이터 관리 없이는 가장 발전된 분석 또는 보고 노력조차도 신뢰할 수 없거나 일관성 없는 정보로 인해 약화될 수 있습니다. 

상업 산업 전반에서 흔히 볼 수 있는 한 가지 예를 살펴보겠습니다. 비즈니스에서 고객 등급에 따라 혜택을 제공하는 로열티 프로그램을 설정하는 것이 일반적입니다. 항공사는 상용 고객 우대 프로그램이 있고 대부분의 소매 프랜차이즈에는 보상 프로그램 등이 있습니다. 고객이 동일한 항공사를 더 많이 이용하거나 동일한 프랜차이즈에서 더 많은 상품을 구매할수록 고객은 더 많은 혜택을 얻습니다.

다음은 Stored Procedure를 사용하여 표준 소매 로열티 프로그램을 관리하고 업데이트하는 방법을 보여주는 예입니다. 고객 로열티 등급을 관리하는 데 두 개의 Procedure가 사용됩니다. 하나는 제공된 customerID에 대한 특정 고객 로열티 등급을 업데이트하고, 다른 하나는 제공된 국가의 모든 고객에 대한 고객 로열티 등급을 업데이트합니다.

이제 생성된 Procedure를 사용하여 세르비아, 독일, 캐나다 고객의 로열티 등급을 업데이트한 다음 업데이트된 레코드를 확인해 보겠습니다.

이전 쿼리는 다음 결과를 생성합니다.

업데이트 로직을 각 Procedure로 캡슐화함으로써 코드 중복을 피하고 호출자로부터 복잡성을 제거하여, 호출자는 적절한 Procedure 매개변수로 Procedure를 호출하기만 하면 됩니다.

다음 단계는 무엇인가요?

DBSQL에 SQL Stored Procedure가 추가됨에 따라 고객은 레거시 엔터프라이즈 데이터 웨어하우스 워크로드를 계속해서 레이크하우스로 마이그레이션할 수 있습니다. 고객 피드백에 따르면 GA로 이동하면서 해결하고자 하는 몇 가지 주요 기능이 있습니다.

• Apache Spark™의 SQL Stored Procedure: 오픈 소스의 모든 SQL Procedure 지원
• SQL SECURITY DEFINER 지원: 고객이 Procedure 생성자(definer)의 권한으로 Procedure 로직을 실행할 수 있도록 허용

SQL 스크립팅 및 Procedure와 관련된 피드백이나 요청을 공유하고 싶은 고객은 이 양식을 통해 할 수 있습니다.

레거시 시스템에서 Stored Procedure를 마이그레이션하는 데 필요한 두 가지 다른 중요한 SQL 구문은 임시 테이블(Temporary Tables)과 트랜잭션(Transactions)입니다. 임시 테이블은 이제 DBSQL에서 일반적으로 사용할 수 있으며, 트랜잭션(다중 문 및 다중 테이블) 지원은 곧 제공될 예정입니다. 

기존 Databricks 사용자이든 다른 데이터 웨어하우스에서 마이그레이션하는 경우이든, SQL 저장 프로시저는 복잡한 SQL 워크플로를 간소화하는 데 사용할 수 있는 기능입니다. Databricks 설명서를 읽고 SQL 저장 프로시저를 시작하세요.

Databricks SQL에 대해 자세히 알아보려면 저희 웹사이트를 방문하거나 설명서를 읽어보세요. 또한 Databricks SQL 제품 투어를 확인할 수도 있습니다. 기존 웨어하우스를 훌륭한 사용자 경험과 낮은 총 비용을 갖춘 고성능 서버리스 데이터 웨어하우스로 마이그레이션하려는 경우 Databricks SQL이 해결책입니다. 지금 바로 무료로 시도해 보세요.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)