Cloudera Introduction

Important Notice

(c) 2010-2015 Cloudera, Inc. All rights reserved.

Cloudera, the Cloudera logo, Cloudera Impala, and any other product or service
names or slogans contained in this document are trademarks of Cloudera and its
suppliers or licensors, and may not be copied, imitated or used, in whole or in part,
without the prior written permission of Cloudera or the applicable trademark holder.

Hadoop and the Hadoop elephant logo are trademarks of the Apache Software
Foundation. All other trademarks, registered trademarks, product names and
company names or logos mentioned in this document are the property of their
respective owners. Reference to any products, services, processes or other
information, by trade name, trademark, manufacturer, supplier or otherwise does
not constitute or imply endorsement, sponsorship or recommendation thereof by
us.

Complying with all applicable copyright laws is the responsibility of the user. Without
limiting the rights under copyright, no part of this document may be reproduced,
stored in or introduced into a retrieval system, or transmitted in any form or by any
means (electronic, mechanical, photocopying, recording, or otherwise), or for any
purpose, without the express written permission of Cloudera.

Cloudera may have patents, patent applications, trademarks, copyrights, or other

intellectual property rights covering subject matter in this document. Except as
expressly provided in any written license agreement from Cloudera, the furnishing
of this document does not give you any license to these patents, trademarks
copyrights, or other intellectual property. For information about patents covering
Cloudera products, see http://tiny.cloudera.com/patents.

The information in this document is subject to change without notice. Cloudera

shall not be liable for any damages resulting from technical errors or omissions
which may be present in this document, or from use of this document.

Cloudera, Inc.
1001 Page Mill Road Bldg 2
Palo Alto, CA 94304
info@cloudera.com
US: 1-888-789-1488
Intl: 1-650-362-0488
www.cloudera.com

Release Information

Version: 5.4.x
Date: May 20, 2015
Table of Contents

About Cloudera Introduction.....................................................................................5

Documentation Overview...........................................................................................................................5

CDH Overview.............................................................................................................7
Cloudera Impala Overview..........................................................................................................................7
Impala Benefits.........................................................................................................................................................8
How Cloudera Impala Works with CDH..................................................................................................................8
Primary Impala Features.........................................................................................................................................9
Cloudera Search Overview..........................................................................................................................9
How Cloudera Search Works.................................................................................................................................10
Cloudera Search and Other Cloudera Components............................................................................................11
Apache Sentry Overview...........................................................................................................................12

Cloudera Manager 5 Overview................................................................................13

Terminology................................................................................................................................................13
Architecture................................................................................................................................................16
State Management....................................................................................................................................16
Configuration Management.....................................................................................................................17
Process Management...............................................................................................................................20
Software Distribution Management........................................................................................................20
Host Management.....................................................................................................................................21
Resource Management.............................................................................................................................22
User Management.....................................................................................................................................24
Security Management...............................................................................................................................24
Cloudera Management Service................................................................................................................26
Cloudera Manager Admin Console...........................................................................................................27
Starting and Logging into the Admin Console.....................................................................................................29
Home Page..............................................................................................................................................................29
Cloudera Manager API...............................................................................................................................31
Backing Up and Restoring the Cloudera Manager Configuration ....................................................................33
Using the Cloudera Manager Java API for Cluster Automation.........................................................................34
Extending Cloudera Manager...................................................................................................................36

Cloudera Navigator 2 Overview..............................................................................37

 Cloudera Navigator UI...............................................................................................................................37
Cloudera Navigator API.............................................................................................................................38

FAQs..........................................................................................................................39
Cloudera Express and Cloudera Enterprise Features............................................................................39
Cloudera Manager 5 Frequently Asked Questions................................................................................41
General Questions..................................................................................................................................................41
Cloudera Navigator 2 Frequently Asked Questions...............................................................................43
Cloudera Impala Frequently Asked Questions.......................................................................................44
Trying Impala...........................................................................................................................................................44
Impala System Requirements...............................................................................................................................45
Supported and Unsupported Functionality In Impala........................................................................................46
How do I?.................................................................................................................................................................47
Impala Performance...............................................................................................................................................48
Impala Use Cases....................................................................................................................................................50
Questions about Impala And Hive........................................................................................................................51
Impala Availability..................................................................................................................................................52
Impala Internals......................................................................................................................................................52
SQL...........................................................................................................................................................................55
Partitioned Tables..................................................................................................................................................56
HBase.......................................................................................................................................................................56
Cloudera Search Frequently Asked Questions.......................................................................................57
General.....................................................................................................................................................................57
Performance and Fail Over....................................................................................................................................58
Schema Management............................................................................................................................................59
Supportability..........................................................................................................................................................60

Getting Support........................................................................................................61
Cloudera Support.......................................................................................................................................61
Information Required for Logging a Support Case.............................................................................................61
Community Support..................................................................................................................................61
Get Announcements about New Releases.............................................................................................62
Report Issues.............................................................................................................................................62
 About Cloudera Introduction

About Cloudera Introduction

Cloudera provides a scalable, flexible, integrated platform that makes it easy to manage rapidly increasing
volumes and varieties of data in your enterprise. Industry-leading Cloudera products and solutions enable you
to deploy and manage Apache Hadoop and related projects, manipulate and analyze your data, and keep that
data secure and protected.
Cloudera provides the following products and tools:
• CDH—The Cloudera distribution of Apache Hadoop and other related open-source projects, including Cloudera
Impala and Cloudera Search. CDH also provides security and integration with numerous hardware and
software solutions.
– Cloudera Impala—A massively parallel processing SQL engine for interactive analytics and business
intelligence. Its highly optimized architecture makes it ideally suited for traditional BI-style queries with
joins, aggregations, and subqueries. It can query Hadoop data files from a variety of sources, including
those produced by MapReduce jobs or loaded into Hive tables. The YARN and Llama resource management
components let Impala coexist on clusters running batch workloads concurrently with Impala SQL queries.
You can manage Impala alongside other Hadoop components through the Cloudera Manager user interface,
and secure its data through the Sentry authorization framework.
– Cloudera Search—Provides near real-time access to data stored in or ingested into Hadoop and HBase.
Search provides near real-time indexing, batch indexing, full-text exploration and navigated drill-down,
as well as a simple, full-text interface that requires no SQL or programming skills. Fully integrated in the
data-processing platform, Search uses the flexible, scalable, and robust storage system included with
CDH. This eliminates the need to move large data sets across infrastructures to perform business tasks.
• Cloudera Manager—A sophisticated application used to deploy, manage, monitor, and diagnose issues with
your CDH deployments. Cloudera Manager provides the Admin Console, a web-based user interface that
makes administration of your enterprise data simple and straightforward. It also includes the Cloudera
Manager API, which you can use to obtain cluster health information and metrics, as well as configure Cloudera
Manager.
• Cloudera Navigator—An end-to-end data management tool for the CDH platform. Cloudera Navigator enables
administrators, data managers, and analysts to explore the large amounts of data in Hadoop. The robust
auditing,data management, lineage management, and life cycle management in Cloudera Navigator allow
enterprises to adhere to stringent compliance and regulatory requirements.
This introductory guide provides a general overview of CDH, Cloudera Manager, and Cloudera Navigator. This
guide also includes frequently asked questions about Cloudera products and describes how to get support,
report issues, and receive information about updates and new releases.

Documentation Overview
The following guides are included in the Cloudera documentation set:

Guide Description

Cloudera Introduction Cloudera provides a scalable, flexible, integrated platform that makes it
easy to manage rapidly increasing volumes and varieties of data in your
enterprise. Industry-leading Cloudera products and solutions enable you
to deploy and manage Apache Hadoop and related projects, manipulate
and analyze your data, and keep that data secure and protected.

Cloudera Release Guide This guide contains release and download information for installers and
administrators. It includes release notes as well as information about
versions and downloads. The guide also provides a release matrix that

Cloudera Introduction | 5
About Cloudera Introduction

Guide Description
shows which major and minor release version of a product is supported
with which release version of Cloudera Manager, CDH and, if applicable,
Cloudera Search and Cloudera Impala.

Cloudera QuickStart This guide describes how to quickly install Cloudera software and create
initial deployments for proof of concept (POC) or development. It describes
how to download and use the QuickStart virtual machines, which provide
everything you need to start a basic installation. It also shows you how
to create a new installation of Cloudera Manager 5, CDH5, and managed
services on a cluster of four hosts. Quick start installations should be
used for demonstrations and POC applications only and are not
recommended for production.

Cloudera Installation and Upgrade This guide provides Cloudera software requirements and installation
information for production deployments, as well as upgrade procedures.
This guide also provides specific port information for Cloudera software.

Cloudera Administration This guide describes how to configure and administer a Cloudera
deployment. Administrators manage resources, availability, and backup
and recovery configurations. In addition, this guide shows how to
implement high availability, and discusses integration.

Cloudera Data Management This guide describes how to perform data management using Cloudera
Navigator. Data management activities include auditing access to data
residing in HDFS and Hive metastores, reviewing and updating metadata,
and discovering the lineage of data objects.

Cloudera Operation This guide shows how to monitor the health of a Cloudera deployment
and diagnose issues. You can obtain metrics and usage information and
view processing activities. This guide also describes how to examine logs
and reports to troubleshoot issues with cluster configuration and
operation as well as monitor compliance.

Cloudera Security This guide is intended for system administrators who want to secure a
cluster using data encryption, user authentication, and authorization
techniques. This topic also provides information about Hadoop security
programs and shows you how to set up a gateway to restrict access.

Cloudera Impala Guide This guide describes Cloudera Impala, its features and benefits, and how
it works with CDH. This topic introduces Impala concepts, describes how
to plan your Impala deployment, and provides tutorials for first-time
users as well as more advanced tutorials that describe scenarios and
specialized features. You will also find a language reference, performance
tuning, instructions for using the Impala shell, troubleshooting
information, and frequently asked questions.

Cloudera Search Guide This guide provides Cloudera Search prerequisites, shows how to load
and index data in search, and shows how to use Search to query data. In
addition, this guide provides a tutorial, various indexing references, and
troubleshooting information.

Cloudera Glossary This guide contains a glossary of terms for Cloudera components.

6 | Cloudera Introduction
 CDH Overview

CDH Overview
CDH is the most complete, tested, and popular distribution of Apache Hadoop and related projects. CDH delivers
the core elements of Hadoop – scalable storage and distributed computing – along with a Web-based user
interface and vital enterprise capabilities. CDH is Apache-licensed open source and is the only Hadoop solution
to offer unified batch processing, interactive SQL and interactive search, and role-based access controls.
CDH provides:
• Flexibility - Store any type of data and manipulate it with a variety of different computation frameworks
including batch processing, interactive SQL, free text search, machine learning and statistical computation.
• Integration - Get up and running quickly on a complete Hadoop platform that works with a broad range of
hardware and software solutions.
• Security - Process and control sensitive data.
• Scalability - Enable a broad range of applications and scale and extend them to suit your requirements.
• High availability - Perform mission-critical business tasks with confidence.
• Compatibility - Leverage your existing IT infrastructure and investment.

Cloudera Impala Overview

Cloudera Impala provides fast, interactive SQL queries directly on your Apache Hadoop data stored in HDFS,
HBase, or the Amazon Simple Storage Service (S3). In addition to using the same unified storage platform, Impala
also uses the same metadata, SQL syntax (Hive SQL), ODBC driver, and user interface (Cloudera Impala query UI
in Hue) as Apache Hive. This provides a familiar and unified platform for real-time or batch-oriented queries.
Cloudera Impala is an addition to tools available for querying big data. Impala does not replace the batch
processing frameworks built on MapReduce such as Hive. Hive and other frameworks built on MapReduce are
best suited for long running batch jobs, such as those involving batch processing of Extract, Transform, and
Load (ETL) type jobs.

Cloudera Introduction | 7
CDH Overview

Impala Benefits
Impala provides:
• Familiar SQL interface that data scientists and analysts already know
• Ability to interactively query data on big data in Apache Hadoop
• Distributed queries in a cluster environment, for convenient scaling and to make use of cost-effective
commodity hardware
• Ability to share data files between different components with no copy or export/import step; for example,
to write with Pig, transform with Hive and query with Impala
• Single system for big data processing and analytics, so customers can avoid costly modeling and ETL just
for analytics

How Cloudera Impala Works with CDH

The following graphic illustrates how Impala is positioned in the broader Cloudera environment:

The Impala solution is composed of the following components:

• Clients - Entities including Hue, ODBC clients, JDBC clients, and the Impala Shell can all interact with Impala.
These interfaces are typically used to issue queries or complete administrative tasks such as connecting to
Impala.
• Hive Metastore - Stores information about the data available to Impala. For example, the metastore lets
Impala know what databases are available and what the structure of those databases is. As you create, drop,
and alter schema objects, load data into tables, and so on through Impala SQL statements, the relevant
metadata changes are automatically broadcast to all Impala nodes by the dedicated catalog service introduced
in Impala 1.2.
• Cloudera Impala - This process, which runs on DataNodes, coordinates and executes queries. Each instance
of Impala can receive, plan, and coordinate queries from Impala clients. Queries are distributed among Impala
nodes, and these nodes then act as workers, executing parallel query fragments.
• HBase and HDFS - Storage for data to be queried.
Queries executed using Impala are handled as follows:
1. User applications send SQL queries to Impala through ODBC or JDBC, which provide standardized querying
interfaces. The user application may connect to any impalad in the cluster. This impalad becomes the
coordinator for the query.
2. Impala parses the query and analyzes it to determine what tasks need to be performed by impalad instances
across the cluster. Execution is planned for optimal efficiency.
3. Services such as HDFS and HBase are accessed by local impalad instances to provide data.
4. Each impalad returns data to the coordinating impalad, which sends these results to the client.

8 | Cloudera Introduction
 CDH Overview

Primary Impala Features

Impala provides support for:
• Most common SQL-92 features of Hive Query Language (HiveQL) including SELECT, joins, and aggregate
functions.
• HDFS, HBase, and Amazon Simple Storage System (S3) storage, including:
– HDFS file formats: Text file, SequenceFile, RCFile, Avro file, and Parquet.
– Compression codecs: Snappy, GZIP, Deflate, BZIP.
• Common data access interfaces including:
– JDBC driver.
– ODBC driver.
– Hue Beeswax and the Cloudera Impala Query UI.
• Impala command-line interface.
• Kerberos authentication.

Cloudera Search Overview

Cloudera Search provides near real-time (NRT) access to data stored in or ingested into Hadoop and HBase.
Search provides near real-time indexing, batch indexing, full-text exploration and navigated drill-down, as well
as a simple, full-text interface that requires no SQL or programming skills.
Search is fully integrated in the data-processing platform and uses the flexible, scalable, and robust storage
system included with CDH. This eliminates the need to move large data sets across infrastructures to perform
business tasks.
Cloudera Search incorporates Apache Solr, which includes Apache Lucene, SolrCloud, Apache Tika, and Solr Cell.
Cloudera Search is tightly integrated with CDH 4 and is included with CDH 5.
Using Search with the CDH infrastructure provides:
• Simplified infrastructure
• Better production visibility
• Quicker insights across various data types
• Quicker problem resolution
• Simplified interaction and platform access for more users and use cases
• Scalability, flexibility, and reliability of search services on the same platform used to execute other types of
workloads on the same data
The following table describes Cloudera Search features.

Table 1: Cloudera Search Features

Feature Description
Unified management and Cloudera Manager provides unified and centralized management and
monitoring with Cloudera Manager monitoring for CDH and Cloudera Search. Cloudera Manager simplifies
deployment, configuration, and monitoring of your search services. Many
existing search solutions lack management and monitoring capabilities
and fail to provide deep insight into utilization, system health, trending,
and other supportability aspects.
Index storage in HDFS Cloudera Search is integrated with HDFS for index storage. Indexes created
by Solr/Lucene can be directly written in HDFS with the data, instead of
to local disk, thereby providing fault tolerance and redundancy.

Cloudera Introduction | 9
CDH Overview

Feature Description
Cloudera Search is optimized for fast read and write of indexes in HDFS
while indexes are served and queried through standard Solr mechanisms.
Because data and indexes are co-located, data processing does not require
transport or separately managed storage.

Batch index creation through To facilitate index creation for large data sets, Cloudera Search has built-in
MapReduce MapReduce jobs for indexing data stored in HDFS. As a result, the linear
scalability of MapReduce is applied to the indexing pipeline.
Real-time and scalable indexing at Cloudera Search provides integration with Flume to support near real-time
data ingest indexing. As new events pass through a Flume hierarchy and are written
to HDFS, those events can be written directly to Cloudera Search indexers.
In addition, Flume supports routing events, filtering, and annotation of
data passed to CDH. These features work with Cloudera Search for
improved index sharding, index separation, and document-level access
control.

Easy interaction and data A Cloudera Search GUI is provided as a Hue plug-in, enabling users to
exploration through Hue interactively query data, view result files, and do faceted exploration. Hue
can also schedule standing queries and explore index files. This GUI uses
the Cloudera Search API, which is based on the standard Solr API.
Simplified data processing for Cloudera Search relies on Apache Tika for parsing and preparation of many
Search workloads of the standard file formats for indexing. Additionally, Cloudera Search
supports Avro, Hadoop Sequence, and Snappy file format mappings, as
well as Log file formats, JSON, XML, and HTML. Cloudera Search also
provides data preprocessing using Morphlines, which simplifies index
configuration for these formats. Users can use the configuration for other
applications, such as MapReduce jobs.
HBase search Cloudera Search integrates with HBase, enabling full-text search of stored
data without affecting HBase performance. A listener monitors the
replication event stream and captures each write or update-replicated
event, enabling extraction and mapping. The event is then sent directly
to Solr indexers and written to indexes in HDFS, using the same process
as for other indexing workloads of Cloudera Search. The indexes can be
served immediately, enabling near real-time search of HBase data.

How Cloudera Search Works

In a near real-time indexing use case, Cloudera Search indexes events that are streamed through Apache Flume
to be stored in CDH. Fields and events are mapped to standard Solr indexable schemas. Lucene indexes events,
and integration with Cloudera Search allows the index to be directly written and stored in standard Lucene index
files in HDFS. Flume event routing and storage of data in partitions in HDFS can also be applied. Events can be
routed and streamed through multiple Flume agents and written to separate Lucene indexers that can write
into separate index shards, for better scale when indexing and quicker responses when searching.
The indexes are loaded from HDFS to Solr cores, exactly like Solr would have read from local disk. The difference
in the design of Cloudera Search is the robust, distributed, and scalable storage layer of HDFS, which helps
eliminate costly downtime and allows for flexibility across workloads without having to move data. Search
queries can then be submitted to Solr through either the standard Solr API, or through a simple search GUI
application, included in Cloudera Search, which can be deployed in Hue.
Cloudera Search batch-oriented indexing capabilities can address needs for searching across batch uploaded
files or large data sets that are less frequently updated and less in need of near-real-time indexing. For such
cases, Cloudera Search includes a highly scalable indexing workflow based on MapReduce. A MapReduce workflow
is launched onto specified files or folders in HDFS, and the field extraction and Solr schema mapping is executed

10 | Cloudera Introduction
 CDH Overview

during the mapping phase. Reducers use Solr to write the data as a single index or as index shards, depending
on your configuration and preferences. Once the indexes are stored in HDFS, they can be queried using standard
Solr mechanisms, as previously described above for the near-real-time indexing use case.
The Lily HBase Indexer Service is a flexible, scalable, fault tolerant, transactional, near real-time oriented system
for processing a continuous stream of HBase cell updates into live search indexes. Typically, the time between
data ingestion using the Flume sink to that content potentially appearing in search results is measured in
seconds, although this duration is tunable. The Lily HBase Indexer uses Solr to index data stored in HBase. As
HBase applies inserts, updates, and deletes to HBase table cells, the indexer keeps Solr consistent with the
HBase table contents, using standard HBase replication features. The indexer supports flexible custom
application-specific rules to extract, transform, and load HBase data into Solr. Solr search results can contain
columnFamily:qualifier links back to the data stored in HBase. This way applications can use the Search
result set to directly access matching raw HBase cells. Indexing and searching do not affect operational stability
or write throughput of HBase because the indexing and searching processes are separate and asynchronous
to HBase.

Cloudera Search and Other Cloudera Components

Cloudera Search interacts with other Cloudera components to solve different problems. The following table lists
Cloudera components that contribute to the Search process and describes how they interact with Cloudera
Search:

Component Contribution Applicable To

HDFS Stores source documents. Search indexes source documents to All cases
make them searchable. Files that support Cloudera Search, such
as Lucene index files and write-ahead logs, are also stored in HDFS.
Using HDFS provides simpler provisioning on a larger base,
redundancy, and fault tolerance. With HDFS, Cloudera Search
servers are essentially stateless, so host failures have minimal
consequences. HDFS also provides snapshotting, inter-cluster
replication, and disaster recovery.
MapReduce Search includes a pre-built MapReduce-based job. This job can be Many cases
used for on-demand or scheduled indexing of any supported data
set stored in HDFS. This job utilizes cluster resources for scalable
batch indexing.
Flume Search includes a Flume sink that enables writing events directly Many cases
to indexers deployed on the cluster, allowing data indexing during
ingestion.
Hue Search includes a Hue front-end search application that uses Many cases
standard Solr APIs. The application can interact with data indexed
in HDFS. The application provides support for the Solr standard
query language, visualization of faceted search functionality, and
a typical full text search GUI-based.
ZooKeeper Coordinates distribution of data and metadata, also known as Many cases
shards. It provides automatic failover to increase service resiliency.
HBase Supports indexing of stored data, extracting columns, column Some cases
families, and key information as fields. Because HBase does not
use secondary indexing, Cloudera Search can complete full-text
searches of content in rows and tables in HBase.
Cloudera Manager Deploys, configures, manages, and monitors Cloudera Search Some cases
processes and resource utilization across services on the cluster.
Cloudera Manager helps simplify Cloudera Search administration,
but it is not required.

Cloudera Introduction | 11
CDH Overview

Component Contribution Applicable To

Oozie Automates scheduling and management of indexing jobs. Oozie Some cases
can check for new data and begin indexing jobs as required.
Impala Further analyzes search results. Some cases
Hive Further analyzes search results. Some cases
Avro Includes metadata that Cloudera Search can use for indexing. Some cases
Sqoop Ingests data in batch and enables data availability for batch Some cases
indexing.
Mahout Applies machine-learning processing to search results. Some cases

Apache Sentry Overview

Apache Sentry (incubating) is a granular, role-based authorization module for Hadoop. Sentry provides the ability
to control and enforce precise levels of privileges on data for authenticated users and applications on a Hadoop
cluster. Sentry currently works out of the box with Apache Hive, Hive Metastore/HCatalog, Apache Solr, Cloudera
Impala and HDFS (limited to Hive table data).
Sentry is designed to be a pluggable authorization engine for Hadoop components. It allows you to define
authorization rules to validate a user or application’s access requests for Hadoop resources. Sentry is highly
modular and can support authorization for a wide variety of data models in Hadoop.
For more information, see Sentry Overview.

12 | Cloudera Introduction
 Cloudera Manager 5 Overview

Cloudera Manager 5 Overview

Cloudera Manager is an end-to-end application for managing CDH clusters. Cloudera Manager sets the standard
for enterprise deployment by delivering granular visibility into and control over every part of the CDH
cluster—empowering operators to improve performance, enhance quality of service, increase compliance and
reduce administrative costs. With Cloudera Manager, you can easily deploy and centrally operate the complete
CDH stack and other managed services. The application automates the installation process, reducing deployment
time from weeks to minutes; gives you a cluster-wide, real-time view of hosts and services running; provides
a single, central console to enact configuration changes across your cluster; and incorporates a full range of
reporting and diagnostic tools to help you optimize performance and utilization. This primer introduces the basic
concepts, structure, and functions of Cloudera Manager.

Terminology
To effectively use Cloudera Manager, you should first understand its terminology. The relationship between the
terms is illustrated below and their definitions follow:

Some of the terms, such as cluster and service, will be used without further explanation. Others, such as role
group, gateway, host template, and parcel are expanded upon in later sections.

Note: A common point of confusion is the type-instance nature of "service" and "role". Cloudera
Manager and this primer sometimes uses the same term for type and instance. For example, the
Cloudera Manager Admin Console Clusters > ClusterName menu actually lists service instances. This
is similar to the practice in programming languages where for example the term "string" may indicate
either a type (java.lang.String) or an instance of that type ("hi there"). When it's necessary to
distinguish between types and instances, the word "type" is appended to indicate a type and the word
"instance" is appended to explicitly indicate an instance.

deployment
A configuration of Cloudera Manager and all the clusters it manages.

dynamic resource pool

A named configuration of resources and a policy for scheduling the resources among YARN applications or
Impala queries running in the pool.

Cloudera Introduction | 13
Cloudera Manager 5 Overview

cluster
A logical entity that contains a set of hosts, a single version of CDH installed on the hosts, and the service and
role instances running on the hosts. A host can belong to only one cluster.

host
A physical or virtual machine that runs role instances.

rack
A physical entity that contains a set of physical hosts typically served by the same switch.

service
A category of managed functionality, which may be distributed or not, running in a cluster. Sometimes referred
to as a service type. For example: MapReduce, HDFS, YARN, Spark, Accumulo. Whereas in traditional environments
multiple services run on one host, in distributed systems a service runs on many hosts.

service instance
An instance of a service running on a cluster. A service instance spans many role instances. For example: "HDFS-1"
and "yarn".

role
A category of functionality within a service. For example, the HDFS service has the following roles: NameNode,
SecondaryNameNode, DataNode, and Balancer. Sometimes referred to as a role type.

role instance
An instance of a role running on a host. It typically maps to a Unix process. For example: "NameNode-h1" and
"DataNode-h1".

role group
A set of configuration properties for a set of role instances.

host template
A set of role groups. When a template is applied to a host, a role instance from each role group is created and
assigned to that host.

gateway
A role that designates a host that should receive a client configuration for a service when the host does not
have any role instances for that service running on it.

parcel
A binary distribution format that contains compiled code and meta-information such as a package description,
version, and dependencies.

static service pool

A static partitioning of total cluster resources—CPU, memory, and I/O weight—across a set of services.
Cluster Example
Consider a cluster Cluster 1 with four hosts as shown in the following listing from Cloudera Manager:

14 | Cloudera Introduction
 Cloudera Manager 5 Overview

The host tcdn501-1 is the "master" host for the cluster, so it has many more role instances, 21, compared with
the 7 role instances running on the other hosts. In addition to the CDH "master" role instances, tcdn501-1 also
has Cloudera Management Service roles:

Cloudera Introduction | 15
Cloudera Manager 5 Overview

Architecture
As depicted below, the heart of Cloudera Manager is the Cloudera Manager Server. The Server hosts the Admin
Console Web Server and the application logic. It is responsible for installing software, configuring, starting, and
stopping services, and managing the cluster on which the services run.

The Cloudera Manager Server works with several other components:

• Agent - installed on every host. It is responsible for starting and stopping processes, unpacking configurations,
triggering installations, and monitoring the host.
• Management Service - a service consisting of a set of roles that perform various monitoring, alerting, and
reporting functions.
• Database - stores configuration and monitoring information. There are typically multiple logical databases
running across one or more database servers. For example, the Cloudera Manager Server and the monitoring
roles use different logical databases.
• Cloudera Repository - repository of software for distribution by Cloudera Manager.
• Clients - are the interfaces for interacting with the server:
– Admin Console - Web-based UI with which administrators manage clusters and Cloudera Manager.
– API - API with which developers create custom Cloudera Manager applications.

Heartbeating
Heartbeats are a primary communication mechanism in Cloudera Manager. By default the Agents send heartbeats
every 15 seconds to the Cloudera Manager Server. However, to reduce user latency the frequency is increased
when state is changing.
During the heartbeat exchange the Agent notifies the Cloudera Manager Server the actions it is performing. In
turn the Cloudera Manager Server responds with the actions the Agent should be performing. Both the Agent
and the Cloudera Manager Server end up doing some reconciliation. For example, if you start a service, the Agent
attempts to start the relevant processes; if a process fails to start, the server marks the start command as
having failed.

State Management
The Cloudera Manager Server maintains the state of the cluster. This state can be divided into two categories:
"model" and "runtime", both of which are stored in the Cloudera Manager Server database.

16 | Cloudera Introduction
 Cloudera Manager 5 Overview

Cloudera Manager models CDH and managed services: their roles, configurations, and inter-dependencies. Model
state captures what is supposed to run where, and with what configurations. For example, model state captures
the fact that a cluster contains 17 hosts, each of which is supposed to run a DataNode. You interact with the
model through the Cloudera Manager Admin Console configuration screens and API and operations such as
"Add Service".
Runtime state is what processes are running where, and what commands (for example, rebalance HDFS or
execute a Backup/Disaster Recovery schedule or rolling restart or stop) are currently being executed. The runtime
state includes the exact configuration files needed to run a process. When you press "Start" in Cloudera Manager
Admin Console, the server gathers up all the configuration for the relevant services and roles, validates it,
generates the configuration files, and stores them in the database.
When you update a configuration (for example, the Hue Server web port), you've updated the model state.
However, if Hue is running while you do this, it's still using the old port. When this kind of mismatch occurs, the
role is marked as having an "outdated configuration". To resynchronize, you restart the role (which triggers the
configuration re-generation and process restart).
While Cloudera Manager models all of the reasonable configurations, inevitably there are some cases that require
special handling. To allow you to workaround, for example, a bug or to explore unsupported options, Cloudera
Manager supports an "advanced configuration snippet" mechanism that lets you add properties directly to the
configuration files.

Configuration Management
Cloudera Manager defines configuration at several levels:
• The service level may define configurations that apply to the entire service instance, such as an HDFS service's
default replication factor (dfs.replication).
• The role group level may define configurations that apply to the member roles, such as the DataNodes' handler
count (dfs.datanode.handler.count). This can be set differently for different groups of DataNodes. For
example, DataNodes running on more capable hardware may have more handlers.
• The role instance level may override configurations that it inherits from its role group. This should be used
sparingly, because it easily leads to configuration divergence within the role group. One example usage is to
temporarily enable debug logging in a specific role instance to troubleshoot an issue.
• Hosts have configurations related to monitoring, software management, and resource management.
• Cloudera Manager itself has configurations related to its own administrative operations.

Role Groups
It is possible to set configuration at the service instance (for example, HDFS) or role instance (for example, the
DataNode on host17). An individual role inherits the configurations set at the service level. Configurations made
at the role level override those inherited from the service level. While this approach offers flexibility, it is tedious
to configure a set of role instances in the same way.

Cloudera Introduction | 17
Cloudera Manager 5 Overview

Cloudera Manager supports role groups, a mechanism for assigning configurations to a group of role instances.
The members of those groups then inherit those configurations. For example, in a cluster with heterogeneous
hardware, a DataNode role group can be created for each host type and the DataNodes running on those hosts
can be assigned to their corresponding role group. That makes it possible to set the configuration for all the
DataNodes running on the same hardware by modifying the configuration of one role group. The HDFS service
discussed earlier has the following role groups defined for the service's roles:

In addition to making it easy to manage the configuration of subsets of roles, role groups also make it possible
to maintain different configurations for experimentation or managing shared clusters for different users and/or
workloads.

Host Templates
In typical environments, sets of hosts have the same hardware and the same set of services running on them.
A host template defines a set of role groups (at most one of each type) in a cluster and provides two main
benefits:
• Adding new hosts to clusters easily - multiple hosts can have roles from different services created, configured,
and started in a single operation.
• Altering the configuration of roles from different services on a set of hosts easily - which is useful for quickly
switching the configuration of an entire cluster to accommodate different workloads or users.

Server and Client Configuration

Administrators are sometimes surprised that modifying /etc/hadoop/conf and then restarting HDFS has no
effect. That is because service instances started by Cloudera Manager do not read configurations from the
default locations. To use HDFS as an example, when not managed by Cloudera Manager, there would usually
be one HDFS configuration per host, located at /etc/hadoop/conf/hdfs-site.xml. Server-side daemons and
clients running on the same host would all use that same configuration.
Cloudera Manager distinguishes between server and client configuration. In the case of HDFS, the file
/etc/hadoop/conf/hdfs-site.xml contains only configuration relevant to an HDFS client. That is, by default,
if you run a program that needs to communicate with Hadoop, it will get the addresses of the NameNode and
JobTracker, and other important configurations, from that directory. A similar approach is taken for
/etc/hbase/conf and /etc/hive/conf.

In contrast, the HDFS role instances (for example, NameNode and DataNode) obtain their configurations from
a private per-process directory, under /var/run/cloudera-scm-agent/process/unique-process-name. Giving
each process its own private execution and configuration environment allows Cloudera Manager to control each
process independently. For example, here are the contents of an example 879-hdfs-NAMENODE process directory:

$ tree -a /var/run/cloudera-scm-Agent/process/879-hdfs-NAMENODE/
/var/run/cloudera-scm-Agent/process/879-hdfs-NAMENODE/
cloudera_manager_Agent_fencer.py
cloudera_manager_Agent_fencer_secret_key.txt

18 | Cloudera Introduction
 Cloudera Manager 5 Overview

cloudera-monitor.properties
core-site.xml
dfs_hosts_allow.txt
dfs_hosts_exclude.txt
event-filter-rules.json
hadoop-metrics2.properties
hdfs.keytab
hdfs-site.xml
log4j.properties
logs
stderr.log
stdout.log
topology.map
topology.py

There are several advantages to distinguishing between server and client configuration:
• Sensitive information in the server-side configuration, such as the password for the Hive Metastore RDBMS,
is not exposed to the clients.
• A service that depends on another service may deploy with customized configuration. For example, to get
good HDFS read performance, Cloudera Impala needs a specialized version of the HDFS client configuration,
which may be harmful to a generic client. This is achieved by separating the HDFS configuration for the
Impala daemons (stored in the per-process directory mentioned above) from that of the generic client
(/etc/hadoop/conf).
• Client configuration files are much smaller and more readable. This also avoids confusing non-administrator
Hadoop users with irrelevant server-side properties.

Deploying Client Configurations and Gateways

A client configuration is a zip file that contain the relevant configuration files with the settings for a service.
Each zip file contains the set of configuration files needed by the service. For example, the MapReduce client
configuration zip file contains copies of core-site.xml, hadoop-env.sh, hdfs-site.xml, log4j.properties,
and mapred-site.xml. Cloudera Manager supports a Download Client Configuration action to enable distributing
the client configuration file to users outside the cluster.
Cloudera Manager can deploy client configurations within the cluster; each applicable service has a Deploy Client
Configuration action. This action does not necessarily deploy the client configuration to the entire cluster; it only
deploys the client configuration to all the hosts that this service has been assigned to. For example, suppose a
cluster has 10 hosts, and a MapReduce service is running on hosts 1-9. When you use Cloudera Manager to
deploy the MapReduce client configuration, host 10 will not get a client configuration, because the MapReduce
service has no role assigned to it. This design is intentional to avoid deploying conflicting client configurations
from multiple services.
To deploy a client configuration to a host that does not have a role assigned to it you use a gateway. A gateway
is a marker to convey that a service should be accessible from a particular host. Unlike all other roles it has no
associated process. In the preceding example, to deploy the MapReduce client configuration to host 10, you
assign a MapReduce gateway role to that host.
Gateways can also be used to customize client configurations for some hosts. Gateways can be placed in role
groups and those groups can be configured differently. However, unlike role instances, there is no way to override
configurations for gateway instances.
In the cluster we discussed earlier, the three hosts (tcdn501-[2-5]) that do not have Hive role instances have
Hive gateways:

Cloudera Introduction | 19
Cloudera Manager 5 Overview

Process Management
In a non-Cloudera Manager managed cluster, you most likely start a role instance using an init script, for example,
service hadoop-hdfs-datanode start. Cloudera Manager does not use init scripts for the daemons it
manages; in a Cloudera Manager managed cluster, starting and stopping services using init scripts will not
work.
In a Cloudera Manager managed cluster you can only start or stop services via Cloudera Manager. Cloudera
Manager uses an open source process management tool called supervisord, which takes care of redirecting
log files, notifying of process failure, setting the effective user ID of the calling process to the right user, and so
on. Cloudera Manager supports automatically restarting a crashed process. It will also flag a role instance with
a bad state if it crashes repeatedly right after start up.
It is worth noting that stopping Cloudera Manager and the Cloudera Manager Agents will not bring down your
cluster; any running instances will keep running.
One of the Agent's main responsibilities is to start and stop processes. When the Agent detects a new process
from the heartbeat, the Agent creates a directory for it in /var/run/cloudera-scm-agent and unpacks the
configuration. These actions reflect an important point: a Cloudera Manager process never travels alone. In other
words, a process is more than just the arguments to exec()—it also includes configuration files, directories
that need to be created, and other information.
The Agent itself is started by init.d at start-up. It, in turn, contacts the server and figures out what processes
should be running. The Agent is monitored as part of Cloudera Manager's host monitoring: if the Agent stops
heartbeating, the host will be marked as having bad health.

Software Distribution Management

A major function of Cloudera Manager is to install CDH and managed service software in your cluster. Cloudera
Manager supports two software distribution formats: packages and parcels.
A package is a binary distribution format that contains compiled code and meta-information such as a package
description, version, and dependencies. Package management systems evaluate this meta-information to allow
package searches, perform upgrades to a newer version, and ensure that all dependencies of a package are
fulfilled. Cloudera Manager uses the native "system package manager" for each supported OS.
A parcel is a binary distribution format containing the program files, along with additional metadata used by
Cloudera Manager. There are a few notable differences between parcels and packages:
• Parcels are self-contained and installed in a versioned directory, which means that multiple versions of a
given parcel can be installed side-by-side. You can then designate one of these installed versions as the
active one. With packages, only one package can be installed at a time so there's no distinction between
what's installed and what's active.

20 | Cloudera Introduction
 Cloudera Manager 5 Overview

• Parcels can be installed at any location in the filesystem and by default are installed in
/opt/cloudera/parcels. In contrast, packages are installed in /usr/lib.

As a consequence of their unique properties, parcels offer a number of advantages over packages:
• CDH is distributed as a single object - In contrast to having a separate package for each part of CDH, when
using parcels there is just a single object to install. This is especially useful when managing a cluster that
isn't connected to the Internet.
• Internal consistency - All CDH components are matched so there isn't a danger of different parts coming
from different versions of CDH.
• Installation outside of /usr - In some environments, Hadoop administrators do not have privileges to install
system packages. In the past, these administrators had to fall back to CDH tarballs, which deprived them of
a lot of infrastructure that packages provide. With parcels, administrators can install to /opt or anywhere
else without having to step through all the additional manual steps of regular tarballs.

Note: With parcel software distribution, the path to the CDH libraries is
/opt/cloudera/parcels/CDH/lib instead of the usual /usr/lib. You should not link /usr/lib/
elements to parcel deployed paths, as such links may confuse scripts that distinguish between
the two paths.

• Installation of CDH without sudo - Parcel installation is handled by the Cloudera Manager Agent running as
root so it's possible to install CDH without needing sudo.
• Decouples distribution from activation - Due to side-by-side install capabilities, it is possible to stage a new
version of CDH across the cluster in advance of switching over to it. This allows the longest running part of
an upgrade to be done ahead of time without affecting cluster operations, consequently reducing the downtime
associated with upgrade.
• Rolling upgrades - These are only possible with parcels, due to their side-by-side nature. Packages require
shutting down the old process, upgrading the package, and then starting the new process. This can be hard
to recover from in the event of errors and requires extensive integration with the package management
system to function seamlessly. When a new version is staged side-by-side, switching to a new minor version
is simply a matter of changing which version of CDH is used when restarting each process. It then becomes
practical to do upgrades with rolling restarts, where service roles are restarted in the right order to switch
over to the new version with minimal service interruption. Your cluster can continue to run on the existing
installed components while you stage a new version across your cluster, without impacting your current
operations. Note that major version upgrades (for example, CDH 4 to CDH 5) require full service restarts due
to the substantial changes between the versions. Finally, you can upgrade individual parcels, or multiple
parcels at the same time.
• Easy downgrades - Reverting back to an older minor version can be as simple as upgrading. Note that some
CDH components may require explicit additional steps due to schema upgrades.
• Upgrade management - Cloudera Manager can fully manage all the steps involved in a CDH version upgrade.
In contrast, with packages, Cloudera Manager can only help with initial installation.
• Distributing additional components - Parcels are not limited to CDH. Cloudera Impala, Cloudera Search, LZO,
and add-on service parcels are also available.
• Compatibility with other distribution tools - If there are specific reasons to use other tools for download
and/or distribution, you can do so, and Cloudera Manager will work alongside your other tools. For example,
you can handle distribution with Puppet. Or, you can download the parcel to Cloudera Manager Server manually
(perhaps because your cluster has no Internet connectivity) and then have Cloudera Manager distribute the
parcel to the cluster.

Host Management
Cloudera Manager provides several features to manage the hosts in your Hadoop clusters. The first time you
run Cloudera Manager Admin Console you can search for hosts to add to the cluster and once the hosts are
selected you can map the assignment of CDH roles to hosts. Cloudera Manager automatically deploys all software

Cloudera Introduction | 21
Cloudera Manager 5 Overview

required to participate as a managed host in a cluster: JDK, Cloudera Manager Agent, CDH, Impala, Solr, and so
on to the hosts.
Once the services are deployed and running, the Hosts area within the Admin Console shows the overall status
of the managed hosts in your cluster. The information provided includes the version of CDH running on the host,
the cluster to which the host belongs, and the number of roles running on the host. Cloudera Manager provides
operations to manage the life cycle of the participating hosts and to add and delete hosts. The Cloudera
Management Service Host Monitor role performs health tests and collects host metrics to allow you to monitor
the health and performance of the hosts.

Resource Management
Resource management helps ensure predictable behavior by defining the impact of different services on cluster
resources. The goals of resource management features are to:
• Guarantee completion in a reasonable time frame for critical workloads
• Support reasonable cluster scheduling between groups of users based on fair allocation of resources per
group
• Prevent users from depriving other users access to the cluster
Cloudera Manager 4 introduced the ability to partition resources across HBase, HDFS, Impala, MapReduce, and
YARN services by allowing you to set configuration properties that were enforced by Linux control groups (Linux
cgroups). With Cloudera Manager 5, the ability to statically allocate resources using cgroups is configurable
through a single static service pool wizard. You allocate services a percentage of total resources and the wizard
configures the cgroups.
Static service pools isolate the services in your cluster from one another, so that load on one service has a
bounded impact on other services. Services are allocated a static percentage of total resources—CPU, memory,
and I/O weight—which are not shared with other services. When you configure static service pools, Cloudera
Manager computes recommended memory, CPU, and I/O configurations for the worker roles of the services
that correspond to the percentage assigned to each service. Static service pools are implemented per role group
within a cluster, using Linux control groups (cgroups) and cooperative memory limits (for example, Java maximum
heap sizes). Static service pools can be used to control access to resources by HBase, HDFS, Impala, MapReduce,
Solr, Spark, YARN, and add-on services. Static service pools are not enabled by default.
For example, the following figure illustrates static pools for HBase, HDFS, Impala, and YARN services that are
respectively assigned 20%, 30%, 20%, and 30% of cluster resources.

Cloudera Manager allows you to manage mechanisms for dynamically apportioning resources statically allocated
to YARN and Impala using dynamic resource pools.

22 | Cloudera Introduction
 Cloudera Manager 5 Overview

Depending on the version of CDH you are using, dynamic resource pools in Cloudera Manager support the
following resource management (RM) scenarios:
• (CDH 5) YARN Independent RM - YARN manages the virtual cores, memory, running applications, and scheduling
policy for each pool. In the preceding diagram, three dynamic resource pools - Dev, Product, and Mktg with
weights 3, 2, and 1 respectively - are defined for YARN. If an application starts and is assigned to the Product
pool, and other applications are using the Dev and Mktg pools, the Product resource pool will receive 30% x
2/6 (or 10%) of the total cluster resources. If there are no applications using the Dev and Mktg pools, the
YARN Product pool will be allocated 30% of the cluster resources.
• (CDH 5) YARN and Impala Integrated RM - YARN manages memory for pools running Impala queries; Impala
limits the number of running and queued queries in each pool. In the YARN and Impala integrated RM scenario,
Impala services can reserve resources through YARN, effectively sharing the static YARN service pool and
resource pools with YARN applications. The integrated resource management scenario, where both YARN
and Impala use the YARN resource management framework, require the Impala Llama role.
In the following figure, the YARN and Impala services have a 50% static share which is subdivided among the
original resource pools with an additional resource pool designated for the Impala service. If YARN applications
are using all the original pools, and Impala uses its designated resource pool, Impala queries will have the
same resource allocation 50% x 4/8 = 25% as in the first scenario. However, when YARN applications are not
using the original pools, Impala queries will have access to 50% of the cluster resources.

Note:
When using YARN with Impala, Cloudera recommends using the static partitioning technique
(through a static service pool) rather than the combination of YARN and Llama. YARN is a central,
synchronous scheduler and thus introduces higher latency and variance which is better suited for
batch processing than for interactive workloads like Impala (especially with higher concurrency).
Currently, YARN allocates memory throughout the query, making it hard to reason about
out-of-memory and timeout conditions.

• (CDH 5) YARN and Impala Independent RM - YARN manages the virtual cores, memory, running applications,
and scheduling policy for each pool; Impala manages memory for pools running queries and limits the number
of running and queued queries in each pool.
• (CDH 5 and CDH 4) Impala Independent RM - Impala manages memory for pools running queries and limits
the number of running and queued queries in each pool.
The scenarios where YARN manages resources, whether for independent RM or integrated RM, map to the YARN
scheduler configuration. The scenarios where Impala independently manages resources employ the Impala
admission control feature.

Cloudera Introduction | 23
Cloudera Manager 5 Overview

User Management
Access to Cloudera Manager features is controlled by user accounts. A user account identifies how a user is
authenticated and determines what privileges are granted to the user.
Cloudera Manager provides several mechanisms for authenticating users. You can configure Cloudera Manager
to authenticate users against the Cloudera Manager database or against an external authentication service.
The external authentication service can be an LDAP server (Active Directory or an OpenLDAP compatible directory),
or you can specify another external service. Cloudera Manager also supports using the Security Assertion Markup
Language (SAML) to enable single sign-on.
A user account can be assigned one of the following roles:
• Auditor - View data and audit events in Cloudera Manager.
• Read-Only - View monitoring information, as well as data.
• Limited Operator - Decommission hosts, as well as view service and monitoring information and data.
• Operator - Decommission and recommission hosts and roles, as well as view service and monitoring
information and data.
• Configurator - Perform the Operator operations described above, configure services, enter and exit maintenance
mode, and manage dashboards.
• Cluster Administrator - View all data and perform all actions except the following: administer Cloudera
Navigator, perform replication and snapshot operations, view audit events, manage user accounts, and
configure external authentication.
• BDR Administrator - View service and monitoring information and data, and perform replication and snapshot
operations.
• Navigator Administrator - View service and monitoring information and data, view audit events, and administer
Cloudera Navigator.
• User Administrator - Manage user accounts and configure external authentication, as well as view service
and monitoring information and data.
• Full Administrator - View all data and do all actions, including reconfiguring and restarting services, and
administering other users.
For more information about the privileges associated with each of the Cloudera Manager user roles, see Cloudera
Manager User Roles.

Security Management
Cloudera Manager strives to consolidate security configurations across several projects.

24 | Cloudera Introduction
 Cloudera Manager 5 Overview

Authentication
The purpose of authentication in Hadoop, as in other systems, is simply to prove that a user or service is who
he or she claims to be.
Typically, authentication in enterprises is managed through a single distributed system, such as a Lightweight
Directory Access Protocol (LDAP) directory. LDAP authentication consists of straightforward username/password
services backed by a variety of storage systems, ranging from file to database.
A common enterprise-grade authentication system is Kerberos. Kerberos provides strong security benefits
including capabilities that render intercepted authentication packets unusable by an attacker. It virtually
eliminates the threat of impersonation by never sending a user's credentials in cleartext over the network.
Several components of the Hadoop ecosystem are converging to use Kerberos authentication with the option
to manage and store credentials in LDAP or AD. For example, Microsoft's Active Directory (AD) is an LDAP directory
that also provides Kerberos authentication for added security.

Authorization
Authorization is concerned with who or what has access or control over a given resource or service. Since Hadoop
merges together the capabilities of multiple varied, and previously separate IT systems as an enterprise data
hub that stores and works on all data within an organization, it requires multiple authorization controls with
varying granularities. In such cases, Hadoop management tools simplify setup and maintenance by:
• Tying all users to groups, which can be specified in existing LDAP or AD directories.
• Providing role-based access control for similar interaction methods, like batch and interactive SQL queries.
For example, Apache Sentry permissions apply to Hive (HiveServer2) and Impala.
CDH currently provides the following forms of access control:
• Traditional POSIX-style permissions for directories and files, where each directory and file is assigned a single
owner and group. Each assignment has a basic set of permissions available; file permissions are simply read,
write, and execute, and directories have an additional permission to determine access to child directories.
• Extended Access Control Lists (ACLs) for HDFS that provide fine-grained control of permissions for HDFS
files by allowing you to set different permissions for specific named users and/or named groups.
• Apache HBase uses ACLs to authorize various operations (READ, WRITE, CREATE, ADMIN) by column,
column family, and column family qualifier. HBase ACLs are granted and revoked to both users and groups.
• Role-based access control with Apache Sentry.

Encryption
The goal of encryption is to ensure that only authorized users can view, use, or contribute to a data set. These
security controls add another layer of protection against potential threats by end-users, administrators and
other malicious actors on the network. Data protection can be applied at a number of levels within Hadoop:
• OS Filesystem-level - Encryption can be applied at the Linux operating system file system level to cover all
files in a volume. An example of this approach is Cloudera Navigator Encrypt (formerly Gazzang zNcrypt)
which is available for Cloudera customers licensed for Cloudera Navigator. Navigator Encrypt operates at the
Linux volume level, so it can encrypt cluster data inside and outside HDFS, such as temp/spill files,
configuration files and metadata databases (to be used only for data related to a CDH cluster). Navigator
Encrypt must be used with Navigator Key Trustee (formerly Gazzang zTrustee).
• HDFS-level - Encryption applied by the HDFS client software. HDFS Data At Rest Encryption operates at the
HDFS folder level, enabling encryption to be applied only to the HDFS folders where it is needed. Cannot
encrypt any data outside HDFS. To ensure reliable key storage (so that data is not lost), Navigator Key Trustee
should be used, while the default Java keystore can be used for test purposes.
• Network-level - Encryption can be applied to encrypt data just before it gets sent across a network and to
decrypt it as soon as it is received. In Hadoop this means coverage for data sent from client user interfaces
as well as service-to-service communication like remote procedure calls (RPCs). This protection uses
industry-standard protocols such as SSL/TLS.

Cloudera Introduction | 25
Cloudera Manager 5 Overview

Cloudera Management Service

The Cloudera Management Service implements various management features as a set of roles:
• Activity Monitor - collects information about activities run by the MapReduce service. This role is not added
by default.
• Host Monitor - collects health and metric information about hosts
• Service Monitor - collects health and metric information about services and activity information from the
YARN and Impala services
• Event Server - aggregates relevant Hadoop events and makes them available for alerting and searching
• Alert Publisher - generates and delivers alerts for certain types of events
• Reports Manager - generates reports that provide an historical view into disk utilization by user, user group,
and directory, processing activities by user and YARN pool, and HBase tables and namespaces. This role is
not added in Cloudera Express.
In addition, for certain editions of the Cloudera Enterprise license, the Cloudera Management Service provides
the Navigator Audit Server and Navigator Metadata Server roles for Cloudera Navigator.

Health Tests
Cloudera Manager monitors the health of the services, roles, and hosts that are running in your clusters via
health tests. The Cloudera Management Service also provides health tests for its roles. Role-based health tests
are enabled by default. For example, a simple health test is whether there's enough disk space in every NameNode
data directory. A more complicated health test may evaluate when the last checkpoint for HDFS was compared
to a threshold or whether a DataNode is connected to a NameNode. Some of these health tests also aggregate
other health tests: in a distributed system like HDFS, it's normal to have a few DataNodes down (assuming
you've got dozens of hosts), so we allow for setting thresholds on what percentage of hosts should color the
entire service down.
Health tests can return one of three values: Good, Concerning, and Bad. A test returns Concerning health if the
test falls below a warning threshold. A test returns Bad if the test falls below a critical threshold. The overall
health of a service or role instance is a roll-up of its health tests. If any health test is Concerning (but none are
Bad) the role's or service's health is Concerning; if any health test is Bad, the service's or role's health is Bad.

In the Cloudera Manager Admin Console, health tests results are indicated with colors: Good , Concerning ,
and Bad .
One common question is whether monitoring can be separated from configuration. One of the goals for monitoring
is to enable it without needing to do additional configuration and installing additional tools (for example, Nagios).
By having a deep model of the configuration, Cloudera Manager is able to know which directories to monitor,
which ports to use, and what credentials to use for those ports. This tight coupling means that, when you install
Cloudera Manager all the monitoring is enabled.

Metric Collection and Display

To perform monitoring, the Service Monitor and Host Monitor collects metrics. A metric is a numeric value,
associated with a name (for example, "CPU seconds"), an entity it applies to ("host17"), and a timestamp. Most
metric collection is performed by the Agent. The Agent communicates with a supervised process, requests the
metrics, and forwards them to the Service Monitor. In most cases, this is done once per minute.
A few special metrics are collected by the Service Monitor. For example, the Service Monitor hosts an HDFS
canary, which tries to write, read, and delete a file from HDFS at regular intervals, and measure whether it
succeeded, and how long it took. Once metrics are received, they're aggregated and stored.
Using the Charts page in the Cloudera Manager Admin Console, you can query and explore the metrics being
collected. Charts display time series, which are streams of metric data points for a specific entity. Each metric
data point contains a timestamp and the value of that metric at that timestamp.

26 | Cloudera Introduction
 Cloudera Manager 5 Overview

Some metrics (for example, total_cpu_seconds) are counters, and the appropriate way to query them is to
take their rate over time, which is why a lot of metrics queries contain the dt0 function. For example,
dt0(total_cpu_seconds). (The dt0 syntax is intended to remind you of derivatives. The 0 indicates that the
rate of a monotonically increasing counter should never have negative rates.)

Events, Alerts, and Triggers

An event is a record that something of interest has occurred – a service's health has changed state, a log message
(of the appropriate severity) has been logged, and so on. Many events are enabled and configured by default.
An alert is an event that is considered especially noteworthy and is triggered by a selected event. Alerts are
shown with an badge when they appear in a list of events. You can configure the Alert Publisher to
send alert notifications by email or via SNMP trap to a trap receiver.
A trigger is a statement that specifies an action to be taken when one or more specified conditions are met for
a service, role, role configuration group, or host. The conditions are expressed as a tsquery statement, and the
action to be taken is to change the health for the service, role, role configuration group, or host to either Concerning
(yellow) or Bad (red).

Cloudera Manager Admin Console

Cloudera Manager Admin Console is the web-based UI that you use to configure, manage, and monitor CDH.
If there are no services configured when you log into the Cloudera Manager Admin Console, the Cloudera Manager
installation wizard displays. If services have been configured, the Cloudera Manager top navigation bar:

and Home page display. In addition to a link to the Home page, the Cloudera Manager Admin Console top
navigation bar provides the following features:
• Clusters > ClusterName
– Services - Display individual services, and the Cloudera Management Service. In these pages you can:
– View the status and other details of a service instance or the role instances associated with the service
– Make configuration changes to a service instance, a role, or a specific role instance
– Add and delete a service or role
– Stop, start, or restart a service or role.
– View the commands that have been run for a service or a role
– View an audit event history
– Deploy and download client configurations
– Decommission and recommission role instances
– Enter or exit maintenance mode
– Perform actions unique to a specific type of service. For example:
– Enable HDFS high availability or NameNode federation
– Run the HDFS Balancer
– Create HBase, Hive, and Sqoop directories

– Hosts - Displays the hosts in the cluster.

– Dynamic Resource Pools - Manage dynamic allocation of cluster resources to YARN and Impala services
by specifying the relative weights of named pools.
– Static Service Pools - Manage static allocation of cluster resources to HBase, HDFS, Impala, MapReduce,
and YARN services.

Cloudera Introduction | 27
Cloudera Manager 5 Overview

– Reports - Create reports about the HDFS, MapReduce, YARN, and Impala usage and browse HDFS files,
and manage quotas for HDFS directories.
– ImpalaServiceName Queries - Query information about Impala queries running on your cluster.
– MapReduceServiceName Jobs - Query information about MapReduce jobs running on your cluster.
– YARNServiceName Applications - Query information about YARN applications running on your cluster.
• Hosts - Display the hosts managed by Cloudera Manager. In this page you can:
– View the status and a variety of detail metrics about individual hosts
– Make configuration changes for host monitoring
– View all the processes running on a host
– Run the Host Inspector
– Add and delete hosts
– Create and manage host templates
– Manage parcels
– Decommission and recommission hosts
– Make rack assignments
– Run the host upgrade wizard
• Diagnostics - Review logs, events, and alerts to diagnose problems. The subpages are:
– Events - Search for and displaying events and alerts that have occurred.
– Logs - Search logs by service, role, host, and search phrase as well as log level (severity).
– Server Log -Display the Cloudera Manager Server log.
• Audits - Query and filter audit events across clusters.
• Charts - Query for metrics of interest, display them as charts, and display personalized chart dashboards.
• Backup - Manage replication schedules and snapshot policies.
• Administration - Administer Cloudera Manager. The subpages are:
– Settings - Configure Cloudera Manager.
– Alerts - Display when alerts will be generated, configure alert recipients, and send test alert email.
– Users - Manage Cloudera Manager users.
– Kerberos - Generate Kerberos credentials and inspect hosts.
– License - Manage Cloudera licenses.
– Language - Set the language used for the content of activity events, health events, and alert email
messages.
– Peers - Connect multiple instances of Cloudera Manager.
• Indicators
– Parcel Indicator - indicates how many parcels are eligible for downloading or distribution.
– Running Commands Indicator - displays the number of commands currently running for all services
or roles.
• Search - Supports searching for services, roles, hosts, configuration properties, and commands. You can enter
a partial string and a drop-down list with up to sixteen entities that match will display.
• Support - Displays various support actions. The subcommands are:
– Send Diagnostic Data - Sends data to Cloudera Support to support troubleshooting.
– Support Portal (Cloudera Enterprise) - Displays the Cloudera Support portal.
– Mailing List (Cloudera Express) - Displays the Cloudera Manager Users list.
– Scheduled Diagnostics: Weekly - Configure the frequency of automatically collecting diagnostic data and
sending to Cloudera support.
– The following links open the latest documentation on the Cloudera web site:
– Help

28 | Cloudera Introduction
 Cloudera Manager 5 Overview

– Installation Guide
– API Documentation
– Release Notes
– About - Version number and build details of Cloudera Manager and the current date and time stamp of
the Cloudera Manager server.
• Logged-in User Menu - The currently logged-in user. The subcommands are:
– Change Password - Change the password of the currently logged in user.
– Logout

Starting and Logging into the Admin Console

1. In a web browser, enter http://Server host:7180, where Server host is the fully qualified domain name
or IP address of the host where the Cloudera Manager Server is running. The login screen for Cloudera
Manager Admin Console displays.
2. Log into Cloudera Manager Admin Console using the credentials assigned by your administrator. User accounts
are assigned roles that constrain the features available to you.

Home Page
When you start the Cloudera Manager Admin Console on page 27, the Home page displays.

You can also navigate to the Home page by clicking Home in the top navigation bar.

Status
The default tab displayed when the Home page displays. It contains:
• Clusters - The clusters being managed by Cloudera Manager. Each cluster is displayed either in summary
form or in full form depending on the configuration of the Administration > Settings > Other > Maximum
Cluster Count Shown In Full property. When the number of clusters exceeds the value of the property, only
cluster summary information displays.
– Summary Form - A list of links to cluster status pages. Click Customize to jump to the Administration >
Settings > Other > Maximum Cluster Count Shown In Full property.
– Full Form - A separate section for each cluster containing a link to the cluster status page and a table
containing links to the Hosts page and the status pages of the services running in the cluster.

Cloudera Introduction | 29
Cloudera Manager 5 Overview

Each service row in the table has a menu of actions that you select by clicking and can contain one or
more of the following indicators:

Indicator Meaning Description

Health issue Indicates that the service has at least one health issue. The indicator
shows the number of health issues at the highest severity level. If there
are Bad health test results, the indicator is red. If there are no Bad health
test results, but Concerning test results exist, then the indicator is yellow.
No indicator is shown if there are no Bad or Concerning health test results.

Important: If there is one Bad health test result and two

Concerning health results, there will be three health issues, but
the number will be one.

Click the indicator to display the Health Issues pop-up dialog.

By default only Bad health test results are shown in the dialog. To display
Concerning health test results, click the Also show n concerning issue(s)
link.Click the link to display the Status page containing with details about
the health test result.

Configuration Indicates that the service has at least one configuration issue. The
issue indicator shows the number of configuration issues at the highest severity
level. If there are configuration errors, the indicator is red. If there are no
errors but configuration warnings exist, then the indicator is yellow. No
indicator is shown if there are no configuration notifications.

Important: If there is one configuration error and two

configuration warnings, there will be three configuration issues,
but the number will be one.

Click the indicator to display the Configuration Issues pop-up dialog.

By default only notifications at the Error severity level are listed, grouped
by service name are shown in the dialog. To display Warning notifications,
click the Also show n warning(s) link.Click the message associated with
an error or warning to be taken to the configuration property for which
the notification has been issued where you can address the issue.See
Managing Services.

Restart Configuration Indicates that at least one of a service's roles is running with a
Needed modified configuration that does not match the current configuration settings in
Cloudera Manager.
Refresh
Needed Click the indicator to display the Stale Configurations page.To bring the
cluster up-to-date, click the Refresh or Restart button on the Stale
Configurations page or follow the instructions in Refreshing a Cluster,
Restarting a Cluster, or Restarting Services and Instances after
Configuration Changes.

Client Indicates that the client configuration for a service should be redeployed.
configuration
Click the indicator to display the Stale Configurations page.To bring the
redeployment
cluster up-to-date, click the Deploy Client Configuration button on the
required
Stale Configurations page or follow the instructions in Manually
Redeploying Client Configuration Files.

30 | Cloudera Introduction
 Cloudera Manager 5 Overview

– Cloudera Management Service - A table containing a link to the Cloudera Manager Service. The Cloudera
Manager Service has a menu of actions that you select by clicking .
– Charts - A set of charts (dashboard) that summarize resource utilization (IO, CPU usage) and processing
metrics.
Click a line, stack area, scatter, or bar chart to expand it into a full-page view with a legend for the individual
charted entities as well more fine-grained axes divisions.
By default the time scale of a dashboard is 30 minutes. To change the time scale, click a duration link
at the top-right of the dashboard.

To set the dashboard type, click and select one of the following:
• Custom - displays a custom dashboard.
• Default - displays a default dashboard.
• Reset - resets the custom dashboard to the predefined set of charts, discarding any customizations.

All Health Issues

Displays all health issues by cluster. The number badge has the same semantics as the per service health issues
reported on the Status tab.
• By default only Bad health test results are shown in the dialog. To display Concerning health test results,
click the Also show n concerning issue(s) link.
• To group the health test results by entity or health test, click the buttons on the Organize by Entity/Organize
by Health Test toggle.
• Click the link to display the Status page containing with details about the health test result.

All Configuration Issues

Displays all configuration issues by cluster. The number badge has the same semantics as the per service
configuration issues reported on the Status tab. By default only notifications at the Error severity level are listed,
grouped by service name are shown in the dialog. To display Warning notifications, click the Also show n warning(s)
link. Click the message associated with an error or warning to be taken to the configuration property for which
the notification has been issued where you can address the issue.

All Recent Commands

Displays all commands run recently across the clusters. A badge indicates how many recent commands are
still running. Click the command link to display details about the command and child commands. See also Viewing
Running and Recent Commands.

Cloudera Manager API

The Cloudera Manager API provides configuration and service lifecycle management, service health information
and metrics, and allows you to configure Cloudera Manager itself. The API is served on the same host and port
as the Cloudera Manager Admin Console on page 27, and does not require an extra process or extra configuration.
The API supports HTTP Basic Authentication, accepting the same users and credentials as the Cloudera Manager
Admin Console.

Resources
• Quick Start
• Cloudera Manager API tutorial
• Cloudera Manager API documentation
• Python client

Cloudera Introduction | 31
Cloudera Manager 5 Overview

• Using the Cloudera Manager Java API for Cluster Automation on page 34
Obtaining Configuration Files
1. Obtain the list of a service's roles:

http://cm_server_host:7180/api/v10/clusters/clusterName/services/serviceName/roles

2. Obtain the list of configuration files a process is using:

http://cm_server_host:7180/api/v10/clusters/clusterName/services/serviceName/roles/roleName/process

3. Obtain the content of any particular file:

http://cm_server_host:7180/api/v10/clusters/clusterName/services/serviceName/roles/roleName/process/
configFiles/configFileName

For example:

http://cm_server_host:7180/api/v10/clusters/Cluster%201/services/OOZIE-1/roles/
OOZIE-1-OOZIE_SERVER-e121641328fcb107999f2b5fd856880d/process/configFiles/oozie-site.xml

Retrieving Service and Host Properties

To update a service property using the Cloudera Manager APIs, you'll need to know the name of the property,
not just the display name. If you know the property's display name but not the property name itself, retrieve
the documentation by requesting any configuration object with the query string view=FULL appended to the
URL. For example:

http://cm_server_host:7180/api/v10/clusters/Cluster%201/services/service_name/config?view=FULL

Search the results for the display name of the desired property. For example, a search for the display name
HDFS Service Environment Advanced Configuration Snippet (Safety Valve) shows that the corresponding property
name is hdfs_service_env_safety_valve:

{
"name" : "hdfs_service_env_safety_valve",
"require" : false,
"displayName" : "HDFS Service Environment Advanced Configuration Snippet (Safety
Valve)",
"description" : "For advanced use onlyu, key/value pairs (one on each line) to be
inserted into a roles
environment. Applies to configurations of all roles in this service except client
configuration.",
"relatedName" : "",
"validationState" : "OK"
}

Similar to finding service properties, you can also find host properties. First, get the host IDs for a cluster with
the URL:

http://cm_server_host:7180/api/v10/hosts

This should return host objects of the form:

{
"hostId" : "2c2e951c-aaf2-4780-a69f-0382181f1821",
"ipAddress" : "10.30.195.116",
"hostname" : "cm_server_host",
"rackId" : "/default",
"hostUrl" :
"http://cm_server_host:7180/cmf/hostRedirect/2c2e951c-adf2-4780-a69f-0382181f1821",

32 | Cloudera Introduction
 Cloudera Manager 5 Overview

"maintenanceMode" : false,
"maintenanceOwners" : [ ],
"commissionState" : "COMMISSIONED",
"numCores" : 4,
"totalPhysMemBytes" : 10371174400
}

Then obtain the host properties by including one of the returned host IDs in the URL:

http://cm_server_host:7180/api/v10/hosts/2c2e951c-adf2-4780-a69f-0382181f1821?view=FULL

Backing Up and Restoring the Cloudera Manager Configuration

You can use the Cloudera Manager REST API to export and import all of its configuration data. The API exports
a JSON document that contains configuration data for the Cloudera Manager instance. You can use this JSON
document to back up and restore a Cloudera Manager deployment.

Required Role:

Exporting the Cloudera Manager Configuration

1. Log in to the Cloudera Manger server host as the root user.
2. Run the following command:

# curl -u admin_uname:admin_pass "http://cm_server_host:7180/api/v10/cm/deployment"

>
path_to_file/cm-deployment.json

Where:
• admin_uname is a username with either the Full Administrator or Cluster Administrator role.
• admin_pass is the password for the admin_uname username.
• cm_server_host is the hostname of the Cloudera Manager server.
• path_to_file is the path to the file where you want to save the configuration.

Restoring the Cloudera Manager Configuration

Using a previously saved JSON document that contains the Cloudera Manager configuration data, you can restore
that configuration to a running cluster.
1. Using the Cloudera Manager Administration Console, stop all running services in your cluster:
a.
On the Home page, click to the right of the cluster name and select Stop.
b. Click Stop in the confirmation screen. The Command Details window shows the progress of stopping
services.
When All services successfully stopped appears, the task is complete and you can close the Command
Details window.

Warning: If you do not stop the cluster before making this API call, the API call will stop all cluster
services before running the job. Any running jobs and data are lost.

2. Log in to the Cloudera Manger server host as the root user.

Cloudera Introduction | 33
Cloudera Manager 5 Overview

3. Run the following command:

# curl --upload-file path_to_file/cm-deployment.json

-u admin_uname:admin_pass
http://cm_server_host:7180/api/v10/cm/deployment?deleteCurrentDeployment=true

Where:
• admin_uname is a username with either the Full Administrator or Cluster Administrator role.
• admin_pass is the password for the admin_uname username.
• cm_server_host is the hostname of the Cloudera Manager server.
• path_to_file is the path to the file containing the JSON configuration file.

Using the Cloudera Manager Java API for Cluster Automation

One of the complexities of Apache Hadoop is the need to deploy clusters of servers, potentially on a regular
basis. If you maintain hundreds of test and development clusters in different configurations, this process can
be complex and cumbersome if not automated.

Cluster Automation Use Cases

Cluster automation is useful in various situations. For example, you might work on many versions of CDH, which
works on a wide variety of OS distributions (RHEL 5 and RHEL 6, Ubuntu Precise and Lucid, Debian Wheezy, and
SLES 11). You might have complex configuration combinations—highly available HDFS or simple HDFS, Kerberized
or non-secure, YARN or MRv1, and so on. With these requirements, you need an easy way to create a new cluster
that has the required setup. This cluster can also be used for integration, testing, customer support,
demonstrations, and other purposes.
You can install and configure Hadoop according to precise specifications using the Cloudera Manager REST API.
Using the API, you can add hosts, install CDH, and define the cluster and its services. You can also tune heap
sizes, set up HDFS HA, turn on Kerberos security and generate keytabs, and customize service directories and
ports. Every configuration available in Cloudera Manager is exposed in the API.
The API also provides access to management functions:
• Obtaining logs and monitoring the system
• Starting and stopping services
• Polling cluster events
• Creating a disaster recovery replication schedule
For example, you can use the API to retrieve logs from HDFS, HBase, or any other service, without knowing the
log locations. You can also stop any service with no additional steps.
Use scenarios for the Cloudera Manager API for cluster automation might include:
• OEM and hardware partners that deliver Hadoop-in-a-box appliances using the API to set up CDH and
Cloudera Manager on bare metal in the factory.
• Automated deployment of new clusters, using a combination of Puppet and the Cloudera Manager API.
Puppet does the OS-level provisioning and installs the software. The Cloudera Manager API sets up the
Hadoop services and configures the cluster.
• Integrating the API with reporting and alerting infrastructure. An external script can poll the API for health
and metrics information, as well as the stream of events and alerts, to feed into a custom dashboard.

Java API Examples

This example covers the Java API client.

34 | Cloudera Introduction
 Cloudera Manager 5 Overview

To use the Java client, add this dependency to your project's pom.xml:

<project>
<repositories>
<repository>
<id>cdh.repo</id>
<url>https://repository.cloudera.comgroups/cloudera-repos</url>
<name>Cloudera Repository</name>
</repository>
…
</repositories>
<dependencies>
<dependency>
<groupId>com.cloudera.api</groupId>
<artifactId>cloudera-manager-api</artifactId>
<version>4.6.2</version> <!-- Set to the version of Cloudera Manager you
use -->
</dependency>
…
</dependencies>
...
</project>

The Java client works like a proxy. It hides from the caller any details about REST, HTTP, and JSON. The entry
point is a handle to the root of the API:

RootResourceV10 apiRoot = new ClouderaManagerClientBuilder().withHost("cm.cloudera.com")

.withUsernamePassword("admin", "admin").build().getRootV10();

From the root, you can traverse down to all other resources. (It's called "v10" because that is the current Cloudera
Manager API version, but the same builder will also return a root from an earlier version of the API.) The tree
view shows some key resources and supported operations:
• RootResourceV10
– ClustersResourceV10 - host membership, start cluster
– ServicesResourceV10 - configuration, get metrics, HA, service commands
– RolesResource - add roles, get metrics, logs
– RoleConfigGroupsResource - configuration
– ParcelsResource - parcel management

• HostsResource - host management, get metrics

• UsersResource - user management
For more information, see the Javadoc.
The following example lists and starts a cluster:

// List of clusters
ApiClusterList clusters = apiRoot.getClustersResource().readClusters(DataView.SUMMARY);
for (ApiCluster cluster : clusters) {
LOG.info("{}: {}", cluster.getName(), cluster.getVersion());
}

// Start the first cluster

ApiCommand cmd = apiRoot.getClustersResource().startCommand(clusters.get(0).getName());
while (cmd.isActive()) {
Thread.sleep(100);
cmd = apiRoot.getCommandsResource().readCommand(cmd.getId());
}
LOG.info("Cluster start {}", cmd.getSuccess() ? "succeeded" : "failed " +
cmd.getResultMessage());

To see a full example of cluster deployment using the Java client, see whirr-cm. Go to CmServerImpl#configure
to see the relevant code.

Cloudera Introduction | 35
Cloudera Manager 5 Overview

Extending Cloudera Manager

In addition to the set of software packages and services managed by Cloudera Manager, you can also define
and add new types of services using custom service descriptors. When you deploy a custom service descriptor,
the implementation is delivered in a Cloudera Manager parcel or other software package. For information on
the extension mechanisms provided by Cloudera Manager for creating custom service descriptors and parcels,
see Cloudera Manager Extensions.

36 | Cloudera Introduction
 Cloudera Navigator 2 Overview

Cloudera Navigator 2 Overview

Cloudera Navigator is a fully integrated data management tool for the Hadoop platform. Data management
capabilities are critical for enterprise customers that are in highly regulated industries and have stringent
compliance requirements.
Cloudera Navigator provides two categories of functionality:
• Auditing data access and verifying access privileges - The goal of auditing is to capture a complete and
immutable record of all activity within a system. While Hadoop has historically lacked centralized
cross-component audit capabilities, products such as Cloudera Navigator add secured, real-time audit
components to key data and access frameworks. Cloudera Navigator allows administrators to configure,
collect, and view audit events, to understand who accessed what data and how. Cloudera Navigator also
allows administrators to generate reports that list the HDFS access permissions granted to groups.
Cloudera Navigator tracks access permissions and actual accesses to all entities in HDFS, Hive, HBase, Impala,
and Sentry to help answer questions such as - who has access to which entities, which entities were accessed
by a user, when was an entity accessed and by whom, what entities were accessed using a service, which
device was used to access, and so on. Cloudera Navigator auditing supports tracking access to:
• HDFS data accessed through HDFS, Hive, HBase, Cloudera Impala, and Cloudera Search services
• HBase and Impala operations
• Hive metadata
• Sentry access
• Solr access
• Cloudera Navigator Metadata Server access
• Searching metadata and visualizing lineage - Cloudera Navigator metadata management features allow
DBAs, data modelers, business analysts, and data scientists to search for, amend the properties of, and tag
data entities.
In addition, to satisfy risk and compliance audits and data retention policies, it supports the ability to answer
questions such as: where did the data come from, where is it used, and what are the consequences of purging
or modifying a set of data entities. Cloudera Navigator supports tracking the lineage of HDFS files, datasets,
and directories, Hive tables and columns, MapReduce and YARN jobs, Hive queries, Impala queries, Pig scripts,
Oozie workflows, Spark jobs, and Sqoop jobs.

Related Information
• Installing Cloudera Navigator
• Upgrading Cloudera Navigator
• Cloudera Navigator Administration
• Cloudera Data Management
• Configuring Authentication in Cloudera Navigator
• Configuring SSL for Cloudera Navigator
• Cloudera Navigator User Roles

Cloudera Navigator UI
Cloudera Navigator UI is the web-based UI that you use to:
• Create and view audit reports
• Search entity metadata, view entity lineage, and modify business metadata
• Define policies for modifying business metadata when entities are extracted

Cloudera Introduction | 37
Cloudera Navigator 2 Overview

Starting and Logging into the Cloudera Navigator UI

1. Do one of the following:
• Enter the URL of the Navigator UI in a browser: http://Navigator_Metadata_Server_host:port/,
where Navigator_Metadata_Server_host is the name of the host on which you are running the Navigator
Metadata Server role and port is the port configured for the role. The default port of the Navigator Metadata
Server is 7187. To change the port, follow the instructions in Configuring the Navigator Metadata Server
Port.
• Navigate to the Cloudera Navigator UI. Do one of the following:
– Select Clusters > Cloudera Management Service > Cloudera Navigator.
– Navigate from the Navigator Metadata Server role:
1. Do one of the following:
• Select Clusters > Cloudera Management Service > Cloudera Management Service.
• On the Status tab of the Home page, in Cloudera Management Service table, click the Cloudera
Management Service link.
2. Click the Instances tab.
3. Click the Navigator Metadata Server role.
4. Click the Navigator Web UI link.

2. Log into Cloudera Navigator UI using the credentials assigned by your administrator. User groups are assigned
roles that constrain the features available to a logged in user.

Cloudera Navigator API

The Cloudera Navigator API provides access to the same features as the Cloudera Navigator UI.
The API available at http://Navigator_Metadata_Server_host:port/api/v5, where
Navigator_Metadata_Server_host is the name of the host on which you are running the Navigator Metadata
Server role and port is the port configured for the role. The default port of the Navigator Metadata Server is 7187.
To change the port, follow the instructions in Configuring the Navigator Metadata Server Port. The API supports
HTTP Basic Authentication, accepting the same users and credentials as the Cloudera Navigator UI.
For API documentation go to Navigator_Metadata_Server_host:port/api-console/index.html.

38 | Cloudera Introduction
 FAQs

FAQs

Cloudera Express and Cloudera Enterprise Features

Features available with Cloudera Express and Cloudera Enterprise are summarized in the following table.

Feature Cloudera Express Cloudera Enterprise

Cluster Management
Number of hosts supported Unlimited Unlimited
Host inspector for determining CDH
readiness
Multi-cluster management
Centralized view of all running
commands
Resource management
Global time control for historical
diagnosis
Cluster-wide configuration
Cluster-wide event management
Cluster-wide log search
Deployment
Support for CDH 4 and CDH 5
Automated deployment and
readiness checks
Installation from local repositories
Rolling upgrade of CDH
Service and Configuration Management
Manage HDFS, MapReduce, YARN,
Hue, Isilon, Oozie, and ZooKeeper
services
Manage Impala, HBase, KMS, Solr,
Spark, Accumulo, and Navigator
services
Manage add-on services
Rolling restart of services
High availability (HA) support
• CDH 4 - HDFS and MapReduce
JobTracker (CDH 4.2)
• CDH 5 - HDFS, Hive Metastore,
Impala Llama ApplicationMaster,

Cloudera Introduction | 39
FAQs

Feature Cloudera Express Cloudera Enterprise

MapReduce JobTracker, YARN
ResourceManager, Oozie

HBase co-processor support

Configuration audit trails
Client configuration management
Workflows (add, start, stop, restart,
delete, and decommission services,
hosts, and role instances)
Role groups
Host templates
Configuration versioning and history
Security
Kerberos authentication
LDAP authentication
SAML authentication
Encrypted communication between
Server and host Agents (TLS)
User roles
Monitoring and Diagnostics
Service, host, and activity monitoring
Proactive health tests
Health history
Advanced filtering and charting of
metrics
Job monitoring for MapReduce jobs,
YARN applications, and Impala
queries
Similar activity performance for
MapReduce jobs
Support for terminating activities
Alert Management
Alert via email
Alert via SNMP
User-defined triggers
Advanced Management Features
Automated backup and disaster
recovery
File browsing, searching, and disk
quota management

40 | Cloudera Introduction
 FAQs

Feature Cloudera Express Cloudera Enterprise

HBase, MapReduce, Impala, and
YARN usage reports
Support integration
Operational reports
Data Management
Role-based access control
Metadata management
Ingest policies
Auditing
Lineage

Cloudera Manager 5 Frequently Asked Questions

This guide answers frequently asked questions about Cloudera Manager.

General Questions

What are the new features of Cloudera Manager 5?

For a list of new features in Cloudera Manager 5, see New Features and Changes in Cloudera Manager 5.

What operating systems are supported?

See Supported Operating Systems for more detailed information on which operating systems are supported.

What databases are supported?

See Supported Databases for more detailed information on which database systems are supported.

What version of CDH is supported for Cloudera Manager 5?

See Supported CDH and Managed Service Versions for detailed information.

What are the differences between the Cloudera Express and the Cloudera Enterprise versions of Cloudera
Manager?
Cloudera Express includes a free version of Cloudera Manager. The Cloudera Enterprise version of Cloudera
Manager provides additional functionality. Both the Cloudera Express and Cloudera Enterprise versions automate
the installation, configuration, and monitoring of CDH 4 or CDH 5 on an entire cluster. See the matrix at Cloudera
Express and Cloudera Enterprise Features on page 39 for a comparison of the two versions.
The Cloudera Enterprise version of Cloudera Manager is available as part of the Cloudera Enterprise subscription
offering, and requires a license. You can also choose a Cloudera Enterprise Data Hub Edition Trial that is valid
for 60 days.
If you are not an existing Cloudera customer, contact Cloudera Sales using this form or call 866-843-7207 to
obtain a Cloudera Enterprise license. If you are already a Cloudera customer and you need to upgrade from
Cloudera Express to Cloudera Enterprise, contact Cloudera Support to obtain a license.

Cloudera Introduction | 41
FAQs

Are there different types of Cloudera Enterprise licenses?

There are three editions of Cloudera Enterprise which enable you to manage clusters of the following services:
• Basic Edition - a cluster running core CDH services: HDFS, Hive, Hue, MapReduce, Oozie, Sqoop, YARN, and
ZooKeeper.
• Flex Edition - a cluster running core CDH services plus one of the following: Accumulo, HBase, Impala, Navigator,
Solr, Spark.
• Data Hub Edition - a cluster running core CDH services plus any of the following: Accumulo, HBase, Impala,
Navigator, Solr, Spark.

Can I upgrade CDH using Cloudera Manager?

You can upgrade to CDH 4.1.2 or later from within the Cloudera Manager Admin Console using parcels.
Furthermore, once you have installed or upgraded CDH using parcels, you can perform rolling upgrades on your
CDH services. If you have HDFS High Availability configured and enabled, you can perform a rolling upgrade on
your cluster without taking the entire cluster down.

Warning: Cloudera Manager 3 and CDH 3 have reached End of Maintenance (EOM) as of June 20,
2013. Cloudera does not support or provide patches for Cloudera Manager 3 and CDH 3 releases.

For instructions on upgrading from CDH 3 to CDH 4, see Upgrading CDH 3 to CDH 4 in a Cloudera Manager
Deployment.
For instructions on upgrading CDH 4 to CDH 5, see Upgrading CDH 4 to CDH 5. For instructions on upgrading
CDH 4 to a newer version, see Upgrading CDH 4.

What version of CDH does Cloudera Manager 5 install?

Cloudera Manager 5 allows you to install any version of CDH 4 or CDH 5.

Where are CDH libraries located when I distribute CDH using parcels?
With parcel software distribution, the path to the CDH libraries is /opt/cloudera/parcels/CDH/lib/ instead
of the usual /usr/lib/.

What upgrade paths are available for Cloudera Manager, and what's involved?
For instructions about upgrading, see Upgrading Cloudera Manager.

How do I install Cloudera Manager 5 in a walled-off environment (no Internet access)?

You can set up a local repository and use it in the installer. For instructions, see Understanding Custom Installation
Solutions.

Do worker hosts need access to the Cloudera public repositories for an install with Cloudera Manager?
You can perform an installation or upgrade using the parcel format and when using parcels, only the Cloudera
Manager Server requires access to the Cloudera public repositories. Distribution of the parcels to worker hosts
is done between the Cloudera Manager Server and the worker hosts. See Parcels for more information. If you
want to install using the traditional packages, hosts only require access to the installation files.
For both parcels and packages, it is also possible to create local repositories that serve these files to the hosts
that are being upgraded. If you have established local repositories, no access to the Cloudera public repository
is required. For more information, see Creating and Using a Remote Package Repository.

42 | Cloudera Introduction
 FAQs

Can I use the service monitoring features of Cloudera Manager without the Cloudera Management Service?
No. To understand the desired state of the system, Cloudera Manager requires the global configuration that the
Cloudera Management Service roles gather and provide. The Cloudera Manager Agent doubles as both the agent
for supervision and for monitoring.

Can I run the Cloudera Management Service and the Hadoop services on the host where the Cloudera Manager
Server is running?
Yes. This is especially common in deployments that have a small number of hosts.

Does Cloudera Manager Support an API?

Yes. A comprehensive set of APIs for the various features is supported in this version of Cloudera Manager. For
more information about the Cloudera Manager API, see Cloudera Manager API on page 31. You can download
this Cloudera Manager API example that shows how to integrate with Nagios or other systems.

Cloudera Navigator 2 Frequently Asked Questions

Is Cloudera Navigator a module of Cloudera Manager?
Cloudera Navigator sits side-by-side with and complements Cloudera Manager. What Cloudera Manager is to
managing services, Cloudera Navigator is to managing all the data stored in those services. Cloudera Navigator
provides two categories of functionality:
• Auditing data access and verifying access privileges - The goal of auditing is to capture a complete and
immutable record of all activity within a system. While Hadoop has historically lacked centralized
cross-component audit capabilities, products such as Cloudera Navigator add secured, real-time audit
components to key data and access frameworks. Cloudera Navigator allows administrators to configure,
collect, and view audit events, to understand who accessed what data and how. Cloudera Navigator also
allows administrators to generate reports that list the HDFS access permissions granted to groups.
• Searching metadata and visualizing lineage - Cloudera Navigator metadata management features allow
DBAs, data modelers, business analysts, and data scientists to search for, amend the properties of, and tag
data entities.
Cloudera Navigator is implemented as two roles in the Cloudera Management Service: Navigator Audit Server
and Navigator Metadata Server. You can add Cloudera Navigator roles while installing Cloudera Manager for the
first time or into an existing Cloudera Manager installation. For information on compatible Cloudera Navigator
and Cloudera Manager versions, see the Cloudera Navigator product compatibility matrix.

Is Cloudera Navigator included with a Cloudera Enterprise Data Hub Edition license?
Yes. Cloudera Navigator is included with Cloudera Enterprise Data Hub Edition license and can be selected as a
choice with a Cloudera Enterprise Flex Edition license.

Can Cloudera Navigator be purchased standalone, that is, without Cloudera Manager?
Cloudera Navigator components are managed by Cloudera Manager. Therefore, Cloudera Manager is a prerequisite
for Cloudera Navigator.

What Cloudera Manager, CDH, and Cloudera Impala releases does Cloudera Navigator 2 work with?
See Cloudera Navigator 2 Requirements and Supported Versions.

Is Cloudera Navigator open source or closed source?

Cloudera Navigator is a closed-source management tool that adds to the Cloudera suite of management
capabilities for Hadoop.

Cloudera Introduction | 43
FAQs

How are Cloudera Navigator logs different from Cloudera Manager logs?
Cloudera Navigator tracks and aggregates only the accesses to the data stored in CDH services and used for
audit reports and analysis. Cloudera Manager monitors and logs all the activity performed by CDH services that
helps administrators maintain the health of the cluster. The target audiences of these logs are different but
together they provide better visibility into both the data access and system activity for an enterprise cluster.

Cloudera Impala Frequently Asked Questions

Here are the categories of frequently asked questions for the Cloudera Impala product.

Trying Impala

How do I try Cloudera Impala out?

To look at the core features and functionality on Impala, the easiest way to try out Impala is to download the
Cloudera QuickStart VM and start the Impala service through Cloudera Manager, then use impala-shell in a
terminal window or the Impala Query UI in the Hue web interface.
To do performance testing and try out the management features for Impala on a cluster, you need to move
beyond the QuickStart VM with its virtualized single-node environment. Ideally, download the Cloudera Manager
software to set up the cluster, then install the Impala software through Cloudera Manager.

Does Cloudera offer a VM for demonstrating Impala?

Cloudera offers a demonstration VM called the QuickStart VM, available in VMWare, VirtualBox, and KVM formats.
For more information, see the Cloudera QuickStart VM. After booting the QuickStart VM, many services are
turned off by default; in the Cloudera Manager UI that appears automatically, turn on Impala and any other
components that you want to try out.

Where can I find Impala documentation?

Starting with Impala 1.3.0, Impala documentation is integrated with the CDH 5 documentation, in addition to
the standalone Impala documentation for use with CDH 4. For CDH 5, the core Impala developer and administrator
information remains in the associated Impala documentation portion. Information about Impala release notes,
installation, configuration, startup, and security is embedded in the corresponding CDH 5 guides.
• New features
• Known and fixed issues
• Incompatible changes
• Installing Impala
• Upgrading Impala
• Configuring Impala
• Starting Impala
• Security for Impala
• CDH Version and Packaging Information
Information about the latest CDH 4-compatible Impala release remains at the Impala for CDH 4 Documentation
page.

Where can I get more information about Impala?

More product information is available here:
• O'Reilly introductory e-book: Cloudera Impala: Bringing the SQL and Hadoop Worlds Together
• O'Reilly getting started guide for developers: Getting Started with Impala: Interactive SQL for Apache Hadoop
• Blog: Cloudera Impala: Real-Time Queries in Apache Hadoop, For Real

44 | Cloudera Introduction
 FAQs

• Webinar: Introduction to Impala

• Product website page: Cloudera Enterprise RTQ
To see the latest release announcements for Impala, see the Cloudera Announcements forum.

How can I ask questions and provide feedback about Impala?

• Join the Impala discussion forum and the Impala mailing list to ask questions and provide feedback.
• Use the Impala Jira project to log bug reports and requests for features.

Where can I get sample data to try?

You can get scripts that produce data files and set up an environment for TPC-DS style benchmark tests from
this Github repository. In addition to being useful for experimenting with performance, the tables are suited to
experimenting with many aspects of SQL on Impala: they contain a good mixture of data types, data distributions,
partitioning, and relational data suitable for join queries.

Impala System Requirements

What are the software and hardware requirements for running Impala?
For information on Impala requirements, see Cloudera Impala Requirements. Note that there is often a minimum
required level of Cloudera Manager for any given Impala version.

How much memory is required?

Although Impala is not an in-memory database, when dealing with large tables and large result sets, you should
expect to dedicate a substantial portion of physical memory for the impalad daemon. Recommended physical
memory for an Impala node is 128 GB or higher. If practical, devote approximately 80% of physical memory to
Impala.
The amount of memory required for an Impala operation depends on several factors:
• The file format of the table. Different file formats represent the same data in more or fewer data files. The
compression and encoding for each file format might require a different amount of temporary memory to
decompress the data for analysis.
• Whether the operation is a SELECT or an INSERT. For example, Parquet tables require relatively little memory
to query, because Impala reads and decompresses data in 8 MB chunks. Inserting into a Parquet table is a
more memory-intensive operation because the data for each data file (potentially hundreds of megabytes,
depending on the value of the PARQUET_FILE_SIZE query option) is stored in memory until encoded,
compressed, and written to disk.
• Whether the table is partitioned or not, and whether a query against a partitioned table can take advantage
of partition pruning.
• Whether the final result set is sorted by the ORDER BY clause. Each Impala node scans and filters a portion
of the total data, and applies the LIMIT to its own portion of the result set. In Impala 1.4.0 and higher, if the
sort operation requires more memory than is available on any particular host, Impala uses a temporary disk
work area to perform the sort. The intermediate result sets are all sent back to the coordinator node, which
does the final sorting and then applies the LIMIT clause to the final result set.
For example, if you execute the query:

select * from giant_table order by some_column limit 1000;

and your cluster has 50 nodes, then each of those 50 nodes will transmit a maximum of 1000 rows back to
the coordinator node. The coordinator node needs enough memory to sort (LIMIT * cluster_size) rows,
although in the end the final result set is at most LIMIT rows, 1000 in this case.

Cloudera Introduction | 45
FAQs

Likewise, if you execute the query:

select * from giant_table where test_val > 100 order by some_column;

then each node filters out a set of rows matching the WHERE conditions, sorts the results (with no size limit),
and sends the sorted intermediate rows back to the coordinator node. The coordinator node might need
substantial memory to sort the final result set, and so might use a temporary disk work area for that final
phase of the query.
• Whether the query contains any join clauses, GROUP BY clauses, analytic functions, or DISTINCT operators.
These operations all require some in-memory work areas that vary depending on the volume and distribution
of data. In Impala 2.0 and later, these kinds of operations utilize temporary disk work areas if memory usage
grows too large to handle. See SQL Operations that Spill to Disk for details.
• The size of the result set. When intermediate results are being passed around between nodes, the amount
of data depends on the number of columns returned by the query. For example, it is more memory-efficient
to query only the columns that are actually needed in the result set rather than always issuing SELECT *.
• The mechanism by which work is divided for a join query. You use the COMPUTE STATS statement, and query
hints in the most difficult cases, to help Impala pick the most efficient execution plan. See Performance
Considerations for Join Queries for details.

See Hardware Requirements for more details and recommendations about Impala hardware prerequisites.

What processor type and speed does Cloudera recommend?

Impala makes use of SSE 4.1 instructions.

What EC2 instances are recommended for Impala?

For large storage capacity and large I/O bandwidth, consider the hs1.8xlarge and cc2.8xlarge instance types.
Impala I/O patterns typically do not benefit enough from SSD storage to make up for the lower overall size. For
performance and security considerations for deploying CDH and its components on AWS, see Cloudera Enterprise
Reference Architecture for AWS Deployments.

Supported and Unsupported Functionality In Impala

What are the main features of Impala?

• A large set of SQL statements, including SELECT and INSERT, with joins, Subqueries, and Impala Analytic
Functions. Highly compatible with HiveQL, and also including some vendor extensions. For more information,
see Impala SQL Language Reference.
• Distributed, high-performance queries. See Tuning Impala for Performance for information about Impala
performance optimizations and tuning techniques for queries.
• Using Cloudera Manager, you can deploy and manage your Impala services. Cloudera Manager is the best
way to get started with Impala on your cluster.
• Using Hue for queries.
• Appending and inserting data into tables through the INSERT statement. See How Impala Works with Hadoop
File Formats for the details about which operations are supported for which file formats.
• ODBC: Impala is certified to run against MicroStrategy and Tableau, with restrictions. For more information,
see Configuring Impala to Work with ODBC.
• Querying data stored in HDFS and HBase in a single query. See Using Impala to Query HBase Tables for
details.
• In Impala 2.2.0 and higher, querying data stored in the Amazon Simple Storage Service (S3). See Using Impala
to Query the Amazon S3 Filesystem (Unsupported Preview) for details.
• Concurrent client requests. Each Impala daemon can handle multiple concurrent client requests. The effects
on performance depend on your particular hardware and workload.

46 | Cloudera Introduction
 FAQs

• Kerberos authentication. For more information, see Overview of Impala Security.

• Partitions. With Impala SQL, you can create partitioned tables with the CREATE TABLE statement, and add
and drop partitions with the ALTER TABLE statement. Impala also takes advantage of the partitioning present
in Hive tables. See Partitioning for Impala Tables for details.

What features from relational databases or Hive are not available in Impala?
• Querying streaming data.
• Deleting individual rows. You delete data in bulk by overwriting an entire table or partition, or by dropping a
table.
• Indexing (not currently). LZO-compressed text files can be indexed outside of Impala, as described in Using
LZO-Compressed Text Files.
• Full text search on text fields. The Cloudera Search product is appropriate for this use case.
• Custom Hive Serializer/Deserializer classes (SerDes). Impala supports a set of common native file formats
that have built-in SerDes in CDH. See How Impala Works with Hadoop File Formats for details.
• Checkpointing within a query. That is, Impala does not save intermediate results to disk during long-running
queries. Currently, Impala cancels a running query if any host on which that query is executing fails. When
one or more hosts are down, Impala reroutes future queries to only use the available hosts, and Impala
detects when the hosts come back up and begins using them again. Because a query can be submitted
through any Impala node, there is no single point of failure. In the future, we will consider adding additional
work allocation features to Impala, so that a running query would complete even in the presence of host
failures.
• Encryption of data transmitted between Impala daemons.
• Hive indexes.
• Non-Hadoop data stores, such as relational databases.
For the detailed list of features that are different between Impala and HiveQL, see SQL Differences Between
Impala and Hive.

Does Impala support generic JDBC?

Impala supports the HiveServer2 JDBC driver.

Is Avro supported?
Yes, Avro is supported. Impala has always been able to query Avro tables. You can use the Impala LOAD DATA
statement to load existing Avro data files into a table. Starting with Impala 1.4, you can create Avro tables with
Impala. Currently, you still use the INSERT statement in Hive to copy data from another table into an Avro table.
See Using the Avro File Format with Impala Tables for details.

How do I?

How do I prevent users from seeing the text of SQL queries?

For instructions on making the Impala log files unreadable by unprivileged users, see Securing Impala Data and
Log Files.
For instructions on password-protecting the web interface to the Impala log files and other internal server
information, see Securing the Impala Web User Interface.
In Impala 2.2 / CDH 5.4 and higher, you can use the log redaction feature to obfuscate sensitive information in
Impala log files. See Sensitive Data Redaction for details.

Cloudera Introduction | 47
FAQs

How do I know how many Impala nodes are in my cluster?

The Impala statestore keeps track of how many impalad nodes are currently available. You can see this
information through the statestore web interface. For example, at the URL
http://statestore_host:25010/metrics you might see lines like the following:

statestore.live-backends:3
statestore.live-backends.list:[host1:22000, host1:26000, host2:22000]

The number of impalad nodes is the number of list items referring to port 22000, in this case two. (Typically,
this number is one less than the number reported by the statestore.live-backends line.) If an impalad
node became unavailable or came back after an outage, the information reported on this page would change
appropriately.

Impala Performance

Are results returned as they become available, or all at once when a query completes?
Impala streams results whenever they are available, when possible. Certain SQL operations (aggregation or
ORDER BY) require all of the input to be ready before Impala can return results.

Why does my query run slowly?

There are many possible reasons why a given query could be slow. Use the following checklist to diagnose
performance issues with existing queries, and to avoid such issues when writing new queries, setting up new
nodes, creating new tables, or loading data.
• Immediately after the query finishes, issue a SUMMARY command in impala-shell. You can check which
phases of execution took the longest, and compare estimated values for memory usage and number of rows
with the actual values.
• Immediately after the query finishes, issue a PROFILE command in impala-shell. The numbers in the
BytesRead, BytesReadLocal, and BytesReadShortCircuit should be identical for a specific node. For
example:

- BytesRead: 180.33 MB
- BytesReadLocal: 180.33 MB
- BytesReadShortCircuit: 180.33 MB

If BytesReadLocal is lower than BytesRead, something in your cluster is misconfigured, such as the impalad
daemon not running on all the data nodes. If BytesReadShortCircuit is lower than BytesRead, short-circuit
reads are not enabled properly on that node; see Post-Installation Configuration for Impala for instructions.
• If the table was just created, or this is the first query that accessed the table after an INVALIDATE METADATA
statement or after the impalad daemon was restarted, there might be a one-time delay while the metadata
for the table is loaded and cached. Check whether the slowdown disappears when the query is run again.
When doing performance comparisons, consider issuing a DESCRIBE table_name statement for each table
first, to make sure any timings only measure the actual query time and not the one-time wait to load the
table metadata.
• Is the table data in uncompressed text format? Check by issuing a DESCRIBE FORMATTED table_name
statement. A text table is indicated by the line:

InputFormat: org.apache.hadoop.mapred.TextInputFormat

Although uncompressed text is the default format for a CREATE TABLE statement with no STORED AS clauses,
it is also the bulkiest format for disk storage and consequently usually the slowest format for queries. For
data where query performance is crucial, particularly for tables that are frequently queried, consider starting
with or converting to a compact binary file format such as Parquet, Avro, RCFile, or SequenceFile. For details,
see How Impala Works with Hadoop File Formats.

48 | Cloudera Introduction
 FAQs

• If your table has many columns, but the query refers to only a few columns, consider using the Parquet file
format. Its data files are organized with a column-oriented layout that lets queries minimize the amount of
I/O needed to retrieve, filter, and aggregate the values for specific columns. See Using the Parquet File Format
with Impala Tables for details.
• If your query involves any joins, are the tables in the query ordered so that the tables or subqueries are
ordered with the one returning the largest number of rows on the left, followed by the smallest (most
selective), the second smallest, and so on? That ordering allows Impala to optimize the way work is distributed
among the nodes and how intermediate results are routed from one node to another. For example, all other
things being equal, the following join order results in an efficient query:

select some_col from

huge_table join big_table join small_table join medium_table
where
huge_table.id = big_table.id
and big_table.id = medium_table.id
and medium_table.id = small_table.id;

See Performance Considerations for Join Queries for performance tips for join queries.
• Also for join queries, do you have table statistics for the table, and column statistics for the columns used
in the join clauses? Column statistics let Impala better choose how to distribute the work for the various
pieces of a join query. See How Impala Uses Statistics for Query Optimization for details about gathering
statistics.
• Does your table consist of many small data files? Impala works most efficiently with data files in the
multi-megabyte range; Parquet, a format optimized for data warehouse-style queries, uses large files
(originally 1 GB, now 256 MB in Impala 2.0 and higher) with a block size matching the file size. Use the
DESCRIBE FORMATTED table_name statement in impala-shell to see where the data for a table is located,
and use the hadoop fs -ls or hdfs dfs -ls Unix commands to see the files and their sizes. If you have
thousands of small data files, that is a signal that you should consolidate into a smaller number of large
files. Use an INSERT ... SELECT statement to copy the data to a new table, reorganizing into new data
files as part of the process. Prefer to construct large data files and import them in bulk through the LOAD
DATA or CREATE EXTERNAL TABLE statements, rather than issuing many INSERT ... VALUES statements;
each INSERT ... VALUES statement creates a separate tiny data file. If you have thousands of files all in
the same directory, but each one is megabytes in size, consider using a partitioned table so that each partition
contains a smaller number of files. See the following point for more on partitioning.
• If your data is easy to group according to time or geographic region, have you partitioned your table based
on the corresponding columns such as YEAR, MONTH, and/or DAY? Partitioning a table based on certain columns
allows queries that filter based on those same columns to avoid reading the data files for irrelevant years,
postal codes, and so on. (Do not partition down to too fine a level; try to structure the partitions so that there
is still sufficient data in each one to take advantage of the multi-megabyte HDFS block size.) See Partitioning
for Impala Tables for details.

Why does my SELECT statement fail?

When a SELECT statement fails, the cause usually falls into one of the following categories:
• A timeout because of a performance, capacity, or network issue affecting one particular node.
• Excessive memory use for a join query, resulting in automatic cancellation of the query.
• A low-level issue affecting how native code is generated on each node to handle particular WHERE clauses in
the query. For example, a machine instruction could be generated that is not supported by the processor of
a certain node. If the error message in the log suggests the cause was an illegal instruction, consider turning
off native code generation temporarily, and trying the query again.
• Malformed input data, such as a text data file with an enormously long line, or with a delimiter that does not
match the character specified in the FIELDS TERMINATED BY clause of the CREATE TABLE statement.

Cloudera Introduction | 49
FAQs

Why does my INSERT statement fail?

When an INSERT statement fails, it is usually the result of exceeding some limit within a Hadoop component,
typically HDFS.
• An INSERT into a partitioned table can be a strenuous operation due to the possibility of opening many files
and associated threads simultaneously in HDFS. Impala 1.1.1 includes some improvements to distribute the
work more efficiently, so that the values for each partition are written by a single node, rather than as a
separate data file from each node.
• Certain expressions in the SELECT part of the INSERT statement can complicate the execution planning and
result in an inefficient INSERT operation. Try to make the column data types of the source and destination
tables match up, for example by doing ALTER TABLE ... REPLACE COLUMNS on the source table if necessary.
Try to avoid CASE expressions in the SELECT portion, because they make the result values harder to predict
than transferring a column unchanged or passing the column through a built-in function.
• Be prepared to raise some limits in the HDFS configuration settings, either temporarily during the INSERT
or permanently if you frequently run such INSERT statements as part of your ETL pipeline.
• The resource usage of an INSERT statement can vary depending on the file format of the destination table.
Inserting into a Parquet table is memory-intensive, because the data for each partition is buffered in memory
until it reaches 1 gigabyte, at which point the data file is written to disk. Impala can distribute the work for
an INSERT more efficiently when statistics are available for the source table that is queried during the INSERT
statement. See How Impala Uses Statistics for Query Optimization for details about gathering statistics.

Does Impala performance improve as it is deployed to more hosts in a cluster in much the same way that Hadoop
performance does?
Yes. Impala scales with the number of hosts. It is important to install Impala on all the data nodes in the cluster,
because otherwise some of the nodes must do remote reads to retrieve data not available for local reads. Data
locality is an important architectural aspect for Impala performance. See this Impala performance blog post for
background. Note that this blog post refers to benchmarks with Impala 1.1.1; Impala has added even more
performance features in the 1.2.x series.

Is the HDFS block size reduced to achieve faster query results?

No. Impala does not make any changes to the HDFS or HBase data sets.
The default Parquet block size is relatively large (256 MB in Impala 2.0 and later; 1 GB in earlier releases). You
can control the block size when creating Parquet files using the PARQUET_FILE_SIZE query option.

Does Impala use caching?

Impala does not cache table data. It does cache some table and file metadata. Although queries might run faster
on subsequent iterations because the data set was cached in the OS buffer cache, Impala does not explicitly
control this.
Impala takes advantage of the HDFS caching feature in CDH 5. You can designate which tables or partitions are
cached through the CACHED and UNCACHED clauses of the CREATE TABLE and ALTER TABLE statements. Impala
can also take advantage of data that is pinned in the HDFS cache through the hdfscacheadmin command. See
Using HDFS Caching with Impala (CDH 5.1 or higher only) for details.

Impala Use Cases

What are good use cases for Impala as opposed to Hive or MapReduce?
Impala is well-suited to executing SQL queries for interactive exploratory analytics on large data sets. Hive and
MapReduce are appropriate for very long running, batch-oriented tasks such as ETL.

50 | Cloudera Introduction
 FAQs

Is MapReduce required for Impala? Will Impala continue to work as expected if MapReduce is stopped?
Impala does not use MapReduce at all.

Can Impala be used for complex event processing?

For example, in an industrial environment, many agents may generate large amounts of data. Can Impala be
used to analyze this data, checking for notable changes in the environment?
Complex Event Processing (CEP) is usually performed by dedicated stream-processing systems. Impala is not
a stream-processing system, as it most closely resembles a relational database.

Is Impala intended to handle real time queries in low-latency applications or is it for ad hoc queries for the
purpose of data exploration?
Ad-hoc queries are the primary use case for Impala. We anticipate it being used in many other situations where
low-latency is required. Whether Impala is appropriate for any particular use-case depends on the workload,
data size and query volume. See Impala Benefits on page 8 for the primary benefits you can expect when using
Impala.

Questions about Impala And Hive

How does Impala compare to Hive and Pig?

Impala is different from Hive and Pig because it uses its own daemons that are spread across the cluster for
queries. Because Impala does not rely on MapReduce, it avoids the startup overhead of MapReduce jobs, allowing
Impala to return results in real time.

Can I do transforms or add new functionality?

Impala adds support for UDFs in Impala 1.2. You can write your own functions in C++, or reuse existing Java-based
Hive UDFs. The UDF support includes scalar functions and user-defined aggregate functions (UDAs). User-defined
table functions (UDTFs) are not currently supported.
Impala does not currently support an extensible serialization-deserialization framework (SerDes), and so adding
extra functionality to Impala is not as straightforward as for Hive or Pig.

Can any Impala query also be executed in Hive?

Yes. There are some minor differences in how some queries are handled, but Impala queries can also be completed
in Hive. Impala SQL is a subset of HiveQL, with some functional limitations such as transforms. For details of
the Impala SQL dialect, see SQL Statements. For the Impala built-in functions, see Built-in Functions. For the
detailed list of differences between Impala and HiveQL, see SQL Differences Between Impala and Hive.

Can I use Impala to query data already loaded into Hive and HBase?
There are no additional steps to allow Impala to query tables managed by Hive, whether they are stored in HDFS
or HBase. Make sure that Impala is configured to access the Hive metastore correctly and you should be ready
to go. Keep in mind that impalad, by default, runs as the impala user, so you might need to adjust some file
permissions depending on how strict your permissions are currently.
See Using Impala to Query HBase Tables for details about querying data in HBase.

Is Hive an Impala requirement?

The Hive metastore service is a requirement. Impala shares the same metastore database as Hive, allowing
Impala and Hive to access the same tables transparently.

Cloudera Introduction | 51
FAQs

Hive itself is optional, and does not need to be installed on the same nodes as Impala. Currently, Impala supports
a wider variety of read (query) operations than write (insert) operations; you use Hive to insert data into tables
that use certain file formats. See How Impala Works with Hadoop File Formats for details.

Impala Availability

Is Impala production ready?

Impala has finished its beta release cycle, and the 1.0, 1.1, and 1.2 GA releases are production ready. The 1.1.x
series includes additional security features for authorization, an important requirement for production use in
many organizations. The 1.2.x series includes important performance features, particularly for large join queries.
Some Cloudera customers are already using Impala for large workloads.
The Impala 1.3.0 and higher releases are bundled with corresponding levels of CDH 5. The number of new features
grows with each release. See What's New in Impala for a full list.

How do I configure Hadoop high availability (HA) for Impala?

You can set up a proxy server to relay requests back and forth to the Impala servers, for load balancing and high
availability. See Using Impala through a Proxy for High Availability for details.
You can enable HDFS HA for the Hive metastore. See the CDH5 High Availability Guide or the CDH4 High Availability
Guide for details.

What happens if there is an error in Impala?

There is not a single point of failure in Impala. All Impala daemons are fully able to handle incoming queries. If
a machine fails however, all queries with fragments running on that machine will fail. Because queries are
expected to return quickly, you can just rerun the query if there is a failure. See Impala Concepts and Architecture
for details about the Impala architecture.
The longer answer: Impala must be able to connect to the Hive metastore. Impala aggressively caches metadata
so the metastore host should have minimal load. Impala relies on the HDFS NameNode, and, in CDH4, you can
configure HA for HDFS. Impala also has centralized services, known as the statestore and catalog services, that
run on one host only. Impala continues to execute queries if the statestore host is down, but it will not get state
updates. For example, if a host is added to the cluster while the statestore host is down, the existing instances
of impalad running on the other hosts will not find out about this new host. Once the statestore process is
restarted, all the information it serves is automatically reconstructed from all running Impala daemons.

What is the maximum number of rows in a table?

There is no defined maximum. Some customers have used Impala to query a table with over a trillion rows.

Can Impala and MapReduce jobs run on the same cluster without resource contention?
Yes. See Controlling Impala Resource Usage for how to control Impala resource usage using the Linux cgroup
mechanism, and Integrated Resource Management with YARN for how to use Impala with the YARN resource
management framework. Impala is designed to run on the DataNode hosts. Any contention depends mostly on
the cluster setup and workload.
For a detailed example of configuring a cluster to share resources between Impala queries and MapReduce jobs,
see Setting up a Multi-tenant Cluster for Impala and MapReduce

Impala Internals

On which hosts does Impala run?

Cloudera strongly recommends running the impalad daemon on each DataNode for good performance. Although
this topology is not a hard requirement, if there are data blocks with no Impala daemons running on any of the

52 | Cloudera Introduction
 FAQs

hosts containing replicas of those blocks, queries involving that data could be very inefficient. In that case, the
data must be transmitted from one host to another for processing by “remote reads”, a condition Impala normally
tries to avoid. See Impala Concepts and Architecture for details about the Impala architecture. Impala schedules
query fragments on all hosts holding data relevant to the query, if possible.

How are joins performed in Impala?

By default, Impala automatically determines the most efficient order in which to join tables using a cost-based
method, based on their overall size and number of rows. (This is a new feature in Impala 1.2.2 and higher.) The
COMPUTE STATS statement gathers information about each table that is crucial for efficient join performance.
Impala chooses between two techniques for join queries, known as “broadcast joins” and “partitioned joins”.
See Joins for syntax details and Performance Considerations for Join Queries for performance considerations.

How does Impala process join queries for large tables?

Impala utilizes multiple strategies to allow joins between tables and result sets of various sizes. When joining
a large table with a small one, the data from the small table is transmitted to each node for intermediate
processing. When joining two large tables, the data from one of the tables is divided into pieces, and each node
processes only selected pieces. See Joins for details about join processing, Performance Considerations for Join
Queries for performance considerations, and Hints for how to fine-tune the join strategy.

What is Impala's aggregation strategy?

Impala currently only supports in-memory hash aggregation. In Impala 2.0 and higher, if the memory requirements
for a join or aggregation operation exceed the memory limit for a particular host, Impala uses a temporary work
area on disk to help the query complete successfully.

How is Impala metadata managed?

Impala uses two pieces of metadata: the catalog information from the Hive metastore and the file metadata
from the NameNode. Currently, this metadata is lazily populated and cached when an impalad needs it to plan
a query.
The REFRESH statement updates the metadata for a particular table after loading new data through Hive. The
INVALIDATE METADATA Statement statement refreshes all metadata, so that Impala recognizes new tables or
other DDL and DML changes performed through Hive.
In Impala 1.2 and higher, a dedicated catalogd daemon broadcasts metadata changes due to Impala DDL or
DML statements to all nodes, reducing or eliminating the need to use the REFRESH and INVALIDATE METADATA
statements.

What load do concurrent queries produce on the NameNode?

The load Impala generates is very similar to MapReduce. Impala contacts the NameNode during the planning
phase to get the file metadata (this is only run on the host the query was sent to). Every impalad will read files
as part of normal processing of the query.

How does Impala achieve its performance improvements?

These are the main factors in the performance of Impala versus that of other Hadoop components and related
technologies.
Impala avoids MapReduce. While MapReduce is a great general parallel processing model with many benefits,
it is not designed to execute SQL. Impala avoids the inefficiencies of MapReduce in these ways:
• Impala does not materialize intermediate results to disk. SQL queries often map to multiple MapReduce jobs
with all intermediate data sets written to disk.
• Impala avoids MapReduce start-up time. For interactive queries, the MapReduce start-up time becomes
very noticeable. Impala runs as a service and essentially has no start-up time.

Cloudera Introduction | 53
FAQs

• Impala can more naturally disperse query plans instead of having to fit them into a pipeline of map and
reduce jobs. This enables Impala to parallelize multiple stages of a query and avoid overheads such as sort
and shuffle when unnecessary.
Impala uses a more efficient execution engine by taking advantage of modern hardware and technologies:
• Impala generates runtime code. Impala uses LLVM to generate assembly code for the query that is being
run. Individual queries do not have to pay the overhead of running on a system that needs to be able to
execute arbitrary queries.
• Impala uses available hardware instructions when possible. Impala uses the supplemental SSE3 (SSSE3)
instructions which can offer tremendous speedups in some cases. (Impala 2.0 and 2.1 required the SSE4.1
instruction set; Impala 2.2 and higher relax the restriction again so only SSSE3 is required.)
• Impala uses better I/O scheduling. Impala is aware of the disk location of blocks and is able to schedule the
order to process blocks to keep all disks busy.
• Impala is designed for performance. A lot of time has been spent in designing Impala with sound
performance-oriented fundamentals, such as tight inner loops, inlined function calls, minimal branching,
better use of cache, and minimal memory usage.

What happens when the data set exceeds available memory?

Currently, if the memory required to process intermediate results on a node exceeds the amount available to
Impala on that node, the query is cancelled. You can adjust the memory available to Impala on each node, and
you can fine-tune the join strategy to reduce the memory required for the biggest queries. We do plan on
supporting external joins and sorting in the future.
Keep in mind though that the memory usage is not directly based on the input data set size. For aggregations,
the memory usage is the number of rows after grouping. For joins, the memory usage is the combined size of
the tables excluding the biggest table, and Impala can use join strategies that divide up large joined tables among
the various nodes rather than transmitting the entire table to each node.

What are the most memory-intensive operations?

If a query fails with an error indicating “memory limit exceeded”, you might suspect a memory leak. The problem
could actually be a query that is structured in a way that causes Impala to allocate more memory than you
expect, exceeded the memory allocated for Impala on a particular node. Some examples of query or table
structures that are especially memory-intensive are:
• INSERT statements using dynamic partitioning, into a table with many different partitions. (Particularly for
tables using Parquet format, where the data for each partition is held in memory until it reaches the full
block size in size before it is written to disk.) Consider breaking up such operations into several different
INSERT statements, for example to load data one year at a time rather than for all years at once.
• GROUP BY on a unique or high-cardinality column. Impala allocates some handler structures for each different
value in a GROUP BY query. Having millions of different GROUP BY values could exceed the memory limit.
• Queries involving very wide tables, with thousands of columns, particularly with many STRING columns.
Because Impala allows a STRING value to be up to 32 KB, the intermediate results during such queries could
require substantial memory allocation.

When does Impala hold on to or return memory?

Impala allocates memory using tcmalloc, a memory allocator that is optimized for high concurrency. Once
Impala allocates memory, it keeps that memory reserved to use for future queries. Thus, it is normal for Impala
to show high memory usage when idle. If Impala detects that it is about to exceed its memory limit (defined by
the -mem_limit startup option or the MEM_LIMIT query option), it deallocates memory not needed by the current
queries.
When issuing queries through the JDBC or ODBC interfaces, make sure to call the appropriate close method
afterwards. Otherwise, some memory associated with the query is not freed.

54 | Cloudera Introduction
 FAQs

SQL

Is there an UPDATE statement?

Impala does not currently have an UPDATE statement, which would typically be used to change a single row, a
small group of rows, or a specific column. The HDFS-based files used by typical Impala queries are optimized
for bulk operations across many megabytes of data at a time, making traditional UPDATE operations inefficient
or impractical.
You can use the following techniques to achieve the same goals as the familiar UPDATE statement, in a way that
preserves efficient file layouts for subsequent queries:
• Replace the entire contents of a table or partition with updated data that you have already staged in a
different location, either using INSERT OVERWRITE, LOAD DATA, or manual HDFS file operations followed by
a REFRESH statement for the table. Optionally, you can use built-in functions and expressions in the INSERT
statement to transform the copied data in the same way you would normally do in an UPDATE statement,
for example to turn a mixed-case string into all uppercase or all lowercase.
• To update a single row, use an HBase table, and issue an INSERT ... VALUES statement using the same
key as the original row. Because HBase handles duplicate keys by only returning the latest row with a
particular key value, the newly inserted row effectively hides the previous one.

Can Impala do user-defined functions (UDFs)?

Impala 1.2 and higher does support UDFs and UDAs. You can either write native Impala UDFs and UDAs in C++,
or reuse UDFs (but not UDAs) originally written in Java for use with Hive. See Impala User-Defined Functions
(UDFs) for details.

Why do I have to use REFRESH and INVALIDATE METADATA, what do they do?
In Impala 1.2 and higher, there is much less need to use the REFRESH and INVALIDATE METADATA statements:
• The new impala-catalog service, represented by the catalogd daemon, broadcasts the results of Impala
DDL statements to all Impala nodes. Thus, if you do a CREATE TABLE statement in Impala while connected
to one node, you do not need to do INVALIDATE METADATA before issuing queries through a different node.
• The catalog service only recognizes changes made through Impala, so you must still issue a REFRESH statement
if you load data through Hive or by manipulating files in HDFS, and you must issue an INVALIDATE METADATA
statement if you create a table, alter a table, add or drop partitions, or do other DDL statements in Hive.
• Because the catalog service broadcasts the results of REFRESH and INVALIDATE METADATA statements to
all nodes, in the cases where you do still need to issue those statements, you can do that on a single node
rather than on every node, and the changes will be automatically recognized across the cluster, making it
more convenient to load balance by issuing queries through arbitrary Impala nodes rather than always using
the same coordinator node.

Why is space not freed up when I issue DROP TABLE?

Impala deletes data files when you issue a DROP TABLE on an internal table, but not an external one. By default,
the CREATE TABLE statement creates internal tables, where the files are managed by Impala. An external table
is created with a CREATE EXTERNAL TABLE statement, where the files reside in a location outside the control
of Impala. Issue a DESCRIBE FORMATTED statement to check whether a table is internal or external. The keyword
MANAGED_TABLE indicates an internal table, from which Impala can delete the data files. The keyword
EXTERNAL_TABLE indicates an external table, where Impala will leave the data files untouched when you drop
the table.
Even when you drop an internal table and the files are removed from their original location, you might not get
the hard drive space back immediately. By default, files that are deleted in HDFS go into a special trashcan
directory, from which they are purged after a period of time (by default, 6 hours). For background information
on the trashcan mechanism, see
http://archive.cloudera.com/cdh4/cdh/4/hadoop/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html. For

Cloudera Introduction | 55
FAQs

information on purging files from the trashcan, see

http://archive.cloudera.com/cdh4/cdh/4/hadoop/hadoop-project-dist/hadoop-common/FileSystemShell.html.
When Impala deletes files and they are moved to the HDFS trashcan, they go into an HDFS directory owned by
the impala user. If the impala user does not have an HDFS home directory where a trashcan can be created,
the files are not deleted or moved, as a safety measure. If you issue a DROP TABLE statement and find that the
table data files are left in their original location, create an HDFS directory /user/impala, owned and writeable
by the impala user. For example, you might find that /user/impala is owned by the hdfs user, in which case
you would switch to the hdfs user and issue a command such as:

hdfs dfs -chown -R impala /user/impala

Is there a DUAL table?

You might be used to running queries against a single-row table named DUAL to try out expressions, built-in
functions, and UDFs. Impala does not have a DUAL table. To achieve the same result, you can issue a SELECT
statement without any table name:

select 2+2;
select substr('hello',2,1);
select pow(10,6);

Partitioned Tables

How do I load a big CSV file into a partitioned table?

To load a data file into a partitioned table, when the data file includes fields like year, month, and so on that
correspond to the partition key columns, use a two-stage process. First, use the LOAD DATA or CREATE EXTERNAL
TABLE statement to bring the data into an unpartitioned text table. Then use an INSERT ... SELECT statement
to copy the data from the unpartitioned table to a partitioned one. Include a PARTITION clause in the INSERT
statement to specify the partition key columns. The INSERT operation splits up the data into separate data files
for each partition. For examples, see Partitioning for Impala Tables. For details about loading data into partitioned
Parquet tables, a popular choice for high-volume data, see Loading Data into Parquet Tables.

Can I do INSERT ... SELECT * into a partitioned table?

When you use the INSERT ... SELECT * syntax to copy data into a partitioned table, the columns corresponding
to the partition key columns must appear last in the columns returned by the SELECT *. You can create the
table with the partition key columns defined last. Or, you can use the CREATE VIEW statement to create a view
that reorders the columns: put the partition key columns last, then do the INSERT ... SELECT * from the
view.

HBase

What kinds of Impala queries or data are best suited for HBase?
HBase tables are ideal for queries where normally you would use a key-value store. That is, where you retrieve
a single row or a few rows, by testing a special unique key column using the = or IN operators.
HBase tables are not suitable for queries that produce large result sets with thousands of rows. HBase tables
are also not suitable for queries that perform full table scans because the WHERE clause does not request specific
values from the unique key column.
Use HBase tables for data that is inserted one row or a few rows at a time, such as by the INSERT ... VALUES
syntax. Loading data piecemeal like this into an HDFS-backed table produces many tiny files, which is a very
inefficient layout for HDFS data files.

56 | Cloudera Introduction
 FAQs

If the lack of an UPDATE statement in Impala is a problem for you, you can simulate single-row updates by doing
an INSERT ... VALUES statement using an existing value for the key column. The old row value is hidden; only
the new row value is seen by queries.
HBase tables are often wide (containing many columns) and sparse (with most column values NULL). For example,
you might record hundreds of different data points for each user of an online service, such as whether the user
had registered for an online game or enabled particular account features. With Impala and HBase, you could
look up all the information for a specific customer efficiently in a single query. For any given customer, most of
these columns might be NULL, because a typical customer might not make use of most features of an online
service.

Cloudera Search Frequently Asked Questions

This section includes answers to questions commonly asked about Search for CDH. Questions are divided into
the following categories:

General
The following are general questions about Cloudera Search and the answers to those questions.

What is Cloudera Search?

Cloudera Search is Apache Solr integrated with CDH, including Apache Lucene, Apache SolrCloud, Apache Flume,
Apache Tika, and Apache Hadoop MapReduce and HDFS. Cloudera Search also includes valuable integrations
that make searching more scalable, easy to use, and optimized for both near-real-time and batch-oriented
indexing. These integrations include Cloudera Morphlines, a customizable transformation chain that simplifies
loading any type of data into Cloudera Search.

What is the difference between Lucene and Solr?

Lucene is a low-level search library that is accessed by a Java API. Solr is a search server that runs in a servlet
container and provides structure and convenience around the underlying Lucene library.

What is Apache Tika?

The Apache Tika toolkit detects and extracts metadata and structured text content from various documents
using existing parser libraries. Using the solrCell morphline command, the output from Apache Tika can be
mapped to a Solr schema and indexed.

How does Cloudera Search relate to web search?

Traditional web search engines crawl web pages on the Internet for content to index. Cloudera Search indexes
files and data that are stored in HDFS and HBase. To make web data available through Cloudera Search, it needs
to be downloaded and stored in Cloudera's Distribution, including Apache Hadoop (CDH).

How does Cloudera Search relate to enterprise search?

Enterprise search connects with different backends (such as RDBMS and filesystems) and indexes data in all
those systems. Cloudera Search is intended as a full-text search capability for data in CDH. Cloudera Search is
a tool added to Cloudera's data processing platform and does not aim to be a stand-alone search solution, but
rather a user-friendly interface to explore data in Hadoop and HBase.

How does Cloudera Search relate to custom search applications?

Custom and specialized search applications are an excellent complement to Cloudera's data-processing platform.
Cloudera Search is not designed to be a custom application for niche vertical markets. However, Cloudera Search
does include a simple search GUI through a plug-in application for Hue. It is based on the Solr API and allows
for easy exploration, along with all of the other Hadoop frontend applications in Hue.

Cloudera Introduction | 57
FAQs

Do Search security features use Kerberos?

Yes, Cloudera Search includes support for Kerberos authentication. Search continues to use simple authentication
with the anonymous user as the default configuration, but Search now supports changing the authentication
scheme to Kerberos. All required packages are installed during the installation or upgrade process. Additional
configuration is required before Kerberos is available in your environment.

Do I need to configure Sentry restrictions for each access mode, such as for the admin console
and for the command line?
Sentry restrictions are consistently applied regardless of the way users attempt to complete actions. For example,
restricting access to data in a collection consistently restricts that access, whether queries come from the
command line, from a browser, or through the admin console.

Does Search support indexing data stored in JSON files and objects?
Yes, you can use the readJson and extractJsonPaths morphline commands that are included with the
CDK to access JSON data and files. For more information, see cdk-morphlines-json.

How can I set up Cloudera Search so that results include links back to the source that contains
the result?
You can use stored results fields to create links back to source documents. For information on data types,
including the option to set results fields as stored, see the Solr Wiki page on SchemaXml.
For example, with MapReduceIndexerTool you can take advantage of fields such as file_path. See
MapReduceIndexerTool Metadata for more information. The output from the MapReduceIndexerTool includes
file path information that can be used to construct links to source documents.
If you use the Hue UI, you can link to data in HDFS by inserting links of the form:

<a href="/filebrowser/download/{{file_path}}?disposition=inline">Download</a>

Why do I get an error “no field name specified in query and no default specified via 'df' param"
when I query a Schemaless collection?
Schemaless collections initially have no default or df setting. As a result, simple searches that might succeed
on non-Schemaless collections may fail on Schemaless collections.
When a user submits a search, it must be clear which field Cloudera Search should query. A default field, or df,
is often specified in solrconfig.xml, and when this is the case, users can submit queries that do not specify
fields. In such situations, Solr uses the df value.
When a new collection is created in Schemaless mode, there are initially no fields defined, so no field can be
chosen as the df field. As a result, when query request handlers do not specify a df, errors can result. There are
several ways to address this issue:
• Queries can specify any valid field name on which to search. In such a case, no df is required.
• Queries can specify a default field using the df parameter. In such a case, the df is specified in the query.
• You can uncomment the df section of the generated schemaless solrconfig.xml file and set the df
parameter to the desired field. In such a case, all subsequent queries can use the df field in solrconfig.xml
if no field or df value is specified.

Performance and Fail Over

The following are questions about performance and fail over in Cloudera Search and the answers to those
questions.

58 | Cloudera Introduction
 FAQs

How large of an index does Cloudera Search support per search server?
There are too many variables to provide a single answer to this question. Typically, a server can host from 10 to
300 million documents, with the underlying index as large as hundreds of gigabytes. To determine a reasonable
maximum document quantity and index size for servers in your deployment, prototype with realistic data and
queries.

What is the response time latency I can expect?

Many factors affect how quickly responses are returned. Some factors that contribute to latency include whether
the system is also completing indexing, the type of fields you are searching, whether the search results require
aggregation, and whether there are sufficient resources for your search services.
With appropriately-sized hardware, if the query results are found in memory, they may be returned within
milliseconds. Conversely, complex queries requiring results aggregation over huge indexes may take a few
seconds.
The time between when Search begins to work on indexing new data and when that data can be queried can be
as short as a few seconds, depending on your configuration.
This high performance is supported by custom caching optimizations that Cloudera has added to the Solr/HDFS
integration. These optimizations allow for rapid read and writes of files in HDFS, performing at or above the
speeds of stand-alone Solr reading and writing from local disk.

What happens when a write to the Lucene indexer fails?

Cloudera Search provides two configurable, highly available, and fault-tolerant data ingestion schemes: near
real-time ingestion using the Flume Solr Sink and MapReduce-based batch ingestion using the
MapReduceIndexerTool. These approaches are discussed in more detail in Search High Availability.

What hardware or configuration changes can I make to improve Search performance?

Search performance can be constrained by CPU limits. If you're seeing bottlenecks, consider allocating more CPU
to Search.

Are there settings that can help avoid out of memory (OOM) errors during data ingestion?
A data ingestion pipeline can be made up of many connected segments, each of which may need to be evaluated
for sufficient resources. A common limiting factor is the relatively small default amount of permgen memory
allocated to the flume JVM. Allocating additional memory to the Flume JVM may help avoid OOM errors. For
example, for JVM settings for Flume, the following settings are often sufficient:

-Xmx2048m -XX:MaxPermSize=256M

Schema Management
The following are questions about schema management in Cloudera Search and the answers to those questions.

If my schema changes, will I need to re-index all of my data and files?

When you change the schema, Cloudera recommends re-indexing. For example, if you add a new field to the
index, apply the new field to all index entries through re-indexing. Re-indexing is required in such a case because
existing documents do yet not have the field. Cloudera Search includes a MapReduce batch-indexing solution
for re-indexing and a GoLive feature that assures updated indexes are dynamically served.
Note that, you should typically re-index after adding a new field, this is not necessary if the new field applies
only to new documents or data. This is because, were indexing to be completed, existing documents would still
have no data for the field, making the effort unnecessary.
For schema changes that only apply to queries, re-indexing is not necessary.

Cloudera Introduction | 59
FAQs

Can I extract fields based on regular expressions or rules?

Cloudera Search supports limited regular expressions in Search queries. For details, see Lucene Regular
Expressions.
On data ingestion, Cloudera Search supports easy and powerful extraction of fields based on regular expressions.
For example the grok morphline command supports field extraction using regular expressions.
Cloudera Search also includes support for rule directed ETL with an extensible rule engine, in the form of the
tryRules morphline command.

Can I use nested schemas?

Cloudera Search does not support nesting documents in this release. Cloudera Search assumes documents in
the Cloudera Search repository have a flat structure.

What is Apache Avro and how can I use an Avro schema for more flexible schema evolution?
To learn more about Avro and Avro schemas, see the Avro Overview page and the Avro Specification page.
To see examples of how to implement inheritance, backwards compatibility, and polymorphism with Avro, see
this InfoQ article.

Supportability
The following are questions about supportability in Cloudera Search and the answers to those questions.

Does Cloudera Search support multiple languages?

Cloudera Search supports approximately 30 languages, including most Western European languages, as well as
Chinese, Japanese, and Korean.

Which file formats does Cloudera Search support for indexing? Does it support searching
images?
Cloudera Search uses the Apache Tika library for indexing many standard document formats. In addition, Cloudera
Search supports indexing and searching Avro files and a wide variety of other file types such as log files, Hadoop
Sequence Files, and CSV files. You can add support for indexing custom file formats using a morphline command
plug-in.

60 | Cloudera Introduction
 Getting Support

Getting Support
This section describes how to get support.

Cloudera Support
Cloudera can help you install, configure, optimize, tune, and run CDH for large scale data processing and analysis.
Cloudera supports CDH whether you run it on servers in your own data center, or on hosted infrastructure
services such as Amazon EC2, Rackspace, SoftLayer, and VMware vCloud.
If you are a Cloudera customer, you can:
• Register for an account to create a support ticket at the support site.
• Visit the Cloudera Knowledge Base.
If you are not a Cloudera customer, learn how Cloudera can help you.

Information Required for Logging a Support Case

Before you log a support case, ensure you have either part or all of the following information to help Support
investigate your case:
• If possible, provide a diagnostic data bundle following the instructions in Collecting and Sending Diagnostic
Data to Cloudera.
• Provide details about the issue such as what was observed and what the impact was.
• Provide any error messages that were seen, using screen capture if necessary & attach to the case.
• If you were running a command or performing a series of steps, provide the commands and the results,
captured to a file if possible.
• Specify whether the issue took place in a new install or a previously-working cluster.
• Mention any configuration changes made in the follow-up to the issue being seen.
• Specify the type of release environment the issue is taking place in, such as sandbox, development, or
production.
• The severity of the impact and whether it is causing outage.

Community Support
There are several vehicles for community support. You can:
• Register for the Cloudera user groups.
• If you have any questions or comments about CDH, you can
– Send a message to the CDH user list: cdh-user@cloudera.org
– Visit the Using the Platform forum
• If you have any questions or comments about Cloudera Manager, you can
– Send a message to the Cloudera Manager user list: scm-users@cloudera.org.
– Visit the Cloudera Manager forum.
– Cloudera Express users can access the Cloudera Manager support mailing list from within the Cloudera
Manager Admin Console by selecting Support > Mailing List.
– Cloudera Enterprise customers can access the Cloudera Support Portal from within the Cloudera Manager
Admin Console, by selecting Support > Cloudera Support Portal. From there you can register for a support
account, create a support ticket, and access the Cloudera Knowledge Base.

Cloudera Introduction | 61
Getting Support

Get Announcements about New Releases

To get information about releases and updates for all products, visit the Release Announcements forum.

Report Issues
Cloudera tracks software and documentation bugs and enhancement requests for CDH on issues.cloudera.org.
Your input is appreciated, but before filing a request:
• Search the Cloudera issue tracker
• Search the CDH Manual Installation, Using the Platform, and Cloudera Manager forums
• Send a message to the CDH user list, cdh-user@cloudera.org, CDH developer list, cdh-dev@cloudera.org, or
Cloudera Manager user list, scm-users@cloudera.org

62 | Cloudera Introduction