amazon-s3 - Hive - 动态分区 : Long loading times with a lot of partitions when updating table

Question

我通过 AWS EMR 运行 Hive，并且有一个经常将日志数据解析到 S3 的作业流。我对解析的 Hive 表使用动态分区(日期和日志级别)。

当我有几 GB 的数据和很多分区时，现在永远需要做的一件事是 Hive 在解析完成后将数据加载到表中。

Loading data to table default.logs partition (dt=null, level=null)
    ...
    Loading partition {dt=2013-08-06, level=INFO}
    Loading partition {dt=2013-03-12, level=ERROR}
    Loading partition {dt=2013-08-03, level=WARN}
    Loading partition {dt=2013-07-08, level=INFO}
    Loading partition {dt=2013-08-03, level=ERROR}
    ...

    Partition default.logs{dt=2013-03-05, level=INFO} stats: [num_files: 1, num_rows: 0, total_size: 1905, raw_data_size: 0]
    Partition default.logs{dt=2013-03-06, level=ERROR} stats: [num_files: 1, num_rows: 0, total_size: 4338, raw_data_size: 0]
    Partition default.logs{dt=2013-03-06, level=INFO} stats: [num_files: 1, num_rows: 0, total_size: 828250, raw_data_size: 0]
    ...
    Partition default.logs{dt=2013-08-14, level=INFO} stats: [num_files: 5, num_rows: 0, total_size: 626629, raw_data_size: 0]
    Partition default.logs{dt=2013-08-14, level=WARN} stats: [num_files: 4, num_rows: 0, total_size: 4405, raw_data_size: 0]

有没有办法克服这个问题并减少这一步的加载时间？

我已经尝试通过存储桶生命周期规则将旧日志存档到 Glacier，希望 Hive 会跳过加载存档分区。好吧，由于这仍然使文件(路径)在 S3 中可见，因此 Hive 无论如何都会识别存档分区，因此不会获得任何性能。

更新 1

数据的加载是通过简单地将数据插入到动态分区表中来完成的

INSERT INTO TABLE logs PARTITION (dt, level)
SELECT time, thread, logger, identity, message, logtype, logsubtype, node, storageallocationstatus, nodelist, userid, nodeid, path, datablockid, hash, size, value, exception, server, app, version, dt, level
FROM new_logs ;

来自一张包含未解析日志的表

CREATE EXTERNAL TABLE new_logs (
  dt STRING,
  time STRING,
  thread STRING,
  level STRING,
  logger STRING,
  identity STRING,
  message STRING,
  logtype STRING,
  logsubtype STRING,
  node STRING,
  storageallocationstatus STRING,
  nodelist STRING,
  userid STRING,
  nodeid STRING,
  path STRING,
  datablockid STRING,
  hash STRING,
  size STRING,
  value STRING,
  exception STRING,
  version STRING
)
PARTITIONED BY (
  server STRING,
  app STRING
)
ROW FORMAT
  DELIMITED
  FIELDS TERMINATED BY '\t'
STORED AS
  INPUTFORMAT 'org.maz.hadoop.mapred.LogFileInputFormat'
  OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.IgnoreKeyTextOutputFormat'
LOCATION 's3://my-log/logs/${LOCATION}' ;

进入新的(解析的)表

CREATE EXTERNAL TABLE logs (
  time STRING,
  thread STRING,
  logger STRING,
  identity STRING,
  message STRING,
  logtype STRING,
  logsubtype STRING,
  node STRING,
  storageallocationstatus STRING,
  nodelist STRING,
  userid STRING,
  nodeid STRING,
  path STRING,
  datablockid STRING,
  hash STRING,
  size STRING,
  exception STRING,
  value STRING,
  server STRING,
  app STRING,
  version STRING
)
PARTITIONED BY (
  dt STRING,
  level STRING
)
ROW FORMAT
  DELIMITED
  FIELDS TERMINATED BY '\t'
  LINES TERMINATED BY '\n'
STORED AS TEXTFILE
LOCATION 's3://my-log/parsed-logs' ;

输入格式 (LogFileInputFormat) 负责将日志条目解析为所需的日志格式。

更新 2

当我尝试以下操作时

INSERT INTO TABLE logs PARTITION (dt, level)
SELECT time, thread, logger, identity, message, logtype, logsubtype, node, storageallocationstatus, nodelist, userid, nodeid, path, datablockid, hash, size, value, exception, server, app, version, dt, level
FROM new_logs
WHERE dt > 'some old date';

Hive 仍然在日志中加载所有分区。另一方面，如果我使用静态分区，例如

INSERT INTO TABLE logs PARTITION (dt='some date', level)
SELECT time, thread, logger, identity, message, logtype, logsubtype, node, storageallocationstatus, nodelist, userid, nodeid, path, datablockid, hash, size, value, exception, server, app, version, level
FROM new_logs
WHERE dt = 'some date';

Hive 仅加载相关分区，但随后我需要为我认为可能出现在 new_logs 中的每个日期创建一个查询。通常 new_logs 只包含今天和昨天的日志条目，但也可能包含旧条目。

静态分区是我目前选择的解决方案，但没有其他(更好的)解决方案可以解决我的问题吗？

Answer 1

在这个缓慢的阶段，Hive 获取它为每个分区构建的文件，并将其从临时目录移动到永久目录。您可以在称为移动运算符的“解释扩展”中看到这一点。

因此，对于每个分区，它都是对 Metastore 的一次移动和更新。我不使用 EMR，但我认为这种将文件移动到 S3 的行为对于它需要移动的每个文件都有很高的延迟。

从你写的内容中不清楚的是你每次运行时是否都在做满载。例如，为什么你有一个 2013-03-05 分区？您是否正在获取包含此旧日期的新日志数据？如果此数据已经在您的日志表中，您应该修改您的插入语句，如

SELECT fields
FROM new_logs
WHERE dt > 'date of last run';

这样，您将只获得几个存储桶和几个要移动的文件。从 new_logs 扫描所有这些额外数据仍然很浪费，但您可以通过对 new_logs 进行分区来解决这个问题。