Merge pull request #382 from uncle-lv/improve-ch1-translation

Improve ch1 translation

content/zh/ch1.md

@@ -36,7 +36,7 @@ breadcrumbs: false
 
 我们将通过观察当今组织中数据的一些典型使用方式来开始我们的旅程。这里的许多想法起源于 **企业软件**（即大型组织的软件需求和工程实践，大型组织包括大公司和政府等），因为历史上只有大型组织拥有需要复杂技术解决方案的大数据量。如果你的数据量足够小，你可以简单地将其保存在电子表格中！然而，最近小公司和初创公司管理大数据量并构建数据密集型系统也变得很常见。
 
-数据系统的关键挑战之一是不同的人需要用数据做非常不同的事情。如果你在一家公司工作，你和你的团队将有一套优先事项，而另一个团队可能有完全不同的目标，即使你们可能在处理相同的数据集！此外，这些目标可能没有明确阐述，这可能导致对正确方法的误解和分歧。
+数据系统的关键挑战之一是不同的人需要用数据做非常不同的事情。如果你在一家公司工作，你和你的团队将有一套优先事项，而另一个团队可能有完全不同的目标，即使你们可能在处理相同的数据集！此外，这些目标可能没有被明确阐述，这可能导致对正确方法的误解和分歧。
 
 为了帮助你了解可以做出哪些选择，本章比较了几个对比概念，并探讨了它们的权衡：
 
@@ -49,14 +49,14 @@ breadcrumbs: false
 
 > [!TIP] 术语：前端和后端
 
-本书中我们将讨论的大部分内容都与 **后端开发** 有关。为了解释这个术语：对于 Web 应用程序，在 Web 浏览器中运行的客户端代码称为 **前端**，处理用户请求的服务器端代码称为 **后端**。移动应用类似于前端，它们提供用户界面，通常通过互联网与服务器端后端通信。前端有时在用户设备上本地管理数据 [^2]，但最大的数据基础设施挑战通常在于后端：前端只需要处理一个用户的数据，而后端代表 **所有** 用户管理数据。
+本书中我们将讨论的大部分内容都与 **后端开发** 有关。为了解释这个术语：对于 Web 应用程序，在 Web 浏览器中运行的客户端代码称为 **前端**，处理用户请求的服务器端代码称为 **后端**。移动应用类似于前端，它们提供用户界面，通常通过互联网与服务器端后端通信。前端有时在用户设备上本地管理数据 [^2]，但最大的数据基础设施挑战通常在于后端：前端只需要处理一个用户的数据，而后端为 **所有** 用户管理数据。
 
-后端服务通常可通过 HTTP（有时是 WebSocket）访问；它通常由一些应用程序代码组成，这些代码在一个或多个数据库中读取和写入数据，有时还与其他数据系统（如缓存或消息队列）接口（我们可能将其统称为 **数据基础设施**）。应用程序代码通常是 **无状态的**（即，当它完成处理一个 HTTP 请求时，它会忘记关于该请求的所有内容），任何需要从一个请求持续到另一个请求的信息都需要存储在客户端或服务器端的数据基础设施中。
+后端服务通常可通过 HTTP（有时是 WebSocket）访问；它通常由一些应用程序代码组成，这些代码在一个或多个数据库中读取和写入数据，有时还与其他数据系统（如缓存或消息队列）交互（我们可能将其统称为 **数据基础设施**）。应用程序代码通常是 **无状态的**（即，当它完成处理一个 HTTP 请求时，它会忘记关于该请求的所有内容），任何需要从一个请求持续到另一个请求的信息都需要存储在客户端或服务器端的数据基础设施中。
 
 
 ## 分析型与事务型系统 {#sec_introduction_analytics}
 
-如果你在企业中从事数据系统工作，你可能会遇到几种不同类型的数据工作者。第一类是 **后端工程师**，他们构建服务来处理读取和更新数据的请求；这些服务通常直接或间接地通过其他服务为外部用户提供服务（参见["微服务与 Serverless"](/ch1#sec_introduction_microservices)）。有时服务是供组织其他部分内部使用的。
+如果你在企业中从事数据系统工作，你可能会遇到几种不同类型的数据工作者。第一类是 **后端工程师**，他们构建服务来处理读取和更新数据的请求；这些服务通常直接或间接地通过其他服务为外部用户提供服务（参见["微服务与 Serverless"](/ch1#sec_introduction_microservices)）。有时服务是供组织其他部门内部使用的。
 
 除了管理后端服务的团队外，通常还有两类人需要访问组织的数据：**业务分析师**，他们生成关于组织活动的报告，以帮助管理层做出更好的决策（**商业智能** 或 **BI**）；以及 **数据科学家**，他们在数据中寻找新的见解，或创建由数据分析和机器学习（AI）支持的面向用户的产品功能（例如，电子商务网站上的“购买了 X 的人也购买了 Y”推荐、风险评分或垃圾邮件过滤等预测分析，以及搜索结果排名）。
 
@@ -76,7 +76,7 @@ breadcrumbs: false
 > [!NOTE]
 > [第 8 章](/ch8#ch_transactions) 详细探讨了我们所说的事务的含义。本章松散地使用该术语来指代低延迟的读取和写入。
 
-尽管数据库开始用于许多不同类型的数据——社交媒体上的帖子、游戏中的移动、地址簿中的联系人等等——基本的访问模式仍然类似于处理商业交易。事务型系统通常通过某个键查找少量记录（这称为 **点查询**）。基于用户的输入插入、更新或删除记录。因为这些应用程序是交互式的，这种访问模式被称为 **联机事务处理**（OLTP）。
+尽管数据库开始用于许多不同类型的数据——社交媒体上的帖子、游戏中的移动、地址簿中的联系人等等——但是基本的访问模式仍然类似于处理商业交易。事务型系统通常通过某个键查找少量记录（这称为 **点查询**）。基于用户的输入插入、更新或删除记录。因为这些应用程序是交互式的，这种访问模式被称为 **联机事务处理**（OLTP）。
 
 然而，数据库也越来越多地用于分析，与 OLTP 相比，分析具有非常不同的访问模式。通常，分析查询会扫描大量记录，并计算聚合统计信息（如计数、求和或平均值），而不是将单个记录返回给用户。例如，连锁超市的业务分析师可能想要回答以下分析查询：
 
@@ -153,7 +153,7 @@ Apache Hive、Spark SQL、Presto 和 Trino 是这种方法的例子。
 
 #### 超越数据湖 {#beyond-the-data-lake}
 
-随着分析实践的成熟，组织越来越关注分析系统和数据管道的管理和运维，例如 DataOps 宣言所捕获的 [^18]。其中一部分是治理、隐私和遵守 GDPR 和 CCPA 等法规的问题，我们将在["数据系统、法律与社会"](/ch1#sec_introduction_compliance)和[待补充链接]中讨论。
+随着分析实践的成熟，组织越来越关注分析系统和数据管道的管理和运维，如在 DataOps 宣言中所描述的那样 [^18]。其中一部分是治理、隐私和遵守 GDPR 和 CCPA 等法规的问题，我们将在["数据系统、法律与社会"](/ch1#sec_introduction_compliance)和[待补充链接]中讨论。
 
 此外，分析数据越来越多地不仅作为文件和关系表提供，还作为事件流（参见[待补充链接]）。使用基于文件的数据分析，你可以定期（例如，每天）重新运行分析以响应数据的变化，但流处理允许分析系统以秒级的速度响应事件。根据应用程序及其时间敏感性，流处理方法可能很有价值，例如识别和阻止潜在的欺诈或滥用活动。
 
@@ -362,7 +362,7 @@ ETL（参见["数据仓库"](/ch1#sec_introduction_dwh)）只是故事的一部
 
 在多台机器上分布系统的最常见方式是将它们分为客户端和服务器，并让客户端向服务器发出请求。最常见的是使用 HTTP 进行此通信，正如我们将在["流经服务的数据流：REST 和 RPC"](/ch5#sec_encoding_dataflow_rpc)中讨论的。同一进程可能既是服务器（处理传入请求）又是客户端（向其他服务发出出站请求）。
 
-这种构建应用程序的方式传统上被称为 **面向服务架构**（SOA）；最近，这个想法已经被细化为 **微服务** 架构 [^52] [^53]。在这种架构中，服务有一个明确定义的目的（例如，在 S3 的情况下，这将是文件存储）；每个服务公开一个可以由客户端通过网络调用的 API，每个服务有一个负责其维护的团队。因此，复杂的应用程序可以分解为多个交互服务，每个服务由单独的团队管理。
+这种构建应用程序的方式传统上被称为 **面向服务架构**（SOA）；最近，这个想法已经被细化为 **微服务** 架构 [^52] [^53]。在这种架构中，服务有一个明确定义的目的（例如，对于S3来说，这个目的是文件存储）；每个服务公开一个可以由客户端通过网络调用的 API，每个服务有一个负责其维护的团队。因此，复杂的应用程序可以分解为多个交互服务，每个服务由单独的团队管理。
 
 将复杂的软件分解为多个服务有几个优点：每个服务可以独立更新，减少团队之间的协调工作；每个服务可以分配它需要的硬件资源；通过将实现细节隐藏在 API 后面，服务所有者可以自由地更改实现而不影响客户端。在数据存储方面，每个服务通常有自己的数据库，而不在服务之间共享数据库：共享数据库实际上会使整个数据库结构成为服务 API 的一部分，然后该结构将很难更改。共享数据库还可能导致一个服务的查询对其他服务的性能产生负面影响。
 
@@ -381,7 +381,7 @@ ETL（参见["数据仓库"](/ch1#sec_introduction_dwh)）只是故事的一部
 云计算不是构建大规模计算系统的唯一方式；另一种选择是 **高性能计算**（HPC），也称为 **超级计算**。尽管有重叠，但与云计算和企业数据中心系统相比，HPC 通常有不同的设计考量并使用不同的技术。其中一些差异是：
 
 * 超级计算机通常用于计算密集型科学计算任务，例如天气预报、气候建模、分子动力学（模拟原子和分子的运动）、复杂的优化问题和求解偏微分方程。另一方面，云计算往往用于在线服务、业务数据系统和需要以高可用性为用户请求提供服务的类似系统。
-* 超级计算机通常运行大型批处理作业，定期将其计算状态检查点到磁盘。如果节点发生故障，常见的解决方案是简单地停止整个集群工作负载，修复故障节点，然后从最后一个检查点重新启动计算 [^55] [^56]。对于云服务，通常不希望停止整个集群，因为服务需要以最小的中断持续为用户提供服务。
+* 超级计算机通常运行大型批处理作业，定期将其计算状态检查点保存到磁盘。如果节点发生故障，常见的解决方案是简单地停止整个集群工作负载，修复故障节点，然后从最后一个检查点重新启动计算 [^55] [^56]。对于云服务，通常不希望停止整个集群，因为服务需要以最小的中断持续为用户提供服务。
 * 超级计算机节点通常通过共享内存和远程直接内存访问（RDMA）进行通信，这支持高带宽和低延迟，但假设系统用户之间有高度的信任 [^57]。在云计算中，网络和机器通常由相互不信任的组织共享，需要更强的安全机制，如资源隔离（例如虚拟机）、加密和身份验证。
 * 云数据中心网络通常基于 IP 和以太网，以 Clos 拓扑排列以提供高对分带宽——这是网络整体性能的常用度量 [^55] [^58]。超级计算机通常使用专门的网络拓扑，例如多维网格和环面 [^59]，这能让具有已知通信模式的 HPC 工作负载产生更好的性能。
 * 云计算允许节点分布在多个地理区域，而超级计算机通常假设它们的所有节点都靠近在一起。
@@ -404,7 +404,7 @@ ETL（参见["数据仓库"](/ch1#sec_introduction_dwh)）只是故事的一部
 
 一般来说，我们存储数据是因为我们认为其价值大于存储它的成本。然而，值得记住的是，存储成本不仅仅是你为 Amazon S3 或其他服务支付的账单：成本效益计算还应该考虑到如果数据被泄露或被对手入侵的责任和声誉损害风险，以及如果数据的存储和处理被发现不符合法律的法律成本和罚款风险 [^51]。
 
-政府或警察部队也可能迫使公司交出数据。当存在数据可能暴露犯罪行为的风险时（例如，在几个中东和非洲国家的同性恋，或在几个美国州寻求堕胎），存储该数据会为用户创造真正的安全风险。例如，去堕胎诊所的旅行很容易被位置数据揭示，甚至可能通过用户 IP 地址随时间的日志（表示大致位置）。
+政府或警察部队也可能迫使公司交出数据。当存在数据可能暴露犯罪行为的风险时（例如，在几个中东和非洲国家的同性恋，或在几个美国州寻求堕胎），存储该数据会为用户创造真正的安全风险。例如，去堕胎诊所的行程很容易被位置数据泄露，甚至可能通过用户 IP 地址随时间的日志（表示大致位置）泄露。
 
 一旦考虑到所有风险，可能合理地决定某些数据根本不值得存储，因此应该删除。这个 **数据最小化** 原则（有时以德语术语 **Datensparsamkeit** 为人所知）与“大数据”哲学相反，后者是投机性地存储大量数据，以防将来有用 [^62]。但它符合 GDPR，该法规要求个人数据只能为指定的、明确的目的收集，这些数据以后不得用于任何其他目的，并且数据不得保留超过收集目的所需的时间 [^63]。
 
@@ -421,7 +421,7 @@ ETL（参见["数据仓库"](/ch1#sec_introduction_dwh)）只是故事的一部
 
 然后，我们将云服务（一个相对较新的发展）与传统的自托管软件范式进行了比较，后者以前主导了数据系统架构。这些方法中哪一种更具成本效益在很大程度上取决于你的特定情况，但不可否认的是，云原生方法正在为数据系统的架构带来重大变化，例如它们分离存储和计算的方式。
 
-云系统本质上是分布式的，我们简要地研究了分布式系统与使用单台机器相比的一些权衡。有些情况下你无法避免分布式，但如果可能在单台机器上运行系统，建议不要急于使系统分布式。在[第 9 章](/ch9#ch_distributed)中，我们将更详细地介绍分布式系统的挑战。
+云系统本质上是分布式的，我们简要地研究了分布式系统与使用单台机器相比的一些权衡。有些情况下你无法避免分布式，但如果可能在单台机器上运行系统，建议不要急于使系统分布式化。在[第 9 章](/ch9#ch_distributed)中，我们将更详细地介绍分布式系统的挑战。
 
 最后，我们看到数据系统架构不仅由部署系统的企业的需求决定，还由保护其数据被处理的人的权利的隐私法规决定——这是许多工程师容易忽视的一个方面。我们如何将法律要求转化为技术实现还没有非常清晰的答案，但在我们阅读本书的其余部分时，记住这个问题很重要。