DatabricksとSAS間のデータフローを高速化する方法

 
This is the first post in a series of blogs on the best practices of bringing together Databricks Lakehouse Platform and SAS. A previous Databricks blog post introduced Databricks and PySpark to SAS developers. In this post, we discuss ways for exchanging data between SAS and Databricks Lakehouse Platform and ways to speed up the data flow. In future posts, we will explore building efficient data and analytics pipelines involving both technologies.

Data-driven organizations are rapidly adopting the Lakehouse platform to keep up with the constantly growing business demands. Lakehouse platform has become a new norm for organizations wanting to build data platforms and architecture. The modernization entails moving data, applications, or other business elements to the cloud. However, the transition to the cloud is a gradual process and it is business-critical to continue leveraging legacy investments for as long as possible. With that in mind, many companies tend to have multiple data and analytics platforms, where the platforms coexist and complement each other.

One of the combinations we see is the use of SAS with the Databricks Lakehouse. There are many benefits of enabling the two platforms to efficiently work together, such as:

• Greater and scalable data storage capabilities of cloud platforms
• Greater computing capacity using technologies, such as Apache Spark™, natively built with parallel processing capabilities
• Achieve greater compliance with data governance and management using Delta Lake
• Lower the cost of data analytics infrastructure with simplified architectures

Some common data science and data analysis use cases and reasons observed are:

1. SAS practitioners leverage SAS for its core statistical packages to develop advanced analytics output that meets regulatory requirements while they use Databricks Lakehouse for data management, ELT types of processing, and data governance
2. Machine learning models developed in SAS are scored on massive amounts of data using parallel processing architecture of Apache Spark engine in the Lakehouse platform
3. SAS data analysts gain faster access to large amounts of data in the Lakehouse Platform for ad-hoc analysis and reporting using Databricks SQL endpoints and high bandwidth connectors
4. Ease cloud modernization and migration journey by establishing a hybrid workstream involving both cloud architecture and on-prem SAS platform

However, a key challenge of this coexistence is how the data is performantly shared between the two platforms. In this blog, we share best practices implemented by T1A for their customers and benchmark results comparing different methods of moving data between Databricks and SAS.

Scenarios

The most popular use case is a SAS developer trying to access data in the lakehouse. The analytics pipelines involving both technologies require data flow in both directions: data moved from Databricks to SAS and data moved from SAS to Databricks.

1. Access Delta Lake from SAS: A SAS user wants to access big data in Delta Lake using the SAS programming language.
2. Access SAS datasets from Databricks: A Databricks user wants to access SAS datasets, generally the sas7bdat datasets as a DataFrame to process in Databricks pipelines or store in Delta Lake for enterprise-wide access.

In our benchmark tests, we used the following environment setup:

1. Microsoft Azure as the cloud platform
2. SAS 9.4M7 on Azure (single node Standard D8s v3 VM)
3. Databricks runtime 9.0, Apache Spark 3.1.2 (2 nodes Standard DS4v2 cluster)

Figure 1 shows the conceptual architecture diagram with the components discussed. Databricks Lakehouse sits on Azure Data Lake storage with Delta Lake medallion architecture. SAS 9.4 installed on Azure VM connects to Databricks Lakehouse to read/write data using connection options discussed in the following sections.

The diagram above shows a conceptual architecture of Databricks deployed on Azure. The architecture will be similar on other cloud platforms. In this blog, we only discuss the integration with the SAS 9.4 platform. In a later blog post, we will extend this discussion to access lakehouse data from SAS Viya.

Access Delta Lake from SAS

Imagine that we have a Delta Lake table that needs to be processed in a SAS program. We want the best performance when accessing this table, while also avoiding any possible issues with data integrity or data types compatibility. There are different ways to achieve data integrity and compatibility. Below we discuss a few methods and compare them on ease of use and performance.

In our testing, we used the eCommerce behavior dataset (5.67GB, 9 columns, ~ 42 mill records) from Kaggle.
Data Source Credit: eCommerce behavior data from multi category store and REES46 Marketing Platform.

Tested methods

1. Using SAS/ACCESS Interface connectors
Traditionally, SAS users leverage SAS/ACCESS software to connect to external data sources. You can either use a SAS LIBNAME statement pointing to the Databricks cluster or use the SQL pass-through facility. At present for SAS 9.4, there are three connection options available.

1. SAS/ACCESS Interface to ODBC
2. SAS/ACCESS Interface to JDBC
3. SAS/ACCESS Interface to Spark

SAS/ACCESS Interface to Spark has been recently loaded with capabilities with exclusive support to Databricks clusters. See this video for a short demonstration. The video mentions SAS Viya but the same is applicable to SAS 9.4.

Code samples on how to use these connectors can be found in this git repository: T1A Git - SAS Libraries Examples.

2. Using saspy package
The open-source library, saspy, from SAS Institute allows Databricks Notebook users to run SAS statements from a Python cell in the notebook to execute code in the SAS server, as well as to import and export data from SAS datasets to Pandas DataFrame.

Since the focus of this section is accessing lakehouse data by a SAS programmer using SAS programming, this method was wrapped in a SAS macro program similar to the purpose-built integration method discussed next.

To achieve better performance with this package, we tested the configuration with a defined char_length option (details available here). With this option, we can define lengths for character fields in the dataset. In our tests using this option brought an additional 15% increase in performance. For the transport layer between environments, we used the saspy configuration with an SSH connection to the SAS server.

3. Using a purpose-built integration
Although the two methods mentioned above have their upsides, the performance can be improved further by addressing some shortcomings, discussed in the next section (Test Results), of the previous methods. With that in mind, we developed a SAS macro-based integration utility with a prime focus on performance and usability for SAS users. The SAS macro can be easily integrated into existing SAS code without any knowledge about Databricks platform, Apache Spark or Python.

The macro orchestrates a multistep process using Databricks API:

1. Databricksクラスターに、指定されたSQLクエリに従ってデータをクエリおよび抽出するように指示し、その結果をDBFSにキャッシュします。これは、Spark SQLの分散処理能力を活用します。
2. データセットを圧縮し、SSH経由で（GZIP形式のCSVとして）SASサーバーに安全に転送します。
3. SASにデータを展開してインポートし、SASライブラリでユーザーが利用できるようにします。このステップでは、Databricksデータカタログからの列メタデータ（列の型、長さ、形式）を活用して、SASでのデータ表示を一貫性があり、正確で、効率的なものにします。

なお、可変長データ型については、ユーザー要件に最適な構成オプションがいくつか用意されています。例えば、

• 設定可能なデフォルト値の使用が必要な場合
• 最大の値を特定するために10,000行をプロファイリングする（＋余裕を追加）
• データセット全体で列をプロファイリングして最大の値を特定する

コードの簡略版はこちらで入手できます。T1A Git - SAS DBR Custom Integration。

このSASマクロのエンドユーザーによる使用方法は以下のとおりで、3つの入力が必要です。

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.6 GBであったのに対し、WORKライブラリには216 GBのファイルが作成されました。しかし、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は、異なるlibnameとして割り当てられた異なる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、DISK）にはいくつかのオプションがあります。当社のテストでは、PROC EXPORT csvファイルとpandas read_csv()メソッドを使用するCSVオプションが、大規模データセットに推奨されるオプションであり、最高のパフォーマンスを示しました。

2. pandasメソッドの使用
初期リリースから、pandasはユーザーがpandas.read_sas APIを使用してsas7bdatファイルを読み取ることを許可しています。SASファイルはPythonプログラムからアクセスできる必要があります。一般的に使用される方法には、FTP、HTTP、またはS3のようなクラウドオブジェクトストレージへの移動があります。私たちは、SCPを使用してSASファイルをリモートSASサーバーからDatabricksクラスターに移動する、よりシンプルなアプローチを使用しました。

3. spark-sas7bdatの使用
spark-sas7bdatは、Apache Spark専用に開発されたオープンソースパッケージです。pandas.read_sas()メソッドと同様に、SASファイルはファイルシステムから利用可能である必要があります。SCPを使用してリモートSASサーバーからsas7bdatファイルをダウンロードしました。

4. 目的特化型統合の使用
もう1つの検討された方法は、利便性とパフォーマンスのバランスに焦点を当てた従来の技術を使用することです。このメソッドはコア統合を抽象化し、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 として利用可能になる前に追加のステップが必要になるという点で似ています。

目的特化型統合 マクロは、Apache Spark API を介して CSV からデータを読み取るため、saspy および pandas よりも優れたパフォーマンスを示しました。ただし、spark-sas7bdat パッケージのパフォーマンスには及びません。目的特化型の手法は、SAS サーバーで中間データ変換を追加できるため、場合によっては便利です。

結論

ますます多くの企業が Databricks Lakehouse の構築に移行しており、他のテクノロジーを介して Lakehouse のデータにアクセスする方法は複数あります。このブログでは、SAS 開発者、データサイエンティスト、その他のビジネスユーザーが Lakehouse のデータをどのように活用し、結果をクラウドに書き込むことができるかについて説明します。私たちの実験では、Databricks と SAS の間でデータを読み書きするためのいくつかの異なる方法をテストしました。これらの手法は、パフォーマンスだけでなく、利便性や提供される追加機能によっても異なります。

このテストでは、SAS 9.4M7 プラットフォームを使用しました。SAS Viya は、議論されたアプローチのほとんどをサポートしていますが、追加のオプションも提供します。手法や、ここでカバーされていないその他の専門的な統合アプローチについて詳しく知りたい場合は、Databricks または [email protected] までお気軽にお問い合わせください。

このブログシリーズの今後の投稿では、統合データパイプラインの実装、SAS と Databricks を使用したエンドツーエンドのワークフロー、および Databricks クラスターで SAS モデルのスコアリング に SAS In-Database テクノロジーを活用する方法に関するベストプラクティスについて説明します。

SAS® およびその他のすべての SAS Institute Inc. の製品またはサービス名は、米国およびその他の国における SAS Institute Inc. の登録商標または商標です。® は米国登録を示します。

はじめに

Databricks Academy のコース Databricks for SAS Users を試して、SAS プログラミング言語の構造に対する PySpark プログラミングの基本的な実践的な経験を積んでください。また、お問い合わせ いただき、SAS チームが ETL ワークロードを Databricks にオンボードし、ベストプラクティスを有効にする方法について、さらに詳しく知ってください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事