大数据架构演变

一、离线数仓

缺点：

1. ETL计算、存储、时间成本高
2. 数据处理链路过长
3. 无法支持实时、近实时的数据分析
4. 数据采集对业务库造成影响

二、Lambda架构，离线实时分开

缺点：

1. 组件多，不方便管理
2. 很难保证数据一致
3. 数据探查困难，出现问题很难排查

三、Kappa架构，实时为主

缺点：

1. kafka无法支持海量存储
2. kafka无法支持高效的OLAP
3. 无法复用数据血缘管理体系
4. kafka不支持update 

四、数据湖，流批一体

数据采集：之前是sqoop,flume,maxwell,datax等各种组件采集，引入组件多，链路复杂，现在是cdc千表入湖

计算引擎：之前spark、impala、presto、flink，现在flink流批一体

即席查询：之前impala、presto、hbase、kudo，现在doris,starrocks

五、实战：Flink+Paimon数据湖架构

Apache Paimon | Apache Paimon

1、Paimon官网基础知识

1. 采集使用CDC Ingestion，可以同步表、同步库
2. 常见配置看Maintenance-Configurations，包括了file.format='parquet',flie.block-size等默认参数
3. 表更日志看Table with PK(主键表)-Changelog Producer
4. 快照管理看Maintenance-Manage Snapshots
5. 表引擎看Merge-Engine，包括了部分更新、聚合等

 

2、LSM-Tree 日志结构合并树

关系型数据库：重点是查询，在读性能上有很高的要求， 通过二分查找、hash、B+树等方式虽然数据查询很快，但是底层磁盘造成了大量随机写。同时对表的要求很高，比如结构化、索引、主键等。

因为磁盘随机写慢，顺序写快的特性，想要提高写操作性能，设计成顺序写。顺序写很简单，就是直接将数据追加到文件后面，但是读取/查询是就需要扫描所有数据，很浪费时间。

LSM-Tree：日志结构合并树，是一种分层，有序，面向磁盘的数据结构，其核心思想就是充分利用了磁盘批量顺序写要远比随机写性能快很多，对读和写性能做了权衡。

1. 保证写操作性能：发挥磁盘特性，一次性地读取或写入固定大小的一批数据，尽可能减少随机寻道操作。（写入LSM树的新记录将首先缓存在内存中。当内存缓冲区满时，内存中的所有记录将被排序并刷新到磁盘，也就是批量写入）
2. 保证读操作性能：
   1. 通过划分内存+磁盘的多层合并结构，及各种优化尽量保证读操作性能，按照时间顺序来存储数据，最新的数据存放在内存中，方便实时计算；
   2. LSM树把文件分成多个sorted run（分成很多批），一个sorted run包含多个文件，每个文件中的数据按主键排序，实现了磁盘的分批顺序写入，查询的时候需要将所有Sorted Run合并起来，并根据时间戳合并相同主键的数据；
   3. 太多Sorted Run合并将导致查询性能较差，甚至内存不足。为了限制Sorted Run的数量，我们必须偶尔将多个Sorted Run合并为一个大的Sorted Run。这个过程称为Compaction。

但是过于频繁的Compaction可能会导致写入速度变慢，这是查询和写入性能之间的权衡。

HBase、MongoDB等存储引擎都是LSM树，kafka用到了磁盘顺序读写。

3、Paimion写入流程

1. 写操作触发，首先将数据记录在写前日志（Write Ahead Log）（相当于checkpoint）,以便故障时恢复数据。
2. 把数据追加到内存中的C0层。
3. 当C0层数量达到一定大小，就把C0和C1层以归并的方式合并覆盖C1，这个过程称为Compaction。合并出来的新文件会顺序写入磁盘，替换掉旧文件。当C1层达到一定大小，会继续和下层合并，合并之后所有旧文件都可以删除。
4. 需要注意，写入可能重复，新版本会覆盖老版本，比如a老版本已经来到Ci层了，C0层来了个新版本，这个时候不会去更新下层老文件，而只是在C0层写入一个新的数据，等待后面合并自动覆盖。

参考视频：011.精通Paimon—大数据环境概览_哔哩哔哩_bilibili