本文章翻譯及摘要自 – 使用 Copilot 深入瞭解 DAX 查詢檢視 |Microsoft Power BI 博客 |Microsoft Power BI

使用 Copilot 編寫和解釋 DAX 查詢，提高 DAX 查詢檢視的工作效率。現在，通過備受期待的 Copilot 在 DAX 查詢檢視中編寫和解釋 DAX 查詢的公共預覽版，使用 DAX 查詢變得更加容易！

讓我們看看 Copilot 如何提供説明。

• 在 DAX 查詢中鍵入您想要的內容，Copilot 可以為您編寫。例如，僅按國家/地區顯示銷售額，甚至按特定列（例如產品）顯示所有度量值。系統會自動添加註釋，以解釋生成的DAX查詢的每個部分，並註明它是在使用者提示下使用 Copilot 生成的。
• 使用 Copilot 調整現有 DAX 查詢。添加其他按列分組，或以其他方式調整已寫入的 DAX 查詢。這種方法的好處是，您將看到 Copilot 使用內聯差異編輯器所做的所有更改，因此您可以確切地知道添加、刪除或更新了哪些內容。
• 使用 Copilot 創建新度量。DAX 查詢包括用於定義度量值的語法，在 DAX 查詢中，可以在不修改語義模型的情況下運行此度量值。因此，您可以創建度量值並試用它們。最後，在 DAX 查詢檢視中，如果要通過添加 DAX 查詢中的度量值來修改語義模型，則可以使用 CodeLens 來“更新模型”。
• 在使用 Copilot 的 DAX 查詢檢視中瞭解有關 DAX 函數或主題的詳細資訊。這個解釋將嘗試用你的語義模型給你一個例子：留在你工作的地方的上下文中。您不再需要使用其他模型來查找搜尋引擎的答案！
• 解釋已使用 Copilot 編寫的 DAX 查詢。讓 Copilot 逐步解釋您正在查看的 DAX 查詢中發生的情況。您需要的地方就是您自己的幫手！

讓我們看看它的實際效果。

若要繼續操作，請使用 https://learn.microsoft.com/power-bi/create-reports/sample-regional-sales 上提供的 Power BI 區域銷售範例。下載 PBIX 後，我做的第一件事是刪除「篩選器」窗格中的相對月份篩選器，以查看報告中的數據。

在 DAX 查詢中鍵入您要的內容，Copilot 可以為您編寫。 在這裡，我想稍微探索一下產品類別，所以我將要求通過“顯示所有產品類別”來查看它們。

1. 轉到 Power BI Desktop 中的 DAX 查詢檢視
2. 調用 Copilot：CTRL + I，按兩下功能區中的 Copilot 按鈕或行號旁邊的 Copilot 按鈕。
3. 輸入「顯示所有產品類別

• 通過點擊 輸入 鍵或按下文字框右側的發送按鈕。然後它將更改為載入螢幕。
  

• 將生成DAX查詢！您暫時無法運行此查詢，在將來的更新中，當 Copilot 處於活動狀態時，將禁用“運行”按鈕。

按兩下保留它，然後可以運行查詢以查看結果。

真棒！現在，使用“數據”窗格/“模型資源管理器”，我可以看到模型中已創建的一堆度量值。讓我們看看這些產品類別的樣子。使用 Copilot 調整現有 DAX 查詢。

• 我選擇DAX查詢，然後再次調用 Copilot。這次我使用“按產品類別評估此模型中的所有度量”。
  

• 就這樣，Copilot 已將此模型中的所有 15 個度量添加到我的 DAX 查詢中！我什至得到了一個差異視圖，向我展示了 Copilot 在原始 DAX 查詢中更改了哪些內容。
  

再次，按下“保留它”，然後運行查詢以查看結果。

這為我節省了很多時間。以前，我只能看到，如果我轉到報表檢視並創建視覺物件，拖放所有欄位，或者在 DAX 查詢檢視中手動鍵入所有欄位。

現在，讓我們使用 Copilot 創建新度量。DAX 查詢支援創建度量值的功能，而無需將其添加到模型中。這種創建度量值的有用方法意味著我可以在添加到模型之前對其進行測試，還可以一次編寫多個度量值。現在，讓我們在 Copilot 的幫助下創建一個額外的度量。我想通過添加總收入的百分比來進一步分析按類別贏得的收入。

1. 我轉到一個新的查詢選項卡並調用 Copilot（CTRL+I 或編輯器或功能區中的 Copilot 按鈕）。這次我使用“為贏得的總收入的百分比創建一個度量，並按產品類別顯示贏得的收入”
2. 這次生成的 DAX 查詢是使用我想要創建的度量值的 DEFINE 塊生成的！

我再次按下「保留它並運行我的查詢」 以查看結果。

在 DAX 查詢檢視中，當在模型中尚不存在的 DAX 查詢中定義度量值時，有一個 CodeLens 選項，用於通過添加新度量值來更新模型，您可以在第 3 行和第 4 行之間看到該選項。就在我正在做的事情的背景下，我擁有完成工作所需的工具。

說到上下文，當我使用 Copilot 處於 DAX 查詢檢視時，我可以找到有關 DAX 函數或主題的更多資訊。剛剛生成的查詢使用了 ALL 函數。讓我們看看 Copilot 是否可以告訴我更多關於它的資訊。

1. 再次，我選擇剛剛創建的DAX查詢並調用 Copilot （CTRL + I）。這一次，我問，「告訴我更多關於 ALL DAX 函數的資訊」。
   

現在，我得到了 ALL DAX 函數的詳細說明，以及它在剛剛生成的 DAX 查詢中的使用方式！

現在，我更多地瞭解了DAX函數，我在哪裡使用它們，以及在我使用它們的模型的上下文中。我可以專注於我的工作，而不會被不同的網站或視頻分心來進一步解釋它，而且我不必聯繫可以向我解釋的朋友。

說到那個可以向我解釋 DAX 函數的朋友，也許他們之前寫了一個 DAX 查詢，現在我不太記得他們說它做了什麼。現在，我將進入最後一個示例：解釋已使用 Copilot 編寫的 DAX 查詢。

1. 我已經在 DAX 查詢選項卡上編寫了 DAX 查詢。在此示例中，我執行了快速查詢>在 Territories 表上顯示前 100 行。我選擇 DAX 查詢，調用 Copilot （CTRL + I） 並使用提示“此 DAX 查詢正在做什麼？
   

我還得到了 DAX 查詢的詳細說明，以及易於閱讀的格式中的每個部分。

同樣，我仍然處於我正在做的事情的上下文中，以及我正在使用的模型的上下文中。得到答案後，我可以繼續從我離開的地方繼續前進。

此功能應已在最新的 Power BI Desktop 版本（2024 年 3 月或更高版本）中啟用，但可以在“檔>設置和選項”>“選項”>“預覽功能”部分中打開和關閉。

使用 DAX 查詢檢視 Copilot 時需要注意的一些事項。 在公共預覽版期間，我們將進行更改並更新功能和UI，因此這些示例可能會為你返回不同的結果。

• 我們還在分析 Copilot 返回的 DAX 查詢，如果語法不正確，則執行一次重試。在重試也未通過解析器檢查的罕見情況下，我們仍將返回DAX查詢，但請注意存在問題。如果可以看到導致問題的原因，則可以鍵入新提示或調整 DAX 查詢。
• 如上所述，目前運行在您完成內聯 Copilot 之前不起作用，因此在將來的更新中，當 Copilot 處於活動狀態時，運行按鈕將被禁用。
• 我們還在努力解決的最後一個限制是，在你按兩下「保留」之前，內聯 Copilot 不知道前面的提示。例如，如果您要求它創建一個 DAX 查詢以顯示“按年份劃分的銷售額”，那麼它會生成 DAX 查詢，則不能簡單地鍵入“添加產品”來進一步調整它。現在，您必須按下「保留它」，選擇生成的 DAX 查詢，再次調用 Copilot，然後「添加產品」將按預期工作。

所以，今天就試試吧！分享您的反饋並查看下面提供的其他資源。

• 瞭解有關 DAX 查詢的更多資訊，請訪問 https://learn.microsoft.com/dax/dax-copilot 查看 Copilot
• 如需詳細瞭解 DAX 查詢檢視，請存取 https://learn.microsoft.com/power-bi/transform-model/dax-query-view
• 瞭解更多關於Fabric Copilot的資訊，請訪問 https://learn.microsoft.com/fabric/get-started/copilot-fabric-overview
• 詳細瞭解 Power BI 中的 Fabric Copilot，請訪問 https://learn.microsoft.com/power-bi/create-reports/copilot-introduction
• 觀看 Carly 和 Guy in a Cube 在 https://www.youtube.com/watch?v=0kE3TE34oLM 上使用 Copilot 演示 DAX 查詢檢視

本文翻譯及摘要自 – Power BI Desktop 中的 Copilot 窗格簡介（預覽版） |Microsoft Power BI 博客 |Microsoft Power BI

開始使用 Copilot

若要開始使用 Copilot，需要至少寫入分配給啟用 Copilot 的容量的單個工作區的訪問許可權，即付費 Fabric 容量（F64 或更高版本）或 Power BI Premium 容量（P1 或更高版本）。

選擇功能區中的 Copilot 圖示以在報表檢視中打開 Copilot 窗格。

• 首次選擇 Copilot 功能區按鈕時，將出現一個對話框，提示您選擇與 Copilot 相容的工作區。選擇分配給所需容量的任何工作區。

• 登陸 Copilot 窗格後，您會看到一張歡迎卡。選擇「開始使用」以開始與 Copilot 進行交互。

• 成功完成上述步驟后，系統不會要求您再次重複這些步驟。

Copilot for Desktop 功能概述

使用我們當前的預覽版，用戶可以在Power BI Desktop體驗中更快、更輕鬆地創建報表。您可以使用 Copilot 執行以下操作：

• 匯總 Power BI 語義模型 (Summarize a Power BI semantic model) – Copilot 將説明你輕鬆獲取 Power BI 語義模型中數據的摘要。此摘要可説明你更好地瞭解模型中的數據，確定重要的見解，並改善數據探索體驗。最終，這可以説明您構建更有意義的報告。

• 為報告建議內容 (Suggest content for a report) – Copilot 可以根據您的數據建議主題，説明您開始編寫新報告。通過直接在聊天中選擇此選項，Copilot 將評估數據並提供報告大綱，其中包含建議的頁面，您可以瀏覽並選擇為您創建。

如果您選擇第一頁旁邊的創建，Copilot 將為您創建該頁面。

• 創建報表頁 (Create a report page) – Copilot for Power BI 可以通過標識表、欄位、度量值和圖表來説明你創建報表頁，以説明你入門。通過向 Copilot 提供特定於您的資料的高級提示，它可以生成一個可自定義的報告頁面，您可以使用我們現有的編輯體驗對其進行修改，從而節省您開始的時間和精力。下面是一些説明您入門的高級提示示例：
  • 創建一個頁面，根據一段時間內的良好計數、拒絕計數和警報計數來評估不同班次的性能。
  • 創建一個頁面來分析生產線的效率和整體設備的效率。
  • 創建一個頁面來比較每種產品的成本和材料及其對生產的影響。

如何為您的組織啟用 Copilot

在企業開始使用 Microsoft Fabric 中的 Copilot 功能之前，請執行以下操作：

• 管理員需要在 Microsoft Fabric 中啟用 Copilot 並啟用租戶切換。
• 需要至少有一個工作區分配給啟用了副駕駛的容量，即付費 Fabric 容量（F64 或更高版本）或 Power BI Premium 容量（P1 或更高版本）。
• F64 或 P1 容量需要位於本文「結構區域可用性」中列出的區域之一。
• 如果租戶或容量位於美國或法國境外，則默認情況下會禁用 Copilot，除非 Fabric 租戶管理員在 Fabric 管理門戶中啟用“發送到 Azure OpenAI 的數據”可以在租戶的地理區域、合規性邊界或國家/地區雲實例租戶設置之外進行處理。
• 試用 SKU 不支援 Microsoft Fabric 中的 Copilot。僅支持付費 SKU（F64 或更高版本，或 P1 或更高版本）。

考慮

• 需要登錄才能開始使用Power BI Desktop報表檢視中的 Copilot 窗格。
• 如果您是首次在桌面報表檢視中使用 Copilot 的使用者，則在按下功能區上的 Copilot 按鈕後，系統將要求您選擇與 Copilot 相容的工作區。
  • 您在此處選擇的工作區不需要與要發佈報表的工作區相同。
  • 如果在未進行任何選擇的情況下取消或關閉工作區選取器對話方塊，則會看到以下錯誤消息。

• 與「數據」窗格或「可視化效果」窗格不同，您無法調整 Copilot 窗格的大小。
• Power BI 中的 Fabric Copilot 體驗是預覽體驗。
• 副駕駛回應是用人工智慧生成的，可能會犯錯誤，請始終檢查您的工作。
• 不斷進行更新。定期查看每月Power BI功能摘要博客，瞭解最新增強功能，隨時瞭解最新情況。

更多資訊

在文檔中詳細瞭解Power BI中的 Copilot。

本篇文章引用並翻譯自Carly Newsome 的 ”Introducing Public Preview Copilot for Power BI chat-based capabilities: summarize, inquire, analyze”，最初發表並公開於2024年2月26日 Microsoft Power BI Blog，以下翻譯僅供參考，如有歧義一律以原文為主。引用來源：Introducing Public Preview Copilot for Power BI chat-based capabilities: summarize, inquire, analyze | Microsoft Power BI Blog | Microsoft Power BI

您準備好踏上數據探索之旅了嗎？ Power BI 的 Copilot 窗格是數據探索和分析領域的終極伴侶！ Power BI 中的 Copilot 窗格現已在公開預覽中提供查看和編輯模式，並提供新功能。 您現在可以向 Copilot 詢問報告內容中的摘要、見解和答案。 在這篇部落格文中，我們將深入探討 Copilot 令人興奮的功能，揭示它如何在查看模式下輕鬆地幫助用戶從數據中提取寶貴的見解。

View 模式下的 Copilot

想像一下，在您流覽Power BI報表時，身邊有一位知識淵博的助手。這正是 Copilot 窗格在 Power BI 中提供的功能。在檢視模式下，使用者只需按兩下即可生成其報表內容的摘要。無休止的手動分析的日子已經一去不復返了 — Copilot 簡化了該流程，提供了簡明扼要的概述，突顯出視覺化中的關鍵趨勢、模式和見解。借助此功能，業務用戶可以獲得對報告頁面的概覽，並對頁面上可視化的數據提出問題，提升了他們的數據探索體驗，使他們能夠進一步深入挖掘。此功能非常強大，因為它將典型的查看體驗提升為分析體驗。註：此功能在編輯模式下也可用。

客製化指導觸手可及

如前所述，Copilot 不僅僅停留在提供報告內容的概述和見解上——通過可訂製的請求，Copilot 會根據您的特定需求訂製其説明，輕鬆指導您完成探索過程。無論您是不確定從哪裡開始，還是正在尋求更深入的見解，Copilot 都能為您提供説明。您可以從開箱即用的提示開始，例如：

• 創建洞察的項目列表
• 對本頁面的視覺進行摘要
• 為本報告撰寫執行摘要

或者，您可以開始使用訂制的請求，以深入且更細緻地探索您數據的關鍵部分，並提供量身訂制的見解和答案。下面是一些自定義請求範例，供您開始使用（請注意，這些請求應該與您正在查看的報告中的數據相關）：

• 此頁面上有哪些關鍵的銷售見解？

• 有哪些有趣的客戶群？

• 產品類型和收入之間有什麼關係？

Copilot 將掃描報告頁面的視覺效果，並以自然語言回答您的請求，使報告分析比以往任何時候都更容易。從發現見解到突出顯示關鍵銷售指標，Copilot 的提示為無與倫比的數據發現鋪平了道路。您甚至可以將 Copilot 文字複製並粘貼到電子郵件、Power Point 或 Teams 討論串中，讓每個人都瞭解最新情況。

釋放問題的力量

Copilot 消費模式的另一個令人興奮的方面是它能夠即時回答您的問題。需要知道哪個團隊在銷售中佔主導地位，或者哪個產品擁有最高的獲利率？只需詢問，Copilot 就會為您提供量身訂製的簡單回覆。Copilot 的與眾不同之處在於它擅長在報告中引用特定的視覺對象，從而比以往任何時候都更容易理解驅動每個見解和答案的基礎數據。以下是一些來自真實範例的範例：

• 收入最高的產品是什麼？
• 2021年的總銷售額是多少？
• 平均停留時間是多少？

賦予數據探索力量

在充斥著數據的世界中，提取有意義的見解的能力是無價的。Copilot 輔助探索使用戶能夠成為數據的主人，為他們提供所需的工具，以便更快地理解他們的報告，並即時回答他們的問題。無論您是經驗豐富的分析師還是新手探索者，Copilot 的直觀特性都使數據探索變得輕而易舉。有關此功能的更多詳細資訊，請參閱我們的文檔。 要查看我們的其他 Copilot 功能，例如 Copilot 報告頁面創建（可在編輯模式下使用），請前往此處。

考慮事項：

• Microsoft Fabric 中的 Copilot 不支持試用版 SKU。僅支持付費 SKU（F64 或更高版本，或者 P1 或更高版本）。 在開始使用 Copilot 之前，管理員需要啟用租戶切換。有關詳細資訊，請參閱 **Copilot 租戶設置一文 F64 或 P1 容量需要位於本文結構區域可用性**中列出的某一區域。如果不是，則無法使用 Copilot。 這些功能在編輯模式和桌面版中也可用。Power BI 中的 Fabric Copilot 體驗是預覽體驗。此體驗為公開預覽階段。 我們會不斷進行更新，因此請期待改進。 Copilot 的回應是由人工智能生成的，可能會犯錯誤，請始終檢查您的工作。

本篇文章引用並翻譯自 Chen May Yee 的 ”India’s schoolteachers are drafting better lesson plans faster, thanks to a copilot ”，最初發表並公開於2024年2月8日 Microsoft Blog Source Asia，以下翻譯僅供參考，如有歧義一律以原文為主。引用來源：https://news.microsoft.com/source/asia/features/indias-schoolteachers-are-drafting-better-lesson-plans-faster-thanks-to-a-copilot/

印度卡納塔克邦卡納卡普拉——在這所被椰子樹環繞的五間教室的鄉村學校裡，老師 Ravindra K. Nagaiah 今天給他的七年級科學課帶來了一個驚喜。

當天的主題是「酸、鹼和鹽」。除了通常供應的石蕊試紙、鹽酸和小蘇打外，Ravindra 還用芙蓉花和檸檬製作了小燒杯。學生們圍在桌子旁，觀看一名學生將檸檬與芙蓉汁混合。溶液變為綠色，表示酸度。另一名學生將小蘇打和芙蓉汁混合在一起，變成粉紅色。

孩子們，誰知道芙蓉汁是一種天然的pH指示劑？

Ravindra 從 Shiksha Copilot那裡得到了這項活動的想法，Shiksha 是一個生成式 AI 數位助理，可以在幾分鐘內制定課程計劃——包括活動、視頻和測驗。該軟體正在與非營利性 Sikshana 基金會合作開發，並由卡納塔克邦 30 所學校的 30 名教師用英語和當地卡納達語進行測試，教師們報告了令人鼓舞的結果。

老師 Ravindra K. Nagaiah 展示了他如何在 Shiksha copilot 上生成課程計劃。

Shiksha copilot 是Project VeLLM的一部分，VeLLM是Microsoft Research India的平臺，用於開發專門的生成式AI copilot，從教師到農民再到小企業主，每個人都可以使用，而 Shiksha 在梵語中意為教育。

它基於 Microsoft Azure OpenAI 服務構建，並與學校課程和學習目標相結合。Azure 認知服務用於引入教科書中的文本，包括內容的組織方式。

借助Shiksha copilot，研究人員希望印度那些工作繁忙的政府學校教師能很快得到休息，而他們的學生也能享受更生動、更豐富的課程。

從老師的角度來看，最大的好處是節省了準備上課的時間。拉文德拉（Ravindra）在文卡塔拉亞納多迪（Venkatarayanadoddi）政府高級小學教科學和數學已有15年，他說他過去常常花40分鐘在紙上寫一份教案。“現在我們可以在10分鐘內上一堂新課，”他說。

這所學校只有5名教師和69名學生，他們的父母大多以種植芒果或養蠶為生，資源可能很匱乏。因此，Ravindra 根據需要修改了計劃。如果他沒有建議的活動所需的材料，他會向 Shiksha copilot 詢問另一個想法，並說明他手頭擁有什麼。如果視頻太長，他會要求一個較短的視頻。他還可以修改作業和提出問題。

拉文德拉說：“用粉筆和黑板的老方法已經不夠了。由Shiksha節省下的時間，我正在和孩子們一起度過。”

大班授課

制定課程計劃一直是一項艱巨的工作。教師從政府課程（通常是教科書）開始，然後根據學校的資源、學習者的構成以及教師自己的能力和經驗創建課程。如果這還不夠難，現在試著吸引一代人被社交媒體和在線視頻所影響的注意力。

在這裡，教師們還要努力應對比其他地方更大的班級規模。根據聯合國教科文組織 2020 年的數據，在印度小學，每 33 名學生就有一名教師，而世界平均水準為 23 名。在中國，這一比例為1：16；在巴西，這一比例為1：20；北美為1：14。

根據總部位於班加羅爾的Sikshana Foundation的數據，在印度，隨著人們從農村遷移到城市，城市班級規模可能會激增至40至80名學生。

多年來，這導致即使收入微薄的人們也不得不借錢送孩子上私立學校，Sikshana的首席執行官Prasanna Vadayar表示。

Vadayar 在卡納塔克邦長大，後來移居美國，在德克薩斯 A&M 大學攻讀計算機工程碩士學位，然後在德克薩斯州奧斯汀創辦了一家成功的軟體企業。2007年，他在休假期間回到印度領導Sikshana。他還在這裡。

Sikshana 基金會首席執行官 Prasanna Vadayar 在班加羅爾的辦公室。照片由Selvaprakash Lakshmanan為Microsoft拍攝。

Sikshana 基金會的使命是通過永久提高教育品質來扭轉公立學校的外流趨勢。“當人們問我為什麼加入Sikshana時，”Vadayar說，“我告訴他們關閉它’。

Sikshana 以其低成本、有效的干預措施而聞名，政府可以採取這些干預措施。它現在在印度的六個邦工作，覆蓋 50,000 所學校，影響 300 萬學生。

例如，它的Prerana項目為學生提供了成為同伴領袖的機會，並獎勵學生每天取得的小成就，從定期出勤到在學術和體育方面取得好成績。學生們會得到閃亮的彩色箔星星，他們可以收集並安全地固定在他們的衣服上，以及代表所學的彩色貼紙。孩子們得到了激勵，家長們可以很容易地看到他們的孩子取得了什麼成就。

Prerana 於 2018 年被卡納塔克邦政府採用，並在全州推廣。

幾年前，Vadayar 注意到教師們在準備課程時陷入了困境，並試圖找到解決方案，但放棄了，等待合適的技術。2023 年初，當微軟印度研究院帶來Shiksha copilot時，瓦達亞記得當時的想法是：“驚人！”

面向大眾的生成式 AI

在Microsoft，Siksana找到了一個合作夥伴，並找到了它所尋求的技術解決方案。在Sikshana，Microsoft找到了一條在學校測試解決方案的途徑，並希望大規模採用，可能在印度以外的地方。

“這是一個全球性問題，”Vadayar說。“學習生態系統無法跟上課堂上的技術，教師也無法跟上他們的學習能力。孩子們期待更多的東西。

Akshay Nambi和Tanuja Ganu是Microsoft Research India的Shiksha copilot研究員，並在其他專案上密切合作。

（左至右）Microsoft Research India的研究人員Akshay Nambi和Tanuja Ganu在班加羅爾的Sikshana Foundation辦公室外擺姿勢拍照。照片由Selvaprakash Lakshmanan為Microsoft拍攝。

“一年前，我們想看看如何應用GenAI來解決人口規模的現實世界問題，”Ganu說。Nambi補充道：「Shiksha copilot是一種研究工具，我們可以了解使用者如何使用它們，並獲得用戶反饋，以改善整體copilot體驗。

生成式 AI 工具建立在大型語言模型 （LLM） 之上，這些模型可合成大量數據以生成文本、代碼、圖像等。但結果可能並不完美。近幾個月來，研究人員試圖通過添加特定領域知識（在這種情況下，是卡納塔克邦的教育課程）來提高準確性。

Nambi 說，從該知識庫中檢索資訊可以降低出錯的風險。然後將該資訊帶入 LLM，從而生成課程計劃。copilot是多模態的，這意味著它包括圖像和視頻以及文本，並從互聯網上繪製公開可用的視頻。最後，Azure OpenAI 服務內容篩選器和內置提示可阻止不適當的內容，例如種族或種姓相關問題。Nambi說，自始至終，老師都是“迴圈中的專家”，學生與Shiksha copilot沒有直接聯繫。

2023 年 12 月底，Sikshana 基金會對教師們進行了調查，了解他們對 Shiksha 的體驗。5人來自城市學校，25人來自農村學校。大多數人用卡納達語教學，只有六人用英語教學。

絕大多數受訪者表示，Shiksha copilot將他們的課程計劃準備時間從一個小時或更長時間縮短到5到15分鐘之間，90%的受訪者表示他們只需要對生成的計劃進行微小的修改，如果需要的話。每位教師平均每周生成三到四個課程計劃。

“每一堂課都變得生動起來”

對於試用該系統的一小部分教師來說，它已經產生了影響。

位於班加羅爾郊區內拉曼加拉鎮的政府高級小學Basavanahalli是一棟L形建築，漆成橙色和石灰綠色，有一個塵土飛揚的校園，一至八年級的學生聚集和玩耍。學校有13名教師，438名學生，平均班級規模為30人。

科學和數學老師Mahalakshmi Ashok一直在測試Shiksha copilot，她說這讓她有時間在課堂上添加活動。

坐在教師會議室裡，牆上掛滿了卡納塔克邦名人的畫像，Mahalakshmi打開了她的筆記型電腦，啟動了Shiksha copilot。

Mahalakshmi Ashok 是一名公立學校教師兼代理校長，在印度卡納塔克邦Basavanahalli的政府高級小學積極參與Shiksha copilot。照片由Selvaprakash Lakshmanan為Microsoft拍攝。

第一頁是一系列帶有下拉功能表的欄位：選擇教育委員會、媒介（目前為英語或卡納達語，其他當地語言即將推出）、班級、學期、學科（目前為英語、數學、社會科學和科學）和主題。

她選擇「科學」，輸入「循環系統」，然後選擇「持續時間：40 分鐘」。。Shiksha copilot會立即生成課程計劃，並可選擇生成 PDF、PowerPoint 幻燈片或講義，以及建議的活動、視頻和評估。在每個小節之後，可以選擇三個表情符號來評價生成的內容。

Mahalakshmi說，過去，在教授心血管系統時，她可能會在黑板上畫出一顆心臟的圖，並討論它的功能。最近，她嘗試了Shiksha copilot建議的一項新活動。每個學生將手指放在手腕上以定位他們的脈搏並測量每分鐘的心跳次數。他們比較了結果，並討論了為什麼有些人的心跳可能比其他人更快或更慢。

一個copilot建議的活動——血型實驗室——是不可能的。但另一項活動——測量血壓——可能是可能的。Mahalakshmi認為她下次可能會從家裡帶一個血壓袖帶給孩子們試用。

“顯然，他們喜歡這些實驗。”Mahalakshmi說，他已經教了20年，也是現任代理校長。每個班級都變得熱鬧起來，學習變得更容易了。

印度卡納塔克邦巴薩瓦納哈利市政府高級小學的政府教師兼代理校長馬哈拉克希米·阿肖克（Mahalakshmi Ashok）演示了Shiksha copilot建議的一個科學實驗。照片由Selvaprakash Lakshmanan為Microsoft拍攝。

在最近一堂關於「物質分離」的科學課上，她帶來了一小袋大米、小麥、沙子和水來說明這一課。6年級的學生穿著全白制服，頭髮編成辮子的女孩已經知道這些概念。當摩訶拉希什米走過場時，他們齊聲喊道：“手工採摘！挑選！沉澱！過濾！“等等。

當被問及她以前是否以這種方式教過書時，她說「沒有」，歪著頭補充道，「因為我有更多的時間，不是嗎？」

超越課程計劃

下一階段是在3月份的學年結束前將試點擴大到100所學校，Sikshana基金會首席專案官Smitha Venkatesh說。然後從 4 月開始，該團隊將開始策劃評分最高的課程計劃，以便教師可以修改現有計劃，而不必創建新計劃。

Smitha在美國學習和工作後於11年前加入Sikshana並表示，她已經開始了解教師面臨的各種挑戰。

Smitha Venkatesh，印度卡納塔克邦卡納卡普拉市 Venkatarayanadoddi 政府高等小學 Sikshana 基金會首席專案官。照片由Selvaprakash Lakshmanan為Microsoft拍攝。

“人們認為公立學校不好，”她說。“但我們承認，教師所做的不僅僅是教學。不僅要確保學生學習，還要確保他們得到制服，確保他們吃飯，進行人口普查等。Shiksha copilot可以幫助教師在時間限提供更好的服務。。

Smitha說，也許在未來，Shiksha copilot還可以協助完成其他任務，例如安排課程或跟蹤學習。也許它也可以幫助那些正在掙扎的學生。

“人工智能是令人興奮的，是的，”她說。“但歸根結底，它能幫助教師，也能幫助孩子嗎？”

上圖：Nagaiah Kanakapura地區政府高級初級學校Venkatarayanadoddi的7年級科學課上，教師Ravindra K. Nagaiah和學生們。照片由Selvaprakash Lakshmanan為Microsoft拍攝。

本篇文章引用並翻譯自 Judson Althoff 的 ”Embracing AI Transformation: How customers and partners are driving pragmatic innovation to achieve business outcomes with the Microsoft Cloud”，最初發表並公開於2024年1月29日 Official Microsoft Blog，以下翻譯僅供參考，如有歧義一律以原文為主。引用來源： https://blogs.microsoft.com/blog/2024/01/29/embracing-ai-transformation-how-customers-and-partners-are-driving-pragmatic-innovation-to-achieve-business-outcomes-with-the-microsoft-cloud/

過去的一年是技術領域最激動人心的一年，隨著生成式人工智慧的出現，各地的領導者都在考慮它為他們的組織帶來的可能性。許多人認識到它的價值並渴望繼續創新，而另一些人則受到它所釋放的啟發並正在尋求採用它的方法。在 Microsoft，我們專注於開發基於務實創新的負責任的 AI 戰略，並為我們的客戶實現 AI 轉型。當我與客戶和合作夥伴討論他們所看到的結果時，並根據Microsoft的生成式AI功能合理化這些結果，我們已經確定了組織增強其AI轉型的四個機會領域：豐富員工體驗，重塑客戶參與，重塑業務流程和彎曲創新曲線.有了這些作為基礎，就更容易看到如何將務實的人工智慧創新帶入生活，我為我們與世界各地的客戶和合作夥伴產生的影響感到自豪。從與沃達豐(Walmart)一起為歐洲和非洲的數百萬人開發以客戶為中心的人工智慧和雲服務，到與沃爾瑪一起為客戶和員工提供生成式人工智慧功能，我期待著我們將在未來一年幫助您實現目標。

電通在Microsoft Copilot的支援下推動品牌的創造力和增長。

利用 Copilot 技術豐富員工體驗並塑造未來的工作

拜耳(Bayer)員工正在通過Copilot for Microsoft 365更好地協作全球研究專案，並節省日常任務的時間，而芬蘭公司Elisa正在幫助財務，銷售和客戶服務方面的知識工作者簡化日常任務。Banreservas正在提高員工的工作效率並加強決策，而香港最大的運輸公司——國泰航空和港鐵——正在簡化工作流程，改善溝通，並減少耗時的行政任務。在專業服務方面，畢馬威的員工生產力提高了 50%，電通每天為數百名員工節省了長達 30 分鐘的創意可視化流程，安永 (EY)則讓生成報告和近乎即時地獲取見解變得更加容易。在馬來西亞，金融服務機構PNB正在節省員工搜索檔和電子郵件的時間，而大馬銀行的員工正在提高他們的工作質量和影響力。在Hargreaves Lansdown，財務顧問正在使用Copilot for Microsoft 365和Teams來提高工作效率並使會議更具包容性。埃維諾正在使用 Copilot for Dynamics 365 説明銷售人員節省更新聯繫人記錄和匯總電子郵件線程的時間，而 HSO Group、Vixxo 和 9altitudes 正在簡化現場和服務團隊的工作。

組織正在創建自己的生成式 AI 助手，以幫助員工改善客戶服務。

利用生成式 AI 重塑客戶互動，以提供更大的價值和更高的滿意度

MECOMS使公用事業客戶能夠提出問題並獲得有關如何使用Microsoft Fabric和Copilot在其Power Pages門戶上降低功耗的建議。施耐德電氣構建了資源顧問副駕駛，為客戶提供增強的數據分析、可視化、決策支援和性能優化。加州州立大學聖馬科斯分校正在尋找方法來更好地瞭解和個人化學生旅程，同時使用 Dynamics 365 Customer Insights 和 Copilot for Dynamics 365 推動與家長和校友的互動。借助Azure OpenAI服務，德科集團正在加強其服務和解決方案，使員工做好準備，因為生成式人工智慧重塑了工作力，UiPath已經通過更高效的運營説明其一家保險客戶節省了90,000多個小時，而普羅維登斯已經為臨床醫生開發了一種解決方案，使患者資訊的回應速度提高了35%。組織正在構建生成式 AI 助手，以幫助員工節省時間、改善客戶服務並專注於更複雜的工作，包括 Domino’s、LAQO 和 OCBC。在推出個人化客戶服務的副駕駛后的幾周內，Atento 將客戶滿意度提高了 30%，同時減少了近 20% 的操作錯誤，總部位於土耳其的 Setur 正在使用聊天機器人個人化旅行計劃，為其 60,000 名日常使用者定製多種語言的回應。在時尚行業，Coats Digital 在六周內推出了一個 AI 助手，讓客戶更容易入職。總部位於希臘的 ERGO Insurance 與 EBO 合作，通過其虛擬代理提供 24/7 全天候個性化協助，H&R Block 推出了 AI Tax Assist，幫助個人和小企業主自信地報稅和管理稅款，同時節省成本。

諾和諾德正在構建 GitHub Copilot 集成，以減少重複的研究和工程任務。

重塑業務流程，提高效率，提高開發人員創造力，刺激 AI 創新

西門子構建了自己的工業copilot，以簡化設計工程師和一線工作人員的虛擬協作，縮短模擬時間，並將任務從數周縮短到幾分鐘。在 Neudesic 的説明下，漢諾威研究公司設計了一個定製的人工智慧研究工具，以簡化工作流程並將識別見解的速度提高 10 倍。借助 Microsoft Fabric，倫敦證券交易所集團和 Milliman 等組織正在重塑團隊從數據洞察中創造更多價值的方式，而蔡司正在簡化分析工作流程，以幫助團隊做出更多以客戶為中心的決策。沃爾沃集團通過推出使用 Azure AI 構建的自定義解決方案來簡化文檔處理，從而節省了 10,000 多個手動小時。通過集成 GitHub Copilot，Carlsberg 顯著提高了其開發團隊的工作效率;Hover、SPH Media、Doctolib 和 CloudZero 在敏捷和安全的環境中改進了他們的工作流程。Mastery Logistics Systems 和 Novo Nordisk 正在使用 GitHub Copilot 為開發人員自動執行重複的編碼任務，而 Intertech 則將其與 Azure OpenAI 服務配對，以提高編碼準確性並將每日電子郵件減少 50%。瑞士人工智慧驅動型公司 Unique AG 正在説明金融行業客戶減少管理工作、加快現有流程並改善 IT 支援;普華永道正在通過 Azure OpenAI 服務簡化其審計流程並提高客戶的透明度。通過利用Power Platform（包括 AI 和 Copilot 功能），Epiq 實現了員工流程的自動化，每年節省超過 500,000 美元的成本和每月 2,000 小時的工作時間，PG&E 正在解決高達 40% 的服務台需求，每年節省超過 100 萬美元，Nsure 正在構建自動化，將手動處理時間減少 60% 以上，成本減少 50%。將安全性放在首位，韋萊韜悅正在使用 Microsoft Copilot for Security 使網路團隊能夠用自然語言提問來加速其威脅搜尋能力，而 LTIMindtree 正計劃使用它來減少培訓時間並加強安全分析師的專業知識。

VinBrain正在利用Microsoft的尖端AI技術來改變越南的醫療保健。

通過差異化的 AI 產品扭轉各行各業的創新曲線

為了提高災難回應效率，非營利組織 Team Rubicon 在 Copilot for Dynamics 365 的説明下，在正確的位置快速識別和吸引合適的志願者。總部位於荷蘭的 TomTom 正在開發一種先進的人工智慧語音助手，幫助駕駛員完成導航和溫度控制等任務，從而將生成式 AI 的優勢帶入全球汽車行業。在越南，VinBrain開發了該國首批全面的人工智慧Copilot，以支援醫療專業人員增強篩查和檢測流程，並鼓勵更有意義的醫患互動。羅克韋爾自動化正在通過 Azure OpenAI 服務提供業界首創的功能，以加快構建工業自動化系統的客戶的上市時間。為了實現 AI 民主化並覆蓋數百萬使用者，Perplexity.AI 使用 Azure AI Studio 在六個月內將其對話式答案引擎推向市場。印度最大的在線時尚零售商Myntra正在通過使用生成式人工智慧來幫助購物者根據場合確定他們應該穿什麼，從而解決該行業面臨的開放式搜索問題。在日本，愛信公司開發了一款生成式人工智慧應用程式，為聾啞人或聽力障礙者提供導航、通信和翻譯等任務;總部位於加拿大的初創公司 Natural Reader 透過使用 Azure AI 提高 AI 語音品質，讓有學習差異的學生更容易在旅途中接受教育。為了解決最複雜的工程挑戰之一——半導體的設計流程——Synopsys 正在引入生成式 AI 的強大功能，説明工程團隊加快產品上市時間。

隨著組織繼續擁抱 AI 轉型，他們必須明確如何最好地應用 AI 來滿足其最緊迫的業務需求。Microsoft 致力於幫助我們的客戶和合作夥伴加速務實的 AI 創新，我對擺在我們面前的機會感到興奮，這些機會可以豐富員工體驗、重塑客戶參與、重塑業務流程並扭轉創新曲線。作為首選的技術合作夥伴，從我們差異化的Copilot能力到我們無與倫比的合作夥伴生態系統以及與客戶的獨特共同創新努力，我們將繼續為您的成功成果服務。我們還致力於維護我們通過合作方式、負責任的人工智慧解決方案以及保護您的數據、隱私和智慧財產權的承諾建立的信任。我們相信，這個人工智慧創新的時代使我們能夠比以往任何時候都更忠實地履行我們的使命，我期待著與您一起繼續這段旅程，幫助您取得更多成就。

本篇文章引用並翻譯自 Marc Bushong 的 ”Lakehouse vs Data Warehouse vs Real-Time Analytics/KQL Database: Deep Dive into Use Cases, Differences, and Architecture Designs”，最初發表並公開於2023年12月13日 Microsoft Fabric Updates Blog，以下翻譯僅供參考，如有歧義一律以原文為主。引用來源：https://blog.fabric.microsoft.com/zh-tw/blog/lakehouse-vs-data-warehouse-deep-dive-into-use-cases-differences-and-architecture-designs?ft=All

隨著 Microsoft Fabric 在 Ignite 上的全面發佈，有很多問題圍繞著每個元件的功能，但更重要的是，哪些架構設計和解決方案最適合 Fabric 中的分析。具體而言，用於分析數據倉庫/報告的數據資產將如何改變或與現有設計不同，以及如何選擇正確的前進路徑。本文將重點幫助您了解數據倉庫、數據湖倉一體和 KQL 資料庫、結構解決方案設計、倉庫/湖倉一體/即時分析用例之間的差異，並充分利用數據倉庫、數據湖倉一體和即時分析/KQL 資料庫。

本文涵蓋的主題：

• 對 Microsoft Fabric 的進階描述，以建立對體系結構/相關元件的基本瞭解。
• 數據倉庫、數據湖倉一體、即時分析/KQL 資料庫和 OneLake 的進階說明。
• 數據倉庫、數據湖倉一體和即時分析/KQL 資料庫之間的區別。
• 數據倉庫、數據湖倉一體、即時分析/KQL 資料庫的用例，或共同使用時的情況。
• 用於使用數據倉庫、數據湖倉一體和即時分析/KQL 資料庫的體系結構設計。

什麼是 Microsoft Fabric？

Microsoft Fabric 是企業級的一體化分析解決方案，涵蓋從數據移動到數據科學、即時分析和商業智慧的所有內容。它提供一整套服務，包括數據湖、數據工程和數據集成，所有都集中在一個地方。

Microsoft Fabric 建立在 SaaS 基礎之上，因為它將 Power BI、Azure Synapse 和 Azure 數據工廠中的新元件和現有元件整合到單個集成環境中。可以通過數據工程、數據工廠、數據倉庫、數據科學、即時分析和Power BI等體驗在這些元件上進行交互/構建。在一個共用平台上擁有這些元件/體驗的優點是：

• 行業內廣泛的深度集成分析。
• 在熟悉且易於學習的體驗之間共享體驗。
• 開發人員可以輕鬆訪問和重用所有資產。
• 一個統一的數據湖，允許您在使用首選分析工具的同時將數據保留在原處。
• 跨所有體驗的集中管理和治理。

儘管 Fabric 的元件使用“Synapse”作為數據工程、數據倉庫、數據科學和即時分析的前綴 → 但這與 Azure Synapse Analytics 不同。由於命名，這可能會導致混淆。該技術建立在 Synapse 現有技術之上，但架構 / 功能有很多重大變化 / 改進，使其成為革命性的版本。具有 Azure Synapse Analytics（專用池、無伺服器池、Spark 池）經驗的用戶會發現 Microsoft 結構元件的概念很熟悉，但技術/ 功能已得到顯著改進和優化。

什麼是 OneLake、數據湖倉一體、數據倉庫和即時分析/KQL 資料庫？

OneLake

OneLake 是數據湖，是構建所有 Fabric 服務的基礎。OneLake 基於 ADLS （Azure Data Lake Storage） Gen2 和服務構建，作為租戶範圍的數據存儲，可以支援任何類型的檔案（結構化或非結構化檔）。每個 Fabric 租戶都會自動預配 OneLake，無需設置或管理額外的資源。所有 Fabric 數據項（如數據倉庫和湖倉一體）都會以 Delta Parquet 格式自動將其數據存儲在 OneLake 中。

它是所有開發人員（專業人員和公民）的單一統一存儲系統，集中且統一地執行所有合規性、安全性和策略。OneLake 消除了跨組織的數據孤島，並且無需物理複製或移動數據供不同的團隊/引擎使用，無論數據是在 OneLake 中還是存儲在快捷方式相容位置。您可以將 OneLake 視為用於組織數據的 OneDrive。

數據湖倉一體(Data Lakehouse)

Microsoft Fabric Lakehouse 是一個數據體系結構平台，用於在單個位置以開放格式存儲、管理和分析結構化和非結構化數據。默認檔案格式為 delta parquet。您可以將資料儲存在自動預配的 2 個物理位置：即檔案（非託管）或表格（託管Delta表）中。

• 表格
  • 用於在Spark中託管所有格式的表格（CSV、Parquet 或 Delta）的託管區域。所有表格（無論是自動創建的還是顯式創建的）都將被識別為 Lakehouse 中的表格。此外，任何 Delta 表格（即具有基於文件的事務日誌的 Parquet 數據檔）也被識別為表格。
• 檔案
  • 用於以任何檔案格式存儲數據的非託管區域。存儲在此區域中的任何 Delta 檔都不會自動識別為表。如果要在非託管區域中的 Delta Lake 資料夾上創建表格，則需要顯式創建快捷方式或外部表格，其位置指向 Spark 中包含 Delta Lake 檔的非託管資料夾。

Lakehouse 允許您通過 Spark 計算執行轉換，或使用 SQL 端點來分析/瀏覽數據。Data Lakehouse 的默認檔格式是 delta parquet，最適合分析工作負載性能。

數據湖倉一體並不是 Microsoft Fabric 的新概念或專有概念，因為它們在使用推薦的medallion架構的分析工作負載體系結構中非常常見（稍後會詳細介紹）。數據湖倉一體的相同概念也存在於 Microsoft Fabric 中，具有一些新功能，並與 Microsoft Fabric 內部的元件以及 Microsoft Fabric 外部的其他一些服務無縫集成。包括提供一份數據副本並在其他團隊之間共用、且零數據重複的能力。

數據倉庫(Data Warehouse)

Microsoft Fabric 數據倉庫是基於企業級分散式處理引擎構建的以湖為中心的數據倉庫。與其他數據倉庫解決方案相比，Fabric Data Warehouse 的主要優勢之一是，由於倉庫使用 OneLake 作為其存儲，因此無需從數據倉庫複製數據供其他計算引擎或團隊使用，以 delta parquet 格式存儲在 Microsoft OneLake 中的數據的一個副本。因此，您可以進行跨資料庫查詢，無縫地利用不同的來源（OneLake 或其他通過快捷方式的來源）的數據，而且沒有數據重複。

數據倉庫的核心是具有 Delta 表格和 TDS 端點的 SQL MPP 引擎（大規模並行處理引擎），它將為您提供完整的 T-SQL DDL 和 DML 支援（檢查特定功能/特性的可用性）。計算是一種無伺服器基礎結構，允許通過動態資源分配進行無限擴展，在不涉及物理預配的情況下即時擴展或縮減，並在幾毫秒內將物理計算資源分配作業。

即時分析/KQL 資料庫(Real-Time Analytics/KQL Database)

Real-Time Analytics(即時分析) 是一個完全託管的大數據分析平台，針對流式處理和時間序列數據進行了優化。它利用具有卓越性能的查詢語言和引擎來搜索結構化、半結構化和非結構化數據。Real-Time Analytics 與整套 Fabric 產品完全集成，適用於數據載入、數據轉換和高級可視化方案。就像其他 Microsoft Fabric 元件一樣，即時分析是一種 SaaS 體驗。

借助 Microsoft Fabric 中的即時分析，您可以使組織能夠專注於和擴展其分析解決方案，同時使數據民主化，以滿足公民數據科學家和高級數據工程師的需求。即時分析在企業領域的許多場景中都變得至關重要，例如網路安全、資產跟蹤和管理、預測性維護、供應鏈優化、客戶體驗、能源管理、庫存管理、品質控制、環境監控、車隊管理以及健康和安全。這是通過降低數據集成的複雜性來實現的。您可以在幾秒鐘內獲得數據洞察的快速訪問，實現對任何數據源或格式的自動數據流、索引和分區（任何數據源或格式）以及按需查詢生成和可視化。即時分析可讓您專注於分析解決方案，隨著數據和查詢需求的增長，通過該服務無縫擴展。

閱讀更多有關即時分析的獨特之處，並了解即時分析的優勢請參考： 是什麼讓即時分析與眾不同？

即時分析使用 KQL 資料庫作為數據存儲。本文稍後將介紹即時分析解決方案的體系結構/元件，但現在我將簡要概述 KQL 資料庫。KQL 代表 Kusto 查詢語言，它是一種查詢語言，用於與位於 KQL 資料庫中的數據進行交互。KQL 資料庫可用作適用於 Fabric Real-Time Analytics 和 Azure 資料資源管理器的通用術語，因為它指的是使用 KQL 與之交互的資料庫/存儲。

即時分析的核心是與 Azure 數據資源管理員共用相同的核心引擎和相同的核心功能，只是管理行為不同。（Azure 數據資源管理器是 PaaS 產品/服務，即時分析是 SaaS 產品/服務）。因此，如果您熟悉 Azure 數據資源管理器，則該知識可轉換為 Fabric 即時分析，但在管理方面存在一些差異。

Azure 數據資源管理器為引入和查詢遙測數據、日誌、事件、跟蹤和時序數據提供了無與倫比的性能。它具有優化的儲存格式和索引，並使用高級數據統計資訊實現高效的查詢規劃和即時編譯的查詢執行。Azure 資料資源管理器提供數據快取、文字索引、行存儲、列壓縮、分散式數據查詢、存儲和計算分離。

請參閱此文檔，查看即時分析和 Azure 數據資源管理器之間的功能/管理差異：即時分析和 Azure 數據資源管理器之間的差異 – Microsoft 結構 | Microsoft 學習

數據湖倉一體、數據倉庫和即時分析/KQL 資料庫之間有什麼區別？

現在，我們已經對 Microsoft Fabric 是什麼有了基本的且深度的瞭解，特別是 OneLake、Data Lakehouse、數據倉庫和即時分析/KQL 資料庫。現在是時候分解數據湖倉一體、數據倉庫和即時分析/KQL 資料庫之間的差異了，以便更好地瞭解每個用例並幫助我們設計解決方案。

首先，我們將重點介紹數據湖倉一體和數據倉庫之間的比較，然後再比較即時分析/KQL 資料庫。

Data Lakehouse 和 Data Warehouse 都是開放數據格式——delta parquet、以湖為中心的方法，並且具有一些交叉功能，但有一些差異，我已將其細分為幾類。

• 如何訪問/處理數據
  • 正在使用的端點（詳見下文）
• 存儲/使用的數據類型
• 開發人員技能組合

數據湖倉一體和數據倉庫的端點

Lakehouse 和 Data Warehouse 之間有 3 個不同的端點。

• Spark 運行時/庫的 Lakehouse 端點
• Lakehouse 的 SQL Analytics 端點
• 數據倉庫端點

Spark 運行時/庫的 Lakehouse 端點

若要使用 Spark 與 Lakehouse 檔/表進行交互以進行分析、轉換或處理，需要連接到獨立於 SQL Analytics 端點的 Lakehouse 端點。就像 Fabric 外部用於與檔/delta表交互的標準方法一樣，您將使用 URL、ABFS 路徑或直接在資源管理員中掛載 Lakehouse 進行連接。使用 Spark 可以使用所選的 Scala、PySpark、Spark SQL 或 R 執行寫入操作。但是，如果要使用 T-SQL，則需要使用 SQL Analytics 端點，在其中只能執行只讀操作。

Lakehouse 的 SQL Analytics 端點

此端點為 Lakehouse Delta表提供基於 SQL 的體驗。SQL Analytics 端點提供了使用 SQL 在 Lakehouse 中交互、查詢和提供數據的功能。此體驗是唯讀的，僅適用於delta表。這將是 Lakehouse 的「表(Tables)」部分，而「檔(Files)」部分無法通過 SQL 終端讀取/發現。SQL Analytics 端點允許使用 T-SQL 分析delta表、保存函數、生成檢視以及應用 SQL 物件級安全性。它使數據工程師能夠在 Lakehouse 中的物理數據之上構建關係層，並使用 SQL 連接字串將其公開給分析和報告工具。

創建指向delta表存儲的 Lakehouse 時，會自動創建 SQL Analytics 端點。每個 Lakehouse 只有一個 SQL 端點，每個工作區可以有多個 Lakehouse。這意味著工作區中的 SQL 端點數量與湖倉一體的數量相匹配。

請務必注意，delta表（以及delta表中的數據）的創建/修改必須使用 Apache Spark 完成，通過 Lakehouse 中的 Spark 創建的delta表可通過端點自動發現。如果存在使用Spark代碼創建的外部delta表，則它們對SQL分析端點不可見，直到創建外部dekta表的快捷方式才能使其可見。

可以設置物件級安全性，以便使用 SQL 分析端點存取資料。這些安全規則僅適用於通過 SQL 分析端點訪問數據。這意味著，如果要確保無法通過其他方式（通過不同的端點或直接）訪問數據，則必須設置工作區角色和許可權。

可以通過提供身份驗證和端點連接字串，在 Fabric 外部以及使用 SSMS 或 Azure Data Studio 等工具連接到此端點，就像任何其他 SQL Server 連接一樣。

在後台，SQL 分析端點使用與倉庫端點相同的引擎來提供高性能、低延遲的 SQL 查詢。這意味著它也是一個 TDS 端點，只是與數據倉庫端點相比，它對 DML/DDL 功能和 T-SQL 圖面有限制。

請務必注意，MSFT 文件會將 Lakehouse 的 SQL Analytics 端點描述為數據倉庫。儘管根據上下文，這可能是正確的，但我不會將其稱為數據倉庫，以避免在討論 Synapse 數據倉庫時產生混淆。我將通過 SQL Analytics 端點或 Lakehouse 上的 SQL 查詢顯式引用它。

在我的 Fabric 工作區中，我有一個名為“BronzeLakehouse”的 Lakehouse。在那個湖屋中，我有 2 個與我的湖屋相關的專案（不同的項目類型）。SQL Analytics 端點（紅色）和 Lakehouse 端點（綠色）

使用「Lakehouse」端點可以看到什麼？檔案（紅色）和delta表（綠色）。您可以通過下拉選項（顯示展開）在右上角查看目前正在查看的端點

使用 Lakehouse 的 SQL Analytics 端點可以看到什麼？僅限delta表。

數據倉庫端點(Data Warehouse Endpoint)

Synapse 數據倉庫或倉庫端點以「傳統」SQL 數據倉庫方式運行。這意味著此端點支援完整的 T-SQL 功能，例如企業數據倉庫。與 SQL Analytics 端點不同，數據倉庫端點提供：

• 對delta表的讀取和寫入支援
  • 可以使用spark或T-SQL讀取數據
  • 只能使用 T-SQL 寫入數據
• 完整的 DML 和 DDL T-SQL 支援
  • 包括通過 TSQL 或 UI 進行數據引入、建模和開發
  • 您可以完全控制建立表、載入和轉換
  • 可以使用 COPY INTO、管道、數據流或使用 CREATE TABLE AS SELECT （CTAS）、INSERT..INTO 或 SELECT..INTO 進行跨資料庫引入。
• 完整的 ACID 兼容性 並支援交易
  • Lakehouse 僅對 Delta Tables 提供 ACID 合規性支援。因此，湖倉一體中可能存在不支援 ACID 比較的檔/數據。
• 多表事務支援

將完整的讀/寫功能與跨資料庫引入功能相結合，可以無縫地從多個數據倉庫或湖倉一體進行引入。將數據引入數據倉庫時，它將創建一個存儲在 OneLake 中的Delta表。

下面是一個關係圖，可幫助解釋 SQL Analytics 端點和數據倉庫端點之間的區別。

用於將數據從 Lakehouse 載入資料倉庫的跨資料庫查詢範例。

倉庫表『holiday.Warehouse_Holiday_Clean“是創建並使用 CTAS 語句，將”SilverLakehouse.dbo.Holiday_Clean“ delta表作為來源載入。

KQL 資料庫端點(KQL Database Endpoint)

KQL 資料庫不是一個新概念，也不像 Lakehouse 或數據倉庫的端點那樣複雜。我們將討論將即時分析/KQL 資料庫與其他產品區分開來的用例和其他因素，但本部分針對的是端點的差異。

讀/寫功能沒有限制，具體取決於語言或端點，因為 KQL 資料庫沒有不同的端點。您將能夠使用 KQL、Spark、連接器生態系統（無代碼）或 T-SQL 進行讀/寫。根據您要執行的確切操作，可能會有更好的語言或流程，您必須根據具體情況進行評估。

讀/寫功能的限制將應用於帳戶許可權。KQL 資料庫提供僅應用行級別安全性的功能，該安全性是特定於帳戶的，而不是特定於計算引擎的，如數據倉庫和 Lakehouse。

下面是我想強調的使用 KQL 資料庫的一些主要好處：

• 管理無限量的數據，從千兆位元組到拍兆位元組不等，併發查詢和併發使用者具有無限的擴充性。
• 內置的自動縮放功能可調整資源以匹配緩存、記憶體、CPU 使用率和引入等工作負載因素，從而優化性能並最大限度地降低成本。
• 無需轉換即可查詢原始數據，具有高性能、極低的響應時間，同時使用各種可用的運算符。排隊和流式引入有幾秒鐘的延遲。
• 自動對攝取的數據進行索引和分區，以進一步支援無限規模的高性能，而無需像傳統 RDMS 那樣進行管理。
• 任何數據格式都可以通過分析查詢（如自由文本和 JSON 結構）進行攝取/分析。
• 支援高級分析，例如時間序列本機元素以及完整的地理空間存儲和查詢功能

還有一個稱為「一個邏輯副本(One Logical Copy)」的預覽功能。這使您能夠通過在 OneLake 中啟用資料可用性來創建 KQL 資料庫數據的一個邏輯副本。在 OneLake 中啟用 KQL 資料庫的數據可用性意味著可以在 KQL 資料庫中以高性能和低延遲查詢數據，並通過其他構造引擎（如 Power BI、倉庫、湖倉一體、筆記本等中的 Direct Lake 模式）以 Delta Lake 格式查詢相同的數據。

一個邏輯副本（預覽版） – Microsoft Fabric |Microsoft 學習

存儲的數據類型

Data Lakehouse、Data Warehouse 和 KQL 資料庫之間的另一個區別是存儲的數據類型及其組織方式。

在數據湖倉一體中：

• 您可以儲存非結構化、半結構化或結構化數據。
• 數據按資料夾和檔、湖資料庫和delta表進行組織。

在資料主目錄中：

• 您可以儲存結構化數據。
• 數據按資料庫、架構和表（後台的delta表）進行組織

在 KQL 資料庫中：

• 您可以儲存非結構化、半結構化或結構化數據。
• 數據按資料庫、架構和表進行組織。

開發人員技能組合

在許多架構和設計會議中，由於團隊成員的技能組合，正確的服務/模式可能不是最適合您的團隊的。例如，在Spark中轉換數據可能是性能、成本等方面的最佳設計選擇。但是，團隊中沒有人具有Spark或除T-SQL以外的任何語言的經驗或知識。這將影響您的設計，以考慮開發人員技能的可用性/用途。

在數據湖倉一體中：

• 主要技能是Spark（Scala，PySpark，Spark SQL，R）
  • 這適用於寫入操作和大多數工作負載
• 借助 Lakehouse 上的 SQL Analytics 端點，可以提供 T-SQL 的輔助技能，用於唯讀操作或分析
• 與數據的交互將主要通過Spark筆記本和Spark作業定義進行。

在資料主目錄中：

• 主要技能是 SQL
  • 這包括 T-SQL 和相關的 SQL 知識，如數據建模、DDL/DML 語句、SQL MPP 引擎理解、SQL DBA 知識等。
• 與數據的交互將通過 SQL 腳本進行。
  • 存儲過程、檢視、即席查詢等。
  • 可以使用 Spark 從數據倉庫讀取數據，但不會將其用於使用/提供。

在 KQL 資料庫中：

• 主要技能是 KQL、SQL 或無代碼。
  • 您將能夠使用 KQL、T-SQL、Spark 和 Power BI 讀取數據
  • 您將能夠使用 KQL、Spark 和連接器生態系統寫入數據。
• 與數據的交互將直接通過 KQL 查詢集或 KQL 資料庫進行。

下面是一個圖表，用於比較數據倉庫、Lakehouse 和 KQL 資料庫。您可以在此處查看完整文件：結構決策指南 – 選擇數據存儲 – Microsoft Fabric |Microsoft 學習

數據倉庫、數據湖倉一體和即時分析/KQL 資料庫的用例

現在，對數據倉庫、數據湖倉一體和即時分析/KQL 資料庫之間的差異有了更深入的瞭解，是時候查看一些用例以確定要使用的選項了。有很多具體的用例，不可能涵蓋所有可能的場景，所以我將介紹一些常見場景。

若要確定是僅單獨使用 Lakehouse、單獨使用數據倉庫、單獨使用 KQL 資料庫，還是將它們混合在一起，通常取決於解決方案的這些要求。

• 數據將如何被消耗/使用
• 應用程式或 ETL/ELT 的要求
• 開發人員的技能組合
  • 包括數據工程師、數據科學家、公民開發者和專業開發者

數據將如何被消耗/使用

在設計解決方案時，瞭解您正在使用的數據將如何被消耗非常重要。Lakehouse、Data Warehouse 和 KQL Database 在向使用者提供數據方面具有很大的靈活性/重疊能力。但是，具體需求/細微差別可能因解決方案而異，因此下面是數據的不同使用方法的一些常見示例：

• 通過Power BI報表/儀錶板使用的用戶。
  • Lakehouse、Data Warehouse 和 KQL Database 都可以為 Power BI 提供服務。
  • Lakehouse 和 Data Warehouse 都可以為具有相同直接湖模式語義模型功能的 Power BI 提供服務。（此處未詳細討論直接湖模式。或者通過 Lakehouse 的 SQL Analytics 端點或數據倉庫端點使用導入或 DirectQuery 模式。
    • KQL 資料庫只能在啟用預覽功能「一個邏輯副本」時為具有直接湖模式的 Power BI 提供服務。稍後會詳細介紹。
• 使用即席 T-SQL 進行分析/探索的商業用戶
  • Lakehouse、Data Warehouse 和 KQL Database 都提供 SQL 讀取功能。其他因素將決定哪種解決方案是最好的。
• 允許用戶直接在檔上使用 Spark，包括非結構化、半結構化和結構化數據以及所有文件類型（而不僅僅是 Delta表或 Delta parquet）。這可以適用於企業用戶、數據科學家等。
  • Lakehouse 是正確的用例，因為可以存儲任何檔格式，並且 Spark 可用於與這些文件進行交互。數據倉庫允許Spark唯讀取表，這可能就足夠了，但通常不會將數據倉庫用於此方案。
  • KQL 資料庫能夠使用 Spark 功能與表進行交互以進行讀取和寫入，但它將取決於其他因素，例如用例、ETL/ELT 或應用程式的需求、數據大小等，以確定是否應在湖倉一體上使用 KQL。
• 混合使用：來自執行轉換工作/數據建模的數據工程團隊的 PySpark 技能，以及使用只讀 T-SQL 查詢的企業用戶/開發人員，無論是直接對 Fabric 中的其他湖倉一體/倉庫進行臨時查詢，還是在 Power BI 中。
  • Lakehouse 最適合這種情況。由於企業用戶使用只讀 T-SQL，因此他們可以使用湖倉一體上的 SQL Analytics 端點進行使用。數據工程團隊可以繼續在Spark中處理數據。
  • 除非有其他要求/需求會強制使用數據倉庫，例如將倉庫端點用於第三方報告工具或分析查詢，或者需要僅在 Data Warehouse 中可用的功能，否則無需使用 Data Warehouse
    • 例如，通過 SQL 的多表事務或 DML/DDL 功能
  • 從技術上講，在此方案中，可以將 KQL 資料庫用於即時分析解決方案，因為在執行轉換時，可以通過 KQL/SQL 查詢或在 Power BI 中提供/使用數據。並且可以在數據倉庫、湖倉一體和其他 KQL 資料庫之間交叉查詢（通過啟用了“一個邏輯副本”的快捷方式） KQL 資料庫滿足此方案的要求，但是我會先從湖倉一體開始，然後根據解決方案的其他要求確定。在後面的部分我們會對此進行更多介紹。
    • 例如，需要具有高性能和低延遲（不是“近即時”）的即時分析或時間序列和地理空間存儲/查詢支援。

每個資料庫、數據倉庫、Lakehouse、KQL、SQL Server、Cosmos DB 等都針對不同的讀/寫大小和工作負載進行了優化。因此，瞭解這些優化是確定哪種解決方案最適合滿足需求的關鍵。

應用程式或 ETL/ELT 的要求

對於不同的應用程式和 ETL/ELT，可能存在需要 Lakehouse、數據倉庫或即時分析/KQL 資料庫的特定功能的解決方案需求。同樣，每個解決方案的細微差別都不可能涵蓋所有方案，但我將介紹應用程式或 ETL/ELT 工作負載的 4 個常見要求。

ACID交易合規性

ACID 代表：

• 原子性(Atomicity)
  • 交易中的每個語句都被視為一個單元。要麼執行整個事務，要麼不執行任何事務。
    • 例如：銀行轉帳從您的帳戶中扣除資金並將其轉入另一個帳戶。如果沒有原子性，您可以從您的帳戶中扣除資金，而不會到達另一個帳戶。
• 一致性(Consistency)
  • 事務一致性。要求在事務中所做的更改與任何約束一致。防止任何這些錯誤或損壞進入您的數據。
    • 例如：您嘗試從 ATM 中提取的錢比您帳戶中的錢多。交易失敗，因為它阻止透支，違反了約束。
• 隔離性(Isolation)
  • 所有事務都是隔離運行的，不會相互干擾。如果有多個事務對同一源應用更改，則它們將逐個發生。
    • 例如：您的銀行帳戶中有 1,000 美元。您同時發送 2 次提款，每次 500 美元。如果這些同時發生，那麼您的結餘將為 500 美元。但是在隔離的情況下，結餘將為0美元，因為每筆交易都會影響另一筆交易。
• 耐久性(Durability)
  • 確保對數據所做的更改保持不變。無論是寫入資料庫、保存檔等，只是在崩潰或系統故障時這些更改都是可用的。

為什麼ACID很重要？

• 符合 ACID 標準，絕不允許數據處於不一致狀態，從而實現最佳的數據完整性和可靠性。

Lakehouse 和 Data Warehouse 中的 ACID 合規性是什麼樣子的？

• Lakehouse ACID 合規性
  • ACID 事務功能僅適用於 Delta 格式的表。
  • 這意味著您必須利用託管Delta表才能具有 ACID 功能。
    • Delta表使用 ACID 事務的基於文件的事務日誌擴展 parquet 檔。
  • 可以使用 Spark 或 SQL 引擎對Delta表進行交互/獲得 ACID 支援。
  • 非Delta表，也就是所有其他檔，在 Lakehouse 中將沒有 ACID 支援。
• 數據倉庫 ACID 合規性
  • 數據倉庫中所有表都完全支援 ACID 事務。
  • 所有表都是以 delta parquet 檔形式存儲在 OneLake 中的Delta表，其中包含基於文件的事務日誌。
• KQL 資料庫 ACID 合規性
  • KQL 資料庫不支援 ACID 事務。
    • KQL 資料庫是支持最終一致性的分散式系統，不支援事務。
      • 可以使用“更新策略”將引入更新應用於多個表，但這不是ACID，因為這存在限制，並且它們不能用作支援ACID合規性的事務。

多表事務(Multi-table Transactions)

多表事務是一種將對多個表的更改分組到單個事務中的方法。這允許您控制讀取和寫入查詢的提交或回滾，並使用事務修改存儲在表中的數據以將更改組合在一起。

例如：您更改了影響三個表 （dbo.ItemStock、dbo.PurchaseOrderHistory，dbo。OrderShippingInfo）。您可以對取消訂單的交易進行分組，以便更改將應用於所有 3 個表或根本不應用。因此，當用戶查詢任何表時，他們將看到所有表的一致更改，而不是矛盾/不正確的數據。

多表事務僅在數據倉庫中受支援。

Lakehouse 目前不支援此功能。

KQL 資料庫不支援事務，它是一個支持最終一致性的分散式系統。KQL 資料庫可以通過「更新策略」實現類似於多表事務的更新行為，但這不符合 ACID 標準，也無法保證執行順序/持久性。

動態數據遮罩(Dynamic Data Masking)

動態數據遮罩通過將敏感數據遮罩給非特權使用者來限制敏感數據洩露。它使管理員能夠指定要顯示的敏感數據量，從而有助於防止未經授權查看敏感數據，同時將對應用程式層的影響降至最低。

• 通常對企業用戶遮罩的一些敏感字段是 SSN、電子郵件、帳號、PHI 等。

Lakehouse 數據遮罩：

• 僅通過 Lakehouse 的 SQL 分析端點支援。除 SQL（例如 Spark）以外的檔或引擎將無法使用動態數據遮罩。
• 還可以應用物件和行級別安全性（以及 DDM），但只能通過 SQL Analytics 端點。
  • Spark 引擎將無法使用物件和行級別安全性。
  • 將來可能會通過OneLake Security改變這種情況。可以在此處查看有關公共路線圖的更多資訊。Microsoft Fabric 中 OneLake 的新增功能和計劃內容 – Microsoft Fabric |Microsoft 學習

數據倉庫數據遮罩：

• 完全支援。
• 除了動態數據遮罩外，數據倉庫還支援 SQL 粒度許可權、列和行級別安全性以及審核日誌。

KQL 資料庫數據遮罩：

• 無。
• 您可以對表應用行級別安全性或受限視圖訪問策略，也可以嘗試創建僅公開選定列的視圖或函數，但不支援遮罩或加密敏感數據。

即時分析

即時分析在收集數據后能夠立即處理、查看、分析和測量數據的一般說明。這意味著數據必須以極低的延遲（例如在幾秒鐘內）可供使用。該解決方案必須能夠處理大量數據，同時提供幾秒鐘的收集延遲。您要考慮的大小將以 PB 或更高為單位，數據格式差異很大。即時分析的一些一般用例涉及安全審計日誌、庫存數據、從生產車間資產到送貨卡車的供應鏈資訊以及任何行業的流式智慧設備資訊。

數據倉庫：

• 數據倉庫不是即時分析的理想解決方案。
• 數據大小、格式和延遲要求並不能使數據倉庫成為即時分析解決方案的選項。
• 但是，您可以將數據從即時分析解決方案引入數據倉庫以進行進一步分析，也可以與現有數據相結合以獲得更多價值。

湖倉一體：

• Lakehouse 可能是即時分析的一個選項，但如果可能的話，這將取決於解決方案的要求。Lakehouse可能是一個選擇，但它不是首選。
• 如果您每秒有數百萬筆交易，而每筆交易只有 100-500 行數據，那麼 Lakehouse 可能能夠滿足即時分析解決方案的需求。因為這符合 Lakehouse 解決方案的潛在性能/延遲預期。但是，如果每秒數百萬個事務每個事務有數十萬或數百萬行，那麼 Lakehouse 將無法處理這個問題，並且不是一個可能的選擇。
• 這將取決於數據的併發性和大小，以確定湖倉一體是否能夠實現低延遲和高性能要求。

KQL 資料庫：

• KQL 資料庫是即時分析解決方案的最佳選擇。
• KQL 資料庫針對超大型寫入和高併發性進行了優化。每秒數百萬個事務，每個事務中有數十萬行的示例將能夠使用 KQL 資料庫以高性能方式進行處理。
• 通過對 KQL 資料庫中的表/資料進行自動索引和分區，以及對所有數據格式的支援，這是處理任何即時分析解決方案的最佳解決方案。

每個資料庫、數據倉庫、Lakehouse、KQL、SQL Server、Cosmos DB 等都針對不同的讀/寫大小和工作負載進行了優化。因此，瞭解這些優化是確定哪種解決方案最適合滿足需求的關鍵。

您的應用程式或 ETL/ELT 的要求摘要

這些只是分析解決方案中常見需求的 4 個示例，這些需求將決定使用哪個元件：Lakehouse、Data Warehouse 或 KQL Database。

對於 ACID 相容性，您需要查看解決方案的要求/其他因素，因為在數據倉庫和 Lakehouse 中使用 ACID 功能；需要創建一個Delta表（Lakehouse 和 Data Warehouse 中的所有表都是Delta表）。這意味著可能需要將文件轉換為Delta表，或者直接載入到兩個元件的Delta表中。您將無法使用 KQL 資料庫。因此，選擇將取決於用例的其他因素，例如技能集、其他要求和消耗。

對於多表事務，需要使用湖倉一體上的數據倉庫和 KQL 資料庫來執行這些事務。瞭解這一點可以在為使用者設計解決方案/功能時為您節省大量麻煩和時間。

對於動態數據遮罩，可以使用數據倉庫或 Lakehouse 和 KQL 資料庫來實現此功能。如果對 Lakehouse 使用 SQL 端點，如果您需要檔具有動態數據遮罩或其他引擎（如 Spark），那麼您當然可以嘗試設計您的 Lakehouse 以刪除敏感列並向業務使用者公開不同版本的數據，但是根據規模的不同，這很快就會變得難以管理。數據倉庫為業務使用者提供了一站式服務，並通過動態數據遮罩保護敏感資訊，而無需擔心檔或其他引擎的使用。

對於即時分析，需要使用 KQL 資料庫。根據確切的要求，您也許可以使用 Lakehouse，但 KQL 資料庫是針對此確切方案進行優化/設計的。與往常一樣，您當然可以嘗試在 Lakehouse 中設計解決方案，但 KQL 資料庫對於此方案的性能更高，並且具有許多現成的優化。Data Warehouse 不是即時分析解決方案的好選擇。

開發人員的技能組合

用例決策的最後一個主要類別是開發人員的技能組合。這包括公民開發人員、專業開發人員、數據工程師、數據科學家等。當我為客戶提供架構決策建議時，一個重要的資訊是瞭解處理數據的個人的技能。對於團隊來說，性能和成本的最佳服務/設計可能不是最佳解決方案，因為沒有人知道如何開發它。

• 這個概念的一個荒謬的例子是，如果您試圖讓您的團隊單獨駕駛一輛車從 A 點到 B 點。您決定到達那裡的最快方法是僅為您的團隊提供手動變速器車輛（變速桿），因為它們比自動變速器車輛更快。如果您知道如何駕駛變速桿，那麼您很快就會遇到問題。但是，如果您的整個團隊都不知道如何駕駛變速桿，那麼他們將需要更長的時間/在使用手動變速器時遇到問題。客觀地說，提供自動變速器而不是手動變速器可能不是最佳選擇，但它可能是您團隊的最佳選擇。

Lakehouse、Data Warehouse 和 KQL 資料庫所使用的技能集和開發人員類型的高階細分。

• Lakehouse
  • 具有 Spark 知識和偏好的開發人員/使用者。直接使用 ETL/ELT 或其他工作負載的檔和/或Delta表。這包括使用 Spark 筆記本和 Spark 作業定義。
    • 通常是數據工程師、數據科學家和專業開發人員
  • 僅具有 T-SQL 知識的開發人員/使用者，只能讀取為他們特選的數據（通過 SQL Analytics 端點在Delta表中）以供使用或分析。
    • 通常是公民開發人員和專業開發人員
• 數據倉庫
  • 在構建 ETL/ELT 時具有 T-SQL 知識和偏好的開發人員/使用者。處理存儲過程、函數和 DBA 任務的數據倉庫專家。
    • 通常是數據倉庫工程師和 SQL 開發人員
  • 僅具有 T-SQL 知識的開發人員/使用者，只能讀取為他們策劃的數據以供使用或分析。
    • 通常是公民開發人員和專業開發人員
• KQL 資料庫
  • 具有 KQL 知識和偏好的開發人員/使用者。您將能夠使用 Spark 或 T-SQL 語句與數據進行交互（讀/寫），但 KQL 是目前與數據互動的最佳選擇。
    • 開發人員/用戶可以通過Power BI 連接器或不同的檢視、查詢或函數作為源使用。

用例總結

在查看了一些常規用例以及您可能具有的不同要求后，應該更清楚何時使用 Lakehouse、數據倉庫和 KQL 資料庫。通常，這些決定很複雜，需要考慮很多因素。首先；分析數據的使用/使用方式、應用程式或 ETL/ELT 的要求以及開發人員/使用者的技能組合可以更快地做出設計/架構決策。如果沒有，那麼至少您會找出其他需要詢問的問題。

數據湖倉一體、數據倉庫和即時分析/KQL 資料庫的解決方案架構/設計

瞭解 Data Lakehouse、Data Warehouse 和 KQL 資料庫之間的功能、特性支援、用例和差異將有助於您建構不同類型的解決方案構建體系架構。我們將結合到目前為止所學到的所有內容，並將其應用於不同工作負載/方案的體系結構。

這些示例並非旨在作為參考體系結構或跨所有方案的特定最佳實踐的建議，因為我們僅介紹了一些需要考慮的複雜性。

目標是演示僅使用 Lakehouse、僅使用數據倉庫、僅使用即時分析/KQL 資料庫、一起使用 Lakehouse 和數據倉庫以及同時使用即時分析/KQL 資料庫和 Lakehouse 或數據倉庫的體系結構，以便根據您的條件更好地瞭解不同的設計模式。

解決方案體系結構/設計將分為以下幾類：

• Medallion 架構概念審查
• Lakehouse 示例架構
• 數據倉庫示例體系結構
• Lakehouse 和 Data Warehouse 組合架構
• 即時分析/KQL 資料庫體系結構

獎章建築概念審查(Medallion Architecture Concept Review)

Medallion架構並非 Fabric 獨有，它已成為雲中湖倉一體/數據倉庫架構的最佳實踐/非常常見。它仍然是 Fabric 的最佳實踐。因此，在深入研究使用它的特定架構之前，我們回顧一下Medallion架構的基礎知識非常重要。Medallion體系結構是 Fabric 中推薦的方法。

Medallion架構描述了一系列數據層，這些數據層表示存儲在湖倉一體中的數據品質。獎章架構由三個不同的層或區域組成：青銅（原始）、銀（已驗證）和黃金（豐富）。每一層都表示存儲在湖倉一體中的數據質量，級別越高表示品質越高。

區域的名稱，例如銀區域的「已驗證」 ，可能因來源和設計而異，但概念是相同的。

青銅

原始區域，第一層以原始格式存儲源數據。

通常在此層幾乎沒有使用者訪問許可權。

銀

豐富區，經過清理和標準化的原始數據。數據現在由行和列構成，並且可以與整個企業中的其他源集成。

白銀級別的轉換應側重於數據品質和一致性，而不是數據建模。

金

策劃區，最後一層來自銀層。這些數據經過優化，「業務就緒」 ，並滿足分析/ 業務需求。

根據需求這可以是湖倉一體或數據倉庫，下面將詳細介紹此設計。

您可以為不同的使用者或域設置多個黃金層，並進行特定的優化/設計。例如，您可能為財務和銷售設置了單獨的黃金層，這些金層利用 STAR 模式並針對分析/報告進行了優化。此外，您可能還為數據科學家準備了一個針對機器學習進行優化的黃金層。

Lakehouse 示例架構

這是一個使用Medallion架構的湖倉一體架構示例。以下是有關圖表不同部分的註釋。

使用此體系結構模式的一般決策點：

• 開發人員團隊的技能集主要是Spark。
• 不需要數據倉庫的其他功能，如多表事務和動態數據遮罩。
• 消費者無需將數據倉庫端點用於某些第三方報告工具所需的功能。
• 用戶/開發人員不需要 T-SQL DDL/DML 功能。

資料來源：

• 可以是任何來源，從檔到流數據以及介於兩者之間的所有內容。
• 此數據可以來自本地位置、Azure 位置、其他雲供應商位置、快捷方式或 Fabric 本身內部。

準備和轉換：

引入方法：

• 我們沒有詳細介紹引入方法，但您可以選擇各種無代碼、低代碼或代碼選項。
• 目標是將數據放在 Bronze Lakehouse（原始層）中。
  • 結構管道
    • 200+ 本機連接器是 Microsoft 結構管道的一部分。
  • 數據流
  • 快捷方式
    • 數據源包括：OneLake、Azure Data Lake Store Gen2 （ADLS Gen2）、Amazon S3 或 Dataverse。
  • Spark 筆記本/作業
    • 包括流數據和檔/資料庫連接。

所有區域轉換/資料提升方法：

• 將取決於無代碼、低代碼或代碼選項的技能集。
  • Spark
    • 可以是筆記本或 Spark 作業定義
    • 複雜方案和高代碼選項的首選方法。對於複雜的轉換方案，性能將達到最佳。
  • 數據流
    • 低代碼選項，可執行簡單的轉換，最適合小型數據集。
  • Microsoft 結構管道的業務流程

青銅Lakehouse：

• 盡可能將數據保留為原始格式。如果無法做到這一點，請使用 Parquet 或 Delta Parquet 作為轉化目標。
  • 原因是性能。
  • 將數據載入到 Lakehouse 中後，可以利用 OneLake/Azure 位置的更好性能以及 Fabric 中提供的優化和可縮放的無伺服器計算來執行任何必要的轉換或轉換。與在中途進行轉換相比，您可能無法利用優化的可擴展計算/低延遲。
• 如果源數據與快捷方式相容，則在青銅區域創建一個快捷方式，而不是複製數據。

銀Lakehouse：

• 如果可以建議使用 Delta 表。
• Fabric 中內置了專門針對 Delta 表的額外功能和性能增強。
  • 例如，對 parquet 檔案格式的 V-Order 寫入時間優化。這允許 Fabric 中可用的不同計算引擎進行極快的讀取。
    • Ex. SQL引擎、Power BI 引擎、Spark 引擎
• 在這個區域，您將開始豐富您的數據。具體情況將取決於需要做什麼。無論是將其他數據源組合在一起、轉換現有數據、數據清理等，白銀區域都是執行這些操作的區域。

黃金Lakehouse：

• 使用Delta Tables的建議與Silver Lakehouse相同。
• 這個區域將是「商業就緒」的湖倉一體。這意味著您的數據位於 STAR 架構數據模型中，數據已規範化，並且已應用業務邏輯，因此數據已準備好供使用。
• 建議將每個 Lakehouse分隔成自己的結構工作區。與將所有湖倉一體放在一個工作區中相比，這允許在每個區域級別進行更好的控制和治理。

分析：

使用者將透過 2 種方法使用和分析資料：

Gold Lakehouse 的 SQL Analytics 端點

使用者/團隊可以將數據提取到不同的報告工具中，甚至可以在湖倉一體和數據倉庫之間進行跨資料庫查詢，以滿足不同的報告需求。

這也是探索或臨時分析的方法。無論是業務用戶還是 SQL 分析師/開發人員，SQL Analytics 端點都能夠從 Gold Lakehouse 獲得完整的唯讀 SQL 體驗。

通過 SQL Analytics 端點，特權使用者可以應用物件級別和行級別安全性來保護敏感數據。您可以創建視圖和函數來自定義和控制最終用戶的體驗，就像許多使用者習慣的傳統 SQL 環境一樣。

Power BI

使用者/團隊將通過報表、數據集、儀錶板、應用等通過Power BI使用數據，這些都來 Gold Lakehouse。

直接湖模式是一種新的語義模型功能，用於直接從數據湖載入 parquet 格式的檔，而無需查詢湖倉一體端點或在 Power BI 模型中導入/複製數據。

• 了解 Power BI 和 Microsoft 結構中的直接湖 – Power BI |Microsoft 學習
• 您仍然可以根據需求從 Gold Lakehouse 使用導入模式和 DirectQuery。

數據倉庫示例體系結構

下面是數據倉庫體系結構的範例，以下是有關圖表不同部分的註釋。

使用此體系結構模式的一般決策點：

• 開發人員團隊技能集主要是 T-SQL/數據倉庫技能集。
  • 使用存儲過程轉換數據
• 需要支援多表事務等功能，而這些功能僅受數據倉庫支援。
  • 例如事務性工作負載（OLTP 與 OLAP）。
    • 這並不意味著事務性工作負載只能使用 Data Warehouse。他們可以根據應用程式或 ETL/ELT 的要求使用 Lakehouse。
• 使用需要數據倉庫端點才能實現第三方報告工具或流程所需的 Lakehouse SQL 端點中不可用的功能。
• 用戶/開發人員需要 T-SQL DDL/DML 功能。
  • 工作負載要求用戶能夠修改數據，即使數據已規範化或轉換。

資料來源：

• “Mount Enabled”指的是快捷方式。如果您能夠使用快捷方式，建議您使用它。快捷方式允許您在不物理複製或移動資料的情況下使用數據。
  • 數據源包括：OneLake、Azure Data Lake Store Gen2 （ADLS Gen2）、Amazon S3 或 Dataverse。
• 結構化/非結構化
  • 包括來自其他 Azure 數據服務、其他雲平台、本地源等的數據。

引入：

• “Mounts”指的是快捷方式。它列在引入下，但快捷方式允許您連接數據，而無需複製或移動數據。您可以從快捷方式在倉庫中創建表，這些表將為您從快捷方式引入的數據進行數據移動。
• 管道和數據流
  • Fabric Pipelines 提供了使用 200+ 本機連接器將數據攝取到倉庫中的能力。
  • 如果需要您可以使用管道中的複製活動來存儲數據，或者使用數據流進行中動態轉換。
  • 熟悉 Azure 數據工廠的使用者會在 Fabric Pipelines 中找到類似的功能和概念。

商店：

倉庫設計：

儘管圖中未顯示，但仍建議在數據倉庫設計中明確分隔數據區域。就像 Medallion架構一樣，但使用數據倉庫而不是湖倉一體。數據倉庫通常具有與獎 Medallion體系結構相同的概念，具有登陸區域、暫存區域和生產區域的一些概念，這些概念提供與 Medallion體系結構相同的優勢。

建議在 Fabric 數據倉庫中也實現此概念。為此有 2 種選擇，具體取決於可容忍的行政監督量。

• 將青銅層、銀層和金層分隔到各自工作區中的單獨數據倉庫中。
  • 您仍然可以交叉查詢到不同的倉庫，以方便數據移動/使用數據，但這提供了自然的安全性和治理邊界。
• 單個倉庫，具有針對不同區域的架構/表實施。
  • 這可能會導致大量開銷和蔓延，但適用於物件/安全要求不多的小型數據倉庫。
  • 每個區域都將在架構中描述，並通過架構在單個倉庫中提供青銅、白銀和黃金。
    • 例如 bronze.Patient、silver.Patient、gold.Patient
  • 您需要強制實施不同的物件級安全性，以防止用戶發現/處理他們不應該發現的數據，例如敏感數據、原始數據等。
    • SQL 粒度許可權、物件/架構安全性、行/列級安全性和動態數據遮罩都可以使用
    • 在規模化管理時可能會有很多管理工作。

資料轉換：

• 建議使用 SQL 儲存過程。
• 這是通過倉庫中的完整 DDL/DML 功能實現的。
• 現在可以通過ADF等結構管道進行ETL（使用SQL儲存過程進行轉換）。

暴露：

倉庫：

• 使用者/團隊可以將數據提取到不同的報告工具中，甚至可以在湖倉一體和數據倉庫之間進行跨資料庫查詢，以滿足不同的報告需求。
  • 這也是用於探索、臨時分析或使用者執行 DDL/DML 語句的方法。
• 無論是業務用戶還是 SQL 分析師/開發人員。使用 SQL 粒度許可權，您可以定義每個使用者/安全組/使用者具有的訪問/許可權級別。
• 您可以通過動態數據掩碼應用物件級別、行級別和列級別安全性，以防止暴露敏感數據。
• 您可以創建視圖和函數來自定義和控制最終用戶的體驗和訪問，就像許多使用者習慣的傳統 SQL 環境一樣。
• 第三方報告工具或其他需要僅通過 Data Warehouse 端點才能獲得功能的流程。

Power BI：

• 使用者/團隊將通過報表、數據集、儀錶板、應用等通過Power BI使用數據，這些來自黃金倉庫或表。
• 直接湖模式是一種新的語義模型功能，用於直接從數據湖載入 parquet 格式的檔，而無需查詢倉庫端點或在 Power BI 模型中導入/複製數據。
  • 了解 Power BI 和 Microsoft 結構中的直接湖 – Power BI |Microsoft 學習
  • 如果需要，您仍然可以從黃金倉庫或表中使用導入模式和 DirectQuery。

數據倉庫和湖倉一體示例架構

下面是 Data Warehouse 和 Lakehouse 組合架構的範例，以下是有關圖表不同部分的註釋。

使用此體系結構模式的一般決策點：

• 開發人員團隊的技能集主要是Spark。
  • 使用 Spark 筆記本轉換數據
• 需要通過 T-SQL 支援最終使用者 DDL/DML 功能等功能，這僅受數據倉庫支援。
  • 工作負載要求用戶能夠修改數據，即使數據已規範化或轉換。
• 使用需要某些第三方報告工具或處理的數據倉庫端點中的功能。

此架構圖與 Lakehouse Medallion架構圖相同，但有 2 個不同之處。

此體系結構與僅 Lakehouse 體系結構之間的差異：

• Gold Lakehouse 被 Gold Data Warehouse 取代。
• 通過 Lakehouse 的 SQL Analytics 端點的消耗量將替換為數據倉庫端點。

為什麼要組合這些架構？

將 Lakehouse 和 Data Warehouse 合併到一個體系結構中可以為您提供兩全其美的效果（具體取決於您的要求）。

使用此體系結構，可以允許消耗層（通過 Power BI 或倉庫端點）充分利用數據倉庫，例如在黃金層為使用者/開發人員提供 DDL/DML 支援，併為其他報告工具/流程提供數據倉庫端點，而不必僅僅為了不同的使用方法而犧牲性能或複製數據。ETL/ELT 中的所有數據轉換都使用 Spark 執行，以實現代碼的最佳性能和靈活性，同時利用開發人員的主要技能集，同時仍能提供最佳的最終用戶體驗/功能。

即時分析/KQL 資料庫範例體系結構

下面是即時分析/KQL 資料庫體系結構的示例，以下是有關圖表不同部分的註釋。

使用此體系結構模式的一般決策點：

• 即時資料分析要求（延遲以秒為單位）
  • 通常客戶會解釋對「即時」需求的需求，經過討論，要求是“近乎即時”。這意味著延遲要求不是以秒為單位，而是以小時或分鐘為單位。“近實時”有時被誤解為即時。這種區別很重要，因為即時分析指的是以秒為單位的延遲。根據其他要求，近實時解決方案可能不使用 KQL 資料庫。
  • KQL 資料庫即使在非常大規模的情況下也能提供高性能、低延遲和高新鮮度。
• 需要有無限的擴展性。
  • 這種無限縮放適用於查詢併發/大小、引入流/大小和存儲大小。
    • 所有內容都會在 KQL 資料庫中自動編製索引和分區。
• 複雜數據結構的即時數據轉換要求。
• 要求使用任何數據源和/或任何數據格式。
• 使用內置的時間序列資料庫和/或地理空間功能的要求。
• 可以通過 Power BI、Lakehouse 中的筆記本、數據管道/數據流或使用者查詢進行使用。

資料來源：

• 任何數據源和任何數據格式都可以在這裡使用。
• Lakehouse 和 Data Warehouses 可以具有跨資料庫查詢，也可以是 KQL 資料庫的源。
• 事件流式處理源（如事件中心、IoT 中心或其他開源生態系統（Kafka、Logstash、Open Telemetry 等）可以使用 KQL 資料庫作為其流式處理目標。

引入：

• 通過事件中心雲連接將數據流式傳輸到即時分析中 從 Azure 事件中心獲取數據 – Microsoft 構造 |Microsoft 學習
  • Microsoft Fabric 中的事件流功能使您在 Fabric 平台中提供了一個集中的位置，可以捕獲、轉換即時事件並將其路由到具有無代碼體驗的各種目標。
  • Fabric 事件流中的所有內容都側重於事件數據。捕獲、轉換和路由事件數據是事件流的基本功能。該功能具有可擴展的基礎結構，由 Fabric 平台代表您進行管理。
• 快捷方式，如果您能夠使用快捷方式，建議您使用它。快捷方式允許您在不物理複製或移動資料的情況下使用數據。
  • 數據源包括：OneLake、Azure Data Lake Store Gen2 （ADLS Gen2）、Amazon S3 或 Dataverse。
• 管道和數據流
  • Fabric Pipelines 提供了使用 200+ 本機連接器將數據攝取到倉庫中的能力。
  • 如果需要，可以使用管道中的複製活動來登陸數據，或者使用數據流通過動態轉換來登陸數據。
  • 熟悉 Azure 數據工廠的使用者會在 Fabric Pipelines 中找到類似的功能和概念。
• 駐留在 OneLake 中的數據
  • 載入到即時分析中的數據將作為一個邏輯副本反映在 OneLake 中。 一個邏輯副本（預覽版） – Microsoft 結構 |Microsoft 學習
  • OneLake的數據可以通過即時分析作為快捷方式進行查詢。
    • OneLake 中的數據可以通過管道、查詢、數據流或在 Fabric UI 中手動載入到 Real-Time Analytics 中。

商店：

KQL 資料庫：

KQL 資料庫是即時分析的數據存儲，所有的好處和用例都在上面。Medallion體系結構不會在 KQL 資料庫中使用，因為這適用於原始遙測數據，建模/清理發生在飛行中或使用層。仍建議在 KQL 物件中具有某種組織或命名約定。

設計即時分析解決方案的一個重要概念是存檔。您需要制定一個存檔策略，以防止數據在不需要時增長/產生成本。為什麼要存檔數據？最有可能的是，即時分析解決方案中的數據只在很短的時間內有價值，而對於更多的歷史分析，您有不同的資產。每個解決方案都有不同的要求和業務需求，因此要保留的數據量可能會有所不同，但很少有真正要求將所有數據保留在即時分析解決方案中。

• 例如，在製造業中，瞭解生產車間機械的當前狀態對於儀錶板/分析至關重要。但是，30 天前特定時間甚至 3 天前的狀態與範圍無關或有用。在這裡，存檔數據將允許您刪除資料或將其移動到其他地方，以提供更深入的分析/趨勢分析、與倉庫數據相結合或您可能擁有的任何其他用途。這將有助於提高性能和成本。

在 Real-Time Analytics 中，您可以定義數據保留策略，並以不同的方式將數據匯出到不同的目標。

Lakehouse & Data Warehouse：

包含 Lakehouse 和 Data Warehouse 的原因是為了更深入地分析或進一步使用超出即時分析報告範圍的分析。這樣做的好處是，該解決方案為您提供即時分析，並保留要用於其他分析報告的數據的歷史保留。

一個邏輯副本（預覽版）允許您與 OneLake 中 KQL 資料庫中的數據進行交互，從而允許您處理數據，而無需為不同的計算引擎物理複製數據。提供湖倉一體或數據倉庫使用快捷方式連接到 KQL 中的數據的功能，而無需將其物理複製到湖倉一體。

現在，如果出於歷史保留或其他原因要將該數據載入到不同的文件或倉庫中，則需要物理移動/複製數據。在 KQL 中啟用一個邏輯副本時，可以通過管道、數據流、Spark 筆記本，甚至在 Lakehouse、Datawarehouse 和 KQL 資料庫之間跨資料庫查詢功能（允許創建快捷方式）來實現此目的。

如果使用 KQL 資料庫作為數據倉庫或湖倉一體的數據源，請查看上述體系結構，瞭解實現這些解決方案時的準則。

暴露：

Power BI：

使用者/團隊將通過報表、數據集、儀錶板、應用等通過Power BI使用數據，這些來自黃金倉庫或桌子。

當您啟用「一個邏輯副本」 時，您將能夠使用直接湖模式。

直接湖模式是一種新的語義模型功能，用於直接從數據湖載入 parquet 格式的檔案，而無需查詢倉庫端點或在 Power BI 模型中導入/複製數據。  了解 Power BI 和 Microsoft 結構中的直接湖 – Power BI |Microsoft 學習

否則，您將不得不使用導入模式或直接查詢模式。

KQL 查詢集：

KQL 查詢集是用於對 KQL 資料庫中的數據運行查詢、查看和自訂查詢結果的項。

使用 KQL 建立查詢、檢視、函數、控制命令、自定義結果和許多 SQL 函數。

KQL 查詢集中有一些選項卡，可用於連接/關聯不同的 KQL 資料庫，並將它們切換出來以在不同狀態下運行相同的查詢。

您可以與他人協作並保存查詢。

筆記本：

還可以通過 Spark/KQL 使用筆記本瀏覽數據。

這使您能夠直接從 KQL 資料庫通過筆記本引入、分析、在機器學習或任何進程中使用。

結論

在考慮在 Fabric 中創建新解決方案或遷移現有解決方案時，瞭解 Fabric 元件的功能和解決方案要求至關重要。通過檢查數據倉庫、Lakehouse 和 Real-Time Analytics/KQL 資料庫的不同用例、不同體系結構模式的示例，並深入瞭解每個數據倉庫、Lakehouse 和 Real-Time Analytics/KQL 資料庫的功能，當與使用者/工作負載要求的知識相結合時，應該會有更清晰的體系結構設計路徑。

文章來源：

什麼是OneLake？– Microsoft面料 |Microsoft 學習

什麼是湖倉一體？– Microsoft面料 |Microsoft 學習

什麼是 Microsoft Fabric 中的數據倉庫？– Microsoft面料 |Microsoft 學習

結構決策指南 – 選擇數據存儲 – Microsoft Fabric |Microsoft 學習

教程：將數據引入湖倉一體 – Microsoft Fabric |Microsoft 學習

構造決策指南 – 複製活動、數據流或Spark – Microsoft Fabric |Microsoft 學習

OneLake 快捷方式 – Microsoft Fabric |Microsoft 學習

在 Microsoft Fabric 中實現獎章湖倉一體體系結構 – Microsoft Fabric |Microsoft 學習

即時分析概述 – Microsoft Fabric |Microsoft 學習

即時分析和 Azure 數據資源管理器之間的差異 – Microsoft Fabric |Microsoft 學習

使用 Microsoft Fabric 中的 Synapse 即時分析感知、分析和生成見解 |Microsoft 結構博客 |Microsoft 結構

Fabric Change the Game：即時分析 |Microsoft 結構博客 |Microsoft 結構

Deep dive into DAX query view and writing DAX queries

本篇文章引用並翻譯自 Kim Manis 的 ”Empower Power BI users with Microsoft Fabric and Copilot”，最初發表並公開於2023年11月15日 Microsoft Power BI Blog，以下翻譯僅供參考，如有歧義一律以原文為主。引用來源：https://powerbi.microsoft.com/zh-tw/blog/empower-power-bi-users-with-microsoft-fabric-and-copilot/

來自麻省理工學院(註1)到《哈佛商業評論》(註2) 再到德勤 (Deloitte 註3)，一項又一項的研究都顯示創建數據驅動文化的好處。這就是為什麼在 Microsoft，我們花了數年時間與世界各地的組織合作，幫助他們實現這些好處。不幸的是，對於大多數組織來說，文化、組織和流程的障礙已經減緩了他們的進程，超過負荷的數據團隊難以滿足業務需求的擴展。業務使用者缺乏自行發現洞察的技術能力。數據在公司內部分散儲存，需要它的人也無法使用。分析工具不連接，從而減緩了獲得洞察的時間。這種模式現在正在發生變化。

我們很高興地宣佈 Microsoft Fabric 正式發佈，並在 Microsoft Fabric 中推出 Copilot 的公共預覽，其中包括 Power BI 的體驗。隨著這些下一代分析工具的推出，您可以使數據團隊更輕鬆地擴展以滿足業務需求。您可以創建一個協調有序的數據資產，最小化數據碎片，並使業務用戶能夠輕鬆找到持續更新的準確數據。它甚至使業務用戶能夠探索和使用經過管控的數據，幫助他們自行解答問題。

Microsoft Fabric 通過將所有人集結在一個端到端的分析平臺上，重塑團隊與數據合作的方式。數據分析師可以與數據工程師、數據倉庫專業人員、數據科學家和業務用戶並肩工作，他們都使用相同的軟體即服務 （SaaS） 體驗，並從同一個統一的數據湖 OneLake 中發現洞察。我們還很高興地宣佈，通過擴展 Direct Lake 模式以及導入模式語義模型與 OneLake 的無縫集成，在 Power BI 和 OneLake 之間實現更深入的整合。

我們還相信 Copilot in Fabric 有可能極大地改變我們處理數據的方式。經驗豐富的商業智慧專業人員可以使用 Copilot 更快地擴展並創建令人驚歎的報告。技能較低的使用者可以使用 Copilot 來探索他們的數據、創建報告和回答他們的問題，而不會加重數據團隊的負擔。

了解更多相關功能及資訊，請參閱下文。

宣佈正式發佈 Microsoft Fabric

我們很高興地宣佈，Microsoft Fabric 現已正式上市。Microsoft Fabric 是一個端到端的數據平臺，通過將每個數據源和分析服務連接在一起，可以重塑每個人訪問、管理和處理數據和洞察的方式。

觀看影片快速了解概述：

https://www.microsoft.com/en-us/videoplayer/embed/RW1eSvs

Microsoft Fabric 正在重新定義當前的分析市場，主要有以下四個方面：

1. Fabric 是一個完整的分析平臺。通過將七個特定於角色的工作負載（數據工廠、數據工程、數據倉庫、數據科學、即時分析、數據啟動器和Power BI）整合到一個統一的體驗和體系結構中，Fabric 可以幫助您降低整合服務的典型成本和工作量，並簡化數據資產。這種統一的架構還透過涵蓋每個工作負載的內建功能簡化了治理，並透過可用於每個工作負載的單一容量和儲存池簡化了計費。
   
2. Fabric 以湖為中心且開放。可以輕鬆地將所有雲、帳戶和域中的所有數據連接到 Fabric 的統一多雲數據湖 OneLake，從而為您的數據創建一個真實的單一數據源。OneLake 會自動連接到每個 Fabric 工作負載中，並且使用 OneLake 的開放數據格式，您只需將數據載入到湖中一次，即可在每個 Fabric 工作負載和引擎中使用它，從而最大限度地減少數據重複和蔓延。
   
3. Fabric 賦予每個企業用戶更強大的能力。Microsoft Fabric 可以確保組織中的用戶能夠訪問做出數據驅動決策所需的數據和洞察。由於 Power BI 本機內置於 Fabric 中，任何人都可以快速從湖中的數據轉換為嵌入在 Microsoft 365 應用程序中的引人注目的 Power BI 可視化圖表。
   
4. Fabric 由 AI 提供支援。Fabric 在每一層面都融入了 AI，以幫助數據專業人員更快地完成更多工作。借助 Fabric 中的 Copilot，您可以使用自然語言創建數據流和管道、編寫 SQL 語句、生成報告，甚至開發機器學習模型。而且，通過我們最近宣佈的與 Azure AI Studio 的整合，您可以使用 Microsoft Fabric 中集成、準備和建模的數據，在 Azure AI Studio 中構建為組織量身定製的生成式 AI 解決方案。

宣佈在 Microsoft Fabric 中推出 Copilot 的公共預覽版

我們很高興地宣佈在 Microsoft Fabric 中推出 Copilot 的公共預覽版，包括 Power BI 的體驗，它通過幫助使用者在 Power BI Web 體驗中創建報表來幫助使用者快速入門。根據高級提示，Copilot for Power BI in Fabric 通過標識有助於入門的表格、字段、度量值和圖表，為您創建整個報表頁。然後，您可以使用我們現有的編輯體驗自定義頁面。Copilot 還可以幫助您了解語義模型，甚至可以為報表頁提供建議的主題。這是一個快速簡便開始使用報表的方法，尤其是對於 Power BI 報表創建不熟悉的用戶情況下。

除了報表創建之外，我們很高興將 Copilot 匯總數據的獨特功能引入到智能敘述視覺中，現在更名為 Narrative with Copilot 視覺物件。此視覺物件匯總頁面上、整個報表中的數據和見解，如果需要定義特定摘要，甚至可以匯總你自己的範本的數據和見解。無論你選擇使用哪種方式，“使用 Copilot 的敘述”視覺物件都會加速您傳達有關最重要數據的見解的方式。視覺物件可在 Power BI 服務和 Power BI Desktop 中使用。

最後，在 Power BI Desktop 中，Copilot 可以説明模型作者改進其模型並節省時間。我們將於 2023 年 11 月發佈的第一個功能幫助作者使用 Copilot 為其字段、度量和表格生成同義詞。但這僅僅是個開始。未來的Power BI Desktop更新將帶來更多新的 Copilot 體驗，包括來自服務的報表創建體驗、數據分析表達式 （DAX） 編寫體驗等。這些體驗僅僅是個開始。我們將繼續發佈 Copilot 功能，為我們的客戶實現生成式 AI 的承諾。

Microsoft Fabric 中的 Copilot 預覽版將分階段推出，目標是所有具有 Power BI Premium 容量（P1 或更高）或 Fabric 容量（F64 或更高）的客戶都可以在 2024 年 3 月底之前訪問 Copilot 預覽版。無需註冊即可加入預覽版，當它推出到租戶時，它將自動作為 Fabric 管理門戶中的新設置提供給你。當 Copilot in Fabric 體驗開始收費時，只需根據現有 Fabric 或 Power BI Premium 容量計算 Copilot 使用量即可。請查看 Power BI 的 Copilot 文件，瞭解完整的說明和要求，如果您有任何問題，請隨時聯繫 Microsoft 代表、合作夥伴或在 Fabric 社區網站上留言。

對 OneLake 中的所有數據使用 Direct Lake 模式

Power BI 語義模型對 Synapse 數據倉庫上的 Direct Lake 的支援

我們很高興地宣佈，Power BI 語義模型現在可以將Direct Lake模式與 Microsoft Fabric 中的 Synapse Data Warehouse 結合使用。到目前為止，Direct Lake 模式僅限於 Fabric 湖倉一體上的語義模型，而倉庫僅在 DirectQuery 模式下查詢。現在，我們擴展了 Direct Lake 模式，以支援 Fabric 中的倉庫。Direct Lake 模式是一種開創性的語義模型數據訪問技術，它基於直接從 OneLake 載入 Delta-Parquet 文件，而無需導入或複製數據。Direct Lake 結合了導入和 DirectQuery 模式的優勢，無需任何數據移動即可提供超快的查詢性能。因此，我們很高興在 Synapse 數據倉庫之上引入對 Direct Lake 語義模型的支援。有關詳細資訊，請閱讀產品文檔中的Power BI和 Microsoft Fabric 中的 Direct Lake 頁。

宣佈推出 Direct Lake 語義模型行級安全性和物件級安全性的存儲憑據的公共預覽版

我們很高興地宣佈推出 Direct Lake 語義模型的行級安全性 （RLS） 和物件級安全性 （OLS） 以及存儲憑據的公共預覽版。RLS 和 OLS 安全性是一項 Power BI 功能，可用於在語義模型中定義行級和物件級訪問規則，以便不同的使用者可以根據其角色和許可權查看不同的數據子集。存儲的憑據有助於降低配置複雜性，強烈建議在將 RLS 和 OLS 與 Direct Lake 語義模型結合使用時使用。以下截圖顯示了如何使用 Web 建模體驗將使用者添加到 Direct Lake 模型中的 RLS 角色。Web 建模安全角色對話框將在未來幾天或幾周內完全部署。有關如何設置存儲憑據的更多資訊，請參閱 Direct Lake 產品文檔。有關 RLS 和 OLS，請參閱使用 Power BI 的行級別安全性 （RLS） 和物件級別安全性 （OLS） 一文。

立即將導入模式語義模型集成到 OneLake 中

我們非常高興地推出另一項突破性的語義模型技術。我們宣佈推出用於導入模型的 Microsoft OneLake 集成的公共預覽版。只需輕按開關，即可啟用 OneLake 集成，並自動將導入語義模型的數據寫入 OneLake 中的增量表，無需任何遷移工作即可享受 Fabric 的優勢。通過這些增量表可以即時並發訪問數據。數據科學家、資料庫管理員、應用開發人員、數據工程師、公民開發者和任何其他類型的數據使用者現在都可以直接訪問驅動商業智能的相同數據。啟用 OneLake 集成，通過快捷方式將這些增量表包含在 Lakehouse 和 Synapse Data Warehouse中，使用戶能夠使用 T-SQL、Python、Scala、PySpark、Spark SQL、R 以及無代碼和低代碼解決方案來查詢數據。

使用「Explore」快速回答您的數據問題

我們很高興地宣佈推出一項名為“Explore”的新公共預覽版功能，該功能將使任何人都可以快速探索語義模型。與在 Excel 中匯出和生成數據透視表類似，可以打開「Explore」體驗並為數據創建矩陣或可視視圖。例如：分析師可以在生成報表之前使用 Explore 來瞭解新的語義模型，或者業務使用者可以在不生成整個報表的情況下回答有關數據的特定問題。

宣佈推出數據分析表達式查詢檢視的公共預覽版

DAX 查詢可幫助您快速流覽和分析語義模型。借助 Power BI Desktop 中的新 DAX 查詢檢視，可以利用強大的 DAX 查詢語言來發現、分析和查看語義模型中的數據。與上面的「Explore」功能一樣，模型作者可以快速驗證語義模型中的數據和度量值，而無需構建視覺物件或使用其他工具。對度量所做的更改可以無縫地直接更新回語義模型。此功能以及一些現有功能（如自動格式設置、與報表檢視的性能分析器集成、快速度量值和度量值引用擴展）都意味著Power BI中的DAX查詢創作對於數據專業人員和高級數據分析師來說已經變得更加高效。

我們計劃繼續向 DAX 查詢檢視添加功能，包括 Copilot 集成、對即時連接報表的支援，以及將其添加到 Power BI 服務。有關詳細資訊，請參閱 DAX 查詢文檔頁，並通過在 Power BI Desktop 選項>預覽功能中啟用此公共預覽版功能開始使用。

宣佈語義模型橫向擴展正式發佈，現在與 Direct Lake 相容

我們很高興地宣佈語義模型橫向擴展現已正式發佈。通過橫向擴展，Power BI 會自動橫向擴展只讀副本，以確保在多個用戶同時使用系統時不會出現性能下降，從而支持高用戶併發的大規模生產解決方案。我們還宣佈，自動橫向擴展現在適用於 Direct Lake 語義模型。此外，導入模式語義模型將受益於刷新隔離，確保業務使用者不受資源密集型刷新操作的影響，並繼續享受用於互動式分析的極快查詢速度。

語義模型橫向擴展是使 Microsoft Fabric 和 Power BI 成為 Microsoft Azure Analysis Services 超集的最後一個關鍵功能。在Fabric 中的橫向擴展甚至優於 Analysis Services，因為橫向擴展是根據即時使用者需求進行的，並會根據使用模式的變化自動進行調整。另一方面，Analysis Services 需要詳細分析以確定高峰使用時間、創建自動化腳本和監視以確保最佳設置。此外，與 Fabric 基於使用方式的計費模型不同，Analysis Services 中的成本會按每個副本呈線性增加。

有關如何啟用語義模型擴展的詳細資訊，請參閱配置語義模型擴展文檔頁面。

使用新的 Microsoft Fabric 許可選項最大限度地降低成本

2023 年 6 月，我們宣佈了 Fabric 的即用即付價格，允許您根據需求動態擴展或縮減，並在需要時暫停容量。我們很高興地宣佈推出 Fabric 的保留定價，可以讓您以一年為單位預先承諾Fabric容量單位，幫助您在按使用付費價格的基礎上節省高達 40.5% 的費用（不包括 Power BI Premium 容量 SKU）。我們還宣佈了 OneLake 業務連續性和災難恢復 （BCDR） 以及快取存儲價格，擴展了我們已經宣佈的 OneLake 儲存定價。在 Microsoft Fabric 定價頁面上查看所有這些定價選項。

通過這些公告，當前的Power BI Premium 每容量客戶可以獲得額外的定價選項，以體驗 Fabric 提供的所有功能。除了即用即付選項外，Fabric 客戶還可以享受遠低於入門級 P-SKU 的較小 SKU。由於Fabric SKU 符合 Microsoft Azure 消耗承諾 （MACC） 的條件，因此 Fabric客戶可以將其 Fabric 消費計入其 MACC 承諾。

Power BI 和 Microsoft Fabric 入門

如果您是現有的Power BI Premium 每容量客戶，則只需在管理門戶中打開「Fabric」，即可訪問 Microsoft Fabric。獲取教學指南。

如果還沒有 Power BI Premium 容量，可以通過註冊免費試用版來試用 Fabric 提供的所有功能，無需信用卡資訊。若要開始免費試用，請註冊一個免費帳戶（Power BI 客戶可以使用其現有帳戶），登錄后，在 Fabric 應用的帳戶管理器工具中選擇「開始試用」。每個試用用戶將獲得 64 CU 的試用容量（計費單位），用於在 60 天免費試用期間的任何工作負載。有關詳細資訊，請訪問 Fabric 入門頁面。

加入我們的 Microsoft Fabric Community 大會

如果您想獲得 Microsoft Fabric 的實踐經驗並直接向創建它的人學習，請參加 2024 年 3 月 24 日至 29 日的 Microsoft Fabric Community 會議。我們將彙集來自 Microsoft 和 Global analytics community的專家，分享、演示和討論 Microsoft Fabric、Power BI 等的最新發展。在本次活動中，您將能夠向頂級數據專家和人工智慧領導者學習，同時有機會與同行互動並分享您的故事。我們希望您能加入我們，瞭解 Microsoft 的尖端技術如何借助 Microsoft Fabric 的強大功能説明您的業務取得成功。立即註冊。

充分利用 Microsoft Fabric 培養您所需的技能

我們宣佈推出增強的 Microsoft 證書組合，包括新的“Microsoft Certified: Fabric Analytics Engineer Associate”認證，以及涵蓋使用 Microsoft Fabric 的方案（如實施湖倉一體、數據倉庫和即時分析解決方案）的幾項新的 Microsoft 應用技能。這些證書將在未來幾個月內推出。

準備好深入瞭解 Fabric 並開始準備這些證書了嗎？參加“Microsoft Fabric 挑戰賽”，作為 Microsoft Learn 雲技能挑戰賽 Microsoft Ignite 版的一部分。掌握熱門技術技能，並參加下一次 Microsoft Ignite 或 Microsoft Build 的 VIP 活動通行證。請參閱官方規則，查看更多詳細資訊。該挑戰從現在起至 2024 年 1 月 15 日，所以趕快開始使用以避免錯過任何一個機會。

立即與充滿活力的數據專業人員在Community互動，解答您所有有關 Fabric 的問題、或是提出新功能建議、瞭解最新更新等等。

保持聯繫

若要了解有關 Power BI 和 Microsoft Fabric 的詳細資訊，請參考：

• 註冊 Microsoft Fabric 免費試用版，或者如果您已有 Power BI Premium 容量，只需在管理門戶中打開 Microsoft Fabric。
• 訪問 Power BI 和 Microsoft Fabric 網站。
• 觀看 Microsoft Fabric Ignite 會議。
• 在 Microsoft Fabric Updates Blog上閱讀更深入的技術資訊。
• 查閱 Power BI和 Fabric 技術文件。
• 參加 2024 年 3 月 24 日至 29 日的 Fabric Community 會議。
• 加入 Power BI 和 Fabric Community。

註1- How to build data literacy in your company, MIT Sloan (February 2021).

註2- 10 Steps to Creating a Data-Driven Culture, Harvard Business Review (February 2020).

註3- Deloitte Survey: Analytics and Data-driven Culture Help Companies Outperform Business Goals in the ‘Age of With’, Deloitte (July 2019).