Hi Jerry, Thanks for your help. Few columns had different data types and table was created using delimiter ',' and column data had elements with '','. Regards. Sandeep Suman ... View more

Hi @Tulasi,   Greate to hear the issue got resolved! I will report internally on this to our documentation team to see how we can improve on it.   Thanks, Li ... View more

Hi,   If there is any changes in the Hive metadata. Please try to run msck repair table <tablename> to get it in sync   Reference Link: https://www.cloudera.com/documentation/enterprise/5-13-x/topics/cdh_ig_hive_troubleshooting.html   Thanks Jerry ... View more

Thanks, That worked like a charm ... View more

  Hi @csguna, CDH version is 5.13.2 ... View more

yes, it is. Not me, sysadmin. If i configed impala - i'd know correct port. ... View more

Actually, scratch what I just said - that advice applies if the query is stuck in the FINISHED state. If it's stuck in the RUNNING state, it means the query is just taking a long time to produce any results. So you're probably getting a bad query plan on one cluster that is extremely slow to execute. E.g. the order of the joins chosen by the planner is inefficient. Usually computing stats on all the tables will improve the query plan. ... View more

Hi,   The probable reason for this job failure is that YARN is not allowing you to submit the job in this queue. Either this queue is not present over there or the placement rules are causing some issue.   There could be a scenario where this user has not been given the permission to submit the job in this queue.   1. Can you share the snapshot of the YARN dynamic resource pools that you have created. 2. Can you also share the snapshot of the YARN placement policies that you have set. 3. The username who is submitting the Sqoop job. 4. Kindly share the snapshot of the users you have given the access to this queue where you are submitting the job.   This will help us to check if there is some issue with the queue or permissions or placement policies.   Regards Nitish ... View more

Hi,   NOT_LEADER_FOR_PARTITION in kafka. when a client is trying to access a topic partition for which the given broker is not the leader. For example a producer can only send new messages to the partition that is considered the leader for a replica set of partitions. Only after the leader partition receives the messages will they be sent to the other brokers that hold the replicas of that partition.   It can happen when the client/producer has stale information about which broker is the leader for a partition. In this case the NotLeaderForPartitionException is thrown by the broker that the client is connecting. Another possible reason , when a leader re-election happened recently (like when restarting brokers one by one in your case and for a short time the leader partitions for certain replicas were unavailable and new leaders were elected for the partitions that used to have a leader on the unavailable broker).   Ideally it is harmless as it is retrial, It can retry and try to send request to other brokers Reference Link:http://kafka.apache.org/documentation/#replication   On what basis does kafka leader election happen ? Kafka maintains a set of in-sync replicas. Only the members of this set are eligible for election as leader. It will be stored in ZK.   Sharing quote from Kafka document “Each partition has one server which acts as the "leader" and zero or more servers which act as "followers". The leader handles all read and write requests for the partition while the followers passively replicate the leader. If the leader fails, one of the followers will automatically become the new leader. Each server acts as a leader for some of its partitions and a follower for others so load is well balanced within the cluster”   Reference Link: https://kafka.apache.org/documentation#design_replicatedlog   What are all the reasons that cause kafka partition leader election to trigger? When the active leader crashed or failed, New leader will be selected from one of the in-sync replicas If you have enabled “auto.leader.rebalance.enable=true” and if your preferred leader is not leader. It will try to make it as leader when it is in in-sync replica.   Hope it helps, Let us know if you any questions   Thanks Jerry ... View more