数据系统的架构
相关：
文章源于我阅读 DDIA 时产生的思考，用我可解释的论证关系把各个概念串联在一起，它和原书几乎毫无关联。文章不会系统地介绍每个细节（AI能够做得比我好），而是侧重于我如何推导、碎片的概念如何联系。希望能够给你提供一个不同的视角。
数据系统（Data System）vs. 分布式系统（Distributed System）
- 数据系统是按照用途来定义的。任何用于存储、处理、传输数据的系统都可以称为数据系统，它可能是单机的，也可能是分布式的。
- 分布式系统是按照架构形态来定义的。即这个系统以多个节点通过网络协作组织而成。
在现代，大部分有规模的数据系统都是分布式的，因此当我们在研究数据系统底层架构的时候，首先要知道单机情况下，数据系统是如何运行的；接着在单机原理的基础上，将数据系统扩展为分布式系统，来研究分布式所带来的新问题和挑战。
在 MIT6.5840 Lab 1：MapReduce 中，我在写 MR 框架的时候，也是用的同样的思路。
- 先了解单机（顺序的）情况下，一个进程如何按序完成任务。确保逻辑（业务）的正确性
- 接着将一个进程扩展为多个进程，再一一解决分布式所带来的容错、协调、一致性等问题。
Operational System vs. Analytical System
任何新的技术系统实际上都是来源于人类的需求，因此本节从需求出发，按照逻辑顺序，探讨两种不同系统的产生。
-
企业需要开发一个应用系统，完成它的不同需求：
- 业务运转需求：系统要实时处理用户的请求。例如注册、登录、下单、支付
- 决策分析需求：系统能够对大量历史业务数据进行复杂查询，相关人员分析数据，帮助企业做出决策。
-
不同的需求代表着不同的工作负载
- online transaction processing(OLTP)：系统能够实时处理频繁的短小事务。即读写少量行、高并发、低延迟，需要事务
- online analytical processing(OLAP)：系统能够处理大量数据的复杂查询，允许高延迟，不需要事务。
Transaction(事务): 是指一系列读写操作的集合，这一系列的读写操作是不可分割的。要么全部提交，要么全部回滚。
什么是工作负载？
工作负载描述的是一个系统在运行时实际承受的请求的总体特征，包括：
- 请求的类型是什么（读多还是写多，点查询还是聚合查询）
- 请求的频率是多少（每秒多少个请求）
- 每个请求涉及多少数据（几行还是几亿行）
- 请求的延迟要求是什么（毫秒级还是秒级）
- 如果两类工作负载都放到同一个系统（比如MySQL）里，OLAP类工作负载会占用大量资源，影响业务运转的性能。工程上的解决方案是把不同的工作负载分离到针对性优化的专用系统上。于是我们可以用一个应用系统，底层使用MySQL+Snowflake两个专用系统，不同的请求路由到不同的系统。
第三点的系统/专用系统指的是数据基础设施，而非应用系统。因为资源竞争发生的地点是数据库，而不是业务应用的服务器。
- 由于服务的用户不同、需求不同、工作负载不同（当然不止这些不同点）。一个应用系统自然而然地演化为两个系统，分别是：
- Operational System（业务系统）：主要承载OLTP的工作负载。
- Analytical System（分析系统）：主要承载OLAP的工作负载
Analytical systems包括：
- Batch Analytics：批处理分析系统
- Interactive/Ad-hoc Analytics：交互式分析系统
- Real-time/Streaming Analytics：实时分析系统
【待——更——新】
Chapter 1: Trade-Offs in Data Systems Architecture