本帖为学习交流的帖子
【 TiDB 使用环境】tiflash v5.1
【概述】 场景 + 问题概述 日志数仓
我们基于tiflash构建日志数仓,但是日志中有些字段为数组字段,我们用spark写入tiflash的时候进行了explode操作,把数组字段拆成了多行数据。这导致的问题就是,我们需要为原始数据总的每一条添加一个唯一id,这样拆分后,数组字段的多个值,对应的唯一id是相同的。但是查询聚合时,需要进行distinct操作,这很慢很慢。
大家有什么好的处理数组字段的方式吗?感谢!
本帖为学习交流的帖子
【 TiDB 使用环境】tiflash v5.1
【概述】 场景 + 问题概述 日志数仓
我们基于tiflash构建日志数仓,但是日志中有些字段为数组字段,我们用spark写入tiflash的时候进行了explode操作,把数组字段拆成了多行数据。这导致的问题就是,我们需要为原始数据总的每一条添加一个唯一id,这样拆分后,数组字段的多个值,对应的唯一id是相同的。但是查询聚合时,需要进行distinct操作,这很慢很慢。
大家有什么好的处理数组字段的方式吗?感谢!
https://asktug.com/t/topic/182835
还有这个最佳实践~你也参考一下
这个与我的问题毫无关系。。。
来自:@xfworld 不按实践的操作方式,没办法得到最好的效果
你可以参考上面的两个最佳实践。
这类数仓架构也是我们目前在用的,但是细节上各有不同。我们的痛点是数组字段导致的问题。
架构上给的支持程度不一样,实现的细节会差很多
tiflash 也是有最佳实践的,官方提供的文档是很好的参考指南
如果在数据处理上觉得有问题,就需要考虑下官方这边提供的处理方式,来改善你遇到的问题
当然,如果你对你目前的架构支持有信心,也是可以解决掉的 ![]()
另外 tiflash 是列存模型,在处理数据的时候就需要考虑下这种方式是否合适
没搞懂你想说什么
白话点,你现在的处理方案谁给你的?
方案有没有做过相应的评估,这个方案在这个场景下是否合适?
目前看来除了存储不合适,其他流程没问题。
主要是我们日志中有数组字段。
目前考虑放es了。。。
rdbms 本身是不适合很适合存放数组数据,
如果真的考虑使用 rdbms 处理这种情况,有几种思路。
此外,您反馈到,希望使用 ES。
ES 是一个非常棒的查询引擎,但我并不太建议使用 ES 代替数据存储。
ES 擅长于全文检索,但 ES 仍然也或多或少的存在某些问题,比如说
那么推翻上面的预聚合的思路,重新构想一下这一套系统
我可以使用 RDBMS → CDC → ES → RDBMS 的思路,
简单来说,就是数据的存储还要依靠 RDBMS,数据的检索依靠 ES,检索回的结果可以考虑是否要重新。因为这里重写还涉及到了一个数据校验的问题。这个需要您仔细的根据业务模型和特点思考一下。
TiDB 社区内部也有相关的操作文档,将 ES 作为查询引擎,解决您的这个问题。
可以联系社区的老师要一下文档。这么好的文档不看都糟蹋了。
感谢回复!!
这点其实我也考虑过,只是需求极不明确,BI应用方都不知道自己想要什么(需求调研我专门做过。。。),所以多数时候是要从DWD层中进行查询,就很尴尬。。。
我已经把数据做宽了,没必要join。基本全是过滤或单字段聚合类的,ES完全胜任。好像大约的确没必要再存rdbms一份
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。