Azure Data Explorer POC 劇本：巨量數據分析

  • 發行項

本文提供準備和執行有效 Azure Data Explorer 概念證明的高階方法， (POC) 專案。

開始之前

劇本可協助您評估 Azure Data Explorer 的使用，並專為最適合 Azure 數據探索的案例所設計。 在啟動 POC 之前，請使用下列案例來判斷 Azure Data Explorer 是否為您正確解決方案。

一般結構模式案例

  • 符合下列一或多個特性的任何數據都應該是 Azure Data Explorer 的良好候選專案：
    • 大量且快速
    • 僅限附加且不可變的資料
    • 資料靜止：不會變更的資料。 例如，線上商店訂單就是靜止資料的一個好例子。
  • 命令查詢責任隔離 (CQRS) 模式適用於 Azure Data Explorer 的附加架構。
  • 事件來源模式

其他案例

下列案例也是 Azure Data Explorer 的良好候選專案：

準備 POC

POC 專案可協助您做出明智的商務決策，以在使用 Azure Data Explorer 的雲端式平臺上實作巨量數據和進階分析環境。

POC 專案會識別雲端式巨量資料和進階分析平台必須支援的重要目標和業務動力。 還會測試關鍵計量並證明關鍵行為，這些都攸關資料工程、建立機器學習模型和定型需求的成敗。 POC 並非設計成部署至實際執行環境。 而是著重於關鍵問題的短期專案，可捨棄結果。

開始規劃 Azure Data Explorer POC 專案之前：

  • 識別組織在資料移至雲端方面的任何限制或指導方針。
  • 識別巨量資料和進階分析平台專案的主管或業務贊助者。 鞏固其對於移轉至雲端的支援。
  • 確定在 POC 執行期間是否有技術專家和商務使用者為您提供支援。

開始準備 POC 專案前，建議您先閱讀 Azure 資料總管文件。

現在您應該確定目前已無障礙，所以可以開始準備 POC。 如果您不熟悉 Azure Data Explorer，可以參閱這份檔，您可以在其中取得 Azure Data Explorer 架構的概觀。

了解這些重要概念：

  • Azure Data Explorer 及其架構。
  • 支援資料格式和資料來源。
  • 叢集、資料庫、數據表、具體化檢視，以 Azure Data Explorer 成品的形式運作。
  • 擷取精靈和連續擷取的支援擷取方法。
  • Azure Data Explorer 中的驗證和授權。
  • 整合 Power BI、Grafana、Kibana 等視覺效果解決方案的原生連接器。
  • 建立外部資料表，從 Azure SQL/SQL Server、Azure Cosmos DB、Azure 監視器、Azure Digital Twin 讀取資料。

Azure Data Explorer 將計算資源與記憶體分離，以便更妥善地管理數據處理需求和控制成本。 您只需支付使用計算的費用。 不使用時，只需要支付儲存體的費用。 Azure Data Explorer 的受控服務架構可讓您獨立調整叢集與記憶體。 您可以相應增加和縮小 (垂直) ，以及相應放大 (水準) 。 您也可以手動停止或 自動停止叢集，而不會遺失您的數據。 例如，您可以相應增加叢集以取得大量數據處理需求或大型負載，然後在較不密集的處理時間將其相應減少，或完全關閉。 同樣地，您可以在週末有效地調整和停止叢集，以降低成本。

設定目標

成功的 POC 專案需要規劃。 首先，明白您為何執行 POC，以完整瞭解真實動機。 動機可能包括現代化、節省成本、改善效能或整合式體驗。 請務必寫下 POC 的明確目標，並設定其成功準則。 自問：

  • 您想要從 POC 獲得什麼輸出？
  • 您要怎麼使用這些輸出？
  • 誰會使用輸出？
  • 如何確定 POC 成功？

請記住，POC 應該簡短而且有重點，以快速證明少量的概念和功能。 這些概念和功能應該足以代表整體工作負載。 如果您有一長串的項目要證明，請規劃多個 POC。 在此情況下，請定義 POC 之間的關卡，以決定是否需要繼續下一個 POC。 例如，一個 POC 可能專注於資料工程角色的需求，例如擷取和處理。 另一個 POC 可能專注於機器學習 (ML) 模型開發。

在考慮 POC 目標時，請自問下列問題，以協助您塑造目標：

  • 您是否從現有的巨量資料和進階分析平台移轉 (內部部署或雲端)？
  • 您是否正要移轉，同時又想在過程中進行一些多方面的改善呢？ 例如，從彈性搜尋移轉至 Azure Data Explorer 以進行記錄分析、從 InfluxDB 或 Timescale DB 移轉至 Azure Data Explorer。
  • 您是否建立全新的巨量資料和進階分析平台 (綠地專案)？
  • 您目前有什麼難題？ 例如，可擴縮性、效能或彈性。
  • 您需要支援哪些新的商務需求？
  • 您需要符合哪些 SLA？
  • 工作負載有哪些？ 例如，ETL、批次處理、串流處理、機器學習模型定型、分析、報告查詢或互動式查詢？
  • 擁有專案的使用者有什麼技能 (應該實作 POC)？ 例如，SQL、Python、PowerBI 或其他技能。

以下是 POC 目標設定的一些範例：

  • 為什麼執行 POC？
    • 必須知道巨量資料工作負載的資料擷取和處理效能會符合新的 SLA。
    • 必須知道近乎即時的串流處理是否可行，以及可支援多少輸送量。 (是否支援商務需求？)
    • 必須知道現有的資料擷取和轉換流程是否合適，以及需要改善之處。
    • 必須知道是否可以縮短資料整合執行時間，以及縮短多少。
    • 我們需要知道數據科學家是否可以建置和定型機器學習模型，並視需要在 Azure Data Explorer 中使用 AI/ML 連結庫。
    • 移至雲端式 Azure Data Explorer 是否符合我們的成本目標？
  • 在此 POC 結束時：
    • 我們使用資料判斷批次和即時串流是否符合資料處理效能需求。
    • 我們會測試擷取和處理所有支援使用案例的不同資料類型 (結構化、半結構化和非結構化)。
    • 我們將測試過一些現有的數據處理需求，並可識別可在 Azure Data Explorer 中使用更新原則完成的工作。
    • 我們會測試資料擷取和處理，然後使用資料點估計初始移轉所需的投入量，及歷程記錄資料的負載。
    • 我們會測試資料擷取和處理，然後即可判斷是否符合 ETL/ELT 處理需求。
    • 我們會取得深入解析以更準確估計完成實作專案所需的投入量。
    • 我們會測試規模和調整選項，然後會有資料點以更妥善設定平台，提供更好的性價設定。
    • 我們會取得可能需要進一步測試的項目清單。

規劃專案

根據目標來指明特定的測試及提供您發現的輸出。 請務必確保至少有一個測試可支援每個目標和預期的輸出。 此外，請指明特定的資料擷取、批次或串流處理，及之後要執行的其他程序，以確認一組特定的資料集和程式碼基底。 此具體資料集和程式碼基底將定義 POC 的範圍。

以下是使用 Azure Data Explorer 評估的典型主題區域：

  • 數據擷取和處理：數據源、數據格式、擷取方法、連接器、工具、擷取原則、串流與佇列擷取
  • 資料儲存體：結構描述、儲存體成品，例如資料表和具體化檢視
  • 原則：例如資料分割、更新、合併
  • 查詢和視覺效果
  • 效能：例如查詢回應時間、擷取延遲、弱式一致性、查詢快取結果
  • 成本：擁有權總成本 (TCO)
  • 安全性：例如驗證、授權、資料存取、資料列層級安全性

注意

使用下列常見問題協助您規劃 POC。

  • 如何? 選擇POC叢集的SKU嗎？
    使用選取 Azure Data Explorer 叢集的 SKU 指南，協助您選擇 POC 叢集的 SKU。 啟動 POC 時，建議您從較小的 SKU 開始，並在開始測試和擷取結果時視需要相應增加 SKU。
  • 如何? 建立POC叢集時選擇快取期間？
    為提供最佳查詢效能，SSD 硬碟會快取內嵌的資料。 此種效能層級不一定是必要的，而且較不常查詢的資料通常可以儲存在較便宜的 Blob 儲存體。 對 Blob 儲存體中資料的查詢執行速度會較慢，但大多數情況下是可以接受的。 了解這點有助您確定在本機 SSD 中保存資料所需的計算節點數目，以繼續符合您的查詢效能需求。 例如，如果您要更頻繁查詢 x 天的資料 (根據擷取存留期)、保留資料 y 天並較少查詢資料，請在快取保留原則中，指定 x 為熱快取保留期的值，及 y 為總保留期的值。 如需詳細資訊，請參閱快取原則。
  • 如何? 建立POC叢集時選擇保留期間？
    保留期間是可供查詢的冷熱快取資料組合。 請根據合規性或其他法規需求，及所需保留資料的時間，來選擇資料保留期。 如需加快任何稽核用途的查詢，您可以使用經常性存取時段 (hot window) 功能，提升極非經常性存取快取 (cold cache) 中儲存的資料。 如需詳細資訊，請參閱使用經常性存取時段查詢極非經常性存取資料。

以下是規劃時所需具體程度的範例：

  • 目標 A：必須知道在我們定義的 SLA 下，是否符合資料擷取和處理批次資料的需求。
  • 輸出 A：我們將擁有數據來判斷佇列資料擷取和處理是否符合批次數據處理需求和 SLA。
    • 測試 A1：因為處理查詢 A、B 和 C 通常是由資料工程小組所執行，這三者可視為良好的效能測試。 也代表整體資料處理需求。
    • 測試 A2：因為處理查詢 X、Y 和 Z 包含近即時的串流處理需求，這三者可視為良好的效能測試。 也代表整體事件型串流處理需求。
    • 測試 A3：比較這些查詢在不同規模的叢集效能 (叢集 SKU、實例數目) ，以及從現有系統取得的基準檢驗。
  • 目標 B：我們需要知道商務使用者是否可以在此平台上組建儀表板。
  • 輸出 B：我們將使用不同的視覺效果選項、連接器和 Kusto 查詢，測試叢集中數據的一些現有儀錶板和視覺效果。 這些測試有助決定可移轉至新環境的儀表板。
    • 測試 B1：將會使用 Azure Data Explorer 資料建立特定視覺效果，並進行測試。
    • 測試 B2：測試立即可用的 KQL 函式和運算子，以滿足需求。
  • 目標 C：我們會測試資料擷取，並獲得資料點用以：
    • 預估初始歷程記錄數據移轉至 Azure Data Explorer 叢集的工作。
    • 規劃方法來移轉歷史資料。
  • 輸出 C：我們會測試並判斷環境中可達到的資料擷取速率，可判斷資料擷取速率是否足以在可用的期間內移轉歷史資料。
    • 測試 C1：測試不同的歷史資料移轉方法。
    • 測試 C2：使用 Blob 記憶體或 Data Lake Store 的 LightIngest、連續擷取，測試從數據源到叢集的數據傳輸。 如需詳細資訊，請參閱 內嵌歷程記錄數據。
  • 目標 D：我們會測試累加資料載入的資料擷取速率，並取得資料點來估計資料擷取和處理時間長度。
  • 輸出 D：我們會測試資料擷取速率，可判斷資料擷取和處理需求是否符合已識別的方法。
    • 測試 D1：每天、每小時和近即時測試資料擷取和處理。
    • 測試 D2：在執行使用者查詢時，執行連續 (佇列或串流) 數據擷取和處理。

請務必新增多個測試情節來改善測試。

以下是一些測試情節：

  • Azure Data Explorer 測試 A：我們將跨多個叢集 SKU 大小執行數據擷取、處理和查詢， (記憶體優化或計算優化) ，以及不同的叢集實例數目。
  • Azure Data Explorer 測試 B：我們將使用儀錶板和查詢工具，例如 Azure Data Explorer Web UI 查詢叢集中處理的數據。

以下是可用來協助您規劃 POC 的高階工作範例：

Sprint Task
0 向客戶小組展示和示範 Azure Data Explorer
0 定義客戶想要使用 Azure Data Explorer 達成的商務案例
0 定義資料來源、擷取方法、資料保留、資料快取、SLA、安全性、網路、IAM 方面的技術需求
0 定義關鍵效能量值，例如查詢效能預期、延遲、並行要求、擷取整個數據更新
0 使用 Azure Data Explorer 及其數據擷取器和取用者定義高階架構
0 定義 POC 範圍
0 定義 POC 規劃和時程表
0 定義、設定優先權並衡量 POC 評估準則
1 定義並針對要測試的查詢設定優先權
1 定義每個使用者群組的資料存取規則
1 估計一次性 (歷史性) 資料擷取量和每日資料擷取量
1 定義資料保留、快取和清除策略
1 定義建立叢集時所需的組態元素，例如串流、Python/R 外掛程式、清除
1 檢閱來源資料格式、結構、結構描述
1 檢閱、精簡、修改評估準則
1 根據適用於 Azure 的 Azure 定價計算機建置定價案例 Data Explorer
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，請識別您已就緒的任何資源 (Microsoft Entra 識別碼、ExpressRoute 和其他) ，您可以在 POC 期間使用。 還要指明組織使用的 Azure 區域。 此時最好指明 ExpressRoute 連線的輸送量，並向其他商務使用者確認您的 POC 可以取用某些輸送量，而不會對生產系統造成負面影響。

如需詳細資訊，請參閱巨量資料架構。

指明 POC 資源

具體指明支援 POC 所需投入的技術資源和時間。 POC 將需要：

  • 業務代表，監督需求和結果。
  • 應用程式資料專家，負責供應資料給 POC，並提供現有流程和邏輯的知識。
  • Azure Data Explorer 專家。 如有需要，您可以要求 Microsoft 連絡人安排。
  • 專家顧問，最佳化 POC 測試。 如有需要，您可以要求 Microsoft 連絡人安排。
  • POC 專案的特定元件會需要資源，但 POC 期間不一定需要。 這些資源可能包括網路管理員、Azure 管理員、Active Directory 管理員、Azure 入口網站管理員和其他人。
  • 請務必佈建所有必要的 Azure 服務資源，並授與必要的存取等級，包括儲存體帳戶的存取權。
  • 請確定您有一個帳戶具有必要的資料存取權限，可從 POC 範圍中的所有資料來源擷取資料。

秘訣

建議洽詢專家顧問以為 POC 提供協助。 請連絡您的 Microsoft 帳戶小組，或連絡可協助您評估、評估或實作 Azure Data Explorer 專家顧問的全球可用性。 您也可以使用 Azure Data Explorer 標籤在 Stack Overflow 上張貼問題。

設定時間軸

檢閱 POC 規劃詳細資料和商務需求，以確認 POC 的時間範圍。 實際估計完成 POC 目標所需的時間。 POC 資料集大小、測試次數和複雜度，以及要測試的介面數目，將會影響完成 POC 所需的時間。 如果您估計 POC 會執行四週以上，請考慮縮小 POC 範圍來專注於最優先的目標。 繼續之前，請務必獲得所有主要人士和贊助者的核准與承諾。

實作 POC

建議以生產專案的紀律和嚴格性來執行 POC 專案。 按計劃執行專案，並管理變更要求程序，以防止 POC 範圍成長失控。

以下是高階工作的一些範例：

  1. 建立 Azure Data Explorer 叢集，以及 POC 方案中識別的所有 Azure 資源。

  2. 載入 POC 資料集：

    • 從來源擷取或在 Azure 中建立範例資料，以提供資料給 Azure。 如需在 Azure Data Explorer 中擷取數據的初始測試，請使用擷取精靈。
    • 測試您計劃用來將資料內嵌至叢集的連接器/整合方法。

  3. 在查詢資料寫入 Kusto 查詢：

  4. 執行測試：

    • 您可以使用不同的用戶端介面，例如儀錶板、PowerBIm 和 Azure Data Explorer Web UI，在叢集上平行執行許多測試。
    • 您可以使用 JMeter 或 Grafana k6 建立負載測試。
    • 以可取用又易懂的格式記錄結果。

  5. 優化查詢和叢集：

    • 無論是撰寫新的 KQL 查詢，或是從其他語言轉換現有的查詢，建議您檢查查詢是否遵循查詢最佳做法。
    • 根據測試結果，您可能需要使用快取原則、數據分割原則、叢集大小或其他優化來微調叢集。 如需建議，請參閱使用 Azure Data Explorer 優化高並行

  6. 監視疑難排解和效能：

  7. 估算定價：

    • 在 POC 結束時，您應該使用您在 POC 中學到的內容來估計符合您需求的叢集 成本 。

  8. 關閉 POC：

    • 記錄 POC 階段的結果、經驗和成果，包括您在 POC 期間套用的基準、設定、最佳化。
    • 清除 POC 期間建立，但不再需要的任何 Azure 資源。

    提示

    如果您決定繼續進行 Azure Data Explorer，並想要將其遷移至生產環境，建議您讓 POC 叢集保持執行。 這可協助您設定生產叢集，以確保不會遺失您在POC期間可能已套用的設定和優化。

解讀 POC 結果

完成所有 POC 測試時，請評估結果。 首先，評估是否符合 POC 結果和是否已收集所需的輸出。 判斷是否需要更多測試，或是否需要解決任何問題。

從 POC 移轉至實際執行環境

如果您決定繼續進行 Azure Data Explorer，並想要將 POC 叢集移轉至生產環境，強烈建議您讓 POC 叢集保持執行狀態，並使用它來設定生產叢集。 這有助確保 POC 期間可能套用的設定和最佳化不遺失。

將POC叢集移轉至生產環境之前，強烈建議您考慮、設計和決定下列因素：

  • 功能和非功能需求
  • 災害復原和高可用性需求
  • 安全性需求
  • 網路連線需求
  • 持續整合/持續部署需求
  • 監視和支援需求
  • 在 Azure Data Explorer 中訓練重要人員
  • 存取控制需求
  • 結構描述、資料模型和資料流程需求
  • 擷取需求
  • 視覺效果需求
  • 資料和深入解析使用需求
  • 測試需求

相關內容