在实际工作中大家应该多多少少都用到#xff0c;这个文章是一个简单的使用体会。

不涉及湖框架的拉踩#xff0c;我们的着眼点是解决实际问题。

我来结合自身体会跟大家说说Paimon这个框架和对未来的一些判断。

大家可以参考#x…

Apache

在实际工作中大家应该多多少少都用到这个文章是一个简单的使用体会。

不涉及湖框架的拉踩我们的着眼点是解决实际问题。

我来结合自身体会跟大家说说Paimon这个框架和对未来的一些判断。

大家可以参考错了也不要怪我误导你。

Evolution、流读流写、批读批写、ACID等几个通用的能力。

但是我们必须指出一点这几个通用能力不是生产环境都需要的我们拿Schema

Evolution举例在真正大型的、重要的生产环境其实是非常不推荐使用这种能力不是因为它不够强大而是因为他带来的风险和收益不成比例没有一个开发愿意冒着背故障的风险去做这样的设计。

所以我们站在业务开发的角度去考虑问题和站在平台开发角度考虑问题呈现了不同的诉求。

那么站在业务开发的角度也就是用户的角度一些诉求如下极简单的学习和理解成本、流批读写足够简单、主键/非主键场景支持丰富、最好能在领域内完成闭环支持不要过度依赖外部组件(也就是不需要和其他组件打交道)。

所以你看对于「极简单的学习和理解成本」来说目前Paimon的设计足够简单概念虽然也很多但是很容易理解相比其他的湖框架学习成本够低因为整个行业内大多数开发者没有极强的学习能力甚至相当比例的人连基本的英文文档都看不懂那么框架设计出来一定要足够简单易理解。

其次「主键/非主键场景支持丰富」并且不能出现明显的性能劣化在Paimon这个框架里它的设计对标了Hive、Kafka的概念区分了Append

Table、Append

PK等只要你的基础够好Hive、Kafka足够熟悉可以轻松上手这些概念并在生产环境做出选型这是其他湖框架做不到的。

另外一个很重要的「闭环思维」大家试想一下开发者在使用湖框架的时候他要解决什么样的问题无非就是Source、Join、Lookup

Join、其他算子、Sink。

那么OK这些能力最好湖框架能自闭环搞定。

所以基本的主键点查询能力、媲美Kafka一样的流读、媲美Spark一样的批读、无缝对接Flink

Streaming、Flink

Batch等这些能力需要在一个框架内自闭环最好不要和外部系统交互目前Paimon做的非常好。

此外我们依次把常见的业务场景排列出来流批一体、端到端精确一次、JoinLookup关联、Partial

Update、数据回溯订正等等这些场景是我们在做开发的时候遇到的最多的场景所以湖框架的着眼点应该是解决最常见的痛点问题。

如果这个文章对你有帮助不要忘记