1. 開源軟體
1.1. 開源軟體(Open Source Software，OSS)是一種軟體發行模式，在這種模式下，軟體和底層程式碼庫通常在特定的許可條款下可供普遍開發者使用
1.2. 社群管理的開源軟體
-
1.2.1. 大部分開源軟體專案都是社群管理的開源軟體
-
1.2.2. 流行的開源軟體專案社群擁有更多的全球開發人員的創新和貢獻的比率
-
1.2.3. 心智份額
-
1.2.3.1. 避免採用沒有吸引力和知名度的OSS專案
-
1.2.3.2. 參考GitHub星數、分叉數、提交量和回訪率
-
1.2.4. 成熟度
-
1.2.4.1. 該專案已經存在了多長時間，現在有多活躍
-
1.2.5. 故障排除
-
1.2.5.1. 如果出現問題，你將如何處理？
-
1.2.5.2. 你是一個人去解決問題，還是有社群可以幫助你解決問題
-
1.2.6. 專案管理
-
1.2.6.1. 檢視Git出現的問題及其解決方式
-
1.2.7. 團隊
-
1.2.7.1. 是否有公司贊助開源軟體專案？
-
1.2.7.2. 誰是核心貢獻者？
-
1.2.8. 開發者關係和社群管理
-
1.2.8.1. 該專案正在做什麼來鼓勵促進被接納和採用
-
1.2.9. 貢獻
-
1.2.9.1. 是否鼓勵並接受拉取請求？
-
1.2.10. 路線圖
-
1.2.10.1. 是否清晰透明？
-
1.2.11. 自託管和維護
-
1.2.12. 回饋社會
-
1.2.13. 可以繼續使用社群管理的開源軟體版本，但你需要繼續自己維護管理（更新、維護伺服器/容器、錯誤修復的拉取請求等）
1.3. 商業開源軟體
-
1.3.1. 取決於開源應用程式，其需要的時間和精力可能是微不足道的，也可能是極其複雜並且煩瑣的
-
1.3.2. 商業開源軟體通常也屬於社群開源軟體專案
-
1.3.3. 你也可以向供應商付款，使用商業開源軟體，讓其為你承擔管理所需要工作
-
1.3.4. 價值
-
1.3.4.1. 供應商來管理的價值是否更高？
-
1.3.5. 交付模式
-
1.3.5.1. 如何獲取該服務？
-
1.3.5.2. 確保你可以輕鬆訪問初始版本和後續版本
-
1.3.6. 技術支援
-
1.3.6.1. 技術支援的重要性不能被低估，而且對買家來說技術支援往往是不透明的
-
1.3.7. 釋出和錯誤修復
-
1.3.8. 銷售週期和定價
-
1.3.9. 公司財務
-
1.3.9.1. 公司有生存能力嗎？
-
1.3.10. 影響力與收入
-
1.3.10.1. 公司是關注增加客戶的數量（影響力），還是關注增加收入？
-
1.3.11. 社群支援
1.4. 雲也提供自己的託管開源產品
2. 私有技術
2.1. 自主發行
-
2.1.1. 資料工具領域在過去幾年呈指數級增長
-
2.1.2. 資料工具的公司的銷售通常不會將產品作為開源軟體釋出，而是提供一個專有的解決方案
2.2. 互操作性
- 2.2.1. 確保該工具與你選擇的其他工具（開源軟體、其他自主發行、雲產品等）能互通
2.3. 心智份額和市場份額
-
2.3.1. 該產品的解決方案受歡迎嗎？
-
2.3.2. 在市場上佔有一席之地嗎？
-
2.3.3. 是否擁有積極的客戶評價？
2.4. 文件和支援
2.5. 定價
2.6. 壽命
- 2.6.1. 公司能否生存足夠長的時間讓你從它的產品中獲得價值？
3. 雲平臺產品
3.1. 雲供應商開發和銷售他們的專有服務，例如儲存、資料庫等更多的服務
3.2. DynamoDB服務
- 3.2.1. 該服務現在是各種規模的公司使用的高成熟度的頂級產品
3.3. 雲供應商通常會將產品捆綁在一起以更好地協同工作
- 3.3.1. 每個雲都可以透過建立強大的整合來與其使用者群建立黏性生態系統
3.4. 效能與價格比較
3.5. 購買注意事項
-
3.5.1. 按需定價可能很昂貴
-
3.5.2. 你能透過保留容量或者簽訂長期承諾協議來降低成本嗎？
4. 單體與模組化
4.1. 單體與模組化系統是軟體架構領域的另一個長期爭論的問題
4.2. 評估單體與模組化選項時
-
4.2.1. 互操作性
-
4.2.1.1. 共享和互操作性的架構
-
4.2.2. 避免“空頭陷阱”
-
4.2.2.1. 容易上手的事物可能會很痛苦或無法逃脫
-
4.2.3. 靈活性
-
4.2.3.1. 現在資料領域中的事物發展很快
-
4.2.3.2. 致力於單體模式會降低靈活性和決策的可逆性
5. 單體
5.1. 單體系統是獨立的，通常執行單一系統下的多種功能
-
5.1.1. 單體傾向於簡單化，一切功能都在一個地方
-
5.1.2. 對單個實體進行分析更容易，你可以更快遷移，因為需要改變的部件更少
5.2. 幾十年來一直是技術支柱
-
5.2.1. 瀑布式的舊時代意味著軟體釋出是巨大的、緊密耦合的、並且步調平穩的
-
5.2.2. 單體資料系統一直延續到今天，老軟體供應商（如Informatica）和開源框架（如Spark）仍然採用這種模式
5.3. 單體的優點是易於推理分析，只需要較低的認知和較少的上下文切換，因為一切都是獨立的
5.4. 缺點
-
5.4.1. 單體很脆弱
-
5.4.1.1. 因為有大量的移動部件，更新和釋出需要更長的時間，並且往往會變得煩瑣
-
5.4.1.2. 如果一個系統有錯誤——但願軟體已經徹底透過釋出前測試——它會損害整個系統
-
5.4.2. 使用者引發的問題也會發生在單體應用中
-
5.4.2.1. 如果在任何地方有任何東西發生故障導致這個管道任務失敗，整個過程不得不重新開始
-
5.4.3. 單體系統中的多租戶也可能是一個嚴重的問題
-
5.4.3.1. 隔離多個使用者的工作負載具有非常大的挑戰性
-
5.4.3.2. 在本地資料倉儲中，一個使用者定義的函式可能會消耗許多的CPU以至於減慢其他使用者的系統速度
-
5.4.4. 如果供應商倒閉或開源專案夭折，切換到一個新的系統會非常痛苦
-
5.4.4.1. 你所有的過程都包含在單體架構內，從那個系統中抽離出來，並進入一個新的平臺，這在時間和金錢上的花費都是昂貴的
5.5. 單體系統中的依賴關係和資源爭用之間的衝突是常見的問題
5.6. 雖然單體很有吸引力，因為它易於理解且減少了複雜性，但這是有高代價的
- 5.6.1. 它可能導致靈活性的喪失，機會成本和在開發週期裡持續的高衝突
6. 模組化
6.1. 模組化傾向於採用解耦的、最佳組合技術執行它們獨特的任務
- 6.1.1. 考慮到資料世界中產品的變化率，你應該追求在不斷變化的一系列解決方案之間的互操作性
6.2. 是軟體工程中的一個古老概念
-
6.2.1. 系統不再是依靠龐大的單體來處理需求，而是將系統和流程分解為相關的獨立區域
-
6.2.2. 微服務可以透過API通訊，這允許開發人員在製作應用程式時專注於他們的領域，同時其他微服務也可以訪問
-
6.2.2.1. 這是軟體工程的趨勢，在現代資料系統中越來越流行
-
6.2.2.2. 大型科技公司一直是微服務的主要推動者
-
6.2.2.3. 著名的貝索斯API指令減少了應用程式之間的耦合，允許重構和分解
-
6.2.2.4. 貝索斯還實施了兩個比薩原則（任何團隊都不應大到兩個比薩餅無法餵飽整個團隊
> 6.2.2.4.1. 意味著團隊最多有五名成員
> 6.2.2.4.2. 這個上限也限制了團隊的責任和領域的複雜性——特別是它可以管理的程式碼庫
6.3. 在模組化的微服務環境中，元件是可交換的，而且能夠建立一個多語言（多程式語言）應用程式
-
6.3.1. Java服務可以替代用Python編寫的服務
-
6.3.2. 服務客戶只需要考慮服務API的技術規範，而不是幕後細節如何執行
6.4. 資料處理技術透過對互操作性的強大支援轉向模組化
-
6.4.1. 資料採用標準的格式（如Parquet格式）將物件儲存存放在資料湖和資料湖倉中
-
6.4.2. 任何支援其格式的讀取工具都可以讀取資料並將處理後的結果由另一個工具寫回資料湖中
-
6.4.3. 雲資料倉儲透過使用標準格式和外部表匯入匯出，支援與物件儲存的互操作
-
6.4.3.1. 查詢直接在資料湖中的資料中執行
6.5. 模組化允許工程師為每項工作或流程中的每一步挑選最佳的技術
6.6. 缺點
-
6.6.1. 模組化不再是關注和處理一個單一系統，現在你可能有無數系統需要了解和操作
-
6.6.2. 編排5～10個系統比編排一個系統要複雜得多
-
6.6.2.1. 編排變成將資料各類技術棧模組繫結在一起的黏合劑
7. 分散式單體模式
7.1. 分散式單體模式存在許多單體架構的侷限性
7.2. 其基本思想是執行一個分散式系統來執行不同的任務
- 7.2.1. 服務和節點享有一套共同的依賴關係或共同的程式碼庫
7.3. 一個標準示例是傳統的Hadoop叢集
-
7.3.1. 一個Hadoop叢集可以同時託管多個框架
-
7.3.1.1. Hive、Pig或Spark
-
7.3.2. 該叢集具有許多內部依賴性
-
7.3.3. 叢集還執行Hadoop核心元件
-
7.3.3.1. Hadoop公共庫、HDFS、YARN和Java
-
7.3.4. 一個叢集對各種元件通常有一個版本
7.4. 標準的本地Hadoop系統需要管理一個公共環境，該環境適用於所有使用者和所有作業
- 7.4.1. 強制現有任務升級依賴關係會有破壞環境的風險，而維持一個框架的兩個版本會帶來額外的複雜性
7.5. 分散式單體模式問題的一種解決方案是在雲環境中使用臨時的基礎設施
- 7.5.1. 第二種解決方案是使用容器將分散式單體分解為多個軟體環境