DDIA阅读笔记 - 数据系统基础概述
DDIA 2 翻译版：https://ddia2.pigsty.io/，非常好书，使我心情舒畅。
更新日期：2025.4.25 02:09
目前读到 第一章：数据系统架构中的利弊权衡
数据系统基础概念
本章的主题是理解权衡：即，认识到对于许多问题并没有唯一的正确答案，而是有几种不同的方法，每种方法都有各自的优缺点。我们探讨了影响数据系统架构的一些重要选择，并介绍了在本书余下部分将需要用到的术语。
首先区分操作型（事务处理，OLTP）和分析型（OLAP）系统，介绍数据仓库和数据湖的概念，这些系统通过 ETL 从业务系统接收数据。
然后，我们比较了云服务和之前主导数据系统架构的传统自托管软件范式。云系统本质上是分布式的，我们简要考察了与使用单一机器相比，分布式系统的一些权衡。
数据系统基础
现在，越来越多的系统是以数据为中心的。
需要存储和供分析使用的数据包括用户活动、商业交易、设备和传感器的数据。当用户与应用程序交互时，他们既读取存储的数据，也生成更多数据。
如果数据管理是开发应用程序的主要挑战之一，我们称这类应用为数据密集型。而在计算密集型系统中，挑战在于并行处理一些非常大的计算，在数据密集型应用中，我们通常更关心的是如何存储和处理大数据量、管理数据变化、在出现故障和并发时确保一致性以及确保服务的高可用性。
这本书把数据系统分为两个部分，业务系统和分析系统。分析系统通常是来自业务系统的数据的只读副本，并进行处理以便于分析。
这一部分就用于介绍数据系统的基础知识，对数据系统的知识做一些补充，感觉会比较零碎。
书中的特别关键词：
- 交易：指的是构成逻辑单元的一组读写操作，泛指低延迟的读写操作。
- 点查询：OLTP中的查询部分，只查询极少数数据用于业务
数据仓库
通常不希望分析模块/人直接查询OLTP数据库，有以下两个问题
- 数据孤岛：感兴趣的数据可能分布在多个业务系统中，将这些数据集合并到单一查询中很困难
- 性能开销：分析查询性能开销通常很大，会影响OLTP性能
因此，要把数据放到数仓中，可以尽情查询，而不影响OLTP操作，且通常为分析查询优化。
数据仓库包含公司所有各种OLTP系统中的数据的只读副本。数据从OLTP数据库中提取，转换成便于分析的模式，清理后，然后加载到数据仓库中。将数据获取到数据仓库的过程称为提取-转换-加载（ETL）。
数据湖：
数仓是由某种特定方式组织的数据，例如SQL，但有时候我们需要一些特殊的处理，例如分析整个系统的文本情感或者炼AI，结构化的数据可能不合适，因此我们需要数据湖：数据湖只包含文件，不强加任何特定的文件格式或数据模型。
数据湖还可以作为从业务系统到数据仓库的中间停靠点，数据湖包含由业务系统产生的“原始”形式的数据，而不是转换成关系数据仓库架构的数据，每个数据的消费者都可以将原始数据转换成最适合其需要的形式。从数据湖加载到数仓的过程就可以归一化为一个消费者消费数据的过程。
也可以直接在数据湖中的文件上运行典型的数据仓库工作负载（SQL查询和商业分析），以及数据科学/机器学习工作负载，这种架构被称为数据湖仓。
在某些情况下，分析系统的输出会提供给业务系统，可以称为反向ETL ，分析系统输出也被称为数据产品。
事件流：在几秒钟的数量级对流式传输来的数据进行分析。
云数据系统
使用云服务的优缺点显而易见
使用云服务，本质上是将该软件的运营外包给云提供商，你不用关心基础设施建设，节省了很多运维成本。但缺点是不清楚细节，且受制于人。
另外，如果系统负载随时间变化很大，云服务特别有价值，可以更容易地根据需求变化扩展或缩减你的计算资源。
相反，如果负载相对稳定，自部署往往会更便宜。
云原生
这概念很玄学，我觉得可以理解为：尽可能利用基于云的基础设施来构建软件，充分发挥云平台的弹性计算、弹性存储的优势，尽量把应用设计成适合云计算的架构，把部署设计成简单易用的流程，最终实现业务快速上线，快速迭代，这样的开发方式就是云原生开发。
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
by CNCF云原生基金会
分布式系统
一个涉及通过网络进行通信的多台机器的系统被称为分布式系统，参与分布式系统的每个进程被称为节点。我们为什么需要系统分布式？
- 可扩展性：负载分配到多台机器以提高负载能力
- 高可用：保证在部分机器故障时仍然可用
- 地域覆盖：如果服务覆盖全球，那么就不得不需要多个服务器（包括法律合规等因素）
除此以外，任何需要借助多台机器的系统都被这本书称为分布式系统，因此还包括：
- 多服务合作：如果数据存储在一个服务中但在另一个服务中处理，则必须通过网络从一个服务传输到另一个服务。
- 特定硬件优化：如对象存储适合多硬盘少CPU的机器，数据分析系统适合CPU和内存多的机器，而AI通常适合用高GPU的机器。
在这里可以思考一下可能会遇到哪些问题？
- 网络故障：每次跨服务调用都要考虑网络故障的可能，都要考虑超时，此时，简单地重试可能也不安全。
- 时延：就算在集群内，跨机器调用仍然比同进程函数调用慢很多。数据如果跟计算分开，加上这中间传输时延后，可能比直接在一台机器更慢。
- 一致性问题：跨服务导致的分布式一致性问题。
因此，作者也认为，如果您可以在单台机器上完成某项任务，这通常比建立分布式系统简单得多。CPU、内存和硬盘已变得更大、更快和更可靠。结合单节点数据库，如SQLite，现在许多工作负载都可以在单个节点上运行。
微服务
每个服务都有一个明确定义的目的（例如，在S3的情况下，这将是文件存储）；每个服务都暴露一个可以通过网络由客户端调用的API，并且每个服务都有一个负责其维护的团队。因此，一个复杂的应用程序可以被分解为多个互动的服务，每个服务由一个单独的团队管理。
这就叫微服务，相对的传统架构叫面向服务的架构（SOA） 。
微服务主要是对人的问题的技术解决方案，允许不同团队独立进展，无需彼此协调。这在大公司中很有价值，但在小公司中，如果没有许多团队，使用微服务可能是不必要的开销，更倾向于使用单体应用。
所以不能无脑微服务。
无服务：就是云服务商提供的类似“计算函数”的功能，云提供商根据对您服务的传入请求，自动分配和释放硬件资源，只需为应用程序代码实际运行的时间付费，而不必提前预配资源。
非功能性要求
相比于你要实现的功能（业务需求），我们通常会有一些非功能需求，例如快速、可靠、安全、合法合规，并且易于维护，他们跟业务需求一样重要。
这一部分，会介绍：
- 如何定义和衡量系统的性能
- 可靠性的含义
- 如何描述可伸缩性
- 什么是系统的可维护性
性能
通常是两个指标：
- 响应时间：就是E2E时延
- 吞吐量：每秒处理的请求数量/数据量
可以认为这两个指标有一定的联系
如果一个系统能够通过增加计算资源显著提高其最大吞吐量，则称该系统具有可扩展性。
重试风暴：有大量请求在排队等待处理，响应时间可能会增加到客户端超时并重新发送请求的程度。这会导致请求率进一步增加，使问题更加严重。
精细化定义延迟与响应时间：
“Latency”和“response time”有时被交替使用，本书中，响应时间是E2E时延，而中间过程被这样拆分，如图。
p50更有参考性，p999通常是优化目标，p9999通常不考虑。
可靠性