本文提供準備和執行有效 Azure 數據總管概念證明 （POC） 專案的高階方法。
開始之前
劇本可協助您評估 Azure 數據總管的使用，並專為最適合 Azure 數據探索的案例所設計。 在開始 POC 之前，請使用下列案例來判斷 Azure 數據總管是否為您正確解決方案。
一般架構模式案例
- 符合下列一或多個特性的任何數據都應該是 Azure 數據總管的良好候選專案：
- 大量和速度
- 僅附加和不可變的數據
- 數據靜止：不會變更的數據。 例如，在在線商店中下訂單是靜止數據的良好範例。
- 命令查詢責任隔離 （CQRS） 模式 適用於 Azure 數據總管的附加架構。
- 事件來源模式
其他案例
下列案例也是 Azure 數據總管的良好候選專案：
- 即時遙測型警示的低延遲數據存放區
- IoT 遙測數據儲存和分析
- 高速互動式分析層。 特別是搭配 Apache Spark 引擎使用時，例如 Synapse Spark、DataBricks 或傳統數據倉儲，例如 Synapse SQL 集區。
- 記錄和可觀察性分析
準備 POC
POC 專案可協助您在使用 Azure 數據總管的雲端式平臺上實作巨量數據和進階分析環境，以做出明智的商務決策。
POC 專案將識別雲端式巨量數據和進階分析平台必須支援的主要目標和業務驅動因素。 還會測試關鍵計量並證明關鍵行為，這些都攸關資料工程、建立機器學習模型和定型需求的成敗。 POC 並非設計成部署至實際執行環境。 而是著重於關鍵問題的短期專案，可捨棄結果。
開始規劃 Azure 數據總管 POC 專案之前：
- 識別組織在資料移至雲端方面的任何限制或指導方針。
- 識別巨量資料和進階分析平台專案的主管或業務贊助者。 鞏固其對於移轉至雲端的支援。
- 確定在 POC 執行期間有技術專家和商務使用者支援您。
開始準備 POC 專案之前，建議您先閱讀 Azure 數據總管檔。
現在您應該確定目前已無障礙，所以可以開始準備 POC。 如果您不熟悉 Azure 數據總管，您可以在這裡參閱 這份檔 ，以取得 Azure 數據總管架構的概觀。
了解這些重要概念：
- Azure 數據總管及其架構。
- 支援數據格式和數據源。
- 叢集、資料庫、數據表、具體化檢視，可作為 Azure 數據總管成品。
- 支援擷取精靈和連續擷取的擷取方法。
- Azure 數據總管中的驗證和授權。
- 與 Power BI、Grafana、Kibana 等視覺效果解決方案整合的原生連接器。
- 建立外部數據表以從 Azure SQL/SQL Server、Azure Cosmos DB、Azure 監視器、Azure Digital Twin 讀取數據。
Azure 數據總管會將計算資源與記憶體分離，以便更妥善地管理數據處理需求和控制成本。 您只需在使用時支付計算費用。 不使用時，只需要支付儲存體的費用。 Azure 資料總管的受控服務架構可讓您獨立於記憶體來調整叢集。 您可以相應增加和縮小（垂直），以及相應縮小和相應放大（水準）。 您也可以手動停止或 自動停止叢集，而不會遺失您的數據。 例如，您可以相應增加叢集以進行繁重的數據處理需求或大型負載，然後在較不密集的處理時間相應減少叢集，或完全關閉叢集。 同樣地，您可以在週末有效地調整和停止叢集，以降低成本。
設定目標
成功的 POC 專案需要規劃。 首先，明白您為何執行 POC，以完整瞭解真實動機。 動機可能包括現代化、節省成本、改善效能或整合式體驗。 請務必寫下 POC 的明確目標，並設定其成功準則。 詢問自己：
- 您想要從 POC 獲得什麼輸出？
- 您要怎麼使用這些輸出？
- 誰會使用輸出？
- 如何確定 POC 成功？
請記住，POC 應該簡短而且有重點，以快速證明少量的概念和功能。 這些概念和功能應該足以代表整體工作負載。 如果您有一長串的項目要證明，請規劃多個 POC。 在此情況下，請定義 POC 之間的關卡，以決定是否需要繼續下一個 POC。 例如，一個 POC 可能專注於資料工程角色的需求，例如擷取和處理。 另一個 POC 可能專注於機器學習 (ML) 模型開發。
在考慮 POC 目標時，請自問下列問題，以協助您塑造目標：
- 您是否從現有的巨量資料和進階分析平台移轉 (內部部署或雲端)？
- 您要移轉並想要一路上進行一些廣泛的改進嗎？ 例如，從彈性搜尋移轉至 Azure 數據總管以進行記錄分析，從 InfluxDB 或 Timescale DB 遷移至 Azure 數據總管。
- 您是否建立全新的巨量資料和進階分析平台 (綠地專案)？
- 您目前有什麼難題？ 例如，可擴縮性、效能或彈性。
- 您需要支援哪些新的商務需求？
- 您需要符合哪些 SLA？
- 工作負載會是什麼？ 例如，ETL、批次處理、串流處理、機器學習模型定型、分析、報告查詢或互動式查詢？
- 擁有專案的使用者有什麼技能 (應該實作 POC)？ 例如，SQL、Python、PowerBI 或其他技能。
以下是 POC 目標設定的一些範例：
- 為什麼執行 POC？
- 必須知道巨量資料工作負載的資料擷取和處理效能會符合新的 SLA。
- 必須知道近乎即時的串流處理是否可行，以及可支援多少輸送量。 (是否支援商務需求？)
- 必須知道現有的資料擷取和轉換流程是否合適，以及需要改善之處。
- 必須知道是否可以縮短資料整合執行時間，以及縮短多少。
- 我們需要知道數據科學家是否可以建置和定型機器學習模型，並在 Azure 數據總管中視需要使用 AI/ML 連結庫。
- 移至雲端式 Azure 資料總管是否符合我們的成本目標？
- 在此 POC 結束時：
- 我們將有數據來判斷數據處理效能需求是否符合批次和即時串流。
- 我們將測試所有支援使用案例的不同數據類型（結構化、半結構化和非結構化）的擷取和處理。
- 我們將測試一些現有的數據處理需求，並識別可在 Azure 數據總管中使用更新原則完成的工作。
- 我們將測試數據擷取和處理，並將有數據點來估計初始移轉和歷程記錄數據負載所需的工作。
- 我們將測試數據擷取和處理，並可以判斷是否可以符合 ETL/ELT 處理需求。
- 我們將取得深入解析，以更妥善地估計完成實作專案所需的工作。
- 我們將測試縮放比例和調整選項，並讓數據點更妥善地設定平臺，以取得更佳的效能設定。
- 我們將有可能需要更多測試的項目清單。
規劃專案
根據目標來指明特定的測試及提供您發現的輸出。 請務必確保至少有一個測試可支援每個目標和預期的輸出。 此外，請識別特定的數據擷取、批次或串流處理，以及將執行的所有其他進程，以便識別特定的數據集和程式代碼基底。 此具體資料集和程式碼基底將定義 POC 的範圍。
以下是使用 Azure 數據總管評估的典型主題區域：
- 數據擷取和處理：數據源、數據格式、擷取方法、連接器、工具、擷取原則、串流與佇列擷取
- 數據記憶體：架構、數據表和具體化檢視等記憶體成品
- 原則：例如分割、更新、合併
- 查詢和視覺效果
- 效能：例如查詢回應時間、擷取延遲、弱式一致性、查詢快取結果
- 成本：總擁有成本（TCO）
- 安全性：例如驗證、授權、數據存取、數據列層級安全性
注意
使用下列常見問題來協助您規劃POC。
- 如何? 選擇POC叢集的SKU嗎？
使用選取 Azure 數據總管叢集 的 SKU 指南，協助您選擇 POC 叢集的 SKU。 啟動 POC 時，建議您從較小的 SKU 開始，並在開始測試和擷取結果時視需要相應增加 SKU。 - 如何? 建立POC叢集時選擇快取期間？
為了提供最佳的查詢效能，擷取的數據會快取在本機 SSD 磁碟上。 這種效能層級不一定是必要，而且查詢頻率較低的數據通常可以儲存在更便宜的 Blob 記憶體上。 Blob 記憶體中數據的查詢執行速度較慢，但在許多情況下都能接受。 瞭解這可協助您識別在本機 SSD 中保存資料所需的計算節點數目，並繼續符合查詢效能需求。 例如，如果您想要更頻繁地查詢 x 天的數據（根據擷取年齡）並保留 y 天的數據，並在快取保留原則中，在快取保留原則中，將 x 指定為經常性快取保留的值，並將 y 指定為總保留期的值。 如需詳細資訊，請參閱 快取原則。 - 如何? 建立POC叢集時選擇保留期間？
保留期間是經常性快取和冷快取數據的組合，可供查詢。 根據您需要根據合規性或其他法規需求保留數據的時間長度，選擇數據保留期。 您可以使用經常性視窗功能，將儲存在冷快取中的數據暖化，以便更快速地查詢任何稽核目的。 如需詳細資訊，請參閱使用經常性視窗查詢非經常性資料。
以下是規劃時所需具體程度的範例：
- 目標 A：必須知道在我們定義的 SLA 下，是否符合資料擷取和處理批次資料的需求。
- 輸出 A：我們將有數據來判斷佇列資料擷取和處理是否符合批次數據處理需求和 SLA。
- 測試 A1：處理查詢 A、B 和 C 會識別為良好的效能測試，因為它們通常是由數據工程小組執行。 也代表整體資料處理需求。
- 測試 A2：因為處理查詢 X、Y 和 Z 包含近乎即時的串流處理需求，可視為良好的效能測試。 也代表整體事件型串流處理需求。
- 測試 A3：比較這些查詢在不同規模的叢集效能（叢集 SKU、實例數目），以及從現有系統取得的基準檢驗。
- 目標 B：我們需要知道我們的商務使用者是否可以在此平臺上建置其儀錶板。
- 輸出 B：我們將使用不同的視覺效果選項、連接器和 Kusto 查詢，測試叢集中數據的一些現有儀錶板和視覺效果。 這些測試有助於判斷哪些儀錶板可以移轉至新的環境。
- 測試 B1：將會使用 Azure 數據總管數據建立特定視覺效果，並進行測試。
- 測試 B2：測試現用的 KQL 函式和運算符，以符合需求。
- 目標 C：我們將測試數據擷取，並將數據點指向：
- 預估初始歷程記錄數據遷移至 Azure 數據總管叢集的努力。
- 規劃方法來移轉歷史資料。
- 輸出 C：我們將測試並判斷環境中可達成的數據擷取率，並判斷我們的數據擷取速率是否足以在可用的時間範圍內移轉歷程記錄數據。
- 測試 C1：測試不同的歷史資料移轉方法。
- 測試 C2：使用 LightIngest、從 Blob 記憶體或 Data Lake Store 連續擷取，測試從數據源到叢集的數據傳輸。 如需詳細資訊，請參閱 內嵌歷程記錄數據。
- 目標 D：我們將測試累加式數據載入的數據擷取速率，並將有數據點來估計數據擷取和處理時間範圍。
- 輸出 D：我們將測試數據擷取速率，並判斷我們的數據擷取和處理需求是否符合已識別的方法。
- 測試 D1：每天、每小時和近乎實時的數據擷取和處理。
- 測試 D2：在執行使用者查詢時，執行連續（佇列或串流）數據擷取和處理。
請務必新增多個測試情節來改善測試。
以下是一些測試情節：
- Azure 數據總管測試 A：我們將跨多個叢集 SKU 大小執行數據擷取、處理和查詢，以及不同數目的叢集實例。
- Azure 數據總管測試 B：我們將使用儀錶板和查詢工具，例如 Azure 數據 總管 Web UI，從叢集查詢已處理的數據。
以下是可用來協助您規劃POC之工作的高階範例：
| Sprint | Task |
|---|---|
| 0 | 向客戶小組呈現及示範 Azure 數據總管 |
| 0 | 定義客戶想要使用 Azure 數據總管達成的商務案例 |
| 0 | 在數據源、擷取方法、數據保留、數據快取、SLA、安全性、網路、IAM等方面定義技術需求 |
| 0 | 定義關鍵效能量值，例如查詢效能預期、延遲、並行要求、擷取整個數據新鮮度 |
| 0 | 使用 Azure 數據總管及其數據擷取器和取用者定義高階架構 |
| 0 | 定義POC範圍 |
| 0 | 定義POC規劃和時程表 |
| 0 | 定義、排列優先順序和權衡POC評估準則 |
| 1 | 定義並排定要測試的查詢優先順序 |
| 1 | 為每個使用者群組定義數據存取規則 |
| 1 | 估計一次性（歷程記錄）數據擷取量和每日數據擷取量 |
| 1 | 定義數據保留、快取和清除策略 |
| 1 | 定義建立叢集時所需的組態專案，例如串流、Python/R 外掛程式、清除 |
| 1 | 檢閱源數據格式、結構、架構 |
| 1 | 檢閱、精簡、修訂評估準則 |
| 1 | 根據適用於 Azure 數據總管的 Azure 定價計算機建置定價案例 |
| 2 | 根據架構設計建立叢集和必要的資料庫、數據表、具體化檢視 |
| 2 | 將許可權指派給相關用戶以進行數據存取 |
| 2 | 實作資料分割和合併原則（如有需要） |
| 2 | 實作一次性擷取數據，通常是歷程記錄或移轉數據 |
| 2 | 安裝及設定查詢工具（如有需要） |
| 2 | 使用數據總管 Web UI 測試內嵌資料的查詢 |
| 2 | 測試更新和刪除案例 |
| 2 | 測試 PowerBI 的連線 |
| 2 | 測試與 Grafana 的連線 |
| 2 | 設定資料存取管理規則 |
| 2 | 實作連續擷取 |
| 2 | 使用事件中樞/Iot 中樞/事件方格建立數據連線 |
| 3 | 在 Azure 數據總管儀錶板或 Grafana 中實作自動重新整理儀錶板以進行近乎即時的監視 |
| 3 | 定義如何執行負載測試 |
| 3 | 根據先前短期衝刺和已完成待處理項目的學習，優化擷取方法和程式 |
| 3 | Grafana 儀錶板上的效能評估 |
| 3 | 根據並行和預期的負載需求執行負載測試 |
| 3 | 驗證成功準則 |
| 3 | 檢閱評分 |
| 3 | 測試使用不同格式內嵌數據的能力 |
| 3 | 驗證POC結果 |
評估 POC 資料集
使用您指明的特定測試，選取資料集以支援測試。 花點時間檢閱此資料集。 您應該確認此資料集在內容、複雜度和規模方面，足以代表未來的處理。 請勿使用太小（小於 1 GB）的數據集，因為它不會提供代表性的效能。 相反地，請勿使用太大的資料集，因為 POC 不應該變成完整的資料移轉。 請務必從現有的系統取得適當的基準，以方便比較效能。 檢查您的資料集是否符合支持的數據格式。 然後，根據擷取方法（已排入佇列或串流），您的數據集可以分批內嵌適當的大小。
重要
請務必在將資料移至雲端之前，與企業負責人確認是否有任何阻礙。 識別安全性或隱私權考量，或任何應在將資料移至雲端之前完成的資料混淆需求。
建立高階結構
根據您提議的未來狀態結構的高階結構，指明將納入 POC 中的元件。 高階未來狀態結構可能包含許多資料元素、許多資料取用者、巨量資料元件，或許還包含機器學習和人工智慧 (AI) 資料取用者。 POC 結構應該明確指明將納入 POC 中的元件。 重要的是，應該指明不會納入 POC 測試中的任何元件。
如果您已經在使用 Azure，請指明您已備妥在 POC 期間可使用的任何資源 (Microsoft Entra ID、ExpressRoute 和其他)。 還要指明組織使用的 Azure 區域。 此時最好指明 ExpressRoute 連線的輸送量，並向其他商務使用者確認您的 POC 可以取用某些輸送量，而不會對生產系統造成負面影響。
如需詳細資訊，請參閱巨量資料架構。
指明 POC 資源
具體指明支援 POC 所需投入的技術資源和時間。 POC 將需要：
- 業務代表，監督需求和結果。
- 應用程式資料專家，負責供應資料給 POC，並提供現有流程和邏輯的知識。
- Azure 數據總管專家。 您可以視需要要求Microsoft聯繫人安排。
- 專家顧問，負責將 POC 測試最佳化。 您可以視需要要求Microsoft聯繫人安排。
- POC 專案特定元件所需的資源，但不一定需要在 POC 期間。 這些資源可能包括網路管理員、Azure 管理員、Active Directory 管理員、Azure 入口網站管理員和其他人。
- 請務必佈建所有必要的 Azure 服務資源，並授與必要的存取等級，包括儲存體帳戶的存取權。
- 請確定您有一個帳戶具有必要的資料存取權限，可從 POC 範圍中的所有資料來源擷取資料。
提示
建議洽詢專家顧問以為 POC 提供協助。 請連絡您的Microsoft帳戶小組，或連絡可協助您評估、評估或實作 Azure 數據總管的專家顧問的全域可用性。 您也可以使用 Azure 數據總管標籤在 Stack Overflow 上張貼問題。
設定時間軸
檢閱 POC 規劃詳細資料和商務需求，以確認 POC 的時間範圍。 實際估計完成 POC 目標所需的時間。 POC 資料集大小、測試次數和複雜度，以及要測試的介面數目，將會影響完成 POC 所需的時間。 如果您估計 POC 會執行四週以上，請考慮縮小 POC 範圍來專注於最優先的目標。 繼續之前，請務必獲得所有主要人士和贊助者的核准與承諾。
實作 POC
建議以生產專案的紀律和嚴格性來執行 POC 專案。 按計劃執行專案，並管理變更要求程序，以防止 POC 範圍成長失控。
以下是高階工作的一些範例：
建立 Azure 數據總管叢集，以及 POC 方案中識別的所有 Azure 資源。
載入 POC 資料集：
- 從來源擷取或在 Azure 中建立範例資料，以提供資料給 Azure。 如需在 Azure 數據總管中擷取數據的初始測試，請使用 取得數據體驗。
- 測試您計劃用來將資料內嵌至叢集的連接器/整合方法。
撰寫 Kusto 查詢以查詢資料：
- 如果您要從 SQL 型系統移轉，您可以使用 SQL 到 Kusto 速查表 來協助您開始使用。
執行測試：
優化查詢和叢集：
- 無論您是撰寫新的 KQL 查詢或轉換其他語言的現有查詢，建議您檢查您的查詢是否遵循 查詢最佳做法。
- 根據測試結果，您可能需要使用快取原則、分割原則、叢集大小或其他優化來微調叢集。 如需建議，請參閱 使用 Azure 數據總管優化高並行
監視以進行疑難解答和效能：
- 如需詳細資訊，請參閱 使用計量監視 Azure 數據總管效能、健康情況和使用方式。
- 如需技術問題，請 建立支援票證。
估計定價：
- 在 POC 結束時，您應該使用 POC 中學到的內容來 預估符合您需求的叢集成本 。
關閉 POC：
- 記錄您在POC期間套用的結果、課程和POC階段的結果，包括基準檢驗、設定、優化。
- 清除您不再需要的 POC 期間建立的任何 Azure 資源。
提示
如果您決定繼續進行 Azure 數據總管，並打算 將它移轉至生產環境，建議您讓 POC 叢集保持執行。 這可協助您設定生產叢集，確保您不會遺失 POC 期間可能已套用的設定和優化。
解譯 POC 結果
完成所有 POC 測試時，請評估結果。 首先，評估是否符合 POC 結果和是否已收集所需的輸出。 判斷是否需要更多測試，或是否需要解決任何問題。
從 POC 移轉至生產環境
如果您決定繼續進行 Azure 數據總管，並打算將 POC 叢集移轉至生產環境，強烈建議您讓 POC 叢集保持執行，並用它來設定生產叢集。 這可協助您確保不會遺失POC期間可能已套用的設定和優化。
將POC叢集移轉至生產環境之前，強烈建議您考慮、設計及決定下列因素：
- 功能性和非功能性需求
- 災害復原和高可用性需求
- 安全性需求
- 網路需求
- 持續整合/持續部署需求
- 監視和支援需求
- 在 Azure 數據總管中訓練重要人員
- 存取控制需求
- 架構、數據模型和數據流需求
- 擷取需求
- 視覺效果需求
- 數據和深入解析取用需求
- 測試需求