1. 資料共享
1.1. 雲資料共享的核心概念是，多租戶系統支援租戶之間共享資料的安全策略
1.2. 任何具有細粒度許可權系統的公有云物件儲存系統都可以成為資料共享的平臺
1.3. 資料共享也簡化了資料市場的概念，在幾個流行的雲和資料平臺上都可用
1.4. 資料共享還可以簡化組織內的資料管道
1.5. 資料共享和資料網格與我們的通用架構元件的理念緊密結合
2. 第三方資料來源
2.1. 技術的消費者化意味著每家公司現在基本上都是技術公司
2.2. 資料是有黏性的，透過允許將公司的資料整合和擴充套件到使用者的應用中，就會產生一個巨大的推動
2.3. 副作用是現在幾乎有無限的第三方資料來源
2.4. 第三方資料的直接訪問通常是透過API、雲平臺上的資料共享，或資料下載來完成
3. 訊息佇列和事件流平臺
3.1. 事件驅動架構在軟體應用程式中無處不在
3.2. 訊息佇列
-
3.2.1. 訊息佇列是一種使用釋出和訂閱模式在離散系統之間非同步傳送資料（通常是小的單獨訊息，以千位元組計）的機制
-
3.2.2. 訊息佇列允許應用程式和系統相互解耦，並被廣泛用於微服務架構中
-
3.2.3. 訊息佇列對訊息進行緩衝，以處理瞬時的負載高峰，並透過具有複製功能的分散式架構使訊息持久
-
3.2.4. 訊息佇列是解耦微服務和事件驅動架構的一個關鍵要素
-
3.2.5. 訊息佇列需要注意的一些事項是交付頻率、訊息排序和可擴充套件性
-
3.2.5.1. 訊息的排序和交付
3.2.5.1.1. 訊息的建立、傳送和接收順序會對下游使用者產生重大影響
3.2.5.1.2. 訊息佇列通常採用模糊的順序概念或者先進先出(First In，First Out，FIFO)的概念
3.2.5.1.3. 除非你的訊息佇列技術保證，否則不要假設你的訊息會按順序交付
3.2.5.1.4. 通常需要以不按順序的訊息傳遞進行架構設計
-
3.2.5.2. 傳送頻率
3.2.5.2.1. 訊息可以傳送恰好一次，或至少傳送一次
3.2.5.2.2. 如果訊息被髮送恰好一次，那麼在訂閱者確認訊息後，訊息就會消失，不會再被髮送
3.2.5.2.3. 至少傳送一次的訊息可以被多個訂閱者或同一訂閱者多次使用
3.2.5.2.4. 系統應該是冪等的
3.2.5.2.4.1. 在一個冪等的系統中，處理一次訊息的結果與多次處理訊息的結果是相同的
-
3.2.5.3. 可擴充套件性
3.2.5.3.1. 在事件驅動的應用程式中使用的最流行的訊息佇列是橫向可擴充套件的，這可以使事務在多個伺服器上執行
3.2.5.3.2. 佇列可以動態地擴大和縮小規模，在系統落後時緩衝訊息，並且持久地儲存訊息以避免故障
-
-
3.2.6. 訊息佇列主要用於傳導具有一定交付保證的訊息
3.3. 事件流平臺
-
3.3.1. 流資料（在這種情況下，訊息和流）跨越了許多資料工程生命週期階段
- 3.3.1.1. RDBMS通常直接連線到一個應用程式，而流資料的界限有時並不那麼清晰
-
3.3.2. 同樣的事件流平臺可以在獲取和轉換階段使用，為實時分析處理資料
-
3.3.3. 事件流平臺是訊息佇列的延續，即訊息從生產者提供給消費者
-
3.3.4. 事件流平臺是用來獲取和處理記錄有序的資料的
-
3.3.5. 在事件流平臺中，資料被保留一段時間，並且有可能從過去的時間點重放訊息
-
3.3.6. 主題
- 3.3.6.1. 在一個事件流平臺中，生產者將事件流向一個主題，即相關事件的集合
-
3.3.7. 流分割槽
-
3.3.7.1. 流分割槽是將一條訊息流細分為多條流
-
3.3.7.2. 資訊透過分割槽鍵分佈在各分割槽中
-
3.3.7.3. 具有相同分割槽鍵的訊息將總是在同一個分割槽中結束
-
3.3.7.4. 設定一個分割槽鍵，使應該一起處理的訊息具有相同的分割槽鍵
-
3.3.7.5. 流分割槽的一個關鍵問題是確保你的分割槽鍵不會產生熱點，即交付給一個分割槽的訊息數量不平均
-
-
3.3.8. 容錯性和彈性
-
3.3.8.1. 事件流平臺是典型的分散式系統，資料流儲存在不同的節點上
-
3.3.8.2. 如果一個節點壞了，另一個節點會取代它，而流仍然可以訪問
3.3.8.2.1. 這意味著記錄不會丟失
-
3.3.8.3. 當你需要一個能夠可靠地產生、儲存和獲取事件資料的系統時，流媒體平臺的容錯性和彈性使它成為一個不錯的選擇
-
4. 和誰一起工作
4.1. 系統和資料利益相關者
-
4.1.1. 資料利益相關者擁有並控制你對想要的資料的訪問，一般由IT部門、資料治理小組或第三方處理
-
4.1.2. 系統和資料利益相關者通常是不同的人或團隊
- 4.1.2.1. 可能是相同的
-
4.1.3. 在資料工程師和源系統的利益相關者之間建立一個反饋途徑，促進源系統相關人員建立對資料如何被消費和使用的意識
4.2. 當上遊源資料發生某種情況時，無論是架構或資料更改、伺服器或資料庫故障，還是其他重要事件，你需要意識到這些問題將對你的資料工程系統產生的影響
5. 資料契約
5.1. 資料契約是源系統所有者和從該系統獲取資料的團隊之間的書面協議
5.2. 契約應該說明獲取什麼資料、透過什麼方法（完全、增量）、多長時間，以及誰（個人、團隊）是源系統和獲取的聯絡人
5.3. 資料合同應該儲存在一個知名的、容易找到的地方
6. 資料底層設計及其對源系統的影響
6.1. 安全
-
6.1.1. 安全是至關重要的
-
6.1.2. 最不希望的就是意外地在源系統中創造一個漏洞點
-
6.1.3. 源系統的架構是否對資料進行了安全和加密，包括靜止的資料和傳輸中的資料？
-
6.1.4. 是否必須透過公共網際網路訪問源系統，或者你是否使用虛擬專用網路(Virtual Private Network，VPN)？
-
6.1.5. 將源系統的密碼、令牌和憑證安全地鎖起來
-
6.1.6. 信任源系統嗎？
6.2. 資料管理
-
6.2.1. 只能對源系統和它們產生的資料進行外圍控制
-
6.2.2. 上游資料和系統是否以可靠的、易於理解的方式進行管理？
-
6.2.3. 誰來管理這些資料？
-
6.2.4. 如何確保上游系統的資料質量和完整性？
-
6.2.5. 上游模式是可能發生變化的
-
6.2.6. 上游記錄的建立是否由主資料管理實踐或系統控制？
-
6.2.7. 是否能接觸到原始資料，或者資料是否會被混淆？
-
6.2.8. 根據法規，你是否應該訪問這些資料？
6.3. Data Ops
-
6.3.1. 確保你能觀察和監控源系統的正常執行時間和使用情況，並在事件發生時做出反應
-
6.3.2. 在資料工程和支援源系統的團隊之間建立一個清晰的溝通鏈
-
6.3.3. 將DevOps納工作流和文化
- 6.3.3.1. 有助於實現DataOps（DevOps的一個兄弟姐妹）的目標，迅速解決和減少錯誤
-
6.3.4. 自動化
-
6.3.4.1. 自動源系統會受到自動化的影響，如程式碼更新和新功能化
-
6.3.4.2. 為你的資料工作流設定的DataOps自動化
-
-
6.3.5. 可觀測性
-
6.3.5.1. 當源系統出現問題時，你如何得知
-
6.3.5.2. 設定檢查以確保來自源系統的資料符合下游使用的期望
-
-
6.3.6. 事故響應
- 6.3.6.1. 如果有壞事發生，你有什麼計劃？
6.4. 資料架構
-
6.4.1. 與資料管理類似，除非你參與了源系統架構的設計和維護，否則你對上游源系統架構的影響很小
-
6.4.2. 應該瞭解上游架構是如何設計的，以及它的優勢和劣勢
-
6.4.3. 可靠性
-
6.4.3.1. 所有的系統在某些時候都會受到熵的影響，輸出會偏離預期的內容
-
6.4.3.2. 漏洞被引入，隨機故障發生
-
-
6.4.4. 永續性
- 6.4.4.1. 一切都會失敗
-
6.4.5. 可用性
- 6.4.5.1. 如何保證源系統在它應該執行的時候是正常的、執行的、可用的？
-
6.4.6. 人員
- 6.4.6.1. 誰負責源系統的設計，你怎麼知道架構中是否有突破性變化？
6.5. 編排
-
6.5.1. 確保你的編排能夠訪問源系統，這需要正確的網路訪問、認證和授權
-
6.5.2. 節奏和頻率
- 6.5.2.1. 資料是否按照固定的時間表提供，或者你是否可以隨時訪問新的資料？
-
6.5.3. 通用框架
- 6.5.3.1. 軟體和資料工程師是否使用相同的容器管理器
6.6. 軟體工程
-
6.6.1. 隨著資料格局向簡化和自動訪問源系統的工具轉變，你很可能需要寫程式碼
-
6.6.2. 網路
- 6.6.2.1. 確保你的程式碼能夠訪問源系統所在的網路
-
6.6.3. 認證和授權
-
6.6.4. 訪問模式
- 6.6.4.1. 如何訪問資料的？
-
6.6.5. 編排
- 6.6.5.1. 程式碼是否與編排框架整合，並且可以作為編排工作流執行？
-
6.6.6. 並行化
- 6.6.6.1. 如何管理和擴充套件對源系統的並行訪問的？
-
6.6.7. 部署
- 6.6.7.1. 如何處理原始碼變化的部署的？
7. 卓越運營
7.1. DevOps、DataOps、MLOps、XOps
7.2. 應該在整個棧上下延伸，並且支援資料工程和生命週期
7.3. 很理想，但往往不能完全實現
7.4. 源系統和它們的資料在資料工程的生命週期中是至關重要的
7.5. 軟硬皆施
- 7.5.1. 與源系統團隊更好的合作可以帶來更高質量的資料、更成功的結果，以及更好的資料產品
7.6. 在資料工程中，主動溝通你的資料需求來幫助應用程式團隊
7.7. 尋找機會來建立面向使用者的資料產品