SAPは、インメモリ、カラムストアという優位なアーキテクチャを前提として設計された SAP HANA およびSAP HANA Cloud をご提供しています。この高速な SAP HANA Cloud のデータ処理機能を、Data Warehouse(DWH、あるいは情報系システムやOLAPと呼ばれるかもしれません)の用途でお使いいただくために、DWHの利用や運用に適した様々な機能をパッケージ化した製品としてSAP Datasphere を提供しています。SAP HANAのインメモリアーキテクチャはすべてのデータをメモリに配置する事で高速な検索処理能力を発揮しますが、一方で相対的にメモリはストレージ(HDDやSSD)よりも高価であり、大規模なデータを扱う場合にはコストも重要な課題になります。SAP HANA Cloudにおけるこのコスト最適化問題の解決策として、Native Storage Extension と HANA Cloud, Data Lakeという機能を提供していることを、過去のブログでご紹介してきました。今回のブログでは、これらの機能をSAP Datasphereで利用する方法についてご紹介いたします。
Native Storage ExtensionとHANA Cloud, Data Lakeについては、それぞれのブログ(HANA Cloud でデータの階層化を実現するNative Storage Extension(NSE)および HANA Cloud, Data Lake First step)をご参照いただくとして、ここでは概略をご説明します。
いずれの機能もSAP HANA Cloudの階層化データ管理を担うための機能です。データベースに格納されるデータは時間の経過とともに利用頻度が低下する傾向にあり、利用頻度の高いデータと、低いデータに対して同じコストをかけて維持するのは得策ではありません。利用頻度の高いデータは高い処理速度で、利用頻度の低いデータはコストに見合った処理性能の領域に格納する事で、コストとシステム性能のバランスを取る事ができます。
SAP HANA Cloud の Native Storage Extensionは、SAP HANAソフトウエアに組み込まれたデータ階層化機能で、「page loadable」という属性を与えた「データの単位」を対象に、データアクセスがなくなるとメモリから揮発し、次回のデータアクセス要求に応じてHANA Cloudのストレージ領域(永続領域)からメモリ領域に配置され、処理されることでメモリ領域のサイズを抑える事ができます。
SAP HANA Cloud, Data Lake はSAP HANAとは独立したData Lake relational engine にテーブルが作成され、HANA Cloud 上の仮想テーブルとして利用されます。Data Lake relational engineはインメモリアーキテクチャではありませんが、DWH用途には最適なカラムストアアーキテクチャを有しており、ストレージベースでありながら、(HANAには及ばないものの)高速にデータ処理を行えるエンジンとなっています。
図1 : 階層化機能 概要図
前述のNSEに関するブログにあるように、HANA CloudではNSEを利用する対象テーブルに割り当てられたパーティションに対し、SQLコマンドによる操作で「Page Loadable」属性を与える事で、対象のパーティションのデータが階層化管理の対象として機能しました。
SAP Datasphereでは、この設定方法をより簡易に行う事ができる様、管理画面のGUIを使用して設定できるようになっています。一方で、階層化管理の対象の単位は、パーテイションではなく、テーブル単位となっています。また、デフォルトの設定はNSEの機能が有効なウォームストアへの格納となっています。Databuilder の画面から、該当のテーブルのプロパティを表示させ、「テーブルデータをメモリに保存」のスライドボタンを有効にして、NSEの機能を無効化して、パフォーマンスを上げる事ができます。
図2 : テーブルデータをメモリに保存(NSEを利用しない)設定
このことから、Datasphereのテーブルを設定する際は、2つの点を考慮して行っていただく必要があります。
HANA Cloudでは、パーティション単位でNSEの機能が設定できるため、一つのテーブル(主に時間の経過とともにデータが増加するトランザクションデータのテーブル)に対して最近のデータと過去のデータを分けて階層化管理が可能でしたが、現時点ではSAP Datasphereではパーティションの作成はできますが、NSE機能の設定の粒度はテーブル単位となっていますので、テーブル単位でアクセス頻度が高いか、低いかを指針にして、NSEの機能を活用するようにして下さい。
一方で、多くのお客様が、一つのテーブルのデータに対して階層化管理を行いたいというニーズをお持ちになると想定されますので、その際は以降でご紹介するData Lakeの機能をご検討下さい。本ブログの以下の手順で設定できる構成を以下に示します。
図3: 本ブログにおける Data Lake 構成例
図3では、SAP DatasphereのスペースAにあるメモリテーブルと、Data Lakeに配したストレージベースのテーブルを活用する場合の構成を示しています。この場合でも、オンメモリほどのパフォーマンスではないものの、常にオンラインで利用する事ができる様にData Lakeのデータへは仮想テーブルを介してアクセスできるようになっています。
最初にご説明した通り、SAP DatasphereはHANA Cloudのデータベースを利用しており、通常のデータはSAP Datasphereから操作をする事で、テーブルなどのオブジェクトの管理が行われています。一方でData Lakeで利用されるテーブルは現在のところHANA Cloud から直接操作する必要があります。そのためにSAP Datasphereの Open SQL スキーマ を利用します。図3で示されているように、アクティブに利用するデータは通常のスペースで管理され、Data Lakeに格納するデータは、Open SQL スキーマを介してHANA Cloud経由で利用する、という点にご注意下さい。Open SQLスキーマについての詳細はこちらをご参照ください。
最初に、Data Lakeの機能を利用するための準備設定を行います。左画面のメニューから「スペース管理」を選択します。Data Lakeの機能を使用するスペースの「編集」ボタンをクリックします。
図4:Data Lakeを使用するスペースの選択
続いてスペース管理の画面から「概要」タブが選択されている事を確認し、「データレイクアクセス」の項で「データレイクにアクセスするには、このスペースを使用します」のチェックボックスをチェックし、保存した後、デプロイをクリックします。
図5:Data Lakeアクセスするための設定
ここでの注意点は、Data Lakeにアクセスするスペースは、1つのインスタンスにおいて1つとなります。複数のスペースでData Lakeにアクセスする場合は、Data Lakeテーブルをそれぞれのスペースで共有するようにして利用します。本ブログでは、Data Lakeアクセス可能なスペースでの手順をご紹介します。
続いてOpen SQLスキーマを利用する準備を行います。
左端のメニューから「スペース管理」を選択し、「データベースアクセス」タブをクリックします。データベースユーザにある「作成」ボタンをクリックし、OPEN SQL スキーマにアクセスするためのデータベースユーザを作成します。これはSAP Datasphereとは異なる、HANA Cloudへアクセスするためのユーザになります。
図6: Open SQL Schemaにアクセスするためのデータベースユーザの作成
データベースユーザの作成画面では、「データベースユーザ名の接尾辞」を設定し、「読み込みアクセスを有効化」、「書き込みアクセスを有効化」をチェックして「作成」をクリックし、データベースユーザを登録します。画面が閉じたら、「保存」をし、続けて「デプロイ」を実行してください。
図7 : データベースユーザの登録
図8 : 保存とデプロイの実行
デプロイが完了し、ユーザが追加されたら、そのユーザのチェックボックスにチェックを入れ、行の右端にあるインフォメーションアイコンをクリックします。
図9 : 追加されたユーザの情報確認
データベースユーザ詳細画面が表示されますので、Open SQL スキーマパスワードを取得します。「新しいパスワードを申請」ボタンをクリックし、可視化ボタン(目玉アイコン)を押してから「パスワードのコピー」をクリックし、作成したユーザ用のパスワードを入手します。以後、この画面からは同じパスワードを入手する事はできませんので、必要があれば記録しておいてください。ただし、本シナリオの場合はログインの度に毎回新しいパスワードを生成しても特に問題はありません(ので記録し忘れても大丈夫)。
図10 : データベースユーザのパスワードの取得方法
取得したパスワードを使って、Open SQL スキーマの領域にアクセスします。前述しましたが、Open SQL スキーマとは、SAP Datasphereの管理下ではないHANA Cloud から操作する必要があります。そのため、SQLコマンドを使用することができる、データベースエクスプローラーというツールを介して操作します。作成したデータベースユーザにチェックを入れ、メニューにある「データベースエクスプローラを開く」をクリックします。
図11 : データベースエクスプローラの起動
ログインプロパティの入力画面に先ほど取得したパスワードを入力し、「OK」すれば、Open SQL スキーマを管理するHANA Cloudへのログインが完了します。
図12 : ログインプロパティの入力
ログインに使用したデータベースエクスプローラは、HANA Cloud用のSQL入力用のツールです。このツールを使用して、SAP DatasphereのOpen SQL スキーマで使用しているデータベース領域に直接SQLコマンドを実行する事ができます。以降の操作では、下の図のData Lakeにあるテーブルを作成し、このテーブルをOpen SQL スキーマにある仮想テーブルで参照する設定を行います。
図3: 本ブログにおける Data Lake 構成例(再掲)
まずData Lakeの物理テーブル(図中 ① SALES_Datalake)を作成します。HANA Cloudに接続したDatabase ExplorerからData Lakeにテーブルを作成する場合 ”DATA_LAKE_EXECUTE" というシステムプロシージャを使用し、Data Lakeを管理するData Lake relational engineに対してSQL(Create table)文を間接的に実行させます。
call "DWC_GLOBAL"."DATA_LAKE_EXECUTE"('CREATE TABLE SALES_Datalake(
Sales_ID INTEGER,
ShopID INTEGER,
Purchase_Num INTEGER,
Prod_ID INTEGER,
Price INTEGER,
Order_date date
)');
上記のSQLプロシージャ文を、Database ExplorerのSQLコンソール画面から実行します。左上にあるSQLコンソール起動アイコンをクリックし、実行してください。
図13 : Data Lake テーブル作成
次に、今作成したData Lake内のテーブルを参照する、Open SQL スキーマ内の仮想テーブル(図中② V_SALES_Datalake)を作成します。仮想テーブルの作成は ”DATA_LAKE_CREATE_VIRTUAL_TABLE" というシステムプロシージャを使用します。
CALL "DWC_GLOBAL"."DATA_LAKE_CREATE_VIRTUAL_TABLE"
( VIRTUAL_TABLE_NAME => 'V_SALES_Datalake',
DATA_LAKE_TABLE_NAME => 'SALES_Datalake'
);
Database Explorerから上記SQLプロシージャ文を実行すると、Data Lakeにある実テーブルを、SAP Datasphereから参照するための仮想テーブルが作成されます。実行完了を確認したのち、左上のペインにある「catalog」フォルダを展開し、「Table」アイコンをクリックすると、左下のペインに作成された仮想テーブルがリストされることが確認できます(図中にもあるWarningに関しては、本シナリオでは特に影響はありません)。
図14 : Open SQL スキーマ 仮想テーブル作成と確認方法
作成した仮想テーブルに対して挿入および更新するための権限を SAP Datasphere のスペースに付与します。これにより、SAP Datasphereのデータ フローによってテーブルにデータを挿入する権限を与えます。次の手順で、スペースにすべての権限を付与します(JAPAN_D&Aは実施した環境のスペース名です、適宜ご自身のスペース名に置き換えてください)。
GRANT ALL PRIVILEGES on "JAPAND&A#YAGAWA"."V_SALES_Datalake"
to JAPAND&A with grant option
図15 : 仮想テーブルに権限付与
以上で、Data Lakeに物理テーブルを作成し、Open SQL スキーマにこれを参照する仮想テーブルが作成されました。それではSAP Datasphereからこの仮想テーブルを操作してみましょう。
Data Lakeに作成したテーブルに、SQL Open スキーマにある仮想テーブル経由でデータをインポートするため、ソースとなるCSVファイルを、AMAZON AWS S3に配置し、これをDatasphereのデータフローを使ってデータを格納します。AWS S3との接続設定に関しては、こちらのブログをご参照ください。このブログに基づき、Import_Location_from_S3 という接続設定を作成しておきます。また、接続先のAWS S3 には、インポートファイルをアップロードしておいてください。サンプルとして SampleData_Datalake2024.csv を添付します。
ブラウザのSAP Datasphereのタブを選択し左のメニューから「データビルダ」を選択、「フロー」タブをクリックし、「新規データフロー」タイルをクリックします。
図16 : AWS S3からCSVファイルをインポートするデータフローの作成
新規データフロー作成画面にて、左のペインから「ソース」タブをクリックし、「接続」フォルダを展開すると、上記で準備した Import_Location_from_S3がリストされます。これを展開すると、アップロード済のファイルがリストされます(下の画面では、AWS S3に作成したフォルダ dspimportlocation の下)。この中からData Lakeに配置するためのデータ SampleData_Datalake2024.csv を、Drug &Dropし、中央のワークスペースに配置します。
図17 : AWS S3に配置したCSVをソースとして定義
つづいて「リポジトリ」タブをクリックし、作成した仮想テーブル「V_SALES_Datalake」をクリックし、ワークスペースにDrug & Dropします。この時同時に表示されるコンテキストメニューから「ターゲット」を選択します。
図18 : 仮想テーブルをターゲットとして定義
ワークスペースのソースオブジェクト(AWS S3ファイル)の黒い ● を、ターゲット(V_SALES_Datalake)にDrug & Drop で結線し、ターゲットオブジェクトをクリックしたのち右のペインのプロパティ画面を下方にスクロールして、ソースとターゲットの項目をマッピングします。こちらも左の項目をDrug &Dropすることでマッピングする事ができます。なお、ソースのCSVファイルの1行目にヘッダー行としてターゲットテーブルのカラム名を記入しておくと、自動マッピングする事も可能です。
図19 : ソースとターゲットの関連付け
設定したデータフローを左上のアイコン「保存」し(データフロー名を指定します)続いて「デプロイ」します。ワークスペースの中央下に「Deployed...」のメッセージが表示されたらデータフローの準備は完了です。このメッセージは自動的に消えますのでご注意下さい(しばらくすると右ペインのプロパティの表示が「未デプロイ」から「デプロイ済み」に更新されるので、こちらで確認可能です)。
図20 : データフローの保存とデプロイ
このデータフローにより、AWS S3にアップロードされたCSVファイルを、Data Lakeにインポートできるようになりました。このワークフローをスケジュールに基づき実行させる場合は、右ペインのプロパティの「実行ステータス」にある「スケジュール」アイコンをクリックし、スケジュールを作成する事ができます。ここでは、すぐにデータフローを実行したいので、左上にある「実行」アイコンをクリックし、データフローを実行します。
図21 : データフローのスケジュール実行と直接実行方法
データフロー完了のメッセージ(DIRECT run of DATA_FLOW .... completed このメッセージは自動で消えます)を確認するか、右ペインのプロパティにある実行ステイタスで「完了」を確認したら、ターゲットオブジェクトをクリックし、表示されるコンテキストアイコンから「データのプレビュー」をクリックすると、下方にこのオブジェクトのデータを確認する事ができます。このオブジェクトは仮想テーブルであり、その実態はData Lakeを参照しているので、これでData Lakeにデータをインポートしたことが確認できました。
図22 : データフローの実行確認と、その実行結果の確認
SAP Datasphereにおける Data Lakeの利用方法については以上となります。
SAP DatasphereにてData Lakeを利用したときのパフォーマンスに関する情報として、以下のブログが参考になりますので、リンクをご紹介しておきます。
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
33 | |
13 | |
11 | |
11 | |
10 | |
9 | |
9 | |
9 | |
8 | |
7 |