Databricks와 SAS 간 데이터 흐름 속도 향상 방법

 
이 문서는 Databricks Lakehouse Platform과 SAS를 함께 사용하는 모범 사례에 대한 블로그 시리즈의 첫 번째 게시물입니다. 이전 Databricks 블로그 게시물에서는 SAS 개발자에게 Databricks와 PySpark를 소개했습니다. 이 게시물에서는 SAS와 Databricks Lakehouse Platform 간의 데이터 교환 방법과 데이터 흐름을 가속화하는 방법을 논의합니다. 향후 게시물에서는 두 기술을 모두 포함하는 효율적인 데이터 및 분석 파이프라인 구축에 대해 살펴볼 것입니다.

데이터 기반 조직은 끊임없이 증가하는 비즈니스 요구 사항을 따라잡기 위해 Lakehouse 플랫폼을 빠르게 채택하고 있습니다. Lakehouse 플랫폼은 데이터 플랫폼과 아키텍처를 구축하려는 조직에게 새로운 표준이 되었습니다. 이러한 현대화는 데이터, 애플리케이션 또는 기타 비즈니스 요소를 클라우드로 이전하는 것을 포함합니다. 그러나 클라우드로의 전환은 점진적인 프로세스이며 가능한 한 오랫동안 레거시 투자를 계속 활용하는 것이 비즈니스에 매우 중요합니다. 이를 염두에 두고 많은 회사는 여러 데이터 및 분석 플랫폼을 보유하고 있으며, 이러한 플랫폼은 공존하며 서로를 보완합니다.

우리가 보는 조합 중 하나는 Databricks Lakehouse와 SAS를 함께 사용하는 것입니다. 두 플랫폼이 효율적으로 함께 작동하도록 하는 것에는 다음과 같은 많은 이점이 있습니다.

• 클라우드 플랫폼의 더 크고 확장 가능한 데이터 저장 기능
• 병렬 처리 기능을 갖추고 네이티브로 구축된 Apache Spark™와 같은 기술을 사용한 더 큰 컴퓨팅 용량
• Delta Lake를 사용한 데이터 거버넌스 및 관리로 더 높은 규정 준수 달성
• 간소화된 아키텍처로 데이터 분석 인프라 비용 절감

관찰된 일반적인 데이터 과학 및 데이터 분석 사용 사례 및 이유는 다음과 같습니다.

1. SAS 전문가들은 핵심 통계 패키지를 위해 SAS를 활용하여 규제 요구 사항을 충족하는 고급 분석 결과를 개발하는 동시에 Databricks Lakehouse를 데이터 관리, ELT 유형 처리 및 데이터 거버넌스를 위해 사용합니다.
2. SAS에서 개발된 머신러닝 모델은 Lakehouse 플랫폼의 Apache Spark 엔진 병렬 처리 아키텍처를 사용하여 대량의 데이터에 대해 채점됩니다.
3. SAS 데이터 분석가는 Databricks SQL 엔드포인트와 고대역폭 커넥터를 사용하여 애드혹 분석 및 보고를 위해 Lakehouse 플랫폼의 대량 데이터에 더 빠르게 액세스할 수 있습니다.
4. 클라우드 아키텍처와 온프레미스 SAS 플랫폼을 모두 포함하는 하이브리드 워크스트림을 설정하여 클라우드 현대화 및 마이그레이션 여정을 용이하게 합니다.

그러나 이러한 공존의 주요 과제는 두 플랫폼 간에 데이터가 성능적으로 어떻게 공유되는가 하는 것입니다. 이 블로그에서는 T1A가 고객을 위해 구현한 모범 사례와 Databricks와 SAS 간에 데이터를 이동하는 다양한 방법을 비교한 벤치마크 결과를 공유합니다.

시나리오

가장 인기 있는 사용 사례는 lakehouse에 액세스하려는 SAS 개발자입니다. 두 기술을 모두 포함하는 분석 파이프라인에는 양방향 데이터 흐름이 필요합니다. 즉, Databricks에서 SAS로 데이터를 이동하고 SAS에서 Databricks로 데이터를 이동해야 합니다.

1. SAS에서 Delta Lake 액세스: SAS 사용자는 SAS 프로그래밍 언어를 사용하여 Delta Lake의 빅데이터에 액세스하려고 합니다.
2. Databricks에서 SAS 데이터셋 액세스: Databricks 사용자는 일반적으로 Databricks 파이프라인에서 처리하거나 엔터프라이즈 전체 액세스를 위해 Delta Lake에 저장하기 위해 DataFrame으로 sas7bdat 데이터셋과 같은 SAS 데이터셋에 액세스하려고 합니다.

벤치마크 테스트에서는 다음 환경 설정을 사용했습니다.

1. Microsoft Azure를 클라우드 플랫폼으로 사용
2. Azure의 SAS 9.4M7 (단일 노드 Standard D8s v3 VM)
3. Databricks 런타임 9.0, Apache Spark 3.1.2 (2개 노드 Standard DS4v2 클러스터)

그림 1은 논의된 구성 요소와 함께 개념 아키텍처 다이어그램을 보여줍니다. Databricks Lakehouse는 Delta Lake 메달리온 아키텍처를 사용하여 Azure Data Lake 저장소에 있습니다. Azure VM에 설치된 SAS 9.4는 다음 섹션에서 논의된 연결 옵션을 사용하여 Databricks Lakehouse에 연결하여 데이터를 읽고 씁니다.

위 다이어그램은 Azure에 배포된 Databricks의 개념 아키텍처를 보여줍니다. 아키텍처는 다른 클라우드 플랫폼에서도 유사할 것입니다. 이 블로그에서는 SAS 9.4 플랫폼과의 통합만 논의합니다. 나중에 블로그 게시물에서는 SAS Viya에서 lakehouse 데이터에 액세스하는 것에 대한 논의를 확장할 것입니다.

SAS에서 Delta Lake 액세스

SAS 프로그램에서 처리해야 하는 Delta Lake 테이블이 있다고 가정해 보겠습니다. 데이터 무결성 또는 데이터 유형 호환성 문제를 피하면서 이 테이블에 액세스할 때 최상의 성능을 원합니다. 데이터 무결성과 호환성을 달성하는 데는 여러 가지 방법이 있습니다. 아래에서는 몇 가지 방법을 논의하고 사용 편의성과 성능을 비교합니다.

테스트에서는 Kaggle의 전자상거래 행동 데이터셋(5.67GB, 9개 열, ~ 42백만 레코드)을 사용했습니다.
데이터 출처: 다중 카테고리 스토어의 전자상거래 행동 데이터 및 REES46 마케팅 플랫폼.

테스트된 방법

1. SAS/ACCESS 인터페이스 커넥터 사용
전통적으로 SAS 사용자는 외부 데이터 소스에 연결하기 위해 SAS/ACCESS 소프트웨어를 활용합니다. Databricks 클러스터에 연결되는 SAS LIBNAME 문을 사용하거나 SQL 패스스루 기능을 사용할 수 있습니다. 현재 SAS 9.4의 경우 세 가지 연결 옵션을 사용할 수 있습니다.

1. SAS/ACCESS ODBC 인터페이스
2. SAS/ACCESS JDBC 인터페이스
3. SAS/ACCESS Spark 인터페이스

SAS/ACCESS Spark 인터페이스는 Databricks 클러스터에 대한 독점 지원으로 최근 기능이 추가되었습니다. 짧은 데모는 이 비디오를 참조하십시오. 비디오에서는 SAS Viya를 언급하지만 SAS 9.4에도 동일하게 적용됩니다.

이러한 커넥터를 사용하는 방법에 대한 코드 샘플은 이 git 리포지토리에서 찾을 수 있습니다: T1A Git - SAS 라이브러리 예제.

2. saspy 패키지 사용
SAS Institute의 오픈 소스 라이브러리인 saspy를 사용하면 Databricks Notebook 사용자가 노트북의 Python 셀에서 SAS 문을 실행하여 SAS 서버에서 코드를 실행하고 SAS 데이터셋에서 Pandas DataFrame으로 데이터를 가져오고 내보낼 수 있습니다.

이 섹션의 초점은 SAS 프로그래머가 SAS 프로그래밍을 사용하여 lakehouse 데이터에 액세스하는 것이므로, 이 방법은 다음에 논의될 전용 통합 방법과 유사한 SAS 매크로 프로그램으로 래핑되었습니다.

이 패키지로 더 나은 성능을 달성하기 위해 정의된 char_length 옵션으로 구성을 테스트했습니다(자세한 내용은 여기에서 확인 가능). 이 옵션을 사용하면 데이터셋의 문자 필드 길이를 정의할 수 있습니다. 이 옵션을 사용한 테스트에서 성능이 15% 추가로 향상되었습니다. 환경 간 전송 계층의 경우 SSH 연결을 SAS 서버에 사용하는 saspy 구성을 사용했습니다.

3. 전용 통합 사용
위에서 언급한 두 가지 방법에는 장점이 있지만, 다음 섹션(테스트 결과)에서 이전 방법의 단점을 해결하여 성능을 더욱 향상시킬 수 있습니다. 이를 염두에 두고 성능과 SAS 사용자의 사용 편의성에 중점을 둔 SAS 매크로 기반 통합 유틸리티를 개발했습니다. 이 SAS 매크로는 Databricks 플랫폼, Apache Spark 또는 Python에 대한 지식 없이도 기존 SAS 코드에 쉽게 통합될 수 있습니다.

이 매크로는 Databricks API를 사용하여 다단계 프로세스를 조정합니다.

1. Databricks 클러스터에 제공된 SQL 쿼리에 따라 데이터를 쿼리하고 추출하도록 지시하고, Spark SQL의 분산 처리 기능을 활용하여 결과를 DBFS에 캐시합니다.
2. 데이터셋을 압축하고 SSH를 통해 SAS 서버(GZIP 형식의 CSV)로 안전하게 전송합니다.
3. SAS에서 압축을 풀고 데이터를 가져와 SAS 라이브러리에서 사용자가 사용할 수 있도록 합니다. 이 단계에서는 Databricks 데이터 카탈로그의 열 메타데이터(열 유형, 길이 및 형식)를 활용하여 SAS에서 일관되고 정확하며 효율적인 데이터 표현을 보장합니다.

가변 길이 데이터 유형의 경우, 통합 기능은 사용자 요구 사항에 가장 적합한 옵션에 따라 다양한 구성 옵션을 지원합니다. 예를 들어,

• 구성 가능한 기본값 사용 필요성
• 가장 큰 값을 식별하기 위해 10,000개 행을 프로파일링하고(+ 추가 여유 공간 확보)
• 가장 큰 값을 식별하기 위해 데이터셋의 전체 열을 프로파일링

코드의 간소화된 버전은 T1A Git - SAS DBR Custom Integration에서 확인할 수 있습니다.

이 SAS 매크로의 최종 사용자 사용법은 아래와 같으며 세 가지 입력을 받습니다:

1. Databricks에서 데이터를 추출할 기준이 되는 SQL 쿼리
2. 데이터가 저장될 SAS libref
3. SAS 데이터셋에 부여될 이름

테스트 결과

위 플롯에서 볼 수 있듯이, 테스트 데이터셋의 경우 SAS/ACCESS Interface to JDBC와 SAS/ACCESS Interface to Apache Spark가 유사한 성능을 보였으며 다른 방법들에 비해 성능이 낮았습니다. 그 주된 이유는 JDBC 방식이 SAS 데이터셋에 적절한 열 길이를 설정하기 위해 문자 열을 프로파일링하지 않기 때문입니다. 대신, 모든 문자 열 유형(String 및 Varchar)에 대해 기본 길이를 765자로 정의합니다. 이는 초기 데이터 검색뿐만 아니라 모든 후속 처리 과정에서 성능 문제를 야기하며, 상당한 추가 저장 공간을 소비합니다. 저희 테스트에서는 5.6GB의 소스 데이터셋으로 WORK 라이브러리에 216GB 파일이 생성되었습니다. 그러나 SAS/ACCESS Interface to ODBC를 사용했을 때 기본 길이는 255자였으며, 이는 상당한 성능 향상을 가져왔습니다.

SAS/ACCESS Interface 방식을 사용하는 것은 기존 SAS 사용자에게 가장 편리한 옵션입니다. 이러한 방식을 사용할 때 몇 가지 중요한 고려 사항이 있습니다.

1. 두 솔루션 모두 암시적 쿼리 패스스루를 지원하지만 몇 가지 제한 사항이 있습니다.

• SAS/ACCESS Interface to JDBC/ODBC는 PROC SQL 문에 대해서만 패스스루를 지원합니다.
• PROC SQL 패스스루 외에도 SAS/ACCESS Interface to Apache Spark는 대부분의 SQL 함수에 대한 패스스루를 지원합니다. 이 방식은 일반적인 SAS 프로시저를 Databricks 클러스터로 푸시하는 것도 가능하게 합니다.

• 앞서 설명한 문자 열의 길이 설정 문제. 해결 방법으로, DBSASTYPE 옵션을 사용하여 SAS 테이블의 열 길이를 명시적으로 설정하는 것을 제안합니다. 이는 데이터셋의 후속 처리에 도움이 되지만 Databricks에서 데이터를 처음 검색하는 데는 영향을 미치지 않습니다.
• SAS/ACCESS Interface to Apache Spark/JDBC/ODBC는 동일한 쿼리에서 다른 libref로 할당된 여러 Databricks 데이터베이스(스키마)의 테이블을 결합(조인)하는 것을 패스스루 기능을 통해 허용하지 않습니다. 대신, 전체 테이블을 SAS로 내보내 SAS에서 처리하게 됩니다. 해결 방법으로, 다른 데이터베이스(스키마)의 테이블을 기반으로 뷰를 포함하는 전용 스키마를 Databricks에 만드는 것을 제안합니다.

saspy 방식을 사용하면 SAS/ACCESS Interface to JDBC/Spark 방식보다 약간 더 나은 성능을 보였지만, 주요 단점은 saspy 라이브러리가 pandas DataFrame과만 작동하고 Apache Spark 드라이버 프로그램에 상당한 부하를 주며 전체 DataFrame을 메모리로 가져와야 한다는 것입니다.

목적별 통합 방식은 테스트된 다른 방식들에 비해 가장 뛰어난 성능을 보였습니다. 그림 3은 논의된 방식 중에서 선택하는 데 대한 개략적인 지침을 제공하는 플로우차트입니다.

Databricks에서 SAS 데이터셋 액세스

이 섹션에서는 Databricks 개발자가 SAS 데이터셋을 Delta Lake로 가져와 비즈니스 인텔리전스, 시각 분석 및 기타 고급 분석 사용 사례를 위해 Databricks에서 사용할 수 있도록 하는 필요성을 다룹니다. 이전에 설명된 방법 중 일부가 여기에 적용될 수 있지만, 추가적인 방법도 논의됩니다.

테스트에서는 SAS 서버에 있는 SAS 데이터셋(sas7bdat 형식)으로 시작하여, 최종적으로 이 데이터셋을 Databricks에서 Spark DataFrame으로 사용할 수 있게 됩니다(지연 호출이 적용 가능한 경우 DataFrame으로 데이터를 로드하도록 강제하고 전체 시간을 측정합니다).

이 시나리오에 대해 이전 시나리오와 동일한 환경 및 데이터셋을 사용했습니다. 테스트에서는 SAS 사용자가 SAS 프로그래밍을 사용하여 Delta Lake에 데이터셋을 쓰는 사용 사례를 고려하지 않습니다. 이는 나중에 블로그 게시물에서 논의될 클라우드 제공업체 도구 및 기능을 고려해야 합니다.

테스트된 방법

1. SAS의 saspy 패키지 사용
saspy 라이브러리의 sd2df 메서드는 SSH를 사용하여 데이터 전송을 통해 SAS 데이터셋을 pandas DataFrame으로 변환합니다. 전송 중 스테이징 스토리지(메모리, CSV, 디스크)에 대한 여러 옵션을 제공합니다. 저희 테스트에서는 PROC EXPORT csv 파일과 pandas read_csv() 메서드를 사용하는 CSV 옵션이 대규모 데이터셋에 권장되며 가장 좋은 성능을 보였습니다.

2. pandas 메서드 사용
초기 릴리스부터 pandas는 사용자가 pandas.read_sas API를 사용하여 sas7bdat 파일을 읽을 수 있도록 했습니다. SAS 파일은 파이썬 프로그램에서 액세스할 수 있어야 합니다. 일반적으로 사용되는 방법은 FTP, HTTP 또는 S3와 같은 클라우드 객체 스토리지로 이동하는 것입니다. 저희는 SCP를 사용하여 원격 SAS 서버에서 Databricks 클러스터로 SAS 파일을 이동하는 더 간단한 접근 방식을 사용했습니다.

3. spark-sas7bdat 사용
Spark-sas7bdat는 Apache Spark를 위해 특별히 개발된 오픈 소스 패키지입니다. pandas.read_sas() 메서드와 유사하게 SAS 파일은 파일 시스템에서 사용할 수 있어야 합니다. SCP를 사용하여 원격 SAS 서버에서 sas7bdat 파일을 다운로드했습니다.

4. 목적별 통합 사용
또 다른 탐색된 방법은 편의성과 성능의 균형에 중점을 둔 기존 기술을 사용하는 것입니다. 이 방법은 핵심 통합 기능을 추상화하고 Databricks Notebook에서 실행되는 Python 라이브러리로 사용자에게 제공됩니다.

1. saspy 패키지를 사용하여 SAS 서버에서 SAS 매크로 코드를 실행합니다. 이 코드는 다음을 수행합니다.

• SAS 코드를 사용하여 sas7bdat를 CSV 파일로 내보냅니다.
• CSV 파일을 GZIP으로 압축합니다.

• 압축된 파일을 SCP를 사용하여 Databricks 클러스터 드라이버 노드로 이동합니다.
• CSV 파일의 압축을 풉니다.
• CSV 파일을 Apache Spark DataFrame으로 읽습니다.

테스트 결과

spark-sas7bdat이 모든 방법 중에서 가장 좋은 성능을 보였습니다. 이 패키지는 Apache Spark의 병렬 처리 기능을 최대한 활용합니다. sas7bdat 파일의 블록을 워커 노드에 분산시킵니다. 이 방법의 주요 단점은 sas7bdat가 독점적인 이진 형식이며, 라이브러리가 이 이진 형식의 역공학을 기반으로 구축되었기 때문에 모든 유형의 sas7bdat 파일을 지원하지 않으며 공식적으로 (상업적으로) 공급업체 지원을 받지 못한다는 것입니다.

saspy와 pandas 방법은 둘 다 단일 노드 환경을 위해 구축되었고 데이터를 pandas DataFrame으로 읽어 Spark DataFrame으로 사용하기 전에 추가 단계가 필요하다는 점에서 유사합니다.

목적별 통합 매크로는 CSV에서 Apache Spark API를 통해 데이터를 읽기 때문에 saspy 및 pandas보다 더 나은 성능을 보였습니다. 하지만 spark-sas7bdat 패키지의 성능에는 미치지 못합니다. 목적별 방법은 SAS 서버에서 중간 데이터 변환을 추가할 수 있다는 점에서 경우에 따라 편리할 수 있습니다.

결론

점점 더 많은 기업들이 Databricks Lakehouse 구축으로 전환하고 있으며, 다른 기술을 통해 Lakehouse의 데이터에 액세스하는 데는 여러 가지 방법이 있습니다. 이 블로그에서는 SAS 개발자, 데이터 과학자 및 기타 비즈니스 사용자가 Lakehouse의 데이터를 활용하고 결과를 클라우드에 쓰는 방법을 논의합니다. 저희 실험에서는 Databricks와 SAS 간에 데이터를 읽고 쓰는 여러 가지 다른 방법을 테스트했습니다. 이러한 방법들은 성능뿐만 아니라 편의성과 제공하는 추가 기능에 따라서도 다릅니다.

이 테스트를 위해 SAS 9.4M7 플랫폼을 사용했습니다. SAS Viya는 논의된 접근 방식의 대부분을 지원하지만 추가 옵션도 제공합니다. 여기서 다루지 않은 방법이나 기타 전문적인 통합 접근 방식에 대해 더 자세히 알고 싶으시면 Databricks 또는 [email protected]으로 문의해 주세요.

이 블로그 시리즈의 다음 게시물에서는 통합 데이터 파이프라인 구현, 엔드투엔드 워크플로, SAS 및 Databricks 사용, SAS In-Database 기술을 활용하여 Databricks 클러스터에서 SAS 모델 채점하는 방법에 대한 모범 사례를 논의할 것입니다.

SAS® 및 기타 모든 SAS Institute Inc. 제품 또는 서비스 이름은 미국 및 기타 국가에서 SAS Institute Inc.의 등록 상표 또는 상표입니다. ®는 미국 등록을 나타냅니다.

시작하기

Databricks Academy의 SAS 사용자를 위한 Databricks 과정을 통해 SAS 프로그래밍 언어 구문에 대한 PySpark 프로그래밍의 기본 실습 경험을 쌓고, 저희에게 연락하여 SAS 팀이 ETL 워크로드를 Databricks로 온보딩하고 모범 사례를 구현하도록 어떻게 도울 수 있는지 알아보세요.

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