Most answers here suggest using the hiveconf or hivevar to store the variable. And all these answers are correct. However, there is another namespace.
In total, three namespaces for storing variables.
- hiveconf - the bush started from this, the entire configuration of the hive is saved as part of this conf. Initially, variable substitution was not part of the hive, and when it appeared, all user-defined variables were also saved as part of this. Which is definitely not a good idea. Thus, two more namespaces were created.
- hivevar : for storing user variables
- system : to store system variables.
And therefore, if you store a variable as part of a request (e.g. date or product_number), you should use the hivevar namespace and not the hiveconf namespace.
And this is how it works.
hiveconf is still the default namespace , so if you don't provide any namespace, it will save your variable in the hiveconf namespace.
However, when it comes to referencing a variable, it is not. By default, this refers to the hivevar namespace. Confused, right? This can become clearer with the following example.
If you do not provide a namespace as follows, the var variable will be stored in the hiveconf namespace.
set var="default_namespace";
So, to access this you need to specify the hiveconf namespace
select ${hiveconf:var};
And if you do not provide a namespace, it will give you an error, as indicated below, the reason is that by default, if you try to access a variable, it checks the hivevar namespace hivevar . And in hivevar there is no variable named var
select ${var};
We explicitly provided the hivevar namespace
set hivevar:var="hivevar_namespace";
since we provide a namespace, this will work.
select ${hivevar:var};
And by default, the workspace used when accessing the variable is hivevar , the following will work as well.
select ${var};