湖仓一体架构是最近1-2年时间开始频繁出现在数据开发领域的新名词。也是各大公司竞相投入的对象。
网络上关于湖仓一体架构的实践文章很多，看得也很眼花缭乱。我们今天站在一个「接地气」的角度，来说一说湖仓一体架构中未来需要关注的核心框架有哪些。
文章内容也没有经过仔细的斟酌，完全是一点不成熟的想法，而且站的角度不是高屋建瓴的而是从下往上的。
一个基本判断是湖仓一体架构在形式上不止一种
大家可以从网上看到很多关于基于Doris、Paimon+Flink等等的不同的技术方案的实现。
几个例子，比如：
《从Clickhouse到Doris，湖仓一体架构升级实践》》
《字节跳动基于 Apache Hudi 的湖仓一体方案及应用实践》
所以你看基于Doris、Hudi、Iceberg等的湖仓方案在不同公司的落地形式完全不同。
但是一个基本的共识是，湖存储框架(Hudi/Iceberg/Paimon)、OLAP引擎(Clickhouse/Doris)，计算引擎框架(Flink/Spark)，在不同的架构中都扮演着重要的作用。
湖仓架构的几个特性和框架
存储&计算分离的架构是普遍的架构设计。
目前存储端类似Hudi/Paimon这样的框架是综合成本、效率最低、最推荐的框架。
不止如此，Flink、Doris在和湖存储框架兼容上在各个社区也是处于较高的优先级。举个例子就是Doris/StarRocks在Hudi、Paimon的外表能力支持上。
读写能力要求变高。
相比于传统的数仓开发中，读写能力以及ACID等能力对于湖仓架构下提出了更高的要求。
这个相信大家也都不陌生，传统的Lambda架构的数仓开发模式至今都是行业内各大公司的主流开发模式。
这套模式一方面受制于存储、计算成本不得已而为之，另外一方面是读写能力限制更多。
所以无论是Paimon还是Doris等这些框架在读写设计中都进行了大量的优化，例如Paimon支持主键表并为此进行了大量的读写优化，Doris本身作为OLAP引擎也进行了大量读写优化。
此外还有一些数据治理、数据服务类的要求我们就不过度展开了。
公司内部的落地偏好
在中大公司，从成本和效率的角度上，在小范围内验证后会更加激进的推进离线/在线融合，除了框架本身的特性支持外，大规模推进架构落地会被优先考虑。
在小公司或者特定的业务场景中，这些框架的「特性」才是更加被重视的部分，例如Changelog、Partial update等等。
所以未来你会看到，社区的分享也主要会有两大类组成。
第一类，偏向宏观叙事，聚焦在成本和架构演进。第二类，聚焦在技术方案，偏向特定场景下的业务解决方案。
这两类没有优劣之分，完全是站的视角不同。
所以我们不仅要从宏观上关注架构方向的演进，特定场景下的落地方案也应该多多考虑。
写的思路比较乱，凑合看吧。😄
