Member since
01-25-2019
75
Posts
10
Kudos Received
13
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2273 | 02-25-2021 02:10 AM | |
1101 | 02-23-2021 11:31 PM | |
2041 | 02-18-2021 10:18 PM | |
2917 | 02-11-2021 10:08 PM | |
15037 | 02-01-2021 01:47 PM |
11-02-2020
12:35 AM
Could you please print the error you are observing so that I can help you..
... View more
11-01-2020
06:10 AM
@HanzalaShaikh Could you try the below and see if this helps or not. grant SELECT on DATABASE `_impala_builtins` to role <role-name mapped to user hadmin>
... View more
10-29-2020
09:30 AM
@sace17 No this is not right. As I mentioned, the Catalog server will be using the keytab file (impala.keytab) present inside it's process directory ssh to catalog server and run the below command to list out the principals from the keytab klist -ket $(ls -td /var/run/cloudera-scm-agent/process/*CATALOGSERVER* | head -1)/impala.keytab Also From the logs, I see the catalog server is not using authentication. Hence I would request you to focus on setting up the kerberos properly. I1029 17:29:11.249019 30770 authentication.cc:1093] Internal communication is not authenticated
I1029 17:29:11.249027 30770 authentication.cc:1114] External communication is not authenticated
... View more
10-29-2020
07:15 AM
@sace17 Your catalog server is unable to authenticate or get a kerberos ticket. Generally the ticket will be read form the impala.keytab file present under catalog process directory. /var/run/cloudera-scm-agent/process/<latest-process-number>-impala-CATALOGSERVER/implala.keytab for example, below is the keytab output from my catalog server. It contains principal of my catalog server. [root@host-10-17-102-166 6772-impala-CATALOGSERVER]# klist -ket /var/run/cloudera-scm-agent/process/6772-impala-CATALOGSERVER/impala.keytab Keytab name: FILE:/var/run/cloudera-scm-agent/process/6772-impala-CATALOGSERVER/impala.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 5 08/11/20 22:46:07 impala/host-10-17-102-166.coe.cloudera.com@COE.CLOUDERA.COM (des3-cbc-sha1) Can you see if you have the same on your end ? You can also verify by looking at the catalog server logs, when it boots. I1029 07:09:27.356434 18103 authentication.cc:730] Using internal kerberos principal "impala/email@redacted.host" I1029 07:09:27.356523 18103 authentication.cc:1083] Internal communication is authenticated with Kerberos I1029 07:09:27.360359 18103 init.cc:362] Logged in from keytab as impala/email@redacted.host (short username impala) I1029 07:09:27.360714 18103 authentication.cc:866] Kerberos ticket granted to impala/email@redacted.host I1029 07:09:27.360739 18103 authentication.cc:730] Using external kerberos principal "impala/email@redacted.host" I1029 07:09:27.360744 18103 authentication.cc:1099] External communication is authenticated with Kerberos Use the below link to setup kerberos manually. to ensure if all the process was followed correctly or not. https://plenium.wordpress.com/2018/07/17/kerberos-setup-in-cloudera-hadoop/
... View more
10-25-2020
10:55 PM
@RandyGoering Check whether the below path exists on the host/node where you are submitting the sqoop job. /usr/lib/hadoop If it does, please remove the path which will further allow HADOOP HOME to be set to /opt/cloudera/parcels/CDH/lib/hadoop which is the correct path. for your reference:--> https://my.cloudera.com/knowledge/Sqoop-Command-Fails-after-Upgrade?id=70109
... View more
10-25-2020
12:16 AM
@ParthiCyberPunk Could you please update the connection string being used here. just share the console/putty output while making a connection and corresponding Hiveserver2 log/stacktrace during the time on connection. notee: please ensure hiveserver2 service is up and running post enabling ssl.
... View more
10-22-2020
06:07 PM
@PauloRC -->With regards to your query point 1, When a table is queried first time, impala pulls the metadata from catalog which further gets it from HMS and then Impalad stores the metadata in the cache. So, next time when the query is run on the same table, impala does not have to again reach out to catalog server to get the metadata. In your case, you were able to submit queries on other tables because those tables metadata was already available locally with impalad(check the query profile and it can be found whether metadata was pulled from catalog or fetched locally). But for table "impala_table", metadata was not present locally and it was trying to fetch this from catalog server. Now due to failover, HMS was somehow still pointing to standby NN which is why you see the below error. CAUSED BY: TableLoadingException: Failed to load metadata for table: impala_db.impala_table
CAUSED BY: RemoteException: Operation category READ is not supported in state standby. Visit https://s.apache.org/sbnn-error -->For your point 2, I would like to check if you followed the below or not. https://docs.cloudera.com/documentation/enterprise/5-14-x/topics/cdh_hag_hdfs_ha_cdh_components_config.html#topic_2_6_3 -->For your point 3, here is the solution below in the link. https://docs.cloudera.com/documentation/enterprise/latest/topics/impala_metadata.html#auto_poll_hms_notification
... View more
10-22-2020
05:45 PM
@RatheeshNote Can you update the hive site.xml as below. (note the kerberos is in small letters) Also accordingly edit the hive.server2.authentication.kerberos.principal value.
<property>
<name>hive.server2.authentication</name>
<value>kerberos</value>
</property>
<property>
<name>hive.server2.authentication.kerberos.principal</name>
<value>hive/<fqdn-hostname>@<REALM.NAME></value>
</property>
... View more
10-20-2020
10:24 PM
@BI123 Please correct me if my understanding is right. So, SSRS (SQL Server Reporting Services) is a third party application for business intelligence and you want to use Impala as the service to pull data. My guess is you have setup ODBC driver connection for Impala (assuming your application supports ODBC) on your host and ensure SSRS to use the driver to work. Use the below documentation to setup ODBC driver. https://www.cloudera.com/downloads/connectors/impala/odbc/2-6-11.html
... View more
10-20-2020
10:32 AM
1 Kudo
@HanzalaShaikh impala-shell -i <hostlb/impaladhost>:<impala-shell port> -d <db-name> -k -q --ssl --ca_cert=<ca-cert path> "query" -o /path/to/file.csv -B //Sample shell command from my test bed impala-shell -i host-10-17-102-166.coe.cloudera.com:25003 -d test_database -k --ssl --ca_cert=/opt/cloudera/security/cacert.pem -q "select * from salerecord limit 20" -o output.txt -B Can you try the above with the updated configurations from your environment and let me know if this addresses your query.
... View more
- « Previous
- Next »