リレーショナルデータベースの基本
リレーショナルデータベースは、データをテーブル（行と列）に格納します。リレーショナルデータベースは、テーブル間に存在する「関係」を利用して、データの格納に必要なディスク容量を最小限に抑えます。Domoは厳密にはリレーショナルデータベース管理システム（RDBMS）ではありませんが、Domoのインフラストラクチャではリレーショナルデータベースが使用されており、Domoの機能とDomoでのデータの効果的な操作方法を説明、理解するには、リレーショナルデータベースの多くの基本原則を使用できます。ディメンションとメトリクス
メトリクスは、多くの場合、ウェブ広告のクリック数や売上額などの数値です。ディメンションは値を説明します。例えば、売上データのテーブルには、製品SKU列が含まれている場合があります。このテーブルには、SKU（ディメンション）当たりの総売上額（メトリクス）など、ビジネス上の疑問に回答を与えることができるデータが格納されています。
テーブルのタイプ
多くの場合、トランザクションおよび関連するすべてのディメンション情報を含む単一のテーブルが表示されるのではなく、複数のテーブルにデータが表示されます。1つのテーブルにはメトリクスが含まれ、ほかのテーブルにはディメンションに関する詳細情報が含まれます。これらの様々なテーブルは、「キー」によって相互に関連付けられます（後述）。キーは、「リレーショナルデータベース」内の関係を確立します。少なくとも2つのタイプのテーブルがあります。トランザクション
トランザクションテーブル（データウェアハウス用語では「ファクト」テーブルとも呼ばれます）には、トランザクションイベントごとに1つのレコードが含まれます。「トランザクション」とは、ソーシャルメディアの投稿におけるインタラクション、ウェブサイトのクリック、売上レコードなどのアクションまたはイベントの記録です。
ディメンション
ディメンションテーブルには、ディメンション値ごとに単一のレコードが含まれ、そのディメンションを詳細に説明する属性も含まれています。例えば、ディメンションテーブルには製品に関する情報が含まれている場合があります。各行は単一のSKUを表し、テーブルの様々な列はSKUを説明します。このような属性には、製品名と単価が含まれる場合があります。
データのタイプ
列のデータタイプは、列にどのようなデータを格納できるかや、その列でどのような操作が許可されるかを制御します。また、データタイプは、列で実行できる操作の効率にも影響します。例えば、数値列でのJoin、フィルター、CASEロジックは、テキスト列での同等の操作よりも高速です。様々なデータタイプがあり、各データタイプの詳細は、データベースシステムによって異なります。ただし、これらのデータタイプは、以下のようにおおまかに分けて考えることができます。- 文字列 （テキストまたは「文字」とも呼ばれます）列には、アルファベット、数字、およびその他の文字を格納できます。文字列には数値データを格納できますが、少数の例外（先頭がゼロの場合がある米国の郵便番号など）を除き、数値データは、数値タイプ列に格納することを推奨します。
- 数値 （整数、固定小数点小数および浮動小数点小数、その他）は数値データのみを格納できます。浮動小数点値の場合、 IEEE 754規格 が適用されます。
- 日付と時刻
NULL：値なし
テーブル内の各セルには、値を含めることも、値をまったく含めないこともできます。セルに値が含まれていないのは、NULLと呼ばれる状態です。NULLの意味と、データベースとDomoがNULLを処理する方法を理解することは重要です。まず、NULLはゼロではなく、空の文字列ではありません。ゼロと空の文字列は両方とも値ですが、NULLは値ではありません。NULLは非常に特殊な目的を果たします。NULLは情報/値の欠落を表す方法だということです。NULLは値ではないため、ほかのNULLを含め、別の値と等しくなるということはあり得ません。したがって、NULLが含まれる可能性のある列にロジックを適用する場合（すべてのフィールドにNULLが含まれる可能性があると仮定するのが最も安全です）、そのロジックはNULLを説明するか、「処理」するものである必要があります。特に2つの列が比較されるロジック、列が定数値と比較されるロジック、または数学的計算が実行される場合がそれに当たります。例としては、CASEロジック、フィルター、Join条件などがあります。粒度と一意性
誤使用や誤解釈を防ぐために、テーブル内のデータの粒度を理解することが重要です。粒度は、データが表示される「レベル」を表します。例えば、従業員のテーブルは従業員レベルの粒度になっています。つまり、各レコードは1人の従業員を表します。このテーブルには、従業員ID、名前、部署など、従業員の多くの属性が含まれている場合があります。トランザクションのテーブルは、トランザクションレベルの粒度になっています。つまり、各レコードはトランザクションを表し、様々な列の値はトランザクションを説明します。 「一意性」の概念も密接に関連しています。一意性は、テーブル内の合計行数に対する列内の固有の値の数を示します。従業員テーブルでは、従業員IDは完全に一意である必要があります（従業員それぞれが1つの従業員IDを持ち、2人の従業員が同じ従業員IDを共有しているということはありません）。従業員名は一意性が高いですが、完全に一意ではありません。大規模な組織では、同姓同名の従業員がいる可能性があるためです。また、部署は一意性が低いものです（多くの従業員が1つの部署に割り当てられているため）。
データの関係
多くの場合、特定のビジネス上の疑問に回答を与えるには、複数のテーブルのデータを結合する必要があります。特に、ソースデータがデータウェアハウスから取得される場合にこのような必要が出てきます。このようなときは、「スタースキーマ」データアーキテクチャーを活用するのが一般的です。このアーキテクチャーでは、中央トランザクション（ファクト）テーブルが、各トランザクションをさらに説明するために使用できる1つまたは複数のほかの周辺のディメンションテーブルを参照します。例えば、売上トランザクションのテーブルには、販売日、販売数量、売上額、販売品目のSKU、および販売を行った販売担当者の従業員IDが示されます。それとは別に、製品のテーブルには、関連する製品名および製品カテゴリーとともにSKUが含まれています。各製品カテゴリー内の売上額を決定するには、テーブル間の関係を定義するキー列を活用して、売上トランザクションテーブルと製品テーブルを一緒に参照する必要があります。カーディナリティ
カーディナリティは、上記の粒度と一意性の概念と密接に関連しています。カーディナリティは、2つのテーブルのレコード間の関係性を説明します。上記の例では、売上トランザクションテーブルと製品テーブルの間には多対1の関係があります。各SKUは、売上トランザクションデータに0回、1回、または複数回出現します。また、売上トランザクションテーブルは、各SKUが1回だけ表示される製品テーブルに関連付けられます。プライマリキーと外部キー
データ行を一意に識別する列（または列のセット）はプライマリキーと呼ばれます。したがって、プライマリキーは完全に一意です。プライマリキー列にNULL値を含めることはできません。あるテーブルのプライマリキーは、別のテーブルの外部キーによって参照できます。言い換えると、2つのテーブル間の関係を、それぞれのプライマリキーと外部キーで記述するということです。上記の売上トランザクションの例では、製品SKU列が製品のプライマリキーであり、売上トランザクションテーブルの製品SKU列によって参照されています。この製品SKU列は外部キーです。 リレーショナルデータベース管理システムでは、データベースが「参照整合性」を強制するように、プライマリキーと外部キーの関係を設定できます。具体的には、プライマリキーを一意にすることを要求し、トランザクションテーブルの外部キーによって参照されるディメンションテーブルのレコードが削除されないようにします。前述のように、Domoはリレーショナルデータベース管理システムではないため、プライマリキーと外部キーの制約は強制されません。ただし、Domoを効果的に使用するには、この概念を理解することが重要です。エンティティ関係図
データテーブルとテーブル間の関係は、多くの場合、エンティティ関係図（ERD）を使用して表されます。2つのテーブルを接続する線は、関係が存在することを示します。線の末端は、関係のカーディナリティを表します。売上データの例では、売上トランザクションテーブルと従業員テーブルの間、売上トランザクションテーブルと製品テーブルの間に、多対1の関係があります。これらの関係は自然言語で解釈することもできます。例えば1人の従業員は販売を0回、1回、または複数回行うことができ、特定のSKUは0回、1回、または複数回販売できる、とも表現できます。
Join
Joinでは、テーブル間の関係が活用されます。Joinは2つのテーブルを横方向に結合する方法をデータベースに指示するコマンドです。Joinの「横方向」の特性は、「Left Outer」や「Right Outer」など、様々なJoinタイプの名前によって示唆されます。 Joinの様々なタイプはJoinする2つのテーブル間で一致した行と一致しない行を処理する方法によって区別されます。- Inner Join： Join条件を満たすレコードのみを返します。
- Left Outer Join： Join条件が満たされるたびに、左のテーブルのすべてのレコードを、右のテーブルのレコードをJoinした状態で返します。
- Right Outer Join： Left Outer Joinの対称となるイメージです。Join条件が満たされるたびに、右のテーブルのすべてのレコードを、左のテーブルのレコードをJoinした状態で返します。
- Full Outer Join： Join条件が満たされるたびに、左のテーブルと右のテーブルのすべてのレコードを、レコードをJoinした状態で返します。
粒度と一意性 – 陥りやすい落とし穴
様々なテーブルの粒度と一意性、および両者の関係を十分に理解することが重要です。そうしないと、誤解を招く方法や完全に間違った方法でデータがJoinまたは使用される可能性があります。基となるデータの誤解や誤用が原因で陥りやすい落とし穴が2つあります。デカルト結合
数学では、「デカルト積」は2つの集合の考えられ得るすべての組み合わせです。集合{A, B}と{C, D}のデカルト積は{AC, AD, BC, BD}になります。2つのデータテーブルをJoinする場合も同じ概念が出てきます。テーブルの粒度と一意性を十分に理解しておらず、適切なJoin条件を指定していない場合に、デカルト結合が発生する可能性があります。デカルト結合では、一方または両方のテーブルのレコードが重複し、結果が不正確になります。行数の増加やレコードの重複が見られる場合、一意の識別子であった列がJoin後になくなっており、デカルト結合になっています。デカルト結合が望ましい特定のユースケースはありますが、少数の例外です。 デカルト結合を回避するには、Join条件によって行が一意に識別されるようにJoinを定義する必要があります。通常この定義づけは、Join条件でJoinするテーブルの一意の識別子列を使用することで行われます。もちろん、これを行うには、どの列が一意の識別子を構成するかを知っている必要があります。一意性が保証されていない場合（システムによって生成された一意のIDがない場合、特に手動で保持されたデータを扱う場合など）、ベストプラクティスは一意性を強制することです。属性または粒度のレベルが混在するテーブル
通常、テーブルには、特定のタイプまたはクラスのエンティティの個別のインスタンスのレコードが含まれます。例えば、売上トランザクションテーブルには、売上トランザクションごとにレコードが1つ、製品テーブルには、SKUごとにレコードが1つ含まれます。また、各エンティティの各インスタンスは、様々なディメンションまたは属性によって定義されます。したがって、各データディメンションは特定のものの属性と考えることができます。 スタースキーマ内のデータの構成により、通常、どのディメンションがどのエンティティの属性であるか、またはどのディメンションがどの粒度レベルで適用されるかを簡単に識別できます。例えば、単価は製品の属性であり、製品テーブルのSKUによって識別されます。給与は従業員の属性であり、従業員テーブルの従業員IDによって識別されます。ただし、複数のテーブルのデータがJoinによって結合されると、どの属性がどのクラスに適用されるかを理解することは困難になる場合があります。従業員テーブルでは、給与を合計（給与の合計オーバーヘッドの計算など）または平均（勤続期間当たりの平均給与の計算など）が可能なメトリクスとして扱うことがおそらく許容されます。ただし、従業員データが売上トランザクションテーブルにJoinされている場合、給与をメトリクスとして考慮しようとすると、誤った結果が生まれます。これは、給与が従業員の属性であり、従業員ごとに1つのレコードレベルの粒度になっているためです。しかし、売上テーブルは、売上トランザクションごとに1つのレコードレベルの粒度になっています。 ベストプラクティスは、異なるクラスまたは粒度レベルの属性を混ぜないことです。したがって、給与データを売上データにJoinし、その結合データから給与に関する疑問への回答を得るのではなく、給与は売上データとは別にし、給与に関する疑問への回答は従業員データから直接得る必要があります。これが不可能な場合は、列のクラスまたは粒度レベルを明確にする命名規則を採用することを検討してください。売り上げと給与の例では、列名をただ「給与」とするより、「従業員の給与」とした方がより適切で有用な場合があります。給与は従業員の属性であることが一般的に認識されているため、誤解のリスクは低くなりますが、常にそうであるとは限りません。例えば、販売地域は、1）顧客の本社所在地にもとづいて分類する場合と、2）販売組織の地理的な階層にもとづいて分類する場合があります。この場合、適切な列名は「顧客地域」と「販売地理的地域」になります。一意性の調査と強制
Domoはリレーショナルデータベース管理システムではありませんが、リレーショナルデータベースの基本原則は働いています。例えば、DomoではDataSetでのプライマリキーの定義づけが許可されていませんが、特にデータのJoinや集計を行う際はデータの粒度と一意性を理解することが重要です。データの一意性を確認する方法はいくつかあります。Analyzerとビュー
列（または列のグループ）がテーブル内の行を一意に識別する場合、列内の各値（または列全体の値の各順列）によって表される行は1つだけになります。一意性は、Analyzerで表カードを設定するか、Views Explorerを使用して調査、確認できます。一意性を確認するには、一意と推定されるキーのレベルまでデータを集計し、行をカウントします。列が実際にテーブル内の一意のキーである場合、行数はすべてちょうど1になります。1にならない場合、その列は一意のキーではありません。 売上トランザクションの例では、PO番号、顧客、製品SKUはいずれもテーブル内の一意の識別子ではありません（したがってプライマリキーではありません）。PO番号、顧客、製品SKUに複数のレコードがある（行数が1より大きい）ものがあるため、これは明らかです。ただし、3つの列を組み合わせると、一意の識別子が形成されます。
集計
重複レコードは、集計を使用して削除できます。この方法では、データは、一意性を強制する列のレベルまで集計されます。追加の属性/ディメンションも含めることができますが、注意して追加する必要があります。集計にディメンションを追加すると、一意性を強制するべき列が一意でなくなる場合があります。メトリクス/値列は集計できます。集計方法（合計、平均、最小など）を選択するときは注意してください。集計後、データは集計が実行されたレベルで一意になります。重複を削除する
集計する代わりに、重複行を削除することもできます。Magic ETLには、「重複を削除」タイルがあります。このタイルを使用するには、一意のキーを構成するフィールドを指定します。Domoでは、一意のキー値ごとに1つのレコードのみを保持し、それ以外のすべてのレコードを除外するようにフィルターすることで、重複を削除します。ただし、このタイルを使用しても、どのレコードが保持され、どのレコードが除外されるかを制御できないため、多くの場合このタイルの使用は推奨されません。 ［重複を削除］タイルを使用する代わりに、「パーティション分割」された行の番号付けとフィルターを使用することを推奨します。この方法では、行に番号を付け、一意のキーフィールドでパーティション分割した後、行番号1の1つのレコードのみを保持し、ほかのレコードはすべて除外するようにフィルターします。この方法でソート順を指定することで、保持するレコードと除外するレコードを選択するためのロジックを追加できます。この方法は、Magic ETLで「ランクとウインドウ」タイルを使用するか、Redshift SQLでrow_number() over(partition by [] order by [])関数を使用して実行できます。DomoのMySQLは同等の行番号関数をサポートしていませんが、構文はより複雑になるものの、変数を使用すれば同じ結果が得られます。Domoのアーキテクチャー
Domoでデータ処理を最適化する方法を理解するには、Domoのアーキテクチャーに関する基本的な理解が必要です。Domoでは、データはDomo Data WarehouseであるVault、高性能カードレンダリングエンジンであるAdrenalineの2ヶ所に格納されます。Adrenalineエンジンは、カードが読み込まれるたびに実行されるクエリに応答することで、カードのレンダリングをサポートするために使用されます。データ処理（抽出/変換/読み込み処理、略称「ETL」）は、別のデータ処理環境で実行されます。例外はAdrenalineのDataFlowとビューで、どちらもAdrenalineエンジンで実行されます。データ処理が開始されたら、データをVaultからETLエンジン（Magic ETL、MySQL、またはRedshift）に読み込む必要があります。その後、ETLプロセスで指定されたデータ変換が実行されます。最後に、出力データがVaultに書き込まれた後、Adrenalineに書き込まれて、インデックスが作成されます。データパイプラインの最適化
多くの場合、特にETLプロセスが非常に大きな入力データを消費している場合、初期入力ステップと最終出力ステップがETLの合計処理時間の大部分を占めます。したがって、入力データや出力データ（行または列）のサイズを効果的に小さくする方法を使用すると、合計処理時間が短縮されます。包括的な指針は、データをできる限り短時間で（できる限りアップストリームで）処理するには、データの合計サイズを減らすということです。堅牢で効率的な、パフォーマンスの高いデータパイプラインを構築できるようになる一般的なガイドラインは複数あります。これらのガイドラインは、Domo内外のETL全般に適用されますが、このドキュメントでは、これらのガイドラインをDomoで採用する方法に焦点を当てています。これらの原則は、マクロレベル（パイプライン全体での複数のデータ処理）およびミクロレベル（単一のDataFlow内での様々な変換）で適用されます。レコードが処理される回数を最小化する
レコードを処理する回数をできる限り減らすという方法です。ソースデータ（連絡先ディメンションテーブルに格納されている顧客の電話番号、注文のステータスなど）でレコードが更新される可能性がある場合は、レコードが変更されたときに、変更されたレコードを再処理する必要があります。ただし、時間が経ってもデータが変更されない場合（つまり、新規レコードが追加されても、既存のレコードは決して変更されない場合）は、履歴レコードを再処理する必要はありません。この一般的なガイドラインに従う方法はいくつかあります。パーティション分割
パーティション分割については、後で詳しく説明します。データを「サブセット化」または「パーティション分割」してから、処理が必要なパーティションのみを処理するという方法です。パーティション分割は、DomoコネクターやDomoコマンドラインインターフェース（CLI）を使用するか、Domo APIに対するスクリプトを作成する（直接またはDomoのJavaまたはPython SDKを使用する）ことで実行できます。ビューを使用してフィルターされたDataFlow入力
この方法では、ビューを使用して、ETLプロセスで実行する必要があるレコードの数を制限します。例えば、DataSetに多数の履歴データが含まれているが、最終使用では最近のデータ（過去13ヶ月など）のみが必要な場合、動的日付フィルターをビューに適用することで、ビューが過去13ヶ月のデータのみを返し、このデータのみがETLを介して処理されるようにできます。Magic ETL v2エンジンでのデータ処理の強化
Magic ETL v2エンジンは、DataFlowが最後に実行されてからどのレコードが新しく追加されたか、または更新されたかを識別できるスマートさを備えています。このため、可能な場合は、新規データまたは変更されたデータのみが処理されます。Magic ETL v2の一部の機能（集計、ウィンドウ関数など）では、すべての入力データを処理する必要があります。処理される行数を最小化する
これは、フィルターや集計を使用して行うことができます。DataSetをフィルターまたは集計できる範囲は、エンドユースケースによって定義されます。言うまでもなく、最終出力で特定の範囲のデータまたは特定のレベルの粒度が必要な場合は、その範囲と粒度をソースから最終出力DataSetに永続化する必要があります。しかし、多くの場合、未加工データは必要以上の粒度になります。例えば、最終出力では、本当にすべてのリンクの全ウェブクリックを確認する必要があるか、それともユーザー当たりまたはその他のディメンション当たりのクリック数を把握するだけで十分かなどについて考慮する必要があります。処理される列数を最小化する
デフォルトでは、DataSetがETLプロセスに渡されると、列がプロセスで実際に必要かどうかに関係なく、すべての列がVaultからETLエンジンにコピーされます。MySQL DataFlowは、ETLエンジンにコピーする特定の列のみを選択するように設定できます。Magic ETLではこの設定は不可能ですが、ビューを使用して必要な列のみをサブセット化し、そのビュー出力を入力としてMagic ETL v2プロセスに読み込むことはできます。単一のDataFlowまたはDataSetを介したシングルスレッドは避ける
Domoユーザーは、すべての（または多すぎる）ユースケースをサポートするために、単一のパイプラインやDataSetの作成に集中しすぎてデータ環境を設計することがあります。このような設計が最適でない理由は少なくとも2つあります。まず、DataSetに依存するユーザーとカードの数が増え、極端な場合にはカードとページのレンダリングのパフォーマンスの問題につながる可能性があります。第二に、このような設計では通常、処理がより複雑になり、DataSetは大きくなります。このどちらによっても、処理時間が長くなる可能性があります。単一のデータパイプラインと単一の出力DataSetを作成して「すべてを指示」するのではなく、特定のエンドユースケース向けに設計された処理と出力DataSetを作成することを検討してください。この方法では、一般的に行と列を大幅に削減できます。また、データ処理を直列ではなく並列に行うこともできます。このようなアーキテクチャーは、カードのレンダリングのパフォーマンスにも最適化されています。これは、非常に大規模なDataSetを扱う場合や多数の同時ユーザーがいる場合に特に重要です。 もちろん、ロジックやデータの複製を避けるなど、ほかの重要な方法ともバランスをとる必要があります。一般的に、2つのユースケースには、共通のデータ、ディメンション、ロジックと、異なるデータ、ディメンション、およびロジックが含まれている可能性があります。両方のユースケースをサポートする処理に、共通の概念とロジックが「まとめて配置」されるようにデータ処理を作成する必要があります。ただし、2つのユースケースが定義またはデータ要件の点で分岐するときは、サポートするデータ処理の点でも分岐することを許可する必要があります。つまり、複数のエンドユースケースをサポートするように設計されたセマンティックミドルレイヤーで、データの標準化とクリーンアップ、およびいくつかのルックアップやその他の操作が行われるアーキテクチャーが推奨されます。次に、様々なエンドユースケースの要件をサポートするために処理が分岐するユースケース固有のレイヤーを作成します。この概念は、マクロレベル（複数のDataFlowとDataSet間）またはミクロレベル（単一のDataFlow内）で適用できます。 このバランスがとれた方法がよく使用されるケースとしては、集計された履歴データと詳細な最新データが必要な場合が挙げられます。例えば、現在の月のトランザクションの顧客、製品、および担当者の詳細だけでなく、売上高のその後13ヶ月分のビューも必要になる場合があります。このビジネスニーズを満たすには、13ヶ月分の詳細なデータを含む単一のDataSetではなく、2つの異なるDataSetを使用します。1つは地域ごとに13ヶ月分の集計データを含む集計履歴DataSet、もう1つは1ヶ月分の詳細データを含む現在の月の詳細なDataSetです。下の図に示すように、2つの出力DataSetを組み合わせることで、未加工データの範囲とディメンションに応じて合計行数の85～90％を削減することができます（可視化に関しては、Domoのドリルダウン機能を使用すると、1つのDataSetから別のDataSetにドリルダウンできます。エンドユーザーは、2つのDataSetをうまく操作できなくてもよいどころか、DataSetが2つあることに気づいている必要すらありません）。
その他のヒント
超アップストリームでのデータのJoinと超ダウンストリームでのデータのJoinのバランスを取る
アップストリームでのJoinとダウンストリームでのJoinにはバランスが必要です。アップストリームでのJoinでは、アップストリームの集計が可能になりますが、アップストリームの列数も増加します。ダウンストリームでのJoinでは、データパイプラインのさらにダウンストリームでより細かい粒度（したがって、より多くの行）が保持される可能性があります。このため、重要な集計をアップストリームで実行できる場合は、必ずアップストリームでJoinを実行します。文字列ではなく数値を使用してJoinする
可能であれば、文字列列ではなく数値列を使用してJoinを実行します。数値、特に整数でのJoinは、文字列でのJoinよりも高速です。インデックスを定義する
データベースでは、人が教科書内の索引を使用するのとちょうど同じようにインデックスを使用します。これにより、情報をすばやく見つけることができます。インデックスは、データ処理を効率的に実行するために、特に、Join、集計、フィルターなどの操作で不可欠です。Magic ETLとRedshiftでは、データベースエンジンが効率的にインデックスを自動作成します。ただし、MySQLでは、DataFlow内に明示的にインデックスを作成する必要があります。インデックスがないと、データ処理時間に大きな悪影響が出る可能性があります。データ更新メソッド
Domoでは、データの更新に、置き換え、追加、結合（Upsert）、パーティションの4つの方法を使用しています。詳細については、「 DataSet更新方法 」を参照してください。再帰的DataFlow
コネクター、Workbench、Domo APIなど、Domo製品の様々な部分で追加、Upsert、パーティション分割がサポートされています。再帰的DataFlowの設定方法によっては、追加、Upsert、パーティション分割の結果と事実上同じ結果が得られる場合があります。再帰的DataFlowを使用する利点は、特定のユースケースに合わせてロジックを微調整できることです。ただし、再帰的DataFlowの実行にはコストがかかります。これは、定義上、出力データが時間の経過とともに継続的に増加し、新規受信データが処理されるたびにすべての履歴データを再処理する必要があるためです。それでも、データの合計サイズと増加率が比較的小さく保たれる限り、再帰的DataFlowはパイプラインソリューションの重要な1つとなり得ます。
- 再帰的/スナップショットMagic ETL DataFlowを作成する
- Magic ETL v2で再帰的/スナップショットDataFlowを作成する
- 再帰的/スナップショットSQL DataFlowを作成する
データ取り込み時に未加工データを蓄積する
データの取り込み方法によっては、追加、Upsert、またはパーティション分割によるデータの蓄積がすべてサポートされている場合があります。また、再帰的DataFlowを未加工ソースデータのすぐダウンストリームに作成し、データ取り込み時に効果的に蓄積することができます。ただし、アップストリームにデータを蓄積することは、レコードの処理回数をできる限り少なくするという一般的なガイドラインに反します（これは、すべてのダウンストリームDataFlowが、累積されたDataSet全体で動作する可能性があるためです）。データの処理回数をできる限り少なくするというガイドラインは、データをダウンストリームに蓄積するべきだということを意味しており、多くの場合、これによってデータパイプラインのパフォーマンスは向上します。データを「中間ストリーム」に蓄積する
データ取り込み時にはすべての蓄積方法が使用可能ですが、Domoは現在、ネイティブでは中間ストリームへの蓄積をサポートしていません。データの蓄積はダウンストリームでは可能ですが、これには少し工夫が必要です。再帰的DataFlowを使用するのも1つの方法です。もう1つの方法は、Domoからデータを抽出し（Domo CLIを使用したスクリプト作成、DomoのAPIに対するスクリプト作成など）、パーティション分割またはUpsertを使用してDomoに再アップロードする方法です。再アップロードステップは、CLIコマンドまたはWorkbenchを使用して実行できます。注記： Workbenchでパーティション分割を行う際、パーティションキーにタイムスタンプが選択されている場合、Workbenchは自動的にパーティションキーのタイムスタンプの日付部分のみを使用します。このため、Workbechではタイムスタンプが適切なパーティションキーになる場合があります。