数据处理

一、第一性原理：数据处理系统究竟在解决什么问题

从抽象层面看，所有数据处理系统都在回答同一个问题：

如何在可控成本下，把原始数据持续、可靠、可解释地转化为可消费的信息。

拆解后，本质只有三类不可回避的矛盾：

  1. **时效性 vs 准确性**：结果要快，还是要准？
  2. **表达能力 vs 系统复杂度**：计算模型越强，系统越复杂
  3. **工程效率 vs 运维成本**：越“自动化”，越依赖底层系统能力

后续所有计算引擎、架构范式、API 设计，本质都是在这三组张力之间取不同的平衡点。

二、计算引擎选型的三维空间（统一抽象）

1. 响应速度：时间维度上的分层

响应速度不是“快或慢”的问题，而是数据是否有界的问题：

本质区别：是否允许“等待完整数据集”。

2. 灵活性：计算模型的表达上限

灵活性来自三个正交维度：

表达能力越强，对执行引擎的约束和状态管理要求越高。

3. 使用难度：系统复杂度的外溢程度

使用难度不是“是否有 SQL”，而是复杂性是否被系统内部吸收：

三、数据处理的基本计算模型

1. 批处理模型

定义：

UNIX Pipeline、MapReduce 都属于这一范畴。

MapReduce 的本质缺陷

并非“慢”，而是：

它暴露的是“分布式计算的真实复杂度”，而不是业务模型。

2. 流处理模型

核心假设改变：

一旦承认数据无界，时间就成为必须显式建模的维度。

四、统一抽象：DAG 作为计算的通用表示

无论批处理还是流处理，最终都会被编译为 有向无环图（DAG）：

DAG 的两种形态

1. 单任务 DAG

2. 管道 DAG

DAG 的价值在于：让系统有机会做全局优化。

五、架构范式：如何组织批与流

1. Lambda 架构

核心思想：

致命问题：

2. Kappa 架构

关键前提：

优势：

代价：

3. 事件溯源

核心模型：

适用场景：

六、Spark：批处理时代的集大成者

设计必然性

Spark 的成功并非偶然，而是精准命中了三点：

  1. RDD 把容错内嵌进数据模型
  2. DAG Scheduler 吸收执行复杂度
  3. 内存优先，磁盘兜底

Spark SQL 的本质

Catalyst = 关系代数 + 规则引擎 + 代价模型

SQL 不是接口，而是可优化的中间表示。

Structured Streaming

七、Flink：以流为一等公民

Flink 的核心取舍：

Flink 不是 Spark 的“流模式”，而是完全不同的计算哲学。

八、Beam：计算模型的抽象层

Beam 的定位不是引擎，而是：

对“分布式数据处理”进行形式化建模。

九、Streaming SQL：表达力的终极形态

当计算模型稳定后，最终一定会走向声明式：

Streaming SQL 是：

的统一外壳。

总结

  1. **先选模型，再选引擎**
  2. **复杂性只能被转移，不能被消灭**
  3. **能被统一描述的，一定会被统一执行**
  4. **所有成功的系统，都在隐藏分布式本质**

关联内容（自动生成）