diff --git a/bin/zh-tw.py b/bin/zh-tw.py index 46d457f..6ff0cf2 100755 --- a/bin/zh-tw.py +++ b/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('下麵條件', '下面條件') # 优先按"面条"解析了? diff --git a/content/tw/ch1.md b/content/tw/ch1.md index 5cce725..03fba66 100644 --- a/content/tw/ch1.md +++ b/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} diff --git a/content/tw/ch8.md b/content/tw/ch8.md index 6cd9ca9..ed24201 100644 --- a/content/tw/ch8.md +++ b/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)),隔離性可以使用每個物件上的鎖來實現(一次只允許一個執行緒訪問物件)。 diff --git a/content/v1/ch2.md b/content/v1/ch2.md index bdd3afd..7d36286 100644 --- a/content/v1/ch2.md +++ b/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,它们不是数据库查询语言,而包含有趣的相似之处。 虽然我们已经覆盖了很多层面,但仍然有许多数据模型没有提到。举几个简单的例子: diff --git a/content/v1_tw/ch2.md b/content/v1_tw/ch2.md index a3457c7..daecd8c 100644 --- a/content/v1_tw/ch2.md +++ b/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,它們不是資料庫查詢語言,而包含有趣的相似之處。 雖然我們已經覆蓋了很多層面,但仍然有許多資料模型沒有提到。舉幾個簡單的例子: