先總結下
unity catalog是databricks的數據治理解決方案，他提供了統一的元數據管理、權限訪問控制、數據審覈、數據質量、數據血緣、數據發現、數據共享等功能。
目前unity catalog在azure中國(Mooncake)還不能使用，如果要使用，需要單獨聯繫databricks客戶代表溝通。
數據血緣真的很不錯，如果是一個新的用戶，又是global的我強烈推薦您使用起來。
本人使用下來的感受：功能還是很強大，解決了以前權限集中管理、數據共享、數據血緣等問題，但是目前限制還是很多（看最後的限制一節），在新環境下使用是可以的，但是如果想從原來的workspace升級過來，尤其是使用了很多權限管理的、涉及ML、streaming的cluster就要詳細看看限制帶來的影響。權限切換成unity catalog也是要考慮的。如果數據治理有其它的產品了，只是想解決統一元數據的問題，我建議可以使用external hive metadata，後面我會寫一篇來介紹和實操。
如果不啓用憑據傳遞，目前還不能使用init script安裝一些擴展的python pkg或者jar包，Libraries也不行，原廠說未來會解決的。目前要不啓用憑據傳遞，要不就access mode改成Single user模式。如果一定要選一個我還是選擇啓用憑據傳遞，因爲Single user只能選擇的那個賬戶登錄才能使用cluster，顯然這不友好。憑據傳遞就要注意要去掉以前的那些配置spark config或者cluster config中的賬號配置或者服務主體訪問配置之類的纔行，還要創建一個組將用戶放入組，再給組添加到blob的對應角色（通常都是“存儲 Blob 數據參與者”）。
啓用憑據傳遞還有很多限制，使用前都要好好規劃下，一般都是用來做多用戶查詢比較合適，不適合ADF調度。使用 Azure Active Directory 憑據傳遞訪問 Azure Data Lake Storage - Azure Databricks | Microsoft Learn
爲什麼數據治理非常重要
數據治理是確保數據帶來價值並支持業務戰略的監督過程。數據治理封裝了爲安全管理組織內的數據資產而實現的策略和做法。隨着數據的數量和複雜性不斷增加，越來越多的組織正在關注數據治理以確保實現核心業務成果：
以一致和高質量的數據作爲分析和機器學習的基礎。
縮短獲得見解的時間。
數據民主化，即讓組織中的每個人都能夠做出數據驅動的決策。
對HIPAA、FedRAMP、GDPR 或 CCPA等行業法規的風險保障與合規性支持。
成本優化，例如通過阻止用戶啓動大型羣集並制定昂貴 GPU 實例的使用準則來實現。
良好的數據治理解決方案是什麼樣的？
數據驅動型公司通常會在lakehouse上構建用於分析的數據體系結構。lakehouse是一種體系結構，可直接在數據湖中存儲的大量數據上實現高效且安全的數據工程、機器學習、數據倉庫和商業智能。lakehouse的數據治理提供以下關鍵功能：
統一目錄：除了每個數據對象的元數據之外，統一目錄還存儲所有數據、ML模型和分析項目。統一目錄還混合了來自其他目錄的數據，例如現有的Hive元存儲。
統一數據訪問控制：跨所有數據資產和所有云的單個統一權限模型。這包括個人身份信息 (PII) 的基於屬性的訪問控制 (ABAC)。
數據審覈：數據訪問通過警報和監視功能進行集中審覈，從而促進問責。
數據質量管理：使用內置的質量控制、測試、監視和強制執行進行可靠的數據質量管理，從而確保下游BI、分析和機器學習工作負載獲得準確和有用的數據。
數據血緣：通過數據血緣，可獲得端到端的可見性，瞭解lakehouse中的數據如何從源流向使用端。
數據發現：利用簡單的數據發現功能，數據科學家、數據分析師和數據工程師可以快速發現和引用相關數據，並縮短實現價值的時間。
數據共享：數據可以跨雲和平臺共享。
數據治理和Azure Databricks
Azure Databricks 通過 Unity Catalog 和 Delta Sharing 提供集中的數據和 AI 治理。
Unity Catalog
Databricks Lakehouse 數據和 AI 的細化治理解決方案。 它通過提供一個集中管理和審覈數據訪問的位置，來幫助簡化數據的安全性和治理。
Delta Sharing
由 Databricks 開發的開放協議，用於與其他組織或組織內的其他團隊進行安全數據共享，而不論他們使用哪種計算平臺。
什麼是unity catalog
Unity Catalog，它是 Lakehouse 的 Azure Databricks 數據治理解決方案
在 Unity Catalog 中，管理員和數據專員在 Azure Databricks 帳戶中的所有工作區集中管理用戶及其對數據的訪問。 不同工作區中的用戶可以共享對相同數據的訪問權限，具體取決於 Unity Catalog 中集中授予的權限。
Unity Catalog 的主要功能包括：
定義一次，處處安全：Unity Catalog提供了一個單獨的地方來管理適用於所有工作區和人物角色的數據訪問策略。 符合標準的安全模型：Unity Catalog的安全模型基於標準ANSI SQL，允許管理員使用熟悉的語法在目錄、數據庫（也稱爲模式）、表和視圖級別授予現有數據湖的權限。 內置審計和血緣：Unity Catalog自動捕獲用戶級審計日誌，記錄對數據的訪問。Unity Catalog還捕獲血緣數據，跟蹤數據資產是如何在所有語言和人物角色中創建和使用的。 數據發現：Unity Catalog允許您標記和記錄數據資產，並提供搜索界面來幫助數據消費者查找數據。
Unity Catalog 對象模型
在 Unity Catalog 中，主要數據對象的層次結構從元存儲流向表：
Metastore：元數據的頂級容器。 每個元存儲都公開了一個用於組織數據的三級命名空間 (catalog.schema.table)。
Catalog：用於組織數據資產的對象層次結構的第一層。
Schema：也稱爲數據庫，是對象層次結構的第二層，包含表和視圖。
Table/View：對象層次結構的最底層，可以是外部表（存儲在所選雲存儲中的外部位置），也可以是託管表（存儲在你爲 Azure Databricks 專門創建的雲存儲中的存儲容器中）。 還可以從表中創建只讀視圖。
Metastores
元存儲是 Unity Catalog 中對象的頂級容器。它存儲數據資產（表和視圖），以及用於管理對數據資產的訪問的權限。 Databricks帳戶管理員可以爲他們操作的每個區域創建一個元存儲，並將其分配給同一區域的Databricks工作區。如果一個工作區想要使用 Unity Catalog，它必須附加 Unity Catalog 元存儲。
每個元存儲都在 Azure 帳戶的 Azure Data Lake Storage Gen2 容器中配置了一個根存儲位置。 此存儲位置用於元數據和託管表數據。
此元存儲與Databricks工作區中包含的Hive元存儲不同，後者尚未爲Unity Catalog啓用。如果您的工作空間包括一個遺留的Hive元存儲，那麼該元存儲中的數據仍將與Unity Catalog中定義的數據可以一起被訪問，只是單獨在一個名爲Hive_metastore的目錄中。請注意，hive_metastore目錄不由Unity catalog管理，也不受益於與Unity目錄中定義的目錄相同的功能集。
Catalog
目錄是 Unity Catalog 三級命名空間的第一層。 它用於組織數據資產。 用戶可以查看分配了USAGE數據權限的所有目錄。
Schema
架構（又稱數據庫）是 Unity Catalog 三級命名空間的第二層。 架構組織表和視圖。 若要訪問（或列出）架構中的表或視圖，用戶必須擁有對架構及其父目錄的 USAGE 數據權限，以及對錶或視圖的 SELECT 權限。
Table/View
位於 Unity Catalog 三級命名空間的第三層。 它包含數據行。 若要創建表，用戶必須對架構具有 CREATE 和 USAGE 權限，並對其父目錄具有 USAGE 權限。 若要查詢表，用戶必須對錶具有 SELECT 權限，並對其父架構和目錄具有 USAGE 權限。
表可以是託管表，也可以是外部表。
視圖是從元存儲中的一個或多個表和視圖創建的只讀對象。 可以從多個架構和目錄中的表和其他視圖創建視圖。 可以創建動態視圖以啓用行級和列級權限。
託管表
是在 Unity Catalog 中創建表的默認方式。 這些表存儲在創建元存儲時配置的根存儲位置。它們使用Delta表格式。
刪除託管表時，將於 30 天內從存儲位置上刪除其對應物理數據文件。
外部表
是其數據存儲在根存儲位置之外的表。 僅當需要直接訪問 Azure Databricks 羣集或 Databricks SQL 倉庫外部的數據時，才使用外部表。
刪除外部表時，Unity Catalog 不會刪除基礎數據。 你可以管理外部表的權限，並以與託管表相同的方式在查詢中使用它們。
支持的數據文件格式
託管表必須使用 delta 表格式。
外部表可以使用 delta、CSV、JSON、avro、parquet、ORC 或 text。
存儲憑據和外部位置
爲了管理對外部表的基礎雲存儲的訪問，Unity Catalog 引入了以下對象類型：
存儲憑據：封裝提供對雲存儲的訪問權限的長期憑據。 例如，可以訪問 Azure Data Lake Storage Gen2 容器的 Azure 託管標識。 外部位置：包含對存儲憑據和雲存儲路徑的引用。
Unity Catalog 的管理員角色
管理 Unity Catalog 需要以下管理員角色：
帳戶管理員（Account Admin）
可以管理標識、雲資源以及工作區和 Unity Catalog 元存儲的創建。
帳戶管理員可以爲 Unity Catalog 啓用工作區。 他們可以授予工作區和元存儲管理員權限。
元存儲管理員（Metastore Admin）
可以管理元存儲中所有安全對象的權限和所有權，例如誰可以創建目錄或查詢表。
創建 Unity Catalog 元存儲的帳戶管理員將成爲初始元存儲管理員。元存儲管理員還可以選擇將此角色委派給另一個用戶或組。 建議將元存儲管理員分配給組，在這種情況下，該組的任何成員都可以獲得元存儲管理員的權限。
工作區管理員
可以將用戶添加到 Azure Databricks 工作區，爲他們分配工作區管理員角色，並管理對工作區中對象和功能的訪問權限，例如創建羣集和更改作業所有權的能力。
也可以通過unity catalog來添加用戶、組對於workspace的訪問權限
Unity Catalog中的數據權限
在 Unity Catalog 中，默認情況下數據是安全的。 最初，用戶無權訪問元存儲中的數據。 訪問權限可由元存儲管理員、對象所有者或包含對象的目錄或架構的所有者授予。 Unity Catalog 中的安全對象是分層的，特權是向下繼承的。
你可以使用數據資源管理器、SQL 命令或 REST API 分配和撤銷權限。
Unity Catalog的集羣訪問模式
若要訪問 Unity Catalog 中的數據，必須爲羣集配置正確的訪問模式。 默認情況下，Unity Catalog 是安全的。 如果羣集未配置支持 Unity Catalog 的訪問模式之一（即“共享”或“單用戶”），則該羣集將無法訪問 Unity Catalog 中的數據。
Unity Catalog的數據血緣(lineage)
可以使用 Unity Catalog，通過以任何語言對 Azure Databricks 羣集或 SQL 倉庫執行的查詢來捕獲運行時數據血緣。血緣捕獲級別低至列，包括與查詢相關的筆記本、工作流和儀表板。
帳戶組(account groups)與本地工作區組(workspakce groups)之間的區別
雖然在工作區級別創建的用戶和服務主體會自動同步到帳戶，但在工作區級別創建的組不會。 相反，Azure Databricks 具有帳戶組和工作區本地組的概念。
帳戶組(account groups)
只能由帳戶管理員使用帳戶級接口創建。 帳戶管理員可以將這些組分配到工作區，並在工作區中爲它們配置數據訪問，前提是這些工作區使用聯合身份驗證。
工作區本地組(workspakce groups)
只能由工作區管理員使用工作區級接口創建。 這些組在工作區管理控制檯和帳戶控制檯的工作區“權限”選項卡上被標識爲“工作區本地”。 不能將工作區本地組分配給其他工作區，也不能向它們授予對 Unity Catalog 元存儲中數據的訪問權限。
Azure Databricks 建議使用帳戶組而不是工作區本地組。 必須啓用工作區的聯合身份驗證才能使用帳戶組。 如果在現有工作區中啓用聯合身份驗證，可以並行使用帳戶組和工作區本地組，但 Azure Databricks 建議將工作區本地組轉換爲帳戶組，以便利用通過 Unity Catalog 的集中式工作區分配和數據訪問管理
Unity Catalog 具有以下限制
如果羣集在低於 11.1 的 Databricks Runtime 版本上運行，則可能存在其他限制。 Unity Catalog 正式版依賴於使用 Databricks Runtime 11.1 或更高版本
Scala、R 和使用機器學習運行時的工作負載僅在使用單用戶訪問模式的羣集上受支持。 這些語言的工作負載不支持使用動態視圖（出於行級或列級安全性考慮）。
將 Unity Catalog 用作克隆的源或目標時，不支持淺表克隆。
Unity Catalog 表不支持 Bucket。 如果運行嘗試在 Unity Catalog 中創建 Bucket 表的命令，則會引發異常。
如果某些羣集訪問 Unity Catalog，而其他羣集不訪問，則從多個區域的工作區寫入相同的路徑或 Delta Lake 表可能會導致性能不可靠。
Delta 表支持對外部表進行分區，但對於任何其他數據源類型則不支持分區。
僅 Delta 表支持將 DataFrame 寫入 Unity Catalog 的覆蓋模式，不支持其他文件格式。 用戶必須對父架構擁有 CREATE 特權，並且必須是現有對象的所有者，或者對該對象擁有 MODIFY 特權。
流式處理目前具有以下限制：
使用共享訪問模式的羣集中不支持流式處理。 對於流式處理工作負載，必須使用單用戶訪問模式。
StreamingQueryListener 無法使用憑據或與 Unity Catalog 管理的對象交互。
Databricks Runtime 11.3 及更低版本不支持異步檢查點。
在 Databricks Runtime 11.2 及更低版本上，在通用羣集或作業羣集上持續超過 30 天的流式處理查詢將引發異常。 對於長時間運行的流式處理查詢，請配置自動作業重試 或使用 Databricks Runtime 11.3 及更高版本。
當前不支持從增量實時表管道引用 Unity Catalog 表。
單用戶羣集支持 Spark-submit 作業，但共享羣集則不支持此類作業。
共享羣集不支持 Python UDF。
以前在工作區中創建的組（即工作區級別的組）不能在 Unity Catalog GRANT 語句中使用。 這是爲了確保跨工作區的組視圖保持一致。 若要在 GRANT 語句中使用組，請在帳戶級別創建組，並更新主體或組管理的任何自動化（例如 SCIM、Okta 和 AAD 連接器以及 Terraform），用於引用帳戶終結點，而不是工作區終結點。
資源配額
Unity Catalog 對所有安全對象強制實施資源配額。限制在整個 Unity Catalog 中都遵循相同的分層組織。 如果預期超過這些資源限制，請聯繫 Azure Databricks 客戶代表。
下面的配額值是相對於 Unity Catalog 中的父對象表示的，例如一個schema下可以有10000個table
| Object | Parent | Value |
table |
schema (database) |
10000 |
| schema | catalog | 10000 |
| catalog | metastore | 1000 |
| storage credentials | metastore | 200 |
| external locations | metastore | 500 |
| functions | schema | 10000 |