tiflash构建日志数仓

本帖为学习交流的帖子

【 TiDB 使用环境】tiflash v5.1

【概述】 场景 + 问题概述 日志数仓

我们基于tiflash构建日志数仓,但是日志中有些字段为数组字段,我们用spark写入tiflash的时候进行了explode操作,把数组字段拆成了多行数据。这导致的问题就是,我们需要为原始数据总的每一条添加一个唯一id,这样拆分后,数组字段的多个值,对应的唯一id是相同的。但是查询聚合时,需要进行distinct操作,这很慢很慢。
大家有什么好的处理数组字段的方式吗?感谢!

1赞

参考下~

1赞

还有这个最佳实践~你也参考一下

1赞

这个与我的问题毫无关系。。。

1赞

来自:@xfworld 不按实践的操作方式,没办法得到最好的效果

你可以参考上面的两个最佳实践。

1赞

这类数仓架构也是我们目前在用的,但是细节上各有不同。我们的痛点是数组字段导致的问题。

1赞

架构上给的支持程度不一样,实现的细节会差很多
tiflash 也是有最佳实践的,官方提供的文档是很好的参考指南
如果在数据处理上觉得有问题,就需要考虑下官方这边提供的处理方式,来改善你遇到的问题

当然,如果你对你目前的架构支持有信心,也是可以解决掉的 :grinning:
另外 tiflash 是列存模型,在处理数据的时候就需要考虑下这种方式是否合适

1赞

没搞懂你想说什么

1赞

白话点,你现在的处理方案谁给你的?
方案有没有做过相应的评估,这个方案在这个场景下是否合适?

1赞

目前看来除了存储不合适,其他流程没问题。
主要是我们日志中有数组字段。
目前考虑放es了。。。

1赞

道友请留步

要不要使用 RDBMS 来处理您的问题

rdbms 本身是不适合很适合存放数组数据,
如果真的考虑使用 rdbms 处理这种情况,有几种思路。

  1. 预聚合操作
    类似 kylin 的 cube 模式,或者 clickhouse 拼宽表的行为,可以考虑预先定义处理的模型。
    无论实时数仓,还是离线数仓,本质上都是数仓,都需要建模。
    如果暴力的想从 ods 层抽取报表的话,其实难度还是挺大的。
  2. 将逻辑计算从数仓中剥离
    其实您已经在 spark 中进行了 explode 操作,如果可以考虑将 distinct 的业务逻辑也放在 spark 中,
    将结果落盘到数仓中也是可以的。

要不要适用 ES 来处理您的问题

此外,您反馈到,希望使用 ES。
ES 是一个非常棒的查询引擎,但我并不太建议使用 ES 代替数据存储。
ES 擅长于全文检索,但 ES 仍然也或多或少的存在某些问题,比如说

  1. ES 管理成本上相比于 rdbms 稍微复杂一些,比如扩容操作,消息队列采集还有双写问题
  2. ES 对于 group by,join 的支持是不够好的
  3. ES 可能涉及到了写入延迟问题
  4. ES 可能还涉及到了事务的问题,当然您是数仓,可能也不涉及到事务

将 ES 单独作为搜索引擎处理您的问题

那么推翻上面的预聚合的思路,重新构想一下这一套系统
我可以使用 RDBMS -> CDC -> ES -> RDBMS 的思路,
简单来说,就是数据的存储还要依靠 RDBMS,数据的检索依靠 ES,检索回的结果可以考虑是否要重新。因为这里重写还涉及到了一个数据校验的问题。这个需要您仔细的根据业务模型和特点思考一下。
TiDB 社区内部也有相关的操作文档,将 ES 作为查询引擎,解决您的这个问题。
可以联系社区的老师要一下文档。这么好的文档不看都糟蹋了。

2赞

感谢回复!!

这点其实我也考虑过,只是需求极不明确,BI应用方都不知道自己想要什么(需求调研我专门做过。。。),所以多数时候是要从DWD层中进行查询,就很尴尬。。。

我已经把数据做宽了,没必要join。基本全是过滤或单字段聚合类的,ES完全胜任。好像大约的确没必要再存rdbms一份

1赞