1、基于 Flink & Paimon 实现 Streaming Warehouse 数据一致性管理 (qq.com)
偶然在微信刷到了这一片文章，静下心来看，才明白了它要表述什么，这是基于流的数仓当中需要实现哪些功能的一个描述，应该是抖音团队的文章，虽然Paimon还没有实现这些功能，但看完之后我觉得真是心潮澎湃，10年了
12、13年我接触了hadoop，然后14年我有机会实操了一遍hadoop的map-reduce，手写MR应用
最后搭建了颇为原始的大数据平台
14年年初刚到极光通讯的时候则是接触到了storm，但这个东西的一致性其实很差
再后来则是16接触到了hive为主的数仓以及手动调度器来实现的ods、dwd、dws三层架构
但其实数据血缘这些都没有接触更深了，就草草结束了，14、16、18年则是三次接触到了打宽表的需求（因为微服务架构导致的分库分表等现实问题）
10年了，都是草草接触，最后10年后，行业才演化出了更像数据库的这种流式解决方案，而且调度、触发，也有望变成自动化，真是感动；
=================================================================
2、当流计算邂逅数据湖：Paimon 的前生今世 (qq.com)
这算是LJS的一篇总结性的文章，比上面那一篇更具价值，可以静下心来好好读一读；
=================================================================
3、Flink Table Store 0.3 构建流式数仓最佳实践 (qq.com)
还是LJS的视频加文章，讲得是0.3的事情，但其实已经讲清楚很多事情；
看完之后我在2023年8月6日晚上，发出了这样的感慨：
5年前，我在万科的项目里，再一次遭遇了打宽表的需求，最后还是用的cdc（阿里的canal）+kafka+java代码+mysql搞定的，实际上有非常糟糕的工程问题需要去解决；当时还尝试过用Flink来解决，结果阿里的工程师推荐什么双流join和lookup join帮我们的团队去解决，5年后再LJS的这篇《Flink Table Store 0.3 构建流式数仓最佳实践》里才算是解答了我当年多少有点不求甚解的疑惑：首先，当年的Flink并不适合干这个事情，所以当年我给某个同事制定的任务确实完成的很差。其次，打宽表和实时数仓需要面对的upsert问题，比我想象的还要严重，除了性能以外，必须给Flink加一些语法，才能去表达，这个存储层面的东西，同时还需要解决队列、CDC changelog语义，自身还需要去作为一个cdc的发生源，还需要解决点回查，数据血缘解析、流式生产时间对齐，一致性问题等等麻烦，当年的我们等于大量依赖的mysql本身的changlog能力去作为中间表来承载....想想也是真的猛得一批；
不容易啊