diff --git a/content/tw/ch1.md b/content/tw/ch1.md index b8fa772..0dfd6fa 100644 --- a/content/tw/ch1.md +++ b/content/tw/ch1.md @@ -221,7 +221,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。 在這種情況下,雲服務的優勢在於它們可以更容易地根據需求變化向上或向下擴充套件你的計算資源。 例如,分析系統通常具有極其可變的負載:快速執行大型分析查詢需要並行使用大量計算資源,但一旦查詢完成,這些資源就會處於空閒狀態,直到使用者進行下一個查詢。 -預定義的查詢(例如,每日報告)可以排隊和排程以平滑負載,但對於互動式查詢,你希望它們完成得越快,工作負載就變得越可變。 +預定義的查詢(例如,每日報告)可以排隊和排程以平滑負載,但對於互動式查詢,你越希望它們完成得快,工作負載就變得越可變。 如果你的資料集如此之大,以至於快速查詢需要大量的計算資源,使用雲可以節省資金,因為你可以將未使用的資源返回給供應商,而不是讓它們閒置。對於較小的資料集,這種差異不太顯著。 雲服務的最大缺點是你無法控制它: @@ -229,13 +229,13 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。 * 如果它缺少你需要的功能,你所能做的就是禮貌地詢問供應商是否會新增它;你通常無法自己實現它。 * 如果服務宕機,你所能做的就是等它恢復。 * 如果你以觸發錯誤或導致效能問題的方式使用服務,你將很難診斷問題。對於你自己執行的軟體,你可以從作業系統獲取效能指標和除錯資訊來幫助你理解其行為,你可以檢視伺服器日誌,但對於供應商託管的服務,你通常無法訪問這些內部資訊。 -* 此外,如果服務關閉或變得無法接受地昂貴,或者如果供應商決定以你不喜歡的方式更改他們的產品,你就受制於他們 —— 繼續執行舊版本的軟體通常不是一個可行選項,所以你將被迫遷移到替代服務 [^24]。 +* 此外,如果服務關閉或變得無法接受的昂貴,或者如果供應商決定以你不喜歡的方式更改他們的產品,你就受制於他們 —— 繼續執行舊版本的軟體通常不是一個可行選項,所以你將被迫遷移到替代服務 [^24]。 如果有暴露相容 API 的替代服務,這種風險會得到緩解,但對於許多雲服務,沒有標準 API,這增加了切換成本,使供應商鎖定成為一個問題。 * 雲供應商需要被信任以保持資料安全,這可能會使遵守隱私和安全法規的過程複雜化。 儘管有所有這些風險,組織在雲服務之上構建新應用程式或採用混合方法(在系統的某些部分使用雲服務)變得越來越流行。 然而,雲服務不會取代所有內部資料系統:許多較舊的系統早於雲,對於任何具有現有云服務無法滿足的專業要求的服務,內部系統仍然是必要的。 -例如,對延遲非常敏感的應用程式(如高頻交易)需要完全控制硬體。 +例如,對延遲非常敏感的應用程式(如高頻交易)需要對硬體的完全控制。 ### 雲原生系統架構 {#sec_introduction_cloud_native} @@ -259,13 +259,13 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。 許多自託管資料系統的系統要求非常簡單:它們在傳統作業系統(如 Linux 或 Windows)上執行,將資料儲存為檔案系統上的檔案,並透過 TCP/IP 等標準網路協議進行通訊。 少數系統依賴於特殊硬體,如 GPU(用於機器學習)或 RDMA 網路介面,但總的來說,自託管軟體傾向於使用非常通用的計算資源:CPU、RAM、檔案系統和 IP 網路。 -在雲中,這種型別的軟體可以在基礎設施即服務環境中執行,使用一個或多個虛擬機器(或 **例項**),分配一定的 CPU、記憶體、磁碟和網路頻寬。 +在雲中,這種型別的軟體可以在基礎設施即服務(IaaS)環境中執行,使用一個或多個虛擬機器(或 **例項**),分配一定的 CPU、記憶體、磁碟和網路頻寬。 與物理機器相比,雲實例可以更快地配置,並且有更多種類的大小,但除此之外,它們與傳統計算機類似:你可以在上面執行任何你喜歡的軟體,但你負責自己管理它。 相比之下,雲原生服務的關鍵思想是不僅使用由作業系統管理的計算資源,還基於較低級別的雲服務構建更高級別的服務。例如: -* **物件儲存** 服務(如 Amazon S3、Azure Blob Storage 和 Cloudflare R2)儲存大檔案。它們提供比典型檔案系統更有限的 API(基本檔案讀寫),但它們的優勢在於隱藏了底層物理機器:服務自動將資料分佈在許多機器上,因此你不必擔心任何一臺機器上的磁碟空間用完。即使某些機器或其磁碟完全故障,也不會丟失資料。 -* 許多其他服務反過來建立在物件儲存和其他雲服務之上:例如,Snowflake 是一個基於雲的分析資料庫(資料倉庫),依賴於 S3 進行資料儲存 [^27],而一些其他服務反過來建立在 Snowflake 之上。 +* 使用 **物件儲存** 服務(如 Amazon S3、Azure Blob Storage 和 Cloudflare R2)儲存大檔案。它們提供比典型檔案系統更有限的 API(基本檔案讀寫),但它們的優勢在於隱藏了底層物理機器:服務自動將資料分佈在許多機器上,因此你不必擔心任何一臺機器上的磁碟空間用完。即使某些機器或其磁碟完全故障,也不會丟失資料。 +* 在物件儲存和其他雲服務之上建立更多的服務:例如,Snowflake 是一個基於雲的分析資料庫(資料倉庫),依賴於 S3 進行資料儲存 [^27],而一些其他服務反過來建立在 Snowflake 之上。 與計算中的抽象一樣,沒有一個正確的答案告訴你應該使用什麼。作為一般規則,更高級別的抽象往往更面向特定的用例。如果你的需求與為其設計更高級別系統的情況相匹配,使用現有的高級別系統可能會比自己從較低級別系統構建更輕鬆,且更能滿足您的需求。另一方面,如果沒有滿足你需求的高階系統,那麼從較低級別的元件自己構建它是唯一的選擇。 @@ -275,15 +275,15 @@ Apache Hive、Spark SQL、Presto 和 Trino 是這種方法的例子。 在雲中,計算例項(虛擬機器)也可能有本地磁碟連線,但云原生系統通常將這些磁碟更多地視為臨時快取,而不是長期儲存。這是因為如果關聯的例項出現故障,或者為了適應負載變化而將例項替換為更大或更小的例項(在不同的物理機器上),本地磁碟就會變得不可訪問。 -作為本地磁碟的替代方案,雲服務還提供可以從一個例項分離並附加到另一個例項的虛擬磁碟儲存(Amazon EBS、Azure 託管磁碟和 Google Cloud 中的持久磁碟)。這種虛擬磁碟實際上不是物理磁碟,而是由一組單獨的機器提供的雲服務,它模擬磁碟的行為(**塊裝置**,其中每個塊通常為 4 KiB 大小)。這項技術使得在雲中執行傳統的基於磁碟的軟體成為可能,但塊裝置模擬引入了在從頭為雲設計的系統中可以避免的開銷 [^25]。它還使應用程式對網路故障非常敏感,因為虛擬塊裝置上的每個 I/O 實際上都是網路呼叫 [^28]。 +作為本地磁碟的替代方案,雲服務還提供可以從一個例項分離並附加到另一個例項的虛擬磁碟儲存(Amazon EBS、Azure 託管磁碟和 Google Cloud 中的持久磁碟)。這種虛擬磁碟實際上不是物理磁碟,而是由一組單獨的機器提供的雲服務,它模擬磁碟的行為(**塊裝置**,其中每個塊通常為 4 KiB 大小)。這項技術使得在雲中執行傳統的基於磁碟的軟體成為可能,但塊裝置模擬所引入的開銷在一開始就為雲設計的系統中是可以避免的 [^25]。它還使應用程式對網路故障非常敏感,因為虛擬塊裝置上的每個 I/O 實際上都是網路呼叫 [^28]。 -為了解決這個問題,雲原生服務通常避免使用虛擬磁碟,而是建立在針對特定工作負載最佳化的專用儲存服務之上。物件儲存服務(如 S3)設計用於長期儲存相當大的檔案,大小從數百千位元組到幾千兆位元組不等。資料庫中儲存的單個行或值通常比這小得多;因此,雲資料庫通常在單獨的服務中管理較小的值,並將較大的資料塊(包含許多單個值)儲存在物件儲存中 [^26] [^29]。我們將在[第 4 章](/tw/ch4#ch_storage)中看到這樣做的方法。 +為了解決這個問題,雲原生服務通常避免使用虛擬磁碟,而是建立在針對特定工作負載最佳化的專用儲存服務之上。物件儲存服務(如 S3)設計用於長期儲存相當大的檔案,大小從數百 KB 到幾 GB 不等。資料庫中儲存的單個行或值通常比這小得多;因此,雲資料庫通常在單獨的服務中管理較小的值,並將較大的資料塊(包含許多單個值)儲存在物件儲存中 [^26] [^29]。我們將在[第 4 章](/tw/ch4#ch_storage)中看到這樣做的方法。 在傳統的系統架構中,同一臺計算機負責儲存(磁碟)和計算(CPU 和 RAM),但在雲原生系統中,這兩個職責已經在某種程度上分離或 **解耦** [^9] [^27] [^30] [^31]:例如,S3 只儲存檔案,如果你想分析該資料,你必須在 S3 之外的某個地方執行分析程式碼。這意味著透過網路傳輸資料,我們將在["分散式與單節點系統"](/tw/ch1#sec_introduction_distributed)中進一步討論。 此外,雲原生系統通常是 **多租戶** 的,這意味著不是每個客戶都有一臺單獨的機器,而是來自幾個不同客戶的資料和計算由同一服務在同一共享硬體上處理 [^32]。 -多租戶可以實現更好的硬體利用率、更容易的可伸縮性和雲提供商更容易的管理,但它也需要仔細的工程設計,以確保一個客戶的活動不會影響其他客戶的系統性能或安全性 [^33]。 +多租戶可以實現更好的硬體利用率、更容易的可伸縮性和雲提供商更容易的管理,但它也需要仔細的工程設計,以確保一個客戶的活動不會影響其他客戶的系統的效能或安全性 [^33]。 ### 雲時代的運維 {#sec_introduction_operations} diff --git a/content/zh/ch1.md b/content/zh/ch1.md index ce92dcc..baca8ea 100644 --- a/content/zh/ch1.md +++ b/content/zh/ch1.md @@ -221,7 +221,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。 在这种情况下,云服务的优势在于它们可以更容易地根据需求变化向上或向下扩展你的计算资源。 例如,分析系统通常具有极其可变的负载:快速运行大型分析查询需要并行使用大量计算资源,但一旦查询完成,这些资源就会处于空闲状态,直到用户进行下一个查询。 -预定义的查询(例如,每日报告)可以排队和调度以平滑负载,但对于交互式查询,你希望它们完成得越快,工作负载就变得越可变。 +预定义的查询(例如,每日报告)可以排队和调度以平滑负载,但对于交互式查询,你越希望它们完成得快,工作负载就变得越可变。 如果你的数据集如此之大,以至于快速查询需要大量的计算资源,使用云可以节省资金,因为你可以将未使用的资源返回给供应商,而不是让它们闲置。对于较小的数据集,这种差异不太显著。 云服务的最大缺点是你无法控制它: @@ -229,13 +229,13 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。 * 如果它缺少你需要的功能,你所能做的就是礼貌地询问供应商是否会添加它;你通常无法自己实现它。 * 如果服务宕机,你所能做的就是等它恢复。 * 如果你以触发错误或导致性能问题的方式使用服务,你将很难诊断问题。对于你自己运行的软件,你可以从操作系统获取性能指标和调试信息来帮助你理解其行为,你可以查看服务器日志,但对于供应商托管的服务,你通常无法访问这些内部信息。 -* 此外,如果服务关闭或变得无法接受地昂贵,或者如果供应商决定以你不喜欢的方式更改他们的产品,你就受制于他们 —— 继续运行旧版本的软件通常不是一个可行选项,所以你将被迫迁移到替代服务 [^24]。 +* 此外,如果服务关闭或变得无法接受的昂贵,或者如果供应商决定以你不喜欢的方式更改他们的产品,你就受制于他们 —— 继续运行旧版本的软件通常不是一个可行选项,所以你将被迫迁移到替代服务 [^24]。 如果有暴露兼容 API 的替代服务,这种风险会得到缓解,但对于许多云服务,没有标准 API,这增加了切换成本,使供应商锁定成为一个问题。 * 云供应商需要被信任以保持数据安全,这可能会使遵守隐私和安全法规的过程复杂化。 尽管有所有这些风险,组织在云服务之上构建新应用程序或采用混合方法(在系统的某些部分使用云服务)变得越来越流行。 然而,云服务不会取代所有内部数据系统:许多较旧的系统早于云,对于任何具有现有云服务无法满足的专业要求的服务,内部系统仍然是必要的。 -例如,对延迟非常敏感的应用程序(如高频交易)需要完全控制硬件。 +例如,对延迟非常敏感的应用程序(如高频交易)需要对硬件的完全控制。 ### 云原生系统架构 {#sec_introduction_cloud_native} @@ -259,13 +259,13 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。 许多自托管数据系统的系统要求非常简单:它们在传统操作系统(如 Linux 或 Windows)上运行,将数据存储为文件系统上的文件,并通过 TCP/IP 等标准网络协议进行通信。 少数系统依赖于特殊硬件,如 GPU(用于机器学习)或 RDMA 网络接口,但总的来说,自托管软件倾向于使用非常通用的计算资源:CPU、RAM、文件系统和 IP 网络。 -在云中,这种类型的软件可以在基础设施即服务环境中运行,使用一个或多个虚拟机(或 **实例**),分配一定的 CPU、内存、磁盘和网络带宽。 +在云中,这种类型的软件可以在基础设施即服务(IaaS)环境中运行,使用一个或多个虚拟机(或 **实例**),分配一定的 CPU、内存、磁盘和网络带宽。 与物理机器相比,云实例可以更快地配置,并且有更多种类的大小,但除此之外,它们与传统计算机类似:你可以在上面运行任何你喜欢的软件,但你负责自己管理它。 相比之下,云原生服务的关键思想是不仅使用由操作系统管理的计算资源,还基于较低级别的云服务构建更高级别的服务。例如: -* **对象存储** 服务(如 Amazon S3、Azure Blob Storage 和 Cloudflare R2)存储大文件。它们提供比典型文件系统更有限的 API(基本文件读写),但它们的优势在于隐藏了底层物理机器:服务自动将数据分布在许多机器上,因此你不必担心任何一台机器上的磁盘空间用完。即使某些机器或其磁盘完全故障,也不会丢失数据。 -* 许多其他服务反过来建立在对象存储和其他云服务之上:例如,Snowflake 是一个基于云的分析数据库(数据仓库),依赖于 S3 进行数据存储 [^27],而一些其他服务反过来建立在 Snowflake 之上。 +* 使用 **对象存储** 服务(如 Amazon S3、Azure Blob Storage 和 Cloudflare R2)存储大文件。它们提供比典型文件系统更有限的 API(基本文件读写),但它们的优势在于隐藏了底层物理机器:服务自动将数据分布在许多机器上,因此你不必担心任何一台机器上的磁盘空间用完。即使某些机器或其磁盘完全故障,也不会丢失数据。 +* 在对象存储和其他云服务之上建立更多的服务:例如,Snowflake 是一个基于云的分析数据库(数据仓库),依赖于 S3 进行数据存储 [^27],而一些其他服务反过来建立在 Snowflake 之上。 与计算中的抽象一样,没有一个正确的答案告诉你应该使用什么。作为一般规则,更高级别的抽象往往更面向特定的用例。如果你的需求与为其设计更高级别系统的情况相匹配,使用现有的高级别系统可能会比自己从较低级别系统构建更轻松,且更能满足您的需求。另一方面,如果没有满足你需求的高级系统,那么从较低级别的组件自己构建它是唯一的选择。 @@ -275,15 +275,15 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。 在云中,计算实例(虚拟机)也可能有本地磁盘连接,但云原生系统通常将这些磁盘更多地视为临时缓存,而不是长期存储。这是因为如果关联的实例出现故障,或者为了适应负载变化而将实例替换为更大或更小的实例(在不同的物理机器上),本地磁盘就会变得不可访问。 -作为本地磁盘的替代方案,云服务还提供可以从一个实例分离并附加到另一个实例的虚拟磁盘存储(Amazon EBS、Azure 托管磁盘和 Google Cloud 中的持久磁盘)。这种虚拟磁盘实际上不是物理磁盘,而是由一组单独的机器提供的云服务,它模拟磁盘的行为(**块设备**,其中每个块通常为 4 KiB 大小)。这项技术使得在云中运行传统的基于磁盘的软件成为可能,但块设备仿真引入了在从头为云设计的系统中可以避免的开销 [^25]。它还使应用程序对网络故障非常敏感,因为虚拟块设备上的每个 I/O 实际上都是网络调用 [^28]。 +作为本地磁盘的替代方案,云服务还提供可以从一个实例分离并附加到另一个实例的虚拟磁盘存储(Amazon EBS、Azure 托管磁盘和 Google Cloud 中的持久磁盘)。这种虚拟磁盘实际上不是物理磁盘,而是由一组单独的机器提供的云服务,它模拟磁盘的行为(**块设备**,其中每个块通常为 4 KiB 大小)。这项技术使得在云中运行传统的基于磁盘的软件成为可能,但块设备仿真所引入的开销在一开始就为云设计的系统中是可以避免的 [^25]。它还使应用程序对网络故障非常敏感,因为虚拟块设备上的每个 I/O 实际上都是网络调用 [^28]。 -为了解决这个问题,云原生服务通常避免使用虚拟磁盘,而是建立在针对特定工作负载优化的专用存储服务之上。对象存储服务(如 S3)设计用于长期存储相当大的文件,大小从数百千字节到几千兆字节不等。数据库中存储的单个行或值通常比这小得多;因此,云数据库通常在单独的服务中管理较小的值,并将较大的数据块(包含许多单个值)存储在对象存储中 [^26] [^29]。我们将在[第 4 章](/ch4#ch_storage)中看到这样做的方法。 +为了解决这个问题,云原生服务通常避免使用虚拟磁盘,而是建立在针对特定工作负载优化的专用存储服务之上。对象存储服务(如 S3)设计用于长期存储相当大的文件,大小从数百 KB 到几 GB 不等。数据库中存储的单个行或值通常比这小得多;因此,云数据库通常在单独的服务中管理较小的值,并将较大的数据块(包含许多单个值)存储在对象存储中 [^26] [^29]。我们将在[第 4 章](/ch4#ch_storage)中看到这样做的方法。 在传统的系统架构中,同一台计算机负责存储(磁盘)和计算(CPU 和 RAM),但在云原生系统中,这两个职责已经在某种程度上分离或 **解耦** [^9] [^27] [^30] [^31]:例如,S3 只存储文件,如果你想分析该数据,你必须在 S3 之外的某个地方运行分析代码。这意味着通过网络传输数据,我们将在["分布式与单节点系统"](/ch1#sec_introduction_distributed)中进一步讨论。 此外,云原生系统通常是 **多租户** 的,这意味着不是每个客户都有一台单独的机器,而是来自几个不同客户的数据和计算由同一服务在同一共享硬件上处理 [^32]。 -多租户可以实现更好的硬件利用率、更容易的可伸缩性和云提供商更容易的管理,但它也需要仔细的工程设计,以确保一个客户的活动不会影响其他客户的系统性能或安全性 [^33]。 +多租户可以实现更好的硬件利用率、更容易的可伸缩性和云提供商更容易的管理,但它也需要仔细的工程设计,以确保一个客户的活动不会影响其他客户的系统的性能或安全性 [^33]。 ### 云时代的运维 {#sec_introduction_operations}