SASとGreenplumを統合する

はじめに

この記事は、SAS ETLを使用してデータウェアハウスを構築する人にとって興味深いものです。 最近、ストレージをGreenplumデータベースに移行するプロジェクトのアクティブフェーズを完了しました。 これ以前は、SASデータセットはデータベースとして使用されていました。 実際、テーブルはファイルシステム上のファイルでした。 ある時点で、データボリュームの増加率がファイルシステムのパフォーマンスを向上させる速度よりも大きいことが明らかになり、専用データベースへの切り替えが決定されました。



プロジェクトを開始したとき、SAS DISとGreenplumの間のリンクに関してインターネット上で何かを見つけることは不可能でした。 移行の主なポイントと、この記事のプロセスで生じた困難を強調したいと思います。



プロジェクトの追加の複雑さは、プロセスをゼロから構築するのではなく、既存のプロセスを作り直す必要があるという事実でした。そうしないと、プロジェクトの条件とコストが受け入れられないでしょう。 歴史的に、ETLとして、SAS、特にSAS Data Integration Studioを使用しています。 ここでの各ETLプロセスは、いわゆる 入力テーブル、その処理のロジック、出力テーブルが存在するジョブ。 毎日のストレージの読み込みプロセスは、約800個のこのようなジョブで構成されています。 彼がGreenplumへの入力/出力テーブルの転送に勝つために、それらをやり直す必要がありました。

SAS / Greenplumのアクセス

SAS Baseで記述されたコードは、データベース内のテーブルとどのように機能しますか？ さまざまなデータベースには、通常<データベース名>のSAS Accessと呼ばれる一連のSAS製品があります。 Greenplumのこのようなコネクタは、SASから使用できる特別なラッパーを備えたODBCドライバです。 コネクタは、データにアクセスする2つの方法を提供します。

• データベーススキーマはSAS libnameを介して定義され、テーブルは通常のSASデータセットと同様に操作できます。 この場合、SASコードはデータベースの指示に暗黙的に変換されますが、そのような変換が不可能な場合（たとえば、GreenplumにないSAS関数が使用される場合）、SAS側の要求処理が適用されます。
• SQLパススルー。 proc sqlでは、実際にそのままODBCドライバーに渡されるコードを作成できます。

SAS Data Integration Studioでは、パススルーメカニズムを使用するコードは「SQL Join」変換のみを生成でき、残りは通常のSASコードを生成します。これは最終的にコネクタに渡されるものを（ログで）チェックする必要があります。 誤って生成されたコードの例がありました。

仕事-> Greenplum Work

デフォルトでは、SASのジョブの原則は、Workが一時テーブルの場所として使用されるというものです。ディスク上のセッションの開始時に作成され、プロセスの現在の所有者のみがアクセスでき、終了後すぐに削除されるディレクトリです。 この作業には、SAS Base言語が適用可能なSASデータセットが含まれているため、ETLを非常に迅速に開発できます。 また、このような分離により、落ちたジョブの場所を簡単に「クリーニング」して、使用するディスク容量を制御できます。 ジョブをGreenplumに転送すると、中間テーブルの一部（またはすべて）がWORKからGreenplumに移動し、これらのテーブルをデータベースのどこに配置するかという疑問が生じました。



SASでは、Greenplumで一時テーブルを操作することは許可されていないため、オプションの1つは、それらに別のスキームを使用することでした。 しかし、このアプローチにはいくつかの重大な欠点がありました。

• SAS DI Studioでの自動コード生成では、不要になったテーブルは削除されません。 すべてのジョブに組み込まれた何らかの種類の手順が必要です。 ETLヘルパーテーブルの全量をデータベースに常に保持するのは無駄です。
• 並列ジョブでは名前の競合が発生する可能性があります。
• 問題が発生した場合、テーブルが誰（どのジョブ）に属しているかを特定することは困難です。

その結果、別のアプローチが選択されました-データベースでSASの動作を再現するため。 各SASセッションは、このセッションのすべての中間テーブルが追加されるスキーマをGreenplumに作成します。 いくつかの詳細：

• そのような「作業」スキームの1つは、1つのSASセッションに対応します。 SASセッションの開始時に、Greenplumにスキームが作成され、SASライブラリがそれに割り当てられます。
• 作成されたスキームの名前は、SAS work、host、user、processへのパスなどの必要な情報をエンコードします： ％let LOAD_ETL_WRK_SCH_NAME = work_％substr（％sysfunc（pathname（work））、％sysfunc（prxmatch（/（？<= SAS_work） ./,%sysfunc(pathname(work)))),12)_&SYSUSERID._srv%substr(&SYSHOSTNAME.,% eval（％length（＆SYSHOSTNAME。）-1））_＆SYSJOBID。;
• 冠には、Greenplumの時間スキームの「クリーナー」を配置しました。 Greenplumの各「work_」スキームに対応するSASセッションの存在を確認し、存在しない場合は「work_」スキームを削除します。

DI Studioは、スキーマとLOAD_ETL_WRK_SCH_NAMを使用してODBCライブラリを作成し、必要に応じて中間テーブルを割り当てます。

SASとGreenplum間のデータ転送

この運用方式では、主な問題の1つはSASとGreenplum間のデータ転送速度です。 GreenplumからSASへのデータ転送は常にマスターノードを経由し、ドライバーの速度によって制限されます。 速度は、ページ化されたテーブルのフィールドの幅と構成に依存し、平均で約50MB /秒になります。



SASからGreenplumへのデータのダウンロードは、はるかに興味深いものです。 Greenplumでは、テキストファイルからの一括読み込みが可能です。 このメカニズムの本質は、外部ファイルが外部テーブルとして定義され（ETLホストにインストールされた特別なユーティリティによってGreenplumにアクセスできる）、マスターをバイパスしてデータホストに直接ロードされることです。 これにより、ダウンロード速度が大幅に向上します。 SAS側から見ると、プロセスは次のようになります。テーブルはcsvファイルにアップロードされ、Greenplumはこのファイルをデータベースに強制します。 ただし、このプロセスの速度は、テーブルをSASからcsvファイルにアンロードする速度に大きく依存することが判明しました。 ファイルは最大20〜30MB / sの速度でアップロードされ（プロセッサ上に置かれます）、Greenplumのcsvダウンロード速度は150 MB / sを超えます。 大きなテーブルの場合、これによりダウンロード速度が完全に不十分になりました。 加速は、ロードされたテーブルをパーツに分割することによって得られました。複数の並列スレッドが起動され、それぞれがテーブルの独自の部分で動作します-csvでアンロードし、Greenplumで挿入します。 これにより、Greenplumでのデータの読み込み速度を最大90〜100 MB / sに増やすことができました。

ETLプリミティブ

DI Studioで作業するには、いくつかの変換を書き直す必要がありました。 標準的なものは、次善策で動作するかエラーで動作するコードを生成しました。 これらは、Table LoaderとSCD Type2 Table Loaderです。 一部の場所では、テーブルをGreenplumに転送するため、ジョブを編集する必要がありました。たとえば、標準の変換「ルックアップ」は、両方の入力テーブルがデータベースにある場合、非効率的に動作します。

結論の代わりに

この記事では、移行プロセス中に対処する必要があった主なタスクについて説明します。 この記事の範囲をはるかに超えています。 ハッシュ結合、ユーザークエリによるテーブルロック、パーティション化および圧縮の問題。 興味がある場合は、次の投稿でこれについて詳しく説明します。