add v1 images

Author: Vonng

README.md

@@ -1,6 +1,8 @@
 # 设计数据密集型应用（第二版） - 中文翻译版
 
-[![Webite: ddia](https://img.shields.io/badge/在线阅读-ddia.vonng.com-slategray?style=flat)](https://ddia.vonng.com)
+[![Webite: ddia](https://img.shields.io/badge/简体中文-第二版-slategray?style=flat)](https://ddia.vonng.com)
+[![Webite: ddia](https://img.shields.io/badge/简体中文-第一版-slategray?style=flat)](https://ddia.vonng.com/v1)
+[![Webite: ddia](https://img.shields.io/badge/繁体中文-第二版-slategray?style=flat)](https://ddia.vonng.com/tw)
 [![GitHub Stars](https://img.shields.io/github/stars/Vonng/ddia?style=flat&logo=github&logoColor=black&color=slategray)](https://star-history.com/#Vonng/ddia&Date)
 
 **作者**： [Martin Kleppmann](https://martin.kleppmann.com)，[《Designing Data-Intensive Applications 2nd Edition》](https://learning.oreilly.com/library/view/designing-data-intensive-applications/9781098119058/ch01.html)： 英国剑桥大学分布式系统研究员，演讲者，博主和开源贡献者，软件工程师和企业家，曾在 LinkedIn 和 Rapportive 负责数据基础架构。
@@ -11,7 +13,7 @@
 
 **阅读**：访问 [https://ddia.vonng.com](https://ddia.vonng.com) 阅读本书在线版本，或使用 [hugo](https://gohugo.io/documentation/) / [hextra](https://imfing.github.io/hextra/zh-cn/) 主题自行构建。
 
-**通知**：DDIA [**第二版**](https://ddia2.vonng.com) 正在翻译中 ([`v2`](https://github.com/Vonng/ddia/tree/v2) 分支)，欢迎加入并提出您的宝贵意见！
+**通知**：DDIA [**第二版**](https://ddia.vonng.com) 正在翻译中 ([`v2`](https://github.com/Vonng/ddia/tree/v2) 分支)，欢迎加入并提出您的宝贵意见！[点击此处阅览第一版](https://ddia.vonng.com/v1)。
 
 
 ---------

content/en/part-ii.md

@@ -91,7 +91,7 @@ Replication can also help improve performance. We discuss replication in [Chapte
 
 These are separate mechanisms, but they often go hand in hand, as illustrated in [Figure II-1](#fig_replication_partitioning).
 
-{{< figure src="/fig/ddia_08.png" id="fig_replication_partitioning" caption="*Figure II-1. A database split into two partitions, with two replicas per partition." class="w-full my-4" >}}
+{{< figure src="/v1/ddia_08.png" id="fig_replication_partitioning" caption="*Figure II-1. A database split into two partitions, with two replicas per partition." class="w-full my-4" >}}
 
 With an understanding of those concepts, we can discuss the difficult trade-offs that you need to make in a distributed system. 
 We’ll discuss *transactions* in [Chapter 8](/en/ch8), as that will help you understand all the many things that can go wrong in a data system, and what you can do about them. 

content/tw/_index.md

@@ -19,7 +19,7 @@ PostgreSQL 專家，資料庫老司機，雲計算泥石流。
 **校訂**： [@yingang](https://github.com/yingang)  ｜  [繁體中文](/tw) **版本維護** by  [@afunTW](https://github.com/afunTW) ｜ [完整貢獻者列表](/contrib)
 
 > [!NOTE]
-> **DDIA 第二版** 正在翻譯中 ([`v2`](https://github.com/Vonng/ddia/tree/v2) 分支)，歡迎加入並提出您的寶貴意見！
+> **DDIA 第二版** 正在翻譯中 ([`main`](https://github.com/Vonng/ddia/tree/main) 分支)，歡迎加入並提出您的寶貴意見！[點選此處閱覽第一版](/v1)。
 
 
 

content/tw/ch11.md

@@ -2,6 +2,7 @@
 title: "第十一章：批處理"
 linkTitle: "11. 批處理"
 weight: 311
+math: true
 breadcrumbs: false
 ---
 
@@ -240,11 +241,11 @@ MapReduce 與 Unix 命令管道的主要區別在於，MapReduce 可以在多臺
 
 在分散式計算中可以使用標準的 Unix 工具作為 Mapper 和 Reducer【25】，但更常見的是，它們被實現為傳統程式語言的函式。在 Hadoop MapReduce 中，Mapper 和 Reducer 都是實現特定介面的 Java 類。在 MongoDB 和 CouchDB 中，Mapper 和 Reducer 都是 JavaScript 函式（請參閱 “[MapReduce 查詢](/tw/ch2#MapReduce查詢)”）。
 
-[圖 10-1](/fig/ddia_1101.png) 顯示了 Hadoop MapReduce 作業中的資料流。其並行化基於分割槽（請參閱 [第六章](/tw/ch6)）：作業的輸入通常是 HDFS 中的一個目錄，輸入目錄中的每個檔案或檔案塊都被認為是一個單獨的分割槽，可以單獨處理 map 任務（[圖 10-1](/fig/ddia_1101.png) 中的 m1，m2 和 m3 標記）。
+[圖 10-1](/v1/ddia_1001.png) 顯示了 Hadoop MapReduce 作業中的資料流。其並行化基於分割槽（請參閱 [第六章](/v1/ch6)）：作業的輸入通常是 HDFS 中的一個目錄，輸入目錄中的每個檔案或檔案塊都被認為是一個單獨的分割槽，可以單獨處理 map 任務（[圖 10-1](/v1/ddia_1001.png) 中的 m1，m2 和 m3 標記）。
 
 每個輸入檔案的大小通常是數百兆位元組。MapReduce 排程器（圖中未顯示）試圖在其中一臺儲存輸入檔案副本的機器上執行每個 Mapper，只要該機器有足夠的備用 RAM 和 CPU 資源來執行 Mapper 任務【26】。這個原則被稱為 **將計算放在資料附近**【27】：它節省了透過網路複製輸入檔案的開銷，減少網路負載並增加區域性。
 
-![](/fig/ddia_1101.png)
+![](/v1/ddia_1001.png)
 
 **圖 10-1 具有三個 Mapper 和三個 Reducer 的 MapReduce 任務**
 
@@ -292,7 +293,7 @@ Hadoop 的各種高階工具（如 Pig 【30】、Hive 【31】、Cascading 【3
 
 [圖 10-2](/fig/ddia_1102.png) 給出了一個批處理作業中連線的典型例子。左側是事件日誌，描述登入使用者在網站上做的事情（稱為 **活動事件**，即 activity events，或 **點選流資料**，即 clickstream data），右側是使用者資料庫。你可以將此示例看作是星型模式的一部分（請參閱 “[星型和雪花型：分析的模式](/tw/ch3#星型和雪花型：分析的模式)”）：事件日誌是事實表，使用者資料庫是其中的一個維度。
 
-![](/fig/ddia_1102.png)
+![](/v1/ddia_1002.png)
 
 **圖 10-2 使用者行為日誌與使用者檔案的連線**
 
@@ -306,7 +307,7 @@ Hadoop 的各種高階工具（如 Pig 【30】、Hive 【31】、Cascading 【3
 
 #### 排序合併連線
 
-回想一下，Mapper 的目的是從每個輸入記錄中提取一對鍵值。在 [圖 10-2](/fig/ddia_1102.png) 的情況下，這個鍵就是使用者 ID：一組 Mapper 會掃過活動事件（提取使用者 ID 作為鍵，活動事件作為值），而另一組 Mapper 將會掃過使用者資料庫（提取使用者 ID 作為鍵，使用者的出生日期作為值）。這個過程如 [圖 10-3](/fig/ddia_1103.png) 所示。
+回想一下，Mapper 的目的是從每個輸入記錄中提取一對鍵值。在 [圖 10-2](/v1/ddia_1002.png) 的情況下，這個鍵就是使用者 ID：一組 Mapper 會掃過活動事件（提取使用者 ID 作為鍵，活動事件作為值），而另一組 Mapper 將會掃過使用者資料庫（提取使用者 ID 作為鍵，使用者的出生日期作為值）。這個過程如 [圖 10-3](/v1/ddia_1003.png) 所示。
 
 ![](/fig/ddia_1103.png)
 
@@ -603,8 +604,7 @@ Spark、Flink 和 Tez 避免將中間狀態寫入 HDFS，因此它們採取了
 
 > 像 Spark、Flink 和 Tez 這樣的資料流引擎（請參閱 “[物化中間狀態](#物化中間狀態)”）通常將運算元作為 **有向無環圖（DAG）** 的一部分安排在作業中。這與圖處理不一樣：在資料流引擎中，**從一個運算元到另一個運算元的資料流** 被構造成一個圖，而資料本身通常由關係型元組構成。在圖處理中，資料本身具有圖的形式。又一個不幸的命名混亂！
 
-許多圖演算法是透過一次遍歷一條邊來表示的，將一個頂點與近鄰的頂點連線起來，以傳播一些資訊，並不斷重複，直到滿足一些條件為止 —— 例如，直到沒有更多的邊要跟進，或直到一些指標收斂。
-我們在 [圖 3-7](/ch3/#fig_datalog_naive) 中看到一個例子，它透過重複跟進標明地點歸屬關係的邊，生成了資料庫中北美包含的所有地點列表（這種演算法被稱為 **傳遞閉包**，即 transitive closure）。
+許多圖演算法是透過一次遍歷一條邊來表示的，將一個頂點與近鄰的頂點連線起來，以傳播一些資訊，並不斷重複，直到滿足一些條件為止 —— 例如，直到沒有更多的邊要跟進，或直到一些指標收斂。我們在 [圖 2-6](/v1/ddia_0206.png) 中看到一個例子，它透過重複跟進標明地點歸屬關係的邊，生成了資料庫中北美包含的所有地點列表（這種演算法被稱為 **傳遞閉包**，即 transitive closure）。
 
 可以在分散式檔案系統中儲存圖（包含頂點和邊的列表的檔案），但是這種 “重複至完成” 的想法不能用普通的 MapReduce 來表示，因為它只掃過一趟資料。這種演算法因此經常以 **迭代** 的風格實現：