Your browser is out of date!

Update your browser to view this website correctly. Update my browser now

×

Sign in or complete our product interest form to continue.

Please Read and Accept our Terms



The recommended tool for installing Cloudera Enterprise

This download installs Cloudera Enterprise or Cloudera Express.

 

Cloudera Enterprise requires a license; however, when installing Cloudera Express you will have the option to unlock Cloudera Enterprise features for a free 60-day trial.

 

Once the trial has concluded, the Cloudera Enterprise features will be disabled until you obtain and upload a license.

 

Important: In order to be covered by Cloudera Support:

  • All CDH hosts in a logical cluster must run on the same major OS release.
  • Cloudera temporarily allows a mixed OS configuration during an OS upgrade project.
  • Cloudera Manager must run on the same OS release as one of the CDH clusters it manages.

Cloudera recommends running the same minor release cross-cluster. However, the risk caused by running different minor OS releases is considered lower than the risk of running different major OS releases.

 

Gateway hosts may use RHEL/Centos 7.2, subject to some restrictions. See Operating System Support for Gateway Hosts (CDH 5.11 and higher only)

 

Other disclaimers:

  • RHEL / CentOS / OEL 6.9 is supported in C5.8 and higher. In C5.8.x through 5.11.0, it has a known cipher issue (that is resolved in 5.11.1).
  • RHEL / CentOS / OEL 7.0 is not supported.
  • Red Hat only supports specific upgrades from RHEL 6 to 7. Contact your OS vendor and review What are the supported use cases for upgrading to RHEL 7?
  • SLES hosts running Cloudera Manager agents must use SLES SDK 11 SP1.
  • Cloudera does not support CDH cluster deployments in Docker containers.
  • Cloudera Enterprise (without Cloudera Navigator) is supported on platforms with Security-Enhanced Linux (SELinux) enabled.

Important: Cloudera is not responsible for policy support nor policy enforcement. If you experience issues with SELinux, contact your OS support provider.

 

Cloudera Manager 5.10.x Supported Operating Systems

Operating System Version (bold=new)
Red Hat Enterprise Linux-compatible
RHEL / CentOS

Max SE Linux support: 6.7

7.3, 7.2, 7.1

6.9, 6.8, 6.7, 6.6, 6.5, 6.4

5.11, 5.10, 5.7

Oracle Linux (OL)

7.3, 7.2, 7.1 (UEK default)

6.9, 6.8 (UEK R2, R4)

6.7, 6.6, 6.5 (UEK R2, R3)

6.4 (UEK R2)

5.11, 5.10, 5.7 (UEK R2)

SUSE Linux Enterprise Server
SLES

12 SP1

11 SP4, 11 SP3, 11 SP2

Ubuntu/Debian
Ubuntu

14.04 LTS (Trusty)

12.04 LTS (Precise)

Debian

8.4, 8.2 (Jessie)

7.8, 7.1, 7.0 (Wheezy)

Selected tab: SupportedOperatingSystems

CDH and Cloudera Manager Supported JDK Versions

Only 64 bit JDKs from Oracle are supported. Oracle JDK 7 is supported across all versions of Cloudera Manager 5 and CDH 5. Oracle JDK 8 is supported in C5.3.x and higher.

 

A supported minor JDK release will remain supported throughout a Cloudera major release lifecycle, from the time of its addition forward, unless specifically excluded.

 

Warning: JDK 1.8u40 and JDK 1.8u60 are excluded from support. Also, the Oozie Web Console returns 500 error when Oozie server runs on JDK 8u75 or higher.

 

Running CDH nodes within the same cluster on different JDK releases is not supported. JDK release across a cluster needs to match the patch level.

  • All nodes in your cluster must run the same Oracle JDK version.
  • All services must be deployed on the same Oracle JDK version.

 

The Cloudera Manager repository is packaged with Oracle JDK 1.7.0_67 (for example) and can be automatically installed during a new installation or an upgrade.

 

For a full list of supported JDK Versions please see CDH and Cloudera Manager Supported JDK Versions.

Selected tab: SupportedJDKVersions

The Cloudera Manager Admin Console, which you use to install, configure, manage, and monitor services, supports the latest version of the following browsers:

  • Mozilla Firefox
  • Google Chrome
  • Internet Explorer
  • Safari.

Selected tab: SupportedBrowsers

Cloudera Manager requires several databases. The Cloudera Manager Server stores information about configured services, role assignments, configuration history, commands, users, and running processes in a database of its own. You must also specify a database for the Activity Monitor and Reports Manager roles.


Important: When you restart processes, the configuration for each of the services is redeployed using information saved in the Cloudera Manager database. If this information is not available, your cluster does not start or function correctly. You must schedule and maintain regular backups of the Cloudera Manager database to recover the cluster in the event of the loss of this database.


The database you use must be configured to support UTF8 character set encoding. The embedded PostgreSQL database installed when you follow Installation Path A - Automated Installation by Cloudera Manager (Non-Production Mode) automatically provides UTF8 encoding. If you install a custom database, you might need to enable UTF8 encoding. The commands for enabling UTF8 encoding are described in each database topic under Cloudera Manager and Managed Service Datastores.


After installing a database, upgrade to the latest patch version and apply any other appropriate updates. Available updates may be specific to the operating system on which it is installed.


Cloudera supports the shipped version of MariaDB, MySQL and PostgreSQL for each supported Linux distribution.

Component MariaDB MySQL SQLite PostgreSQL Oracle Derby - see Note 5
Cloudera Manager 5.5, 10 5.7, 5.6, 5.5, 5.1 9.4, 9.3, 9.2, 9.1. 8.4, 8.3, 8.1

12c, 11gR2

See Note 11

 
Oozie 5.5, 10 5.7, 5.6, 5.5, 5.1

9.4, 9.3, 9.2, 9.1. 8.4, 8.3, 8.1

See Note 3

12c, 11gR2 Default
Flume Default (for the JDBC Channel only)
Hue 5.5, 10 5.7, 5.6, 5.5, 5.1

See Note 6

Default

9.4, 9.3, 9.2, 9.1. 8.4, 8.3, 8.1

See Note 3

12c, 11gR2
Hive/Impala 5.5, 10 5.7, 5.6, 5.5, 5.1

See Note 1

9.4, 9.3, 9.2, 9.1. 8.4, 8.3, 8.1

See Note 3

12c, 11gR2 Default
Sentry 5.5, 10 5.7, 5.6, 5.5, 5.1

See Note 1

9.4, 9.3, 9.2, 9.1. 8.4, 8.3, 8.1

See Note 3

12c, 11gR2
Sqoop 1 5.5, 10 See Note 4 See Note 4 See Note 4
Sqoop 2 5.5, 10 See Note 9 Default

 

Note:

  1. Cloudera supports the databases listed above provided they are supported by the underlying operating system on which they run.
  2. MySQL 5.5 is supported on CDH 5.1. MySQL 5.6 is supported on CDH 5.1 and higher. The InnoDB storage engine must be enabled in the MySQL server.
  3. Cloudera Manager installation fails if GTID-based replication is enabled in MySQL.
  4. PostgreSQL 9.2 is supported on CDH 5.1 and higher. PostgreSQL 9.3 is supported on CDH 5.2 and higher. PostgreSQL 9.4 is supported on CDH 5.5 and higher.
  5. For purposes of transferring data only, Sqoop 1 supports MySQL 5.0 and above, PostgreSQL 8.4 and above, Oracle 10.2 and above, Teradata 13.10 and above, and Netezza TwinFin 5.0 and above. The Sqoop metastore works only with HSQLDB (1.8.0 and higher 1.x versions; the metastore does not work with any HSQLDB 2.x versions).
  6. Derby is supported as shown in the table, but not always recommended. See the pages for individual components in the Cloudera Installation guide for recommendations.
  7. CDH 5 Hue requires the default MySQL version of the operating system on which it is being installed, which is usually MySQL 5.1, 5.5, or 5.6.
  8. When installing a JDBC driver, only the ojdbc6.jar file is supported for both Oracle 11g R2 and Oracle 12c; the ojdbc7.jar file is not supported.
  9. Sqoop 2 lacks some of the features of Sqoop 1. Cloudera recommends you use Sqoop 1. Use Sqoop 2 only if it contains all the features required for your use case.
  10. MariaDB 10 is supported only on CDH 5.9 and higher.
  11. For Oracle 12cR1, the Oracle 12 client library and the OJDBC7 connector are not supported.
Selected tab: SupportedDatabases

The following versions of CDH and managed services are supported:

 

Warning: Cloudera Manager 5 does not support CDH 3 and you cannot upgrade Cloudera Manager 4 to Cloudera Manager 5 if you have a cluster running CDH 3. Therefore, to upgrade CDH 3 clusters to CDH 4 using Cloudera Manager, you must use Cloudera Manager 4.

  • CDH 4 and CDH 5. The latest released versions of CDH 4 and CDH 5 are strongly recommended. For information on CDH 4 requirements, see CDH 4 Requirements and Supported Versions. For information on CDH 5 requirements, see CDH 5 Requirements and Supported Versions.
  • Cloudera Impala - Cloudera Impala is included with CDH 5. Cloudera Impala 1.2.1 with CDH 4.1.0 or higher. For more information on Impala requirements with CDH 4, see Impala Requirements.
  • Cloudera Search - Cloudera Search is included with CDH 5. Cloudera Search 1.2.0 with CDH 4.6.0. For more information on Cloudera Search requirements with CDH 4, see Cloudera Search Requirements.
  • Apache Spark - 0.90 or higher with CDH 4.4.0 or higher.
  • Apache Accumulo - 1.4.3 with CDH 4.3.0, 1.4.4 with CDH 4.5.0, and 1.6.0 with CDH 4.6.0.

For more information, see the Product Compatibility Matrix.

Selected tab: SupportedCDHandManagedServiceVersions

See CDH and Cloudera Manager Supported Transport Layer Security Versions.

 

To configure TLS security for the Cloudera Manager Server and Agents, see Configuring TLS Security for Cloudera Manager.

Selected tab: SupportedTransportLayerSecurityVersions

Cloudera Manager requires the following resources:

  • Disk Space
    • Cloudera Manager Server
      • 5 GB on the partition hosting /var.
      • 500 MB on the partition hosting /usr.
      • For parcels, the space required depends on the number of parcels you download to the Cloudera Manager Server and distribute to Agent hosts. You can download multiple parcels of the same product, of different versions and different builds. If you are managing multiple clusters, only one parcel of a product/version/build/distribution is downloaded on the Cloudera Manager Server—not one per cluster. In the local parcel repository on the Cloudera Manager Server, the approximate sizes of the various parcels are as follows:
        • CDH 5 (which includes Impala and Search) - 1.5 GB per parcel (packed), 2 GB per parcel (unpacked)
        • Impala - 200 MB per parcel
        • Cloudera Search - 400 MB per parcel
    • Cloudera Management Service -The Host Monitor and Service Monitor databases are stored on the partition hosting /var. Ensure that you have at least 20 GB available on this partition.
    • Agents - On Agent hosts, each unpacked parcel requires about three times the space of the downloaded parcel on the Cloudera Manager Server. By default, unpacked parcels are located in /opt/cloudera/parcels.
  • RAM - 4 GB is recommended for most cases and is required when using Oracle databases. 2 GB might be sufficient for non-Oracle deployments with fewer than 100 hosts. However, to run the Cloudera Manager Server on a machine with 2 GB of RAM, you must tune down its maximum heap size (by modifying -Xmx in /etc/default/cloudera-scm-server). Otherwise the kernel might kill the Server for consuming too much RAM.
  • Python - Cloudera Manager requires Python 2.4 or higher (but is not compatible with Python 3.0 or higher). Hue in CDH 5 and package installs of CDH 5 require Python 2.6 or 2.7. All supported operating systems include Python version 2.4 or higher. Cloudera Manager is compatible with Python 2.4 through the latest version of Python 2.x. Cloudera Manager does not support Python 3.0 and higher.
  • Perl - Cloudera Manager requires perl.
Selected tab: ResourceRequirements

The hosts in a Cloudera Manager deployment must satisfy the following networking and security requirements:

  • CDH requires IPv4. IPv6 is not supported and must be disabled.

    See also

  • Multihoming CDH or Cloudera Manager is not supported outside specifically certified Cloudera partner appliances. Cloudera finds that current Hadoop architectures combined with modern network infrastructures and security practices remove the need for multihoming. Multihoming, however, is beneficial internally in appliance form factors to take advantage of high-bandwidth InfiniBand interconnects.
  • Although some subareas of the product might work with unsupported custom multihoming configurations, there are known issues with multihoming. In addition, unknown issues can arise because multihoming is not covered by the test matrix outside the Cloudera-certified partner appliances.
  • Cluster hosts must have a working network name resolution system and correctly formatted /etc/hostsfile. All cluster hosts must have properly configured forward and reverse host resolution through DNS. The /etc/hosts files must:
    • Contain consistent information about hostnames and IP addresses across all hosts
    • Not contain uppercase hostnames
    • Not contain duplicate IP addresses

    Cluster hosts must not use aliases, either in /etc/hosts or in configuring DNS. A properly formatted /etc/hosts file should be similar to the following example:

    127.0.0.1 localhost.localdomain localhost
    192.168.1.1 cluster-01.example.com cluster-01
    192.168.1.2 cluster-02.example.com cluster-02
    192.168.1.3 cluster-03.example.com cluster-03

  • In most cases, the Cloudera Manager Server must have SSH access to the cluster hosts when you run the installation or upgrade wizard. You must log in using a root account or an account that has password-less sudo permission. For authentication during the installation and upgrade procedures, you must either enter the password or upload a public and private key pair for the root or sudo user account. If you want to use a public and private key pair, the public key must be installed on the cluster hosts before you use Cloudera Manager.

    Cloudera Manager uses SSH only during the initial install or upgrade. Once the cluster is set up, you can disable root SSH access or change the root password. Cloudera Manager does not save SSH credentials, and all credential information is discarded when the installation is complete.

  • If single user mode is not enabled, the Cloudera Manager Agent runs as root so that it can make sure the required directories are created and that processes and files are owned by the appropriate user (for example, the hdfs and mapred users).
  • No blocking is done by Security-Enhanced Linux (SELinux).Note: Cloudera Enterprise is supported on platforms with Security-Enhanced Linux (SELinux) enabled. However, Cloudera does not support use of SELinux with Cloudera Navigator. Cloudera is not responsible for policy support nor policy enforcement. If you experience issues with SELinux, contact your OS provider.
  • No blocking by iptables or firewalls; port 7180 must be open because it is used to access Cloudera Manager after installation. Cloudera Manager communicates using specific ports, which must be open.
  • For RHEL and CentOS, the /etc/sysconfig/network file on each host must contain the hostname you have just set (or verified) for that host.
  • Cloudera Manager and CDH use several user accounts and groups to complete their tasks. The set of user accounts and groups varies according to the components you choose to install. Do not delete these accounts or groups and do not modify their permissions and rights. Ensure that no existing systems prevent these accounts and groups from functioning. For example, if you have scripts that delete user accounts not in a whitelist, add these accounts to the list of permitted accounts. Cloudera Manager, CDH, and managed services create and use the following accounts and groups:

Users and Groups

Component (Version)

Unix User ID Groups Notes
Cloudera Manager (all versions) cloudera-scm cloudera-scm Cloudera Manager processes such as the Cloudera Manager Server and the monitoring roles run as this user.

The Cloudera Manager keytab file must be named cmf.keytab since that name is hard-coded in Cloudera Manager.Note: Applicable to clusters managed by Cloudera Manager only.

Apache Accumulo (Accumulo 1.4.3 and higher) accumulo accumulo Accumulo processes run as this user.
Apache Avro   No special users.
Apache Flume (CDH 4, CDH 5) flume flume The sink that writes to HDFS as this user must have write privileges.
Apache HBase (CDH 4, CDH 5) hbase hbase The Master and the RegionServer processes run as this user.
HDFS (CDH 4, CDH 5) hdfs hdfs, hadoop The NameNode and DataNodes run as this user, and the HDFS root directory as well as the directories used for edit logs should be owned by it.
Apache Hive (CDH 4, CDH 5) hive hive

The HiveServer2 process and the Hive Metastore processes run as this user.

A user must be defined for Hive access to its Metastore DB (for example, MySQL or Postgres) but it can be any identifier and does not correspond to a Unix uid. This is javax.jdo.option.ConnectionUserName in hive-site.xml.

Apache HCatalog (CDH 4.2 and higher, CDH 5) hive hive

The WebHCat service (for REST access to Hive functionality) runs as the hive user.

HttpFS (CDH 4, CDH 5) httpfs httpfs

The HttpFS service runs as this user. See HttpFS Security Configuration for instructions on how to generate the merged httpfs-http.keytab file.

Hue (CDH 4, CDH 5) hue hue

Hue services run as this user.

Hue Load Balancer (Cloudera Manager 5.5 and higher) apache apache The Hue Load balancer has a dependency on the apache2 package that uses the apacheuser name. Cloudera Manager does not run processes using this user ID.
Cloudera Impala (CDH 4.1 and higher, CDH 5) impala impala, hive Impala services run as this user.
Apache Kafka (Cloudera Distribution of Kafka 1.2.0) kafka kafka Kafka services run as this user.
Java KeyStore KMS (CDH 5.2.1 and higher) kms kms The Java KeyStore KMS service runs as this user.
Key Trustee KMS (CDH 5.3 and higher) kms kms The Key Trustee KMS service runs as this user.
Key Trustee Server (CDH 5.4 and higher) keytrustee keytrustee The Key Trustee Server service runs as this user.
Kudu kudu kudu Kudu services run as this user.
Llama (CDH 5) llama llama Llama runs as this user.
Apache Mahout   No special users.
MapReduce (CDH 4, CDH 5) mapred mapred, hadoop Without Kerberos, the JobTracker and tasks run as this user. The LinuxTaskController binary is owned by this user for Kerberos.
Apache Oozie (CDH 4, CDH 5) oozie oozie The Oozie service runs as this user.
Parquet   No special users.
Apache Pig   No special users.
Cloudera Search (CDH 4.3 and higher, CDH 5) solr solr The Solr processes run as this user.
Apache Spark (CDH 5) spark spark The Spark History Server process runs as this user.
Apache Sentry (CDH 5.1 and higher) sentry sentry The Sentry service runs as this user.
Apache Sqoop (CDH 4, CDH 5) sqoop sqoop This user is only for the Sqoop1 Metastore, a configuration option that is not recommended.
Apache Sqoop2 (CDH 4.2 and higher, CDH 5) sqoop2 sqoop, sqoop2 The Sqoop2 service runs as this user.
Apache Whirr   No special users.
YARN (CDH 4, CDH 5) yarn yarn, hadoop Without Kerberos, all YARN services and applications run as this user. The LinuxContainerExecutor binary is owned by this user for Kerberos.
Apache ZooKeeper (CDH 4, CDH 5) zookeeper zookeeper The ZooKeeper processes run as this user. It is not configurable.

Selected tab: NetworkingandSecurityRequirements
Selected tab: SystemRequirements

What's New in Cloudera Manager 5.10.0

  • Backup and Disaster Recovery
    • Change of default behavior for Impala metadata setting in Hive replications

      There are now three options for configuring replication of Impala metadata for Hive replication jobs:

      • No – Impala metadata is not replicated.
      • Yes – Impala metadata is replicated.
      • Auto – Cloudera Manager decides the value for this option based on the version of CDH in your cluster.

      In Cloudera Manager 5.9, when creating a Hive replication schedule, the Replicate Impala Metadata option was not selected by default (false). In Cloudera Manager 5.10, the value defaults to Auto, so that Cloudera Manager decides what the value should be.

    • Replication of Impala Cached Column statics

      Table and partition-level column statistics stored in the Hive metastore and used by Impala are now replicated during Hive Replication. This is supported between a replication source with Cloudera Manager running version 5.10 or higher and a replication target running Cloudera Manager 5.10 or higher. Because this change replicates more information, the same schedule may take more time to complete if column statistics are present.

    • Performance summaries of HDFS and Hive replication jobs

      You can download full performance reports for HDFS and Hive replications from the Replication Schedules page and from the Replication History page. You can also filter the output by error, deleted, or skipped status. See Monitoring the Performance of Hive Replications and Monitoring the Performance of HDFS Replications.

    • HDFS replication performance monitoring now reports an initial sample

      HDFS performance reports now display early samples during the start of a replication job to give users earlier information about the progress of the job.

    • Scheduler Pool field for replications moved to Resources tab

      When creating replication schedules, the Scheduler Pool input field has been moved to the Resources tab.

  • Amazon S3
    • Amazon S3 Object Store

      You can configure auxiliary storage in your cluster using Amazon Simple Storage Service (S3). Client applications such as YARN, MapReduce, or Spark can access data stored in Amazon S3 using Amazon S3 URLs and credentials. See Configuring the Amazon S3 Connector.

    • Auto-configuration of Hue with AWS credentials (S3 access)

      Cloudera Manager now automatically configures S3 credentials for Hue in the hue.ini file.

  • Resource Management
    • maxResources per user now configurable in YARN Dynamic Resource Pools

      YARN Dynamic Resource Pools now support default capacity limits which automatically apply to all child pools of a resource pool. Using these limits, you can now effectively control the YARN resources available to any user or group in the cluster by configuring these settings on a parent pool and then using placement rules to auto-create child pools per user or group.

  • Key Management Service (KMS)
    • Java Option configuration added for KMS and Key Trustee KMS

      Additional Java Configuration Options can now be set for the KMS and Key Trustee KMS using Advanced Configuration Snippets. This allows customized Java configuration options for the KMS process.

    • Revised ACLs for KMS

      The ACL set generated by the KMS installation wizard has been updated to implement the recommended secure ACL policies for common key names. For more information, See Configuring KMS Access Control Lists Using Cloudera Manager.

  • Security
    • Redaction of stdout and stderr logs

      Redaction logic now applies to the output streams of a service to stdout and stderr logs to redact sensitive information from these files.

    • Encryption of Cloudera Manager database password

      By default the Cloudera Manager database password is stored as clear text in the /etc/cloudera-scm-server/db.properties file. You can now specify a program to execute whose standard output is the password. If com.cloudera.cmf.db.password is not found in /etc/cloudera-scm-server/db.properties, then the property com.cloudera.cmf.db.password_script, if it exists, is used. The value of this property is executed as a program, and the value returned to stdout is used as the password.

  • Monitoring
    • Collection of Metrics can be disabled for specified roles

      A new configuration has been introduced at the role level to disable monitoring by the Cloudera Manager Agent for each individual role. By default, monitoring is enabled for all roles. Once disabled, you must restart the role to make the change take effect. This can help in scenarios where the Cloudera Manager Service Monitor is experiencing performance issues and does not have enough resources. See Disabling Metrics for Specific Roles.

    • New chart display number of monitored entities

      A new chart displays on the Cloudera Management Service status page that shows the number of monitored entities by service monitor and host monitor.

    • Default timeouts configurable for Service Monitor, Host Monitor, Reports Manager, Events Server, and Activity Monitor

      The default timeout is now configurable for Service Monitor, Host Monitor, Reports Manager, Events Server, and Activity Monitor to register themselves to a cluster. Users can change the timeout by increasing the values of the Descriptor Fetch Max Tries property (the default value is 5) and the Descriptor Fetch Tries Intervalproperty (the default value is 2).

    • New Health Test for Service Monitor heap usage.

      A health test has been added to monitor heap usage of the Service Monitor. This test can be useful when diagnosing out of memory errors in the Service Monitor.

  • Users can send feedback on Cloudera Manager

    You can go to Support > Feedback to send feedback to Cloudera about Cloudera Manager.

  • Suppression of warning about embedded database for Cloudera Manager.

    When Cloudera Manager is configured to use the embedded PostgreSQL data base, it displays a banner warning that the embedded PostgreSQL database is not recommended for production environments. You can now suppress this banner: Go to Administration > Settings > Enable Embedded Database Check .

  • New HDFS balancer related configuration options

    HDFS balancer can now be configured to specify which hosts are included and excluded or which hosts are used as sources for transferring replicas. Additional properties for tuning the performance of the balancer can now also be configured starting for CDH 5.10.0 and higher.

  • Removing service dependencies

    Previously, when the user tries to delete a service that another service depends on, Cloudera Manager displays a dialog box explaining that the dependent service should be deleted. There is now a link that takes user to the configuration page where they can remove this dependency.

  • HBase topology files now deployed in client configurations

    When the HBase property Enable Replication To Secondary Region Replicas is enabled, the topology.pyand topology.mapp files are deployed with the client configuration and the Topology Script File Name property is set to the deployed topology.py path.

  • The length of Impala queries retained by the Service Monitor is now configurable.

    The maximum size of impala queries is now configurable and the limit the default size to 10k chars.

Selected tab: WhatsNew

Want to Get Involved or Learn More?

Check out our other resources

Cloudera Community

Collaborate with your peers, industry experts, and Clouderans to make the most of your investment in Hadoop.

Cloudera University

Receive expert Hadoop training through Cloudera University, the industry's only truly dynamic Hadoop training curriculum that’s updated regularly to reflect the state of the art in big data.