由来
在“大数据”之前，是“数据”。之前的数据都是在数据库中的。可以进行增删改查这种 OLTP（OnLine Transaction Processiong，联机交易处理）。 有了数据之后通常要进行分析，在数据量比较小的时候，只需要 OLAP（OnLine Analytical Processing，联机分析处理）进行简单的 join，max，min 即可。但是随着数据量的递增，比如对数据库进行了分库分表，那么怎么进行 join 查询，怎么进行数据分析统计？这就出现了“大数据”。这些分库分表的数据，可能分布在不同的机器上，也就是这些数据都是“分布式”的。而分析统计却是“中心化”的。大数据要做的就是将这些原始的“分布式”数据，汇聚到一个“中心化”的存储，然后进行分析计算。
发展路径
2006 hadoop map reduce
需要程序员编写 map reduce 方法，然后提交到 hadoop 集群运行。比如对文章进行单词统计。
2010 hive
编写 map reduce 方法，成本还是有些高，在 2010 年出现了 hive。可以直接编写 sql，就可以获得结果。sql 由 hive 解析之后，提交到 hadoop中运算。
2012 yarn
yarn(Yet Another Resource Negotiator)。在 Map reduce 和 hdfs 之间插入 yarn，可以实现调度 Map reduce，又可以调度后来的 spark 和 flink。
可以把 yarn 理解为 k8s。k8s 管理调度的是 docker，是一个个独立的 Linux进程。而 yarn 管理的是 JVM 虚拟机。
2014 spark
之前写的 Map reduce 代码比较多，而且中间结果要存储在 hdfs（落盘） 上。spark 出现后，可以写很少的代码，而且中间结果尽可能在内存中。
spark sql
之后也不需要写 spark 的 java 代码了，可以写 sparkSQL 的方式。这样跟 hive 就一样了。只是之前的 hive sql 被解析到 map reduce 引擎去计算，而 spark SQL 被解析到 spark 引擎。
spark python
为了降低开发成本，开发了python spark 框架，将 Python 代码通过这个框架翻译成 java，然后在 spark 计算引擎上执行。
流式计算
之前的都是“批处理”的年代。比如启动定时任务去全量计算。 spark streaming 出现之后，进入了流式计算的年代。spark streaming 是一个“伪流式”计算。 spark streaming按照分钟的粒度，将任务做拆分，形成“微批”任务提交到spark计算引擎。
flink诞生于流式计算，flink创始人的flink商业化公司在2019年被阿里用1亿美元收购。在2022年5月，flink创始团队创建新的flink商业化公司，在2023年又被confluent(kafka的商业化公司)收购。
flink也可以批处理，以从spark中分蛋糕。
数据采集到处理
数据从在线的实时系统，通过日志文件采集的方式、DB binlog的方式、API推送的方式被采集。
上图中的canal是阿里开源的MySQL同步组件，既可以实现增量同步又可以增量同步。使用时，先开始增量同步，再进行全量同步。问题是，全量同步完成时，增量同步从哪里开始？在全量同步的时候，增量同步会暂停，当全量同步完成时，增量同步继续。
binlog有3种模式：
- statement模式，即语句模式。对于DDL（Data Define Language）和DML（data management language，不包括查询语句），会记录执行的SQL语句信息。
- 缺点是，比如语句中有now()函数，而不同的机器时间可能不一致，这就会有问题。
- row模式，即行模式。binlog不再记录SQL语句，而是仅记录语句执行前后的数据变化信息。比如一条update语句会更新10行数据，那么row模式下会记录10条数据的变化信息。
- mix模式。对于不依赖本地函数的语句，使用statement模式；否则使用row模式。
- 5.7.7之前默认是statement模式，之后是row模式；8.0之后默认是mix模式。
