我在Clickhouse中的SQL使用呢DictGet来关联一些纬度数据,应当如何迁移到Doris中?

Viewed 36

我在Clickhouse中的SQL使用呢dictGet来关联一些位于字典表中的纬度数据,最近在调研数据迁移到Doris中,不过根据查阅文档,Doris中应该是没有直接对等的功能。

主要问题

所以迁移到Doris中最佳实践是替换为Join?或者是否有类似的其它方案?

场景咨询

我的一个场景是,纬度表中存放了IP与一些数据的映射关系,clickhouse中,在SQL查询阶段,会通过数据的IP字段,利用DictGet函数,来将数据关联到到查询结果数据上。经过查阅文档,Doris应该并没有可以直接对等的方案(如果说得不对还请指正)。目前我想到的办法是使用Join来重写SQL。

对于Join来说,我查阅Doris的文档,采用Colocation Join来进行Join是效率最高的,但其会要求数据按照设置的分桶来存储。

在上述场景中,纬度表中的IP是相对分散的。但事实表中的IP数据可能不是那么分散,由于触发Colocation Join对分桶有要求,我这种场景是否适合使用Colocation Join

由于一些特殊原因,需要在即席查询是进行关联。故这个问题主要是针对查询阶段。

Discussion

这个问题我在Doris的Discussion中也有咨询,我会持续关注两边的答复。

Version

2.02.1均可。
如果答复有版本限制,还请说明。

谢谢!

1 Answers

在Doris中,如果需要替换Clickhouse中的dictGet功能,通常是使用Join操作来实现维度数据的关联。对于您提到的场景,由于纬度表中的IP数据相对分散,而事实表中的IP数据可能不具备同样的分散性,这会对使用Colocation Join造成一定的限制。

Colocation Join的优势在于避免了数据Shuffle,从而提高了Join的效率,但这依赖于数据按照特定的分桶方式存储,以便可以直接在对应的节点上执行Join操作。如果纬度表和事实表的IP数据分布不适合Colocation Join的要求,那么可能需要考虑以下方案:

  1. 使用Broadcast Join:如果纬度表不大,可以采用Broadcast Join,将纬度表广播到所有节点,这样每个节点都可以在本地进行Join操作。但要注意,如果纬度表数据量较大,这种方式可能会导致网络开销增大。
  2. 使用Shuffle Join或Bucket Shuffle Join:如果无法使用Broadcast Join,或者想避免其网络开销,可以选择Shuffle Join或Bucket Shuffle Join。这两种方式会根据Join条件对数据进行Shuffle,使得具有相同键的数据分布到相同的节点上。
  3. 具体可以参考Doris Join优化

如果事实表中的IP数据不是特别分散,但仍然希望能够利用延迟物化的特性来优化性能,可以考虑使用Doris提供的Runtime Filter。这可以在Join之前对数据进行过滤,减少实际需要Join的数据量。
如果即席查询对性能要求很高,且纬度表数据量不大,Broadcast Join可能是一个合理的选择。
如果不适合使用Colocation Join,可以考虑对数据进行预处理,例如通过建立索引或者物化视图来加速查询。