starrocks 自动生成的时间比kafka自带消息时间戳的值小

为了更快的定位您的问题,请提供以下信息,谢谢
【详述】问题详细描述
在使用starrocks自带的kafka routine task来导入数据到starrocks表中时,有一个衍生列通过current_timestamp()来生成的,导入任务执行间隔为10s,但是数据写入到表中时发现,衍生列生成的时间竟然会比kafka消息中的时间字段值小,这个不太合理;因为任务执行间隔为10s,那衍生列值至少是大于等于kafka消息字段时间值的。
【背景】做过哪些操作?
以下是kafka routine load任务DDL:
Id: 2301861
Name: xx_xx_xx_his_test_kafka_routine_job_20231226
CreateTime: 2023-12-26 17:43:37
PauseTime: NULL
EndTime: NULL
DbName: default_cluster:app
TableName: xx_xx_xx_his_test
State: RUNNING
DataSourceType: KAFKA
CurrentTaskNum: 1
JobProperties: {“partitions”:"",“partial_update”:“false”,“columnToColumnExpr”:“ts,lastRecordTs,underlying,price,close,high,low,origin_data,dt=from_unixtime(ts / 1000, ‘%Y-%m-%d’),update_time=current_timestamp()”,“maxBatchIntervalS”:“10”,“whereExpr”:"",“dataFormat”:“json”,“timezone”:“Asia/Shanghai”,“format”:“json”,“json_root”:"",“strict_mode”:“false”,“jsonpaths”:"["$.ts","$.lastRecordTs","$.underlying","$.price","$.close","$.high","$.low","$.originData"]",“desireTaskConcurrentNum”:“1”,“maxErrorNum”:“0”,“strip_outer_array”:“false”,“currentTaskConcurrentNum”:“1”,“maxBatchRows”:“200000”}
DataSourceProperties: {“topic”:“xxx_xxx”,“currentKafkaPartitions”:“0”,“brokerList”:“xx.xx.xx.xx:9092”}
CustomProperties: {“kafka_default_offsets”:“OFFSET_END”,“group.id”:“xx_xx_xx_xx_his_kafka_routine_job_20230926_group”}
Statistic: {“receivedBytes”:1148274599,“errorRows”:0,“committedTaskNum”:11505,“loadedRows”:2482136,“loadRowsRate”:0,“abortedTaskNum”:4,“totalRows”:2482136,“unselectedRows”:0,“receivedBytesRate”:32000,“taskExecuteTimeMs”:34807711}
Progress: {“0”:“87639589”}
ReasonOfStateChanged:
ErrorLogUrls:
OtherMsg:
【业务影响】
无法获取数据的真实入库时间
【是否存算分离】

【StarRocks版本】2.3.16
【集群规模】3fe(3 follower)+ 4be(fe与be分开部署)
【机器信息】CPU虚拟核/内存/网卡,16C/64G/万兆

【联系方式】社区群15-老张
【附件】


其中ts字段是通过实时计算得出来的,而且这个ts和本地时间是对得上的,不存在时钟和时区问题,所以那update_time按道理来说,是肯定要大于或者等于这个ts的,因为kafka routine load task是异步落库,10秒才执行一次

您好,看这个时间差的只有3秒,能确定sr集群机器的本地时间和你们实时计算比如flink端的时钟不存在一些秒级的差异吗?

我看flink端和我本地的时间是基本一致的,但是也不应该差3秒吧,因为kafka routine load落数据是异步的,10s落一次。

而且我也通过本地flink计算出来得数据,得到的ts还是比通过current_timestamp()自动计算出来的大,说明不是时钟的问题了