数据系统的架构
你的需求 应用的设计目标 恰好落在这些系统的设计边界内
需求：
功能性需求。
非功能性需求
系统的设计边界
组合--如果不在，现阶段和可预见的阶段开发设计
--如果存在，低级别的组件还是使用现有的高级别系统
不同的人需要用同一份数据做完全不同的事 这些目标往往并未被明确表达，容易引发误解和分歧。
数据系统的架构不仅受到技术目标和要求的影响，还受到它们所支持的组织的人力需求的影响
复杂性分成两类：本质复杂性 与 偶然复杂性
管理复杂性的工具--抽象
1.数据
--应用中的职责划分
原始数据源--派生数据系统
派生数据丢失是否可以从原始数据源重新构建。
--数据演化
存储数据的变更：可能需要捕获新的字段或记录类型，或者现有数据需要以新的方式呈现
模式不可避免地需要随时间而变化。我们称之为 模式演化
--数据模型
规范化、反规范化与连接
文档模型和图模型
多对一与多对多关系
图由两种对象组成：顶点（也称为 节点 或 实体）和 边（也称为 关系 或 弧）
三元组存储
数据框和多维数字数组（如矩阵）-Dataframe 和 matrix
数据框 API
在线系统（online systems）
请求（request） 与 查询（query） 以及对应的 响应（response） 或 结果（result）
离线系统（offline systems）
2.事务型系统和分析型系统
OLTP 事务（transaction） 点查询（通过键获取单个记录
OLAP
历史
1.起初，相同的数据库既用于事务处理，也用于分析查询。
2.由于目标和约束不同，事务型系统与分析型系统分离仍很常见
01.分析查询继而单独的数据库被称为 数据仓库
数据仓库包含公司中所有各种 OLTP 系统中数据的只读副本
提取-转换-加载（ETL
先加载-在数据仓库中进行转换），从而产生 ELT。
ETL 过程的数据源是外部 SaaS 产品-专门的数据连接器服务（如 Fivetran、Singer 或 AirByte）实现
ETL 过程慢慢泛化为 数据管道
02. 组织面临着以适合数据科学家使用的形式提供数据的需求： 数据湖
03.典型的数据仓库工作负载（SQL 查询和业务分析），以及数据科学和机器学习的工作负载。这种架构被称为 数据湖仓
数据 ： Table
机器学习ML： Dataframe
3.HTAP 不会取代数据仓库。相反，它在同一应用程序既需要执行扫描大量行的分析查询，
又需要以低延迟读取和更新单个记录的场景中很有用。
3.开发-运营_业务优先级
01.谁构建软件-开发实现 和谁部署它-实施和运营
云服务与自托管-不同的经济模型-取决于你的技能和系统的工作负载
分析系统通常具有极其可变的负载
在云原生系统： 多租户 存储与计算的分离
02.DevOps/SRE 理念
03.微服务与无服务器 面向服务的体系结构（SOA） Serverless
4.分布式系统和单机系统
云计算 分布式系统
在云计算中，网络和机器通常由相互不信任的组织共享，需要更强的安全机制
云的本质承诺是弹性和按需
云计算与超级计算：超级计算机通常用于计算密集型科学计算任务
5.衡量和评估
功能实现下的
可靠性与容错
可拓展性
可演化性 的概念： 致力于构建易于适应变化的系统
可维护性
可运维管理
数据技术与现实
请求时删除其数据的权利（有时称为 被遗忘权）。
许多数据系统依赖不可变构造（如仅追加日志）作为其设计的一部
吞吐量 延迟与响应时间
可靠性与容错
6.技术层面
物理存储布局：
数据在物理上的组织方式（按列 vs 按行）
列存储 ：列式存储、压缩和排序 列存储中的排序顺序
索引/写入结构（日志合并 vs 随机更新）
数据库内部如何处理存储和检索
数据库如何存储你提供的数据，以及当你请求时如何再次找到这些数据。
OLAP：
OLTP 的存储引擎家族：
写入不可变数据文件的 日志结构 存储引擎，
以及像 B 树 就地更新数据的 存储引擎
一个不同的数据结构：索引 索引是从主数据派生出的 额外 结构
LSM-Tree 日志结构合并树（Log-Structured Merge-Tree）或 LSM 树（LSM-Tree）：基于合并和压实排序文件原理的存储引擎
LSM 存储引擎通常在每个段中包含一个 布隆过滤器（Bloom filter）
日志结构索引将数据库分解为可变大小的 段，通常为几兆字节或更大，写入一次后就不可变
B-Tree B 树将数据库分解为固定大小的 块 或 页，并可能就地覆盖
使数据库对崩溃具有弹性，B 树实现通常包括磁盘上的额外数据结构：预写日志（write-ahead log，WAL
Apache Doris
数据先写内存表结构（MemTable）+ 内存跳表（SkipList），再写入磁盘上的有序字符串表（SSTable）
多列索引类型称为 联合索引
OLAP
Duckdb
OLAP数据库的定位量身定制的，核心是自适应基数树 (Adaptive Radix Tree, ART)和自动的区域映射 (Zonemap)
WAL主要负责保障ACID中的原子性 (A) 和持久性 (D)
原子性 (Atomicity) 事务中的所有操作要么全部成功，要么全部失败（不留下部分修改）
依赖 WAL（预写日志）实现：事务提交前日志完整落盘；崩溃后重放或回滚。
一致性 (Consistency) 事务执行前后，数据库从一个合法状态变为另一个合法状态（约束、规则不被破坏）。
外键必须有效。 由应用层约束（主键、唯一、检查）和引擎 MVCC 共同保障。
隔离性 (Isolation) 并发执行的事务互不干扰，效果如同串行执行。
DuckDB 采用 乐观 MVCC（多版本并发控制），读取的是事务开始时的快照，写入冲突时中止事务。
持久性 (Durability)
一旦事务提交，其修改永久保存，即使系统崩溃也不丢失
依赖 WAL + Checkpoint：提交时日志强制落盘；定期将日志合并到主数据库文件
全文检索
倒排索引。这是一个键值结构，其中键是词项，值是包含该词项的所有文档的 ID 列表（倒排列表）
向量嵌入
倒排文件（IVF）索引 分层可导航小世界（HNSW）
查询执行：编译与向量化
查询优化器（规则 vs 代价）、执行模型（向量化 vs 元组迭代）
OLTP（规则+轻量代价）
OLAP（复杂代价模型+动态规划）
云数据库组件： 查询引擎 数据目录 表格式 存储格式
演化
向后兼容性 向前兼容性
谁编码数据，谁解码数据？
序列化和反序列化
从内存表示到字节序列的转换称为 编码（也称为 序列化 或 编组），反向过程称为 解码（解析、反序列化、反编组
编码通常与特定编程语言绑定 ：
Java 有 java.io.Serializable，Python 有 pickle，Ruby 有 Marshal
语言无关
文本格式
JSON、XML 和 CSV 文本格式
二进制格式编码
Apache Avro 是另一种二进制编码格式
Protocol Buffers (protobuf) 是 Google 开发的二进制编码库
读取者如何知道特定数据是用哪个写入者模式编码的
文件存储格式--数据传输格式--内存格式
如何处理数据演化的问题
01.流经文本文件的方式
json
02.流经数据库的数据流
03.流经服务的数据流：REST 与 RPC
04.通过工作流引擎
工作流由 工作流引擎 运行或执行 工作流引擎通常由编排器和执行器组成
Airflow、Dagster 和 Prefect，与数据系统集成并编排 ETL 任
05.通过异步消息 “事件驱动的架构”
kafaka
01.流经服务的数据流：REST 与 RPC
网络请求与本地函数调用非常不同
根据 REST 原则设计的 API 称为 RESTful
调用 Web 服务 API 的代码必须知道要查询哪个 HTTP 端点，以及发送什么数据格式以及预期的响应
gRPC（Protocol Buffers）和 Avro RPC 可以根据各自编码格式的兼容性规则进行演化
事件驱动架构（使用消息代理或 actor 事件驱动架构
编码数据从一个进程流向另一个进程的另一种方式。请求称为 事件 或 消息
消息代理（也称为 事件代理、消息队列 或 面向消息的中间件）
RabbitMQ、ActiveMQ、HornetQ、NATS 和 Apache Kafka）
Actor 模型
案例
数据流动--通过文件的方式--通过数据库的方式
01. 增加字段或者
02. 删除字段-废弃字段
03. 改变字段
将单值属性更改为多值--
不同时间写入的不同值--
AI 时代
AI 时代内容本身正在失去作为证据的资格，AI可以批量生成，内容就从“证据”降级成了“素材”
真正需要意志介入的叫信任（Trust），不需要意识介入的默认状态叫信心
现代社会的本质是把信任降级为信心——让人在大部分日常生活里，不必真的做信任决定。
识别 识别本身不是信任，是信任的前置条件
升值的不是内容本身，是让自己的内容能被信任的支撑结构
内容已经过剩，观点已经过剩，教程已经过剩。让自己被信任的支撑结构
内容怎么办
COde怎么办
当“写代码”本身不再稀缺，剩下最有价值的东西只有两样：
能提出有品位的设计。
能进行可靠的工程验收
质量控制的核心已经从“写代码”转移到了“设计 + 验收”。
是用工程方法解决“写什么代码、为什么写、怎么验收”的工程问题,它向传统行业回归的进程中
新动能成熟后，其核心技术可能下沉为基础设施（新基建），同时行业本身回归传统商业逻辑。
新基建更强调公共基础和支撑作用，而“回归传统”更强调企业竞争模式的变化。
其核心从“技术是否可行”，变为“成本是否够低”
agent 一个 CRUD 后台，加一套业务逻辑，再包一层好看的 UI
不懂技术的领导，如何确保技术团队不偷懒、不犯傻？一个简单的办法：让他们互相找茬
AI Agent ：两个不同架构、不同训练数据的模型，犯同一个错误的概率远低于单个模型。
这不是什么高深理论，就是朴素的交叉验证
你的思维工具不应该依赖于别人的善意。 数据主权 ，云计算-进入的自由，从未对等于离开的自由
参考
AI正在让信任的脚手架塌陷 https://vonng.com/ai/ai-trust-issue/
https://vonng.com/ai/local-ai-inference/
浙公网安备 33010602011771号