update zh-tw content

content/tw/ch1.md

@@ -36,7 +36,7 @@ breadcrumbs: false
 
 我們將透過觀察當今組織中資料的一些典型使用方式來開始我們的旅程。這裡的許多想法起源於 **企業軟體**（即大型組織的軟體需求和工程實踐，大型組織包括大公司和政府等），因為歷史上只有大型組織擁有需要複雜技術解決方案的大資料量。如果你的資料量足夠小，你可以簡單地將其儲存在電子表格中！然而，最近小公司和初創公司管理大資料量並構建資料密集型系統也變得很常見。
 
-資料系統的關鍵挑戰之一是不同的人需要用資料做非常不同的事情。如果你在一家公司工作，你和你的團隊將有一套優先事項，而另一個團隊可能有完全不同的目標，即使你們可能在處理相同的資料集！此外，這些目標可能沒有明確闡述，這可能導致對正確方法的誤解和分歧。
+資料系統的關鍵挑戰之一是不同的人需要用資料做非常不同的事情。如果你在一家公司工作，你和你的團隊將有一套優先事項，而另一個團隊可能有完全不同的目標，即使你們可能在處理相同的資料集！此外，這些目標可能沒有被明確闡述，這可能導致對正確方法的誤解和分歧。
 
 為了幫助你瞭解可以做出哪些選擇，本章比較了幾個對比概念，並探討了它們的權衡：
 
@@ -49,14 +49,14 @@ breadcrumbs: false
 
 > [!TIP] 術語：前端和後端
 
-本書中我們將討論的大部分內容都與 **後端開發** 有關。為了解釋這個術語：對於 Web 應用程式，在 Web 瀏覽器中執行的客戶端程式碼稱為 **前端**，處理使用者請求的伺服器端程式碼稱為 **後端**。移動應用類似於前端，它們提供使用者介面，通常透過網際網路與伺服器端後端通訊。前端有時在使用者裝置上本地管理資料 [^2]，但最大的資料基礎設施挑戰通常在於後端：前端只需要處理一個使用者的資料，而後端代表 **所有** 使用者管理資料。
+本書中我們將討論的大部分內容都與 **後端開發** 有關。為了解釋這個術語：對於 Web 應用程式，在 Web 瀏覽器中執行的客戶端程式碼稱為 **前端**，處理使用者請求的伺服器端程式碼稱為 **後端**。移動應用類似於前端，它們提供使用者介面，通常透過網際網路與伺服器端後端通訊。前端有時在使用者裝置上本地管理資料 [^2]，但最大的資料基礎設施挑戰通常在於後端：前端只需要處理一個使用者的資料，而後端為 **所有** 使用者管理資料。
 
-後端服務通常可透過 HTTP（有時是 WebSocket）訪問；它通常由一些應用程式程式碼組成，這些程式碼在一個或多個數據庫中讀取和寫入資料，有時還與其他資料系統（如快取或訊息佇列）介面（我們可能將其統稱為 **資料基礎設施**）。應用程式程式碼通常是 **無狀態的**（即，當它完成處理一個 HTTP 請求時，它會忘記關於該請求的所有內容），任何需要從一個請求持續到另一個請求的資訊都需要儲存在客戶端或伺服器端的資料基礎設施中。
+後端服務通常可透過 HTTP（有時是 WebSocket）訪問；它通常由一些應用程式程式碼組成，這些程式碼在一個或多個數據庫中讀取和寫入資料，有時還與其他資料系統（如快取或訊息佇列）互動（我們可能將其統稱為 **資料基礎設施**）。應用程式程式碼通常是 **無狀態的**（即，當它完成處理一個 HTTP 請求時，它會忘記關於該請求的所有內容），任何需要從一個請求持續到另一個請求的資訊都需要儲存在客戶端或伺服器端的資料基礎設施中。
 
 
 ## 分析型與事務型系統 {#sec_introduction_analytics}
 
-如果你在企業中從事資料系統工作，你可能會遇到幾種不同型別的資料工作者。第一類是 **後端工程師**，他們構建服務來處理讀取和更新資料的請求；這些服務通常直接或間接地透過其他服務為外部使用者提供服務（參見["微服務與 Serverless"](/tw/ch1#sec_introduction_microservices)）。有時服務是供組織其他部分內部使用的。
+如果你在企業中從事資料系統工作，你可能會遇到幾種不同型別的資料工作者。第一類是 **後端工程師**，他們構建服務來處理讀取和更新資料的請求；這些服務通常直接或間接地透過其他服務為外部使用者提供服務（參見["微服務與 Serverless"](/tw/ch1#sec_introduction_microservices)）。有時服務是供組織其他部門內部使用的。
 
 除了管理後端服務的團隊外，通常還有兩類人需要訪問組織的資料：**業務分析師**，他們生成關於組織活動的報告，以幫助管理層做出更好的決策（**商業智慧** 或 **BI**）；以及 **資料科學家**，他們在資料中尋找新的見解，或建立由資料分析和機器學習（AI）支援的面向使用者的產品功能（例如，電子商務網站上的“購買了 X 的人也購買了 Y”推薦、風險評分或垃圾郵件過濾等預測分析，以及搜尋結果排名）。
 
@@ -76,7 +76,7 @@ breadcrumbs: false
 > [!NOTE]
 > [第 8 章](/tw/ch8#ch_transactions) 詳細探討了我們所說的事務的含義。本章鬆散地使用該術語來指代低延遲的讀取和寫入。
 
-儘管資料庫開始用於許多不同型別的資料——社交媒體上的帖子、遊戲中的移動、地址簿中的聯絡人等等——基本的訪問模式仍然類似於處理商業交易。事務型系統通常透過某個鍵查詢少量記錄（這稱為 **點查詢**）。基於使用者的輸入插入、更新或刪除記錄。因為這些應用程式是互動式的，這種訪問模式被稱為 **聯機事務處理**（OLTP）。
+儘管資料庫開始用於許多不同型別的資料——社交媒體上的帖子、遊戲中的移動、地址簿中的聯絡人等等——但是基本的訪問模式仍然類似於處理商業交易。事務型系統通常透過某個鍵查詢少量記錄（這稱為 **點查詢**）。基於使用者的輸入插入、更新或刪除記錄。因為這些應用程式是互動式的，這種訪問模式被稱為 **聯機事務處理**（OLTP）。
 
 然而，資料庫也越來越多地用於分析，與 OLTP 相比，分析具有非常不同的訪問模式。通常，分析查詢會掃描大量記錄，並計算聚合統計資訊（如計數、求和或平均值），而不是將單個記錄返回給使用者。例如，連鎖超市的業務分析師可能想要回答以下分析查詢：
 
@@ -153,7 +153,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
 
 #### 超越資料湖 {#beyond-the-data-lake}
 
-隨著分析實踐的成熟，組織越來越關注分析系統和資料管道的管理和運維，例如 DataOps 宣言所捕獲的 [^18]。其中一部分是治理、隱私和遵守 GDPR 和 CCPA 等法規的問題，我們將在["資料系統、法律與社會"](/tw/ch1#sec_introduction_compliance)和[待補充連結]中討論。
+隨著分析實踐的成熟，組織越來越關注分析系統和資料管道的管理和運維，如在 DataOps 宣言中所描述的那樣 [^18]。其中一部分是治理、隱私和遵守 GDPR 和 CCPA 等法規的問題，我們將在["資料系統、法律與社會"](/tw/ch1#sec_introduction_compliance)和[待補充連結]中討論。
 
 此外，分析資料越來越多地不僅作為檔案和關係表提供，還作為事件流（參見[待補充連結]）。使用基於檔案的資料分析，你可以定期（例如，每天）重新執行分析以響應資料的變化，但流處理允許分析系統以秒級的速度響應事件。根據應用程式及其時間敏感性，流處理方法可能很有價值，例如識別和阻止潛在的欺詐或濫用活動。
 
@@ -362,7 +362,7 @@ ETL（參見["資料倉庫"](/tw/ch1#sec_introduction_dwh)）只是故事的一
 
 在多臺機器上分佈系統的最常見方式是將它們分為客戶端和伺服器，並讓客戶端向伺服器發出請求。最常見的是使用 HTTP 進行此通訊，正如我們將在["流經服務的資料流：REST 和 RPC"](/tw/ch5#sec_encoding_dataflow_rpc)中討論的。同一程序可能既是伺服器（處理傳入請求）又是客戶端（向其他服務發出出站請求）。
 
-這種構建應用程式的方式傳統上被稱為 **面向服務架構**（SOA）；最近，這個想法已經被細化為 **微服務** 架構 [^52] [^53]。在這種架構中，服務有一個明確定義的目的（例如，在 S3 的情況下，這將是檔案儲存）；每個服務公開一個可以由客戶端透過網路呼叫的 API，每個服務有一個負責其維護的團隊。因此，複雜的應用程式可以分解為多個互動服務，每個服務由單獨的團隊管理。
+這種構建應用程式的方式傳統上被稱為 **面向服務架構**（SOA）；最近，這個想法已經被細化為 **微服務** 架構 [^52] [^53]。在這種架構中，服務有一個明確定義的目的（例如，對於 S3 來說，這個目的是檔案儲存）；每個服務公開一個可以由客戶端透過網路呼叫的 API，每個服務有一個負責其維護的團隊。因此，複雜的應用程式可以分解為多個互動服務，每個服務由單獨的團隊管理。
 
 將複雜的軟體分解為多個服務有幾個優點：每個服務可以獨立更新，減少團隊之間的協調工作；每個服務可以分配它需要的硬體資源；透過將實現細節隱藏在 API 後面，服務所有者可以自由地更改實現而不影響客戶端。在資料儲存方面，每個服務通常有自己的資料庫，而不在服務之間共享資料庫：共享資料庫實際上會使整個資料庫結構成為服務 API 的一部分，然後該結構將很難更改。共享資料庫還可能導致一個服務的查詢對其他服務的效能產生負面影響。
 
@@ -381,7 +381,7 @@ ETL（參見["資料倉庫"](/tw/ch1#sec_introduction_dwh)）只是故事的一
 雲計算不是構建大規模計算系統的唯一方式；另一種選擇是 **高效能計算**（HPC），也稱為 **超級計算**。儘管有重疊，但與雲計算和企業資料中心繫統相比，HPC 通常有不同的設計考量並使用不同的技術。其中一些差異是：
 
 * 超級計算機通常用於計算密集型科學計算任務，例如天氣預報、氣候建模、分子動力學（模擬原子和分子的運動）、複雜的最佳化問題和求解偏微分方程。另一方面，雲計算往往用於線上服務、業務資料系統和需要以高可用性為使用者請求提供服務的類似系統。
-* 超級計算機通常執行大型批處理作業，定期將其計算狀態檢查點到磁碟。如果節點發生故障，常見的解決方案是簡單地停止整個叢集工作負載，修復故障節點，然後從最後一個檢查點重新啟動計算 [^55] [^56]。對於雲服務，通常不希望停止整個叢集，因為服務需要以最小的中斷持續為使用者提供服務。
+* 超級計算機通常執行大型批處理作業，定期將其計算狀態檢查點儲存到磁碟。如果節點發生故障，常見的解決方案是簡單地停止整個叢集工作負載，修復故障節點，然後從最後一個檢查點重新啟動計算 [^55] [^56]。對於雲服務，通常不希望停止整個叢集，因為服務需要以最小的中斷持續為使用者提供服務。
 * 超級計算機節點通常透過共享記憶體和遠端直接記憶體訪問（RDMA）進行通訊，這支援高頻寬和低延遲，但假設系統使用者之間有高度的信任 [^57]。在雲計算中，網路和機器通常由相互不信任的組織共享，需要更強的安全機制，如資源隔離（例如虛擬機器）、加密和身份驗證。
 * 雲資料中心網路通常基於 IP 和乙太網，以 Clos 拓撲排列以提供高對分頻寬——這是網路整體效能的常用度量 [^55] [^58]。超級計算機通常使用專門的網路拓撲，例如多維網格和環面 [^59]，這能讓具有已知通訊模式的 HPC 工作負載產生更好的效能。
 * 雲計算允許節點分佈在多個地理區域，而超級計算機通常假設它們的所有節點都靠近在一起。
@@ -404,7 +404,7 @@ ETL（參見["資料倉庫"](/tw/ch1#sec_introduction_dwh)）只是故事的一
 
 一般來說，我們儲存資料是因為我們認為其價值大於儲存它的成本。然而，值得記住的是，儲存成本不僅僅是你為 Amazon S3 或其他服務支付的賬單：成本效益計算還應該考慮到如果資料被洩露或被對手入侵的責任和聲譽損害風險，以及如果資料的儲存和處理被發現不符合法律的法律成本和罰款風險 [^51]。
 
-政府或警察部隊也可能迫使公司交出資料。當存在資料可能暴露犯罪行為的風險時（例如，在幾個中東和非洲國家的同性戀，或在幾個美國州尋求墮胎），儲存該資料會為使用者創造真正的安全風險。例如，去墮胎診所的旅行很容易被位置資料揭示，甚至可能透過使用者 IP 地址隨時間的日誌（表示大致位置）。
+政府或警察部隊也可能迫使公司交出資料。當存在資料可能暴露犯罪行為的風險時（例如，在幾個中東和非洲國家的同性戀，或在幾個美國州尋求墮胎），儲存該資料會為使用者創造真正的安全風險。例如，去墮胎診所的行程很容易被位置資料洩露，甚至可能透過使用者 IP 地址隨時間的日誌（表示大致位置）洩露。
 
 一旦考慮到所有風險，可能合理地決定某些資料根本不值得儲存，因此應該刪除。這個 **資料最小化** 原則（有時以德語術語 **Datensparsamkeit** 為人所知）與“大資料”哲學相反，後者是投機性地儲存大量資料，以防將來有用 [^62]。但它符合 GDPR，該法規要求個人資料只能為指定的、明確的目的收集，這些資料以後不得用於任何其他目的，並且資料不得保留超過收集目的所需的時間 [^63]。
 
@@ -421,7 +421,7 @@ ETL（參見["資料倉庫"](/tw/ch1#sec_introduction_dwh)）只是故事的一
 
 然後，我們將雲服務（一個相對較新的發展）與傳統的自託管軟體正規化進行了比較，後者以前主導了資料系統架構。這些方法中哪一種更具成本效益在很大程度上取決於你的特定情況，但不可否認的是，雲原生方法正在為資料系統的架構帶來重大變化，例如它們分離儲存和計算的方式。
 
-雲系統本質上是分散式的，我們簡要地研究了分散式系統與使用單臺機器相比的一些權衡。有些情況下你無法避免分散式，但如果可能在單臺機器上執行系統，建議不要急於使系統分散式。在[第 9 章](/tw/ch9#ch_distributed)中，我們將更詳細地介紹分散式系統的挑戰。
+雲系統本質上是分散式的，我們簡要地研究了分散式系統與使用單臺機器相比的一些權衡。有些情況下你無法避免分散式，但如果可能在單臺機器上執行系統，建議不要急於使系統分散式化。在[第 9 章](/tw/ch9#ch_distributed)中，我們將更詳細地介紹分散式系統的挑戰。
 
 最後，我們看到資料系統架構不僅由部署系統的企業的需求決定，還由保護其資料被處理的人的權利的隱私法規決定——這是許多工程師容易忽視的一個方面。我們如何將法律要求轉化為技術實現還沒有非常清晰的答案，但在我們閱讀本書的其餘部分時，記住這個問題很重要。
 

content/zh/ch1.md

@@ -362,7 +362,7 @@ ETL（参见["数据仓库"](/ch1#sec_introduction_dwh)）只是故事的一部
 
 在多台机器上分布系统的最常见方式是将它们分为客户端和服务器，并让客户端向服务器发出请求。最常见的是使用 HTTP 进行此通信，正如我们将在["流经服务的数据流：REST 和 RPC"](/ch5#sec_encoding_dataflow_rpc)中讨论的。同一进程可能既是服务器（处理传入请求）又是客户端（向其他服务发出出站请求）。
 
-这种构建应用程序的方式传统上被称为 **面向服务架构**（SOA）；最近，这个想法已经被细化为 **微服务** 架构 [^52] [^53]。在这种架构中，服务有一个明确定义的目的（例如，对于S3来说，这个目的是文件存储）；每个服务公开一个可以由客户端通过网络调用的 API，每个服务有一个负责其维护的团队。因此，复杂的应用程序可以分解为多个交互服务，每个服务由单独的团队管理。
+这种构建应用程序的方式传统上被称为 **面向服务架构**（SOA）；最近，这个想法已经被细化为 **微服务** 架构 [^52] [^53]。在这种架构中，服务有一个明确定义的目的（例如，对于 S3 来说，这个目的是文件存储）；每个服务公开一个可以由客户端通过网络调用的 API，每个服务有一个负责其维护的团队。因此，复杂的应用程序可以分解为多个交互服务，每个服务由单独的团队管理。
 
 将复杂的软件分解为多个服务有几个优点：每个服务可以独立更新，减少团队之间的协调工作；每个服务可以分配它需要的硬件资源；通过将实现细节隐藏在 API 后面，服务所有者可以自由地更改实现而不影响客户端。在数据存储方面，每个服务通常有自己的数据库，而不在服务之间共享数据库：共享数据库实际上会使整个数据库结构成为服务 API 的一部分，然后该结构将很难更改。共享数据库还可能导致一个服务的查询对其他服务的性能产生负面影响。