Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]
Created 06-15-2017 08:29 PM
Hi Team, any suggestions. what will be the impact of adding this setting hive.exec.max.dynamic.partitions to whitelist. which allows any user to create any number of partitions for a table at run time.
Created 06-15-2017 09:52 PM
There is no maximum as per my knowledge and again this value depends on the back-end metastore database what you are using.
I have tested up 500,000 in production with oracle as back-end.
hive.exec.max.dynamic.partitions=500000
There won't be any impact by adding that to whitelist but always suggested to have number so that it won't impact cluster in long term.
Example: One user is keeps on increasing partitions, where each partition is very small file, in this case it increase the Namenode metadata which proportionally my effect cluster.
Created 06-15-2017 09:52 PM
There is no maximum as per my knowledge and again this value depends on the back-end metastore database what you are using.
I have tested up 500,000 in production with oracle as back-end.
hive.exec.max.dynamic.partitions=500000
There won't be any impact by adding that to whitelist but always suggested to have number so that it won't impact cluster in long term.
Example: One user is keeps on increasing partitions, where each partition is very small file, in this case it increase the Namenode metadata which proportionally my effect cluster.
Created 06-16-2017 03:31 PM
We are using oracle as back-end, we have plan to implement it in production in near future. As you said small files will increase metadata which proportionally effects cluster. So, are there any precautions or suggestion to be followed while implementing or after implementation.