道友请留步
要不要使用 RDBMS 来处理您的问题
rdbms 本身是不适合很适合存放数组数据，
如果真的考虑使用 rdbms 处理这种情况，有几种思路。
- 预聚合操作
类似 kylin 的 cube 模式，或者 clickhouse 拼宽表的行为，可以考虑预先定义处理的模型。
无论实时数仓，还是离线数仓，本质上都是数仓，都需要建模。
如果暴力的想从 ods 层抽取报表的话，其实难度还是挺大的。 - 将逻辑计算从数仓中剥离
其实您已经在 spark 中进行了 explode 操作，如果可以考虑将 distinct 的业务逻辑也放在 spark 中，
将结果落盘到数仓中也是可以的。
要不要适用 ES 来处理您的问题
此外，您反馈到，希望使用 ES。
ES 是一个非常棒的查询引擎，但我并不太建议使用 ES 代替数据存储。
ES 擅长于全文检索，但 ES 仍然也或多或少的存在某些问题，比如说
- ES 管理成本上相比于 rdbms 稍微复杂一些，比如扩容操作，消息队列采集还有双写问题
- ES 对于 group by，join 的支持是不够好的
- ES 可能涉及到了写入延迟问题
- ES 可能还涉及到了事务的问题，当然您是数仓，可能也不涉及到事务
将 ES 单独作为搜索引擎处理您的问题
那么推翻上面的预聚合的思路，重新构想一下这一套系统
我可以使用 RDBMS → CDC → ES → RDBMS 的思路，
简单来说，就是数据的存储还要依靠 RDBMS，数据的检索依靠 ES，检索回的结果可以考虑是否要重新。因为这里重写还涉及到了一个数据校验的问题。这个需要您仔细的根据业务模型和特点思考一下。
TiDB 社区内部也有相关的操作文档，将 ES 作为查询引擎，解决您的这个问题。
可以联系社区的老师要一下文档。这么好的文档不看都糟蹋了。