DWHアジャイル設計手法の概要

リポジトリ開発は長く深刻なビジネスです。



プロジェクトの寿命の大部分は、開始時にオブジェクトモデルとベースの構造をどれだけよく考えたかに依存します。



一般的に受け入れられているアプローチは、「スター」スキームを第3の通常の形式と組み合わせるためのさまざまなオプションであり、現在も続いています。原則として、原則によれば、初期データ-3NF、ショーケース-スター。多くの研究に裏打ちされたこの実績のあるアプローチは、経験豊富なDWHの人が分析リポジトリがどのように見えるべきかを考えるときに最初に（そして時には唯一の）考えることです。



一方、ビジネス全般、特に顧客の要件は急速に変化する傾向があり、データは「深さ」と「幅」の両方で増大します。そして、これはスターの主な欠点が現れるところです-限られた柔軟性。



そして、DWH開発者としての静かで居心地の良い生活の中で、突然：

• タスクは「少なくとも何かをすばやく実行することで発生しました。そうすればわかります」。
• 急速に発展しているプロジェクトが登場し、少なくとも週に1回、新しいソースの接続とビジネスモデルの作り直しが行われました。
• システムがどのように見えるべきか、そして最終的にどのような機能を実行するべきかを想像していないが、一貫したアプローチで実験と望ましい結果の一貫した改良の準備ができている顧客が現れました。
• プロジェクトマネージャーは、「そして今、私たちは機敏になりました！」という良いニュースを持って立ち寄りました。

または、他にどのようにストレージを構築できるかを知りたいだけの場合は、猫の下で歓迎します！

柔軟性とはどういう意味ですか？

まず、「フレキシブル」と呼ばれるためにシステムが持つ必要のあるプロパティを定義しましょう。



これとは別に、説明されているプロパティは、システムの開発プロセスではなく、システムに特に関連している必要があることに注意してください。したがって、開発方法論としてAgileについて読みたい場合は、他の記事を読むことをお勧めします。たとえば、Habréには、興味深い資料がたくさんあります（概要と実用的、そして問題のあるものの両方）。



これは、開発プロセスとCDの構造がまったく関連していないことを意味するものではありません。一般に、柔軟なアーキテクチャのアジャイルストレージを開発する方がはるかに簡単です。ただし、実際には、KimballによるクラシックDWHとWaterfallによるDataVaultのアジャイル開発には、1つのプロジェクトでの2つの仮説における柔軟性の偶然の一致よりも多くのオプションがあります。



では、フレキシブルストレージにはどのような機能が必要ですか？ここには3つのポイントがあります。

1. 早期の納品と迅速な改訂は、理想的には、最初のビジネス結果（たとえば、最初の作業レポート）をできるだけ早く、つまりシステム全体が完全に設計および実装される前に受信する必要があることを意味します。さらに、その後の各改訂も可能な限り短い時間で行う必要があります。
2. — , . — , , . , , — .
3. 変化するビジネス要件への絶え間ない適応-全体的なオブジェクト構造は、可能な拡張を考慮に入れるだけでなく、この次の拡張の方向が設計段階であなたを夢見さえしないかもしれないことを期待して設計する必要があります。

そして、はい、1つのシステムでこれらすべての要件を満たすことが可能です（もちろん、特定の場合といくつかの注意点があります）。



以下では、HDで最も人気のある2つのアジャイル設計手法であるアンカーモデルとデータボールトについて検討します。..。括弧の後ろには、EAV、6NF（純粋な形で）およびNoSQLソリューションに関連するすべてのような優れた技術があります-それらが何らかの形で悪化しているからではなく、この場合、記事が平均のボリュームを取得する恐れがあるからでもありませんディセラ。これはすべて、わずかに異なるクラスのソリューションを指しているだけです。プロジェクトの一般的なアーキテクチャ（EAVなど）に関係なく、特定の場合に適用できる手法、または情報ストレージの他のパラダイム（グラフデータベースやその他のオプションなど）を指します。 NoSQL）。

「古典的な」アプローチの問題と機敏な方法論におけるそれらの解決策

「古典的な」アプローチとは、古き良きスターを意味します（基礎となるレイヤーの特定の実装に関係なく、キンボール、インモン、CDMのフォロワーが私を許してくれますように）。

1.ネクタイの厳格なカーディナリティ

このモデルは、データをディメンション（Dimension）とファクト（Fact）に明確に分離することに基づいています。そして、これは論理的です-結局のところ、圧倒的多数のケースでのデータ分析は、特定のセクション（次元）の特定の数値指標（事実）の分析に帰着します。



この場合、オブジェクト間のリンクは、外部キーによるテーブル間のリンクの形式で配置されます。これは非常に自然に見えますが、柔軟性の最初の制限、つまり接続のカーディナリティの厳密な定義にすぐにつながります。



つまり、テーブルの設計段階で、関連するオブジェクトのペアごとに、それらが多対多であるか、1対多であるか、および「どの方向」であるかを正確に定義する必要があります。これにより、どのテーブルにプライマリキーがあり、どのテーブルに外部キーがあるかが直接決まります。新しい要件を受け取ったときにこの態度を変えると、ベースの再設計につながる可能性があります。



たとえば、「キャッシュレジスタ」オブジェクトを設計する際、営業部門の誓約に基づいて、1つのプロモーションが複数のチェックポジションに作用する可能性を定めました（ただし、その逆はありません）。





そしてしばらくして、同僚は新しいマーケティング戦略を導入しました。この戦略では、複数のプロモーションが同じポジションで同時に機能することができます。次に、別のオブジェクトへのリンクを選択して、テーブルを変更する必要があります。



（プロモーションチェックが行われるすべての派生オブジェクトも改善する必要があります）。





データボールトおよびアンカーモデルのリンク



この状況を回避するのは非常に簡単であることがわかりました。これについて営業部門を信頼する必要はありません。すべてのリンクは最初は別々のテーブルに保存され、多対多で処理されます。



このアプローチは、提案されたダンLinstedtでの一部として、データボールトパラダイムと完全によってサポートされているラースRönnbäckにアンカーモデル。



その結果、アジャイル手法の最初の際立った特徴が得られます。

オブジェクト間の関係は、親エンティティの属性には格納されませんが、別のタイプのオブジェクトです。

データボールトと呼ばれるテーブル・靭帯あるリンク、およびアンカーモデル-タイ。一見、それらは非常に似ていますが、違いは名前に限定されません（これについては以下で説明します）。どちらのアーキテクチャでも、リンクテーブルは任意の数のエンティティをリンクできます（必ずしも2つである必要はありません）。



一見すると、この冗長性により、変更に大きな柔軟性がもたらされます。このような構造は、既存のリンクのカーディナリティを変更するだけでなく、新しいリンクを追加することにも耐性があります-チェック位置にそれをパンチしたキャッシャーへのリンクもある場合、そのようなリンクの外観は、既存のオブジェクトに影響を与えることなく、既存のテーブルのアドオンになります。プロセス。

2.データの複製

柔軟なアーキテクチャによって解決される2番目の問題は、それほど明白ではなく、主にSCD2タイプ（2番目のタイプの寸法がゆっくりと変化する）の測定に固有のものですが、それらだけではありません。



従来のストレージでは、ディメンションは通常、代理キー（PKとして）とビジネスキーおよび属性のセットを別々の列に含むテーブルです。







ディメンションがバージョン管理されている場合、バージョンの期限が標準のフィールドセットに追加され、ストアのソースの行ごとに複数のバージョンが表示されます（バージョン管理された属性への変更ごとに1つ）。



ディメンションに頻繁に変更されるバージョン管理された属性が少なくとも1つ含まれている場合、そのようなディメンションのバージョン数は印象的です（他の属性がバージョン管理されていないか、変更されていない場合でも）。そのような属性が複数ある場合、バージョン数はそれらの数から指数関数的に増加する可能性があります。このようなディメンションは、かなりの量のディスクスペースを占める可能性がありますが、そこに格納されているデータのほとんどは、他の行から変更されていない属性の値を複製しただけです。







この場合、非正規化も非常に頻繁に使用されます。一部の属性は、ディレクトリや別のディメンションへの参照ではなく、意図的に値として保存されます。このアプローチは、ディメンションにアクセスするときの結合の数を減らすことにより、データアクセスを高速化します。



原則として、これは同じ情報が複数の場所に同時に保存されます。たとえば、居住地域と顧客のカテゴリに属する​​情報は、「顧客」のディメンションと「購入」、「配信」、「コールセンターへの電話」のファクト、およびリンクテーブル「顧客-顧客マネージャー」に同時に保存できます。



一般に、上記は通常の（バージョン管理されていない）測定に適用されますが、バージョン管理された測定では、異なるスケールを持つことができます：オブジェクトの新しいバージョンの外観（特に後知恵）は、関連するすべてのテーブルを更新するだけでなく、関連するオブジェクトの新しいバージョンのカスケード外観につながります-表1を使用して表2を作成し、表2を使用して表3を作成する場合など。表1の属性のいずれも表3の構築に関与していない場合（および他のソースから取得した表2の他の属性が関与している場合）、この構築のバージョン管理された更新は、少なくとも追加のオーバーヘッドコストにつながり、多くても、表3の不要なバージョンにつながります。これはそれとは何の関係もなく、さらにチェーンに沿っています。

3.改訂の非線形の複雑さ

さらに、別のマートの上に構築された新しいマートはそれぞれ、ETLに変更を加えるときにデータが「分岐」できる場所の数を増やします。これにより、後続の各リビジョンの複雑さ（および期間）が増加します。



上記がめったに変更されないETLプロセスを持つシステムに関係する場合、そのようなパラダイムに住むことができます-新しい変更がすべての関連オブジェクトに正しく導入されていることを確認する必要があります。改訂が頻繁に発生する場合、誤っていくつかのリンクを「見逃す」可能性が大幅に高まります。



さらに、「バージョン管理された」ETLが「バージョン管理されていない」ETLよりもはるかに複雑であることを考慮すると、この経済全体の頻繁な改訂による間違いを回避することは非常に困難になります。

オブジェクトと属性をデータボールトとアンカーモデルに保存する

アジャイルアーキテクチャの作成者によって提案されたアプローチは、次のように定式化できます。

変更されたものと変更されていないものを分離する必要があります。つまり、キーを属性から分離してください。

同時に、バージョン管理されていない属性と変更されていない属性を混同しないでください。最初の属性は変更の履歴を保存しませんが、変更することはできます（たとえば、入力エラーが修正されたときや新しいデータを受信したとき）。2番目の属性は変更されません。



データボールトとアンカーモデルで不変と正確に見なすことができるものについての見方は異なります。Data Vault



アーキテクチャの観点からは、キーのセット全体は変更されていないと見なすことができます-自然（組織のTIN、ソースシステムの製品コードなど）および代理。この場合、残りの属性は、ソースや変更の頻度によってグループに分割でき、グループごとに独立したバージョンのセットを持つ個別のテーブルを維持できます。 パラダイムで



アンカーモデルは、エンティティの代理キーのみが不変であると見なされます。他のすべて（自然キーを含む）は、その属性の特殊なケースにすぎません。同時に、デフォルトではすべての属性が互いに独立しているため、属性ごとに個別のテーブルを作成する必要があります。



では、データボールト、エンティティのキーを含むテーブルが呼び出されハブ。ハブには常に固定のフィールドセットが含まれています。

• エンティティの自然キー
• 代理キー
• ソースへのリンク
• 追加時間を記録する

ハブのエントリは変更されず、バージョンもありません。外見上、ハブはサロゲートを生成するために一部のシステムで使用されるIDマップタイプのテーブルと非常に似ていますが、Data Vaultのサロゲートとして整数シーケンスではなく、ビジネスキーのセットからのハッシュを使用することをお勧めします。このアプローチにより、ソースからのリンクと属性の読み込みが簡単になります（代理を取得するためにハブに参加する必要はなく、自然キーからハッシュを計算するだけで済みます）が、他の問題を引き起こす可能性があります（たとえば、衝突、大文字と小文字、文字列キーの印刷不可能な文字など）。 .p。）、したがって、一般的に受け入れられていません。



他のすべてのエンティティ属性は、Satellitesと呼ばれる特別なテーブルに格納されます..。 1つのハブに、異なる属性のセットを格納する複数の衛星を含めることができます。







衛星による属性の分布は、共同変更の原則に基づいています-1つの衛星はバージョン管理されていない属性（たとえば、個人の生年月日やSNILS）を格納でき、別の衛星はほとんど変更されないバージョン管理された属性（たとえば、姓とパスポート番号）を3番目に保存できます-多くの場合変更（たとえば、配送先住所、カテゴリ、最終注文日など）。この場合、バージョン管理はエンティティ全体ではなく、個々の衛星のレベルで実行されるため、1つの衛星内のバージョンの交差が最小になるように属性を配布することをお勧めします（これにより、保存されるバージョンの総数が減ります）。



また、データの読み込みプロセスを最適化するために、さまざまなソースから取得した属性が別々の衛星に配置されることがよくあります。



サテライトは、外部キー（1対多のカーディナリティに対応）を使用してハブと通信します。これは、この「デフォルト」アーキテクチャでは、複数の属性値（たとえば、1人の顧客の複数の連絡先電話番号）がサポートされていることを意味します。アンカーモデルでは、キーを保持するテーブル



はアンカーと呼ばれます。そして彼らは保ちます：

• 代理キーのみ
• ソースへのリンク
• 追加時間を記録する

自然キーは、アンカーモデルの観点からは通常の属性と見なされます。このオプションは理解するのが難しいように思われるかもしれませんが、オブジェクトを識別するためのより多くの余地があります。







たとえば、同じエンティティに関するデータが異なるシステムから取得される可能性がある場合、各システムは独自の自然キーを使用します。 Data Vaultでは、これにより複数のハブ（ソースごとに1つ+統合マスターバージョン）の構造がかなり煩雑になる可能性がありますが、アンカーモデルでは、各ソースの自然キーが独自の属性に分類され、他のすべてとは独立してロード中に使用できます。



しかし、ここには1つの陰湿な点があります。異なるシステムの属性が1つのエンティティに結合されている場合、おそらくいくつかの属性があります。異なるソースからのレコードがエンティティの1つのインスタンスに対応することをシステムが理解する必要がある、「接着」のルール。



では、データボールト、これらのルールは、最も可能性の形成を決定しますマスターエンティティの「代理ハブ」を、任意の方法でソースとその初期の属性の自然なキーを格納ハブには影響しません。ある時点でスプライシングルールの変更（またはそれが行われる属性の更新）が発生した場合、代理ハブを再形成するだけで十分です。



でアンカーモデル、しかし、そのような実体は、ほとんどの場合に保存されます単一のアンカー。..。これは、ソースに関係なく、すべての属性が同じサロゲートにバインドされることを意味します。誤ってマージされたレコードを分離し、一般に、そのようなシステムでのマージの関連性を追跡することは、特にルールが十分に複雑で頻繁に変更され、同じ属性を異なるソースから取得できる場合は、非常に困難になる可能性があります（ただし、それぞれが属性バージョンは、そのソースへのリンクを保持します）。



いずれにせよ、システムが重複排除、レコードおよびその他のMDM要素のマージの機能を実装することになっている場合、アジャイルな方法で自然キーを保存する側面を詳しく調べる価値があります。より厄介なDataVaultの設計は、マージエラーに関して突然より安全であることが証明される可能性があります。



アンカーモデルは、ノットと呼ばれる追加のタイプのオブジェクトも提供します。実際、これは、1つの属性のみを含むことができる特別な縮退タイプのアンカーです。ノードは、フラットディレクトリ（たとえば、性別、婚姻状況、カスタマーサービスカテゴリなど）を格納するために使用されることになっています。アンカーとは異なり、ノードには関連付けられた属性テーブルがありません、およびその唯一の属性（名前）は、常にキーと同じテーブルに格納されます。ノードは、アンカーが相互にリンクされているのと同じように、タイテーブルによってアンカーにリンクされます。



ノードの使用について明確な意見はありません。たとえば、ロシアでアンカーモデルの使用を積極的に推進しているニコライゴロフは、リファレンスブックがないため、常に静的で単一レベルであると断言することは不可能であると考えています。したがって、すべてのオブジェクトに一度に本格的なアンカーを使用することをお勧めします。



データボールトとアンカーモデル間のもう一つの重要な違いが存在することであるリンクの属性：



ではデータボールト、リンクはハブと同じ本格的なオブジェクトであり、そして持つことができます独自の属性。でアンカーモデル、リンクはアンカーを接続するためにのみ使用され、自分の属性を持つことはできません。この違いにより、事実をモデル化するためのアプローチが大幅に異なります。これについては、以下で説明します。

事実の保存

その前に、私たちは主にモデリング測定について話しました。事実を考えると、状況は少し単純ではありません。



では、データボールト、保管の事実のための一般的なオブジェクトがあるリンクの本当の指標が追加されるの衛星で、。



このアプローチは直感的に見えます。分析されたインジケーターに簡単にアクセスでき、一般に従来のファクトテーブルに似ています（インジケーターのみがテーブル自体ではなく、「隣接する」テーブルに保存されます）。ただし、落とし穴もあります。典型的なモデルの変更の1つであるファクトキーの拡張では、Linkに新しい外部キーを追加する必要があります。そして、これはモジュール性を「破壊」し、他のオブジェクトを改善する必要性を引き起こす可能性があります。



でアンカーモデルリンクは独自の属性を持つことができないため、このアプローチは機能しません。絶対にすべての属性とインジケーターを1つの特定のアンカーにバインドする必要があります。これからの結論は単純です-各事実にも独自のアンカーが必要です。私たちが事実としてとらえているもののいくつかについては、自然に見えるかもしれません-たとえば、購入の事実は、オブジェクトの「注文」または「チェック」、サイトへの訪問、セッションなどに完全に還元されます。しかし、そのような自然な「運搬物」を見つけるのはそれほど簡単ではないという事実もあります。たとえば、毎日の初めに倉庫に残っている商品です。



したがって、アンカーモデルのファクトキーを拡張する際のモジュール性に問題はありませんが（対応するアンカーに新しいリンクを追加するだけで十分です）、ファクトを表示するモデルの設計はそれほど明確ではなく、ビジネスオブジェクトモデルを反映する「人工」アンカーが表示される場合があります。

柔軟性の実現方法

どちらの場合も、結果として得られる構造には、従来のディメンションよりも大幅に多くのテーブルが含まれています。ただし、従来のディメンションと同じバージョン管理された属性のセットを使用すると、使用するディスク領域を大幅に減らすことができます。当然、ここには魔法はありません-それはすべて正規化に関するものです。サテライト全体（データボールト内）または個別のテーブル（アンカーモデル）に属性を分散することにより、他の属性を変更するときに一部の属性の値の重複を減らす（または完全に排除する）。



以下のためにデータボールト、利得は衛星を横切る属性の分布に依存するであろう、とのためにアンカーモデルは、測定オブジェクトごとのバージョンの平均数にほぼ正比例します。



ただし、スペースを確保することは重要ですが、属性を個別に保存することの主な利点ではありません。リンクを個別に保存するとともに、このアプローチにより、リポジトリはモジュラー設計になります。この手段そのようなAモデルのルックスの両方の個々の属性と全体の新しい対象領域の追加アドオンそれらを変更することなく、オブジェクトの既存のセットの上に上。そして、これがまさに説明された方法論を柔軟にするものです。



また、ピース生産から大量生産への移行にも似ています。従来のアプローチで各モデルテーブルが一意であり、個別の注意が必要な場合、柔軟な方法論では、それはすでに典型的な「詳細」のセットです。一方では、より多くのテーブルがあり、データのロードとフェッチのプロセスはより複雑に見えるはずです。一方、それらは典型的になります。これは、メタデータによって自動化および管理できることを意味します。改善の設計の重要な部分を占める可能性のある「どのように配置するのか」という質問は、今では単に価値がありません（モデルの変更が作業プロセスに与える影響の問題も同様です）。



これは、そのようなシステムでアナリストがまったく必要ないという意味ではありません。誰かが属性を持つオブジェクトのセットを処理し、これらすべてをどこにどのようにロードするかを理解する必要があります。ただし、作業量、およびエラーの可能性とコストは大幅に削減されます。分析の段階とETLの開発中の両方で、本質的にはメタデータの編集に還元できます。

暗黒面

上記のすべてにより、両方のアプローチが非常に柔軟で、技術的に進歩し、反復的な改良に適しています。もちろん、あなたがすでに推測していると思う「軟膏のバレル」もあります。



柔軟なアーキテクチャのモジュール性の基礎であるデータ分解は、テーブルの数の増加につながり、したがって、フェッチ時の結合のオーバーヘッドにつながります。ディメンションのすべての属性を単純に取得するには、従来のリポジトリでは1つの選択で十分であり、柔軟なアーキテクチャでは多数の結合が必要になります。さらに、レポートの場合、これらすべての結合を事前に作成できると、SQLを手動で作成することに慣れているアナリストは2倍の苦労を強いられます。



この状況を容易にするいくつかの事実があります：



大きなディメンションで作業する場合、そのすべての属性が同時に使用されることはほとんどありません。これは、モデルを最初に見たときよりも結合が少ない可能性があることを意味します。 Data Vaultでは、衛星間で属性を配布するときに予想される共有頻度を考慮することもできます。同時に、ハブまたはアンカー自体は、主にロード段階でサロゲートを生成およびマッピングするために必要であり、リクエストで使用されることはめったにありません（特にアンカーの場合）。



すべての結合はキーによるものです。さらに、データを保存するためのより「簡潔な」方法により、必要な場所でテーブルをスキャンするオーバーヘッドが削減されます（たとえば、属性値でフィルタリングする場合）。これにより、多数の結合を使用して正規化されたデータベースからフェッチする方が、1行に多くのバージョンがある1つの重いディメンションをスキャンするよりもさらに高速になる可能性があります。



たとえば、この記事では、1つのテーブルから選択したアンカーモデルの詳細な比較パフォーマンステストがあります。



エンジンに大きく依存します。最新のプラットフォームの多くには、内部結合最適化メカニズムがあります。たとえば、MS SQLとOracleは、データが他の結合以外の場所で使用されておらず、最終的な選択（テーブル/結合の削除）に影響を与えない場合、テーブルへの結合を「スキップ」できますが、MPPVerticaはAvitoの同僚の経験は、クエリプランの手動最適化を考慮に入れると、アンカーモデルの優れたエンジンであることが証明されました。一方、たとえば、参加サポートが制限されているClick Houseでアンカーモデルを維持することは、今のところ良い考えとは思えません。



さらに、両方のアーキテクチャには、データへのアクセスを容易にするための特別な手法があります（クエリパフォーマンスの観点とエンドユーザーの両方の観点から）。たとえば、Data Vaultのポイントインタイムテーブルや、アンカーモデルの特別なテーブル関数などです。

合計

検討されている柔軟なアーキテクチャの主な本質は、それらの「設計」のモジュール性です。



以下を可能にするのはこのプロパティです。

• , ETL, , . ( ) .
• ( ) 2-3 , ( ).
• , - .
• 標準要素に分解されるため、このようなシステムのETLプロセスは同じタイプに見え、それらの記述はアルゴリズム化、そして最終的には自動化に役立ちます。

この柔軟性の代償はパフォーマンスです。これは、そのようなモデルで許容可能なパフォーマンスを達成することが不可能であることを意味するものではありません。多くの場合、必要なメトリックを達成するには、より多くの労力と細部への注意が必要です。

アプリケーション

DataVaultエンティティタイプ

Data Vaultの詳細：

DanListadtのサイト

ロシア語のDataVaultのすべてHabréのDataVault

について

アンカーモデルエンティティタイプ

アンカーモデルの詳細：



アンカーモデル作成者

のサイトAvitoでのアンカーモデルの実装の経験に関する記事



考慮されているアプローチの共通機能と相違点を含む要約表：