mirror of
https://github.com/Vonng/ddia.git
synced 2025-09-26 23:09:18 +08:00
Compare commits
3 Commits
8ecd801d24
...
5fd25581f1
Author | SHA1 | Date | |
---|---|---|---|
![]() |
5fd25581f1 | ||
![]() |
964f9c9303 | ||
![]() |
bca5ee5552 |
41
.github/workflows/ebooks.yaml
vendored
Normal file
41
.github/workflows/ebooks.yaml
vendored
Normal file
@ -0,0 +1,41 @@
|
|||||||
|
name: Generate GitBook eBooks
|
||||||
|
|
||||||
|
on:
|
||||||
|
push:
|
||||||
|
branches:
|
||||||
|
- main
|
||||||
|
workflow_dispatch:
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
build-ebook:
|
||||||
|
runs-on: ubuntu-latest
|
||||||
|
|
||||||
|
steps:
|
||||||
|
- name: Checkout repository
|
||||||
|
uses: actions/checkout@v3
|
||||||
|
|
||||||
|
- name: Set up Pandoc
|
||||||
|
uses: siacodelabs/setup-pandoc@v1
|
||||||
|
with:
|
||||||
|
xelatex: true
|
||||||
|
|
||||||
|
- name: Generate EPUB file
|
||||||
|
run: make epub
|
||||||
|
|
||||||
|
- name: Create or update Release and upload EPUB
|
||||||
|
if: github.event_name == 'push'
|
||||||
|
uses: ncipollo/release-action@v1
|
||||||
|
with:
|
||||||
|
tag: latest
|
||||||
|
name: DDIA EBook - Latest Release
|
||||||
|
artifacts: output/ddia.epub
|
||||||
|
allowUpdates: true
|
||||||
|
env:
|
||||||
|
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||||
|
|
||||||
|
- name: Upload generated eBooks
|
||||||
|
if: github.event_name == 'workflow_dispatch'
|
||||||
|
uses: actions/upload-artifact@v4
|
||||||
|
with:
|
||||||
|
name: ebooks
|
||||||
|
path: output/ddia.epub
|
2
bin/epub
2
bin/epub
@ -20,7 +20,7 @@ convert_to_epub() {
|
|||||||
pandoc -o "$OUTPUT_BOOK" --metadata-file="$meta_file" \
|
pandoc -o "$OUTPUT_BOOK" --metadata-file="$meta_file" \
|
||||||
--toc-depth=2 \
|
--toc-depth=2 \
|
||||||
--top-level-division=chapter \
|
--top-level-division=chapter \
|
||||||
--file-scope=true \
|
--file-scope \
|
||||||
--css="$css_file" \
|
--css="$css_file" \
|
||||||
--webtex \
|
--webtex \
|
||||||
--wrap=preserve \
|
--wrap=preserve \
|
||||||
|
@ -180,8 +180,6 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
|
|||||||
這就結束了我們對分析和事務處理的比較。在下一節中,我們將研究另一個你可能已經看到多次爭論的權衡。
|
這就結束了我們對分析和事務處理的比較。在下一節中,我們將研究另一個你可能已經看到多次爭論的權衡。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 雲服務與自託管 {#sec_introduction_cloud}
|
## 雲服務與自託管 {#sec_introduction_cloud}
|
||||||
|
|
||||||
對於組織需要做的任何事情,首要問題之一是:應該在內部完成,還是應該外包?應該自建還是購買?
|
對於組織需要做的任何事情,首要問題之一是:應該在內部完成,還是應該外包?應該自建還是購買?
|
||||||
@ -233,10 +231,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
|
|||||||
如果有暴露相容 API 的替代服務,這種風險會得到緩解,但對於許多雲服務,沒有標準 API,這增加了切換成本,使供應商鎖定成為一個問題。
|
如果有暴露相容 API 的替代服務,這種風險會得到緩解,但對於許多雲服務,沒有標準 API,這增加了切換成本,使供應商鎖定成為一個問題。
|
||||||
* 雲供應商需要被信任以保持資料安全,這可能會使遵守隱私和安全法規的過程複雜化。
|
* 雲供應商需要被信任以保持資料安全,這可能會使遵守隱私和安全法規的過程複雜化。
|
||||||
|
|
||||||
儘管有所有這些風險,組織在雲服務之上構建新應用程式或採用混合方法(在系統的某些部分使用雲服務)變得越來越流行。
|
儘管有所有這些風險,組織在雲服務之上構建新應用程式或採用混合方法(在系統的某些部分使用雲服務)變得越來越流行。然而,雲服務不會取代所有內部資料系統:許多較舊的系統早於雲,對於任何具有現有云服務無法滿足的專業要求的服務,內部系統仍然是必要的。例如,對延遲非常敏感的應用程式(如高頻交易)需要對硬體的完全控制。
|
||||||
然而,雲服務不會取代所有內部資料系統:許多較舊的系統早於雲,對於任何具有現有云服務無法滿足的專業要求的服務,內部系統仍然是必要的。
|
|
||||||
例如,對延遲非常敏感的應用程式(如高頻交易)需要對硬體的完全控制。
|
|
||||||
|
|
||||||
|
|
||||||
### 雲原生系統架構 {#sec_introduction_cloud_native}
|
### 雲原生系統架構 {#sec_introduction_cloud_native}
|
||||||
|
|
||||||
@ -291,15 +286,15 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
|
|||||||
|
|
||||||
運維的作用是確保服務可靠地交付給使用者(包括配置基礎設施和部署應用程式),並確保穩定的生產環境(包括監控和診斷可能影響可靠性的任何問題)。對於自託管系統,運維傳統上涉及大量在單個機器級別的工作,例如容量規劃(例如,監控可用磁碟空間並在空間用完之前新增更多磁碟)、配置新機器、將服務從一臺機器移動到另一臺機器,以及安裝作業系統補丁。
|
運維的作用是確保服務可靠地交付給使用者(包括配置基礎設施和部署應用程式),並確保穩定的生產環境(包括監控和診斷可能影響可靠性的任何問題)。對於自託管系統,運維傳統上涉及大量在單個機器級別的工作,例如容量規劃(例如,監控可用磁碟空間並在空間用完之前新增更多磁碟)、配置新機器、將服務從一臺機器移動到另一臺機器,以及安裝作業系統補丁。
|
||||||
|
|
||||||
許多雲服務提供了一個 API,隱藏了實際實現服務的單個機器。例如,雲端儲存用 **計量計費** 替換固定大小的磁碟,你可以儲存資料而無需提前規劃容量需求,然後根據實際使用的空間收費。此外,許多雲服務保持高可用性,即使單個機器發生故障(參見["可靠性與容錯"](/tw/ch2#sec_introduction_reliability))。
|
許多雲服務提供了 API 來隱藏實際實現服務的單個機器。例如,雲端儲存用 **計量計費** 替換固定大小的磁碟,你可以儲存資料而無需提前規劃容量需求,然後根據實際使用的空間收費。此外,即使在單個機器發生故障時,許多雲服務仍能保持高可用性(參見["可靠性與容錯"](/tw/ch2#sec_introduction_reliability))。
|
||||||
|
|
||||||
從單個機器到服務的重點轉移伴隨著運維角色的變化。提供可靠服務的高階目標保持不變,但流程和工具已經發展。DevOps/SRE 理念更加強調:
|
從單個機器到服務的重點轉移伴隨著運維角色的變化。提供可靠服務的高階目標保持不變,但流程和工具已經發展。DevOps/SRE 理念更加強調:
|
||||||
|
|
||||||
* 自動化——優先考慮可重複的流程而不是手動的一次性工作,
|
* 自動化——優先考慮可重複的流程而不是手動的一次性工作,
|
||||||
* 優先考慮短暫的虛擬機器和服務而不是長期執行的伺服器,
|
* 優先考慮短暫的虛擬機器和服務而不是長期執行的伺服器,
|
||||||
* 啟用頻繁的應用程式更新,
|
* 啟用頻繁的應用程式更新,
|
||||||
* 從事件中學習,以及
|
* 從事故中學習,以及
|
||||||
* 保留組織關於系統的知識,即使個人來來去去 [^35]。
|
* 保留組織關於系統的知識,即使組織里的人員在不斷流動 [^35]。
|
||||||
|
|
||||||
隨著雲服務的興起,角色出現了分叉:基礎設施公司的運維團隊專門研究向大量客戶提供可靠服務的細節,而服務的客戶在基礎設施上花費盡可能少的時間和精力 [^36]。
|
隨著雲服務的興起,角色出現了分叉:基礎設施公司的運維團隊專門研究向大量客戶提供可靠服務的細節,而服務的客戶在基礎設施上花費盡可能少的時間和精力 [^36]。
|
||||||
|
|
||||||
@ -307,17 +302,16 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
|
|||||||
|
|
||||||
此外,雲服務確實有資源限制或 **配額**(例如你可以同時執行的最大程序數),你需要在遇到它們之前瞭解並規劃這些 [^38]。
|
此外,雲服務確實有資源限制或 **配額**(例如你可以同時執行的最大程序數),你需要在遇到它們之前瞭解並規劃這些 [^38]。
|
||||||
|
|
||||||
採用雲服務可能比執行自己的基礎設施更容易、更快,儘管即使在這裡,學習如何使用它也有成本,也許還要解決其限制。隨著越來越多的供應商提供針對不同用例的更廣泛的雲服務,不同服務之間的整合成為一個特別的挑戰 [^39] [^40]。
|
採用雲服務可能比執行自己的基礎設施更容易、更快,儘管學習如何使用它也有成本,也許還要解決其限制。隨著越來越多的供應商提供針對不同用例的更廣泛的雲服務,不同服務之間的整合成為一個特別的挑戰 [^39] [^40]。
|
||||||
|
|
||||||
ETL(參見["資料倉庫"](/tw/ch1#sec_introduction_dwh))只是故事的一部分;事務型雲服務也需要相互整合。目前,缺乏促進這種整合的標準,因此它通常涉及大量的手動工作。
|
ETL(參見["資料倉庫"](/tw/ch1#sec_introduction_dwh))只是故事的一部分;事務型雲服務也需要相互整合。目前,缺乏促進這種整合的標準,因此它通常涉及大量的手動工作。
|
||||||
|
|
||||||
無法完全外包給雲服務的其他運維方面包括維護應用程式及其使用的庫的安全性、管理你自己的服務之間的互動、監控服務的負載,以及追蹤問題的原因,例如效能下降或中斷。雖然雲正在改變運維的角色,但對運維的需求比以往任何時候都大。
|
無法完全外包給雲服務的其他運維方面包括維護應用程式及其使用的庫的安全性、管理你自己的服務之間的互動、監控服務的負載,以及追蹤問題的原因,例如效能下降或中斷。雖然雲正在改變運維的角色,但對運維的需求比以往任何時候都大。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 分散式與單節點系統 {#sec_introduction_distributed}
|
## 分散式與單節點系統 {#sec_introduction_distributed}
|
||||||
|
|
||||||
涉及多臺機器透過網路通訊的系統稱為 **分散式系統**。參與分散式系統的每個程序稱為 **節點**。你可能希望系統分散式的原因有多種:
|
涉及多臺機器透過網路通訊的系統稱為 **分散式系統**。參與分散式系統的每個程序稱為 **節點**。你希望採用分散式系統的原因可能有多種:
|
||||||
|
|
||||||
固有的分散式系統
|
固有的分散式系統
|
||||||
: 如果應用程式涉及兩個或多個互動使用者,每個使用者使用自己的裝置,那麼系統不可避免地是分散式的:裝置之間的通訊必須透過網路進行。
|
: 如果應用程式涉及兩個或多個互動使用者,每個使用者使用自己的裝置,那麼系統不可避免地是分散式的:裝置之間的通訊必須透過網路進行。
|
||||||
@ -335,16 +329,16 @@ ETL(參見["資料倉庫"](/tw/ch1#sec_introduction_dwh))只是故事的一
|
|||||||
: 如果你在世界各地都有使用者,你可能希望在全球各個地區都有伺服器,以便每個使用者都可以從地理位置接近他們的伺服器獲得服務。這避免了使用者必須等待網路資料包繞地球半圈才能回答他們的請求。參見["描述效能"](/tw/ch2#sec_introduction_percentiles)。
|
: 如果你在世界各地都有使用者,你可能希望在全球各個地區都有伺服器,以便每個使用者都可以從地理位置接近他們的伺服器獲得服務。這避免了使用者必須等待網路資料包繞地球半圈才能回答他們的請求。參見["描述效能"](/tw/ch2#sec_introduction_percentiles)。
|
||||||
|
|
||||||
彈性
|
彈性
|
||||||
: 如果你的應用程式在某些時候很忙,在其他時候很空閒,雲部署可以根據需求向上或向下擴充套件,因此你只需為實際使用的資源付費。這在單臺機器上更困難,它需要配置以處理最大負載,即使在幾乎不使用的時候也是如此。
|
: 如果你的應用程式在某些時候很忙,在其他時候很空閒,雲部署可以根據需求向上或向下伸縮,因此你只需為實際使用的資源付費。這在單臺機器上更困難,它需要按處理最大負載的情況進行配置,即使在幾乎不使用的時候也是如此。
|
||||||
|
|
||||||
使用專用硬體
|
使用專用硬體
|
||||||
: 系統的不同部分可以利用不同型別的硬體來匹配其工作負載。例如,物件儲存可能使用具有許多磁碟但很少 CPU 的機器,而資料分析系統可能使用具有大量 CPU 和記憶體但沒有磁碟的機器,機器學習系統可能使用具有 GPU 的機器(GPU 在訓練深度神經網路和其他機器學習任務方面比 CPU 效率高得多)。
|
: 系統的不同部分可以利用不同型別的硬體來匹配其工作負載。例如,物件儲存可能使用具有許多磁碟但很少 CPU 的機器,而資料分析系統可能使用具有大量 CPU 和記憶體但沒有磁碟的機器,機器學習系統可能使用具有 GPU 的機器(GPU 在訓練深度神經網路和其他機器學習任務方面比 CPU 效率高得多)。
|
||||||
|
|
||||||
法律合規
|
法律合規
|
||||||
: 一些國家有資料駐留法律,要求其管轄範圍內的人員資料必須在該國地理範圍內儲存和處理 [^41]。這些規則的範圍各不相同——例如,在某些情況下,它僅適用於醫療或金融資料,而其他情況則更廣泛。因此,在幾個這樣的管轄區域中擁有使用者的服務將不得不將他們的資料分佈在幾個位置的伺服器上。
|
: 一些國家有資料駐留法律,要求其管轄範圍內的人員資料必須在該國地理範圍內儲存和處理 [^41]。這些規則的範圍各不相同——例如,在某些情況下,它僅適用於醫療或金融資料,而其他情況則更廣泛。因此,在幾個這樣的管轄區域中擁有使用者的服務不得不將他們的資料分佈在幾個位置的伺服器上。
|
||||||
|
|
||||||
可持續性
|
可持續性
|
||||||
: 如果你對執行作業的地點和時間有靈活性,你可能能夠在可再生電力充足的時間和地點執行它們,並避免在電網緊張時執行它們。這可以減少你的碳排放,並允許你在電力可用時利用廉價的電力 [^42] [^43]。
|
: 如果你能靈活把控作業執行的地點和時間,你可能能夠在可再生電力充足的時間和地點執行它們,並避免在電網緊張時執行它們。這可以減少你的碳排放,並允許你利用到廉價的電力 [^42] [^43]。
|
||||||
|
|
||||||
這些原因既適用於你自己編寫的服務(應用程式程式碼),也適用於由現成軟體(如資料庫)組成的服務。
|
這些原因既適用於你自己編寫的服務(應用程式程式碼),也適用於由現成軟體(如資料庫)組成的服務。
|
||||||
|
|
||||||
@ -353,14 +347,16 @@ ETL(參見["資料倉庫"](/tw/ch1#sec_introduction_dwh))只是故事的一
|
|||||||
分散式系統也有缺點。透過網路進行的每個請求和 API 呼叫都需要處理失敗的可能性:網路可能中斷,或者服務可能過載或崩潰,因此任何請求都可能超時而沒有收到響應。在這種情況下,我們不知道服務是否收到了請求,簡單地重試它可能不安全。我們將在[第 9 章](/tw/ch9#ch_distributed)中詳細討論這些問題。
|
分散式系統也有缺點。透過網路進行的每個請求和 API 呼叫都需要處理失敗的可能性:網路可能中斷,或者服務可能過載或崩潰,因此任何請求都可能超時而沒有收到響應。在這種情況下,我們不知道服務是否收到了請求,簡單地重試它可能不安全。我們將在[第 9 章](/tw/ch9#ch_distributed)中詳細討論這些問題。
|
||||||
|
|
||||||
儘管資料中心網路很快,但呼叫另一個服務仍然比在同一程序中呼叫函式慢得多 [^44]。
|
儘管資料中心網路很快,但呼叫另一個服務仍然比在同一程序中呼叫函式慢得多 [^44]。
|
||||||
在處理大量資料時,與其將資料從儲存傳輸到處理它的單獨機器,不如將計算帶到已經擁有資料的機器上可能更快 [^45]。
|
|
||||||
更多的節點並不總是更快:在某些情況下,單臺計算機上的簡單單執行緒程式可以比具有 100 多個 CPU 核心的叢集表現得更好 [^46]。
|
|
||||||
|
|
||||||
故障排除分散式系統通常很困難:如果系統響應緩慢,你如何找出問題所在?在 **可觀測性** [^47] [^48] 的標題下開發了診斷分散式系統問題的技術,這涉及收集有關係統執行的資料,並允許以允許分析高階指標和單個事件的方式進行查詢。**追蹤** 工具(如 OpenTelemetry、Zipkin 和 Jaeger)允許你跟蹤哪個客戶端為哪個操作呼叫了哪個伺服器,以及每次呼叫花費了多長時間 [^49]。
|
在處理大量資料時,與其將資料從其儲存處傳輸到處理它的單獨機器,將計算帶到已經擁有資料的機器上可能更快 [^45]。
|
||||||
|
|
||||||
|
更多的節點並不總是更快:在某些情況下,一個簡單的單執行緒程式在單臺計算機上執行的效能可以比在具有 100 多個 CPU 核心的叢集上更好 [^46]。
|
||||||
|
|
||||||
|
對分散式系統進行故障排除通常很困難:如果系統響應緩慢,你如何找出問題所在?**可觀測性** [^47] [^48] 技術可以用來對分散式系統中的問題進行診斷,這涉及到系統執行資料的收集,並提供查詢方式來支援對高層級的指標或單個的事件的分析。**追蹤** 工具(如 OpenTelemetry、Zipkin 和 Jaeger)允許你跟蹤哪個客戶端為哪個操作呼叫了哪個伺服器,以及每次呼叫花費了多長時間 [^49]。
|
||||||
|
|
||||||
資料庫提供了各種機制來確保資料一致性,正如我們將在[第 6 章](/tw/ch6#ch_replication)和[第 8 章](/tw/ch8#ch_transactions)中看到的。然而,當每個服務都有自己的資料庫時,維護這些不同服務之間的資料一致性就成了應用程式的問題。分散式事務(我們在[第 8 章](/tw/ch8#ch_transactions)中探討)是確保一致性的一種可能技術,但它們在微服務上下文中很少使用,因為它們違背了使服務彼此獨立的目標,而且許多資料庫不支援它們 [^50]。
|
資料庫提供了各種機制來確保資料一致性,正如我們將在[第 6 章](/tw/ch6#ch_replication)和[第 8 章](/tw/ch8#ch_transactions)中看到的。然而,當每個服務都有自己的資料庫時,維護這些不同服務之間的資料一致性就成了應用程式的問題。分散式事務(我們在[第 8 章](/tw/ch8#ch_transactions)中探討)是確保一致性的一種可能技術,但它們在微服務上下文中很少使用,因為它們違背了使服務彼此獨立的目標,而且許多資料庫不支援它們 [^50]。
|
||||||
|
|
||||||
出於所有這些原因,如果你可以在單臺機器上做某事,與設定分散式系統相比,這通常要簡單得多,成本也更低 [^23] [^46] [^51]。CPU、記憶體和磁碟已經變得更大、更快、更可靠。當與 DuckDB、SQLite 和 KùzuDB 等單節點資料庫結合使用時,許多工作負載現在可以在單個節點上執行。我們將在[第 4 章](/tw/ch4#ch_storage)中進一步探討這個主題。
|
出於所有這些原因,如果你可以在單臺機器上做某件事情,與搭建分散式系統相比通常要簡單得多,成本也更低 [^23] [^46] [^51]。CPU、記憶體和磁碟已經變得更大、更快、更可靠。當與 DuckDB、SQLite 和 KùzuDB 等單節點資料庫結合使用時,許多工作負載現在可以在單個節點上執行。我們將在[第 4 章](/tw/ch4#ch_storage)中進一步探討這個主題。
|
||||||
|
|
||||||
### 微服務與 Serverless {#sec_introduction_microservices}
|
### 微服務與 Serverless {#sec_introduction_microservices}
|
||||||
|
|
||||||
@ -372,22 +368,22 @@ ETL(參見["資料倉庫"](/tw/ch1#sec_introduction_dwh))只是故事的一
|
|||||||
|
|
||||||
另一方面,擁有許多服務本身可能會帶來複雜性:每個服務都需要用於部署新版本、調整分配的硬體資源以匹配負載、收集日誌、監控服務健康狀況以及在出現問題時向值班工程師發出警報的基礎設施。**編排** 框架(如 Kubernetes)已成為部署服務的流行方式,因為它們為這種基礎設施提供了基礎。在開發期間測試服務可能很複雜,因為你還需要執行它所依賴的所有其他服務。
|
另一方面,擁有許多服務本身可能會帶來複雜性:每個服務都需要用於部署新版本、調整分配的硬體資源以匹配負載、收集日誌、監控服務健康狀況以及在出現問題時向值班工程師發出警報的基礎設施。**編排** 框架(如 Kubernetes)已成為部署服務的流行方式,因為它們為這種基礎設施提供了基礎。在開發期間測試服務可能很複雜,因為你還需要執行它所依賴的所有其他服務。
|
||||||
|
|
||||||
微服務 API 的演進可能具有挑戰性。呼叫 API 的客戶端期望 API 具有某些欄位。開發人員可能希望根據業務需求的變化向 API 新增或刪除欄位,但這樣做可能會導致客戶端失敗。更糟糕的是,這種失敗通常直到開發週期的後期才被發現,當更新的服務 API 部署到暫存或生產環境時。API 描述標準(如 OpenAPI 和 gRPC)有助於管理客戶端和伺服器 API 之間的關係;我們將在[第 5 章](/tw/ch5#ch_encoding)中進一步討論這些。
|
微服務 API 的演進可能具有挑戰性。呼叫 API 的客戶端期望 API 具有某些欄位。開發人員可能希望根據業務需求的變化向 API 新增或刪除欄位,但這樣做可能會導致客戶端失敗。更糟糕的是,這種失敗通常直到開發週期的後期才被發現,當更新的服務 API 部署到預生產或生產環境時。API 描述標準(如 OpenAPI 和 gRPC)有助於管理客戶端和伺服器 API 之間的關係;我們將在[第 5 章](/tw/ch5#ch_encoding)中進一步討論這些。
|
||||||
|
|
||||||
微服務主要是人員問題的技術解決方案:允許不同的團隊獨立取得進展,而無需相互協調。這在大公司中很有價值,但在沒有很多團隊的小公司中,使用微服務可能是不必要的開銷,最好以最簡單的方式實現應用程式 [^52]。
|
微服務主要是人員問題的技術解決方案:允許不同的團隊獨立取得進展,而無需相互協調。這在大公司中很有價值,但在沒有很多團隊的小公司中,使用微服務可能是不必要的開銷,最好以最簡單的方式實現應用程式 [^52]。
|
||||||
|
|
||||||
**Serverless** 或 **函式即服務**(FaaS)是部署服務的另一種方法,其中基礎設施的管理外包給雲供應商 [^33]。使用虛擬機器時,你必須明確選擇何時啟動或關閉例項;相比之下,使用 serverless 模型,雲提供商根據對你服務的傳入請求自動分配和釋放硬體資源 [^54]。Serverless 部署將更多的運營負擔轉移到雲提供商,並透過使用量而不是機器例項實現靈活的計費。為了提供這些好處,許多 serverless 基礎設施提供商對函式執行施加時間限制,限制執行時環境,並且在首次呼叫函式時可能會遭受緩慢的啟動時間。術語"serverless"也可能具有誤導性:每個 serverless 函式執行仍然在伺服器上執行,但後續執行可能在不同的伺服器上執行。此外,BigQuery 和各種 Kafka 產品等基礎設施已經採用"serverless"術語來表示他們的服務自動擴充套件,並且他們按使用量而不是機器例項計費。
|
**Serverless** 或 **函式即服務**(FaaS)是部署服務的另一種方法,其中基礎設施的管理外包給雲供應商 [^33]。使用虛擬機器時,你必須明確選擇何時啟動或關閉例項;相比之下,使用 serverless 模型,雲提供商根據對你服務的傳入請求自動分配和釋放硬體資源 [^54]。Serverless 部署將更多的運營負擔轉移到雲提供商,並透過使用量而不是機器例項實現靈活的計費。為了提供這些好處,許多 serverless 基礎設施提供商對函式執行施加時間限制,限制執行時環境,並且在首次呼叫函式時可能會遭受緩慢的啟動時間。術語“serverless”也可能具有誤導性:每個 serverless 函式執行仍然在伺服器上執行,但後續執行可能在不同的伺服器上執行。此外,BigQuery 和各種 Kafka 產品等基礎設施已經採用“serverless”術語來表示他們的服務自動擴充套件,並且他們按使用量而不是機器例項計費。
|
||||||
|
|
||||||
就像雲端儲存用計量計費模型取代了容量規劃(提前決定購買多少磁碟)一樣,serverless 方法正在為程式碼執行帶來計量計費:你只為應用程式程式碼實際執行的時間付費,而不必提前配置資源。
|
就像雲端儲存用計量計費模型取代了容量規劃(提前決定購買多少磁碟)一樣,serverless 方法正在為程式碼執行帶來計量計費:你只為應用程式程式碼實際執行的時間付費,而不必提前配置資源。
|
||||||
|
|
||||||
### 雲計算與超級計算 {#id17}
|
### 雲計算與超級計算 {#id17}
|
||||||
|
|
||||||
雲計算不是構建大規模計算系統的唯一方式;另一種選擇是 **高效能計算**(HPC),也稱為 **超級計算**。儘管有重疊,但與雲計算和企業資料中心繫統相比,HPC 通常有不同的優先順序並使用不同的技術。其中一些差異是:
|
雲計算不是構建大規模計算系統的唯一方式;另一種選擇是 **高效能計算**(HPC),也稱為 **超級計算**。儘管有重疊,但與雲計算和企業資料中心繫統相比,HPC 通常有不同的設計考量並使用不同的技術。其中一些差異是:
|
||||||
|
|
||||||
* 超級計算機通常用於計算密集型科學計算任務,例如天氣預報、氣候建模、分子動力學(模擬原子和分子的運動)、複雜最佳化問題和求解偏微分方程。另一方面,雲計算往往用於線上服務、業務資料系統和需要以高可用性為使用者請求提供服務的類似系統。
|
* 超級計算機通常用於計算密集型科學計算任務,例如天氣預報、氣候建模、分子動力學(模擬原子和分子的運動)、複雜的最佳化問題和求解偏微分方程。另一方面,雲計算往往用於線上服務、業務資料系統和需要以高可用性為使用者請求提供服務的類似系統。
|
||||||
* 超級計算機通常執行大型批處理作業,定期將其計算狀態檢查點到磁碟。如果節點發生故障,常見的解決方案是簡單地停止整個叢集工作負載,修復故障節點,然後從最後一個檢查點重新啟動計算 [^55] [^56]。對於雲服務,通常不希望停止整個叢集,因為服務需要以最小的中斷持續為使用者提供服務。
|
* 超級計算機通常執行大型批處理作業,定期將其計算狀態檢查點到磁碟。如果節點發生故障,常見的解決方案是簡單地停止整個叢集工作負載,修復故障節點,然後從最後一個檢查點重新啟動計算 [^55] [^56]。對於雲服務,通常不希望停止整個叢集,因為服務需要以最小的中斷持續為使用者提供服務。
|
||||||
* 超級計算機節點通常透過共享記憶體和遠端直接記憶體訪問(RDMA)進行通訊,這支援高頻寬和低延遲,但假設系統使用者之間有高度的信任 [^57]。在雲計算中,網路和機器通常由相互不信任的組織共享,需要更強的安全機制,如資源隔離(例如,虛擬機器)、加密和身份驗證。
|
* 超級計算機節點通常透過共享記憶體和遠端直接記憶體訪問(RDMA)進行通訊,這支援高頻寬和低延遲,但假設系統使用者之間有高度的信任 [^57]。在雲計算中,網路和機器通常由相互不信任的組織共享,需要更強的安全機制,如資源隔離(例如虛擬機器)、加密和身份驗證。
|
||||||
* 雲資料中心網路通常基於 IP 和乙太網,以 Clos 拓撲排列以提供高對分頻寬——這是網路整體效能的常用度量 [^55] [^58]。超級計算機通常使用專門的網路拓撲,例如多維網格和環面 [^59],這為具有已知通訊模式的 HPC 工作負載產生更好的效能。
|
* 雲資料中心網路通常基於 IP 和乙太網,以 Clos 拓撲排列以提供高對分頻寬——這是網路整體效能的常用度量 [^55] [^58]。超級計算機通常使用專門的網路拓撲,例如多維網格和環面 [^59],這能讓具有已知通訊模式的 HPC 工作負載產生更好的效能。
|
||||||
* 雲計算允許節點分佈在多個地理區域,而超級計算機通常假設它們的所有節點都靠近在一起。
|
* 雲計算允許節點分佈在多個地理區域,而超級計算機通常假設它們的所有節點都靠近在一起。
|
||||||
|
|
||||||
大規模分析系統有時與超級計算共享一些特徵,如果你在這個領域工作,瞭解這些技術可能是值得的。然而,本書主要關注需要持續可用的服務,如["可靠性與容錯"](/tw/ch2#sec_introduction_reliability)中所討論的。
|
大規模分析系統有時與超級計算共享一些特徵,如果你在這個領域工作,瞭解這些技術可能是值得的。然而,本書主要關注需要持續可用的服務,如["可靠性與容錯"](/tw/ch2#sec_introduction_reliability)中所討論的。
|
||||||
@ -396,7 +392,7 @@ ETL(參見["資料倉庫"](/tw/ch1#sec_introduction_dwh))只是故事的一
|
|||||||
|
|
||||||
到目前為止,你已經在本章中看到,資料系統的架構不僅受到技術目標和要求的影響,還受到它們所支援的組織的人力需求的影響。越來越多的資料系統工程師認識到,僅服務於自己企業的需求是不夠的:我們還對整個社會負有責任。
|
到目前為止,你已經在本章中看到,資料系統的架構不僅受到技術目標和要求的影響,還受到它們所支援的組織的人力需求的影響。越來越多的資料系統工程師認識到,僅服務於自己企業的需求是不夠的:我們還對整個社會負有責任。
|
||||||
|
|
||||||
一個特別的關注點是儲存有關人員及其行為資料的系統。自 2018 年以來,**通用資料保護條例**(GDPR)賦予了許多歐洲國家居民對其個人資料更大的控制權和法律權利,類似的隱私法規已在世界各地的各個國家和州採用,包括例如加州消費者隱私法(CCPA)。關於 AI 的法規,例如 **歐盟 AI 法案**,對個人資料的使用方式施加了進一步的限制。
|
一個特別的關注點是儲存有關人員及其行為資料的系統。自 2018 年以來,**通用資料保護條例**(GDPR)賦予了許多歐洲國家居民對其個人資料更大的控制權和法律權利,類似的隱私法規已在世界各地的各個國家和州採用,例如加州消費者隱私法(CCPA)。關於 AI 的法規,例如 **歐盟 AI 法案**,對個人資料的使用方式施加了進一步的限制。
|
||||||
|
|
||||||
此外,即使在不直接受法規約束的領域,人們也越來越認識到計算機系統對人和社會的影響。社交媒體改變了個人消費新聞的方式,這影響了他們的政治觀點,因此可能影響選舉結果。自動化系統越來越多地做出對個人產生深遠影響的決策,例如決定誰應該獲得貸款或保險覆蓋,誰應該被邀請參加工作面試,或者誰應該被懷疑犯罪 [^60]。
|
此外,即使在不直接受法規約束的領域,人們也越來越認識到計算機系統對人和社會的影響。社交媒體改變了個人消費新聞的方式,這影響了他們的政治觀點,因此可能影響選舉結果。自動化系統越來越多地做出對個人產生深遠影響的決策,例如決定誰應該獲得貸款或保險覆蓋,誰應該被邀請參加工作面試,或者誰應該被懷疑犯罪 [^60]。
|
||||||
|
|
||||||
@ -404,33 +400,33 @@ ETL(參見["資料倉庫"](/tw/ch1#sec_introduction_dwh))只是故事的一
|
|||||||
|
|
||||||
法律考慮正在影響資料系統設計的基礎 [^61]。例如,GDPR 授予個人在請求時刪除其資料的權利(有時稱為 **被遺忘權**)。然而,正如我們將在本書中看到的,許多資料系統依賴不可變構造(如僅追加日誌)作為其設計的一部分;我們如何確保刪除應該不可變的檔案中間的某些資料?我們如何處理已被納入派生資料集(參見["權威資料來源與派生資料"](/tw/ch1#sec_introduction_derived))的資料刪除,例如機器學習模型的訓練資料?回答這些問題會帶來新的工程挑戰。
|
法律考慮正在影響資料系統設計的基礎 [^61]。例如,GDPR 授予個人在請求時刪除其資料的權利(有時稱為 **被遺忘權**)。然而,正如我們將在本書中看到的,許多資料系統依賴不可變構造(如僅追加日誌)作為其設計的一部分;我們如何確保刪除應該不可變的檔案中間的某些資料?我們如何處理已被納入派生資料集(參見["權威資料來源與派生資料"](/tw/ch1#sec_introduction_derived))的資料刪除,例如機器學習模型的訓練資料?回答這些問題會帶來新的工程挑戰。
|
||||||
|
|
||||||
目前,我們對於哪些特定技術或系統架構應被視為"符合 GDPR"沒有明確的指導方針。法規故意不強制要求特定技術,因為隨著技術的進步,這些技術可能會迅速變化。相反,法律文字規定了需要解釋的高階原則。這意味著如何遵守隱私法規的問題沒有簡單的答案,但我們將透過這個視角來看待本書中的一些技術。
|
目前,我們對於哪些特定技術或系統架構應被視為“符合 GDPR”沒有明確的指導方針。法規故意不強制要求特定技術,因為隨著技術的進步,這些技術可能會迅速變化。相反,法律文字規定了需要解釋的高層級原則。這意味著如何遵守隱私法規的問題沒有簡單的答案,但我們將透過這個視角來看待本書中的一些技術。
|
||||||
|
|
||||||
一般來說,我們儲存資料是因為我們認為其價值大於儲存它的成本。然而,值得記住的是,儲存成本不僅僅是你為 Amazon S3 或其他服務支付的賬單:成本效益計算還應該考慮到如果資料被洩露或被對手入侵的責任和聲譽損害風險,以及如果資料的儲存和處理被發現不符合法律的法律成本和罰款風險 [^51]。
|
一般來說,我們儲存資料是因為我們認為其價值大於儲存它的成本。然而,值得記住的是,儲存成本不僅僅是你為 Amazon S3 或其他服務支付的賬單:成本效益計算還應該考慮到如果資料被洩露或被對手入侵的責任和聲譽損害風險,以及如果資料的儲存和處理被發現不符合法律的法律成本和罰款風險 [^51]。
|
||||||
|
|
||||||
政府或警察部隊也可能迫使公司交出資料。當存在資料可能暴露犯罪行為的風險時(例如,在幾個中東和非洲國家的同性戀,或在幾個美國州尋求墮胎),儲存該資料會為使用者創造真正的安全風險。例如,去墮胎診所的旅行很容易被位置資料揭示,甚至可能透過使用者 IP 地址隨時間的日誌(表示大致位置)。
|
政府或警察部隊也可能迫使公司交出資料。當存在資料可能暴露犯罪行為的風險時(例如,在幾個中東和非洲國家的同性戀,或在幾個美國州尋求墮胎),儲存該資料會為使用者創造真正的安全風險。例如,去墮胎診所的旅行很容易被位置資料揭示,甚至可能透過使用者 IP 地址隨時間的日誌(表示大致位置)。
|
||||||
|
|
||||||
一旦考慮到所有風險,可能合理地決定某些資料根本不值得儲存,因此應該刪除。這個 **資料最小化** 原則(有時以德語術語 **Datensparsamkeit** 為人所知)與"大資料"哲學相反,後者是投機性地儲存大量資料,以防將來有用 [^62]。但它符合 GDPR,該法規要求個人資料只能為指定的、明確的目的收集,這些資料以後不得用於任何其他目的,並且資料不得保留超過收集目的所需的時間 [^63]。
|
一旦考慮到所有風險,可能合理地決定某些資料根本不值得儲存,因此應該刪除。這個 **資料最小化** 原則(有時以德語術語 **Datensparsamkeit** 為人所知)與“大資料”哲學相反,後者是投機性地儲存大量資料,以防將來有用 [^62]。但它符合 GDPR,該法規要求個人資料只能為指定的、明確的目的收集,這些資料以後不得用於任何其他目的,並且資料不得保留超過收集目的所需的時間 [^63]。
|
||||||
|
|
||||||
企業也注意到了隱私和安全問題。信用卡公司要求支付處理企業遵守嚴格的支付卡行業(PCI)標準。處理商經常接受獨立審計師的評估,以驗證持續的合規性。軟體供應商也受到了更多的審查。現在許多買家要求他們的供應商遵守服務組織控制(SOC)型別 2 標準。與 PCI 合規性一樣,供應商接受第三方審計以驗證遵守情況。
|
企業也注意到了隱私和安全問題。信用卡公司要求處理支付的企業遵守嚴格的支付卡行業(PCI)標準。處理商需要經常接受獨立審計師的評估,以驗證持續的合規性。軟體供應商也受到了更多的審查。現在許多買家要求他們的供應商遵守服務組織控制(SOC)型別 2 標準。與 PCI 合規性一樣,供應商需要接受第三方審計以驗證遵守情況。
|
||||||
|
|
||||||
一般來說,重要的是平衡你的業務需求與你收集和處理其資料的人的需求。這個話題還有很多內容;在[待補充連結]中,我們將更深入地探討道德和法律合規性的主題,包括偏見和歧視的問題。
|
一般來說,重要的是平衡你的業務需求與你收集和處理其資料的人的需求。這個話題還有很多內容;在[待補充連結]中,我們將更深入地探討道德和法律合規性的主題,包括偏見和歧視的問題。
|
||||||
|
|
||||||
|
|
||||||
## 總結 {#summary}
|
## 總結 {#summary}
|
||||||
|
|
||||||
本章的主題是理解權衡:也就是說,認識到對於許多問題,沒有一個正確的答案,而是有幾種不同的方法,每種方法都有各種利弊。我們探討了影響資料系統架構的一些最重要的選擇,並介紹了本書其餘部分所需的術語。
|
本章的主題是理解權衡:也就是說要認識到對於許多問題並沒有一個正確的答案,而是有幾種不同的方法,每種方法都有各種利弊。我們探討了影響資料系統架構的一些最重要的選擇,並介紹了本書其餘部分所需的術語。
|
||||||
|
|
||||||
我們首先區分了事務型(事務處理,OLTP)和分析型(OLAP)系統,並看到了它們的不同特徵:不僅管理不同型別的資料和不同的訪問模式,而且服務於不同的受眾。我們遇到了資料倉庫和資料湖的概念,它們透過 ETL 從事務型系統接收資料饋送。在[第 4 章](/tw/ch4#ch_storage)中,我們將看到事務型和分析型系統通常使用非常不同的內部資料佈局,因為它們需要服務的查詢型別不同。
|
我們首先區分了事務型(事務處理,OLTP)和分析型(OLAP)系統,並看到了它們的不同特徵:不僅透過不同的訪問模式管理不同型別的資料,而且服務於不同的受眾。我們遇到了資料倉庫和資料湖的概念,它們透過 ETL 從事務型系統接收資料。在[第 4 章](/tw/ch4#ch_storage)中,我們將看到事務型和分析型系統通常使用非常不同的內部資料佈局,因為它們需要服務的查詢型別不同。
|
||||||
|
|
||||||
然後,我們將雲服務(一個相對較新的發展)與傳統的自託管軟體正規化進行了比較,後者以前主導了資料系統架構。這些方法中哪一種更具成本效益在很大程度上取決於你的特定情況,但不可否認的是,雲原生方法正在為資料系統的架構帶來重大變化,例如它們分離儲存和計算的方式。
|
然後,我們將雲服務(一個相對較新的發展)與傳統的自託管軟體正規化進行了比較,後者以前主導了資料系統架構。這些方法中哪一種更具成本效益在很大程度上取決於你的特定情況,但不可否認的是,雲原生方法正在為資料系統的架構帶來重大變化,例如它們分離儲存和計算的方式。
|
||||||
|
|
||||||
雲系統本質上是分散式的,我們簡要地研究了分散式系統與使用單臺機器相比的一些權衡。有些情況下你無法避免分散式,但如果可能在單臺機器上保持系統,建議不要急於使系統分散式。在[第 9 章](/tw/ch9#ch_distributed)中,我們將更詳細地介紹分散式系統的挑戰。
|
雲系統本質上是分散式的,我們簡要地研究了分散式系統與使用單臺機器相比的一些權衡。有些情況下你無法避免分散式,但如果可能在單臺機器上執行系統,建議不要急於使系統分散式。在[第 9 章](/tw/ch9#ch_distributed)中,我們將更詳細地介紹分散式系統的挑戰。
|
||||||
|
|
||||||
最後,我們看到資料系統架構不僅由部署系統的企業的需求決定,還由保護資料被處理的人的權利的隱私法規決定——這是許多工程師容易忽視的一個方面。我們如何將法律要求轉化為技術實現還不太瞭解,但在我們閱讀本書的其餘部分時,記住這個問題很重要。
|
最後,我們看到資料系統架構不僅由部署系統的企業的需求決定,還由保護其資料被處理的人的權利的隱私法規決定——這是許多工程師容易忽視的一個方面。我們如何將法律要求轉化為技術實現還沒有非常清晰的答案,但在我們閱讀本書的其餘部分時,記住這個問題很重要。
|
||||||
|
|
||||||
### 參考
|
### 參考
|
||||||
|
|
||||||
|
|
||||||
[^1]: Richard T. Kouzes, Gordon A. Anderson, Stephen T. Elbert, Ian Gorton, and Deborah K. Gracio. [The Changing Paradigm of Data-Intensive Computing](http://www2.ic.uff.br/~boeres/slides_AP/papers/TheChanginParadigmDataIntensiveComputing_2009.pdf). *IEEE Computer*, volume 42, issue 1, January 2009. [doi:10.1109/MC.2009.26](https://doi.org/10.1109/MC.2009.26)
|
[^1]: Richard T. Kouzes, Gordon A. Anderson, Stephen T. Elbert, Ian Gorton, and Deborah K. Gracio. [The Changing Paradigm of Data-Intensive Computing](http://www2.ic.uff.br/~boeres/slides_AP/papers/TheChanginParadigmDataIntensiveComputing_2009.pdf). *IEEE Computer*, volume 42, issue 1, January 2009. [doi:10.1109/MC.2009.26](https://doi.org/10.1109/MC.2009.26)
|
||||||
[^2]: Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. [Local-first software: you own your data, in spite of the cloud](https://www.inkandswitch.com/local-first/). At *2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software* (Onward!), October 2019. [doi:10.1145/3359591.3359737](https://doi.org/10.1145/3359591.3359737)
|
[^2]: Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. [Local-first software: you own your data, in spite of the cloud](https://www.inkandswitch.com/local-first/). At *2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software* (Onward!), October 2019. [doi:10.1145/3359591.3359737](https://doi.org/10.1145/3359591.3359737)
|
||||||
[^3]: Joe Reis and Matt Housley. [*Fundamentals of Data Engineering*](https://www.oreilly.com/library/view/fundamentals-of-data/9781098108298/). O’Reilly Media, 2022. ISBN: 9781098108304
|
[^3]: Joe Reis and Matt Housley. [*Fundamentals of Data Engineering*](https://www.oreilly.com/library/view/fundamentals-of-data/9781098108298/). O’Reilly Media, 2022. ISBN: 9781098108304
|
||||||
|
@ -180,8 +180,6 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。
|
|||||||
这就结束了我们对分析和事务处理的比较。在下一节中,我们将研究另一个你可能已经看到多次争论的权衡。
|
这就结束了我们对分析和事务处理的比较。在下一节中,我们将研究另一个你可能已经看到多次争论的权衡。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 云服务与自托管 {#sec_introduction_cloud}
|
## 云服务与自托管 {#sec_introduction_cloud}
|
||||||
|
|
||||||
对于组织需要做的任何事情,首要问题之一是:应该在内部完成,还是应该外包?应该自建还是购买?
|
对于组织需要做的任何事情,首要问题之一是:应该在内部完成,还是应该外包?应该自建还是购买?
|
||||||
@ -233,10 +231,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。
|
|||||||
如果有暴露兼容 API 的替代服务,这种风险会得到缓解,但对于许多云服务,没有标准 API,这增加了切换成本,使供应商锁定成为一个问题。
|
如果有暴露兼容 API 的替代服务,这种风险会得到缓解,但对于许多云服务,没有标准 API,这增加了切换成本,使供应商锁定成为一个问题。
|
||||||
* 云供应商需要被信任以保持数据安全,这可能会使遵守隐私和安全法规的过程复杂化。
|
* 云供应商需要被信任以保持数据安全,这可能会使遵守隐私和安全法规的过程复杂化。
|
||||||
|
|
||||||
尽管有所有这些风险,组织在云服务之上构建新应用程序或采用混合方法(在系统的某些部分使用云服务)变得越来越流行。
|
尽管有所有这些风险,组织在云服务之上构建新应用程序或采用混合方法(在系统的某些部分使用云服务)变得越来越流行。然而,云服务不会取代所有内部数据系统:许多较旧的系统早于云,对于任何具有现有云服务无法满足的专业要求的服务,内部系统仍然是必要的。例如,对延迟非常敏感的应用程序(如高频交易)需要对硬件的完全控制。
|
||||||
然而,云服务不会取代所有内部数据系统:许多较旧的系统早于云,对于任何具有现有云服务无法满足的专业要求的服务,内部系统仍然是必要的。
|
|
||||||
例如,对延迟非常敏感的应用程序(如高频交易)需要对硬件的完全控制。
|
|
||||||
|
|
||||||
|
|
||||||
### 云原生系统架构 {#sec_introduction_cloud_native}
|
### 云原生系统架构 {#sec_introduction_cloud_native}
|
||||||
|
|
||||||
@ -291,15 +286,15 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。
|
|||||||
|
|
||||||
运维的作用是确保服务可靠地交付给用户(包括配置基础设施和部署应用程序),并确保稳定的生产环境(包括监控和诊断可能影响可靠性的任何问题)。对于自托管系统,运维传统上涉及大量在单个机器级别的工作,例如容量规划(例如,监控可用磁盘空间并在空间用完之前添加更多磁盘)、配置新机器、将服务从一台机器移动到另一台机器,以及安装操作系统补丁。
|
运维的作用是确保服务可靠地交付给用户(包括配置基础设施和部署应用程序),并确保稳定的生产环境(包括监控和诊断可能影响可靠性的任何问题)。对于自托管系统,运维传统上涉及大量在单个机器级别的工作,例如容量规划(例如,监控可用磁盘空间并在空间用完之前添加更多磁盘)、配置新机器、将服务从一台机器移动到另一台机器,以及安装操作系统补丁。
|
||||||
|
|
||||||
许多云服务提供了一个 API,隐藏了实际实现服务的单个机器。例如,云存储用 **计量计费** 替换固定大小的磁盘,你可以存储数据而无需提前规划容量需求,然后根据实际使用的空间收费。此外,许多云服务保持高可用性,即使单个机器发生故障(参见["可靠性与容错"](/ch2#sec_introduction_reliability))。
|
许多云服务提供了 API 来隐藏实际实现服务的单个机器。例如,云存储用 **计量计费** 替换固定大小的磁盘,你可以存储数据而无需提前规划容量需求,然后根据实际使用的空间收费。此外,即使在单个机器发生故障时,许多云服务仍能保持高可用性(参见["可靠性与容错"](/ch2#sec_introduction_reliability))。
|
||||||
|
|
||||||
从单个机器到服务的重点转移伴随着运维角色的变化。提供可靠服务的高级目标保持不变,但流程和工具已经发展。DevOps/SRE 理念更加强调:
|
从单个机器到服务的重点转移伴随着运维角色的变化。提供可靠服务的高级目标保持不变,但流程和工具已经发展。DevOps/SRE 理念更加强调:
|
||||||
|
|
||||||
* 自动化——优先考虑可重复的流程而不是手动的一次性工作,
|
* 自动化——优先考虑可重复的流程而不是手动的一次性工作,
|
||||||
* 优先考虑短暂的虚拟机和服务而不是长期运行的服务器,
|
* 优先考虑短暂的虚拟机和服务而不是长期运行的服务器,
|
||||||
* 启用频繁的应用程序更新,
|
* 启用频繁的应用程序更新,
|
||||||
* 从事件中学习,以及
|
* 从事故中学习,以及
|
||||||
* 保留组织关于系统的知识,即使个人来来去去 [^35]。
|
* 保留组织关于系统的知识,即使组织里的人员在不断流动 [^35]。
|
||||||
|
|
||||||
随着云服务的兴起,角色出现了分叉:基础设施公司的运维团队专门研究向大量客户提供可靠服务的细节,而服务的客户在基础设施上花费尽可能少的时间和精力 [^36]。
|
随着云服务的兴起,角色出现了分叉:基础设施公司的运维团队专门研究向大量客户提供可靠服务的细节,而服务的客户在基础设施上花费尽可能少的时间和精力 [^36]。
|
||||||
|
|
||||||
@ -307,17 +302,16 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。
|
|||||||
|
|
||||||
此外,云服务确实有资源限制或 **配额**(例如你可以同时运行的最大进程数),你需要在遇到它们之前了解并规划这些 [^38]。
|
此外,云服务确实有资源限制或 **配额**(例如你可以同时运行的最大进程数),你需要在遇到它们之前了解并规划这些 [^38]。
|
||||||
|
|
||||||
采用云服务可能比运行自己的基础设施更容易、更快,尽管即使在这里,学习如何使用它也有成本,也许还要解决其限制。随着越来越多的供应商提供针对不同用例的更广泛的云服务,不同服务之间的集成成为一个特别的挑战 [^39] [^40]。
|
采用云服务可能比运行自己的基础设施更容易、更快,尽管学习如何使用它也有成本,也许还要解决其限制。随着越来越多的供应商提供针对不同用例的更广泛的云服务,不同服务之间的集成成为一个特别的挑战 [^39] [^40]。
|
||||||
|
|
||||||
ETL(参见["数据仓库"](/ch1#sec_introduction_dwh))只是故事的一部分;事务型云服务也需要相互集成。目前,缺乏促进这种集成的标准,因此它通常涉及大量的手动工作。
|
ETL(参见["数据仓库"](/ch1#sec_introduction_dwh))只是故事的一部分;事务型云服务也需要相互集成。目前,缺乏促进这种集成的标准,因此它通常涉及大量的手动工作。
|
||||||
|
|
||||||
无法完全外包给云服务的其他运维方面包括维护应用程序及其使用的库的安全性、管理你自己的服务之间的交互、监控服务的负载,以及追踪问题的原因,例如性能下降或中断。虽然云正在改变运维的角色,但对运维的需求比以往任何时候都大。
|
无法完全外包给云服务的其他运维方面包括维护应用程序及其使用的库的安全性、管理你自己的服务之间的交互、监控服务的负载,以及追踪问题的原因,例如性能下降或中断。虽然云正在改变运维的角色,但对运维的需求比以往任何时候都大。
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 分布式与单节点系统 {#sec_introduction_distributed}
|
## 分布式与单节点系统 {#sec_introduction_distributed}
|
||||||
|
|
||||||
涉及多台机器通过网络通信的系统称为 **分布式系统**。参与分布式系统的每个进程称为 **节点**。你可能希望系统分布式的原因有多种:
|
涉及多台机器通过网络通信的系统称为 **分布式系统**。参与分布式系统的每个进程称为 **节点**。你希望采用分布式系统的原因可能有多种:
|
||||||
|
|
||||||
固有的分布式系统
|
固有的分布式系统
|
||||||
: 如果应用程序涉及两个或多个交互用户,每个用户使用自己的设备,那么系统不可避免地是分布式的:设备之间的通信必须通过网络进行。
|
: 如果应用程序涉及两个或多个交互用户,每个用户使用自己的设备,那么系统不可避免地是分布式的:设备之间的通信必须通过网络进行。
|
||||||
@ -335,16 +329,16 @@ ETL(参见["数据仓库"](/ch1#sec_introduction_dwh))只是故事的一部
|
|||||||
: 如果你在世界各地都有用户,你可能希望在全球各个地区都有服务器,以便每个用户都可以从地理位置接近他们的服务器获得服务。这避免了用户必须等待网络数据包绕地球半圈才能回答他们的请求。参见["描述性能"](/ch2#sec_introduction_percentiles)。
|
: 如果你在世界各地都有用户,你可能希望在全球各个地区都有服务器,以便每个用户都可以从地理位置接近他们的服务器获得服务。这避免了用户必须等待网络数据包绕地球半圈才能回答他们的请求。参见["描述性能"](/ch2#sec_introduction_percentiles)。
|
||||||
|
|
||||||
弹性
|
弹性
|
||||||
: 如果你的应用程序在某些时候很忙,在其他时候很空闲,云部署可以根据需求向上或向下扩展,因此你只需为实际使用的资源付费。这在单台机器上更困难,它需要配置以处理最大负载,即使在几乎不使用的时候也是如此。
|
: 如果你的应用程序在某些时候很忙,在其他时候很空闲,云部署可以根据需求向上或向下伸缩,因此你只需为实际使用的资源付费。这在单台机器上更困难,它需要按处理最大负载的情况进行配置,即使在几乎不使用的时候也是如此。
|
||||||
|
|
||||||
使用专用硬件
|
使用专用硬件
|
||||||
: 系统的不同部分可以利用不同类型的硬件来匹配其工作负载。例如,对象存储可能使用具有许多磁盘但很少 CPU 的机器,而数据分析系统可能使用具有大量 CPU 和内存但没有磁盘的机器,机器学习系统可能使用具有 GPU 的机器(GPU 在训练深度神经网络和其他机器学习任务方面比 CPU 效率高得多)。
|
: 系统的不同部分可以利用不同类型的硬件来匹配其工作负载。例如,对象存储可能使用具有许多磁盘但很少 CPU 的机器,而数据分析系统可能使用具有大量 CPU 和内存但没有磁盘的机器,机器学习系统可能使用具有 GPU 的机器(GPU 在训练深度神经网络和其他机器学习任务方面比 CPU 效率高得多)。
|
||||||
|
|
||||||
法律合规
|
法律合规
|
||||||
: 一些国家有数据驻留法律,要求其管辖范围内的人员数据必须在该国地理范围内存储和处理 [^41]。这些规则的范围各不相同——例如,在某些情况下,它仅适用于医疗或金融数据,而其他情况则更广泛。因此,在几个这样的管辖区域中拥有用户的服务将不得不将他们的数据分布在几个位置的服务器上。
|
: 一些国家有数据驻留法律,要求其管辖范围内的人员数据必须在该国地理范围内存储和处理 [^41]。这些规则的范围各不相同——例如,在某些情况下,它仅适用于医疗或金融数据,而其他情况则更广泛。因此,在几个这样的管辖区域中拥有用户的服务不得不将他们的数据分布在几个位置的服务器上。
|
||||||
|
|
||||||
可持续性
|
可持续性
|
||||||
: 如果你对运行作业的地点和时间有灵活性,你可能能够在可再生电力充足的时间和地点运行它们,并避免在电网紧张时运行它们。这可以减少你的碳排放,并允许你在电力可用时利用廉价的电力 [^42] [^43]。
|
: 如果你能灵活把控作业运行的地点和时间,你可能能够在可再生电力充足的时间和地点运行它们,并避免在电网紧张时运行它们。这可以减少你的碳排放,并允许你利用到廉价的电力 [^42] [^43]。
|
||||||
|
|
||||||
这些原因既适用于你自己编写的服务(应用程序代码),也适用于由现成软件(如数据库)组成的服务。
|
这些原因既适用于你自己编写的服务(应用程序代码),也适用于由现成软件(如数据库)组成的服务。
|
||||||
|
|
||||||
@ -353,14 +347,16 @@ ETL(参见["数据仓库"](/ch1#sec_introduction_dwh))只是故事的一部
|
|||||||
分布式系统也有缺点。通过网络进行的每个请求和 API 调用都需要处理失败的可能性:网络可能中断,或者服务可能过载或崩溃,因此任何请求都可能超时而没有收到响应。在这种情况下,我们不知道服务是否收到了请求,简单地重试它可能不安全。我们将在[第 9 章](/ch9#ch_distributed)中详细讨论这些问题。
|
分布式系统也有缺点。通过网络进行的每个请求和 API 调用都需要处理失败的可能性:网络可能中断,或者服务可能过载或崩溃,因此任何请求都可能超时而没有收到响应。在这种情况下,我们不知道服务是否收到了请求,简单地重试它可能不安全。我们将在[第 9 章](/ch9#ch_distributed)中详细讨论这些问题。
|
||||||
|
|
||||||
尽管数据中心网络很快,但调用另一个服务仍然比在同一进程中调用函数慢得多 [^44]。
|
尽管数据中心网络很快,但调用另一个服务仍然比在同一进程中调用函数慢得多 [^44]。
|
||||||
在处理大量数据时,与其将数据从存储传输到处理它的单独机器,不如将计算带到已经拥有数据的机器上可能更快 [^45]。
|
|
||||||
更多的节点并不总是更快:在某些情况下,单台计算机上的简单单线程程序可以比具有 100 多个 CPU 核心的集群表现得更好 [^46]。
|
|
||||||
|
|
||||||
故障排除分布式系统通常很困难:如果系统响应缓慢,你如何找出问题所在?在 **可观测性** [^47] [^48] 的标题下开发了诊断分布式系统问题的技术,这涉及收集有关系统执行的数据,并允许以允许分析高级指标和单个事件的方式进行查询。**追踪** 工具(如 OpenTelemetry、Zipkin 和 Jaeger)允许你跟踪哪个客户端为哪个操作调用了哪个服务器,以及每次调用花费了多长时间 [^49]。
|
在处理大量数据时,与其将数据从其存储处传输到处理它的单独机器,将计算带到已经拥有数据的机器上可能更快 [^45]。
|
||||||
|
|
||||||
|
更多的节点并不总是更快:在某些情况下,一个简单的单线程程序在单台计算机上运行的性能可以比在具有 100 多个 CPU 核心的集群上更好 [^46]。
|
||||||
|
|
||||||
|
对分布式系统进行故障排除通常很困难:如果系统响应缓慢,你如何找出问题所在?**可观测性** [^47] [^48] 技术可以用来对分布式系统中的问题进行诊断,这涉及到系统执行数据的收集,并提供查询方式来支持对高层级的指标或单个的事件的分析。**追踪** 工具(如 OpenTelemetry、Zipkin 和 Jaeger)允许你跟踪哪个客户端为哪个操作调用了哪个服务器,以及每次调用花费了多长时间 [^49]。
|
||||||
|
|
||||||
数据库提供了各种机制来确保数据一致性,正如我们将在[第 6 章](/ch6#ch_replication)和[第 8 章](/ch8#ch_transactions)中看到的。然而,当每个服务都有自己的数据库时,维护这些不同服务之间的数据一致性就成了应用程序的问题。分布式事务(我们在[第 8 章](/ch8#ch_transactions)中探讨)是确保一致性的一种可能技术,但它们在微服务上下文中很少使用,因为它们违背了使服务彼此独立的目标,而且许多数据库不支持它们 [^50]。
|
数据库提供了各种机制来确保数据一致性,正如我们将在[第 6 章](/ch6#ch_replication)和[第 8 章](/ch8#ch_transactions)中看到的。然而,当每个服务都有自己的数据库时,维护这些不同服务之间的数据一致性就成了应用程序的问题。分布式事务(我们在[第 8 章](/ch8#ch_transactions)中探讨)是确保一致性的一种可能技术,但它们在微服务上下文中很少使用,因为它们违背了使服务彼此独立的目标,而且许多数据库不支持它们 [^50]。
|
||||||
|
|
||||||
出于所有这些原因,如果你可以在单台机器上做某事,与设置分布式系统相比,这通常要简单得多,成本也更低 [^23] [^46] [^51]。CPU、内存和磁盘已经变得更大、更快、更可靠。当与 DuckDB、SQLite 和 KùzuDB 等单节点数据库结合使用时,许多工作负载现在可以在单个节点上运行。我们将在[第 4 章](/ch4#ch_storage)中进一步探讨这个主题。
|
出于所有这些原因,如果你可以在单台机器上做某件事情,与搭建分布式系统相比通常要简单得多,成本也更低 [^23] [^46] [^51]。CPU、内存和磁盘已经变得更大、更快、更可靠。当与 DuckDB、SQLite 和 KùzuDB 等单节点数据库结合使用时,许多工作负载现在可以在单个节点上运行。我们将在[第 4 章](/ch4#ch_storage)中进一步探讨这个主题。
|
||||||
|
|
||||||
### 微服务与 Serverless {#sec_introduction_microservices}
|
### 微服务与 Serverless {#sec_introduction_microservices}
|
||||||
|
|
||||||
@ -372,22 +368,22 @@ ETL(参见["数据仓库"](/ch1#sec_introduction_dwh))只是故事的一部
|
|||||||
|
|
||||||
另一方面,拥有许多服务本身可能会带来复杂性:每个服务都需要用于部署新版本、调整分配的硬件资源以匹配负载、收集日志、监控服务健康状况以及在出现问题时向值班工程师发出警报的基础设施。**编排** 框架(如 Kubernetes)已成为部署服务的流行方式,因为它们为这种基础设施提供了基础。在开发期间测试服务可能很复杂,因为你还需要运行它所依赖的所有其他服务。
|
另一方面,拥有许多服务本身可能会带来复杂性:每个服务都需要用于部署新版本、调整分配的硬件资源以匹配负载、收集日志、监控服务健康状况以及在出现问题时向值班工程师发出警报的基础设施。**编排** 框架(如 Kubernetes)已成为部署服务的流行方式,因为它们为这种基础设施提供了基础。在开发期间测试服务可能很复杂,因为你还需要运行它所依赖的所有其他服务。
|
||||||
|
|
||||||
微服务 API 的演进可能具有挑战性。调用 API 的客户端期望 API 具有某些字段。开发人员可能希望根据业务需求的变化向 API 添加或删除字段,但这样做可能会导致客户端失败。更糟糕的是,这种失败通常直到开发周期的后期才被发现,当更新的服务 API 部署到暂存或生产环境时。API 描述标准(如 OpenAPI 和 gRPC)有助于管理客户端和服务器 API 之间的关系;我们将在[第 5 章](/ch5#ch_encoding)中进一步讨论这些。
|
微服务 API 的演进可能具有挑战性。调用 API 的客户端期望 API 具有某些字段。开发人员可能希望根据业务需求的变化向 API 添加或删除字段,但这样做可能会导致客户端失败。更糟糕的是,这种失败通常直到开发周期的后期才被发现,当更新的服务 API 部署到预生产或生产环境时。API 描述标准(如 OpenAPI 和 gRPC)有助于管理客户端和服务器 API 之间的关系;我们将在[第 5 章](/ch5#ch_encoding)中进一步讨论这些。
|
||||||
|
|
||||||
微服务主要是人员问题的技术解决方案:允许不同的团队独立取得进展,而无需相互协调。这在大公司中很有价值,但在没有很多团队的小公司中,使用微服务可能是不必要的开销,最好以最简单的方式实现应用程序 [^52]。
|
微服务主要是人员问题的技术解决方案:允许不同的团队独立取得进展,而无需相互协调。这在大公司中很有价值,但在没有很多团队的小公司中,使用微服务可能是不必要的开销,最好以最简单的方式实现应用程序 [^52]。
|
||||||
|
|
||||||
**Serverless** 或 **函数即服务**(FaaS)是部署服务的另一种方法,其中基础设施的管理外包给云供应商 [^33]。使用虚拟机时,你必须明确选择何时启动或关闭实例;相比之下,使用 serverless 模型,云提供商根据对你服务的传入请求自动分配和释放硬件资源 [^54]。Serverless 部署将更多的运营负担转移到云提供商,并通过使用量而不是机器实例实现灵活的计费。为了提供这些好处,许多 serverless 基础设施提供商对函数执行施加时间限制,限制运行时环境,并且在首次调用函数时可能会遭受缓慢的启动时间。术语"serverless"也可能具有误导性:每个 serverless 函数执行仍然在服务器上运行,但后续执行可能在不同的服务器上运行。此外,BigQuery 和各种 Kafka 产品等基础设施已经采用"serverless"术语来表示他们的服务自动扩展,并且他们按使用量而不是机器实例计费。
|
**Serverless** 或 **函数即服务**(FaaS)是部署服务的另一种方法,其中基础设施的管理外包给云供应商 [^33]。使用虚拟机时,你必须明确选择何时启动或关闭实例;相比之下,使用 serverless 模型,云提供商根据对你服务的传入请求自动分配和释放硬件资源 [^54]。Serverless 部署将更多的运营负担转移到云提供商,并通过使用量而不是机器实例实现灵活的计费。为了提供这些好处,许多 serverless 基础设施提供商对函数执行施加时间限制,限制运行时环境,并且在首次调用函数时可能会遭受缓慢的启动时间。术语“serverless”也可能具有误导性:每个 serverless 函数执行仍然在服务器上运行,但后续执行可能在不同的服务器上运行。此外,BigQuery 和各种 Kafka 产品等基础设施已经采用“serverless”术语来表示他们的服务自动扩展,并且他们按使用量而不是机器实例计费。
|
||||||
|
|
||||||
就像云存储用计量计费模型取代了容量规划(提前决定购买多少磁盘)一样,serverless 方法正在为代码执行带来计量计费:你只为应用程序代码实际运行的时间付费,而不必提前配置资源。
|
就像云存储用计量计费模型取代了容量规划(提前决定购买多少磁盘)一样,serverless 方法正在为代码执行带来计量计费:你只为应用程序代码实际运行的时间付费,而不必提前配置资源。
|
||||||
|
|
||||||
### 云计算与超级计算 {#id17}
|
### 云计算与超级计算 {#id17}
|
||||||
|
|
||||||
云计算不是构建大规模计算系统的唯一方式;另一种选择是 **高性能计算**(HPC),也称为 **超级计算**。尽管有重叠,但与云计算和企业数据中心系统相比,HPC 通常有不同的优先级并使用不同的技术。其中一些差异是:
|
云计算不是构建大规模计算系统的唯一方式;另一种选择是 **高性能计算**(HPC),也称为 **超级计算**。尽管有重叠,但与云计算和企业数据中心系统相比,HPC 通常有不同的设计考量并使用不同的技术。其中一些差异是:
|
||||||
|
|
||||||
* 超级计算机通常用于计算密集型科学计算任务,例如天气预报、气候建模、分子动力学(模拟原子和分子的运动)、复杂优化问题和求解偏微分方程。另一方面,云计算往往用于在线服务、业务数据系统和需要以高可用性为用户请求提供服务的类似系统。
|
* 超级计算机通常用于计算密集型科学计算任务,例如天气预报、气候建模、分子动力学(模拟原子和分子的运动)、复杂的优化问题和求解偏微分方程。另一方面,云计算往往用于在线服务、业务数据系统和需要以高可用性为用户请求提供服务的类似系统。
|
||||||
* 超级计算机通常运行大型批处理作业,定期将其计算状态检查点到磁盘。如果节点发生故障,常见的解决方案是简单地停止整个集群工作负载,修复故障节点,然后从最后一个检查点重新启动计算 [^55] [^56]。对于云服务,通常不希望停止整个集群,因为服务需要以最小的中断持续为用户提供服务。
|
* 超级计算机通常运行大型批处理作业,定期将其计算状态检查点到磁盘。如果节点发生故障,常见的解决方案是简单地停止整个集群工作负载,修复故障节点,然后从最后一个检查点重新启动计算 [^55] [^56]。对于云服务,通常不希望停止整个集群,因为服务需要以最小的中断持续为用户提供服务。
|
||||||
* 超级计算机节点通常通过共享内存和远程直接内存访问(RDMA)进行通信,这支持高带宽和低延迟,但假设系统用户之间有高度的信任 [^57]。在云计算中,网络和机器通常由相互不信任的组织共享,需要更强的安全机制,如资源隔离(例如,虚拟机)、加密和身份验证。
|
* 超级计算机节点通常通过共享内存和远程直接内存访问(RDMA)进行通信,这支持高带宽和低延迟,但假设系统用户之间有高度的信任 [^57]。在云计算中,网络和机器通常由相互不信任的组织共享,需要更强的安全机制,如资源隔离(例如虚拟机)、加密和身份验证。
|
||||||
* 云数据中心网络通常基于 IP 和以太网,以 Clos 拓扑排列以提供高对分带宽——这是网络整体性能的常用度量 [^55] [^58]。超级计算机通常使用专门的网络拓扑,例如多维网格和环面 [^59],这为具有已知通信模式的 HPC 工作负载产生更好的性能。
|
* 云数据中心网络通常基于 IP 和以太网,以 Clos 拓扑排列以提供高对分带宽——这是网络整体性能的常用度量 [^55] [^58]。超级计算机通常使用专门的网络拓扑,例如多维网格和环面 [^59],这能让具有已知通信模式的 HPC 工作负载产生更好的性能。
|
||||||
* 云计算允许节点分布在多个地理区域,而超级计算机通常假设它们的所有节点都靠近在一起。
|
* 云计算允许节点分布在多个地理区域,而超级计算机通常假设它们的所有节点都靠近在一起。
|
||||||
|
|
||||||
大规模分析系统有时与超级计算共享一些特征,如果你在这个领域工作,了解这些技术可能是值得的。然而,本书主要关注需要持续可用的服务,如["可靠性与容错"](/ch2#sec_introduction_reliability)中所讨论的。
|
大规模分析系统有时与超级计算共享一些特征,如果你在这个领域工作,了解这些技术可能是值得的。然而,本书主要关注需要持续可用的服务,如["可靠性与容错"](/ch2#sec_introduction_reliability)中所讨论的。
|
||||||
@ -396,7 +392,7 @@ ETL(参见["数据仓库"](/ch1#sec_introduction_dwh))只是故事的一部
|
|||||||
|
|
||||||
到目前为止,你已经在本章中看到,数据系统的架构不仅受到技术目标和要求的影响,还受到它们所支持的组织的人力需求的影响。越来越多的数据系统工程师认识到,仅服务于自己企业的需求是不够的:我们还对整个社会负有责任。
|
到目前为止,你已经在本章中看到,数据系统的架构不仅受到技术目标和要求的影响,还受到它们所支持的组织的人力需求的影响。越来越多的数据系统工程师认识到,仅服务于自己企业的需求是不够的:我们还对整个社会负有责任。
|
||||||
|
|
||||||
一个特别的关注点是存储有关人员及其行为数据的系统。自 2018 年以来,**通用数据保护条例**(GDPR)赋予了许多欧洲国家居民对其个人数据更大的控制权和法律权利,类似的隐私法规已在世界各地的各个国家和州采用,包括例如加州消费者隐私法(CCPA)。关于 AI 的法规,例如 **欧盟 AI 法案**,对个人数据的使用方式施加了进一步的限制。
|
一个特别的关注点是存储有关人员及其行为数据的系统。自 2018 年以来,**通用数据保护条例**(GDPR)赋予了许多欧洲国家居民对其个人数据更大的控制权和法律权利,类似的隐私法规已在世界各地的各个国家和州采用,例如加州消费者隐私法(CCPA)。关于 AI 的法规,例如 **欧盟 AI 法案**,对个人数据的使用方式施加了进一步的限制。
|
||||||
|
|
||||||
此外,即使在不直接受法规约束的领域,人们也越来越认识到计算机系统对人和社会的影响。社交媒体改变了个人消费新闻的方式,这影响了他们的政治观点,因此可能影响选举结果。自动化系统越来越多地做出对个人产生深远影响的决策,例如决定谁应该获得贷款或保险覆盖,谁应该被邀请参加工作面试,或者谁应该被怀疑犯罪 [^60]。
|
此外,即使在不直接受法规约束的领域,人们也越来越认识到计算机系统对人和社会的影响。社交媒体改变了个人消费新闻的方式,这影响了他们的政治观点,因此可能影响选举结果。自动化系统越来越多地做出对个人产生深远影响的决策,例如决定谁应该获得贷款或保险覆盖,谁应该被邀请参加工作面试,或者谁应该被怀疑犯罪 [^60]。
|
||||||
|
|
||||||
@ -404,33 +400,33 @@ ETL(参见["数据仓库"](/ch1#sec_introduction_dwh))只是故事的一部
|
|||||||
|
|
||||||
法律考虑正在影响数据系统设计的基础 [^61]。例如,GDPR 授予个人在请求时删除其数据的权利(有时称为 **被遗忘权**)。然而,正如我们将在本书中看到的,许多数据系统依赖不可变构造(如仅追加日志)作为其设计的一部分;我们如何确保删除应该不可变的文件中间的某些数据?我们如何处理已被纳入派生数据集(参见["权威数据源与派生数据"](/ch1#sec_introduction_derived))的数据删除,例如机器学习模型的训练数据?回答这些问题会带来新的工程挑战。
|
法律考虑正在影响数据系统设计的基础 [^61]。例如,GDPR 授予个人在请求时删除其数据的权利(有时称为 **被遗忘权**)。然而,正如我们将在本书中看到的,许多数据系统依赖不可变构造(如仅追加日志)作为其设计的一部分;我们如何确保删除应该不可变的文件中间的某些数据?我们如何处理已被纳入派生数据集(参见["权威数据源与派生数据"](/ch1#sec_introduction_derived))的数据删除,例如机器学习模型的训练数据?回答这些问题会带来新的工程挑战。
|
||||||
|
|
||||||
目前,我们对于哪些特定技术或系统架构应被视为"符合 GDPR"没有明确的指导方针。法规故意不强制要求特定技术,因为随着技术的进步,这些技术可能会迅速变化。相反,法律文本规定了需要解释的高级原则。这意味着如何遵守隐私法规的问题没有简单的答案,但我们将通过这个视角来看待本书中的一些技术。
|
目前,我们对于哪些特定技术或系统架构应被视为“符合 GDPR”没有明确的指导方针。法规故意不强制要求特定技术,因为随着技术的进步,这些技术可能会迅速变化。相反,法律文本规定了需要解释的高层级原则。这意味着如何遵守隐私法规的问题没有简单的答案,但我们将通过这个视角来看待本书中的一些技术。
|
||||||
|
|
||||||
一般来说,我们存储数据是因为我们认为其价值大于存储它的成本。然而,值得记住的是,存储成本不仅仅是你为 Amazon S3 或其他服务支付的账单:成本效益计算还应该考虑到如果数据被泄露或被对手入侵的责任和声誉损害风险,以及如果数据的存储和处理被发现不符合法律的法律成本和罚款风险 [^51]。
|
一般来说,我们存储数据是因为我们认为其价值大于存储它的成本。然而,值得记住的是,存储成本不仅仅是你为 Amazon S3 或其他服务支付的账单:成本效益计算还应该考虑到如果数据被泄露或被对手入侵的责任和声誉损害风险,以及如果数据的存储和处理被发现不符合法律的法律成本和罚款风险 [^51]。
|
||||||
|
|
||||||
政府或警察部队也可能迫使公司交出数据。当存在数据可能暴露犯罪行为的风险时(例如,在几个中东和非洲国家的同性恋,或在几个美国州寻求堕胎),存储该数据会为用户创造真正的安全风险。例如,去堕胎诊所的旅行很容易被位置数据揭示,甚至可能通过用户 IP 地址随时间的日志(表示大致位置)。
|
政府或警察部队也可能迫使公司交出数据。当存在数据可能暴露犯罪行为的风险时(例如,在几个中东和非洲国家的同性恋,或在几个美国州寻求堕胎),存储该数据会为用户创造真正的安全风险。例如,去堕胎诊所的旅行很容易被位置数据揭示,甚至可能通过用户 IP 地址随时间的日志(表示大致位置)。
|
||||||
|
|
||||||
一旦考虑到所有风险,可能合理地决定某些数据根本不值得存储,因此应该删除。这个 **数据最小化** 原则(有时以德语术语 **Datensparsamkeit** 为人所知)与"大数据"哲学相反,后者是投机性地存储大量数据,以防将来有用 [^62]。但它符合 GDPR,该法规要求个人数据只能为指定的、明确的目的收集,这些数据以后不得用于任何其他目的,并且数据不得保留超过收集目的所需的时间 [^63]。
|
一旦考虑到所有风险,可能合理地决定某些数据根本不值得存储,因此应该删除。这个 **数据最小化** 原则(有时以德语术语 **Datensparsamkeit** 为人所知)与“大数据”哲学相反,后者是投机性地存储大量数据,以防将来有用 [^62]。但它符合 GDPR,该法规要求个人数据只能为指定的、明确的目的收集,这些数据以后不得用于任何其他目的,并且数据不得保留超过收集目的所需的时间 [^63]。
|
||||||
|
|
||||||
企业也注意到了隐私和安全问题。信用卡公司要求支付处理企业遵守严格的支付卡行业(PCI)标准。处理商经常接受独立审计师的评估,以验证持续的合规性。软件供应商也受到了更多的审查。现在许多买家要求他们的供应商遵守服务组织控制(SOC)类型 2 标准。与 PCI 合规性一样,供应商接受第三方审计以验证遵守情况。
|
企业也注意到了隐私和安全问题。信用卡公司要求处理支付的企业遵守严格的支付卡行业(PCI)标准。处理商需要经常接受独立审计师的评估,以验证持续的合规性。软件供应商也受到了更多的审查。现在许多买家要求他们的供应商遵守服务组织控制(SOC)类型 2 标准。与 PCI 合规性一样,供应商需要接受第三方审计以验证遵守情况。
|
||||||
|
|
||||||
一般来说,重要的是平衡你的业务需求与你收集和处理其数据的人的需求。这个话题还有很多内容;在[待补充链接]中,我们将更深入地探讨道德和法律合规性的主题,包括偏见和歧视的问题。
|
一般来说,重要的是平衡你的业务需求与你收集和处理其数据的人的需求。这个话题还有很多内容;在[待补充链接]中,我们将更深入地探讨道德和法律合规性的主题,包括偏见和歧视的问题。
|
||||||
|
|
||||||
|
|
||||||
## 总结 {#summary}
|
## 总结 {#summary}
|
||||||
|
|
||||||
本章的主题是理解权衡:也就是说,认识到对于许多问题,没有一个正确的答案,而是有几种不同的方法,每种方法都有各种利弊。我们探讨了影响数据系统架构的一些最重要的选择,并介绍了本书其余部分所需的术语。
|
本章的主题是理解权衡:也就是说要认识到对于许多问题并没有一个正确的答案,而是有几种不同的方法,每种方法都有各种利弊。我们探讨了影响数据系统架构的一些最重要的选择,并介绍了本书其余部分所需的术语。
|
||||||
|
|
||||||
我们首先区分了事务型(事务处理,OLTP)和分析型(OLAP)系统,并看到了它们的不同特征:不仅管理不同类型的数据和不同的访问模式,而且服务于不同的受众。我们遇到了数据仓库和数据湖的概念,它们通过 ETL 从事务型系统接收数据馈送。在[第 4 章](/ch4#ch_storage)中,我们将看到事务型和分析型系统通常使用非常不同的内部数据布局,因为它们需要服务的查询类型不同。
|
我们首先区分了事务型(事务处理,OLTP)和分析型(OLAP)系统,并看到了它们的不同特征:不仅通过不同的访问模式管理不同类型的数据,而且服务于不同的受众。我们遇到了数据仓库和数据湖的概念,它们通过 ETL 从事务型系统接收数据。在[第 4 章](/ch4#ch_storage)中,我们将看到事务型和分析型系统通常使用非常不同的内部数据布局,因为它们需要服务的查询类型不同。
|
||||||
|
|
||||||
然后,我们将云服务(一个相对较新的发展)与传统的自托管软件范式进行了比较,后者以前主导了数据系统架构。这些方法中哪一种更具成本效益在很大程度上取决于你的特定情况,但不可否认的是,云原生方法正在为数据系统的架构带来重大变化,例如它们分离存储和计算的方式。
|
然后,我们将云服务(一个相对较新的发展)与传统的自托管软件范式进行了比较,后者以前主导了数据系统架构。这些方法中哪一种更具成本效益在很大程度上取决于你的特定情况,但不可否认的是,云原生方法正在为数据系统的架构带来重大变化,例如它们分离存储和计算的方式。
|
||||||
|
|
||||||
云系统本质上是分布式的,我们简要地研究了分布式系统与使用单台机器相比的一些权衡。有些情况下你无法避免分布式,但如果可能在单台机器上保持系统,建议不要急于使系统分布式。在[第 9 章](/ch9#ch_distributed)中,我们将更详细地介绍分布式系统的挑战。
|
云系统本质上是分布式的,我们简要地研究了分布式系统与使用单台机器相比的一些权衡。有些情况下你无法避免分布式,但如果可能在单台机器上运行系统,建议不要急于使系统分布式。在[第 9 章](/ch9#ch_distributed)中,我们将更详细地介绍分布式系统的挑战。
|
||||||
|
|
||||||
最后,我们看到数据系统架构不仅由部署系统的企业的需求决定,还由保护数据被处理的人的权利的隐私法规决定——这是许多工程师容易忽视的一个方面。我们如何将法律要求转化为技术实现还不太了解,但在我们阅读本书的其余部分时,记住这个问题很重要。
|
最后,我们看到数据系统架构不仅由部署系统的企业的需求决定,还由保护其数据被处理的人的权利的隐私法规决定——这是许多工程师容易忽视的一个方面。我们如何将法律要求转化为技术实现还没有非常清晰的答案,但在我们阅读本书的其余部分时,记住这个问题很重要。
|
||||||
|
|
||||||
### 参考
|
### 参考
|
||||||
|
|
||||||
|
|
||||||
[^1]: Richard T. Kouzes, Gordon A. Anderson, Stephen T. Elbert, Ian Gorton, and Deborah K. Gracio. [The Changing Paradigm of Data-Intensive Computing](http://www2.ic.uff.br/~boeres/slides_AP/papers/TheChanginParadigmDataIntensiveComputing_2009.pdf). *IEEE Computer*, volume 42, issue 1, January 2009. [doi:10.1109/MC.2009.26](https://doi.org/10.1109/MC.2009.26)
|
[^1]: Richard T. Kouzes, Gordon A. Anderson, Stephen T. Elbert, Ian Gorton, and Deborah K. Gracio. [The Changing Paradigm of Data-Intensive Computing](http://www2.ic.uff.br/~boeres/slides_AP/papers/TheChanginParadigmDataIntensiveComputing_2009.pdf). *IEEE Computer*, volume 42, issue 1, January 2009. [doi:10.1109/MC.2009.26](https://doi.org/10.1109/MC.2009.26)
|
||||||
[^2]: Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. [Local-first software: you own your data, in spite of the cloud](https://www.inkandswitch.com/local-first/). At *2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software* (Onward!), October 2019. [doi:10.1145/3359591.3359737](https://doi.org/10.1145/3359591.3359737)
|
[^2]: Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. [Local-first software: you own your data, in spite of the cloud](https://www.inkandswitch.com/local-first/). At *2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software* (Onward!), October 2019. [doi:10.1145/3359591.3359737](https://doi.org/10.1145/3359591.3359737)
|
||||||
[^3]: Joe Reis and Matt Housley. [*Fundamentals of Data Engineering*](https://www.oreilly.com/library/view/fundamentals-of-data/9781098108298/). O’Reilly Media, 2022. ISBN: 9781098108304
|
[^3]: Joe Reis and Matt Housley. [*Fundamentals of Data Engineering*](https://www.oreilly.com/library/view/fundamentals-of-data/9781098108298/). O’Reilly Media, 2022. ISBN: 9781098108304
|
||||||
|
Loading…
Reference in New Issue
Block a user