隨著雲端運算的普及，企業開始將資料分析平台遷移至雲端，以降低成本並提升效率。雲端資料平台提供更彈性的擴充套件性和更豐富的分析工具，讓企業能更有效地利用資料洞察來驅動業務決策。然而，雲端環境也帶來了新的安全挑戰，企業需要妥善管理資料隱私和存取許可權，以確保資料安全。
雲端運算對分析工程的影響
在過去的幾十年中，全球面臨了一系列具有重大技術影響的複雜挑戰。經濟衰退推動了金融科技和風險管理系統的創新。地緣政治緊張局勢要求在網路安全方面取得進展，以保護關鍵基礎設設施和敏感資料。全球健康危機凸顯了先進資料分析和預測建模對於疾病監測和管理的重要性。此外，應對氣候變化的迫切需要推動了尖端可再生能源技術和可持續工程解決方案的發展，以實作氣候目標。
商業模式的變革
在這些挑戰中，追求利潤和增長仍然是全球企業的主要驅動力。然而，人類勞動時間的價值已經有了新的維度，導致企業經營方式和雲端運算適應方式的重大變化。這種變化反映在越來越多採用託管和無伺服器服務，以減少對全職支援人員（如資料函式倉管理員）的依賴。
隨著公司適應這個不斷變化的環境，創新、分化和商業模式及策略的可持續性已成為公司在快速變化的世界中成功的重要考量。資訊科技和系統產業在此背景下發現了一個很好的機會來提高其幫助組織克服這個不確定性和壓力的世界的能力。營運模式的合理化已成為當務之急，需要重新評估資料中心和定價結構。此外，產品和服務供應必須主要專注於易用性、更低的延遲、改進的安全性、更廣泛的即時工具、更多的整合、更多的智慧、更少的程式碼和更快的上市時間。
資料分析的重要性
組織已經認識到投資創新工具、推動數位轉型和採用以資料為中心的決策方法的重要性，以實作更高的敏捷性和競爭優勢。為了實作這些目標，許多組織正專注於利用來自內部和外部來源的精心整理的資料。這些精心結構化的資料可以為業務績效提供寶貴的見解。
在產業中，以可存取的格式建立、視覺化和分析相互連線的業務資料的做法通常被稱為資料分析。從歷史上看，它也被稱為商業智慧，兩個術語密切相關。雖然商業智慧是分析的一個子集，專注於業務導向的決策，但資料分析涵蓋了更廣泛的領域，包括產品分析、營運分析和其他幾個專業領域。兩者都在幫助組織透過資料驅動的洞察獲得競爭優勢方面發揮著關鍵作用。
從本地解決方案到雲端解決方案的轉變
儘管資料分析為改進和重塑業務策略及監控績效提供了眾多好處，但它需要在伺服器、軟體許可證和專業人員（如資料工程師、資料科學家和資料視覺化專家）方面進行大量的財務投資。在經濟危機時期，與IT硬體、軟體和專業人員相關的高前期和營運成本可能被視為不切實際和缺乏吸引力。
因此，在公司自己的場所設定和管理資料分析基礎設施的本地解決方案往往失去了吸引力。對於不熟悉這個概念的新進入者來說尤其如此。本地解決方案通常需要在硬體、軟體和持續維護方面進行大量投資。它們與根據雲端的資料分析解決方案相比，也更不靈活和可擴充套件。這種偏好的轉變正在為新的根據雲端的資料分析解決方案鋪平道路，這些解決方案滿足與傳統資料分析相同的業務需求。然而，根據雲端的解決方案利用雲端運算服務來加速佈署並最小化基礎設施成本。
雲端運算供應商的作用
各個行業中雲端運算的採用率越來越高，促使微軟、谷歌和亞馬遜等軟體供應商開發出先進的資料分析和資料倉儲工具。這些工具旨在在雲端運算環境中執行，為企業提供更靈活、可擴充套件且經濟高效的資料分析解決方案。
內容解密：
上述內容闡述了雲端運算對分析工程領域的深遠影響，以及企業如何透過採用根據雲端的資料分析解決方案來提高其競爭力和敏捷性。其中，提到了多家領先的雲端運算供應商所提供的先進工具和服務，這些工具和服務不僅加速了資料分析的佈署，還降低了相關的基礎設施成本。
圖表翻譯： 此圖示呈現了從本地解決方案轉向雲端解決方案的過程，以及由此帶來的諸多好處，包括降低成本、提高競爭力、促進創新、推動業務增長以及增強企業敏捷性。每一步驟都與前一步驟相關聯，形成了一個邏輯清晰的流程圖。
雲端運算對分析工程的影響
雲端運算正在徹底改變企業佈署與建構資訊系統及技術解決方案的方式，而資料分析也不例外。雲端運算已成為現代資料平台的核心組成部分，並且與根據雲端的分析及人工智慧平台不斷成長，共同推動產業的顛覆。
雲端運算的趨勢與挑戰
雲端運算帶來了諸多好處，例如規模經濟和靈活性，但同時也伴隨著資訊安全問題。由於資料集中在雲端基礎設施中，使得它們成為未授權攻擊的誘人目標。因此，企業必須瞭解並降低與雲端運算相關的風險，包括資料隱私、控制權喪失、資料刪除不完整或不安全、內部未授權存取、資料可用性和複雜的成本計算等。
重大風險與對策
- 資料隱私：驗證供應商是否符合法律和標準具有挑戰性，儘管公開的稽核報告有助於建立信任。
- 供應商依賴：當資料管理的責任完全由一家服務提供商承擔時，會限制遷移到其他解決方案的能力。
- 資料安全風險：在非整合場景中，隨著資料在不同系統和資料中心之間流動，資料被攔截和同步的風險增加。
企業需要仔細考慮這些風險，遵循安全標準和最佳實踐，並持續進行成本控制，以衡量投資回報。
雲端運算的優勢與價值
如果能夠正確處理和降低這些風險，並制定適當的資料策略，企業就能獲得顯著的競爭優勢。透過利用雲端資料平台，企業可以將原始資料轉化為有意義的洞察，加速建立穩固的資料基礎，並支援採用人工智慧技術，從而在更短的時間內以更低的成本創造價值。
雲端資料平台、分析與人工智慧的共生關係
雲端資料平台、分析與人工智慧之間的關係是共生的。實施雲端資料平台可以加速採用以分析為驅動的架構，並實作人工智慧計畫的全面運作。企業能夠利用所有相關資料，獲得企業級的洞察，並開啟新的商機。
資料分析生命週期
資料分析生命週期是一系列將原始資料轉化為有價值且易於消費的資料產品的步驟。這些產品可以從管理良好的資料集到儀錶板、報告、API，甚至是網頁應用程式。換句話說，它描述了資料如何被建立、收集、處理、使用和分析，以實作特定的產品或業務目標。
資料分析生命週期的階段
- 問題定義：瞭解需要解決的問題，包括識別業務目標、可用資料和解決問題所需的資源。
- 資料建模：在識別業務需求並評估資料來源後，可以根據最符合需求的建模技術對資料進行建模。可以選擇鑽石策略、星型模式、Data Vault，甚至是完全反正規化技術。
圖表1-1展示了資料分析生命週期的各個階段。
此圖示 圖表1-1 資料分析生命週期
圖表翻譯： 圖表1-1詳細展示了資料分析生命週期的流程，包括問題定義、資料建模等關鍵步驟。這種結構化的流程幫助企業更好地理解和管理資料分析過程中的各個任務和活動。
資料工程與分析生命週期
資料工程與分析的生命週期是組織以結構化和一致的方式處理資料工程、科學和分析流程的關鍵概念。這個過程確保組織能夠解決正確的問題，使用正確的資料，並建立準確可靠的資料產品，最終帶來更好的決策和業務成果。
資料引入與轉換
第一階段是將來自源系統的資料引入並準備好，以符合所建立的模型。根據整體資訊架構，可以選擇**結構寫入（schema-on-write）策略或結構讀取（schema-on-read）**策略。結構寫入需要將原始資料直接轉換為模型，而結構讀取則是在下游層進行大量轉換。
資料儲存與結構
一旦資料管道被設計和實作，就需要決定使用的檔案格式，例如簡單的 Apache Parquet 或更進階的格式，如 Delta Lake 或 Apache Iceberg。同時，也需要選擇分割策略和儲存元件，例如雲端物件儲存服務 Amazon S3 或更類別似資料倉儲的平台，如 Redshift、BigQuery 或 Snowflake。
資料視覺化與分析
當資料可用時，下一步是探索、視覺化或建立直接支援決策或啟用業務流程監控的儀錶板。此階段非常注重業務，需要與業務利益相關者密切協調。
資料品質監控、測試和檔案
儘管被列為分析生命週期的最後階段，但資料品質應該是端對端關注的問題，並在整個流程中透過設計來確保。這涉及實施所有品質控制措施，以確保利益相關者可以信任所公開的資料模型，記錄所有轉換和語義含義，並確保在資料持續流動的過程中沿著管道進行適當的測試。
使用 dbt 可以更輕鬆、更高效地佈署其中幾個元件，因為它允許我們在整個生命週期中平行構建它們。檔案、測試和品質成為平行執行的常規任務。
分析工程師的新角色
隨著資料儲存和分析量的持續增長，組織越來越需要資料專家來幫助管理這些資料並提供所需的基礎設施。最近新興的分析工程師分支在開發和維護資料函式庫和資料管道方面發揮著不可或缺的作用，使資料科學家和分析師能夠專注於更進階的分析任務。
分析工程師的職責
分析工程師負責設計、構建和維護使組織能夠將資料轉化為有價值洞察並做出資料驅動決策的資料架構。他們需要在軟體開發最佳實踐（如版本控制和持續整合/持續佈署（CI/CD））和有效的溝通技巧之間取得平衡。
與其他角色的關係
分析工程師充當資料平台工程師（專注於構建技術基礎設施以啟用資料平台）和資料分析師（專注於將資料轉化為有洞察力的資料產品）之間的橋樑。他們的工作是建立經過良好測試、更新及時且有充分檔案的資料集，供組織的其他人員用來回答自己的問題。
內容解密：
此段落描述了分析工程師在組織中的角色，強調了他們在軟體開發最佳實踐和溝通技巧方面的重要性。
與土木工程的類別比
可以將分析工程師與建築師進行類別比。他們利用資料工程師建立的堅實基礎，設計符合業務模型的結構，從優秀的儀錶板到有價值的資料模型，從而彌合技術基礎設施和業務目標之間的差距。
圖表翻譯： 此圖示呈現了從資料引入到最終分析與決策的整個流程，展示了不同階段之間的連貫性和依賴關係。從原始資料引入開始，經過轉換、儲存到視覺化，最終透過品質監控達到支援決策的目的。
分析工程師的角色與責任：資料分析生態系的核心
在資料分析的生態系中，分析工程師扮演著至關重要的角色。他們的工作涵蓋了資料儲存與檢索系統的設計、資料管線的建立與維護，以及機器學習模型的開發與佈署。這些任務不僅需要技術上的專業知識，也需要對業務需求有深入的瞭解。
分析工程師的主要責任
- 設計與實作高效的資料儲存與檢索系統：這包括與資料函式庫和資料倉儲技術合作，設計能夠處理大型和複雜資料集的資料模型和結構。
- 建立和維護資料管線：資料管線負責從各種來源提取資料、轉換資料，並將其載入到中央儲存函式庫中供分析使用。
- 開發和佈署機器學習模型：雖然這不是所有分析工程師的主要任務，但許多人參與與資料科學家合作，瞭解他們的需求，選擇和實施適當的演算法，並確保模型得到適當的訓練和佈署。
- 監控和維護機器學習模型的效能：這包括幫助構建離線評估，以及將模型特定的指標與業務指標結合起來進行線上監控。
分析工程師所需的技能
- 精通程式語言和工具，如 Python、R、SQL 和 Spark，以實作資料管線、資料模型和機器學習模型。
- 熟悉雲端運算平台，如 AWS、GCP 或 Azure，以佈署和擴充套件分析解決方案。
分析工程師在不同公司的職責範例
- 設計和實施能夠處理大型和複雜資料集的資料儲存和檢索系統，如資料函式庫和資料倉儲。
- 建立和維護資料管線，以從各種來源提取、轉換和載入資料到中央儲存函式庫中供分析使用。
- 透過執行資料品品檢查、跟蹤資料流和實施資料安全措施，確保資料的準確性、完整性、一致性和可存取性。
- 利用雲端運算平台佈署和分析解決方案，同時最佳化資料基礎設施的可擴充套件性、安全性和成本。
- 最佳化資料儲存和檢索系統、資料管線和機器學習模型的效能，以處理大量的複雜資料。
- 與資料科學家合作，瞭解他們的需求，選擇和實施適當的演算法，並確保機器學習模型得到適當的訓練和佈署。同時，監控和維護模型的效能，並根據需要進行故障排除和最佳化。
- 跟上資料工程、機器學習和分析領域的最新技術和趨勢，不斷尋找機會改善組織的資料基礎設施和分析能力。
分析工程師在 Data Mesh 中的角色
Data Mesh 是一種現代化的框架，用於規劃組織的資料策略。它使業務領域團隊能夠擁有自己的資料和提供存取許可權的服務，而不是僅僅依賴於一個中央資料團隊。這種架構將單一的資料架構分解為一組獨立、自治的資料服務，從而實作更精細的擴充套件、更多的自主權和更好的資料管理。
在 Data Mesh 中，分析工程師的工作變得更加靈活，需要具備跨領域的技術能力和對業務需求的深刻理解。他們需要能夠在獨立的資料服務之間建立聯絡，確保資料能夠被有效地共用和利用。
內容解密：
Data Mesh 的核心概念在於分散式資料管理和自主權。它鼓勵不同業務部門直接負責自己的資料資產，並透過標準化的介面進行分享。這種方法提高了組織對變化的業務需求的回應速度，並促進了創新和協作文化的形成。
資料網格（Data Mesh）架構與分析工程的重要性
資料網格方法論作為一種架構模式，徹底改變了分析師與資料基礎設施的互動方式。透過將單一的資料架構分解為一系列獨立、自治的資料服務，這些服務可以獨立開發、佈署和營運，團隊能夠以更細緻、更有效的方式應對資料架構的可擴充套件性、可管理性和自治性挑戰。
資料網格的優勢
這種新穎的方法使團隊能夠更精細地擴充套件其資料基礎設施，降低資料孤島和重複的風險。每個業務領域團隊擁有更大的自主權，使他們能夠選擇最適合其特定需求的工具和技術，同時利用集中提供的服務來管理整個資料生命週期。這使他們能夠更快、更敏捷，並快速回應不斷變化的業務需求。此外，資料網格方法在處理不同型別的資料（如結構化、半結構化和非結構化資料）時提供了更大的靈活性。它還透過打破單一的資料架構和實作資料服務的清晰對映來實作更好的資料治理實踐。
分析工程師在資料網格中的角色
分析工程師可以透過專注於構建和維護獨立、自治的資料服務來為資料網格組織創造價值，這些服務支援多個團隊和應用程式的需求，例如分享的資料模型、良好治理和檔案化的資料，以確保輕鬆的資料可發現性、可存取性和安全性。確保資料治理和安全性是資料網格中的另一個重要方面，這可能包括實施資料策略和程式，例如資料存取控制、資料排序和資料品品檢查，以確保資料的安全性和高品質。此外，分析工程師應與資料所有者和利益相關者合作，以瞭解並遵守所有資料儲存和管理法規要求。
資料產品（Data Products）
定義與範例
資料產品是可存取的應用程式，提供對資料驅動洞察的存取，以支援業務決策過程甚至自動化它們。在內部，它們可能包含用於檢索、轉換、分析和解釋資料的元件。另一個重要方面是，資料產品應以其他內部或外部應用程式或服務可以存取和使用的方式公開其資料。
一些資料產品的例子如下：
- 一個REST API，允許使用者查詢特定的業務資料模型
- 一個資料管道，攝取和處理來自各種來源的資料
- 一個資料湖，儲存和管理大量的結構化和非結構化資料
- 一個資料視覺化工具，幫助使用者理解和傳達資料洞察
微服務架構
資料產品也可以由微服務組成。這些是小型、獨立且專注的服務，可以獨立開發、佈署和擴充套件。它們可以透過API存取，並在企業內重複使用。
dbt作為資料網格的推動者
dbt是一個開源工具，透過提供建立、測試和管理資料服務的方式，幫助資料工程師、分析工程師和資料分析師構建資料網格。它允許團隊定義、測試和構建資料模型，並為這些模型建立一個清晰且定義良好的介面，以便其他團隊和應用程式可以輕鬆使用它們。
dbt的功能特點
- 資料建模能力：允許團隊使用簡單熟悉的根據SQL的語法定義其資料模型，使資料工程師和分析師能夠共同定義和測試資料模型。
- 資料測試能力：提供一個測試框架，允許團隊測試其資料模型並確保它們準確可靠。這有助於在開發過程的早期識別錯誤，並確保資料服務的高品質。
- 資料檔案：使資料模型和服務能夠被檔案化，以便其他團隊和應用程式能夠輕鬆理解和使用它們。
- 資料追蹤能力：允許團隊追蹤資料模型的來源。這使得了解資料的使用方式和來源變得容易。
- 資料治理能力：使得能夠實施資料治理策略，例如資料存取控制、資料血統和資料品品檢查，這有助於確保資料的安全性和高品質。
分析工程的核心：資料轉換
資料轉換的重要性
資料轉換將資料從一種格式或結構轉換為另一種，以使其對特定的應用或目的更有用或更合適。這個過程是必要的，因為它使組織能夠將原始的、非結構化的資料轉換為有價值的洞察，從而為業務決策提供依據，改善營運，並推動增長。
資料轉換在分析生命週期中的角色
資料轉換是分析生命週期中的關鍵步驟，組織需要具備高效執行此任務的工具和技術。一些資料轉換的例子包括清理和準備資料、聚合和匯總資料，以及透過附加資訊豐富資料。
dbt在資料轉換中的應用
dbt被廣泛用於資料轉換，因為它允許組織快速、輕鬆地執行複雜的資料轉換任務，並且可以與其他工具（如Airflow）整合，用於端對端的資料管道管理。dbt是分析師和企業利益相關者的「現場」（gemba）。當資料被轉換並以易於使用的形式交付時，就為企業和利益相關者創造了價值。
ETL與ELT策略比較
在ETL（提取、轉換、載入）策略中，資料轉換通常在將資料載入到目標系統（如資料倉儲或資料湖）之前執行。資料從各種來源提取，轉換以匹配目標系統的結構和格式，然後載入到目標系統中。這個過程確保了跨系統和應用程式的資料一致性和可用性。
相比之下，ELT（提取、載入、轉換）策略代表了一種更新、更靈活的資料處理方法。在這種策略中，資料首先被提取並載入到目標系統中，然後進行轉換。ELT提供了多個優勢，包括提高靈活性等。
圖表翻譯：ETL與ELT流程比較
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 雲端分析工程轉型與資料網格策略
package "時間序列分析" {
package "資料準備" {
component [時間索引] as time_idx
component [重採樣 Resample] as resample
component [缺失值處理] as missing
}
package "特徵分析" {
component [趨勢 Trend] as trend
component [季節性 Seasonality] as season
component [殘差 Residual] as residual
}
package "預測模型" {
component [ARIMA] as arima
component [指數平滑] as ets
component [Prophet] as prophet
component [LSTM] as lstm
}
}
time_idx --> resample : 時間聚合
resample --> trend : 分解
trend --> season : STL分解
season --> residual : 殘差分析
trend --> arima : 自迴歸
season --> ets : 季節調整
residual --> prophet : 預測
residual --> lstm : 深度學習
note right of arima
p: 自迴歸階數
d: 差分階數
q: 移動平均階數
end note
@enduml圖表翻譯： 此圖示比較了ETL（提取、轉換、載入）和ELT（提取、載入、轉換）兩種不同的處理流程。在ETL流程中，原始資料首先被提取，接著進行轉換，最後被載入到目標系統。相比之下，ELT流程則是先提取原始資料，直接載入到目標系統，然後再進行轉換。兩種方法的主要區別在於何時進行資料轉換：ETL是在載入前進行，而ELT則是在載入後進行。這種差異反映了不同的資料處理需求與技術考量。
