讀資料工程之道：設計和構建健壯的資料系統07資料架構的原則

1. 企業架構

1.1. 企業架構有很多子集，包括業務、技術、應用程式和資料

1.2. TOGAF

• 1.2.1. The Open Group Architecture Framework，是The Open Group的一個標準

• 1.2.2. 被譽為當今使用最廣泛的架構框架

• 1.2.3. 定義

• 1.2.3.1. “企業架構”上下文中的術語“企業”可以表示整個企業——包括其所有資訊和技術服務、流程和基礎設施——或企業內的一個特定領域

• 1.2.3.2. 架構都跨越多個系統和企業內的多個職能部門

1.3. Gartner

• 1.3.1. 一家全球研究和諮詢公司，撰寫與企業相關的趨勢研究文章和報告

• 1.3.2. 定義

• 1.3.2.1. 企業架構(EA)是一門學科，透過識別和分析變更執行情況，實現預期業務願景和結果，主動和全面地領導企業對破壞性力量做出響應

1.4. EABOK

• 1.4.1. Enterprise Architecture Book of Knowledge

• 1.4.2. 一份由MITRE Corporation製作的企業架構參考資料

• 1.4.3. 定義

• 1.4.3.1. 企業架構是一種組織模型、一個企業的抽象表示，它協調戰略、運營和技術以建立成功的路線圖

1.5. 該書定義

• 1.5.1. 企業架構是支援企業變更的系統設計，透過仔細的權衡的評估做出靈活且可逆的決策來實現

1.6. 共同的主線

• 1.6.1. 變更

• 1.6.2. 對齊

• 1.6.3. 組織

• 1.6.4. 機會

• 1.6.5. 問題解決和遷移

1.7. 關鍵領域

• 1.7.1. 靈活和可逆的決

• 1.7.2. 變更管理

• 1.7.3. 權衡的評估

1.8. 單向門是一個幾乎無法逆轉的決策

1.9. 雙向門是一個很容易逆轉的決策

• 1.9.1. 每個可逆決策（雙向門）的風險都很低，因此組織可以做出更多決策、迭代、改進並快速收集資料

• 1.9.2. 變更管理與可逆決策密切相關，是企業架構框架的中心主題

• 1.9.3. 即使強調可逆決策，企業也常常需要採取重大舉措

1.10. 架構師不只是簡單地規劃IT流程，也不是模糊地展望遙遠的烏托邦式未來

• 1.10.1. 積極解決業務問題並創造新的機會

• 1.10.2. 技術解決方案的存在不是為了它們本身，而是為了支援業務目標

• 1.10.3. 識別當前狀態下的問題（資料質量差、可擴充套件性限制、虧損的業務線）​，定義期望的未來狀態（敏捷的資料質量改進、可擴充套件的雲資料解決方案、改進的業務流程）​，並透過執行小而具體的步驟實現計劃

1.11. 數字系統最終會受到延遲、可靠性、密度和能耗等物理限制的約束

• 1.11.1. 修補軟體錯誤比重新設計和更換飛機機翼要容易得多

• 1.11.2. 工程師還面臨各種非物理限制，如程式語言和框架的特性，以及管理複雜性、預算等方面的實際限制

• 1.11.3. 神奇的想法最終導致糟糕的工程

• 1.11.4. 資料工程師必須在設計最佳系統的每一步都進行權衡，同時最大限度地減少高息技術債

2. 資料架構

2.1. 架構代表了塑造系統的重要設計決策，其中重要的部分是透過變化的成本來衡量的

2.2. 成功的資料工程建立在堅如磐石的資料架構之上

• 2.2.1. 資料架構是企業架構的一個子集，繼承了它的屬性：流程、策略、變更管理和評估權衡

• 2.2.2. 好的資料架構提供了使資料生命週期的每一步和底層設計無縫銜接的能力

• 2.2.3. 資料工程架構是構成資料工程生命週期關鍵部分的系統和框架

• 2.2.3.1. 執行架構包含與人、流程和技術相關的功能需求

2.3. 定義

• 2.3.1. TOGAF定義

• 2.3.1.1. 對企業主要資料型別和來源、邏輯資料資產、物理資料資產和資料管理資源的結構和互動的描述

• 2.3.2. DAMA的定義

• 2.3.2.1. 識別企業的資料需求（無論結構如何）並設計和維護主藍圖以滿足這些需求

• 2.3.2.2. 使用主藍圖來指導資料整合、控制資料資產並使資料投資與業務戰略保持一致

• 2.3.3. 該書定義

• 2.3.3.1. 資料架構是系統設計，以支援企業不斷變化的資料需求，由透過仔細評估權衡做出的靈活且可逆的決策來實現

2.4. 資料架構師的目標是做出重大決策，從而在基礎層面上形成好的架構

• 2.4.1. 好的資料架構透過一組通用的、可廣泛重用的構建塊來滿足業務需求，同時保持靈活性並做出適當的權衡

2.5. 好的資料架構

• 2.5.1. 敏捷性是好的資料架構的基礎

• 2.5.1.1. 承認世界是流動的

• 2.5.1.2. 世界是動態的，資料空間的變化步伐正在加快

• 2.5.2. 好的資料架構是靈活且易於維護。它的發展是為了響應業務內部的變化，從而可能在未來釋放更多價值的新技術和實踐

• 2.5.3. 理想情況下，透過在設計架構時考慮到可逆性，變更的成本會更低

• 2.5.4. 好的資料架構是有生命力的

• 2.5.4.1. 變更和演進是資料架構意義和目的的核心

2.6. 糟糕的資料架構

• 2.6.1. 糟糕的資料架構是緊耦合的、僵化的、過度集中的，或者使用了錯誤的作業工具，阻礙了開發和變更管理

3. 2002年貝索斯API指令

3.1. 今後所有團隊都將透過服務介面公開他們的資料和功能

3.2. 團隊必須透過這些介面相互溝通

3.3. 不允許其他形式的程序間通訊

• 3.3.1. 不允許直接連線

• 3.3.2. 不允許直接讀取另一個團隊的資料儲存

• 3.3.3. 沒有共享記憶體模型

• 3.3.4. 沒有任何後門

• 3.3.5. 唯一允許的通訊是透過網路的服務介面呼叫

3.4. 團隊使用什麼技術並不重要

3.5. 所有服務介面，無一例外，都必須從頭開始設計為可外部化的

• 3.5.1. 團隊必須進行規劃和設計，才能將介面暴露給外界的開發者

3.6. 將資料和服務置於API之後實現了松耦合，並最終促成了我們現在所知道的AWS

4. AWS Well-Architected Framework

4.1. 卓越運營

4.2. 安全

4.3. 可靠性

4.4. 效能效率

4.5. 成本最佳化

4.6. 可持續性

5. 谷歌雲的雲原生架構

5.1. 自動化設計

5.2. 智慧處理狀態

5.3. 智慧處理狀態

5.4. 實行縱深防禦

5.5. 始終進行架構設計

6. 原則1：明智地選擇通用元件

6.1. 資料工程師的主要工作之一是選擇可以在整個組織中廣泛使用的通用元件和實踐

6.2. 當架構師選擇得當並領導有效時，通用元件就會成為促進團隊協作和打破孤島的結構

6.3. 通用元件可以是在組織內具有廣泛適用性的任何東西

6.4. 常見元件包括物件儲存、版本控制系統、可觀測性、監控和編排系統，以及處理引擎

6.5. 每個有適當用例的人都應該可以訪問通用元件，並且鼓勵團隊依賴已經在使用的通用元件，而不是重新發明輪子

6.6. 通用元件必須支援強大的許可權和安全性，以實現團隊之間的資產共享，同時防止未經授權的訪問

6.7. 雲平臺是採用通用元件的理想場所

6.8. 選擇通用元件是一種平衡行為

• 6.8.1. 需要關注整個資料工程生命週期和團隊的需求，利用對單個專案有用的通用元件，同時促進互操作和協作

• 6.8.2. 架構師應該避免做出會阻礙工程師處理特定領域問題的生產力的決策，因為這些決策會迫使工程師採用一刀切的技術解決方案

7. 原則2：為失敗做計劃

7.1. 只要經過足夠的時間，任何硬體元件都會出現故障

• 7.1.1. 要構建高度健壯的資料系統，你必須在設計中考慮故障

7.2. 可用性

• 7.2.1. IT服務或元件處於可操作狀態的時間百分比

7.3. 可靠性

• 7.3.1. 系統在指定時間間隔內執行其預期功能時滿足規定標準的機率

7.4. 恢復時間目標

• 7.4.1. 服務或系統中斷的最長可接受時間

• 7.4.2. 恢復時間目標(Recovery Time Objective，RTO)通常是透過確定故障對業務的影響來設定的

7.5. 恢復點目標

• 7.5.1. 恢復後的可接受狀態

• 7.5.2. 恢復點目標(Recovery Point Objective，RPO)指的是可接受的最大資料丟失

7.6. 工程師在設計故障時需要考慮可接受的可用性、可靠性、RTO和RPO

8. 原則3：可擴充套件性架構

8.1. 可擴充套件系統可以放大以處理大量資料

8.2. 可擴充套件系統可以縮小

• 8.2.1. 一旦負載峰值下降，我們應該自動移除容量以降低成本

• 8.2.2. 一些可擴充套件系統也可以擴充套件到零：它們在不使用時完全關閉

8.3. 彈性系統可以動態擴充套件以響應負載，理想情況下以自動化方式進行

• 8.3.1. 許多無伺服器系統[例如，無伺服器函式和無伺服器聯機分析處理(Online Analytical Processing，OLAP)資料庫]可以自動擴充套件到零

8.4. 部署不適當的擴充套件策略可能會導致系統過於複雜和成本高昂

8.5. 具有一個故障轉移節點的直接關聯式資料庫可能更適合應用程式而不是複雜的叢集安排

8.6. 測量你當前的負載、估計負載峰值並估計未來幾年的負載，以確定你的資料庫架構是否合適

9. 原則4：架構是領導力

9.1. 強大的領導能力與高超的技術能力相結合是罕見且極其寶貴的

9.2. 領導力並不意味著對技術的命令-控制型方法

• 9.2.1. 過去，架構師選擇一種專有資料庫技術並強制每個團隊將資料存放在那裡的情況並不少見

• 9.2.2. 現代架構不應該是命令-控制型或瀑布式的，而是協作和敏捷的

9.3. 資料架構師擁有資料工程師的技術技能，但不再從事日常資料工程

• 9.3.1. 指導當前的資料工程師，在與他們的組織協商後做出謹慎的技術選擇，並透過培訓和領導力傳播專業知識

• 9.3.2. 以最佳實踐培訓工程師，並將公司的工程資源整合在一起，以追求技術和業務方面的共同目標

9.4. 作為資料工程師，你應該實踐架構領導力並尋求架構師的指導

10. 原則5：始終進行架構設計

10.1. 資料架構師的職責不僅僅是維護現有狀態，相反，他們不斷設計新的和令人興奮的東西以應對業務和技術的變化

10.2. 架構師的工作是深入瞭解基線架構（當前狀態）​，開發目標架構，並制定排序計劃以確定優先順序和架構變化的順序

10.3. 資料架構師維護隨時間變化的目標架構和排序計劃

• 10.3.1. 目標架構成為一個移動的目標，根據內部和全球的業務和技術變化進行調整

• 10.3.2. 排序計劃確定交付的即時優先順序

11. 原則6：構建松耦合系統

11.1. 技術特徵

• 11.1.1. 系統被分解成許多小元件

• 11.1.2. 系統透過抽象層與其他服務對接

• 11.1.3. 對一個系統元件的內部改變不需要在其他部分進行修改

• 11.1.3.1. 程式碼更新的細節被隱藏在穩定的API後面

• 11.1.4. 整個系統沒有瀑布式的全球釋出週期

11.2. 組織特徵

• 11.2.1. 許多小團隊對一個大型的、複雜的系統進行設計

• 11.2.2. 團隊透過API定義、訊息模式等向其他團隊釋出其元件的抽象細節

• 11.2.2.1. 團隊不需要關心其他團隊的元件

• 11.2.2.2. 只是使用釋出的API或訊息規範來呼叫這些元件

• 11.2.2.3. 不需要團隊去擔心所請求的功能的內部技術細節

• 11.2.2.4. 團隊透過鬆耦合的溝通方式一起工作

• 11.2.3. 每個團隊都可以快速發展和改進自己的元件，不受其他團隊工作的影響

• 11.2.4. 團隊可以在最短的停機時間內釋出元件更新

11.3. 技術和人的系統的松耦合將使你的資料工程團隊能夠更有效地相互協作，並與公司的其他部門協作

12. 原則7：做出可逆的決策

12.1. 資料格局正在迅速變化

• 12.1.1. 今天的熱門技術或棧是明天的事後想法

• 12.1.2. 大眾輿論迅速轉變

• 12.1.3. 你應該以可逆決策為目標，因為這些決策往往會簡化你的架構並保持其敏捷性

13. 原則8：優先考慮安全

13.1. 每個資料工程師都必須對其構建和維護的系統的安全性承擔責任

13.2. 強化邊界和零信任安全模型

• 13.2.1. 要了解傳統的強化邊界安全模型及其侷限性

• 13.2.2. 在強化的組織安全邊界利用人類目標的安全漏洞的威脅越來越大

• 13.2.3. 在雲原生環境中，強化邊界的概念被進一步削弱

• 13.2.3.1. 所有資產都在某種程度上與外界相連

• 13.2.3.2. 可以在沒有外部連線的情況下定義虛擬私有云(Virtual Private Cloud，VPC)網路，但工程師用來定義這些網路的API控制面仍然面向網際網路

13.3. 共同責任模型

• 13.3.1. 雲的安全

• 13.3.2. 雲中的安全

• 13.3.3. 所有云提供商都以某種形式的這種責任共擔模型運作

13.4. 在當今的企業界，對安全採取命令和控制方法非常普遍，其中安全與網路團隊管理邊界和一般安全實踐

13.5. 所有資料工程師都應該將自己視為安全工程師

13.6. 不承擔這些新的隱性責任可能會導致可怕的後果

13.7. 資料處理的人員必須假設他們最終要對資料的安全負責

14. 原則9：擁抱FinOps

14.1. FinOps是一種不斷髮展的雲財務管理學科和文化實踐，透過幫助工程、財務、技術和業務團隊協作制定資料驅動的支出決策，使組織能夠獲得最大的業務價值

14.2. 提倡DevOps和財務之間建立協作工作關係，從而促進對基礎設施支出的迭代和資料驅動管理（即降低雲的單位經濟效益）​，同時提高成本效率以及最終提高雲環境的盈利能力

14.3. 在雲時代，資料的成本結構發生了巨大變化

• 14.3.1. 責任方必須根據所需的計算和儲存容量來平衡他們的預算

• 14.3.2. 過度購買意味著浪費資金，而購買不足則意味著阻礙未來的資料專案，並導致人員花費大量時間來控制系統負載和資料大小

• 14.3.3. 購買不足可能需要更快的技術更新週期，以及相關的額外成本

14.4. 在雲時代，大多數資料系統都是即付即得且易於擴充套件的

• 14.4.1. 系統可以在查詢成本模型、處理能力成本模型或即付即得模型的另一種變體上執行

• 14.4.2. 資料領導者面臨的新挑戰是管理預算、優先順序和效率

14.5. 雲工具需要一組用於管理支出和資源的流程

• 14.5.1. 過去，資料工程師從效能工程的角度考慮，在一組固定的資源上最大化資料處理的效能，併購買足夠的資源以滿足未來的需求

• 14.5.2. 藉助FinOps，工程師需要學會思考雲系統的成本結構

14.6. FinOps改進了運營監控模型，以持續監控支出

• 14.6.1. FinOps不是簡單地監控Web伺服器的請求和CPU利用率，而是監控無伺服器功能處理流量的持續成本，以及支出觸發警報的峰值

• 14.6.2. 運營團隊還應該考慮成本攻擊

14.7. 在公開共享資料時，資料團隊可以透過設定請求者付費政策來解決這些問題，或者簡單地監控過度的資料訪問支出，並在支出開始上升到不可接受的水平時迅速取消訪問

14.8. 在遇到高昂的雲費用之前儘早開始考慮FinOps