update zh-tw.py and zh-tw content

Author: yingang

bin/zh-tw.py

@@ -49,6 +49,10 @@ def convert_file(src_filepath, dst_filepath, src_folder, dst_folder, cfg='s2twp.
                     .replace('線上性一致', '在線性一致')    # 优先按"在线"解析了？
                     .replace('復雜', '複雜')
                     .replace('討論瞭', '討論了')
+                    .replace('瞭解釋', '了解釋')
+                    .replace('瞭如', '了如')                # 引入了如, 實現了如, 了如何, 了如果, 了如此
+                    .replace('了如指掌', '瞭如指掌')        # 针对上一行的例外情况
+                    .replace('明瞭', '明了')                # 闡明了, 聲明了, 指明了
                     .replace('倒黴', '倒楣')
                     .replace('區域性性', '區域性')
                     .replace('下麵條件', '下面條件')        # 优先按"面条"解析了？

content/tw/ch1.md

@@ -120,34 +120,34 @@ breadcrumbs: false
 
 相比之下，**資料倉庫** 是一個單獨的資料庫，分析師可以隨心所欲地查詢，而不會影響 OLTP 操作 [^7]。正如我們將在[第 4 章](/tw/ch4#ch_storage)中看到的，資料倉庫通常以與 OLTP 資料庫非常不同的方式儲存資料，以最佳化分析中常見的查詢型別。
 
-資料倉庫包含公司中所有各種 OLTP 系統中資料的只讀副本。資料從 OLTP 資料庫中提取（使用定期資料轉儲或連續更新流），轉換為分析友好的模式，清理，然後載入到資料倉庫中。這種將資料匯入資料倉庫的過程稱為 **提取-轉換-載入**（ETL），如[圖 1-1](/tw/ch1#fig_dwh_etl) 所示。有時 **轉換** 和 **載入** 步驟的順序會互換（即，在載入後在資料倉庫中進行轉換），從而產生 **ELT**。
+資料倉庫包含公司中所有各種 OLTP 系統中資料的只讀副本。資料從 OLTP 資料庫中提取（使用定期資料轉儲或連續更新流），轉換為分析友好的模式，進行清理，然後載入到資料倉庫中。這種將資料匯入資料倉庫的過程稱為 **提取-轉換-載入**（ETL），如[圖 1-1](/tw/ch1#fig_dwh_etl) 所示。有時 **轉換** 和 **載入** 步驟的順序會互換（即，先載入，再在資料倉庫中進行轉換），從而產生 **ELT**。
 
 {{< figure src="/fig/ddia_0101.png" id="fig_dwh_etl" caption="圖 1-1. ETL 到資料倉庫的簡化概述。" class="w-full my-4" >}}
 
 在某些情況下，ETL 過程的資料來源是外部 SaaS 產品，如客戶關係管理（CRM）、電子郵件營銷或信用卡處理系統。在這些情況下，你無法直接訪問原始資料庫，因為它只能透過軟體供應商的 API 訪問。將這些外部系統的資料匯入你自己的資料倉庫可以實現透過 SaaS API 無法實現的分析。SaaS API 的 ETL 通常由專門的資料聯結器服務（如 Fivetran、Singer 或 AirByte）實現。
 
-一些資料庫系統提供 **混合事務/分析處理**（HTAP），旨在在單個系統中啟用 OLTP 和分析，而無需從一個系統 ETL 到另一個系統 [^8] [^9]。然而，許多 HTAP 系統內部由一個 OLTP 系統與一個單獨的分析系統耦合組成，隱藏在公共介面後面——因此兩者之間的區別對於理解這些系統如何工作仍然很重要。
+一些資料庫系統提供 **混合事務/分析處理**（HTAP），目標是在單個系統中同時支援 OLTP 和分析，而無需從一個系統 ETL 到另一個系統 [^8] [^9]。然而，許多 HTAP 系統內部由一個 OLTP 系統與一個單獨的分析系統耦合組成，隱藏在公共介面後面——因此兩者之間的區別對於理解這些系統如何工作仍然很重要。
 
-此外，儘管 HTAP 存在，但由於目標和要求不同，事務型系統和分析型系統之間的分離是常見的。特別是，每個事務型系統擁有自己的資料庫被認為是良好的做法（參見["微服務與 Serverless"](/tw/ch1#sec_introduction_microservices)），導致數百個單獨的事務型資料庫；另一方面，企業通常有一個單一的資料倉庫，以便業務分析師可以在單個查詢中組合來自多個事務型系統的資料。
+此外，儘管 HTAP 存在，但由於目標和要求不同，事務型系統和分析型系統之間的分離是常見的。特別是，讓每個事務型系統擁有自己的資料庫被認為是良好的做法（參見["微服務與 Serverless"](/tw/ch1#sec_introduction_microservices)），這將導致數百個單獨的事務型資料庫；另一方面，企業通常有一個單一的資料倉庫，以便業務分析師可以在單個查詢中組合來自多個事務型系統的資料。
 
-因此，HTAP 不會取代資料倉庫。相反，它在同一應用程式需要既執行掃描大量行的分析查詢，又以低延遲讀取和更新單個記錄的場景中很有用。例如，欺詐檢測可能涉及此類工作負載 [^10]。
+因此，HTAP 不會取代資料倉庫。相反，它在同一應用程式既需要執行掃描大量行的分析查詢，又需要以低延遲讀取和更新單個記錄的場景中很有用。例如，欺詐檢測可能涉及此類工作負載 [^10]。
 
 事務型系統和分析型系統之間的分離是更廣泛趨勢的一部分：隨著工作負載變得更加苛刻，系統變得更加專業化並針對特定工作負載進行最佳化。通用系統可以舒適地處理小資料量，但規模越大，系統往往變得越專業化 [^11]。
 
 #### 從資料倉庫到資料湖 {#from-data-warehouse-to-data-lake}
 
-資料倉庫通常使用透過 SQL 查詢的 **關係** 資料模型（參見[第 3 章](/tw/ch3#ch_datamodels)），可能使用專門的商業智慧軟體。這個模型很適合業務分析師需要進行的查詢型別，但不太適合資料科學家的需求，他們可能需要執行以下任務：
+資料倉庫通常使用透過 SQL 進行查詢的 **關係** 資料模型（參見[第 3 章](/tw/ch3#ch_datamodels)），可能使用專門的商業智慧軟體。這個模型很適合業務分析師需要進行的查詢型別，但不太適合資料科學家的需求，他們可能需要執行以下任務：
 
 * 將資料轉換為適合訓練機器學習模型的形式；這通常需要將資料庫表的行和列轉換為稱為 **特徵** 的數值向量或矩陣。以最大化訓練模型效能的方式執行這種轉換的過程稱為 **特徵工程**，它通常需要難以用 SQL 表達的自定義程式碼。
 * 獲取文字資料（例如，產品評論）並使用自然語言處理技術嘗試從中提取結構化資訊（例如，作者的情感或他們提到的主題）。同樣，他們可能需要使用計算機視覺技術從照片中提取結構化資訊。
 
-儘管已經努力將機器學習運算元新增到 SQL 資料模型 [^12] 並在關係基礎上構建高效的機器學習系統 [^13]，但許多資料科學家不喜歡在資料倉庫等關係資料庫中工作。相反，許多人更喜歡使用 Python 資料分析庫（如 pandas 和 scikit-learn）、統計分析語言（如 R）和分散式分析框架（如 Spark）[^14]。我們將在["資料框、矩陣和陣列"](/tw/ch3#sec_datamodels_dataframes)中進一步討論這些。
+儘管已經有人在努力將機器學習運算元新增到 SQL 資料模型 [^12] 並在關係基礎上構建高效的機器學習系統 [^13]，但許多資料科學家不喜歡在資料倉庫等關係資料庫中工作。相反，許多人更喜歡使用 Python 資料分析庫（如 pandas 和 scikit-learn）、統計分析語言（如 R）和分散式分析框架（如 Spark）[^14]。我們將在["資料框、矩陣和陣列"](/tw/ch3#sec_datamodels_dataframes)中進一步討論這些。
 
 因此，組織面臨著以適合資料科學家使用的形式提供資料的需求。答案是 **資料湖**：一個集中的資料儲存庫，儲存任何可能對分析有用的資料副本，透過 ETL 過程從事務型系統獲得。與資料倉庫的區別在於，資料湖只是包含檔案，而不強制任何特定的檔案格式或資料模型。資料湖中的檔案可能是資料庫記錄的集合，使用 Avro 或 Parquet 等檔案格式編碼（參見[第 5 章](/tw/ch5#ch_encoding)），但它們同樣可以包含文字、影像、影片、感測器讀數、稀疏矩陣、特徵向量、基因組序列或任何其他型別的資料 [^15]。除了更靈活之外，這通常也比關係資料儲存更便宜，因為資料湖可以使用商品化的檔案儲存，如物件儲存（參見["雲原生系統架構"](/tw/ch1#sec_introduction_cloud_native)）。
 
-ETL 過程已經泛化為 **資料管道**，在某些情況下，資料湖已成為從事務型系統到資料倉庫路徑上的中間站。資料湖包含事務型系統產生的"原始"形式的資料，沒有轉換為關係資料倉庫模式。這種方法的優勢在於，每個資料消費者都可以將原始資料轉換為最適合其需求的形式。它被稱為 **壽司原則**："原始資料更好"[^16]。
+ETL 過程已經泛化為 **資料管道**，在某些情況下，資料湖已成為從事務型系統到資料倉庫路徑上的中間站。資料湖包含事務型系統產生的“原始”形式的資料，沒有轉換為關係資料倉庫模式。這種方法的優勢在於，每個資料消費者都可以將原始資料轉換為最適合其需求的形式。它被稱為 **壽司原則**：“原始資料更好”[^16]。
 
-除了從資料湖載入資料到單獨的資料倉庫之外，還可以直接在資料湖中的檔案上執行典型的資料倉庫工作負載（SQL 查詢和業務分析），以及資料科學/機器學習工作負載。這種架構被稱為 **資料湖倉**，它需要一個查詢執行引擎和一個元資料（例如，模式管理）層來擴充套件資料湖的檔案儲存 [^17]。
+除了從資料湖載入資料到單獨的資料倉庫之外，還可以直接在資料湖中的檔案上執行典型的資料倉庫工作負載（SQL 查詢和業務分析），以及資料科學和機器學習的工作負載。這種架構被稱為 **資料湖倉**，它需要一個查詢執行引擎和一個元資料（例如，模式管理）層來擴充套件資料湖的檔案儲存 [^17]。
 
 Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
 
@@ -157,7 +157,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。
 
 此外，分析資料越來越多地不僅作為檔案和關係表提供，還作為事件流（參見[待補充連結]）。使用基於檔案的資料分析，你可以定期（例如，每天）重新執行分析以響應資料的變化，但流處理允許分析系統以秒級的速度響應事件。根據應用程式及其時間敏感性，流處理方法可能很有價值，例如識別和阻止潛在的欺詐或濫用活動。
 
-在某些情況下，分析系統的輸出被提供給事務型系統（這個過程有時被稱為 **反向 ETL** [^19]）。例如，在分析系統中訓練的機器學習模型可能會部署到生產環境中，以便為終端使用者生成推薦，例如"購買了 X 的人也購買了 Y"。這種分析系統的部署輸出也被稱為 **資料產品** [^20]。機器學習模型可以使用 TFX、Kubeflow 或 MLflow 等專門工具部署到事務型系統。
+在某些情況下，分析系統的輸出被提供給事務型系統（這個過程有時被稱為 **反向 ETL** [^19]）。例如，在分析系統中訓練的機器學習模型可能會部署到生產環境中，以便為終端使用者生成推薦，例如“購買了 X 的人也購買了 Y”。這種分析系統的部署輸出也被稱為 **資料產品** [^20]。機器學習模型可以使用 TFX、Kubeflow 或 MLflow 等專門工具部署到事務型系統。
 
 ### 權威資料來源與派生資料 {#sec_introduction_derived}
 

content/tw/ch8.md

@@ -163,7 +163,7 @@ SELECT COUNT(*) FROM emails WHERE recipient_id = 2 AND unread_flag = true
 當單個物件被更改時，原子性和隔離性也適用。例如，假設你正在向資料庫寫入 20 KB 的 JSON 文件：
 
 * 如果在傳送了前 10 KB 後網路連線中斷，資料庫是否儲存了無法解析的 10 KB JSON 片段？
-* 如果資料庫正在覆蓋磁碟上的先前值的過程中電源失敗，你是否最終會將新舊值拼接在一起？
+* 如果資料庫正在覆蓋磁碟上的先前值的過程中電源失效，你是否最終會將新舊值拼接在一起？
 * 如果另一個客戶端在寫入過程中讀取該文件，它會看到部分更新的值嗎？
 
 這些問題會令人非常困惑，因此儲存引擎幾乎普遍的目標是在一個節點上的單個物件（如鍵值對）上提供原子性和隔離性。原子性可以使用日誌實現崩潰恢復（參見["使 B 樹可靠"](/tw/ch4#sec_storage_btree_wal)），隔離性可以使用每個物件上的鎖來實現（一次只允許一個執行緒訪問物件）。

content/v1/ch2.md

@@ -920,7 +920,7 @@ Cypher 和 SPARQL 使用 SELECT 立即跳转，但是 Datalog 一次只进行一
 
 文档数据库和图数据库有一个共同点，那就是它们通常不会将存储的数据强制约束为特定模式，这可以使应用程序更容易适应不断变化的需求。但是应用程序很可能仍会假定数据具有一定的结构；区别仅在于模式是**明确的**（写入时强制）还是**隐含的**（读取时处理）。
 
-每个数据模型都具有各自的查询语言或框架，我们讨论了几个例子：SQL，MapReduce，MongoDB 的聚合管道，Cypher，SPARQL 和 Datalog。我们也谈到了 CSS 和 XSL/XPath，它们不是数据库查询语言，而包含有趣的相似之处。
+每个数据模型都具有各自的查询语言或框架，我们讨论了几个例子：SQL、MapReduce、MongoDB 的聚合管道、Cypher、SPARQL 和 Datalog。我们也谈到了 CSS 和 XSL/XPath，它们不是数据库查询语言，而包含有趣的相似之处。
 
 虽然我们已经覆盖了很多层面，但仍然有许多数据模型没有提到。举几个简单的例子：
 

content/v1_tw/ch2.md

@@ -920,7 +920,7 @@ Cypher 和 SPARQL 使用 SELECT 立即跳轉，但是 Datalog 一次只進行一
 
 文件資料庫和圖資料庫有一個共同點，那就是它們通常不會將儲存的資料強制約束為特定模式，這可以使應用程式更容易適應不斷變化的需求。但是應用程式很可能仍會假定資料具有一定的結構；區別僅在於模式是**明確的**（寫入時強制）還是**隱含的**（讀取時處理）。
 
-每個資料模型都具有各自的查詢語言或框架，我們討論了幾個例子：SQL，MapReduce，MongoDB 的聚合管道，Cypher，SPARQL 和 Datalog。我們也談到了 CSS 和 XSL/XPath，它們不是資料庫查詢語言，而包含有趣的相似之處。
+每個資料模型都具有各自的查詢語言或框架，我們討論了幾個例子：SQL、MapReduce、MongoDB 的聚合管道、Cypher、SPARQL 和 Datalog。我們也談到了 CSS 和 XSL/XPath，它們不是資料庫查詢語言，而包含有趣的相似之處。
 
 雖然我們已經覆蓋了很多層面，但仍然有許多資料模型沒有提到。舉幾個簡單的例子：