Hello @SajawalSultan    It seems you are running the job via user cloudera_user and it needs access to /user/<username> directory to create scratch directories which it is unable to create because user "cloudera_user" does not has permissions.   hdfs:supergroup:drwxr-xr-x /user   Run hdfs dfs -chmod 777 /user from hdfs user to ensure you get proper access to /user directory.   Let me know if this solves your sqoop import. ... View more

hello @Benj1029    You need to go to the below path on the host which is hosting HIveserver2 process.   cd /var/log/hive/   vi hiveserver2.log file and just before the shutdown try looking at the stack trace, the would help you with some pointers. ... View more

Well @ryu, My understanding is when you are storing things on HDFS and that too things related to hive, it is best to use managed table considering in mind that CDP is now coming up with compaction features where in small file issue would automatically get addressed.   Compaction will not happen on external tables.   one would prefer to choose external tables if the data is stored outside HDFS like S3. This is my understanding, but again it could vary on customer to customer based on their use cases. ... View more

Hello @ryu    The purpose of Ranger is to give the necessary user authentication to access the tables/database. If you allow a certain user access to a particular table/database, the user will be able to perform those actions on the table/database and the unwanted user automatically will not be able to remove the table.   Let say there are two users test1 and test2. If I allow test1 user to have access to table t1 and test2 user to have access to table t2, test1 will not be able to see table t2 and test2 will not be able to see test1.   You can further also add granularity as to what user can perform what actions on the table. This authorization is checked via Ranger hook which is present in the Hiveserver2.    Let me know if the above answers your queries. ... View more

Hello @BhaveshP    The error you are seeing is because certificate CN/SAN name mismatch than that of hostname. Let me try to explain you with an example.   client [A]--> Balancer[B] -->NIFI Nodes[C,D,E]   Here you have a client A who wants to access NIFI nodes C,D and E and he wants to access via B. When you create SSL certificates for C,D,E, you create 3 certificates with 3 different "Common Names" C, D. E respectively. Now when you try connecting to nifi nodes C,D,E respectively directly from client A, you will not observe the issue. But when you try to access C,D,E via balancer or any proxy B, you are likely to get the error.   WHY?   Client A is trying to talk to Nifi Node C or D or E but to client the NIFI node is B. During SSL handshake, the certificates are passed by Nifi server to A where in client gets confused becuase it wanted to talk to B however the certificate it got is from C. Name don't match.   FIX: Make use to SAN Names in certificates. (Subject Alternative Names)   Issue certificate of C,D,E such that it has a SAN name as B. What I am trying to say is, the certificate should have both the name that of C and B in nifi node C, D and B in nifi node D and E and B in nifi node E. In this way client will come to know that when it talks to B and when the certificate received to A from C, it will not get confused because the certificate will have two name present in SAN that of B and C.    Let me know if the above gives some clarity as to what exactly is happening. ... View more