实时湖仓架构演变

1. queue + flink + mysql/redis ：
   最初形态，flink做计算，结果插入数据库中，数据库的查询速度很快。缺点是不够灵活，只能查询计算好的聚合数据，想查其他维度或条件的数据，要从头开发一套完整的流程

2. queue + flink + clickhouse(OLAP) ：
   flink 只做 etl 和 join 形成宽表，结果导入支持向量化(？)的 clickhouse，查询在 ck 上做。缺点是 clickhouse 要用 ssd 和 好 cpu,价格昂贵

3. queue + flink hive sink + hive (ad-hoc)
   用 flink 的 hive sink 代替 clickhouse, flink 还是只做 etl + join 宽表，只是查询从 OLAP 换成了存储便宜的 ad-hoc （即席查询）。由于 flink 的 hie sink 延迟是 checkpoint 级别的，一般几分种，所以这种结构做了离线数仓的近实时

4. queue + flink CDC + iceberg
   该方案用 iceberg 替换掉 hive 做离线数仓存储。好处是 iceberg 只负责存储，可以对外被实时流读取，也可以做离线查询。比 hive 的可用性强，而且数据更安全了，这意味着你可以做一些小数据的操作：比如 INSERT INTO 一些数据，DELTE \ UPDATE \ MERGE_INTO 有着更好的支持，而不是像 Hive 一样，要安全的动数据只能 INSERT OVERWRITE 整个分区。。缺点是 CDC 入离线数仓产生的文件不好控制，而且由于那个时候 iceberg 还不能支持 upsert (有就update,没有就insert),所以使用 flink CDC(Change Data Capture) 入仓所采用的“前天的一个全量表，合并今天的增量表，产生今天的全量表“的存储方式。使得每天一个全量表存储成本巨大。
   实际业务为什么要用 CDC 同步 mysql呢？在 OLTP 系统中，为了解决单表数据量大的问题，通常采用分库分表的方式将单个大表进行拆分以提高系统的吞吐量。 但是为了方便数据分析，通常需要将分库分表拆分出的表在同步到数据仓库、数据湖时，再合并成一个大表。 目前 iceberg 支持 upsert 的特性， 但 Iceberg 主打离线数据湖和扩展性

5. flink cdc / kafka cdc + paimon ：
   paimon原生支持flink cdc,因为他的前身叫 flink table store. 而却设计成支持 upsert, 使用 lsm 树的格式
   相比于 Flink SQL 入湖，Paimon 的 CDC 入湖不但可以将数据和 Schema 的变更一起同步到 Paimon 的表中。每天的离线视图可以通过 CREATE TAG 创建，Tag 是一个 snapshot 的引用。而且基于LSM数据结构的特点，只要增量数据不大，两个 TAG 之间是可以复用大量文件的，某些场景有上百倍的节省！