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

これは、Databricks Lakehouse PlatformとSASを連携させるためのベストプラクティスに関するブログシリーズの最初の投稿です。以前のDatabricksのブログ投稿では、SAS開発者向けにDatabricksとPySparkを紹介しました。この投稿では、SASとDatabricks Lakehouse Platform間でデータを交換する方法と、データフローを高速化する方法について説明します。今後の投稿では、両方のテクノロジーを組み合わせた効率的なデータおよび分析パイプラインの構築について探求します。

データドリブンな組織は、絶えず増大するビジネス要求に対応するため、レイクハウスプラットフォームを急速に採用しています。レイクハウスプラットフォームは、データプラットフォームとアーキテクチャを構築したい組織にとって新たな標準となっています。モダナイゼーションには、データ、アプリケーション、その他のビジネス要素をクラウドに移行することが伴います。しかし、クラウドへの移行は段階的なプロセスであり、可能な限りレガシー投資を活用し続けることはビジネス上不可欠です。このことを念頭に置いて、多くの企業は複数のデータおよび分析プラットフォームを持つ傾向があり、それらのプラットフォームは共存し、互いに補完し合っています。

私たちが目にする組み合わせの一つに、SASとDatabricks Lakehouseの利用があります。これら2つのプラットフォームを効率的に連携させることには、次のような多くのメリットがあります。

• クラウドプラットフォームのより大規模でスケーラブルなデータストレージ機能
• Apache Spark™のような、並列処理機能をネイティブに備えたテクノロジーを使用したより高いコンピューティング能力
• Delta Lakeを使用したデータガバナンスと管理におけるコンプライアンスの向上
• 簡素化されたアーキテクチャによるデータ分析インフラストラクチャのコスト削減

一般的なデータサイエンスおよびデータ分析のユースケースと観察された理由は次のとおりです。

1. SASの実務家は、規制要件を満たす高度な分析出力を開発するためにSASのコア統計パッケージを活用し、データ管理、ELTタイプの処理、データガバナンスにはDatabricks Lakehouseを使用します。
2. SASで開発された機械学習モデルは、レイクハウスプラットフォームのApache Sparkエンジンによる並列処理アーキテクチャを使用して、大量のデータに対してスコアリングされます。
3. SASデータアナリストは、Databricks SQLエンドポイントと高帯域幅コネクタを使用して、レイクハウスプラットフォーム内の大量データにアドホック分析やレポート作成のために迅速にアクセスできます。
4. クラウドアーキテクチャとオンプレミスSASプラットフォームの両方を含むハイブリッドワークストリームを確立することで、クラウドのモダナイゼーションと移行プロセスを容易にします。

しかし、この共存における主要な課題は、2つのプラットフォーム間でデータがどのように効率的に共有されるかです。このブログでは、T1Aが顧客のために実装したベストプラクティスと、DatabricksとSAS間でデータを移動するさまざまな方法を比較したベンチマーク結果を共有します。

シナリオ

最も一般的なユースケースは、レイクハウス内のデータにアクセスしようとするSAS開発者です。両方のテクノロジーを含む分析パイプラインでは、DatabricksからSASへ、そしてSASからDatabricksへという双方向のデータフローが必要です。

1. SASからDelta Lakeへのアクセス: SASユーザーがSASプログラミング言語を使用してDelta Lake内のビッグデータにアクセスしたい場合。
2. DatabricksからSASデータセットへのアクセス: DatabricksユーザーがSASデータセット（通常はsas7bdatデータセット）をDataFrameとしてDatabricksパイプラインで処理したり、企業全体でアクセスできるようにDelta Lakeに保存したりしたい場合。

ベンチマークテストでは、以下の環境設定を使用しました。

1. クラウドプラットフォームとしてのMicrosoft Azure
2. Azure上のSAS 9.4M7 (シングルノード Standard D8s v3 VM)
3. Databricks runtime 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からレイクハウスデータにアクセスするための議論を拡張します。

SASからDelta Lakeへのアクセス

SASプログラムで処理する必要があるDelta Lakeテーブルがあると想像してください。このテーブルにアクセスする際に最高のパフォーマンスを望む一方で、データの整合性やデータ型の互換性に関する潜在的な問題を回避したいと考えます。データの整合性と互換性を実現するにはさまざまな方法があります。以下では、いくつかの方法について説明し、使いやすさとパフォーマンスの観点から比較します。

テストでは、Kaggleのeコマース行動データセット（5.67GB、9列、約4200万レコード）を使用しました。
データソース提供元: eCommerce behavior data from multi category store および REES46 Marketing Platform。

テスト方法

1. SAS/ACCESSインターフェースコネクタの使用
従来、SASユーザーはSAS/ACCESSソフトウェアを利用して外部データソースに接続していました。Databricksクラスターを指すSAS LIBNAMEステートメントを使用するか、SQLパススルー機能を使用できます。現在、SAS 9.4では3つの接続オプションが利用可能です。

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

SAS/ACCESS Interface to Sparkは、Databricksクラスターへの排他的サポートを含む機能が最近追加されました。このビデオで簡単なデモンストレーションをご覧ください。ビデオではSAS Viyaに言及していますが、SAS 9.4にも同様に適用されます。

これらのコネクタの使用方法に関するコードサンプルは、こちらのGitリポジトリで見つけることができます: T1A Git - SAS Libraries Examples。

2. saspyパッケージの使用
SAS Instituteが提供するオープンソースライブラリsaspyを使用すると、Databricks Notebookユーザーはノートブック内のPythonセルからSASステートメントを実行してSASサーバーでコードを実行したり、SASデータセットからPandas DataFrameにデータをインポートおよびエクスポートしたりできます。

このセクションの焦点は、SASプログラマーがSASプログラミングを使用してレイクハウスデータにアクセスすることであるため、この方法は次に説明する専用の統合方法と同様にSASマクロプログラムにラップされました。

このパッケージでより良いパフォーマンスを達成するために、char_lengthオプションを定義した構成をテストしました（詳細はこちらで入手可能）。このオプションを使用すると、データセット内の文字フィールドの長さを定義できます。このオプションを使用したテストでは、パフォーマンスがさらに15%向上しました。環境間のトランスポート層には、SSH接続を使用したsaspy構成をSASサーバーに適用しました。

3. 専用統合の使用
上記の2つの方法には利点がありますが、前述の方法のいくつかの欠点（次のセクション「テスト結果」で議論）に対処することで、パフォーマンスをさらに向上させることができます。このことを念頭に置いて、SASユーザーのパフォーマンスと使いやすさに重点を置いたSASマクロベースの統合ユーティリティを開発しました。このSASマクロは、Databricksプラットフォーム、Apache Spark、またはPythonに関する知識がなくても、既存のSASコードに簡単に統合できます。

このマクロは、Databricks APIを使用して多段階プロセスをオーケストレーションします。

1. Databricksクラスターに、提供されたSQLクエリに従ってデータをクエリおよび抽出させ、そのApache Spark SQL分散処理機能を利用して結果をDBFSにキャッシュします。
2. データセットを圧縮し、SSH経由でSASサーバーに（GZIP形式のCSVとして）安全に転送します。
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は、パススルー機能を使用して、異なるDatabricksデータベース（スキーマ）から、同じクエリ内で異なるライブラリ名（libname）として割り当てられたテーブルを結合することを許可しません。代わりに、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でApache 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ファイルはPythonプログラムからアクセス可能である必要があります。一般的に使用される方法は、FTP、HTTP、またはS3などのクラウドオブジェクトストレージへの移動です。私たちは、SCPを使用してリモートSASサーバーからDatabricksクラスターにSASファイルを移動する、よりシンプルなアプローチを使用しました。

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翻訳ツールを使用して翻訳されています) 原文記事