tidb 4.0.1,tispark 2.3.0-rc.1,限定条件读取tikv,返回数据集过大，好像没有用到过滤条件

🛸 其他技术问题 TiSpark
1

我们有几张表是按照如下规则创建的（对某列取crc32 % 9999做为伪分区字段，并且有一个自动填充的时间字段）：

image
image776×339 11.8 KB

我们的读取语句为：select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > ‘2020-06-22 14:34:19’ 所有分区大约1.2亿数据，时间过滤之后就很少了也就10几万数据。
在tidb3.x，tispark 2.1时，这样完全没有问题；升级到最新版之后，就报oom。然后把改成：select * from table where primary_partition >= 0 and primary_partition < 5000 and last_modify_time > ‘2020-06-22 14:34:19’ 和
select * from table where primary_partition >= 5000 and primary_partition < 10000 and last_modify_time > ‘2020-06-22 14:34:19’ 分两个批次执行，就可以。
是不是新版tispark这里没有把计算推到存储底层，直接就返回了

2

请设置一下这个参数 spark.tispark.coprocess.codec_format=default 试试

3

加上这个配置也不行，还是oom，这个参数在文档上没找见，作用是啥啊？

4

能否

  1. 提供一下错误堆栈？
  2. 运行一下 explain select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > ‘2020-06-22 14:34:19’ 看下执行计划？
  3. 试一下 select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > timestamp ‘2020-06-22 14:34:19’
5

文档已添加

6

tikv本身没有异常，spark这里报了个没啥价值的信息：

image
image1114×203 32 KB

执行计划如下：

image
image1738×188 4.87 KB

tispark 2.1版本正常。到了新版就不行了。

7

改写成这样可以运行吗？

select * from table where primary_partition >= 0 and primary_partition < 10000 and last_modify_time > timestamp ‘2020-06-22 14:34:19’

1 个赞
8

测试了，这样是可以的。我看了执行计划都不一样。

image
image1748×165 4.7 KB

9

image
image1813×960 15.4 KB

我这个article_id是有索引的，新版tispark也不会走索引了吗？

10

这是另外一个问题吗？可以再开一个issue，提供一下schema信息

11

schema也是我开始的那种。

12

能提供一下 tidb 的执行计划吗？

13

image
image1133×327 11.3 KB

14

另外这个原因是什么？ tispark 2.3改了处理方式？类型不匹配要取回来然后转换成过滤条件类型，在比对？

15

这个和tispark的版本没关系，spark没有做类型的隐式转换，需要在字符串前面加上 timestamp

16

不是吧，我们用tispark 2.1版本就可以啊

17

请先通过tidb运行一下

analyze table ok_chi.perio_artical;

然后再通过tispark运行一下 explain

18

可以运行意味着没有oom，并不能表示字符串被隐式转换成了timestamp，并下推

19

就是说啊，完全一样的处理逻辑，在tispark 2.1是可以，没有任何报错；在tispark 2.3就不行了，就oom了:cold_sweat:

20

方便的话能否比对一下 tispark 2.1 时候的 explain 结果和现在的结果有何区别？