使用SQOOP同步数据时timestamp字段格式异常问题

我之前处理过几乎一模一样的场景，当时踩了好几个坑，给你分享几个可行的解决思路，按推荐程度排序：

• 从Oracle数据源层面预处理（最推荐）
  直接在SQOOP抽取数据的SQL里，用Oracle的TO_CHAR函数把timestamp字段格式化成标准的无空格格式，从源头避免转换bug。比如：

  SELECT 
    TO_CHAR(your_timestamp_column, 'YYYY-MM-DD HH24:MI:SS.FF9') AS formatted_timestamp,
    other_column1,
    other_column2
  FROM your_oracle_table 
  WHERE $CONDITIONS
  

  然后在SQOOP命令里，把这个格式化后的字段映射成java.sql.Timestamp类型，确保导入到Parquet时类型正确：

  sqoop import \
    --connect jdbc:oracle:thin:@your_oracle_host:1521/your_service_name \
    --username your_username \
    --password your_password \
    --query "上面的SQL语句" \
    --map-column-java formatted_timestamp=java.sql.Timestamp \
    --target-dir /hdfs/path/to/your/parquet \
    --as-parquetfile \
    --split-by your_split_column
  

  这个方法从根源上解决了格式问题，不依赖SQOOP的类型转换逻辑，稳定性最高。

• 升级SQOOP版本并配置时区
  有些旧版本的SQOOP（比如1.4.6及以下）对Oracle TIMESTAMP类型的毫秒解析存在bug，会导致多余空格。先尝试升级到SQOOP 1.4.7或更高版本，同时在导入命令中指定Oracle会话时区，帮助SQOOP更准确解析时间字段：

  sqoop import \
    --connect jdbc:oracle:thin:@your_oracle_host:1521/your_service_name \
    --username your_username \
    --password your_password \
    --table your_oracle_table \
    --target-dir /hdfs/path/to/your/parquet \
    --as-parquetfile \
    --split-by your_split_column \
    --driver oracle.jdbc.OracleDriver \
    --conf sqoop.oracle.sessionTimeZone=UTC
  

  注意时区要和Oracle数据库的时区保持一致，或者根据业务需求调整。

• 导入后用Spark做数据清洗（补救方案）
  如果已经导入了有问题的数据，或者前面的方法无法实施，可以用Spark读取Parquet文件后做二次处理：

  import org.apache.spark.sql.functions._
  import org.apache.spark.sql.types.TimestampType
  
  // 读取有问题的Parquet数据
  val rawDf = spark.read.parquet("/hdfs/path/to/bad_parquet")
  
  // 修复timestamp字段：替换毫秒前的空格
  val cleanedDf = rawDf
    .withColumn(
      "fixed_timestamp",
      regexp_replace(col("your_timestamp_column").cast("string"), "\\. ", "\\.").cast(TimestampType)
    )
    .drop("your_timestamp_column")
    .withColumnRenamed("fixed_timestamp", "your_timestamp_column")
  
  // 写入修复后的Parquet文件
  cleanedDf.write.mode("overwrite").parquet("/hdfs/path/to/fixed_parquet")
  

  这个方法属于事后补救，适合紧急处理已存在的错误数据。

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