我使用的是Cloudera5.16和Hadoop2.6。
我使用importtsv将大型csv文件加载到hbase中。
hbase org.apache.hadoop.hbase.mapreduce.ImportTsv -Dimporttsv.separator=';' -Dimporttsv.columns=HBASE_ROW_KEY,data:name,data:age mynamespace:mytable /path/to/csv/dir/*.csv
我的问题是,不管文件大小如何(我有300k行的文件,其他有1k行的文件),操作需要20到30秒。
19/08/22 15:11:56 INFO mapreduce.Job: Job job_1566288518023_0335 running in uber mode : false
19/08/22 15:11:56 INFO mapreduce.Job: map 0% reduce 0%
19/08/22 15:12:06 INFO mapreduce.Job: map 67% reduce 0%
19/08/22 15:12:08 INFO mapreduce.Job: map 100% reduce 0%
19/08/22 15:12:08 INFO mapreduce.Job: Job job_1566288518023_0335 completed successfully
19/08/22 15:12:08 INFO mapreduce.Job: Counters: 34
File System Counters
FILE: Number of bytes read=0
FILE: Number of bytes written=801303
FILE: Number of read operations=0
FILE: Number of large read operations=0
FILE: Number of write operations=0
HDFS: Number of bytes read=2709617
HDFS: Number of bytes written=0
HDFS: Number of read operations=6
HDFS: Number of large read operations=0
HDFS: Number of write operations=0
HDFS: Number of bytes read erasure-coded=0
Job Counters
Launched map tasks=3
Data-local map tasks=3
Total time spent by all maps in occupied slots (ms)=25662
Total time spent by all reduces in occupied slots (ms)=0
Total time spent by all map tasks (ms)=25662
Total vcore-milliseconds taken by all map tasks=25662
Total megabyte-milliseconds taken by all map tasks=26277888
Map-Reduce Framework
Map input records=37635
Map output records=37635
Input split bytes=531
Spilled Records=0
Failed Shuffles=0
Merged Map outputs=0
GC time elapsed (ms)=454
CPU time spent (ms)=14840
Physical memory (bytes) snapshot=1287696384
Virtual memory (bytes) snapshot=8280121344
Total committed heap usage (bytes)=2418540544
Peak Map Physical memory (bytes)=439844864
Peak Map Virtual memory (bytes)=2776657920
ImportTsv
Bad Lines=0
File Input Format Counters
Bytes Read=2709086
File Output Format Counters
Bytes Written=0
我已经创建了多个区域(取决于密钥)来分发看跌期权,但它没有改变任何东西。
create 'mynamespace:mytable', {NAME => 'data', COMPRESSION => 'SNAPPY'}, {SPLITS => ['0','1','2','3','4','5']}
有人知道如何优化这个操作吗?
谢谢。
1条答案
按热度按时间8mmmxcuj1#
我认为你可以做一些事情来改善这一点:
看看如何创建一个表,我可以看到您没有预先定义区域的数量,这些区域将服务于这个特定的表。假设这是您正在填充的新表,hbase将不得不承担拆分现有区域的额外负载,并且您的导入将花费更长的时间。
我建议您通过添加以下内容来设置表的区域数:
NUMREGIONS => "some reasonable number depending on the size of the initial table"
当我说初始表时,我的意思是容纳你知道你将要加载到其中的数据量。稍后逐渐添加的数据此时不一定需要考虑(因为您不想让“一半”空区域进程运行)我不确定您的密钥分布是否均匀,通常使用md5散列来在区域服务器之间均匀分布条目,并避免出现偏差。这可能是需要考虑的另一点,因为您可能会遇到这样一种情况:单个Map器的负载比其他Map器更大,因此作业的长度将取决于此单个Map器的执行情况。所以我会非常小心地使用预分割,除非你真的知道你在做什么。作为一种替代方法,我可以建议您在表格中使用此选项,而不是手动预拆分:
SPLITALGO => 'UniformSplit'
我还建议你用谷歌搜索一下上面的内容。我真的不知道您的具体用例,所以我不能给您一个更深刻的答案,但我相信这些将帮助您提高数据导入表的性能。