Configuring a Shared Amazon RDS as an HMS for CDH
Before CDH 5.10, each CDH cluster had to have its own Apache Hive metastore (HMS) backend database. This model is ideal for clusters where each cluster contains the data locally along with the metadata. In the cloud, however, many CDH clusters run directly on a shared object store, such as Amazon S3, making it possible for the data to live across multiple clusters and beyond the lifespan of any cluster. In this scenario, clusters need to regenerate and coordinate metadata for the underlying shared data individually.
From CDH 5.10 and later, clusters running in the AWS cloud can share a single persistent instance of the Amazon Relational Database Service (RDS) as the HMS backend database. This enables persistent sharing of metadata beyond a cluster's life cycle so that subsequent clusters need not regenerate metadata as they had to before.
Advantages of This Approach
Using a shared Amazon RDS server as your HMS backend enables you to deploy and share data and metadata across multiple transient as well as persistent clusters if they adhere to restrictions that are outlined in the "Supported Scenarios" section below. For example, you can have multiple transient Hive or Apache Spark clusters writing table data and metadata which can be subsequently queried by a persistent Apache Impala cluster. Or you might have 2-3 different transient clusters, each dealing with different types of jobs on different data sets that spin up, read raw data from S3, do the ETL (Extract, Transform, Load) work, write data out to S3, and then spin down. In this scenario, you want each cluster to be able to simply point to a permanent HMS and do the ETL. Using RDS as a shared HMS backend database greatly reduces your overhead because you no longer need to recreate the HMS again and again for each cluster, every day, for each transient ETL job that you run.
How To Configure Amazon RDS as the Backend Database for a Shared Hive Metastore
The following instructions assumes that you have an Amazon AWS account and that you are familiar with AWS services.
- Create a MySQL instance with Amazon RDS. See Creating a MySQL DB Instance... and Creating an RDS Database Tutorial in Amazon documentation. This step is performed only once. Subsequent clusters that use an existing RDS instance do not need this step because the RDS is already set up.
- Configure a remote MySQL Hive metastore database as part of the Cloudera Manager installation procedure, using the hostname, username, and password configured during your RDS setup. See Configuring a Remote MySQL Database for the Hive Metastore.
-
Configure Hive, Impala, and Spark to use Amazon S3:
- For Hive, see Tuning Hive on S3.
- For Impala, see Using Impala with the Amazon S3 Filesystem.
- For Spark, see Accessing Data Stored in Amazon S3 through Spark.
Supported Scenarios
The following limitations apply to the jobs you run when you use an RDS server as a remote backend database for Hive metastore.
- No overlapping data or metadata changes to the same data sets across clusters.
- No reads during data or metadata changes to the same data sets across clusters.
-
Overlapping data or metadata changes are defined as when multiple clusters concurrently:
- Make updates to the same table or partitions within the table located on S3.
- Add or change the same parent schema or database.
Categories: AWS | Administrators | Configuring | HMS | Metastore | Preview Features | RDS | S3 | All Categories