はじめに
**本ブログはこちらのブログを参考に書かれたものです。
全5回のシリーズでご紹介していく予定です。
このブログは、Part5 複製フローのサイジング についてご紹介します。
Part 1 : 複製フロー概要
Part 2 : デルタキャプチャと変換フロー
Part３：Google BigQueryをターゲットととした複製フロー
Part 4 : Amazon S3をターゲットとした複製フロー(近日公開予定)
Part 5 : 複製フローのサイジング(本ブログ)
SAP Datasphereはデータランドスケープをシンプル化し全ての利用者に意義のあるデータを届けるだけでなく、データに含まれるビジネスロジックとコンテキストを維持することでデータの価値を引き出すビジネスデータファブリックの構築を実現します。
本ブログシリーズでご紹介する複製フローはそのビジネスデータファブリックの実現に欠かせない役割を果たす機能の1つであり、データの抽出や複製によって失われがちなビジネスコンテキストを１から再構築する必要をなくし、信頼性の高いデータをご利用頂くことを可能とします。
今回のブログでは、複製フローのサイジングについてサンプルシナリオに沿ってご紹介していきます。
目次
- 複製フローのユースケースとSAP Datasphereテナント構成
- 複製フローの用語の定義とサイジング
- 複製フローを利用する際のサンプルシナリオのサイジング
- 複製フローを利用したデータモデル作成時の注意点および、データ変更時の例
- まとめ
1.複製フローのユースケースとSAP Datasphereのテナント構成
複製フローには主に3つのユースケースがあります。
それぞれのケースでのサイジングの概要をご紹介します。本ブログでは「複製フロー」についてご説明し、変換フローの使用とサイジングについては詳しく説明しませんのでご了承ください。変換フローは技術的には Datasphere の基盤となる HANA Cloudのコンピューティング リソース上で実行されます。
ユースケース① 外部システムからのデータ取り込み
複製フローを利用してサポートされているさまざまなソースシステム (例: SAP S/ 4HANA、SAP ECC、SAP HANA など) から SAP Datasphere のローカルテーブルにデータを追加します。この場合、データを "従来の(デルタキャプチャなしの)" ローカルテーブルにロードするか、デルタキャプチャを使用してローカル テーブルにロードするかを選択できます (複製フローでロードタイプ "初期 + デルタ"を選択する場合、デルタキャプチャはデフォルトでオンになります)。
ユースケース② 外部システムへのデータ転送
データが SAP Datasphere (ローカル テーブルなど) ですでに利用可能であり、SAP・non-SAP を含むターゲットシステムにデータを転送する必要があるユースケースです。変換フローの変換や、Datasphere スペースのローカルテーブルを作成することで、データが外部転送可能になります。
現時点では、初期ロード機能を使用した Datasphere ローカルテーブルのみがサポートされていますが、追加の機能拡張が計画されています。SAP Datasphere のロードマップ エクスプローラーで最新情報を確認してください。
ユースケース③ パススルーでのデータ転送
複製フローは、SAP Datasphere にデータを保持せずに、ソースシステムからSAP Datasphere 以外のターゲットシステムにデータを直接複製することも可能です。サンプルシナリオとして以下のような場合が考えられます。
- SAP S/4HANA Cloud から Google BigQuery にデータを複製する
- SAP ECC から SAP HANA Cloud にデータを複製する
- SAP S/4HANA オンプレミスから HANA Data Lake ファイルまたはサードパーティのオブジェクト ストアにデータを複製する
後ほど、各ユースケースのサイジングについて考慮すべきポイントをご紹介します。
次の章では、複製フローのサイジングを理解するために必要な、複製フローの重要な用語について説明します。
2. 複製フローの用語の定義とサイジング
用語の定義：複製フローは、バックグラウンドで実行される複製フロージョブによって、設定されたソースシステムからターゲットシステムにデータを複製します。複製フロージョブには、複数の複製スレッドが含まれています。複製スレッドはソースシステムとターゲットシステム間の初期およびデルタ ロード時にデータの転送を行います。複製フローには、ユーザーが自由に複製スレッドを割り当てることができるため、大量のデータをレプリケートする場合には複製スレッド数の設定を変更することでパフォーマンスの改善が見込めます。ただし、複製スレッドはデフォルト値があること、初期ロードプロセスの複製フローに割り当てることができる並列スレッドの最大数があることに注意してください。
各項目の説明は下記をご確認ください。
| 用語 | 定義と説明 |
| 複製フロー | SAP Datasphereのユーザー向け機能を指します。複製フロー作成用のデータビルダーUIとデータ統合モニターを使用してデータ複製をモデル化・監視できます。 |
| 複製オブジェクト | ソースシステム内でユーザーが選択しているソース データセットを指します。複製オブジェクトはターゲットシステムに複製されます。複製オブジェクトは、SAP S/4HANA のCDS ビュー、SAP Business Suite (SAP ECC) のテーブル、SAP HANA Cloud のテーブルなどが含まれます。ユーザーは、複数の複製オブジェクトを複製フローに追加できます。複製フローごとに最大 500 個の複製オブジェクトを割り当てることができます。 |
| 複製フロージョブ | 実際にデータを複製するジョブ を指します。ソースシステムからターゲットシステムにデータを複製する際にバックグラウンドで実行されます。 SAP Data Intelligence Cloud では、複製フロージョブは「ワーカー グラフ」と呼ばれます。 1 つの複製フロージョブは5 つの複製スレッドで構成され、初期およびデルタロード実行中にデータを複製します。Datasphere テナントごとに並列実行できる複製フロージョブは最大 10 個です。 デフォルトでは、複製スレッド内の複製フローごとに 2 つの複製フロージョブが割り当てられます。 複製フロージョブは、こちらの「データ統合」セクションの「最大並列ジョブ数」のジョブを指します。 |
| 複製スレッド（初期ロード） | 初期ロードフェーズ中にソースからターゲットシステムにデータを転送するスレッドで、1 つまたは複数のスレッドが並行して実行されます。 SAP Datasphere テナントごとに、合計で50 個を超える複製スレッドを並行して実行することはできません。 1 つの複製フロー ジョブ (= RF ジョブ)には通常、データをレプリケートできる5 つのレプリケーション スレッドがあります。 デフォルトでは、ユーザーが SAP Datasphere UI で作成している各複製フローに10 個の複製スレッド(10 = 2 RF ジョブ * 5 スレッド) が割り当てられます。この数は、複製フローの作成時にユーザーが変更できます (リンク)。 |
| 複製スレッド（デルタロード） | デルタロード実行中にデータを転送するスレッドの数を指します。現時点では、1 つの複製オブジェクトが一度に使用できるデルタスレッドは 1 つだけのため(ただしCDS および SLT の場合を除く)、Datasphere テナントごとの複製スレッドの全体の最大合計数が複製オブジェクトの必要数より大きい必要があります。 デフォルトでは、デルタロード実行中に複製オブジェクトごとに 1 つのスレッドが割り当てられます。 |
注意: ユーザーがテナントごとに設定可能な現在の最大数 (= 50 複製スレッド) を超える複製スレッドを複数の複製フローにわたって割り当てた場合、デルタ ロードでは並列に複製が実行されます。後ほど、ユーザーがデータを変更する場合などのいくつかのシナリオ例を説明します。詳細は、「4.複製フローを利用したデータモデル作成時の注意点および、データ変更時の例」の章の情報を確認してください。
次の図は、ユーザーが データビルダ内の SAP Datasphere UIで選択できる複製フローの項目と、技術的なランタイムアーティファクト (= 複製フロージョブ) との関係を示しています。ユーザーは複製フロージョブを SAP Datasphere システムで実際に見ることはできず、SAP Datasphere データ ビルダーおよびデータ統合モニター アプリに搭載された複製フローUIを利用して設定が可能です。
次に、SAP Datasphere テナントの複製フローのサイジングで使用される用語を確認しましょう。これらの用語については、SAP Datasphere Estimatorおよび SAP Datasphere テナント構成ドキュメントでも確認できます。
| 用語 | 定義と説明 |
| データ統合ブロック | SAP Datasphere Estimatorのデータ統合では、Datasphereテナントでデータ複製シナリオに複製フローを使用するために必要なデータ統合のブロック単位での容量設定が可能です。 |
| ノード実行時間 | 複製フローの消費単位は、一定期間の複製フローのメモリ使用量に基づいて計算されます。 |
| 最大並列ジョブ | データの複製に使用される、複製スレッドによる並列化の数です。この数は、複製フロージョブの数を指します。 最大並列ジョブ数は、データ統合ブロックの数から自動で設定されます。各テナントで最大100 個のデータ統合ブロックが割り当て可能で、 100 ノード実行時間と10 個の複製フロージョブまでの設定が可能です。 Datasphere テナントごとの並列ジョブのデフォルトおよび最小数は、2です。 |
| プレミアムアウトバウンド ブロック | 複製フローを使用してnon-SAP ターゲットシステムにデータをロードする場合は、データ統合ブロックに加えてプレミアム アウトバウンド ブロックを購入する必要があります。プレミアム アウトバウンドの計算は複製されるデータボリュームに基づいており、1ブロックあたり 20 GB (データ ボリューム) の複製が可能です。 |
次に、SAP Datasphere テナント構成の 2 つの異なるコンポーネント (「データ統合」と「プレミアム アウトバウンド統合」) を、このブログで前述した複製フローのユースケースと合わせてご説明します。
ユースケース① 外部システムからのデータ取り込み
ユースケース①では、複製フローを使用してさまざまなソースシステムからSAP Datasphereをターゲットとしてインバウンドデータ移動を実行するときに、「ノード実行時間」を計算する必要があります。
ユースケース② 外部システムへのデータ転送
ユース ケース②では、Datasphere からデータを複製するときに複製フローを使用するため「ノード実行時間」を計算する必要があります。non-SAPシステム (Kafka、BigQuery、Amazon S3、サードパーティ オブジェクト ストアなど) をターゲットとしてデータを複製する場合、SAP Datasphere テナントの追加構成としてプレミアム アウトバウンドを計算する必要があります。データが SAP HANA Cloud や SAP HANA Data Lake Files などの SAP ターゲット システムに複製する場合、プレミアム アウトバウンドの計算は必要ありません。
ユースケース③ パススルーでのデータ転送
ユース ケース③では、ユース ケース①および②と同様に、複製フロー利用時の「ノード実行時間」を計算する必要があります。複製フローのターゲットシステムがnon-SAPである場合、non-SAP ターゲットシステムにロードされるデータ量に基づいて、プレミアム アウトバウンドを追加構成に含む必要があります。データをSAP HANA Cloud や SAP HANA Data Lake Files などの SAP ターゲット システムに複製する場合、ユースケース②と同様に、プレミアム アウトバウンドは必要ありません。
パフォーマンス測定について
サンプルシナリオのサイジングに入る前に、このブログのサンプル計算に使用されているパフォーマンス測定についてご説明します。
テストの結果から、測定単位「セル」（セル＝行×列）が、性能を測定するための良い指標であることがわかりました。これは、レコードベースの性能計算よりも精度が高いです。これは、さまざまな列の量を持ついくつかのソースデータアーティファクトが存在するためです。例えば、ACDOCAに基づくCDSビューは400列まであり、小さなCDSビューは50列しか持たない場合があります。列の数がレコードの総パフォーマンスに大きく影響するため、ある一定の時間内に複製できるレコードの数、例えば1時間あたりの複製されたレコード数などに対して、異なるデータセット間で大きな変動が発生するリスクを減らすために、「セル」という測定単位を使用します。
データセットのセル数の計算例
SAP S/4HANA の CDS ビュー A : 1,000 万レコード × 50 列 = 5 億セル
SAP S/4HANA の CDS ビュー B : 1,000 万レコード × 350 列 = 35億セル
3. 複製フローを利用する際のサンプルシナリオのサイジング
次に、SAP S/4HANA システムからCDS ビューを利用して SAP Datasphere にデータをロードするサンプルシナリオを見ていきます。初期ロードとデルタロードで必要なデータ統合ブロックの量を計算する必要があります。実際の計算は複雑であるため、今回は仮定を置いて計算を簡略化して計算を行っています。
サンプルシナリオの説明: SAP S/4HANAオンプレミスからSAP Datasphereデルタローカルテーブルへのターゲットシステムに対して、合計初期ボリュームが6億レコードの20のCDSビューのデータを複製します。ここでは、20のCDSビューが平均で150の列を持っていると仮定します。ユーザーが20のCDSビュー全体の初期ロードに対して希望する複製スループットは1時間あたり6000万レコードと想定します。
デルタ ロードでは、20のCDSビュー全体でリアルタイムに読み込むための合計変更ボリュームが1時間あたり1000万レコードと仮定しています*。
* 複製フローのニアリアルタイム デルタ複製は、まだ利用できませんが、2024 年Q1に提供される予定です (更新状況はロードマップ エクスプローラーを確認してください)。
詳細なサイジング計算に入る前に、サイジング計算を簡単な方法で行うための仮定についても説明します。
注意：このブログのサイジング計算および数値を通して、サンプルシナリオに対するおおよそのサイジングの数値についていくつかのガイダンスを提供しますが、実際のシナリオに1:1に適合しない可能性があります。実際の計算は個々の要件に依存することにご注意ください。
前提条件：
- このサンプルサイジング計算では、インフラストラクチャやネットワーク関連の構成は考慮していません。
- 各CDSビューごとに個別に複製するセルの量を計算する代わりに、すべてのCDSビューに対する平均列数（平均で150列）に基づいてセルの量を計算します。
- 初期ロード中の各複製スレッドごとの平均パフォーマンスを1時間あたり5.2億セルと仮定します。ただし、異なるソースとターゲットシステムの組み合わせを使用したサンプルシナリオに対しては数値が変動するため、後ほどいくつかの追加のスループットの数値を使った計算をご案内します（例：SAP S/4HANAからオブジェクトストアへの複製またはSAP Business SuiteからGoogle BigQueryへの複製など）。1つのセルの平均サイズが10バイトであると仮定すると、これは複製スレッドごとに約4.8ギガバイト（GB）のスループットに相当します。
- デルタロード中の各複製スレッドごとの平均パフォーマンスを1時間あたり2.6億セルと仮定します。理由：デルタロードフェーズ中のスループットは初期ロードと同様に最大で1時間あたり5.2億セルまで複製できますが、通常、デルタロードフェーズ中は初期ロードフェーズと比較して同じボリュームの連続した複製は行われません。デルタロードのボリュームは初期ロードのボリュームのおおよそ半分程度で十分なことが大半ですが、個々のシナリオやシステムランドスケープによって異なることがあります。
- 前述の通り、現在のところDatasphereテナントごとに最大10の複製フロージョブの制限があります。こちらは拡張が計画されています。最新情報については、SAP Datasphereロードマップエクスプローラーをご確認ください。
上記のパフォーマンスの仮定に基づいて「クイックサイザー」を使用した計算の概要と、最大並列ジョブ数（＝複製フロージョブ）を使用して3つの異なる構成で達成可能なスループットを説明しています。
* 平均スループットが初期ロードの複製スレッドごとに1時間あたり5.2億セルであると仮定した場合： 最初の例では、1つのRFジョブを使用して520億セル/時 × 10の複製スレッド = 5,200億セル/時
** 平均スループットがデルタロードの複製スレッドごとに1時間あたり2.6億セルであると仮定した場合： 最初の例では、1つのRFジョブを使用して260億セル/時 × 10の複製スレッド = 2,600億セル/時
*** 将来的に拡張予定、更新情報はロードマップエクスプローラーをご確認ください
サンプルシナリオに沿ってSAP Datasphereテナントのサイジングを行うために、3ステップで計算を行います。
必要なパフォーマンススループットから複製するデータ量を計算する
顧客の希望するスループットに基づき初期データ複製で必要なジョブの数を計算する
ノード実行時間に基づいてデルタロード中のリアルタイム*データ複製の必要なサイジングを計算する
*複製フローのニアリアルタイムデルタ複製は、まだ利用できず、2024年Q1に提供される予定です（ロードマップエクスプローラーを確認してください）
1. 必要なパフォーマンススループットから複製するデータ量を計算する
まず、データ数値 (レコードベースの数値) を「セル」の数値に変換します。ここでは列の平均数を利用していますが、実際には、CDS ビューごとの数値を掛け算することで具体的な数値が求まります。今回は、レコード全体の数にすべての CDS ビューの平均 150 列の数を掛けた値を利用します。
セルのデータ総量 = 6億レコード × 150列 = 合計 9,000億セル
希望スループット = 6000万レコード × 150列 = 9,000万セル / 時
2. 顧客の希望するスループットに基づき初期データ複製で必要なジョブの数を計算する
次に、顧客の希望するスループットと初期ロード中の1つの複製スレッドが処理できるパフォーマンススループットに基づいて、必要な複製フロージョブの数を計算します。
9,000万セル/時(希望スループット) ÷ 1複製スレッドあたりの520万セル/時 = 17.31 ≈ 18の複製スレッド
希望するパフォーマンススループットを達成するために必要な複製スレッドの数がわかったので、初期ロードフェーズの必要な複製フロージョブの数と「ノード実行時間」を計算します。18の複製スレッド ÷ (1 複製フロージョブあたり)5つのスレッド = 3.5 ≈ 4つのジョブ = 400ノード実行時間（200時間の追加 + 200時間の無料）
4つのジョブから400ノード実行時間が計算されました。前述のように、100データ統合ブロックごとに別の並列ジョブが利用可能になるため、合計で400ノード実行時間が必要です。
各SAP Datasphereテナントに無料で提供される200ノード実行時間を差し引くと、初期ロードフェーズの追加の200ノード実行時間を得るために200のデータ統合ブロックを割り当てる必要があります。これはSAP Datasphere Calculatorでは次のようになります。
3. ノード実行時間に基づいてデルタロード中のリアルタイム*データ複製の必要なサイジングを計算する
リアルタイム複製の使用ケースを検討するにあたり、ソースシステムで生成されるデルタレコードを複製するために各複製フロージョブが24時間×7日間実行されていると仮定します。1か月あたり30日間で、1つのジョブあたり720時間（＝ノード実行時間）です。1時間あたり1000万レコードという仮定に基づいて1日あたりの複製する必要があるデルタの量を計算し、「セル」の数値に変換します。再び平均150列の数を使用します。
1日あたりの複製するデルタ量の計算： 1時間あたりの1000万レコード × 24時間 = 1日あたりの2.4億セル × 150列 = 1日あたりの360億セル
1つの複製フロージョブが1日あたり処理できる最大スループットの計算： 1時間あたりの2.6億セル × 24時間 = 1日あたりの62.4億セル（1スレッドあたり） × 5つのスレッド（1つのジョブあたり） = 1日あたり312億セル（1つのジョブあたり）
シナリオにおいてリアルタイムデータ複製の変更量を処理するために必要な複製フロージョブとノード実行時間を計算し、整数値に切り上げます。バッファと、テナント構成での複製フロージョブの設定は整数のみ可能なためです。
必要な複製フロージョブの数 = 360億 セル ÷ 312置くセル（1つのジョブあたり） = 1.2 ≈ 2つの複製フロージョブ × 720時間（1つのジョブあたり） = 1,440時間（Node Hours）
上記の計算では、第3ステップの最初で述べた720時間の実行時間に必要な複製フロージョブの数を掛け算しています。
注意: リアルタイム複製が必要でない場合、2024年Q1からユーザーはデルタロードの頻度を次のパラメータを使用して構成できるようになる予定です。これによりデルタ更新間隔を特定の頻度で実行でき、例えば1時間ごと、1日ごとの最大回数などを設定できます。このオプションを使用すると、ユーザーは必要に応じてデルタ更新の間隔を設定できますので、デルタロードフェーズのサイジングを小さくすることが可能で、ニアリアルタイムの使用ケースよりも少ないノード実行時間の消費となります。
SAP Datasphere テナント構成におけるデータ統合ブロックの構成
初期ロードとリアルタイムの差分ロード フェーズの両方の計算値を確認して合計します。
- 4つのジョブを使用する場合、初期ロードを実現するために顧客は少なくとも200のブロックを構成する必要があります
- リアルタイムで1時間あたり1000万レコードを複製するために、デルタロード中に追加で1440時間、つまり追加の1440ブロックを構成する必要があります
合計で、最初の月には200のデータ統合ブロックと2月目以降には1,440のブロックが必要です。ただし、実際は毎月同じデルタ量でない可能性があり、月によって異なる可能性があります。
2 つの計算を合計すると、次のようになります:
200 ブロック(初期ロード) + 1,440 ブロック(デルタ ロード) = 初月には1,640のデータ統合ブロック、2月目以降には1,440のブロックが必要です。ただし、実際には毎月同じデルタ量ではなく、月によって異なる可能性があります。
サンプルシナリオでのプレミアムアウトバウンドの計算
SAP S/4HANA からnon-SAP ターゲット システム (Google BigQuery など) にデータをリアルタイムでロードしたい場合を考えます。前述のデータ統合ブロックの計算に加えて、プレミアムアウトバウンドを計算する必要があります。
20 個の CDS ビューの初期ロードデータボリュームが約 300 GB、毎月の変更データ ボリュームが 60 GB であるとします。
- 初期ロード : 15 ブロックの割り当て= 15 ブロック × ブロックあたり 20 GB = 300 GB の初期ロード ボリューム
- デルタ ロード : 月あたり 3 ブロックの割り当て= 3 ブロック × ブロックあたり 20 GB = 60 GB デルタ ロード ボリューム
2 つの数値を合計し、SAP Datasphere キャパシティーユニットカリキュレーター (もしくはSAP Datasphere テナント構成)を利用すれば金額が計算できます:
最初の月には15 ブロック(初期ロード) + 3 ブロック(デルタ ロード) = 18 ブロックが必要
2月目以降は3ブロックが必要になります。
ただし実際はデルタボリュームが月ごとに異なる可能性があります。
4. 複製フローを利用したデータモデル作成時の注意点および、データ変更時のサンプルシナリオ
注意点
- 複製フローで作られるすべての複製オブジェクト (データ セット) は複製フローのすべての複製スレッドを共有します
- SAP ABAP が適切に設定されており、SAP Noteの最新版であることを確認してください。詳細については、次の 2 つのノートを確認してください: https://me.sap.com/notes/2890171 & https://me.sap.com/notes/2596411 !
注意点
- 複製フローで作られるすべての複製オブジェクト (データ セット) は複製フローのすべての複製スレッドを共有します
- SAP ABAP が適切に設定されており、SAP Noteの最新版であることを確認してください。詳細については、次の 2 つのノートを確認してください: https://me.sap.com/notes/2890171 & https://me.sap.com/notes/2596411 !
- 1 つの複製フローに追加できる複製オブジェクトは最大 500 個です
- 複製フローの複製オブジェクトが増えるほど、転送される全体のデータ量に応じてスループットを達成するために必要な並列スレッドが増えます
- 非常に大規模なデータ セット (10 億を超えるレコードなど) で高いスループットを達成したい場合は、専用の排他的な複製フローを使用して、一定量の複製スレッドを確保して最適なパフォーマンスを実現したいと希望されると思います。近々、パフォーマンス チューニングに関する専用のブログ投稿を公開する予定です。
- 複数の複製フローにわたって多数の複製スレッドを定義する場合でも、Datasphere テナントで開始される複製フロー ジョブは 10 個以下になります。
複製フローを再初期化することなく、実行中の複製フローを引き続き処理できる場合があります。次のような場合です
- ソースに主キー以外の列を追加した場合、複製フローは実行を継続し、新しい列は無視されます。新しい列のデータを追加する場合は、再度データの初期ロードが必要です
- 既存の実行中の複製フローから複製オブジェクトを削除した場合、残りのレプリケーションは変更されません。
- 実行中の複製フローが実行時に処理できない変更ももあります。初期 + デルタ ロード タイプで実行する場合は、再デプロイして再初期化する必要があります。将来的には、再デプロイを回避し、複製フローをより柔軟に実行できるように機能改善がされる予定です。
- 既存の実行中の RF に別のレプリケーション オブジェクトを追加する場合
--> 代替ソリューション: 新しいレプリケーション フローを作成する
- 既存の実行中の RF に別のレプリケーション オブジェクトを追加する場合
SAP ABAP ベースのソース システムからデータをロードする場合の考慮事項:
- 最新の機能を利用し、既知の問題やすでに解決されている問題の発生を避けるために、関連するすべての SAP ノートを適用して、SAP ABAP ベースのソース システムが最新であることを確認してください(リンク)
- SAP ABAP システムの複製フローによってトリガーされる一定数のセッションを許可するか、セッション パラメーター チェック(リンク)を無効にしてください。
ユーザーのアクションと複製フローのサイジング・複製フローの実行への影響
次の表で、SAP Datasphere ユーザーが新しいデータを作成する、もしくは既存の複製フローを変更する場合データビルダーで設定を行うアクションについての結果とデータ複製への影響をご説明します。
| アクション | 予想される結果と影響 |
| 複製フローのデフォルト複製スレッドを10を超えた数に設定する (デフォルトでは10 の複製スレッド =それぞれ 5 つの複製スレッドを持つ 2 つの複製フロージョブ) | 最大並列数に制限があることに注意してください。 SAP Datasphere テナントごとに全体で最大 10 個の複製フロージョブを並列実行できます。 |
| デルタ変更の更新頻度を 1 時間未満に設定する | デルタレ複製がより頻繁に実行されるため、より多くのノード実行時間が消費されます。 |
| 追加の複製フローを作成して、追加のソース 複製オブジェクトからより多くのデータを複製する | より多くのノード実行時間が消費されます |
| 実行中の複製フローを停止する | 停止された複製フローのノード実行時間は消費されなくなります。 |
| 実行中の複製フローを一時停止する | 一時停止された複製フローのノード実行時間は、再開されるまで消費されません。 |
| Datasphere テナントごとに許可される最大数より多くの複製スレッドを構成します | データ複製は引き続き実行されますが、Datasphere テナントごとに合計で最大 10 個を超える複製フロー ジョブを実行することはありません。 |
| 追加の複製フローを作成し、 割り当てたデータ統合ブロックの合計数の制限を超えた | データ 複製は引き続き実行されますが、ノード時間の消費量が増えるため、コストが増加します。サブスクリプションベースの顧客の場合、過剰消費が繰り返される場合には契約の調整を行う必要があります。 |
まとめ
このブログは、サンプルシナリオを通じて複製フローを使用する場合に SAP Datasphere テナントのサイズをどのように設定する必要があるかについてご紹介しました。ここで示した数値はサンプル値であり、お客様のインフラストラクチャと1 対 1 で同じではない可能性があることにご注意ください。個々のユースケースに応じて、必要なデータ統合ブロックの量とプレミアム アウトバウンド統合を計算するためのサンプルケースとして参照してください。最後までお読みいただきありがとうございました。
リンクとリソース:
Creating a Replication Flow in SAP Datasphere
Important considerations for Replication Flows in SAP Datasphere
Configure your SAP Datasphere tenant
SAP Datasphere Calculator / Estimator
Information about connecting SAP ABAP sources as source to Replication Flows
Prepare your SAP ABAP based source system for using Replication Flows
