看磚的建議使用的目錄。我本能現在主要結論有單獨為每個SDLC metastore環境(開發、測試、刺激)者優先。我認為如果遵循這種模式,這意味著由於電流的限製,一個單獨的帳戶需要為每一個環境,我們不希望在不同地區同一帳戶。這種方法所帶來的全部好處三級名稱空間你不放棄頂級的環境按這個“最佳實踐”
https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/best-practices,或者……
我的理由是:
- 通過奉獻一個目錄的環境中,你不能得到的全部利益三級名稱空間如一個源數據集:
目錄- bronze_systemA(一個目錄致力於源環境的metastore)
模式——生
模式的子對象
模式——historised(可選,如果你需要收集時間序列數據從源)
模式的子對象
模式,策劃(可選內容管理的源數據聚合在銀其他來源一樣。)
模式的子對象
比:
目錄- bronze_all_systems_dev(目錄獻給所有來源的環境metastore相同)
模式——systemA_raw
模式的子對象
模式——systemA_historised
模式的子對象
模式——systemA_curated
模式的子對象
更多的模式
”
”
”
- 平台上Beplay体育安卓版本部署從低到高環境就不會管理目錄名稱的改變,一個對象引用例如視圖的SQL定義:
……
從bronze_systemA。生。table_abc
比:
……
從bronze_all_systems_dev。systemA_raw。table_abc
當部署到更高的環境“_dev”需要改變。
我預計這可能也適用於其他對象,如:
工作流
DLT
工作
也許更多的…
- 外部連接在外部工具將為更高的環境隻有更改連接字符串而不是目錄的名字。
- 結合編目工作空間提供了一種幹淨的方法來管理數據訪問比櫻桃挑選與授權用戶模式到acl和相關聯的。
如果我錯過了一些和其他感興趣的觀點。
謝謝
