@Uday_Singh2022 There won't be any documentation available from Cloudera regarding Flume because that lack of availability is part of what "not a supported component" means. If you must use Flume, then the documentation on the Apache site that @mszurap pointed you to above is your only option.     ... View more

Hi @EmanuelArano  Keeping abreast of the fast moving and ever-updating collection of requirements in terms of supported operating systems, Database Management Systems, Java Development Kits and/or primary processor architectures compatible for use with Cloudera Data Platform (CDP) is quite a challenge and I doubt any members of the Cloudera Community keeps track of all of that in their head. Luckily, you don't have to.   I recommend you refer to the section subheaded CDP Private Cloud Base Supported Operating Systems …in the documentation for the specific release you're interested in (you didn't say which specific version of CDP Private Cloud Base you want to install, and there are as of this writing eight different "point releases" of CDP Private Cloud Base 7.1). As a point of reference, CDP Private Cloud Base versions 7.1.2 and 7.1.3 were released in the Fall of 2020, so hopefully you are not attempting to install 7.1.0 at this point. In particular, that section features a hyperlink to the very handy Cloudera Support Matrix, on which you can click on the product (in your case, Cloudera Manager and CDP Private Cloud Base) to see all the product versions that it supports. To narrow down your search for supported combinations, click again on the supported product versions that are highlighted in green. You can then scroll down to see the supported Operating Systems (along with Databases and JDKs).   Should you find, after consulting that documentation, that "redhat 8.5" is not supported, and you have full backups available to you, the best approach would be to restore your system to the state it was in prior to the yum update and proceed with your installation using 8.4 as the operating system. If for some reason you don't have full backups available, you might want to explore using the yum history command to roll back that last OS update.     ... View more

Hi @Data1701  According to the API documentation, one can get a java.net.URISyntaxException when a passed string could not be parsed as a URI reference. The file you are attempting to read in might very well be available on your local area network from a shared server drive, but it isn't available via a valid URI, or at the very least, the URI you are referencing in your Spark code isn't a valid and accessible URI. What your problem boils down to is that the file isn't available via a web server, and the server that is running your Spark code can't retrieve it at the time your code executes. And that should shed light on why you had to previously upload your .csv files into CDSW, because that was the way to ensure that they could be found at runtime, since they were in a well-known/accessible location.   There are several valid approaches to addressing this, but the easiest solution, if you want to continue to use the code snippet you've written and shared here, is to place the file on some server that is accessible over the web (preferably via HTTPS) and refer to it using a fully-qualified URL. In order to do that, a functioning and secured web server will have to be available to you (you could set this up on your local workstation). Let's assume you place the file on a web-accessible server somewhere local to your corporate network and the web-accessible directory path you place the file in turns out to be something like Data1701/project/data_folder/. Then you can change the assignment statement in your Spark code to this:   df = spark.read.format('csv').load('https://web.dept.yourcompany.com/Data1701/project/data_folder/file.csv', header=True)   …and the rest of your code should work, unchanged.     ... View more