我想将一个大的(超过150万条记录和700列)表格从一个Hive数据库转移到另一个Hive数据库,其中包括一些转换,例如在日期列上使用一个强制转换, substr 和一个简单的 case 语句。
所以,像这样:
-- initial settings
SET hive.exec.dynamic.partition=true;
SET hive.exec.dynamic.partition.mode=nonstrict;
SET hive.exec.compress.intermediate=true;
SET hive.exec.parallel=true;
SET parquet.compression=SNAPPY;
SET hive.optimize.sort.dynamic.partition=true;
SET hive.merge.size.per.task=1000000000;
SET hive.merge.smallfiles.avgsize=1000000000;
INSERT INTO databaseA.tableName PARTITION(parition_col)
CASE WHEN a='Something' THEN 'SOMETHING'
WHEN a is null THEN 'Missing'
ELSE a END AS a,
column1,
column2,
...
cast(to_date(from_unixtime(unix_timestamp(),'yyyy-MM-dd')) AS string) AS
run_date,
substr(some_string, 1, 3)
FROM databaseB.tableName;
问题是这个查询需要花费很多时间(每小时1百万行)。也许有人知道如何加快速度?
我正在使用map reduce引擎执行此任务。
谢谢!
答案 0 :(得分:0)
由于Hive表中的所有数据都是HDFS上的文件,为什么不将文件直接移动/复制到新表格的HDFS位置。
示例:
Assuming the table you want to move is already present in db1 as table_to_cpy;
create database db2;
create table db2.table_to_cpy like db1.table_to_cpy;
desc formatted db1.table_to_cpy;
--copy the hdfs table path ---> /user/hive/warehouse/db1.db/table_to_cpy
desc formatted db2.table_to_cpy;
--copy the hdfs table path ---> /user/hive/warehouse/db2.db/table_to_cpy
hadoop fs -cp /user/hive/warehouse/db1.db/table_to_cpy/* /user/hive/warehouse/db2.db/table_to_cpy/.
答案 1 :(得分:0)
关于如何加快查询速度的建议很少:
尽可能避免使用unix_timestamp()。此函数是非确定性的并且阻止了对查询的正确优化,它将在每个映射器或缩减器中执行,并且可能返回不同的值。改为使用
current_date()AS run_date
有关详情,请参阅此答案:https://stackoverflow.com/a/41140298/2700344
调整映射器和缩减器并行度。如果你的进程以一个大文件(20 GB)而不是一些小文件结束,那么显然没有足够的并行性。
对于地图制作者,请使用以下设置:
set mapreduce.input.fileinputformat.split.minsize=16777216; -- 16 MB
set mapreduce.input.fileinputformat.split.minsize=1073741824; -- 1 GB
减少hive.exec.reducers.bytes.per.reducer
以增加减速器的数量。
使用这些设置进行播放。成功标准是更多的映射器/缩减器,并且您的map和reduce阶段运行得更快。
有关详细信息,请参阅此答案:https://stackoverflow.com/a/42842117/2700344
distribute by parition_col
它将根据分区键在reducers之间分发数据,因此每个reducer将创建更少的分区并消耗更少的内存。此外,它有助于避免太多小输出文件。此设置应与hive.exec.reducers.bytes.per.reducer
一起使用,以避免缩减器之间分布不均匀的问题,并避免输出文件过大。