在实际工作中大家应该多多少少都用到，这个文章是一个简单的使用体会。不涉及湖框架的拉踩，我们的着眼点是解决实际问题。
我来结合自身体会跟大家说说Paimon这个框架和对未来的一些判断。大家可以参考，错了也不要怪我误导你😄。
首先湖框架在发展之初解决的几个问题：Schema Evolution、流读流写、批读批写、ACID等几个通用的能力。
但是我们必须指出一点，这几个通用能力不是生产环境都需要的，我们拿Schema Evolution举例，在真正大型的、重要的生产环境其实是非常不推荐使用这种能力，不是因为它不够强大，而是因为他带来的风险和收益不成比例，没有一个开发愿意冒着背故障的风险去做这样的设计。
所以我们站在业务开发的角度去考虑问题，和站在平台开发角度考虑问题呈现了不同的诉求。
那么站在业务开发的角度也就是用户的角度，一些诉求如下：极简单的学习和理解成本、流批读写足够简单、主键/非主键场景支持丰富、最好能在领域内完成闭环支持，不要过度依赖外部组件(也就是不需要和其他组件打交道)。
所以你看对于「极简单的学习和理解成本」来说，目前Paimon的设计足够简单，概念虽然也很多，但是很容易理解，相比其他的湖框架学习成本够低，因为整个行业内大多数开发者没有极强的学习能力，甚至相当比例的人连基本的英文文档都看不懂，那么框架设计出来一定要足够简单易理解。
其次「主键/非主键场景支持丰富」并且不能出现明显的性能劣化，在Paimon这个框架里，它的设计对标了Hive、Kafka的概念，区分了Append Table、Append Queue、Table with PK等，只要你的基础够好，Hive、Kafka足够熟悉，可以轻松上手这些概念并在生产环境做出选型，这是其他湖框架做不到的。
另外一个很重要的「闭环思维」，大家试想一下，开发者在使用湖框架的时候他要解决什么样的问题，无非就是Source、Join、Lookup Join、其他算子、Sink。那么OK这些能力最好湖框架能自闭环搞定。所以基本的主键点查询能力、媲美Kafka一样的流读、媲美Spark一样的批读、无缝对接Flink Streaming、Flink Batch等，这些能力需要在一个框架内自闭环，最好不要和外部系统交互，目前Paimon做的非常好👍。
此外我们依次把常见的业务场景排列出来：流批一体、端到端精确一次、Join+Lookup关联、Partial Update、数据回溯订正等等，这些场景是我们在做开发的时候遇到的最多的场景，所以湖框架的着眼点应该是解决最常见的痛点问题。
目前我只能说，Paimon社区是走在正确的道路上，未来看好。
