このブログは、2023 年 5 月 22 日に SAP ジャパン公式ブログに掲載されたものを SAP ジャパン公式ブログ閉鎖に伴い転載したものです。
このブログは、2022 年 11 月に開催された Teched 2022 セッション DA108 のスピーチの日本語抄訳です。オリジナルは、こちらで公開されている動画を参照してください。
また、最新の情報は、SAP Community の最新ブログやマニュアルを参照してください。
本日のアジェンダです。最初に、SAP HANA Cloud 内のデータピラミッドのコンセプトについて説明します。
データティアリングとは何かについて説明し、そのデータピラミッドを構成する HANA Cloud 内のコンポーネントについて説明していきます。
次に、データエージングやデータファネルの一般的な設計パターンについて紹介し、スキーマモデリングアプローチについて簡単に説明します。
その後、NSE (Native Storage Extension)、HANA データベース自体の機能、ペタバイトスケールの列指向データデータベースである data lake リレーショナルエンジン、data lake files、オブジェクトストレージ機能、data lake リレーショナルエンジンと data lake files 間の橋渡しをする SQL on Files 機能など、HANA Cloud のデータ階層の使用に関する、より詳細な技術事項について説明します。
お客様にとってのデータティアリングは何を意味するのかをお聞きすると、その回答は共通してお客様のデータティアリング戦略のゴールがデータ容量の拡張に関してであるということでした。同時に、所有コストを管理すること（必ずしもこれを最小限に抑えることとは限りませんが）、そして、システムの複雑性を最小限に抑えることでした。
つまり、データティアリングの導入に関する方針は、データ量について考えるところから始まります。
データ量が SAP HANA データベースのメモリーサイズに適合する場合には、データティアリングについて考える必要はありません。
同様に、データ量が SAP HANA および SAP HANA NSE（Native Storage Extension）内に収まる場合も、SAP HANA Cloud, data lake を使用する場合の複雑性について考える必要はありません。
まずデータ量に関する検討からスタートし、次にコストのトレードオフについて見ていくことになりますが、お客様にとって本当に重大な優先事項は、ストレージのコストではなく、多くの場合、データのランドスケープの複雑性を管理することでしょう。
次のデータピラミッドの図へ続きます。
SAP HANA Cloud, data lake は、数年前に初めて SAP HANA Cloud を発表した時に SAP HANA データベースとともに発表されました。(訳注 参照：SAP Sapphire 2019 Keynote Youtube 動画 10:35～)
SAP HANA Cloud の SAP HANA データベースは、従来の純粋なインメモリーデータストレージに対してクエリを実行するものです。
これに加えて SAP HANA NSE (Native Storage Extension) によって SAP HANA のデータをディスクに拡張してデータを保存する機能が追加されました。
これにより、メモリー容量を直線的に拡張しなくても、データ容量を大きく拡張できるようになりました。
一方、前述したように、SAP HANA Cloud, data lake リレーショナルエンジンは、ペタバイト規模のデータ（圧縮後）を格納できるカラムベースの構造化されたデータベースです。
これは、実績が豊富なエンタープライズスケールのデータベースであるオンプレミスの SAP IQ テクノロジーに基づいています。
この SAP HANA Cloud, data lake リレーショナルエンジンに、SAP HANA Cloud, data lake files オブジェクトストレージ機能が追加されました。
SAP HANA Cloud, data lake files には、どのようなファイルでも、つまり、構造化されたファイルでも、JSON などの半構造化ファイルでも、非構造化データでも、JPEG や、Word 文書でも、何でも格納することができます。
SAP HANA Cloud, data lake files 内のデータが CSV ファイルや Parquet、ORC などの構造化データの場合には、それらの構造化ファイル上に仮想テーブルを作成し、SQL on files コンポーネントを使用してファイルコンポーネントを通してテーブルのように処理することができます。
これにより SAP HANA Cloud, data lake リレーショナルエンジンから直接クエリを実行することができます。
右側の矢印を見てください。このグラデーションの濃淡は意図的に調整しています。
ピュア インメモリー HANA は、最高のパフォーマンスを実現しますが、そのハードウェアコンポーネントによりデータ量の制約を受けてしまいます。その結果、価格にも影響します。しかしながら、ディスクベースのストレージ使用することで、データ量を拡大できます。
SAP HANA Cloud の SAP HANA NSE (Native Storage Extension) を使用すると、SAP HANA データベースのデータを最大約 10 テラバイトまで利用することができます。
それ以上の場合には、最終結果セットまたは中間結果セットの、結果セットごとに 20 億件のレコード数という SAP HANA の機能上の制限について考慮する必要が出てきます。
そこで、SAP HANA Cloud, data lake リレーショナルエンジンにデータをオフロードすることで、構造化データをペタバイト規模まで拡張することが可能になります。
パフォーマンスに関しては、ディスクベースのデータを使用する場合には、SAP HANA Cloud のSAP HANA データベース内で SAP HANA NSE を使用しても、SAP HANA Cloud, data lake リレーショナルエンジンを使用しても、同等のパフォーマンスを得ることができます。
複雑性の観点では、SAP HANA Cloud の SAP HANA NSE には大きなメリットがあります。すべてのデータが 1 つの SAP HANA データベースにあるだけでなく、１つの SAP HANA テーブルに存在するからです。
そのため、アプリケーション開発者の観点では、データが SAP HANA のメモリー内にあるのか、SAP HANA NSE を使用しているのか、特に注意する必要はありません。1 つのテーブルに対して作業するだけです。
しかし、SAP HANA Cloud, data lake を使用する場合には、さらに別のデータベースを使用することになります。
別のデータベースがあるということは、それぞれ別のテーブルが存在するということです。そのため、アプリケーション開発者は特定のデータが SAP HANA Cloud の HANA データベースにあるテーブルにあるのか、SAP HANA Cloud, data lake リレーショナルエンジンにあるテーブルにあるのかを知っておく必要があります。
データのどのセグメントがSAP HANA Cloud の HANA テーブルにあり、データのどの部分が SAP HANA Cloud, data lake リレーショナルエンジンにあるのか、クエリ内で、明示的にこれらのテーブルを参照する必要があります。
SAP HANA Cloud の SAP HANA NSE の仕組みについては後ほどさらに詳しく説明します。
その前に一般的な設計パターンについてもう少し説明します。
1 つ目は、最も一般的なデータエージングについてです。
データティアリングについて語られる時には、通常、お客様のデータベースは増大しており、データをオフロードしなければならない状態にあります。しかしデータマイニング、機械学習、長期レポート、傾向分析、何等かの規制上の理由などの目的で、そのデータはそばで利用しやすいように保存しておく必要がある、と言われます。
データエージングシナリオでは、データは通常 SAP HANA Cloud ピラミッドの上部に投入されます。
すべてのアクティブなデータ、または少なくとも最もアクティブなデータが、この SAP HANA Cloud ピラミッドの上部に格納されます。
ご覧のとおり、このデータピラミッドは構造化されています。
次に、このデータを SAP HANA Cloud, data lake リレーショナルエンジンに移動またはコピーします。
最終的には SAP HANA Cloud, data lake リレーショナルエンジンからファイルにオフロードするかもしれません。
データエージングシナリオには、いくつかの特性があります。
最初に、テーブルスキーマは一般的に各階層で整合がとれています。階層間で列の追加や削除は行いません。
データが SAP HANA Cloud の HANA データベースまたは SAP HANA Cloud, data lake リレーショナルエンジンにある限り、データの更新は可能です。
SAP HANA Cloud, data lake files の階層では、ファイルを上書きすることもできないわけではありませんが、SAP HANA Cloud, data lake files の階層に対する update 文はありません。
2 番目に一般的な使い方は、データファネルです。
データファネルでは、通常、データは SAP HANA Cloud データピラミッドの下方から追加されます。
SAP HANA Cloud, data lake files オブジェクトストレージレイヤーのデータは、フォルダ構造として表示していることに気づかれたかもしれませんが、
この時点では、SAP HANA Cloud, data lake リレーショナルデータベースにデータは取り込まれていないため、ファイルとして表示されます。
SQL on files を介してこれらのファイルに対してクエリを実行し、これらのファイルに SAP HANA Cloud, data lake リレーショナルエンジンを介してアクセスしたり、load table を実行してこのデータを SAP HANA Cloud, data lakeリ レーショナルエンジンにロードすることもできます。繰り返しますが、これは構造化テーブルに対して行います。
データエージングシナリオとは異なるのは、多くの場合、階層によってスキーマが異なることです。
（訳注：2022 QRC で SAP HANA Cloud, data lake で HANA DB と互換のスキーマがサポートされました。https://blogs.sap.com/2022/12/29/whats-new-in-sap-hana-cloud-in-december-2022/）
スライドの例では、センサーデータを投入しています。そのセンサーデータを上の階層に移動させるのに伴いデータがエンリッチ化されます。工場に関する情報、センサータイプ、SAP HANA Cloud, data lake リレーショナルエンジンにある別の情報などが付加されていきます。
そして SAP HANA Cloud, HANA データベースに移動させる前に、そのデータにさらなる処理を実行します。
ファネルを通じて、データをどう処理するかは、お客様のビジネスケースに完全に依存します。
これは考えられる使用法の一例です。
スキーマモデリングについて、説明します。
まず、離散データサブセットの格納モデルです。
お客様は従来、個別のデータセットを使用しています。そして、たとえば今年度の鮮度の高い、あるいは価値のあるデータをインメモリーにおきます。
受注シナリオについて考えてみると、非常に意味があります。
SAP HANA Cloud の SAP HANA データベースには前年度のデータもあります。これは、前年比較を行っているためです。
SAP HANA NSE でディスクベースにして、オフロードすることもあるかもしれません。
その後、古くなったデータは SAP HANA Cloud の SAP HANA データベースから完全に削除し、SAP HANA Cloud, data lake リレーショナルエンジンに格納していきます。
このアプローチの良い点は、あるレコードのコピーを 1 つの場所に 1 つしか持たないことです。
しかし、クエリを実行し、データの全範囲を必要とするレポートを生成しなければならない場合には、2 つのデータベースを連携する必要があります。
また、データフェデレーションは、非常に機能的であるものの、パフォーマンスのオーバーヘッドがあり、完全なデータのスーパーセットを使用した代替モデリングアプローチが必要になります。
次に完全スーパーセットの格納モデルについて説明します。このモデルでは、SAP HANA Cloud のSAP HANA データベースのインメモリーデータと前年度データとを分割します。
繰り返しになりますが、これは 1 つの SAP HANA テーブルに格納することができるため、アプリケーション開発者はこれを明確に認識する必要はありません。
その後、今年度および前年度のデータを SAP HANA Cloud, data lake リレーショナルエンジンにコピーしていきます。つまり、データセット全体、この例の場合では最初の 10 年分のデータが SAP HANA Cloud, data lake に存在することになります。
そのため、SAP HANA Cloud, data lake リレーショナルエンジンでもレポートをフルで実行することができるようになります。インメモリーのパフォーマンスを必要としないレポートについては、SAP HANA Cloud, data lake リレーショナルエンジンで実行できるため、データフェデレーションとオフロードの負荷の両方を回避することができます。
それでは、この技術がどう機能するのか、実際にどう活用すればいいのか、についてお話しします。
上の右側上の図は、従来の純粋なインメモリーの SAP HANAです。
メモリー領域の約半分がデータストレージに使用されるように、サイズを設定します。残り半分はワークスペースとして維持されます。
時間の経過とともに柔軟性が向上しました。
ただし、ここで注意すべき最も重要なことは、純粋なインメモリーデータベースであっても、リカバリー性 (計画されている再起動、フェイルオーバー、いずれであっても) のためにデータをディスクに書き込まなければならないため、パーシステンスレイヤーが存在します。
純粋なインメモリーの SAP HANAでは、データをテーブルまたはパーティション全体として同時にロードします。
これは大きなモノリシックブロックです。
SAP HANA NSE（Native Storage Extension）には、SAP HANA のディスクエイジング機能が実装されています。
これらのモノリシックなカラムまたはパーティションをページと呼ばれる単位に分割します。
上の右側下の図のように、必要なページを必要に応じてロードするだけです。
そのため、20 億レコードのパーティション全体をロードするのではなく、読み込みのため、20 億レコードパーティションのうち例えば 128k 程度をロードすることも可能です。
マニュアル: SAP HANA Native Storage Extension
SAP HANA NSE（Native Storage Extension）を使用して、page loadable あるいはディスクベースにするのかのデータの割り当てには、ロードユニットと呼ばれるものを設定します。
デフォルトでは、テーブルを作成してパーティションを作成すると、すべてのデータは完全にメモリーに格納されます。これは、column loadable と呼ばれるものです。
Page loadable またはディスクベースに割り当てる場合は、完全なテーブルレベル、個別のカラムレベル、または個別のパーティションレベルで割り当てることができます。
データティアリングの場合、通常、パーティションレベルで行うのが最適な設定です。
これは、create table 文または alter table 文を使用して行います。
したがって、このことを認識する必要があるのは、これらのテーブルを作成している DBA のみです。
ここでも、アプリケーション開発者は、SAP HANA NSE (Native Storage Extension) を使用しているかどうかを認識する必要はありません。
画面の例は注文テーブルです。
O_ORDERDATE 列に基づいてパーティションを作成します。
カラム宣言内、最後のカラム、O_COMMENT カラムに注意してください。カラム定義の最後に、”page loadable” 句で page loadable に割り当てます。
これで、カラムは、その他のテーブルがどこにあっても、純粋にインメモリーであっても、常にディスクベースのデータとして格納されます。
パーティション定義は、この例では、最も古い年 2 年分、つまり 2019 年と 2020 年の分が page-loadable に設定されているので、これらは主にディスクに保存されることになります。
これらは、これらの年を参照するクエリーから完全にアクセス可能ですが、クエリーが投げられない限りはメモリー領域を占有しません。
直近の 2 年分は、column-loadable として設定します。物理的にデータを移動させているわけではありません。
パーティショニングスキームに基づいて、orders テーブルに対して、insert、update、delete の操作を行っているだけで、HANA エンジン側でそれを適切に格納します。
関連マニュアル: SAP HANA Native Storage Extension
次に、SAP HANA Cloud の SAP HANA データベースと data lake のリレーショナルエンジン間で物理的にデータを移動するにはどうすればよいか、説明していきます。
まず、最も単純なオプションは、SAP HANA データベースからのプッシュです。
SAP HANA Cloud, data lake リレーショナルエンジンのテーブルを指定する SAP HANA データベースで定義された仮想テーブルに対して標準の DML 文、insert / update / delete / select を使用します。
データを移動する場合、またはデータを一括でいずれかの方向に移動させる場合、insert / select 文を実行します。
ターゲットテーブルへの insert は、SAP HANA から SAP HANA Cloud, data lake リレーショナルエンジンにデータをプッシュする場合には、リレーショナルエンジン上に定義された仮想テーブル、つまり SAP HANA Cloud, data lake リレーショナルエンジン内の物理テーブルに対して insert を実行します。
これは、最も簡単なアプローチです。
しかしながら、これは実際にはデータ移動の方法としては、最低速のスループットになります。
そのため、多くのユースケースでは不十分であり、スループットを上げる必要がある場合には、別の選択肢があります。
2 つ目のオプションは、SAP HANA Cloud, data lake リレーショナルエンジン自体からプルする方法です。
SAP HANA データベースの接続を介して、SAP HANA Cloud, data lake リレーショナルエンジンに接続します。そして、SAP HANA データベースの物理テーブルを指定する仮想テーブルを作成し、SAP HANA Cloud, data lake リレーショナルエンジンにパスされる select 文を発行します。この仮想テーブル定義を介してSAP HANA テーブルに対して insert / select クエリを実行し、データをSAP HANA Cloud, data lake にプルします。
これは、元々オンプレミスの SAP HANA dynamic tiering でデータをマルチスレッドでプルするために開発したパフォーマンス強化の長所を活用しています。
そのため、このデータ転送方法を使用することで、スループットが大幅に向上します。
一度設定してしまえばかなり簡単です。
ここで紹介しているリンクは、接続の設定方法を説明している SAP コミュニティのブログへのリンクです。
（訳注：2022 QRC4でSAP HANA Cloud, data lake リレーショナルエンジンの各リレーショナルコンテナに SYSHDL_<relational_container_name>_SERVER という名称の専用のリモートサーバーが新たに付属し、このリモートサーバーを使用して、SAP HANA データベースに接続し、SAP HANA データベースから、SAP HANA Cloud, data lake リレーショナルエンジンのリレーショナルコンテナにデータを pull することが可能になりました。）
3 つ目の選択肢は、特にテラバイト規模のデータを処理する際には実際に最高のスループットになる方法です。一時ストレージとして SAP HANA Cloud, data lake files を使用してデータをファイルにエクスポートし、その後、それを反対側にインポートします。
構文の観点から見ると、SAP HANA データベースの構文は IMPORT / EXPORT です。
SAP HANA Cloud, data lake リレーショナルエンジン内の構文は LOAD TABLE または UNLOAD です。
マニュアル: SAP HANA Cloud Data Lake Administration Guide for Data Lake Relational Engine
SAP HANA Cloud, data lake files の直接の操作について説明します。すでに少し触れましたが、SAP HANA データベースからインポートまたはエクスポートを行うためのコードサンプルを、上の四角の枠内に記載しています。
CSV ファイルからインポートし、形式を指定して、SAP HANA Cloud, data lake files 内のファイルへのディレクトリパスを指定します。特定のファイルへのパスを指定し、ロード先のテーブルを指定します。認証情報の定義が必要です。パーミッションも必要です。
エクスポートも同じです。
SAP HANA Cloud, data lake files 内の特定のファイルにエクスポートします。
SAP HANA Cloud, SAP HANA データベースのテーブルからファイルのパターン、ファイル名のパターンが必要です。
SAP HANA Cloud, data lake リレーショナルエンジンでは、構文が異なるため、LOAD TABLE または UNLOAD を使用します。
この場合は、UNLOAD / SELECT を使用します。
再び、SAP HANA Cloud, data lake files 内の場所を指定します。
データをロードします。LOAD TABLE を使用している場合は、ファイルごとに実行する必要があります。
UNLOAD を行う場合、指定したパラメーターに基づいて、必要な数分のファイルを生成することができます。
もちろん、常に SAP HANA データベースまたは SAP HANA Cloud, data lake リレーショナルエンジンを介して SAP HANA Cloud, data lake files を操作しなければならないわけではありません。
オブジェクトストアとして SAP HANA Cloud, data lake files 独自の方法で直接使用することもできます。
主なインタフェースとしては、Web HDFS API に基づく REST API があります。
一般的な操作について見ていきます。
ファイルを置いたり、開けて読み込んだり、ファイルをマージすることができます。
また、コマンドラインユーティリティーも提供しています。
この場合、コマンドラインユーティリティーを Windows で実行しているため、HDLFS クライアントファイルユーティリティーを使用します。
ここでも、プログラムするのではなく、コマンドラインで作業した方が操作はよりシンプルです。
マニュアル: SAP HANA Cloud, Data Lake User Guide for Data Lake Files
・hdlfscli Data Lake Files Utility
最後のコンポーネント、最もクールなコンポーネントが、SQL on files の機能です。
SQL on Files が何をするかと言うと、SAP HANA Cloud, data lake リレーショナルエンジンと SAP HANA Cloud, data lake files に格納されている構造化ファイルとの間の橋渡しを行います。
これを実行するには、SAP HANA Cloud, data lake files に格納されている CSV ファイルや Parquet ファイルに対してSAP HANA Cloud, data lake リレーショナルエンジン内に仮想テーブルを定義します。
右側にコード例があります。SAP HANA Cloud, data lake files サービス内にスキーマを作成することから始めます。
SAP HANA Cloud, data lake files サービスはすでに存在するため、あらためて作成する必要はありませんが、SAP HANA Cloud, data lake files サービスでスキーマを定義する必要があります。
次に、SQL on files テーブルを定義します。
これはファイルサービスレベルです。
SQL on file エンジン自体のテーブル定義を提供します。
SQL on files テーブルを SAP HANA Cloud, data lake リレーショナルエンジンに公開するため、SAP HANA Cloud, data lake リレーショナルエンジン内に仮想テーブルを作成します。
既存のテーブルを作成します。
最後のステップはデータソースの定義です
データソースは、この仮想テーブルを構成するファイルが SAP HANA Cloud, data lake files ストレージのどこかを示します。
また、パス内のワイルドカードは、複数のディレクトリと複数のファイルを持つことができることを示していますが、この場合は CSV ファイルのみを探します。
つまり、もしそのディレクトリに非 CSV ファイルがあった場合には、そのファイルは処理されません。
SQL on files の価値は、SQL クエリで、このファイルベースのデータの使用をファイルストレージに届き次第すぐに開始できることです。
マニュアル: SAP HANA Cloud, Data Lake Administration Guide for SQL on Files
以上が、データファネルシナリオにおけるすべてです。データファネルシナリオでは、データベースにデータを高速投入する前に、事前調査、フィルタリング、場合によってはデータクレンジングを行います。
データが届き次第、リアルタイムアクセスが必要になる場合があるからです。
これらが、SAP HANA Cloud データピラミッドのコンポーネントです。
SAP HANA Cloud を使用して実際に作業を開始する際に役立つ情報を数多く用意しています。
チュートリアルカタログにも、多数のチュートリアルを用意しています。
リンクはこちらです。
SAP HANA Cloud, data lake チュートリアル
SAP HANA Cloud および SAP HANA Cloud, data lake のタグで検索してください。
SAP HANA Cloud, data lake files、SAP HANA Cloud, data lake リレーショナルエンジン、SQL on files をお試しください。
SAP コミュニティのブログ記事の数も増えてきています。リンクはこちらです。
SAP HANA Cloud, data lake というタグで検索してみてください。
今後さらに質問がある場合は、SAP Community を利用して、質問することができます。質問でもSAP HANA Cloud または SAP HANA Cloud, data lake のタグを使用してください。
如有侵权请联系:admin#unsafe.sh