背景：
當一個新的資料倉庫、資料集市從零開始建設時，我們通常會糾結如何按照經典的數倉分層理論進行設計，然後按照經驗規範進行所有的開發工作；但從實際開發過程中，會發現這種思路類似建設一個大型系統，想在設計階段就把各種需求考慮完整，然後再花時間統一建設，這種思路需要非常完整的專家領域經驗及模組化方法論，對人員及時間的要求非常高，不适合目前快速發展的業務需要，是以我們需要對數倉建設的靈活實踐進行探索。
資料層次的階段變化：
在不同的發展階段，資料層次會呈現出不同的狀态：
階段一：
起步階段，資料資産從零開始建設，各種adm應用層資料直接按需求口徑從ods貼源資料表擷取，資料複用不考慮層次問題，會出現各種 adm + ods 混合處理 産出新的 adm 資料，慢慢出現所謂的蜘蛛網結構
階段二：
初步治理階段，開始對複用資料進行治理，按需衍生出新的 dwd 中間層資料，但需求發展較快的情況下，dwd 中間層 并不能快速進行需求疊代，又開始形成 ods + dwd 混合處理 産出新的 dwd 或者 adm 資料，也就出現了模糊的層次結構
階段三：
規範治理階段，開始對 中間層 複用資料進行重新設計和重構，制定中間層的開發規範，這個階段 dwd + dwd 模式可以滿足大部分的資料需求，但并不能避免 dwd + ods 混合産生 dwd 或者 adm 資料，這是 數倉特性 所決定，新的資料 和 新的需求 需要在不斷的處理過程中慢慢被整理和規範化使用，這種 dwd 中間層不斷疊代的階段是我們通常所處的階段，有清晰的結構和流轉層次
階段四：
靈活開發階段，為了權衡 開發的規範要求 與 傳遞協作的時效性，開始按靈活思路進行 dwd 中間層共建，dwd + ods 多版本共存管理，按周期性進行 dwd + ods 治理，沉澱統一口徑的dwd中間層資料，這個階段要求開發團隊有較成熟的設計和管理能力，可以長時間的保持 清晰的層次結構和子產品設計
靈活模式下的資料治理：
從上文中的四個不同階段可以看出，在實際工作中需要制定不同的資料治理政策，保證資料流轉的層次可控及較高的傳遞效率；綜合起來可以先從以下幾點開始：
1、從規範上要求避免 adm 應用層互相依賴的情況，特殊情況可以使用 臨時表 解決，犧牲一些計算代價
2、在初期明确 靈活dwd中間層 共建方法，友善對多版本進行管理與後續治理
3、對涉及 口徑處理 的字段或名額 上升到dwd層處理
4、周期進行 靈活dwd多版本治理 與 ods穿透治理
5、對dwd層次進行管理和要求，混合層次不要超過三層
6、定期整理治理需求，短期靈活疊代治理
靈活模式下的資料品質保障：
由于靈活模式下，中間層會頻繁疊代及多版本合并，對資料品質保障會有更高的要求，需要從人員能力及流程規範上嚴格要求：
1、安排專人負責中間層疊代或合并開發，必須進行全量資料對比測試及代碼review
2、所有中間層資産 必須明确業務主鍵 并 配置dqc規則
3、下遊adm替換修改由團隊共建，按風險等級進行結果資料驗證
總結：
資料的靈活開發本質上為了解決業務需求時效要求與中間層建設投入在 時間和協作 上的沖突，在正常的資料中台架構下，無法充分的發揮靈活協作的優勢，需要對中間層的建設規範與協作模式進行探索，在保障業務側業務需求的情況下，最大程度的保持數倉層級結構上的合理性，讓一線需求開發同學進行中間層多版本共建，并在規範上進行一些限制，可能會是我們後續繼續探索的方向，希望可以給大家在數倉建設方面一些啟發。