@Sami Ahmad, Since you have specified --hbase-table , it will import into hbase rather than HDFS. Ref : https://sqoop.apache.org/docs/1.4.2/SqoopUserGuide.html#_importing_data_into_hbase ... View more

Hi @Sami Ahmad! Looking at your sqoop command, it seems that your issue comes from the different types used in --split-by (number column) and --boundary-query (timestamp column). If you take a look at the documentation (at 7.2.2. Selecting the Data to Import). https://sqoop.apache.org/docs/1.4.2/SqoopUserGuide.html By default sqoop will use query select min(<split-by>), max(<split-by>) from <table name> to find out boundaries for creating splits. In some cases this query is not the most optimal so you can specify any arbitrary query returning two numeric columns using --boundary-query argument. Guess if you change your split-by column to the same column as boundary-query it should work (or vice-versa) 🙂 Hope this helps! ... View more

Hello@Sami Ahmad, CAUTION: Retrieving the keytab resets the secret for the Kerberos principal. This renders all other keytabs for that principal invalid. The correct answer depends on which Kerberos implementation you are using. For MIT KDC, a system admin would use an interface, known as "kadmin" (or an alternative "kadmin.local"), to create keytab for users using 'ktadd' command. ktadd will regenerate key with a random password and then add it to keytab: # ktadd -k </path/to/file.keytab> <principal-name> For FreeIPA, an admin would use ipa-getkeytab command. This command can generate keytab with a random or provided password: # ipa-getkeytab -s <ipaserver.example.com> -p <principal-name> -k </path/to/file.keytab> For Microsoft AD, an admin should use ktpass command. This command is really useful when you want to generate a keytab for AD service principal to be used in Linux environment. This can also use a given password or a random password (+rndpass): # ktpass /princ hive/sandbox.hortonworks.com@HWX.COM /pass <password> /mapuser hiveservice /pType KRB5_NT_PRINCIPAL /crypto ALL /out c:\temp\hive.service.keytab Hope this helps! ... View more

@Sami Ahmad Users who are not authorized for specific NiFi components (process groups, processors, input/output ports, etc...) will only see "ghost" processors. Those ghost processors will not contain any information on the face of them the reveals their type or configuration. - - Unless authorized, user also will not be able to list queues, perform provenance queries, etc on FlowFiles that traverse these components. - There are good reasons why NiFi does not hide these ghost processor completely: 1. All components operate within the same resource constraints of a single JVM. It is important that all user can identify areas of any flow that may be backlogging or have large queues, as these things may impact their own dataflows. While the can not see the actual data or processor details, they can observe FlowFile stat info as you can see in above screenshot. 2. If User1 built a dataflows only user 1 could see, User2 may end up building a dataflow directly on top of it. While functionally NiFi does not care about overlapping components, user3 who logs in and has access to both user1 and user2 flows would. It would make it very hard for user 3 to follow the canvas in such a case. - Thanks, Matt ... View more

yes that fixed the issue ..thanks a lot ... View more

awesome it worked . thanks ... View more