prestosql(trino) hive时间戳显示不正确排查
TLDR: 服务器的时区设置有问题。
prestosql也老早改名trino了…
公司的数仓很早就建了且没有升级，所以版本很老。hive使用的是1.1版本,对应的ORC版本是0.12。
装了一个远古版本的prestodb，后来在2019年又装了一个prestosql。
讲完了背景说一下问题。hive中有timestamp字段的表，在hive和prestodb中显示正常，比如2022-02-19 08:00:00,但是在prestosql中显示的是2022-02-19 16:00:00，也就是多了8H。
最开始排查，检查hive,prestosql和prestodb的当前时间和时区，都显示为正常。排除物理机时区不同或者设置了不同时区。
既然数据库设置没问题，那看一下ORC,dump了一下元信息，发现对应字段类型是timestamp，dump一下数据，发现存储的是2022-02-19 08:00:00。
???
存的是2022-02-19 08:00:00？看ORC的类型可知时间戳分类两个类型，一个是UTC一个是with timezone offset的，stripe信息中没有timezone信息，为什么timestamp存的是东八区的时间，而不是UTC？
看到这个渐渐有点明朗，东八区的时间的确是2022-02-19 08:00:00，但时间戳存的也是2022-02-19 08:00:00，那也就是hive和prestodb直接把这个当作东八区来用了所以正常显示，而prestosql是认为2022-02-19 08:00:00是UTC时间，所以查询显示的时候自动加了当前时区的8小时。
再检查了一下使用的ORC版本，发现版本很低，对比release信息，这个版本是不支持timezone offset的。
找到定义文档，发现一段话：
Before ORC-135, the local timezone offset was included and they were stored as minimum and maximum. After ORC-135, the timestamp is adjusted to UTC before being converted to milliseconds and stored in minimumUtc and maximumUtc.
emmm，所以他存的timestamp实际上是包括了本地时间偏移。
再加上.(见后面分析)hive和prestodb用的版本过低，读取timestamp的时候用的就是当前时区。所以显示没问题。
而prestosql版本更新，且支持ORC的timestamp with timezone offset，那如果stripe里没有时区会怎么样呢，我们使用的版本看起来是会默认把timestamp当作UTC
经过上面一顿分析，参考trino的文档找到了一个参数hive.orc.time-zone，实测无效因为这个是341版本实装的，版本过低。
在看了一眼老版本要用参数hive.time-zone，设置回Asia/Shanghai后回复正常了。
本来以为事情就这么解决。
但后来一想这个trino升级应该不会这么不谨慎吧，如果有这个问题那应该大面积爆发且爆栈，issue很多才对。
实际上这个资料都很难搜到。
那可不可能是自己的问题呢。
再次对比prestodb和presosql，他们现在配置的区别就是prestosql设置了time-zone。
这个参数很早就支持了，那为什么prestodb不设置也可以呢。
查了下这个参数的默认值用的是JVM Default。
emmm， 那主要就是两个user.timezone这个属性。
用jcmd pid VM.system_properties检查了一下… …
果然，prestosql写的是user.timezone=UTC，而prestodb的是user.timezone=Asia/Shanghai。
破案… …
这个属性一般不用自己设置，看了下服务器，emmm，部署prestosql的用的是UTC，所以他把hive.time-zone设置为了UTC,读取ORC也错了。
哎，走了一些弯路还在怀疑版本更新之后的一些兼容性问题。
不过也是必要的，最后发现是环境问题也是因为知道了对应的参数和其默认值。
排查问题最主要的还是要尽量刨根究底，不然会有错误的认知和结论。
哎，还是太菜了 …( ＿ ＿)ノ｜。
参考资料
ORC Specification v1
Trino Release 341(8 Sep 2020)
How to set a JVM TimeZone Properly