Databricks中date_trunc函数的后端运行实现原理是什么？

你在PySpark侧能查到的date_trunc代码只是最上层的API封装，不包含核心执行逻辑，这个函数的实现和正则表达式完全没有关系，核心逻辑分层如下：

• 上层API层（Python/Scala/SQL入口）
  这层代码只做两类基础校验：一是校验传入的时间粒度参数是否为合法值（支持的粒度包括year/quarter/month/week/day/hour/minute/second/millisecond/microsecond），二是校验入参的字段类型为日期/时间戳类型，校验完成后会把调用转换为Catalyst优化器可识别的TruncDate/TruncTimestamp逻辑表达式节点，没有任何实际的截断计算逻辑，也不存在正则处理。
• 核心执行层
  这层分两套实现，逻辑一致只是开发语言和性能不同：
  1. 开源Spark兼容实现：逻辑实现在JVM侧的Catalyst表达式模块，基于Java 8的java.time时间工具包实现，本质是直接对时间对象的对应字段做置位操作——比如截断到月粒度时，直接将日期的“日”字段设为当月1号，时、分、秒、小数秒字段全部置0；截断到小时粒度时，直接将分、秒、小数秒字段置0，全程是直接操作时间对象的属性，不会把时间转成字符串处理，完全不涉及正则匹配。
  2. Databricks Photon引擎实现：这部分是Databricks闭源的C++原生实现，性能比开源Java实现高一个量级，核心逻辑比开源版更直接：直接操作时间戳的内部存储值（即从Unix纪元开始累计的微秒/毫秒长整型数值）做时间粒度对齐计算，连Java时间对象的构造开销都省了，更不可能走字符串正则的路径。

补充说明：Databricks Photon引擎的核心C++代码不对外开源，你没法直接查到这部分的源码。如果要参考逻辑完全对齐的开源实现，可以查看Spark Catalyst模块中TruncTimestamp表达式的计算逻辑，和Databricks上date_trunc的公开行为完全一致，差异仅在执行性能层面。

• 常见认知误区：不要把date_trunc和字符串处理类的时间函数混淆，所有原生时间截断函数都是直接操作时间类型的内部数值存储，不会做“时间转字符串-正则匹配截断-字符串转时间”的冗余流程，这类流程性能比直接数值操作低数十倍，不会被大数据引擎采用。只有当你传入的入参是字符串类型、触发隐式类型转换时，才会走时间格式解析逻辑，这部分属于类型转换的范畴，不是date_trunc本身的实现逻辑。

内容的提问来源于stack exchange，提问作者memo