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

Viewed 39
query

我在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.0和2.1均可。
如果答复有版本限制，还请说明。

谢谢！

____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，可以考虑对数据进行预处理，例如通过建立索引或者物化视图来加速查询。

张彬华6972