共用方式為

Synapse 實作成功方法：評估環境

  • 發行項

注意

本文會透過設計 一系列文章，形成 Azure Synapse 實作成功的一部分 。 如需系列的概觀，請參閱 Azure Synapse 實作成功設計 。

實作 Azure Synapse Analytics 的第一個步驟是對您的環境進行評估。 評定可讓您收集現有環境、環境需求、專案需求、條件約束、時程表和痛點的所有可用資訊。 這項資訊將形成後續評估與檢查點活動的基礎。 在驗證和比較專案方案時，它會證明無價，因為它已規劃、設計和開發。 我們建議您投入大量時間收集所有資訊，並務必與相關群組進行必要的討論。 相關群組可以包括現有解決方案和環境的專案專案專案關係人、商務使用者、解決方案設計師和主題專家（SME）。

此評量將會成為協助您評估解決方案設計的指南，並提供明智的技術建議來實作 Azure Synapse。

工作負載評估

工作負載評估與環境、分析工作負載角色、ETL/ELT、網路和安全性、Azure 環境和資料耗用量有關。

環境

針對環境，請評估下列幾點。

  • 描述您現有的分析工作負載：
    • 工作負載是什麼（例如資料倉儲或巨量資料）？
    • 此工作負載如何協助企業？ 使用案例有哪些？
    • 此分析平臺和潛在移轉的商業驅動因素為何？
    • 收集現有架構、設計和實作選項的詳細資料。
    • 收集所有現有上游和下游相依元件和取用者的詳細資料。
  • 您要移轉現有的資料倉儲 （例如 Microsoft SQL Server、Microsoft Analytics Platform System （APS）、Netezza、Snowflake 或 Teradata？
  • 您要移轉巨量資料平臺 （例如 Cloudera 或 Hortonworks）嗎？
  • 收集目前分析環境的架構和資料流程圖。
  • 您計劃性分析工作負載的資料來源位於何處（Azure、其他雲端提供者或內部部署）？
  • 現有資料集的總大小為何（歷程記錄和累加式） ？ 您資料集的目前成長率為何？ 未來 2-5 年資料集的預測增長率為何？
  • 您有現有的 Data Lake 嗎？ 盡可能收集檔案類型的詳細資料（例如 Parquet 或 CSV）、檔案大小和安全性設定。
  • 您是否有半結構化或非結構化資料可處理和分析？
  • 描述資料處理的本質（批次或即時處理）。
  • 您需要從關聯式資料、Data Lake 或其他來源進行互動式資料探索嗎？
  • 您需要作業資料來源的即時資料分析和探索嗎？
  • 目前環境中的痛點和限制為何？
  • 您目前使用哪些原始檔控制和 DevOps 工具？
  • 您是否有使用案例可建置混合式（雲端和內部部署）分析解決方案、僅限雲端或多雲端？
  • 收集現有雲端環境的相關資訊。 它是單一雲端提供者還是多雲端提供者？
  • 收集未來雲端環境的相關計畫。 它是否為單一雲端提供者或多雲端提供者？
  • 現有環境中的 RPO/RTO/HA/SLA 需求為何？
  • 規劃環境中的 RPO/RTO/HA/SLA 需求為何？

分析工作負載角色

針對分析工作負載角色，請評估下列幾點。

  • 描述不同的角色（資料科學家、資料工程師、資料分析師和其他角色）。
  • 描述這些角色的分析平臺存取控制需求。
  • 識別負責布建計算資源並授與存取權的平臺擁有者。
  • 描述不同資料角色目前如何共同作業。
  • 同一個分析平臺上是否有多個小組共同作業？ 如果是，這些小組的存取控制和隔離需求為何？
  • 使用者用來與分析平臺互動的用戶端工具為何？

ETL/ELT、轉換和協調流程

針對 ETL/ELT、轉換和協調流程，請評估下列幾點。

  • 您目前使用哪些工具進行資料擷取 （ETL 或 ELT）？
  • 這些工具存在於現有環境（內部部署或雲端）中的位置？
  • 您目前的資料載入和更新需求為何（即時、微批次、每小時、每日、每週或每月）？
  • 描述每個層的轉換需求（巨量資料、資料湖、資料倉儲）。
  • 目前轉換資料的程式設計方法為何（無程式碼、低程式碼、如 SQL、Python、Scala、C# 或其他程式設計）？
  • 轉換資料的慣用計劃性程式設計方法為何（無程式碼、低程式碼、SQL、Python、Scala、C# 或其他程式設計）？
  • 哪些工具目前用於資料協調流程，以自動化資料驅動程式？
  • 您現有 ETL 的資料來源位於何處（Azure、其他雲端提供者或內部部署）？
  • 需要與分析平臺整合的現有資料耗用量工具（報告、BI 工具、開放原始碼工具）為何？
  • 需要與分析平臺整合的計畫資料耗用量工具（報告、BI 工具、開放原始碼工具）為何？

網路和安全性

針對網路和安全性，請評估下列幾點。

  • 您的資料有哪些法規需求？
  • 如果您的資料包含客戶內容、支付卡產業（PCI）或 1996 年健康保險可攜性和責任法案（HIPAA）資料，您的安全性群組是否已針對此資料認證 Azure？ 如果是，則為哪一項 Azure 服務？
  • 描述您的使用者授權和驗證需求。
  • 是否有安全性問題可能會限制在實作期間存取資料？
  • 開發和測試期間是否有可供使用的測試資料？
  • 描述分析計算和儲存體的組織網路安全性需求（私人網路、公用網路或防火牆限制）。
  • 描述用戶端工具存取分析計算和儲存體的網路安全性需求（對等互連網路、私人端點或其他）。
  • 描述內部部署與 Azure 之間的目前網路設定（Azure ExpressRoute、站對站或其他）。

使用下列可能需求的檢查清單來引導您的評量。

  • 資料保護：
    • 傳輸中加密
    • 待用加密（預設金鑰或客戶管理的金鑰）
    • 資料探索與分類
  • 存取控制：
    • 物件層級安全性
    • 資料列層級安全性
    • 資料行層級安全性
    • 動態資料遮罩
  • 認證：
    • SQL 登入
    • Microsoft Entra ID
    • Multi-factor authentication (MFA) (NIST - 回到基本概念：Multi-Factor Authentication (MFA))
  • 網路安全性：
    • 虛擬網路
    • 防火牆
    • Azure ExpressRoute
  • 威脅防護：
    • 威脅偵測
    • 稽核
    • 弱點評估

如需詳細資訊，請參閱 Azure Synapse Analytics 安全性白皮書 。

Azure 環境

針對 Azure 環境，評估下列幾點。

  • 您目前正在使用 Azure 嗎？ 它是否用於生產工作負載？
  • 如果您使用 Azure，您正在使用哪些服務？ 您使用哪些區域？
  • 您是否使用 Azure ExpressRoute？ 其頻寬為何？
  • 您是否有預算核准來布建所需的 Azure 服務？
  • 您目前如何布建和管理資源 （Azure Resource Manager （ARM） 或 Terraform？
  • 您的關鍵小組是否熟悉 Synapse Analytics？ 是否需要任何訓練？

資料耗用量

針對資料耗用量，請評估下列幾點。

  • 描述您目前用來執行活動的方式和資料視覺效果，例如擷取、探索、準備和資料視覺效果。
  • 識別您計畫用來執行活動的工具，例如內嵌、探索、準備和資料視覺效果。
  • 哪些應用程式計畫與分析平臺互動（Microsoft Power BI、Microsoft Excel、Microsoft SQL Server Reporting Services、Tableau 或其他應用程式）？
  • 識別所有資料取用者。
  • 識別資料匯出和資料共用需求。

Azure Synapse 服務評量

Azure Synapse 服務評量與 Azure Synapse 內的服務有關。 Azure Synapse 具有下列用於計算和資料移動的元件：

  • Synapse SQL： 適用于 Transact-SQL （T-SQL） 的分散式查詢系統，可啟用資料倉儲和資料虛擬化案例。 它也會擴充 T-SQL 來解決串流和機器學習 （ML） 案例。 Synapse SQL 同時 提供無 伺服器和 專用 資源模型。
  • 無伺服器 SQL 集區： 分散式資料處理系統，專為大規模資料和計算函式所建置。 沒有基礎結構可設定或叢集來維護。 此服務適用于非計劃性或高載工作負載。 建議的案例包括直接在資料湖上的檔案、邏輯資料倉儲，以及原始資料的資料轉換上的快速資料探索。
  • 專用 SQL 集區： 代表使用 Synapse SQL 時所布建的分析資源集合。 專用 SQL 集區的大小（先前稱為 SQL DW）取決於資料倉儲單位（DWU）。 此服務適用于具有可預測、高效能連續工作負載的資料儲存在 SQL 資料表中的資料的資料倉儲。 
  • Apache Spark 集區： 深入且順暢地整合 Apache Spark，這是最常用於資料準備、資料工程、ETL 和 ML 的巨量資料引擎開放原始碼。
  • 資料整合管線： Azure Synapse 包含與 Azure Data Factory （ADF） 相同的資料整合引擎和體驗。 它們可讓您建立豐富的大規模 ETL 管線，而不需要離開 Azure Synapse。

若要協助判斷最佳的 SQL 集區類型（專用或無伺服器），請評估下列幾點。

  • 您要為儲存在 SQL 資料表中的資料保留處理能力，以建置傳統的關聯式資料倉儲嗎？
  • 您的使用案例需要可預測的效能嗎？
  • 您要在資料湖之上建置邏輯資料倉儲嗎？
  • 您要直接從 Data Lake 查詢資料嗎？
  • 您要探索資料湖中的資料嗎？

下表比較兩個 Synapse SQL 集區類型。

比較 專用 SQL 集區 無伺服器 SQL 集區
價值主張 資料倉儲的完整受控功能。 連續工作負載的可預測和高效能。 已針對受控（已載入）資料進行優化。 易於開始使用並探索 Data Lake 資料。 更適合臨機操作和間歇性工作負載的擁有權總成本 （TCO）。 已針對在 Data Lake 中查詢資料進行優化。
工作負載 適用于連續工作負載。 載入可提升效能，且複雜度更高。 每個 DWU 的收費（大小良好時）將是符合成本效益的。 適用于臨機操作或間歇性工作負載。 不需要載入資料，因此更容易啟動和執行。 每個使用量的收費將符合成本效益。
查詢效能 提供高並行和低延遲。 支援豐富的快取選項，包括具體化檢視。 使用工作負載管理 （WLM） 選擇取捨的能力。 不適用於儀表板查詢。 預計不會有毫秒回應時間。 它只適用于外部資料。

專用 SQL 集區評量

針對專用 SQL 集區評估，請評估下列平臺點。

  • 目前的資料倉儲平臺為何（Microsoft SQL Server、Netezza、Teradata、Greenplum 或其他） ？
  • 針對移轉工作負載，請針對每個環境判斷設備的製造和模型。 包含 CPU、GPU 和記憶體的詳細資料。
  • 針對設備移轉，何時購買硬體？ 設備是否已完全過時？ 如果沒有，折舊何時結束？ 還有多少資本支出？
  • 是否有任何硬體和網路架構圖表？
  • 規劃資料倉儲的資料來源位於何處（Azure、其他雲端提供者或內部部署）？
  • 資料倉儲資料來源的資料裝載平臺為何（Microsoft SQL Server、Azure SQL 資料庫、DB2、Oracle、Azure Blob 儲存體、AWS、Hadoop 或其他專案？
  • 是否有任何資料來源資料倉儲？ 如果是的話，哪一個？
  • 識別所有 ETL、ELT 和資料載入案例（批次視窗、串流、近乎即時）。 識別每個案例的現有服務等級協定（SLA），並在新環境中記錄預期的 SLA。
  • 目前的資料倉儲大小為何？
  • 專用 SQL 集區的目標資料整合長率為何？
  • 描述您目前使用的環境（開發、測試或生產環境）。
  • 目前有哪些工具可用於資料移動（ADF、Microsoft SQL Server Integration Services （SSIS）、robocopy、Informatica、SFTP 或其他工具？
  • 您是否打算載入即時或近乎即時資料？

評估下列資料庫點。

  • 每個資料倉儲中的物件數目為何（架構、資料表、檢視表、預存程式、函式）？
  • 它是星狀架構、雪花式架構或其他設計嗎？
  • 在記錄大小和數目方面，最大的資料表為何？
  • 以資料行數目而言，最寬的資料表為何？
  • 資料倉儲是否已設計資料模型？ 這是 Kimball、Inmon 或星型架構設計嗎？
  • 使用中緩時變維度 （SCD） 嗎？ 如果是，哪一種類型？
  • 語意層會使用關聯式資料超市或 Analysis Services（表格式或多維度）或其他產品來實作嗎？
  • HA/RPO/RTO/資料封存需求為何？
  • 區域複寫需求為何？

評估下列工作負載特性。

  • 在尖峰時段 存取資料倉儲 的並行使用者或作業估計數目為何？
  • 在離峰時段 存取資料倉儲 的並行使用者或作業估計數目為何？
  • 是否有一段時間沒有使用者或工作？
  • 您對於互動式查詢的查詢執行效能預期為何？
  • 您每天/每週/每月資料載入或更新的資料載入效能預期為何？
  • 報表和分析查詢的查詢執行預期為何？
  • 最常執行的查詢有多複雜？
  • 您的使用中資料集大小總計百分比為何？
  • 大約預期要載入或更新、批次處理或報告、互動式查詢和分析處理的工作負載百分比為何？
  • 識別取用模式和平臺的資料：
    • 目前和計畫的報告方法和工具。
    • 哪些應用程式或分析工具會存取資料倉儲？
    • 並行查詢的數目？
    • 在任何時間點的平均使用中查詢數目？
    • 資料存取的本質為何（互動式、臨機操作、匯出或其他專案）？
    • 資料角色及其資料需求的完整描述。
    • 並行連線數目上限。
  • 查詢效能 SLA 模式的方式如下：
    • 儀表板使用者。
    • 批次報告。
    • ML 使用者。
    • ETL 程式。
  • 現有環境與新環境的安全性需求為何（資料列層級安全性、資料行層級安全性、存取控制、加密和其他專案）？
  • 您是否需要整合 ML 模型評分與 T-SQL？

無伺服器 SQL 集區評量

Synapse 無伺服器 SQL 集區支援三個主要的使用案例。

  • 基本探索和探索： 快速推斷 Data Lake 中各種格式的資料（Parquet、CSV、JSON），以便規劃如何從中擷取深入解析。
  • 邏輯資料倉儲： 在未經處理或不同的資料上提供關聯式抽象概念，而不需要重新置放和轉換資料，即可讓您隨時檢視資料。
  • 資料轉換： 使用 T-SQL 在湖中轉換資料的簡單、可調整且高效能的方式，因此可以饋送給 BI 和其他工具，或載入關聯式資料存放區（Synapse SQL 資料庫、Azure SQL 資料庫或其他工具）。

不同的資料角色可以受益于無伺服器 SQL 集區：

注意

T-SQL 語言同時用於專用 SQL 集區和無伺服器 SQL 集區，但支援的功能集有一些差異。 如需 Synapse SQL 中支援 T-SQL 功能的詳細資訊（專用和無伺服器），請參閱 Azure Synapse SQL 中支援的 Transact-SQL 功能。

針對無伺服器 SQL 集區評估，請評估下列幾點。

  • 您是否有使用案例來探索和探索資料湖中的資料，方法是使用關聯式查詢 （T-SQL） ？
  • 您是否有使用案例在資料湖之上建置邏輯資料倉儲？
  • 識別是否有使用案例可轉換 Data Lake 中的資料，而不需先從 Data Lake 移動資料。
  • 您的資料已在 Azure Data Lake 儲存體 （ADLS） 或 Azure Blob 儲存體中嗎？
  • 如果您的資料已經在 ADLS 中，您在 Data Lake 中是否有良好的資料分割策略？
  • 您有 Azure Cosmos DB 中的作業資料嗎？ 您是否有 Azure Cosmos DB 即時分析的使用案例，而不會影響交易？
  • 識別 Data Lake 中的檔案類型。
  • 識別查詢效能 SLA。 您的使用案例需要可預測的效能和成本嗎？
  • 您是否有非計劃性或高載 SQL 分析工作負載？
  • 識別取用模式和平臺的資料：
    • 目前和計畫的報告方法和工具。
    • 哪些應用程式或分析工具會存取無伺服器 SQL 集區？
    • 在任何時間點的平均使用中查詢數目。
    • 資料存取的本質為何（互動式、臨機操作、匯出或其他專案）？
    • 資料角色及其資料需求的完整描述。
    • 並行連線數目上限。
    • 查詢複雜度？
  • 安全性需求（存取控制、加密和其他需求）為何？
  • 必要的 T-SQL 功能（預存程式或函式）為何？
  • 識別將傳送至無伺服器 SQL 集區和每個查詢結果集大小的查詢數目。

提示

如果您不熟悉無伺服器 SQL 集區，建議您使用 Azure Synapse 無伺服器 SQL 集 區學習路徑來建 置資料分析解決方案。

Spark 集區評量

Azure Synapse 中的 Spark 集區可啟用下列主要案例。

  • 資料工程/資料準備： Apache Spark 包含許多語言功能，可支援準備和處理大量資料。 準備和處理可讓資料更有價值，並讓其他 Azure Synapse 服務取用資料。 它可透過多種語言啟用 （C#、Scala、PySpark、Spark SQL），以及使用提供的程式庫來處理和連線。
  • 機器學習： Apache Spark 隨附 MLlib ，這是建置在 Spark 之上的 ML 程式庫，您可以從 Spark 集區使用。 Spark 集區也包含 Anaconda，這是 Python 散發套件，其中包含各種資料科學套件，包括 ML。 此外，Synapse 上的 Apache Spark 為 Microsoft 機器學習 提供預先安裝的程式庫 ，這是容錯、彈性和 RESTful ML 架構。 結合筆記本的內建支援時，您有豐富的環境可建立 ML 應用程式。

注意

如需詳細資訊，請參閱 Azure Synapse Analytics 中的 Apache Spark。

此外，Azure Synapse 與 Linux Foundation Delta Lake 相容。 Delta Lake 是開放原始碼儲存層，可將 ACID （不可部分完成性、一致性、隔離和持久性）交易帶入 Apache Spark 和巨量資料工作負載。 如需詳細資訊，請參閱 什麼是 Delta Lake 。

針對 Spark 集區評估，請評估下列幾點。

  • 識別需要資料工程或資料準備的工作負載。
  • 清楚定義轉換的類型。
  • 識別您是否有非結構化資料要處理。
  • 當您從現有的 Spark/Hadoop 工作負載移轉時：
    • 什麼是現有的巨量資料平臺（Cloudera、Hortonworks、雲端服務或其他）？
    • 如果是從內部部署移轉，硬體已過時或授權已過期？ 如果沒有，何時會發生折舊或到期？
    • 什麼是現有的叢集類型？
    • 必要的程式庫和 Spark 版本為何？
    • 這是 Hadoop 移轉至 Spark 嗎？
    • 目前或慣用的程式設計語言為何？
    • 工作負載類型為何（巨量資料、ML 或其他）？
    • 現有和規劃的用戶端工具和報告平臺為何？
    • 安全性需求為何？
    • 是否有任何目前的痛點和限制？
  • 您打算使用或目前正在使用 Delta Lake 嗎？
  • 您目前如何管理套件？
  • 識別必要的計算叢集類型。
  • 識別是否需要叢集自訂。

提示

如果您不熟悉 Spark 集區，建議您使用 Azure Synapse Apache Spark 集 區執行資料工程學習路徑。

下一步

在 Azure Synapse 成功設計 系列中的下一篇文章 中，瞭解如何評估 Synapse 工作區設計，並驗證其是否符合指導方針和需求。