Member since
09-16-2021
423
Posts
55
Kudos Received
39
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 845 | 10-22-2025 05:48 AM | |
| 858 | 09-05-2025 07:19 AM | |
| 1631 | 07-15-2025 02:22 AM | |
| 2229 | 06-02-2025 06:55 AM | |
| 2444 | 05-22-2025 03:00 AM |
08-28-2024
12:45 AM
When connecting through ODBC, make sure that Ranger is enabled on the connected HiveServer2 (HS2). If possible, validate the configuration with LLAP for further verification.
... View more
08-28-2024
12:40 AM
1 Kudo
When writing to a statically partitioned table using HWC, the following query is internally fired to Hive through JDBC after writing data to a temporary location: Spark write statement: df.write.format(HIVE_WAREHOUSE_CONNECTOR).mode("append").option("partition", "c1='val1',c2='val2'").option("table", "t1").save(); HWC internal query: LOAD DATA INPATH '<spark.datasource.hive.warehouse.load.staging.dir>' [OVERWRITE] INTO TABLE db.t1 PARTITION (c1='val1',c2='val2'); During static partitioning, the partition information is known during compile time, resulting in the creation of a staging directory in the partition directory. On the other hand, when writing to a dynamically partitioned table using HWC, the following query is internally fired to Hive through JDBC after writing data to a temporary location: Spark write statement: df.write.format(HIVE_WAREHOUSE_CONNECTOR).mode("append").option("partition", "c1='val1',c2").option("table", "t1").save(); HWC internal query: CREATE TEMPORARY EXTERNAL TABLE db.job_id_table(cols....) STORED AS ORC LOCATION '<spark.datasource.hive.warehouse.load.staging.dir>';
INSERT INTO TABLE t1 PARTITION (c1='val1',c2) SELECT <cols> FROM db.job_id_table; During dynamic partitioning, the partition information is known during runtime, hence the staging directory is created at the table level. Once the DAG is completed, the MOVE TASK will move the files to the respective partitions.
... View more
08-28-2024
12:07 AM
Based on the INFO logs, it appears that there is an open transaction blocking the compaction cleaner process. This requires a separate investigation, so I advise raising a support case to resolve the problem. Additionally, we need to examine the HMS logs, backend DB dump, and the output of "hdfs dfs -ls -R" command.
... View more
08-23-2024
06:09 AM
1 Kudo
Since the partition related information not mentioned in the write statement staging directory created in the table directory instead of partition directory.
... View more
08-22-2024
11:53 PM
To determine the cause of the failure, it is recommended to review the HMS logs within the specified time frame as the exception stack-trace does not provide sufficient information.
... View more
08-22-2024
05:25 AM
1 Kudo
make sure below is enabled at cluster level. hive.acid.direct.insert.enabled Also use below format to insert into partitioned tables. Static partition df.write.format(HIVE_WAREHOUSE_CONNECTOR).mode("append").option("partition", "c1='val1',c2='val2'").option("table", "t1").save(); Dynamic partition df.write.format(HIVE_WAREHOUSE_CONNECTOR).mode("append").option("partition", "c1,c2").option("table", "t1").save();
... View more
08-22-2024
04:34 AM
1 Kudo
It looks similar to the KB Please follow the instructions in the KB.
... View more
08-22-2024
04:24 AM
1 Kudo
Please verify if there are any long-running transactions on the cluster and, if found, consider aborting them using the "abort transactions" command, if it is safe to do so. You can use the "show transactions" command in Beeline to validate the long-running transactions. Another alternative is to use the following backend DB query . SELECT * FROM "TXNS" WHERE "TXN_ID" = ( SELECT min(res.id) FROM ( SELECT "NTXN_NEXT" AS id FROM "NEXT_TXN_ID" UNION ALL SELECT "MHL_TXNID" FROM "MIN_HISTORY_LEVEL" WHERE "MHL_TXNID" = ( SELECT min("MHL_MIN_OPEN_TXNID") FROM "MIN_HISTORY_LEVEL" ) ) res) Note: This query is for postgres DB, modify it depending upon the backend DB in which you're using.
... View more
08-13-2024
04:37 AM
1 Kudo
From the Error Stack-trace , it does looks like problem is , connection closed exception between Tez AM application and the HBase server (host12.com). This connection closure led to a java.net.SocketTimeoutException. In simpler terms, tez AM tried to communicate with HBase but the connection timed out after 60 seconds (callTimeout) because it didn't receive a response within that time frame. This issue occurred during the initialization of a vertex named "vertex_1723487266861_0004_2_00" within the Tez application. Possible Reasons The HBase server might be overloaded, experiencing internal issues, or even down entirely. Hive might have an incorrect HBase server address or port configured.
... View more
08-12-2024
01:51 AM
Can you please share the stacktrace from HiveServer2 logs and spark-submit command used
... View more