Member since
07-31-2013
1924
Posts
462
Kudos Received
311
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 1969 | 07-09-2019 12:53 AM | |
| 11876 | 06-23-2019 08:37 PM | |
| 9141 | 06-18-2019 11:28 PM | |
| 10124 | 05-23-2019 08:46 PM | |
| 4576 | 05-20-2019 01:14 AM |
03-17-2015
12:20 AM
You should be able to simply set a TTL on your tables and run a major compaction to delete older-than-TTL-time data. More on TTL at http://archive.cloudera.com/cdh5/cdh/5/hbase/book.html#ttl.
... View more
03-03-2015
10:31 PM
Thanks for sharing the solution! Indeed, the -- separator lets you pass the connector specific arguments into the connector itself, than sending it to Sqoop which would not recognize them. We cover this need at http://www.cloudera.com/content/cloudera/en/documentation/connectors/latest/Teradata/Cloudera-Connector-for-Teradata/cctd_use_tpcc.html, as "You can control the behavior of the connector by using extra arguments. Extra arguments must appear at the end of the command, using -- as the delimiter.".
... View more
02-26-2015
08:17 PM
The oozie-oozi is the system-id of your Oozie server, and the contents of such a directory on HDFS carries job running data pertaining to your various actions under it. This path is not configurable at the moment, however, as it roots itself on the user's home directory on the FS, which on HDFS translates to /user/<my_user_name>. Is the presence of the directory causing a problem? The directory is cleaned up at the end typically.
... View more
02-26-2015
07:48 PM
Could you post the outputs of the below, from your NodeManager machines where the attempt appears to have failed to run?: ls -ld /mnt/ssd/yarn/nm ls -ld /mnt/ssd/yarn/nm/usercache ls -ld /mnt/ssd/yarn/nm/usercache/urika ls -l /mnt/ssd/yarn/nm/usercache/urika
... View more
02-09-2015
02:01 PM
The UI approach is easier, and it serves the same file from the location you're looking under, but to answer your question, you can look for the latest (numbered or mtime) directory that carries just the role name. For NameNodes, the following is the pattern: NNNN-hdfs-NAMENODE The other dirs with NNNN-hdfs-NAMENODE-xyz are specific sub-commands that run on top of a live NN or similar, but the daemon itself runs on the original dir format mentioned above. Likewise for other role types.
... View more
02-06-2015
06:36 PM
Can you share your problematic core-site.xml and hdfs-site.xml contents here?
... View more
02-06-2015
06:32 PM
The dfs.permissions property is a server-side (NameNode) one. It cannot be overriden by clients. If you use CM, then /etc/hadoop/conf/ is just where your client properties are. The Server-side generated properties are maintained in isolation elsewhere, which you can view for example by going to CM ->HDFS -> Instances -> NameNode -> Processes -> hdfs-site.xml. A good doc on understanding the CM approach can also be found at http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_intro_primer.html#concept_fgj_tny_jk_unique_1
... View more
01-10-2015
10:17 PM
Adding onto David's reply, your end-goal for checking if HDFS understands your group setups, should be to have the command "hdfs groups <username>" return a satisfactory result. Also checkout this blog post: http://blog.cloudera.com/blog/2012/03/authorization-and-authentication-in-hadoop/, and the general HDFS permissions guide: http://archive.cloudera.com/cdh5/cdh/5/hadoop/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html for more reading on the topic.
... View more
01-06-2015
10:15 PM
It will be resolved in the next 5.2.x and 5.3.x bugfix releases (along with 5.4.0 in future).
... View more
12-27-2014
08:19 PM
1 Kudo
This is being caused due to https://issues.apache.org/jira/browse/OOZIE-2102. It will be resolved in a future release of CDH5.
... View more