When bringing Apache Hadoop infrastructure into
your environment, integration with existing systems is a paramount
concern. That integration, of course, most commonly takes the form
of building new data movement and transformation pipelines between
the Hadoop Distributed File System (HDFS) and other data endpoints,
such as relational data warehouses, distributed data stores (such
as Apache HBase), and Apache Solr-based enterprise search
servers.

Building these pipelines has long been a common
task for Java developers (long before Hadoop even existed, in fact)
– so much so that writing custom data movement applications in Java
is often considered a core competency. Now, with Hadoop penetrating
the data center, building new pipelines that bring Hadoop into the
data movement network (or integrating a Hadoop cluster with
existing ones), this function is reaching a new apex in
popularity.

For those developers, however, writing these
custom apps is very often an exercise in reinventing the wheel.
Because data formats, sources, and transformation requirements are
so varied, re-purposing code is rarely an option. Furthermore, when
Hadoop is involved as an endpoint, it’s necessary to know your way
around the MapReduce API and be familiar with MapReduce
programming.

In this article, I will describe a new open source
library, Cloudera Morphlines, that reduces the time and skills
necessary to integrate, build, and change Hadoop processing
applications that extract, transform, and load data into HDFS,
Solr, HBase, enterprise data warehouses, or analytic applications.
If you want to integrate, build, or facilitate transformation
pipelines without a lot of Java programming and without
substantial MapReduce skills, and get the job done with a minimum
amount of fuss and support costs, Morphlines is for you.

What is the Morphlines Use Case?

Earlier this year, Cloudera engineers developed
Morphlines in support of the newCloudera Searchoffering (in beta, at the
time of writing), which unites Solr with Hadoop to enable
natural-language search across data in HDFS or HBase. Since the
launch of Cloudera Search, Morphlines development has graduated
into the Cloudera
Development Kit (CDK) in order to make the
technology accessible to a wider range of users, contributors,
integrators, and products beyond Search. The CDK is a set of
libraries, tools, examples, and documentation focused on making it
easier to build systems on top of the Hadoop ecosystem (and hence a
perfect home for Morphlines).

Morphlines powers a variety of ETL data flows
from Apache Flume and MapReduce into Solr or data warehouses and
other end points. Flume covers the real time case, whereas
MapReduce covers the batch processing case.

What is a Morphline?

A “morphline” is a rich configuration file that
makes it easy to define a transformation chain that consumes any
kind of data from any kind of data source, processes the data, and
loads the results into a Hadoop component. It replaces Java
programming with simple configuration steps, and correspondingly
reduces the cost and integration effort associated with developing,
maintaining, or integrating custom ETL projects.

Morphlines is a library, embeddable in any Java codebase.
An individual morphline is an
in-memory container of transformation commands. Commands are
plugins to a morphline that perform tasks such as loading, parsing,
transforming, or otherwise processing a single record.
A record is an in-memory data
structure of name-value pairs with optional blob attachments or
POJO attachments. The framework is extensible and integrates
existing functionality and third-party systems in a simple and
straightforward manner.

Currently, Morphlines works with multiple indexing workloads,
but could easily be embedded into Apache Crunch, Apache HBase,
Cloudera Impala, Apache Pig, Apache Hive, or Apache
Sqoop. Your feedback is welcome and in fact crucial, so please
let us know where you see more opportunities for integration going
forward!

Next, let’s take a look at the Morphlines
processing and data models.

Processing Model

Morphlines can be seen as an evolution of Unix
pipelines where the data model is generalized to work with streams
of generic records, including arbitrary binary payloads. A
morphline is an efficient way to consume records (e.g. Flume
events, HDFS files, RDBMS tables, or Apache Avro objects),
turn them into a stream of records, and pipe the stream of records
through a set of easily configurable transformations on the way to
a target application such as Solr.

The Morphlines framework ships with a set of
frequently used high-level transformation and I/O commands that can
be combined in application-specific ways. The plugin system allows
the adding of new transformations and I/O commands and integrates
existing functionality and third-party systems in a straightforward
manner.

The CDK ships an efficient runtime that compiles
a morphline on the fly. The runtime executes all commands of a
given morphline in the same thread. Piping a record from one
command to another implies just a cheap Java method call. In
particular, there are no queues, no handoffs among threads, no
context switches, and no serialization between commands, which
minimizes performance overhead.

Data Model

Morphlines manipulate continuous or arbitrarily
large streams of records. A command transforms a record into zero
or more records. The data model can be described as follows: a
record is a set of named fields where each field has an ordered
list of one or more values. A value can be any Java Object. That
is, a record is essentially a hash table where each hash table
entry contains a String key and a list of Java Objects as values.
Note that a field can have multiple values and any two records need
not use common field names. This flexible data model corresponds
exactly to the characteristics of the Solr/Lucene data
model.

Not only structured data, but also binary data,
can be passed into and processed by a morphline. By convention, a
record can contain an optional field named _attachment_body, which
can be a Javajava.io.InputStreamor Java
byte[]. Optionally, such binary input data can be characterized in
more detail by setting the fields named_attachment_mimetype(such as“application/pdf”)
and_attachment_charset(such as “UTF-8”)
and_attachment_name(such as “cars.pdf”),
which assists in detecting and parsing the data type. (This is
similar to the way email works.)

This generic data model is useful to support a
wide range of applications. For example,
the Apache Flume Morphline Solr
Sink embeds the morphline library and executes a
morphline to convert Flume events into morphline records and load
them into Solr. This sink fills the body of the Flume event into
the _attachment_body field of the morphline record, as well as
copies the headers of the Flume event into record fields of the
same name.

Commands

Commands can access all record fields. For
example, commands can parse fields, add fields, remove fields,
rename fields, find and replace values of existing fields, split a
field into multiple fields, split a field into multiple values, or
drop records. Often, regular expression-based pattern matching is
used as part of the process of acting on fields. The output records
of a command are passed to the next command in the chain. A command
has a Boolean return code, indicating success or
failure.

For example, consider the case of a multi-line
input record: a command could take this multi-line input record and
divide the single record into multiple output records, one for each
line. This output could then later be further divided using regular
expression commands, splitting each single line record out into
multiple fields in application specific ways.

A command can extract, clean, transform, join,
integrate, enrich and decorate records in many other ways. For
example, a command might join records with external data sources
such as relational databases, key-value stores, local files or IP
Geo lookup tables. It might also perform tasks such as DNS
resolution, expand shortened URLs, fetch linked metadata from
social networks, perform sentiment analysis and annotate the record
accordingly, continuously maintain statistics for analytics over
sliding windows, or compute exact or approximate distinct values
and quantiles.

A command can also consume records and pass them
to external systems. For example, a command might load records into
Apache Solr or write them to a MapReduce Reducer, or load them into
an Enterprise Data Warehouse or a Key Value store such as HBase, or
pass them into an online dashboard, or write them to
HDFS.

The CDK includes several maven modules that
contain morphline commands for flexible log file analysis,
single-line records, multi-line records, CSV files, JSON, commonly
used HDFS file formats Avro and Hadoop Sequence Files, regular
expression based pattern matching and extraction, operations on
record fields for assignment and comparison, operations on record
fields with list and set semantics, if-then-else conditionals,
string and timestamp conversions, scripting support for dynamic
java code, a small rules engine, logging, metrics and counters,
integration with Solr including SolrCloud, integration and access
to the large set of file formats supported by the Apache Tika
parser library, auto-detection of MIME types from binary data using
Tika, and decompression and unpacking of arbitrarily nested
container file formats, among others. These are described in detail
in the Cloudera
Morphlines Reference Guide.

Embedding into a Host System

A morphline has no notion of persistence,
durability, distributed computing, or node failover — it’s
basically just a chain of in-memory transformations in the current
thread. There is no need for a morphline to manage multiple
processes, nodes, or threads because this is already addressed by
host systems such as MapReduce, Flume, or Storm. However, a
morphline does support passing notifications on the control plane
to command subtrees. Such notifications include BEGIN_TRANSACTION,
COMMIT_TRANSACTION, ROLLBACK_TRANSACTION, and SHUTDOWN.

Syntax

The morphline configuration file is implemented
using the HOCON format (Human Optimized Config Object Notation)
developed by typesafe.com. HOCON is basically JSON slightly
adjusted for the configuration file use case. HOCON syntax is
defined at the HOCON
github page.

Conclusion

If you’ve got any questions, please do ask us. The best
place is to do that is in theCommunity Forum for CDK. Alternatively, if
you are trying out Cloudera Search, post your
questions here.