讀資料工程之道：設計和構建健壯的資料系統10技術選擇

躺柒發表於2024-10-16

1. 選擇技術

1.1. 架構第一，技術第二

1.2. 現如今資料工程師因技術種類過於繁雜豐富而感到選擇困難

1.3. 許多完整並可立即使用的資料技術觸手可得

  • 1.3.1. 開原始碼

  • 1.3.2. 託管開源

  • 1.3.3. 軟體專利

  • 1.3.4. 服務專利

1.4. 資料工程核心：設計出可靠穩定的系統來承載資料全週期的流動，並滿足不同終端使用者的需求

  • 1.4.1. 資料工程師的也需要選擇合適的資料技術來引導資料在整個生命週期裡為應用程式和使用者服務

1.5. 判斷資料技術好壞的標準是很簡單的：選擇這個技術有沒有增加產品的商業價值

  • 1.5.1. 資料工程師必須選擇好的技術來儘可能實現最佳的資料產品

1.6. 資料架構是一種戰略，而資料工具是一種戰術

  • 1.6.1. 資料架構是資料系統的高層設計、框架和藍圖，以使資料系統實現它的商業戰略

  • 1.6.1.1. 回答了“是什麼？​”​“為什麼？​”​“什麼時候？​”這三個問題

  • 1.6.2. 資料工具是將架構落到實處的方法

  • 1.6.2.1. 資料工具是將架構落到實處的方法

1.7. 脫離軌道

  • 1.7.1. 在設計出資料架構之前就選擇了技術

  • 1.7.1.1. 提前選擇技術會導致最終產出的是技術的胡亂拼湊而不是真正的資料架構

  • 1.7.2. 原因

  • 1.7.2.1. 新奇事物綜合症(shiny

object syndrome)

  • 1.7.2.2. 簡歷驅動開發(resume-driven

development)

  • 1.7.2.3. 對架構缺乏經驗

1.8. 選擇正確的技術並非易事，尤其是當新技術和模式每天都在出現時

  • 1.8.1. 現在可能是歷史上評估和選擇技術最混亂的時期

  • 1.8.2. 選擇技術是用例、成本、構建與購買以及模組化之間的平衡

  • 1.8.3. 始終以與架構相同的方式來處理技術的選擇：評估權衡並以可逆決策為目標

2. 團隊大小和能力

2.1. 需要評估的第一件事就是團隊的大小和團隊成員的技術能力

  • 2.1.1. 你的團隊的大小會直接影響選擇的技術型別

  • 2.1.2. 小團隊

  • 2.1.2.1. 也許只有一個人

  • 2.1.2.2. 成員需要同時扮演各種角色

  • 2.1.3. 大團隊

  • 2.1.3.1. 每個成員都有特定的角色

2.2. 簡單和複雜的技術的共性是：團隊的大小會基本上決定你的團隊有多少精力和時間可以投入研究複雜問題的解決方案

2.3. 貨物崇拜主義軟體工程(cargo-cult engineering)

  • 2.3.1. 小的資料團隊在閱讀大公司的科技前沿博文，並且嘗試在自己的團隊復現相應的技術與實踐

  • 2.3.2. 一種會耗費大量時間和金錢的錯誤選擇，通常能得到的回報很少

2.4. 推薦保持使用團隊熟悉的技術和工作流

2.5. 學習新的技術、語言或者工具需要大量的時間投入，所以需要明智地去規劃這方面的投入

3. 加速市場化

3.1. 對於技術而言，快速地投入市場是必勝之道

  • 3.1.1. 需要選擇能讓資料需求開發得更快速的技術，同時能保持高質量標準和高安全性

  • 3.1.2. 需要開發者在釋出、學習、迭代中不斷反饋和改進

3.2. 追求完美是保持優秀的敵人

  • 3.2.1. 猶豫不決和少有產出是資料團隊的死亡前兆

3.3. 團隊需要儘早實現價值交付並且保持階段性地交付頻率

  • 3.3.1. 你的團隊成員會更熟練地使用他們已知的工具

  • 3.3.2. 為了避免無差別的繁重工作讓你的團隊少有價值產出

  • 3.3.3. 選擇能幫助團隊快速、可靠、安全地進行開發的工具

4. 互操作性

4.1. 互操作性描述了多種技術和系統之間是如何連線、互換資訊和互動的

4.2. 標準化是實現互操作性的前提

  • 4.2.1. 幾乎所有的資料庫都會允許使用Java資料庫連線(Java

Database Connectivity，JDBC)或開放式資料庫連線(Open Database Connectivity，ODBC)，這樣使用者就可以透過標準介面輕鬆連線資料庫

4.3. 互操作性無須事先定義好標準

  • 4.3.1. 描述性狀態遷移(Representational State Transfer，REST)並不完全是標準化的API，每個REST

API有自己的定義

  • 4.3.2. 供應商或者開源軟體(Open Source Software，OSS)專案負責保證與其他技術和系統的順利整合

4.4. 在整個資料工程生命週期中，要時刻注意到連線你所選擇的不同技術的困難程度

5. 成本最佳化和商業價值

5.1. 在完美世界裡，你可以無須考慮成本、時間、商業價值就可以嘗試使用最新最前沿的技術

5.2. 在現實世界中，預算和時間都是有限的，並且成本是資料架構和技術選擇的最主要限制

5.3. 總擁有成本

  • 5.3.1. Total Cost of Ownership，TCO

  • 5.3.2. 一個方案的總估計成本，包括使用的產品和服務的直接成本與間接成本

  • 5.3.2.1. 直接成本可以直接來自於方案

>  5.3.2.1.1.             團隊的工資

>  5.3.2.1.2.             AWS的服務消費
  • 5.3.2.2. 間接成本
>  5.3.2.2.1.             間接成本

>  5.3.2.2.2.             和該方案無關的

  >   5.3.2.2.2.1.              無論選擇哪種方案都需要被花費的

  • 5.3.3. 費用分為兩大類

  • 5.3.3.1. 資本支出

>  5.3.3.1.1.             capital expenses

  >   5.3.3.1.1.1.              capex

>  5.3.3.1.2.             前期投資

>  5.3.3.1.3.             支付是需要今天完成的

>  5.3.3.1.4.             資產並會隨著時間慢慢折舊

>  5.3.3.1.5.             資本支出，並需要制定長期計劃以實現前期付出和費用的正投資回報率(R O I)

>  5.3.3.1.6.             資本支出注重長期的計劃
  • 5.3.3.2. 運營支出
>  5.3.3.2.1.             operation

expenses

  >   5.3.3.2.1.1.              opex

>  5.3.3.2.2.             運營支出是漸進的並且分散於各時間段的

>  5.3.3.2.3.             運營支出注重短期的計劃

>  5.3.3.2.4.             運營支出幾乎是即付即得的，且有更多靈活性

  >   5.3.3.2.4.1.              資料工程師需要切實地對待靈活性

>  5.3.3.2.5.             更像是直接成本，能更容易歸因於資料專案

>  5.3.3.2.6.             隨著雲技術的出現而發生了改變，因為資料平臺服務允許依據實際消費模型來付費

  >   5.3.3.2.6.1.              運營支出能更好地給予工程師團隊選擇軟體和硬體的能力

  >   5.3.3.2.6.2.              雲端服務使得資料工程師可以快速地迭代各種軟體和技術配置，通常費用也不貴

>  5.3.3.2.7.             鑑於運營支出在靈活性和低初始成本上的優勢，我們建議資料工程師優先考慮運營支出，將技術集中在雲上並且使用靈活的即付即得技術

5.4. 總擁有機會成本

  • 5.4.1. Total Opportunity Cost of Ownership，TOCO

  • 5.4.2. 在選擇技術、架構或流程後所損失的機會的成本

  • 5.4.3. 就算在雲環境中，一旦將個技術、棧，或者管道變成生產資料流程的核心部分，就很難改變了

  • 5.4.4. 減少機會成本的第一步是睜大眼睛仔細進行評估

  • 5.4.4.1. 不靈活的資料技術就像是為熊準備的陷阱，很進入，卻很難擺脫

5.5. FinOps

  • 5.5.1. 典型的雲端消費本質上是一種運營支出：公司為執行重要資料流程的服務付費，而不是前期投資和長期的固定投資

  • 5.5.2. FinOps的目標就是透過應用類似DevOps的實踐來監控和動態調整系統，以全面實現賬戶財務管理和創造商業價值

  • 5.5.3. FinOps是創造價值

  • 5.5.3.1. 雲可以創造更多的收入、促進使用者的大量增加、增快產品的釋出速度，甚至幫助關閉資料中心

  • 5.5.3.2. 快速迭代和動態擴充套件是創造商業價值的無價之寶

6. 不變的與暫時的技術

6.1. 建立更好的未來的出發點是難能可貴的，但這經常導致過度設計和過度工程

  • 6.1.1. 現在為未來選擇的工具也許在未來真正到來時已經陳舊過時

  • 6.1.2. 未來通常和我們幾年前所設想的不同

6.2. 專注於現在

  • 6.2.1. 選擇對於現在或者不遠的將來最好的工具

  • 6.2.2. 也要支援未來的未知和變化

6.3. 不變的技術可能是支撐雲的基礎元件或者經受住了時間考驗的程式語言基礎

  • 6.3.1. 在雲技術中，不變的技術如物件儲存、網路、伺服器和安全

  • 6.3.2. 選擇物件儲存儲存資料是明智之舉

  • 6.3.3. 物件儲存會繼續以各種方式去提升並且一直提供新的選擇，但你的資料在物件儲存中會很安全並且保持可用，無論整個技術如何快速進化

  • 6.3.4. SQL和bash會存在好幾十年，並且我們不會看見它們很快就消失

6.4. 林迪效應

  • 6.4.1. 這個技術建立得越久，它就越可能長期存在

  • 6.4.2. 建議使用林迪效益作為試金石去測試一個技術是不是可能長期不變的

  • 6.4.3. 電力網路、關聯式資料庫、C語言或者X86的處理器架構

6.5. 有大量資金支援的新技術和各種開源專案每天都在資料領域出現

  • 6.5.1. 大多數這樣的公司和專案不會有長期的引領力，會漸漸淡出人們的視線

  • 6.5.2. 頂級風投在押注鉅額的賭注，因為多數的資料工具投資都會失敗

  • 6.5.3. 工程師被Hive激發但想最佳化其缺點，開發了新的如Presto等新技術

  • 6.5.3.1. 現在Hive幾乎只出現在遺留的部署之中

6.6. 幾乎所有的技術都無法避免衰落的命運

  • 6.6.1. 每兩年就評估使用中的工具

6.7. 不論何時，找到在資料工程生命週期中不變的技術，並且將它們作為你的基石

  • 6.7.1. 在不變的技術之上再使用暫時的技術

相關文章