1. 源系統中的資料生成

1.1. 資料工程師的工作是從源系統獲取資料，對其進行處理，使其有助於為下游用例提供服務

1.2. 資料工程師的角色將在很大程度上轉向理解資料來源和目的地之間的相互作用

1.3. 資料工程的最基本的資料管道任務——將資料從A移動到B

2. 資料來源

2.1. 資料是無組織的、缺乏內容描述的事實和資料特徵的集合

2.1.1. 模擬的
2.1.1.1. 模擬資料是在現實世界中生成的，例如語音、手語、紙上書寫或演奏樂器
2.1.1.2. 模擬資料通常是瞬態的，如通常的口頭對話，在對話結束後聲音資料也就消失了
2.1.2. 數字的
2.1.2.1. 數字資料要麼是透過將模擬資料轉換為數字形式生成的，要麼是數字系統直接生成的
2.1.2.2. 將模擬語音轉換為數字文字的移動簡訊應用程式
2.1.2.3. 電子商務平臺上的信用卡交易資訊

2.2. 資料在我們周圍的世界無處不在

2.2.1. 物聯網裝置、信用卡終端、望遠鏡感測器、股票交易等都在生成資料

3. 源系統

3.1. 源系統以各種方式生成資料

3.2. 檔案和非結構化資料

3.2.1. 檔案是位元組序列，通常儲存在磁碟上
3.2.2. 應用程式經常將資料寫入檔案
3.2.3. 檔案可以儲存本地引數、事件、日誌、影像和音訊
3.2.4. 檔案是一種通用的資料交換媒介
3.2.5. 主要原始檔格式型別（手動生成或源系統輸出的檔案）有Excel、CSV、TXT、JSON和XML
3.2.5.1. 結構化的(Excel、CSV)
3.2.5.2. 半結構化的(JSON、XML、CSV)
3.2.5.3. 非結構化的(TXT、CSV)

3.3. API

3.3.1. 應用程式介面是系統間交換資料的標準方式
3.3.2. API仍然存在許多針對資料的複雜性，需要工程師管理
3.3.3. 資料工程師也必須投入大量資金和相當多的精力用於維護自定義的API連線

3.4. 應用程式資料庫（OLTP系統）

3.4.1. 應用程式資料庫儲存應用程式的狀態
3.4.2. 應用程式資料庫是聯機事務處理系統
3.4.2.1. 以高速率讀取和寫入單個資料記錄的資料庫
3.4.2.2. OLTP系統通常被稱為事務資料庫，但這並不一定意味著所討論的系統支援原子事務
3.4.2.3. OLTP資料庫支援低延遲和高併發
3.4.2.4. 當成千上萬甚至數百萬使用者可能同時與應用程式互動、同時更新和寫入資料時，OLTP資料庫可以很好地作為應用程式後端
3.4.3. OLTP系統不太適合由大規模分析驅動的用例，由於其單個查詢也必須掃描大量資料
3.4.4. 小公司直接在OLTP上執行分析
3.4.4.1. 適用於短期但最終無法擴充套件

3.5. 聯機分析處理系統

3.5.1. 聯機分析處理系統是為執行大型分析查詢而構建的，通常在處理單個記錄的查詢方面效率低下
3.5.2. OLAP來指代任何支援大規模互動式分析查詢的資料庫系統
3.5.3. OLAP的線上部分透過不斷地監聽傳入的查詢，使OLAP系統適合互動式分析

3.6. 變更資料捕獲

3.6.1. 變更資料捕獲是一種提取資料庫中發生的每個變更事件（插入、更新、刪除）的方法
3.6.2. CDC經常用於近乎實時地在資料庫之間進行復制或為下游處理建立事件流
3.6.3. 關聯式資料庫通常直接生成儲存在資料庫伺服器上的事件日誌，可以對其進行處理以建立一個流
3.6.4. 許多雲端NoSQL資料庫可以將日誌或事件流傳送到目標儲存位置

3.7. 日誌

3.7.1. 日誌收集有關係統中發生的事件的資訊
3.7.2. 日誌是一個豐富的資料來源，對下游資料分析、ML和自動化具有潛在價值
3.7.2.1. 作業系統
3.7.2.2. 應用程式
3.7.2.3. 伺服器
3.7.2.4. 容器
3.7.2.5. 網路
3.7.2.6. 物聯網裝置
3.7.3. 所有日誌都跟蹤事件和其後設資料
3.7.4. 日誌應該記錄誰、發生了什麼和什麼時候
3.7.4.1. 與事件關聯的人員、系統或服務賬戶
3.7.4.2. 事件和相關後設資料
3.7.4.3. 事件的時間戳
3.7.5. 日誌編碼
3.7.5.1. 二進位制編碼日誌

>  3.7.5.1.1. 透過自定義的緊湊格式編碼資料來提高空間效率和I/O速度

3.7.5.2. 半結構化日誌

>  3.7.5.2.1. 被編碼為物件序列化格式（JSON，也可能是其他）的文字

>  3.7.5.2.2. 半結構化日誌是機器可讀和可移植的

>  3.7.5.2.3. 效率遠低於二進位制日誌

3.7.5.3. 純文字（非結構化）日誌

>  3.7.5.3.1. 儲存從軟體的控制檯輸出的日誌

3.7.6. 日誌解析度
3.7.6.1. 日誌以各種解析度和日誌等級建立
3.7.6.2. 日誌解析度是指一個日誌中捕獲的事件資料量
3.7.6.3. 捕獲大資料系統中的所有資料變化通常是不切實際的
3.7.6.4. 日誌等級是指記錄一個日誌條目所需的條件，具體涉及錯誤和除錯資訊
3.7.7. 日誌延遲：批處理或實時
3.7.7.1. 批處理日誌通常被連續寫入一個檔案
3.7.7.2. 將單個日誌條目寫入訊息系統

3.8. 資料庫日誌

3.8.1. 預寫日誌
3.8.1.1. 以特定資料庫的格式儲存的二進位制檔案
3.8.1.2. 在資料庫的保證和可恢復性中起著至關重要的作用
3.8.1.3. 確認伴隨著與日誌相關的保證：即使伺服器出現故障，它也可以透過完成日誌中未完成的工作來在重新啟動時恢復其狀態
3.8.2. 資料庫日誌在資料工程中非常有用，特別是利用CDC從資料庫更改中生成事件流

3.9. CRUD

3.9.1. 代表建立、讀取、更新和刪除，是程式設計中常用的事務模式，代表持久化儲存的四種基本操作
3.9.2. CRUD是在資料庫中儲存應用程式狀態的最常見模式
3.9.3. CRUD的一個基本原則是資料必須在使用前建立

3.10. ⑩僅插入

3.10.1. 僅插入模式將歷史記錄直接保留在資料的表中
3.10.2. 新記錄沒有更新記錄，而是插入了一個新的時間戳，指示它們的建立時間
3.10.3. 僅插入模式直接在表本身中維護資料庫日誌，如果應用程式需要訪問歷史記錄，則這種模式特別有用
3.10.4. 僅插入模式的分析通常與常規CRUD應用程式表一起使用
3.10.5. 在僅插入模式ETL中，只要CRUD表中發生更新，資料管道就會在目標分析表中插入一條新記錄
3.10.6. 缺點
3.10.6.1. 表可能會變得非常大，尤其是在資料頻繁更改的情況下
3.10.6.2. 記錄查詢會產生額外的開銷，因為查詢當前狀態涉及執行MAX(created_timestamp)

3.11. ⑾訊息和流

3.11.1. 訊息是在兩個或多個系統之間通訊的原始資料
3.11.1.1. 訊息通常透過訊息佇列從一個釋出者到一個消費者，一旦訊息被傳遞，它就會從佇列中移除
3.11.1.2. 在事件驅動系統中，訊息是離散的單一訊號
3.11.2. 流是事件記錄的僅追加日誌
3.11.2.1. 流被獲取並儲存在事件流平臺中
3.11.2.2. 當事件發生時，它們會按時間戳或ID順序累積
3.11.2.3. 在分散式系統下需要注意，事件並不總是按準確的順序傳遞
3.11.2.4. 當你關心許多事件中發生的事情時，推薦使用流
3.11.2.5. 由於流的僅追加性質，流中的記錄會儲存很長時間（通常為數週或數月），從而允許對記錄進行復雜的操作
3.11.2.6. 處理流的系統也可以處理訊息，流平臺經常用於訊息傳遞
3.11.2.7. 當我們想要執行訊息分析時，我們經常在流中累積訊息

3.12. ⑿時間型別

3.12.1. 時間是所有資料獲取的基本考慮因素，但在流處理的上下文中它變得更加關鍵和微妙，因為我們將資料視為連續資料並期望在生成後不久就使用它
3.12.2. 事件時間表示事件在源系統中何時產生，包括原始事件本身的時間戳
3.12.3. 在事件被下游獲取和處理之前，會發生不確定的時間滯後
3.12.4. 事件經過的每個階段的時間戳都需要被記錄
3.12.5. 日誌需要記錄事件發生時以及每個階段的時間（建立、獲取和處理時間）
3.12.6. 時間戳日誌可以準確跟蹤資料在資料管道中的移動
3.12.7. 處理時間發生在獲取時間之後，此時資料被處理（通常是轉換）
3.12.8. 處理時長是處理資料所花費的時間，以秒、分鐘、小時等為單位

4. ACID

4.1. 對原子事務的支援是資料庫關鍵特徵之一，統稱為ACID

4.1.1. 原子性
4.1.1.1. 原子事務

>  4.1.1.1.1. 原子事務是在一個提交中有多個更改

4.1.2. 一致性
4.1.2.1. 一致性意味著資料庫的任何讀取檢索都將返回最後寫入版本
4.1.3. 隔離性
4.1.3.1. 隔離性意味著如果針對同一事物同時進行兩個更新，則最終資料庫狀態將與這些更新的提交順序一致
4.1.4. 永續性
4.1.4.1. 永續性表示提交的資料永遠不會丟失，即使在停電的情況下也是如此

4.2. 支援應用程式後端不需要完全具備ACID特性，放寬這些限制可以大大提高效能和規模

4.3. 文件資料庫叢集可以透過降低一致性來獲取更高的文件提交率

4.4. 圖資料庫還可以處理事務用例

讀資料工程之道：設計和構建健壯的資料系統14源系統

1. 源系統中的資料生成

2. 資料來源

3. 源系統

4. ACID

相關文章