Azure的資料整合設計

現今的企業，資料通常散落在各處(包含雲端)。通常我們都需要建立一個雲端數據解決方案，該解決方案主要在處理對傳統資料庫系統來說太大且太複雜的資料的擷取(ingestion)，處理(processing)與分析。 我們被要求確定如何最好地組合這些多個資料來源； 將其重新格式化為分析模型，並保存這些模型以供後續的數據查詢、報告和可視化。

本文中，我們將有以下的學習目標：

• 使用 Azure Data Factory設計資料整合解決方案
• 使用 Azure Data Lake 設計資料整合解決方案
• 使用 Azure Databricks 設計資料整合和分析解決方案
• 使用 Azure Synapse Analytics 設計資料整合和分析解決方案
• 設計資料的hot/warm/cold data path策略
• 設計用於資料分析的 Azure Stream Analytics solution

使用 Azure Data Factory設計資料整合解決方案

如果我們是一家成長快速的公司，一個重大挑戰是我們的平台可能會產生大量的資料，資料散佈在雲端和地端的關聯、非關聯或其他類型存儲系統中。管理高層希望盡可能即時從這些資料中獲得可運作的業務洞察力。此外，銷售團隊希望建立和推出追加銷售(up-selling) 與 交叉銷售(cross-selling) 方案。我們將如何在雲端中創建大規模資料整合解決方案？我們將採用哪些 Azure service和解決方案來幫助在各種資料存儲和運算資源之間移動和轉換資料？

Azure Data Factory是一種基於雲端的ETL 和資料整合服務，可以協助我們建立從不同資料存儲中擷取資料的資料導向工作流程（也稱為流水線pipeline）。我們可以使用 Azure Data Factory

• 大規模的資料移動。
• 大規模的轉換資料。

資料導向工作流程

在 Azure Data Factory中建立和實施Data-driven的工作流程有四個主要步驟。如下圖所示，它們分別是：

1. Connect and collect — — 資料導入是將來自不同來源的所有資料收集到一個集中位置的第一步。
2. Transform and enrich — — 現在我們將使用 Azure Databricks 和 Azure HDInsight Hadoop 等運算服務來”轉換/強化”資料
3. Continuous integration and delivery (CI/CD) and publish— — 通過 GitHub 和 Azure pipeline支援 CI/CD，可以在將資料傳送到分析引擎之前逐步交付的 ETL 流程。
4. Monitor — 通過 Azure portal，我們可以監控計劃活動和任何故障的pipeline。

下圖顯示了 Azure Data Factory協調從不同資料來源導入資料。 資料被導入Storage Blob 並存儲在 Azure Synapse Analytics 中。 分析和可視化組件也連接到 Azure Data Factory。 Azure Data Factory為所有資料整合需求提供了一個通用管理界面。

何時使用Azure Data Factory?

我們根據以下決策標準評估是否使用 Azure Data Factory：

• 需要資料導入— — Azure Data Factory使用於兩個地方 — — 大數據和SQL Server Integration Services(SSIS) 的Relational data warehousing。根據需求，我們可以使用 Azure Data Factory在雲端中設置pipeline，Data Factory可以存取來自雲端和地端的資料來源。
• 編寫代碼的資源 — 如果我們更喜歡圖形界面來設置pipeline，那麼 Azure Data Factory 編寫和監視工具非常適合這個需求。 Azure Data Factory提供用於處理資料來源的low code/no code process
• 連接多個資料來源— — Azure Data Factory支援 90 多個連接器來整合不同的資料來源。
• 無伺服器的基建 — 使用全託管的serverless解決方案進行資料整合具有優勢 — 無需維護、配置或部署服務器，並且能夠根據不固定的工作負載進行擴展。

Azure Data Factory的組件

如上圖所示，Azure Data Factory具有以下組件，它們會協同作業以提供資料的移動和資料整合平台。

• Pipelines and activities — 執行作業的活動邏輯群組。activity是pipeline中的單一處理步驟。 Azure Data Factory支援資料的移動、轉換和控制作業。
• Datasets — — 這些是資料存儲中的資料結構。
• Linked services — 定義 Azure Data Factory連接到外部資源所需的連接資訊。
• Data Flows— — Data flow允許資料工程師在不編寫code的情況下開發資料轉換邏輯。可以使用現有的 Azure Data Factory 進行scheduling/ control/ flow/monitoring功能來操作資料流程活動。
• Integration Runtimes — — 它是activity和linked service object之間的橋樑。共有三種類型的Integration Runtimes，包括 Azure、self-hosted和 Azure-SSIS。

讓我們看一下Azure Data Factory的組件如何參與組織內的資料準備階段和移動場景。他們有許多不同的資料來源要連接，並且需要通過在資料上運行的存儲過程來攝取(ingest)和轉換資料。最後，將資料推送到分析平台進行分析。

• 在這種情況下，Linked Service 使我們能夠從不同來源擷取資料，並存儲connection strings進行on-demand的運算服務。
• 可以通過 Azure SSIS 中的Linked Service執行資料轉換的存儲過程，Azure SSIS 是我們的integration runtime environment。
• Datasets 組件是被activity object使用，activity object包含轉換邏輯。
• 可以觸發pipeline — 即所有activity組合在一起。
• 然後，可以使用Data Factory將最終dataset發佈到另一個linked service，該服務由 Power BI 或機器學習等技術使用。

使用 Azure Data Lake 設計資料整合解決方案

組織內可能有多種資料來源，從電商網站到POS系統，社交媒體網站到IoT Devices。 組織有興趣使用 Azure 分析所有業務資料。 在這個角色中，我們將提供有關 Azure 如何增強其現有 BI 系統的指引。 我們還將提供有關使用 Azure 的存儲功能為其 BI 解決方案增加價值的建議。 由於組織的需求，我們可以推薦 Azure Data Lake Storage。 Data Lake Storage 提供了一個存儲庫，我們可以在其中上傳和存儲大量非結構化資料，著眼於高效能的大數據分析。

Azure Data Lake Storage

Data Lake是以資料原始格式存儲的資料存儲庫(基於Hadoop)，通常以 blob 或檔案的形式存儲。 Azure Data Lake Storage 是一個全面、可擴展且經濟高效的Data Lake解決方案，內建於 Azure 中的大數據分析。 Azure Data Lake Storage 將file system與storage platform相結合，幫助我們快速識別對資料的見解。 Data Lake Storage Gen2 基於 Azure Blob 存儲功能構建，專門針對分析工作負載進行優化。 這種整合支援 Azure Storage的分析效能、高可用性、安全性和持久性。

Azure Data Lake Storage

以下為Azure Data Lake的功能表列與說明:

Azure Data Lake Storage的作業流程

以下是Azure Data Lake Storage 的三個重要步驟。它們分別是:

導入資料— Azure Data Lake Storage 提供了許多不同的資料導入方法。

• 對於ad hoc data — 使用 AzCopy、CLI、PowerShell、Storage Explorer等工具。
• 對於關聯式資料 — 使用 Azure Data Factory 。 它使我們能夠從任何來源傳輸資料，包括 Cosmos DB、SQL DB、 Managed instances等。
• 對於串流資料-使用 Azure HDInsight 上的 Apache Storm、 Azure Stream Analytics 等工具。

下圖顯示如何在 Azure Data Lake Storage 中bulk ingestion或ad hoc ingestion和streaming data。

存取儲存資料
存取資料的最簡單方法是使用 Azure Storage Explorer。 Storage Explorer是 GUI 的獨立應用程式，用於存取 Azure Data Lake Storage data。 我們還可以使用 PowerShell、 Azure CLI、HDFS CLI 或其他開發語言 的SDK 來存取資料。

設定存取控制
若要控制誰可以存取存儲在 Azure Data Lake Storage 中的資料，可以實施以下一種或兩種授權機制：

• Azure RBAC
• ACL

何時使用Azure Data Lake Storage

下表為在一些狀況下我們可以使用 Azure Data Lake Storage

何時選擇Azure Blob Storage而不是Azure Data Lake

讓我們看看一些標準，這些標準將幫助我們決定何時選擇一種存儲解決方案而不是另一種。 在下表中，將兩種存儲解決方案與一組標準進行比較。

使用 Azure Databricks 設計資料整合和分析解決方案

Azure Databricks 是一個全託管的的大數據和機器學習平台(基於Apache Spark)。 Azure Databricks 為資料科學和技術團隊提供用於大數據處理和機器學習的單一平台。 Azure Databricks 是一個"託管 的Apache Spark 平台"讓我們運行大規模 Spark 工作負載變得簡單。

Azure Databricks 提供了三種用於開發data intensive applications的環境:

• Databricks SQL:
  Azure Databricks SQL 為想要在其Data Lake上執行 SQL 查詢的分析師提供一個易於使用的平台。 可以建立多個視覺效果類型，從不同的觀點探索查詢結果，然後建置和共用儀表板。
• Databricks Data Science & Engineering:
  這是一個互動式「工作區」，可在資料工程師、資料科學家和機器學習工程師之間實現共同作業。 對於big data pipeline，資料 (raw or structured) 會透過 Azure Data Factory 分批擷取到 Azure 中，或使用 Apache Kafka、Azure Event Hubs或 Azure IoT Hub，以近即時的方式進行串流處理。 此資料會放置在Data Lake中，長期持續儲存於 Azure Blob storage或 Azure Data Lake Storage 中。 做為分析工作流程的一部分，使用 Azure Databricks，從多個資料來源讀取資料，並使用 Spark 來將其轉換。
• Databricks Machine Learning:
  這是整合式端對端機器學習環境。 其中包含用於experiment tracking、 model training、feature development與管理，以及功能與模型服務的託管服務。

分析組織的需求後我們可能可以用 Azure Databricks 方案。 我們正在利用 Azure cloud service來滿足我們的大數據需求 — — 資料有batch data 與streaming data。我們有資料工程師、資料科學家和資料分析師，他們協作為許多組織內業務單位快速產生有洞察力的報告。

在上述場景中，我們選擇 Databricks 資料科學與工程環境，因為：

• 它提供了一個基於 Apache Spark 的整合分析“工作區”，允許不同user之間的協作
• 使用 Spark SQL 和 Dataframes 等 Spark components，它可以處理結構化資料，並與 Kafka 和 Flume 等real-time data ingestion tools整合來處理streaming data
• 基於 Spark 構建的Secure data integration capabilities使我們無需集中即可統一資料，資料科學家只需點幾下滑鼠即能可視化資料，並使用 Matplotlib、ggplot 或 d3 等熟悉的工具。
• Runtime抽象出基礎架構的複雜性以及設置和配置資料基礎架構對專業知識的需求，因此User可以使用他們熟悉的語言（如 Python、Scala、R）並探索資料
• 還跟 Azure databases 與stores深度整合：Synapse Analytics、Cosmos DB、Data Lake Store 和 Blob storage
• 與 Power BI 的整合允許快速而有意義的見解，
• Databricks SQL無法處理非結構化資料
• Databricks 是機器學習的解決方案

Azure Databricks的作業流程

如下圖所示，

• 左側有一個control plane，它託管 Databricks jobs、帶有查詢結果的notebooks、cluster manager、Web application、Hive metastore以及ACL 和user sessions。 這些組件由 Microsoft 與 Databricks 合作管理，不是放在我們的 Azure subscriptions中。
• 右側是data plane，其中包含工作區中託管的所有 Databricks runtime clusters。 所有資料處理和存儲都存在於我們的subscriptions中。 這意味著在 Microsoft/Databricks — managed subscription中不會進行任何資料處理。

何時該用 Azure Databricks

Azure Databricks 完全基於 Apache Spark，因此對於那些已經熟悉open-source cluster-computing framework的人來說是一個很好的工具。作為一個統一的分析引擎，它專為大數據處理而設計，資料科學家可以利用 SQL、Java、Python、R 和 Scala 等核心語言的內建API。

可以將 Azure Databricks 用作以下場景的解決方案。

• 資料科學的準備階段 — — Create, clone 與 edit複雜的非結構化資料，將它們轉化為特定的工作，並將它們交付給資料科學家和資料分析師進行審查
• 在資料中找到相關見解 — 推薦引擎、流失分析和入侵偵測是許多組織使用 Azure Databricks 的常見方案。
• 提高資料和分析團隊的生產力 — 為資料工程師、分析師和資料科學家創立建協同作業環境和共享工作區，以便在資料科學生命週期中通過共享工作區協同工作，從而節省團隊寶貴的時間和資源。
• 大數據工作負載 — — 利用 Delta Lake 和引擎為我們的大數據工作負載獲得最佳效能和可靠性，並建立簡單的multi-step data pipelines
• 機器學習計劃 — — 利用整合的end-to-end機器學習環境，其中包含用於實驗追踪、模型訓練、特徵開發和管理以及特徵和模型服務的託管服務

使用 Azure Synapse Analytics 設計資料整合和分析解決方案

假設我們需要的是即時訊息，像是加密貨幣交易所。 我們需要batch 與stream processing的組合。 最新資料可用於幫助即時監控需要的即時決策以做出明智的瞬間買賣的決定。 歷史數據對於查看趨勢同樣重要。 我們會推薦什麼樣的data wartehouse和資料整合解決方案來提供對原始data stream的存取，以及從這些資料衍生的商業資訊？

借助 Azure Synapse Analytics，我們可以從外部源擷取資料，然後將這些資料轉換和聚合為適合分析處理的格式。

在這裡，我們用 Azure Synapse Analytics 的 high-level architecture 與組件，以及如何開始使用 Azure Synapse Analytics 進行資料整合。

Azure Synapse Analytics 利用massively parallel processing(MPP) 架構。 在上圖中，我們可以看到此架構包括一個control node和一群compute node。

control node是此架構的大腦。 它是與所有應用程式交互的前端。 compute node提供運算能力。 待處理的資料均勻分佈在節點上。 我們以 Transact-SQL 語法的形式進行資料查詢，Azure Synapse Analytics 運作它們。 Azure Synapse Analytics 使用一種名為 PolyBase 的技術，使我們能夠從關聯式 與非關聯式的資料來源中擷取與查詢資料。 我們可以將讀入的資料保存為 Synapse Analytics 服務中的 SQL tables。

Azure Synapse Analytics的組件

• Synapse SQL pool：Synapse SQL 提供serverless和專用資源模型在node-based architecture作業。為了可預測的效能和成本，我們可以建立專用 SQL pool，對於計劃外或臨時的工作負載，我們可以使用always-available, serverless SQL endpoint。
• Synapse Spark pool：這是一個運行 Apache Spark 以處理資料的clusters。我們可以使用以下四種支援的語言之一編寫資料處理邏輯：Python、Scala、SQL 和 C#（通過 .NET 用於 Apache Spark）。用於 Azure Synapse 的 Apache Spark 整合了 Apache Spark — — 用於資料準備、資料工程、ETL 和機器學習的開源大數據引擎。
• Synapse Pipelines：Azure Synapse Pipelines 利用 Azure Data Factory的功能，可讓我們建立資料驅動的工作流，以大規模編排資料移動和轉換資料。我們可以包括在傳輸資料時轉換資料的活動，或者我們可以將來自多個資料來源組合在一起。
• Synapse Link：可以連接到 Cosmos DB。我們可以使用它對存儲在 Cosmos DB 中的操作資料執行near real-time的分析。
• Synapse Studio：這是一個Web-based IDE，可集中用於處理 Azure Synapse Analytics 的所有功能。我們可以使用 Synapse Studio 建立 SQL 和 Spark pool、定義和運行pipeline以及配置指向外部data source的links。

更多的Azure Synapse Analytics請參考此篇文件．

何時使用Azure Synapse Analytics？

• 如果我們有多種資料來源，使用 Azure Synapse Analytics 進行code-free ETL 和data flow活動。
• 當我們需要使用 Apache Spark 實施機器學習解決方案時，使用 Azure Synapse Analytics 為 AzureML 提供內建支援。
• 當我們將現有資料存儲在data lake中並需要與data lake和其他input source整合時，Azure Synapse Analytics 可提供兩者之間的無縫整合。

當組織中的長官需要即時分析時，我們可以使用 Azure Synapse Link 等功能進行即時分析並提供見解。

哪些分析種類我們需要使用Azure Synapse Analytics？

下表為 Azure Synapse Analytics 支援的分析類型範圍：

何時應該用Azure Data Factory而不是Azure Synapse Analytics

讓我們看看一些標準，這些標準將幫助我們決定何時選擇 Azure Data Factory而不是 Azure Synapse Analytics。 在下表中，將這兩種解決方案與一組標準進行比較。

設計資料的Hot/Warm/Cold data path策略

傳統上，資料存儲在地端機房時大都沒有考慮其運用和生命週期。 在雲端中，可以根據資料的存取、生命週期和其他合規性要求存儲資料。 讓我們了解hot/warm/cold data path的概念如何決定我們存儲和運算資料的方式。

Warm Path

讓我們看一下IoT資料聚合的常見場景。這些設備可能正在發送資料，但實際上並沒有產生任何東西。這凸顯了在嘗試從 IoT 資料中提取洞察力時的一個非常常見的挑戰：我們正在尋找的資料在我們得到的資料中無法使用。因此，我們需要通過將我們獲得的資料與其他資料來源相結合來推斷資料使用率，並套用規則來確定機器是否正在運作中。此外，這些規則可能因公司而異，因為它們可能對“運作中”是什麼有著不同的解釋。

Warm Path是在資料流經系統時進行分析。我們會近乎即時的處理這個資料流，將其保存到warm storage中，然後將其推送到分析服務中。

Azure 平台提供了許多用於處理事件的選項，其中一種常用的選項是Stream Analytics。

Stream Analytics可以大規模執行複雜的分析，例如tumbling/sliding/hopping windows, stream aggregations和外部資料來源連接。對於更複雜的處理，可以通過Event Hubs, Stream Analytics jobs與Azure functions的多個instance來擴展效能。

可以使用 Azure 平台上的各種服務來實現Warm storage，例如 Azure SQL DataBase 和 Azure Cosmos DB。

Cold Path

Warm Path是stream processing發生的地方，以隨著時間的推移發現其模式。但是，可能需要使用不同的pivots和aggregations來計算過去一段時間內的使用率，並將這些結果與Warm Path結果合併以向使用者呈現一個統一的視角。

Cold Path包括batch layer 與 serving layers。這種組合提供了系統的long-term view。

Cold Path包含解決方案的長期資料存儲。它還包含批batch layer，這個layer建立預先計算的aggregate views，以提供長時間的快速查詢回應。 Azure 平台上這一個layer可用的技術選項非常多樣化。

Azure Storage 是一個cold storage 解決方案。 Azure storage包括 Azure Blob（object）、Azure Data Lake Storage Gen2、Azure Files、Azure Queues和 Azure Tables。Cloud Storage可以是 Blob、Data Lake Storage Gen2 或 Azure Tables，也可以是它們的組合。

要存儲大量非結構化資料，例如 JSON 或包含 IoT Application接收到未處理資料的 XML 檔案，Blob storage、Azure Files或 Azure Data Lake Storage Gen2 是最佳選擇。

Azure Data Factory是在serving layer上建立batch views的解決方案。它是一種cloud-based managed data integration service，允許我們在雲端中創建資料導向工作流程，以編排和自動化資料移動和資料轉換。它可以使用 Azure HDInsight Hadoop、Spark 和 Azure Databricks 等服務處理和轉換資料。這允許我們構建機器學習模型並與分析服務一起使用它們。

Hot Path

Hot Path通常用於即時的流程或資料顯示。 它可以用於即時告警或即時交易，並使用這個data streaming operations。 Hot Path是對延遲敏感的資料，資料的結果需要在幾秒鐘或更短的時間內準備好，並且它可以流動到分析服務中。

何時該使用 Hot/Warm/Cold Path

讓我們分析決定Hot/Warm/Cold Path的要求。

設計用於資料分析的 Azure Stream Analytics solution

組織的電商部門可能已開始對其應用程式和服務進行數位轉型，以幫助組織發展。 可能的場景有涉及存取、儲存和分析來自物流車上GPS 的IoT資料。 業務單位需要一種能夠對物流車上 GPS 的streaming data進行real-time analytics並即時做出決策的解決方案。

進一步分析後，可能發現我們希望這些資料出現在現有的 Power BI 可視化儀表板中。

我們將如何幫助解決這個問題？ 讓我們看看 Azure Stream Analytics是否可以在這種情況下提供幫助。

Azure Stream Analytics

使用資料串流、分析它們並得出可運作的見解過程稱為stream processing。 Azure stream processing是一個PaaS 的即時分析和事件流程引擎。它提供了對來自IoT設備資料、感測器、clickstreams等來源的多個data streams執行即時分析的可能性。Azure 串流分析支援以三種資料格式處理事件：CSV、JSON 和 Avro

Azure Stream Analytics適用於以下概念：

• Data Stream — — data stream是由應用程式、IoT設備產生的連續型資料。分析這些Data stream，並從中提取可運作的見解。例如，監控來自製造業的data stream，監控一般家戶的電表資料。data stream有助於理解隨時間變動的資料。
• Event processing — Event processing是指接收和分析連續型data stream，以從該stream中發生的event中提取運作作的見解。例如，通過收費站的汽車應該包括時間訊息，例如timestamp，呈現它發生的時間。

上圖顯示了Stream Analytics pipeline，以及資料是如何被擷取、分析和發送以進行呈現。

Azure Stream Analytics的主要功能

Stream Analytics從 Azure Event Hubs（包括來自 Apache Kafka 的 Azure event hubs）、Azure IoT Hub或 Azure Blob storage導入資料。該查詢基於 SQL 語言，可用於filter/sort/ aggregate與join 一段時間內的streaming data。我們還可以使用 JavaScript 和 C# user-defined functions(UDF) 擴展此 SQL 語言。更多stream processing資訊請參閱此篇文件．

Azure Stream Analytics job由input/query/output組成。我們可以對job output執行以下操作：

• 將資料路由到 Azure Blob storage、Azure SQL Database、Azure Data Lake Store 和 Azure CosmosDB 等存儲系統。
• 可以將資料發送到 Power BI 以進行即時的可視化。
• 可以將資料存儲在 Azure Synapse Analytics 等data warehouse中，用歷史資料訓練機器學習模型或執行批量分析。
• 可以通過將資料發送到 Azure Functions、Service Bus Topics 或 Queues等服務來觸發custom downstream workflows。

何時應該考量使用Azure Stream Analytics

以下是一些可以有效利用 Azure Stream Analytics的常用的資料案例。

在上面討論的場景中，我們可以利用 Azure Stream Analytics通過 Power BI 可視化物流車輛的即時位置。 對於分析工作負載的管理決策，可以將資料存儲在 Cosmos DB 或 Azure Data Lake 等Data warehouse中以供將來分析。

Azure Stream Analytics的效益

• Fully Managed— 它是PaaS服務，因此沒有配置任何硬體或基礎設施的額外作業與管理。 Azure Stream Analytics全面管理我們的作業，因此我們可以專注於業務邏輯而不是基礎架構。
• Low cost — 計費由Streaming Units (SU) 完成，這些單元代表分配的 CPU 和memory資源的數量。擴展和縮則是基於組織的業務量，這也可以降低成本(不涉及維護成本)。
• Run in cloud or Intelligent edge — 它可以在雲端運行以進行大規模分析，或在 IoT Edge 或 Azure Stack 上運行以進行ultra-low latency analytics。
• Performance — Stream Analytics提供可靠的效能保證。它通過partitioning支援更高的效能，允許在多個streaming nodes上平行處理和執行複雜的查詢。Stream Analytics每秒可以處理數百萬個events，並且可以用ultra-low latencies交付結果。
• Security — 在安全性方面，Azure Stream Analytics對所有incoming/outgoing communication進行加密，並支持 TLS 1.2。內建檢查點也被加密。Stream Analytics不存儲incoming data，因為所有processing都在memory中完成。

以上是有關於Azure的資料整合的各項方案。然而大數據的出現能夠讓我們比以往歷史上的任何時刻都能夠歸檔我們的過去、量化我們的現在、預測我們的未來。因此人類可以是自己歷史的數據探索家，並以智慧方式在歷史的盡頭規劃自己的人生。