update translations of ch1

Author: yingang

content/tw/ch1.md

@@ -30,11 +30,11 @@ breadcrumbs: false
 
 在構建應用程式時，我們通常會採用幾個軟體系統或服務，例如資料庫或 API，並用一些應用程式程式碼將它們粘合在一起。如果你正在做資料系統設計的工作，那麼這個過程可能會相當容易。
 
-然而，隨著你的應用程式變得更加雄心勃勃，挑戰就會出現。有許多具有不同特性的資料庫系統，適合不同的目的——你如何選擇使用哪一個？有各種快取方法、構建搜尋索引的幾種方式等等——你如何推理它們的權衡？你需要找出哪些工具和哪些方法最適合手頭的任務，當你需要做單個工具無法單獨完成的事情時，組合工具可能會很困難。
+然而，隨著你的應用程式變得更加雄心勃勃，挑戰就會出現。有許多具有不同特性的資料庫系統，適合不同的目的——你如何選擇使用哪一個？有各種快取方法、構建搜尋索引的幾種方式等等——你如何在它們之間進行權衡？你需要找出哪些工具和哪些方法最適合手頭的任務，當你需要做單個工具無法單獨完成的事情時，組合工具可能會很困難。
 
 本書是一個指南，幫助你決定使用哪些技術以及如何組合它們。正如你將看到的，沒有一種方法從根本上優於其他方法；一切都有利弊。透過本書，你將學會提出正確的問題來評估和比較資料系統，以便你能找出哪種方法最能滿足你特定應用程式的需求。
 
-我們將透過觀察當今組織中資料的一些典型使用方式來開始我們的旅程。這裡的許多想法起源於 **企業軟體**（即大型組織（如大公司和政府）的軟體需求和工程實踐），因為歷史上只有大型組織擁有需要複雜技術解決方案的大資料量。如果你的資料量足夠小，你可以簡單地將其儲存在電子表格中！然而，最近小公司和初創公司管理大資料量並構建資料密集型系統也變得很常見。
+我們將透過觀察當今組織中資料的一些典型使用方式來開始我們的旅程。這裡的許多想法起源於 **企業軟體**（即大型組織的軟體需求和工程實踐，大型組織包括大公司和政府等），因為歷史上只有大型組織擁有需要複雜技術解決方案的大資料量。如果你的資料量足夠小，你可以簡單地將其儲存在電子表格中！然而，最近小公司和初創公司管理大資料量並構建資料密集型系統也變得很常見。
 
 資料系統的關鍵挑戰之一是不同的人需要用資料做非常不同的事情。如果你在一家公司工作，你和你的團隊將有一套優先事項，而另一個團隊可能有完全不同的目標，即使你們可能在處理相同的資料集！此外，這些目標可能沒有明確闡述，這可能導致對正確方法的誤解和分歧。
 
@@ -51,14 +51,14 @@ breadcrumbs: false
 
 本書中我們將討論的大部分內容都與 **後端開發** 有關。為了解釋這個術語：對於 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"推薦、風險評分或垃圾郵件過濾等預測分析，以及搜尋結果排名）。
+除了管理後端服務的團隊外，通常還有兩類人需要訪問組織的資料：**業務分析師**，他們生成關於組織活動的報告，以幫助管理層做出更好的決策（**商業智慧** 或 **BI**）；以及 **資料科學家**，他們在資料中尋找新的見解，或建立由資料分析和機器學習（AI）支援的面向使用者的產品功能（例如，電子商務網站上的“購買了 X 的人也購買了 Y”推薦、風險評分或垃圾郵件過濾等預測分析，以及搜尋結果排名）。
 
 儘管業務分析師和資料科學家傾向於使用不同的工具並以不同的方式操作，但他們有一些共同點：兩者都執行 **分析**，這意味著他們檢視使用者和後端服務生成的資料，但他們通常不修改這些資料（除了可能修復錯誤）。他們可能建立派生資料集，其中原始資料已經以某種方式處理過。這導致了兩種型別系統之間的分離——我們將在本書中使用這種區別：
 
@@ -67,56 +67,56 @@ breadcrumbs: false
 
 正如我們將在下一節中看到的，事務型系統和分析型系統通常出於充分的理由而保持分離。隨著這些系統的成熟，出現了兩個新的專業角色：**資料工程師** 和 **分析工程師**。資料工程師是知道如何整合事務型系統和分析型系統的人，並更廣泛地負責組織的資料基礎設施 [^3]。分析工程師對資料進行建模和轉換，使其對組織中的業務分析師和資料科學家更有用 [^4]。
 
-許多工程師專注於事務型或分析型方面。然而，本書涵蓋了事務型和分析型資料系統，因為兩者在組織內資料生命週期中都扮演著重要角色。我們將深入探討用於向內部和外部使用者提供服務的資料基礎設施，以便你能更好地與這一分界線另一邊的同事合作。
+許多工程師專注於事務型系統和分析型系統中的一個。然而，本書涵蓋了事務型和分析型資料系統，因為兩者在組織內資料的生命週期中都扮演著重要角色。我們將深入探討用於向內部和外部使用者提供服務的資料基礎設施，以便你能更好地與分界線另一邊的同事合作。
 
 ### 事務處理與分析的特徵 {#sec_introduction_oltp}
 
-在商業資料處理的早期，對資料庫的寫入通常對應於發生的 **商業交易**：進行銷售、向供應商下訂單、支付員工工資等。隨著資料庫擴充套件到不涉及金錢交換的領域，**事務** 這個術語仍然保留了下來，指的是形成邏輯單元的一組讀取和寫入。
+在商業資料處理的早期，對資料庫的寫入通常對應於發生的 **商業交易（commercial transaction）**：進行銷售、向供應商下訂單、支付員工工資等。隨著資料庫擴充套件到不涉及金錢交換的領域，**事務（transaction）** 這個術語仍然保留了下來，指的是形成邏輯單元的一組讀取和寫入。
 
 > [!NOTE]
 > [第 8 章](/tw/ch8#ch_transactions) 詳細探討了我們所說的事務的含義。本章鬆散地使用該術語來指代低延遲的讀取和寫入。
 
 儘管資料庫開始用於許多不同型別的資料——社交媒體上的帖子、遊戲中的移動、地址簿中的聯絡人等等——基本的訪問模式仍然類似於處理商業交易。事務型系統通常透過某個鍵查詢少量記錄（這稱為 **點查詢**）。基於使用者的輸入插入、更新或刪除記錄。因為這些應用程式是互動式的，這種訪問模式被稱為 **聯機事務處理**（OLTP）。
 
-然而，資料庫也越來越多地用於分析，與 OLTP 相比，分析具有非常不同的訪問模式。通常，分析查詢會掃描大量記錄，並計算聚合統計資訊（如計數、求和或平均值），而不是將單個記錄返回給使用者。例如，超市連鎖店的業務分析師可能想要回答以下分析查詢：
+然而，資料庫也越來越多地用於分析，與 OLTP 相比，分析具有非常不同的訪問模式。通常，分析查詢會掃描大量記錄，並計算聚合統計資訊（如計數、求和或平均值），而不是將單個記錄返回給使用者。例如，連鎖超市的業務分析師可能想要回答以下分析查詢：
 
 * 我們每家商店在一月份的總收入是多少？
-* 在我們最近的促銷期間，我們賣出了比平時多多少香蕉？
+* 在我們最近的促銷期間，我們比平時多賣出了多少香蕉？
 * 哪個品牌的嬰兒食品最常與 X 品牌尿布一起購買？
 
-這些型別查詢產生的報告對商業智慧很重要，幫助管理層決定下一步做什麼。為了將這種使用資料庫的模式與事務處理區分開來，它被稱為 **聯機分析處理**（OLAP）[^5]。OLTP 和分析之間的區別並不總是很明確，但[表 1-1](/tw/ch1#tab_oltp_vs_olap) 列出了一些典型特徵。
+這些型別的查詢產生的報告對商業智慧很重要，可以幫助管理層決定下一步做什麼。為了將這種使用資料庫的模式與事務處理區分開來，它被稱為 **聯機分析處理**（OLAP）[^5]。OLTP 和分析之間的區別並不總是很明確，但[表 1-1](/tw/ch1#tab_oltp_vs_olap) 列出了一些典型特徵。
 
 {{< figure id="tab_oltp_vs_olap" title="表 1-1. 事務型系統和分析型系統特徵比較" class="w-full my-4" >}}
 
 | 屬性            | 事務型系統（OLTP）                      | 分析型系統（OLAP）                 |
 |-----------------|----------------------------------------|-----------------------------------|
 | 主要讀取模式    | 點查詢（透過鍵獲取單個記錄）            | 對大量記錄進行聚合                 |
 | 主要寫入模式    | 建立、更新和刪除單個記錄                | 批次匯入（ETL）或事件流            |
-| 人類使用者示例    | Web/移動應用程式的終端使用者              | 內部分析師，用於決策支援           |
+| 人類使用者示例    | Web 或移動應用程式的終端使用者              | 內部分析師，用於決策支援           |
 | 機器使用示例    | 檢查操作是否被授權                      | 檢測欺詐/濫用模式                  |
 | 查詢型別        | 固定的查詢集，由應用程式預定義          | 分析師可以進行任意查詢             |
 | 資料代表        | 資料的最新狀態（當前時間點）            | 隨時間發生的事件歷史               |
 | 資料集大小      | GB 到 TB                                | TB 到 PB                           |
 
 > [!NOTE]
-> OLAP 中 **online** 的含義不明確；它可能指的是查詢不僅用於預定義的報告，而且分析師可以互動式地使用 OLAP 系統進行探索性查詢。
+> OLAP 中 **聯機（online）** 的含義不明確；它可能指的是查詢不僅用於預定義的報告，也可能是指分析師互動式地使用 OLAP 系統來進行探索性查詢。
 
-在事務型系統中，通常不允許使用者構建自定義 SQL 查詢並在資料庫上執行它們，因為這可能會允許他們讀取或修改他們沒有許可權訪問的資料。此外，他們可能編寫執行成本高昂的查詢，從而影響其他使用者的資料庫效能。出於這些原因，OLTP 系統主要執行嵌入到應用程式程式碼中的固定查詢集，只偶爾使用一次性自定義查詢進行維護或故障排除。另一方面，分析資料庫通常讓使用者可以自由地手動編寫任意 SQL 查詢，或使用 Tableau、Looker 或 Microsoft Power BI 等資料視覺化或儀表板工具自動生成查詢。
+在事務型系統中，通常不允許使用者構建自定義 SQL 查詢並在資料庫上執行它們，因為這可能會允許他們讀取或修改他們沒有許可權訪問的資料。此外，他們可能編寫執行成本高昂的查詢，從而影響其他使用者的資料庫效能。出於這些原因，OLTP 系統主要執行嵌入到應用程式程式碼中的固定查詢集，只偶爾使用一次性的自定義查詢來進行維護或故障排除。另一方面，分析資料庫通常讓使用者可以自由地手動編寫任意 SQL 查詢，或使用 Tableau、Looker 或 Microsoft Power BI 等資料視覺化或儀表板工具自動生成查詢。
 
-還有一種型別的系統是為分析工作負載（對許多記錄進行聚合的查詢）設計的，但嵌入到面向使用者的產品中。這一類別被稱為 **產品分析** 或 **即時分析**，為這種用途設計的系統包括 Pinot、Druid 和 ClickHouse [^6]。
+還有一種型別的系統是為分析型的工作負載（對許多記錄進行聚合的查詢）設計的，但嵌入到面向使用者的產品中。這一類別被稱為 **產品分析** 或 **即時分析**，為這種用途設計的系統包括 Pinot、Druid 和 ClickHouse [^6]。
 
 ### 資料倉庫 {#sec_introduction_dwh}
 
-起初，相同的資料庫既用於事務處理，也用於分析查詢。SQL 在這方面相當靈活：它對兩種型別的查詢都很有效。然而，在 20 世紀 80 年代末和 90 年代初，公司傾向於停止使用其 OLTP 系統進行分析目的，而是在單獨的資料庫系統上執行分析。這個單獨的資料庫被稱為 **資料倉庫**。
+起初，相同的資料庫既用於事務處理，也用於分析查詢。SQL 在這方面相當靈活：它對兩種型別的查詢都很有效。然而，在 20 世紀 80 年代末和 90 年代初，企業有停止使用其 OLTP 系統進行分析目的的趨勢，轉而在單獨的資料庫系統上執行分析。這個單獨的資料庫被稱為 **資料倉庫**。
 
-一家大型企業可能有幾十個，甚至上百個聯機事務處理系統：為面向客戶的網站提供動力的系統、控制實體店中的銷售點（收銀臺）系統、跟蹤倉庫中的庫存、規劃車輛路線、管理供應商、管理員工以及執行許多其他任務。這些系統中的每一個都很複雜，需要一個團隊來維護它，因此這些系統最終主要是相互獨立地執行。
+一家大型企業可能有幾十個甚至上百個聯機事務處理系統：為面向客戶的網站提供動力的系統、控制實體店中的銷售點（收銀臺）系統、跟蹤倉庫中的庫存、規劃車輛路線、管理供應商、管理員工以及執行許多其他任務。這些系統中的每一個都很複雜，需要一個團隊來維護它，因此這些系統最終主要是相互獨立地執行。
 
 出於幾個原因，業務分析師和資料科學家直接查詢這些 OLTP 系統通常是不可取的：
 
 * 感興趣的資料可能分佈在多個事務型系統中，使得在單個查詢中組合這些資料集變得困難（稱為 **資料孤島** 的問題）；
 * 適合 OLTP 的模式和資料佈局不太適合分析（參見["星型和雪花型：分析模式"](/tw/ch3#sec_datamodels_analytics)）；
 * 分析查詢可能相當昂貴，在 OLTP 資料庫上執行它們會影響其他使用者的效能；以及
-* OLTP 系統可能位於使用者出於安全或合規原因不允許直接訪問的單獨網路中。
+* 出於安全或合規原因，OLTP 系統可能位於不允許使用者直接訪問的單獨網路中。
 
 相比之下，**資料倉庫** 是一個單獨的資料庫，分析師可以隨心所欲地查詢，而不會影響 OLTP 操作 [^7]。正如我們將在[第 4 章](/tw/ch4#ch_storage)中看到的，資料倉庫通常以與 OLTP 資料庫非常不同的方式儲存資料，以最佳化分析中常見的查詢型別。