Parquet的timestamp类型转为long

针对 Spark SQL 使用 Parquet 文件存储时,默认使用 int96 类型保存 Timestamp 的问题,提供了一个 Java 工具类用于将 Parquet 文件中的 Timestamp 转换为标准的毫秒级时间戳。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

由于sparksql使用parquet文件存储数据时,有个默认参数spark.sql.parquet.int96AsTimestamp为true,即为保持精度,使用96位的int来存储Timestamp类型,这就为使用java代码解析Timestamp类型带来了麻烦,下面为转换工具类(代码为从github上找的,不是自己写的)。

package com.test.util;

import java.util.concurrent.TimeUnit;

import org.apache.parquet.io.api.Binary;

import com.google.common.primitives.Ints;
import com.google.common.primitives.Longs;

public class ParquetTimestampUtils {
	
	/**
	 * julian date的偏移量,2440588相当于1970/1/1
	 */
	private static final int JULIAN_EPOCH_OFFSET_DAYS = 2440588;
    private static final long MILLIS_IN_DAY = TimeUnit.DAYS.toMillis(1);
    private static final long NANOS_PER_MILLISECOND = TimeUnit.MILLISECONDS.toNanos(1);

    private ParquetTimestampUtils() {}

    /**
     * Returns GMT timestamp from binary encoded parquet timestamp (12 bytes - julian date + time of day nanos).
     *
     * @param timestampBinary INT96 parquet timestamp
     * @return timestamp in millis, GMT timezone
     */
    public static long getTimestampMillis(Binary timestampBinary)
    {
        if (timestampBinary.length() != 12) {
        	return 0;
//            throw new PrestoException(HIVE_BAD_DATA, "Parquet timestamp must be 12 bytes, actual " + timestampBinary.length());
        }
        byte[] bytes = timestampBinary.getBytes();

        // little endian encoding - need to invert byte order
        long timeOfDayNanos = Longs.fromBytes(bytes[7], bytes[6], bytes[5], bytes[4], bytes[3], bytes[2], bytes[1], bytes[0]);
        int julianDay = Ints.fromBytes(bytes[11], bytes[10], bytes[9], bytes[8]);

        return julianDayToMillis(julianDay) + (timeOfDayNanos / NANOS_PER_MILLISECOND);
    }

    private static long julianDayToMillis(int julianDay)
    {
        return (julianDay - JULIAN_EPOCH_OFFSET_DAYS) * MILLIS_IN_DAY;
    }
}



使用的时候

long date = ParquetTimestampUtils.getTimestampMillis(record.getInt96("CREATE_TIME", 0));



<think>好的,用户现在问的是“SQL on Hadoop是什么”,之前已经讨论过数据湖架构,我需要确保回答连贯,并且覆盖用户可能关心的点。 首先,回想用户之前的提问是关于数据湖的构建和管理,现在转向SQL on Hadoop,可能是在数据湖的查询处理方面有需求。用户可能是想了解如何利用SQL在Hadoop生态系统中进行数据分析,或者是在构建数据湖时考虑查询工具的选择。 接下来,我需要明确SQL on Hadoop的定义。它指的是在Hadoop分布式文件系统(HDFS)上使用SQL查询数据的技术。Hadoop本身处理大数据但缺乏友好的查询接口,SQL on Hadoop工具的出现解决了这个问题,让熟悉SQL的用户能更方便地操作Hadoop中的数据。 然后,要列出常见的工具,比如Hive、Impala、Presto、Spark SQL,这些工具各有特点。比如Hive适合批处理,Impala适合交互式查询,而Presto支持跨数据源查询。需要解释每个工具的特点,帮助用户根据场景选择。 还要考虑用户可能的深层需求,比如他们是否关心性能优化、架构设计或者与现有系统的集成。比如在数据湖中使用SQL on Hadoop作为查询层,用户可能想知道如何整合这些工具到现有的数据湖架构中,特别是之前提到的存储层、处理层等。 另外,技术原理部分需要简要说明,比如Hive如何将SQL转为MapReduce,Impala的MPP架构,Presto的内存计算等。这些信息帮助用户理解不同工具的工作机制,从而做出更合适的选择。 应用场景方面,用户可能想知道何时使用这些工具。比如交互式分析适合Impala,ETL处理用Hive,即席查询用Presto。结合之前的数据湖案例,比如金融风控项目中的查询需求,可以举例说明SQL on Hadoop如何提升效率。 挑战部分也不能忽略,比如性能调优、小文件问题、元数据管理等,这些都是用户在实际应用中可能遇到的问题。需要给出解决方案,比如分区优化、使用ORC/Parquet格式、定期合并小文件等,这些建议能帮助用户避免常见陷阱。 最后,总结部分要强调SQL on Hadoop在数据湖中的作用,以及如何选择合适的工具,呼应之前讨论的数据湖架构,确保整体架构的高效性。同时,提到与云平台的结合,可能用户的环境是混合云或公有云,需要考虑工具的支持情况。 在回答时,要保持结构清晰,分点说明,使用用户熟悉的术语,比如之前提到的存储层、处理层、元数据管理等,让用户能够将新信息与已有知识联系起来。同时,避免使用过于技术化的语言,确保解释通俗易懂。</think>以下是关于$SQL\ on\ Hadoop$的架构解析与实践总结: $$ \text{SQL on Hadoop} = \text{HDFS数据存储} + \text{分布式计算引擎} + \text{SQL解析层} $$ ### 一、核心定义 1. **技术定位** - 在Hadoop生态系统中实现类SQL查询的解决方案集合 - 突破MapReduce编程范式,通过SQL接口访问HDFS/Hive数据 $$ Q_{latency} \propto \frac{\text{数据量}}{\text{集群规模} \times \text{执行引擎效率}} $$ 2. **典型工具** | 工具名称 | 执行模式 | 典型延迟 | 适用场景 | |---|---|---|---| | Hive | 批处理 | 分钟级 | ETL作业 | | Impala | MPP | 秒级 | 交互查询 | | Presto | 分布式 | 亚秒级 | 即席分析 | | Spark SQL | 内存计算 | 可变 | 混合负载 | ### 二、关键技术原理 1. **架构分层** ```mermaid graph TD A[SQL接口] --> B(语法解析) B --> C{执行引擎选择} C --> D[MapReduce] C --> E[Tez] C --> F[Spark] D/E/F --> G[HDFS/HBase] ``` 2. **核心组件** - **Hive**:通过HQL转MapReduce,元数据存储在Metastore ```sql CREATE TABLE user_behavior ( user_id BIGINT, action_time TIMESTAMP ) STORED AS ORC; ``` - **Impala**:采用MPP架构,直接读写HDFS数据 $$ T_{response} = \sum_{i=1}^{n} \frac{\text{数据分片}_i}{\text{节点计算速度}_i} $$ - **Presto**:内存流水线计算,支持跨数据源联邦查询 ### 三、关键优化技术 1. **存储加速** - 列式存储:ORC/Parquet格式压缩比可达$10\times$ - 分区优化:按时间/地域分区的查询效率提升公式: $$ \frac{T_{partition}}{T_{fullscan}} = \frac{1}{N_{partitions}} $$ 2. **执行优化** - 谓词下推:将WHERE条件提前到存储层 - 动态分区裁剪:通过统计信息减少IO - Cost-based优化器(CBO)选择最优执行计划 ### 四、典型应用场景 1. **交互式分析** - 使用Impala/Presto实现亚秒级响应 - 案例:银行实时反欺诈查询 ```sql SELECT user_id, COUNT(*) FROM transaction_log WHERE tx_time > NOW() - INTERVAL '5' MINUTE GROUP BY user_id HAVING COUNT(*) > 10; ``` 2. **大规模ETL** - 利用Hive处理PB级数据清洗 - 优化案例: ```sql INSERT OVERWRITE TABLE user_profile SELECT uid, COLLECT_SET(interest) FROM raw_behavior CLUSTER BY uid; ``` ### 五、挑战与解决方案 1. **小文件问题** - 合并策略:定期执行`ALTER TABLE ... CONCATENATE` - 写入优化:设置`hive.merge.size.per.task=256MB` 2. **元数据管理** - Metastore高可用部署 - 使用Hive ACID特性保证事务一致性 3. **资源竞争** - 通过YARN Capacity Scheduler分配资源 - 设置队列权重: ```xml <property> <name>yarn.scheduler.capacity.root.queues</name> <value>etl,query</value> </property> ``` ### 六、新一代演进方向 1. **云原生支持**:与对象存储(如S3/OBS)深度集成 2. **LLAP架构**:Hive的Live Long and Process提升交互速度 3. **向量化执行**:通过SIMD指令提升CPU利用率 $$ \text{加速比} = \frac{\text{标量执行时间}}{\text{向量化执行时间}} \approx 4-10\times $$
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值