最近、SASからDatabricksへ移行する案件をいくつかこなしているが、移行に関する情報は非常に少ない。おそらく両方使える人材が少ないこと、難易度が高いなどの理由があると思われる。

そこでSASからDatabricksに移行する際の注意点をまとめてみる。SAS→Databricks移行のためには大きく分けてデータ移行とプログラム移行の2つある（気が向いたら管理周りについても書きます）。今回はデータ移行について書く。

前提

そもそもSASからDatabricksの移行とは、「SAS v9がインストールされたSASサーバーで管理されたデータセットおよびETLプログラムなどのアセットをDatabricksに移行する」ことを指す場合がほとんどだろう。本記事もその前提に立つが、SAS v9の製品群は非常に複雑なので、スコープをSAS言語で書かれたプログラム、Enterprise Guide（以下EG）で作られたプロセス（データフロー）とSASデータセットを移行対象とすることを前提とする。あとSAS Data Integrationは単純に使ったことが無いので対象外。

またユーザー管理やセキュリティも移行・もしくは再設定が必要だが、それについては言及しない。ただしデータ管理についての考慮事項は記載する。
現在のSASはSAS Viya環境も存在しているが、SAS ViyaからDatabricks移行については本記事の対象外とする。代わりに後日SAS ViyaとDatabricksの比較記事でも書く（多分ニーズはない）。

データセットの移行

SASデータセットはライブラリ→データセットという階層で管理される。これはDatabricksでいうところのスキーマ→テーブルという階層に近い。階層構造はそのまま継承してしまって良いだろう。

問題はデータセット。SASデータセットはデータ型が数値か文字しかない、ガバガバな構造になっている。数値型に整数型、ブール（0,1のフラグ変数）、小数点型、さらには日付も含まれる。なので、データ移行の際には各テーブルの変数をどの変数型で定義するか、マッピングする必要がある。

厄介な文字変数のブランク

SASの文字変数はNULLが存在せず、欠損値は全て長さゼロのブランクとなる。安直に考えるとこのブランクは全てNULLにしてしまえば良いのだが、ここに落とし穴が潜む。SASではこのブランク値はNULLではないので、ブランク同士の結合ができてしまう他、文字列操作の関数の結果もNULLではなく普通に結果が返ってくる。
また、SASではWHERE var1 IS NULL とWHERE var1 =''は同義なので、抽出結果は同じになるが、Databricksでは両者で結果が異なってくるので、ブランクをNULLに置換して移行する際はプログラムも精査が必要となる。

フォーマット・ラベル

SASデータセットに設定されている変数ラベルやフォーマットは、Databricksに対応する機能は存在しない。ラベルについては必要に応じてコメントで対応する。フォーマットは残念ながら諦めるしかない。

実際の移行

移行を実施する際にはまずクラウドストレージにSASデータセットをアップロードし、Databricksからクラウドストレージ上のSASデータセットを読みにいく方法がシンプル。
SASデータセットを読み込む際はspark-sas7bdatを使用することをお勧めする。pandas.read_sasはSASデータセットの読み込みが非常に遅いので、移行にかなり時間を取られる可能性がある。なおspark-sas7bdatはクラスターにインストールが必要なライブラリなので、事前にシステム管理者との調整が必要な点に注意。