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

貯蔵施設の開発は時間のかかる真剣な仕事です。

プロジェクトの存続は、オブジェクト モデルと基本構造が最初にどれだけよく考えられているかに大きく左右されます。

一般に受け入れられているアプローチは、スター スキームと第 3 正規形を組み合わせたさまざまなバリエーションであり、今も昔も変わりません。 原則として、原則に従って：初期データ - XNUMXNF、ショーケース - スター。 このアプローチは、長年の実績があり、大量の調査によって裏付けられており、経験豊富な DWH スペシャリストが分析リポジトリがどうあるべきかを考えるときに最初に思い浮かぶ (場合によっては唯一の) ものです。

一方で、ビジネス全般、特に顧客の要件は急速に変化する傾向があり、データは「深く」も「広く」も増大する傾向があります。 そして、これがスターの主な欠点が現れる場所です - 限定的です 柔軟性.

そして、DWH 開発者としての静かで居心地の良い生活の中で、突然次のようになったとします。

• 「少なくとも何かをすぐに実行して、それから見てみましょう」という課題が生じました。
• 急速に発展するプロジェクトが出現し、少なくとも週に一度は新しい情報源を接続し、ビジネス モデルを再構築しました。
• システムがどのようなものであるべきか、最終的にどのような機能を実行する必要があるのか​​はまったくわからないが、実験を行って望ましい結果に常に近づけながら、一貫して改良を加える準備ができている顧客が現れました。
• プロジェクト マネージャーが朗報を持ってやって来ました。「これでアジャイルが実現しました!」

または、保管施設を他にどのように構築できるかを知りたいだけなら、ようこそ!

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

まず、システムが「柔軟」と呼ばれるためにどのような特性を備えていなければならないかを定義しましょう。

これとは別に、説明されているプロパティは特に次のことに関連する必要があることに言及する価値があります。 システム、ではなく プロセス その発展。 したがって、開発方法論としてのアジャイルについて読みたい場合は、他の記事を読んだ方がよいでしょう。 たとえば、ハブレ島には、興味深い資料がたくさんあります（ レビュー и 実用的と 問題がある).

これは、開発プロセスとデータ ウェアハウスの構造がまったく無関係であることを意味するものではありません。 全体として、アジャイル アーキテクチャ向けのアジャイル リポジトリの開発は大幅に簡単になるはずです。 しかし、実際には、XNUMX つのプロジェクトで XNUMX つの形式の柔軟性が偶然に実現するよりも、Kimbal 氏や DataVault 氏によると、ウォーターフォール氏によると、古典的な DWH のアジャイル開発という選択肢が存在することが多いのです。

では、フレキシブル ストレージにはどのような機能が必要でしょうか? ここでのポイントは次の XNUMX つです。

1. 早期納品と迅速な対応 - これは、理想的には、最初のビジネス結果 (たとえば、最初の作業レポート) をできるだけ早く、つまりシステム全体が完全に設計および実装される前に取得する必要があることを意味します。 さらに、その後の各改訂の時間もできるだけ短くする必要があります。
2. 反復的な改良 - これは、その後の各改善が、理想的にはすでに動作している機能に影響を与えないようにする必要があることを意味します。 大規模なプロジェクトで最大の悪夢となることが多いのはこの瞬間です。遅かれ早かれ、個々のオブジェクトが非常に多くの接続を取得し始めるため、既存のテーブルにフィールドを追加するよりも、近くのコピーでロジックを完全に繰り返す方が簡単になります。 また、既存のオブジェクトに対する改善の影響を分析する方が、改善そのものよりも時間がかかることに驚いている方は、おそらく、銀行や通信業界の大規模なデータ ウェアハウスをまだ扱ったことがないでしょう。
3. 変化するビジネス要件に常に適応する - オブジェクト全体の構造は、拡張の可能性を考慮するだけでなく、次の拡張の方向性が設計段階では夢にも思わなかったということも考慮して設計される必要があります。

そして、はい、これらすべての要件を XNUMX つのシステムで満たすことは可能です (もちろん、場合によっては、ある程度の条件はありますが)。

以下では、データ ウェアハウスの最も一般的なアジャイル設計手法の XNUMX つを検討します。 アンカーモデル и データ保管庫。 たとえば、EAV、6NF (純粋な形式)、および NoSQL ソリューションに関連するすべてのような優れた技術が括弧の外に残されています。これは、それらの技術が何らかの点で劣っているからではなく、この場合、記事が買収を脅かすからでもありません。平均的なディザーのボリューム。 ただ、これらはすべて、プロジェクトの全体的なアーキテクチャ (EAV など) に関係なく、特定のケースで使用できるテクニック、またはグローバルに他の情報ストレージ パラダイム (グラフ データベースなど) など、少し異なるクラスのソリューションに関連しています。およびその他のオプション NoSQL)。

「古典的」アプローチの問題点と柔軟な方法論による解決策

「古典的な」アプローチとは、古き良きスターのことを指します (基礎となる層の特定の実装に関係なく、Kimball、Inmon、CDM の信奉者はお許しください)。

1. 接続の厳格な基数

このモデルは、データを次のように明確に分割することに基づいています。 寸法 и 事実。 そして、これは、まったく、論理的です。結局のところ、圧倒的多数の場合のデータ分析は、特定のセクション (次元) における特定の数値指標 (事実) の分析に帰着します。

この場合、オブジェクト間の接続は、外部キーを使用したテーブル間の関係の形で確立されます。 これは非常に自然に見えますが、すぐに最初の柔軟性の制限につながります。 接続の基数の厳密な定義.

つまり、テーブルの設計段階で、関連オブジェクトのペアごとに、多対多で関連付けることができるのか、それとも 1 対多のみで関連付けることができるのか、また「どの方向に」関連付けることができるのかを正確に判断する必要があります。 これにより、どのテーブルが主キーを持つのか、どのテーブルが外部キーを持つのかが直接決まります。 新しい要件を受け取ったときにこの態度を変えると、ベースの手戻りにつながる可能性が高くなります。

たとえば、「現金受領書」オブジェクトを設計するときに、営業部門の宣誓を信頼して、アクションの可能性を設定しました。 複数のチェックポジションに対して XNUMX つのプロモーション (ただしその逆はありません):

そしてしばらくして、同僚たちは同じ立場で行動できる新しいマーケティング戦略を導入しました。 複数のプロモーションを同時に行う。 次に、リレーションシップを別のオブジェクトに分離してテーブルを変更する必要があります。

(昇格チェックが結合されているすべての派生オブジェクトも改善する必要があります)。

Data Vault とアンカー モデルの関係

この状況を回避するのは非常に簡単であることが判明しました。これを行うために営業部門を信頼する必要はありません。 すべての接続は最初は別のテーブルに保存されます そしてそれを多対多として処理します。

このアプローチが提案されたのは、 ダン・リンステット パラダイムの一部として データ保管庫 そして完全にサポートされています ラース・レンベック в アンカーモデル.

その結果、柔軟な方法論の最初の特徴が得られます。

オブジェクト間の関係は親エンティティの属性には保存されませんが、別の種類のオブジェクトとして保存されます。

В データ保管庫 このようなリンクテーブルは呼ばれます リンクとで アンカーモデル - ネクタイ。 一見すると、これらは非常によく似ていますが、違いは名前だけではありません (これについては後述します)。 どちらのアーキテクチャでも、リンク テーブルはリンクできます。 任意の数のエンティティ (必ずしも 2 であるとは限りません)。

この冗長性により、一見すると、変更に対する大幅な柔軟性が得られます。 このような構造は、既存のリンクの基数の変更だけでなく、新しいリンクの追加にも耐性を持ちます。小切手の位置に、そこを突破したレジ担当者へのリンクも含まれている場合、そのようなリンクの出現は単純です。既存のオブジェクトやプロセスに影響を与えることなく、既存のテーブルのアドオンになります。

2. データの重複

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

従来のウェアハウスでは、ディメンションは通常、サロゲート キー (PK として) と一連のビジネス キーおよび属性を別の列に含むテーブルです。

ディメンションがバージョン管理をサポートしている場合、バージョン有効性の境界がフィールドの標準セットに追加され、ソース内の XNUMX 行に対して複数のバージョンがリポジトリに表示されます (バージョン管理された属性の変更ごとに XNUMX つ)。

ディメンションに、頻繁に変更されるバージョン管理された属性が少なくとも XNUMX つ含まれている場合、そのようなディメンションのバージョンの数は膨大になります (残りの属性がバージョン管理されていないか、まったく変更されない場合でも)。また、そのような属性が複数ある場合、バージョンの数は大幅に増加します。その数は指数関数的に増加します。 このディメンションは、大量のディスク領域を占有する可能性がありますが、ディメンションに保存されるデータの多くは、他の行の不変属性値の単純な複製です。

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

通常、これにより次のようなことが起こります 同じ情報が複数の場所に同時に保存される。 たとえば、居住地域とクライアントのカテゴリに関する情報は、「クライアント」ディメンションと「購入」、「配送」、「コールセンターでの通話」の事実、および「クライアント - クライアント マネージャー」に同時に保存できます。 」リンクテーブル。

一般に、上記の内容は通常の (バージョン管理されていない) ディメンションに当てはまりますが、バージョン管理されたディメンションではスケールが異なる場合があります。オブジェクトの新しいバージョンの出現 (特に後から見ると) は、関連するすべてのディメンションの更新だけでなく、ただし、テーブル 1 を使用してテーブル 2 を構築し、テーブル 2 を使用してテーブル 3 を構築する場合など、関連オブジェクトの新しいバージョンがカスケード的に表示されます。 表 1 の属性が 3 つも表 2 の構築に関与していない場合でも (また、他のソースから取得した表 3 の他の属性も関与している)、この構築をバージョン管理すると、少なくとも追加のオーバーヘッドが発生し、最大で追加のオーバーヘッドが発生します。表 XNUMX のバージョンは、まったく関係がありません。さらにその下にあります。

3. リワークの非線形複雑さ

同時に、別のストアフロントに基づいて新しいストアフロントが構築されるたびに、ETL に変更が加えられたときにデータが「分岐」する可能性のある場所の数が増加します。 これにより、後続の各リビジョンの複雑さ (および期間) が増加します。

上記で ETL プロセスがほとんど変更されないシステムについて説明している場合は、そのようなパラダイムに従うことができます。必要なのは、関連するすべてのオブジェクトに新しい変更が正しく行われていることを確認することだけです。 改訂が頻繁に発生すると、いくつかの接続が誤って「欠落」する可能性が大幅に増加します。

さらに、「バージョン管理された」ETL が「バージョン管理されていない」ETL よりも大幅に複雑であることを考慮すると、この機能全体を頻繁に更新するときに間違いを避けることが非常に困難になります。

Data Vault と Anchor Model へのオブジェクトと属性の保存

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

変化するものと変わらないものを区別する必要があります。 つまり、キーを属性とは別に保存します。

ただし、混同してはいけません バージョン管理されていない 属性付き 変更なし: 最初のものは変更履歴を保存しませんが、変更される可能性があります (たとえば、入力エラーを修正するときや新しいデータを受信するとき)、XNUMX 番目のものは決して変更されません。

Data Vault とアンカー モデルで正確に何が不変とみなせるかについては、視点が異なります。

建築的な観点から見ると データ保管庫、変更されていないと考えることができます キーのセット全体 - ナチュラル (組織の TIN、ソース システムの製品コードなど) およびサロゲート。 この場合、残りの属性は、変更のソースおよび/または頻度に応じてグループに分割できます。 グループごとに個別のテーブルを維持する 独立したバージョンのセットを使用します。

パラダイムでは アンカーモデル 変化がないとみなされる 代理キーのみ エッセンス。 他のすべて (自然キーを含む) は、その属性の特殊なケースにすぎません。 その中で すべての属性はデフォルトで互いに独立していますしたがって、各属性について、 別のテーブル.

В データ保管庫 エンティティキーを含むテーブルは呼び出されます 湖見。 ハブには常に、次のフィールドの固定セットが含まれます。

• 自然エンティティキー
• 代理キー
• ソースへのリンク
• レコード追加時間

ハブの投稿 決して変更されず、バージョンもありません。 外部的には、ハブは一部のシステムでサロゲートを生成するために使用される ID マップ タイプのテーブルに非常に似ていますが、Data Vault ではビジネス キーのセットからのハッシュをサロゲートとして使用することをお勧めします。 このアプローチでは、ソースからの関係と属性のロードが簡素化されます (サロゲートを取得するためにハブに参加する必要はなく、自然キーのハッシュを計算するだけです) が、他の問題 (衝突、大文字と小文字、印刷不能などに関連した問題) が発生する可能性があります。文字列キーなどの文字.p.)、したがって、一般的には受け入れられません。

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

衛星間の属性の配布は、次の原理に従って行われます。 関節の変更 — XNUMX つのサテライトにはバージョン管理されていない属性 (個人の生年月日や SNILS など) を保存でき、別のサテライトにはほとんど変更されないバージョン管理された属性 (姓やパスポート番号など)、XNUMX 番目には頻繁に変更される属性が保存されます。 (例: 配送先住所、カテゴリ、最後の注文日など)。 この場合、バージョン管理はエンティティ全体ではなく、個々のサテライトのレベルで実行されるため、XNUMX つのサテライト内のバージョンの交差が最小限になるように属性を分散することをお勧めします (保存されるバージョンの総数が減少します)。 ）。

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

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

В アンカーモデル キーを格納するテーブルはと呼ばれます アンカー。 そして彼らは次のように続けています。

• 代理キーのみ
• ソースへのリンク
• レコード追加時間

アンカーモデルの観点からの自然キーが考慮されます 通常の属性。 このオプションは理解するのが難しいように思えるかもしれませんが、オブジェクトを識別するための範囲がはるかに広がります。

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

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

В データ保管庫 これらのルールがフォーメーションを決定する可能性が高くなります マスターエンティティの「サロゲートハブ」 また、自然なソース キーとその元の属性を保存するハブには一切影響を与えません。 ある時点でマージ ルールが変更された場合 (またはマージ ルールを実行する属性が更新された場合)、サロゲート ハブを再フォーマットするだけで十分です。

В アンカーモデル そのようなエンティティは、おそらく次の場所に保存されます。 唯一のアンカー。 これは、どのようなソースから来たものであっても、すべての属性が同じサロゲートにバインドされることを意味します。 誤ってマージされたレコードを分離し、一般に、そのようなシステムでマージの関連性を監視することは、特にルールが非常に複雑で頻繁に変更され、同じ属性が異なるソースから取得できる場合には、はるかに困難になる可能性があります (ただし、確かにそうです)。各属性バージョンがそのソースへのリンクを保持しているため、可能です)。

いずれにせよ、システムがその機能を実装する必要がある場合は、 重複排除、レコードのマージ、その他の MDM 要素、アジャイル手法における自然キーの保存の側面に特に注意を払う価値があります。 おそらく、より大規模な Data Vault 設計が、マージ エラーの観点から突然安全になる可能性があります。

アンカーモデル という追加のオブジェクト タイプも提供します。 結び目 それは本質的に特別です 退化タイプのアンカー、属性を XNUMX つだけ含めることができます。 ノードは、フラットなディレクトリ (性別、婚姻状況、顧客サービス カテゴリなど) を保存するために使用されることになっています。 アンカーとは異なり、ノットは 関連する属性テーブルがありません、その唯一の属性 (名前) は常にキーと同じテーブルに保存されます。 アンカーが相互に接続されるのと同じ方法で、ノードはタイ テーブル (Tie) によってアンカーに接続されます。

ノードの使用に関して明確な意見はありません。 例えば、 ニコライ・ゴロフロシアでアンカーモデルの使用を積極的に推進している彼は、（不合理ではないが）どの参考書についても、次のように断言できると信じている。 常に は静的で単一レベルになるため、すべてのオブジェクトに対してすぐに本格的なアンカーを使用することをお勧めします。

Data Vault とアンカー モデルのもう XNUMX つの重要な違いは、可用性です。 接続の属性:

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

ファクトストレージ

これまでは、主に測定モデリングについて説明しました。 事実は少し明らかではありません。

В データ保管庫 ファクトを保存するための典型的なオブジェクトは次のとおりです。 リンク、その衛星には実際のインジケーターが追加されます。

このアプローチは直感的に思えます。 これは、分析された指標への簡単なアクセスを提供し、一般に従来のファクト テーブルに似ています (指標のみがテーブル自体ではなく、「隣接する」テーブルに保存されます)。 しかし、落とし穴もあります。モデルの典型的な変更の XNUMX つであるファクト キーの拡張では、 新しい外部キーをリンクに追加する。 そして、これによりモジュール性が「破壊」され、他のオブジェクトへの変更が必要になる可能性があります。

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

したがって、アンカー モデルでファクト キーを展開するときにモジュール性の問題は発生しません (対応するアンカーに新しいリレーションシップを追加するだけで十分です) が、ファクトを表示するモデルの設計はそれほど明確ではなく、「人工的な」アンカーが表示される可能性があります。ビジネス オブジェクト モデルが不明瞭に表示されます。

柔軟性を実現する方法

どちらの場合でも、結果として得られる構造には次のものが含まれます。 大幅に多くのテーブル従来の測定よりも優れています。 しかし、それはかかるかもしれません ディスク容量が大幅に減少 従来のディメンションと同じバージョン化された属性セットを使用します。 当然のことながら、ここには魔法はありません。すべては正規化に関するものです。 サテライト (Data Vault 内) または個々のテーブル (アンカー モデル) 全体に属性を分散することで、属性を削減 (または完全に排除) します。 他の属性を変更すると、一部の属性の値が重複する.

のために データ保管庫 賞金はサテライト間の属性の配分によって異なります。 アンカーモデル — は、測定オブジェクトごとの平均バージョン数にほぼ正比例します。

ただし、スペースの節約は、属性を個別に保存することの重要な利点ではありますが、主な利点ではありません。 このアプローチは、関係を個別に保存することと併せて、ストアを作成します。 モジュール設計。 つまり、そのようなモデルに個々の属性と新しいサブジェクト領域全体の両方を追加すると、次のようになります。 上部構造 オブジェクトの既存のセットを変更せずに上書きします。 そして、これこそが、説明されている方法論を柔軟にするものです。

これは、個数生産から大量生産への移行にも似ています。従来のアプローチでは、モデルの各テーブルが独自で特別な注意が必要である場合、柔軟な方法論では、それはすでに標準の「部品」のセットです。 一方で、テーブルの数が増え、データのロードと取得のプロセスがより複雑になるはずです。 一方、彼らは次のようになります。 典型的な。 つまり、あるかもしれない 自動化およびメタデータ主導型。 「どのように構築するか?」という質問は、その答えが改善設計の作業の重要な部分を占める可能性がありますが、今ではまったく価値がありません (モデルの変更が作業プロセスに及ぼす影響についての質問も同様です) ）。

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

ダークサイド

上記のすべてにより、どちらのアプローチも真に柔軟で、技術的に進歩し、反復的な改善に適したものになります。 もちろん、「軟膏の樽」もありますが、それについてはすでに推測できると思います。

柔軟なアーキテクチャのモジュール性の基礎となるデータ分解は、テーブル数の増加につながり、それに応じて、 オーバーヘッド サンプリング時に結合します。 ディメンションのすべての属性を単純に取得するには、従来のストアでは XNUMX 回の選択で十分ですが、柔軟なアーキテクチャでは一連の結合全体が必要になります。 さらに、レポートのこれらすべての結合を事前に作成できる場合、手動で SQL を作成することに慣れているアナリストは二重に苦労することになります。

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

大きなディメンションを操作する場合、そのすべての属性が同時に使用されることはほとんどありません。 これは、モデルを一見したように見えるよりも結合が少ない可能性があることを意味します。 Data Vault は、属性をサテライトに割り当てるときに、予想される共有頻度も考慮に入れることができます。 同時に、ハブまたはアンカー自体は主に読み込み段階でサロゲートを生成およびマッピングするために必要であり、クエリで使用されることはほとんどありません (これは特にアンカーに当てはまります)。

すべての結合はキーによって行われます。 さらに、より「圧縮された」データの保存方法により、必要な場合 (属性値によるフィルター処理など) のテーブルのスキャンのオーバーヘッドが削減されます。 これにより、多数の結合を含む正規化されたデータベースからのサンプリングの方が、行ごとに多くのバージョンを含む XNUMX つの重いディメンションをスキャンするよりも高速になる可能性があります。

たとえば、ここでは この この記事には、XNUMX つのテーブルのサンプルを使用したアンカー モデルのパフォーマンスの詳細な比較テストが含まれています。

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

さらに、どちらのアーキテクチャにも、 特別な動きにより、データ アクセスが容易になります (クエリ パフォーマンスの観点とエンド ユーザーの両方の観点から)。 例えば、 ポイントインタイムテーブル Data Vault または 特別なテーブル関数 アンカーモデルで。

合計で

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

このプロパティにより、次のことが可能になります。

• メタデータの展開と基本的な ETL アルゴリズムの作成に関連する初期準備を行った後、 顧客に最初の結果を迅速に提供する わずか数個のソース オブジェクトからのデータを含むいくつかのレポートの形式。 オブジェクト モデル全体を (最上位レベルであっても) 徹底的に考える必要はありません。
• データ モデルは、わずか 2 ～ 3 個のオブジェクトで動作し始める (そして便利になる) ことができます。 徐々に成長する （アンカーモデルのニコライについて） 適用された 菌糸体との素晴らしい比較)。
• 対象領域の拡大や新しいソースの追加など、ほとんどの改善 既存の機能には影響せず、すでに動作しているものを壊すリスクもありません.
• 標準要素への分解のおかげで、そのようなシステムの ETL プロセスは同じように見え、その記述はアルゴリズム化に適しており、最終的には オートメーション.

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

アプリ

エンティティの種類 データ保管庫

Data Vault の詳細情報:
ダン・ライシュタットのウェブサイト
ロシア語での Data Vault のすべて
Habré の Data Vault について

エンティティの種類 アンカーモデル

アンカー モデルの詳細:

Anchor Model 作成者の Web サイト
Avito でのアンカー モデルの実装体験に関する記事

検討されたアプローチの共通の特徴と相違点をまとめた表:

出所： habr.com