Member since
03-11-2020
197
Posts
30
Kudos Received
40
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 3620 | 11-07-2024 08:47 AM | |
| 2650 | 11-07-2024 08:36 AM | |
| 1562 | 06-18-2024 01:34 AM | |
| 1079 | 06-18-2024 01:25 AM | |
| 1227 | 06-18-2024 01:16 AM |
04-12-2023
01:48 AM
@rajilion It seems that you are using the -update flag with distcp command, which is causing the command to skip files that exist in the destination and have a modification time equal to or newer than the source file. This is the expected behavior of distcp when the -update flag is used. In your case, even though the content of the file has changed, the size and modification time are still the same, which is causing distcp to skip the file during the copy process. To copy the updated file to S3, you can try removing the -update flag from the distcp command. This will force distcp to copy all files from the source directory to the destination, regardless of whether they exist in the destination or not. Your updated command would look like this: hadoop distcp -pu -delete hdfs_path s3a://bucket The -pu flag is used to preserve the user and group ownership of the files during the copy process. Please note that removing the -update flag can cause distcp to copy all files from the source directory to the destination, even if they haven't been modified. This can be time-consuming and may result in unnecessary data transfer costs if you have a large number of files to copy. If you only want to copy specific files that have been modified, you can use a different tool such as s3-dist-cp or aws s3 sync that supports checksum-based incremental copies. These tools use checksums to determine which files have been modified and need to be copied, rather than relying on modification times or file sizes. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.
... View more
03-30-2023
04:11 AM
@jjjjanine Thanks for providing your valuable inputs.
... View more
01-25-2023
09:26 PM
If the same Node is getting down every time, it's worth checking the Memory utilization at the OS end. You can check the /var/log/messages of the NN host when the NN went down and check if the process is getting killed by an oom.
... View more
01-10-2023
05:47 AM
To resolve this issue, open /opt/cloudera/cm/bin/gen_credentials.sh for editing and add the following to the very end of the script: exit ${PIPESTATUS[0]} And then try generating Kerberos credentials once more.
... View more
12-27-2022
07:51 AM
2 Kudos
@asish Thanks!!! that worked.
... View more
12-25-2022
11:33 AM
I solved problem, reason was not in filter
... View more
12-23-2022
09:19 PM
@quangbilly79 It should be /opt/cloudera/parcels/SPARK2/lib/
... View more
12-21-2022
09:41 PM
@kvbigdata What happens if you set Cloudera Manager > Hive > Configuration > Service Monitor Client Config Overrides > Add
Name: hive.metastore.client.socket.timeout
Value: 600 We have provided the below information regarding the current situation of the canary jira . https://my.cloudera.com/knowledge/quotError--The-Hive-Metastore-canary-failed-to-create-a?id=337839 You have only one workaround ,that is to disable the canary test as you already did currently and that will not harm anything on your cluster . Currently the workaround is to disable the Canary tests on the HMS. # Access HIve Service
# Configuration Tab >> Look for Hive Metastore Canary Health Test
# Uncheck the box
# Restart the service.
... View more
12-18-2022
07:15 PM
@myzard Increase the timeout below. You can also check after changing the below property from Ambari UI > Advance Hive-interactive-env:
Number of retries while checking LLAP app status = 40
(It will show a warning, please ignore that and save)
This should increase the timeout from 400 to 800s. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.
... View more
12-18-2022
05:16 AM
@drgenious This is an OS-level issue that will need to be addressed at the OS level by the system admin. The bottom line here is that thrift-0.9.2 needs to be uninstalled There are various things that could be happening:
1) Multiple python versions.
2) Multiple pip versions.
3) Broken installation. Solution: 1
- You can try to create the Python virtual environment to connect to impala-shell
virtualenv venv -p python2
cd venv
source bin/activate
(venv) impala-shell Solution : 2 (i) Remove easy-install.pth files available in,
/usr/lib/python2.6/site-packages/
/usr/lib64/python2.6/site-packages/
(ii) Try running impala-shell If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped.
... View more