讀資料工程之道：設計和構建健壯的資料系統09示例和型別

躺柒發表於2024-10-15
型別

1. 資料架構不是憑空設計的

1.1. 資料架構是一門抽象學科，所以它有助於透過示例進行推理

2. 資料倉儲

2.1. 一個面向主題的、整合的、非易失性和時變的資料集合，以支援管理決策

2.2. 資料倉儲是用於報告和分析的中央資料中心

  • 2.2.1. 資料倉儲中的資料通常針對分析用例進行了高度格式化和結構化

  • 2.2.2. 是最古老和最完善的資料架構之一

2.3. 組織型

  • 2.3.1. 組織型資料倉儲架構組織與某些業務團隊結構和流程相關的資料

  • 2.3.2. 將聯機分析處理(OLAP)與生產資料庫（聯機事務處理，Online Transaction Processing，OLTP）分離

  • 2.3.3. 將資料移動到一個單獨的物理系統中，可以將負載從生產系統轉移出去，並提高分析效能

  • 2.3.4. 傳統上，資料倉儲透過使用ETL從應用程式系統中獲取資料

  • 2.3.4.1. 提取階段從源系統中獲取資料

2.4. 技術型

  • 2.4.1. 技術型資料倉儲架構反映了資料倉儲的技術性質

  • 2.4.2. ETL的一種變體是ELT

  • 2.4.3. 轉換不是使用外部系統，而是直接在資料倉儲中處理

  • 2.4.4. 目的是利用雲資料倉儲和資料處理工具的巨大計算能力

2.5. 雲資料倉儲

  • 2.5.1. 雲資料倉儲代表了本地資料倉儲架構的重大演變，因此導致了組織架構的重大變化

  • 2.5.2. 雲資料倉儲擴充套件了MPP系統的功能，以涵蓋最近需要Hadoop叢集的許多大資料用例

  • 2.5.3. 通常支援允許每行儲存數十兆位元組原始文字資料或極其豐富和複雜的JSON文件的資料結構

  • 2.5.4. 隨著雲資料倉儲（和資料湖）的成熟，資料倉儲和資料湖之間的界限將繼續模糊

2.6. 資料倉儲提供了開箱即用的基本資料管理功能，而SQL是編寫複雜、高效能查詢和轉換的有效工

3. 資料集市

3.1. 資料集市是倉庫的一個更精細的子集，旨在為分析和報告提供服務，專注於一個單一的子組織、部門或業務線

3.2. 資料集市使分析師和報告開發人員更容易訪問資料

3.3. 資料集市在初始ETL或ELT管道提供的轉換階段之外提供了一個額外的轉換階段

4. 資料湖

4.1. 大資料時代出現的最流行的架構之一是資料湖

4.2. 資料湖有望成為一股民主化的力量，解放企業，讓它們從無限資料的源泉中暢飲

4.3. 資料湖1.0始於HDFS

  • 4.3.1. 隨著雲越來越受歡迎，這些資料湖轉移到基於雲的物件儲存，儲存成本極其低廉，儲存容量幾乎是無限的

  • 4.3.2. 資料湖不依賴於儲存和計算緊耦合的單一資料倉儲，它允許儲存任何大小和型別的大量資料

  • 4.3.3. 當需要查詢或轉換這些資料時，你可以透過按需啟動叢集來獲得幾乎無限的計算能力，並且你可以為手頭的任務選擇你最喜歡的資料處理技術

  • 4.3.3.1. MapReduce

  • 4.3.3.2. Spark

  • 4.3.3.3. Ray

  • 4.3.3.4. Presto

  • 4.3.3.5. Hive

  • 4.3.4. 資料湖成了垃圾場

  • 4.3.4.1. 資料沼澤、暗資料和WORN等術語是在曾經有希望的資料專案失敗時創造出來的

  • 4.3.5. 廉價的現成硬體將取代定製的供應商解決方案

  • 4.3.5.1. 由於管理Hadoop叢集的複雜性迫使公司以高薪聘請大量的工程師團隊，因此大資料成本激增

  • 4.3.5.2. 公司通常選擇從供應商處購買許可的、定製的Hadoop版本，以避免原始Apache程式碼庫的裸線和尖銳邊緣，並獲得一套腳手架工具，使Hadoop更加使用者友好

  • 4.3.5.3. 即使是避免使用雲端儲存管理Hadoop叢集的公司也不得不花費大量人才來編寫MapReduce作業

4.4. 公司擁有足夠的資源來構建成功的資料實踐，並建立基於Hadoop的自定義工具和增強功能

  • 4.4.1. 對於許多組織而言，資料湖變成了浪費、令人失望和成本不斷上升的內部超級垃圾場所

5. 資料湖倉一體

5.1. 資料湖倉一體一詞暗示了資料湖和資料倉儲之間的融合

5.2. 雲資料倉儲將計算與儲存分開，支援PB級的查詢，儲存各種非結構化資料和半結構化物件，並與先進的處理技術（如Spark或Beam）整合

5.3. AWS、Azure、Google Cloud、Snowflake和Databricks是一流的領導者，每家都提供了一系列緊密整合的工具來處理資料，從關係型到完全非結構化

5.4. 未來的資料工程師可以根據各種因素，包括供應商、生態系統和相對開放性，選擇一個融合的資料平臺，而不是在資料湖或資料倉儲架構之間進行選擇

6. 現代資料棧

6.1. 現代資料棧是目前流行的分析架構，突出了我們希望在未來幾年內看到更廣泛使用的抽象型別

6.2. 現代資料棧的主要成果是自助服務（分析和管道）​、敏捷資料管理以及使用開源工具或具有明確定價結構的簡單專有工具

6.3. 現代資料棧現在是並將繼續是資料架構的預設選擇

7. Lambda架構

7.1. 在Lambda架構中​，你的系統彼此獨立執行——批處理、流處理和服務

7.2. 流處理

  • 7.2.1. 流處理的目的是在“速度”層（通常是NoSQL資料庫）中以儘可能低的延遲為資料提供服務

7.3. 批處理

  • 7.3.1. 在批處理層，資料在資料倉儲等系統中進行處理和轉換，建立資料的預計算和聚合的資料檢視

7.4. 服務層透過聚合來自兩個層的查詢結果來提供組合檢視

8. Kappa架構

8.1. 透過直接讀取實時事件流並重放大塊資料以進行批處理，可以將實時和批處理無縫地應用於相同的資料

9. Dataflow模型

9.1. Dataflow模型的核心思想是將所有資料視為事件，因為聚合是在各種型別的視窗上執行的

9.2. 持續的實時事件流是無邊界的資料

9.3. 資料批次只是有界事件流，邊界提供了一個自然視窗

9.4. “批處理作為流處理的特例”的理念現在更加普遍

10. 物聯網架構

10.1. 物聯網是裝置的分散式集合，又稱為事物——計算機、感測器、移動裝置、智慧家居裝置以及任何其他具有網際網路連線的裝置

10.2. 由定期或連續從周圍環境收集資料並將其傳輸到目的地的裝置生成

10.3. 物聯網裝置通常是低功耗的，並且在低資源/低頻寬環境中執行

10.4. 物聯網已經從未來主義的幻想演變為海量資料工程領域

10.5. 裝置

  • 10.5.1. 裝置（也稱為事物）是連線到網際網路的物理硬體，可以感知周圍的環境、收集資料並將其傳輸到下游目的地

  • 10.5.2. 裝置應該至少能夠收集和傳輸資料

10.6. 物聯網閘道器

  • 10.6.1. 物聯網閘道器是連線裝置並將裝置安全路由到網際網路上適當目的地的樞紐

  • 10.6.2. 雖然你可以在沒有物聯網閘道器的情況下將裝置直接連線到網際網路，但閘道器允許裝置使用極少的功率進行連線

  • 10.6.3. 充當資料保留的中轉站，並管理與最終資料目的地的網際網路連線

  • 10.6.4. 新的低功耗WiFi標準旨在降低物聯網閘道器在未來的重要性

10.7. 儲存

  • 10.7.1. 儲存要求在很大程度上取決於系統中物聯網裝置的延遲要求

10.8. 服務

  • 10.8.1. 服務模式非常多樣化

  • 10.8.2. IoT的一種重要服務模式類似於反向ETL

11. 資料網格

11.1. 資料網格是最近對龐大的單一資料平臺（例如集中式資料湖和資料倉儲）以及“資料大分水嶺”的回應，其中資料分為運營資料和分析資料

11.2. 資料網格試圖反轉集中式資料架構的挑戰，採用領域驅動設計的概念（通常用於軟體架構）並將其應用於資料架構

11.3. 關鍵組成部分

  • 11.3.1. 面向領域的分散式資料所有權和架構

  • 11.3.2. 資料作為產品

  • 11.3.3. 自助式資料基礎架構作為平臺

  • 11.3.4. 聯合計算治理

12. 其他資料架構

12.1. 資料中心

12.2. 縮放架構

12.3. 後設資料優先架構

12.4. 事件驅動架構

12.5. 實時資料棧

相關文章