讀資料工程之道：設計和構建健壯的資料系統20資料工程儲存抽象

躺柒發表於2024-10-26
抽象

1. 資料工程儲存抽象

1.1. 資料工程儲存抽象是資料組織和查詢模式，位於資料工程生命週期的核心，建立在之前討論的資料儲存系統之上

1.2. 關鍵的考慮

  • 1.2.1. 目的和用例

  • 1.2.1.1. 必須首先確定儲存資料的目的

  • 1.2.2. 更新模式

  • 1.2.2.1. 是否針對批次更新、流式插入或上載進行了最佳化

  • 1.2.3. 成本

  • 1.2.4. 分離儲存和計算

  • 1.2.4.1. 現在的趨勢是將儲存和計算分離，但大多數系統是混合分離和主機託管

2. 資料倉儲

2.1. 資料倉儲是一個標準的OLAP資料架構

2.2. 資料倉儲一詞指的是技術平臺（如Google BigQuery和Teradata）​、資料集中化的架構以及公司內部的組織模式

2.3. 雲資料倉儲

  • 2.3.1. 雲資料倉儲經常被用來將資料組織到資料湖中

  • 2.3.2. 這是一個儲存大量未處理的原始資料的區域

  • 2.3.3. 最初是由James Dixon構想的

  • 2.3.4. 可以處理大量的原始文字和複雜的JSON文件

  • 2.3.5. 侷限性在於，與真正的資料湖不同，雲資料倉儲不能處理真正的非結構化資料，如影像、影片或音訊

  • 2.3.6. 可以與物件儲存結合起來，提供一個完整的資料湖解決方案

3. 資料湖

3.1. 資料湖最初被認為是一個大規模的儲存，資料以原始的、未處理的形式被保留

3.2. 最初，資料湖主要建立在Hadoop系統上，廉價的儲存允許保留大量的資料，而沒有專有MPP系統的成本開銷

3.3. 主要的進展

  • 3.3.1. 出現了計算和儲存分離的重大遷移

  • 3.3.2. MPP系統提供的許多功能（模式管理；更新、合併和刪除功能）​，以及最初在匆忙建立資料湖概念時被放棄的功能，事實上是非常有用的

  • 3.3.2.1. 促進了資料湖倉一體概念的產生

4. 資料湖倉一體

4.1. 資料湖倉一體是一個結合了資料倉儲和資料湖的架構

4.2. 湖倉一體在物件儲存中儲存資料，就像一個湖一樣

4.3. 湖倉一體系統是一個後設資料和檔案管理層，與資料管理和轉換工具一起部署

4.4. 資料湖倉一體的關鍵優勢是互操作性

4.5. 資料湖倉一體中的許多資料可能沒有強加表結構

5. 儲存的重要思想和趨勢

5.1. 資料目錄

  • 5.1.1. 資料目錄是一個集中的後設資料儲存，用於整個組織的所有資料

  • 5.1.2. 資料目錄不是一個頂級的資料儲存抽象，但它與各種系統和抽象相整合

  • 5.1.3. 資料目錄通常跨運營和分析資料來源工作，整合資料脈絡和資料關係的呈現，並允許使用者編輯資料描述

  • 5.1.4. 資料目錄通常被用來提供一箇中央場所，人們可以在那裡檢視他們的資料、查詢和儲存資料

  • 5.1.5. 目錄應用整合

  • 5.1.5.1. 理想情況下，資料應用程式被設計成與目錄API整合，直接處理其後設資料和更新

  • 5.1.6. 自動掃描

  • 5.1.6.1. 在實踐中，目錄系統通常需要依賴一個自動掃描層，從各種系統中收集後設資料，如資料湖、資料倉儲和運算元據庫

  • 5.1.7. 資料門戶和社會層

  • 5.1.7.1. 資料目錄通常還透過網路介面提供一個使用者訪問層，使用者可以在那裡搜尋資料並檢視資料關係

  • 5.1.8. 資料目錄用例

  • 5.1.8.1. 資料目錄有組織和技術兩方面的用例

  • 5.1.8.2. 資料目錄使後設資料容易被系統使用

5.2. 資料共享

  • 5.2.1. 資料共享允許組織和個人與特定實體共享特定的資料和精心定義訪問許可權

  • 5.2.2. 資料共享允許資料科學家與組織內的合作者共享沙盒中的資料

  • 5.2.3. 雲端多租戶環境使組織間的協作更加容易

  • 5.2.4. 資料共享是許多雲資料平臺的一個核心特徵

5.3. 模式

  • 5.3.1. 模式不一定是關係型的

  • 5.3.2. 模式可以作為一種羅塞達石，指示我們如何閱讀資料

  • 5.3.3. 寫時模式

  • 5.3.3.1. 寫時模式基本上是傳統的資料倉儲模式：一個表有一個整合的模式，任何對該表的寫入都必須符合

  • 5.3.3.2. 為了支援寫時模式，資料湖必須整合一個模式元儲存

  • 5.3.3.3. 寫時模式的主要優點是，它可以執行資料標準，使資料在未來更容易被消費和利用

  • 5.3.4. 讀時模式

  • 5.3.4.1. 在讀時模式下，模式是在資料寫入時動態建立的，而讀者在讀取資料時必須確定模式

  • 5.3.4.2. 理想情況下，讀時模式是使用實現內建模式資訊的檔案格式來實現的

  • 5.3.4.3. 讀時模式強調的是靈活性，允許幾乎任何資料被寫入

>  5.3.4.3.1. 代價是在未來消費資料時更加困難

5.4. 計算與儲存的分離

  • 5.4.1. 計算和儲存的主機託管

  • 5.4.1.1. 長期以來一直是提高資料庫效能的標準方法

  • 5.4.2. 計算和儲存的分離

  • 5.4.2.1. 短暫性和可擴充套件性

>  5.4.2.1.1. 購買和託管一臺伺服器要比從雲提供商那裡租來的便宜，只要你每天24小時不停地執行它，連續數年

>  5.4.2.1.2. 工作負荷變化很大，如果伺服器可以擴大和縮小，那麼採用即付即得模式就能實現顯著的效率
  • 5.4.2.2. 資料的耐久性和可用性
>  5.4.2.2.1. 雲物件儲存大大減輕了資料丟失的風險，通常提供極高的正常執行時間（可用性）​

>  5.4.2.2.2. 因錯誤配置而破壞物件儲存中資料的可能性仍然有些可怕，但有簡單部署的緩解措施
  • 5.4.2.3. 混合分離和主機託管
>  5.4.2.3.1. 多層快取

  >   5.4.2.3.1.1. 透過多層快取，我們利用物件儲存進行長期的資料保留和訪問，但在查詢和資料管道的各個階段使用本地儲存來啟動

>  5.4.2.3.2. 混合物件儲存

  >   5.4.2.3.2.1. 結合了物件儲存的簡潔抽象和計算儲存的一些優勢

>  5.4.2.3.3. Spark通常在HDFS或其他一些短暫的分散式檔案系統上執行作業，以支援處理步驟之間的資料的高效能儲存

>  5.4.2.3.4. 保持資料的永續性仍然是至關重要的，所以Druid使用物件儲存作為其永續性層
  • 5.4.2.4. 零複製克隆
>  5.4.2.4.1. 基於物件儲存的雲系統支援零複製克隆

>  5.4.2.4.2. 零複製克隆通常意味著一個物件的新的虛擬副本被建立（例如，一個新的表）​，而不一定要物理複製基礎資料

>  5.4.2.4.3. 零複製克隆是一個引人注目的功能，但工程師必須瞭解它的優點和侷限性

5.5. 資料儲存的生命週期和資料保留

  • 5.5.1. 儲存資料並不是簡單地把它儲存到物件儲存或磁碟上就可以不再管理它

  • 5.5.2. 三類永續性

  • 5.5.2.1. 熱、暖和冷

>  5.5.2.1.1. 熱資料

  >   5.5.2.1.1.1. 熱資料有即時或頻繁的訪問要求。熱資料的底層儲存適合於快速訪問和讀取，如SSD或記憶體

  >   5.5.2.1.1.2. 儲存熱資料往往是最昂貴的儲存形式

  >   5.5.2.1.1.3. 熱資料的用例包括檢索產品推薦和產品頁面結果

  >   5.5.2.1.1.4. 儲存熱資料的成本是這三個儲存層中最高的，但檢索往往是廉價的

>  5.5.2.1.2. 暖資料

  >   5.5.2.1.2.1. 暖資料的訪問是半定期的，例如每月一次

  >   5.5.2.1.2.2. 沒有硬性規定表明暖資料的訪問頻率，但它比熱資料少，比冷資料多

>  5.5.2.1.3. 冷資料

  >   5.5.2.1.3.1. 在另一個極端，冷資料是不經常訪問的資料

  >   5.5.2.1.3.2. 用於歸檔冷資料的硬體通常是廉價和耐用的，如HDD、磁帶儲存和基於雲的歸檔系統

  >   5.5.2.1.3.3. 當幾乎沒有人打算訪問這些資料時，冷資料主要是為了長期存檔

  >   5.5.2.1.3.4. 雖然儲存冷資料很便宜，但檢索冷資料往往很昂貴

  >   5.5.2.1.3.5. 冷儲存在歸檔資料方面很受歡迎

5.5.2.1.3.5.1. 歷史上，冷儲存涉及物理備份，並經常將這些資料郵寄給第三方，由其在字面上的保險庫中存檔

  >   5.5.2.1.3.6. 冷儲存在雲中越來越受歡迎

  • 5.5.2.2. 每個資料集的查詢訪問模式都不同

  • 5.5.2.3. 通常情況下，較新的資料和比較舊的資料被查詢得更頻繁

  • 5.5.2.4. 考慮你的資料的儲存層時，要考慮每層的成本

>  5.5.2.4.1. 如果你把所有的資料儲存在冷儲存中以節省成本，你當然會降低你的儲存成本，但代價是延長檢索時間

>  5.5.2.4.2. 如果你需要訪問資料，則要付出高昂的檢索費用

  • 5.5.2.5. 儲存價格在更快/更高效能的儲存中更高，並在更低的儲存中逐漸降低

  • 5.5.2.6. 記憶體是昂貴而有限的

  • 5.5.3. 如果你使用基於雲的物件儲存，則為你的資料建立自動化的生命週期策略

  • 5.5.3.1. 使用不經常使用的或歸檔式的儲存層

  • 5.5.3.2. 訪問和檢索的時間和成本可能因雲提供商而異

  • 5.5.4. 資料保留

  • 5.5.4.1. 價值

>  5.5.4.1.1. 資料是一種資產，所以你應該知道你所儲存的資料的價值
  • 5.5.4.2. 時間
>  5.5.4.2.1. 對下游使用者的價值也取決於資料的年齡
  • 5.5.4.3. 合規性
>  5.5.4.3.1. 某些法規可能要求你在一定時間內保留資料
  • 5.5.4.4. 成本
>  5.5.4.4.1. 資料是一種資產，​希望有一個投資回報率

>  5.5.4.4.2. 在投資回報率的成本方面，一個明顯的儲存費用是與資料相關的

5.6. 單租戶與多租戶儲存的對比

  • 5.6.1. 在單租戶架構下，每組租戶（如個人使用者、使用者組、賬戶或客戶）都得到自己的專用資源，如網路、計算和儲存

  • 5.6.2. 採用單租戶儲存意味著每個租戶都得到他們的專用儲存

  • 5.6.2.1. 每個租戶得到一個資料庫

  • 5.6.2.2. 使用單租戶儲存的一個例子是，每個客戶的資料必須隔離儲存，不能與任何其他客戶的資料混合在一起

  • 5.6.2.3. 每個客戶得到他們自己的資料庫

  • 5.6.2.4. 獨立的資料儲存意味著獨立的模式、桶結構以及與儲存有關的一切

>  5.6.2.4.1. 意味著你可以自由地將每個租戶的儲存環境設計成統一的，或者讓他們任意發展

  • 5.6.3. 多租戶架構則相反，在各組使用者之間共享這些資源

  • 5.6.4. 多租戶儲存允許在一個單一的資料庫中儲存多個租戶

6. 其他

6.1. 儲存是資料工程基礎設施的核心

  • 6.1.1. 儲存無處不在，並且支撐著資料工程生命週期的許多階段

6.2. 你將與擁有你的IT基礎設施的人互動

  • 6.2.1. 常是DevOps、安全和雲架構師

6.3. 資料儲存的責任劃分將在很大程度上取決於相關組織的成熟度

  • 6.3.1. 如果公司處於資料成熟度的早期，則資料工程師可能會管理儲存系統和工作流

6.4. 資料工程師需要確保下游使用者使用的儲存系統是安全可用的、包含高質量的資料、有充足的儲存容量，並在查詢和轉換執行時執行

6.5. 底層設計

  • 6.5.1. 儲存的底層設計很重要，因為儲存是資料工程生命週期的所有階段的關鍵樞紐

  • 6.5.2. 安全

  • 6.5.2.1. 接受安全是一個關鍵的促成因素的想法

  • 6.5.2.2. 像往常一樣，行使最小特權的原則

>  6.5.2.2.1. 除非需要，否則不要給任何人完整的資料庫訪問權

>  6.5.2.2.2. 意味著大多數資料工程師在實踐中不需要完全的資料庫訪問

  • 6.5.3. 資料管理

  • 6.5.3.1. 資料目錄和後設資料管理

>  6.5.3.1.1. 資料透過強大的後設資料得到加強
  • 6.5.3.2. 物件儲存中的資料版本管理
>  6.5.3.2.1. 主要的雲物件儲存系統能夠實現資料版本管理
  • 6.5.3.3. 隱私
>  6.5.3.3.1. 任何具有隱私影響的資料都有一個生命週期，資料工程師必須管理

>  6.5.3.3.2. 隱私法規對儲存系統設計產生了重大影響

>  6.5.3.3.3. 資料工程師必須準備好響應資料刪除請求，並根據需要選擇性地刪除資料

  • 6.5.4. Data Ops

  • 6.5.4.1. DataOps與資料管理並不是正交的，而且存在一個重要的重疊區域

  • 6.5.5. 編排

  • 6.5.5.1. 編排與儲存高度相關

  • 6.5.5.2. 儲存允許資料在管道中流動，而編排是泵

  • 6.5.5.3. 編排還可以幫助工程師應對資料系統的複雜性

相關文章