良好資料架構的原則

架構原則可以幫助我們評估重大的架構決策和實踐方法，並以此基礎從整體的角度來討論良好的架構。我們會從多個來源尋找架構原則的靈感，尤其是AWS Well-Architected Framework和Google Cloud之 Cloud-Native Architecture的五項原則。

AWS Well-Architected Framework由六大支柱組成：卓越的運營（Operational excellence）、安全性（Security）、可靠性（Reliability）、性能成效（Performance efficiency）、成本優化（Cost optimization）、可持續性（Sustainability）。

Google Cloud之雲端原生架構的五項原則如下：設計自動化、善於處理狀態、偏好託管服務、實踐深度防禦、始終保持架構思維。

我們建議你仔細研究這兩個框架，找出有價值的想法，並確定分歧點。我們想用以下資料工程架構原則來擴展或闡述這些支柱：

原則1：明智地選擇常用組件

資料工程師的主要工作之一，是選擇可在整個組織中廣泛使用的常見組件和實踐方法。當架構師選擇得當並有效領導時，通用組件將成為促進團隊協作和打破隔閡的基礎。通用組件與共享的知識和技能結合，可以在團隊內部和團隊之間實現敏捷性。

通用組件可以是在組織內具有廣泛適用性的任何東西。常見組件包括物件儲存、版本控制系統、可觀測性、監控和編排系統以及處理引擎。具有適當使用案例的每個人都應該可以取用通用組件，並鼓勵團隊依賴已在使用的通用組件，而不是重新發明輪子。通用組件必須支援強大的許可權和安全性，以便在團隊之間共享資產，同時防止未經授權的取用。

選擇通用組件是一種平衡的過程。一方面，你需要關注整個資料工程生命週期和團隊的需求，利用對個別專案有用的通用組件，同時促進互通性和協作。另一方面，架構師應避免其強制使用通用技術解決方案的決策，阻礙工程師處理特定領域問題時的工作效率。

原則2：為失敗做規劃

要建構高度可靠的資料系統，必須在設計中考慮到故障問題。以下是幾個評估故障場景的關鍵術語：

可用性：IT服務或組件處於可運行狀態的時間百分比。

可靠性：系統在指定的時間間隔內，執行其預期功能並符合定義標準的概率。

恢復時間目標：服務或系統中斷（outage）的最大可接受時間。恢復時間目標（recovery time objective，RTO）通常是透過評估中斷對業務的影響來確定的。對於內部報告系統來說，一天的RTO可能是可接受的。但對線上零售商來說，僅僅五分鐘的網站中斷就可能會對業務產生重大不利的影響。

恢復點目標：恢復後的可接受狀態。在資料系統中，經常在中斷期間丟失資料。在此情況下，恢復點目標（recovery point objective，RPO）指的是可接受的最大資料丟失量。

工程師在設計失敗容忍性時，需要考慮可接受的可靠性、可用性、恢復時間目標（RTO）和恢復點目標（RPO）。這將影響他們在評估可能的故障場景時所做的架構決策。

原則3：為可擴展性進行架構設計

在資料系統中，可擴展性包括兩個主要能力。首先，可擴展的系統能夠擴展以處理大量資料。我們可能需要啟動一個大型叢集（large cluster）來訓練一個PB級的客戶資料模型，或者擴展一個串流攝取系統（streaming ingestion system）來處理短暫的負載峰值。我們的擴展能力使我們能夠暫時處理極端負載。其次，可擴展的系統能夠縮小規模。一旦負載峰值消退，我們應該自動移除容量以降低成本。一個彈性系統（elastic system）可以根據負載動態調整規模，理想情況下是以自動化方式實現。

有些可擴展的系統也可以被調整成零規模（scale to zero）：在不使用時完全關閉。一旦大型模型訓練作業完成後，我們可以刪除該叢集。許多無伺服器系統（例如，無伺服器函數（serverless functions）和無伺服器（serverless）線上分析處理（online analytical processing，OLAP）資料庫），可以自動調整成零規模。

請注意，部署不適當的擴展策略可能會導致系統過於複雜及成本高昂。對於某些應用程式而言，一個具有故障轉移節點的簡單關聯式資料庫，可能比一個複雜的叢集配置更合適。測量當前負載，估算負載峰值，並估計未來幾年的負載，以確定你的資料庫架構是否合適。如果你的初創公司的成長速度遠遠超過預期，那麼這種成長也應該帶來更多的可用資源，可以用來重新設計系統架構以實現更好的擴充性。

原則4：架構就是領導力

資料架構師負責技術決策和架構描述，並透過有效的領導和培訓來傳播這些選擇。資料架構師應該具有很高的技術能力，但大多數的具體工作可以委派給其他人。強大的領導能力和高度的技術能力相結合是罕見且極其有價值的。最好的資料架構師會認真對待這種雙重角色。

馬丁．福勒（Martin Fowler）描述了理想軟體架構師的具體原型，這個原型在他的同事戴夫．賴斯（Dave Rice）身上得到了很好的體現：在許多方面，Architectus Oryzus最重要的活動之一是指導開發團隊，提高他們的水準，讓他們能夠處理更複雜的問題。提高開發團隊的能力為架構師提供了比「成為唯一決策者」更大的影響力，進而避免了成為架構瓶頸的風險。

理想的資料架構師也具有類似的特徵。他們擁有資料工程師的技能，但不再每天從事資料工程；他們會指導當前的資料工程師，與組織協商做出謹慎的技術選擇，並透過培訓和領導力傳播專業知識。他們培訓工程師遵循最佳實踐方法，並將公司的工程資源整合在一起，以追求技術和業務方面的共同目標。

作為一名資料工程師，你應該實踐架構領導力，並尋求架構師的指導。最終，你很可能會自己擔任架構師的角色。

原則5：始終保持架構思維

我們直接從Google Cloud之雲端原生架構的五項原則中借用此一原則。資料架構師的角色不僅僅是為了維護現有狀態；相反地，他們不斷根據業務和技術的變化設計令人興奮的新東西。根據EABOK（https://oreil.ly/i58Az）的說法，架構師的工作是深入瞭解基本架構（baseline architecture）（現狀），開發目標架構（target architecture），並制定一個有序計畫（sequencing plan）來確定優先順序和架構變更的順序。

以下是我們的補充：現代架構不應該是命令和控制（command-and-control）或瀑布式（waterfall）的，而應該是協作和敏捷的。資料架構師維護著一個隨時間變化的目標架構（target architecture）和有序計畫（sequencing plans）。目標架構成為一個不斷變動的目標，根據內部和全球的業務和技術變化進行調整。有序計畫確定了交付的即時優先順序。（本文摘錄整理自《資料工程基礎》，碁峰資訊提供）

圖片來源_碁峰資訊

 書名  資料工程基礎（Fundamentals of Data Engineering）

Joe Reis, Matt Housley／著；蔣大偉／譯

碁峰資訊出版

定價：980元

 作者簡介 

圖片來源_Ternary Data

Joe Reis

是一位具有商業頭腦的資料狂熱者，已在資料行業工作了20年，職責範圍包括統計建模、預測、機器學習、資料工程、資料架構等幾乎所有相關領域。Joe是Ternary Data的CEO和共同創辦人，這是一家位於猶他州鹽湖城的資料工程和架構諮詢公司。

圖片來源_Ternary Data

Matt Housley

是一位資料工程顧問和雲端專家。在早年學習過Logo、Basic和6502組合語言及其程式設計經驗，之後他在猶他大學獲得了數學博士學位。Matt隨後開始從事資料科學工作，最終專攻基於雲端的資料工程。他與Joe Reis共同創立了Ternary Data公司。