1. 無伺服器
1.1. 雲供應商的一個大趨勢是無伺服器，允許開發人員和資料工程師無須在後臺管理伺服器即可執行應用程式
- 1.1.1. 無伺服器快速將價值投入到其正確的用例
1.2. 無伺服器真正開始流行是在2014年AWS Lambda全面投入使用之後
-
1.2.1. 由於無須管理伺服器，只需在無伺服器的基礎上執行小型所需的程式碼塊，無伺服器人氣迅速提升
-
1.2.2. 它受歡迎的主要原因是低成本和便利性
1.3. 無伺服器有很多種
-
1.3.1. 功能即服務(Function as a Service，FaaS)廣受歡迎，並早於AWS Lambda的出現
-
1.3.2. Google Cloud的BigQuery是無伺服器的，因為資料工程師無須管理後端基礎設施結構，系統自動擴充套件以處理從小到大的查詢
1.4. 你支付的金額取決於查詢消耗的資料量和少量儲存資料的成本
- 1.4.1. 其為消費和儲存付費的模式正變得越來越普遍
1.5. 無伺服器也有固有的開銷低效的問題
- 1.5.1. 以高事件率處理每個函式呼叫一個事件會帶來災難性的成本，而更簡單的方法（如多執行緒或多程序）是很好的選擇
1.6. 監控確定真實環境中每個事件的成本和無伺服器執行的最長時間，並對每個事件的成本建模以確定隨著事件速率的增長的總體成本
- 1.6.1. 建模還應該包括最壞的情況
1.7. 當無伺服器的使用和成本已經超過自己維護一個伺服器的成本時，選擇無伺服器就意義不大了
-
1.7.1. 在一定規模上，無伺服器的經濟利益可能會減少，並且搭建伺服器變得更有吸引力
-
1.7.2. 定製化、強大功能和易於控制是青睞於伺服器的其他主要原因
1.8. 伺服器故障將發生
-
1.8.1. 避免使用“特殊雪花”伺服器，它們是高度定製化且脆弱的，這會在你的架構中引入一個明顯的薄弱環節
-
1.8.2. 如果你的應用程式需要在伺服器上安裝特定程式碼，請使用啟動指令碼或者構建映象，然後使用CI/CD管道將程式碼部署到伺服器
1.9. 使用叢集和自動擴充套件
- 1.9.1. 利用雲能夠根據需求的增長和縮減來計算資源的能力
1.10. 將你的基礎設施當作程式碼
- 1.10.1. 自動化不僅僅適用於伺服器，還應該儘可能擴充套件到你的基礎設施中
1.11. 使用容器
- 1.11.1. 對於更復雜或更繁重的多依賴性工作，考慮在單個伺服器上或Kubernetes上使用容器
1.12. 無伺服器是否適合你
-
1.12.1. 工作負載大小和複雜性
-
1.12.1.1. 無伺服器最適合簡單、離散的任務和工作負載
-
1.12.1.2. 如果你有許多活動部件或需要大量計算、記憶體則不太合適
-
1.12.2. 執行頻率和持續時間
-
1.12.3. 請求和網路
-
1.12.3.1. 無伺服器平臺通常使用某種簡化的網路，而不是支援所有云虛擬網路功能
-
1.12.4. 語言
-
1.12.4.1. 如果它不是官方無伺服器平臺支援的語言之一，那麼你反而應該考慮容器
-
1.12.5. 執行時限制
-
1.12.5.1. 無伺服器平臺不會為你提供完整的作業系統抽象
-
1.12.5.2. 相反，你會受限於特定的執行時
-
1.12.6. 成本
-
1.12.6.1. 無伺服器功能非常方便，但可能很昂貴
-
1.12.7. 抽象往往更加好
1.13. 建議首先考慮使用無伺服器，然後是伺服器（如果可能配合容器和編排），如果規模較大成本較高，使用伺服器
2. 容器
2.1. 將無伺服器和微服務相結合，容器是最強的操作技術發展趨勢之一
- 2.1.1. 容器能在無伺服器和微服務中都發揮作用
2.2. 容器通常被稱為輕量級虛擬機器
-
2.2.1. 傳統的VM包括了整個作業系統，而容器只包括了一個孤立的使用者空間（例如檔案系統和一些程序），許多這樣的容器可以共同存在於單個主機作業系統上
-
2.2.1.1. 和完整VM相比，容器叢集不提供同樣的安全性和隔離性
> 2.2.1.1.1. 雖然Amazon EC2是一個真正的多租戶的環境，許多客戶的虛擬機器託管在同一環境硬體中，但Kubernetes叢集應該只存放在一個相互信任的環境中
- 2.2.1.2. 容器逃逸
> 2.2.1.2.1. 從廣義上解釋，指一類利用容器中的程式碼獲得外部作業系統級別許可權的漏洞
> 2.2.1.2.2. 是很常見的一種多租戶的風險
-
2.2.1.3. 程式碼審查流程和漏洞掃描對於確保開發人員不引入安全漏洞也至關重要
-
2.2.2. 這樣做的主要好處是虛擬化（即依賴和程式碼隔離），無須支付整個作業系統核心的開銷
2.3. 單個硬體節點可以承載多個具有細粒度資源的容器
2.4. 容器上執行的就是一種無伺服器環境
- 2.4.1. Kubernetes也是一種無伺服器環境，因為它允許開發人員和運營團隊部署微服務並且無須擔心部署的細節
2.5. 容器為分散式單體問題提供了部分解決方案
2.6. 各種型別的容器平臺為無伺服器增加了新的功能
- 2.6.1. 功能容器化的平臺由事件來觸發容器而不是一直執行著容器
2.7. 抽象將繼續在資料技術棧中發揮作用
3. 基準戰爭
3.1. 要麼比較針對完全不同用例進行最佳化的資料庫，要麼使用與現實世界需求毫無相似之處的測試場景
3.2. 資料領域充滿了無意義的基準
3.3. 20世紀90年代的大資料
- 3.3.1. 聲稱支援PB級“大資料”的產品通常會使用足夠小的基準資料集，可以輕鬆放入智慧手機的儲存空間中
3.4. 無意義的成本比較
3.5. 非對稱最佳化
-
3.5.1. 非對稱最佳化的欺騙以多種形式出現
-
3.5.2. 標準化資料模型對於基於行的系統是最佳的，但列式系統在其他的框架下才能展示出全部潛力
-
3.5.3. 供應商透過額外的連線最佳化來增強它們的系統，而沒有在競爭資料庫中應用相匹配的調優
3.6. 買者自負
-
3.6.1. 與資料技術中的所有事物一樣，買家要當心
-
3.6.2. 要先做功課去了解，以避免盲目依賴供應商基準來評估和選擇技術
4. 底層設計及其對技術選擇的影響
4.1. 無論你選擇何種技術，一定要了解它如何支援資料工程生命週期裡的底層設計
4.2. 資料管理是一個廣泛的領域，就技術而言，一項技術是否將資料管理作為主要關注點並不總是很明顯
-
4.2.1. 合規性、安全性、隱私、資料質量和治理
-
4.2.2. 你如何保護資料免受來自外部和內部的破壞？
-
4.2.3. 你的產品是否符合GDPR、CCPA和其他資料隱私法規？
-
4.2.4. 你是否允許我託管我的資料以遵守這些規定？
-
4.2.5. 你如何確保資料質量以及我在你的解決方案中檢視的資料是否正確？
4.3. DataOps
-
4.3.1. 問題總是會出現
-
4.3.1.1. 伺服器或資料庫可能會死亡，雲的區域可能會中斷，你可能會部署錯誤程式碼，這可能將錯誤資料引入你的資料倉儲，也可能會出現其他無法預料的問題
4.4. 資料架構
-
4.4.1. 良好的資料架構意味著評估權衡和選擇最適合工作的工具，同時保持你的決定的可逆性
-
4.4.2. 資料格局以極快的速度變化著，現在最佳工具是一個移動目標
-
4.4.3. 主要目標是避免不必要的鎖定，確保不同技術棧的互操作性，併產生高投資回報率
4.5. Airflow
- 4.5.1. 編排領域目前由一種開源技術Apache Airflow主導
4.6. 軟體工程
-
4.6.1. 應該努力簡化和抽象整個資料技術棧
-
4.6.2. 對金融科技平臺提供支援的特定的演算法
-
4.6.3. 透過抽象出大量冗餘的工作流和過程，你可以繼續削減、改進和定製那些推動業務發展的東西