開發儲存設施是一項長期而艱鉅的任務。
專案的生命週期在很大程度上取決於物件模型和基礎結構在開始時的考慮程度。
普遍接受的方法一直是並且仍然是星型方案與第三範式結合的各種變體。 通常，根據原則：初始數據 - 3NF，展示 - 明星。 這種經過時間考驗並得到大量研究支持的方法是經驗豐富的 DWH 專家在考慮分析儲存庫應該是什麼樣子時首先想到的（有時是唯一的）事情。
另一方面，一般業務和特別是客戶需求往往會快速變化，數據往往會「深度」和「廣度」成長。 這就是明星的主要缺點出現的地方——有限 靈活性.
如果在您作為 DWH 開發人員的安靜舒適的生活中突然出現：
- 任務是「至少快速做一些事情，然後我們看看」；
- 出現了一個快速發展的項目，每周至少一次連接新資源並重新設計商業模式；
- 出現了一位客戶，他不知道系統應該是什麼樣子以及它最終應該執行什麼功能，但準備好進行試驗並不斷完善所需的結果，同時不斷接近它；
- 專案經理順便帶來了好消息：“現在我們有敏捷了！”
或者，如果您只是想了解如何建立儲存設施 - 歡迎來到剪切！
「靈活性」是什麼意思？
首先，讓我們定義一個系統必須具備哪些屬性才能稱為「靈活」。
另外，值得一提的是，所描述的屬性應具體涉及 系統，不 流程 它的發展。 因此，如果您想了解敏捷作為一種開發方法，最好閱讀其他文章。 例如，就在那裡，在 Habré 上，有很多有趣的材料（例如 и 和 ).
這並不意味著開發過程和資料倉儲的結構完全無關。 總的來說，為敏捷架構開發敏捷儲存庫應該要容易得多。 然而，在實踐中，根據 Kimbal 和 DataVault 的說法，經典 DWH 的敏捷開發通常有多種選擇 - 根據 Waterfall 的說法，而不是一個專案上兩種形式的靈活性的巧合。
那麼，靈活儲存該具備哪些能力呢？ 這裡有三點：
- 提前交付和快速週轉 - 這意味著理想情況下應儘早獲得第一個業務結果（例如第一個工作報告），甚至在整個系統完全設計和實施之前。 而且，後續的每次修改也應該花費盡可能少的時間。
- 迭代細化 - 這意味著每次後續改進理想情況下不應影響已運行的功能。 這一刻往往成為大型專案中最大的噩夢 - 遲早，各個物件開始獲得如此多的連接，以至於在附近的副本中完全重複邏輯比向現有表格添加欄位更容易。 如果您驚訝地發現分析改進對現有物件的影響可能比改進本身花費更多的時間，那麼您很可能還沒有使用過銀行或電信中的大型資料倉儲。
- 不斷適應不斷變化的業務需求 - 整體物件結構的設計不應只考慮可能的擴展，而是要預期下一個擴展的方向在設計階段是無法想像的。
是的，在一個系統中滿足所有這些要求是可能的（當然，在某些情況下並且有一些保留）。
下面我將考慮兩種最受歡迎的資料倉儲敏捷設計方法 - 錨模型 и 數據倉庫。 排除在括號之外的是一些優秀的技術，例如EAV、6NF（以其純粹的形式）以及與NoSQL 解決方案相關的所有內容- 並不是因為它們在某種程度上更糟糕，甚至不是因為在這種情況下該文章會威脅要收購平均disser的音量。 只是所有這些都與稍微不同類別的解決方案相關 - 要么是可以在特定情況下使用的技術，無論項目的整體架構如何（例如 EAV），要么是全局其他信息存儲範例（例如圖形數據庫）和其他選項NoSQL）。
「經典」方法的問題及其靈活方法的解決方案
我所說的「經典」方法是指優秀的老明星（無論底層的具體實現如何，請 Kimball、Inmon 和 CDM 的追隨者原諒我）。
1. 連接的剛性基數
該模型基於將數據明確劃分為 方面 и 事實。 這，媽的，是合乎邏輯的——畢竟，絕大多數情況下的數據分析都歸結為對某些部分（維度）中某些數值指標（事實）的分析。
在這種情況下，物件之間的連接是使用外鍵以表之間關係的形式建立的。 這看起來很自然，但立即導致了靈活性的第一個限制—— 嚴格定義連接基數.
這意味著在表設計階段，您必須準確地確定每對相關物件是否可以多對多關聯，還是只能一對多關聯，以及「在哪個方向」。 這直接決定了哪個表將具有主鍵，哪個表將具有外鍵。 當收到新要求時改變這種態度很可能會導致基礎的重新設計。
例如，在設計「現金收據」物件時，您依靠銷售部門的誓言，制定了行動的可能性 一次晉升多個檢查職位 （但反之則不然）：
一段時間後，同事們推出了一種新的行銷策略，他們可以在相同的位置上採取行動 多個促銷活動同時進行。 現在您需要透過將關係分離到單獨的物件中來修改表格。
（現在加入升級檢查的所有派生物件也需要改進）。
Data Vault 與錨定模型中的關係
事實證明，避免這種情況非常簡單：您不必相信銷售部門會這樣做。 所有連接最初都儲存在單獨的表中 並將其處理為多對多。
提出了這種方法 丹·林斯特 作為範式的一部分 數據倉庫 並全力支持 拉爾斯·倫巴克 в 錨模型.
由此，我們得到了彈性方法論的第一個顯著特徵：
物件之間的關係不會儲存在父實體的屬性中，而是單獨類型的物件。
В 數據倉庫 這種連結表稱為 Link，並在 錨模型 - 領帶。 乍一看，它們非常相似，儘管它們的差異並不以名稱結束（這將在下面討論）。 在兩種架構中，連結表都可以連結 任意數量的實體 （不一定是 2）。
乍一看，這種冗餘為修改提供了極大的靈活性。 這樣的結構不僅可以容忍現有鏈結基數的變化，還可以容忍新鏈接的添加 - 如果現在支票位置也有一個指向突破它的收銀員的鏈接，那麼這種鏈接的出現將簡單地成為現有表的附加元件，而不影響任何現有物件和流程。
2. 數據重複
靈活架構解決的第二個問題較不明顯，且是首先固有的。 SCD2 型測量 （慢慢改變第二種類型的維度），儘管不只是他們。
在經典倉庫中，維度通常是一個表，其中包含代理鍵（作為 PK）以及單獨列中的一組業務鍵和屬性。
如果維度支援版本控制，則版本有效性邊界將新增至標準欄位集，且來源中一行的多個版本會出現在儲存庫中（版本化屬性的每個變更對應一個版本）。
如果一個維度至少包含一個頻繁更改的版本化屬性，那麼該維度的版本數量將是可觀的（即使其餘屬性沒有版本化或從不更改），並且如果存在多個這樣的屬性，則版本數量可以他們的數量呈指數級增長。 此維度可能會佔用大量磁碟空間，儘管它儲存的大部分資料只是其他行中不可變屬性值的重複。
同時，它也經常被使用 非規範化 — 某些屬性有意儲存為值，而不是作為參考書或其他維度的連結。 此方法可加快資料存取速度，減少存取維度時的聯接數量。
通常這會導致 相同的資訊同時儲存在多個地方。 例如，有關居住地區和客戶類別的資訊可以同時儲存在「客戶」維度和「購買」、「送貨」和「呼叫中心呼叫」事實中，以及「客戶-客戶經理」中」連結表。
一般來說，上述內容適用於常規（非版本化）維度，但在版本化維度中，它們可能具有不同的比例：物件新版本的出現（尤其是回顧）不僅會導致所有相關的更新表，而是相關對象的新版本的級聯外觀- 當表1 用於構建表2，表2 用於構建表3 時，等等。 即使表 1 的構造中不涉及表 3 的單一屬性（並且涉及從其他來源獲得的表 2 的其他屬性），對該構造進行版本控制至少會導致額外的開銷，最多會導致額外的開銷表3 中的版本與它完全無關，並且在鏈的更下游。
3.返工的非線性複雜性
同時，每個建立在另一個店面基礎上的新店面都會增加在 ETL 發生更改時資料可能「發散」的地方的數量。 這反過來又導致每個後續修訂的複雜性（和持續時間）增加。
如果上面描述的系統很少修改 ETL 過程，那麼您可以生活在這樣的範例中 - 您只需要確保對所有相關物件進行正確的新修改。 如果頻繁進行修改，則意外「遺失」多個連線的可能性會顯著增加。
此外，如果我們考慮到「版本化」ETL 比「非版本化」ETL 複雜得多，那麼在頻繁更新整個設施時就很難避免錯誤。
在 Data Vault 和 Anchor Model 中儲存物件和屬性
靈活架構的作者提出的方法可以表達如下：
有必要將變化的內容與保持不變的內容區分開來。 也就是說，將鍵與屬性分開儲存。
然而，人們不應該混淆 沒有版本控制 屬性與 不變：第一個不儲存其更改的歷史記錄，但可以更改（例如，當更正輸入錯誤或接收新資料時）；第二個永遠不會更改。
對於資料倉儲和錨模型中到底什麼可以被認為是不可變的，有不同的觀點。
從建築學的角度來看 數據倉庫, 可以認為是不變的 整套鑰匙 - 自然（組織的 TIN、來源系統中的產品代碼等）和替代。 在這種情況下，剩餘的屬性可以根據變化的來源和/或頻率進行分組，並且 為每個群組維護一個單獨的表 具有一組獨立的版本。
在範式中 錨模型 視為不變 唯一的代理鍵 本質。 其他一切（包括自然鍵）只是其屬性的特殊情況。 其中 預設所有屬性都是相互獨立的，因此對於每個屬性 單獨的表.
В 數據倉庫 包含實體鍵的表稱為 胡巴米。 集線器始終包含一組固定的欄位：
- 自然實體鍵
- 代理鍵
- 連結到來源
- 記錄新增時間
中心的帖子 永遠不會改變並且沒有版本。 從外部來看，集線器與某些系統中用於產生代理項的 ID 對映類型表非常相似，但是，建議使用一組業務金鑰中的雜湊值作為 Data Vault 中的代理程式。 這種方法簡化了從來源載入關係和屬性（不需要加入集線器來取得代理，只需計算自然鍵的雜湊值），但可能會導致其他問題（例如，與衝突、大小寫和不可列印相關）字串鍵等中的字元.p.），因此它不被普遍接受。
所有其他實體屬性都儲存在稱為 衛星。 一個集線器可以有多個儲存不同屬性集的衛星。
衛星之間的屬性分配遵循以下原則 共同改變 — 在一顆衛星中，可以儲存非版本化屬性（例如，個人的出生日期和SNILS），在另一顆衛星中，儲存很少更改的版本化屬性（例如，姓氏和護照號碼），在第在三顆衛星中，儲存經常變更的屬性（例如，送貨地址、類別、最後訂單日期等）。 在這種情況下，版本控制是在單一衛星層級進行的，而不是在整個實體層級上進行的，因此建議分發屬性，以使一顆衛星內版本的交集最小化（這會減少儲存版本的總數） ）。
此外，為了優化資料載入過程，從各種來源獲得的屬性通常包含在各個衛星中。
衛星透過以下方式與集線器通信 外鍵 （對應一對多基數）。 這意味著這種「預設」架構支援多個屬性值（例如，一個客戶的多個聯絡電話號碼）。
В 錨模型 儲存鍵的表稱為 錨。 他們保留：
- 僅代理鍵
- 連結到來源
- 記錄新增時間
從錨模型的角度考慮自然鍵 普通屬性。 此選項可能看起來更難以理解，但它為識別物件提供了更大的範圍。
例如，如果有關相同實體的資料可以來自不同的系統，則每個系統都會使用自己的自然金鑰。 在Data Vault 中，這可能會導致相當繁瑣的多個集線器結構（每個來源一個+ 統一的主版本），而在Anchor 模型中，每個來源的自然鍵屬於其自己的屬性，並且可以在獨立加載時使用所有其他人。
但這裡也有一個陰險的地方：如果來自不同系統的屬性組合在一個實體中，很可能會有一些屬性 「黏合」規則，系統必須了解來自不同來源的記錄對應於實體的一個實例。
В 數據倉庫 這些規則很可能決定陣型 主實體的“代理中心” 並且不會以任何方式影響儲存自然來源密鑰及其原始屬性的集線器。 如果在某個時刻合併規則發生變化（或執行合併規則的屬性被更新），則重新格式化代理集線器就足夠了。
В 錨模型 這樣的實體很可能會儲存在 唯一的錨。 這意味著所有屬性，無論它們來自什麼來源，都將綁定到同一個代理。 分離錯誤合併的記錄以及一般情況下監視此類系統中合併的相關性可能要困難得多，特別是如果規則非常複雜且頻繁更改，並且可以從不同的來源獲取相同的屬性（儘管它肯定是可能的，因為每個屬性版本都保留其來源的連結）。
無論如何，如果您的系統應該實現該功能 重複資料刪除、合併記錄和其他 MDM 元素，值得特別關注敏捷方法中儲存自然鍵的方面。 就合併錯誤而言，笨重的資料倉儲設計可能會突然變得更安全。
錨模型 還提供了一個額外的物件類型，稱為 結 它本質上很特別 簡併型錨點，它只能包含一個屬性。 這些節點應該用於儲存平面目錄（例如性別、婚姻狀況、客戶服務類別等）。 與錨不同的是，結 沒有關聯的屬性表，並且它的唯一屬性（名稱）始終與鍵儲存在同一個表中。 節點透過連接表（Tie）連接到 Anchor，就像 Anchor 之間相互連接一樣。
關於節點的使用沒有明確的意見。 例如， 積極推動在俄羅斯使用錨定模型的人認為（並非沒有道理），沒有一本參考書可以肯定地說，它 總是 將是靜態的和單級的，因此最好立即對所有物件使用成熟的 Anchor。
Data Vault 和 Anchor 模型之間的另一個重要區別是可用性 連線屬性:
В 數據倉庫 連結是與集線器相同的成熟對象，並且可以具有 自己的屬性。 在 錨模型 連結僅用於連接錨點和 不能有自己的屬性。 這種差異導致建模方法顯著不同 事實，這將進一步討論。
事實儲存
在此之前，我們主要討論了測量建模。 事實還不太清楚。
В 數據倉庫 存儲事實的典型物件是 關聯，在其衛星中加入真實指標。
這種方法看起來很直覺。 它提供了對分析指標的輕鬆訪問，通常類似於傳統的事實表（只是指標不存儲在表本身中，而是存儲在“相鄰”表中）。 但也存在陷阱：模型的典型修改之一 - 事實金鑰的擴展 - 需要 在 Link 新增新的外鍵。 反過來，這「破壞」了模組化並可能導致需要修改其他物件。
В 錨模型 連結不能有自己的屬性，因此這種方法行不通——所有屬性和指標絕對必須連結到特定的錨點。 由此得出的結論很簡單—— 每個事實也需要自己的錨點。 對於我們習慣於視為事實的某些內容，這可能看起來很自然 - 例如，購買的事實可以完美地簡化為對象“訂單”或“收據”、訪問網站進行會話等。 但也有一些事實，要找到這樣一個天然的「載體物件」並不那麼容易——例如，每天早上倉庫中剩餘的貨物。
因此，在Anchor 模型中擴展事實鍵時不會出現模組化問題（只需向相應的Anchor 添加新的關係就足夠了），但設計一個模型來顯示事實就不那麼明確了；可能會出現「人工”Anchor以不清楚的方式顯示業務對像模型。
如何實現靈活性
兩種情況下得到的結構都包含 明顯更多的桌子比傳統測量。 但這可能需要 顯著減少磁碟空間 具有與傳統維度相同的版本化屬性集。 當然，這裡並沒有什麼魔力——一切都與標準化有關。 透過跨衛星（在資料倉儲中）或單一表（錨模型）分配屬性，我們減少（或完全消除） 更改其他屬性時某些屬性的值重複.
為 數據倉庫 獎金將取決於衛星之間的屬性分佈，並且 錨模型 — 幾乎與每個測量對象的平均版本數成正比。
然而，節省空間是單獨儲存屬性的重要優勢，但不是主要優勢。 與單獨的關係存儲一起，這種方法使得存儲 模組化設計。 這意味著在這樣的模型中添加單獨的屬性和整個新的主題領域看起來像 上層建築 覆蓋現有的一組物件而不更改它們。 這正是所描述的方法變得靈活的原因。
這也類似於從單件生產到大規模生產的轉變——如果在傳統方法中模型的每個表都是唯一的並且需要特別關注，那麼在靈活的方法中它已經是一組標準“零件” 。 一方面，表格更多，載入和檢索資料的過程應該看起來更複雜。 另一方面，他們也成為 典型的。 這意味著可能有 自動化和元數據驅動。 「我們將如何鋪設？」這個問題的答案可能會佔用設計改進工作的很大一部分，但現在根本不值得（以及關於更改模型對工作流程的影響的問題） ）。
這並不意味著這樣的系統根本不需要分析師——仍然需要有人處理具有屬性的物件集，並弄清楚在哪裡以及如何載入它們。 但工作量以及出錯的可能性和成本都顯著減少。 無論是在分析階段還是在 ETL 的開發過程中，其中很大一部分都可以簡化為編輯元資料。
黑暗的一面
所有這些使得這兩種方法真正靈活、技術先進並且適合迭代改進。 當然，還有一個“美中不足”，我想你已經猜到了。
資料分解是靈活架構模組化的基礎，導致表格數量增加，相應地， 高架 採樣時加入。 為了簡單地獲取一個維度的所有屬性，在經典儲存中，一個選擇就足夠了，但靈活的架構將需要一系列的連接。 而且，如果所有這些報表的連接都可以提前編寫，那麼習慣於手工編寫SQL的分析師將遭受加倍的痛苦。
有幾個事實可以使這種情況變得更容易：
當處理大維度時，它的所有屬性幾乎不會同時使用。 這意味著連接數可能比模型乍看之下要少。 在向衛星指派屬性時，Data Vault 還可以考慮預期的共用頻率。 同時，集線器或錨點本身主要用於在載入階段產生和映射代理，很少在查詢中使用（對於錨點尤其如此）。
所有連接都是透過鍵進行的。 此外，更「壓縮」的資料儲存方式減少了在需要時掃描表的開銷（例如，按屬性值過濾時）。 這可能導致這樣一個事實：從具有一堆聯接的規範化資料庫中進行採樣甚至比掃描每行多個版本的一個大維度更快。
例如，在這裡 文章包含了 Anchor 模型表現與一張表中樣本的詳細比較測試。
很大程度上取決於引擎。 許多現代平台都有內部連結優化機制。 例如，MS SQL 和 Oracle 可以「跳過」表的聯接，如果它們的資料除了其他聯接之外沒有在任何地方使用，並且不影響最終選擇（表/聯結消除），而 MPP Vertica ，已被證明是錨模型的優秀引擎，考慮到對查詢計劃的一些手動優化。 另一方面，將錨定模型儲存在例如具有有限連接支援的 Click House 上，看起來還不是一個好主意。
此外，對於這兩種架構都有 特殊動作，使資料存取更容易（無論是從查詢效能的角度還是對於最終用戶而言）。 例如， 時間點表 在資料保險庫中或 特殊表函數 在錨模型中。
在總
所考慮的靈活架構的主要本質是其「設計」的模組化。
正是這個屬性允許：
- 經過一些與元資料部署和編寫基本 ETL 演算法相關的初步準備後， 快速向客戶提供第一個結果 以包含來自幾個來源物件的資料的幾個報告的形式。 沒有必要徹底思考（即使在頂層）整個物件模型。
- 資料模型只需 2-3 個物件就可以開始工作（並且有用），然後 逐漸成長 （關於錨模型尼古拉 與菌絲體進行了很好的比較）。
- 大多數改進，包括擴展主題領域和添加新來源 不會影響現有功能，也不會帶來破壞已經運作的功能的風險.
- 由於分解為標準元素，此類系統中的 ETL 流程看起來相同，它們的編寫方式適合演算法化，最終， 自動化.
這種靈活性的代價是 生產率。 這並不意味著在此類模型上不可能實現可接受的性能。 通常，您可能只是需要更多的努力和對細節的關注來實現您想要的指標。
應用程序
實體類型 數據倉庫
有關數據保險庫的更多資訊：
實體類型 錨模型
有關錨定模型的更多詳細資訊：
所考慮方法的共同特徵和差異的總結表：
來源： www.habr.com